31 enero 2013

Pedofilia, Internet, Justicia y Hackers

"Todos somos ignorantes, pero no todos 
ignoramos las mismas cosas"  
Albert Einstein (1879-1955)
Qué difícil me es hablar de estos temas, sobre todo cuando no estoy seguro si este tipo de post es el que realmente quieren leer, ni siquiera si es el tipo de post que me gusta escribir a mi, sin embargo hoy tengo ganas de transmitirles algunos pensamientos.

Es casi imposible evitar enfadarme hasta con el aire que me rodea, cuando leo noticias sobre pedófilos que distribuyen material por internet y algunos periodistas describen al imputado como "hacker" o "alguien muy cercano al hacking"... Esto sin duda demuestra la ignorancia de quienes escriben, pero la verdad es que en algún punto esa ignorancia que me irrita logro comprenderla, al fin y al cabo a mi me pasa lo mismo en otros rubros por ejemplo al opinar sobre salud, política, educación, etc...



Sin embargo, algo que últimamente me pone de mal humor es que después de tantos años colaborando con la formación de las fuerzas de seguridad para combatir y atrapar a verdaderos delincuentes informáticos y no a hackers, researchers o entusiastas, sigo viendo como en los periódicos, en las redes sociales y hasta en los bares se habla de pedofilia como algo ajeno que debe ser tomado por "otro".  Quién es ese otro? A quién esperamos? Es esa maldita forma de expresarnos y quejarnos por que algo no se hace, que además pretendemos que otros lo hagan y rápido pero sin comprometernos a hacer nada ya que no es mi responsabilidad.

En donde vivo, en Argentina, he visto y conocido muy de cerca casos de detenciones de pedófilos.  Incluso en los noticieros suelen pasarse informes cada vez que ocurre una detención importante, pero lo que nunca se comenta es lo que sucede antes o después de dicha detención.  Nunca se comentan los esfuerzos personales de los oficiales de policía que incluso poniendo en riesgo su carrera hacen investigaciones sin el apoyo suficiente ni de recursos, ni políticos, ni sociales.   Trabajos extras y hasta sin sentido que deben realizar para que fiscales acepten las investigaciones, que parecerían no interesarles o que simplemente no quisieran aceptar por que les da mucho trabajo, o por que tienen un costo político alto.   Nunca se comentan aquellos casos donde después de los increíbles esfuerzos para llevar adelante una investigación, para convencer al fiscal, para proceder a la detención y que los medios lo publiciten, un juez decida soltar al imputado en menos de 3 días considerando que la persona no es peligrosa para la sociedad y/o que el delito es excarcelable... 

Una realidad inalterable. ¿O sí?


Me preocupa que pase el tiempo y sigamos siendo 
tan superficiales en los análisis o en las discusiones.  Al igual que con la trata de personas, no se atacan realmente todos los frentes posibles (generación de una ley, denuncia de corrupción policial y municipal, cierre de los centros donde trabajan las víctimas de esta barbaridad, etc.) salvo que una noticia se haga importante o por esfuerzos aislados de una zona o región.    Me preocupa que hoy en día todos los que leemos estos medios, personas inteligentes y capaces, no nos comprometamos realmente a hacer algo por cambiarlo.
Siempre fue igual, con internet o sin internet.  Negocios son negocios.  La seguridad no se implementa por que sí, nadie hace las cosas bien porque sí, pensemos en Yahoo y su anuncio de SSL en el 2013, o en los campeonatos de hacking de Facebook por unos pocos dólares mientras acomoda sus politicas de privacidad a su gusto.   Es más, salgamos de la informática y vayamos al campo de los autos: en la mayoría de las autopistas del mundo hay una velocidad máxima pre-establecida (en algunos 120 o 130 km/hora), sin embargo la gran pero gran mayoría de los autos salen de fábrica con velocidades superiores a los 180 Km/hora. Porqué? por que sino la gente no los compraría...

Me preocupa que con la pedofilia sigamos peleando en desventaja.    Donde esta la falla que tanto me molesta?  En parte en los mismos lugares que antes de existir internet, en mi opinión no creo que haya voluntad clara y decidida de atraparlos, pero por otra parte, los avances tecnológicos provocaron algunas brechas que nunca fueron achicadas: 


  • Ausencia de fiscalias especializadas para atender delitos informáticos, pero sobre todo, temas que esten relacionados con los chicos.
  • Falta de recursos y conocimientos de las fuerzas de la ley para atender la cantidad de denuncias recibidas y seguir procedimientos relacionados con el mundo digital.
  • Poco compromiso y entendimiento de los jueces al tratar el tema, o su mal asesoramiento por parte de profesionales informáticos.
  • No existencia de leyes o regulaciones severas generadas por las cámaras de diputados o senadores que tardan años en tratar y discutir un proyecto de ley  a fin, pero en pocas horas deciden agregar un feriado, aumentarse salarios o salvar a un club de la quiebra.
¿Cuál es la solución? 

"Grupos hacktivistas" es lo primero que a muchos lectores se les debe haber ocurrido, sobre todo si la bronca les aflora en la piel, pero perdón por mi visión poco positiva:  Cada vez que los grupos hacktivistas atacaron con denegaciones de servicios, las víctimas fuimos siempre los usuarios, las empresas nunca han cambiado.  O alguno piensa que Sony cambió su postura después del ataque a la PSN? o quizas Visa y Paypal dieron marcha atrás con sus medidas con respecto wikileaks?
"Publiquemos los datos de los pedófilos en internet" puede ser otro de los pensamientos de algunos, pero y si esa persona era inocente?  Como garantizamos la realización de una investigación adecuada y el principio de defensa e inocencia?   Es más, muchas veces, la difusión de cuentas o perfiles de pedófilos publicamente solo sirven para avivarlos y ahuyentarlos para que no las sigan usando, lo cual genera que la policía o las empresas no puedan continuar investigandola...  Eso sin siquiera suponer que quien denuncia podría ser alguien que quiere perjudicar a una persona por un mal de amores o por un negocio frustrado, o simplemente por una broma...

¿Y entonces? 

Como dije al principio, no se si este post lleva a algún lado, pero al menos plantea un debate, una serie de cuestiones para que pensemos juntos.
RTFM
Durante muchos años en seguridad se dijo que "el eslabón más débil de la cadena es el usuario" y muy pocas empresas hacen algo serio al respecto.   Nosotros, los que trabajamos en seguridad, siempre nos quejamos porque no se tratan los temas en profundidad y nadie se compromete a solucionar las fallas detectadas en las auditorias, pero curiosamente en este tema, hacemos lo mismo que las empresas hacen con nuestros informes: "Nada.  Que se haga cargo quien corresponda!".  

Quién??!!  Tanto que hablamos de GTD, a quién le asignamos esta tarea?

¡No tengo idea!  

No se como contestar todas mis preguntas anteriores.  No tengo idea sobre que podes hacer para ayudar.  Pero si no puedes encontrar una respuesta por ti mismo de como colaborar de alguna forma, de cualquier forma que aporte de verdad, se me ocurre que puede ser por alguno de los siguientes motivos:

De esto también se trata ser un hacker, no?
  1. Quizás no tengas interes en el tema, por lo cual no puedo juzgarte, estas en todo tu derecho.
  2. Quizás no tengas ganas de involucrarte, por lo cual te digo:  Deja de quejarrte!!
  3. Quizás no eres los suficientemente creativo, por lo cual quizas la palabra hacker te quede demasiado grande.  <- Si esto último lo sientes como un desafío, pues sí, es un desafío.  Unete y colabora, busquemos la forma de cubrir todos los puntos de falla antes mencionado para potenciar la lucha.

Saludos a todos y gracias por dejarme compartir estas lineas con ustedes.

Claudio B. Caracciolo

Leer más...

30 enero 2013

Cualquiera puede ver tu foto de perfil en Whatsapp

Dado que este es mi primer post en SbD, me presentaré.
Mi nombre es Alejandro Amo y trabajo como consultor IT empresarial. Abarco desde el marketing y la comunicación hasta el área de planificación y operaciones en sistemas de la información, pasando por la escritura y redacción comercial o la gestión de crisis de reputación online. En otras palabras: no soy precisamente un perfil 100% técnico.
Sin embargo, aunque no especializado en ella, siempre he estado en contacto con el mundo de la seguridad; puede que algunos me conozcan como alist3r, seudónimo bajo el cual he aportado como desarrollador en proyectos como Wifiway.

Ya presentado, entro en materia. Me temo que voy a realizar mi incursión en SbD con un post sobre Whatsapp, un tema muy tocado en SbD, pero no es para menos ya que la aplicación siempre ha dado que hablar desde su nacimiento. Hoy os traigo un juguete nuevo que nos ayudará a sacarle partido a todo lo que ya sabemos acerca de Whatsapp, y esperemos que también sirva como herramienta de concienciación del usuario promedio.

Estas pasadas navidades decidí, junto a berni69 (creador del famoso airwin), unir fuerzas y conocimientos para condensar en una web todo lo comentado en estas líneas, de manera que fuera fácil de comprender, de compartir y de usar, que tuviera impacto visual para la gente y que fuera sobre todo concienciadora y didáctica. De esta idea nace WhatsappVoyeur.

Whatsappvoyeur es un servicio web que permite a cualquier persona, incluso sin el uso de teléfono movil, obtener todos los datos de perfil de un determinado usuario de Whatsapp. En el momento de escribir estas líneas somos capaces de proporcionar los siguientes:
  • Foto de perfil a tamaño real y fácil de descargar a disco como cualquier imagen de una web
  • Frase de estado o "status quote"
  • Último momento en que el usuario cambió la "status quote"
  • Último momento en que el usuario apareció conectado en la red
Con ello pretendemos realizar la prueba de los siguientes conceptos y aplicaciones prácticas:
  • Determinar si un usuario te ha bloqueado en Whatsapp (cotejando datos con tu movil) 
  • Capturar la foto de perfil a tamaño real (con mas detalle de lo que la gente cree cuando las elige)
  • Controlar la actividad de un determinado usuario (controlar si está o no conectado)
  • Demostrar que los datos de todos son quasi-públicamente accesibles debido a las políticas de Whatsapp (solo hace falta estar autenticado dentro de Whatsapp - la web conecta a Whatsapp usando conjuntos de credenciales válidas que hemos creado para la ocasión)
A los ojos de un seguidor de SbD, WaV no es más que una herramienta cómoda para hacer pruebas de concepto, curiosear y jugar un poco, pero como he dicho antes todo está pensado especialmente para concienciar y facilitar la experiencia del usuario menos avezado, con textos muy explicativos del concepto, así como una interfaz vistosa pero simple y fácil de usar, con "responsive design" para adaptarse tanto a móviles como PCs.
Mi experiencia con un grupo de pruebas de estos usuarios es positiva y les ha ayudado a entender la poca protección de sus datos en Whatsapp, y esa es precisamente la intención.

Tanto Berni69 como un servidor esperamos que os guste y que la utilicéis para jugar y curiosear ;) concienciar a los usuarios de estos temas tan importantes, ya que si la gente supiera que su foto de perfil en Whatsapp es prácticamente pública, se lo pensarían mas antes de ponerse fotos como esta...


WTF!

O igual no, ¿quién sabe? hay gente para todo... ;)

¿Cómo y por qué funciona WhatsappVoyeur?



Antes de nada debo rememorar uno de los problemas de Whatsapp que ya fué comentado aquí: los datos del perfil de los usuarios de Whatsapp eran completamente accesibles al público, mediante una simple consulta a una url. Ni siquiera era necesario entrar en la red interna de Whatsapp propiamente dicha.

Gracias al script de Alejandro Ramos pudimos practicar el harvesting de todas las cuentas de Whatsapp de España, saber que por aquel entonces sumábamos casi 10 millones de usuarios, y tener sus "status quotes" en una base de datos. Todo ello, sin esfuerzo, sin más límite que el de nuestra paciencia, sin siquiera necesitar credenciales válidas de Whatsapp.

Desde el punto de vista de arquitectura, modelo de datos y privacidad, es de lo mas "braindead" que se puede perpetrar.

Pues bien, el 9 de enero, Whatsapp realizó un nuevo cambio en el protocolo de comunicaciones, con la intención de resolver este asunto: han desaparecido de sus servidores los archivos PHP contra los que podíamos hacer un query usando simplemente wget, curl o un navegador regular. 

Adiós a "https://sro.whatsapp.net/client/iphone/iq.php"

En su lugar, implementaron un protocolo de intercambio de datos de los contactos. A este protocolo le llamaremos "Contact Sync V2", tal como ha dado en llamarle el egipcio Tarek Galal, creador de la API yowsup. Dicho protocolo está colocado donde siempre debió estar: debajo de la capa de sesión. Los datos devueltos por este nuevo conjunto de comandos son muy parecidos a los que devolvía el famoso archivo iq.php, con la salvedad de que ahora es necesario estar autenticado contra el servidor de Whatsapp para poder enviar esos comandos.
Seguramente el lector pensará:
¡Bien! ¡Ya tenemos una mejora! Nuestros datos personales de Whatsapp ya no son públicamente accesibles...
...bueno, pues no. Pensemos por un momento en el modelo de datos de Whatsapp, en las reglas bajo las que han definido dicho modelo: una de las características más inseguras del protocolo Whatsapp y de las relaciones entre sus usuarios es que "quien no está explícitamente bloqueado está implícitamente permitido". Cualquier persona que añada nuestro número de teléfono a su agenda puede ver nuestra foto de perfil, nuestra "frase de estado" y controlar en todo momento si estamos conectados, o cuánto tiempo hace que lo estuvimos por última vez. Y todo esto nos está sucediendo sin que nosotros podamos hacer absolutamente nada por evitarlo, en tanto en cuanto el individuo que nos "controla" no nos envíe un mensaje que delate su presencia (ese es otro tema: esta política permite que un usuario nos envíe un mensaje sin que lo "aceptemos" previamente como contacto. Podremos bloquearlo, pero ya nos ha molestado. Para aplicaciones de spam puede ser rentable cambiar de número cada vez y seguir molestando...)

Pero hay más. No es solo un asunto de mi privacidad como individuo (que un headhunter, un responsable de RRHH, mi ex pareja o mi jefe puedan controlarme a mí, como persona elegida arbitrariamente, desde números que desconozco y de los cuales yo no puedo defenderme). También es un asunto de privacidad como elemento de una masa. Es decir, que aún es posible realizar un "harvesting" masivo de los datos de los usuarios, tal como hizo en su día Alejandro Ramos, con tan solo añadir dos elementos nuevos: unas credenciales de usuario de Whatsapp válidas (muy fáciles de obtener) y la adaptación al nuevo protocolo "Contact Sync V2" (cosa que Tarek Galal nos proporciona con su API yowsup, que no tardó en actualizar para reflejar los cambios). Nosotros en WhatsappVoyeur simplemente ofrecemos una interfaz ágil para usar la API y unas credenciales secretas para consultar cualquier número sin que nos puedan bloquear.

Uno puede pensar que, ahora que se nos piden credenciales para obtener los datos de los contactos, Whatsapp podría realizar un control del número de querys por usuario/tiempo...
...bueno, pues tampoco. He realizado stress testing y he validado hasta 700 contactos a un ritmo de 30-40 contactos por minuto. Demasiados. También he obtenido las fotos de perfil de los usuarios comprendidos en un rango de 30.000 números de teléfono. Y ya habeis visto más arriba una prueba del espectáculo, entre dantesco y divertido, que eso puede llegar a suponer...

Conclusión


El protocolo "Contact Sync V2" apenas implica una mejora real en la protección de nuestros datos de perfil en Whatsapp. Solo coloca una barrera de autenticación frente al exterior, pero no nos protege de otros usuarios autenticados en el interior; no nos protege como individuos porque las políticas en sí mismas no lo hacen (deficiencia de diseño), y tampoco nos protegen del "harvesting" masivo porque, si bien el protocolo "Contact Sync V2" proporciona una base técnica para impedirlo, no se le ha sacado partido aún.

Las políticas del tipo "lo que no está explícitamente prohibido, está implícitamente permitido" siempre deben ser implementadas con mucho cuidado, pero cuando los nombres de usuario son números de teléfono móvil que cualquiera puede obtener y sondear, y cuando están en juego nuestras fotos y otros datos que pueden ser bastante sensibles... es una muy mala idea de base.

Y digo "de base" porque es un error de diseño en sí mismo. No es una deficiencia del protocolo de comunicaciones sino una deficiencia del modelo de datos y de su lógica inherente. Whatsapp debería cambiar muy profundamente la definición del modelo de datos y los procesos de integración con nuestra agenda en el teléfono, cosa que dudo mucho que tenga en mente hacer. Ante todo soy consultor tecnológico empresarial y sé que, lamentablemente, hay cosas que no son rentables en un contexto de negocio; sé lo duro e incontrolable que es tirar adelante una startup mientras luchas con el capital riesgo. Probablemente Whatsapp seguirá invirtiendo lo mínimo indispensable en materia de seguridad, y el 99% de su esfuerzo seguirá siendo el crecimiento de la base de usuarios y la búsqueda de monetización de los mismos. Pero desde el punto de vista del usuario, de su seguridad y su privacidad, opino que Whatsapp ha cometido un error desde el principio y ha excedido los límites razonables de controversia e inseguridad, cosa por la cual (entre otras como peor diseño y peor campaña de comunicación) caerá derrotado por alternativas como Spotbros o Line...

Artículo cortesía de Alejandro Amo
Leer más...

29 enero 2013

Recordatorio: presentación - Hacker Épico

Unas breves líneas para recordaros que pasado mañana, Jueves 31, nos veremos todos a las 20:30 en La Casa de Zamora (Calle de las Tres Cruces, 12, Madrid) para la presentación oficial del libro y por supuesto, nos encararía contar con vosotros.

Al finalizar, Chema Alonso y nosotros mismos contaremos algunas iniciativas y novedades surgidas por la novela y podremos tomar un vino y charlar con todos los asistentes.

Aún cabemos muchos más, así que no lo dudéis y mandarnos un correo electrónico a la dirección: presentacion@hackerepico.com. ¡Os esperamos!




Leer más...

Juan Carlos Calderón compartió un enlace este pasado fin de semana en la lista de correo del capítulo de OWASP en español, del que es coordinador, que apuntaba a un concurso/quiz promovido por la empresa Aspect Security para evaluar los conocimientos de seguridad en equipos de desarrollo. A través de 20 preguntas que cubren los aspectos básicos acerca de metodologías y cumplimientos OWASP, WASC y PCI.


Al crear la cuenta, se permite detallar más aspectos del perfil que va a realizar el cuestionario, como por ejemplo el rol o departamento dentro del equipo (arquitecto, desarrollador, manager, equipo de pruebas, u otro), así como el tipo de empresa y los años de experiencia.

Una vez nos registramos, recibimos un correo con el enlace a proporcionar al resto del equipo para que completen el cuestionario. Desde dicho enlace, se irán recogiendo las respuestas y puntuaciones de cada uno que complete las 20 preguntas, para poder así realizar estadísticas acerca del equipo y sus conocimientos en seguridad.



Mientras se van contestando las preguntas, en casto de que la respuesta sea incorrecta, se muestra la verdadera y la explicación, por lo que no sólo podremos "picarnos" entre departamentos y compañeros, si no que además se podrán afianzar y conocer nuevos conceptos. Las preguntas están categorizadas según los siguientes módulos: Comunicaciones seguras, cifrado, securización de sistemas, errores y registro de eventos, validación de datos, autenticación y control de acceso.

[+] Puedes acceder a esta aplicación mediante el siguiente enlace:


Y vosotros, ¿qué puntuación habéis obtenido?
Leer más...

27 enero 2013

Enlaces de la SECmana - 159

Leer más...

24 enero 2013

Libro: Cuando la criptografía falla

Siempre se ha dicho que resulta difícil encontrar en un mismo perfil a un técnico excelente y que sea a la vez un gran divulgador.

Es lo que marca la diferencia entre alguien bueno y alguien que además es capaz de hacer buenos a los que le rodean.

El caso de Arturo Quirantes es exactamente ese: una persona con un perfil técnico de muy alto nivel y que además es capaz de explicar los conceptos de una forma amena y legible prácticamente para todo aquel que ponga un poco de atención.

Desde hace bastantes años, Arturo lidera el proyecto 'Boletín Enigma', antaño una lista de correo, hoy día un blog. Y siempre, un punto de referencia para todos los que siempre hemos sentido interés por la criptografía.

Cuando estas navidades cayó en mis manos el libro de Arturo, me vino a la cabeza esa típica escena de película donde el protagonista se sienta con una copa de coñac en un sillón a disfrutar y recrearse con su bebida.

El libro es exactamente lo que me esperaba: Un libro ameno, que permite leerlo en un corto espacio de tiempo, que deja satisfecho tanto a un neófito como a alguien versado en ciertas partes de la criptografía que pretenda ganar visión global en el tema.

En definitiva, es el libro que recomendaré a todo aquel que pretenda introducirse de lleno en el apasionante mundo de la criptografía.

El libro solo cuesta 6,95 euros y se puede comprar en Amazon
Leer más...

23 enero 2013

Antes de entrar en la parte técnica y llegar a la programación, donde seguramente muchos lectores dejen de leer, quiero hacer una pequeña introducción para todos los públicos.

En este artículo voy a escribir un poco sobre lo fácil que es burlar la protección de un antivirus sin tener que recurrir a técnicas complejas y algoritmos "vanguardistas" como encoders, polimorfismos, metamorfismos y demás ingenios, que muchas veces nos llevan a la falsa creencia de que un posible intruso o creador de malware debe ser un genio de los ordenadores, y como hay pocos genios es difícil que nos toque. De hecho un gran porcentaje de incidentes de seguridad se produce aprovechando vulnerabilidades o malware antiguos, que a priori todo antivirus detectaría fácilmente de no haber sido modificados.

Eso, sumado a la falsa seguridad que nos proporciona el software como los antivirus o firewalls hace que la gran mayoría de la gente no preste la atención que debiera a la seguridad de sus sistemas (ya no vamos a entrar en el recalcado tema de cómo escoger una buena contraseña).

Se invierten millones de euros en investigación de protecciones de seguridad informática y existe todo un gran mercado en torno a ello, pero al final del día el mejor antivirus, y la mejor protección que "podría" existir para nuestros ordenadores es el propio usuario (aunque desgraciadamente, todavía siga siendo lo contrario). Muchas veces me han pedido consejo para escoger un antivirus, o me han preguntado que antivirus utilizo, y cuando yo contestaba "ninguno" se quedaban un poco sorprendidos. Si bien hoy en día si utilizo, es verdad que he estado muchísimos años sin utilizarlos.

A lo que quiero llegar es que fuera del mundillo de la seguridad informática, se sigue confiando la seguridad un 100% a programas como los antivirus, la gente se siente protegida con ellos, lo cual es contraproducente. Pequeñas cosas como mantener actualizados todos nuestros programas, ser cuidadosos con las cosas que descargamos o controlar que servicios tenemos corriendo en nuestras máquinas en cada momento quedan relegados a un segundo plano (muchísima gente ni siquiera le da importancia a no actualizar), aunque no infalible, minimizan mucho los riesgos, convirtiendo un antivirus en una capa de protección más, y no en la más importante.

Dicho esto, y después de asustar un poco a los no iniciados (esa era la intención), entremos al lío.


De todos es sabido que los antivirus basan casi el 90% de su detección en la búsqueda de signatures, partes de código reconocibles como maliciosas o sospechosas se que van actualizando en sus bases de datos de firmas según se descubren nuevos virus o exploits.

Para camuflar este tipo de firmas en malware, una de las cosas que más se están utilizando son encoders de todo tipo, que manipulan ese código detectable convirtiendolo en otro diferente que hace la misma función, pero a la larga esos encoders se vuelven inefectivos porque siguen un patrón que puede detectarse con análisis heurístico. Incluso el famoso y polimórfico shikata ga nai es inefectivo hoy en día, por muchos pases que se apliquen.


Por regla general, un antivirus realiza el análisis de los archivos tanto cuando se escriben en disco como cuando son ejecutados, pero no monitoriza toda la ejecución del mismo, porque eso requeriría de unos recursos de los que una máquina normal hoy en día no dispone (imaginad que cada vez que se ejecutase un Photoshop u otro programa intensivo computacionalmente, el AV tuviese que monitorizar en todo momento todas las operaciones que realiza).

Sin embargo existen técnicas que le pueden poner las cosas muy difíciles a un antivirus, incluso a los análisis heurísticos, y que sólo un análisis exhaustivo por parte de un humano en un entorno sandbox podría detectar (algo impensable para la detección en tiempo real).

Algo de lo que adolecen los antivirus es que analizan los archivos independientemente, y no como un conjunto de archivos que forman una pieza de software. Y desgraciadamente deben hacerlo así para evitar multitud de falsos positivos.

Por ejemplo, en uno de los últimos exploits Java (CVE-2012-1723), compuesto por varias clases empaquetadas en un jar, detectaba la firma sólo en dos de ellas, donde se ejecutaban las funciones sospechosas, con lo que separando esas firmas en clases diferentes se podía anular la detección muy fácilmente.

Sin entrar en detalles, este exploit se basa en type confusion, asignando una clase con funciones que requieren privilegios de sistema a otra clase de distinto tipo que no los requiere, saltándose el sandbox java de ese modo. El antivirus detectaba el exploit en la clase que forzaba la confusión (llamemosle confusor), y en un par de líneas de código de otra clase, donde se creaba la instancia del confusor (probablemente para detectar variantes del exploit donde el confusor fuese diferente).

No fue necesario utilizar ningún tipo de ofuscación de clases sobre el exploit:

Para el confusor bastó con cambiar un bucle for de 100 iteraciones por 110 para que el antivirus ya no lo marcase como peligroso.

En cuanto a la clase donde se creaba la instancia de forma reflectiva, el AV lo detectaba cuando estas dos líneas aparecían juntas en el mismo archivo, pero separandolas de una manera extremadamente trivial, neutralizamos totalmente lo que el AV daba por sentado como malicioso:




Como se puede apreciar, realizando pequeñas modificaciones al código, y sobretodo separando las partes del código sospechosas en diferentes lugares es muy sencillo desaparecer de la lista de firmas del AV. De este modo y con un poco de creatividad podríamos ocultar incluso ROP chains, heap sprays...,  pilares de muchos exploits modernos.

Para continuar, y ya que hemos utilizado el exploit java para demostrar cómo evadir el antivirus durante la fase de explotación, vamos a ver como ocultar también un payload, ya que las shellcode más comunes suelen ser detectadas per se como firmas.

Hemos modificado el código del exploit de java para evitar el antivirus, pero en cuanto añadiesemos a la ecuación nuestra shellcode (por ejemplo un meterpreter https reverso), volvería a ser detectado. Dado que el exploit en java no nos limita en tamaño a la hora de weaponizarlo con un payload, y como ya nos hemos saltado el sandbox java, ¿por qué ejecutar la shellcode directamente desde el exploit, cuando podemos volcar un ejecutable a disco y lanzar la shellcode desde allí? Podría parecer una estupidez hacer una escritura a disco dando al AV una oportunidad extra de análisis, pero como veremos más adelante evitar la detección de la explotación asumiendo ese riesgo tiene sus ventajas si nos encargamos de ocultarlo bien en la fase post-exploit, donde contamos con más flexibilidad para hacerlo.


Como se puede apreciar, hemos convertido los binarios en cadenas de texto (los he truncado por legibilidad), los hemos almacenado en variables (separados en dos mitades), y los recodificamos a binario antes de escribirlos a disco, consiguiendo que el AV no los detecte al analizar el paquete Java.

Con eso ya estamos separando el payload del propio exploit (recordad, separación es la clave), pero tendremos que conseguir que el payload sea también indetectable.

Para ello vamos a utilizar varios trucos. En primer lugar, cogeremos nuestra shellcode y la partiremos en 2 mitades (una vez más). Con eso ya sería suficiente, pero para este ejemplo, además, he creado un sencillo "encoder" que hace rotaciones de bits en cada byte de la shellcode y luego los invierte, con la intención de camuflarla un poco. Así que ya tenemos dos mitades de nuestro meterpreter, previamente scrambled con el miniencoder.


Si sólo utilizaramos el encoder sobre la shellcode entera, el antivirus podría reconocerla con algo de heurística, pero de este modo aunque aplique la heurística a cada mitad, no se encontrará con la shellcode completa, con lo que no la reconocerá como firma.

Podríamos crear un sencillo ejecutable que lanzase esa shellcode, pero aquí vamos a utilizar otro truco para engañar aún más.

Crearemos un ejecutable normal (payload.exe), con una función trivial que no haría saltar jamás al antivirus, porque no realiza ninguna acción sospechosa, pero utilizaremos unas librerías dinámicas para sobreescribir esa función trivial con nuestra shellcode en tiempo de ejecución, y ya en memoria:



Debemos configurar el compilador para que no utilice el NX/XD (DEP) ni base dinámica (ASLR), de este modo la dirección de memoria que sobreescribiremos en nuestro programa no variará en cada ejecución, ni la memoria estará desorganizada por el ASLR, lo cual sería un problema para escribir secuencialmente.

Como veis, y para esta demostración, la función inofensiva() está compuesta por una serie de NOPs (o cualquier otra cosa), para hacerla más fácil de encontrar en nuestro debugger, y debe tener el tamaño suficiente para albergar nuestra shellcode una vez la sobreescribamos.

Lo ejecutamos en el debugger para localizar la dirección donde comienza dicha función:


Dado que en este caso el programa comienza a ejecutarse en 400000, nuestro offset para comenzar a sobreescribir será 53F0, que es el punto de entrada de la función.

Un análisis por parte del antivirus sobre el ejecutable no revelaría nada ya que el código de la shellcode no sobreescribe la función inofensiva() hasta que cargamos las librerías.

Como hemos partido la shellcode en 2 mitades, crearemos dos DLL (shellcode1.dat y shellcode2.dat), una con cada mitad (una vez más, separación), de este modo el AV aunque analice cada DLL en disco, no encontrará nada.



En MY_OFFSET establecemos la posición de memoria en tiempo de ejecución donde debe empezar a sobreescribir. Decodificamos nuestra media shellcode anteriormente “revuelta”, y la escribimos donde estaba la función inofensiva().

VirtualProtectEx, así como otras que permiten API hooking, es una de las funciones más vigiladas por un antivirus dado que abre las puertas a escribir en memoria en tiempo de ejecución, pero como hemos dicho antes, solo estamos escribiendo media shellcode, y es por esa razón por la que no saltará la alarma, y es a lo que me refería con que un antivirus escanea archivos independientes, y no como un conjunto.


También habréis notado que utilizo sleeps para pausar la ejecución. Es solo una sospecha personal infundada, pero aunque retrasa la ejecución del payload creo que algunos antivirus (especialmente los que quieren vendernos que casi no comen recursos al ordenador) dejan de analizar si el proceso que monitorizan es lento, especialmente si es un bucle, para ahorrar recursos y no interferir en la experiencia del usuario. Y también para tratar de que el AV no “relacione” una función con la anterior, aunque supongo que eso ya es un raciocinio humano que no se aplica a una máquina ;)


Para la segunda DLL, solo tenemos que cambiar la segunda mitad de la shellcode y el offset para continuar escribiendo en la posición donde terminó la primer mitad.

Algo que podríamos hacer para enrrevesarlo aún más (aunque para no complicarlo demasiado no lo hemos hecho aquí), sería empezar escribiendo la segunda parte de la shellcode, y luego la primera (simplemente invirtiendo el orden en el que hacemos el LoadLibrary), con lo cual nos curamos en salud ante un posible análisis secuencial de lo que estamos escribiendo en memoria.

Ya para terminar, vamos a añadir una capa más de separación, utilizando un ejecutable (spawner.exe) , el cual es el verdadero ejecutado por nuestro exploit java y que será el encargado de lanzar el payload (Nota: he hecho esto porque a día de escribir el código, el reverse https terminaba el proceso al cabo de unos minutos si no se establecía una conexión):




Este pequeño programa también es inofensivo a los ojos del AV, y lo único que hace es monitorizar si existe el proceso de nuestro payload, y si no es así, lo relanza.

Además, como hemos creado una entrada en el autorun del registro (lo cual podría resultar sospechoso para el AV), siempre es mejor que el "sospechoso" sea este nuestro spawner inofensivo, y no el que carga las librerías del payload.


Resumiendo:

  • Hemos lanzado nuestro exploit en java, ya modificado, con lo cual el antivirus no lo ha detectado. 

  • El exploit ha volcado 4 archivos al directorio temporal de Windows. El AV los analiza en el momento en que se escriben a disco. Dos de ellos son ejecutables inofensivos, con lo cual no los detecta. Los otros dos son las librerías donde está la shellcode, pero son dos archivos independientes, el AV tampoco detectará una shellcode completa. 

  • Se ejecuta nuestro lanzador inofensivo, el AV no lo detecta en la ejecución. Se ejecuta el payload lanzado, y el AV analiza qué trata de hacer (una función inofensiva), también analiza las DLL al cargarlas (pero cada una realiza la sobreeescritura por separado, tampoco las detecta). Llegado ese punto la shellcode ya está reemplazando la función inofensiva(), pero el AV ya no puede detectarlo, ya que para ello tendría que volver a analizar la ejecución completa del programa en memoria y darse cuenta que el código fue sobreescrito, algo que requeriría muchos más recursos, y que en un programa más complejo sería demasiado intensivo. 


Hemos engañado al antivirus sin rompernos la cabeza con algoritmos imposibles, simplemente separando código malicioso en diversos trozos y lugares, y ejecutandolo de una forma poco convencional (sobreescribiendo una función ya existente). Podríamos haber utilizado otros trucos sencillos, como crear un programa con un overflow deliberado y explotarlo para lanzar la shellcode (algo que el antivirus jamás se "imaginaría"), en lugar de integrarla en el propio programa como una función más.

En el hipotético caso de que esto fuese un malware real, ya conocido, y con las firmas añadidas a un antivirus, bastaría con partir en más trozos todavía el código para que el AV dejase de detectarlo, y se convertiría en el juego del gato y el ratón.


¿Soluciones? Pues es bastante complicado. Para que los antivirus pudiesen conseguir una detección robusta no basada en firmas conocidas deberían ser capaces de monitorizar todos los procesos que ocurren en una máquina en todo momento, de relacionar esos procesos entre si de forma racional, tendrían que ser capaces de descubrir automáticamente vulnerabilidades en los programas (sin saber de antemano que las tienen); en definitiva, ser una inteligencia artificial que a día de hoy solo es ciencia ficción. Y necesitarían utilizar prácticamente la totalidad de los recursos de la máquina dejando una pequeñísima parte para el resto de procesos.


----------------------------------------------------------------------------------------------------------------

Artículo cortesía de Antonio Rodríguez (MoebiuZ)
Leer más...

22 enero 2013

Unhide 20121229 is out !

Finalmente y tras haber lanzado la beta con una gran respuesta a nivel descargas y feedback,  ¡tenemos la versión final de Unhide!

Para los mas ansiosos, se puede descargar desde aquí

La nueva versión trae bastantes cambios con respecto a la anterior versión (20110113)

Copio y pego el 'Changelog':

IMPORTANT

  - unhide-linux26.c was renamed to unhide-linux.c
  - unhide.c was renamed to unhide-posix.c
  - The log file of unhide-linux is renamed 'unhide-linux_AAAA-MM-DD.log'
  - The log file of unhide-tcp is named 'unhide-tcp_AAAA-MM-DD.log'
  - By default, unhide-tcp now use /sbin/ss from iproute2 package, to use netstat as before '-n' option must be given on command line.
  - Display is more verbose and multi-lines for hidden processes (unhide-linux).
  - If asked to (-l and/or -f), display is more verbose and multi-lines for hidden ports (unhide-tcp).
  - sysinfo test is no more called as part of compound quick and sys tests as it may give false positives.

    It could still be run using the checksysinfo, checksysinfo2 or checksysinfo3 command line parameter.

NEW FEATURES

  - Major enhancement of unhide-tcp :

    * Add capability to output a log file (unhide-tcp_AAA-MM-DD.log)
    * Add capability to output more information (via lsof and/or fuser) on hidden port if available
    * Add verbose mode (disabled by default) to display warning
    * Add a new method (via option '-s') very fast on system with huge number of opened ports
  * Make a double check of port access to avoid false positive (previous single check version is available as unhide-tcp-simple-check.c if needed).

  - Add a quick port in C language of unhide.rb (unhide_rb.c) and guess what ...it's 40 times faster than original ruby unhide.rb
    
Note: unhide_rb doesn't take any option.

  - Add "-d" option for doing a double check in brute test, this reduce false positives.
  - Add "-o" option as synonym of "-f".
  - For found hidden processes, display the user and the working directory as extracted from the process environment. Note that it doesn't work well for kernel processes/threads nor for deamons.
  - For found hidden processes, display cmdline, exe link and internal command name.

MISCELLANOUS

  - Add french and spanish man page for unhide-tcp
  - Update english manpage of unhide-tcp to reflect changes
  - Minor corrections in french manpage of unhide
  - Display copyright and license information in start banners.
  - Make message from sysinfo tests more clear.
  - Add a NEWS file :)
  - Update README.txt, LISEZ-MOI.txt and LEEME.txt to clarify difference between unhide-posix and unhide-linux.
  - Remove sysinfo test from quick and sys compound tests as it may give false positive.
sysinfo test still can be used via the checksysinfo[2|3] command line parameters.

BUG FIXES

  - Suppress pedantic compilation warnings (glibc >=2.3, gcc >=4.6).
  - Correct the number of processes displayed for /proc counting in sysinfo test.

[+] Página principal de Unhide (unhide-forensics.info)
Leer más...

21 enero 2013

Rooted CON 2013 y RootedLabs


Quedan apenas semanas para que asistamos a la ya cuarta edición de uno de los congresos de seguridad más multitudinarios de España: Rooted CON. Como ya os comentamos cuando se inició el proceso de solicitud de ponencias / call-for-papers, esta vez tendrá lugar el 7, 8 y 9 de Marzo en la Fundación Mútua Madrileña de Madrid, como en las últimas dos ediciones.

Rooted CON 2012 Día 1


La semana pasada se anunciaron, entre otras cosas, los primeros ponentes confirmados, que son los siguientes:

- Nuestro compañero Alejandro Ramos
- Jose Miguel Esparza "eternaltodo" y Mikel Gastesi
- Jesús Olmos "sha0"
- José Pico, David Pérez y Raúl Siles - los chicos de Taddong
- Sebastián Guerrero "0xroot" y Christian López "phr0nak"
- Los hermanos Tarasco: Andrés y Miguel

Todavía quedan muchos ponentes por confirmar, pero ¡ya la cosa promete! Para este primer tramo, se ha tenido que activar la lista de espera en el proceso de registro, por haber llegado al límete de usuarios pre-registrados.



Hasta el próximo 31 de Enero no se liberarán más plazas, ya que es el último día en el que se confirmarán los pagos de este primer tramo.

Ayer domingo también conocimos más datos acerca de los RootedLabs para este año, en el que ya se han anunciado los siguientes cursos:


Cartel de lujo para estas acciones formativas que tendrán lugar los 3 días antes del congreso, ¡reserva tu plaza cuanto antes!

Leer más...

20 enero 2013

Enlaces de la SECmana - 158

Leer más...

18 enero 2013

TurkTrust: Algunas reflexiones sobre el último 'CA Gate'


Sí, ha vuelto a suceder: Otra vez una CA ha vuelto a saltar a la luz pública por haber protagonizado un mini escándalo de certificados fraudulentos.

En este caso, la protagonista ha sido 'TurkTrust' entidad de certificación Turca que, tal y como reflejamos en otro artículo donde se analizó en manos de quién está la seguridad, es junto a ANCE las dos únicas CAs cuyo origen es un país musulmán.

En este caso el problema no ha sido un hackeo (como en el caso comodo y diginotar), mas bien un uso indebido de dicha CA.

Se puede encontrar en internet mucha información del asunto, pero tal vez la fuente mas expeditiva sea nakedsecurity donde explican lo sucedido realmente,

Resumido queda en esto:

1- A mitad de 2011, en teoría debido a un error interno y supuestamente no malintencionado, TurkTrust emitió dos certificados de CA subordinada en vez de un certificado normal a dos clientes (nótese que un certificado de CA subordinada permite, a la postre, crear certificados válidos para identificar hosts en internet sin control alguno)

2- Uno de esos certificados 'erróneos' fue revocado porque el cliente al que se le dio informó del error (es extraño que a raíz de ese error no se investigase si existían más certificados así). El otro certificado que se emitió a EGO (autoridad gubernamental del transporte) siguió activo.

3- Alguna mente iluminada en EGO que se dio cuenta del error (ellos dicen que no, pero yo no me lo creo) instaló este certificado mágico en un dispositivo CheckPoint que, entre otras capacidades, tiene la habilidad de interceptar tráfico SSL mediante MitM creando certificados al vuelo a partir de un certificado CA (el cómo usan estos dispositivos las organizaciones que no tienen uno de esos certificados mágicos da para otro post y ahora mismo como explicación, sobra).

4- A finales de 2012, la gente de EGO creó un certificado 'wildcard'  para *.google.com

5- Un usuario de la red de EGO estaba empleando Chrome como navegador y Chrome, resulta que usa Public key pinning que, muy groso modo, significa que Chrome sabe de que CAs puede esperar certificados para sitios como www.google.com y de cuales no.

6- A partir de ahí saltó la chispa que prendió todo este escándalo.

En mi humilde opinión, la historia de los certificados 'erróneos' que terminan en un dispositivo CheckPoint para interceptar tráfico SSL me suena excesivamente obvia como para creerme la explicación oficial de TurkTrust en la que tratan de explicar todo esto como un cúmulo de infortunios.

A partir de esto, me gustaría reflexionar sobre varias cosas. Mucha gente, a raíz de estos escándalos están poniendo en tela de juicio el modelo tradicional PKI / CAs.

Tal vez el más notable intento sea Convergence, que propone una ruptura con el modelo tradicional para cambiarlo por otro.

A mi modo de ver, pasado un tiempo de su lanzamiento, opino que no es el camino, el modelo tradicional de las CAs no es un modelo 'malo', simplemente el tiempo lo ha 'prostituido', se han admitido un desproporcionado número de CAs de confianza, los procesos de auditoría son excesivamente laxos y al final se confía más de la cuenta.

Frente a eso, hay otras propuestas que proponen mejorar el sistema, Google apuesta por el pinning y también proponen 'Certificate Transparency [PDF]' que, básicamente es un gran log público donde cada CA debe registrar cada certificado que emita, de esa forma si tu eres el dueño de ejemplo.com puedes consultar periódicamente que certificados para tus dominios hay en circulación.

Mi pequeña aportación a todo esto fue 'SSLCop' que tuve el placer de presentar en la pasada rootedcon, y que pretende ser una forma de reducir el número de CAs en las que confía tu navegador eliminado CAs por procedencia geográfica asumiendo, por ejemplo, que tu, si no eres Turco, no necesitas confiar en las CAs de ese país
Leer más...

17 enero 2013

Presentación: Hacker Épico

Como todos sabéis, 'el parto' del libro ha sido largo y se ha demorado por bastante tiempo, aun así, parafraseando a la película El Santo: Las infancias difíciles dan lugar a los adultos más interesantes

Tanto Rodrigo como yo, estamos muy contentos de la acogida que ha tenido entre todos vosotros. Han sido muchos y muy alentadores la cantidad enorme de comentarios recibidos a través del blog, twitter (#hackerepico) y correo electrónico. Cada uno de ellos nos ha levantado una sonrisa y han convertido esta alocada idea en un éxito.

No obstante, pensamos que falta algo. Dar las gracias a toda la gente que nos está apoyando usando twitter se nos queda un poco corto, así que hemos pensando en hacer una presentación oficial donde poder veros de una forma más personal, charlar con vosotros y tratar de devolver una pequeña parte del cariño recibido.

Por ello, nos hemos decidido a organizar un evento en La Casa de Zamora (Calle de las Tres Cruces, 12, Madrid) el día 31 de Enero a las 20:30, a la que tenemos el placer de invitaros a todos, hemos preparado una degustación de vino de la tierra y unos canapés para hacer más amena la estancia.

Además aprovecharemos la ocasión para presentaros varias novedades en primicia, ¿el qué? ¡será una sorpresa

Si os apetece pasar la tarde con Rodrigo y conmigo, que os firmemos y dediquemos el libro y sobre todo, que os podamos conocer y dar las gracias personalmente, tan solo os pedimos que confirméis asistencia enviando un correo a la dirección: presentacion@hackerepico.com y allí nos veremos.
Leer más...

16 enero 2013

Control de certificados permitidos en IOS


Hace tiempo explicamos cómo se podía hacer análisis de seguridad de las peticiones web que hace una aplicación de iOS instalando una CA  en el propio móvil. Aunque en la  gran mayoría de casos el método funcionará, en otros el tráfico no será transmitido tal y como se espera, ya que la aplicación verificará que el certificado que recibe está firmado por una CA concreta, desconfiando de cualquier otro tipo de certificado recibido, sea o no válido.

Para llevar a cabo ese control (que roza la seguridad por oscuridad), se hace de dos formas distintas: definir exactamente el certificado que se espera recibir, sacando de la ecuación a la CA o limitando las firmas válidas a una CA determinada. 

Las funciones que se usan para trabajar con SSL son tres: NSStream, CFStream, NSURLConnection, siendo esta última la más usada. 

NSURLConnection usa varios métodos delegados para obtener los valores y poder hacer la comprobación de los parámetros, como didReceiveAuthenticationChallenge, canAuthenticateAgainstProtectionSpace o willSendRequestForAuthenticationChallenge.

Por ejemplo, twitter hace uso de este método para evitar ataques man in the middle, y se puede intuir el "pinado" del certificado en el volcado de su aplicación.
Volcado de class-dump-z de la aplicación de Twitter.

En esos casos, la estrategia debe ser distinta. Usar un debugger y cambiar el comportamiento, recompilar la aplicación o hookear esas funciones.

Con este objetivo iSEC Partners ha creado IOS SSL Kill Switch, un pequeño tweak de MobileSubstrate que realiza esta tarea. Para usarlo, como es obvio, se requiere que el teléfono tenga jailbreak.

La instalación es sencilla, se instala el paquete deb correspondiente y se reinicia el proceso de MobileSubstrate.

Instalación de IOS SSL Kill Switch

Una vez instalado, se aparecerá una nueva configuración dentro de los ajustes para habilitarlo o deshabilitarlo.

Ajustes de SSL Kill Switch

Actualización 10/2/2013:
Otra herramienta que parchea a un nivel más bajo: https://github.com/intrepidusgroup/trustme

Referencias:
Leer más...

15 enero 2013

Saber romper medidas de seguridad no hacen que seas hacker, al igual que saber hacer un puente en un coche no te convierte en un ingeniero de automoción

Eric S. Raymond

Y finalmente, después de esta larga pausa tras el penúltimo artículo de la saga y gracias a los pedacitos de tiempo que he podido reunir entre jálogüins, fines de semana, navidades y festividades varias, por fin, el cierre de estos seis artículos sobre infección.

No sería honesto decir que no me lo he pasado mejor escribiendo los códigos que aprovechaban estas vulnerabilidades que pensando en cómo cerrarlos. El hecho de tener que escribir algo que se escapa a la idea general de programa, en la que tienes un conjunto de instrucciones que deben satisfacer el aburrido fin de contentar al usuario, es siempre atractiva. Sin embargo, la meta ha estado clara desde el principio: más allá del divertimento individual hay un interés general que prima sobre todo lo demás por protegernos de una amenaza que es clara. Y terminaré esta saga desmontando (o al menos, enseñando a desmontar) todos los trucos que he utilizado para introducirme dentro de un binario, tomar el control y pasar desapercibido.

Este artículo se centrará principalmente en dos puntos: qué debemos hacer para protegernos de estos ataques por un lado y, por el otro, cómo detectar si hemos sido realmente atacados. Comenzaré por la primera, pues como todos sabemos -y todavía más en este mundo de jefes poco comprensivos con graves problemas a la hora de asimilar explicaciones- más vale prevenir que curar.

Medidas preventivas
Un día, cierto usuario despreocupado (y orgulloso, a la par que seguro de sí mismo usuario de una flamante Ubuntu versión algo punto diez) se encuentra desayunando tranquilamente, pensando en lo que mola Linux porque no hay virus. Pero, pobre de él, ahora hasta el vecino usa Ubuntu. Y desgraciadamente, un día, en algún espacio dedicado a noticias sobre tecnología en la tele, anuncian que ¡oh, imposible! un virus llamado Linux.RimmedGlasses.B (no, no existe realmente) amenaza la delicada sensación de dominio intelectual de nuestro querido usuario sobre los pobres no-conversos Windowsers expuestos a los peligros de la red.

Es el momento de bajar al mundo real.

Linux ha sido históricamente más seguro que Windows, pero esto es realmente una consecuencia de, entre otras, cómo se estructura el sistema y de que ciertas prácticas que en Windows favorecen mucho la infección, en Linux sencillamente no se da(ba)n. Además de que, cómo no, un sistema operativo que se usaba tan poco no era un blanco tan popular como el sistema de Microsoft.

Sin embargo, los tiempos cambian. En otros tiempos, la usual seguridad de Unix residía en que si no eres root, no eres nadie. Los usuarios que compilaban software para instalarlo en el sistema eran muy contados (en gran medida, sólo root, detrás del cual solía haber un administrador de sistemas responsable y medianamente preparado). Hoy por hoy, quien piensa en Unix piensa en Linux. Y quien piensa en Linux piensa en esa abrumadora masa de usuarios de una distribución de escritorio, susceptibles de caer en la tentación de añadir repositorios extrañísimos a las fuentes del apt, a bajarse código de todas partes, compilarlo ellos mismos y ejecutar un buen sudo make install para dejarlo a la vista de todos los usuarios (que en la práctica se reducen a un usuario con su nombre de pila en minúsculas y a root). Incluso, fíjense en lo que les digo, meter un peligrosísimo NOPASSWD en el sudoers. Dicha seguridad histórica de Linux queda en entredicho cuando introducimos al usuario corriente en la ecuación.

Esto ha abierto un montón de vías de ataque que antes, simplemente, no existían. Por eso, antes de continuar, me gustaría resumir algunas ideas que son de perogrullo, pero está bien tener en una lista aunque sea sólo por si nos olvidamos de alguna.

  1. root no es un usuario de andar por casa. Es más, no se debería poder iniciar sesión como root jamás (debería dejarse bloqueada con un asterisco en el campo contraseña de /etc/shadow) ya que esa no es la función de la cuenta de administrador. 
  2. sudo es muy cómodo, pero también es un tremendo agujero de seguridad si no se configura adecuadamente. Los tres puntos de los que nos advierte esta herramienta cuando no la tenemos configurada deberían tomarse más en serio. En resumidas cuentas, nunca configurar para que sudo no pida contraseña.
  3. Los repositorios de software (sean los del apt, yum, o los que correspondan), siempre de fuentes de confianza y firmados.
  4. El mejor binario es el que te compilas tú mismo. Eso sí, lo dicho, ojo con qué compilamos y de dónde lo sacamos. Desconfiar de cualquier enlace (web) que apunta directamente a un ejecutable. Lo mismo con los scripts.
  5. Ciertos directorios deberían poder leerse (o escribirse) sólo por root. Nunca relajar los permisos de directorios del sistema sólo porque nos sea más cómodo de administrar desde el usuario corriente.
  6. Continuando con el tema de los permisos, el permiso de ejecución (modo +x de los archivos) sólo debería estar activo para directorios y ejecutables que vengan con el sistema o hayamos compilado nosotros mismos. Tener particiones de Windows con este permiso de ejecución activado por defecto no es buena idea, debemos montar siempre con noexec.
  7. La variable de entorno PATH nunca debe tener el directorio de trabajo (.) en la lista. Nunca jamás. Los ataques companion han sembrado muerte y destrucción durante los ochenta y los noventa en los sistemas tipo DOS precisamente porque los programas se buscaban primero en el directorio de trabajo, y después en la ruta de búsqueda. Dejemos el pasado pasar.
  8. La variable de entorno LD_PRELOAD debería tener sólo aquello que sabemos para qué sirve. 

Teniendo todo esto en cuenta, y sabiendo que aquello que queremos proteger son nuestros binarios de una modificación no deseada (bonito eufemismo), hablaré un poco de las herramientas más populares destinadas a este fin, ventajas e inconvenientes. Algunas de ellas son IDS pensados sólamente en detectar qué ficheros son modificados (he obviado los diplodocus de la detección de intrusiones como OSSEC), no vamos a matar moscas a cañonazos.

bsign
bsign es una herramienta de firmado y verificación de ejecutables (ELF) mediante en espacio de usuario que funciona sobre GPG (esto quiere decir que, técnicamente, podríamos utilizar cualquier tipo de clave soportada por GPG), por lo cual vamos a necesitar una clave privada lista para este fin. Esta herramienta puede encontrarse en las principales distribuciones de GNU/Linux, es verdaderamente fácil de usar y para lo que nos interesa sólo se reduce principalmente a dos casos de uso, a saber: firmar y verificar.

Para firmar:

% bsign --sign ejecutable

Acto seguido nos pedirá la contraseña de nuestra clave privada (si la tenemos configurada, cosa que yo recomiendo), y listo, el binario está firmado con un chorro de bytes al final del mismo conteniendo la suma de comprobación cifrada de lo que acabamos de firmar.

Para verificar la integridad, bastará con llamar a :

% bsign --verify ejecutable

Yo recomiendo firmar con claves RSA en lugar de con DSA, básicamente porque es más rápido.De hecho, GPG computa firmas RSA como diez veces más rápido que DSA.

bsign devolverá un mensaje indicando el estado de comprobación, así como un valor de retorno (que podríamos examinar mediante la variable del shell $?) que será 0 si la comprobación ha ido bien, o distinto de cero -en realidad, un código de error- si ha fallado. Podemos leer la página de manual de bsig para poder darle un significado a estos códigos de error si nos interesa integrar esta utilidad en algún programa más grande.

Como ya dije, la gran ventaja de bsign es que es muy fácil de usar, su principio de funcionamiento es igualmente fácil de comprender y fácil de integrar. Los únicos fallos, si es que merece la pena mencionarlos como tales, son que sólo soporta ELF (cosa que hoy por hoy no es problemático, ya que la práctica totalidad de binarios nativos de GNU/Linux son ELF) y que es una herramienta de espacio de usuario. Es decir, no podemos proteger nuestro sistema globalmente con bsign de una forma directa, habría que llamar a bsign antes de cada ejecución.

Este último problema estuvo (que ya no está) solucionado gracias al proyecto del que hablaré a continuación. En sí no tiene gran utilidad, pero quién sabe, quizá anime a alguien a retomarlo ;)

DigSig
DigSig fue un proyecto que pretendía llevar a nivel de núcleo las comprobaciones de integridad de binarios firmados con bsig, pero que desgraciadamente dejó de mantenerse en 2009. La idea era un módulo del núcleo que a cada ejecución buscaba una firma de tipo bsig, la validaba y decidía si debía ser ejecutado o no.

He intentado compilar DigSig bajo un kernel 3.3, pero las cosas han cambiado mucho en el kernel de Linux desde 2009 (en realidad sólo lo suficiente para estropearme la compilación). De todas formas, se echa de menos algo como DigSig para este sistema operativo. Algún avispado programador debería darse cuenta de esta necesidad y retomarlo.

Tripwire
El problema de bsign es que se trata de una herramienta de firmado y verificación de ejecutables ELF que debemos ejecutar sea manualmente, sea formando parte de un proyecto más grande. Tripwire viene a proporcionar todo un sistema de control de integridad orientado a la detección en lugar de la prevención. Según su página de manual, Tripwire compara los archivos y directorios del sistema contra una base de datos previamente construida (por lo tanto, lo hace completamente inútil ante un sistema ya atacado) mediante la cual puede encontrar modificaciones, borrados, cambios en los atributos, etcétera.

El problema de Tripwire es que es un producto comercial. Sin embargo, si nuestra intención es vigilar una sola máquina (o conjunto reducido de ellas), sin control ni generación de informes centralizados, podemos descargarnos la versión libre (en código fuente y GPL) directamente de SourceForge.

Asumiendo que la compilación ha ido bien, durante la instalación nos pedirá las contraseñas con las que se protegen las claves de sus bases de datos, y llegará esa divertida fase de configuración y puesta en marcha :P

Tripwire se basa en un fichero de políticas binario y cifrado que se genera a partir de una plantilla en texto plano (que en mi sistema se encuentra en /usr/local/etc/twpol.txt), el cual contiene una lista de todos los ficheros (y directorios) que están bajo control y las propiedades (permisos, hash, fechas de modificación, etc) que no deberían modificarse. Por defecto este archivo es amplísimo, y posiblemente nos interese suprimir la mayoría de las reglas para hacer un control más centralizado. Una vez modificado este archivo, bastaría con ejecutar:

% sudo twadmin -m P /usr/local/etc/twpol.txt

Para generar de nuevo las políticas a partir de la plantilla, y:

% sudo tripwire -m i 

Para regenerar la base de datos. Nótese que twpol.txt es sólo una plantilla, no es algo que Tripwire utilice directamente, por lo que podríamos borrarlo (o moverlo a otra ubicación) una vez generadas las políticas.

Podríamos obtener un informe detallado de las violaciones de acceso sobre los archivos vigilados con:

% sudo tripwire -m c

Comando que podríamos introducir en el crontab para enviar estos informes periódicamente por correo a la cuenta de administrador, por ejemplo.

El problema de esto es que necesitamos conocer todos los ejecutables (o directorios donde se encuentran) para que Tripwire sea algo verdaderamente efectivo. Sin embargo, el hecho de poder contar con un fichero de texto en el que podamos especificar una lista de ficheros a estudiar sin tener que modificar los binarios y además poder generar informes más o menos comprensibles lo hace ya superior a bsign.

AIDE
El Advanced Intrusion Detection Environment (AIDE) se presenta como otra herramienta de tipo IDS dedicada a vigilar archivos del sistema de una manera muy similar a como lo hace Tripwire: existe un fichero con reglas para los ficheros vigilados, y una serie de herramientas para manipular y visualizar la base de datos.

La gran desventaja de AIDE respecto de Tripwire es que a diferencia de este último, AIDE no encripta la base de datos (aunque puede comprimirla). Sin embargo, ganamos a cambio mayor facilidad a la hora de instalarlo y ponerlo en marcha, ya que, por ejemplo, no hace falta compilar el equivalente del fichero de políticas.

De nuevo, tenemos dos casos de uso principales, inicializar la base de datos:

% sudo aide -c ruta/al/fichero/de/configuracion.conf --init

Y generar un informe:

% sudo aide -c ruta/al/fichero/de/configuracion.conf --check

El cual podríamos generar periódicamente y enviar por correo de la misma manera que haríamos con Tripwire.

Hay más comandos, como comparar dos bases de datos, actualizar la existente, etc. Un aspecto interesante de AIDE es que puede trabajar (y de hecho, espera trabajar) por separado con dos bases de datos diferentes. Esto nos podría permitir tener una base de datos de referencia en un sistema de ficheros de sólo lectura mientras podríamos generar una base de datos con la situación real del sistema en otra ubicación, pudiendo comparar ambas fuera de la máquina, etcétera.

Mi humilde opinión
Yo soy, personalmente, partidario de soluciones a nivel de kernel tipo DigSig. AIDE, Tripwire y bsig sólo nos van a avisar si los archivos bajo vigilancia han sido comprometidos. Y puesto que no podemos hacer un chequeo completo de todo el sistema cada dos por tres, habrá una ventana de tiempo entre la infección y la verificación en la que nuestro atacante podría haberse hecho con información valiosísima. Por ejemplo, supongamos que el código infectado busca tocar ssh o las propias bibliotecas pam y monitorizar el teclado. El daño ya estaría hecho si durante ese tiempo consiguió hacerse con alguna clave importante y enviársela al atacante. ¡Sería incluso peor si hablamos de un sistema con varios usuarios!

Ya que DigSig está en coma, y lo demás me deja el miedo en el cuerpo, yo ofrezco la siguiente idea: que el binario se autoverifique al principio. Si las cosas no encajan, el binario rechaza ejecutarse, lanza un aviso y fin de la amenaza. En función del binario, esto podría tener un efecto más o menos catastrófico en el sistema, pero al menos sabríamos que hay un problema antes de la propia explotación del mismo.

La prueba de concepto se llama spintop: un archivo fuente en C que compilado con el resto de un proyecto (esperablemente mayor) se encargará, antes de ejecutarse el main, de comprobar que hay una firma válida tipo bsign en el binario desde el que se ejecuta. A la hora de incluir esto en un proyecto, debemos tener en cuenta que:

a) Hay que definir una macro SPINTOP_TRUSTABLE_FINGERPRINT con una cadena conteniendo el fingerprint en mayúsculas de la clave con la que firmamos y
b) Que hay que que compilar contra GPGME, preferiblemente contra la versión estática de la biblioteca.

He intentado escribir esta prueba de concepto con la menor cantidad de llamadas a funciones externas posible (aunque me ha quedado malloc en el tintero) y definiendo todas las funciones como static. Con todo esto, consigo que la cosa funcione incluso para binarios que no dependan de la biblioteca estándar de C (cosa rara, pero nunca se sabe) y sobre todo, para complico a un posible atacante el asunto de hookear las llamadas que spintop podría necesitar para alterar su funcionamiento. Siendo un código más o menos "autónomo", el manipular spintop se hace más difícil. Evidentemente, esto requiere un estudio mucho más serio.

Cuando se compila un binario con spintop y no hacemos nada más, recibiríamos un mensaje como el siguiente:


% ./myprogram 
spintop warning: binary is not signed (yet). Use bsign(1) to generate a signature before running it.
%

Es normal, ya que no lo hemos firmado. Suponiendo que tenemos bsign configurado, sólo nos quedaría firmarlo:


% bsign --sign ./myprogram

Enter pass phrase: ***
%

Y al ejecutar todo iría sobre ruedas. Aunque bueno, eso ya dependería del binario en cuestión :P


% ./myprogram             
LOOK MOM, I'M A PROGRAM AND I'M DOING THINGS LIKE ASKING
THE USER FOR STRINGS WITH gets() HURRR DURRR AM I COOL YET?
GIMME YOUR NAME: fulanito
LOL K, YOUR NAME IS fulanito
%

Si nos atrevemos a modificar un byte, sólo un byte, incluso añadiendo algo al final sin tocar el resto:

% echo -n a >> myprogram 
% ./myprogram        
spintop error: MODIFIED BINARY DETECTED (Bad signature)
spintop error: SOMEBODY CALL DE COPS
%

Y habremos prevenido la ejecución de algo potencialmente peligroso. Eso sí, si nuestro código malicioso de ha enganchado al punto de entrada, no habremos podido evitar la ejecución del mismo, pero al menos habremos impedido que manipule el resto del programa en tiempo de ejecución.


Y para terminar, hablemos de estadística
En los artículos anteriores hemos revisado diversas técnicas de infección. Hemos visto que, como todo en esta vida, tiene sus putos fuertes y sus puntos débiles. En general, nuestros métodos de infección tocaban partes del ejecutable que, si bien no son críticas o al menos su modificación se hacía de forma que pasase desapercibida, hacía del ejecutable infectado algo particularmente especial. Por ejemplo, la información de PT_NOTE suele ser prescindible, pero es muy raro encontrar un binario que no la defina.

Nuestra meta en este punto es evaluar hasta qué punto estos binarios "especiales" se dan realmente en un sistema Unix, y justificar la existencia de una heurística que permita aventurarnos a alertar de la posibilidad de una infección. La idea es revisar todos los métodos de infección y activación que hemos visto hasta ahora, y averiguar si realmente dichas modificaciones pueden pasar desapercibidas, ignorando por completo el código que hayamos inyectado.

Para esto, revisaremos la estructura de algunos miles de binarios ELF ya no de una sola arquitectura (como llevamos haciendo con las pruebas de concepto hasta ahora), si no de unas cuantas más para situarnos en un escenario un poco más realista, y de paso, gozar de más y más variados ficheros. Los sistemas donde se ha realizado este estudio han sido:

- Ubuntu 12.04, i386 (9160 binarios)
- Ubuntu 12.04, x86_64 (2045 binarios)
- Debian Squeeze, x86_64 (941 binarios)
- Solaris 10, UltraSparc IIe (12163 binarios)
- Debian testing, x86_64 (1825 binarios)
- Debian Sequeeze, i386 (3152 binarios)
- Ubuntu 10.04, i386 (2442 binarios)

El análisis ha sido automatizado gracias a una pequeña herramienta (elfprobe) que escribí expresamente para la tarea, las fuentes se pueden descargar aquí.

La sobreescritura PT_NOTE: algunos datos
Los ejecutables infectados mediante esta técnica se caracterizan por compartir las siguientes características:
  1. Perdieron su segmento PT_NOTE
  2. Tienen (normalmente) tres (o más) segmentos PT_LOAD
  3. Tienen segmentos ocultos

Y digo "normalmente", porque si el binario original tiene un solo segmento, esto deja de ser verdad. En los sistemas analizados, se ha contabilizado un total de 79 binarios con un único segmento PT_LOAD. No es una situación común, pero se podría utilizar para ocultar una infección.

Los binarios que no tienen PT_NOTE son mucho más numerosos: en Solaris la práctica totalidad de ellos carecen de esta característica (12110) mientras que en el resto de sistemas suman 4452, encontrándose la mayoría en las Ubuntu de 32 bits. Estas cifras no son nada despreciables.

Por otro lado, la cifra de binarios que tienen más de dos PT_LOAD asciende a 388, encontrándose, una vez más, la mayoría en Solaris. Los que tienen más de dos PT_LOAD y ningún PT_NOTE son algunos menos, 378, pero la cifra anda muy a la par. En el caso particular de los sistemas Linux, sólo se encontró un fichero (en la Ubuntu de 32 bits) que además pertenecía a otra arquitectura.

El problema de los segmentos ocultos, si es que de verdad es un problema como tal, es una constante de todas nuestras técnicas de inyección: el código infectado no aparece dentro de ninguna sección y eso puede ser bueno y malo a la vez. Es bueno, porque herramientas como objdump no desensamblan lo que no está dentro de una sección. Y es malo, porque un binario no suele tener segmentos no cubiertos por ninguna sección. Puesto que este problema es compartido por la técnica de desplazamiento de cabeceras, analizaremos este fenómeno más adelante.


Desplazamiento de cabeceras

En esta técnica la detección adquiere un nuevo orden de complejidad. Lo único que caracteriza a estos binarios es:
  1. La tabla de cabeceras de programa ha sido desplazada.
  2. Hay segmentos ocultos.
Desde el punto de vista de la detección, la dificultado reside en que no hay una forma de afirmar con total seguridad que la tabla de cabeceras de programa ha sido desplazada. En Linux, esta tabla de cabeceras suele estar antes del contenido de la primera sección (empezando desde el principio del fichero), pero podría estar en cualquier otra ubicación. En todos los sistemas analizados no he encontrado ningún binario (salvo los que yo he infectado deliberadamente) que tenga la cabecera de programas después del comienzo de la primera sección, por lo que esto podría ser una buena heurística.

El gran problema de la inyección: los segmentos ocultos
Como hemos visto antes, los segmentos inyectados no suelen aparecer como secciones del programa. Por supuesto que se podría modificar el binario para que esto no fuese así, pero añadiríamos una dosis de complejidad extra que a la larga nos sería contraproducente. Sin embargo, esta decisión tiene sus consecuencias, y es que estos datos "no cubiertos" son bastante fáciles de localizar.

De todos los binarios analizados, sólo se encontró un binario no infectado y con segmentos ocultos, por lo que esto podría ser una heurística bastante buena.

Inyección segmentada: virtualmente imposible de detectar
Tal cual. La inyección segmentada se basa en aprovecharse de unos huecos de alineamiento entre funciones que bien pueden no existir. Y escribir una heurística sobre qué binarios tienen o dejan de tener estos espacios es muy similar al código que escribí varias entregas antes sobre la viabilidad de esta técnica. La única forma de detectar un binario infectado por esta técnica (sin ejecutarlo, claro) es, o bien buscando partes del segmento de código que no estén cubiertas por la sección .text (algo que es posible que nunca encontremos ya que, a pesar de que en nuestras técnicas no lo hemos modificado nunca, tocar esa información es trivial), o por alguna vulnerabilidad del mecanismo de activación. Y esto nos lleva al siguiente punto:

Modificando el punto de entrada: no tan malo al fin y al cabo
Cuando vimos esta técnica de activación hemos asumido que es la más simple y que suele ser la más vigilada. Sin embargo, una vez infectados, ¿hasta qué punto podemos sospechar?

Pues resulta que el método depende de la robustez de la técnica de infección que haya detrás. Una forma sería buscar si el punto de entrada cae en una dirección que no esté cubierta por ninguna sección. Esto en el caso de la infección segmentada bien hecha, modificando .text para cubrir la rutina de reensamblado, puede llevarnos a un callejón sin salida. Sin embargo, en el caso de las otras dos técnicas, es más fácil debido al problema de los segmentos ocultos.

De todos los sistemas analizados, se han encontrado 4544 binarios donde el punto de entrada caía en una dirección no cubierta por ninguna sección, todos ellos en Solaris. En el resto de sistemas Linux, sólo se encontró un sistema Linux con esta peculiaridad.

Conclusión: para la plataforma que nos atañe en este post, modificación del punto de entrada + infección segmentada => potencialmente indetectable. Para todo lo demás, basta con comprobar dónde cae el EP.


.got.plt: complicado de comprobar, pero no tanto

La única complicación real aquí es técnica: se trata de encontrar una sección que se llame ".got.plt" y analizar su contenido. Tal análisis se resumirá en comprobar que los punteros caigan en siempre en la .plt, que es donde le corresponde. Nótese que de momento sólo puedo asegurar que este truco funciona en GNU/Linux para x86 de 32 y 64 bits con binarios construidos por GCC, en Solaris (al menos en mi Sparc) la sección ".got.plt" simplemente no existe (los punteros son modificados directamente dentro de la .plt, y sí, la .plt está en un segmento con todos los permisos de acceso encendidos).

Para el resto de sistemas, sólo se encontraron dos binarios (y en la Ubuntu de 32 bits) que tenían una .got.plt con entradas fuera de la .plt: uno era busybox (el formato interno de este binario es una auténtica rareza, al menos en mi sistema, no me preguntéis por qué), y el otro era la propia libc, con cuatro entradas fuera. En el resto de sistemas Linux, todo estaba en orden. La heurística que podríamos derivar de aquí no es perfecta, pero algo es algo.

.plt: confiando en que el compilador haga las cosas bien
Este caso es verdaderamente complicado de detectar, ya no sólo por el simple hecho de que puede haber muchísimos compiladores diferentes que generen .plts con formatos cualesquiera, si no por la propia variedad de .plts que nos podemos encontrar dentro del conjunto de binarios generados por el mismo compilador. Superadas estas complicaciones, el algoritmo es siempre el mismo: comprobar que las direcciones e índices de los símbolos colocados por los wrappers de la .plt siguen un orden creciente con el mismo salto.

Este truco sólo ha funcionado parcialmente en x86 (32 y 64 bits). En Solaris las entradas de la .plt los saltos no tienen un orden claro. En el resto de los sistemas de estudio he encontrado varios binarios cuyas .plts son bastante extrañas (busybox una vez más, el binario de skype e incluso ld), sin embargo siguen siendo la minoría. De las .plts soportadas, ninguna tenía entradas fuera de orden.

Conclusión: hacer una heurística sobre esto es posible, pero hacerla perfecta es bastante complicado. Si algún software quiere aprovecharse de esta técnica de activación, será difícil hacer una detección temprana de la infección.

.ctors: además de peligroso, evidente
Y por último, le toca el turno a .ctors. Hemos visto que esta técnica de infección es muy arriesgada, y en la práctica será todavía peor: además de funcionar sólo con los binarios generados por GCC, estamos cargándonos el marcador inicial (-1) que caracteriza esta sección. Esto hace la detección algo trivial.

Como era de esperar, ningún binario en todos los sistemas analizados tenía una sola sección .ctors que no empezase por -1. Por tanto, podemos hablar igualmente de buena heurística. De todas formas, estaría bien completar esta heurística comprobando si este entero que reemplaza al marcador es verdaderamente una dirección y estudiando dónde cae.

Conclusión de conclusiones
Este pequeño estudio ha arrojado algunos resultados interesantes: al final, las técnicas más simples acaban siendo las más robustas para esconderse de la mirada inquisitiva de la heurística de un antivirus. Las mejores, evidentemente, siguen siendo las más complicadas. ¿Se pueden escribir virus para Unix? Sí. ¿Se puede hablar de una amenaza? Potencialmente. ¿Nos podemos proteger? Afortunadamente sí. Sin embargo, la estadística cantará y cuando llegue ese futuro en el que escribir virus para Linux se vuelva algo divertido algún administrador se llevará un buen disgusto tarde o temprano.

Esta extensa saga ha obviado técnicas menos directas para acercanos a los detalles de infección directa de binarios, pero existen formas más simples (e incluso más efectivas) con las que se podrían conseguir resultados mucho más dañinos. Una forma sería, por ejemplo, modificando los Makefiles: encontrando la sección install y añadiendo la ruta de nuestro código malicioso podríamos ser ejecutados con permisos de root en el futuro, o incluso añadiendo alias a sudo en el .bashrc y cosas similares.

La picaresca está ahí, sólo esperemos que no la exploten demasiado.

No suelo añadir sección de agradecimientos a los artículos, pero después de la paciencia que tuvo Yago con esta interminable saga, de los ánimos de knx y NighterMan, y de la colaboración de n0p y también de la hermana de Pales al dejarme probar cositas en sus sistemas, toda esta gente bien se merecía una línea. Y por supuesto, a todos aquellos que tuvieron el estómago de llegar hasta aquí. Gracias.


Update: A fecha del 16 de enero de 2013, día más tarde de publicar este artículo, alguien sacó un parche para realizar verificación de firma digital a nivel Kernel. Información: https://twitter.com/2gg/status/291483726410559488



Artículo cortesía de BatchDrake
Leer más...