jueves, 31 de octubre de 2013

Intrusión en la red de la compañía MongoHQ

MongoHQ, la firma que da soporte profesional y alojamiento a usuarios de la base de datos MongoDB, ha informado en un comunicado que han detectado una intrusión en sus servidores. Según la compañía los atacantes podrían haber accedido a la base de datos de cuentas de usuarios.

MongoDB es una base de datos NoSQL, programada en C++ y licenciada bajo GNU AGPL. MongoDB fue publicada por primera vez en 2009, su uso se encuentra bastante extendido en la industria.

El pasado día 28 de octubre, los técnicos del equipo de operaciones de MongoHQ detectaron un acceso no autorizado a una aplicación interna orientada al soporte. Los atacantes habían usado unas credenciales provenientes de una cuenta comprometida. La aplicación interna permite acceder a información de cuentas, lista de bases de datos, direcciones de correo electrónico y las credenciales de los clientes en forma de hash utilizando el algoritmo bcrypt.

El problema es que dicha aplicación de soporte permite a cualquier técnico autenticado acceder al portal principal de los clientes con los mismos privilegios que estos para realizar tareas de soporte. En ese portal el cliente puede consultar sus datos almacenados y administrar sus instancias privadas de MongoDB.

Los responsables dan por hecho que los atacantes han tenido acceso a los datos de conexión de los clientes y a través de la auditoría que están llevando a cabo han detectado accesos a los datos almacenados utilizando las credenciales que guardaban. Es decir, que ciertas bases de datos de sus clientes han sido volcadas (se desconoce si parcial o totalmente) por los intrusos.

La respuesta de MongoHQ fue detener los servicios implicados y proceder a efectuar un análisis forense y auditoría. Se han desactivado las cuentas de los técnicos y rehabilitado tras cambiar sus credenciales. También se han puesto en contacto con los clientes afectados directamente, al menos sobre los que tienen evidencia de que sus datos han sido accedidos.

Sobre las medidas que van a imponer a partir de ahora, anuncian la imposición de un sistema de doble autenticación, acceso exclusivo a través de VPN y la dotación de permisos graduales basados en el mínimo privilegio necesario. Además planean cifrar el contenido importante que administren las aplicaciones.

Resulta evidente que este anuncio de medidas es equivalente a decir que carecían de ellas. No es fácilmente digerible que una arquitectura que almacena datos, supongamos muy valiosos, de terceros no tuviera ya una rigidez y fiabilidad desde el punto de vista de la seguridad. Sorprende sobre todo el último punto, que no tuvieran establecido un sistema de credenciales basados en el mínimo privilegio, algo básico.

Otro de los puntos reseñables en el comunicado es la invalidación de credenciales de Amazon Web Services que sus clientes tenían almacenadas en MongoHQ. Dichas cuentas eran usadas para realizar copias de respaldo en la infraestructura S3 de Amazon.

Por supuesto, como primera medida a tomar, aconsejan cambiar las credenciales de acceso a los servicios.

MongoHQ irá comunicando, a medida que aparezcan nuevos hallazgos, información sobre el incidente.

Más información:

MongoHQ Security Breach

bcrypt


David García

Twitter: @dgn1729

miércoles, 30 de octubre de 2013

Publicado Firefox 25

Mozilla ha anunciado la publicación de la versión 25 de Firefox que incluye nuevas mejoras y la corrección de 15 nuevas vulnerabilidades.

Entre las novedades incluidas se incluye el soporte de "Web Audio", la barra de búsqueda ya no se comparte entre pestañas, el "reseteo" de Firefox no elimina las sesiones de navegación, soporte de background-attachment:local CSS3, implementación de nuevas funciones ES6 y se ha corregido la página al abrir una nueva pestaña.

Por otra parte, se han publicado 10 boletines de seguridad que corrigen 15 vulnerabilidades con Firefox 25: 10 de impacto crítico, tres de gravedad alta y dos moderadas

MFSA 2013-102: Boletín considerado crítico por un uso después de liberar al interactuar con plantillas de documentos HTML (CVE-2013-5603).

MFSA 2013-101: Soluciona una corrupción de memoria en el motor JavaScript (CVE-2013-5602).

MFSA 2013-100: Corrige tres vulnerabilidades críticas de reutilización de memoria liberada (use after free)
en el motor de navegación (CVE-2013-5599, CVE-2013-5600 y CVE-2013-5601).

MFSA 2013-99: Soluciona una vulnerabilidad de impacto alto, de salto de restricciones que podría permitir a un atacante la obtención de archivos del sistema remoto (CVE-2013-5598).

MFSA 2013-98: Soluciona una vulnerabilidad crítica, por reutilización de memoria previamente liberada al actualizar la cache offline (CVE-2013-5597).

MFSA 2013-97: Destinado a corregir una vulnerabilidad de gravedad alta al cargar páginas muy largas (CVE-2013-5596).

MFSA 2013-96: Boletín de carácter moderado, por desbordamientos debidos a una inicialización inadecuada de algunas funciones JavaScript (CVE-2013-5595).

MFSA 2013-95: Boletín considerado de importancia alta, por una violación de acceso debido a datos no inicializados durante el procesamiento XSLT (Extensible Stylesheet Language Transformation) (CVE-2013-5604).

MFSA 2013-94: Soluciona una vulnerabilidad de gravedad moderada, que podría permitir la falsificación de la barra de direcciones (CVE-2013-5593).

MFSA 2013-93: Soluciona cuatro vulnerabilidades críticas relacionadas con fallos de seguridad de memoria (CVE-2013-5590, CVE-2013-5591, CVE-2013-5592 y CVE-2013-1739).

La nueva versión está disponible a través del sitio oficial de descargas de Firefox: http://www.mozilla.org/es-ES/firefox/new/

Más información:

Firefox Notes

MFSA 2013-102 Use-after-free in HTML document templates

MFSA 2013-101 Memory corruption in workers

MFSA 2013-100 Miscellaneous use-after-free issues found through ASAN fuzzing

MFSA 2013-99 Security bypass of PDF.js checks using iframes

MFSA 2013-98 Use-after-free when updating offline cache

MFSA 2013-97 Writing to cycle collected object during image decodingç

MFSA 2013-96 Improperly initialized memory and overflows in some JavaScript functions

MFSA 2013-95 Access violation with XSLT and uninitialized data

MFSA 2013-94 Spoofing addressbar though SELECT element

MFSA 2013-93 Miscellaneous memory safety hazards (rv:25.0 / rv:24.1 / rv:17.0.10)



Antonio Ropero
Twitter: @aropero

martes, 29 de octubre de 2013

Evasión de restricciones en RSA Authentication Agent para IIS

Se ha confirmado la existencia de una vulnerabilidad en RSA Authentication Agent para servidores Web Microsoft IIS, que podría permitir a un atacante remoto evitar la autenticación de doble factor.
  
RSA Authentication Agent se usa conjuntamente con el software RSA Authentication Manager como solución para organizaciones que busquen el uso de autentificadores RSA SecurID para proporcionar autentificación de usuarios de doble factor.

En determinadas circunstancias, puede evitarse la protección del RSA Authentication Agent para servidores Web para IIS debido a que tiene un diseño de "fail-open". Esta vulnerabilidad (con CVE-2013-3280) podría permitir a atacantes remotos evitar las restricciones de acceso mediante vectores que provoquen una caída del agente.

Un diseño "fail-open" significa que cuando un servicio o sistema falla, todo el tráfico de red (independientemente de lo que sea) no se procesa y pasa de forma transparente al siguiente componente de destino. Por eso, en este caso debido a que por defecto se encuentra activa la politica de "fail-open" es posible evadir completamente el mecanismo de autenticación. Por otra parte una política "fail-close" resulta mucho más paranoica, evitando todo el tráfico ante una parada del dispositivo.

Se ven afectadas las versiones 7.1.x anteriores a 7.1.2. Se ha publicado la versión 7.1.2 para solucionar el problema.

Más información:

Vulnerability Summary for CVE-2013-3280

RSA Authentication Agent for Web for Internet Information Services (IIS) Security Controls Bypass Vulnerability


Antonio Ropero
Twitter: @aropero


lunes, 28 de octubre de 2013

15 años de una-al-día

Lo reconocemos, somos un poco pesados y en ocasiones hasta podemos resultar agobiantes. Y es que 15 años, recibiendo día tras día noticias de problemas, vulnerabilidades, troyanos, y de la (in)seguridad existente en la Red puede desesperar a cualquiera.

El 28 de octubre de 1998 Bernardo Quintero escribía una noticia de seguridad informática para un pequeño grupo de amigos: "Service Pack 4, los problemas de la solución". La noticia versaba sobre la publicación del pack de servicio número 4 del sistema operativo Windows NT 4.0. Días después se le fueron uniendo otras voces: Antonio Ropero y Antonio Román. Dos meses después se crearía HispasecSistemas (que poco después se formaría como empresa de servicios de seguridad informática), proyecto al que después se uniría Jesús Cea.

Casi 5.500 noticias-días después "Una-al-día" continua con el espíritu con el que nació. Tal como reza en el propio eslogan: "Primer diario de información técnica sobre seguridad informática en español". A lo que podríamos añadir "independiente" y siempre intentado, desde el respeto, ofrecer una perspectiva diferente o alternativa a la oficialidad.

Durante este trayecto hemos ido progresando poco a poco, añadiendo nuevos canales de transmisión paralelos a la lista de correo e incluso dotando a Una-al-día de una renovada imagen con el fin de actualizar su formato y hacerlo más cómodo al lector. Eso sí, aun mantenemos el viejo modelo de la "news-letter" original en modo texto, pero los lectores siempre pueden acudir a nuestra webpara leerla en un formato más atractivo, con enlaces e imágenes. También disponemos de un twitter (@unaladia) oficial para aquellos usuarios que prefieren este canal.

Respecto a su contenido, decir que poco va a variar en su fondo tradicional salvo la introducción de entrevistas a personalidades del mundillo de la seguridad, agradecemos de nuevo a Brian Krebs y a Carlos Pérez su colaboración y disposición. Contenido que creíamos interesante añadir y era una nueva experiencia que deseábamos aportar. Seguiremos publicando nuevas entradas de este tipo, del que nos consta ha gustado a los lectores.

Hoy cumplimos 15 años ofreciendo ese contenido. Puede parecer que el panorama no ha cambiado mucho desde entonces y que no quede mucho resquicio al optimismo. Las noticias siguen siendo muy parecidas: "nueva vulnerabilidad en…", "Actualización para…", "un troyano que afecta a…", sin embargo sí han cambiado muchas cosas.

El panorama ha cambiado bastante en el mundo hispano. Desde unas pocas webs y listas de correo, cabe señalar la cada vez mayor comunidad de personas y profesionales que ofrecen una gran cantidad de contenidos de calidad. La preocupación por la seguridad de empresas, usuarios, desarrolladores, medios, etc. es creciente y cada vez mayor. La seguridad ha pasado de ocupar un puesto secundario a ser algo primordial para todos. Señal inequívoca es el salto, salvando las distancias, de este tipo de noticias desde canales especializados a medios generalistas.

Una-al-día no sería nada sin sus lectores. Les pertenece. A ellos les agradecemos profundamente su tiempo y dedicación. También como no sus críticas sin las cuales no podríamos mejorar nuestro trabajo. Agradecer a nuestros colaboradores su desinteresada ayuda, en especial al profesor Jorge Ramió Aguirre, director de Criptored.

Desde Hispasec seguiremos trabajando para ofrecer a los lectores de "Una-al-día" su noticia diaria de información técnica sobre seguridad informática en español.

De parte del equipo de redacción de Una-al-día: ¡Muchas gracias a todos!

Más información:

una-al-dia (28/10/1988) Service Pack 4, los problemas de la solución.

una-al-dia (25/07/2013) Entrevista a Brian Krebs

una-al-dia (18/09/2013) Entrevista a Carlos Pérez. "Metasploit ha cambiado la industria y lo seguirá haciendo"


Laboratorio Hispasec


domingo, 27 de octubre de 2013

Salto de restricciones e inyección de comandos en router WNDR3700v4 de Netgear

En una serie de dos artículos, el investigador Zack Cutlip (@zcutlip) ha localizado varias vulnerabilidades en la versión 4 del router inalámbrico WNDR3700 de Netgear. Estas, entre otros impactos, permitirían acceder a la interfaz de administración sin necesidad de autenticación y la inyección de comandos al sistema operativo del dispositivo. Están confirmadas en las versiones 1.0.1.42 y 1.0.1.32 del firmware.

Router Netgear WNDR3700v4
Cutlip desgrana, a través del estudio del manejo de las peticiones, las diferentes vulnerabilidades descubiertas. Cuando se pide un recurso al router, se comprueba que su nombre coincida con el patrón asociado a uno de los manejadores MIME. Esto se hace buscando el patrón como subcadena del recurso. Si se encuentra, se le aplica su manejador de autenticación asociado.

Poniendo como ejemplo el mismo que se utiliza en el articulo, una de las entradas en la tabla de patrones MIME es "BRS_". La función de autenticación para estos recursos es un puntero nulo. Por tanto, cualquier recurso que contenga la cadena "BRS_" no necesita autenticación. Son muchas las páginas que cumplen esta condición en la interfaz. Como ejemplo, la que muestra la contraseña de la conexión WPA del dispositivo.

Otras páginas permiten el salto de las restricciones de autenticación con el mismo método. Para controlar qué páginas requieren autenticación, comprueban que el patrón (que no es más que el nombre de la página), sea subcadena *de la petición*, y no comparan con el nombre de recurso en si. Esto se permite que se sirvan páginas restringidas si la petición contiene el nombre de una de las páginas que no lo están. Por ejemplo, en una petición como http://router/pagina_protegida.htm?foo=unauth.cgi se podría acceder a la página protegida, ya que unauth.cgi, que salta las restricciones, se encuentra como subcadena.

Como colofón, Cutlip termina con un salto de restricciones persistente. En este dispositivo, el valor de la variable hijack_process controla si se debe aplicar la autenticación en todas las páginas de la interfaz. Esta funcionalidad se aplica durante el primer inicio del router. En vez de usar una contraseña por defecto, directamente se deshabilita la autenticación hasta que esté configurado. Cuando se configura, hijack_process toma el valor 3, con el que indica que la autenticación debe aplicarse.

Sin embargo, existe una página pública de la interfaz del dispositivo (BRS_02_genieHelp.html) que da a hijack_process un valor distinto de 3, con lo que una sola petición a esa página permitiría desactivar la autenticación en todo el dispositivo. Como la variable se guarda en RAM no volátil, este estado permanece aunque el dispositivo se reinicie.

Además, también se ha encontrado una vulnerabilidad que permite la inyección de comandos al sistema operativo subyacente del router a través de la página de ping a direcciones IPv6. El comando con la dirección dada por el usuario se le pasa a la función system, que llama a /bin/sh. Por tanto, si pasamos en lugar de la IP una cadena de la forma "; comando;", la ejecución del ping falla, pero podemos inyectar código. Ya se ha publicado una prueba de concepto que abre una conexión telnet y permite el acceso como administrador sin autenticación.

Las vulnerabilidades se han probado en la versión 4 del modelo WNDR3700 de Netgear, con los firmwares 1.0.1.42 y 1.0.1.32, y en el 4700. El autor acredita a Jacob Holocomb (que encontró la esta misma vulnerabilidad en el modelo WNDR4700) y Craig Young, que hizo este descubrimientos el pasado abril pero no lo publicó (https://twitter.com/zcutlip/status/393752865187328000).

Según el portal The Register, Netgear ha prometido un parche que solucione la vulnerabilidad en el plazo de un mes, aunque apunta que solo es explotable si el atacante se encuentra en la misma red que el dispositivo.

Más información:

Complete, Persistent Compromise of Netgear Wireless Routers

Netgear Root Compromise via Command Injection

Netgear router admin hole is WIDE OPEN, but DON'T you dare go in, warns infosec bod



Francisco López



sábado, 26 de octubre de 2013

Actualizaciones automáticas a partir de Wordpress 3.7

Wordpress, el popular gestor de contenidos orientado a la creación de blogs, marca un antes y un después en su política de seguridad tras publicar la versión 3.7, nombre en clave "Basie".

La principal característica es la capacidad de actualizaciones autónomas a partir de esta versión. Wordpress no anunciará al administrador que hay actualizaciones disponibles sino que directamente se actualizará con los parches de mantenimiento y seguridad que se vayan publicando. Eso sí, existe una opción para filtrar según que tipo de actualización esté disponible. Por ejemplo, podremos decidir si también actualizamos los complementos y temas al igual que el núcleo de Wordpress o dejar su actualización a nuestro cargo.

Wordpress se suma así a la tendencia que popularizó Google Chrome: Actualizaciones transparentes al usuario. Un paso que no se ha dado sin motivación.

Recientemente, un estudio realizado por WP WhiteSecurity, determinó que más de un 70% sobre una base de más de 40.000 instalaciones eran vulnerables. Algunas versiones detectadas, como la 3.3.1, con hasta 24 vulnerabilidades sin parchear. Esto sin contar los innumerables complementos y temas con agujeros críticos de seguridad que permiten el compromiso del sitio con relativa facilidad. Como muestra: una búsqueda de exploits para Wordpress en el sitio www.exploit-db.com devuelve 7 resultados para complementos y temas… tan solo en el mes de octubre, y la mayoría de ellos permite subir archivos de manera arbitraria o inyección ciega de código SQL.


Dentro de las estadísticas internas del equipo Antifraude de Hispasec, Wordpress suele copar los primeros puestos de plataformas usadas para alojar malware o phishing, casi siempre, eso si, muy cerca de otro CMS popular: Joomla.

Otra característica interesante es la integración de la librería 'zxcvbn'. Esta librería, escrita en su mayor parte en Coffescript, realiza un análisis de la contraseña con la que el usuario va a autenticarse en el sistema indicándole cuando esta es considerada débil. Esto servirá para paliar en parte la elección de contraseñas sencillas que favorecen las posibilidades de éxito en ataques de fuerza bruta, diccionario o híbridos sobre cuentas de usuarios.

Finalmente, en el documento de cambios, señalan también que se han solucionado más de 400 tickets de mantenimiento. Esta versión no incluye ningún parche de seguridad más allá de las mejoras comentadas.

Sin lugar a dudas una versión interesante desde el punto de vista de la seguridad que podría ayudar a acortar la ventana de exposición ante vulnerabilidades publicadas.

Más información:

WordPress 3.7 “Basie”

Version 3.7

Statistics Show Why WordPress is a Popular Hacker Target

realistic password strength estimation



David García
Twitter: @dgn1729


viernes, 25 de octubre de 2013

Comprometen el sitio oficial de PHP para alojar malware

El sitio web oficial del lenguaje de programación PHP ha sido comprometido y usado para infectar con malware a los visitantes.

Aunque en un primer momento, incluso el propio Rasmus Lerdorf (@rasmus), creador de PHP, pensó que se trataba de un falso positivo, el primer aviso lo dio el motor de bloqueo de Google Chrome, Safe Browsing. En el se podía leer que el motivo del bloqueo era la detección de malware alojado en el sitio web principal de PHP. Exactamente el script

Dicho script contenía código ofuscado que generaba un iframe oculto el cual cargaba otro script adicional, de un tercer dominio, para finalmente acabar siendo víctima del exploit kit Magnitude. Un esquema habitual usado por los atacantes para atraer gran cantidad de objetivos (un sitio popular) y alargar en lo posible la infección (código ofuscado, iframe oculto y múltiples dominios maliciosos). Existe un excelente análisis del proceso de infección realizado por Jaime Blasco de Alienvault.

Tras descartar el falso positivo y eliminar el malware del sitio oficial, los administradores de php.net han publicado una nota de prensa admitiendo la intrusión y el alojamiento de malware por parte de los atacantes.

Aunque todavía se encuentran trabajando en la investigación para llegar a conclusiones, los administradores han situado la ventana de exposición entre el día 22 y 24 de octubre. Durante esos días haber visitado los sitios web de php.net que incluyesen un enlace al script userpref.js significa que se ha estado expuesto a la infección.

En principio han sido comprometidos dos servidores. El principal alojaba los sitios www.php.net, static.php.net y git.php.net. Este último dominio es el que lleva al repositorio de código de todo el proyecto PHP, no solo la vista web del repositorio, sino el servidor GIT (puerto tcp/9418). Aunque según informan han comprobado que el repositorio de código no se ha "tocado" como precaución se ha bloqueado en modo lectura y migrado a otro servidor. El otro servidor se correspondería con el dominio bugs.php.net y aloja el sitio web de reporte de errores.

Como medida de precaución los certificados han sido revocados, ya que podrían haber sido extraídos por los atacantes. Es decir, llegaron a tener los privilegios necesarios para leer dichos archivos. De momento los servicios SSL no van a funcionar hasta que sean emitidos nuevos certificados. Un ejemplo perfecto para justificar el mecanismo de revocación de certificados.


Declaran que solo un pequeño porcentaje de usuarios del sitio ha sido expuesto a la infección. Esto es algo que cuesta entender sin una argumentación clara, sobre todo teniendo en cuenta que se ha usado un kit de explotación y no un solo exploit. Los kit de explotación son verdaderos cócteles de exploits con capacidad de detección de complementos del navegador vulnerables y soporte multiplataforma.

Adicionalmente las cuentas de los desarrolladores van a ser reiniciadas como medida de precaución.

Estaremos atentos para cuando publiquen, como han anunciado, un post-morten de la investigación que están llevando a cabo. Va a ser interesante ver hasta donde y como han llegado a colgar un script de infección en la web de uno de los lenguajes más usados para construir sitios y aplicaciones web. Según el ranking de Alexa, www.php.net es uno de los 250 sitios más visitados de Internet.

Más información:

PHP.net

Twitter. Rasmus Lerdorf

PHP.net potentially compromised and redirecting to an exploit kit

A further update on php.net

Alexa. Php.net



David García

Twitter: @dgn1729

jueves, 24 de octubre de 2013

Apple publica OS X Mavericks v10.9 de forma gratuita y corrige varias vulnerabilidades

Apple ha publicado la primera actualización gratuita para su sistema operativo OS X bajo el nombre de Mavericks. La nueva versión introduce varias soluciones a fallos de seguridad. Además, se han lanzado varios boletines de seguridad para otros productos entre ellos iOS 7 y Safari 6.1.

La "keynote" de ayer dejo una buena noticia para los usuarios de Apple. La última versión de OS X, de nombre Mavericks, se publicaba durante el mismo día de su presentación y se distribuye de forma gratuita. Una opción que sigue la evolución lógica de su política de actualizaciones, que han ido bajando de precio durante los últimos años.

Además de las hasta 200 novedades incluidas en la nueva versión, Apple ha solucionado un total de 48 vulnerabilidades en el sistema operativo. La mayoría de los fallos solucionados se encuentra en el kernel del sistema (10), aunque una gran parte de ellos tienen un impacto de perfil bajo, contando con denegaciones de servicio y revelaciones de información. De todas ellas, la vulnerabilidad de mayor importancia se refiere a una ejecución de código arbitrario debida a un fallo en el manejo de argumentos en la API posix_spawn. Otros componentes que han recibido actualizaciones son python (5), tanto en sus versiones 2.6 como 2.7.

Se ha corregido la vulnerabilidad CVE-2011-3389 presente en el componente CFNetwork SSL, que hacía posible un ataque BEAST al incluir TLS 1.0. Se deja de soportar también certificados X.509 firmados usando MD5 (CVE-2011-3427) para aquellos que no se utilicen como certificado raíz de confianza.

Además, Mavericks corrige hasta 21 vulnerabilidades en Safari a través de la versión 7 del navegador, que incorpora de serie. De las que 20 se localizan en el motor Webkit. La mayoría de ellas dan lugar a una denegación de servicio, con posibilidad de la ejecución de código arbitrario, de forma remota a través de un sitio web especialmente diseñado. El resto podrían permitir ataques tipo cross-site scripting, o revelación de información. Para versiones de OS X anteriores, se estos fallos se corrigen en la versión 6.1 del navegador.

Entre el resto de actualizaciones publicadas se encuentra la versión 7.0.3 de su sistema operativo móvil iOS. Esta nueva versión corrige tres vulnerabilidades, todas ellas relacionadas con fallos en la pantalla de bloqueo y de petición de "passcode". Un atacante con acceso físico al dispositivo podría realizar llamadas (CVE-2013-5144), acceder al panel de contactos (CVE-2013-5164) o saltar el bloqueo temporal del teléfono tras superar el número de intentos fallidos (CVE-2013-5162).

También se corrige una vulnerabilidad en el software para presentaciones Keynote que permitía el desbloqueo de la pantalla si el equipo se puso en modo suspensión durante el modo de presentación. Por último, también se ha actualizado el sistema OS X Server a su versión 3.0, en la que se corrigen siete vulnerabilidades. Cinco de ellas están relacionadas con fallos en Ruby on Rails y la gema JSON de Ruby en el componente Profile Manager, pudiendo el más serio de ellos dar lugar a un ataque cross-site scripting. De las otras dos, la más grave es la localizada en FreeRADIUS(CVE-2012-3547) que podría permitir la ejecución de código arbitrario debido a un fallo al procesar el certificado de cliente.

OS X Mavericks v10.9, al igual que el resto de actualizaciones, está disponible a través de Mac App Store, las actualizaciones de software y el centro de descargas de Apple.

Más información:

About the security content of OS X Mavericks v10.9

About the security content of Safari 6.1

About the security content of iOS 7.0.3

About the security content of Keynote 6.0

About the security content of OS X Server v3.0



Francisco López
flopez@hispasec.com

miércoles, 23 de octubre de 2013

Martin Gardner, RSA y otros pasatiempos matemáticos

Hace dos días (el 21 de octubre) se conmemoró el 99 aniversario del nacimiento de Martin Gardner (1914-2010), uno de los grandes divulgadores científicos (principalmente de la rama de las matemáticas). Especialmente conocido por su columna su columna mensual "Juegos matemáticos" de la revista de divulgación científica "Scientific American" ("Investigación y ciencia" en su edición en castellano) entre diciembre de 1956 y mayo de 1986.

Martin Gardner 
Fuente: http://owpdb.mfo.de/detail?photo_id=1292
En agosto de 1977 en su columna del Scientific American (publicado en "Investigación y ciencia" en octubre) y bajo el título de "Claves de nuevo tipo cuyo desciframiento ocuparía unos cuantos millones de años" ("a new kind of cipher that would take millions of years to break"), Martin Gardner presentó a tres profesores del MIT hasta entonces desconocidos y el resultado de su investigación.

Los profesores no eran otros que Rivest, Shamir y Adleman, especialistas en ciencias informáticas y se anunciaba un nuevo sistema criptográfico que poco después fue conocido como RSA por las siglas de los nombres de los tres investigadores). En su artículo, tras describir la criptografía de clave pública y los avances de Diffie y Hellman, presentaba como Rivest, Shamir y Adleman a través de números primos y la dificultad de factorización de un número producto de dos primos de gran tamaño habían conseguido un método criptográfico que cumplía las condiciones del criptosistema de clave pública.

Por primera vez se presentaba el criptosistema RSA al público, además en su artículo Gardner y el grupo del MIT dejaron un desafío a sus lectores en forma de mensaje codificado y dando la clave pública empleada para cifrarlo.
Clave pública (r):
114381625757888867669235779976146612010218296721242362562561842935706935245733897830597123563958705058989075147599290026879543541
Texto cifrado:
96869613754622061477140922254355882905759991124574319874695120930816298225145708356931476622883989628013391990551829945157815154

El desafío consistía en factorizar la clave pública en sus dos factores y emplearlos para descifrar el mensaje. El texto llano es una frase inglesa convertida en un número mediante el procedimiento habitual (a=0, b=1…) elevado a 9007 módulo r. Rivest estimaba que usando el mejor algoritmo de factorización conocido y el más rápido de los ordenadores disponibles (del año 77) serían necesario del orden de 40 cuatrillones de años para resolver el reto.

En el artículo, Gardner no disponía de espacio suficiente para explicar todos los detalles prácticos del RSA por lo que pidió a los lectores interesados que solicitaran los detalles al laboratorio de informática del MIT. Los tres investigadores se vieron inundados con unas 7.000 solicitudes de documentación. Sin embargo tardaron en contestar cerca de un año, hasta solventar ciertos problemas jurídicos y otros relacionados con la patente.

Lejos de la predicción de Rivest, el desafío de Gardner tardó "tan solo" 17 años en ser descifrado. El 26 de abril de 1994 un equipo de 600 voluntarios, en un reto de computación colaborativa, empleando unas 1.600 máquinas durante más de seis meses. Hay que señalar la mejora en los algoritmos de factorización (desde la publicación original) y que el reto propuesto por Gardner empleaba una clave de 129 cifras decimales.

El artículo original de Martin Gardner sobre el RSA se encuentra publicado también en su libro "Mosaicos de Penrose y escotillas cifradas". Otros libros de Martin Gardner relacionados con la criptografía: "El idioma de los espías", "Codes, ciphers and secret writing". Al tratar casi todas las ramas de las matemáticas, ha tocado otros muchos campos ampliamente relacionados con la computación y la seguridad informática, como por ejemplo los números aleatorios y pseudoaleatorios, etc. En general la bibliografía de este autor es extensa, altamente recomendable y con artículos de gran interés.

Más información:

A new kind of cipher that would take millions of years to break
Martin Gardner

Investigación y Ciencia. Claves de nuevo tipo cuyo desciframiento ocuparía unos cuantos millones de años


Antonio Ropero
Twitter: @aropero

martes, 22 de octubre de 2013

Vulnerabilidad en dispositivos Cisco Video Surveillance 4000 Series IP Camera

Cisco ha anunciado una vulnerabilidad que afecta a las cámaras de vigilancia Cisco Video Surveillance de la serie 4000. Podría permitir a usuarios remotos eludir restricciones de seguridad y acceder al dispositivo comprometiendo la confidencialidad e integridad.

El problema de seguridad reside en la inclusión en el código de credenciales de una cuenta de usuario no documentada. Un intruso remoto no autenticado podría obtener acceso a las páginas de análisis de Cisco Video Surveillance 4000 Cámara IP Serie y ver el canal de video mediante el uso de dichos credenciales.

La vulnerabilidad ha sido identificada como CVE-2013-5535. Se encuentran afectados los dispositivos con las siguientes versiones de firmware: 2.3.x, 2.4.x, 3.1.x y 3.2.x.

Cisco ha publicado una actualización que solventa este error de seguridad. Se encuentra disponible para su descarga desde la página oficial.

Más información:

Cisco Video Surveillance 4000 Series IP Camera Default Credential Vulnerability

CVE-2013-5535: Cisco Video Surveillance 4000 Series IP Camera Default Credential Vulnerability



Juan José Ruiz



lunes, 21 de octubre de 2013

No te dejes engañar por las vulnerabilidades leves (y II)

Hay fallos que generalmente suelen ser pasados por alto a la hora de corregir problemas o hacer una valoración de la seguridad. En la anterior entrega hablamos de problemas como cross-site scripting o denegación de servicio suelen pasar desapercibidos y no se les presta gran atención. Sin embargo pueden causar graves perjuicios o permitir la realización de ataques más avanzados si son combinados o encadenados con otras vulnerabilidades, incluso aunque también estas últimas sean de impacto moderado.

Cross-site Request Forgery, la vulnerabilidad incomprendida

Este tipo de vulnerabilidad permite a un atacante ejecutar funcionalidad de una web determinada a través de la sesión en esa web de otro usuario. Su mecanismo es sencillo, pero entender como funciona y su impacto no lo es y mucho menos para profesionales ajenos al mundo de la seguridad. Para ello necesitamos montar una prueba de concepto realista y detallar cada paso efectuado en el ataque. Si no se entiende este ataque y su impacto, la interpretación del mismo suele ser pobre y se tiende a infravalorar su peligrosidad.

En una ocasión uno de nuestros clientes nos pidió una prueba de concepto detallada para entender su impacto ya que con la descripción del ataque no percibía el peligro y descartaba una solución a corto plazo, incluso nos solicitaba cambiar su calificación a una más moderada. Cuando se efectuó dicho test observó como un simple correo con un enlace a una imagen, sin asociación ninguna a la marca, llevaba al usuario a una web de Hispasec sin relación con la suya. ¿Ya está? preguntó el cliente. Entonces le pedimos que accediera a la cuenta de pruebas de su aplicación web y observara los cambios. A partir de ese momento las piezas encajaron y pudo ver el peligro real que suponía.

CVSS, un estándar para medir la gravedad

Está claro que hay que dar un nivel de gravedad para cada problema. Aunque un cross-site scripting pueda llegar a ser grave, evidentemente sería mucho peor que la aplicación tuviera una vulnerabilidad de inyección SQL con capacidad para ejecutar volcar la base de datos completa. Para solucionar el "problema" de medir la gravedad de una vulnerabilidad se creó el estándar CVSS (Common Vulnerability Scoring System).

El CVSS es un sistema de puntuación de vulnerabilidades diseñado para proporcionar un método abierto y estandarizado para la clasificación de vulnerabilidades. CVSS pretende ayudar a las empresas a priorizar y coordinar una respuesta a los problemas de seguridad.

Las puntuaciones asignadas por el CVSS se derivan de la medición de tres grupos diferenciados: El grupo "base" representa las propiedades de una vulnerabilidad que son inmutables en el tiempo (como la complejidad, si es local o remota, o si se requiere autenticación, así como el grado en que compromete la confidencialidad, integridad y disponibilidad del sistema), el grupo "temporal" mide propiedades que pueden cambiar con el tiempo (como la existencia de parches o código para su explotación) y el grupo "medioambiental" que mide las propiedades de una vulnerabilidad que pueden depender del propio entorno de la organización en el que se usan los sistemas. De la métricas base se deriva una puntuación de 0 a 10, que puede verse reducido en función de los valores de las métricas "temporal" y "medioambiental".

El CVSS se ha convertido en un estándar y es plenamente utilizado por un gran número de organizaciones, que incluso en los propios avisos o boletines de seguridad ya notifican los valores del CVSS. Nuestro servicio de alertas de vulnerabilidades SANA, también ofrece el valor CVSS en todas las alertas emitidas.

Al final, el CVSS nos da una puntuación entre 0 y 10 que permite categorizar la gravedad de una vulnerabilidad, a mayor valor, más gravedad. De esta forma una correcta aplicación del CVSS puede resultar de gran utilidad en las organizaciones, ya que puede ayudar a determinar la urgencia para instalar un determinado parche, o planificar el orden en que deben ser instaladas las actualizaciones.

Aunque también hay que tener cuidado en su aplicación, en ocasiones nos hemos encontrado con organizaciones que dentro de su política de actualización no parchean vulnerabilidades con un CVSS menor de un determinado valor. En definitiva, el CVSS puede ser de utilidad para determinar la prioridad a la hora de actualizar, pero no para establecer que una vulnerabilidad no merece ser parcheada.

Todas las vulnerabilidades tienen su importancia

Está claro que una vulnerabilidad 0-day, con un exploit público, que afecte a todos los Windows, fácilmente explotable es mucho más peligrosa que un simple cross-site scripting; pero también hay que tener claro que no hay que descuidar las vulnerabilidades de menor importancia, ya que también pueden conllevar graves consecuencias si son explotadas con éxito. Por eso, una vez más, es importante recordar la importancia de auditar y corregir cualquier tipo de fallo encontrado.


Más información:

una-al-dia (04/01/2010) El falso "hackeo" de la web de la presidencia española, XSS y lecciones para aprender

una-al-dia (13/02/2000) Ataques masivos. ¿Es tan fiero el león como lo pintan?

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

Common Vulnerability Scoring System (CVSS-SIG)

Common Vulnerability Scoring System Version 2 Calculator



Antonio Ropero
Twitter: @aropero

David García
Twitter: @dgn1729

domingo, 20 de octubre de 2013

No te dejes engañar por las vulnerabilidades leves (I)

Hay fallos que generalmente suelen ser pasados por alto a la hora de corregir problemas o hacer una valoración de la seguridad, problemas como cross-site scripting o denegación de servicio suelen pasar desapercibidos y no se les presta gran atención. Sin embargo pueden causar graves perjuicios o permitir la realización de ataques más avanzados si son combinados o encadenados con otras vulnerabilidades, incluso aunque también estas últimas sean de impacto moderado.

En muchas ocasiones en nuestros trabajos de auditoría nos planteamos cómo calificar la gravedad de un cross-site scripting o una denegación de servicio; desde luego, no permite "entrar" en el servidor o volcar la base de datos (al menos, no directamente), pero el alcance que puede provocar puede ser igual de serio.

En las revisiones realizadas una vez que el cliente ha implantado las medidas recomendadas, o en posteriores auditorías periódicas, comprobamos como problemas como cross-site scripting o denegaciones de servicio no se corrigen, a pesar de que la solución suele ser sencilla.

La experiencia nos dicta que no se presta la suficiente atención en corregir este tipo de problemas, incluso podemos oír que estos problemas no se consideran graves y se da carpetazo al asunto con un "este fallo no permite entrar en el servidor".

Un caso clásico de cross-site scripting

Recordamos que un ataque Cross-site Scripting (o XSS) se basa en que una página web no filtra correctamente ciertos caracteres especiales y permite ejecutar código JavaScript. Dentro del XSS principalmente hay dos tipos, el persistente y el no persistente (o reflejado).

Página de la "Presidencia Española de la Unión Europea"
supuestamente "hackeada"
Con el XSS reflejado se consigue que, mediante una URL especialmente modificada, en la web afectada se obtenga otro resultado. Un claro ejemplo, que tuvo una gran repercusión, es el que se realizó hace tres años sobre la página web de la "Presidencia Española de la Unión Europea", cambiando el vídeo de bienvenida del entonces presidente, por una foto de Mr. Bean.

Si se entraba a la página a través de la URL real, se veía la página en perfecto estado, pero el atacante en este caso publicitó una URL manipulada a través de las redes sociales que cargaba la imagen de Mr. Bean desde otro punto. En muchos medios se publicó la noticia de que un "hacker" había modificado la web. Evidentemente ningún hacker había modificado la web ni mucho menos había entrado en ella; pero el daño, la mala publicidad, la pérdida de imagen, ya estaba hecha.

Ni que decir tiene que el otro tipo de cross-site scripting (XSS persistente) puede resultar aun bastante más peligroso. Este tipo de ataques se producen igualmente al no comprobar los datos de entrada en una web, normalmente formularios, con la diferencia de que quedan "grabados". El atacante puede introducir un código JavaScript que quedará almacenado en la base de datos y cuando un usuario legítimo visite la web, se cargará ese código malicioso (en esta ocasión sí se cargará desde la web legítima).

Un ejemplo de la utilización de una vulnerabilidad de cross-site scripting (del tipo permanente) y de la encadenación de vulnerabilidades para realizar un ataque exitoso, se pudo ver recientemente en la intrusión en el servidor de los foros de la comunidad Ubuntu

En una página sin control de sesión y sin datos que robar, el riesgo de un error como el que nos ocupa actualmente ("de libro" y más habitual de lo que parece) puede ser considerado como de riesgo medio desde el punto de vista técnico. Si bien hay casos en que deben considerarse otro tipo de "impactos", como el impacto mediático, imagen de la compañía, etc. por tanto, también debe valorarse el daño potencial a la imagen de este tipo de vulnerabilidades.

Estos ataques pueden usarse para inyectar iframes que conduzcan a infecciones o phishing elaborados. El visitante verá el dominio legítimo en la URL e incluso, evidentemente y en su caso, el certificado válido, pero la capacidad de inyectar código permite que la página "amiga" se comporte de manera maliciosa.

También existen casos en que las vulnerabilidades de XSS deben ser consideradas de riesgo alto por criterios técnicos. Debemos pensar que los vectores de ataques de las vulnerabilidades XSS son variados y dependen del contexto, ya que podrían permitir la realización de ataques de phishings, distribución de malware desde fuentes teóricamente confiables, suplantación de sesiones, robos de cookies, etc.

Denegaciones de servicio

El caso de las denegaciones de servicio (o "DoS" por sus siglas en inglés) no es muy diferente, en muchos casos estos problemas suelen ser aun más ignorados que los cross-site scripting. No se valora el potencial peligro que puede suponer una denegación de servicio, ya que tampoco llegan a suponer un compromiso de la seguridad de las máquinas. No modifica páginas web ni obtiene listados de claves o de números de tarjetas de crédito. Se trata, sencillamente, de entorpecer el acceso de los usuarios a los servicios de la máquina, pero sin comprometer estos directamente.

En ese sentido, estos ataques acostumbran a ser poco sofisticados y se basan en fallos de diseño inherentes a Internet o a la aplicación. Por otro lado los ataques de denegación de servicio son una constante en Internet desde sus comienzos (sin ir más lejos, el célebre gusano de Morris desencadenó un ataque DoS por un error de programación).

El problema no debe ser pasado por alto, la caída de un servidor puede provocar graves pérdidas a una compañía. En muchos casos un ataque de denegación de servicio puede durar algunas horas, pero en algunos casos puede prolongarse durante días. Pero para una mediana empresa, la caída del servicio durante unas horas puede suponer unas pérdidas de miles de euros en ingresos, publicidad, operaciones no realizadas, pérdida de imagen, posicionamiento web, etc.

Por no hablar de perdidas millonarias como las que puede sufrir una gran empresa, por ejemplo una entidad bancaria, o una empresa de comercio electrónico. Una empresa como Amazon factura 160.000 dólares por minuto (de media), unos 118.600 euros, según RetailNet. Se pueden calcular fácilmente las pérdidas directas que pueden suponer por una caída del servicio. Por no decir de las pérdidas a nivel de reputación, imagen, etc.


En la siguiente entrega analizaremos otros problemas que suelen ser ignorados en las auditorías y que pueden conllevar graves consecuencias.


Más información:

una-al-dia (04/01/2010) El falso "hackeo" de la web de la presidencia española, XSS y lecciones para aprender

una-al-dia (13/02/2000) Ataques masivos. ¿Es tan fiero el león como lo pintan?

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

una-al-dia (21/10/2013) No te dejes engañar por las vulnerabilidades leves (y II)
http://unaaldia.hispasec.com/2013/10/no-te-dejes-enganar-por-las_21.html


Antonio Ropero