Una investigación revela infección de terminales iPhone a través de MDM

Interesante trabajo por parte del equipo de seguridad Talos de Cisco, en la que revelan como hasta un total de 13 teléfonos con sistema operativo iOS que habrían sido infectados.

Los detalles técnicos, de obligada y agradable lectura, están en el artículo original publicado en el blog de Cisco Talos. Sintetizando: una investigación de este grupo ha dado con más de una docena de terminales de la marca Apple que podrían haber sido infectados, no con un malware diseñado para esta plataforma sino con la funcionalidad de gestión del dispositivo.

Esquema de infección (Fuente: https://blog.talosintelligence.com/2018/07/Mobile-Malware-Campaign-uses-Malicious-MDM.html)

La gestión de dispositivos o Mobile Device Management, está pensada para administrar grandes parques de móviles en entornos de empresa. Pensemos en una organización de tamaño mediano y en la persona que debe instalar las aplicaciones de uso en la empresa, certificados y reglas de restricción sobre el uso de la plataforma. El MDM permite librarle de ese tedioso trabajo. Además también posee interesantes características prácticas como el borrado remoto en caso de pérdida y otras, más orwellianas, como la geolocalización. Apple llama a esto “dispositivo supervisado”.

Naturalmente, no funciona por arte de magia, es necesario o bien tener acceso físico al dispositivo o pidiéndole amablemente a la usuaria o al usuario que proceda a aceptar su sumisión mediante ingeniería social (a veces ni tan siquiera hace falta engañarle un poco, basta pedir que lo acepte sin mas). Una vez se agrega el certificado apropiado (funciona como una especie de autoridad certificadora) es posible instalar y administrar el dispositivo.

Pero eso es solo el principio, hay más. El esquema explota una técnica denominada BOptions sideloading. Consiste en la carga y ejecución de funciones desde una biblioteca dinámica (dylib). Esta biblioteca es incluida con el paquete ipa (el equivalente en iOS a un apk de Android) de una aplicación legítima, lo que deriva en su troyanización. De hecho, los investigadores encontraron hasta tres aplicaciones “retocadas”, algunas muy conocidas por todos: WhatsApp, Telegram y una tercera popular, al parecer, en la India, país en el que se circunscribe el ataque.

Respecto del ataque, llama la atención que solamente haya 13 dispositivos afectados. Según Talos, este ataque llevaba activo 3 años y aunque en su manufactura se dejaran pistas falsas para desviar la atribución, todo parece indicar que se trata de una operación montada desde India. Además, con una intención muy clara de obtener las comunicaciones y localización de las víctimas.

El esquema en si no es original. MDM ya ha dado algún que otro susto, recordemos a SidestepperCuanto más se abre un dispositivo o sistema más se expone a que esa misma funcionalidad retorne como una fresca y sonora bofetada en la cara. Eso si, con la connivencia de la ignorancia de quienes usan el dispositivo.

Más información:

Advance Mobile Malware Campaign in India uses malicious MDM

ZombieBoy, nuevo malware de minado de criptomonedas

ZombieBoy, como lo ha bautizado el analista de seguridad James Quinn, es una nueva familia de malware de minado de criptomonedas que utiliza la capacidad de procesamiento de tu ordenador para obtener Moneros.

ZombieBoy tiene características de gusano, valiéndose de WinEggDrop para buscar nuevos hosts y propagarse. Para infectar a la víctima el virus utiliza la herramienta que le da nombre: “ZombieBoyTools”. Esta herramienta aprovecha dos conocidos exploits, EternalBlue y DoublePulsar para instalar la DLL maliciosa en la máquina de la víctima.

Captura de la herramienta ZombieBoyTools. Fuente: www.alienvault.com

Una vez instalada la DLL en la máquina, se descarga y ejecuta el binario “123.exe” desde ca[.]posthash[.]org:443. Este se encargará de descargar el resto de componentes del malware:

“64.exe”, además de estar encriptado con el packet “Themida” implementa algunas técnicas de evasión bastante sofisticadas. Se encarga de la propagación del virus y de ejecutar el miner (XMRIG), para ello utiliza “WinEggDrop” un escaner TCP que buscará víctimas potenciales contra las que ejecutar el exploit DoublePulsar. Adicionalmente “64.exe” utiliza el software XMRIG para minar Monero y enviarlo a las direcciones:

  • 42MiUXx8i49AskDATdAfkUGuBqjCL7oU1g7TsU3XCJg9Maac1mEEdQ2X9vAKqu1pvkFQUuZn2HEzaa5UaUkMMfJHU5N8UCw
  • 49vZGV8x3bed3TiAZmNG9zHFXytGz45tJZ3g84rpYtw78J2UQQaCiH6SkozGKHyTV2Lkd7GtsMjurZkk8B9wKJ2uCAKdMLQ

El otro componente descargado tiene el nombre de “74.exe”. Se encarga de descargar y ejecutar la DLL “NetSyst96.dll”, heredada del RAT “Gh0stRat”, permitirá al administrador del malware realizar algunas acciones sobre la máquina infectada de forma remota, como capturar la pantalla, grabar sonidos o alterar el portapapeles de la víctima.

“84.exe” es otro de los módulos droppeados por “123.exe”. Al igual que “74.exe” es un RAT utilizado para extraer información adicional sobre la víctima: SO utilizado, velocidad de la CPU o antivirus instalados. Además añade una entrada al registro que sirve para comprobar si el malware se está ejecutando por primera vez.

Flujo de actividad. Fuente: www.alienvault.com

Para comprobar si está infectado por ZombieBoy puede buscar si alguno de los binarios implicados se encuentra entre sus procesos:

  • 123.exe
  • 64.exe
  • 74.exe
  • 84.exe
  • CPUinfo.exe
  • N.exe
  • S.exe
  • Svchost.exe (OJO, siempre que no provenga de C:\Windows\System32)

Si es así debería detener estos procesos y borrar los ficheros implicados, así como las entradas al registro introducidas por el virus.

Entradas de registro maliciosas:

  • SYSTEM/CurrentControlSet/Services/Dazsks Fsdgsdf
  • SYSTEM/CURRENTCONTROLSET/SERVICES/ANqiki cmsuuc
Ficheros descargados por el malware:
  • C:\%WindowsDirectory%\sys.exe
  • C:\windows\%system%\boy.exe
  • C:\windows\IIS\cpuinfo.exe
  • C:\Program Files(x86)\svchost.exe
  • C:\Program Files\AppPatch\mysqld.dll
  • C:\Program Files(x86)\StormII\mssta.exe
  • C:\Program Files(x86)\StormII\*
  • C:\Archivos de programa (x86)\svchost.exe
  • C:\Archivos de programa\AppPatch\mysqld.dll
  • C:\Archivos de programa (x86)\StormII\mssta.exe
  • C:\Archivos de programa (x86)\StormII\*
Más información:
 
ZombieBoy:

Más de 18.000 routers Huawei comprometidos en un día por una nueva botnet

Investigadores de NewSky Security descubren una botnet que ha infectado a más de 18.000 routers Huawei en tan solo un día.

 

El autor del malware, que se hace llamar “Anarchy” es el responsable de otras botnets variantes de Mirai, como Sora o Owari. “Anarchy” ha conseguido infectar más de 18.000 routers Huawei HG532 en tan solo un día y utilizando un solo exploit. Su motivación es, probablemente, la ejecución de ataques DDoS bajo demanda.

Lo preocupante de esto es que lo ha hecho utilizando una vulnerabilidad ampliamente conocida y parcheada hace casi un año: CVE-2017-17215 utilizada además en otras botnets como Mirai o Satori.

La vulnerabilidad permitiría a un atacante remoto autenticado ejecutar código arbitrarioenviando paquetes especialmente manipulados al puerto 37215.

Pese a que los fabricantes publican los parches, es responsabilidad de los usuarios su aplicación, lo que refleja todavía una gran falta de concienciación en materia de seguridad.

Exploit. Fuente: @ankit_anubhav

Como se observa en la imagen, el aumento de escaneos del puerto 37215, el utilizado para explotar la vulnerabilidad, es notable.

Según ha comunicado el propio autor del malware a algunos medios, “Anarchy” planea otro ataque que apunta a routers Realtek aprovechando la vulnerabilidad CVE-2014-8361, que permitiría la ejecución remota de código realizando peticiones ‘NewInternalClient‘ especialmente manipuladas.

Aunque todavía no se tiene constancia de ninguna muestra se ha observado un aumento de escaneos en el puerto 52869, utilizado para explotar la vulnerabilidad de estos routers.

Algunos IoCs proporcionados por NewSky:

  • Hash-MD5 c3cf80d13a04996b68d7d20eaf1baea8
  • Hash-SHA256 61440574aafaf3c4043e763dd4ce4c628c6c92fb7d7a2603076b3f60f2813f1b
  • IPv4 104.244.72.82
  • URL http://104.244.72.82
  • URL http://104.244.72.82/sister
  • URL http://104.244.72.82/k
  • URL http://104.244.72.82/gpon
Más información:
 
Router Crapfest: Malware Author Builds 18,000-Strong Botnet in a Day

Chrome dice que mi sitio no es seguro ¿Qué hago?

Hoy es el día elegido (no os quejéis, podrían haber escogido un viernes) para que el navegador Google Chrome comience a marcar los sitios que no posean un certificado como “No seguro”. De momento es un mensaje adosado al nombre del dominio visitado, en gris. No salta a la vista, es algo discreto y con las prisas con las que vivimos hoy día no parece que a muchos les vaya a molestar…hasta que en octubre de este mismo año, ese mismo mensaje, se cabree y se torne de color rojo chillón…Ya lo contaba nuestro compañero Carlos ‘Maestro‘ Ledesma en otra UAD.

Casi es seguro, el resto de navegadores menos uno seguirá la estela marcada por Chrome. Con el tiempo añadirán el mismo mensaje o similar. Así que toca extender un certificado y configurar adecuadamente el cifrado del servidor para que ese mensaje desaparezca cuando nuestros visitantes entren en nuestros dominios. Pero no queremos que esa sea la motivación principal. Existe otra (y muchas más) importantes por las que ya deberías estar ofreciendo cifrado incondicional en todos y cada uno de tus sitios. Además vamos a derribar unos cuantos mitos acerca de los costes y complejidades inherentes a su despliegue.

1.- Respeta la privacidad de tus clientes o visitantes

Las conexiones cifradas no son un adorno ni están ahí para que “salga el candadito”. Están para que otros no capturen y lean el tráfico que se produce entre cliente y servidor. Es posible que creas que ese tráfico “no es importante”, pero en muchos contextos sí que lo es e importa mucho. Incluso si tu sitio es presencial y no existen formularios o campos de búsqueda, la propia traza de visitas de URLs del sitio ya permite crearse un perfil de la persona afectada por no cifrar las comunicaciones.

2.- Da autenticidad a tu dominio

Sin un certificado debidamente extendido un visitante no sabría diferenciarlo de un sitio falsificado. Visitar un dominio no implica que sea el sitio correcto, tanto con un ataque de envenenamiento de la caché DNS como con un ataque sobre rutas BGP nos permite falsificar un sitio si este no posee un certificado adecuado.

3.- Es gratis

Muchas personas y organizaciones piensan que extender un certificado es caro y un gasto innecesario (o simplemente, no dan importancia a los motivos del punto 1). No solo no es caro, es gratis. Iniciativas como Let’s Encrypts nos permiten poseer un certificado libre de costes directos. No hay excusas si habías mirado la inversión en certificados como un gasto inútil. Es gratis. 0 euros. Nada.

4.- Es sencillo

No tengo/No voy a dedicar personal/tiempo para una tarea así. A veces no es cuestión de dineros sino de tiempo o no tener el personal adecuado para extender e instalar un certificado. En realidad es una tarea sencilla, no es compleja. Elige el certificado adecuado (recuerda, Let’s Encrypts…es gratis!), lo obtienes, sigues los pasos indicados por el emisor (todos tienen una guía, por ejemplo), reinicias el servidor y a funcionar.

5.- Mejora tu imagen

A ver. ¿Cómo va a ser lo mismo una conexión plana, ahí, sin candado ni verde y con un mensaje de “No seguro” que una conexión cifrada con un buen candadazo TLS 1.3? Eso dice mucho. Da fuerza, vigor y sienta principios: “Esto es seguro, bueno (toc, toc) y de confianza”. Aunque no lo hagas por la privacidad, te salga gratis y te lo instale un amigo con conocimientos informáticos al que invitarás a una paella a cambio, al menos piensa que va a reforzar tu imagen.

Desbloquea un logro más:

6.- HSTS o mata tus conexiones inseguras

No es suficiente con el certificado y las conexiones bien configuradas, que eso es otro menester. Mientras no configuremos nuestros servidores para que les diga al navegador de nuestros clientes que no usen conexiones inseguras cuando nos visiten, todo esto podría no servir de mucho.

Aunque dispongamos de lo anterior, los ataques de hombre en el medio suelen usar herramientas del tipo ssltrip, donde se puentea la conexión segura hacia una insegura. Sin embargo, si el navegador visitó antes de ese ataque nuestro sitio y recibió la cabecera HSTS entonces optará por no establecer una conexión plana (no cifrada) y cortará las comunicaciones que se dirijan a nuestro dominio. ¿Sencillo verdad?.

HSTS (https strict transport security) no es para nada difícil de implementar. Hay miles de guías para ello. Una sola cabecera http puede proteger a tus clientes y visitantes de ataques de hombre en el medio de forma bastante sencilla y eficaz.

Corregidos dos fallos graves en OpenWhisk

PureSec ha hallado dos fallos, ya corregidos, en OpenWhisk, la arquitectura FaaS de la fundación Apache, con los que se podría ejecutar código arbitrario sustituyendo la funciones a ejecutar por código malicioso.

FaaS, es un tipo de arquitectura que conlleva todo lo que representa la familia de los sufijos aaS (as a Service): Usar el ordenador de otro. Solo que esta vez nos abstraemos aun más y no solo no tenemos que vérnosla con la creación y configuración de servidores, ni eso. FaaS nos permite “ejecutar una función en la nube” y nos cobran por los recursos que se han tenido que consumir para atender la respuesta. Por supuesto, es serverless, ese vocablo que significa que sí que hay servidores pero no los ves, ni los tocas, ni los hueles.

OpenWhisk es una implementación en particular de esa arquitectura, creada por la fundación Apache y usada sobre todo en IBM Cloud Functions, la nube de IBM, para dar servicios del tipo serverless y FaaS. El concepto puede parecer chocante la primera vez que lo lees. Programas tu función, al ejecutarla se sube a la nube, esta levanta un contenedor Docker y la ejecuta devolviendo la respuesta. Esto libera al cliente de tener que poseer y administrar recursos en local. Además, se pueden programar eventos que disparen la ejecución de estas funciones.

PureSec ha encontrado dos fallos en OpenWhisk que podrían permitir a un atacante sustituir el código de la función a ejecutar, lo que abre la puerta a ataques que podrían ser aprovechados para minar o causar denegación de servicio.

El fallo se encuentra siempre y cuando la función legítima a ejecutar permita interactuar con el interfaz REST del contenedor. En ese caso es posible enviar una nueva función a ejecutar en el terminador /init que sustituirá a la función actual en curso. Todos los contenedores posteriores que se levanten tendrán la nueva función maliciosa como cuerpo a ejecutar.

Los fallos poseen los CVE asignados: CVE-2018-11756 y CVE-2018-11757. Han sido corregidos y una nueva versión de OpenWhisk se encuentra disponible para su descarga.

Más información:

Apache OpenWhisk ‘Action’ mutability weakness 

Cómo un Open Redirect puede usarse para robar credenciales en la app en Electron de Hangouts

Hangouts, la app de mensajería de Google, ha sido comprometida en su versión de escritorio por una vulnerabilidad de tipo Open Redirect, sumado a un error en la forma en que se abren los enlaces

 

 

Electron se ha convertido estos últimos años en una alternativa económica y sencilla de construir apps multiplataforma para escritorio. En vez de invertir recursos y dinero en crear aplicaciones nativas, es posible crear aplicaciones web que se ejecutarán en su propio navegador, sin la barra de direcciones. Esta propiedad de Electron, impide al usuario conocer qué sitio web se está visualizando, lo que puede aprovecharse para redirigir a un sitio de phishing sin que se dé cuenta.

La app de Hangouts para escritorio, que hace uso de Electron, soluciona en parte este problema abriendo con el navegador del sistema los enlaces externos a la aplicación web que ejecuta (https://chat.google.com). El analista Michal Bentkowski investigó este hecho en su blog, descubriendo que la aplicación sigue los enlaces de redirección, y que podría emplearse para redirigir a un phishing. Haciendo uso de un Open Redirect conocido en https://accounts.google.com/ServiceLogin?continue= (que también está presente en chat.google.com), es posible redirigir al usuario a un sitio arbitrario, como una página falsa de login de Google, tal y como puede comprobarse en esta url de demostración:

https://chat.google.com/accounts/ServiceLogin?continue=https://appengine.google.com/_ah/conflogin?continue=http://bentkowski.info/&service=ah

Al tratarse de una vulnerabilidad en una aplicación de mensajería, su propagación es tan sencilla como enviar este enlace a un contacto, y esperar a que éste lo abra. Al cargarse la url en la propia ventana de Electron, el usuario no nota la diferencia con el login original, y ni siquiera puede volver atrás, al no disponer de botones de navegación.
Ya hemos visto otras vulnerabilidades relacionadas con el uso de Electron, como ejecución remota de código o la sufrida en Atom (también de tipo RCE). Debido a su popularidad, es probable que en los próximos años sigamos viendo casos similares, lo que evidencia la necesidad de adoptar medidas. Por ejemplo, en el caso de Hangouts, existen soluciones, como bloquear las redirecciones, o forzar el uso del navegador externo en todos los enlaces recibidos a través de un mensaje.
Más información:

Vulnerability in Hangouts Chat a.k.a. how Electron makes open redirect great again:

Google Open URL Redirection :
https://vagmour.eu/google-open-url-redirection/

Ejecución remota de código en aplicaciones Electron:
https://unaaldia.hispasec.com/2018/01/ejecucion-remota-de-codigo-en.html

Ejecución remota de código en el editor Atom:
https://unaaldia.hispasec.com/2017/11/ejecucion-remota-de-codigo-en-el-editor.html

Vulnerabilidad en Bluetooth permite realizar ataques “hombre en el medio”

El fallo de encuentra en el proceso de validación de claves públicas, y podría permitir la lectura e inyección de datos  por un tercero entre dos dispositivos conectados.

Los investigadores Eli Biham y Lior Neumann, parte del equipo del Centro de Investigación en Seguridad Hiroshi Fujuwara del Technion, en Israel, han descubierto una vulnerabilidad en la tecnología Bluetooth que podría permitir a un tercero descifrar e inyectar datos en la comunicación entre dos dispositivos emparejados.

El fallo, al que se ha asignado el identificador CVE-2018-5383, ocurre durante el intercambio de claves de curva elíptica Diffie-Hellman. Durante este proceso, los dispositivos que van a emparejarse deben intercambiar sus claves públicas y acordar los parámetros de curva elíptica que van a utilizar.

El problema aparece cuando en algunas implementaciones estos parámetros no son validados. Esto permitiría a un atacante en el rango de alcance inyectar una clave pública inválida para realizar un ataque “man-in-the-middle“, de forma que podría descifrar las comunicaciones entre los dos dispositivos e incluso inyectar mensajes con contenido malicioso en la comunicación sin ser detectado.
El Bluetooth SIG (Special Interest Group), órgano encargado de las especificaciones de la tecnología, ha reconocido el fallo, y han realizado un cambio en el estándar que fuerza a la validación cualquier clave pública recibida.
Sin embargo, queda que los distintos fabricantes hagan cambios en sus implementaciones para eliminar la vulnerabilidad. Estos recibieron notificaciones entre mediados de enero y mediados de marzo de este año, antes de que el descubrimiento se hiciera público. Entre los afectados se encuentran Google, Apple y Samsung, que ya han lanzado parches para sus dispositivos.

Como curiosidad, Microsoft no está afectado por esta vulnerabilidad, pero no porque se haya adelantado a los acontecimientos, sino porque implementa una versión antigua del estándar que no contiene esta vulnerabilidad pero que es aún más insegura.

Más información:
 

Breaking the Bluetooth Pairing: Fixed Coordinate Invalid Curve Attack

Bluetooth SIG Security Update
https://www.bluetooth.com/news/unknown/2018/07/bluetooth-sig-security-update

Lanzada versión 0.4.0 de Dirhunt

Dirhunt, una herramienta para encontrar directorios de un sitio web sin fuerza bruta, ha lanzado una nueva versión con soporte para el fichero Robots.txt, entre otros cambios

Esta herramienta de reciente creación (enero de este mismo año) se trata de un crawler especializado en la búsqueda y análisis de directorios de un sitio web. En vez de utilizar fuerza bruta, recorre el sitio web (tanto enlaces como carpetas de recursos) para encontrar directorios. En la mayoría de los casos, permite conocer la estructura del sitio web y sus  plugins, y en ciertas ocasiones zonas ocultas desprotegidas.

Pero cuando resulta más útil esta herramienta, es en los sitios con el modo “Index Of”habilitado. En estos casos, Dirhunt obtiene los ficheros listados más interesantes (como zips o ficheros csv olvidados) e incluso kits de malware en sitios comprometidos. Al finalizar la búsqueda, se reportan los ficheros con un resumen de su contenido. En caso de no estar el modo “Index Of” habilitado, también se muestra otra información útil, como directorios que devuelven un falso 404, o que tienen un fichero index en blanco para ocultar el contenido del directorio.

 Demostración de uso de Dirhunt
Demostración de uso de Dirhunt

En esta última versión que se ha lanzado, con identificador 0.4.0, utiliza además el fichero “robots.txt” (si existiese) para obtener posibles directorios, analizando su contenido y obteniendo a su vez nuevos directorios de los mismos.

Además, resuelve un fallo presente desde su primera versión en aquellos sitios web con un bucle de directorios. En dichos sitios, la herramienta entraba en bucle y nunca terminaba. Ahora se detectan los bucles y se para en cierto límite. También se han incluido nuevos parámetros para configurar la búsqueda, y se ha añadido soporte para Python 3.7.

Para instalar o actualizar Dirhunt puede emplearse el siguiente comando si está Pip instalado en la máquina: ‘sudo pip install -U dirhunt’. Se encuentra soportado Python 2.7 y Python 3.4-3.7, siendo la versión recomendada la última disponible de Python 3.


Más información:
 
Dirhunt en Github:
https://github.com/Nekmo/dirhunt

Vídeo Dirhunt demo 1:
https://asciinema.org/a/xPJXT0MhrvlZ8lJYJYkjxlice

Documentación de Dirhunt:
http://docs.nekmo.org/dirhunt/

Dirhunt en Pypi:
https://pypi.org/project/dirhunt/

Cambios en v0.4.0:

Múltiples vulnerabilidades en Samsung SmartThings Hub

El equipo de Cisco Talos ha descubierto múltiples vulnerabilidades que podrían permitir hacerse con el control total del Hub y actuar sobre interruptores, cerraduras, termostatos, cámaras y cualquier otro dispositivo conectado a éste.

 

SmartThings Hub es un dispositivo que sirve para gestionar y conectar entre sí diferentes sensores y dispositivos IoT para casas inteligentes. En la última actualización de su firmware, Samsung ha solucionado más de 20 vulnerabilidades que podrían comprometer el dispositivo y afectar a los dispositivos conectados:

Dos vulnerabilidades de denegación de servicio en ‘hubCore Port 39500’ y en el firmware de ‘ZigBee’ (CVE-2018-3918 y CVE-2018-3926) podrían permitir a un atacante remoto desconectar las cámaras o interrumpir el servicio ZigBee por medio de paquetes especialmente manipulados.

Desbordamientos de buffer y otros errores a la hora de gestionar la memoria en el componente ‘video-core’ de SmartThings Hub podrían permitir la ejecución de código arbitrario (CVE-2018-3863 a CVE-2018-3866, CVE-2018-3872, CVE-2018-3878, CVE-2018-3880, CVE-2018-3897, CVE-2018-3902 a CVE-2018-3906, CVE-2018-3912 a CVE-2018-3917, CVE-2018-3919, CVE-2018-3925).

Una falta de comprobación en el parámetro ‘camera-password’ de la configuración del componente ‘video-core’ podría permitir a un atacante remoto ejecutar comandos arbitrarios en el sistema (CVE-2018-3856).

Otra vulnerabilidad en el componente ‘video-core’ podría permitir la inyección de comandos SQL a través del módulo ‘credentials’, al no sanear correctamente el JSON enviado en las peticiones POST del usuario a ‘/credentials’ (CVE-2018-3879).

Múltiples vulnerabilidades a la hora de procesar peticiones HTTP segmentadas permitirían a un atacante manipular las peticiones HTTP e insertar datos maliciosos en el servidor HTTP del componente ‘video-core’ (CVE-2018-3907, CVE-2018-3908, CVE-2018-3909).

El componente ‘hubCore Port 39500’ presenta una vulnerabilidad de inyección de cabeceras HTTP que podría ser explotada y combinada con otras vulnerabilidades presentes en el dispositivo para ejecutar código arbitrario (CVE-2018-3911).

Por último, un error en el controlador de excepciones del componente ‘hubCore‘ permitiría a un atacante interceptar los volcados con información de debug que el componente envía al servicio de ‘backtrace.io’ para su posterior análisis (CVE-2018-3927).

Se recomienda actualizar actualizar inmediatamente el firmware a la última versión disponible.

 

Más información:

Vulnerability Spotlight: Multiple Vulnerabilities in Samsung SmartThings Hub
https://blog.talosintelligence.com/2018/07/samsung-smartthings-vulns.html

Vulnerabilidad de 2007 permite escalar privilegios en Solaris

Investigadores de SpiderLabs, el equipo élite de seguridad de Trustwave, han descubierto que una vulnerabilidad de Solaris parcheada hace 9 años no fue totalmente mitigada y todavía se puede escalar privilegios

Un usuario no privilegiado puede ejecutar código en un contexto privilegiado, permitiendo el control total del sistema operativo. Este es el resumen de la vulnerabilidad descubierta en 2007 y publicada en 2009 en la conferencia CanSecWest. El mismo año de su publicación se parcheó, pero investigadores de Trustwave han encontrado resquicios en el parche por donde meterse, y poder seguir explotando la vulnerabilidad. Esta “nueva” vulnerabilidad tiene asignado el identificador CVE-2018-2892.

Si bien la explotación de vulnerabilidades, o exploiting, es un campo que en los últimos años se ha complicado bastante, la explotación de esta vulnerabilidad en concreto no es complicada de entender. Especialmente porque no parece haber protecciones genéricas contra exploiting por parte del sistema operativo (o al menos en la entrada del blog de SpiderLabs no se mencionan). La vulnerabilidad se encuentra en un manejador de ioctl, esto es, una parte de un controlador (driver) que recibe peticiones de aplicaciones posiblemente no privilegiadas. Como en la mayoría de los sistemas operativos para PC, los controladores corren en contexto privilegiado. Lo que tenemos entonces es que recibimos una petición desde el lado no privilegiado, y la manejamos en el lado privilegiado. Si el manejo es robusto, no hay problema. Si el manejo es débil… Vulnerabilidad.

En la vulnerabilidad original (antes de parchear), el error es flagrante. En el manejador de ioctl se usan directamente dos argumentos que vienen del lado no privilegiado: uno que se usa para indicar dónde escribir en memoria privilegiada, y otro para indicar el tamaño a escribir. Esos dos argumentos son pasados a una función que se encarga de copiar memoria del lado no privilegiado al privilegiado, y junto con un tercer argumento que especifica el contenido a copiar, tenemos la forma de escribir lo que queramos (tercer argumento y segundo especificando el tamaño) donde queramos (primer argumento).

En la llamada a ‘copyin’, ‘uap->addr’ sería nuestro tercer argumento, y los otros dos, el primero y el segundo respectivamente

Se entiende que el tercer argumento (lo que se copia) aun siendo controlable por el usuario no permite explotación por sí solo si se copia donde se debe, pero si podemos controlar dónde se copia, podemos hacer que sobreescriba código crítico del lado privilegiado y nos permite ejecutar código arbitrario en ese contexto. El parche se antoja sencillo entonces: vale con controlar que el primer argumento no permita escribir fuera del tiesto, y que el segundo argumento no permita escribir más de la cuenta. Y en eso consistió el parche de 2009.

Por desgracia, la comprobación del segundo parámetro es incompleta. Por definición, el segundo parámetro es de tipo ‘int’, esto es, un valor numérico que puede ser positivo o negativo. Y la comprobación introducida por el parche de 2009 sólo comprueba que no sea mayor de un cierto número positivo, no comprobando si es negativo. ¿Qué problema plantea esto? Que el segundo argumento indica en qué dirección escribir, pero de forma relativa. Existe una dirección fija en memoria, y el segundo argumento indica a qué distancia de esta dirección fija escribimos. Como se controla que el valor positivo no exceda cierto límite, no es posible salirse del tiesto por arriba, pero como el valor negativo no se controla, pues te puedes salir del tiesto por arriba…

Cabe preguntarse por qué una vulnerabilidad tan obvia termina en un punto tan delicado del sistema. Una posible respuesta se encuentra en el código fuente, donde se ve que el tipo de petición que nos lleva al código vulnerable es un tipo de petición usada con propósitos de prueba. Y es que el código escrito con este propósito es usado por los mismos desarrolladores para hacer pruebas de forma rápida y no debe ser usado por el usuario final, con lo que se programa de forma rápida y sin tener la seguridad en mente.

Finalmente, indicamos que Oracle ha publicado un parche para solucionar este problema (esperemos que definitivamente). Un parche sacado apenas hace una semana, en el que se corrige esta vulnerabilidad para las últimas versiones de Solaris 10 y 11. Para su explotación es necesario que esté configurado el módulo Sun StorageTek Availability Suite, ya que el manejador ioctl pertenece a éste.

Carlos Ledesma
@Ravenons

Más información:
 
CVE-2018-2892 – Kernel Level Privilege Escalation in Oracle Solaris
https://www.trustwave.com/Resources/SpiderLabs-Blog/CVE-2018-2892—Kernel-Level-Privilege-Escalation-in-Oracle-Solaris/

Oracle Critical Patch Update Advisory – July 2018
http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.htmlInvestigadores de SpiderLabs, el equipo élite de seguridad de Trustwave, han descubierto que una vulnerabilidad de Solaris parcheada hace 9 años no fue totalmente mitigada y todavía se puede escalar privilegios

Un usuario no privilegiado puede ejecutar código en un contexto privilegiado, permitiendo el control total del sistema operativo. Este es el resumen de la vulnerabilidad descubierta en 2007 y publicada en 2009 en la conferencia CanSecWest. El mismo año de su publicación se parcheó, pero investigadores de Trustwave han encontrado resquicios en el parche por donde meterse, y poder seguir explotando la vulnerabilidad. Esta “nueva” vulnerabilidad tiene asignado el identificador CVE-2018-2892.

Si bien la explotación de vulnerabilidades, o exploiting, es un campo que en los últimos años se ha complicado bastante, la explotación de esta vulnerabilidad en concreto no es complicada de entender. Especialmente porque no parece haber protecciones genéricas contra exploiting por parte del sistema operativo (o al menos en la entrada del blog de SpiderLabs no se mencionan). La vulnerabilidad se encuentra en un manejador de ioctl, esto es, una parte de un controlador (driver) que recibe peticiones de aplicaciones posiblemente no privilegiadas. Como en la mayoría de los sistemas operativos para PC, los controladores corren en contexto privilegiado. Lo que tenemos entonces es que recibimos una petición desde el lado no privilegiado, y la manejamos en el lado privilegiado. Si el manejo es robusto, no hay problema. Si el manejo es débil… Vulnerabilidad.

En la vulnerabilidad original (antes de parchear), el error es flagrante. En el manejador de ioctl se usan directamente dos argumentos que vienen del lado no privilegiado: uno que se usa para indicar dónde escribir en memoria privilegiada, y otro para indicar el tamaño a escribir. Esos dos argumentos son pasados a una función que se encarga de copiar memoria del lado no privilegiado al privilegiado, y junto con un tercer argumento que especifica el contenido a copiar, tenemos la forma de escribir lo que queramos (tercer argumento y segundo especificando el tamaño) donde queramos (primer argumento).

En la llamada a ‘copyin’, ‘uap->addr’ sería nuestro tercer argumento, y los otros dos, el primero y el segundo respectivamente

Se entiende que el tercer argumento (lo que se copia) aun siendo controlable por el usuario no permite explotación por sí solo si se copia donde se debe, pero si podemos controlar dónde se copia, podemos hacer que sobreescriba código crítico del lado privilegiado y nos permite ejecutar código arbitrario en ese contexto. El parche se antoja sencillo entonces: vale con controlar que el primer argumento no permita escribir fuera del tiesto, y que el segundo argumento no permita escribir más de la cuenta. Y en eso consistió el parche de 2009.

Por desgracia, la comprobación del segundo parámetro es incompleta. Por definición, el segundo parámetro es de tipo ‘int’, esto es, un valor numérico que puede ser positivo o negativo. Y la comprobación introducida por el parche de 2009 sólo comprueba que no sea mayor de un cierto número positivo, no comprobando si es negativo. ¿Qué problema plantea esto? Que el segundo argumento indica en qué dirección escribir, pero de forma relativa. Existe una dirección fija en memoria, y el segundo argumento indica a qué distancia de esta dirección fija escribimos. Como se controla que el valor positivo no exceda cierto límite, no es posible salirse del tiesto por arriba, pero como el valor negativo no se controla, pues te puedes salir del tiesto por arriba…

Cabe preguntarse por qué una vulnerabilidad tan obvia termina en un punto tan delicado del sistema. Una posible respuesta se encuentra en el código fuente, donde se ve que el tipo de petición que nos lleva al código vulnerable es un tipo de petición usada con propósitos de prueba. Y es que el código escrito con este propósito es usado por los mismos desarrolladores para hacer pruebas de forma rápida y no debe ser usado por el usuario final, con lo que se programa de forma rápida y sin tener la seguridad en mente.

Finalmente, indicamos que Oracle ha publicado un parche para solucionar este problema (esperemos que definitivamente). Un parche sacado apenas hace una semana, en el que se corrige esta vulnerabilidad para las últimas versiones de Solaris 10 y 11. Para su explotación es necesario que esté configurado el módulo Sun StorageTek Availability Suite, ya que el manejador ioctl pertenece a éste.


Más información: