La URL vulnerable es http://tvndeportes.cl/intersitial/index.html?link=, a “link” podemos asignarle cualquier URL y el navegador será redireccionado a esa URL. Por ejemplo:

http://tvndeportes.cl/intersitial/index.html?link=http://sitio.webmaligno.com/pics/pics.exe

Quizá este método solo nos permita redireccionar a un usuario y nada mas, pero con un poco de imaginación y trabajo, perfectamente ese usuario podría ser engañado por email para ingresar a un sitio confiable de TVN y redirigirlo a un sitio de streaming falso, donde le haga aceptar la descarga de un archivo (troyano) para que pueda ver el video. Aprovechandose de todo esto del mundial, la locura por ver los partidos en alta definicion, perfectamente un atacante podría insitar a un usuario a descargar un programa para poder ver el partido, desde el sitio de tvn, en alta definición y gratis, obviamente “ese” programa sería un virus o algo similar.

Compartir/Guardar

Generalmente los criterios para asignar accesos a los distintos sistemas es los mismos, existen las que son aleatorias con y sin patrones, las típicas “dos letras iniciales del apellido seguido del año de nacimiento”, etc. Quizá el problema no está en asignarles claves por defecto fáciles a los usuarios, sino en los mismos usuarios que no las cambian o bien tardan una eternidad en ingresar por primera vez al sistema. Por esto mismo, pienso que la seguridad de los sistemas no debe depende de los usuarios, debe depender del sistema, a menos que tengamos muy acotado el tipo de usuarios que tendrá el sistema.
En este post hablaré sobre los tipicos accesos a universidades, cuentas de correo de empresas, cuentas de servidores ftp, ssh, web, etc.

En primer lugar, pienso que, el hecho de querer facilitarle las cosas al usuario final asignandole una password que sea “recordable”, es riesgoso. El hecho de que una password siga un patrón quiere decir que es altamente descifrable o descubrible por un atacante. Como patrónoes entendemos password como:

• usuarioYYYY: donde YYYY puede ser el año de nacimiento, el año que la persona ingreso a la institución u otra cosa que tenga relación.
• Primeros o últimos 3 o 4 digitos del rut: Por ejemplo si el rut de una persona es 6.714.870-9, la clave podría ser 6714 o bien 8709
• Nombre de usuario: aunque no lo crean, es muy comun tambien que se asigne como contraseña lo mismo que le entregan como nombre de usuario
• Juego con las iniciales de los nombres y/o apellidos y año de nacimiento o año de ingreso: Por ejemplo, para Juan Perez, una posible password sería jperez2009, juanp2009, jp2010, etc.

Quiza lo que acaban de leer pareciera ser algo muy estúpico o algo demasiado básico, pero es increible que suceda. Hace un par de semanas publiqué dos ejemplos muy claros al respecto, lo pueden ver en:

La poca importancia de la seguridad en la Universidad Mayor
Seguridad en accesos de ex alumnos del Instituto Profesional CIISA

El hecho de saber un patrón de asignaciones de contraseñas por defecto de una empresa o alguna institución les abre una puerta trasera enorme y, a mi criterio, es una vulnerabilidad que debe ser considerada critica si se desea proteger el robo de información y la privacidad de la institución y de los mismos usuarios.

La contraseña de un usuario puede comprometer el acceso a otros usuarios, por ejemplo si mi password por defecto corresponde a la primera inicial de mi nombre, seguido de mi apellido, luego un guión bajo (_) y finalmente mi año de nacimiento y es interceptada por algun atacante, sea como sea, independiente de que esa persona haya querido atacarme a mi o independiende de que si yo tengo informacion privada o si me interesa la seguridad o no, estoy dando el paso para que esa pesona pueda adivinar contraseñas de las demas personas.

Un caso muy comun es el hecho que cuando una persona ingresa a trabajar a una empresa generalmente le preparan un computador con todo listo, su cuenta de correo lista, configurada y lista para usarse por lo que el usuario jamás tendrá curiosidad de cambiarla, asi mismo todos o la gran mayoría de la empresa. Una persona sin muchos conocimientos podría probar el mismo patrón de contraseñas para ingresar como su compañero de trabajo, luego que ingresa al correo de esa persona exitosamente, lo gracioso sería intentar ingresar a otras cuentas por ejemplo al sistema de tickets u otros sistemas con el que podríamos hacer más daño. Según mi punto de vista, las contraseñas por defecto deberían ser por defecto aleatorias y obligar a que el usuario se loguee apenas es creada la cuenta y cuando ingrese por primera vez obligarlo a cambiar la contraseña.

Los desarrolladores o administradores pueden quejarse con la típica frase “es que son sistemas que acceder desde la red interna, desde la lan solamente”, pero la verdad es que uno nunca sabe desde que lado esta el atacante.

Aunque no lo crean, muchas veces esas mismas empresas que le asignan esas contraseñas por defecto a sus empleados, lo hacen tambien con sus clientes. Por ejemplo, una empresa de hosting o diseño web, en ambos casos, cuando le quieren dar acceso a ftp o bien acceso a algun sistema para que hagan el “testing”, cumplen el mismo patron, si no es “123456″ es, por lo general, el nombre del cliente. Puedo entender que es engorroso asignar contraseñas tan dificiles de recrodad a los clientes para que hagan simplemente un checkeo de una aplicación, pero aveces la seguridad requiere de un poco de esfuerzo.

Compartir/Guardar

Estimado Fernando:

Me dirijo a usted como representante de la Empresa E-Sign, en mi calidad de Gerente de Operaciones,  para comentarle algunos de los alcances que ha tenido para nosotros el  reporte de vulnerabilidad XSS que usted ha publicado a fines de la semana pasada.  Con su información hemos verificado los errores reportados, y nuestros programadores se encuentran trabajando en la revisión y corrección de otros posibles problemas. Específicamente, aquellos relacionados con el “contacto.php” se corrigieron el 30 de Abril en la tarde.

Le agradecería que, en el caso de detectar una nueva vulnerabilidad o la posibilidad de ella en nuestro sitio, lo informe directamente a mi correo particular o telefónicamente a la empresa. Asimismo, le solicitamos que nos dé un  espacio de tiempo suficiente para corregir el problema, antes de publicarlo en internet.

Finalmente, a nombre de E-Sign, quisiéramos agradecerle su nota y enfatizar que tomaremos todas las medidas necesarias para evitar que este tipo de problemas vuelvan a ocurrir.

Creo que es una buena respuesta y es la forma en que deberían actuar las empresas cuando se les informa sobre algún fallo, bug o vulnerabilidad que los afecta.
Podemos ver que el enlace vulnerable: https://www.e-sign.cl/contacto.php?prefilla=%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E ya no se ve afectado.

Compartir/Guardar

La idea de un sitio con certificado SSL es que toda la información viaje cifrada, pero la gente de E-Sign al parecer no piensan eso. Al menos dos formularios del sitio envían la información sin cifrar, entonces ¿Para qué usan el certificado SSL?

Quizá no es tan crítico, ya que se trata del formulario de contacto y el buscador, pero ya que ellos obligan al usuario a confiar de ellos aun cuando los formularios no se envian de forma segura, nosotros aprovecharemos de generar otro tipo de trafico de manera insegura, por ejemplo insertando un formulario falso o un sitio externo mediante XSS.

¿A qué me refiero con esto? Sencillo, cuando estás navegando en un sitio seguro y en él, existe información que viaja de manera no-segura (sin cifrar), el navegador nos alerta y nos pregunta si queremos continuar.

En cierta forma, E-Sign está obligando al usuario a confiar en ellos y para proceder, el usuario tendrá que poner aceptar. Si ellos lo hacen, ¿por qué nosotros no?

Nos aprovechamos de una vulnerabilidad XSS que presentan algunos links, por ejemplo link de “Contacto”:

https://www.e-sign.cl/contacto.php?prefilla=%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E

Mediante XSS podriamos perfectamente modificar el formulario, agregar y quitar campos y redireccionar la informción hacia otro sitio o bien colocar un iframe externo que nos permita insertar un formulario arbitrario para capturar información que necesitamos.

Con un poco de ingenieria social y un poco del arte del engaño, seguramente podemos explotar aun mas esta vulnerabilidad. Muchas veces la vulnerabilidad va más alla de si misma, depende mucho del sitio sobre el cual se intenta explotar, en este caso, es mucho mas grave que en el caso del post anterior.

Lo que encuentro más problematico, es que una empresa de seguridad, quienes ofrecen un servicio Anti Phishing, tengan este tipo de vulnerabilidades, le resta demasiada credibilidad a la empresa, lamentablemente las personas que contratan estos servicios generalmente no saben mucho del tema y creen que estaran en buenas manos y muchas veces estan cometiendo un error entregando su seguridad a las personas equivocadas.

Como de costumbre, intenté contactarme con los encargados mediante el formulario de contacto del sitio pero no he obtenido ningun tipo de respuesta.

ACTUALIZACIóN – 3/Mayo/2010: La empresa se ha contactado conmigo via email. Más información acá.

Compartir/Guardar

La URL vulnerable es

http://www.wei.cl/catalogue/product_search.htm?ph=&query=

Podemos inyectar código javascript en el valor de la variable “ph” y con esto insertar un frame o algun elemento externo al sitio y hacelo parecer como si fuera del sitio usando la confianza que tienen los clientes, como por ejemplo un iframe o bien un javascript que nos envie la cookie de la sesion a otro sitio.

Prueba de Concepto (PoC)

http://www.wei.cl/catalogue/product_search.htm?ph=%22%3E%3Cscript%3Ealert%28this%29%3C/script%3E&query=+++++Buscar+++++

http://www.wei.cl/catalogue/product_search.htm?ph=%22%3E%3Ciframe%20src=%22http://google.com%22%3E%3C/iframe%3E&query=+++++Buscar+++++

En el sitio se pueden encontrar links de contacto y emails para escribir tipo info@wei.cl, ni los links ni los emails funcionan. Intenté reportar el problema pero el correo que envié al destinatario que en la misma página aparece, me rebotó.

Compartir/Guardar

#!/bin/bash
NETWORK=192.168.1
FROM=100
TO=110
for x in $(seq $FROM $TO)
do
	ping -c 1 $NETWORK.$x >/dev/null 2>&1
	if [ $? -eq 0 ]; then
		echo $NETWORK.$x is up.
	else
		echo $NETWORK.$x is down.
	fi
done

Una vez que tengamos el mapa mental-lógico de la red podemos empezar a analizar el tráfico que pasa por ellas y acá es donde entran en juego los famosos sniffers, que nos ayudarán a reforzar nuestro diagrama:

En informática, un packet sniffer es un programa de captura de las tramas de red.

Existen distintos métodos y herramientas para sniffear y para envenenar la red.

ettercap Ettercap es un interceptor/sniffer/registrador para LANs con switch. Soporta direcciones activas y pasivas de varios protocolos (incluso aquellos cifrados, como SSH y HTTPS). También hace posible la inyección de datos en una conexión establecida y filtrado al vuelo aun manteniendo la conexión sincronizada gracias a su poder para establecer un Ataque Man-in-the-middle(Spoofing). Muchos modos de sniffing fueron implementados para darnos un conjunto de herramientas poderoso y completo de sniffing.

tcpdump es un herramienta en línea de comandos cuya utilidad principal es analizar el tráfico que circula por la red. Permite al usuario capturar y mostrar a tiempo real los paquetes transmitidos y recibidos en la red a la cual el ordenador está conectado. Está escrito por Van Jacobson, Craig Leres, y Steven McCanne que trabajaban en … (más)

wireshark o ethereal La funcionalidad que provee es similar a la de tcpdump, pero añade una interfaz gráfica y muchas opciones de organización y filtrado de información. Así, permite ver todo el tráfico que pasa a través de una red (usualmente una red Ethernet, aunque es compatible con algunas otras) estableciendo la configuración en modo promiscuo. También incluye una versión basada en texto llamada tshark.

(nota: Las definiciones fueron obtenidas desde Wikipedia)

Luego de identificar qué máquinas nos interesan, podemos aplicar la técnica del hombre en el medio (Man In The Middle) o MiTM para capturar información para poder acceder a otros sistemas.

Link: Top 11 Packet Sniffers

Compartir/Guardar

1. Te quedas en el lugar sin tener acceso a wifi
2. Te vas indignado del lugar ya que no te prestaron internet
3. Te quedas en el lugar y te conectas a una red de otro lugar
4. Crackeas la clave y te quedas en el lugar
5. Te vas del lugar, crackeas la red y te vas a otro lugar a conectarte

De las 5, yo prefiero dos de ellas: la 3 y la 5. Generalmente son claves WEP y no te demoras nada en obtener la contraseña. Que te digan que el wifi es solo para los dueños o solo para usos administrativo, te dan más ganas de querer conectarte a intrusear qué hay. Es muy típico que tengan la password del router por defecto (admin/admin), puedes hacer MiTM, etc.
Lo que yo no entiendo, es por qué tienen una red WiFi en los pubs o restaurantes “sólo para usos administrativos”. Ahora viene mi crítica: Si realmente quieren usar una red sólo para usos administrativos conectense por cable de red o al menos protejan las claves de las redes con un cifrado más potente que el WEP. Está bien si entendemos que no toda la gente sabe crackear redes y no todos van a tener el tiempo de hacerlo, de las 1000 personas que visitan el lugar quizá sólo 1 sabe hacerlo, pero basta con una para que te puedan fastidiar, o por último no le pongas el nombre del lugar, lo hacen sólo para llamar la atención (¿publicidad?).
En fín, si voy a un lugar donde SI hay wifi pero no quieren decirme que clave es, entonces la crackeo y de pasada, los fastidio un poco. ¿Cómo los podemos fastidiar?

1. Nos conectamos sea como sea y sólo por molestar, llamamos al garón o camarero y le pedimos que si puede reiniciar el router, por que el internet anda muy lento.
2. Desconectarlos de internet.
3. Nos ponemos frente al dueño o frente a los camareros, con el notebook, dejando en claro que “estoy navegandooooo”
4. Imprimir en un papel la clave de WiFi y pegarla en la entrada

Compartir/Guardar

La semana pasada he descubierto una vulnerabilidad Cross-Site Scripting (XSS) en el sitio web de RedBanc.

Redbanc S.A.. es una empresa que presta servicios de interconexión bancaria, es decir permite a los clientes de todos los bancos asociados realizar distintas operaciones, depósitos, transferencias, giros, etc. a través de una red cajeros automáticos, que son computadores interconectados, permitiéndole al cliente realizar una serie de operaciones que antiguamente se debían realizar en una caja normal y con la restricción del horario.

Está de más decir que con esta vulnerabilidad encontrada es posible realizar phishing, robos de identidad (robos de cookies mediante xss) y muchas otras cosas más relacionadas con estáfas usando la confianza el sitio RedBanc.cl.

La vulnerabilidad se encuentra en la no-validación de los parametros de entrada en la URL http://www.redbanc.cl/portal_redbanc/browse?pagina=portal_redbanc/inicio.htm. Si modificamos la variable “pagina” y preparamos un javascript especialmente para el robo de cookies o bien algun sitio web externo que nos permita hacer phishing, basta con que coloquemos el código necesario y se lo asignemos a la variable.

Explicación

Cuando se cambia el valor de la variable pagina el sistema reportará que la página no existe. El mensaje de error tomará el valor que ingresamos en la variable y lo mostrará de la siguiente forma:
- En el caso de http://www.redbanc.cl/portal_redbanc/browse?pagina=veamos/si/existe/la/pagina.htm podemos ver el mensaje de error

Pagina no existe
Pagina veamos/si/existe/la/pagina.htm no disponible

Si nos damos cuenta, lo que dice justo debajo de “Pagina no existe” es justo lo que pusimos como valor de la variable pagina por lo que asumimos que cualqiuer cosa que pongamos en su lugar será mostrado y por ende si inyectamos un código html éste será mostrado e interpretado por nuestro navegador.

PoC

Inyectando un código javascript:
http://www.redbanc.cl/portal_redbanc/browse?pagina=<script>alert('XSS')</script>

Inyectando un iframe con destino a otro sitio, el cual podría contener un sitio web maligno:
http://www.redbanc.cl/portal_redbanc/browse?pagina=<iframe src=http://sitio.web</iframe></iframe>

(más información sobre este último punto en: Haciendo phishing explotando una vulnerabilidad XSS)

He intentado contactarme con los encargados del desarrollo del sitio pero no he obtenido respuesta. El formulario de contacto del mismo sitio web no funciona y he estado enviando correos a info@redbanc.cl (correo que aparece en el sitio web) y ni si quiera me han respondido que leyeron el correo.

Los riesgos

Los chilenos bien saben lo que es RedBanc y deberían imaginar los peligros que puede significar un fallo de este tipo en el sitio web oficial.
Explotando esta vulnerabilidad es posible robar la identidad de personas y obtener información privadas tales como nombres, rut, telefonos, números de cuenta bancaria y claves de acceso. Tratandose de un sitio web que tiene directa relacion con los bancos y tarjetas de débito es posible tambien obtener los dígitos del PIN PASS, usando un poco de ingenieria social y engañando a los usuarios con falsos e identicos sitios y formularios.

Aclaración

La vulnerabilidad fue avisada el Jueves de la semana pasada por primera vez, luego intente contactarme con ellos el día Lunes y tambien el Martes y, siendo Jueves, aún no he obtenido ninguna respuesta, ni si quiera acusando que el correo que les envié fue recibido.

ACTUALIZACIóN – 5/Mar/2010 12:30
Luego de numerosos correos enviados a la gente de redbanc reportando el error y sin obtener ninguna respuesta, decidí publicar este artículo y parece que ha dado resultado, porque la gente de Redbanc ya ha solucionado el problema, obviamente sin agradecer y sin emitir ningun tipo de comentario al respecto, simpemente solucionaron el problema como si nada ha pasado.
Buscando en Google me he dado cuenta que este sitio ha tenido esta misma vulnerabilidad en distintos scripts y y redbanc nunca dijo nada.

Compartir/Guardar

Alvaro Veliz me ha reportado el siguiente problema básico de seguridad en la plataforma de ingreso de alumnos. Esta plataforma llamada “Portal Estudiantil” dice ser una “Intranet solo disponible para alumnos regulares y egresados“, sin embargo, ellos mismos dan la opción de que no sea así y que cualquier persona pueda ingresar tan solo probando con RUTs al azar.

Podemos ver el mensaje en rojo que dice:

La clave que debes ingresar para acceder al Portal Estudiantil es 123456. Esta contraseña la debes cambiar en la pantalla siguiente tal como se te solicita.
IMPORTANTE: Al momento de cambiarla se te pide ingresar tu clave anterior, ésta es 123456, no lo olvides.

Me pregunto cuanta gente, hasta la fecha de hoy, ha ingresado al portal y ha cambiado su clave? Bastaría con generar un script que pruebe una lista de RUTs probables con una clave 123456 y ganar acceso al sistema, obtener informacion de los alumnos y crear dolores de cabeza a los administradores cambiandole todos los datos al usuario. Con estos hechos queda demostrada la poca o nula preocupación por las Universiades cuando se trata de proteger la información personal y la privacidad de sus alumnos.

Compartir/Guardar

La teoría es sencilla, la idea era encontrar un link directo a los distintos archivos multimedia o bien un enlace a algun directorios que los contenga, para luego descargar todo el contenido del directorio.
El fallo por parte de ellos fue dejar que se liste el contenido de directorios, de esta forma pudimos tener acceso a informacón como la siguiente:

Luego, con un poco de magia, simplemente descargamos el contenido de todo ese directorio.

Todo fue gracias al sitio “Satanick” el cual contiene un flash que provee al usuario poder ver series en línea, afortunadamente lamentablemente si vemos el código fuente nos encontramos con la siguiente sorpresa:

Miren detenidamente el código a ver si encuentran algo que nos ayude a nuestro propósito. Encontramos:

file=http://efectoanime.com/server/dn0te/06.mp4

Con esto ya podemos deducir que todos los videos se encuentran en la URL http://efectoanime.com/server/XXX, donde XXX corresponde al nombre de la serie. Como vimos en la imágen que les mostré anteriormente (donde se listaban los archivos del directorio thundercats/), está permitido listado de archivos de un directorio. Nuestro amigo wget será la salvación, ya que con el parametro -r es posible descargar un directorio.

Bien, ahora nos falta automatizar el proceso. Las URL de Satanick, donde se encuetran los videos, son de la forma http://satanick.com/?page_id=XXX, por lo que podemos asumir que cada ID corresponde a una página y en cada página es posible que encontremos links como el que les acabo de mostrar (el html de más arriba). Entonces mi idea fue crear un script que recorriera todas las páginas desde XXX hasta XXX+n. Pensando que si lo hago desde 0 se iba a demorar una eternidad, solo lo hice desde el 3000 hasta el 10000, luego cada página examinada deberá ser parseada y se debe encontrar un patrón que nos permita obtener la URL donde se encuentran los videos.
Yo lo hice de la siguiente forma:

for x in $(seq 3000 10000); do wget -O - http://satanick.net/?page_id=$x |grep "http://efectoanime.com/server" |awk -F '&' {'print $2'}>> lista_videos_satanick; done

Si lo queremos ver más bonito y en forma de “script”:

#!/bin/bash
for x in $(seq 3000 10000);
do
   wget -O - http://satanick.net/?page_id=$x |grep "http://efectoanime.com/server" |awk -F '&' {'print $2'}>> lista_videos_satanick;
done

El archivo “lista_videos_satanick” va a guardar todas las URL que encuentre y quedarás más o menos así:

file=http://efectoanime.com/server/hades/h29.mp4
file=http://efectoanime.com/server/hades/h29.mp4
file=http://efectoanime.com/server/hades/h30.mp4
file=http://efectoanime.com/server/hades/h30.mp4
file=http://efectoanime.com/server/hades/h31.mp4
file=http://efectoanime.com/server/hades/h31.mp4
file=http://efectoanime.com/server/hades/h31.mp4
file=http://efectoanime.com/server/thundercats/Th71.mp4
file=http://efectoanime.com/server/thundercats/Th71.mp4
file=http://efectoanime.com/server/thundercats/Th71.mp4
file=http://efectoanime.com/server/thundercats/Th72.mp4
file=http://efectoanime.com/server/thundercats/Th72.mp4
file=http://efectoanime.com/server/thundercats/Th72.mp4
file=http://efectoanime.com/server/thundercats/Th73.mp4
file=http://efectoanime.com/server/thundercats/Th73.mp4
file=http://efectoanime.com/server/thundercats/Th73.mp4
file=http://efectoanime.com/server/thundercats/Th74.mp4
file=http://efectoanime.com/server/thundercats/Th74.mp4

Lo único que debemos hacer es quitarle el principio “file=” y quitar las líneas repetidas:
sed -i 's/file=//g' lista_videos_satanick
Nos quedará algo así:

http://efectoanime.com/server/shippuden/Shippuden_144.mp4

http://efectoanime.com/server/bl34ch/B255.mp4

http://efectoanime.com/server/shippuden/Shippuden_145.mp4

http://efectoanime.com/server/md/612.mp4

http://efectoanime.com/server/bl34ch/B256.mp4

http://efectoanime.com/server/shippuden/Shippuden_146.mp4

http://efectoanime.com/server/thundercats/Th90.mp4

http://efectoanime.com/server/thundercats/Th92.mp4

De todas estas URL lo que nos interesa es sólo http://efectoanime.com/server/XXX, entonces lo arreglamos:

awk -F '/' {'print $1"/"$2"/"$3"/"$4"/"$5'} lista_videos_satanick

Quedará algo así:

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/thundercats

http://efectoanime.com/server/bl34ch

http://efectoanime.com/server/bl34ch

http://efectoanime.com/server/bl34ch

http://efectoanime.com/server/shippuden

http://efectoanime.com/server/shippuden

http://efectoanime.com/server/shippuden

http://efectoanime.com/server/MD

http://efectoanime.com/server/MD

http://efectoanime.com/server/MD

Ahora debemos eliminar las repetidas:

# awk -F '/' {'print $1"/"$2"/"$3"/"$4"/"$5'} lista_videos_satanick |sort|uniq -d

http://efectoanime.com/server/Vshow

Luego un script que descarge todos los contenidos de los directorios:

for link in $(cat lista_videos_satanick); do wget -r $link; done

Y listo.

1.6G Death Note.tar
1.6G Saga de Hades.tar

ACTUALIZADO 16/02/2009

Luego de los comentarios de los responsables de los sitios, dando las gracias y diciendo que no les importa porque de todas formas tiene una marca de agua, etc etc.. Los directorios ya no se pueden listar:

http://efectoanime.com/server/thundercats/

Al fin y al cabo, si les importó el tema. Me alegro que les sirviera el post.

Compartir/Guardar

Este sistema de pago del transporte público de Santiago, tiene un sistema que nos permite monitorear en línea los saldos y los movimientos de nuestra tarjeta y de ésta forma saber dónde cargamos con dinero la tarjeta, en qué buses o metro la usamos, cuánto salgo nos queda, etc. Este sistema no es en tiempo real por lo que asumo que no saca los valores directamente de la base de datos del sistema de transporte, además desconozco si tiene permisos para escribir en la base de datos o solamente leer.
El sistema tiene un bug que nos puede permitir, con un poco de ingenio, hacer un ataque de denegación de servicio distibuido (DDoS) y dejar el sistema (de saldos y mov. en linea) offline y posiblemente realizar inyección de código SQL (SQL-Injection) . No me he puesto a investigar que otro impacto podría tener.

El sistema nos permite ver la cantidad de movimientos y saldos de nuestra tarjeta por periodos de mes actual, 60 y 90 días, sin embargo, es posible modificar esos valores alterando el atributo “value” del elemento del formulario. Si, así de sencillo.

Código HTML original:

Mes Actual
60 dias
90 dias

Pruebas de concepto (PoC)

1. Modificamos el valor de “Mes Actual” por un número negativo.

Mes Actual
60 dias
90 dias

Y ejecutamos la consulta:

2. Modificamos el valor de “Mes Actual” por el número 5.

Mes Actual
60 dias
90 dias

Y ejecutamos la consulta:

Si se fijan en la fecha, podrán ver que sólo se mostró información desde hace 5 días.

3. Modificamos el valor de “Mes Actual” por una comilla para generar un error de sintáxis:

Mes Actual
60 dias
90 dias

Y ejecutamos la consulta:

Si cambiamos el valor de “Mes Actual” a uno muy alto, por ejemplo 99999999999999999999999999999999999999 podemos ver cómo el sistema ya comienza a comportarse de forma extraña, por ejemplo ver la fecha:

Operación: Cartola de movimientos
Tarjeta bip!: 6547XXXXX
Fecha: 11/02/2010 10:57
Movimientos desde: 90/37/-2.7

De ésta forma podemos manejar arbitrariamente la consulta.

Queda más que demostrado que el famoso sistema para ver los saldos y movimientos en línea de la tarjeta bip no está validando los parametros de entrada y con un poco de ingenio podemos realizar distintos tipos de ataques. Se pueden generar simultaneamente consultas pesadas en el servidor, provocando su caída. Tambien, con un poco más de conocimientos y habilidades es posible lograr la inyección de código sql en la consulta.

Compartir/Guardar

El port forwarding, según el mismo manual de ssh, corresponde a:

Specifies that the given port on the local (client) host is to be
forwarded to the given host and port on the remote side. This
works by allocating a socket to listen to port on the local side,
optionally bound to the specified bind_address. Whenever a con-
nection is made to this port, the connection is forwarded over
the secure channel, and a connection is made to host port
hostport from the remote machine. Port forwardings can also be
specified in the configuration file. IPv6 addresses can be spec-
ified with an alternative syntax:
[bind_address/]port/host/hostport or by enclosing the address in
square brackets. Only the superuser can forward privileged
ports. By default, the local port is bound in accordance with
the GatewayPorts setting. However, an explicit bind_address may
be used to bind the connection to a specific address. The
bind_address of “localhost” indicates that the listening port
be bound for local use only, while an empty address or ‘*’ indi-
cates that the port should be available from all interfaces.

En simples palabras, lo que se hace, es habilitar un puerto local, por el cual se hara un redireccionamiento, a traves de ssh y el servidor remoto, hacia nuestro destino.

Paso a paso

Mapear la dirección de destino a nuestor localhost, en mi caso (y como ejemplo) usaré smtp.gmail.com. Debemos editar el /etc/hosts y agregar a la línea de 127.0.0.1 nuestro destino:
127.0.0.1 localhost.localdomain localhost smtp.gmail.com
Verificamos:
$ ping -c1 smtp.gmail.com
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.038 ms
Ahora, para nuestro sistema, el host smtp.gmail.com está apuntando a nuestra misma máquina.

Ahora, hacemos el port forwading usando el parámetro -L de la siguiente forma:
# ssh -L25:smtp.gmail.com:25 zerial@mydomain.org

Una véz logeados, ya va a estar hecho el redireccionamiento de puerto. Lo que hacemos con esa linea es decirle que todo el trafico desde localhost:25 lo lleve a traves de mydomain.org:22 a nuestro destino smtp.gmail.com:25.

Ahora realizamos la prueba, para ver si realmente tenemos salida a smtp.gmail.com:25:
$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mx.google.com ESMTP 42sm25383892vws.12

Listo. Obviamente, el Firewall no podrá bloquear el tráfico de localhost y tampoco el de ssh, ya que va cifrado.

Compartir/Guardar

Ahora vamos a la práctica, se los enseñaré mediante un ejemplo real buscando un sitio web al azar con la ayuda de Google. Encontramos el sitio “Cibertec.cl” que al parecer cumple todo para poder explotarla.Ç
Si ingresamos al sitio http://www.cibertec.cl y revisamos el tipo de links que contiene, podemos darnos cuenta fácilmente que puede  ser vulnerable a SQLi.

Vamos a comprobarlo cambiando el número 587 por una comilla simple. Entonces ingresamos a http://www.cibertec.cl/detalle.php?item=’ y obtenemos el siguiente mensaje:

Database error: Invalid SQL: SELECT * FROM inventory WHERE id = ‘
MySQL Error: 1064 (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”’ at line 1)
Session halted.

Si nos fijamos en la línea donde nos muestra la consulta SQL podemos ver que al final pone “WHERE id = ‘“. Pues esa comilla simple que se ve depsues del signo igual es la comilla que nosotros pusimos en el navegador. De esta misma forma, si agregamos la palabra “prueba” luego de la comilla simple, podemos ver el siguiente mensaje:

Database error: Invalid SQL: SELECT * FROM inventory WHERE id = ‘prueba
MySQL Error: 1064 (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”prueba’ at line 1)
Session halted.

Ahi aparece la comilla simple seguida de la palabra prueba, justo lo que nosotros escribimos. Bien, ya manejamos lo que queremos que se muestre, ahora debemos insertar el código malicioso.

Prueba de concepto (PoC)

Vamos a aprovecharnos de ésta vulnerabilidad de SQL Injection para realizar phishing y para intentar robar una credencial mediante XSS.

1. Phishing: Vamos a añadir un iframe con un sitio especialmente preparado para éste fin. Pueden hacer la prueba incrustando el sitio de Google: http://www.cibertec.cl/detalle.php?item=%27%3Ciframe%20src=http://www.google.cl%3E%3C/iframe%3E
   (puede leer más sobre esto en un post que publiqué hace un tiempo)
2. Robo de credenciales: El típico aprovechamiento de Cross-Site Scripting usando javascript para redirigir al usuario a un sitio web cuyos parámetros será una cookie. Por ejemplo: http://www.cibertec.cl/detalle.php?item=%27%3Cscript%3Ealert%28this.cookie%29%3C/script%3E

De esta manera podemos afirmar que el sitio web Cibertec.cl es vulnerable a SQL Injection y Cross-Site Scriting.

Compartir/Guardar

<script>alert(‘this.cookie’)</script>

Cuando los ataques XSS mediante tags no son posibles, existe la posibilidad de realizar el ataque usando las propiedades de cada tag. Puede ser usando el atributo style, src o algúnos gatilladores de eventos como onMouseOver, etc. Para poder realizar el ataque es necesario usar comillas (simples o dobles), aunque tambien en algunos casos existe la posibilidad de no usarlas, para poder agregar una nueva propiedad al tag en el cual hemos conseguido insertar el código.

En los ataques realizados mediante la propiedad style, podemos usar las siguientes funciones o métodos (en este caso, el código se ejecuta automáticamente al cargar la página):

1. Usando expression(), sólo funciona en Internet Explorer anterior a la versión 8.
2. Usando background:url() o background-img:url(), sólo funciona en Internet Explorer.
3. Usando -moz-binding:url(), sólo funciona en Mozila y en otros motores basados en Gecko (antes de Firefox 3).

Pueden ver un ejemplo de un ataque usando -moz-binding:url() y expression() en éste link (está en un idioma que seguramente no entenderemos pero los ejemplos se entienden sin problemas).

Los ataques vía eventos (handlers) son aplicables de la siguiente forma:

1. Eventos como onMouseOver, onFocus, onBlur, onSelect, onChange, onClick, etc.
2. Usando onError, onLoad y onUnload, para ejecutar código automáticamente al cargar o cerrar la página.

La posibilidad de usar onLoad, onUnload y onError no es muy amenudo y los otros eventos no se ejecutan automáticamente, siempre hay que esperar a que algo los gatille. Por ésto mismo, este tipo de ataque XSS no es muy popular, generalmente se ataca incrustando código en las propiedades tales como style, ya que se ejecuta automáticamente.
Cerca del 2008, la posibilidad de realizar un ataque XSS mediante -moz-binding fue removida (o bueno, fue parcialmente removida ya que aún es posible realizar ataques de éste tipo mediante ficheros xml en el mismo sitio). En el lanzamiento de Internet Explorer 8, a comienzos del 2009, se removió el soporte a la función o método expression(). Tambien fue removido el soporte de javascript o vbscript en background-image.
Con los arreglos que se hicieron en los distintos navegadores,  se dificuló el llevar a cabo  ataques Cross-Site Scripting mediante tags. Por otro lado, los navegadores como Opera y Chrome resisten ataques  de éste tipo mediante la propiedad style.
Podemos usar la técnica del MouseOverJacking. Con ésta técnica, se puede automatizar el ataque XSS. Es una solución que funciona en todos los navegadores, incluyendo IE8, eludiendo la protección anti-clickjacking que trae incorporada.
MouseOverJacking se puede usar en lugar de expression() y -moz-binding(). El ataque está automatizado, por lo que el ataque cumpliría el mismo objetivo que expression y -moz-binding y gracias al soporte multi navegador, es posible atacar a más usuarios.
Se puede realizar con MouseOverJacking lo mismo que con ClickJacking, con la diferencia que el MouseOverJacking es más efectivo, ya que no espera ninguna acción del usuario, no es necesario que el usuario haga click para gatillar el ataque. El ClickJacking espera un click por parte del usuario en cambio el MouseOverJacking simplemente espera el movimiento del ratón.

Ejemplos:

Reflected XSS

http://site/script?param=%22%20style=%22width:100%;height:100%;display:block;position:absolute;top:0px;left:0px%22%20onMouseOver=%22alert(document.cookie)%22

Persistent XSS

<a href=”#” style=”width:100%;height:100%;display:block;position:absolute;top:0px;left:0px” onMouseOver=”alert(document.cookie)”>&nbsp;</a>

Este artículo corresponde a una traducción al Español de la traducción al Inglés del original, extraído de WebSecurity.

Compartir/Guardar

Los errores más estúpidos comunes son validaciones mal hechas para ingresar a intranets, ficheros de respaldos visibles publicamente, directorios con información confidencial no protegidos, etc. Yo, como programador, se como funcionan estas cosas, los clientes quieren muchas cosas por muy poco dinero y, por ésto mismo, el programador decide optar por el camino más rápido posible. Por otro lado, sabemos que a los clientes no les importa mucho la seguridad y que cuando le dices que cobrarás un poco más por el hecho de agregarle seguridad al sitio o al sistema, ellos no lo entienden y prefieren el camino más barato. En fín, mientras no se invierta en seguridad, seguirán sucediendo cosas como las que les mostraré a continuación.

El primer caso (gracias a xwall o más conocido como El Arma Secreta, miembro del Hacklab por la información) es el del Instituto Chacabuco (del Colegio Maristas) quienes tienen una intranet donde podemos encontrar los datos de tosos los alumnos y apoderados. Estos datos son nombre, dirección, e-mail, número telefónico, etc.

Estos pantallazos pertenecen al area de administración de estudiantes (una intranet) que en teoría requiere un login, pero se puede bypassear fácilmente.

Este sitio además de poder mirar información, nos permite agregar, eliminar y modificar datos. Estoy seguro de que la misma forma que cometieron éste error, tienen otros más y que al agregar un usuario puedo adjuntar ficheros y lograr subir un archivo que me permita ejecutar código arbitrario en el servidor.

Pronto publicaré otro sitio con información expuesta.

Compartir/Guardar