lunes, 21 de noviembre de 2011

Patch Bindiffing (II)

La semana pasada nos quedamos en un anterior post con que habíamos analizado un parche y habíamos descubierto que ficheros del sistema habían sido añadidos o actualizados.

Ahora nos quedaba la segunda parte, que es... ¿qué modificaciones se han hecho sobre estos binarios?
Para hacer esto tendremos que coger las dos versiones del binario, librería, o en este caso driver, y emplear alguna de las herramientas que existen para hacer este análisis diferencial.

Para este caso concreto he usado una extensión de IDA, desarrollada por Tenable, llamada patchdiff2, y que os podeis descargar de forma completamente gratuita aquí.

Hay otras extensiones para IDA que realizan estas mismas acciones. Vierito5 publicó hace tiempo en su blog una lista de extensiones recomendadas para IDA en las que, además de otras muchas extensiones de todo tipo, podemos encontrar varias opciones para realizar bindiffing.

Para añadir uno de estas extensiones únicamente hay que buscar el directorio "plugins" dentro del directorio de IDA. Lo reconoceremos porque veremos que tiene dentro ficheros con extensión "*.pmc", que son exactamente como los que nos vendrán en el zip del patchdiff2. Dejamos los "pmc" del patchdiff2 en este directorio y ya tendremos completamente disponible la extensión la próxima vez que arranquemos IDA.

Para poder utilizar el bindiffing es necesario que este se haga a partir de los ficheros "*.idb" de IDA, que es un formato propio de esta herramienta en el que podemos guardar el análisis que realiza la herramienta sobre un binario concreto. Para ello, abrimos el primero de los binarios (tcpip-old.sys) y dejamos que IDA lo pre-procese, y cuando acabe de hacerlo cerramos y elegimos guardar la base de datos, con lo que se nos generará un fichero tcpip-old.idb, que usaremos a continuación.

Ahora abrimos de nuevo IDA pero esta vez elegimos analizar tcpip-new.sys, y dejamos de nuevo que IDA lo pre-procese. Una vez que acabe nos vamos al menú "Edit" y a "Plugins", y elegimos el plugin "PatchDiff2", con lo que se nos abrirá una ventana para elegir con que otro fichero "*.idb" lo queremos comparar. Elegimos tcpip-old.idb y lo dejamos que realice el bindiffing.

Al hacer esto, veremos que nos salen tres pestañas nuevas:

  • Identical Functions: Son aquellas que han sido detectadas como idénticas en ambos binarios, es decir, no han cambiado al hacer el bindiffing.
  • Unmatched Functions: Son aquellas de las que, teóricamente, no se ha podido encontrar una función equivalente en el otro binario. Generalmente suele tratarse de funciones nuevas, aunque es muy común que nos encontremos muchas funciones idénticas pero que por algún motivo no se han hecho match. La columna CRC nos puede dar una pista sobre esto.
  • Matched Functions: Son aquellas que han sido detectadas como que son las mismas, pero que han sufrido alguna modificación

Sabiendo esto, y dado que nos estamos centrando en un bindiffing, podemos asumir que las funciones que han hecho match completo no nos interesan, y que las unmatched que tengan un CRC idéntico o que sean completamente nuevas, tampoco nos interesan (a priori, si notamos que nos falta información volveremos atrás), ya que las funciones nuevas tienen que ser llamadas desde ningún sitio, así que su "origen" lo vamos a tener pillado a través de las funciones "matched".


En este caso, tenemos cinco funciones que parecen haber sido modificadas por el parche, así que alguna de ellas tiene que haber sido la que corrige la vulnerabilidad, o quizá una combinación de varias de ellas.

Para poder ver los cambios exactos introducidos en cada una de ellas, deberemos seleccionar la función y pulsar con el botón secundario del ratón para que nos salga el menú, y elegiremos la opción "Display Graphs".


Una vez que vemos gráficamente la función, vemos de una forma muy clara las modificaciones realizada, ya que el código se encuentra separado en bloques con un código de colores que nos proporciona información sobre estos cambios:

  • Blanco: Bloques idénticos, es decir, no se ha producido ningún cambio en ellos.
  • Gris: Bloques "unmatched", generalmente trozos nuevos de código que serán llamados desde algún otro bloque modificado.
  • Rojo: Bloques "matched", es decir, que han sufrido algún tipo de modificación.

No os puedo remitir a la documentación de PatchDiff2 para más información, ya que al menos yo no he encontrado ninguna fuente oficial, pero podeis encontrar información buscando en Google, o sencillamente jugando un poco con ella, ya que permite hacer correcciones sobre el análisis automático que hace, es decir, podeis pasar de "unmatched" a "matched" una función, y cosas así.

En el próximo post, veremos cada una de estas funciones, a ver que cambios concretos ha realizado el parche, a ver si conseguimos averiguar en que consiste la vulnerabilidad que parchea.

miércoles, 16 de noviembre de 2011

Encuesta: Cursos del SANS Institute en España

Como ya se comentó en el anterior post, publicamos una encuesta sobre los cursos y modalidades del SANS Institute más demandadas, con el fin de plantear los cursos de 2012 en adelante.

Os pido que, al completar el formulario, seais sinceros con respecto a los cursos y modalidades a los que OS APUNTARIAIS, no solo los que os interesan, sino en los que realmente existen altas probabilidades de que pudiéramos contar con vosotros como alumnos. Toda la información sobre cursos, modalidades, precios, etc, se puede encontrar aquí. La descripción de muchos cursos aún no está, pero podéis mirarlo directamente en la web del SANS, o simplemente completar el formulario más adelante.

lunes, 14 de noviembre de 2011

Patch Bindiffing (I)

Todos sabemos, más que nada por lo mediáticos que son, lo que son las vulnerabilidades/exploits 0-day, que son vulnerabilidades descubiertas por alguien que no notifica al creador del producto, sino que utiliza el exploit para su propio provecho, o simplemente lo publica en full-disclosure, antes de que pueda prepararse un parche.

Otro tipo de exploits que podamos encontrar son los 1-day. La explotabilidad de los 1-day está muy estrechamente relacionada con la lentitud de algunas personas o entidades en aplicar los parches de seguridad. Una vez que el fabricante del producto saca un parche, aunque no proporcione mucha información acerca de la vulnerabilidad, dicho parche es analizado para obtener toda esa información, y de este modo poder tener un exploit funcional para dicha vulnerabilidad. Si esto se consigue en un día o en unos pocos días (de ahí su nombre), podemos decir casi con seguridad que habrá muchas potenciales víctimas que no tendrán parcheados sus sistemas.

Para ejemplificar esto, vamos a utilizar la vulnerabilidad MS-11-083, publicada por Microsoft la semana pasada y que, según parece, podría provocar ejecución remota de código mediante el envio de paquetes UDP en sistemas Windows 7 y Windows 2008.

Para poder hacer un Bindiffing, lo primero que tenemos que hacer es obtener dos binarios sobre los que hacer el diffing, ¿verdad? ¿cómo conseguimos esto? Siguiendo estos pasos:
  1. Instalamos un Windows 7 (en este caso) en una máquina virtual y lo actualizamos hasta que nos aparezca para actualizar el parche en cuestión que queremos analizar. Éste no lo instalamos.
  2. Nos descargamos e instalamos en la máquina el RegShot o alguna herramienta similar, que nos sirva para tomar snapshot fichero a fichero de todo el sistema.
  3. Hacemos un Snapshot completo de la máquina virtual.
  4. Lanzamos RegShot para hacer un Snapshot de todos los ficheros. Por comodidad, ya que sabemos que es un parche de sistema, le podemos decir que busque solo en C:\Windows, que siempre irá más rápido que hacer Snapshot de todo el disco. Elegimos la opción "shot and save" para que nos guarde el snapshot en un fichero, ya que este parche necesita reiniciar y sino perderemos el estado.


  5. Instalamos el parche. Nos pedirá que reiniciemos.
  6. Volvemos a lanzar RegShot, pero esta vez en la opción "1st shot" elegimos "load" y cargamos el snapshot que hicimos antes de reiniciar. Hacemos el segundo shot (2nd shot, shot) y cuando acabe pulsamos sobre "Compare" para que nos saque las diferencias.
En otro tipo de parches puede resultar mucho más inmediato ver los ficheros modificados, pero en este caso, con un reinicio de por medio, va a haber muchísimos registros y ficheros modificados. Veremos un montón de temporales del parche que acabamos de instalar, prefetchs, ficheros de logs, y un montón de registros, pero debemos pasar de toda esa "paja" e intentar ir a la sección de ficheros modificados y buscar aquellos que estén en un path que nos hagan ver que se trata de un fichero del sistema:

[...]
----------------------------------
Files [attributes?] modified:133
----------------------------------
[...]
C:\Windows\System32\drivers\tcpip.sys
C:\Windows\System32\LogFiles\Scm\729f4f57-2181-4edb-bb11-79c7914d10dc
C:\Windows\System32\LogFiles\Scm\9b75c702-ea13-406a-badb-6c588ee4375b
C:\Windows\System32\LogFiles\Scm\a1cfa52f-06f2-418d-addb-cd6456d66f43
C:\Windows\System32\LogFiles\Scm\a316e645-1c56-45a6-bd6a-7dca79778090
[...]


El resultado tiene sentido, vemos que ha modificado el driver tcpip.sys, que presumiblemente es el que contiene la vulnerabilidad. En este caso solo he podido apreciar un fichero (aunque hay gente por ahí que habla de dos, pero yo en Windows 7 solo he visto uno), así que lo que nos queda ahora por hacer es copiarlo fuera de la máquina virtual, y llamarlo tcpip-new.sys para diferenciarlo del original.


Para finalizar, restauramos el Snapshot de la máquina virtual al estado previo a la aplicación del parche que queremos analizar y buscamos estos mismos ficheros que hemos encontrado que han sido modificados, en este caso tcpip.sys, y lo copiamos de nuevo fuera de la máquina virtual, esta vez con el nombre tcpip-old.sys, para no confundirlo con el anterior.

Una vez hecho esto, ya tenemos la version anterior y posterior al parche de los ficheros modificados pero... ¿cómo sabemos ahora que cambios concretos se han hecho a cada fichero?

Lo veremos en el próximo post.

lunes, 7 de noviembre de 2011

SANS Institute: Explicaciones

En mi experiencia como Mentor y también alumno del SANS Institute, diría que todos pasamos por una primera etapa en la que nos perdemos un poco cuando buscamos información sobre cursos y modalidades de esta entidad. Perdí ya la cuenta hace mucho tiempo de la cantidad de correos que me llegan de gente que ha estado buceando por la web del SANS, y no se sabe muy bien si por su organización, por el idioma, o por una combinación de ambas, no consiguen comprender como tienen que proceder para hacer alguno de sus cursos.

Pensando en esto, y en la cantidad de veces que he copiado y pegado mis propios correos, he decidido publicar una pequeña "guía SANS" en Español que podéis encontrar AQUÍ, en donde se explican las diferentes modalidades de los cursos, y las que suelen ser mis recomendaciones habituales según el caso, con lo que espero que pueda ayudar a toda la gente que se encuentra perdida saltando entre las webs de SANS y GIAC, o por lo menos ahorrarme escribir en los correos siempre la misma explicación xD

También he añadido una descripción de cada curso de los que conozco, así como los cursos que en la actualidad tengo conocimiento de que estén teniendo lugar en España, pero si eres un Mentor, Community Instructor o Instructor del SANS y quieres aportar una descripción para tu curso, o corregir alguna de la información que he dado sobre los cursos disponibles, por favor ponte en contacto conmigo.

En unos pocos días sacaré también una encuesta de interés por los cursos de SANS, en los que podréis todos marcar, ahora que conoceréis bien las diferentes opciones, que cursos serían de vuestro interés, en que modalidades y en que ciudades, para que de este modo podamos plantear mejor con SANS que cursos montar de cara al 2012 que ya nos acecha.

Cualquier comentario sobre lo escrito, algo que no se entienda, o necesidad de ampliación de alguna parte, estoy completamente abierto a sugerencias.

miércoles, 2 de noviembre de 2011

#5EBloggers en León (INTECO-CERT)

El pasado miércoles tuve la oportunidad de estar en León participando en la mesa redonda de Bloggers de Seguridad organizada por el INTECO-CERT, que tenía idéntico tema al del ENISE: "Hacia una sociedad conectada más confiable".

Siempre he sido de la opinión de que existe un exceso de confiabilidad en el mundo de la tecnología, y que ciertamente no ocurren más incidentes porque, aunque parezca mentira, los atacantes aún tienen "buena Fé", o al menos no tanta mala leche como podrían tener, y no pensaba que ninguno de los otros invitados tuviera opiniones muy diferentes al respecto.

De izquierda a derecha:
Javier Berciano (@jberciano)
Manolo Benet (@mbenet)
Sergio de los Santos (@ssantosv)
David Hernández (@daboblog)
Jose Selvi (yo) (@JoseSelvi)
Yago Jesús (@YJesus)
Francisco Losada (@flosadam)
Gracias a Dabo por hacer con su móvil y pasarnos la foto :)

No tiene mucho sentido que haga una crónica extensa de lo que comentó cada uno de nosotros en la mesa redonda porque el resto de asistentes han publicado ya sus propias crónicas, así que en ese sentido no tengo mucho más que aportar al respecto.

A modo de resumen, todos estuvimos de acuerdo en que, en este momento, existen muchas deficiencias en la tecnología que usamos que nos hacen perder esa "confiabilidad" que se busca en el título de la mesa redonda. Culpables... un montón, nuestra propia visión de la tecnología, la publicidad engañosa por parte de empresas, etc. Sin embargo, alcanzar la deseada confiabilidad es posible, con mucho trabajo, y con una actitud responsable por parte de las empresas y de las personas.

Por citar una frase que dije durante mi intervención, y que al parecer gustó bastante a Yago (no sé como resumirla para que quepa en un Tweet xD):

Seguro que la primera persona que consiguió volar, una vez lo hizo, primero se pasó un buen rato felicitándose a si mismo por el logro conseguido, y cuando acabó de hacerlo y de decirse lo bueno que era, se dio cuenta que no había pensado como aterrizar. Lo mismo ocurre con la tecnología hoy en día, nos estamos preocupando tanto de poder llevar la conectividad a un extremo, de conseguir nuevos avances, y de lo buenos que somos por haberlos conseguido, que luego nos damos cuenta de que no tenemos ni idea de como "vamos a terrizar".

Para acabar, simplemente agradecer a Javier Berciano, a Francisco Losada, y en general al INTECO-CERT, por una impecable organización y por un trato personal excepcional. Sin duda uno de los eventos mejor organizados y en los que mejor me han tratado de los que he asistido.

Espero poder tener la oportunidad de asistir en futuras ediciones.
¡Muchas gracias!