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

Filtración de información confidencial a través de Philips IntelliSpace y Xcelera

Las vulnerabilidades han sido descubierta por el equipo de control de emergencia cibernética de sistemas de control industrial (ICS-CERT) junto con el equipo de Philips Hearhcare en los software Philips’ IntelliSpace Cardiovascular (ISCV) y en el software de administración de información e imagen cardiovascular Xcelera los cuales alertaron después de descubrir esta vulnerabilidad.

Extraída de https://www.philips.com/
Según ICS-CERT una explotación exitosa de las vulnerabilidades podría permitir a un atacante local con privilegios en el servidor ISCV/Xcelera elevar privilegios y ejecutar código arbitrario en el servidor.

A las vulnerabilidades encontradas se les han asignado los identificadores CVE-2018-14787 y CVE-2018-14789. La primera vulnerabilidad es debida a una gestión incorrecta de los privilegios, y la segunda es debida a un error de sanitización de los parámteros en el campo de búsqueda.

Aunque por separado, estas vulnerabilidades no son críticas, ambas juntas podrían permitir a un atacante ejecutar código arbitrario, lo que puede provocar a la obtención de detalles de los pacientes existentes en el sistema.

A día de hoy, según el Philips no han recibido datos ni indicios de que estas vulnerabilidades hayan sido explotadas.

Las vulnerabilidades afectan a la versión 3.1 o anterior de IntelliSpace Cardiovascular y a la versión 4.1 o anterior de de Xcelera.

Actualmente no hay parche oficial disponible que corrija estos problemas. Los parches que corrigen estas vulnerabilidades serán lanzados en su próxima versión prevista para el mes de octubre. Mientras tanto, Philip recomienda que se revisen los permisos a los archivos de todos los usuarios de la red.


Jose Ignacio Palacios
jipalacios@hispasec.com
@jpalaciosortega
Más información:
 
E Hacking News: Cybersecurity Vulnerabilities in Philips IntelliSpace System Exposes Sensitive Cardiac Patient Information:

Fallo en OpenSSH permite la enumeración de usuarios

OpenSSH, es una popular suite de utilidades criptográficas que permiten establecer una comunicación cifrada entre cliente y servidor.  Prácticamente omnipresente en el ámbito UNIX, OpenSSH fue escrita como parte del proyecto OpenBSD a partir de un fork de SSH; posee una licencia de código BSD.

El problema se ha hallado en la función userauth_pubkey. Como podemos ver en el código original:

authctx es una estructura que contiene información del contexto de autenticación, entre los valores que la componen, valid es un entero. Cómo podemos observar de los comentarios anexos, si posee un 0 el usuario no existe (lo contrario, existe y se le permite hacer login):

Tal y como comenta el reporte original, si el usuario no es válido la función vuelve (línea 100 de la primera captura) y el servidor enviaría un mensaje al cliente, SSH2_MSG_USERAUTH_FAILURE, indicando este error. Sin embargo, y siempre que la petición ssh de autenticación posea un formato erróneo, si el usuario existe, procede a verificar la petición y al no ser correcta falla en la función sshpkt_get_u8, con lo que se ejecutaría la función fatal y el servidor cerraría la conexión con el cliente de inmediato.

Es decir, siempre y cuando el usuario sea válido y la petición tenga un formato no válido, sabremos por el cierre de la conexión que el usuario existe en el sistema. Esto nos permite obtener un método de prueba y error para enumerar los posibles usuarios de un sistema.

Hasta ahora, OpenSSH ha tenido otras vulnerabilidades relacionadas con este tipo de ataques, del tipo timming, donde se explota una diferencia en tiempo o cantidad de datos en la respuesta entre un usuario válido u otro que no exista. Posibilitando, por lo tanto, un método para derivar la existencia.

Por ejemplo, esta, donde si un usuario existía en el sistema el servidor ssh respondía con dos segundos aproximados de retraso frente a la respuesta inmediata si el usuario no existía.

La corrección de este fallo se ha traducido en postergar la comprobación authctxt->valid que hemos visto después de comprobar que la petición posee un formato correcto, impidiendo que existan diferencias tanto si existe o no un usuario concreto. Observemos el cambio de posición del bloque de código afectado:

El fallo afecta, en principio, a todas las versiones de OpenSSH, aunque ya ha sido parcheado en la versión 7.7

No tardaremos en ver exploits y módulos de nmap explotando este error, por lo que habrá que estar atentos a los registros de eventos para comprobar como se comen el espacio en disco a base de martillear los servidores ssh.


Más información:
 

Vulnerabilidades en PimCore

Se han hecho públicas 3 vulnerabilidades en PimCore que podrían permitir extraer información de la base de datos y realizar ataques Cross-site Request Forgery yCross-site Scripting. Una de ellas permanece sin corregir.

PimCore es una plataforma de software empresarial de código abierto que combina funcionalidades de gestión de información de productos y datos (PIM/MDM), gestión de activos digitales (DAM), gestión de la experiencia del usuario (CMS/UX), y comercio electrónico. Es utilizado por empresas como T-Mobile, Peugeot, Intersport o Carrefour.

Las vulnerabilidades son las siguientes:

* CVE-2018-14057: existen múltiples funciones en la aplicación que no cuentan con la protección de un token anti-CSRF. Esto podría permitir la realización de ataques Cross-site Request Forgery (CSRF) para, entre otras acciones, añadir, actualizar o eliminar entradas.

Algunas de las funciones vulnerables son las siguientes:

CVE-2018-14057 – Funciones vulnerables

* CVE-2018-14058: se han identificado múltiples fallos que podría permitir inyecciones SQLen la API REST. Un atacante que disponga de una clave válida de la API y con al menos permiso de “Activos”, “Documentos” u “Objetos” podría extraer información sensible de la base de datos.

A continuación se muestran algunas de las funciones vulnerables:

CVE-2018-14058 – Funciones vulnerables

* CVE-2018-14059: se han encontrado errores de falta de filtrado en múltiples campos de texto y entradas de datos por parte del usuario que podrían permitir a un atacante autenticado llevar a cabo ataques Cross-site Scripting (XSS) persistentes y, entre otras acciones, editar cuentas de usuario, tipos de documento, propiedades predefinidas, metadatos de activos predefinidos, valores de cantidad, rutas, miniaturas, clasificación de un item, etc.

Cabe destacar que la empresa desarrolladora ha declarado que no corregirá estos últimos errores (a pesar de la insistencia de los descubridores), al considerar que únicamente afectan a funcionalidades administrativas y se requieren permisos elevados para utilizarlas y por tanto estimar que se trata de un gasto adicional sin ningún beneficio para la seguridad.

Todas las vulnerabilidades anteriores han sido encontradas en PimCore 5.2.3. Se ha lanzado una nueva versión, la 5.3.0 que corrige los problemas de seguridad (excepto los identificados como CVE-2018-14059), y se encuentra disponible para su descarga desde la página oficial.

Más información:
 
SQL Injection, XSS & CSRF vulnerabilities in Pimcore software:

Foreshadow, nuevo ataque basado en la ejecución especulativa

Foreshadow, nuevo ataque basado en la ejecución especulativa

 

A Spectre y Meltdown se les suma un nuevo ataque (en realidad son varios) del tipo “ejecución especulativa”. Las consecuencias, al igual que los anteriores ataques, es la capacidad de leer zonas de la memoria a las que no se debería de tener acceso.

Este tipo de ataques se basan, como ya hemos mencionado, en la ejecución especulativa. ¿Qué es? Es una técnica de optimización que utilizan los microprocesadores para ir “adelantando” trabajo. Mientras que un grupo de instrucciones se está ejecutando, otro hilo del procesador puede ejecutar instrucciones futuras o acceder a recursos adicionales basado simplemente en la especulación, es decir, en “creer” que el proceso va a necesitar esos cálculos o recursos en un futuro. Naturalmente, eso es una apuesta con sus correspondientes probabilidades, siendo normal y factible que todo ese trabajo que se ha adelantado no sirva para nada, dado que el proceso puede derivar perfectamente en otro cauce de ejecución.

Por poner un ejemplo más mundano, supón que un día ves con tus amigos dos capítulos de una serie, preparáis las bebidas, palomitas y os acopláis en el sofá. Al día siguiente hacéis lo mismo, al otro también y como supones que eso va a ocurrir al siguiente del siguiente (porque a la serie le quedan dos capítulos para que termine), preparas el refrigerio y acomodas el salón antes de que tus amigos aparezcan, pero llega el momento y tus amigos no llegan. ¿Qué haces? Te comes el refrigerio tu sólo porque no ha servido para lo que pensabas. Has adelantado trabajo “especulando” qué podría ocurrir.

Las víctimas de “Arquitectura de Computadores I, II y III”, saben que diseñar microprocesadores de cierta complejidad es una tarea destinada a unos pocos seres humanos con cierto volumen craneal, necesario para evitar la expansión cerebral que produce el calentamiento inherente al diseño de estos ingenios. Y como con todo lo que conlleva la palabra humano: nada es perfecto. Así que cuando diseñaron la forma en la que se traducen direcciones de la memoria virtual de un proceso de usuario a memoria física (o real), incluyeron también la posibilidad de mapear la memoria del kernel y de paso, la de otros procesos. ¿Qué podría salir mal?

Ojo, que esto no significa que a las bravas puedas leerlo. No, no, no. De ningún modo. Un proceso de usuario no puede venirse arriba y decir: “Venga, voy a aprovechar que tengo pendiente una lectura de disco y me voy a guardar cuatro páginas enteras de memoria del kernel y de paso un par del proceso bash del vecino”. Para ello existe un mecanismo que comprueba si dicho proceso posee derechos de acceso a esas partes de la memoria. Una especie de aduana digital donde se comprueba la mercancía que se está intentando llevar un proceso. “Oiga, pollo, pare, pare. ¿De donde ha sacado usted esos 256 bytes con pinta de clave RSA privada. ¿Ah, que es de un amigo? ¡Claro!, como no. Venga por aquí.”

Vale, vale, pero ¿Cómo se explota?

Bien, hemos comentado a muy alto nivel que todo esto se basa en adelantar trabajo, ya sea ejecutando de antemano saltos en el código que podrían o no ejecutarse (predicción de saltos), procesar conjuntos de instrucciones que se pueden ejecutar de forma independiente al conjunto en ejecución actual (ejecución fuera de orden), etc. Y por otro lado, hemos dicho que en la memoria de un proceso, por diseño, se mapean las direcciones de la memoria del kernel y otros procesos (debido a que se está traduciendo memoria virtual a física y viceversa).

Pues el problema principal de seguridad es que cuando se está produciendo la ejecución especulativa, no se están revisando los privilegios de un proceso respecto a esa zona de memoria. Se dejan para después, cuando se hace efectiva la ejecución adelantada. Mientras tanto, los datos de esas zonas de memoria a las que no se debería acceder, permanecen en la memoria caché, donde mediante la aplicación de ciertas técnicas, pueden ser leídas. Esto es en lo que, de forma general, se basan este tipo de vulnerabilidad.

Foreshadow y Foreshadow-NG

Foreshadow fue descubierta por un grupo de investigadores procedentes de varias universidades y centros de investigación. Pertenece a la familia de fallos sobre los que ya hemos hablado, ataques sobre la ejecución especulativa. En particular, este ataque se centra sobre una característica en particular SGX (Software Guard Extensions). Esta tecnología permite a un proceso de usuario proteger una zona de memoria incluso del acceso por parte de procesos más privilegiados.

Por poner un ejemplo, supongamos que mapeamos 16 kilobytes de memoria y la protegemos mediante SGX, pues se supone que ni siquiera un proceso root podría tener acceso a ese fragmento de datos. Esto permite un nivel de protección muy útil cuando queremos proteger datos de importancia sin recurrir a cifrado.

El grupo que descubrió el fallo reportó los detalles a Intel para que contrastaran los hallazgos. Pues además de confirmar el fallo, el propio equipo de Intel ha descubierto una nueva forma de ataque que han denominado “L1 Terminal Fault” y que posibilitaría la lectura completa de la caché L1.

La caché L1 es la más cercana al procesador (existe una jerarquía de memorias caché, clasificadas según la “cercanía” al procesador), lo que significa que posee poca capacidad relativa de memoria pero una alta velocidad en la recuperación de datos e instrucciones. Esto se traduce en una memoria muy viva, con datos de procesos que están siendo ejecutados en ese momento y por supuesto, muy relacionada con la ejecución especulativa de estos últimos. Razón por la cual, con los elementos que ya hemos explicado, la hace objeto de la tormenta perfecta.

Consecuencias. Es posible leer la caché L1, pieza útil en mecanismos como el ya descrito SGX, memoria del kernel y máquinas virtuales, además de memoria del modo SMM (System Management Mode) que regula funciones de muy bajo nivel relacionadas con el hardware subyacente, por ejemplo, la gestión de energía, etc. Como apuntan en el estudio, esto tiene importantes consecuencias en la nube, donde el uso de la virtualización forma la espina dorsal del paradigma.

Intel ha actualizado el microcódigo de los procesadores afectados, aunque señala que habrá que actualizar sistemas operativos y las soluciones de virtualización para impedir la explotación del fallo. Tanto Microsoft como el kernel Linux han aportado ya una solución para la causa en la parte que les toca.

Se han asignado los siguientes CVEs para las distintas variedades del ataque:

– CVE-2018-3615 para el ataque sobre SGX
– CVE-2018-3620 para la memoria del kernel y SMM
– CVE-2018-3646 para el que afecta a máquinas virtuales

Podéis encontrar una amplia lista de procesadores afectados en esta página.

Bonus track:

Foreshadow es una palabra inglesa que hace mención a una figura o recurso literario que anticipa al lector unos hechos que han de producirse, pero de una forma tan sutil que impide que este se haga una idea directa y clara de ese futuro. En español se denominaría: presagio.

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 defacebook.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 yno 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 (aGoogle 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

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.

Muestras relacionadas

b6829ddc762f8e218e34006ed0892e880d3efcedbbbbb7cc133e3326a9a89512
338fdf3626aa4a48a5972f291aacf3d6172dd920fe16ac4da4dd6c5b999d2f13
591a97d42f895139ceacc4e79cf59ef2cc565f7c3905d872448ff246d7e66cd2
ebba97948a468526820cce002cf0222c91784376c52a1706fef118642b14c726
c99da4b3f96a678dcec9bcb9b06b0e2b7d713e6761a9f43773fcb92722838498

Más información:
 

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:

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 solucionauna 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.


Juan José Ruiz
jruiz @ hispasec.com
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: