De Cañas

Regreso de Sevilla, después de pasar un par de días dabutis. El fumar en el paseo por la noche al lado de la Torre del Oro, tomar unos vinos con flamenquines en el Salvador o un Queso Camenberg frito con mermelada de frambuesa y un tinto de verano con blanca al lao de la Catedral ha estado dabuti, pero ahora hay que seguir con la "fiesta".

Ahora, para los más amigos de la "Fiesta Sangrienta Tecnológica" os paso el artículo que publiqué en la revista E-Security de los meses de Junio y Julio. El artículo lo escribí después de leer en la misma revista que un linux instalado en el 2002 y sin ninguna actualización de seguridad no sería hackeable. Ahí es ná. Así que pensé, "Joder, si en el lado del bien se puede decir lo que quieras, voy a escribir yo un artículo a mi rollito, como si llevara dos copas, un peta y estuviera en una bodega de esas donde tomaba los litros en Móstoles" y me salió esto. Parece que les gustó y me pidieron la segunda parte que sale el mes que viene y en la que creo que ya se me nota el pedo de los litros, las copas y los petas.

Nota: El Artículo se escribió en Mayo del 2006 y los que seguís este blog ya lo conoceréis casi todo.

El mantenimiento de una infraestructura Segura.
Parte 1. Sistemas Actualizados.

Cada mañana me levanto y lo primero que hago es encender el portátil. Esta es una rara dependencia digna de ser mirada por el psiquiatra que muchos de los que nos dedicamos a la seguridad acabamos desarrollando. En mi buzón tengo a primera hora, calentitas, las newsletters a las que, como seguro muchos de vosotros, estoy suscrito. El mecánico proceso me lleva a ver primero que selección de noticias de seguridad vía RSS ha realizado la comunidad hacker de Zone-h y ver, al mismo tiempo, las webs que han sufrido un ataque de defacement (grafittis en web) mientras yo he dormido. Acto seguido leeré el asunto de la newsletter de Bernardo y compañía en Hispasec, para momentos después conectarme a los expedientes de seguridad publicados en la base de datos de Bugtraq id en Securityfocus. Sí la suerte me acompaña recibiré la newsletter quincenal de mis tiendas de comics favoritas (aquí cada uno con sus vicios, yo como el Robe, los tengo todos) y la newsletter mensual del Brujo en Elhacker.net.

Y así comienza un nuevo día, con un montón de problemas de seguridad para todo el mundo. Cada día hay entre 30 y 40 expedientes de seguridad nuevos que afectan a todas las plataformas, alrededor de 3000 sitios hackeados en zone-h (algún día se pasaron los 30.000) y un montón de nuevas herramientas y exploits listos para utilizar por los atacantes de sistemas. ¡Viva la fiesta!.

El mundo ideal de este entorno sería contar con software perfecto [aquel que hace lo que tiene que hacer y nada más], pero como decía Santo Tomás sabiamente, “nada imperfecto puede crear algo perfecto” así que, como nosotros somos seres imperfectos creamos tecnología imperfecta. Esto por desgracia es así y con ello hay que vivir. Además el exceso de orgullo en la ignorancia de esta máxima nos lleva a campañas cómo la de “Oracle makes Linux Unbreakable”, que recibió su último ataque con la presentación de David Litchfield en las BlackHat Federal Conferences (Enero 2006) con su presentación “Oracle Breakable”. Previamente Michael Lynn, en su presentación para BlackHat en Junio de 2005 ya hizo una alegoría a esta campaña con una foto de gente escapando en una lancha del hundimiento de un barco. El título de la diapositiva decía “Another Unbreakable System”. Yo viví una experiencia similar con un amigo que me retó públicamente en una lista de correo a que no le tumbaba su servidor Apache y al final tuvo que postear un reconocimiento de caída de su servidor.

Hay que vivir con ello, y así es. En Microsoft, hace ya varios años, con la puesta en marcha de la Iniciativa de Informática de Confianza (Trustworthy Computing Iniciative) que se pusieron a trabajar desde el principio. Contratando, entre otros a Michael Howard, reconocido en el mundo por sus trabajos sobre seguridad en código [Writting Secure Code] para formar a los ingenieros en el desarrollo seguro de plataformas. Él y su equipo (Microsoft Security Team) se encargan de definir y realizar las pruebas de seguridad que los productos deben de superar, tienen potestad de veto para retrasar el lanzamiento de un producto o quitarle alguna funcionalidad si estiman que este no cumple con los requisitos de seguridad establecidos.

Para mejorar la seguridad de sus productos Microsoft se embarco en varias medidas con el lanzamiento en Enero del 2002 de su iniciativa de informática de confianza (Trusworthy Computing) y hay varias que, a mi juicio, marcan la diferencia con respecto de muchos de sus competidores.

SDL (Security Development Lifecycle - Ciclo de desarrollo seguro)

Es el proceso mediante el cual Microsoft desarrolla software y que define tanto los requisitos como los hitos de seguridad que los productos han de cumplir. Microsoft es una factoría de software que cumple con los ciclos de vida de sus productos, y en ellos se incluyeron 24 subtareas relacionadas con la seguridad entre la fase de desarrollo y mantenimiento. Entre ellas, las referentes a la gestión de fallos de seguridad en los productos.

El Parche

Cuando una nueva vulnerabilidad es descubierta (en más del 90% de los casos esto se produce internamente) se realiza un análisis completo que permita conocer el origen del error para proceder a preparar una actualización que arregle dicha “funcionalidad no conocida” (bug). Dicho parche será puesto a disposición del cliente de la forma más adecuada y siempre pensando en lo mejor para el destinatario de la actualización. Hay que tener en cuenta que la publicación de un parche de seguridad de un producto es el banderazo de salida para la carrera entre los que van a generar una amenaza y los clientes en la puesta en producción del parche. Esto es así ya que la aparición de un parche ayuda a los atacantes a, mediante ingeniería inversa de la actualización, conocer cuales son las partes vulnerables en un sistema sin actualizar. Además, cada parche deberá ser probado exhaustivamente en los entornos de trabajo de los clientes. Un parche que se tarda en programar unas 3 horas puede tener 1 semana de pruebas. Es decir, el cambio de 3 líneas puede generar más de 800.000 pruebas distintas.

La elección de adelantar la publicación de un parche o no depende del nivel de criticidad de la vulnerabilidad, del nivel de conocimiento externo de la misma y de la existencia o no de exploits que saquen partido de ella. A esto se llama Responsable Discloussure. Esto ha ayudado a las empresas a poder planificar el ciclo de mantenimiento de sus sistemas y poder planificar las fases de pruebas y puesta en producción del software actualizado.

Retroalimentación

Al mismo tiempo que se lanza la tarea de actualizar el software se produce una tarea interna de aprendizaje y eliminación de problemas similares en otras piezas de software. Para eso se sintetiza un patrón que permita encontrar el mismo problema en cualquier código de la compañía y que va a ser introducido dentro de las herramientas de auditoría de código de forma automática. Estas herramientas son lectores de código fuente que están alimentadas con todos los patrones que generan software vulnerable para que puedan ser detectados fallos antes de que los productos lleguen a manos de los clientes.

Delivery

El último punto fuerte a destacar dentro de esta forma de actualizar el software termina con un amplio abanico de posibilidades para la gestion de actualizaciones. Hay soluciones sencillas y gratuitas como los servicios de Microsoft Update Services que permiten, actualizar un equipo o interconectar un Windows Services Update Server (WSUS) para actualizar toda una red. El MBSA, que sirve para auditar el nivel de actualización de un sistema. Para los enternos empresariales mas grades y complejos se puede utilizar la potencia y funcionalidad de SMS

¿Y en el otro lado?

En el mundo de GNU/LINUX las cosas se hacen de otra forma. En primer lugar cada proyecto tiene su propia política en la generación de actualizaciones….un momento, antes de nada, en el otro lado también hay vulnerabilidades, y en concreto en el kernel de Linux cada vez más según Morton, segundo a bordo de Linus Torvalds en el proyecto del kernel quien reconocía el 10 de Mayo en la LinuxTag conference en Alemania, que el kernel está “slowy getting buggier” e incluso Linus Torvalds reconocía que el problema es real aunque no tanto como se quiere hacer ver por ahí.

El primer problema que tenemos es la poca homogenización de políticas en la gestión de vulnerabilidades de seguridad. Lo único que sí que tienen todos es una apuesta por el Full Disclousure. Esta apuesta total a veces va en contra de los intereses de posibles clientes. Crispin Cowan, lider del proyecto Sardonix, que nació para auditar el código de los proyectos Open Source, se lamentaba de que los investigadores de seguridad estaban únicamente interesados en encontrar bugs sorprendentes en lugar de securizar las aplicaciones.

Además de la motivación, claramente decantada hacía el lado del mal…digo hacia la búsqueda del fallo en lugar de hacia la corrección, hay que asumir, en la elección de una plataforma GNU/Linux que el código no cuenta con esa retroalimentación de herramientas automáticas para la búsqueda de fallos de seguridad. No ha sido hasta el año 2006 cuando la Agencia de Seguridad Nacional ha subvencionando el proyecto Bug Hunting entre la Universidad de Stanford y la empresa Coverity para, con herramientas automáticas, auditar el código de los principales proyectos OpenSource. Así se ha visto que el kernel, quizás programado por algunos de los mejores desarrolladores del mundo, tenía 841 fallos (en 3 millones de líneas de código), demostrando así que es necesario el uso de herramientas automáticas para auditar el código. Este análisis mediante herramientas automáticas es lo que Microsoft hace, con sus productos en fase Beta, antes de entregar a sus clientes.

¿Y las distribuciones?

Las distribuciones de GNU/Linux, a pesar de que a veces les hacen parecer como los malos de la peli los mismos partidarios del Open/Free Software, a parte de apoyar económica y con recursos en los principales proyectos, tienen que lidiar entre unos ideales, a veces más fuertes que la realidad tecnológica de algunos, y unos objetivos económicos. Esta disparidad lleva a situaciones como el cierre que se ha producido recientemente de Fedora Foundation [14], entre otros motivos. Este “no control total” sobre el proceso de desarrollo de los principales programas de la distribución hace que el avance tecnológico sea mucho más costoso para ellas ya que son competidoras entre sí. Así Hovsepian, presidente de Novell y dueños de SUSE Linux reconocía que el 60% de los equipos de la compañía aún tienen Windows en arranque dual ya que se dieron cuenta durante el proceso de la migración de que les faltaban componentes clave, en la próxima versión de la distro será.

Hay que tener en cuenta que el costo de solucionar problemas en un producto de software después de su implantación, es unas quince veces superior al costo de detectar y solucionar el problema durante su desarrollo, mediante una correcta ingeniería de software. Si para lo último se ha recurrido, tal y como ya comentamos, a la subvención del Gobierno Americano, para lo primero tendremos que esperar a ver quien paga la factura. De momento lo que hay encima de la mesas es un problema de interoperatibilidad entre distribuciones. Se habla mucho de la interoperabilidad GNU/Linux con plataformas Microsoft, pero el problema de interconectar distribuciones, existe y se agranda, con el nacimiento de las “distro cuartinex” (la de mi cuarto). El sistema de actualización de software que usa SUSE es Yast mientras que, por ejemplo, el que usa RedHat es RPM. Así, si tengo dos tipos de plataformas Linux en mi organización, (RedHat/SUSE) y quisiera poner un servidor de paquetes en mi compañía (para no saturar la conexión de Internet) tendría que montar un servidor de RPMs y un servidor de SUSE, y lo peor, como cada uno paquetiza cuando considera en el tiempo y versión, con dos clientes GNU/LINUX actualizados al mismo tiempo por distinto servidor no podríamos garantizar que tienen la misma versión de software instalado.