XSS
Mostrando entradas con la etiqueta XSS. Mostrar todas las entradas
Mostrando entradas con la etiqueta XSS. Mostrar todas las entradas

Multiple XSS en Babylon

Add Comment
Hola tod@s

Tras varios avisos y por distintos medios, formularios de contacto, a diferentes correos corporativos de Babylon, como info, soporte, software, etc. En fin, no he recibido ningún tipo de respuesta. Por ello he decidido hacerlo público, a ver si con repercusión mediática, llamamos su atención. Así mismo sres de Babaylon sigo estando a su disposición para ayudarles a solucionar la vulnerabilidad que afectaría a millones de usuarios en todo el mundo. Al igual que hice con otras vulnerabildiades, fue reportar y ayudar a su solución de forma inmediata, yo también soy un usuario de Internet y deseo una red más segura.

Babylon fue fundada en 1997 y tiene sede en Tel Aviv (Israel). Babylon ofrece varios y distintos servicios a usuarios finales y empresas.

El traductor ofrece traducciones en 77 idiomas, también dispone de diccionario. El software se vende en todo el mundo y se utiliza en más de 168 países y tiene una creciente base de usuarios de instalaciones de escritorio más 90 millones. Además dispone de app para Iphone, Android, Windows, Blackberry y Kindle y hasta un servicio pro para empresas.

Por otro lado, dispone de servicios de monetización para proveedores de contenidos y sitios web editores web, bloggers y webmasters.

Esta empresa hasta dispone de servicios búsqueda en la web, sí también es un buscador.

Veamos la prueba de concepto:
  • URL:   
  1. http://espanol.babylon-software.com/bht/index.html?trid=
  2. http://traductor.babylon-software.com/ingles/a-espanol/ 
  3. http://traduccion.babylon-software.com/?trid=
  • Vector:  <img src=1 onerror=alert("n0ipr0cs");>/
  • State: unpathed

Imagen 1: Primer XSS en Babylon

Imagen 2: Segundo XSS en Babylon

Imagen 3: Tercer XSS en Babylon


No seáis malos. 

XSS en Tradukka

Add Comment


Hola a tod@s


Ayer necesitaba traducir un texto y como es habitual tire de un traductor que conocía hace tiempo, pero nunca me puse a analizarlo, su nombre Tradukka, se trata de unos de los traductores más usados por su calidad de traducción más real, comparado con traductores como el de Google que traduce bastante mal.


Tras un simple vistazo, en la URL: http://tradukka.com/translate/en/es/ probé tipo de inyecciones, tras unas cuantas pruebas y payload, bingo! Entro en mi gustirin que nos entra a los que nos dedicamos a esto. Una mezcla  de placer y satisfacción. Mi cara de malo :p  encontré un Cross Site Scripting en la parte pública de la web, más concretamente en la URL principal del aplicativo web.



URL: http://tradukka.com/translate/en/es/

Vector:'><img src=x onerror=alert("XSS");>

Estado: Solucionado.


La verdad que el equipo de Tradukka ha sido muy rápido en solucionar la vulnerabilidad, lo notifique ayer por la tarde y hoy ya estaba solucionado.

Por lo visto no tienen bug bounty, así que no recibí ni un €, tampoco tienen hall of fame, me han comentado que tienen uno interno. Eso sí me han dado las gracias por Twitter.



Credits: http://seclists.org/fulldisclosure/2016/Apr/17

No seáis malos.

El NO Cross-Site Scripting de Google

2 Comments


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.

No seáis malos.

Actualización 15/12/2015


Medios que se han hecho eco del hallazgo:

Liberando algunas vulnerabilidades - Ultimate Product Cataloge v2.1.2 (II de II)

Add Comment
Hace ya un tiempo que escribí la primera parte de de este artículo, en él os hablaba de unas vulnerabilidades del plugin de Wordpress llamado Ultimate Product Catalogue en una versión menor o igual a la 3.1.4.
En su momento publiqué un par de SQL Injections sin autenticar [1][2]y hoy toca hablar de una especie de combo XSS + CSRF + File Upload descrito en el POC de de exploit-db [3] y el vídeo de youtube [4].

La utilidad básica de este plugin es publicar un catálogo de productos para vender y presentar en tu blog wordpress.

Ninguno de los formularios de este plugin cuenta con protección contra CSRF, es decir, que en el momento que un administrador o colaborador de la web visite un enlace a una web especialmente creada para esto, podría provocar, entre otras cosas, acciones en la parte de administración de este plugin, como podría ser cambiar los detalles de un producto como precio, título, descripción, o lo que es peor, inyectar código javascript en estos campos, ya que estos no se filtran en ningún momento. Por lo tanto, se podría conseguir mediante una visita del administrador a una web de perros gansta que modificara atributos de un producto a la venta para servir código HTML o javascript a todos los visitantes del blog que visitaran este catálogo de productos (1º combo: CSRF + XSS).

Por otro lado, contamos con la funcionalidad de subida de excels o CSV sin protección CSRF ni comprobación del tipo de fichero que se sube, dando como resultado la la posibilidad de que un administrador visitara una web de perros molones terminara subiendo un backdoor PHP en el servidor (2º combo: CSRF + File Upload).

En el siguiente vídeo se observa un POC de lo anterior, está editado regular, así que es posible que para pillar los detalles tengas que pararlo de vez en cuando:



La empresa está notificada desde hace tiempo y ambas vulnerabilidades solucionadas.

[1] https://www.exploit-db.com/exploits/36823/
[2] https://www.exploit-db.com/exploits/36824/
[3] https://www.exploit-db.com/exploits/36907/
[4] https://www.youtube.com/watch?v=roB_ken6U4o

Ataques de inyección de código en aplicaciones móviles basadas en HTML5

Add Comment
Hola a tod@s

Con nuestros Smartphone escaneamos códigos QR, realizamos envíos de mensajes, escuchamos música o vemos videos. En estos pequeños gestos podemos estar expuestos a infectarnos o ser víctimas de robo de información.

Una tecnología emergente HTML5 se ha convertido en nuevo vector de ataque, el desarrollo de aplicaciones basadas en HTML5 ha ido ganando rápidamente popularidad en la industria móvil. Un reciente informe de Gartner dice que para el año 2016, cincuenta por ciento de las aplicaciones móviles utilizará las tecnologías basadas en HTML5.

¿Qué plataformas están afectadas?
Todos los principales sistemas móviles se verán afectados, incluyendo Android, iOS, Blackberry, Windows Phone, etc., porque todos ellos admiten aplicaciones móviles basadas en HTML5.

Un problema notorio de la tecnología basada en HTML5 es que código malicioso puede inyectar fácilmente en el programa y ejecutado. Es por ello que el ataque Cross-Site Scripting (XSS) sigue siendo uno de los ataques más comunes en la Web. Sólo pueden hacer objetivo a ataques XSS en aplicaciones web a través de un solo canal (es decir, Internet), pero con la adopción de la misma tecnología en dispositivos móviles, se ha descubierto que un tipo similar de ataque no puede ser sólo lanzado contra aplicaciones móviles, puede atacar de muchos canales, incluyendo código QR, exploración de Wi-Fi, canciones MP3, videos MP4, Mensajes SMS, etiquetas NFC, lista de contactos, etc.. Tanto como una aplicación basada en HTML5 muestra información obtenida del exterior o de la aplicación, puede ser una víctima potencial.

¿Qué hace una aplicación Vulnerable?

  1. En primer lugar, esta aplicación debe basarse en la tecnología basada en HTML5, es decir, su código (o parte de su código) está escrito en JavaScript. Si la aplicación está escrita usando el lenguaje nativo de la plataforma (por ejemplo Java para Andrid) y Object-C para iOS, es inmune a este tipo de ataques.
  2. En segundo lugar, si existe un canal para la aplicación recibir datos desde afuera. Los datos pueden ser desde fuera del dispositivo (por ejemplo, análisis de código QR) o desde otra aplicación en el mismo dispositivo (por ejemplo, la lista de contacto).
  3. En tercer lugar, la aplicación necesita mostrar la información desde afuera. La elección de las API para mostrar la información es crítica. Algunas API es seguro, pero muchos de ellos no lo son.
¿Cómo funciona el ataque?








No seáis malos.
Suscribirse a: Entradas (Atom)