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...

28 enero 2013

12.000 grabadores de video expuestos en Internet

Casi por casualidad he detectado una vulnerabilidad que afecta a la web de administración de algunos grabadores de vídeo (DVR) de cámaras IP expuestos en Internet por todo el mundo. Cuatro fabricantes distintos, 20 modelos de grabadores y 127 versiones de firmware afectadas. En total, centenares de productos vulnerables y más de 12.000 dispositivos en la red, lo que equivaldría, aproximadamente, al acceso de 55.000 cámaras distintas y todo aquello que hayan grabado.

En septiembre del año pasado buscaba algún fallo que sirviera como ejemplo y que me permitiese incluirlo como parte de la historia del libro "Hacker Epico".  Cuando dí con el, no le presté demasiada atención, ya que este tipo de dispositivos suelen tener una plaga de vulnerabilidades. Ahora que ya se publicó la novela y vuelvo a tener algo más de tiempo, me dio por profundizar un poco más y explorar el impacto que tenía aquel hallazgo. Desde luego, no imagine que fuera a ser tan significativo.

Un grabador de vídeo es un sistema, como el que se muestra en la imagen, que sirve para gestionar  cámaras de vigilancia, generar alertas en base a patrones y grabar en archivos el contenido. Generalmente tienen varios canales, y en cada uno de ellos se conecta una cámara, que según el modelo varía entre 4, 6, 8, 16, etcétera.

Trozo (editado) de archivo "DVR.cfg" de ejemplo
La vulnerabilidad es muy sencilla, usando un navegador y solicitando el archivo "/DVR.cfg", puedes descargarte la configuración del sistema sin necesidad de introducir credenciales. En esta configuración se guarda sin ningún tipo de cifrado el usuario y la contraseña de acceso a su configuración y otros datos, como por ejemplo las credenciales de acceso del correo, FTP, DDNS o PPPOE.

Con estos datos, la forma más sencilla, y sin necesidad de entrar al panel de administración, de ver lo que graban las cámaras, es accediendo a su versión móvil. Para ello, tan solo hay que abrir el archivo "/iphone.html", añadiendo a la URL el usuario y la contraseña.  Por ejemplo: http://admin:admin@1.1.1.1/iphone.html. Aunque también es posible conectarse mediante el ActiveX del fabricante o utilizando un cliente RTSP.

Si se accede directamente usando el control del navegador, se visualizarán simultáneamente todas las cámaras .

Panel de control de administración de DVR (ActiveX)
Una búsqueda en shodan, con la pregunta exacta, revela que en la actualidad hay 46.889 direcciones IP con estos grabadores, de los que 12.667 son vulnerables.

Resultados de Shodan
Después de analizar todos los resultados (con un nmap, script en nmap y perl para procesar los XML), he sacado muchos más datos.  Como el número de apariciones por localización geográfica, siendo Taiwan el país donde más cacharros se han encontrado.

Grabadores de Vídeo vulnerables por país

En cuanto a las credenciales, la inmensa mayoría mantiene las que se entregan por defecto de fábrica: usuario admin, contraseña admin, así no se le olvida a nadie.

Uso de contraseñas en grabadores vulnerables
Los fabricantes afectados que he encontrado son:
  • Hunt CCTV (http://www.huntcctv.com/)
  • Capture CCTV (http://www.capturecctv.ca/)
  • Hachi CCTV
  • NoVus CCTV (http://www.novuscctv.com/)
  • Well-Vision Inc (http://well-vision.com/)
Los modelos de estos fabricantes:
  • DVR-04CH, DVR-04NC, DVR-08CH, DVR-08NC, DVR-16CH (HuntCCTV)
  • CDR 0410VE, CDR 0820VDE (CaptureCCTV-HuntCCTV)
  • DR6-704A4H, DR6-708A4H, DR6-7316A4H, DR6-7316A4HL (HuntCCTV)
  • HDR-04KD, HDR-08KD (unknown-HuntCCTV)
  • HV-04RD PRO, HV-08RD PRO (Hachi-HuntCCTV)
  • NV-DVR1204, NV-DVR1208, NV-DVR1216 (NovusSec) 
  • TW-DVR604, TW-DVR616 (Well Vision INC Solutions-HuntCCTV)

Distribución por modelos

He encontrado en total  127 firmwares distintos con la vulnerabilidad, de forma resumida:
  • 1.1.10 to 1.1.92 
  • 1.47 to 1.51
  • 2.0.0 to 2.1.93
  • 3.0.04 to 3.1.92
Toda la información ha sido reportada a HuntCCTV y tiene reservado el identificador CVE-2013-1391, pero desgraciadamente no han respondido. La vulnerabilidad también ha sido remitida al Grupo de Delitos Telemáticos de la Guardia Civil, quienes a su vez la han reportado al fabricante.

Para finalizar, mi amigo Wiredrat, con el que he compartido muchas aventuras (asíncronas), ha hecho un mapa interactivo (similar al de TrendNET, solo que con 12.000 puntos en vez de 300) que muestra la posición de los grabadores que se ven en Shodan y genera automáticamente un enlace a la configuración (donde están las credenciales) y a la versión móvil de las cámaras. Pese a que avisa en la propia web, os recuerdo que acceder tanto a la configuración como a la cámara , en la gran mayoría de países sería considerado un delito. Incluso aunque sea haga con el usuario admin y contraseña admin, que tienen la gran mayoría de ellas :-P

Mapa interactivo con grabadores vulnerables.

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...