Próxima parada: DragonjarCON 2015 en Colombia

Hace ya tres años que tuve la oportunidad de conocer la acogedora ciudad de Manizales (Colombia). En esa época, se trataba del ACK Security Conference invitado por Jhon César Arango y Jaime Andrés Restrepo. Quien me iba a decir a mí que sería el primero de tantos congresos de seguridad informática al que asistiría como ponente a partir de dicha fecha (de hecho mientras escribo estas líneas me encuentro en Guayaquil - Ecuador, donde daré una charla en el evento eCommerce Day que organiza la Cámara de Comercio de Guayaquil). 

A partir de ese evento, he estado en Colombia otras dos veces más como speaker en eventos, uno en el Security CSI en Pereira, y otra en la Asociación Bancaria de Colombia en Bogotá (ambos en 2013). 

Pues bien, este año, durante la semana del 14 al 18 de Septiembre de 2015, se celebrará la segunda edición del evento DragonjarCON, organizado por mi buen amigo Jaime Andrés Restrepo. 

El evento tiene dos días de duración de charlas, el 17 y 18 de Septiembre, en la que los asistentes podréis disfrutar de lo que os contarán diversos profesionales de la seguridad de diferentes países. 

Por mi parte, tendré el honor de abrir el evento con la charla “Cooking an APT in the Paranoid Way”, en el que relataré la experiencia vivida el año pasado a la hora de ver cómo de complicado sería realizar un APT a diferentes organismos públicos, con una mentalidad muy paranoica. 

Por otra parte, en los tres días previos al evento, tendrán lugar diversos talleres. En mi caso, el lunes 14 y martes 15 impartiré un curso presencial de “Hardening de infraestructuras y servidores GNU/Linux” que en la web han titulado como “Seguridad en Entornos Corporativos”. El temario de lo que impartiré será bastante parecido a los módulos I y III del curso online de "Hardening de Sistemas Windows, Linux e Infraestructuras" que terminamos esta semana en Securízame.

Como siempre será una excelente oportunidad para aquellos que podáis asistir de poneros al día en diferentes materias relacionadas con seguridad, en uno de los mejores eventos del ramo realizados en Colombia. 

Para mí, un enorme placer compartir cartel y experiencias con buenos amigos del hemisferio sur, así como disfrutar de la amabilidad, buena gente y excelente café de Colombia.

Nos vemos en el DragonjarCON en Septiembre!

Leer más...

Enlaces de la SECmana - 284

• El foro del servidor multimedia Plex comprometido, se pide a los usuarios que cambien su contraseña, según informan en LifeHacker.
• Anunciada la nueva Kali Linux 2.0, distribución que será presentada oficialmente en Agosto, durante Black Hat y Defcon. Además, se ha publicado un trailer con las novedades.
• Problemas en los servidores en la nube de Amazon dejan sin servicio a Netflix, Experian y Yelp, entre otros.
• El grupo GhostShell vuelve a la carga realizando hacks masivos por inyección SQL (su fuerte...) a multitud de portales de internet. Entre sus víctimas, la mayoría son universidades de Estados Unidos.
• Artículo en Xataka sobre Lo que los hackers de verdad piensan de Hacking Team, con Chema Alonso, Román Ramirez y nuestro compañero Yago. Además, también colaboró en este artículo del ABC sobre el mismo tema.
• Wikileaks publica un buscador con todos los emails obtenidos del hack a Hacking Team.
• Anunciados los ponentes del congreso GSICKMinds, que tendrá lugar el 20 y 21 de Noviembre en A Coruña.
• Bug en OpenSSH para versiones menores o iguales que 6.8 en referencia con X11.
• Muere Fernando Bonsembiante, referente de la comunidad hacker en Argentina. Fue jefe de redacción en la revista 'Virus Report'. Lorenzo tuvo el honor de hacerle una entrevista que podréis leer en este enlace.
• Abierto el Call For Papers para la próxima Ekoparty
• Experimento de hacking realizado sobre tres políticos, sobre los cuales se demostró lo vulnerables que resultaron gracias a comprometer su conexión en redes inalámbricas.

Leer más...

Google Open Redirect + SET

Buenas a todos!

 Hoy me gustaría enseñaros un fallo (que ya adelanto que google no lo ve como tal ya que dice que esta “Out of Scope”) que a mi parecer puede ser usado para fines maliciosos si se utiliza de manera malintencionada.

 En concreto el fallo es un Open Redirect. Este fallo como muchos sabréis esta recogido en la OWASP e incluso fue un fallo recogido en este proyecto dentro del TOP 10 en el 2013.

 Bueno... vamos a ello! Si vamos a https://myaccount.google.com y miramos el source de la página veremos la siguiente redirección:

Dicha redirección es interesante ya que según parece una vez finalizado el formulario seremos redirigidos de nuevo a http://myaccount.google.com.

Intentamos primero modificar el parametro continue con “http://www.example.com”. Esto nos mostrará un error 404 y nos dirá que la página no existe:

Es muy pronto para rendirnos aún... según podemos ver la redirección se hace, pero seguramente sea únicamente a dominios de google... para poder aprovechar esto vamos a usar el servicio que nos permite acortar URLs que nos permite google: http://goo.gl

Una vez creada la URL vamos a intentar utilizar tal que así:

https://security.google.com/settings/security/secureaccount?continue=http://goo.gl/SAQ0Gk

¡Ahora sí! Una vez terminado el formulario somos redirigidos a la página que hayamos puesto en http://goo.gl

Como podéis ver, realizando el ataque de esta manera hemos podido redirigir a una página externa usando un servicio de google.

Este escenario podría ser perfecto para una campaña de phishing donde por ejemplo un atacante se hiciera pasar por el servicio técnico de google pidiendonos que verifiquemos la seguridad de la cuenta para finalmente acabar en una página de phishing con el fin de robarnos los credenciales o ser redirigido a un exploit kit y comprometer nuestra máquina.

Para ver este posible escenario vamos a realizar una prueba de concepto. Par ello usaremos:

[*] Víctima

• Windows

[*] Atacante

• Linux
• Set Toolkit
• Dominio Fraudulento

Para poder realizar esta poc vamos a usar SET y clonar la página de gmail.com. Para ello nos valdremos del ataque “Credential Harvester Attack Method” que nos permitirá clonar dicha página y una vez la víctima inserte su usuario/contraseña será redirigido a la página original.

¿Cómo realiza esto SET? Pues es tan fácil como la siguiente linea de código que contiene post.php:

<?php $file = 'harvester_2015-06-13 16:16:34.695876.txt';file_put_contents($file, print_r($_POST, true), FILE_APPEND);?><meta http-equiv="refresh" content="0; url=https://accounts.google.com" />

Como podéis observar hace un put de los parámetros POST introducidos por el usuario dentro de un fichero que se genera el mismo y posteriormente hace un refresh de la página y redirige a “https://accounts.google.com".

En un entorno real, este dominio debería estar registrado y controlado por el atacante pero para nuestra poc he modificado el fichero hosts y he puesto el dominio “joogle.com” (podéis usar el que más os guste) que redirigirá dichas peticiones a la máquina del atacante.

Un vez realizado todo esto solo falta enviar un email a la víctima o cualquier otra vía de ingeniería social y esperar ver si finalmente la víctima ingresa sus datos en nuestra página de phishing.

Sí todo va bien veremos en el fichero llamado harvester_* lo siguiente:

Array

(

[GALX] => aePsgdFkA-A

[continue] => https://accounts.google.com/ManageAccount

[followup] => https://accounts.google.com/ManageAccount

[_utf8] => ☃

[bgresponse] => !YmFCjHSy8J4p7k9EfsdhbaflTtoPAAQeCP83CgBlXtGQrSD2cA002GKnfiHDe42cdD6z91d8rPg2oQRPJHJW3IJ2gdb5VjT0sCIpNWdMAcu9rUwnc3rKcKvB5-OFAtZSfy19yJ5zXCzP67yOLOeMrb3uDXnzBQVIkBAzt471DHB5QSpcqAA7xpQv4Z2HRIj12JJdLzQ

[pstMsg] => 1

[dnConn] =>

[checkConnection] =>

[checkedDomains] => youtube

[Email] => user@gmail.com

[Passwd] => passw0rd

[signIn] => Sign in

[PersistentCookie] => yes

[rmShown] => 1

) 

Y de esta manera, usando un dominio legítimo de google y su servicio goo.gl podemos llegar a ser víctimas de un robo de credenciales que a mi parecer se podría evitar restringiendo goo.gl al igual que se han restringido todos aquellos dominios no pertenecientes a google.

Vosotros que opináis, ¿Es un fallo? ¿No lo es? … se aceptan críticas :)

 Saludos!

Artículo cortestía de Sergio Galán @NaxoneZ

Leer más...

Congela tu web con SnapWeb y ¡disfruta del fin de semana!

Desde que la mayoría de las empresas piensan en un CMS a la hora de decidir cómo hacer su flamante nueva Web, debo reconocer que de forma casi directamente proporcional han aumentado mis dolores de cabeza: que si un módulo no actualizado había permitido “colar” un shell-remoto, que si habían modificado todos los .js del site, que si Google marca mi sitio como que contiene software malicioso, etc.

Estos nuevos “desafíos” hicieron que recordara una herramienta con la que tropecé hace ya algunos años y que me pareció genial. Dicha herramienta (Deep Freeze) permitía “congelar” todo el disco de tal forma que, cualquier cambio realizado en el equipo (instalación de software, infección de virus,  descargas, etc.), era eliminado automágicamente al reiniciar.  Con este antecedente, pensé en hacer algo parecido. Un sistema que fuera capaz de impedir cualquier cambio en cualquier archivo de mi Web, incluso impedir que se pudiera añadir/eliminar cualquier nuevo fichero/directorio, es decir, una especie de modo "Sólo lectura" para la Web que me permitiera pasar un fin de semana tranquilo y sin llamadas.

Una vez tenía clara la idea feliz, y el nombre: SnapWeb, pensé en realizar una copia del directorio web y, a través de una tarea cron, comprobar si se había realizado cualquier cambio y restaurarlo con la copia. Si bien este sistema funcionaba de forma correcta, tenía dos problemas fundamentales: 

1. ¿Cada cuánto tiempo repito la tarea?
2. El hecho de tener que comprobar TODO el sitio web cada vez; esto es un gran hándicap para los sites hechos con un CMS donde hay múltiples archivos y directorios. 

Con estas debilidades encontradas, recordé un proyecto que vi, allá por el 2010, que permitía analizar ficheros en tiempo real con clamAV + Inotify (También en SbD se han publicado varios post acerca de este asunto: Post 1 y Post 2). En este caso, la API inotify (disponible a partir de linux 2.6.13),  permitía iniciar el antivirus cuando se producía cualquier cambio en el sistema de archivos. 

Puesto que tenía claro que mi sistema iba a estar programado en BASH, busqué en alternativas que implementaran dicha API y que lanzaran mi script cuando se produjera algún evento sobre el directorio del site. 

De las distintas opciones que vi seleccioné incron. Éste programa es una mezcla de cron (programación de tareas) + inotify (detección de eventos en el sistema de archivos), lo que permite que se ejecuten tareas cada vez que se produce un evento sobre el directorio indicado. Una de los hándicaps que tiene incron es la NO recursividad, es decir, que en el fichero de configuración /etc/incron.conf debe contener cada uno de los directorios del site, además, cualquier nuevo directorio que se cree dentro del site debe ser dado de alta en el fichero de configuración.

Para solucionar el problema de la NO recursividad de incron, tenía claro que mi proyecto debía estar divido en dos scripts:

1. snapweb.sh --> Encargado de, dado un directorio pasado como parámetro, dar de alta en el fichero de configuración de incron todos los subdirectorios (Así solucioné los problemas de recursividad). 
2. jack.sh --> Será lanzado por incron cuando se produzca un evento. Dicho script recibirá el nombre del fichero afectado, su ruta y el evento en cuestión.

Pensé en hacer una especie de snapshot del directorio y monitorizar cualquier cambio posterior, denegando dichos cambios; después pensé que denegar siempre sería un poco radical, que lo ideal sería poder configurar varios tipos de bloqueo. Finalmente me decanté por esta segunda opción, con lo que en un fichero de configuración /etc/snapweb/snapweb.conf podremos decidir el tipo de bloqueo, existiendo un valor global que habilita el modo "freeze" del site: site_lock=1.

Está claro que esta solución no resuelve todas la vulnerabilidades que pueden explotarse en un CMS, pero sí permite cierta inmunidad a determinados exploits cuyo “modus operandi” está basado en la modificación de archivos (CryptoPHP), en la subida de Shells remotos o, incluso, en el uso de credenciales FTP robadas para distribuir malware. 

Actualmente una vez implementado correctamente ese “modo candado”, aquí os dejo un link a un vídeo con una prueba de concepto.

Estoy realizando varias mejoras:

• Nuevos modos de "bloqueo":
• Modo automático: Analiza en tiempo real cualquier cambio, categoriza dichos cambios y decide qué hacer.
• Aceptar cambios y guardar réplica.
• Denegar cambios y volver a réplica -> En este caso, para evitar los problemas que pudiera provocar un falso positivo, guardo copia del archivo en “cuarentena”
• Modo semiautomático:
• Si no se detectan indicios de malware, se acepta cambio, se actualiza réplica y se envía correo de notificación.
• Si se detecta malware, por encima de un umbral, se rechazan los cambios y se notifica al administrador.
• Si sólo hay indicios de malware pero no certeza, se envía correo al administrador para que éste decida qué hacer con dicha incidencia.
• Modo candado: No permite ningún cambio en el site, descartando de forma automática cualquier cambio en el site (Nuevas carpetas/archivos, cambios en ficheros existentes, etc.)
• Configuración del modo por site: Ahora los modos de bloqueo pueden indicarse por site, en vez de un único tipo de bloqueo para todos los sites albergados.
• Exclusión de directorios a monitorizar.
• Activación de modo "candado" por horario.
• Administración y monitorización de snapweb vía App.

Espero acabar pronto con esta primera parte del proyecto, publicarlo en github y que esté disponible para todos aquellos que lo consideréis interesante.

Además aprovecho para indicaros que si tenéis cualquier duda, sugerencia o crítica,  estaré encantando de recibirlas... aunque con las críticas habilitaré el modo bloqueo  :P.

[+] Ruta GitHub para su descarga y prueba: https://github.com/wllop/snapweb

Artículo cortesía de Walter Llop -  wllop@esat.es - @wllop

Leer más...

El compromiso de Hacking Team: el drama está servido

Aunque puede sonar repetitivo frente a lo ocurrido con Sony este pasado Diciembre, el compromiso de información de la empresa Hacking Team puede ser uno de los más importantes hasta la fecha. 

Si bien la relevancia de la información contenida en el dump de Sony podría alimentar nuestras ansias de cotilleos y próximos estrenos de cine, obtener información sensible de HT nos ha dado contraseñas de trabajadores, detalles de ventas, estrategias a clientes, código fuente de software de uso interno, correos electrónicos, y un larguísimo etc que aún hoy en día (bajo el hashtag #HackingTeam) está siendo analizado por la amplia mayoría de la comunidad.

Estamos ante una empresa, que no llega a 50 empleados, controvertida por el modelo de negocio de su última etapa, ya que en los últimos años ha sido software factory de mecanismos de infección de dispositivos (sistemas de usuario y móviles) para su compromiso de forma remota. Si bien este tipo de software es muy potente, sólo se comercializaba, supuestamente, para organismos gubernamentales y fuerzas del orden. En años anteriores, la empresa era una consultora más que realizaba tareas de auditoría y hacking ético.

Durante la noche de ayer domingo, comenzaba el buzz en Internet, en el que aparecían las primeras informaciones acerca de un supuesto leak de información de más de 400GB de información de dicha empresa. Pero la información llegaba con cuentagotas, unos pocos tenían acceso a la supuesta copia completa de información, y por el momento nos divertíamos con las filtraciones realizadas desde la propia cuenta de Twitter del Hacking Team que había sido comprometida. 

Uno de los tweets publicados desde la cuenta original de Hacking Team tras ser comprometida

Además, en un paste de Pastebin, aparecía un listado de los estados de renovación del software vendido a sus clientes, entre los que destacaban la Policia Nacional y CNI por parte de España.

Clientes europeos de Hacking Team

Los torrents con la información recopilada no avanzaban, además empezaban a surgir rumores de que podrían contener regalo, pero durante la mañana, Mustafa Al-Bassam, ex-miembro de Lulzsec habilitó una copia en su servidor web con todo el contenido robado de Hacking Team disponible para su navegación.

Es el tema candente de la mañana, y estamos seguros que también durante esta semana, seguiremos recibiendo información acerca de todo lo filtrado que llenarán posts de la mayoría de blogs relacionados con seguridad informática. Como comentamos anteriormente, conviene seguir el hashtag #HackingTeam para estar al tanto de todo lo que acontece.

Por el momento, desde Hacking Team no se han pronunciado acerca de lo ocurrido.

Leer más...

Enlaces de la SECmana - 283

• La polémica está servida, cómo votar múltiples veces con el sistema Vot.AR hoy domingo en Buenos Aires (Argentina)
• Vulnerability-Lab publica una vulnerabilidad en la API de Pinterest que permitiría a atacantes comprometer e-mails mediante inyección persistente.
• Advisory de Apple para el anuncio de parches de seguridad disponibles con corrección de vulnerabilidades tanto en iOS como en OS X
• Nota de prensa desde Europol anunciando la detección de sospechosos que estarían desarrollando y utilizando los troyanos bancarios Zeus y SpyEye
• El fundador de Rhino Security, Benjamin Caudill, crea un dispositivo que permite la utilización de redes wifi a 4 kilómetros, además de encaminar las conexiones mediante la red Tor.
• Artículo de la propia Microsoft sobre cómo capturar y descifrar tráfico TLS de Lync Server 2010 mediante herramientas propias de Microsoft.

Leer más...

Análisis dinámico de apps Android por hooking

Cuando nos enfrentamos a un proceso de reversing sobre una app Android una de las dificultades que podemos encontrar al hacer un análisis estático es un código complejo de trazar, ya sea por intención propia del desarrollador al escribirlo, por el uso de algún sistema de ofuscación, o incluso porque el propio proceso de decompilación ha generado un código poco legible.

Para lograr encajar las piezas de estos puzzles difíciles de resolver nos podemos apoyar en un análisis dinámico para por ejemplo identificar qué ocurre en las comunicaciones, qué cambios se producen en el sistema de ficheros, qué eventos genera la app, a cuáles responde, etc. Pero seguiremos teniendo un código muy oscuro que en algunos casos requerirá de un gran esfuerzo para determinar por ejemplo si un fragmento de código malicioso se llega a ejecutar.

Hace tiempo comentaba en un artículo cómo podíamos alterar en tiempo de ejecución el código de una app Android haciendo uso de la librería para hooking Cydia Substrate para por ejemplo desactivar el certificate pinning en Android.

Vista la capacidad de la librería, ¿porque no utilizarla para reflejar métodos y parámetros recibidos en una app que queramos analizar?, de este modo podríamos construir un árbol con el flujo de ejecución de la app según interactuamos con ella (o mientras ella misma hace sus procesos en background), identificando qué métodos llamaron a qué otros métodos además de reflejando qué valores fueron pasados como parámetros.

Con la idea clara de representar el flujo de ejecución y parámetros recibidos, decidí dar un paso más y hacerlo todo más sencillo, ¿por qué no hacer una herramienta que automatice al máximo el proceso?, podría conectarse al dispositivo, listar las apps, enumerar todas las clases que participan en una app seleccionada y permitir al analista seleccionar cuáles quiere observar...

android-hooker

Para poder utilizar la herramienta necesitaremos el siguiente entorno:

• Un dispositivo Android (físico o VM) rooteado, con Cydia Substrate instalado
• En el equipo desde el que vamos a realizar el análisis, será necesario tener Java (JRE para ejecutar o JDK si queremos modificar el proyecto) y las SDK tools de Android (con las Build Tools y una versión de la API de Android compatible con la instalada en el dispositivo)

La herramienta funciona del siguiente modo:

• Descargamos la app del repositorio de Github con el siguiente enlace (MD5: bbf563831e3d6be77c773c15f8a978e1 ) o clonamos el repositorio y lo compilamos con "mvn clean assembly:assembly" (nos generará el JAR a ejecutar en el directorio target)

• Iniciamos la aplicación con "java -jar android-hooker-1.0-jar-with-dependencies.jar". La primera vez que iniciamos la app tendremos que configurar la ruta al directorio donde tengamos el Android SDK, seleccionar la versión de las build tools que queramos utilizar y la versión del SDK que se ajuste al dispositivo que vamos a analizar:

• Lo siguiente que hacemos es introducir la IP del dispositivo a analizar (o dejarlo vacío si nos vamos a conectar a un dispositivo físico conectado en modo depuración) y seleccionamos la opción Connect, nos listará las apps instaladas en el dispositivo:

• Seleccionamos la app que queremos analizar y seguimos con el botón Extract classes from APK, descargará la app del dispositivo y podremos seleccionar las clases que queremos hookear. Ya casi hemos terminado, seleccionamos las clases que nos interesen y le damos a Hook classes:

En este punto es donde sucede la magia, dentro de android-hooker hay incluida una app Android que será compilada e instalada en el dispositivo. La app Android está preparada con un plugin Substrate diseñado para recibir un listado de clases sobre los que aplicará reflection para hookear todos sus métodos y crear así una traza dejando un rastro en el logcat que posteriormente android-hooker utilizará para crear el árbol de ejecución.

• Cuando se compile e instale la app Android veremos la notificación de Substrate en el dispositivo:

• En este momento ya podemos seleccionar en android-hooker la opción Watch logcat y reiniciar el dispositivo para que se aplique el plugin. En cuanto los métodos hookeados sean llamados comenzaremos a verlos reflejados en pantalla:

Dejo también un vídeo para que lo podáis ver en marcha:

Detalles finales

En cuanto al uso de la tool en sí, como toda herramienta "automatizada", recomiendo hacer un uso controlado. Si decidís hookear clases a diestro y siniestro, especialmente sobre clases muy básicas del framework de Android, posiblemente dejéis colgado el dispositivo al generar una actividad elevada sobre el logcat. Recordar, en la mesura está la maestría ;) .

Y en cuanto al código:

• Si queréis hacer vuestros propios ajustes sobre la app Android encargada del hooking, el código relevante lo tenéis en la clase LoggerPlugin
• Si queréis modificar la app Android, tendréis que comprimir todo el directorio de la app en un zip con nombre substrateApp y guardarlo en el directorio de resources (podéis darle un vistazo al zip que hay ahora para haceros una idea). Con esto el siguiente empaquetado que hagáis con "mvn clean assembly:assembly" usará vuestra app modificada.

Artículo cortesía de Miguel Ángel García

@nodoraiz

Leer más...