Noticias de Seguridad Abril 2018

Estado del arte del malware de minado de criptomonedas publicado por CSIRT-CV

El Centro de Respuesta ante Incidentes de la Comunitat Valenciana (CSIRT-CV) ha publicado hoy un estudio sobre el estado del arte de algunas de las variantes más extendidas de amenazas orientadas al minado de criptodivisas.

En el informe se detallan el tipo de equipos objetivo más comunes de cada una, así como sus principales vías, técnicas de infección y últimas tendencias que este CSIRT ha detectado.

A partir de toda la información recabada en dicho informe se puede enfatizar el considerable incremento de nuevas amenazas de tipo ‘miner’ y el hecho de que la mayoría se basan en código reutilizado de repositorios públicos. Otro hecho interesante es que se está explotando todo tipo de dispositivos para minar criptomonedas, desde equipos de usuario, servidores, smartphones y dispositivos IoT.

En el informe de CSIRT-CV no solo nos hablan de los equipos de usuario o servidores como objetivos de infección sino de los dispositivos Android.

Malware como Loapi o ADB.Miner están en auge y cada vez son más las APK que intentan aprovecharse de la potencia de cómputo de los cada vez más avanzados terminales móviles o dispositivos IoT para minar criptomonedas. Un ejemplo de este hecho es el que muestran en el informe, en el que muestran cómo partiendo de nuestra plataforma Koodous y unas sencillas firmas Yara se pueden ir detectando un gran número de APK sospechosas de tener como objetivo no lícito el minado de criptomonedas.

A nivel de tendencias destacan, entre otras, en cuanto a infección de servidores, la distribución de ‘miners’ haciendo uso de vulnerabilidades en los procesos inseguros de deserialización de objetos Java para, tras explotarlas, descargar y ejecutar el ‘miner’ en el servidor comprometido, el aumento de la explotación de las vulnerabilidades CVE-2017-5638 (Apache Struts) y CVE-2017-9822 del servicio DotNetNuke para introducirse en los sistemas y dependiendo de si se trata de un servidor Windows o Linux, cuenta con diferentes Payloads en Powershell o Bash a partir de los cuales descarga el ‘miner’ en el equipo.

En el informe también se recogen una serie de mecanismos de detección para los distintos tipos de ‘miners’ mencionados tanto a nivel de red como de dispositivo y una serie de recomendaciones para protegerse ante este tipo de malware.

Publicada en el BOE la instrucción técnica sobre auditorías de seguridad ENS

Nos hacemos eco, vía el CCN-CERT, de la publicación en el BOE de la tercera instrucción técnica acerca de las auditorías de seguridad obligatorias, la cual, establece las condiciones en las que deberán realizarse las auditorías de seguridad obligatorias para los sistemas clasificados con categoría MEDIA o ALTA, dentro del ámbito del Esquema Nacional de Seguridad (en adelante, ENS).

¿Qué es una instrucción técnica? 

En las propias palabras del CCN-CERT:

Estas instrucciones técnicas entran a regular aspectos concretos que la realidad cotidiana ha mostrado especialmente significativos, tales como: Informe del Estado de la Seguridad; notificación de incidentes de Seguridad; auditoría de la Seguridad; conformidad con el Esquema Nacional de Seguridad; adquisición de Productos de Seguridad; criptología de empleo en el Esquema Nacional de Seguridad; interconexión en el Esquema Nacional de Seguridad y Requisitos de Seguridad en entornos externalizados, sin perjuicio de las propuestas que pueda acordar el Comité Sectorial de Administración Electrónica, según lo establecido en el citado artículo 29.

¿Ha de auditarse un sistema de información de categoría BÁSICA?

No es obligatorio, pero de forma voluntaria es recomendable. Un sistema de información con dicha categoría sólo está obligado a una autoevaluación por los administradores o en quien estos deleguen. Básicamente, un documento donde se expone que las medidas de seguridad exigidas están implementadas y son revisadas con regularidad.

¿Cuándo debo auditar los sistemas de información con categoría MEDIA o ALTA?

Las auditorías son necesarias, al menos una cada dos años, para obtener la certificación de adecuación al ENS. Además, se deberán realizar auditorías extraordinarias cada vez que el sistema reciba modificaciones cuyo alcance modifique los requerimientos de seguridad.

Independencia del auditor

Un punto interesante y a tener en cuenta es la circunscripción explícita de las tareas de auditorías al cometido o ámbito para la que están encomendadas. Esto, impide que dentro del proceso de auditoría entren funciones de consultoría, labores de implantación o la modificación lógica de las aplicaciones del propio sistema de información auditado. Incluso cierra la puerta a la realización de la documentación exigida por el ENS o los procedimientos de actuación.

Es decir, el auditor viene a auditar. Solo eso. Se respeta así la independencia de un proceso. Por lo que, ni el auditor puede ofertar arreglar los fallos que él mismo encuentra (algo, muy cuestionable éticamente) ni por tu parte puedes exigirle que implemente las modificaciones y medidas propuestas por él en su informe. Es más, se hace explícito algo que siempre hemos defendido desde HISPASEC: no recomendar ningún producto o servicio concreto. Independencia absoluta y sin intereses.

¿Cómo se clasifican los hallazgos?

En dos. “No conformidad menor” y “No conformidad mayor”. Las primeras indican fallos o controles de seguridad ausentes en uno o más requisitos del ENS. Pero ojo, dan cabida a la “duda significativa”. Es decir, cuando mediante una evidencia objetiva, el auditor plantee la posibilidad de existencia de una no conformidad en los requisitos, entonces pasa a considerarse una no conformidad de lleno.

Para que nos hagamos una idea, una no conformidad podría ser no usar criptografía en dispositivos removibles (un USB) si el sistema de información posee categoría MEDIA o ALTA; siendo necesario en ésta el uso de algoritmos aprobados por el Centro Criptológico Nacional (CCN).

Resultados de la auditoría

La auditoría posee tres finales posibles: “FAVORABLE”, en el cual el sistema no poseerá ninguna “no conformidad”. “FAVORABLE CON NO CONFORMIDADES”, en la que existen deficiencias, tanto mayores como menores. En este caso, se deberá presentar en el plazo de un mes un Plan de Acciones Correctivas sobre dichos hallazgos a la entidad certificadora. Por último, tenemos el resultado “DESFAVORABLE”. En este caso, se deberá realizar una nueva auditoría extraordinaria, en el plazo de seis meses, para comprobar que se han solucionado los hallazgos encontrados por el auditor.

Vulnerabilidad crítica en Cisco IOS deja a miles de dispositivos al descubierto

La vulnerabilidad permite a un atacante remoto ejecutar código arbitrario, tomar el control total de los equipos de la red vulnerable e interceptar tráfico.

Resultado de imagen de cisco hackedLa vulnerabilidad de desbordamiento de búfer (CVE-2018-0171) reside debido a una validación incorrecta de los datos del paquete Small Install Client, el cuál es una función plug-and-play que ayuda a los administradores a implementar dispositivos de red fácilmente.

La empresa Embedi, descubridora de este fallo, ha publicado los detalles técnicos y el código de la prueba de concepto (PoC) después de que Cisco lanzara las actualizaciones pertinentes para abordar el fallo.

Como funciona la vulnerabilidad:

Un atacante debe enviar un mensaje de instalación del software antes mencionado (Small Install Client) a un dispositivo afectado en el puerto 4784, que está abierto de manera predeterminada.

Cisco comentó en un comunicado:

“Para ser más precisos, el desbordamiento de búfer se encuentra en la función ‘smi_ibc_handle_ibd_init_discovery_msg'” y “porque el tamaño de los datos copiados directamente a un búfer de tamaño fijo no son comprobados. El tamaño y los datos se toman directamente del paquete de red el cuál es controlado por el atacante.”

Cisco publicó el parche para corregir este fallo el 28 de Marzo, por lo que se recomienda a todo el mundo que actualice sus dispositivos lo antes posible.

Ejecución remota de código en el motor de Microsoft Malware Protection

Microsoft ha actualizado urgentemente su motor Microsoft Malware Protection (mpengine.dll) para corregir una vulnerabilidad crítica que afectaría, entre otros, a Windows Defender, Security Essentials y Exchange Server.

La vulnerabilidad fue descubierta por el investigador de Google Project Zero, Thomas Dullien, y se le ha asignado el CVE-2018-0986. Según la investigación de Thomas, existiría una incorrecta comprobación de valores en el módulo principal “mpengine.dll”, al haber realizado una implementación de la gestión de archivos comprimidos en formato RAR, utilizando para ello un fork del código libre de unrar.
El problema reside en la modificación del código original, eliminando la comprobación de signo de los valores (signed int), que sí estaba presente inicialmente.
En base a la prueba de concepto publicada, un atacante, utilizando un fichero .RAR especialmente modificado, podría generar un desbordamiento de memoria y potencialmente ejecutar código de manera remota, como se comenta en el propio reporte:

An attacker that can set PosR to be -2, and DataSize to 1, will bypass the (PosR + 2 < DataSize) check.

A minimal sample RAR file that exhibits these traits & causes mpengine to corrupt memory and crash is attached.

Debido a que este motor está presente de serie en diversas versiones de Windows (desde la 7 hasta la 10) y herramientas específicas de correo, como Exchange server, se han publicado urgentemente paquetes de actualizaciones automáticas para corregir la vulnerabilidad.

Las versiones afectadas son:

  • Microsoft Exchange Server 2013 y 2016
  • Microsoft Forefront Endpoint Protection 2010
  • Microsoft Security Essentials
  • Windows Defender (Windows 7, 8, 10, Server 2012, 2016)
  • Windows Intune Endpoint Protection
Más información:
 
CVE-2018-0986 | Microsoft Malware Protection Engine Remote Code Execution Vulnerability
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0986

Rarog: malware para realizar ataques de minado de criptomonedas

El equipo de investigadores de Palo Alto Networks realiza un análisis de Rarog, un troyano de minado de criptomonedas que está creciendo en popularidad debido a su facilidad de uso y versatilidad.

Rarog se empezó a vender en foros underground en junio del 2017. Su precio y su sencillez lo han hecho muy atractivo para delincuentes noveles que quieren realizar ataques de minado de criptomonedas.

Hasta la fecha se ha detectado más de 166.000 infecciones relacionadas con Rarogalrededor de todo el mundo. La mayoría de estas infecciones apuntan a ciudadanos de Filipinas, Rusia e Indonesia.

Mapa de infecciones. Fuente: paloaltonetworks.com

El malware es muy versátil: permite infectar dispositivos USB, configurar distintos programas de minado para distintas criptodivisas, inyectar DLL en la víctima… Además de contar con un panel web donde visualizar información estadística de los ataques y administarlos.

A pesar de esto, no se tiene constancia de ataques muy lucrativos. A lo sumo se ha podido encontrar el equivalente a unos 120 dólares en una de las carteras de un atacante.

Como decíamos, el troyano se puede adquirir en foros ‘underground’ por unos 6000 rublos, que al cambio equivalen a unos 85€.

Foro donde se anuncia el malware
Más información:
 

Cross-Site Scripting en IBM WebSphere Portal

Se ha publicado una vulnerabilidad en IBM WebSphere Portal que podría permitir un ataque de Cross-Site Scripting (XSS).

 

IBM WebSphere Portal es una solución de herramientas que permite gestionar y construir portales web.

La vulnerabilidad es causada por un error en el filtrado a la hora de procesar el código JavaScript introducido por el usuario y se le ha asignado el identificador CVE-2018-1483.

Esta puede ser aprovechada por un atacante remoto para realizar un ataque XSS, que permitiera ejecutar código JavaScript especialmente manipulado. Una explotación exitosa de la vulnerabilidad le permitiría, entre otras cosas, obtener acceso a las cookies de los objetivos, incluyendo las de sesión.

La vulnerabilidad afecta a las versiones 8.5 y 9 y ha sido corregida con el parche ‘APAR PI95221’ siguiendo la nomenclatura de IBM.

Más información:

IBM Security Bulletin:
https://www-01.ibm.com/support/docview.wss?uid=swg22015317

Paquetes fraudulentos en npm

Se han detectado un total de 40 paquetes maliciosos en el gestor de paquetes de Node.js.

npm es el manejador de paquetes que fue añadido al entorno de ‘Node.js’ en la versión 0.6.3. Desde entonces es instalado automáticamente con el entorno.

Oscar Bolmsten (@o_cee) fue el usuario de Twitter, que por esta red alertó de un comportamiento malicioso en el paquete ‘cross-env’ al detectar que robaba información de las variables de entorno durante la instalación.

Twit de Oscar Bolmsten (@o_cee), extraída de https://twitter.com/

Este paquete, según npm, es uno de los muchos paquetes fraudulentos detectados, el cual fue publicado por el usuario ‘hacktask’ el día 19 de Julio, imitando ser el paquete ‘crossenv’. Dicho paquete fue eliminado el 1 de agosto con unas 700 descargas, aunque muchas de éstas fueron realizadas por automatismos y tan solo unas 50 parecen ser infecciones reales.

Funciones inseguras de un futuro pasado

Desde hace algunos años, existe un grupo de funciones del lenguaje C que han sido el origen de multitud de quebraderos de cabeza, entendámonos, su (mal) uso suele derivar en agujeros de seguridad; algunos catastróficos

Microsoft, terminó por agrupar este variopinto conjunto de funciones en un archivo de cabecera llamado, explícitamente: “banned.h”. Anteriormente estaba publicado en este enlace, pero desde hace algún tiempo dejó de estar disponible. Aun así, Internet se ha encargado de guardarnos varias copias, así que (ojo con las fuentes) podemos, por ejemplo, bajarlo del Github de Mozilla.

Dicho esto, las funciones están definidas para el mundo Windows del desarrollo; aunque existen equivalentes para sistemas UNIX y muchas de ellas son extrapolables (tan solo cambia el nombre o se le añade un guión bajo). Básicamente, la mayor parte del problema reside en funciones que escriben o leen memoria reservada, pero lo hacen de forma incontrolada.

Programar en C o C++ no es fácil, aunque sí que es divertido, ya que dispones de una libertad y potencia que resulta difícil de alcanzar en otros lenguajes o entornos de ejecución. Tenemos a los nuevos vecinos Rust y Go, pero estos chicos aún tienen mucho que demostrar para destronar 40 años de reinado.

Sin duda, parte de la leyenda negra lo suponen estas funciones inseguras, procedentes de otros tiempos, donde aún no existía base de conocimiento alguna. No obstante, los compiladores modernos, librerías y nuevas herramientas pueden amortiguar lo que las prisas y la inexperiencia pueden causar.

 

Actualización de seguridad para Jenkins

Jenkins ha publicado un boletín de seguridad para corregir una vulnerabilidad media y otra menor sobre su core.

 

 

Jenkins es un popular software de integración continua (CI) de código abierto escrito en Java. Actualmente es mantenido por la comunidad y por el proveedor de servicios de CD/CI CloudBees.

 

Las versiones afectadas por estas vulnerabilidades son las anteriores a 2.116 para la rama Jenkins weekly y 2.107.2 para la versión LTS.

 

La primera vulnerabilidad identificada con el identificador SECURITY-754, afecta a la consola de comandos (CLI) y podría permitir a un atacante remoto acceder a vistas y agentes del sistema. El fallo ha sido descubierto a través de los errores que el sistema devuelve en función de los argumentos que un atacante va enviando al sistema.

 

La segunda vulnerabilidad identificada con el identificador SECURITY-759, está localizada en los cuadros de diálogo de confirmación de JavaScript. El fallo expone el nombre de algunos elementos de forma insegura, lo que podría ser aprovechado por un atacante para llevar a cabo ataques de tipo ‘cross site scripting’.

Jenkins dispone de una lista de correo en la cual los usuarios de este software pueden suscribirse para recibir notificaciones de seguridad. También pone a disposición de cualquier usuario que descubra alguna vulnerabilidad el siguiente enlace para reporte.

Más información:
 

Fallo en Outlook permite usar ficheros OLE remotos para filtrar la contraseña del usuario

Se ha descubierto un fallo en Outlook que permite la carga de objetos OLE remotos solo previsualizando un correo electrónico. Esto podría usarse para acceder a información secreta del usuario, como el hash de la contraseña del usuario de Windows.

Nos situamos en 2016. Buscando técnicas para saltar ASLR de Windows, el investigador Will Dormann, miembro del CERT, empieza a hacer pruebas incrustando ficheros OLE en el contenido de ficheros de formato de texto enriquecido (RTF). Sin embargo, la vulnerabilidad que encontró iba más allá de sus objetivos iniciales.

Desde hace tiempo, Microsoft Outlook (y la mayoría de clientes y plataformas de correo) bloquea la carga de imágenes remotas en correos HTML como medida de protección de la privacidad, concretamente para no desvelar la dirección IP. Para cargarlas, pide interacción del usuario.

Sin embargo, al enviar correos RTF con objetos OLE remotos incrustados, Dormann comprobó que se carga el contenido automáticamente y sin pedir ninguna autorización cuando estos objetos están alojados en un servidor SMB. Es más, esta carga no se realiza al abrir el correo, sino simplemente previsualizándolo.

A diferencia de los correos HTML, que revelarían únicamente nuestra dirección IP, al iniciar una  conexión SMB estaríamos enviando al servidor remoto mucha más (y más crítica) información del sistema:

  • Dirección IP.
  • Nombre de dominio.
  • Nombre de usuario.
  • Nombre del equipo.
  • Clave de sesión SMB.

Esta vulnerabilidad (CVE-2018-0950) ha sido solucionada en el último boletín de Microsoft. Ahora no se producen visualizaciones de contenido remoto OLE. Sin embargo, este no es el único modo en el que se podría forzar al cliente SMB de Windows iniciar una conexión SMB, por lo que se recomienda el bloqueo de los puertos involucrados en este tipo de conexiones.

Más información:
 

Automatically Stealing Password Hashes with Microsoft Outlook and OLE:
https://insights.sei.cmu.edu/cert/2018/04/automatically-stealing-password-hashes-with-microsoft-outlook-and-ole.html

 

Vulnerabilidades en VMware vRealize Automation 7

VMware ha publicado un boletín de seguridad con el objetivo de corregir dos vulnerabilidades en el panel de control de vRealize Automation, ambas relacionadas con el robo de sesiones de usuario

VMware vRealize Suite es una plataforma orientada a la gestión de la nube. De esta suite forma parte VMware vRealize Automation, la parte encargada de automatizar varios aspectos de la gestión de la nube, que presenta al usuario un panel de control web como parte de su funcionalidad. Precisamente a este panel mencionado le afectan dos vulnerabilidades relacionadas con el robo de sesiones de usuario,

La primera de las vulnerabilidades, identificada como CVE-2018-6958, es el clásico cross-site scripting. Básicamente consiste en la posibilidad de inyectar código JavaScript de forma inesperada en una página web, cosa que es posible porque la página web no limpia adecuadamente la entrada de datos de un usuario. Y por tanto, éste puede introducir datos especialmente diseñados para provocar la inyección. De hecho, es particularmente peligroso cuando los datos especialmente diseñados persisten de una carga de la página a otra, por almacenarse en la base de datos de la página. Esto permite que otro usuario distinto sufra la ejecución de la inyección JavaScript. El escenario descrito es de los más peligrosos para esta vulnerabilidad, y puede permitir el robo de sesión al obtener la cookie de otro usuario.

La segunda vulnerabilidad, con identificador CVE-2018-6958, refleja un problema en el manejo de identificadores de sesión de usuario. Según afirman, puede llevar a que se secuestre la sesión de un usuario. Si bien no especifican cómo, es bastante probable que sea porque los identificadores de sesión generados sigan un patrón, y que por tanto sea posible averiguar identificadores existentes o predecir los identificadores futuros. Ya que los identificadores de sesión se suelen presentar como una cookie, sería tan fácil como una vez obtenido el identificador de otro usuario, presentarlo como tuyo introduciendo esa cookie en tu navegador.

Ambas vulnerabilidades afectan a distintas versiones de la rama 7 de VMware vRealize Automation, y se han publicado versiones corregidas según indica el mismo boletín informativo.

Más información:

 
VMSA-2018-0009: vRealize Automation updates address multiple security issues
https://www.vmware.com/security/advisories/VMSA-2018-0009.html

HoleyBeep: escalado de permisos en Linux usando Beep

El programa Beep, disponible en la mayoría de distribuciones, no parecía mantenerse desde el año 2013 a pesar de emplear el ejecutable el bit SUID

Parece casi una broma, como así evidencia la web creada para la ocasión (holeybeep.ninja) con un gran sentido del humor, pero fallos como estos no hacen más que demostrar la falta de auditoría de código, más en casos como estos en los que el programa hace uso del bit ‘SUID’.

El bit ‘SUID’, permite la ejecución de un programa como otro usuario (el creador del ejecutable) para así poder realizar operaciones que normalmente no podría realizar el usuario que emplea el programa. Un ejemplo clásico es el comando ‘passwd’: este  programa requiere modificar el archivo protegido del sistema (‘/etc/shadow’) donde se almacenan las contraseñas de los usuarios, pero un usuario común requiere poder cambiar su propia contraseña (pero no la del resto de usuarios). En este caso, el programa ‘passwd’se ejecuta como root a pesar de emplearse por un usuario sin permisos, y es el programa el encargado de asegurar que el usuario no pueda realizar acciones que pongan el sistema en riesgo.

En el caso que nos ocupa, el programa Beep, que hace uso del bit ‘SUID’ para ejecutarse como root por un usuario común, llevaba varios años sin actualizarse. Cualquiera pensaría que un programa de este tipo, de tan solo 375 líneas de código y tantos años a sus espaldas (la versión 1.2.2 es de 2002) no contaría con vulnerabilidades, lo que ha quedado patente que no es así. La vulnerabilidad (CVE-2018-0492) es provocada por un efecto carrera que permitiría escribir a un archivo protegido tal y como se explica en Pirhack’s Blog, y así escalar privilegios.

La vulnerabilidad, de la que ya hay un ejemplo de explotación, aprovecha que la función ‘handle_signal del programa es un signal (permitiendo su ejecución en cualquier momento), para así ejecutarse manteniendo el valor anterior de la variable console_type, y el nuevo de la variable console_fd, y así poder escribir a cualquier archivo.

Por suerte el programa no se encuentra instalado de serie en distribuciones como Debian, aunque sí es un paquete conocido y utilizado por scripts. Aunque las vulnerabilidades para escalado de permisos son comunes, los ejecutables que hacen uso del bit ‘SUID’ deberían ser los primeros en ser analizados en busca de este tipo de errores.

Más información:
 
Holey Beep:

Una vulnerabilidad en un dispositivo IoT pone patas arriba la seguridad de un casino

El jueves de la pasada semana el CEO de la empresa de seguridad Darktrace, Nicole Eagan, que asistía al evento WSJ CEO Council Conference en Londres, contó ante los asistentes un escenario que cada día está tomando mayor repercusión: acceder a un sistema informático a través de un dispositivo IOT.

 
La noticia de la cual se hacía eco Nicole Eagan, sin citar ni a la empresa comprometida ni al dispositivo IoT, era que un casino había sido ‘hackeado’ a través de una vulnerabilidad en el termómetro de uno de los acuarios que formaban parte de la decoración. La información obtenida por los atacantes era la base de datos de los clientes del casino.
 
Este escenario que se presentaba el pasado jueves bien podría formar parte de la próxima película de Ocean’s Eleven, pero la realidad no es mucho más halagüeña. El número de dispositivos IoTs que conectamos a nuestra red no para de aumentar. Esta situación unida a la escasa seguridad que presentan algunos dispositivos IoTs hacen que estos dispositivos sean una puerta de entrada sobre la que después pivotan los atacantes hacia objetivos de mayor criticidad.
 
La empresa consultora Gartner asegura que en el último año había crecido un 31% el número de dispositivos IoT, llegando a la cifra de 8.400 millones de dispositivos conectados, y para 2020 la previsión es que esta cifra superará los 20 mil millones de dispositivos.
Para las empresas es vital tener un correcto plan de auditoría técnica que permita a expertos revisar la seguridad de toda su red para poder detectar y mitigar estos problemas de seguridad.
Más información:
 
Casino smart thermometer hacked:

Actualización de seguridad del lenguaje Perl

Perl es un popular lenguaje de programación creado en 1987 por Larry Wall. Es un lenguaje polifacético y usado en multitud de entornos y plataformas.

La distribución del lenguaje ha recibido una actualización de seguridad que corrige tres vulnerabilidades importantes que podrían causar revelación de información, denegación de servicio y potencialmente ejecución de código arbitrario.El primer fallo ha sido descubierto por Brian Carpenter. Se trata de un error en el procesamiento de expresiones regulares que podría causar un desbordamiento de memoria pasada en montículo a través de una expresión regular maliciosa.

El segundo fallo, descubierto por Nguyen Duc Manh, también afecta al mismo componente al hacer referencia a un elemento ya definido. Esto podría desencadenar la revelación de partes de la memoria y potencialmente un desbordamiento de memoria basada en montículo.

El último fallo ha sido descubierto por GwanYeong Kim y afecta a la función ‘pack()’. Se trata, del mismo modo, de un desbordamiento de memoria basada en montículo cuando se está procesando un gran número de objetos.

Los fallos afectan desde la versión de Perl 2.18 a la 2.26.1 inclusives.

Más información
heap-buffer-overflow (WRITE of size 1) in S_regatom (regcomp.c)https://rt.perl.org/Public/Bug/Display.html?id=132227

Heap-buffer-overflow in Perl__byte_dump_string (utf8.c)
https://rt.perl.org/Public/Bug/Display.html?id=132063

heap-buffer-overflow in S_pack_rec
https://rt.perl.org/Public/Bug/Display.html?id=131844

Carga insegura de librerías en Foxit Reader

Foxit Reader, presentado como una alternativa al lector de PDF Adobe Reader con algunas mejoras, sufre de una de las vulnerabilidades menos conocidas: la carga insegura de DLL’s.

Foxit Reader es una herramienta dedicada al formato de archivos PDF, que puede ver, crear, editar, imprimir y firmar digitalmente. Bajo el modelo de características base gratuitas y servicios adicionales de pago conocido como ‘freemium’, esta aplicación está desarrollada por Foxit Software, una compañía localizada en Fremont, California. Las primeras versiones de Foxit Reader se hicieron famosas por ser rápidas y livianas.

Esta vez, Foxit Reader es noticia por presentar una vulnerabilidad poco común, que tiene su origen en un fallo de programación a la hora de especificar las DLL’s a cargar por el programa. La vulnerabilidad concreta es conocida como ‘Unsafe DLL loading’, y consiste en que es posible engañar al programa para que cargue una DLL diferente a la original. Debido a que por defecto las DLL’s al ser cargadas ejecutan un método encargado de inicializar recursos que necesite la DLL (llamado ‘DllMain’), esto es equivalente a ejecución de código arbitrario, si bien las condiciones están ciertamente restringidas.

Generalmente, en Windows la carga de DLL’s funciona buscando la librería en distintas rutas, siguiendo el siguiente orden (en Windows XP, en versiones modernas varía ligeramente):

  1. Donde reside el ejecutable
  2. El directorio actual (no es lo mismo que el primer punto)
  3. El de sistema (típicamente ‘C:\Windows\System32\’)
  4. Otro de sistema, pero el de 16 bits (‘C:\Windows\System\’)
  5. El directorio de Windows (‘C:\Windows\’)
  6. Los directorios especificados en la variable de entorno ‘PATH’
Windows no usa esa lista de búsqueda si se especifica una librería con una ruta absoluta (por ejemplo, C:\Windows\System32\rtutils.dll’) en lugar de relativa (‘rtutils.dll’), y va directamente a por la librería en esa ruta. Pero si efectivamente usa una ruta relativa, entonces usará esa lista de búsqueda. A partir de Windows XP SP2, al estar activado por defecto el valor del registro SafeDllSearchMode’, el orden cambia y el directorio actual pasa al quinto lugar de esa lista, haciendo un poco más segura la carga de DLL’s.
Sin embargo, a pesar de ésto, la carga de DLL’s sigue siendo vulnerable al buscar donde reside el ejecutable, o incluso si no existe la DLL, terminaría por usar rutas como el directorio actual o sacadas de la variable de entorno ‘PATH’. Lo cierto es que las condiciones son un poco especiales, y en las posibilidades de explotación se habla de una víctima ejecutando programas en un servidor de archivos remoto (un escenario no muy común y peligroso ya de por sí por otras razones).
Al final, nos quedamos con que si podemos escribir en la carpeta de una aplicación con esta vulnerabilidad, aunque no tengamos permisos de ejecución, cuando esa aplicación se ejecute tirará de la librería maliciosaplantada por el atacante en lugar de la librería del sistema. Si bien no es una técnica muy usada en explotación, sí lo es en malware, donde los autores plantan una DLL maliciosa como una forma poco usual y enrevesada de conseguir persistencia del malware en el sistema.
Foxit Software ya ha corregido esta vulnerabilidad en la última versión de Foxit Reader disponible en su página web.
Más información:
 
Foxit Reader 8.3.1.21155 (Unsafe DLL Loading Vulnerability)
http://seclists.org/fulldisclosure/2018/Apr/41

Vulnerabilidad en la función autocompletar de LinkedIn podría poner en peligro los datos de los usuarios

Vulnerabilidad descubierta en la funcionalidad autocompletar de Linkedin permite el robo de datos

Una nueva vulnerabilidad descubierta en la popular funcionalidad de ‘Autocompletar’ o ‘Auto fill’ que puede permitir el robo de datos por parte de terceros.

Esta funcionalidad proporciona que otros sitios web puedan permitir que los usuarios de LinkedIn puedan completar rápidamente los datos del perfil, incluyendo información sensible como nombre completo, número de teléfono. dirección de correo electrónico, código postal, empresa…etc en un solo clic.

Recientemente el investigador de seguridad Jack Cable de ‘Lightning Security’descubrió que podía no ser así.

Descubrió que esta funcionalidad estaba plagadas de vulnerabilidades que permitiría a cualquier sitio web obtener los datos del perfil del usuario sin que el usuario se diera cuenta.

Un atacante puede hacer que la funcionalidad autocompletar en su sitio web cambiando algunas propiedades como la de extender esta funcionalidad a través de todo el sitio web para posteriormente hacerlo invisible, en el momento en el que el usuario haga click en cualquier parte de la web desencadenaría la ejecución de esta función y el envío de los datos albergados en la funcionalidad. Por pasos sería de la siguiente manera:

  • El usuario visita el sitio web malicioso, que carga el ‘iframe’ del autocompletar de LinkedIn.
  • El ‘iframe’ ocupa toda la página web y es invisible al usuario.
  • El usuario hace clic en cualquier parte de la web.
  • Los datos son enviados un sitio web malicioso.
Esta vulnerabilidad fue reportada e inmediatamente la compañía emitió una solución temporal a este posible ataque. La corrección restringe el uso de la función autocompletar a los sitios incluidos en la ‘white list’ o lista blanca.
El mismo investigador ha subrayado que el parche está incompleto y que aún permitiría usar esta características por los dominios incluidos en la lista blanca. Por lo tanto si cualquiera de estos sitios se viera comprometido, podría hacerse uso de este ataque.
Por parte de LinkedIn ya han lanzado el parche completo, en un comunicado por parte de la entidad aclaran lo sucedido:

“We immediately prevented unauthorized use of this feature, once we were made aware of the issue. We are now pushing another fix that will address potential additional abuse cases, and it will be in place shortly,” the company said in a statement. 

“While we’ve seen no signs of abuse, we’re constantly working to ensure our members’ data stays protected. We appreciate the researcher responsible reporting this, and our security team will continue to stay in touch with them.”

Más información:

Twitter del investigador:
https://twitter.com/jackhcable
Web para la prueba de concepto:

Software malicioso escondiéndose detrás de la apariencia de AdBlock.

Un gran número de usuarios se han visto afectados por extensiones maliciosas en el market de Google Chrome, según un reciente estudio.

Cada día vemos nuevas técnicas de ataque hacia el usuario, una de ellas es hacer pasar extensiones maliciosas como verdaderas, incluso llegando a colgarlas en markets oficiales. Y como no podría ser menos no se libra AdBlock,  el famoso complemento para diversos navegadores que bloquea la publicidad de los sitios web que visitamos.

El peligro de estas aplicaciones es que se posicionan en lo más alto en el market mediante el uso de palabras claves, siendo suficiente para ganarse la confianza de los usuarios.

Esto ha quedado demostrado en un reciente estudio del investigador de seguridad Andrey Meshkov, que ha publicado una lista de cinco extensiones de AdBlock falsas. Estas  contenían código malicioso que permitían el control total del navegador, y acceder a toda la información disponible.

Adblock falsos

Este investigador informó a Google de sus hallazgos y se han eliminado todas las extensiones referentes a bloqueadores de anuncios que tenían presencia de código malicioso. La lista de complementos era la siguiente:

  • AdRemover para Google Chrome ™ (10 millones + usuarios)
  • uBlock Plus (8 millones + usuarios)
  • [Fake] Adblock Pro (2 millones + usuarios)
  • HD para YouTube ™ (400,000+ usuarios)
  • Webutation (más de 30,000 usuarios)
Debemos tener en cuenta que el número de instalaciones totales asciende a unos 20 millones de instalaciones, cuando por ejemplo añadimos ‘AdRemover’ a nuestro navegador, estamos instalando el código malicioso que se encuentra escondido dentro de una versión modificada de ‘jQuery’, la conocida biblioteca JavaScript. AdRemover’ recibe comandos de un servidor remoto, que se ejecutan en segundo plano y obtienen el acceso al navegador por parte de los atacantes.
Como norma general se recomienda instalar extensiones de la que sepamos su procedencia y sean oficiales. En la sección de Más Información podéis ver noticias de este blog relacionadas con la temática de las aplicaciones maliciosas en markets oficiales.
Más información:
 

Denegación remota de servicio en Microsoft Internet Explorer 11

John Page, conocido bajo el nick ‘hyp3rlinx’, ha descubierto un error en el procesamiento de páginas web por parte de Internet Explorer 11 para Windows 10 que permite forzar el cierre del navegador

Internet Explorer todavía no está muerto. Microsoft Edge es el sucesor, y de hecho es el navegador predeterminado ya en Windows 10. Pero tal y como reza Microsoft en su página oficial, si todavía usas ActiveX (simplificando, esa tecnología muerta usada para ampliar la funcionalidad de Internet Explorer) porque las aplicaciones web en tu empresa lo usan, debes usar Internet Explorer, ya que Edge ya no soporta ActiveX.

Y como sigue vivo, los exploiters siguen dedicando esfuerzos a buscarle las cosquillas al viejo navegador. En este caso, ha sido hyp3rlinx quien se las ha encontrado, creando una página web especialmente diseñada que fuerza al proceso de Internet Explorer a realizar una acción inválida y provoca que el sistema operativo fuerce su cierre. Específicamente, el fallo se produce cuando Internet Explorer se encuentra con una etiqueta HTML ‘a’ con el atributo ‘href’ apuntando a un valor como ‘.exe’. Básicamente, que contenga únicamente una de ciertas extensiones de archivos precedida con un punto, siendo estas extensiones al menos ‘exe’, ‘com’, ‘pif’, ‘bat’ y ‘scr’.

Tal y como el autor reporta la vulnerabilidad, especificando una versión muy concreta (Microsoft Internet Explorer 11.371.16299.0 para Windows 10) sin mencionar rangos, es posible que sea un fallo para esa versión específica. Desde Hispasec hemos podido comprobar que no afecta a la versión de Internet Explorer que viene por defecto con una de las primeras versiones de Windows 10. El impacto de esta vulnerabilidad es fácil de entender: cualquier usuario que visite una página web en la que el atacante pueda insertar un enlace puede terminar con el navegador cerrado.

A la fecha de escritura de este artículo, esta vulnerabilidad no tiene identificador CVE ni ha sido reconocida por Microsoft.

Más información:

 
Microsoft (Win 10) InternetExplorer v11.371.16299.0 – Denial Of Service
http://hyp3rlinx.altervista.org/advisories/MICROSOFT-INTERNET-EXPLORER-(Win-10)-DENIAL-OF-SERVICE.txtGuía empresarial acerca del uso de Microsoft Edge e Internet Explorer 11
https://docs.microsoft.com/es-es/microsoft-edge/deploy/enterprise-guidance-using-microsoft-edge-and-ie11

Un grupo de hackers crean una “llave maestra” que abre millones de habitaciones de hotel

A partir de hoy, piénselo dos veces antes de dejar pertenencias valiosas en su habitación de hotel. Esta puede ser desbloqueada por un extraño.

Una vulnerabilidad crítica en un sistema de bloqueo electrónico ampliamente utilizado puede aprovecharse para desbloquear cada habitación cerrada en una instalación, dejando millones de habitaciones de hoteles del mundo vulnerables a cualquier delincuente conocedor de la técnica.

Este sistema de cierre está desplegado en más de 42.000 instalaciones en 166 países diferentes, lo que equivale a millones de puertas inseguras.

Los investigadores de F-Secure Tomi Tuominen y Timo Hirvonen lograron construir una llave maestra que podría usarse para acceder a cualquier habitación de hotel que utilice la tecnología Vision de VingCard.

Como se crea la llave maestra

Lo primero que se necesita es una tarjeta electrónica. Cualquier tarjeta electrónica existente, vieja o expirada puede servir.

Para obtener la clave RFID, el atacante podría leer los datos acercándose a un huésped o empleado del hotel que lleve la tarjeta encima. O simplemente reservar una habitación en el hotel y utilizar su propia tarjeta como fuente.

Luego, y con la ayuda de un programador portátil (los cuáles venden en línea por unos cientos de euros), crearía la llave maestra.

USB-stick-of-death, o dejar K.O. a Windows insertando una memoria USB

Un fallo en el manejador del sistema de ficheros NTFS puede ser aprovechado por un atacante para provocar la famosa “pantalla azul de la muerte” en sistemas de escritorio Windows, ya sea a través del acceso físico al sistema o consiguiendo la inserción usando ingeniería social.

Imagen tomada de https://potasiyam.deviantart.com/art/Blue-screen-of-sadness-258539681

El investigador Marius Tivadar, de Bitdefender, ha publicado una prueba de concepto de una técnica que provoca la aparición de la “pantalla azul de la muerte” (en resumidas cuentas, Denegación de Servicio) en sistemas de escritorio Windows.

Tivadar aprovecha un fallo al cargar sistemas de ficheros NTFS. Mediante el cambio de nombre de directorio raíz y la variable ‘INDEX_ALLOCATION’ en varias localizaciones de una imagen NTFS provoca la creación de una estructura FCB (‘File Control Block‘) que contiene un puntero nulo. Éste, al ser accedido por la función ‘NtfsFindExistingLcb()’, produce una excepción.

El fallo ha sido probado en sistemas Windows 7 Enterprise y 10 en sus versiones Enterprise y Pro, y puede ser explotado por cualquier atacante con acceso físico a la máquina sin importar el nivel de cuenta del usuario ejecutando el sistema operativo.

Además, al estar activada la función Auto-play por defecto, el sistema es afectado automáticamente al insertar el lápiz de memoria. En caso de estar desactivado Auto-play, el sistema quedará bloqueado en el primer acceso a la imagen NTFS modificada, por ejemplo al analizar la memoria con Windows Defender.

La técnica funciona también cuando el sistema se encuentra en modo Bloqueo, por lo que un atacante puede aprovechar un momento de despiste para insertar el lápiz de memoria sin ser visto.

Tivadar expresa su preocupación por este ultimo comportamiento en la documentación de la prueba de concepto:

Creo firmemente que este comportamiento debería cambiarse, dado que ningún lápiz USB o volumen debe montarse cuando el sistema está bloqueado. (…) Pienso en esto como código que se ejecuta sin el consentimiento del usuario. Si este tipo de ataque fuera explotable, y un atacante pudiera cargar malware incluso si un sistema está bloqueado, se podrían abrir miles de múltiples escenarios.

Cabe decir que esta vulnerabilidad fue descubierta en julio del 2017, pero los intentos del investigador para realizar una revelación responsable han sido infructuosos, ya que desde Microsoft han argumentado que el requisito de acceso físico o ingeniería social hace que la vulnerabilidad no sea considerada para lanzar un parche de seguridad. Sin embargo, el descubridor expresa sus dudas, ya que una imagen manipulada, descargada por un malware, podría disparar el fallo.

La prueba de concepto se ha publicado en Github junto con su documentación y varios vídeos demostrativos en la cuenta de Google Fotos de Tivadar.

Más información:
 
PoC for a NTFS crash that I discovered, in various Windows versions: