Ibex35 en la brecha de Adobe

Hace unos días hacíamos un pequeño análisis de la información filtrada por el desafortunado incidente en Adobe.com. Hoy queremos darle una vuelta más y tratar de explicar cómo impacta esto en las empresas del IBEX35.

Cuando nos enteramos de que se habían filtrado millones de usuarios y sus contraseñas cifradas, todos pensamos que tan solo era un portal más hackeado, otro listado como las decenas que ya hay públicos en Internet. Nada más lejos de la realidad.

El listado de credenciales está compuesto por 6 campos: un identificador numérico, el nombre de usuarios (pocas veces), el correo electrónico, la contraseña (cifrada) y una "pista" que introdujo el usuario para recordar esta clave, y finalmente una sexta parte que permanece vacío para todas las filas.

Este fichero no se ha indexado por los buscadores, pero está en torrents desde hace días y se puede descargar por todo aquel que quiera.

Como ya comentó mi compañero, las contraseñas de cada usuario están cifradas con 3DES, para ello se ha usado una cadena de texto como clave. A día de hoy no se conoce esta clave, por lo que no se saben todas las contraseñas de los usuarios, pero será cuestión de días que se publique y entonces el proceso será instantáneo.

Si no se pueden descifrar, ¿cómo se sabe cuáles son las top100 contraseñas? Fácil, al no incluir salt, la cadena de cifrado siempre es la misma, por lo que ordenándolas y contándolas se puede saber cuáles son las cadenas más repetidas.

Pero, ¿cómo se sabe cuál es el texto descifrado de esas top100? Aquí ayuda el gran número de usuarios que las utilizan y las pistas que han puesto para recordarla. Por ejemplo, si buscamos unas cuantas líneas  la cadena de la primera de ellas: EQ7fIpT7i/Q= en el fichero, nos encontramos lo siguiente:

Ejemplo de las pistas de algunos usuarios para su contraseña

Ahora seguro que se comprende cómo se conocen el top100, incluso sin saber idiomas.

Como afecta esto a una empresa grande con decenas de dominios y usuarios es obvio: al final esos usuarios habrán introducido ahí la misma contraseña que tienen para servicios en su lugar de trabajo: como la contraseña del dominio, aplicaciones web de negocio, sistemas operativos, que se yo, incluso de una VPN. Aunque seguro que todos ellos ya son conscientes de este incidente y han tomado las oportunas medidas... ;-)

Tratando de sacar números, hemos buscado algunas cadenas y dominios de las empresas del IBEX35, es un ejercicio complejo debido al número de dominios, pero sirve para tener una aproximación basada en muestra de los usuarios comprometidos de Adobe para cada una de ellas.

Usuarios de IBEX35 en el listado de Adobe

La siguiente pregunta que nos hacemos es cuantas de estas 7.370 cuentas tienen una contraseña que se ha mostrado en el top100. La respuesta rápida: 248, un 3,3%.

Usuarios con contraseñas el top100 

Un dato también muy curioso, y que siempre se comenta entre chistes de informáticos es el que sacamos de estos usuarios y sus hábitos de contraseñas: "pon la fecha del cumpleaños". Con la información publicada es posible  analizar las pistas que han introducido en la plataforma. Aquí gana por goleada "la de siempre", seguido del nombre, el perro...

-No, si yo uso siempre la misma. Ya, pues te va a salir caro.

Ahora solo cabe difundir el mensaje, rotar las contraseñas y esperar, porque estamos convencidos de que la intrusión en Adobe, rebotará a otros sitios donde su política de contraseñas no les haya obligado a cambiarla.

Que San 123456 nos pille confesados.

Leer más...

Brecha de seguridad en el servicio online Scribd.

Scribd. es un servicio dedicado a compartir y visualizar documentos de forma online, así como permitir el incrustar dichos documentos en webs.

Como parece ya típico en cualquier servicio online de un cierto renombre con una gran masa de usuarios registrados, por lo que parece ser ha sufrido una intrusión en su red interna.

El miércoles por la tarde, desde su servicio de soporte http://support.scribd.com/, se publicaba un anuncio en el que se comentaba que su equipo de Operaciones había descubierto, y posteriormente bloqueado, actividad sospechosa dentro de su red que aparentemente consistía en el intento de acceso a las cuentas de correo electrónico y contraseñas de los usuarios de Scribd.

Al parecer no llegarían a la totalidad de usuarios, pero si a un porcentaje, según ellos, muy reducido. Además, también creen que no se ha podido acceder a ningún otro tipo de información (contenido, financiera...)

Todos los usuarios afectados han sido notificados vía e-mail informando de la situación e instándoles a reinicializar su contraseña. Además, han creado un servicio llamado "Check Password" para comprobar si tu cuenta de correo ha sido una de "las elegidas":

Si utilizas este servicio cambia la contraseña, aún no habiendo recibido ningún mail por parte de Scribd, cambia la contraseña, aunque según ellos estuviese hashed and salted, cambia la contraseña.

De momento no consideramos que sea un hackeo memorable (esperamos que salga algún tipo de información más técnica sobre lo que verdaderamente haya ocurrido...), pero si uno más a añadir a la gran lista de servicios comprometidos como son Dropbox, LinkedIn, Yahoo!...

[+] Scribd. Support Desk - Important Security Announcement

Leer más...

El caso Global Payments: consecuencias de una intrusión

El pasado Sábado saltaba la noticia en el blog de Brian Krebs, KrebsOnSecurity.com, sin todavía conocer muchos datos, de que VISA y MasterCard estaban empezando a avisar a los bancos sobre una brecha de seguridad con la que se habría comprometido un determinado conjunto de tarjetas de crédito, y que tuvo lugar entre finales de enero y finales de febrero. La información obtenida era justamente las incluídas en los Tracks 1 y 2 de dichas tarjetas, lo que permitiría falsificaciones. En los avisos ya se anunciaba que dicha brecha se había detectado en una empresa procesadora de sus tarjetas. Al poco tiempo ya teníamos el nombre de la víctima: Global Payments (GPN)

Una vez se puso el foco de atención en Global Payments, de nuevo las principales compañías financieras (VISA, MasterCard, etc) dejaban claro que no se había producido ninguna intrusión en sus propios sistemas, y que todo el daño se había realizado en dicha empresa procesadora. GPN a continuación, habló, intentando que reinase la calma. El propio CEO de GPN, Paul R. García dijo "Lo que nos tranquiliza es que nuestros procesos de seguridad detectaron una intrusión. Es crucial que se entienda que este incidente no involucra a nuestras compañías asociadas o su relación con sus clientes".

Rápidamente, y durante las horas siguientes al anuncio de lo ocurrido, comenzaron las primeras consecuencias, que mostramos a continuación en una captura de la evolución de la compañía en bolsa:

Evolución de NY:GPN de estos últimos días

No hace falta ser un experto en economía para saber, mirando esa gráfica, cuando se hizo pública la intrusión. En este caso, y no como otras veces, esta consecuencia en las acciones de una compañía no se debían a un rumor, si no que se había incluso confirmado la intrusión, y aún sin conocer muchos detalles ni tener notas de prensa oficiales (salvo las de las entidades de tarjetas de crédito), el revuelo comenzaba a extenderse. Lo que todavía no estaba claro era la magnitud completa de la intrusión, y a cuantas tarjetas se había tenido acceso. GPN se encontraba en pleno proceso de análisis de la brecha de seguridad, y esperamos que se hagan públicos más detalles en los próximos días.

La última consecuencia la tuvimos ayer mismo, cuando VISA anunciaba que había eliminado a Global Payments Inc. de su lista de proveedores de servicio debido a la intrusión cibernética que habían sufrido, y que podría afectar a más de 1,5 millones de clientes. No creo que el resto de entidades tarden mucho en seguir los mismos pasos, ya sólo por no quedarse atrás. Este hecho me hizo recordar lo ocurrido con Diginotar, y como poco a poco fueron llegando a la bancarrota tras hacer pública una intrusión en sus sistemas. Compañías que aparentemente deben tener unas protecciones de seguridad más importantes que el resto por su magnitud y tipo de negocio, y que finalmente son comprometidas una y otra vez (en el caso de GPN, parece ser que no era la primera vez que se detectaba un problema de seguridad...)

Seguimos al tanto de esta intrusión, y esperamos tener más datos, sobretodo técnicos y detallados, a todo lo que rodea a este hackeo memorable de principios de año. A continuación se incluyen más referencias sobre este caso, en los que destacamos los posts de Brian Krebs el cual está llevando a cabo un mayor seguimiento de todo lo que ocurre alrededor de este tema:

[+] Global Payments: 1.5MM Cards ‘Exported’ (krebsonsecurity.com)

[+] Global Payments: Rumor and Innuendo (krebsonsecurity.com)

[+] Evolución financiera de GPN y titulares relacionados (finance.yahoo.com/)

Leer más...

Buena programación + Auditoría + WAF = Web segura

Pese a trabajar para un fabricante de soluciones WAF (Web Application Firewall), intentaré ser objetivo, puesto que sigo pensando que mientras el mundo requiera desarrollos "para ayer", la seguridad de las aplicaciones web queda relegada a una menor prioridad primando la funcionalidad y "cuanto antes". Lo verdaderamente seguro sería que los desarrollos pasasen por estrictos ciclos de calidad, de principio a fin, en los que la base fuesen los criterios de programación segura por encima de todo. Otro ingrediente esencial es una correcta y ágil administración de parches para el software de los servidores expuestos a Internet para evitar sorpresas por problemas en la infraestructura utilizada.

Como las metodologías de desarrollo seguro no suele estar entre las buenas prácticas de las organizaciones más que en un mínimo porcentaje de los casos, ya sea por desconocimiento, por sub-sub-sub-sub-sub-contratación de los servicios de desarrollo o por prisas infundadas,… para tener la tranquilidad (y a veces por necesidad de cumplimiento únicamente), hay otras dos alternativas: auditorías periódicas o proteger mediante un dispositivo WAF que analice las peticiones web y bloquee las que considere como maliciosas.

Partiendo de que no se siguen metodologías de programación seguras, el eterno debate entre la preferencia entre auditar o proteger con WAF se ve zanjado con la mejor de las respuestas: las dos cosas.

La demostración más clara de ello es la decisión por parte de la empresa de seguridad americana Trustwave Spiderlabs al comprar Breach Security. Quizá Breach no os suene mucho, pero es la marca comercial de un WAF de los que ya hemos hablado en varias ocasiones en SbD. Se trata de mod security, un módulo de seguridad a nivel de aplicación embebido en Apache. De hecho, uno de los creadores de mod_security, Ivan Ristic era uno de los principales desarrolladores trabajando para Breach.

Con la compra de este tipo de solución, la empresa Trustwave Spiderlabs que, entre otras, ya proporcionaba soluciones y servicios de seguridad, completa su portfolio sobre todo para ofrecer a empresas que necesiten cumplir con determinadas normativas. Un ejemplo de esto es PCI-DSS, obliga a empresas que permitan utilizar tarjetas de crédito en sus negocios online, cumplan una serie de requisitos. En el punto 6.6 se indica claramente que sus aplicaciones web deberán ser convenientemente auditadas periódicamente y/o protegidas mediante una herramienta WAF.

Lo sensato a la hora de proteger las aplicaciones web sigan o no metodologías de programación segura, desde mi punto de vista, es añadir más capas de seguridad, basadas en auditoría y en WAF. Una serie de auditorías programadas con una frecuencia determinada ayudan a determinar dónde están los puntos débiles a nivel de aplicación y obligar por supuesto a su corrección para la siguiente evaluación. Sin embargo, contar con un WAF que permita "parchear virtualmente" esas aplicaciones, disminuye el tiempo de exposición desde que se detecta un agujero hasta que se tapa, así como reaccionar ante determinados ataques Zero-Day de una manera mucho más ágil.

En una estrategia de seguridad por capas, la unión de ambas técnicas para la protección puede hacer que un "encargo" de obtener información sensible de una organización, fuerce al atacante a buscar por otro sitio que no sea la web,… y Trustwave, parece que también opina lo mismo.

Leer más...