Las vulnerabilidades de software son debilidades susceptibles (es decir, «errores») en el software, a menudo a partir de defectos explotables escritos por el desarrollador o inherentes al lenguaje de programación. No todos los errores de software son vulnerabilidades de seguridad. Para llegar a ser amenaza o riesgo, el error debe ser explotable por un atacante. La mayoría de los errores de software causan problemas de funcionamiento (que en muchas ocasiones el administrador ni siquiera llega a percibir) o incluso una interrupción fatal en el procesamiento, pero no pueden ser aprovechados por un atacante para obtener acceso no autorizado al sistema.

Las vulnerabilidades explotables del software son responsables de un amplio (no el más amplio) porcentaje de ataques en un periodo de tiempo determinado, a pesar de que otros métodos de hackeo (como los troyanos o la ingeniería social) suelen ser muy competitivos. Algunos expertos en seguridad informática piensan que la mayoría de los problemas de seguridad informática desaparecerían si todo el software estuviera libre de errores, aunque esto no es ni cierto ni posible. Sin embargo, aunque no sea la panacea, un código más seguro con menos vulnerabilidades eliminaría una categoría significativa de problemas de hackeo y haría que nuestro entorno informático fuera evidentemente más seguro.

Número de vulnerabilidades de software

Existen varias fuentes que permiten seguir las vulnerabilidades de software públicas, aunque los errores listados para cada una de ellas pueden variar significativamente. De media, cada año, los desarrolladores de software y buscadores de errores más importantes hacen públicas entre 5.000 y 6.000 nuevas vulnerabilidades. Esto significa unos 15 errores por día todos los días. El Common Vulnerabilities and Exposures (CVE), cuya dirección web es http://cve.mitre.org, y sus listas (http://cve.mitre.org/data/downloads/index.html) están considerados como un sitio independiente, de confianza e inclusivo para el informe y seguimiento de vulnerabilidades públicas. Muchos otros proveedores también siguen sus propias vulnerabilidades, así como todas las vulnerabilidades conocidas. Puedes comprobar todos los problemas del Security Intelligence Report de Microsoft (http://www.microsoft.com/sir) para obtener las últimas cifras conocidas, así como un buen análisis.

Evidentemente, estos son solo los errores que el público puede conocer. Muchos proveedores no anuncian públicamente todos los errores y otros no anuncian los errores encontrados por recursos internos o solucionados en versiones de preproducción. Aunque no hay manera de confirmarlo, la mayoría de los expertos piensan que el número «real» de errores es significativamente más alto que la cifra de los que se conocen públicamente.

NOTA El número de vulnerabilidades de software solo es una medida y no es la imagen completa de toda la seguridad de un programa o sistema. La única medida en la que se puede confiar es el nivel de daños de los cuales las vulnerabilidades de software son responsables. Podría darse el caso que el número de vulnerabilidades disminuyera al mismo tiempo que aumentara la cantidad de daños, aunque por lo general tener programas más seguros es mejor para todos.

¿Por qué las vulnerabilidades de software todavía son un gran problema?

Actualmente, los proveedores suelen parchear la mayoría de las vulnerabilidades críticas en cuestión de horas o días. Si esto es así, ¿por qué las vulnerabilidades de software todavía son un problema tan importante, especialmente cuando la mayoría de los proveedores tienen mecanismos de actualización automática para parchear más rápido? La respuesta es que una pequeña parte de los dispositivos informáticos se parchean de forma más lenta o, en un número de casos bastante importante, nunca se parchean. Y cada parche tiene la posibilidad de causar un problema operacional inesperado, lo que a veces causa más frustración en el usuario que el propio error.

El número total de vulnerabilidades es bastante abrumador y constante. Una parte significativa de la gestión del ordenador se dedica a preparar y aplicar parches. Es una increíble pérdida de tiempo, dinero y otros recursos que podrían destinarse a cosas más productivas. Incluso si tanto usuarios como administradores convirtieran el proceso de aplicar parches en una ciencia exacta, en el tiempo que pasa desde que el proveedor lanza el parche hasta que el usuario o administrador lo aplica, los hackers tienen la oportunidad de ganar contra un sistema determinado. Si yo soy un hacker paciente y persistente contra un objetivo concreto, simplemente tengo que esperar a que el proveedor anuncie un nuevo parche y utilizarlo para atacar a mi objetivo.

Cuando los proveedores lanzan un parche, tanto los sombreros blancos como los sombreros negros lo analizan de inmediato para localizar vulnerabilidades. Seguidamente, crean explotaciones que pueden aprovecharse del error. Existen decenas de empresas comerciales, unos cuantos servicios gratuitos y un número no identificado de hackers que hacen esto todos los días. Se pueden comprar y/o descargar escáneres de vulnerabilidades para analizar todos los dispositivos e informar acerca de las vulnerabilidades sin parchear. Estos escáneres de vulnerabilidades suelen tener miles y miles de explotaciones integradas. Existen en todo el mundo muchos sitios web de hackers con miles de explotaciones independientes que se pueden descargar para explotar una vulnerabilidad determinada. Una de las herramientas gratuitas más populares que utilizan tanto sombreros blancos como sombreros negros es Metasploit (https://www.metasploit.com/).

Defensas contra vulnerabilidades de software

La defensa número uno contra vulnerabilidades de software es una mejor formación de los desarrolladores de software y unos lenguajes de programación por defecto más seguros.

Ciclo de vida de desarrollo de seguridad

El proceso de intentar reducir el número de vulnerabilidades de software se conoce actualmente como ciclo de vida de desarrollo de seguridad (Security Development Lifecycle [SDL]). El SDL se centra en cada componente del ciclo de vida de un programa informático, desde su creación hasta el parcheado de nuevas vulnerabilidades detectadas, con el fin de crear software más seguro. Aunque no es un invento de Microsoft, Microsoft Corporation es probablemente quien ha trabajado más en este ámbito y quien ha lanzado más información y herramientas gratuitas (https://www.microsoft.com/sdl) que cualquier otra fuente. La falibilidad humana asegura que el código informático siempre tendrá errores explotables, pero, si seguimos el SDL, podemos tener menos (por el mismo número de líneas de código).

NOTA El Dr. Daniel J. Bernstein (https://es.wikipedia.org/wiki/Daniel_J._Bernstein) es un profesor de universidad que promueve y proporciona un código increíblemente seguro. Es el autor de un gran número de programas informáticos gratuitos y muy utilizados, como dbjdns y qmail, que tienen una cifra muy baja de errores. Incluso suele pagar de su bolsillo a localizadores de errores. Defiende avergonzar públicamente a los proveedores haciendo públicos sus errores antes de que tengan la oportunidad de analizar y parchear sus productos.

Lenguajes de programación más seguros

Unos programas más seguros no pueden ser una realidad sin un lenguaje de programación más seguro. Durante años, la mayoría de lenguajes de programación se han esforzado por crear versiones predeterminadas más seguras. Estos lenguajes intentan reducir o eliminar las causas comunes de las explotaciones. Cabe decir que han tenido bastante éxito y que los programas escritos con estos lenguajes son significativamente más difíciles de explotar que los que han sido creados mediante lenguajes menos seguros.

Análisis del programa y el código

Una vez que un programa ha sido escrito, debe ser siempre analizado en busca de errores conocidos y reconocibles. Esta tarea puede llevarse a cabo mediante análisis humanos o herramientas de software. El análisis humano suele ser el menos eficiente, detecta pocos errores por hora, pero puede localizar errores de explotación significativos que las herramientas no están codificadas para encontrar. Las herramientas de detección de errores normalmente se clasifican en analizadores estáticos y fuzzers. Los analizadores estáticos miran el código fuente (o los programas) en busca de errores de software conocidos en la codificación. Los fuzzers introducen datos inesperados en busca de vulnerabilidades en los programas en ejecución. Muchos de los poco conocidos cazadores de errores, incluyendo el Dr. Charlie Miller, descrito en el Capítulo 36, han confiado en el fuzzing para muchos de sus descubrimientos.

Sistemas operativos más seguros

La mayoría de los sistemas operativos no solo han sido codificados por programadores formados en el SDL que utilizan por defecto lenguajes de programación más seguros, sino que también incluyen defensas integradas contra los vectores de explotación más comunes. La mayoría de los sistemas operativos actuales más populares incluyen defensas de memoria especialmente diseñadas y protegen las áreas más críticas del sistema operativo. Algunos también incluyen software para evitar el desbordamiento de búfer, software antimalware y cortafuegos; todo ello ayuda a limitar errores explotables o sus consecuentes daños.

Protecciones de terceros y complementos del fabricante

Existen miles de programas capaces de defender un sistema informático contra vulnerabilidades de software desconocidas previamente con un mínimo de éxito. Algunos los ofrece el fabricante de forma gratuita o de pago y otros proceden de terceros. Los programas que prometen la detección y detención de nuevas explotaciones son muy comunes y, aunque no son nunca perfectos, pueden reducir significativamente el riesgo de nuevas amenazas. Uno de mis tipos favoritos de software de defensa son los denominados de control de aplicación o lista blanca. Estos programas no detienen la explotación inicial, sino que evitan o complican que los hackers o programas maliciosos provoquen daños adicionales.

El software perfecto no erradicará todos los males

Ninguna defensa puede superar un software que ha sido codificado de forma más segura con menos errores explotables desde el principio. Sin embargo, el software perfecto y sin errores es imposible y no acabaría con todo el hackeo aunque esto fuera posible. Desafortunadamente, las vulnerabilidades de software no son nuestro único problema. Los programas troyanos funcionan simplemente haciendo que el usuario ejecute un programa malicioso. Muchos hackers y programas maliciosos explotan las capacidades inherentes y, por otro lado, legítimas de datos, lenguajes de programación y otros componentes para hacer cosas malas. Y la ingeniería social puede llevar a cabo lo que el software no es capaz de hacer.

Aún así, nadie discute que unos programas más seguros no sean de gran ayuda. En los Capítulos 7 y 8 se presentan dos expertos que han dedicado sus vidas a perfeccionar software. El Capítulo 7 presenta a Michael Howard, quien popularizó prácticas de codificación más seguras, y el Capítulo 8 se centra en Gary McGraw, uno de los mejores buscadores de errores que existen.

7
Perfil: Michael Howard

Michael Howard es contagioso. Es un gran educador, un ponente enérgico y, después de aproximadamente 20 años, sigue tan apasionado de su especialización en seguridad informática, la codificación segura, como lo era en sus inicios. Resulta difícil estar con él más de unos minutos sin desear hacer el mundo más seguro en cada línea de código. Fue conocido a nivel mundial como coautor del libro Writing Secure Code (Escribir código seguro) junto a David LeBlanc, así como por haber sido una parte importante de la razón por la cual Microsoft se dedica ampliamente a escribir código más seguro. Howard, originario de Nueva Zelanda pero establecido actualmente en Austin, Texas, ha colaborado en la redacción de muchos libros sobre la escritura de código más seguro y es un bloguero activo.

NOTA David LeBlanc, coautor con Howard en Writing Secure Code, es otro especialista en seguridad con visión de futuro. Es el responsable de que Microsoft Office sea significativamente más seguro y ha creado un modelo de seguridad para navegadores que han acabado utilizando Google, Adobe y Microsoft.

Le pregunté a Howard cómo empezó en esto de la seguridad informática. Su respuesta fue la siguiente: «Estaba trabajando en las primeras versiones de Windows NT para Microsoft. Me dedicaba a tareas de bajo nivel como control de acceso, criptografía y GINA personalizadas (interfaces gráficas que solían ser la manera de iniciar sesión en Microsoft Windows y otros proveedores de autenticación). Esto realmente me permitió empezar a pensar en la seguridad como una característica más. Sobre el año 2000, estaba claro que las características de seguridad no hacen a un producto seguro, por lo que decidí que me tenía que centrar en funcionalidades seguras, que son una disciplina diferente».

Le pregunté cómo empezó el SDL en Microsoft. Me dijo: «Con el tiempo, varias prácticas relacionadas con la seguridad aprendidas por los equipos de SQL Server, Office, Windows y .NET Framework y otros evolucionaron hacia el ciclo de vida de desarrollo de seguridad (SDL). El SDL ayudó a popularizar el código seguro y el movimiento de diseño seguro y actualmente es la fuerza que dirige la mayor parte de las empresas que mejor protegen su software ».

Le pregunté si el SDL fue una pequeña mejora de algo que había leído o si lo había construido de la nada sin ninguna referencia previa. Me contestó: «Todos construimos sobre el trabajo de otros, pero la mayor parte del SDL surgió de acciones y aprendizaje. Lo que funciona se mantiene y lo que no funciona o no es completamente práctico se tira. A veces me pregunto si alguno de los modelos académicos ha sido probado en un entorno de producción alguna vez, con plazos, requisitos de desempeño, tiempo para sacarlo al mercado, aspectos económicos, requisitos de compatibilidad anteriores, etc.

»En ese momento, había una enorme escuela de pensamiento que creía que si se puede aumentar la calidad general del código también se aumentará directamente la seguridad del código. Pero yo aún no he visto ninguna evidencia empírica de ello. Puedes hacer un código SQL funcional que pase todas las pruebas de funcionalidad, pero podría estar plagado de vulnerabilidades de inyección de SQL. Si nunca has aprendido qué es la vulnerabilidad de inyección de SQL, todo cuanto verás será un código perfecto, que hace lo que se supone que tiene que hacer. Un sistema seguro solo hace lo que se supone que tiene que hacer y nada más, y esta es la “funcionalidad extra” que viene con la vulnerabilidad de inyección de SQL que lo hace inseguro».

Le pregunté cuál era su papel en Microsoft al adoptar las prácticas SDL. Me dijo: «Era una sinergia de muchas cosas distintas con las que tanto yo como otros estábamos involucrados. Empecé en el año 2001, cuando el equipo .NET daba un evento de “concienciación de seguridad” para analizar los problemas de seguridad existentes y los riesgos potenciales. Aprendimos mucho y se añadieron muchas defensas nuevas. Recuerdo que habíamos preparado camisetas especialmente para el evento con las fechas, y se produjo un gran temporal de nieve y tuvo que aplazarse. Fue muy irónico que, en un evento de código más seguro, apareciera en nuestras camisetas una fecha incorrecta. No obstante, lo que surgió de este evento fueron aprendizajes que nutrieron de algún modo el SDL. El libro de David y mío vio la luz e hizo que mucha gente pensara más en la seguridad del código. Microsoft fue atacada en 2001 por un elevado número de malware y de hackers. Los gusanos Code Red y Nimda fueron especialmente fuertes. Entonces, Bill Gates nos preguntó acerca de la naturaleza de las vulnerabilidades de software y por qué todavía existían. Yo fuí elegido como parte del equipo que se reunió con Bill Gates. Le entregué una copia de nuestro libro Writing Secure Code y, desde esa reunión, escribió su famoso memorando Trustworthy Computing. En el informe, Bill mencionaba nuestro libro, ¡el cual tuvo unas ventas estratosféricas! Acabé trabajando en la recientemente creada división Trustworthy Computing de Microsoft. Esto empezó un proceso de concienciación de seguridad adicional (también para Windows, SQL Server y muchos otros productos de Microsoft). El SDL los generó y actualizó todos, y los mejoró e hizo más eficientes. Y continúa actualizándose una vez al año».

Le pregunté si era cierto que él y Microsoft habían publicado más información y herramientas relacionadas con la codificación segura que otras empresas. Y me dijo: «De manera inequívoca y enfática, ¡sí! Pero lo que es más importante son las herramientas y las técnicas que utilizamos en nuestro entorno de producción, en millones de líneas de código de producción, cada día. No se trata de un ejercicio académico, sino que es lo que hace una de las empresas más grandes del mundo. Y nosotros lo compartimos prácticamente todo».

Le pregunté por qué, si los programadores de todo el mundo están mejor formados en problemas de seguridad informática, no se anuncian menos vulnerabilidades. Me contestó lo siguiente: «Bueno, seguramente hay más software con más líneas de código. Pero el verdadero problema es que los programadores todavía no están formados en codificación segura y no han entendido las amenazas básicas de seguridad. La enseñanza aún está muy atrasada en la mayoría de los casos. El otro día estaba revisando el programa de un curso de seguridad informática en la universidad y casi el 50 % del curso estaba centrado en amenazas de red de bajo nivel. No había formación en seguridad en la nube o codificación segura. Nuestras universidades todavía están formando a programadores sin muchas nociones de seguridad informática o codificación segura, que parece una broma si pensamos que estos, cuando se gradúen, crearán sistemas críticos conectados a Internet. Yo sigo buscando errores en códigos de otra gente. Cuando muestro un problema de corrupción de memoria o una vulnerabilidad de inyección SQL —algo muy básico y común—es como si hubiera hecho algo mágico o especial. Es tan difícil encontrar nuevos programadores que realmente entiendan los fundamentos de la seguridad informática que me emocionaré si el candidato como mínimo se preocupa por ello. Si el programador pone los ojos como platos cuando le hablo de problemas de seguridad informática, me siento muy feliz. Si al menos muestran interés, ya podemos enseñarles todo lo demás. Os sorprendería cómo a muchos no les preocupa este tema, y la principal razón de ello es porque todavía no se enseña. O se enseñan cosas incorrectas, como centrarse en seguridad de redes u otras pequeñeces. Las escuelas enseñan a los alumnos el funcionamiento detallado del algoritmo RSA, y no dedican el tiempo a enseñar por qué se debe utilizar, qué problemas resuelve y para qué es una buena solución. Saber cómo utilizar algo para resolver problemas de seguridad reales es mucho más importante que saber cómo funciona. Todos podemos memorizar un protocolo, pero necesitamos personas que conozcan los riesgos y piensen en soluciones. Algunos profesores y universidades lo están haciendo correctamente, como Matt Bishop de la Universidad de California, en Davis, y son los heroicos esfuerzos de Matt y otra gente lo que lo hacen posible. Él y el resto de profesores como él son los verdaderos héroes».

Le pregunté que, si la mayoría de las universidades no preparaban de forma adecuada a nuestros programadores en este ámbito, qué es lo que podía hacer un programador por su parte. Y me dijo: «Seguir aprendiendo. Yo tengo marcada en mi agenda una hora cada día que dice “Aprender”. Y leo/codifico/pruebo durante una hora algo que no conozco, cada día. Y lo he estado haciendo durante toda mi carrera. En segundo lugar, si no te estás formando en seguridad informática de un modo formal, hazlo tú mismo. Dirígete al CVE (http://cve.mitre.org/cve/), lee sobre los errores recientes, lee sobre ellos atentamente con todo detalle. Después, escribe el código que tiene la vulnerabilidad e imagínate cómo debería ser para prevenir esta vulnerabilidad, tanto a nivel técnico como de procesamiento. ¿Cómo ha ocurrido la vulnerabilidad y se ha situado en el código en primer lugar? Y, por último, utiliza todas las lecciones aprendidas para mantener esos mismos tipos de errores fuera del propio código».

Le pregunté qué podrían hacer la mayoría de las empresas para escribir código más seguro, además de seguir todos los consejos actuales del SDL y utilizar sus herramientas. La respuesta fue la siguiente: «Hacer que los programadores entiendan las amenazas reales, no solo la parte teórica. Y construir el proceso de seguridad en proceso de desarrollo, de forma que el código inseguro y malo no tenga cabida. En Microsoft, los llamamos Quality Gates. Un buen ejemplo (no de seguridad) es alguien que escribe código que asume que todas las direcciones IP tienen cuatro octetos. Esto significa que el código no funcionaría nunca en un entorno IPv6. Este código no puede ser enviado a nuestros repositorios de código porque una herramienta que se ejecuta automáticamente encontrará un problema y rechazará la entrada. Esto es lo que nosotros conocemos como Quality Gate. No obstante, por seguridad, lo puedes repetir en casos de inyección SQL, amenazas de seguridad de memorias y cualquier otra cosa que no quieras incluir en el código.

»Si tuviera que elegir unas cuantas sentencias básicas relacionadas con la seguridad, estas serían:

■ Los desarrolladores deben aprender a no confiar nunca en los datos de entrada y a validar los que son correctos, preferiblemente mediante una biblioteca revisada y probada correctamente. Si quieres que los datos tengan una longitud de solo 20 bytes, no permitas más de 20 bytes, si quieres que sea un número, comprueba que lo sea, etc.

■ Diseñadores/arquitectos/gestores de programas deben aprender a modelar amenazas y comprobar que las defensas correctas se encuentran en su lugar en el sistema.

■ Por último, los probadores necesitan probar que los desarrolladores se equivocan al crear o facilitar herramientas que generen información maliciosa y/o deformada. El objetivo es vencer las comprobaciones de los desarrolladores, ¡si es que tienen alguna!

»Existe mucho más en la seguridad de software que lo que he dicho, pero estas son, en mi opinión, las habilidades fundamentales relacionadas con la seguridad que todo ingeniero de software debería tener».

Prev.1 ...3 456 Next

Hackear al hacker

Para más información sobre Kevin Mitnick

6Vulnerabilidades de software