Incinera tu sitio WEB!

Iniciado por WHK, 28 Julio 2020, 05:04 AM

0 Miembros y 2 Visitantes están viendo este tema.

WHK

Hola a todos!, se me ha ocurrido una buena idea para que todos podamos aprender de seguridad de manera didáctica, real y sin meternos en problemas. La idea es la siguiente:

¿Eres dueño de un sitio WEB?

Haz pasar por el fuego a tu sitio WEB!



Danos la oportunidad de revisar la seguridad de tu sitio entregandonos de manera voluntaria la URL, claramente debes ser el dueño y para asegurarnos de ello debes crear un registro TXT en tu dominio con la palabra "elhacker.net", si lo haces, entonces entre los mismos usuarios del foro le daremos un vistazo a tu sitio web y eso nos permitrá intercambiar ideas y técnicas para aprender mutuamente, y de pasada podrás corregir tus vulnerabilidades antes de que alguien más las encuentre y las aproveche para un ataque real no controlado.


¿Quieres ser el Pentester?

O para los que no conozcan el término: El atacante.



Sólo se pide algo de sentido común, acá la idea no es botar un sitio o hacerle daño, la idea es demostrar una vulnerabilidad, publicarlo en este mismo hilo y demostrar como lo hizo. Asi que:

- No se permiten ataques DOS ni DDOS ni nada que indisponga al sitio WEB.
- No se permite robar información de la base de datos.
- No se deben modificar archivos o datos de la db.
- La vulnerabilidad debe ser comprobable más que teórica.
- Publicar vulnerabilidades reales, nada de que le faltan cabeceras x frame options y basuras similares.
- Solo se debe revisar mientras exista el registro TXT en su dominio.

Cómo revisar si el dominio contiene el registro TXT correcto?: Desde el bash se debe ejecutar:

$ dig -t txt dominio.com

Si usas windows puedes usar la PowerShell:

PS> Get-Dns -Name dominio.com -Type TXT


¿Reglas?

Se vale todo, menos afectar la integridad o privacidad del mismo sitio. Esto quiere decir que no solo debemos restringirnos a una revisión web, tambien se vale revisar subdominios, puertos, etc, todo aquello que sirva para poder llegar al sitio WEB en cuestión (si, incluyendo la del proveedor de hosting).


¿Entregables?

Vamos, esto es un foro, el que quiera puede publicar sus hallazgos en un simple post o puede hacer un pdf a modo de informe, todo dependerá de quien lo haga, acá no hay un "esperable" o un "entregable", eso depende de cada uno.

De todas maneras, si se recomienda poder dar posibles soluciones por cada vulnerabilidad que encuentre (dentro de lo posible).





Vamos, esto es bien fácil, si tienes un sitio WEB permítenos que le demos un vistazo, eso es todo y los que lo revisemos podremos aplicar técnicas reales sobre sistemas reales. Muchas veces nos encontramos con CTF que no reflejan la realidad o solo debes estar adivinando cosas, la idea es poder ganar experiencia real en sistemas reales con vulnerabilidades reales.

Alguien se apunta?, solo basta con entregar su URL y agregar el registro TXT, si el dominio no tiene el registro TXT entonces abtenerse de revisarlo porque puede que realmente no sea el dueño del sitio WEB.

Drakaris

#1
Me gusta la idea! He desarrollado mi web hace un tiempo y tengo curiosidad de que vulnerabilidades tengo.

Este sitio web esta hospeado en 260MB la url es https://cleanet.260mb.net
TXT: https://cleanet.260mb.net/hackme.txt
Lo increible, no es lo que ves, sino como es

kub0x

Cita de: Drakaris en 28 Julio 2020, 10:45 AM
Este sitio web esta hospeado en 260MB la url es https://cleanet.260mb.net
TXT: https://cleanet.260mb.net/hackme.txt

Un .txt no es válido, sino que el DNS debe contener la palabra elhacker.net en el registro TXT. Al estar hosteado en 260MB supongo que no podrás cambiar esa información.

Saludos.
Viejos siempre viejos,
Ellos tienen el poder,
Y la juventud,
¡En el ataúd! Criaturas Al poder.

Visita mi perfil en ResearchGate


Drakaris

Cita de: kub0x en 28 Julio 2020, 16:44 PM
Un .txt no es válido, sino que el DNS debe contener la palabra elhacker.net en el registro TXT. Al estar hosteado en 260MB supongo que no podrás cambiar esa información.

Saludos.
Ahh! Entiendo... En este caso no puedo porque tendría que tocar el servidor DNS... Y poner la siguiente regla por ejemplo:

cleanet        IN        TXT        elhacker

Tendría que hacer algo así?
Lo increible, no es lo que ves, sino como es

WHK

#4
CitarEste sitio web esta hospeado en 260MB la url es https://cleanet.260mb.net
TXT: https://cleanet.260mb.net/hackme.txt

Bien, claramente no podrá crear un registro TXT en su subdominio porque es un hosting por subdominios, asi que no podrá crear el registro. Creo que de todas maneras en estos casos si valdrá un archivo .txt.

El sitio WEB es casi en su totalidad estático y casi no tiene secciones, asi que es muy poco lo que se puede revisar, a demás, es un hosting compartido asi que tampoco se puede hacer mucho a su infraestructura, pero, si tiene un formulario de contacto.

Pude ver dos acciones distintas en el sitio WEB, uno encargado de hacer el envío del mensaje de contacto y otro para cambiar el lenguaje, extrañamente cuando quieres cambiar el lenguaje a un lenguaje inexistente la pagina web se muestra en blanco en ves de arrojar un error o simplemente mostrar un lenguaje por defecto, supongo que efectivamente hay un error pero errors_display está deshabilitado desde php.

El formulario de contacto tiene un problema, actualmente para enviar un correo debes resolver un valor en AES y luego enviarlo a traves de una cookie, muy ingenioso ya que te exije tener habilitado javascript, pero esto no evita bots. La validación del lado de PHP es estática, asi que en la práctica da igual si utilizas el valor de AES del momento o uno que ya haya sido utilizado, el servicio te arroja un estado de "enviado" cada ves que reenvías la misma solicitud utilizando el mismo hash en AES:

Probando sin la cookie:

ncat --ssl --crlf -v cleanet.260mb.net 443

POST /email.php HTTP/1.1
Host: cleanet.260mb.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: */*
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 36
Origin: https://cleanet.260mb.net
Connection: Close
Referer: https://cleanet.260mb.net/

asunto=test&mensaje=test&anonimo=on


Respuesta del servidor:

<html><body><script type="text/javascript" src="/aes.js" >
</script><script>function toNumbers(d){var e=[];
d.replace(/(..)/g,function(d){e.push(parseInt(d,16))});
return e}function toHex(){for(var d=[],d=1==arguments.length&&
arguments[0].constructor==Array?arguments[0]:arguments,e="",
f=0;f<d.length;f++)e+=(16>d[f]?"0":"")+d[f].toString(16);
return e.toLowerCase()}var a=toNumbers("f655ba9d09a112d4968c63579db590b4"),
b=toNumbers("98344c2eee86c3994890592585b49f80"),
c=toNumbers("03b479870acf0ba0ff959ab28fb1dfe9");document.cookie="__test="+toHex(slowAES.decrypt(c,2,a,b))+";
expires=Thu, 31-Dec-37 23:55:55 GMT; path=/";
location.href="https://cleanet.260mb.net/email.php?i=1";</script>
<noscript>This site requires javascript to work, please enable
javascript in your browser or use a browser with javascript support</noscript>
</body></html>


Probando con una cookie estática múltiples veces:

ncat --ssl --crlf -v cleanet.260mb.net 443

POST /email.php HTTP/1.1
Host: cleanet.260mb.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: */*
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 36
Origin: https://cleanet.260mb.net
Connection: Close
Referer: https://cleanet.260mb.net/
Cookie: __test=17544cb0f7e91786eec69621b893d683;

asunto=test&mensaje=test&anonimo=on


HTTP/1.1 200 OK
Server: nginx
Date: Tue, 28 Jul 2020 19:00:38 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: close
Vary: Accept-Encoding
Cache-Control: max-age=0
Expires: Tue, 28 Jul 2020 19:00:36 GMT

4
sent
0


Ok, este hash de la cookie la he reutilizado varias veces y el servidor me sigue diciendo que el mensaje ha sido enviado, asi que esto puede provocar un abuso del servicio.

No se sabe exactamente si PHP del lado del servidor hace el envío de un correo o almacena los mensajes en un txt, pero si se envían correos a traves de la función mail() entonces hay un problema serio y es que el envío masivo de correos puede provocar que caigas en listas negras o den de baja tu hosting y termines con tu sitio web abajo.

También intenté verificar si el formulario de correos tiene inyección de cabeceras:

asunto=test%0a%0cReply-To:%20test@demo.com&mensaje=test%0a%0a.%0a&anonimo=on

Ya que mail() de php adjunta las cabeceras de manera plana separadas por saltos de línea \r\n, pero no se si realmente funcionó porque no puedo hacer que me llegue una copia del correo, asi que podrías validar tu mismo, si realiza el filtrado de saltos de línea o no.

También pude ver un directory listing: https://cleanet.260mb.net/lang/ , esto no causa ningún problema, pero si puede dar problemas serios si tienes algún directorio oculto que no esté protegido, por ejemplo, alguna carpeta donde almacenes los mensajes del formulario de contacto o algún plugin de php de terceros que pueda ser llamado de manera directa, como por ejemplo: https://cleanet.260mb.net/plugins/PHPMailer-master/src/

Saludos.

@XSStringManolo

https://phishingoda.ga/hackme.txt

Le añadí un easter egg por si no tiene vulnerabilidades reales.

BloodSharp

#6
Cita de: @XSStringManolo en 29 Julio 2020, 02:35 AMLe añadí un easter egg por si no tiene vulnerabilidades reales.

Cita de: BannerHTTP/1.1 200 OK
Date: Sun, 12 Jul 2020 22:01:11 GMT
Server: Apache/2.4.38 (Debian)
h4x0r: what are you looking for?
Content-Length: 0
Content-Type: text/html; charset=UTF-8

;-) :laugh: :xD

Por otro lado el servidor donde está hosteado tiene 6 CVE potenciales del 2019...


B#



Drakaris

Cita de: WHK en 28 Julio 2020, 21:19 PM
El formulario de contacto tiene un problema, actualmente para enviar un correo debes resolver un valor en AES.
Buenas no entiendo, que es un valor en AES, yo programé el envio de correo gracias a PHPMailer

Cita de: WHK
Ok, este hash de la cookie la he reutilizado varias veces y el servidor me sigue diciendo que el mensaje ha sido enviado, asi que esto puede provocar un abuso del servicio.
Con esto te refieres a que, un cliente puede escribir un mensaje enviarlo, y enviar este mensaje, sin cambiarlo, tantas veces como quiera? O a que te refieres? Y con el mismo hash AES?

Cita de: WHK
También pude ver un directory listing: https://cleanet.260mb.net/lang/ , esto no causa ningún problema, pero si puede dar problemas serios si tienes algún directorio oculto que no esté protegido, por ejemplo, alguna carpeta donde almacenes los mensajes del formulario de contacto o algún plugin de php de terceros que pueda ser llamado de manera directa, como por ejemplo: https://cleanet.260mb.net/plugins/PHPMailer-master/src/
Ok, esto ya lo solucioné, inserté en un archivo .htaccess la siguiente linea:
Options -Indexes
Así ya cuando accedes a la url https://cleanet.260mb.net/lang/ te arrojará un errro 403
Lo increible, no es lo que ves, sino como es

@XSStringManolo

Cita de: BloodSharp en 29 Julio 2020, 03:32 AM
;-) :laugh: :xD

Por otro lado el servidor donde está hosteado tiene 6 CVE potenciales del 2019...


B#
Cuales? Supongo que lo has mirado con un scanner auto que te avisa de vulnerabilidades de software opcional.

Shell Root

Cita de: Drakaris en 29 Julio 2020, 13:10 PMBuenas no entiendo, que es un valor en AES, yo programé el envio de correo gracias a PHPMailer
Tipo de encryptación.

Cita de: Drakaris en 29 Julio 2020, 13:10 PMCon esto te refieres a que, un cliente puede escribir un mensaje enviarlo, y enviar este mensaje, sin cambiarlo, tantas veces como quiera? O a que te refieres? Y con el mismo hash AES?
Se supone que cada petición debe de validar un hash diferente, algo como Tokens CSRF, en cada petición cambia el token y debe de validarse así se evita automatización de peticiones. Corrigeme si estoy mal WHK!
Por eso no duermo, por si tras mi ventana hay un cuervo. Cuelgo de hilos sueltos sabiendo que hay veneno en el aire.