You are here

Seguridad

¿Es OptionsBleed el nuevo HeartBleed?

Hispasec - Thu, 21/09/2017 - 09:30
El investigador independiente Hanno Böck ha descubierto una vulnerabilidad en los servidores web Apache que permite el filtrado de fragmentos de memoria arbitrarios. Un comportamiento que nos recuerda a HeartBleed, famosa vulnerabilidad en OpenSSL de 2014.

Imagen tomada de The Fuzzing Project
Precisamente por este parecido la vulnerabilidad ha sido bautizada como OptionsBleed, también en honor al método OPTIONS de HTTP. Este es utilizado por un cliente web para recibir información sobre los métodos soportados por el servidor. Una petición OPTIONS normal debería devolver una respuesta de la forma:


Respuesta de una petición OPTIONS.
Pero, durante una investigación sobre los sitios con mayor posición de Alexa, Böck descubrió algunas respuestas a OPTIONS bastante peculiares. Los métodos se repetían, aparecían vacíos, y en algunas cabeceras se devolvía algo parecido a una fuga de memoria:


Respuesta OPTIONS de un servidor vulnerable.
Este comportamiento le hizo sospechar. Aunque no conocía el software especifico que devolvía estas respuestas, encontró fugas con fragmentos de configuraciones que parecían pertenecer a servidores Apache, y se puso en contacto con el equipo de desarrollo, que finalmente confirmaron la vulnerabilidad. 

Este error ha sido identificado como CVE-2017-9798 y ya existen parches para la mayoría de las versiones de Apache Web Server en Linux.

Teoría y práctica
Explotar OptionsBleed en teoría es sencillo: solo hay que realizar una petición OPTIONS al servidor para disparar la vulnerabilidad. En la práctica, la vulnerabilidad no es determinista, es decir, no devuelve siempre el mismo resultado dados los mismos datos de entrada. Por ello su reproducción es difícil.

Se sabe con seguridad que la vulnerabilidad es causada por un fallo en la implementación de la directiva Limit. Los métodos disponibles en el servidor (aquellos que la respuesta de OPTIONS comunica) se pueden establecer a nivel global en la configuración. Usando Limit, además, se puede limitar su uso por recurso, usando un fichero .htaccess.


Sintaxis de una directiva Limit.
El problema ocurre cuando establecemos una directiva Limit sobre un método que no hemos registrado en la configuración global. Es más, en general cualquier método no valido sobre el que se define esta directiva directiva en un fichero .htaccess provoca la fuga de información.

Aun localizado el problema, se deben dar ciertas condiciones para su explotación, y los detalles son bastante vagos. Según Böck en el FAQ de la vulnerabilidad:

Debido a su naturaleza, el fallo no aparece de forma determinista. Parece que solo se da en servidores ocupados. A veces aparece tras varias peticiones.
OptionsBleed no es HeartBleed
Más allá del parecido en el comportamiento, hay varias diferencias que hacen a OptionsBleed bastante menos peligroso que HeartBleed, la famosa vulnerabilidad en OpenSSL aparecida en 2014 con la que se le está comparando.

Por un lado, la superficie de exposición es menor. OptionsBleed solo afecta a servidores Apache Web Server. Por su parte HeartBleed afectaba a todo servidor con versiones de OpenSSL vulnerables, sin distinción entre web, email, o VPN. 

Además, es necesario tener una cierta configuración y que el servidor se encuentre en condiciones específicas para la explotación. Hay que tener en cuenta que en el estudio se ha conseguido explotar la vulnerabilidad en solo 466 servidores entre el Top 1 millón de Alexa. Además, de ser explotada, OptionsBleed devuelve un fragmento de menor longitud que HeartBleed.

Sin embargo, tiene un riesgo añadido: en servidores Apache compartidos, un usuario puede incluir un fichero .htaccess manipulado para facilitar deliberadamente la explotación y descubrir secretos del resto de usuarios.

Pero hay algo que sí tiene en común: pasaron desapercibidos durante bastante tiempo.



Francisco López
@zisk0
flopez@hispasec.com
Más información:
Optionsbleed - HTTP OPTIONS method can leak Apache's server memoryhttps://blog.fuzzing-project.org/60-Optionsbleed-HTTP-OPTIONS-method-can-leak-Apaches-server-memory.html

OpenSSL afectada por una vulnerabilidad apodada HeartBleedhttp://unaaldia.hispasec.com/2014/04/openssl-afectada-por-una-vulnerabilidad.html




Categories: Seguridad

RedAlert2.0, nuevo troyano bancario en Android

Hispasec - Tue, 19/09/2017 - 12:41
En foros underground se ha estado cocinando un nuevo troyano bancario, bautizado como RedAlert 2.0 por el creador. A diferencia de otros bots anteriores, no utiliza como base de código otros troyanos que acostumbraban a tomar códigos filtrados para su desarrollo. Entidades españolas como Bankia o BBVA se ven afectadas.


RedAlert cuenta con características comunes al resto de troyanos bancarios en Android como Overlay (superposición de un falso login), control sobre los SMS y extracción de los contactos. 
Como principal novedad, los equipos de respuesta de incidente de las entidades bancarias pueden verse afectados por este troyano. Los SOC internos suelen localizar a los clientes por vía telefónica para avisarles de la infección. Este troyano monitoriza y bloquea las llamadas que provienen de entidades bancarias para evitar el contacto.

Otra particularidad es que utiliza Twitter como método para conseguir nuevos centros de control en caso de que su servidor por defecto sea neutralizado. 
Vector de infección utilizado por RedAlert
Utiliza un vector de infección típico utilizado por el Malware en Android para evitar tener que evadir los controles de la Google Play Store: se hace uso de un servidor comprometido o registrado con fines maliciosos que, al visitarlo, contiene una falsa alerta de actualización para dispositivos Android. Los usuarios se descargan así automáticamente el APK y lo ejecutan. Una vez ejecutado, se solicitan permisos de administrador de dispositivo y se comprueba la hora UTC via timeapi.org
Esquema de comunicaciones de RedAlert
Una vez tiene todo lo necesario para proceder a comunicarse con el servidor de control, comienza a enviar datos al servidor remoto:

  • Modelo.
  • Versión de Android.
  • Idioma del teléfono.
  • IMEI del dispositivo infectado. 

Estas comunicaciones utilizan codificación BASE64, por lo que son sencillas de visualizar. Consecuentemente, se envía información sobre si se consiguió el permiso de administrador en el dispositivo junto con un array con el contenido de SMS al servidor remoto. Finalmente, cuenta con el comando UCS utilizado para recibir instrucciones, y puede introducirse cualquiera de los comandos incluidos en el listado ilustrado en el esquema de comunicaciones. 
La metodología de robo de credenciales a las víctimas es similar al resto de troyanos en Android actuales. Sin embargo, a partir de las versiones Android 5.0 en adelante se hace uso de Android toolbox, que encapsula la funcionalidad de los comandos mas comunes en Linux en un único binario, como por ejemplo 'ls' o 'ps'
Fragmento de codigo correspondiente a la llamada de `toolbox ps -p -P -x -c`
Como comentabamos anteriormente, es destacable que a pesar de que hace uso de métodos utilizados por otros troyanos bancarios no es una evolución de código anterior. Se trata de un troyano que se ha programado completamente desde cero y cuenta con actualizaciones constantes. Este tipo de troyanos de momento se encuentran en markets no oficiales y en otras páginas con el fin de infectar usuarios.
De momento todas estas muestras se pueden detectar con Koodous Antivirus, y se pueden localizar muestras mediante el tag #RedAlert en Koodous o en el siguiente enlace.
Más información:
* https://clientsidedetection.com/new_android_trojan_targeting_over_60_banks_and_social_apps.html
* https://github.com/virqdroid/Android_Malware/tree/master/Red_Alert_2


Fernando Díazfdiaz@hispasec.com
@entdark_

Categories: Seguridad

Cómo mantenerse a salvo de BlueBorne si no tenemos actualización

Hispasec - Mon, 18/09/2017 - 16:43
BlueBorne es el conjunto de vulnerabilidades publicadas el pasado día 12 de septiembre por la empresa de seguridad Armis, que hizo una publicación responsable de las vulnerabilidades encontradas en la implementación Bluetooth, poniendose en contacto previamente con los sistemas operativos más importantes.




Windows y Linux han publicado actualizaciones para esta vulnerabilidad, Apple ha comunicado que la vulnerabilidad no afecta a las últimas versiones de su sistema. El caso de Android es el más delicado, debido a que aunque la versión oficial ya se encuentre corregida, falta que los fabricantes la incorporen y la distribuyan entre los terminales afectados. Este escenario, nada halagüeño, crea bastante preocupación debido a la pasividad de la mayoría de los fabricantes en el proceso de actualización de sus terminales.

Para comprobar si su móvil Android es vulnerable, la propia empresa Armis hizo público una aplicación en Google Play para comprobarlo. Esta aplicación no sólo comprueba si su terminal es vulnerable, sino que comprueba también en todos los terminales con Bluetooth a los que tenga alcance. En el caso de que Armis estuviese guardando esta información, estaría generando una formidable base de datos sobre dispositivos vulnerables que sería interesante que compartiesen. De esta forma, fabricantes y comunidad podrían sacar parches que corrijan, o al menos mitiguen cuando no sea posible corregir la vulnerabilidad.

Mientras tanto, millones de dispositivos siguen siendo vulnerables a la espera de un exploit, que sin ser aún público, podría estar siendo aprovechado en estos momentos. Quién sabe si alguien está programando un ransomware con autopropagación, al ser un nuevo vector que da acceso a los ciberdelincuentes a dispositivos en los que aún no hemos visto este tipo de amenazas (como es el caso de relojes inteligentes, SmartTV's, etc).

Desde Hispasec, como no podría ser de otro modo, recomendamos a todos los usuarios que actualicen y en caso de no tener actualización, desactiven el Bluetooth a espera de noticias de su fabricante.
Más información:


BlueBorne, una vulnerabilidad en Bluetooth con capacidad de autopropagación
http://unaaldia.hispasec.com/2017/09/blueborne-una-vulnerabilidad-en.html

BlueBorne Technical White Paper
http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper.pdf

Google Play - BlueBorne Vulnerability Scanner by Armis
https://play.google.com/store/apps/details?id=com.armis.blueborne_detector



Fernando Ramírezframirez@hispasec.com
@fdrg21




Categories: Seguridad

Vulnerabilidad de denegación de servicio en ImageMagick

Hispasec - Mon, 18/09/2017 - 12:08
Se ha reportado una vulnerabilidad en Imagemagick, una herramienta empleada por millones de sitios web para el tratamiento de imágenes. La vulnerabilidad es considerada de gravedad alta y podría permitir a un atacante provocar condiciones de denegación de servicio.

Como hemos explicado en anteriores boletines, ImageMagick es un conjunto de utilidades de código abierto para mostrar, manipular y convertir imágenes, capaz de leer y escribir más de 200 formatos. Se trata de un conjunto de utilidades de línea de comandos empleado para la manipulación de imágenes. Muchas aplicaciones Web como MediaWiki, phpBB o vBulletin, pueden usar ImageMagick para generar miniaturas. También es usado por otros programas para la conversión de imágenes.
En el problema reportado, con CVE-2017-14505, debido a un error en la función 'DrawGetStrokeDashArray' en 'wand/drawing-wand.c' al manejar determinados arrays nulos podría causar una desreferencia a puntero nulo en la función 'AcquireQuantumMemory' en  'MagickCore/memory.c'.
Un atacante remoto podría valerse de este error para provocar denegaciones de servicios a través de archivos de imágenes especialmente manipulados.

Este problema afecta a las versiones anteriores a la 7.0.7-1. Se recomienda actualizar a versiones superiores. https://www.imagemagick.org/download/beta/
Juan Sánchezjasanchez@hispasec.com
Más información:
Null Pointer Dereference triggered by malformed Image Filehttps://github.com/ImageMagick/ImageMagick/issues/716
Imagemagick https://www.imagemagick.org/script/index.php



Categories: Seguridad

'Display Widgets' Backdoor: Cuando el río suena, agua lleva.

Hispasec - Sun, 17/09/2017 - 16:56
‘Display Widgets’ ha sido el plugin en el cual se ha encontrado una backdoor. Lo raro de este caso, es que ha sido necesario reportar hasta cuatro veces esta vulnerabilidad para que, finalmente, se haya producido la eliminación total del plugin en los repositorios oficiales de Wordpress. 
Una backdoor o puerta trasera es el nombre que se le ha puesto al código existente en un software que permite que la máquina que aloja este código sea accesible remotamente por parte de los desarrolladores, permitiendo un control total o casi total en la máquina afectada.
‘Display Widgets’ es un plugin de Wordpress desarrollado por Stephanie Well para facilitar el control a los dueños del blog, permitiendo el control de cómo y cuándo se muestran los widgets en el sitio web. Al ser un plugin de esta plataforma tan exitosa, ha permitido que esta infección haya podido superar las 200000 infecciones en poco más de 2 meses. Pero, ¿qué es lo que ha pasado para tener este alcance?
Todo comienza cuando la desarrolladora del plugin cambia su enfoque de negocio y decide monetizar este plugin con una versión premium, vendiendo el código de su versión libre a otro desarrollador, el cual al mes ya publicó una versión actualizada la 2.6.0.
Esta primera versión recibe su primera queja del SEO David Law, advirtiendo de que este plugin no cumplía las reglas de publicación de Wordpress, puesto que descargaba 38MB's de servidores de terceros. Y no sólo eso, sino que el código descargado contenía código para monitorizar tráfico del usuario obteniendo información como IP, navegador y sitios visitados, y que después esta información era enviada a estos servidores de terceros.
Aunque Wordpress eliminó este plugin de los repositorios oficiales, el plugin no tardó en estar activo de nuevo. Una semana tardó el desarrollador en publicar la versión 2.6.1. Esta vez el plugin no descargaba esos 38MB, sino que esta vez el plugin tenía este contenido en su interior, y además, este plugin (geolocation.php) contenía una backdoor, lo cual permitía a servidores externos conectarse a este plugin y publicar o crear nuevas entradas. Y como no, David Law que aún tenía la vista en este plugin, volvió a reportarlo, y en cuestión de un día, el plugin fue eliminado de nuevo.
En otro tercer intento de este desarrollador, el día 6 de julio publicó su tercera actualización, que aparentemente era inocua, pero 17 días después Wordpress volvía a recibir noticias de este plugin. Éste había cambiado su comportamiento, y esta vez insertaba comentarios de spam en el sitio web que no eran mostrados desde la interfaz de administración. Comentarios que eran sacados desde la IP 52.173.202.113. IP que respondía a los dominios ‘stopspam.io’, ‘w-p.io’, ‘geoip2.io’ y ‘maxmind.io’. Con esta información el equipo de Wordpress volvió a eliminar el plugin.
Ante otro intento de seguir con el proceso de infección, el 2 de septiembre el desarrollador volvió a publicar una versión, y al última, la versión 2.6.3, la cual duró 5 días tras nuevas quejas de los usuarios.
Actualmente el plugin no está disponible en los repositorios oficiales de Wordpress, pero son muchos investigadores los que se han quejado sobre el método de publicación de estas herramientas, ya que son muchos los investigadores que no ven con buenos ojos que una herramienta que ha sido eliminada varias veces por estos motivos, pueda ser subida de nuevo en muy poco tiempo y sin apenas control. 

Más información

Wordfence
https://www.wordfence.com/blog/2017/09/display-widgets-malware/

BleepingComputer
https://www.bleepingcomputer.com/news/security/backdoor-found-in-wordpress-plugin-with-more-than-200-000-installations/


Jose Ignacio Palaciosjipalacios@hispasec.com
Categories: Seguridad

Ejecución de código remoto en Microsoft Edge

Hispasec - Sat, 16/09/2017 - 16:06
Microsoft ha publicado una vulnerabilidad en Microsoft Edge que permite ejecutar código remoto a través de una página web especialmente manipulada.
ChakraCore, el núcleo de Chakra, el motor de JavaScript presente en Microsoft Edge, se ha visto afectado por una vulnerabilidad en la forma en la que maneja ciertos objetos en memoria. Según una observación superficial del trozo de código afectado antes y después de corregir la vulnerabilidad, ésta parece ser provocada por un manejo incorrecto de los ámbitos (partes del código en los que cada una de las variables existe). Esto provocaría un error de inicialización no esperada, afectando a memoria que no debería.
Cuando se produce un fallo de escritura inesperada en memoria, existe el riesgo de que se ejecute código fuera del flujo original, produciéndose el fenómeno de weird machine. Si el fallo de escritura se provoca a propósito y es construido cuidadosamente, en algunos casos se puede ejecutar código proporcionado por el atacante. Esta es la base de la mayoría de las vulnerabilidades modernas de explotación de memoria.
El escenario de explotación es clásico: Una página web especialmente diseñada para explotar la vulnerabilidad, y el atacante sólo tendría que apañárselas para que la víctima la visitase. Por el momento, la vulnerabilidad está corregida en el repositorio de código GitHub, pero no hay indicios de que esté incorporada esta corrección en una versión pública.


Carlos Ledesmacledesma@hispasec.com


Más información
CVE-2017-11767 | Scripting Engine Memory Corruption Vulnerabilityhttps://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11767
CVE-2017-11767 | Do not instantiate param scope if only the function expression symbol is capturedhttps://github.com/Microsoft/ChakraCore/pull/3729/commits/33cdbe2c582cfa09242aca3876c4f0d300685cb9#diff-747c6e5a9953473a38c2a9629fa00990
Categories: Seguridad

Grave vulnerabilidad remota en .NET corregida en los últimos boletines de Microsoft

Hispasec - Fri, 15/09/2017 - 12:00
Como viene siendo habitual, Microsoft ha publicado su boletín mensual de actualizaciones de seguridad, y entre ellas, se ha corregido un importante 0-day para la plataforma .NET Framework, que estaba siendo explotado en una nueva campaña de malware, relacionada con el grupo NEODYMIUM y la distribución de FINSPY



Boletín de septiembre 
Microsoft ha corregido este mes en un boletín bastante numeroso, 82 vulnerabilidades/CVEs, siendo el siguiente el listado de productos actualizados con sus correciones más importantes: 
  • Internet Explorer, presentando un total de 7 vulnerabilidades corregidas relacionadas con ejecución remota de código. 
  • Microsoft Edge, 29 vulnerabilidades corregidas, 20 de ellas críticas. 
  • Microsoft Windows, con 38 vulnerabilidades corregidas, siendo las de mayor impacto, por ejecución remota de código, las que afectaban a los módulos NetBIOS (CVE-2017-0161), Win32k Graphics (CVE-2017-8682), Windows DHCP Server (CVE-2017-8686), Uniscribe (CVE-2017-8692), Microsoft Graphics Component (CVE-2017-8696), Windows Shell (CVE-2017-8699),  Remote Desktop Virtual Host (CVE-2017-8714),  Microsoft PDF (CVE-2017-8728, CVE-2017-8737) y el controlador Broadcom BCM43xx presente en las HoloLens (CVE-2017-9417).
    Merece mención especial, la actualización de la pila Bluetooth, tras el reciente ataque BueBorne y la corrección de una vulnerabilidad de tipo Spoofing (CVE-2017-8628)
  • Microsoft Office y Microsoft Office Services & Web Apps. Se han solucionado 14 vulnerabilidades, 10 de ellas críticas. 
  • Skype for Business y Lync, ejecución de código, CVE-2017-8696.
  • .NET Framework, quizás la vulnerabilidad más importante (CVE-2017-8759) y que desgranaremos más adelante. 
  • Xamarin.iOS, elevación de privilegios en Xamarin Studio para Mac (CVE-2017-8665
  • ChakraCore, motor Javascript de Edge, una ejecución remota de código (CVE-2017-8658
  • Microsoft Exchange Server, una vulnerabilidad de revelación de información (CVE-2017-11761
  • Adobe Flash Player, dos vulnerabilidades por ejecuciones remota de código que afectaban al plugin (CVE-2017-11281, CVE-2017-11282). 


0-day en .NET Framework  y distribución de FINSPY
En conjunción y de manera coordinada con la publicación de estos boletines, la firma de seguridad FireEye, ha hecho público el análisis de la vulnerabilidad presente en .NET Framework y que estaría siendo explotada por un grupo de atacantes, identificados por Microsoft como el grupo NEODYMIUM. Utilizarían este 0-day para la distribución de una variante del malware de espionaje conocido como FINSPY o FinFisher, mediante el envío de documentos Office (RTF, DOCX) especialmente manipulados.

La vulnerabilidad (CVE-2017-8759) estaría presente al procesar un objeto OLE embebido en el documento, en concreto un webservice WSDL a través de su moniker SOAP. Esto permitiría a un atacante remoto inyectar código arbitrario durante el proceso de parseo, elevar privilegios y como se ha demostrado, según los reportes de FireEye, ser explotado para ejecutar código remoto y controlar el sistema afectado.

Técnicamente, el problema residiría en el método PrintClientProxy y la incorrecta validación presente en la función "IsValidUrl" al recibir códigos CRLF. Esto provocaría la posterior ejecución de los comandos inyectados.

Debido a esto y a la sencillez de la vulnerabilidad, firmas como MDSec ya han mostrado públicamente como reproducir el exploit:


Desde la propia Microsoft se recomienda encarecidamente actualizar los sistemas o al menos actualizar Windows Defender Antivirus, que ya bloquea este tipo de exploit, identificado como Exploit:RTF/Fitipol.A, Behavior:Win32/Fitipol.A y Exploit:RTF/CVE-2017-8759.A. También los usuarios de Windows 10 y como nueva capa de seguridad añadida, se verán protegidos mediante Windows Defender Exploit Guard (sustituto de EMET), disponible en la próxima actualización Fall Creators Update.

Más información: 
September 2017 Security Updates https://portal.msrc.microsoft.com/en-us/security-guidance/releasenotedetail/5984735e-f651-e711-80dd-000d3a32fc99 
Security Update Guide https://portal.msrc.microsoft.com/en-US/security-guidance 
FireEye Uncovers CVE-2017-8759: Zero-Day Used in the Wild to Distribute FINSPY https://www.fireeye.com/blog/threat-research/2017/09/zero-day-used-to-distribute-finspy.html
Exploit for CVE-2017-8759 detected and neutralized https://blogs.technet.microsoft.com/mmpc/2017/09/12/exploit-for-cve-2017-8759-detected-and-neutralized/
Exploiting CVE-2017-8759: SOAP WSDL Parser Code Injection https://www.mdsec.co.uk/2017/09/exploiting-cve-2017-8759-soap-wsdl-parser-code-injection/ 
José Mesa Orihuela@jsmesa
Categories: Seguridad

Apache Struts y los peligros de la teletransportación

Hispasec - Thu, 14/09/2017 - 10:41
Si alguna vez has visto algún episodio o película de Star Trek, te habrás fijado en algo muy característico, icónico, de la franquicia desde sus inicios: El uso de un teletransportador para la mayoría de los viajes entre la Enterprise y los muchos de sus inhóspitos destinos. Ahora, en nuestro tiempo, ese recurso no sería ni trending topic, pero en los años sesenta, chico, en los años sesenta ver a un vulcaniano con sus orejas puntiagudas emerger de la nada en medio de un festival de luces estroboscópicas era una auténtica revolución. Allí no había ni mota de polvo y de pronto, zas, aparecía un tipo con todos sus átomos en su sitio, tricorder incluido, un paseito cuántico sin importancia; con vistas al universo.
Curiosamente, ese "truco" de escena les sirvió para recortar presupuesto, puesto que de ese modo se ahorraban las secuencias de despegue-aterrizaje de una hipotética lanzadera o método similar. Evidentemente, hacía falta hipotecar nuestra imaginación para no romper la suspensión de la incredulidad, o ensanchar nuestra cintura científica para pasar por alto el quebrantamiento de varias leyes de la física. Pero oiga, ¿no resulta atrevido pensar en un sistema que  descomponga la materia, la haga viajar a la velocidad de la luz y la vuelva a recomponer sin riesgo alguno en el otro extremo?




Pues bien, eso es lo que hace la serialización de objetos. Descomponer un objeto en un extremo, transmitir esos datos y recomponerlos en el destino. La magia de la computación distribuida. Solo que de momento tenemos un problemilla: no es tan segura como el teletransportador del Enterprise y en vez de recomponer un objeto seguro y fiable se nos puede colar una bomba de resina de Trilithium con pinta de inocente objeto que transporta de forma diligente las preferencias del usuario.
Eso es lo que ha pasado últimamente con una vulnerabilidad en el framework Struts de la fundación Apache. Se trata de un conocido proyecto muy usado en aplicaciones web para J2EE. O de otra forma, un framework que usa la mayoría de grandes empresas en sus desarrollos bajo la plataforma y lenguaje Java. Aunque Struts tiene ya sus años (fue pionero en este ámbito), y no tiene el tirón que tuvo en su día, todavía se sigue usando en muchas instalaciones, algunas de ellas gestionando recursos bastante valiosos para estas empresas. 
Tal es el caso que nos ocupa, el de Equifax, una empresa de valoración de crédito que ha sido atacada supuestamente usando la mencionada vulnerabilidad. Hasta 143 millones de registros podrían haber sido extraídos de sus archivos y bases de datos por un grupo atacante. En un ambiente en el que la gestión de este incidente ha sido muy discutida, la fundación Apache ha emitido un comunicado explicando algo que se puede resumir en una sola frase: "si usas software y ha salido un parche de seguridad, PARCHEA, YA!". Evidente, pero que por desgracia hay que repetir continuamente. 
La vulnerabilidad ha sido descubierta por Man Yue Mo, de la empresa lgtm. El fallo estaba en la clase ContentTypeHandler, un interfaz muy básica pero potente que permite serializar y deserializar objetos desde el objeto raíz de la API de Java, el objeto Object. Esto permite a cualquier clase que herede una implementación de dicha interfaz poseer la funcionalidad para usar serialización (en palabras trekkies, de usar el teletransportador).  Para que nos entendamos, un cliente contacta con un servidor y le dice "te voy a enviar un objeto serializado en formato XML", el servidor lo recibe, interpreta el XML del cliente a través de una instancia del objeto XStreamHandler...y como este hereda de ContentTypeHandler...no se detiene a comprobar si el XML donde yace el objeto inerte contiene o no un método peligroso. 
Como curiosidad, se ha dicho que el bug tiene o puede tener 8 años de antigüedad, pero esto es relativo y no debería ocasionar sorpresa. Ahora mismo hay cientos de bugs peligrosos que están ahí, esperando a ser descubiertos, el problema no es no verlos, sino quien los ve y que hace con él. En una imagen:


Si nos fijamos en la línea de tiempo del investigador, las fechas coinciden:


Vemos los cambios realizados a nivel de API, coincidiendo con el estilo, filosofía y formas Java: añadiendo una capa (más) de abstracción:



Y como ahora, con la nueva llamada a la API se comprueban ciertos permisos que deben figurar para serializar objetos con una mejora en la seguridad (vamos a omitir decir, de manera completamente segura):



Huelga decir que a las pocas horas de hacerse pública la vulnerabilidad comenzaron a salir exploits y pruebas de concepto, incluyendo, como no, un módulo para metasploit. Si se quiere tener una visión técnica más directa sobre cómo se arquitecta un exploit para esta vulnerabilidad podemos leer el código de este repositorio de GitHub, donde se ha publicado un exploit stand-alone para explotar el fallo por Mazin Ahmed. Ojo, no recomendamos que ejecutes este o cualquier exploit. 
Por ejemplo, vemos cómo en dicho exploit se nos pide el comando que queremos ejecutar en el sistema remoto. Este irá codificado en XML, con la etiqueta que describe su tipo, "string":

A su vez, más adelante, el comando va incrustado en una plantilla que sirve para describir completamente el objeto a serializar (siempre será el mismo, solo cambia el comando):

Hay algo más, ya por curiosidad, no lo comenta pero como post-explotación, tras asegurarse de que es explotable utiliza partes de ysoserial, un framework que ha crecido recopilando vulnerabilidades de este tipo, serialización, en el ámbito de la plataforma Java, por ejemplo:

Es una codificación base64, luego:


Interesantísima forma de explotación, aunque viene a rubricar de nuevo uno de los principios universales de la seguridad informática: jamás dar por bueno lo que llega del usuario. Ni aunque sea un vulcaniano de orejas puntiagudas y buenas intenciones.



David García@dgn1729dgarcia@hispasec.com

Más información
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica} Remote code execution vulnerability in Apache Struts (CVE-2017-9805)https://lgtm.com/blog/apache_struts_CVE-2017-9805


Categories: Seguridad

Una-al-día cambia de formato, pero no su contenido

Hispasec - Wed, 13/09/2017 - 17:57
Una-al-día nació a raíz de un inocente comentario en un canal IRC hace casi 19 años. A través de los archivos, un lector curioso puede ver cómo ha cambiado (o no) la seguridad de la información desde entonces. Paralelamente, el boletín ha ido cambiando con los tiempos, aunque la mayoría de las veces este hecho ha sido transparente para los suscriptores. El sistema manual, casi artesano, de redacción, firmado y envío de las noticias utilizado al principio ha ido dando paso a soluciones más adecuadas a los tiempos.



En este afán de mejora continua, a partir de esta semana una-al-día cambiará de formato. Como siempre, seguiremos estando cada mañana en vuestra bandeja de correo, pero un par de diferencias:
  • La primera, y quizá la más notable, es que el formato por defecto de los correos será HTML. Por supuesto, la opción de recibirlo en texto plano seguirá disponible para los suscriptores. Para cambiarlo, solo hay que acceder a la configuración de la suscripción en el enlace dentro del mismo correo y marcar el formato preferido.
  • Existen ya bastantes sistemas, como SPF y DKIM, que aseguran la autenticidad del mensaje y del servidor que lo envía, y que llevan implementados bastante tiempo en nuestra infraestructura. A partir de ahora nos remitimos a estos sistemas para sustituir la firma PGP de las noticias.
  • Adicionalmente lanzamos un nuevo newsletter en el que hablaremos de la actualidad en seguridad desde un enfoque más corporativo. Os podéis suscribir en este enlace.
Cambiamos el formato, pero no el contenido. Seguiremos hablando de seguridad con el mismo espíritu de divulgación y servicio público como empezamos. Y como siempre, cualquier sugerencia o crítica constructiva es bienvenida.
Categories: Seguridad

BlueBorne, una vulnerabilidad en Bluetooth con capacidad de autopropagación

Hispasec - Tue, 12/09/2017 - 18:30

La empresa Californiana de seguridad para dispositivos IoT Armis ha descubierto un total de 8 vulnerabilidades bautizadas todas ellas bajo el nombre de BlueBorne. Todas ellas afectan a la implementación del protocolo Bluetooth de, al menos los sistemas operativos Android, IOS, Linux y Windows, y podrían permitir a un atacante infectar un dispositivo de forma remota y que esta infección se propague a otros dispositivos, con el único requisito de que tengan el modo visible activado y sin necesidad de autorización ni autenticación. 


Las vulnerabilidades han sido identificadas con los siguientes CVEs:
  • CVE-2017-0781 CVE-2017-0782, CVE-2017-0783 y CVE-2017-0785 para dispositivos Android.
  • CVE-2017-1000251 y CVE-2017-1000250 para Linux
  • CVE-2017-8628 en Windows. 
Lo más preocupante de BlueBorne es la facilidad de propagación y la cantidad de dispositivos potencialmente vulnerables. Estaríamos hablando de que un dispositivo infectado podría utilizar su conectividad Bluetooth para dotar al malware de funciones de gusano e infectar a todos los dispositivos con los que se vaya cruzando. Esto, unido a la dificultad de actualización que ofrecen algunos dispositivos dotados de Bluetooth, podría provocar un impacto pocas veces visto. Hay que tener en cuenta que Bluetooth lleva implantandose en dispositivos desde hace más de 10 años, y muchos de ellos están descontinuados y no tienen soporte.

La empresa ha compartido pruebas de concepto para las plataformas Linux, Windows y Android:

Linux
Windows
Android
Lo descubridores publicarán en breve una aplicación Android a través de Google Play para que los usuarios puedan comprobar si son vulnerables a esta vulnerabilidad. Mientras tanto, la idea más sensata es desconectar el Bluetooth de nuestros dispositivos.
Más información:
BlueBorne Technical White Paper
http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper.pdf

Fernando Ramírezframirez@hispasec.com@fdrg21
Categories: Seguridad

Cross site Scripting persistente en CodeMeter

Hispasec - Sun, 10/09/2017 - 10:20
Se ha encontrado una vulnerabilidad en Wiby CodeMeter,  que podría ser aprovechada para provocar ataques XSS de tipo persistente. La vulnerabilidad ha sido descubierta por Benjamin Kunz Mejri de Evolution Security GmbH.

CodeMeter es una solución de seguridad para editores de software y fabricantes de dispositivos inteligentes, combinando la protección, seguridad y emisión de licencias para software. Es ampliamente utilizado en el sector industrial, siendo sus variantes compatibles con un gran número de controladores, dispositivos y ordenadores: desde microcontroladores sencillos o dispositivos móviles e incluso controladores lógicos programables (PLC), además de ordenadores personales y servidores.
Como hemos comentado en otros boletines, 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 existen dos tipos, el persistente y el no persistente. Con el XSS no persistente se consigue que, mediante una URL especialmente modificada, en la web afectada se obtenga otro resultado.
El otro tipo, y el que afecta al error comentado en este boletín, es el XSS persistente, que puede resultar bastante más peligroso. Este tipo de ataques se producen igualmente al no comprobar los datos de entrada en una web, normalmente formularios y 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, esta cargará ese código.
El problema, con CVE-2017-13754, se debería a un error de validación de entrada en el campo ‘server Name’ de las herramientas avanzadas del módulo ‘time server’. Los archivos afectados por este problema son `ChangeConfiguration.html` (donde se inyecta el payload),` time_server_list.html` y `certified_time.html` (en estos dos, donde se ejecuta el problema). Este error podría ser aprovechado por un atacante remoto inyectar código web malicioso a través de Scripts especialmente manipulados.
Este problema afecta a las versiones anteriores a la 6.50b.Se recomienda actualizar a versiones superiores.
Más información:
Wibu CodeMeterhttp://www.wibu.com/es/codemeter.html
Wibu Systems CodeMeter 6.50 - Persistent XSS Vulnerabilityhttps://www.vulnerability-lab.com/get_content.php?id=2074

Juan Sánchezjasanchez @ hispasec.com
Categories: Seguridad

MongoDB, el nuevo filón del Ransomware

Hispasec - Sat, 09/09/2017 - 09:00
Es posible que el Ransomware afecte a cientos de miles de usuarios de "a pie" o incluso cifre carpetas compartidas de redes corporativas donde la pérdida de ciertos archivos podría suponer una sobredosis de ibuprofeno a los sysadmins. Pero eso, económicamente, podemos suponer que no reporta un gran beneficio al filibusterismo digital. 
El lucro está realmente donde se encuentran los dineros, los cuartos, la pasta, el peculio, en definitiva, la riqueza. ¿Porqué cifrar las fotos del último verano o los informes TPS cuando puedes paralizar el departamento de ventas de una multinacional? ¿y donde de encuentra el corazón de todo ese andamiaje digital que sustenta el aparato de negocio? Las Bases de Datos amigo, las bases de datos. Ahí es donde tenemos el tesoro de la corona, años enteros de amasamiento binario, transacciones, datos, cifras, etc, etc, etc.
Así que, con la cantinela de costumbre, se traza el rumbo, se izan las velas y se dan guiñas a la crujía hasta enfocar un buen puerto abierto y tranquilo, ahí tenemos un 27017. Abrimos los cartapacios y consultamos las cartas: MongoDB. Ahora toca cargar las piezas con un buen amasijo de contraseñas por defecto y "bum", tras unas pocas andanas la plaza se rinde y capitula. Victoria fácil y desmeritoria. A los pies, gigas y gigas de petróleo eléctrico, el botín es nuestro.
No hace falta ni cifrar. Ahora se extrae la base de datos cuidadosamente, trozo a trozo. Luego se borra por completo y se deja una nota de rescate: 1000 maravedíes a cambio de esta fabulosa fortuna. Suyo, el cybercrooker de turno. No pasa mucho tiempo cuando empiezan a sonar los timbres de los teléfonos del departamento técnico. No pasa mucho tiempo más cuando después de un reseteo la cosa sigue sin funcionar. Algo falla, los datos ya no están ahí.
Bases de datos secuestradas asomando en Shodan

Estos ataques se vienen produciendo desde enero de este año, cuando se reportó el secuestro progresivo de miles de bases de datos. No solo MongoDB, por supuesto, pero era significativo su porcentaje, que alcanzaba hasta un 56% del total de secuestros a manos de varios grupos organizados. Nada de zero-days, ni sofisticadas APT, palos y piedras: basta con probar un juego de contraseñas y clack, acceso permitido. Incluso algunas instalaciones ni tan siquiera poseían contraseña.
Poco a poco, los grupos organizados dieron cuenta de este nuevo filón y se fueron sumando a la fiesta, soltando automatismos que iban escudriñando la red en busca de objetivos. Una auténtica cadena de producción, donde todo es un proceso, desde la infección o ataque al propio pago. Podríamos hablar ya de un perfecto RaaS (Ransomware as a Service), la industrialización del pecado por omisión o desidia de algunas organizaciones, que movidos por la fiebre del low-cost reducen la planificación y despliegue al mínimo imprescindible.
Un trabajo que merece la pena atender, es el de los investigadores Víctor GeversNiall Merrigan y Dylan Kats. Se han dedicado a recopilar información sobre los ataques, transacciones, grupos involucrados, campañas, etc. Toda la información está disponible públicamente en una hoja de cálculo. En ella puede observarse una curiosa anotación "These are actors that have been found deleting databases without exfiltrating the data first. This means that they are unable to produce data even if ransom is paid". Es decir, que incluso pagando no hay datos de vuelta; algo que se observa con toda variante de Ransomware.


En este sentido, otro de los puntos reseñables en los datos acumulados es que los delincuentes "hacen caja". Si observamos las transacciones en bitcoins vemos flujos de pequeñas cantidades que han sido abonadas en un intento, muchas veces en vano, de recuperar los datos sustraídos. Esto podría haber hecho que los ataques repunten y que últimamente se observe una nueva oleada de secuestros.
Con el Internet de las cosas que parecen no importarnos lo más mínimo se han creado lucrativas botnets para extorsionar mediante denegaciones de servicio selectivas. Se han levantado granjas clandestinas de criptominado y ahora tenemos servicios publicados a la ligera, con datos valiosos protegidos por contraseñas (donde las hay) triviales. 
Justo aquí, en este bloque, tradicionalmente hemos puesto una serie de medidas para paliar semejantes agujeros. ¿Pero vale la pena el esfuerzo? ¿De verdad le interesa la seguridad a alguien que deja expuesto los datos del negocio a una distancia de 8 caracteres? Yo asumo que no. El mal rato dura lo que tardan los datos en reconstruirse o los seguros en responder o incluso puede que ese golpe termine por cargarse el negocio y apaga y vámonos, quien sabe. 
MongoDB ha publicado una guía de prácticas seguras y una checklist preciosa, algo es algo. Un solo administrador competente echa una mañana en bastionizar con esos documentos una instalación de MongoDB, pero claro eso ya sale caro, ya no es low-cost, ni un veterano ni una mañana en "perder" el tiempo arreglando algo que "funciona"...



David García@dgn1729dgarcia@hispasec.com




Más información
Massive Wave of MongoDB Ransom Attacks Makes 26,000 New Victimshttps://www.bleepingcomputer.com/news/security/massive-wave-of-mongodb-ransom-attacks-makes-26-000-new-victims/
How to Avoid a Malicious Attack That Ransoms Your Datahttps://www.mongodb.com/blog/post/how-to-avoid-a-malicious-attack-that-ransoms-your-data






Categories: Seguridad

Nuevas versiones de seguridad de Django

Hispasec - Fri, 08/09/2017 - 10:00
La Django Software Foundation ha publicado nuevas versiones de seguridad de las ramas Django 1.11 y 1.10, que soluciona una vulnerabilidad de cross-site scripting.

Django es un framework de código abierto basado en Python para el desarrollo de sitios web siguiendo el patrón MVC (Modelo-Vista-Controlador). Fue publicado por primera vez en 2005, y desde entonces su uso ha experimentado un considerable crecimiento entre los desarrolladores. Se compone de una serie de herramientas para facilitar la creación de páginas Web, siguiendo las directrices 'DRY' (Do not repeat yourself – No se repita) evitando redundancias de código y consecuentemente reduciendo tiempo y esfuerzo.

La vulnerabilidad, identificada con el identificador CVE-2017-12794, se produce sólo cuando se tiene el modo debug activado (DEBUG = True) y podría permitir a un atacante remoto llevar a cabo ataques de cross-site scripting contra la página de retorno de error 500 que devuelve el framework.

Django Software Foundation ha publicado las versiones Django 1.11.5 y 1.10.8 de Django que soluciona la vulnerabilidad. Las actualizaciones están disponibles desde la página oficial de Django.
Django 1.11.5https://www.djangoproject.com/m/releases/1.11/Django-1.11.5.tar.gzDjango 1.10.8https://www.djangoproject.com/m/releases/1.10/Django-1.10.8.tar.gz


También se encuentran disponibles los parches en github o a través del aviso publicado:https://www.djangoproject.com/weblog/2017/sep/05/security-releases/

Más información:Django security releases issued: 1.11.5 and 1.10.8https://www.djangoproject.com/weblog/2017/sep/05/security-releases/Fernando Ramírezframirez@hispasec.com
@fdrg21
Categories: Seguridad

La brecha en Taringa expone a 28 millones de usuarios

Hispasec - Thu, 07/09/2017 - 10:00



Hace un mes el portal Taringa avisaba a sus usuarios que sus servidores se habían visto comprometidos, y con ellos la base de datos y el código fuente de la página. Ahora, LeakBase ha tenido acceso a los datos robados, entre los que se encuentran emails, nombres de usuario y hashes md5 de 28.722.877 usuarios.
Taringa se encuentra entre los portales más importantes de habla hispana, ocupando según Alexa el puesto número 12 de sitios más visitados de Argentina (su país de origen).
Al momento de escribir estas líneas, LeakBase ya ha obtenido el 93.79% de las contraseñas (casi 27 millones), y tras contactar el portal PentestingExperts con algunos de los afectados por email, se ha podido dar validez a la filtración. A la gravedad del asunto, hay que sumarle que las claves estén cifradas con md5, el cual se considera inseguro desde 2012.
Cabe recordar, que es insuficiente proteger las claves usando una función hash como md5, debiéndose utilizar medidas adicionales como las que añade Bcrypt, como un salt. Si no, nos estaremos arriesgando a que las claves sean fácilmente descifrables, o incluso a poder encontrarlas en bases de datos de hashes.



De las claves obtenidas y por la información facilitada por LeakBase, podemos concluir:
  • Cerca de la mitad han sido utilizadas por más de una persona (15.320.524 claves únicas).
  • La clave 123456789 es la más utilizada con diferencia (casi el doble que la segunda más utilizada, 123456)
  • Las longitudes más populares son 6 (29.82%) y 8 (20.2%).
  • El 44.98% utiliza minúsculas y números, el 29.89% sólo minúsculas, y el 16.81% sólo números.
  • Destacar también, que la tercera clave más usada fue el propio nombre del sitio, y que el 0.37% de las contraseñas contenían la palabra taringa.
Taringa entre las medidas adoptadas ya está avisando a sus clientes por email, y está obligando a reestablecer las claves a los usuarios afectados (que son, todos). No obstante, si tenéis cuenta en Taringa, y utilizáis la misma clave en otros sitios, os recomendamos cambiarla inmediatamente.

Juan José Oyaguejoyague@hispasec.com
Más información:

Notificación Taringahttps://www.taringa.net/posts/taringa/19972402/Un-mensaje-importante-sobre-la-seguridad-de-tu-cuenta.html

LeakBase
https://leakbase.pw/dbs.php
Estadísticas filtración por LeakBase
https://leakbase.pw/analysis/taringa/
Pentesting Expertshttp://www.pentestingexperts.com/taringa-over-28-million-users-data-exposed-in-massive-data-breach/
Categories: Seguridad

Actualizaciones de seguridad para Telerik UI ASP.NET AJAX

Hispasec - Wed, 06/09/2017 - 10:00
Se han publicado dos parches para Telerik UI ASP.NET AJAX que solucionan dos graves vulnerabilidades relacionadas con la subida de archivos al servidor y la ejecución de código remoto.



Para los que no lo conozcan, Telerik UI ASP.NET AJAX es una colección de componentes que facilitan el desarrollo de interfaces de usuario Web y móvil. Su uso está ampliamente extendido y ha sido adoptado en numerosos equipos de desarrollo de importantes empresas y organizaciones, como Microsoft, Philips, IBM o Sony entre otros.

Interfaz desarrollada con Telerik UI
Las vulnerabilidades afectan a todas las versiones de 'Telerik.Web.UI.dll' anteriores a la 2017.2.711.

La primera vulnerabilidad, identificada como CVE-2017-11357 afecta al componente RadAsyncUpload, que permite subir archivos al servidor al no validar correctamente las entradas de usuario.

La segunda vulnerabilidad, identificada como CVE-2017-11317 se debe a que 'Telerik.Web.UI' emplea un cifrado demasiado débil para encriptar los datos que recibe RadAsyncUpload, lo que podría ser explotado para subir ficheros arbitrarios y potencialmente ejecutar código remoto.

Se recomienda actualizar cuanto antes a la versión R2 2017 SP2 (2017.2.711) o posterior de Telerik UI para ASP.NET AJAX.



Francisco Salidofsalido@hispasec.com
Más informaciónASP.NET AJAX Insecure Direct Object Reference
http://www.telerik.com/support/kb/aspnet-ajax/upload-(async)/details/insecure-direct-object-reference

ASP.NET AJAX Unrestricted File Upload
http://www.telerik.com/support/kb/aspnet-ajax/upload-(async)/details/unrestricted-file-upload
Categories: Seguridad

Actualización de seguridad para Asterisk

Hispasec - Tue, 05/09/2017 - 10:00
Asterisk ha publicado tres actualizaciones de seguridad para solucionar tres vulnerabilidades que podrían permitir a atacantes remotos o en red local revelar información sensible, causar una denegación de servicio o ejecutar código arbitrario en los sistemas afectados.
Asterisk es una implementación de una central telefónica (PBX) de código abierto. Como cualquier PBX, se pueden conectar un número determinado de teléfonos para hacer llamadas entre sí e incluso conectarlos a un proveedor de VoIP para realizar comunicaciones con el exterior. Asterisk es ampliamente usado e incluye un gran número de interesantes características: buzón de voz, conferencias, IVR, distribución automática de llamadas, etc. Además el software creado por Digium está disponible para plataformas Linux, BSD, MacOS X, Solaris y Microsoft Windows.
La primera vulnerabilidad, explicada en el boletín AST-2017-005, permite a un atacante remoto obtener información sensible forzando que se le envíe información multimedia. El fallo tiene su origen en una relajación de las políticas de manejo de RTP, que permitían que una nueva fuente enviando RTP pudiese suplantar una fuente anterior (permitía el cambio de dirección de la fuente). Si la opción de RTP simétrico está activa, la nueva fuente suplantadora recibiría toda la información multimedia del nodo. La solución incluye una serie de mitigaciones y cambios en la política de envío y recepción de RTP.
La segunda vulnerabilidad, descrita en el boletín AST-2017-006, permite a un atacante en red local ejecutar código arbitrario en una shell del sistema. El fallo es un clásico, pasar un comando a la shell usando parámetros no escapados correctamente. De esta forma, se puede introducir un parámetro especialmente manipulado que rompa la lógica de lectura de la shell y permita ejecutar comandos arbitrarios en ésta. En este caso, los parámetros son el nombre de la persona que llama y su número, que son parámetros proporcionados desde fuera y por tanto no fiables. La solución pasa por no dejar que la shell sea la encargada de separar los parámetros entre sí.
La última vulnerabilidad, comentada en el boletín AST-2017-007, permite a un atacante remoto causar una denegación de servicio, haciendo que Asterisk caiga. El problema reside en la lectura de las cabeceras From, To y Contact, que puede fallar al leer una URI especialmente manipulada, tirando el sistema. La solución consiste en reforzar la lectura de estas cabeceras para que no falle con esas URI's.
Las dos primeras vulnerabilidades afectan a Asterisk Open Source en sus ramas 11, 13 y 14 y a Certified Asterisk en sus ramas 11.6 y 13.13, y la última vulnerabilidad afecta sólo a Asterisk Open Source en sus versiones 13.15.0 y 14.4.0. Actualizar a las últimas versiones de cada rama soluciona estos problemas.

Carlos Ledesmacledesma@hispasec.com
Más información:
Media takeover in RTP stack - ASTERISK-2017-005http://downloads.asterisk.org/pub/security/AST-2017-005.html
Shell access command injection in app_minivm - ASTERISK-2017-006http://downloads.asterisk.org/pub/security/AST-2017-006.html
Remote Crash Vulnerability in res_pjsip - ASTERISK-2017-007http://downloads.asterisk.org/pub/security/AST-2017-007.html



Categories: Seguridad

Grave vulnerabilidad en LabVIEW será finalmente parcheada

Hispasec - Mon, 04/09/2017 - 10:00
El investigador Cory Duplantis (@ctfhacker) de la firma de seguridad Cisco Talos, ha hecho público recientemente un reporte de una vulnerabilidad de ejecución arbitraria de código, que afectaría a LabVIEW, y que, tras la repercusión en los medios, el fabricante ha decidido finalmente planificar un parche para solucionarla.

LabVIEW de National Instruments
LabVIEW, de la empresa National Instruments, es una plataforma y entorno de desarrollo para diseñar sistemas, con un lenguaje de programación visual gráfico. Recomendado para sistemas hardware y software de pruebas, control y diseño, simulado o real y embebido, pues acelera la productividad.

La vulnerabilidad 
Según Duplantis , la vulnerabilidad (CVE-2017-2779) se presentaría a la hora de cargar ficheros VI especialmente manipulados.
Este formato propietario (VI), es bastante potente y flexible, por lo que es equiparable a un fichero EXE o DLL, y permite de serie, ejecutar código embebido. El propio fabricante recomienda, por tanto, no abrir ficheros VI provenientes de orígenes desconocidos o no fiables, como pudiera ser un correo electrónico o un archivo descargado directamente de Internet.
Según su investigación, el problema principal reside a la hora de procesar el segmento RSRC del fichero VI y cargarlo en memoria. En concreto durante el proceso encargado del contador de bucle, que podría ser modificado por un atacante para provocar una escritura fuera de límites y elevar permisos de seguridad, permitiendo la ejecución de código arbitrario.
La polémica
Aunque parecía evidente la gravedad de la vulnerabilidad reportada por Duplantis, el fabricante comunicó a Talos que no iba a actualizar esta incidencia en su software por no considerarla una vulnerabilidad grave.

Sin embargo, Talos recordaba en su reporte que esta vulnerabilidad (reportada a la firma en enero de este año) era similar a la parcheada por Microsoft y su entorno .NET (CVE-2007-0041) por lo que recomendaba al fabricante tomar las medidas oportunas.  A los pocos días, firmas como 0patch ya estaban ofreciendo micro parches para solucionarlo, e incluso mostraban abiertamente lo sencillo de su solución, tanto en una extensa entrada en su blog, como en éste vídeo: 

National Instruments, ante estos hechos, ha recapacitado y planificado un parche para resolverla, que será liberado próximamente, actualizando además, el listado de versiones afectadas: 
LabVIEW 2017
LabVIEW 2016
LabVIEW 2015
LabVIEW 2014 

Más información: 
Cory Duplantis @ctfhacker https://twitter.com/ctfhacker 
National Instruments LabVIEW RSRC Arbitrary Null Write Code Execution Vulnerability https://www.talosintelligence.com/reports/TALOS-2017-0273/ 
Vulnerability Spotlight: Code Execution Vulnerability in LabVIEW http://blog.talosintelligence.com/2017/08/vulnerability-spotlight-code-execution.html 
Incomplete RSRC Validation in LabVIEW http://www.ni.com/product-documentation/54099/en/ 
Security Best Practices for LabVIEW VI Files  http://digital.ni.com/public.nsf/allkb/ECCA13EDE2300EFA86257FE100747965 
0patching the RSRC Arbitrary NULL Write Vulnerability in LabVIEW (CVE-2017-2779)  https://0patch.blogspot.com.es/2017/09/0patching-rsrc-arbitrary-null-write.html
Categories: Seguridad

Campaña de "boletos" fraudulentos afecta a Iberia y Ryanair

Hispasec - Sun, 03/09/2017 - 10:00
Desde el laboratorio Hispasec queremos alertar de una nueva campaña de scams o estafas a través de Internet dirigidos a empresas españolas, que al igual que pasadas campañas (como la que ya comentamos en 2015 y que afectó a Mercadona, entre otros) utilizan el correo electrónico y Facebook como vector de propagación. 
Campaña de boletos fraudulentos de Iberia
Este tipo de campañas tienen como objetivo principal recolectar datos privados (nombre, email, edad, dirección...) de los visitantes para utilizarlos en campañas de spam posteriores y sobre todo, para poder obtener sus números de teléfono móvil y suscribirlos a servicios Premium de pago.Debido a la mala praxis de muchos usuarios al aceptar las condiciones y términos de servicio sin leerlos previamente, el visitante incauto puede caer en suscripciones indebidas y el cobro de servicios abusivos.Todo estos datos recolectados crean un perfil bastante completo sobre el visitante que es vendido a terceros, por lo que continúan llegando publicidad bien por correo, bien por SMS. Detrás de estas campañas siempre hay grupos de spammers que utilizan y reutilizan kits fácilmente modificables y empresas de dudosa legalidad, ligadas a este mercado que facilitan las plataformas necesarias de venta de clicks y visitas para publicidad.
Si nos ceñimos a esta campaña en concreto, que afectaría a Iberia y también a Ryanair, los dominios involucrados son los siguientes:
* hxxp:// iberia-usa .us
* hxxp:// iberia-fly .us
* hxxp:// iberiasep .us
* hxxp:// www. iberiaes-ticket .us


En un primer acceso, la campaña nos pide que nos conectemos a Facebook para compartir el supuesto boleto/ticket, y así poder propagarse rápidamente mediante nuestro "timeline".



El último paso, si aceptamos el supuesto "Like" nos redireccionará a un segundo dominio de scam, donde dependiendo del país desde que lo visitemos, nos mostrará una campaña u otra. Actualmente para los visitantes españoles muestra un scam de Ryanair, donde se piden datos privados, teléfono incluido y que es la parte más peligrosa en términos de spam posterior y monetarios dado el caso.



Desde nuestro laboratorio recomendamos encarecidamente ser precavidos y no rellenar ningún tipo de dato privado en cualquiera de estas campañas y aplicar el sentido común.

Recordar también que desde Hispasec y gracias al servicio Antifraude, ofrecemos un servicio integral de detección y desactivación de este tipo de amenazas para evitar el abuso de marca en Internet.
José Mesa Orihuela@jsmesa


Más información:
Promoción falsa: Iberia no está regalando dos boletos por redes socialeshttp://www.nacion.com/tecnologia/Iberia-regalando-boletos-sociales-promocion_0_1638036231.html
Categories: Seguridad

XI Jornadas STIC CCN-CERT

Hispasec - Sat, 02/09/2017 - 09:30
El próximo 13 y 14 de diciembre se celebrarán en Madrid las XI jornadas STIC CCN-CERT, promovidas por el Centro Criptológico Nacional, con el lema Ciberamenazas, el reto de compartir.
Este evento, que ya reuniera en 2016 a más de 1.700 expertos, se ha convertido en un referente en materia de ciberseguridad y punto de encuentro de profesionales, tanto del sector público como de las empresas con intereses estratégicos en el ámbito de la nación.
Los temas a tratar durante el evento versan desde las amenazas avanzadas y persistentes APT, el Esquema Nacional de Seguridad (ENS), herramientas de ataque y defensa, aprendizaje computacional orientado a la ciberseguridad, innovación tecnológica, modelos de compartición de información, el reglamento general de protección de datos (RGPD) y la gestión de crisis.
Para aquellos que deseen contribuir y participar con una propuesta, existe un plazo de presentación hasta el 2 de octubre. El documento para el CFP está disponible aquí.






David García@dgn1729dgarcia@hispasec.com


Más información


XI JORNADAS STIC CCN-CERT
https://www.ccn-cert.cni.es/xijornadas.html

Categories: Seguridad

711 millones de correos electronicos expuestos.

Hispasec - Fri, 01/09/2017 - 10:00
Los investigadores Troy Hunt y Benkow moʞuƎq han descubierto a través de un correo de spam un componente malicioso, localizado en una IP holandesa, que contaba con un gran numero de archivos con información personal. Un total de 711 millones de e-mails con sus correspondientes contraseñas se encuentran comprometidas. La información se ha añadido al sitio web haveibeenpwned para comprobar si tu cuenta de correo se encuentra afectada.
Formato de los correos encontrados en el volcado.
Antiguamente hacer envíos de spam en masa era mucho mas sencillo. Los atacantes buscaban servidores SMTP vulnerables con contraseñas débiles y los utilizaban para enviar spam. Sin embargo, hoy en día existen cientos de empresas y firewalls dedicados a frenar el spam en la red. Además, estos servidores comprometidos se encuentran en una blacklist por lo que no son viables para dicha tarea. 
A pesar de esto, existen dos metodos populares hoy en día:
El primer método es hacer uso de un mailer en PHP en servidores web comprometidos:
  1. El atacante escanea cientos de sitios web hasta dar con varios miles de servidores vulnerables o los compra en el mercado negro.
  2. Utiliza un script en PHP encargado de hacer el envio fraudulento
  3. Todos los servidores estan sincronizados y monitorizados por un panel oculto. 
El segundo método es a través de malware. Este metodo consiste en hacer un software malicioso haga de servidor SMTP permitiendo el envio de correos maliciosos. Cuantos más dispositivos sea capaz de comprometer el atacante, mayor cantidad de spam será capaz de enviar. 
En resumidas cuentas, los atacantes cuentan con dos opciones: Crear su servidores SMTP o comprarlos.
En la última campaña de Ursnif el atacante el atacante se dejó por error un directorio expuesto perteneciente al Command and Control del spammer. En este directorio, existían más de 40GB en e-mails. Entre ellos, se incluyen:
  • Credenciales email: contraseña en texto plano.
  • Enorme lista de correos electrónicos.
  • Configuración del spambot.

Infraestructura de un spambot

Si quieres comprobar si te encuentras afectado por este volcado, puedes hacerlo introduciendo tu dirección de correo electrónico en haveibeenpwned.com
Fernando Díazfdiaz@hispasec.com@entdark_
Mas información:
From Onliner Spambot to millions of email's lists and credentialshttps://benkowlab.blogspot.com.es/2017/08/from-onliner-spambot-to-millions-of.html
Inside the Massive 711 Million Record Onliner Spambot Dumphttps://www.troyhunt.com/inside-the-massive-711-million-record-onliner-spambot-dump/
Categories: Seguridad

Pages

Subscribe to Bytecoders aggregator - Seguridad