Mitigación de ataques DDoS basados en inundación

Los últimos años las denegaciones de servicio están en las noticias: ataques y amenazas a países enteros, bancos y servicios online, webs de intercambio de Bitcoins o cualquier otra cosa es susceptible de ser un objetivo.

Hace un tiempo Lorenzo contaba como se planteaban algunas mitigaciones. Esta entrada es una actualización, ahora que han pasado varios años y el panorama ha cambiado.

Antes de definir una solución técnica, los mecanismos de protección no tendrán sentido si no hay un procedimiento de respuesta y gestión del incidente que la respalde. Pese a que es obvio, este documento lo debe conocer y aprobar la dirección de la compañía. 

Algunas acciones que se han de contemplar para solventar el ataque, independientes del negocio del que se trate y la tecnología, incluyen:

• Antes del ataque:
• Conocer el impacto de la perdida de Internet, por ejemplo, si las VPN con clientes o proveedores se perderán, si otras oficinas ubicadas geográficamente se verán afectadas, si habrá correo electrónico con el exterior, VoIP, FAX, etcétera.
• Establecer procedimiento de monitorización temprana, donde se detecten movimientos o síntomas de que pronto habrá un ataque. Generalmente para esto se usan servicios de vigilancia de marca.
• Definir como se supervisan los sistemas y cuando generan una alerta de DDoS. Por ejemplo, cuando el ancho de banda es superior al 50%, hay más de 200.0000 conexiones en el firewall o su CPU ha superado el 75%.
• Establecer la arquitectura tecnológica de defensa, que debe incluir varias capas y que discutiremos más adelante.
• Definir como y cuando se harán pruebas de denegación de servicio para conocer como responderá la plataforma y el personal involucrado. Tal y como se haría en un Plan de Continuidad de Negocio específico.
• Borrador de plan de comunicación, que será remitido a los medios en caso de que se produzca una caída durante un periodo largo de tiempo. Este es un tema complejo, ya que en ocasiones salir en los medios de comunicación es lo único que pretenden algunos atacantes, por lo que ser transparente puede ser perjudicial.
• Plan de como se reforzarán otros canales de comunicación, por ejemplo, redes sociales, callcenters, presenciales, móviles, etcétera.
• Elaborar lista de contactos, con todos aquellas personas que deban llevar a cabo alguna acción, incluido proveedores (ISP) o fuerzas de seguridad del estado.
• Durante el ataque:
• Activar todas las mitigaciones técnicas: redirección de tráfico, aumento del ancho de banda, reglas en firewalls, firmas en IPS, WAFs, etcétera.
• Monitorizar la carga en los sistemas y aligerar la carga allí donde se pueda. Como por ejemplo hace Twitter cuando se cae y muestra un tiburón y un mensaje avisando de su caida. Podría definirse como "muerte con dignidad".
• Publicar nota de prensa y seguir la estrategia para dar respuesta en redes sociales o llamadas de medios de comunicación.
• Reportar el ataque a fuerzas de seguridad del estado en caso de que se considere esta opción como necesaria.
• Después del ataque:
• Hacer un estudio exhaustivo de lo ocurrido,  ya que en ocasiones la denegación de servicio es una cortina de humo para un ataque fraudulento más elaborado.
• Analizar el comportamiento y aprender donde se han producido los cuellos de botella.

Estas acciones son un punto de partida, pero en base al sector y tipo de negocio, seguro que son necesarias incluir muchas otras.

En cuanto a la solución técnica, por desgracia no hay nada completamente eficaz y si el ataque es de tamaño considerable, nada podrá evitar que se deje a la compañía fuera de juego. Al final, es un pulso de recursos para averiguar quien tiene más dinero, si centenares de miles de personas (o bots) o una compañía que pueda pagar el coste que eso supone en ancho de banda.

Este tipo de soluciones no son excluyentes y es conveniente disponer de más de una de ellas. Es cierto que existe mucho marketing alrededor de las denegaciones de servicio, ya que es la última moda y los fabricantes no han tardado en sumarse al FUD para vender sus productos y servicios. Por desgracia y teniendo en cuenta la situación actual, es mejor protegerse.

La arquitectura de seguridad para minimizar los efectos de la denegación se basa en alejar lo máximo posible el ataque de los sistemas finales de la compañía y conseguir el filtrado lo más cerca posible de los que atacan, para ello hay distintos niveles de protección.

1.- Servicios de "data scrubbing"
Cada día son más populares, la defensa consiste en anunciar mediante BGP rutas alternativas que llevan   a datacenters estratégicamente ubicados en zonas clave de la red, donde filtran el tráfico malicioso y redireccionan el limpio hasta el destino.

Los proveedores que ofrecen este tipo de servicio son Prolexic y Verisign.  

2.-Servicios en redes distribuidas (CDN)
Funcionan como proxys-cache transparentes y hacen las funciones de WAF en la nube con capacidad de absorber grandes cantidades de ancho de banda. Generalmente solo sirven para web y DNS.

Los proveedores que ofrecen estos servicios son: Cloudflare, Akamai e Imperva

3.-Servicios del ISP
Los ISP grandes tienen servicios adicionales para proteger a sus clientes de los DDoS. Realmente lo único que hacen es redirigir el tráfico a su propio datacenter de limpiado donde con la cacharrería adecuada filtran el tráfico creando una tubería limpia o "clean pipe".

Los ISP  con este tipo de servicios son: Telefónica, Colt, Verizon, AT&T, etc

4.-Productos "in-house"
Además del firewall/IPS como elementos perimetrales de la propia red de la compañía, hoy en día es necesario añadir un producto específico que su única capacidad sea la del filtrado de tráfico. No tienen firmas para mucho más y el objetivo de estos appliances es el de procesar grandes volúmenes de datos.

Los proveedores que ofrecen este tipo de hardware específico son: Arbor, Radware, RioRey y Corero

Como había comentado anteriormente, no hay bala de plata, pero se puede luchar.

En la próxima entrada hablaré del plan de pruebas. Lo mismo a alguien le es útil.

Leer más...

Mod_dynip: Cómo proteger wordpress de ataques de fuerza bruta

En las últimas semanas se ha publicado en diferentes medios que ha habido una oleada de ataques de fuerza bruta, o de diccionario, contra el panel de administración de plataformas Wordpress. Por defecto, las herramientas de administración de este tipo de infraestructuras suele estar en la URI /wp-admin.

Es decir, que mediante http://www.ejemplo.com/wp-admin se accedería a una bonita pantalla de autenticación que espera un usuario admin y una contraseña. 

Este es el escenario ideal para este tipo de ataque de fuerza bruta o de diccionario, que prueban de forma sucesiva combinaciones de usuarios/contraseñas hasta dar con algún par que tenga la suficiente debilidad.

Como medidas de seguridad para wordpress ya hemos recomendado, entre otras, la utilización de algún módulo que incluya un CAPTCHA que permita evitar la actividad maliciosa de algunos bots.

Sin embargo, y como soy de la opinión que "muerto el perro, se acaba la rabia", creo que la mejor de las medidas que se pueden tomar para proteger la administración del Wordpress es acotar, mediante las herramientas que provee el propio servidor web,  las direcciones IP desde las que se puede llegar a ver lo que hay tras el directorio /wp-admin. 

En Apache, tanto mediante ficheros .htaccess o en un fichero de configuración, mod_access o en Apache 2.2.X y 2.4.X mod_access_compat, permiten generar, para el "Location /wp-admin" un bloque del tipo

<Location /wp-admin>
Order deny,allow

Allow from 192.168.1.0/24

Deny from All
</Location>

Para muchos de nosotros, que disponemos de una dirección IP fija o que gestionamos el wordpress en un servidor "in-house" el problema se termina ahí. Permites únicamente el direccionamiento interno de forma manual y a correr. Si el servidor se encuentra en algún hosting, quien tiene que administrarlo cuenta con una dirección IP pública fija, y te permiten configurar un bloque como el anterior, también esto se arregla ahí.  

Sin embargo, si nuestro ADSL dispone de una IP dinámica, o si nos encontramos fuera de nuestra red. ¿Cómo lo hacemos? Inicialmente pensé que como mod_access tiene una opción mediante la que podemos indicar un dominio, de manera que todos sus subdominios estarán permitidos o denegados (dependiendo de si usamos una directiva Allow o Deny en Apache), podríamos crear un dominio del tipo dyndns o no-ip.info, que podamos actualizar según la IP que tengamos y hacer que Apache nos abra sus puertas.

Después de hacer un montón de pruebas, y ayudado de tcpdump, se ve que el funcionamiento de Apache, cuando llega una petición a /wp-admin, hace una resolución DNS inversa de la IP origen. De esta manera, si ve que coincide con lo definido en la directiva con el subdominio, le permite la entrada. Pero esto no funciona para lo que queremos, puesto que el dominio devuelto en la resolución inversa no coincide con el dominio Dyndns, sino que suele referirse al nombre de la red del proveedor de Internet. 

Así que, tras buscar opciones y otros módulos existentes para lo que yo quería, decidí hacérmelo yo mismo.

Utilizando esta fantástica guía de desarrollo de módulos de Apache modifiqué, según mis necesidades el código fuente de mod_access.c. Lo he llamado mod_dynip.c y lo podéis descargar desde el repositorio de herramientas de SbD.

Para no volverme loco con la creación de directivas nuevas, he sustituido los típicos Order, Allow y Deny por "Orden", "Permitir" y "Denegar" (typical spanish :D). De esta forma el bloque que necesitaríamos para proteger /wp-admin sería algo así:

<Location /wp-admin>
Orden denegar,permitir

Permitir from anywhere.dyndns.com

Denegar from All
</Location>

Para permitir la IP donde estemos, sólo tenemos que habilitar, o desde la propia página web de dyndns/no-ip, la API del proveedor, aplicaciones para dispositivos móviles, etc,… Una vez gestionado el dominio, una buena práctica sería modificar el valor IP a 127.0.0.1, para que quede la puerta cerrada al exterior.

Como ya sabéis, para compilar e incluir el módulo en vuestro Apache debéis ejecutar:

apxs -i -a  -c  mod_dynip.c -n mod_dynip

Con este comando el fichero mod_dynip.so se creará y colocará donde corresponda, y se editará el fichero httpd.conf, e incluirá en la sección correspondiente la línea "LoadModule dynip_module       /usr/lib64/httpd/modules/mod_dynip.so"

Bueno venga… ¿y las tripas del módulo, qué hacen?

Fundamentalmente, lo que modifiqué del código de mod_access, es el comportamiento del mismo cuando se encuentra un dominio en una directiva Allow o Domain. Así, lo que hace primero es resolver, dado ese dominio, todas las direcciones IP asociadas. En el caso de un dominio dinámico, será sólo uno, pero si lo queremos usar para un dominio estático, que tenga varias IPs, funcionará igualmente. Por cada una de las direcciones IP encontradas, las irá compararando contra la dirección IP origen detectada por el servidor web y si coincide la dejará pasar o no (dependiendo si es un Permitir o Denegar). 

Aunque faltan varios includes y cambios menores, que podéis ver en la descarga, la parte más importante del código es la siguiente: 

Después de una semana puesto en mis servidores en producción (soy así de osado), puedo decir que funciona estable y correctamente con direccionamiento IPv4.  

Leer más...

Enlaces de la SECmana - 171

• La noticia de la SECmana, el blog de nuestro compañero Angelucho cumple 1 año en la red. ¡FELICIDADES! X1RedMasSegura!
• Detenido un empleado de la empresa de hosting Hostgator, tras descubrir que podría haber comprometido más de 2700 servidores tras instalar una puerta trasera.
• Versión 2.1.0 de la aplicación proxy para interceptar peticiones, OWASP ZAProxy. Se puede descargar para todos los sistemas operativos desde este enlace.
• Disponible la beta de la versión 4 del Enhanced Mitigation Experience Toolkit (EMET) de Microsoft. 
• Nir Goldshlager de Break Security publica en el blog algunos de sus descubrimientos en referencia a Cross-Site Scriptings almacenados en Facebook, en aplicaciones de Chat, Check-in y Messenger.
• Disponible el video con la conferencia presentada el 20 de marzo de 2013 por D. Oscar de la Cruz, Comandante de la Guardia Civil y Responsable del Grupo de Delitos Telemáticos, en el IX Ciclo de Conferencias UPM TASSI.
• En MacTracks&Tips, recopilatorio con 12 recomendaciones de seguridad a tener en cuenta para sistemas operativos Mac OS X
• Nuevo módulo dentro del proyecto ThreatAgent llamado Passision, que permite la creación de listas de palabras con posibles passwords a probar, generada tras la recopilación de información sobre la organización y su localización.
• Oracle parchea 42 vulnerabilidades de Java en la versión 7u21, añadiendo restricciones y avisos para la firma de código. Además, también se parchean 24 vulnerabilidades en MySQL que permitirían denegaciones de servicio, acceso y modificación de datos.
• En NakedSecurity, recopilación de 8 acciones imprescindibles para tener un buen plan de seguridad para gestión ante incidentes.

Leer más...

Jornadas de Análisis Forense en Tarragona

Disclaimer: Estimado lector, si has llegado a este artículo buscando ayuda con relación a algún análisis forense, formación relativa al tema o a una asociación existente, yo, Lorenzo Martínez, a título personal, te quiero hacer saber que ya no me encuentro en la ANTPJI. Por ello, si piensas que puede darte ciertas garantías que yo pertenezca a la misma, te ruego que leas el post relacionado con ANCITE, Asociación Nacional de Ciberseguridad y Pericia Tecnológica.

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

Fue hace escasamente un par de meses, cuando se celebró el curso de perito telemático forense en la UDIMA en Madrid, organizado por la ANTPJI. Agradezco a todos aquellos que rápidamente os apuntasteis y pudisteis optar a una plaza. Lamentablemente el aforo era de unas 120 personas y se llenó en seguida. En esa ocasión, intenté coordinar las ponencias y cubrir un temario que pudiera ser de utilidad para peritos informáticos forenses. Por ello quiero agradecer, primero que nada, a todos aquellos profesores y amigos, a los que lié para que participasen dando una charla. Todos los profesores sois compañeros y amigos, pero quiero expresar públicamente mi agradecimiento a Juan Garrido "Silverhack" (calificado por las encuestas de los asistentes como mejor ponente en ese evento), Marc Rivero y Luis Delgado por haberme apoyado y estado ahí, como se suele decir, a las duras y a las maduras.

En esta ocasión, y para los que no tuvisteis oportunidad de asistir a la edición de Madrid, el buen amigo, y socio de la ANTPJI, sobradamente conocido en el sector de la seguridad y el análisis forense, Pedro Sánchez ha decidido liderar la organización de un evento con charlas sobre análisis forense con el apoyo de la Universidad Rovira i Virgili, en Reus - Tarragona. Las fechas que debéis reservar en vuestra agenda desde ya mismo son el 10 y 11 de Mayo de  2013.

Ver mapa más grande

El objetivo de estas jornadas es enseñar a los asistentes las diversas actividades que se llevan a cabo a lo largo de un análisis forense, de manera que pueda ser un buen punto de apoyo a la hora de ser perito informático judicial. 

En este caso, el plantel de ponentes que Pedro ha seleccionado, entre los que me encuentro yo mismo, promete un evento bastante interesante: Juan Antonio Calles, David Barroso, Simón Roses, Juan Garrido "Silverhack", Marc Rivero, el propio Pedro Sánchez, etc,…

En los siguientes enlaces, podéis ver la lista completa de ponentes y la agenda inicial de las presentaciones.

Si sois de Cataluña o alrededores, y tenéis inquietud por el mundo de la informática forense, podéis asistir a este curso que tiene un coste de 70 euros para socios de la ANTPJI y Universitarios, así como de 140 euros para profesionales.

Por experiencias de otras ediciones, como las de Valencia o Madrid, el aforo se completó bastante rápido y hasta los ponentes teníamos que permanecer de pie casi todo el evento, por lo que os aconsejo que si os vais a apuntar, no lo dejéis para última hora y lo hagáis cuanto antes.

Nos vemos en Reus - Tarragona!

Leer más...

El timo de los números 118xx y Google

Es innegable nuestra dependencia hoy día de Google, mucha gente ni siquiera se molesta en teclear la URL de servicios conocidos, simplemente pone 'facebook' en la barra de búsqueda y espera a que Google les de el enlace.

Google, aun siendo el buscador mas usado (o igual por eso), es víctima de muchos 'pillos' que se afanan por encontrar huecos para colar su timo.

Hoy vamos a hablar de los números de teléfono 118xx, en principio son solo números de información, de esos que proliferaron cuando se terminó el afable y gratuito 1003 'de toda la vida' y que tienen un coste por llamada bastante alto.

Como el resto de números de sobre-tarificación viven de dar una supuesta información 'muy útil' cobrándola a precio de oro.

Hasta aquí, nada que objetar, si alguien es tan generoso de usar ese número para encontrar información que se puede encontrar en un buscador, genial.

El problema viene cuando engañas a la gente, cuando timas y cuando intentas lucrarte a base de aprovecharte de incautos.

Ayer necesitaba localizar el número de atención al cliente de cierto operador, vago de mí puse en google:

'telefónica atención al cliente'

y ¡¡ Sorpresa !! esto fue lo que me encontré

Como se puede observar (click para agrandar la imagen) nos encontramos con que unos cuantos 'listos' han comprado ADS en google para que muestre como primer resultado sus números de sobre-tarificación. ¡ Toma ya !

En este caso nos encontramos 11847. Bueno, aquí, haciendo un ejercicio de sofismo en estado puro, uno puede pensar, tal vez 'telefónica' es un término muy genérico y en buena lid, 'telefónica atención al cliente' igual se puede interpretar como 'atención telefónica' en genérico, venga vale

¿Y si buscamos otro? Veamos

Ah no ! ahora si que no hay la menor duda, ya en plan descarado, buscando el número de atención al cliente de Yoigo nos encontramos en primer lugar 11834 y más abajo, como tercer resultado 11874.

Ya no me cabe ninguna duda: Timo a la vista, de hecho, si visitamos uno de esos enlaces, nos encontramos algo como:

Creo que sobran las palabras, personalmente entiendo que esto está hecho así para generar confusión y hacer que la gente llame y sea víctima de un timo. De hecho si se googlean esos números nos encontramos con cosas como esta:

Si yo fuese telefónica, Yoigo, ONO o cualquier operadora, ya estaría tomando cartas en el asunto.

Leer más...

La mentira de los "puntitos" en Android

Tu contraseña está segura en tu teléfono Android. Lo he visto yo. Pone puntitos en la casilla, eso es seguro FIJO.

Pone "·········" en la casilla dónde la pusiste anteriormente. Así que nadie la puede ver. Bueno... depende.

Los datos de las WiFis en Android no se cifran de ninguna manera. Si bien puede ser algo delicado depende en que entornos, es útil en cierto modo...

Al margen de poder ver la contraseña en los ajustes, con la casilla "Mostrar contraseña"; podéis verlas en el fichero "/data/misc/wifi/wpa_supplicant.conf", con este formato tan chulo:

network={

  ssid="BatWifi"

  psk="c4tw0m4n1sh0t"

key_mgmt=WPA-PSK

priority=3

  }

Pero, las credenciales de las VPNs almacenadas en Android... ¿cómo almacenan los datos?

@Chencho dijo: "(...) están en /misc/data/keystore (creo) y parece que están cifradas con cosas gordas y caras."

Pregunté por ahí a ver si alguien sabía de la existencia de una manera de "desvelar" contraseñas de las VPNs almacenadas (Gracias a @ldelgadoj y a @0xroot por la info), y a nadie le sonaba nada... Echemos un vistazo.

Si nos asomamos a "Ajustes > VPN > VPNBorjamari", al contrario que con las claves de redes WiFi:

• No hay casilla de "mostrar contraseña"
• Seleccionar el texto no da la opción de copiar/cortar. (Menú contextual capado)
• Arrastrar la selección a la casilla de usuario (por ejemplo) no hace más que mostrar los "puntitos".

¿No se puede copiar?

Bien hecho Android, guardar en plano la contaseña de acceso a una VPN, quedaría feo... Pero...

Un día, usando la aplicación WifiKeyboard (un teclado que ofrece un interfaz web para poder escribir al teléfono) encontré una opción que se define como:

"Edit text locally:"

Si pulsas la tecla F4, te "trae" el contenido de la caja de texto que tuvieras seleccionada en el teléfono para que lo puedas editar en el navegador, y volver a mandarlo al teléfono. ¡ QUE ÚTIL !

Pero... ¿si lo hago en una casilla de contraseña? Yo di por hecho que ejecutaría un "copy" en el teléfono, y pegaría el resultado en el navegador, con su correspondiente string de "·········".

Sin embargo, cual fué mi sorpresa, que al pulsar F4 mientras tenía seleccionado el campo de la contraseña de mi VPN casera, ¡ me mostró la clave en plano !

Vaya. Aquí pasa algo. Lo interesante será, saber EL QUÉ.

Lo que me facilitó MUCHO las cosas fué que el proyecto es de código abierto :D (Para que luego digan que el open source no vale para nada ¬¬) Está disponible aquí: https://code.google.com/p/wifikeyboard/

Bueno, al turrón. Vamos a ver que pasa cuando le damos a la tecla F4... Empecemos con lo fácil, Zaproxy + Interfaz web del WifiKeyboard:

Al pulsar F4 se realiza una petición HTTP a "http://IPDELTELEFONO:1111/text" (sin datos por POST ni nada "extra") que devuelve en plano el texto contenido en la casilla donde nos encontremos en el teléfono.

En el código fuente del interfaz en HTML, se procesa que en el get esté "/text" y una vez encontrado, llama a local_input(), que es donde lee que la tecla pulsada sea F4 (En Javascript el keycode 115):

Que a su vez llama a submit_text()... que finalmente acaba pasando la petición a una clase en Java del tipo InputMethodService, que nos va a permitir usar los métodos que interactúan con el teclado.

Y finalmente, llegamos a la función clave:

Lo que ocurre aquí, es más o menos lo siguiente: 

Se crea un objeto de tipo ExtractedTextRequest, que será utilizado para llamar con el cómo parámetro al método getExtractedText(), de la interfaz InputConnection.

Una vez establecidos los parámetros necesarios del objeto ExtractedTextRequest, se llama a la función "getExtractedText(ExtractedTextRequest request, int flags)", que según la documentación oficial, hace esto:

"Retrieve the current text in the input connection's editor, and monitor for any changes to it."

Lo castea a String... y ¡ TACHÁN ! ya tenemos nuestro contenido :D

Al no ejecutar el "copy", Android no copia los puntos. En lugar de "copiar", "extrae" el texto de la selección, que como voy a demostrar, está en plano realmente.

Bueno, una vez visto esto... ¡ vamos a hacer una pequeña app para poder usarlo en local !

PoC

Después de mirar y rebuscar, teniendo en cuenta que es la primera vez que programo algo para Android... (quiero agradecer a Iban su paciencia en enseñarme lo que se de Java, si no, no hubiera podido ni leer el código) vi que la mejor manera de hacer el PoC era con el teclado de muestra que viene con el SDK, que provee un IME (Input Method Editor) enterito y busqué una manera de "disparar" la función getExtractedText().

La solución ha sido onKeyDown() dentro del fichero .java que nos da la demo del teclado de Android "SoftKeyboard.java":

Por lo tanto, mientras tengamos seleccionado como input nuestro teclado "especial", la tecla "MENU" lanzará ese código que hemos definido, mostrando, en este caso, la contraseña de nuestra VPN:

Claro, imagínate que ves algo así, preguntas a la gente... y nadie sabe nada... ¡ Oh dios ! ¡ Lo he encontrado yo !

Y como buena persona que soy, un "responsible disclosure" estaría bien, así que mandé un mail a security@android.com.

Tras decirme en el primer email, que me agradecían el aviso, que lo iban a mirar y se pondrían en contacto conmigo... cito la respuesta final:

"Looking into this more we believe this is intended behavior, since an IME must be able to interact with text already entered in text fields."

Vaya, he dado con una "feature"... que decepción. Sinceramente, viniendo esa respuesta de la empresa que viene, no me la esperaba en absoluto. ¿Una "feature" poder acceder a las credenciales de una VPN?

Pero, si es una funcionalidad, ¿por qué está capado el menú de copiar y pegar?

¿Por qué no hay una casilla de "mostrar contraseña"?

Aunque lo fuera... no me parece una buena práctica el poder ver las contraseñas de las VPNs almacenadas...

En resumen, no se si alguien sabía esto. Igual resulta que se puede incluso habilitar un botón de "Mostrar contraseña" para las VPNs y yo no lo sabía... De todas maneras, aquí he escrito algo para que os entretengais un poco y encima os regalo el APK para que mireis vuestras contraseñas por si se os olvidan.

Como parte de una auditoría, el obtener las credenciales de una VPN corporativa en un teléfono Android... me parece que menos que útil.

Esta "función extra" del teclado la he probado con unos cuantos inputs "ocultos" como el campo donde se escribe el pin de desbloqueo en los ajustes o en algún otro campo. Es útil si tienes que escribir una contraseña larga y no sabes si te has equivocado :D

Bueno, os dejo el .apk y ¡ Espero que a alguien le sea de ayuda !

[APK] DotShowKeyboard

P.D.: Es un .apk autofirmado que es el "SoftKeyboard" incluido de muestra en el SDK de Android y SÓLO tiene añadida la función de sacar en una alerta Toast con el contenido de la casilla donde se encuentre el usuario posicionado. Si no os fiais (normal) podeis hacerlo vosotros mismos con el "SoftKeyboard" que viene con los ejemplos del SDK de Android.

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

Artículo cortesía de Borja Berástegui

Leer más...

Análisis dinámico de malware para Android con REMnux y MobiSec

Esta semana Lenny Zelster ha liberado la versión 4 de REMnux, una distribución pensada para el análisis de malware.

REMnux incorpora una batería de herramientas que facilita y acelera el proceso de análisis y aunque inicialmente no está pensada para analizar malware para Android sí que puede aprovecharse algunas de sus funcionalidades.

Por otro lado los chicos de Secure Ideas han desarrollado una distribución llamada MobiSec diseñada para evaluar y analizar la seguridad de dispositivos móviles y las aplicaciones para estos. Tiene también multitud de herramientas, emuladores, etc.

La idea de este post es daros a conocer ambas distribuciones y combinar sus funcionalidades con un pequeño ejemplo para Android. El objetivo no es realizar un análisis exhaustivo de malware sino explicar como con estas herramientas se podría realizar parte del análisis del comportamiento durante análisis de malware.

REMnux se puede descargar en formato OVF/OVA lo que permite importarla en VMWare or VirtualBox. Por el contrario MobiSec requiere descargar la ISO e instalarla en VMWare or VirtualBox de manera manual. Una vez instaladas ambas máquinas, y como se trata de analizar malware, es importante configurar la red de manera aislada y sin acceso a Internet, es decir, en modo 'Host only'. Además, con el fin de facilitar el análisis, configuraremos el DNS y gateway de MobiSec para que sean la IP de REMnux.

MobiSec, entre otras herramientas,  incorpora distintas versiones de emuladores para Android lo que facilita mucho el trabajo cuando se quiere ejecutar algo sobre Android de manera rápida, ya que no hay que configurar nada. En este caso usaremos la versión más reciente instalada, 4.0.3.

El siguiente paso es subir el malware al emulador de Android dentro de MobiSec. En el caso de este ejemplo el malware lo descargaremos desde http://contagiominidump.blogspot.com.es a la máquina física para luego subirlo a MobiSec por SCP. El malware elegido es el Android.Exprespam.  El único paso restante es instalar el malware en el emulador con los comandos de 'adb' (adb install).

Mientras, y antes de ejecutar el malware en el emulador, vamos a preparar REMnux. REMnux permite ejecutar servicios de tal manera que el malware se conecta a estos servicios simulados (como si se tratara de un honeypot) lo que es de gran utilidad para ver qué hace el malware de manera dinámica, por ejemplo resolver una determinada dirección IP, conectarse a un servidor de IRC, enviar SPAM or comunicarse vía HTTP. 

El primer paso es ejecutar 'fakedns' para resolver todos los nombres de dominio a la IP de REMnux y a su vez lanzar Wireshark para tener visibilidad de lo qué ocurre.

En este caso podemos ver que el malware  pregunta por el dominio ftukguhilcom.globat.com y que REMnux le responde con la IP de si misma.

A continuación se puede ver en Wireshark que el malware intenta realizar una conexión HTTPS, que es reseteada por REMnux al no existir tal servicio.

El siguiente paso es emular un servidor HTTPS, con el fin de ver que tipo de información se intercambia. REMnux incluye una servidor HTTP y stunnel, lo que permite crear de manera sencilla un servidor HTTPS. Para ello lanzamos el servidor HTTP con el comando 'httpd start' y configuramos stunnel con un certificado autofirmado.

Si miramos en los logs del servidor HTTP no vemos ninguna petición web. El problema es que al tratarse de un certificado autofirmado es necesario aceptarlo cuando se accede por HTTPS. Puede ser que el malware compruebe la validez del certificado, como un control adicional, o bien que el malware use el navegador de Android que tampoco tiene importado este certificado.

Si fuera el segundo caso se podría importar el certificado en el repositorio de Android y evitar este problema. Pero como el propósito de este post no es realizar un completo análisis sino mostrar las herramientas que ofrece REMnux y MobiSec, vamos a continuar el análisis con otro malware que usa HTTP. En este segundo caso usaremos el malware Chuli.A

Los pasos son análogos: instalaremos el malware en el emulador y lo ejecutaremos.

En este caso el malware accede directamente a una dirección IP, en lugar de resolver un dominio. Afortunadamente REMnux es capaz de responder a esas peticiones de manera automática por lo que mirando Wireshark podemos ver que el recurso pedido es 'android.php' pero este recurso no existe en nuestro servidor HTTP.

Paralelamente podemos ver en los logs del servidor HTTP las peticiones web al recurso android.php. Como el fichero no existe en el servidor, vamos a crearlo con el fin de interactuar con el malware y ver como reacciona al encontrar el fichero.

Ahora, al existir el recurso, se puede ver en los logs del servidor la respuesta con código 200 .

Probablemente durante este mensaje POST el malware informe al C&C de que el dispositivo ha sido comprometido y le mande información del mismo como por ejemplo el IMEI. Seguramente  el string 'phone1365842571243' envíado en el POST sea un identificador único para este dispositivo que permita indentificarlo.

Como la respuesta recibida ha sido 200 ahora el malware realiza otras peticiones que se pueden ver ver en los logs del servidor HTTP. Para ser precisos, el recurso solicitado es 'POST /data/phone1365842571243/process.php'. Igualmente que antes, y con el fin de interactuar con el malware, vamos a crear ese recurso y a ver que pasa.

Parece que funciona pues se realizan varias peticiones POST  que podremos analizar con Wireshark. Estas peticiones contienen diferente información.

Por ejemplo, en una de ellas se envía lo que parece ser la localización del dispositivo (probablemente coordenadas GPS codificadas de alguna manera)

En otra parece que se envía los contactos, que en este caso no son datos validos porque la lista esta vacía:

Podríamos seguir analizando las distintas peticiones y ver que tipo de información se envía mediante las diferentes peticiones POST pero no es el objetivo de este artículo.

Lo imporante es quedarse con la idea de que con MobiSec y REMnux es posible interactuar con el malware de manera dinámica creando respuestas DNS, servicios HTTP/s, recursos web, etc, según vayamos avanzando en el análisis. Además MobiSec incorpora herramientas que permitirían hacer ingeniería inversa del malware, pero eso lo dejamos para otro post.

Artículo cortesía de Angel Alonso-Parrizas 

Leer más...