sábado, julio 29, 2006

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.

9 comentarios:

  1. Muy bueno el artículo.
    Aunque en el tema de auditar código, seguridad, y codear actualizaciones y hotfixes, Microsoft ha ido aprendiéndolo con el paso del tiempo, a base de muchas equivocaciones. Todavía tenemos servidores antiguos con un 2kserver en inglés, instalados en su día por el tema de las actualizaciones críticas (que llegaban antes en idioma en-en). Pienso que Microsoft ha hecho balance de la usabilidad vs seguridad en los últimos años, para mejor. Y una buena parte de este cambio es fruto del despertar de GNU/Linux. La competencia ayuda a mejorar y a reciclarse!
    Por cierto perra... Has estado en Sevilla y ni me he enteráo! :)
    Para la próxima me avisas con tiempo y nos vamos de tapitas por Triana city!...

    ResponderEliminar
  2. Estoy contigo Silverhack. Microsoft ha cometido los errores y ha ido aprendiendo. En el tema de las actualizaciones el caso del RPC fue el detonante.

    Y tb estoy contigo la competencia es buena y debe existir.

    Lastima lo de Sevilla, avisaré con tiempo la próxima vez.

    ResponderEliminar
  3. Hola Chema, te estoy promocionando la idea del Deathmatch aquí en Canarias y hay bastante gente interesada en asistir al evento por lo menos online para aprender, ya que como bien sabes, aquí el tema de la aplicación de los conceptos de seguridad esta aun algo verde.

    ¿tienes algún email para la suscripción de los participantes?

    Yo he creado 2 cuentas para que se apunte la gente que quiera formar parte de uno u otro equipo.

    deathmatch-linux@aghconsultores.com
    deathmatch-windows@aghconsultores.com

    Ale el Canario

    ResponderEliminar
  4. A partir de Septiembre empezamos en serio con el Deathmatch, ahora estoy pensando en ..."otras cosas". Esta noche pondré un post para moverlo.

    ResponderEliminar
  5. Hola Pedro,

    How long time without know things about you!!

    Bueno, yo con YaST he instalado SW. Seguro!. Y aquí, según la wikipedia dice que sirve pa eso tb!

    Un saludo!!

    http://es.wikipedia.org/wiki/YaST

    ResponderEliminar
  6. Hola, soy Marta Pastor de Radio Nacional y estoy intentando ponerme en contacto contigo para una entrevista sobre el uso de los blogs. Mi email: marta@martapastor.com Si puedes me envias un telefono movil para llamarte y concertar la entrevista

    ResponderEliminar
  7. Hola Pedro!

    mira que has venido guerrero de vacaciones!!. En fin. vamos por partes compi.

    En el caso de la gestión de paquetes SUSE y RedHat. El mensaje no es mio compi, ya me gustaría!, pero es algo que hace tiempo que se habla. A ver si me explico bien, que no he debido de hacerlo.

    Si tú tienes un servidor con SUSE con soporte de pago debes instalar las actualizaciones que te de SUSE y si lo tienes con RedHat, las que te de RedHat. Nadie, y repito nadie, te garantiza que SUSE y RedHat paqueticen la misma versión con la misma aplicación de parches en cualquiera de los paquetes que componen una actualización, ya que al ser un desarrollo continuo en la mayoría de los proyectos, la versión que tendrás en un determinado paquete dependerá del día en que se hace.

    Un ejemplo: El kernel de linux subre aprox. 2,5 cambios a la hora y se sacan nuevas versiones cada muy poco tiempo, prácticamente se saca una nueva construcción entre 5 y 7 días. Así el día 14 de Julio salía la versión 2.6.17.5 y el día 25 de Julio la 2.6.17.7 y entre medias la versión 2.6.17.6.

    Una distribución no puede estar siempre actualizando, ya que debe juntar unos mil paquetes distintos y probarlos juntos. Para ello, se corta en una determinada fecha. Un ejemplo real, RedHat, para sacar la vesión RHEL 4 cortó a mediados de Octubre de 2004, seleccionó todos los paquetes en las versiones que había y empezó a montar la distro para hacer pruebas (tienen que funcionar todos bien, hay que documentar, etc, etc... vamos, lo que es hacer un Sistema Operativo). La versión final salió a mediados de febrero de 2005, es decir, 4 meses después. En ese periodo, el kernel pasó de la versión 2.6.9 a casi la versión 2.6.11 que salió a primeros de marzo del 2006. Estos cambios, al igual que con el kernel, fueron sufridos, en menor o mayor grado por el resto de los paquetes de la distribución. La pregunta es, ¿cuantos parches críticos han salido en esos 4 meses? ¿Cuantos paquetes debemos actualizar? ¿cuantos se tienen que volver a probar? Si se actualiza otra vez todo, entonces se tiene que volver a empezar el trabajo de pruebas, doc, etc.. (otros cuatro meses?) y así nunca se puede parar. Así que se corta, se aplican parches críticos y se saca la distro con una determinada versión.

    Periodicamente se van actualizando paquetes de la distro que se prueban y se van actualizando en distintas versiones.

    La pregunta es SUSE y RedHat eligen los mismos instantes de tiempo para paquetizar los distintos proyectos que componene su distro? NO, tajantemente.

    Ejemplo real: la versión SLES 9 empezó a paquetizar en Abril de 2004 y en Agosto de 2004 sacó la versión. Cada uno lleva su propio ritmo de pruebas, documentación, construcciones, etc...

    Entonces, dos servidores actualizados al máximo de versiones que nos ofrecen nuestro proveedor (SUSE o REDHAT) no nos garantiza que tengamos la misma versión de un proyecto. Puedes actualizar todos las actualizaciones que te ofrece SUSE de un proyecto y tendrás la última que ellos han probado y funciona al igual que hace Redhat y en una puedes tener la 2.6.9.3 y en la otra la 2.6.9.4. De hecho, si buscas el último kernel paquetizado en rpmfind encontrarás la 2.6.9-34.0.1 para RHEL mientras que para Fedora tienes la 2.6.9.17-1. y compilaciones de la dosmil y pico en adelante. ¿que te lo puedes poner a mano? Claro que sí!!, pero sin soporte.

    Respecto a lo del DDK, bueno, ya te lo expliqué, en mi post, tras acercarme a hablar con una doctora y un profe de desarrollo de Drivers en la universidad en mi posts. Si te parece que es lo mismo pq tengan las mismas siglas adelante compi, pero cuando quieras los ves funcionar.

    No obstante Pedro, me apunto a pedirte ayuda cuando tenga dudas.

    PD: Los estudios de las disparidades de versiones no son mios, como comprenderás. Son buenos y de alguien que se dedica solo a estudiar esas cosas.

    Un besoT

    ResponderEliminar
  8. Bueno, esa será tu decisión no? En mi artículo yo constataba un hecho. Puedes tener dos distros totalmente actualizadas y no te garantizan la misma versión ni de kernel. Solo es un hecho en el sistema de actualizaciones.

    Un besoT Pedro.

    ResponderEliminar
  9. Bueno, supongo ke a la gente le gustaa tener una SUSE y una RedHat igual que los senos de silicona, uno de cada tamnyo, como las autenticas ke nunca miden lo mismo!!!


    jajaja; dejemoslo ya Pedro; ke se nos va la pinza!!!


    besoTs

    ResponderEliminar