Yahoo confirma el robo de 500 millones de cuentas de usuario

Yahoo ha publicado un comunicado en el que confirma que a finales del 2014 sufrió un robo de datos, que afectó al menos a 500 millones de cuentas de usuario.

En lo que ya se cataloga como el mayor robo de cuentas de usuario de la historia, la información substraída también es de gran alcance, al incluir nombres, dirección de e-mail, números de teléfono, fechas de nacimiento, el hash de las contraseñas (la mayoría con bcrypt) y en algunos casos las preguntas de seguridad y sus respuestas cifradas o sin cifrar. ¿Aun seguimos usando preguntas de seguridad?

Y aunque la investigación todavía está en curso, la propia firma cree que detrás del ataque se encuentra un Estado. Aunque tampoco aporta ninguna información sobre cómo llega a esa conclusión. También se señala que la información robada no incluía las contraseñas sin cifrar (¡solo faltaba!), datos de tarjetas de pago o información de cuentas bancarias.

Como es costumbre en estos casos, Yahoo dice lo habitual: que está notificando a los potenciales usuarios afectados, pidiendo a los usuarios que hayan podido verse afectados que cambien rápidamente sus contraseñas y adopten medios alternativos de verificación de la cuenta, está invalidado las preguntas de seguridad sin cifrar y las respuestas para que no se pueden usar para acceder a una cuenta, recomienda a todos los usuarios que no hayan cambiado sus contraseñas desde 2014 que lo hagan, que están mejorando sus sistemas para detectar y evitar accesos no autorizados a las cuentas y por supuesto están trabajando con las autoridades en esta materia.

Yahoo confirma "ahora" el robo de 500 millones de cuentas en 2014 https://t.co/e1n1rCIb9m

— hispasec (@hispasec) 23 de septiembre de 2016

Yahoo recomienda a los usuarios utilizar la herramienta Yahoo Account Key, una utilidad de autenticación que evita el uso de contraseñas mediante el uso del móvil.

La noticia no resulta extraña, los ataques de este tipo siempre han rondado a Yahoo, el mismo 2014 (cuando datan este robo) ya confirmó un intento de intrusión y el reinicio de las contraseñas de cuenta atacadas.  

Después de todo esto, quedan muchas cuestiones en el aire. ¿Cuándo supo Yahoo realmente el robo de los datos? ¿Desde 2014 no se ha dado cuenta del robo? ¿Qué datos tiene para afirmar que hay un Estado detrás del ataque? ¿Se filtrarán o se publicarán de alguna forma los datos? ¿Dejaremos de usar las preguntas de seguridad?

Más información:

una-al-dia (02/02/2016) Los sitios web que no amaban a las contraseñas

http://unaaldia.hispasec.com/2016/02/los-sitios-web-que-no-amaban-las.html

An Important Message About Yahoo User Security

https://yahoo.tumblr.com/post/150781911849/an-important-message-about-yahoo-user-security

Account Security Issue FAQs

https://help.yahoo.com/kb/account/SLN27925.html?impressions=true

una-al-dia (31/01/2014) Si usas Yahoo Mail cambia tu contraseña

http://unaaldia.hispasec.com/2014/01/si-usas-yahoo-mail-cambia-tu-contrasena.html

una-al-dia (27/04/2012) Grave fallo de seguridad en Hotmail permitía el robo de cuentas

http://unaaldia.hispasec.com/2012/04/grave-fallo-de-seguridad-en-hotmail.html

Antonio Ropero

antonior@hispasec.com

Twitter: @aropero

Vulnerabilidades en vBulletin exponen más de 27 millones de cuentas

Más de 27 millones de cuentas de usuarios, la mayoría del dominio mail.ru, se han visto expuestas debido a vulnerabilidades no parcheadas en foros con software vBulletin.

vBulletin es un software desarrollado por vBulletin Solutions, para la creación y mantenimiento de foros en Internet. Está basado en PHP y MySQL y según la propia compañía más de 100.000 sitios funcionan bajo este sistema, incluyendo compañías como Electronic Arts, Sony, NASA o Steam.

En total se han visto afectadas más de 27 millones de cuentas de usuario a través de casi una docena de sitios web. La mayoría de las cuentas comprometidas, hasta 25 millones, están vinculadas a los foros de tres juegos (CFire, Parapa y Tanks) alojados bajo el dominio mail.ru. También se han visto expuestas, más de 190.000 cuentas de expertlaw.com y más de 100.000 cuentas en gamesforum.com.

Según el grupo LeakedSource en torno a la mitad de contraseñas han sido fácilmente obtenidas mediante herramientas de cracking, debido a que todos los sitios usan alguna variación de MD5 con o sin salt única. Algo que como ya hemos comentado no es nada recomendable.

"Not a single website used proper password
storage, they all used some variation of
MD5 with or without unique salts."

Entre los datos filtrados se encuentran nombres de usuario, direcciones de correo, contraseñas, números de teléfono, direcciones IP y cumpleaños.

Los dominios afectados han sido:

• cfire.mail.ru
• parapa.mail.ru
• parapa.mail.ru (forums)
• tanks.mail.ru
• expertlaw.com
• ageofconan.com
• anarchy-online.com
• freeadvice.com
• gamesforum.com
• longestjourney.com
• ppcgeeks.com
• thesecretworld.com (inglés)
• thesecretworld.com (francés)
• thesecretworld.com (alemán)

Todos los sitios comprometidos funcionaban con una versión sin parchear del software vBulletin, que permitía la realización de ataques de inyección SQL a través del complemento (add-on) incluido Forumrunner en versiones anteriores a la 4.2.2 o 4.2.3. La actualización estaba disponible desde mediados de junio. Una vez más, la importancia de mantener actualizado todo el software.

La compañía Funcom ha reconocido la intrusión y el compromiso de los datos de los usuarios de los foros TheSecretWorld.com, AgeofConan.com, Anarchy-Online.com y LongestJourney.com. Aunque confirman que el software se actualizó el día 19 de agosto no pueden determinar exactamente cuando se produjo la intrusión. Como medida de seguridad temporal Funcon ha reiniciado todas las contraseñas de estos foros.

No es la primera vez que algún tipo de vulnerabilidad en este popular gestor de foros expone las cuentas de los usuarios de un foro. En 2013 se anunció una intrusión en el servidor correspondiente a los foros de la comunidad de Ubuntu (ubuntuforums.org), también se habían sustraído cuentas de correos de los usuarios así como los hashes de las contraseñas de acceso a los foros. Incluso, el propio equipo de vBulletin se vio obligado a reconocer una intrusión en su sitio oficial que comprometió hasta 480.000 cuentas de usuarios en un ataque combinado sobre la propia vBulletin.com y sobre el foro de Foxit Software.

Más información:

Leaked Source. Mail.ru

https://www.leakedsource.com/blog/mailru

una-al-dia (02/02/2016) Los sitios web que no amaban a las contraseñas

http://unaaldia.hispasec.com/2016/02/los-sitios-web-que-no-amaban-las.html

Security Update for vBulletin 4

http://www.vbulletin.com/forum/forum/vbulletin-announcements/vbulletin-announcements_aa/4345175-security-update-for-vbulletin-4

una-al-dia (31/07/2013) Crónica del ataque a los foros de Ubuntu

http://www.hispasec.com/unaaldia/5394

una-al-dia (03/11/2015) Intrusión en los foros de vBulletin y Foxit Software

http://unaaldia.hispasec.com/2015/11/intrusion-en-los-foros-de-vbulletin-y.html

Data Breach on Funcom Forums

http://www.funcom.com/news/data_breach_on_funcom_forums

Antonio Ropero

antonior@hispasec.com

Twitter: @aropero

Intrusión y múltiples vulnerabilidades en cPanel

cPanel ha publicado un aviso en el que reconocen haber sufrido una intrusión en su sitio oficial que ha podido exponer información de una base de datos de usuarios. Poco después de esta intrusión la compañía confirma hasta 20 vulnerabilidades en cPanel, que podrían explotarse por usuarios para manipular datos, elevar privilegios, insertar scripts, inyección SQL, obtener información sensible o realizar ataques de cross-site scripting.

CPanel es un conocido panel de control para empresas de alojamiento web, que a través de una sencilla interfaz web permite a usuarios de miles de compañías realizar de forma sencilla tareas como crear subdominios, añadir cuentas de correo, instalar scripts, proteger directorios, crear bases de datos. La administración de estas acciones puede realizarse por los propios usuarios sin necesidad de la intervención del personal técnico. CPanel está disponible para Linux y FreeBSD.

El pasado fin de semana cPanel confirmó un ataque sobre una de sus bases de datos y aunque había detenido la intrusión, anunciaba la posibilidad de que determinada información hubiera quedado expuesta. Según la compañía la información comprometida estaba limitada a nombres, información de contacto y el hash (con salt) de las contraseñas.

En cualquier caso confirmaba que la información de las tarjetas de crédito se encuentra almacenada en un sistema independiente diseñado para guardar las tarjetas de crédito y no se ve afectada por este ataque. cPanel anuncia un cambio a un sistema de cifrado de contraseñas más robusto y forzará a todos los usuarios a cambiar su contraseña.

Por otra parte, pocos días después de este anuncio la compañía publica un aviso en el que se corrigen un total de 20 vulnerabilidades. aunque no está confirmada ninguna relación entre la intrusión y estas vulnerabilidades.

Los problemas residen en ejecución de comandos arbitrarios debido a que no se filtra adecuadamente el directorio de trabajo actual ('.') de rutas cargadas desde la librería de módulos Perl, modificación de archivos arbitrarios durante la modificación de cuentas mediante enlace simbólico, lectura arbitraria de archivos a través de script bin/fmq y scripts/fixmailboxpath, inyección SQL en bin/horde_update_usernames, ejecución de código arbitrario a través de manipulación de archivos temporales o revelación de hashes de contraseñas por los scripts bin/mkvhostspasswd y chcpass.

También se han corregido problemas como que llamadas JSON-API permiten a cuentas cPanel y Webmail la ejecución de código mientras se ejecutan con privilegios de cuentas de usuario compartidas, lectura de archivos arbitrarios a través de bin/setup_global_spam_filter.pl y scripts/quotacheck, sobreescritura de archivos arbitrarios a través de scripts/check_system_storable y cambios arbitrarios de permisos de archivos (chown/chmod) durante el proceso de conversión de bases de datos para Roundcube.

Más vulnerabilidades corregidas podrían permitir la ejecución de código arbitrario a través de scripts/synccpaddonswithsqlhost, cambios de permisos de archivos a través de scripts/secureit y cross-site scriptings en WHM y en X3 y ejecución de código arbitrario sin necesidad de autenticación a través de cpsrvd.

Todas estas vulnerabilidades se han corregido en las versiones de cPanel:

11.54.0.4

11.52.2.4

11.50.4.3

11.48.5.2

Más información:

Important Information for cPanel Store Users

https://news.cpanel.com/important-information-for-cpanel-store-users/

cPanel TSR-2016-0001 Full Disclosure

http://news.cpanel.com/cpanel-tsr-2016-0001-full-disclosure/

Antonio Ropero

antonior@hispasec.com

Twitter: @aropero

Intrusión en los foros de vBulletin y Foxit Software

El equipo de desarrollo de vBulletin ha publicado un aviso en el que reconocen haber sufrido una intrusión en su sitio oficial que ha obligado al reinicio de todas las contraseñas de sus usuarios.

vBulletin es un software desarrollado por vBulletin Solutions, para la creación y mantenimiento de foros en Internet. Está basado en PHP y MySQL y según la propia compañía más de 100.000 sitios funcionan bajo este sistema, incluyendo compañías como Electronic Arts, Sony, NASA o Steam.

Un intruso, apodado "ColdZer0", afirmó que se había apropiado de un total de 480.000 cuentas de usuarios en un ataque combinado sobre la propia vBulletin.com y sobre el foro de Foxit Software. Todo indica que en ambas intrusiones se ha empleado la misma vulnerabilidad 0-day.

vBulletin ha publicado un aviso en el que reconocen la intrusión y el reinicio de todas las contraseñas. De tal forma, que todos los usuarios deben proceder como cuando se olvida la contraseña y solicitar el envío de una nueva por correo.

"We take your security and privacy very seriously. Very recently, our security team discovered a sophisticated attack on our network. Our investigation indicates that the attacker may have accessed customer IDs and encrypted passwords on our systems. We have taken the precaution of resetting your account password. We apologize for any inconvenience this has caused but felt that it was necessary to help protect your account."

Como es habitual recomiendan elegir una nueva contraseña, diferente a la anterior y que no se utilice en otros sitios.

Se ha publicado el siguiente vídeo:

https://www.youtube.com/watch?v=5x4upULiQ4s

La vulnerabilidad podría permitir a un usuario malicioso realizar ataques de inyección SQL sobre la base de datos, con todas las implicaciones que ello puedo llevar. Es decir, extraer toda la información y contenido de la base de datos, e incluso a partir de ahí comprometer todo el sistema.

Más información:

Password reset invoked after vBulletin.com forum software site defaced

http://www.theregister.co.uk/2015/11/03/vbulletin_forum_software_hacked_defaced/?mt=1446575306309

vBulletin.com Password Reset

http://www.vbulletin.com/forum/forum/vbulletin-announcements/vbulletin-announcements_aa/4332165-vbulletin-com-password-reset

vBulletin Zero-Day Used to Hack Official vBulletin Website and Foxit Software

http://news.softpedia.com/news/vbulletin-zero-day-used-to-hack-official-vbulletin-website-and-foxit-software-495620.shtml

                                                                                                  

Antonio Ropero

antonior@hispasec.com

Twitter: @aropero

Cuando barrer debajo de la alfombra hace arder la alfombra

Hoy toca una de brechas, millones de contraseñas y el uso del patrón 

PuesAMiNoMePareceQueSeEsteQuemandoFactory.

Empecemos por el peso, que es lo que le da a cualquier titular el brillo necesario para que destaque entre los otros cientos de titulares que el lector medio verá discurrir por su pantalla y pujan por su atención. 13 millones y medio de contraseñas, nombres, direcciones IP y otros datos. ¿Qué tal está eso? Nada mal. Pero si los comparamos a los 152 millones del Adobazo se queda corto.

La historia comienza cuando a Troy Hunt (@troyhunt), reconocido MVP de Microsoft y creador del servicio Have I been pwned? (haveibeenpwned.com) (metes tu email y te dice si anda por ahí metido en alguna lista de datos robados (o extraídos de algún sitio hackeado)), le contactan de manera anónima y le sueltan una información a cambio de nada: "Oye Troy, que se de un hacker que entró a 000webhost y está por ahí vendiendo una lista de cuentas, etc.". De esto hace cinco meses, en mayo de este año.

Tal y como Troy comenta en su propio blog, se ve en la tesitura de publicar o meter en la base de datos de su servicio información que todavía no se ha publicado o no ha sido noticia. Así que a menos que la información se haya hecho pública (entendemos por pública que la lista puede ser obtenida por algún método que no requiera el pago ilegal de la misma; receptación), Troy no va a publicarla. Evidentemente podemos imaginar que le ha podido llover alguna que otra propuesta de venta de primicia en datos robados.

¿Alguien dijo seguridad?

No fue el caso. No le pidió dinero. Ignoramos esa parte pero la lista terminó en el disco duro de Troy sin ningún tipo de mercadeo. Allí estaban alojados, 13 millones de cuentas con sus respectivas contraseñas en texto plano. Dando una vuelta por el servicio de 000webhost ya pudo observar algunas características que no auguraban nada bueno. Formularios de acceso enviados sin cifrar, correos donde se muestra la contraseña que acabamos de cambiar, versiones obsoletas, URLs con la contraseña adosada, etc. Quedó bastante claro que las prácticas de seguridad más básicas no eran muy apreciadas por los desarrolladores.

Hasta aquí queda bastante claro que el sitio tenía bastante probabilidad de ser objeto de un ataque. ¿Qué haces cuando tienes una lista de 13 millones de cuentas y ves que el sitio es altamente vulnerable?

Lo que comenta Troy a continuación es un símil bastante parecido a los que todos hemos sufrido cuando intentamos reclamar algo por teléfono. Una infraestructura orquestada y diseñada por una mente malévola con el único objeto de que el cliente (o víctima) termine la llamada fruto de la desesperación o traspase la frontera hacia el valle de la locura. Un autentico laberinto por el que creerás alcanzar la salida y cuando llegues a la puerta reconocerás el mismo lugar por el que pasaste otras tres veces. Resumiendo: se pasó días enteros rebotando de formulario en formulario sin que nadie le hiciera caso.

Al final la cosa derivó al terreno público y Troy buscó a usuarios de 000webhost vía Twitter. No tardó en saltar el resorte. Algunos usuarios se interesaron por el llamamiento y quedó claro lo que estaba pasando. Incluso un periodista del Forbes, Thomas Fox-Brewster, tomó nota del asunto e investigó hasta dar con una cuenta de Facebook donde parece que tocó hueso al comentar que estaba tratando de contactar con un responsable. Eso prendió fuego a la mecha.

Al final, sin previo aviso, resetearon las cuentas. Cientos de usuarios se quejaron de no tener acceso al servicio porque sus cuentas parecían bloqueadas. Un escueto mensaje dirigido al usuario: 

"…Debido a una verificación de seguridad de la plataforma y de su propia seguridad, el acceso al FTP de su cuenta ha sido deshabilitado hasta el 10 de noviembre de 2015…".
Nada más.

Nos quedamos con Fox-Brewester. No terminaron las sorpresas. Cuando por fin pudo contactar con Alec, "alguien" de la compañía, (le dieron un nombre de pila, se negaron incluso a sumarle un apellido) este no dio otro mensaje que el de confirmación del corte de acceso FTP y de que "responderían" pero que no estaban preparados para hacer comentarios en este momento.

¡Por fin!

La presión mediática que se les venía encima hizo el resto. Los responsables de la compañía matriz de 000webhost publicaron una entrada en Facebook donde, ahora sí, admitían el ataque, el robo de los datos e incluso una breve explicación de lo ocurrido. Tarde. Las respuestas de sus clientes, de pago y gratuitos, quemaron en muy poco tiempo las vanas esperanzas que depositaron en el descafeinado ejercicio de transparencia. Quejas, borrado de comentarios, más quejas.

Sobre el cómo del ataque no merece más detalle que dos líneas: PHP, versión obsoleta y subida de una shell.

¿Qué podemos aprender?

La dejadez que imperaba en el servicio se evidenciaba por la clara ausencia del elemento más común y básico de cualquiera infraestructura en informática: el puñetero cifrado de la información, tanto en tránsito como en reposo.

En segundo lugar, si alguien te dice que se te está quemando la casa, como mínimo, presta un gramo de atención.

Y en tercer y último lugar. Esto es Internet. La probabilidad de comprensión de tus clientes en un incidente así es inversamente proporcional a tu empeño por esconderlo elevado al tiempo que pases por no admitirlo.

Más información:

Breaches, traders, plain text passwords, ethical disclosure and 000webhost

http://www.troyhunt.com/2015/10/breaches-traders-plain-text-passwords.html

13 Million Passwords Appear To Have Leaked From This Free Web Host

http://www.forbes.com/sites/thomasbrewster/2015/10/28/000webhost-database-leak/

una-al-dia (05/11/2013) Adobe, la tormenta después de la tormenta

http://unaaldia.hispasec.com/2013/11/adobe-la-tormenta-despues-de-la-tormenta.html

David García

dgarcia@hispasec.com

Twitter: @dgn1729

Operación Cleaver: Irán detrás de ataques informáticos a 16 paises

Un informe de la compañía Cylance desvela las actuaciones de un grupo de atacantes iraníes que durante los dos últimos años han conseguido recopilar información de más de 50 organizaciones críticas en 16 países.

La compañía Cylance ha publicado un completo informe en el que detalla como desde al menos 2012 un grupo iraní ha estado atacando, se ha establecido de forma permanente y ha llegado a extraer información altamente sensible de redes de agencias gubernamentales y de compañías de infraestructuras críticas (transporte, comunicaciones energía…) de los siguientes países: Canadá, China, Inglaterra, Francia, Alemania, India, Israel, Kuwait, México, Pakistán, Qatar, Arabia Saudí, Corea del Sur, Turquía, Emiratos Árabes Unidos y los Estados Unidos.

Bautizado como "Operación Cleaver" debido a que la cadena "cleaver" aparece en múltiples piezas de software empleadas en los ataques (especialmente en diferentes rutas y directorios).

Todo indica a que Irán se ha tomado la revancha, podemos recordar como durante los años 2009 a 2012 fue víctima de diferentes campañas de sabotaje industrial y espionaje como Stuxnet, duqu o Flame. Estas muestras de malware se centraron en el programa nuclear iraní, y operaciones de petróleo y gas.

Según Cylance, el grupo de atacantes trabajaban desde Teheran (Irán) aunque se han identificado miembros auxiliares en otras localizaciones como Países Bajos, Canadá y el Reino Unido.

Los objetivos incluían instalaciones militares, gobiernos, servicios públicos, aerolíneas, aeropuertos, hospitales, empresas químicas y aeroespaciales. También compañías petroleras, de gas, de energía, de transporte, de telecomunicaciones y de tecnología.

Durante los dos últimos años, Cylance confirma que ha recogido más de 8 GB de información, que incluyen más de 80.000 archivos de datos extraídos, herramientas, registros de las víctimas y datos de reconocimiento altamente sensibles.

Metodología

Para realizar los ataques el grupo aprovechó con éxito tanto herramientas disponibles públicamente como otras personalizadas (en algunos casos la personalización pasaba por modificar el nombre del autor). Aunque evidentemente los métodos empleados han sido eficaces, tanto por haber logrado sus objetivos como por haber permanecido ocultos durante tanto tiempo, tampoco hay muchas novedades detrás de ellos (inyecciones SQL, campañas de spear phishing o uso de exploits públicos).

La campaña de Cleaver usa una variedad de métodos en múltiples etapas de ataques. El objetivo inicial era lograr la intrusión en la red atacada y conseguir la ejecución de código arbitrario. Para este compromiso se emplearon principalmente técnicas de inyección SQL y campañas de spear-phishing.

Después se trataba de lograr una elevación de privilegios, lo que permitía a los atacantes conseguir acceso a zonas restringidas del sistema, así como atacar otros sistemas de la red. Igualmente tampoco se empleaban técnicas novedosas, según Cylance han encontrado varios exploits públicos conocidos. PrivEsc un exploit compilado que explota la vulnerabilidad con CVE-2010-0232 sobre sistemas Windows sin actualizar, NetC (Net Crawler), un exploit en Python para aprovechar la vulnerabilidad MS08-067, Jasus y hasta el conocido Cain & Abel.

Para la extracción de datos el informe enumera diferentes servidores ftp anónimos. También se describe el uso de NetCat (también empleado como Shell inversa), que posteriormente fue reemplazado por una utilidad desarrollada por el equipo de Operación Cleaver que opera de forma similar a NetCat. También se ha usado PLink (utilidad incluida en la suite SSH PuTTY) y hasta el uso de correo mediante servidores SMTP con el relay abierto.

Para mantenerse en los sistemas atacados principalmente se utilizaron diferentes versiones de TinyZBot, una puerta trasera desarrollada en C#. Según indica el informe esta muestra de malware es el mayor desarrollo realizado por la organización (y aun así no fue desarrollada completamente por Cleaver).  

En el propio informe, con el objetivo de prevenir y detectar infecciones de esta amenaza, se comparten los IOCs (Indicators of Compromise) descubiertos durante la investigación. Estos incluyen dominios, direcciones de correo, direcciones IP, exclusiones mutuas, nombres de servicios instalados, MD5 y SHA-256 de cientos de muestras y firmas YARA.

Más información:

Operation Cleaver

http://www.cylance.com/assets/Cleaver/Cylance_Operation_Cleaver_Report.pdf

una-al-dia (19/10/2011) Duqu, ¿el nuevo malware descendiente de Stuxnet?

http://unaaldia.hispasec.com/2011/10/duqu-el-nuevo-malware-descendiente-de.html

una-al-dia (15/01/2011) Según el New York Times, Stuxnet fue creado por el gobierno de Estados Unidos e Israel

http://unaaldia.hispasec.com/2011/01/segun-el-new-york-times-stuxnet-fue.html

una-al-dia (29/05/2012) TheFlame: reflexiones sobre otra "ciberarma" descubierta demasiado tarde

http://unaaldia.hispasec.com/2012/05/theflame-reflexiones-sobre-otra.html

Antonio Ropero

antonior@hispasec.com

Twitter: @aropero

Intrusión en eBay

Esta vez le ha tocado a eBay, el gigante de las subastas online acaba de anunciar una intrusión en sus sistemas, por lo que recomienda a todos sus usuarios el cambio de contraseñas.

Este miércoles eBay ha reconocido que entre finales de febrero y principios de marzo (¡hace más de dos meses!), sufrieron una intrusión en sus sistemas y la base de datos de usuarios fue comprometida. Los datos afectados incluyen el nombre de los usuarios, contraseñas cifradas, dirección e-mail, dirección física, número de teléfono y fecha de nacimiento. Según confirman, la base de datos a la que lograron tener acceso los atacantes no contenía información financiera ni ningún otro tipo de información confidencial personal. No existe ninguna evidencia de acceso a datos como números de tarjetas de crédito, que se almacenan de forma separada de forma cifrada.

Según la nota publicada por eBay la intrusión se logró a través del compromiso de un pequeño número de credenciales de autenticación de empleados. Lo que permitió el acceso no autorizado a la red corporativa de eBay.

Como medida de seguridad, eBay recomienda el cambio de contraseñas a todos sus usuarios.

La compañía también ha confirmado que no hay evidencias de de acceso no autorizado o compromisos de información relativa a los usuarios de PayPal. Los datos de PayPal se guardan de forma separada en una red segura, y toda la información financiera de PayPal está cifrada.

Como ya hemos comentado en casos similares, la recomendación pasa siempre porque la compañía almacene las contraseñas en forma de hash usando una función sólida (sin problemas conocidos de seguridad) y aplicando buenas prácticas. Este tipo de funciones son teóricamente irreversibles, es decir, una vez almacenado el hash debería ser imposible conocer qué cadena (la contraseña) lo originó. Es lo que se conoce como criptografía asimétrica. Sin embargo eBay afirma que sus contraseñas estaban cifradas.

Como en otras ocasiones quedan preguntas en el aire:¿Como "cifraban" las contraseñas? y como ya viene siendo habitual ¿Cuanto tardarán los datos de los usuarios en aparecer en pastebin?

Como medidas de seguridad recodar las ya habituales, como no emplear la misma contraseña en diferentes sitios, cambiar regularmente la "password", así como emplear caracteres y símbolos en la contraseña. Usar de la misma contraseña en múltiples servicios hace al usuario vulnerable ante otros ataques.

Más información:

eBay Inc. To Ask eBay Users To Change Passwords

http://investor.ebayinc.com/releasedetail.cfm?ReleaseID=849396

una-al-dia (05/11/2013) Adobe, la tormenta después de la tormenta

http://unaaldia.hispasec.com/2013/11/adobe-la-tormenta-despues-de-la-tormenta.html

Antonio Ropero

antonior@hispasec.com

Twitter: @aropero

Crónica de la intrusión en blogs.perl.org

El pasado día 25, Aaron Crane, uno de los administradores del dominio blogs.perl.org, la plataforma de federación de blogs del lenguaje Perl, publicó una entrada donde anunciaba que el sitio había sido víctima de una intrusión. Los datos de casi 3000 cuentas de usuario habían sido publicados.

Vamos a analizar como se realizó la intrusión con la información que Crane y otros usuarios aportaron y que medidas tomaron tras el episodio.

La mañana del 22 de enero, los administradores del sitio, fueron alertados de la intrusión. No comentan si esta fue descubierta al ver las cuentas publicadas o el defacement. Los atacantes dejaron un mensaje reivindicativo en blogs.perl.org/icrg.php pero, al parecer, no tocaron el index. Algo bastante típico en este tipo de ataques, por lo que supuestamente el mensaje no aparecía visitando la raíz.

En el leak de las cuentas, subido a https://www.quickleak.org/QtPly6aE puede observarse la fecha del volcado de la base de datos: 21.01.2014 y la página creada el 22.01.2014 unas cuatro horas después, por lo que cabe la posibilidad de que alguien que lo viese diera la voz de alarma a los administradores. Tras el aviso, desactivaron la parte dinámica del sitio (los módulos Perl y PHP de Apache) para determinar que estaba ocurriendo, en ese momento solo se ofrecía contenido estático.

blogs.perl.org corre una plataforma Movable Type versión 4, podemos verlo simplemente accediendo al código HTML de cualquier página generada. Movable Type es una plataforma de contenido para blogs realizada en el lenguaje Perl para la gestión y PHP para la publicación. Esto es un dato curioso ya que los atacantes usaron PHP en el ataque mientras que la vulnerabilidad estaba presente en un módulo de Perl. Otro dato naturalmente importante es que la versión 4 ya no recibe soporte oficial desde hace bastante tiempo.

¿Qué vulnerabilidad usaron?

No usaron un 0day, ni una vulnerabilidad conocida pero sin exploit publicado, tampoco usaron una vulnerabilidad conocida con un exploit publicado al que hay que retocar algo el código para que funcione correctamente. En el ataque se usó una vulnerabilidad que permite inyectar código Perl arbitrario en remoto, sobre la que se conoce su existencia desde hace un año y de la cual se tiene un exploit funcional en la suite por excelencia: Metasploit (http://www.exploit-db.com/exploits/24321/)

La vulnerabilidad se encuentra en "mt-upgrade.cgi" cuya funcionalidad reside en “lib/MT/Upgrade.pm”. Esta vulnerabilidad se encuentra perfectamente descrita en http://www.sec-1.com/blog/2013/402 y tiene asignado el CVE-2013-0209.

Básicamente es un script que es usado durante la instalación y actualización de la plataforma. El problema es que puede ser invocado desde el exterior, sin necesidad de autenticación y (sin parche) contiene una función con un parámetro que efectúa un 'eval' sobre cualquier código Perl que inyectemos vía petición HTTP POST.

Afortunadamente para los usuarios que no podían permitirse la migración o actualización, Movable Type publicó un parche para las ramas afectadas: 4.2 y 4.3. Dicho parche fue publicado hace justamente un año, días antes del anunció de la vulnerabilidad.

Recapitulando, blogs.perl.org llevaba más de un año funcionando con una vulnerabilidad que permitía ejecutar código arbitrario en su sitio. Con un exploit publicado. Corriendo un software con una versión fuera de soporte y sin aplicar un parche que lleva igualmente un año disponible para tapar el agujero. La pregunta quizás no es por qué no se molestaron en revisar la seguridad sino como han sido capaces de permanecer intactos un año entero…si es que realmente han permanecido intactos.

Evaluación de daños

Aunque no lo relatan directamente es bastante probable que los atacantes usaran la vulnerabilidad para subir una shell en PHP. Crane comenta en la entrada "borramos la herramienta del atacante", por lo que es asumible que hicieran esto último.

Las medidas que tomaron fue el borrado del script PHP, aplicación del parche correspondiente y otro parche más, creado por ellos mismos, que cambia el algoritmo de generación de los hashes a SHA-512.

Públicamente solo se tiene conocimiento del mensaje y el leak de la tabla "mt_author" que contiene, entre otros datos, el correo, contraseña y nombre.

De las contraseñas se almacena el hash usando la función "crypt" de Perl, básicamente una envoltura de la función correspondiente de la librería C (ver "unistd.h" o man 3 crypt). Esta función contiene dos parámetros: un texto en claro y una sal y devuelve el hash en forma de 13 bytes siendo los dos primeros la sal. Se puede "experimentar" con la función con un simple oneliner:

perl -e ‘ print crypt(“cadena”, “sal”) . “\n” ’

Internamente “crypt” usa el algoritmo DES ligeramente modificado, aunque puede utilizar otros. Solo se usan los ocho primeros bytes de la cadena por lo que las contraseñas ven reducidas su longitud efectiva a ese tamaño. DES y su actualización Triple DES son considerados inseguros y sobre ellos pueden usarse diversos tipos de ataques con éxito. Otra nota curiosa es que la función, tanto en Perl como en C, es llamada "crypt" lo que hace pensar erroneamente que se "cifran" las contraseñas.

El verdadero problema de los leaks con los hashes es el uso cruzado que puede darse de las contraseñas. Teniendo información del usuario (correo, nombre, etc) puede darse el caso de que una misma contraseña sea usada en múltiples sitios (ssh, correo, ftp…). En una conversación privada se ha comentado que con un simple portátil alguien ya ha conseguido el 20% de las contraseñas en solo 3 horas.

Cuando ocurre una brecha de esta clase cabe preguntarse ¿Hasta donde han podido ramificar el ataque? ¿Le habrá dado tiempo al usuario x a cambiar esa contraseña que usa también en el repositorio de código, donde guardan celosamente el código fuente de una aplicación de miles de dólares?

David García

dgarcia@hispasec.com

Twitter: @dgn1729

Ataque masivo de fuerza bruta contra los usuarios de GitHub

Github, el popular servicio de hospedaje de código fuente, ha publicado una entrada en su blog para informar de la detección de un ataque distribuido de fuerza bruta contra las cuentas de sus usuarios.

En principio, según GitHub, parece ser que el ataque se ha originado desde unas 40.000 IPs, lo que hace pensar que proviene de una botnet. Aunque aun se encuentran investigando el impacto del ataque, algunas cuentas han sido bloqueadas debido a que se ha detectado actividad desde las IPs atacantes, lo cual indica que el ataque de fuerza bruta ha tenido éxito sobre algunas cuentas de usuario.

No se comenta que tipo de actividad, pero desde una cuenta de usuario de GitHub se puede manipular código de un repositorio. GitHub permite editar el código directamente desde su interfaz web, o añadir claves privadas que permiten operar desde remoto contra el repositorio.

Respecto de las defensas de GitHub, tienen limitado el número de autenticaciones fallidas por cuenta, lo que ha motivado que el ataque se haya efectuado "a fuego lento" con un ratio bajo de prueba-error por cada cuenta de usuario. Los atacantes intentaron permanecer por debajo del radar.

No se conoce cuando se inició el ataque, pero revisando el histórico de seguridad algunos usuarios han detectado IPs desde ciertos países ajenos a ellos con intentos de hace más de cinco días.

Desde GitHub recomiendan revisar el histórico de seguridad, crear una contraseña fuerte y activar autenticación de dos factores.

Llama la atención una cosa: A partir de ahora GitHub no permitirá crear una contraseña débil. O lo que es lo mismo: GitHub permitía hasta hoy, como otros tantos sitios, crear una contraseña débil. Esto, junto con la práctica de compartir la misma credencial en varios sitios, es un eslabón demasiado frágil que está siendo aprovechado por los atacantes. Sirva de ejemplo el reciente ataque a Adobe, donde las contraseñas de los usuarios, cifradas inadecuadamente, también servían para autenticarse en otros sitios no relacionados.

El ataque que estamos comentando es muy sonoro, prácticamente casi todos los usuarios tienen registros de intentos fallidos de autenticación, eso no pasa sin ser detectado ya que produce demasiado ruido a pesar de que el ataque ha limitado su ratio de intentos.

¿Pero que hubiera ocurrido si hubiesen concentrado el ataque en unos pocos proyectos grandes, con muchos desarrolladores, donde una pequeña cuenta es capaz de inyectar un trozo de código que pasase desapercibido entre multitud de líneas?

Más información:

Weak passwords brute forced

https://github.com/blog/1698-weak-passwords-brute-forced

About Two-Factor Authentication

https://help.github.com/articles/about-two-factor-authentication

GitHub Security

https://github.com/settings/security

una-al-dia (05/11/2013) Adobe, la tormenta después de la tormenta

http://unaaldia.hispasec.com/2013/11/adobe-la-tormenta-despues-de-la-tormenta.html

David García

dgarcia@hispasec.com

Twitter: @dgn1729

Adobe, la tormenta después de la tormenta

Tras reconocer el robo del código fuente de varios de sus productos y la información personal de casi tres millones de usuarios y clientes, se han ido haciendo públicos varios análisis que ponen en cuestión el procedimiento usado por Adobe para almacenar las credenciales.

Los datos extraídos alcanzan casi los 10Gb. Unos 130 millones de credenciales que Adobe ha ido almacenando a lo largo de varios años. Entre las cuentas robadas pueden observarse algunas que pertenecen a agencias del gobierno norteamericano tales como el FBI.

El problema hubiera sido "menor" si estas credenciales hubieran estado almacenadas en forma de hash usando una función sólida (sin problemas conocidos de seguridad) y aplicando buenas prácticas. Este tipo de funciones son teóricamente irreversibles, es decir, una vez almacenado el hash debería ser imposible conocer qué cadena (la contraseña) lo originó.

Adobe, sin embargo, no optó por almacenar los hashes de las credenciales. En vez de ello las contraseñas eran cifradas con un algoritmo denominado TripleDES. Este algoritmo simétrico surgió debido a un problema de seguridad en el algoritmo DES relacionado con la longitud de clave (56 bits).

TripleDES es el resultado de encadenar tres veces el algoritmo DES en cada bloque de datos. Un método simple de prolongar la longitud de clave (168 bits) para reusar el DES y no invertir en el diseño de un nuevo algoritmo. Pero como suele ser habitual en seguridad, era cuestión de tiempo para que surgieran ataques sobre TripleDES, como "Meet-in-the-middle" o a través del cifrado aislado de porciones conocidas de texto claro que se sospechen estén incluidas dentro del texto cifrado. Todos estos ataques tienden a reducir la efectividad de la longitud de clave.

Además, en el caso de Adobe se usó TripleDES con el método ECB (Electronic CodeBook). Esto quiere decir que el texto claro se separa el bloques de idéntico tamaño y es cifrado de manera independiente. El resultado final es que dos porciones o bloques que tengan el mismo texto claro tendrán la misma apariencia cuando sean cifrados. No es necesario decir que esto representa una ventaja enorme para el atacante.

Una mala práctica el escoger un cifrado simétrico para almacenar las contraseñas cifradas y otra peor al escoger un algoritmo con problemas conocidos y para terminar de empeorarlo la selección de una configuración débil en la aplicación de la función de cifrado.

En el lado ético de la cuestión nos queda preguntarnos: ¿Por qué Adobe cifró las credenciales con un cifrado simétrico en vez del hash? Esto, significa que Adobe tenía la llave para conocer las credenciales de sus usuarios y clientes. Algo que por hacer una correspondencia mundana es como si cuando compras una casa el que te la vendió se queda una copia de la llave, por si acaso...

Por supuesto los ataques contra el cifrado no se han hecho esperar y ya hay una lista con el top 100 de las contraseñas más usadas. Sin sorpresa alguna dejamos aquí constancia de las 10 primeras:

#	Nº de veces	Texto cifrado	Texto plano
1.	1.911.938	EQ7fIpT7i/Q=	123456
2.	446.162	j9p+HwtWWT86aMjgZFLzYg==	123456789
3.	345.834	L8qbAD3jl3jioxG6CatHBw==	password
4.	211.659	BB4e6X+b2xLioxG6CatHBw==	adobe123
5.	201.580	j9p+HwtWWT/ioxG6CatHBw==	12345678
6.	130.832	5djv7ZCI2ws=	qwerty
7.	124.253	dQi0asWPYvQ=	1234567
8.	113.884	7LqYzKVeq8I=	111111
9.	83.411	PMDTbP0LZxu03SwrFUvYGA==	photoshop
10.	82.694	e6MPXQ5G6a8=	123123

Ahora cabría preguntarse de qué lado está la responsabilidad a la hora de elegir una buena llave para la casa.

  

Más información:

Adobe anuncia el robo de código fuente y datos de casi 3 millones de usuarios

http://unaaldia.hispasec.com/2013/10/adobe-anuncia-el-robo-de-codigo-fuente.html

twitter: @Sc00bzT

https://twitter.com/Sc00bzT/status/396114231436644352

Top 100 Adobe Passwords with Count

http://stricture-group.com/files/adobe-top100.txt

  

David García

dgarcia@hispasec.com

Twitter: @dgn1729