Noticias de Seguridad Agosto 2018

Actualizaciones para múltiples productos de Adobe

Adobe ha publicado cuatro boletines de seguridad en los que se hah corregido un total de once vulnerabilidades en sus productos Flash Player, Reader, Acrobat, Experience Manager, y Creative Cloud Desktop Application

A continuación se exponen los boletines publicados para cada producto.

Adobe Creative Cloud Desktop Application (APSB18-20): boletín que soluciona una vulnerabilidad relacionada con la carga insegura de librerías DLL que podría permitir la elevación de privilegios (CVE-2018-5003).

Adobe Flash Player (APSB18-25): solventa cinco errores de seguridad en el popular reproductor flash que podrían causar la revelación de información (CVE-2018-12824, CVE-2018-12826, CVE-2018-12827), eludir restricciones de seguridad (CVE-2018-12825), y elevar privilegios (CVE-2018-12828).

Adobe Experience Manager (APSB18-26): tres problemas de seguridad son solucionados en este boletín que podrían permitir la revelación de información sensible a través de ataques Cross-site Scripting y Cross-site Scripting reflejado (CVE-2018-5005 y CVE-2018-12806) y modificar información sin autorización a causa de un error relacionado con el incorrecto filtrado de entradas proporcionadas por el usuarios (CVE-2018-12807).

Adobe Reader y Acrobat (APSB18-29): este último boletín corrige dos vulnerabilidades que permitirían la ejecución de código remoto debido a una escritura en memoria fuera de límite y dereferencia a puntero (CVE-2018-12808 y CVE-2018-12809 respectivamente).

Se encuentran afectadas las siguientes versiones de los producto Adobe (y anteriores):

  • Adobe Creative Cloud Desktop Application 4.5.0.324 para Windows
  • Adobe Flash Player 30.0.0.134 para los sistemas operativos Windows, macOS, Linux y ChromeOS, así como los navegadores Google Chrome, Microsoft Edge and Internet Explorer 11.
  • Adobe Experience Manager 6.x para todas las plataformas.
  • Acrobat en sus versiones 2018.011.20055, 2017.011.30096 y 2015.006.30434, y anteriores para Windows y macOS.
  • Acrobat Reader en sus versiones 2018.011.20055, 2017.011.30096 y 2015.006.30434 para Windows y macOS.

 

Más información:
 
APSB18-20 – Security update available for the Adobe Creative Cloud Desktop Application:

https://helpx.adobe.com/security/products/creative-cloud/apsb18-20.html

APSB18-25 – Security updates available for Adobe Flash Player:
APSB18-26 – Security update available for Adobe Experience Manager:

Actualización de seguridad para Apache Struts

Apache ha confirmado una vulnerabilidad en el proyecto Apache Struts que podría permitir a un atacante remoto ejecutar código arbitrario.

Struts es un entorno de trabajo de código abierto para el desarrollo de aplicaciones web en Java EE bajo el patrón MVC (Modelo Vista Controlador). Desarrollado por la Apache Software Foundation, en un primer momento formaba parte del proyecto Jakarta, convirtiéndose en proyecto independiente en 2005.

La vulnerabilidad, considerada de gravedad crítica (con CVE-2018-11776), se debe a una validación insuficiente de los datos introducidos por el usuario. Esta vulnerabilidad reside en el core del framework y existen varios vectores de ataque:

  1. Cuando se utilizan resultados que no especifican un espacio de nombres (ni el el fichero de configuración de Struts ni en el propio código Java)
  2. Cuando se utiliza la etiqueta ‘url’ en una plantilla sin especificar una acción y un valor.

A través de estos vectores un atacante remoto podría inyectar un espacio de nombres arbitrario pasándolo como parámetro en una petición HTTP.

Para que el ataque se haga efectivo, se tienen que cumplir dos condiciones:

  1. El parámetro ‘alwaysSelectFullNamespace’ debe estar a ‘true’ en la configuración de Struts.
  2. El fichero de configuración de Struts contiene una etiqueta ‘<action …>’ que no especifica ningún espacio de nombres.

La forma más sencilla para evitar las vulnerabilidades es actualizar a Apache Struts versiones 2.3.35 o 2.5.17; disponibles desde: http://struts.apache.org/download.html#struts-ga

Más información:
 
S2-057 – Apache Struts

https://cwiki.apache.org/confluence/display/WW/S2-057

Semmle Discovers Critical Remote Code Execution Vulnerability in Apache Struts

https://semmle.com/news/apache-struts-CVE-2018-11776

El ransomware SamSam ataca a entidades financieras peruanas

Desde Hispasec tenemos conocimiento de los ataques sufridos por entidades financieras peruanas, ataques que han tenido como objetivo principal la instalación del ransomware SamSam (también conocido como Samsa o Samas)

SamSam no es más que la herramienta principal de un ataque dirigido a entidades concretas. No es un malware de distribución masiva, sino que es ejecutado de forma manual dentro de la red de la organización víctima. Para ello, el atacante necesita encontrar previamente una forma de acceder a la red. Las primeras versiones del ataque usaban exploits conocidos contra servicios de la organización expuestos a Internet, pero las últimas versiones han optado por atacar usando fuerza bruta (probando contraseñas una tras otra) contra un servicio en concreto: el servicio RDP (Remote Desktop Protocol), usado para permitir el acceso remoto a otro ordenador compartiendo la pantalla.

Características principales del ransomware

Una característica del malware que impide su análisis en profundidad es que su parte principal viene cifrada con una clave que sólo conoce el atacante. Evidentemente, para su ejecución es necesario descifrarla, pero lo hace el atacante proporcionando la contraseña al ejecutarlo manualmente. Por tanto, para poder analizar el malware en profundidad, sería necesario pillar al atacante in fraganti y capturar la contraseña, ya que apenas se ejecuta el malware se borra la contraseña usada para descifrarlo.

El resto de partes son piezas de apoyo que ayudan a descifrar y lanzar el malware de forma automática. Adicionalmente, el ataque hace uso de diversas herramientas de apoyo, entre otras una herramienta de administración remota (RAT) con capacidad para realizar cualquier acción en el sistema y herramientas públicas de terceros para realizar el reconocimiento de la red y moverse lateralmente en ésta (es decir, saltar de un punto de la red a otro). De nuevo, recordamos que estamos ante un ataque dirigido, donde un atacante entra en la red por algún medio externo al ransomware, y una vez dentro, reconoce y ataca manualmente otros puntos de la red, para finalmente ejecutar el ransomware en los puntos de la red que considere dignos de secuestrar.

Flujo del ataque

A continuación se describe las fases del ataque que tienen como objetivo final la ejecución del ransomware SamSam. Se presupone que la entidad ya ha sido seleccionada por el atacante. Para ello, puede haber sido elegida manualmente por su importancia y valor, o bien haber sido elegida tras buscar organizaciones con redes con una seguridad débil. Para esto último, los atacantes se suelen valer de herramientas como el buscador Shodan, que permiten buscar qué puntos de Internet corren ciertos servicios que se conocen vulnerables, para intentar explotarlos luego. También existen listas de servicios vulnerables previamente confeccionadas puestas a la venta por otros criminales.

1. Intrusión en la red

Se conocen tres métodos por los cuales el atacante accede a la red en este paso:

  1. Ataque de fuerza bruta sobre el servicio RDP de Windows, que corre en el puerto 3389, buscando credenciales débiles.
  2. Aprovechando vulnerabilidades de servicios expuestos a Internet. En el pasado aprovecharon vulnerabilidades en el servidor de aplicaciones JBoss.
  3. Ingeniería social, especialmente a través de correos adjuntos infectados. Se desconocen los detalles de esta forma de entrada.

Una vez completado este punto, el atacante puede ejecutar código en la máquina afectada, si bien dependiendo de la configuración del sistema comprometido o del nivel de la cuenta de usuario comprometida, estaríamos hablando de ejecución a nivel de usuario sin privilegios o a nivel de administrador. Si el atacante no ha conseguido privilegios de administrador, procede al siguiente paso:

2. Elevación de privilegios

Tras conseguir entrar en la red con una cuenta de usuario sin privilegios, el atacante tiene que escalar privilegios y obtener acceso como controlador de dominio. Para ello hace uso de distintas herramientas y exploits, herramientas la mayoría de código abierto y gratuitas, y también creadas por el mismo atacante.  No se ha documentado una relación directa entre un exploit en particular y estos ataques en esta fase. Se sabe que en esta fase el atacante ha podido estar días, por ejemplo debido al uso de herramientas que aprovechan la entrada de un controlador de dominio al sistema para robarle el acceso.

3. Movimiento lateral

Con el objetivo de afectar el número máximo de sistemas, el atacante procede a escanear la red y comprometer los sistemas accesibles. Para ello, y con el acceso de administrador, accede de forma normal a un servidor de la compañía, desde el cual procede a escanear la red. Una vez seleccionados los posibles objetivos, accede a todos los que puede y realiza una prueba para ver si efectivamente puede acceder al sistema de archivos de ese sistema. El que esto sea realizado por parte del atacante de forma manual permite hacer el menor ruido posible.

4. Ejecución del malware

Tras establecerse como controlador de dominio desde un servidor de la compañía, el atacante procede a instalar y ejecutar el ransomwareSamSam en los objetivos disponibles. Para ello, usa principalmente una herramienta legal llamada PsExec. La ejecución del malware se realiza de una forma atípica: se proporciona una contraseña como parámetro de línea de comandos al ejecutable del ransomware en el momento de ejecución. Esta contraseña se usa para descifrar el malware, que viene cifrado. De esta forma, el atacante mantiene en secreto el funcionamiento concreto del malware, ya que en un análisis post mortem del sistema víctima no se encuentra el código que ha provocado el desastre.

5. Espera del pago y soporte técnico

Tras infectar todos los sistemas objetivo de una forma coordinada (con segundos de diferencia entre ellos), al atacante sólo le queda limpiar todos los rastros que pueda y esperar a que la víctima pague. Tras completarse la ejecución del ransomware, como en casi todos los casos, el malware deja una nota de rescate. En ésta se especifica la cantidad de Bitcoins a pagar para obtener la contraseña de descifrado (con precios en dólares actualmente de unos 500 dólares por máquina y 4.000 por todas) y la dirección a la que realizar el pago. También se especifica una dirección de una web contenida en la red Tor (una red pública y gratuita que mantiene el anonimato de los usuarios, pero que requiere la instalación de software adicional para navegar por ella). En esa dirección se encuentra una forma de contactar con el atacante e incluso poder descifrar algunos archivos gratuitamente. Como el acceso a la red Tor no es conocido para la mayoría de los usuarios, el atacante incluye instrucciones accesibles para poder acceder a ella.

Precisamente uno de los puntos más llamativos de este ransomware es la calidad del “soporte técnico” que se ofrece por parte del atacante para solucionar problemas relacionados con el pago y el descifrado de los archivos, llegando hasta el punto de enviarse una decena de mensajes por parte del atacante para solucionar un problema particular de un usuario que ya había pagado. O disculparse por la tardanza al responder a un mensaje de un usuario. También es reseñable que el atacante parece haber proporcionado la clave de descifrado a todas las víctimas que han pagado, si bien desde Hispasec recomendamos nunca pagar el rescate, ya que contribuiríamos a alimentar este tipo de fraude.

Soluciones y contramedidas

Este malware tiene un sistema de cifrado para el que no se han documentado fallos. Por tanto, en este momento no hay solución más allá de pagar el rescate. Ahora pasamos a diferenciar entre la infección por ransomware y la intrusión a la red para explicar qué medidas se deben tomar con antelación para protegerse de estas amenazas:

Infección por ransomware

En el primer caso, infección por ransomware, existen una serie de medidas específicas para detectar que un malware de este tipo se encuentra ejecutándose y bloquearlo, pero existen otras medidas más básicas y generales de protegerse. Hablamos de las copias de seguridad y los entornos de usuario fácilmente restaurables. Las copias de seguridad son imprescindibles para casos como éste, pero son igualmente vitales en casos de rotura del almacenamiento principal de un sistema y otras catástrofes. Es especialmente interesante que estas copias no estén conectadas a red alguna, o que se encuentren en otro lugar físico.

Adicionalmente, poder restaurar los equipos de los usuarios con un sistema de replicación de imagen de disco duro o un sistema de virtualización distribuido son las otras medidas que complementan a las copias de seguridad de los datos. Ambas medidas combinadas proporcionan una excelente protección contra la amenaza de un ransomware. Incluso en uno de los peores casos: entra un ransomware de propagación automática e infecta los sistemas de todos los usuarios de la red usando un exploit desconocido. Si tienes copias de seguridad diarias, habrás perdido como mucho un día de información. Y si los entornos de tus usuarios son fácilmente restaurables, en unas horas puedes estar funcionando de nuevo con equipos limpios.

Intrusión en la red

Finalmente, queda comentar contramedidas contra intrusiones en la red. En este tipo de casos, empresas grandes con mucho que perder y redes bastante complejas, no se puede ofrecer una serie de contramedidas generales y pensar que eso es suficiente. Es necesario invertir en seguridad informática, tanto en personal como en equipos, y apoyar firmemente desde dirección la implementación y respeto de la política de seguridad diseñada por personal cualificado. En este caso en particular, dados los tres tipos de entradas que se conoce realiza el atacante, podemos comentar las medidas básicas de protección contra cada uno de ellos:

  1. Credenciales débiles: Forzar que todo método de autenticación basado en contraseña respete unos requisitos mínimos de longitud y variedad de caracteres en la contraseña.
  2. Servicios vulnerables expuestos a Internet: Lo primero es exponer el mínimo número de servicios posibles a Internet. Lo segundo es actualizar el software para protegerse al menos de vulnerabilidades conocidas. Finalmente, aislar en la medida de lo posible estos servicios del resto de la red interna.
  3. Ingeniería social: Cursos de conciención a todos los niveles de la compañía, siempre procurando que sean prácticos y amenos. Las políticas de seguridad deben ser razonables y no requerir un esfuerzo sobrehumano para ser respetadas, o los usuarios no las respetarán.
Más información:
 

Un fallo en Google Chrome permite extraer información sensible de otras páginas

La implementación de la política del mismo origen en las etiquetas HTML multimedia es insuficiente, lo que permite peticionar páginas externas de las que es posible extraer cierta información

Extraer información de tu perfil personal de Facebook si tienes iniciada sesión en él y visitas una web maliciosa. Esta es la prueba de concepto llamativa para esta vulnerabilidad. Es posible extraer tu edad, tus likes, tu histórico de localización…Esta vulnerabilidad ha sido reportada por Imperva, una empresa de seguridad informática dedicada entre otras cosas al análisis de eventos de seguridad. Se dieron cuenta de ella cuando investigaban el comportamiento del mecanismo CORS (Cross-Origin Resource Sharing) en las distintas etiquetas HTML.

Lo que encontraron fue ciertamente interesante… Pero antes es necesario explicar lo básico, para que la vulnerabilidad no nos suene a chino. Primero, es necesario saber que el navegador, por seguridad, restringe bastante las peticiones que puede hacer una página web a otra página web que no esté en su dominio. ¿Qué quiere decir esto? Que la página de facebook.com tal y como se ejecuta en tu navegador, no puede hacer cierto tipo de peticiones a google.com. ¿Por qué este comportamiento? Un ejemplo simple: imagínate que entras a paginamala.com y ésta se pone a hacer peticiones a bancosantander.com, teniendo abierta la banca online… En realidad luego no es tan sencillo, ya que existe otra serie de medidas para evitar que esto ocurra aunque no se respete esa restricción, pero es un control necesario más.

Lo que acabamos de contar arriba no es ni más ni menos que la famosa “same-origin policy” (política del mismo origen), cuyo nombre tras la breve explicación cobra sentido. Lo que pasa es que la web, por definición, no tiene sentido como nodos aislados, y una página funcional necesita recursos de otras webs. No estamos hablando de estar en google.com y desde allí pinchar en un enlace a facebook.com, no. Esto se considera como una acción intencionada del usuario, y no es la misma página la que ejecuta la acción (ni recibe el contenido de facebook.com). Hablamos de facebook.com necesitando una fuente de texto especial alojada en google.com (que tiene una sección para obtener fuentes), para poder mostrarte un texto con esa fuente.

Error en Chrome por realizar una petición que viola la política del mismo origen

Es por esto que para que una web pueda acceder a recursos de otra (siempre que esta otra quiera), se crea el mecanismo CORS antes mencionado, que define una serie de situaciones y acciones que se deben llevar a cabo en éstas que permiten compartir recursos entre orígenes distintos. Y esto es lo que significa CORSbásicamente, “intercambio de recursos de origen cruzado”. En la práctica esto se implementa haciendo el navegador una petición de prueba antes de la real, para preguntar al dominio externo si permite peticiones completas desde otros dominios, y si no lo permite explícitamente, no se hace la petición completa. En algunos casos más relajados se permite hacer directamente la petición completa, pero si el servidor no especifica explícitamente que cierta página externa puede peticionarla (ya sea por no haber sido configurado o por otras razones), el mismo navegador no permite a la página leer la respuesta a la petición.

Ya disponemos de las bases para entender la vulnerabilidad. Como bien sabemos, la parte principal de una web está compuesta por HTML, que a su vez se compone de etiquetas especificando el contenido de la web. Pues bien, en Google Chrome, las etiquetas ‘audio’ y ‘video’, tienen un pequeño fallo. Estas etiquetas son usadas para insertar audio y vídeo en las páginas, y uno de sus atributos es la URL en la que está el recurso, (audio o vídeo). El fallo que tienen es que no comprueban el tipo de recurso (básicamente, que sea audio o vídeo) antes de permitir acceder a cierta información del recurso. Concretamente, sin saber si el recurso es audio o vídeo y mientras lo descarga, esta etiqueta lanza una serie de eventos que el código JavaScript de la página puede capturar y extraer información de éstos.

¿Cuál es el problema de ésto? Que según el número de eventos de cierto tipo que arroje la etiqueta HTML mientras va cargando el recurso sea audio o no, es posible estimar el tamaño del recurso. ¿Realmente esto es un problema? Sí. Y lo entenderemos describiendo el escenario del ataque propuesto por el autor:

  1. Crea una página en Facebook
  2. Publica un post restringido a personas con 18 años
  3. Publica otro post restringido a persona con 19 años
  4. Publica más posts con la misma idea hasta cubrir todo el rango de edad, año a año
  5. Crea una página maliciosa con tantas etiquetas ‘audio’ como posts has creado en Facebook, y que cada una apunte a un post.
  6. Controla la cantidad de veces que se lanza este evento por cada etiqueta, para estimar el tamaño de cada página.
  7. Consigue que la víctima visite tu página maliciosa
La idea de esto es que el post restringido a la edad que tiene el usuario tendrá un tamaño distinto al resto de páginas, que serán más pequeñas porque en vez del ofrecer el contenido del post, devolverán un mensaje del estilo “no estás autorizado a ver este post”. El autor describía esto como jugar a un juego de preguntas de sí o no para adivinar algo, al estilo de Quién es Quién. Este escenario en concreto quizás no se pueda reproducir ahora mismo, ya que Facebook ha cambiado hace poco el sistema de restricción y parece que no se puede restringir por edad a nivel de año, sino por rangos concretos. Igualmente, el autor describe otros campos que se pueden extraer y no sólo es posible con Facebook, sino con cualquier web en realidad que tenga características similares.
Afortunadamente, este fallo (CVE-2018-6177) se reportó por las vías adecuadas (a Google de forma privada) y actualmente se encuentra corregido en la versión estable 68. ¿Cómo lo ha corregido Google? Ahora no permite que se dispare ese evento hasta que el navegador no sepa a ciencia cierta que lo que está cargando es un recursos de audio o vídeo. Esta vulnerabilidad es compleja, aunque comparada con el resto de vulnerabilidades que se suelen encontrar hoy en día tampoco es extraordinaria. Eso permite hacerse una idea de la cantidad de conocimiento que es necesario tener sobre un sistema para encontrar una vulnerabilidad medio graveen éste, sobre todo si es el navegador más usado en todo el mundo.
Más información:
 
A Bug in Chrome Gives Bad Actors License to Play ‘20 Questions’ with Your Private Data
https://www.imperva.com/blog/2018/08/a-bug-in-chrome-gives-bad-actors-license-to-play-20-questions-with-your-private-data/Stable Channel Update for Desktop – Tuesday, July 24, 2018
https://chromereleases.googleblog.com/2018/07/stable-channel-update-for-desktop.html

Control de acceso HTTP (CORS)
https://developer.mozilla.org/es/docs/Web/HTTP/Access_control_CORS

Política Same-origin

Security: Cross Site Resource Size Estimation via OnProgress events
defeat cors attacks on audio/video tags

Vulnerabilidad crítica en Oracle Database

El fallo, con una puntuación CVSSv3 de 9,9, podría propiciar el acceso completo a la base de datos y al sistema operativo subyacente. Oracle apela al parcheo inmediato de los sistemas.

Pocas veces una empresa con una política periódica de publicación de parches rompe sus ciclos pero, cuando lo hace, normalmente es motivo de preocupación. En este caso le ha tocado a Oracle, que publica sus parches cuatrimestralmente.

Y el motivo no es para menos. Identificada como CVE-2018-3110, la vulnerabilidad encontrada en Oracle Database Server permite a un atacante remoto tomar el control de la base de datos y acceder a través de linea de comandos al sistema operativo sobre el que se ejecuta.

Concretamente, el fallo se encuentra en el componente Java VM. La explotación es trivial, pero requiere al atacante remoto estar autenticado y contar con el privilegio “Create Session“, además de acceso a través de Oracle Net.

La vulnerabilidad ha sido publicada debido a su impacto en las versiones 11.2.0.4 y 12.2.0.1 para Windows. Sin embargo ya en su boletín de julio Oracle parcheaba este mismo fallo para la versión 12.1.0.2 en Windows, y para aquellas bajo sistemas Linux y Unix.

Esta no es la primera vez que Oracle saca parches fuera de ciclo. De hecho, el año pasado publicó hasta 4 alertas bajo la tipología Oracle Security Alert Advisory, que es la que se utiliza cuando las vulnerabilidades son críticas (puntuaciones CVSSv3 mayor a 9.8, al menos) y requieren acción inmediata. Una de ellas era 10/10.

Más información:

Oracle Security Alert Advisory – CVE-2018-3110:

Man-in-the-Disk: el nuevo ataque que ha dejado a millones de teléfonos Android vulnerables

El ataque aprovecha la forma en la que las apps utilizan el sistema de almacenamiento externo para dar como resultado una inyección de código.

Los investigadores de seguridad de Check Point Software Technologies han descubierto un nuevo vector de ataque contra el sistema operativo Android que podría permitir a los atacantes infectar silenciosamente sus teléfonos inteligentes con aplicaciones maliciosas o lanzar ataques de denegación de servicio.

Conceptos base:

Es bien conocido que las aplicaciones en el sistema operativo Android pueden almacenar sus recursos en el dispositivo en dos ubicaciones: almacenamiento interno y externo.

Google, insta a los desarrolladores a usar el almacenamiento interno, que es un espacio aislado asignado a cada aplicación protegida usando el ‘sandbox’ integrado de Android, para almacenar sus archivos o datos confidenciales.

Sin embargo, los investigadores encontraron que muchas aplicaciones usaban almacenamiento externo sin protección al que cualquier aplicación instalada en el mismo dispositivo puede acceder.

Explicación del ataque:

Por ejemplo, los investigadores encontraron que el navegador web Xiaomi descarga su última versión en el almacenamiento externo del dispositivo antes de instalar la actualización. Dado que la aplicación no puede validar la integridad de los datos, el código de la actualización legítimo de la aplicación se puede reemplazar por uno malicioso.


 
Entre las aplicaciones que han probado se encuentran: Google Translate, Yandex Translate, Google Voice Typing, Lg World, … entre otras.

Los investigadores recalcan que solo han probado una pequeña cantidad de aplicaciones importantes y, por lo tanto, esperan que el problema afecte a un número más signifitcativo.

El cifrado Speck gana presencia en el kernel Linux

Speck es un algoritmo de cifrado ligero, especialmente diseñado para dispositivos IoT, con baja capacidad de cómputo y creado por la NSA, la Agencia de Seguridad Nacional de Estados Unidos.


Esta tecnología, que fue aceptada por una petición de Google para dar soporte de cifrado al nuevo sistema operativo Android Go en la versión 4.17 del kernel Linux, ha aumentado su presencia en el kernel de Linux debido a la inclusión de Speck128 y Speck256 como algoritmos compatibles en FSCRYPT.

Speck al igual que Simon, fueron publicadas en 2013 como dos tipos cifrados diseñados para sistemas ligeros. Speck es un cifrado add-rotate-xor (ARX) diseñado para ser lo más ligero posible, mientras que su algoritmo hermano, Simon, se ha optimizado para implementaciones de hardware.
 
El hecho de que ambas tecnologías de cifrado hayan sido desarrolladas por la NSA y que hayan sido rechazadas por la Organización Internacional de Estándares (ISO), han rodeado a esta decisión de una latente desconfianza por parte de la comunidad.
Si tiramos de antecedentes, esta desconfianza está sustentada por hechos como las filtraciones sobre que el software de cifrado Truecrypt estaba ‘backdoreado’ por la NSA. Caso que finalmente por medio de dos auditorias quedó descartado, excepto por los más escépticos que vieron en el abandono de sus desarrolladores un argumento a favor de sus convicciones.
Más información:
Auditoría Truecrypt:

Kaspersky VPN – Descubierto bug que afecta a millones de usuarios

La versión 1.4.0.216 de Kaspersky VPN presenta una fuga de DNS que podría revelar información sobre las páginas visitadas por los usuarios.

El bug se encontraba en el servicio VPN ofrecido por Kaspersky, también conocido como “Secure Connection” y que según Kaspersky cuenta con más de un millón de usuarios en todo el mundo.

En Android, Kaspersky VPN – Secure Connection tiene más de 1.000.000 de descargas

Cuando un usuario se conecta a una VPN, todo el tráfico pasa a través de un túnel cifrado al servidor VPN, por lo que al servidor de destino le llega la dirección IP de dicho servidor.

Funcionamiento VPN

El problema surge cuando Kaspersky VPN no redirige las consultas al servidor DNS cifradas, por lo que el servidor DNS podría registrar los sitios web que visitan los usuarios e incluso vincularlos a su dirección IP.

Este bug fue descubierto por el analista de seguridad Dhiraj Mishra, en su blog indica los pasos a seguir para reproducir el problema:

  1. Visitar IPleak.net
  2. Conectarse a cualquier servidor virtual utilizando Kaspersky VPN.
  3. Una vez conectado, volver a visitar IPleak.net. Se podrá observar que la dirección DNS no ha cambiado.
 
Kaspersky a solucionado este fallo en la versión 1.4.0.453. Se recomienda actualizar a la última versión disponible.
Más información:
 
A bug that affects million users – Kaspersky VPN | Dhiraj Mishra
https://www.inputzero.io/2018/08/kaspersky-vpn-leaks-dns-address.html

Actualización de seguridad para VMware Horizon Client

El equipo de VMware a publicado actualizaciones de seguridad para corregir una vulnerabilidad de lectura fuera de límites de memoria (Out-of-bounds Read) que afecta al producto VMware Horizon Client para Windows.

VMware Horizon ofrece una infraestructura de escritorios virtuales (VDI). Es este caso el cliente de conexión de Horizon permite a los usuarios conectarse a su escritorio virtual desde múltiples dispositivos.

La aplicación Horizon Client se comunica con View Connection Server, que actúa como intermediario entre el dispositivo cliente y los escritorios. Los usuarios inician sesión en Horizon Client y View Connection Server los autentica para luego conectarlos con sus respectivos escritorios virtuales.

VMware Horizon – Gestión de la infraestructura
VMware Horizon Client – Conexión desde el cliente al escritorio virtual

Las versiones de Horizon 6, 7 y Horizon Client para Windows presentan una vulnerabilidad de lectura fuera de los límites de memoria en la librería “Message Framework”. Un usuario malicioso con pocos privilegios podría explotar esta vulnerabilidad permitiendo acceder a información desde un proceso privilegiado en un sistema donde se encuentre instalado Horizon Connection Server, Horizon Agent u Horizon Client afectados por esta vulnerabilidad.

Este problema solo afecta a las versiones de Horizon 6 y 7 de Microsoft Windows.

VMware ha publicado las siguientes actualizaciones:

Horizon 7 – Windows | Parche 7.5.1:
https://my.vmware.com/en/web/vmware/info/slug/desktop_end_user_computing/vmware_horizon/7_5

Horizon 6 – Windows | Parche 6.2.7:
https://my.vmware.com/group/vmware/info?slug=desktop_end_user_computing/vmware_horizon/6_2

Horizon Client for Windows – Windows | Parche 4.8.1:
https://my.vmware.com/web/vmware/details?productId=578&downloadGroup=CART19FQ2_WIN_4_8_1

Más información:
 

Bughunting, la economía alrededor de los errores

Encontrar un fallo de seguridad en una aplicación o servicio conocido puede llegar a ser lucrativo…o meterte en graves problemas legales. Vamos a dar un repaso al arte de reportar vulnerabilidades.

Sabes que está ahí, lo puedes sentir, es ese olor ocre y salino de la sustancia que emana de la presa herida. El cazador lo percibe, agudiza sus sentidos y acecha en silencio; esperando pacientemente al momento adecuado. Un segundo más, abres el editor de texto (Vim, naturalmente) y cambias dos lineas de tu script. Zas!: ejecución remota de código arbitrario conseguida. Premio. ¿Ahora qué hacemos con el trofeo?

Hace poco, leía en una viñeta de esas que aparecen, brillan y se extinguen en un par de milésimas de red social, que los Ingenieros Mecánicos y Aeronáuticos confían plenamente en aquello que diseñan y construyen. Es decir, es seguro y transmiten esa seguridad. Soluciones contrastadas, experimentadas. No dejan espacio al error, lo arrinconan, le temen, lo respetan, pero lo desafían y controlan hasta reducirlo a probabilidades muy reducidas. Ahora pregunta lo mismo a un Ingeniero Informático…

En el software las probabilidades son las mismas, pero en sentido contrario. Es decir, es ridículamente improbable que encuentres un programa que esté libre de errores. Irónicamente…no falla. Hay algo en el proceso de construcción de nuestros ingenios que impide que estén libres de errores. Esto no es nuevo, ya lo dijo el grandísimo Fred Brooks: No hay balas de plata. El software es complejo, mucho y está lejos de ser perfecto.

No hay dos errores iguales

Bien, creo que lo hemos dejado claro o al menos lo hemos intentado. El software está lleno de errores. El problema añadido es que los errores no son idénticos, poseen una jerarquía, gravedad y especializaciones propias. De entre ellos podemos destacar los errores de seguridad, que al fin y al cabo son los que nos interesan. Estos son especialmente graves de por sí, puesto que conllevan un impacto asociado a una necesidad humana: la de sentirnos seguros.

No es lo mismo un error funcional, por ejemplo: Cuando pulso esta opción de menú aparece una molesta ventana de error, pero el proceso sigue su curso, que uno de seguridad: Cuando pulso sobre esta opción de menú, aparece una molesta ventana de error, le doy al cuadro de ayuda, mostrar propiedades, abrir consola, pum, eres administrador. Evidentemente, las consecuencias no son las mismas.

Además -para mejorar la cosa- está el primo hermano del error: el contexto. Puedes tener un error, poco grave a primera vista y que, por ejemplo, solo afecta al redondeo de unos pocos decimales. ¿Nada grave, verdad? Escala eso a millones de entradas en un software científico y tendrás un error de magnitudes incalculables. La diferencia suficiente entre hallar la vacuna del ébola a encontrar un nuevo colorante industrial para la gaseosa. Uy, por cuatro péptidos de nada.

Economía de mercado

Vale, ya sabemos que el software es un saco de bichos, que estos pueden ser más o menos graves y que las consecuencias de un fallo de seguridad pueden ser desastrosas según el contexto. ¡Anda!, ¿Y qué pasaría si descubres un error por el cual un tercero le podría sacar una rentabilidad económica o mediática? Pues que acabas de encontrar un billete de lotería premiado. Descubres algo, lo trasladas a un interesado a cambio de unos doblones y este usa esa información para su propio beneficio. Eso, amigos, nos lleva a construir una auténtica economía de mercado (con su equivalente paralelo mercado negro) basada en los errores de seguridad.

Servicios de inteligencia, contrainteligencia, brokers de exploits, productores de software de control remoto, unidades militares que participan en operaciones de ciberguerra, robo de propiedad intelectual, etc. Hay intereses de todo tipo y ejemplos que vemos casi a diario de demanda de nuevos zero-days para mantener el frente abierto. Una vez sale el parche, se acabaron las nuevas operaciones…hasta que el siguiente exploit devuelva la pelota al campo.

Y aun no hemos mencionado las botnets, el cryptojacking y el ransomware. Muchas de ellas se apoyan en la mera ingeniería social e ir probando suerte con campañas de phishing para ir infectando equipos. Sin embargo, esta técnica suele tener un porcentaje sorprendentemente bajo de éxito. No obstante, cuando estas campañas van acompañadas de un exploit fresco, la rentabilidad en los primeros días se dispara exponencialmente.

Que nadie crea que vender un exploit es algo exclusivo del mercado negro. Existencompañías dispuestas a pagar una suma importante de dineros a cambio de esa secuencia única de ceros y unos.

Bug hunting, cuando la necesidad crea el producto

Hastiadas por ver como sus productos se convertían en un continuo mercadeo que afecta a sus usuarios, las empresas comenzaron a dar un paso en un peculiar sentido: No lo vendas a ellos, compártelo con nosotros. Ahora son las propias empresas, afectadas por los errores de seguridad en sus productos, las que compran los fallos de seguridad a sus descubridores.

Uno de los primeros programas de este tipo es el de Google. Allá por el 2013 anunció que pagaría por los errores de seguridad en sus productos; ahora incluso por ciertos proyectos de fuente abierta, cuyas librerías son usadas por ellos. Este paso llevó a otras compañías a anunciar el emprendimiento de programas de este tipo con pequeñas variaciones en cuanto a reglas y premios.

Tras ellos, otros con buen olfato vieron claro que aquí había negocio. ¿Por qué no abrir el negocio del reporte de fallos de seguridad? Estaba claro que había una necesidad y, por otro lado, un batallón de personas interesadas en investigar y descubrir fallos. Así que si hay una demanda y por otro una oferta…unámoslos con el pegamento universal que todo el mundo entiende y usa: el dinero.

Este tipo de esquema asume que la gente va a seguir investigando, sean cuales sean sus motivaciones y que los servicios y productos desarrollados por empresas son demasiado grandes como para ser controlados por un departamento. Win-win. Todos ganan, todos contentos.

En algunos casos, el investigador ni tan siquiera es premiado económicamente. Existen programas de recompensas que solo premian con una mención o con merchandising, dependiendo de la gravedad del hallazgo. Esperad, esperad, no os riáis. Una mención puede parecer ridícula, pero en el curriculum de un investigador puede ser la diferencia con el resto de candidatos. Por otro lado, las vulnerabilidades especialmente graves pueden llegar a reportar beneficios de cientos de miles de dólares. Como vemos el abanico de premios es surtido.

¿Cómo reportar una vulnerabilidad que no posee un programa de recompensas?

Es complicado. Muchas empresas no se toman bien este tipo de acciones. Quizás porque derivan a departamentos legales donde no saben maniobrar de otra forma que no sea abriendo fuego contra el supuesto enemigo o porque se toman como una ofensa el que alguien haya estado husmeando en sus servidores. Sea como fuere, si una empresa no indica explícitamente la manera de reportar fallos de seguridad, no se los reportes directamente.

Desde luego no reportar no implica que no des conocimiento. Existen muchísimas posibilidades de hacerlo sin meterte en un lío legal. Por un lado has descubierto algo, sabes que es ético que dicho fallo se conozca y sea reparado, pero por otro tienes miedo de que tu buena intención acabe trayéndote quebraderos de cabeza y arrastres tu alma y tus ahorros por los juzgados del país durante unos cuantos años.

En España puedes probar con el CERTSI, donde te ofrecen anonimato y si en un plazo de tiempo prudencial no se ha encontrado solución por parte del fabricante, se publicarían los detalles de tu hallazgo con tu nombre si lo deseas.

Francamente, si te gusta encontrar fallos y ganarte un dinero y renombre, las opciones anteriores, del tipo Bugcrowd o Hackerone poseen un buen equilibrio. Busca un programa de recompensas que te interese, léete las condiciones y a cazar!

Denegación de servicio remota en los núcleos Linux y FreeBSD

Un investigador de los Nokia Bell Labs ha descubierto vulnerabilidades en los núcleos Linux y FreeBSD que pueden usarse para saturar el procesador (y consecuentemente la máquina) a través de un flujo TCP especial

No estamos ante vulnerabilidades que podrían ser aprovechadas en teoría, en circunstancias especiales, si se alinean los planetas… Que pasa a veces con vulnerabilidades de este tipo en el núcleo Linux. Y eso lo sabemos porque Akamai ha realizado un comunicado oficial asegurando que ha parcheado sus sistemas más críticos y está trabajando en parchear el resto en estos momentos. Ambas vulnerabilidades, tanto la de Linux como la de FreeBSD han venido de la mano de Juha-Matti Tilli, un investigador de los Nokia Bell Labs. Estos laboratorios pertenecen a la división de investigación industrial de la famosa “teleco” multinacional Nokia.Para comprender estas dos vulnerabilidades, es necesario recordar por encima lo básico de redes. Para que la información llegue de un punto a otro del planeta, esta información suele envolverse en varias capas. Literalmente, a cada trozo de información se le pone un prefijo (y a veces un sufijo) que contiene información relativa a esa capa. Y el proceso se repite por cada capa. Cada una de estas capas es responsable de algún aspecto de la comunicación: una contiene información sobre el siguiente nodo al que viajará el paquete, otra contiene información que permite asegurar que no se pierde ningún paquete… Durante el viaje, las capas se van quitando, poniendo y modificando según sea necesario. De hecho, cada dispositivo de red (router, switch, tarjeta de red y el mismo sistema operativo) está preparado para interpretar ciertas capas e ignorar las otras.

En este caso, la vulnerabilidad se encuentra en la forma en la que ambos núcleos manejan el protocolo TCP, hermano del protocolo UDP que aparece en la figura. TCPtiene entre sus responsabilidades dividir en trozos llamados “segmentos” la información que pretende transportar si es demasiado grande para transportarse de una sola vez. Tras dividirse en segmentos, TCP se encarga de que cada segmento tenga un identificador que permita al destinatario juntar los segmentos TCP en el orden correcto y reconstruir la información original. Esto es necesario, ya que los paquetes no tienen por qué llegar en el orden en el que salieron.

Llegados a este punto, ya podemos empezar a entender las vulnerabilidades tal y como la explican los reportes oficiales (el primero Linux y el segundo FreeBSD):

One of the data structures that holds TCP segments uses an inefficient algorithm to reassemble the data. This causes the CPU time spent on segment processing to grow linearly with the number of segments in the reassembly queue.

Juha-Matti Tilli reported that malicious peers could inject tiny packets in out_of_order_queue, forcing very expensive calls to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for every incoming packet.

Ambas vulnerabilidades dan a entender el mismo problema subyacente: la reconstrucción de la información original a partir de los segmentos TCP fuera de orden no es demasiado eficiente. Los algoritmos usados para la reconstrucción seguramente funcionan bastante bien en las circunstancias habituales, pues en otro caso se habrían detectado problemas de rendimiento previamente. Pero en casos raros, y especialmente si quieres buscarle las cosquillas, es posible a través de una serie de segmentos TCP especialmente diseñados causar que la reconstrucción tarde demasiado. Lo de “demasiado” significa que para una cantidad relativamente pequeña de segmentos TCP (es decir, con un ancho de banda pequeño) conseguimos usar tiempo del procesador de una forma desproporcionada.

Tanto el código del núcleo de Linux como el de FreeBSD han sido actualizados con sendos parches. En Linux estamos hablando de la versión 4.9 para adelante como las más afectadas, pero con la 4.8 y anteriores vulnerables en menor medida (necesitando más tráfico para causar el mismo efecto). En FreeBSD se ven afectadas todas las versiones. La vulnerabilidad de Linux ha recibido el identificador CVE-2018-5390, mientras que la de FreeBSD ha recibido el CVE-2018-6922.

 

Más información:

Cuando tu impresora es más lista de lo que parece: Ejecución remota en HP

HP ha publicado un boletín informando de una vulnerabilidad que permite ejecución remota de código en múltiples modelos de impresoras de tinta

La puntuación base CVSS no deja lugar a dudas: un 9.8 sobre 10. Para que nos entendamos, esta vulnerabilidad equivale a dejarse la puerta de casa abierta con las joyas en la mesa del salón. A pesar de que los vectores CVSS muchas veces no permiten describir la complejidad de una vulnerabilidad, un valor extremo es un mensaje claro. Y afectando a múltiples dispositivos, es una pequeña catástrofe. De éstas que te hacen poner un aviso claro en tu web:

En este caso, es posible que el reporte por parte del investigador externo se haya realizado de forma privada, ya que no aparece vínculo alguno al reporte técnico original. Estos reportes suelen ser más técnicos, y te permiten entender la parte importante de la vulnerabilidad, ya que los reportes oficiales suelen ser bastante escuetos y parecen escritos por cumplir. Por tanto, en este caso no podemos ofrecer un análisis técnico de los hechos y nos limitaremos a comentar el boletín oficial y comentar algunos hechos relacionados. La vulnerabilidad es lo más clásico: se manda a imprimir un archivo especialmente diseñado que desborda memoria en la impresora y permite ejecutar código arbitrario.

En el boletín oficial asignan los identificadores CVE-2018-5924 y CVE-2018-5924 a las vulnerabilidades descritas, y especifican una lista bastante larga de productos afectados, viéndose afectadas las impresoras de inyección de tinta (inkjet). También se especifica que se han actualizado los firmwares de las impresoras afectadas, y que los usuarios de éstas deberían actualizar el firmware a la versión indicada siguiendo el procedimiento enlazado en el mismo boletín.

Lo cierto es que es un tema algo candente, y parece ser que con la fiebre de la seguridad del IoT algunos se han dado cuenta de que esos cacharros que imprimen son otro punto vulnerable más. Y lo bueno de una impresora es que no se suele considerar sospechosa, pues se le cree tonta. Y al final es un dispositivo más, probablemente con acceso a Internet y un procesador ARM genérico que ejecutará lo que sea. Tirando un poco de historial y sin irnos muy lejos, podemos comprobar que hace casi un año se descubrieron algunas vulnerabilidades graves en impresoras HP. El reporte técnico que se realizó es para sentarse a leerlo y disfrutarlo.

Respecto a la seguridad de las impresoras, hay una wiki bastante interesante sobre la “(in)seguridad” como dicen ellos mismos de estos dispositivos. Asociado a la wiki disponemos de PRET, un conjunto de herramientas para la explotación de impresoras. Visto el panorama, parece un buen momento para prestarle atención a la explotación de estos dispositivos.

Más información:
 
Una-al-día:

Detectadas aplicaciones en Google Play Store que contienen malware… para Windows

Las aplicaciones se encontraban en el repositorio oficial desde octubre del año pasado. Aunque inofensivas para los usuarios de Android, si se ejecutan en un entorno Windows pueden infectar el equipo con un keylogger.

Imagen obtenida de Palo Alto.

La retirada de aplicaciones de Google Play Store debido a su contenido malicioso no es nada nuevo. De hecho, hace poco una buena tanda de aplicaciones de minería fueron eliminadas del repositorio. Sin embargo, lo curioso de este caso es que, aunque maliciosas, las aplicaciones no presentan riesgos para usuarios de Android. 

Han sido investigadores de Palo Alto los que han detectado un total de hasta 142 aplicaciones disponibles en Google Play Store que contienen al menos un ejecutable malicioso para Microsoft Windows. El fichero es inofensivo para los usuarios móviles, sin embargo su desempaquetado y posterior ejecución en entornos Windows lleva a la infección del equipo con un keylogger.

La teoría más plausible es que sean los propios desarrolladores de las aplicaciones los infectados por malware (posiblemente de varias familias) y durante el proceso de desarrollo los ejecutables se han introducido dentro del APK que ha pasado a distribuirse. Cabe señalar que otras aplicaciones del mismo desarrollador están limpias, lo que apunta a que han sido confeccionadas en otro entorno.

Las APKs involucradas que Palo Alto ha hecho públicas se pueden encontrar en Koodous. Como curiosidad, el ejecutable de Windows fue visto por primera vez en 2013.

Más información:
 
Hidden Devil in the Development Life Cycle: Google Play Apps Infected with Windows Executable Files:
https://researchcenter.paloaltonetworks.com/2018/07/unit42-hidden-devil-development-life-cycle-google-play-apps-infected-windows-executable-files/
adminits

This entry has 0 replies

Comments are closed.