Inyección en códigos de barras y QR
Interceptando comunicaciones web cifradas (I)
Mostramos a continuación un ejemplo muy sencillo y rápido de como llevar una ataque de spoofing en una LAN. Con él conseguiremos ver todo el tráfico del usuario atacado en tiempo real, a partir de un archivo donde volcaremos esa información y en pantalla. Para llevar a cabo el ataque todos los comandos tienen que ser ejecutados con derechos de administrador.
- Nos aseguramos que tenemos instalado el software necesario: openssl y la suite dsniff
- Generamos nuestro certificado. No voy a explicar como, hay millones de howto por ahí.
- Conseguimos que nos lo firme un CA Válido y confiable. Esto es lo difícil. Necesitamos dinero o:
(a) Que nos lo firme entidades que no nos cobran (http://cert.startcom.org/ , http://www.cacert.org/). El problemas de estos CA es que los navegadores no se suelen fiar mucho de ello.
(b) Podemos hacer que nos los firmen entidades confiables. Esto normalmente cuesta dinero (y mucho), pero muchas de ellas te lo firman, como una versión de prueba podríamos decir, para 30 días. Para nuestros propósitos nos sobra. Un ejemplo de entidades que hacen esto puede ser: http://www.rapidssl.com/ssl-certificate-products/free-ssl/freessl.htm
- Antes de seguir tentemos que activar el forwarding:
echo "1" > /proc/sys/net/ipv4/ip_forward
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”.
Posible fallo en Vodafone Club 2020
El nuevo servicio de Vodafone (Club 2020) ofrece regalos (sms por lo general) a cambio de que recibas publicidad de diferentes categorías.
En un intento de automatizar el uso del servicio (después de conseguir mediante el "rasca y gana" 20 sms gratuitos) encontramos un posible fallo que permite el envio de mensajes de una forma algo "tosca" pero que puede suponer un problema, tanto para el operador como para los usuarios.
Por lo que parece, comentandolo con compañeros, cuando se realiza una petición sobre el servicio sin incluir un usuario concreto no se realiza una validación previa y la 'base de datos' devuelve los datos del usuario al que en ese momento este apuntando. Lo que permite el envio del mensaje de forma gratuita al destinatario indicado en caso de que el usuario tenga mensajes en su cuenta.
Después de ponernos en contacto con Vodafone y obtener como respuesta: "No tenemos detectada ninguna incidencia del tipo que nos comenta. Si persiste la incidencia contacte con el 123". Hemos decido publicar esta entrada con el objetivo de alertar a los usuarios del servicio, ya que estan expuestos a un posible ataque.
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