No estaba muerto... ¡estaba de parranda!

Decidido a pillar cacho en las mejores discotecas de España, nada como echar un buen vistazo al percal que cada región nos brinda. Y es que las fotos cuando estamos de parranda, dicen mucho... posiblemente más de lo que deberían.

Fui directo a la conocida página de PubyFiesta, conocida para aquellos que lingotazo en mano, pasan el fin de semana rodeados de escandalosa música y mujeres que poco o nunca, cenan antes de salir de fiesta, que como mariposas revolotean alrededor de los fotógrafos, esperando exhibirse de forma aceptable en alguna foto, mientras preparan poses con cara de otras.

En mi paseo matutino, mientras jugaba a encontrar las diferencias entre las auténticas, y las menos maquilladas, no podía dejar escarpar algún que otro Cross Site Scripting, por aquello tan ignorado como un robo de cookies. Nada más directo que algo de publicidad para el blog, que nunca viene mal.

http://www.pubyfiesta.com/embedding/image.php?image=0003457011%22%3E%3Cscript%3Ealert%288%29%3C/script%3E

http://www.pubyfiesta.com/embedding/agenda.php?image=0000233443%22%3E%3Cscript%3Ealert%288%29%3C/script%3E

O recordar la técnica del redirects, que en este caso, no restringe ningún tipo de URL y nos permite utilizarla con un poco de imaginación, para mostrar a los menos precavidos, posibles enlaces infectados de malware.

http://www.pubyfiesta.com/redirekt.php?url=www.enelpc.com

Pero sin duda, llegué a pasarme el reto personal en modo Hardcore, cuando encontré una ruta y varios ficheros que prefiero omitir, donde un Directory Transversal, explotaba en añicos la web.

Entre tanto salieron cosas feas, tales como infinidad de cuentas en el fichero group o passwd. Shadow se escondía protegido contra lectura, salvo para usuario root.

Algún fichero llamativo, con el nombre de las compilaciones para determinar el sistema a atacar, que luego con un simple error forzado desde el puerto 80 saldría como CentOS.

Un Index.php me llevaría hasta el fichero de configuración de la conexión a MySQL.

Tiré al puerto con MySQL Administrator, antes de probar nmap y me sorprendí bastante...

El registro de Realtime, donde duermen las DNS.

El panel de administración Plesk del servidor.

La cuenta SMTP para envío de correos.

Envío de SMS a móviles de clientes, utilizando APIS de servidores externos.

Y alguna que otra cosa que prefiero no mostrar, por no hacer de esta entrada una carnicería...

Más tarde me daría cuenta de la posible masacre, buscando en Google, algo así como:

intext:"Powered by OcioUno"

Pues dicha empresa de desarrollo web, envuelve una estructura idéntica para multitud de dominios orientados a salas de fiesta.

Espero que no sean malos, y tan solo utilicen esto que redacto aún siendo subido de tono, para leer y empaparse de aquello que tenemos detrás de la pantalla...

Saludos 4n4les! ;)

XSS + Spoofing IP + XFF = BOOM!

Pasar demasiado tiempo en el pc, según los médicos, aumenta la fatiga visual y además puede provocar problemas visuales permanentes. Pero de lo que los médicos no quieren hablar, es de que pasar demasiado tiempo enelpc, además aumenta de forma alarmante, la paranoica visual al visitar determinados dominios vulnerables.

Si os muestro el siguiente ejemplo:

http://enelpc.com/index.php?id=1

Os imagino como auténticos posesos probando inyecciones de todo tipo, hasta que nos devuelva el tan esperado error, y así terminar diciéndonos a nosotros mismos ¡Genial! ¡lo he conseguido! ¿y ahora qué? ¿Brazzers?

Pues bien, la entrada de hoy, se me ocurrió con una de mis fantásticas tardes como desarrollador sobre PHP (no sé programar, pero Google sí). Así que la aplicación no era más que, un error 403 que recogiese la IP, la fecha, la hora y el navegador desde el que se realizaba el ataque.

Supongamos que un tipo muy malo ataca mi servidor con una denegación de servicio, Mod Evasive le enviará a un 403 y que por otro lado tiene un delay en cada petición tras unos 10 proxys con los que consigue seguir atacando a mi sistema, con lo que cada intercepción del ataque por parte de Mod Security, irán destinados al mismo 403.

Yo soy un administrador manco como la mayoría, y el único log al que acudir, es el creado por dicha aplicación... ¡sí! ¡Ya sé que access y error log también existen! ¡Pero hoy soy humano como un administrador descuidado! Así que si inserto en el código la variable de entorno REMOTE_ADDR, devolverá la IP del visitante pero... ¿Es la real? La única forma de saber que no se encuentra detrás de un proxy, sería incorporando otra variable llamada HTTP_X_FORWARDED_FOR.

Hasta este punto todo nos parece genial ¡vamos a capturar la IP real que se encuentra detrás del Proxy del Hacker! Pero se nos olvida una cosa... ¿Como el proxy transporta la IP real? Pues bien, la única forma es en el Header de la petición y como todos sabemos, los Headers son modificables.

Si se produce un IP Spoofing en la petición, al ocupar el espacio de X Forwarded For, la IP real pasaría a ser la de proxy y la spoofeada en primer lugar. Intenté un simple tag script y este es el resultado:

Al no filtrar correctamente la variable recogida del Header, la escribe directamente al código y la interpreta. Algo similar ocurre con la cabecera Referer, la cual también es vulnerable a inyecciones si esta no se encuentra filtrada correctamente.

Para la corrección, programé nada más simple que una función que filtrase lo mostrado en el echo, que viniese directamente de la variable vulnerable.

De esta forma, nos libraríamos de los ataques de script.

Ataques.log, me quedó así de bonito con el parser :)

Y no pude evitar probar el fallo, en los famosos dominios españoles que facilitan nuestra IP pública, como Vermiip.

O miip.

Aunque aquí nadie se salva y See-my-ip, también se lo traga.

Si el tema de scripts, te dejó insatisfecho, siempre puedes navegar spoofeando la IP real a enviar a un proxy ruidoso, y asegurarte aun más la anonimidad en la red. Firefox no podía ser menos, y cuenta con un par de plugins públicos que facilitan el trabajo.

https://addons.mozilla.org/en-US/firefox/addon/x-forwarded-for-spoofer/eula/36927?src=dp-btn-primary

https://addons.mozilla.org/en-US/firefox/addon/x-forwarded-for-spoofer-242700/

También podremos usar un simple modificador de cabeceras y agregar nuestro X-FORWARDED-FOR predeterminado.

https://addons.mozilla.org/en-US/firefox/addon/modify-headers/eula/24052

Hijo... ¡no hagas maldades por ahí fuera!
¡No mama! Hoy me quedo estudiando enelpc...

Saludos 4n4les! ;)

¿Ataques DDos automatizados?

Debo de ser aficionado a meter los Ddos en los lugares más recónditos enelpc y fuera de él, pues de casualidad llegué de nuevo, a una sentencia vulnerable en el mundo de las aulas virtuales. Anteriormente ya publiqué algo similar en esta entrada, aunque esta vez, el fallo se encuentra en un algoritmo creado para dar el refresco de actualización, a las ventanas de Chat que reciben los mensajes dentro de la conocida plataforma Moodle.

El contador de espera, que recoge la variable “&wait=”, tiene una peculiar forma de ir aumentando su tasa de refresco, según aumenta a su vez los segundos a la espera. La URL es la siguiente:

http://Dominio.com/Moodle/message/refresh.php?id=1&name=enelpc.com&wait=1

 

A su vez el campo “&name=”, rescata el nombre de usuario de la base de datos que contiene mensajes nuevos.

Me llamó la atención ver como la tasa de refresco, se incrementaba con no demasiada lógica, pues la variable “&wait=”, mostraba la siguiente secuencia de números.

&wait=1, &wait=3, &wait=4, &wait=5, &wait=6, &wait=8, &wait=10, &wait=12, &wait=15, &wait=18, &wait=22, &wait=27, &wait=33...

¿Qué cojones está pasando? ¿No saben sumar 1 y evitan problemas?

Así que no dudé dos veces en acceder a través del Terminal Service, para leer el dichoso PHP que creaba este comportamiento.

Refresh.php me contaba lo siguiente:

**************************************************************************
            if ($wait < 300) {                     // Until the wait is five minutes 

$wait = ceil(1.2 * (float)$wait);  // Exponential growth
**************************************************************************

 

Obviamente, solo me tenía que centrar en esta línea.

********************************************************

$wait = ceil(1.2 * (float)$wait);  // Exponential growth
********************************************************

La función ceil en php, devuelve el siguiente valor entero mayor, redondeando el valor si es necesario, así que si el resultado es por ejemplo 1,2 aun siendo más lógico redondear al valor menor, se transformaría a ser un 2.

Realmente la práctica es mucho más sencilla que el trabalenguas que os acabo de explicar, así que para entender el algoritmo mejor, veamos un ejemplo:

1
1*1,2 = 1,2 ->2
2*1,2 = 2,4 ->3
3*1,2 = 3,6 ->4
4*1,2 = 4,8 ->5
5*1,2 = 6 ->6
6*1,2 = 7,2 ->8
8*1,2 = 9,6 ->10
10*1,2 = 12 -> 12
12*1,2 = 14,4 ->15
15*1,2 = 18 -> 18
18*1,2 = 21,6 -> 22
22*1,2 =26,4 -> 27
27*1,2 = 32,4 -> 33
33...

 

Hasta aquí todo perfecto, el valor se incrementa constantemente, y nunca tiene el motivo de llevar a error.

¿Pero que número es el único que multiplicado por 1,2 consiga un comportamiento anómalo?

0

0*1,2 = 0 -> 0 (Cada cero segundos repite su ejecución) Cero por cualquier número es igual a cero.

El redondeo lleva a un número entero mayor que -1 y menor que 1, del cual no se puede esperar una tasa de refresco con incremento, así que las peticiones que este conlleva al servidor, se ahogan en continuos e infinitos GET.

Llevemos a la práctica mi teoría, mientras Tamper Data hace el trabajo sucio.

En intervalos de imperceptibles milisegundos, se lleva a cabo innumerables peticiones GET que el servidor no tiene más remedio que contestar, así incrementando el tráfico hasta poder llegar a colapsarlo sin necesidad de otro software que automatice la tarea, a lo que están acostumbrados nuestros amigos Anonymous.

Con esto no solo disminuiremos la velocidad para responder peticiones del servidor, si no también sus recursos entre otras cosas, porque estamos haciendo conexiones directamente a la base de datos, para recuperar el nombre de usuario y leer las tablas.

Así que desde la parte servidor nos encontraremos con este panorama:

Seguro más de un administrador, se volvería loco al ver tantas peticiones desde su localhost, siendo estas invocadas por el archivo refresh.php, hacia el puerto 3306, o más bien el utilizado por defecto en MySQL. Todo esto incluso podría llegar a Crashear la tabla de la base de datos, como alguna vez pasó con indetectables y algún listillo que dentro de poco se verá acusado por posesión de Botnets.

Por otro lado el FIX para las versiones de Moodle, sería tan simple como agregar un “if”. Si el valor es menor a 1, que devuelva 1, de esta forma conseguiremos que el algoritmo creado por los desarrolladores del proyecto, no pudiese ser modificado a manos de terceros.

Para aquellos que quieran corregir el archivo o simplemente sean tan despiadadamente paranoicos como Germán, en este tema de la seguridad, ya saben lo que deben de hacer.

Saludos 4n4les! ;)