Fallo de seguridad CRÍTICO sin parchear en dispositivos de almacenamiento LG

Aviso importante: Si ha instalado un dispositivo de almacenamiento en red LG, debe desconectarlo inmediatamente.

Un investigador de seguridad de la empresa VPN Mentor ha descubierto una vulnerabilidad de ejecución de código remoto en varios modelos de dispositivos LG NAS. Este fallo podría permitir a un atacante comprometer los dispositivos vulnerables y robar datos almacenados en ellos.

Los dispositivos NAS son unidades de almacenamiento de archivos conectadas a una red que permite a los usuarios almacenar y compartir datos con varios equipos.

El fallo en cuestión, reside en la validación incorrecta del parámetro “contraseña” de la página de inicio de sesión para la administración remota del dispositivo. Explotando este campo, los atacantes pueden pasar comandos arbitrarios del sistema.

El modo de actuar más simple para la explotación del fallo es inyectando una shell simple con la que poder ejecutar los comandos con mayor comodidad.

Con el uso de la shell, los atacantes pueden incluso descargar la base de datos completa del dispositivo NAS, incluidos los correos electrónicos, los nombres de usuario y las contraseñas hasheadas en MD5.

Dado que el cifrado MD5 es muy débil y se puede romper con facilidad, un atacante remoto podría obtener acceso autorizado y robar datos sensibles almacenados en los dispositivos vulnerables.

Otra manera de actuar sería agregar un nuevo usuario al dispositivo mediante los comandos ejecutados en la shell, e iniciar sesión con esas credenciales.

Este último modo de actuar lo vemos en el siguiente vídeo:

Dado que LG aún no ha lanzado una actualización que solucione el problema, se recomienda a los usuarios que posean alguno de estos dispositivos, que lo desconecte hasta que el fallo sea parcheado.

Para los usuarios que no quieran prescindir del uso de su dispositivo NAS, se recomienda asegurarse de que su dispositivo no es accesible desde Internet, que estén protegidos por un firewall que solo permita el acceso a ellos por un grupo confiable de IPs y que observen periódicamente cualquier actividad sospechosa en la verificación de usuarios y contraseñas.

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

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 seguridadDarktrace, 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.

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ónJavaScript. 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 losidentificadores 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:

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.
Información revelada durante la carga de objetos OLE embebidos en un RTF previsualizado por Microsoft Outlook. Obtenida de: https://insights.sei.cmu.edu/cert/2018/04/automatically-stealing-password-hashes-with-microsoft-outlook-and-ole.html

Una vez abierta la puerta a conexiones arbitrarias a servidores SMB, nos queda estudiar qué información adicional podemos obtener y cómo la podemos explotar. En este caso, Dormann aprovecha una vulnerabilidad en los clientes SMB para provocar una denegación de servicio en el sistema del usuario. 

Explotación de vulnerabilidad en el cliente SMB de Microsoft a travér de Outlook. Obtenida de: https://insights.sei.cmu.edu/cert/2018/04/automatically-stealing-password-hashes-with-microsoft-outlook-and-ole.html

También, usando la herramienta Responder pudo interceptar conexiones del protocolo NTMLv2, que incluye el hash de la contraseña de usuario de Windows. Si esta contraseña es débil, descifrarla es cuestión de segundos.

Información obtenida a través de la petición SMB. Obtenida de: https://insights.sei.cmu.edu/cert/2018/04/automatically-stealing-password-hashes-with-microsoft-outlook-and-ole.html

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

Salto de restricciones en el bloqueo de pantalla de Signal

Signal ha corregido urgentemente una vulnerabilidad que permitiría saltarse el bloqueo de pantalla establecido para la aplicación, tanto al utilizar TouchID como al definir una contraseña de bloqueo en dispositivos Apple.

Signal es una popular aplicación de mensajería de código libre enfocada, principalmente, a la privacidad y la seguridad, cifrando las comunicaciones de extremo a extremo.

 

La vulnerabilidad (CVE-2018-9840), reportada por el joven investigador Leonardo Porpora, permitiría saltar de manera sencilla el bloqueo de pantalla activo, utilizando únicamente combinaciones de ciertos eventos y habilitando el acceso a los mensajes sin tener que introducir contraseña o utilizar el lector de huellas.

 

Como se puede comprobar en los vídeos publicados, se podía saltar el bloqueo por TouchID, simplemente utilizando la siguiente combinación de acciones, una vez abierto Signal, en su versión 2.23:

 

  • Pulsar Cancelar
  • Pulsar el botón Home
  • Volver a Signal
Mientras que en la versión 2.23.1.1, un parche parcial de la anterior, se reproducía el mismo error mediante:
  • Pulsar Cancelar
  • Pulsar el botón Home
  • Pulsar dos veces botón Home
  • Cerrar Signal
  • Abrir Signal
  • Pulsar Cancelar
  • Pulsar el botón Home

 

El investigador, tras analizar el código fuente pudo comprobar que, técnicamente, la vulnerabilidad residía en una incorrecta gestión de los eventos de sistema, mediante las funciones appEnteredBackgroundDate, appEnteredForegroundDate, lastUnlockSuccessDate, y alertar a los desarrolladores para una pronta resolución.

 

Para corregir la vulnerabilidad sólo hay que actualizar o instalar la versión 2.23.2 de Signal, ya disponible.

Más información:
 
Signal Bypass Screen locker:

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:
 

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

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.

Una muestra. Tenemos la función “strcpy“, el MS08-067 (por la popularidad) de los desbordamientos de búfer. Toda una campeona desde los 90 (quizás más). Observemos su interfaz:

char *strcpy( char *dest, const char *src );

Básicamente nos está diciendo, “venga, dime de donde tengo que leer (src) y donde lo tengo que escribir (dest); y además te devolveré misma dirección de memoria de destino que tú mismo me has pasado” Eficaz, ¿eh?. Naturalmente, C (y su hermano mayor, C++), no poseen gestión automática de la memoria dinámica ni realiza una gestión de chequeo de límites en los búfer que trata. Esto no viene de serie.

Cuando se usaba esta función los programadores no se quebraban mucho la cabeza. ‘strcpy’, para de copiar cuando encuentra un carácter nulo. El problema empieza cuando no lo encuentra. Seguirá copiando y copiando hasta que lea un carácter nulo de ‘src’. Y por supuesto, seguirá escribiendo en ‘dest’…aunque el límite del búfer designado haya sido rebasado varias veces, de ahí la denominación de desbordamiento.

Para enmendar el fallo, ‘strcpy’ evolucionó para “controlar” el tamaño del búfer. Ese controlar entrecomillado denota ironía. Cómo ‘strcpy’ no tomaba en cuenta el tamaño de búfer, sino que se limitaba a buscar un carácter nulo, había que buscar una solución y está, en aquellos tiempos, fue un…ejem…parche…mmm…considerable. Incluso el propio manual de GNU libcdestaca:

This function was designed for now-rarely-used arrays consisting of non-null bytes followed by zero or more null bytes. It needs to set all size bytes of the destination, even when size is much greater than the length of from. As noted below, this function is generally a poor choice for processing text.

Dentro interfaz de “strncpy”:

char *strncpy( char *dest, const char *src, size_t count );

Ahora tenemos un tercer parámetro para que el programador designe el tamaño de búfer requerido, es decir, la pelota en el otro campo. El perfecto, “Ah, yo qué sé, tú me dijiste qué…”. ¿Servía esto de algo? Pues no de mucho. Básicamente porque cuando se calculaba el parámetro “count”, su expresión no era precisamente un simple número natural, sino que se abusó hasta límites matemáticamente inconcebibles para definir el tamaño.

Además, la función no solo se limitaba a copiar los ‘n’ caracteres designados, lo hace pero no deja sitio para el carácter nulo de terminación de línea ‘\0’. Por lo que cuando la cadena era vuelta a tratar esta no tenía virtualmente fin, ya que no disponía de carácter terminador que la limitará.

No solo eso, también da pie a horrores que parecen el producto de la muerte por deadline, como equivocar el orden de los parámetros y poner el tamaño entre los dos búfer de fuente y destino…y no es precisamente una muestra de tiempos pasados, el CVE es de 2018.

Una última muestra de hasta donde llegan los problemas con el uso de funciones inseguras: un desbordamiento de búfer al corregir con ‘strncat’ un desbordamiento de búfer causado por usar ‘strcat’. Esta fenomenal carambola está mejor explicada aquí.

root@bokchoy:~/tes/apache_1.3.33/src/support# diff -uN  htpasswd.orig.c htpasswd.c
— htpasswd.orig.c     2004-10-28 18:20:13.000000000 -0400
+++ htpasswd.c  2004-10-28 18:17:25.000000000 -0400
@@ -202,9 +202,9 @@
ap_cpystrn(record, “resultant record too long”, (rlen – 1));
return ERR_OVERFLOW;
}
–    strcpy(record, user);
+    strncpy(record, user,MAX_STRING_LEN – 1);
strcat(record, “:”);
–    strcat(record, cpw);
+    strncat(record, cpw,MAX_STRING_LEN – 1);
return 0;
}

(fuente: https://blogs.msdn.microsoft.com/michael_howard/2004/10/29/buffer-overflow-in-apache-1-3-xx-fixed-on-bugtraq-the-evils-of-strncpy-and-strncat/)

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.