Análisis de seguridad: Servipag vs Sencillito vs MisCuentas

Ya muchos leyeron mi post anterior sobre la seguridad del servicio que ofrece Servipag, la idea de este nuevo artículo es hacer un tipo de benchmark de seguridad entre los tres principales servicios de pagos de cuentas online: Servipag, Sencillito y MisCuentas.

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="https://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 https:// 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

29 comentarios

  1. Excelente artículo, completando el anterior 😉

  2. Interesante artículo, impresentable lo se servipag, pero los únicos datos que se podrían obtener de servipag logrando entrar a la cuenta de cualquier usuario, son, los identificadores en los distintos servicios que se tengan guardados…

    me explico: servipag te redirecciona a la página de tu banco/tarjeta de crédito para efectuar los pagos; en ningun momento guarda datos cuya perdida sea fatal, es un nexo entre la empresa de servicio y tu dinero, asi que más allá de la dirección y el teléfono de alguien, no creo que consigas mucho. Ahora con las estafas del cuento del tío y todo eso, igual habría que entrar a mejorar la seguridad de esos datos.

  3. Siempre, mientras mas sencillo un sistema, menos componentes, y si son menos componentes, menos de lo que hay que preocuparse.

  4. Luis.S.Urrutia.F

    agosto 3, 2011 a las 6:36 am

    Buenos análisis básicos, aunque el hecho de que te envíen las contraseñas al correo electrónico no implica que las contraseñas no estén cifradas. Si bien me he topado por muchos casos similares en las que si lo implica, en algunos no es así. No recuerdo el nombre de que plataforma era, pero analizando su código, al momento de que introducías tu nueva contraseña en el fichero de fuentes, enviaba la contraseña al correo electrónico pero las guardaba en la base de datos en forma de hash.
    Si lo analizas bien, puede ser posible, aunque la información este cifrada durante el trafico (ya que es posible descifrarla con una key, siendo simple), en el servidor se leerá normalmente y se puede procesar como texto plano.

  5. Luis.S.Urrutia.F

    agosto 3, 2011 a las 6:45 am

    Rectificación del comentario anterior: Debí usar otro termino en vez de hash, algo como “texto cifrado” (es decir, reversible)

  6. Y que hay de los bancos ? esas wueas si que son mulas en calidad de servicio y seguridad.

  7. Zerial, solo aclarar que donde tu dices “De los dos sitios que requieren registro de usuario”, debo decir que tanto en Mis Cuentas como en Servipag se puede pagar sin registrarse. En esos servicios, el registro es solo para que ellos lleven tus estadísticas de que pagaste y que no, y guardan las cuentas a las que pagas siempre como para que sea más rápido pero, perfectamente puedes pagar sin registrarte. De hecho te puedes registrar con datos falsos y pagas igual.

    Como dice EldarBerserker, es cierto. A través de Servipag y sus “OBVIAS VULNERABILIDADES” no podrán obtener ni interceptar nuestra información financiera, pero si nuestra información personal que es básicamente el meollo de todo este asunto. Es verdad también que las transacciones monetarias (los pagos) en ningún momento se realizan en servidores de Servipag sino que en los suyos propios de WebPay y cada banco asociado al sistema.

    Ahora, mi análisis es el siguiente:
    Primero que todo, Servipag si es vulnerable. Fuera de las decenas de fallas del tipo XSS (Cross Site Scripting) que, fácilmente podrían ser utilizadas por usuarios mal intencionados para hacer PHISHING, existían hace 16 días atrás dos “Bug`s” del tipo Blind SQLi que afectaban directamente a la base de datos que contenía la información personal de los usuarios registrados.
    El sitio también “tenia” (digo tenia porque creo que están parchados) errores de programación, los cuales permitían incluir archivos locales (LFI). Siendo una maquina Windows la que ocupa Servipag como servidor, se podían ver archivos como “boot.ini”, el archivo de host ([sysdir]\system32\drivers\etc\hosts) y obviamente también se podían ver los “sources“ de las paginas web con el conocido fallo “Source Disclousure”. Aquí me detengo un poco porque, creo que es o era una de las fallas mas graves del sistema.

    Servipag en su servidor, todavía tiene este archivo http://www.servipag.com/test.asp, utilizando el Source Disclousure obtenemos el codigo de fuente de ese archivo que, lamentablemente hace una petición a la base de datos de Servipag y contiene los datos de conexión dentro del archivo :S.

    Source de test.asp:

    http://paste.kde.org/105883/

    Nótese:

    DSN=ServipagDbWeb;
    SRVR=ServipagDbWeb;
    DB=portal;
    UID=WebBrowse;
    PWD=AnTiCiPa;

    Agrego a esto que los realizadores del portal de http://www.servipag.com son de http://www.anticipa.cl quienes también trabajan para Bancos Chilenos, el Gobierno, el Ejército, ENTEL entre otros….

    ….agrego también que mi intención en ningún momento es defender ni atacar a nadie, es solo mi punto de vista.

    Para terminar y creyendo que fue lo peor que pudo haber hecho Servipag, es el tema de sus declaraciones por Facebook y por Twitter, que contradice primero que nada la realidad y en segundo lugar contradice sus Políticas de Privacidad.

    Me explico:

    Servipag en su “DECLARACION” a traves de Facebook, dice (extracto):
    “las operaciones y las transacciones se encuentran seguras y resguardadas bajo exigentes parámetros y estándares nacionales e internacionales, que se van actualizando día a día.”.
    (http://www.facebook.com/notes/servipagcom/comunicado-servipag-desestima-riesgo-de-datos-de-sus-usuarios/199971020061765).

    Pero, Servipag en sus Políticas de Privacidad dice (extracto):
    “No obstante lo anterior, Servipag no garantiza de manera alguna que la información del usuario no será o no podrá ser objeto de interceptación, monitoreo y/o uso por parte de terceros no autorizados.
    En consecuencia, Servipag no será responsable de los eventuales daños y perjuicios, que dichas actuaciones por parte de terceros no autorizados, causen al usuario.”
    (http://www.servipag.com/browse.asp?pagina=web/politicas_privacidad.htm).

    Mmmmm…. MAL.

    Eh dicho!

  8. Estimados,

    Por lo menos cuando pago, sin registro usando la cuenta corriente del banco de Chile, el formulario donde te pide meter la clave (del banco) esta en una pagina de Servipag, pero que simula del del banco usando los logos del banco y trata de esconder su origen usando una ventanita minimizada sin barra de direcciones. Eso si lo encuentro trucho, nunca se si estan guardando mi clave o no, con algun ajax lanzado por detras antes de reenviar al home del banco.
    Saludos

  9. Excelente aporte pks!

    Tal como dicen muchos en los comentarios que me han dejado, saemos que puedes pagar sin registrarte y que la transaccion de pago se realiza por webpay o los bancos y no por servipag. La posibilidad de tomar el control del servidor, obteniendo datos sensibles realizando ataques phishing mediante XSS a la gente que trabaja en servipag o viendo informacion sensible del servidor mediante el LFI, imaginense falsificamos el sitio de pago que se conecta a realizar las transacciones…

  10. Para los que dicen que servipag no guarda datos, si tienes el control del servidor aprovechando un lfi bien explotado no es necesario que se guarden los datos para capturarlos. Si tienes control del server es facil colocar un sniffer en la interfaz local para capturar los datos quw viajen, incluso los capturarias desencriptados. El sniffer solo habria que cargarlo en memoria para que no lo detecte el antivirus y listo… alguien dijo metasploit?

  11. Con las formas de pago que tiene sencillio, no se si es correcto llamarlo “portal de pagos”

  12. De verdad no veo ni un aporte al “estudio” que hiciste, es pobre y poco contundente, ahora si tienes 16 años, te lo acepto y te felicito si ya tienes mas 20, mmmm lamer? Aun existe esa cosa?

  13. Test, las vulnerabilidades están si o si, no importa si es un lammer, script kiddies, si tiene 16 años o no, date cuenta, que hay grandes bugs y que los datos de muchas personas pueden ser afectados, ¿Qué aporte? claro que hay un aporte en dar a conocer estos problemas para que la gente no sea engañada o no use servipag porque sus datos corren peligro, tu no conoces el potencial de un atacante, colócate en la situación que se toma el control del server mediante backdoor etc, el daño puede ser aun mayor, pensando en que un server no se apaga, por lo tanto todo lo que ha sucedido en la maquina, toda la información que ha circulado por la maquina, teniendo ya el control sobre ella puedes usar una tool forensics y recordando la ruls “mientras no se apaga todo sigue en memoria”, podemos extraer una cantidad mucho mayor de datos inlcuso de los demás sitios que están el en server, test sinceramente tu comentario es un reflejo de que sabes poco y hablas mucho.

  14. Test: que fácil es criticar sin aportar al tema, acá nadie está entregando información por ser más o menos “lammer” (y no lamer como tu lo escribes), solamente se entrega un ANÁLISIS para declarar y denunciar que hay información vulnerable de muchas personas que utilizan esta plataforma.

    Creo que el único que queda de “lammer” eres tú, al no aportar y no tener una mínima capacidad de compresión lectora (Asumiendo que terminaste cuarto medio y sabes lo que es la comprensión lectora).

  15. Que buenos comentarios en PRO de la seguridad de la información!. Que lástima que no se te haya ocurrido antes “Test”. Envidioso xD.!

  16. Gracias por hacer este trabajo y hacerlo público. Una pena que empresas que se dedican a temas tan delicados en cuanto a seguridad no trabajen con mejores estándares y pasen años así hasta que alguien ajeno a ellos se los hace ver.
    ¿Y qué dijo Servipag?

  17. Zerial

    agosto 3, 2011 a las 8:17 pm

    No quería responderle a “Test” porque oculta su identidad y asi es facil desprestigiar a las personas, ademas tampoco queria alimentar al troll, pero veo que algunas personas ya le han respondido.

    Test: Lo mismo que @alvaroveliz, pks y Anon, el que no está realizando ningun aporte ni a los usuarios, ni a este post, ni ami ni ati .. ers tu 🙂

    hari_seldon: Servipag dice que las vulnerabilidades existen, sin embargo, no pone en riesgo los datos de los usuarios

  18. para mi que test es programador de servipag, buen aporte ya que los datos que se manejan deberian estar seguros, sobr todo si en la pagina dice que el porta es “seguro”

  19. Me entere de tu pagina leyendo un articulo en un diario: Mira yo no entiendo nada de nada , porke no soy muy joven, tampoco importa la edad que tengas, lo LOABLE es que con la informacion que tu aportas es muy buena. Te felicito y mas aun que das esta informacion desinteresada y que NADIE TE PAGA.
    Mis respetos y sincera gratitud a tu trabajo

  20. Yo tambien vi el articulo en el diario y entre al sitio de zerial , tambien reconozco no ser un entendido en el tema , pero si creo que es un aporte la informacion entregada , nunca he confiado en los portales de pago , siendo yo una persona que tengo tarjetas de casas comerciales y bancarias , por lo tanto jamas compro o pago en sitios web. Se agradece a personas como zerial que nos muestra lo vulnerables que podemos ser al entregar informacion privada.

  21. No entiendo nada de nada, No soy computin. Sin embargo esoty preocupado de este Tema. Quizas es una tonteria, pero yo hago lo siguiente cuando Pago.
    Cuenta Rut. Siempre la tengo en “0” Ocupo los sitios de pago con ella. Traspaso de mi Cta. Bancaria a la Cuenta Rut. solo lo que voy a pagar. Una vea realizado los pagos. La cuenta Rut queda nuevamente en “0”. Por lo tanto, no me preocupo de si me van a robar. Ustedes que se manejan en el tema. Corro algún riesgo?
    Gracias

  22. Hola Marcel: Teniendo tus cuentas en $0 previenes que si alguien ingresa pueda robar dinero, ademas que una cuenta en $0 es poco tentativa. Pero mas alla de eso, la seguridad va en ti mismo, saber donde pones tus datos, ver que realmente el sitio en el que estas ingresando tus datos es el que dice ser y no uno falso. Suena basico cierto? El problema es que estos sitios web son vulnerables a una tecnica que te permiten manipular el como se te va a ver el sitio en tu navegador, pudiendo agregar formularios, modificar parametros, etc y hacer que cuando tu ingreses tus datos, en un sitio totalmente verdadero, se vayan a otro lugar y no al que deberia irse, por ejemplo, a un servidor remoto que almacena informacion de usuarios.

    Es complicado el tema, porque una persona que no tiene mucha idea de internet, seguridad o, como dices tu, no es un “computin”, no tiene muchas herramientas para determinar si le estan robando informacion o no. Simplemente, ser cuidadoso … Esa tecnica de dejar la cuenta rut en cero y pagar con ella, es un acto de paranoia, inseguridad y desconfianza que lo haces para protegerte de robos, etc. Está bien, debes ser desconfiado, no te digo no usar estos portales, pero no entregar tu info sin desconfiar

  23. Agradesco tu respuesta tan temprana. Desde ahora, despues de leèr el articulo del periodico, cuentas con un seguidor mas.
    Además, es bueno entontrar personas que se preocupan de Otras personas. Lamentablemente, no tengo aporte alguno en este tema de la computación. Sin embargo, estare atento a tus publicaciones.
    Gracias Zerial.

  24. Zerial, entonces preocupate de la seguridad de los bancos y no hables de Sitios Web de Pagos Online si no sabes quienes están detrás. No soy promotor de nadie, pero me ilustro antes de dar entrevistas.

  25. andino: escribes como si me conocieras, gran error tuyo

    saludos 😉

  26. Estimado,

    La prueba que tomó para verificar que la clave de usuario no viene cifrada, no me parece certera. No creo que con esa prueba lo pueda determinar. Tal como decía @Luis.S.Urrutia.F, no necesariamente la clave no está cifrada.

  27. Mark Twain: Ok, pensemos que no está cifrada.. Entonces? Por qué cuando pones “recuperar contraseña” te llega la password en texto plano? Claro, “está cifrada pero si la pueden descifrar”, al final es lo mismo .. que sentido tiene almacenar una password cifrada y tener como descifrarla?
    Vamos, que es lo mismo …

  28. Estimado,

    Tiene toda la razón. Retiro lo dicho.

    De paso lo felicito por su aporte a la comunidad virtual.

  29. Que buen post compadre. Yo corroboro tu analisis.

    Yo hace un tiempo atras trabaje en una importante multinacional bancaria, la cual, luego de haberte contratado te hacen sacar certificados para temas de seguridad donde se ve todo esto del XSS, etc. Y un dia que no tenia mucha pega, luego de haber terminado una certificacion, me puse a jugar un poco con las URL de SERVIPAG y claro, nada complejo para un desarrollador ordinario. Y me di cuenta que nada estaba seguro.

    Me dan rabia estas empresas que ni siquiera agradecen la pega gratis que les estas haciendo de seguridad. Alguien les avisa que estan en pelotas y que cualquiera los puede llegar y violar y se enojan por eso.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Esto sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.