Fuzzing Server Side Includes (SSI)
Cuando hacemos una auditoría de seguridad a un sitio web, y según la OWASP, una de las pruebas a realizar son los ataques de fuzzing. Éstos pueden ir desde la típica búsqueda de directorios ocultos en el servidor hasta la validación de parámetros de entrada usando diccionarios.
Haciendo uso de estos últimos podemos conseguir multitud de información útil, e incluso muchas veces podemos hacer nuestro ataque a un SLQ Injection de “estar por casa”.
Reemplazo de Milw0rm
Milw0rm parece que ya tiene reemplazo.
La gente de offensive-security ha creado Explo.it. Este repositorio que mantiene el formato de Milw0rm, con secciones como "papers" o "shellcode", pero mejora las búsquedas. Añadiendo como opciones de búsqueda el puerto o plataforma entre otras.
Para empezar a utilizarlo cuanto antes hemos creado este "plugin":
+info
TLS Renegotiation Indication Extension
Marsh Ray y Steve Dispensa han hecho pública la versión 1.1 del documento donde presentan un ataque MiTM basado en la renegociación TLS. En el comienzo del documento podemos leer:
There are three general attacks against HTTPS discussed here, each with slightly
different characteristics, all of which yield the same result: the attacker is able to
execute an HTTP transaction of his choice, authenticated by a legitimate user (the
victim of the MITM attack)
Esta versión del documento se ha traducido en un borrador de IETF:
Internet draft "Transport Layer Security (TLS) Renegotiation Indication Extension"
TLS [RFC5246] allows either the client or the server to initiate renegotiation--a new handshake which establishes new cryptographic parameters. Unfortunately, although the new handshake is carried out over the protected channel established by the original handshake, there is no cryptographic connection between the two. This creates the opportunity for an attack in which the attacker who can intercept a client's transport layer connection can inject traffic of his own as a prefix to the client's interaction with the server. [...] This attack can be prevented by cryptographically binding renegotiation handshakes to the enclosing TLS channel, thus allowing the server to differentiate renegotiation from initial negotiation, as well as preventing renegotiations from being spliced in between connections. An attempt by an attacker to inject himself as described above will result in a mismatch of the extension and can
UPDATE:
Actualización para OpenSSL
Nov 5 17:20:01 2009 openssl-0.9.8l.tar.gz (MD5) (SHA1) (PGP sign) [LATEST]
OpenSSL CHANGES
_______________Changes between 0.9.8k and 0.9.8l [5 Nov 2009]
*) Disable renegotiation completely - this fixes a severe security
problem (CVE-2009-3555) at the cost of breaking all
renegotiation. Renegotiation can be re-enabled by setting
SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in s3->flags at
run-time. This is really not recommended unless you know what
you're doing.
[Ben Laurie]
Más información en los siguientes enlaces
http://extendedsubset.com/?p=8
http://www.links.org/?p=780
http://sunbeltblog.blogspot.com/2009/11/man-in-middle-attack-uses-ssl.html
http://www.hispasec.com/unaaldia/4030
http://www2.packetstormsecurity.org/cgi-bin/search/search.cgi?searchvalue=renegotiating+tls
Prueba de concepto del ataque: http://packetstormsecurity.org/0911-exploits/ssl-mitm.c
El exploit mas sencillo del mundo
Hola a tod@s,
Buscando por la red, me encuentro con muchas y variadas formas hacer un DoS en sistemas *NIX por sobrecarga u "override".
Hay mucha información al respecto en la red pero, sin lugar a dudas, el que más me ha llamado la atención, por su simplicidad, es el siguiente:
: ( ) { : | : & } ; : (Eliminar los espacios entre símbolos)
Con este comando le decimos a *NIX, explicado a groso modo, que empiece a crear procesos de forma infinita. Obviamente las listas de procesos, planificadores, etc etc etc del sistema se llenaran y en un momento dado dejará de responder.
Si bien es cierto que es necesario el acceso a una shell del sistema para poder ser ejecutado, una vez conseguida (por los medios que sean) se pone de manifiesto que no es necesario elaborados programas para causar una denegación de servicio.
Para evitar estos ataques es necesario tomar ciertas medidas de seguridad para cuando un proceso se desboque, de forma involuntaria o no, no inutilice el resto del sistema ni perjudique al resto de usuarios, si hablamos de un sistema compartido.
Merece la pena probar este pequeño comando. Eso si, aseguraos que no estais haciendo nada que os pueda hacer perder información y, muy importante, no lo hagais en un sistema que no sea vuestro.
Intetaré publicar un post sobre como evitar este tipo de ataques.
¿Comentarios, dudas, sugerencias...?
0pen0wn
OpenOwn es el nombre del que puede ser un exploit para SSH. En el blog de isc.sans.org ha publicado correos anónimos asegurando su existencia, trazas de la ejecución del mismo y al parecer el movimiento "antisec" está detrás de todo.
La traza del ataque:
anti-sec:~/pwn# cd xpl/
anti-sec:~/pwn/xpl# ./0pen0wn -h xx.yy.143.133 -p 22
[+] 0wn0wn – anti-sec group
[+] Target: xx.yy.143.133
[+] SSH Port: 22
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>]
sh-3.2# export HISTFILE=/dev/null
sh-3.2# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
sh-3.2# uname -a
Linux xx.yy.net 2.6.24.5-grsec-hostnoc-4.0.0-x86_64-libata
#1 SMP Mon Aug 25 15:56:12 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
En una segunda actualización muestran el contenido de un e-mail donde se dan algunos detalles/explicaciones sobre el exploit. Según este informador el exploit no funciona sobre las versiones actuales de SSH y se hará público antes de BH/DC:
Expect the SSH exploit to be made public before BH/DC. I have proof that I can't share (sorry), that this exploit does exist, does not work against current versions of SSH, and is actively being used by members of the anti-sec movement.
Muy bien, todo perfecto. Con misterio y conspiraciones de por medio.
Pero a mí me surgen unas dudas.
- ¿Cómo es que se publica esta entrada en el blog de Sans.org el día 7 de julio (Published: 2009-07-07) y la supuesta traza es de Agosto de 2008? (Mon Aug 25 15:56:12 EDT 2008)
- ¿Cuando en la entrada de Sans.org dice "here is an anonymous email we received today" se refiere al 7 de Julio de 2009 como pone en la fecha de publicación de la entrada?
- ¿Por qué habla el informador anónimo del BH/DC en futuro si en realidad es pasado? (¿Black-Hat DC no se celebró en Febrero?) ¿Se refiere al del año 2010? además...
- ¿Cómo puede ser que solamente tengamos 10 entradas en google sobre OpenOwn?
Sea como fuere, esto resulta hasta divertido!
ACTUALIZACIÓN / UPDATE
Ayer (14/07/09) se publicó el código fuente de este exploit. En algunos blog podemos ver el análisis del código. Al parecer contiene en el shellcode el comando rm por tanto, mucho cuidad con las pruebas que hagais del mismo.
Os dejo los enlaces:
http://blog.zoller.lu/2009/07/0pen0wnc-shellcode-dissasembled.html
http://blogs.securiteam.com/index.php/archives/1302
[OpenSSH Rumors by Marcus Sachs sans.org]