55 vulnerabilidades no es mucho para un mes en Microsoft. Eso sí, 6 son críticas. Cuatro se conocían de antes y dos están siendo aprovechadas por atacantes. Estas últimas son problemas en Excel que permiten eludir protecciones pero necesitan que interactúe el usuario.

Y Exchange no se libra. CVE-2021-42321. Un grave fallo que, aunque necesite que el atacante esté autenticado, llega a una gravedad de 8.8.
También se ha solucionado un grave fallo (9.0) en Virtual Machine Bus, que permitiría a un atacante salir de la máquina virtual.

Una de las más interesantes es el fallo en RDP (CVE-2021-38666) que permitiría ejecución de código remoto pero no en el servidor, sino desde el servidor hacia el cliente si este se conecta con un cliente vulnerable. Interesante para crear “honeypots” que al final se vuelvan en contra del supuesto agresor.

Más información: https://msrc.microsoft.com/update-guide/vulnerability/

Hay que afrontar que aunque la máxima sea “no se debe negociar con atacantes de ransomware”, la realidad es muy diferente para compañías cuya alternativa es perderlo todo. Por tanto, si se va a pagar, es necesario al menos tener en cuenta algunos consejos para la negociación. Analistas de Fox-IT, tras observar un conjunto de 700 negociaciones llevadas a cabo entre 2019 y 2020, han diseccionado algunas respuestas y consejos.

Hay que entender que la cuenta atrás empieza cuando se pulsa en el enlace para chatear con el atacante. Así, previamente hay que tener muy clara la estrategia. Localizar la zona cero, la comunicación y cuánto es posible pagar. El atacante al otro lado sabe perfectamente cuánto se puede permitir pagar la víctima, pero siempre están dispuestos a rebajar algo si el atacado sabe conseguirlo.

También es importante cambiar a un chat privado, tanto para las comunicaciones con el atacante como las internas. Tras las muchas filtraciones en los últimos tiempos, es posible que un tercero en la operación tenga acceso a la negociación e interfiera a su en beneficio propio.

Y ante todo, aunque duela, la mejor estrategia es ser profesional con el atacante al otro lado. Pedir siempre más tiempo, porque funciona, para negociar, controlar la situación y evaluar daños. Conocer bien el alcance del ataque y al propio atacante es la mayor ventaja para poder negociar el rescate con algún arma por parte del atacado.

Más información:
https://research.nccgroup.com/2021/11/12/we-wait-because-we-know-you-inside-the-ransomware-negotiation-economics/

En noviembre, Microsoft arregló una elevación de privilegios en el instalador. CVE-2021-41379. Pero lo ha hecho mal. El propio descubridor ha publicado un exploit capaz de eludir el parche y volver a elevar privilegios gracias a un fallo en el sistema de instalación de MSIs. Y funciona mejor que el anterior, incluso. Ahora mismo no hay parche y no es fácil pensar en una contramedida, como indica el propio autor.

La prueba de concepto sobrescribe los permisos de el servicio de elevación de Edge (porque Edge se ejecuta con muy pocos privilegios, pero para ciertas operaciones debe elevar). Una vez sobrescrito copia ahí un programa y consigue lanzarse ejecutado.

Aparte de la gravedad, destaca otra pregunta interesante que le hizo BleepingComputer. ¿Por qué el descubridor reporta el fallo anterior de forma responsable y en este caso lanza el exploit sin previo aviso? Desde abril de 2020, los investigadores consideran que la política de Microsoft con respecto a los bug bounty es muy deficiente y deja mucho que desear. Pagan menos cada vez.

Más información: https://github.com/klinix5/InstallerFileTakeOver

Desde Telefónica Cyber Security and Cloud Tech hemos creado un bot de Telegram que permite poner a prueba tus conocimientos sobre el mundo de la ciberseguridad y el cloud. Compite con el resto de usuarios por ser el primero en el ranking.

Comienza haciendo /start en este enlace. 20 preguntas. 15 segundos para responder. 4 intentos cada 4 horas.

Más información: https://t.me/tcct_quiz_bot

Aunque ya se conocían fórmulas para descargar inadvertidamente ficheros a través de las plantillas de Office alojadas en remoto, ahora los ciertos atacantes sofisticados están usando… plantillas en ficheros RTF abiertos con Word. RTF es un formato en texto plano con una serie de etiquetas. Los atacantes se han dado cuenta de que añadiendo en la etiqueta \template una URL (incluso ofuscada) en vez de un archivo interno y renombrando el fichero a rtf.doc (para que sea abierto por Word en vez de Wordpad) se descarga el recurso en el destino. Importante destacar que no se ejecuta, sino que se solo se descarga algo en el sistema. También que es posible que aparezca un diálogo advirtiendo de que se está descargando.

Aun así, es una técnica importante porque permite que el fichero RTF modificado llegue con más facilidad al correo del destinatario puesto que es una técnica poco detectada. Una vez ahí, al abrirlo permite al atacante descargar otro fichero en el sistema objetivo de forma directa. En cierta forma es una vuelta de tuerca al viejo sistema conocido en el que se embebían recursos ejecutables dentro de un RTF que se distribuía por correo.

Más información: https://www.proofpoint.com/us/blog/threat-insight/injection-new-black-novel-rtf-template-inject-technique-poised-widespread

Si bien Firefox ha sido tradicionalmente más lento a la hora de incluir mejoras de seguridad en su código, se posiciona a la vanguardia en esta ocasión añadiendo RLBox, una sandbox para librerías de terceros. Firefox (y muchos otros antes) ya ejecuta en su propia sandbox el contenido de cada web y cada web a su vez en su propio proceso. Pero todavía hay un problema con el uso de librerías de terceros por parte del motor de renderizado de esa web dentro de ese proceso. Imaginemos que un fallo en la librería de proceso de vídeo, audio, fuentes, etc. permite la ejecución de código. Aprovechando el fallo, el atacante podría, sin salir de ese proceso sandboxeado por página, tener el control de esa página. Suficientemente peligroso si por ejemplo hablamos de una web de correo, o de almacenamiento en la nube.

RLBox lo que permite es precisamente crear una sandbox ligera, dentro del motor de renderizado, que aísla y comprueba las llamadas a librerías de terceros. Una mejora adicional al hecho de que el motor de renderizado de cada web esté ya de por sí dentro de un proceso ya aislado. Lo consigue llamando a las librerías y las funciones en un espacio de memoria separado y comprobado las entradas y las salidas.

Para conseguirlo se utiliza el estándar WebAssembly (código y compilado que se llama con JavaScript) para “normalizar” las funciones de la librería y una API de llamada a RLBox, que aísla las llamadas y realiza las comprobaciones de los resultados devueltos.
Por ahora lo han hecho con las librerías Graphite, Hunspell, y Ogg en

Firefox 95. Expat y Woff2 llegará en Firefox 96. RLBox puede ser usado en otros navegadores.

Más información: https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/

Novedades recientes e importantes sobre el fallo en Log4j. Se aprovecha una validación de entrada incorrecta al procesar solicitudes LDAP en variables de entorno que podría permitir la ejecución remota de código. Se publicó el parche 2.15.0 para mitigar el problema, bajo el CVE-2021-44228.

Pero no es suficiente. Se ha publicado otro CVE, CVE-2021-45046 para solucionar un problema que todavía persiste y que ha sido corregido en 2.16.0 eliminando fundamentalmente la clase JndiLookup.

También se está alertando de que el hecho de mantener versiones de Java más o menos recientes no elimina la vulnerabilidad. Por tanto, independientemente de la versión del entorno Java del que se disponga, es importante actualizar la librería Log4j en sí hasta la última versión e incluso aplicar medidas adicionales.

Más información: https://thehackernews.com/2021/12/second-log4j-vulnerability-cve-2021.html

La seguridad en los navegadores ha mejorado mucho en los últimos años, pero las decenas de 0days encontrados en Chrome en los últimos tiempos, están haciendo reaccionar a la industria. Chrome ha anunciado que implementará una especificación de la W3C llamada private network access (PNA) que protegerá de que los atacantes accedan a recursos internos como routers o servidores a través de CSRF en el navegador.

Por su lado, Edge ha ido un poco más allá. Implementará un modo de navegación específicamente diseñado para mejorar la seguridad contra vulnerabilidades no conocidas (0days). Para ello, pone en marcha una serie de cambios en el registro que, activados, permitirán forzar esta seguridad y permitir excepciones. Son EnhanceSecurityMode, EnhanceSecurityModeBypassListDomains y EnhanceSecurityModeEnforceListDomains
Esto permitirá activar en el navegador tres mitigaciones contra exploits genéricos:

* Hardware-enforced Stack Protection: Que permite protección a nivel procesador (que soporte tecnología Shadow stack en AMD y llamada CET en Intel) contra ataques típicos de desbordamiento de pila.
* Arbitrary Code Guard (ACG), Si bien gracias a la tecnología CIG de Windows, un proceso no puede cargar binarios no firmados, ACG evita esto mismo con código mapeado ya en memoria.
* Content Flow Guard (CFG). Una tecnología fallida (Microsoft tuvo que dejar de pagar recompensas para quien la eludiera) para intentar evitar de nuevo exploits funcionales.

Más información:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-relnote-beta-channel#version-980110823-january-14

Las macros en Excel del tipo 4.0 (también llamadas XLM) permitían insertar instrucciones de programación directamente en las celdas. Las otras, las macros “normales” estaban creadas en código VBA y se compilaban y guardaban en binario en el Excel sin poder verse. Cuando los atacantes redescubrieron este estándar 4.0 de 1993, consiguieron eludir todas las restricciones hasta el momento. Y lo han estado haciendo desde hace unos 5 años hasta ahora, que Microsoft las ha deshabilitado por defecto.

Este es el último paso contra este tipo de macros. El primero fue en julio de 2021 cuando se introdujo este tipo de macros en el flujo de AMSI, esto es, su ejecución al vuelo se analizaría por un antivirus.

Paralelamente se añadió una opción en Excel para que se pudiera habilitar las macros 4.0 y que se comportasen con la misma configuración que las VBA normales. Este botón se puso con la intención inmediata (antes de final de 2021, se dijo) de deshabilitarlas por defecto y tener que habilitarlas con esa opción.

Ahora en enero se deshabilitan por fin por defecto y quien las necesite (pocos las echarán de menos, solo los atacantes) podrá habilitarlas desde esta opción.

Más información: https://techcommunity.microsoft.com/t5/excel-blog/excel-4-0-xlm-macros-now-restricted-by-default-for-customer/ba-p/3057905

12 años. Ese es el tiempo que ha permanecido oculta una vulnerabilidad en PolKit (antes Policykit), un sistema para la gestión de permisos ampliamente usado por las distribuciones Linux más populares. El fallo está en el componente ‘pkexec’, que permite una funcionalidad similar a ‘sudo’, es decir, ejecutar un comando con los privilegios de otra cuenta o usuario. Por lo tanto, al explotarlo, permitiría la elevación de privilegios a root, dado que ‘pkexec’ es un binario SUID root.

Además de estar presente en casi todas las distribuciones Linux, la explotación es trivial. Basta, a grosso modo, con manipular únicamente las variables de entorno para llevarla a cabo. Es decir, no se trata de un exploit al uso, en el que se tiene que evadir protecciones y poseer un contexto de ejecución favorable, sino que prácticamente el éxito de la explotación está asegurado. De hecho, para esta vulnerabilidad (con CVE-2021-4043) están apareciendo gran cantidad de exploits.

Curiosamente, la base del fallo fue descrita en 2013 en un post de un investigador australiano, Ryan Mallon, que ya advirtió que inyectando un puntero nulo en el array de argumentos a un programa podría tener consecuencias desastrosas. Aunque no pudo en ese momento identificar un vector sobre el que aplicar su hallazgo. Finalmente se ha materializado en esta elevación de privilegios, recordemos, trivial de explotar.

Más información: https://github.com/berdav/CVE-2021-4034/blob/main/cve-2021-4034.c

Solo 70 vulnerabilidades corregidas este martes por Microsoft. Curiosamente, ninguna crítica, aunque sí una pública sin exploit. La más grave (que no crítica, hay varias que supuestamente permiten ejecución de código) está en Sharepoint, con un CVSS de 8.8. Parece fácil de explotar aunque necesita de algunos permisos por parte del atacante (que no son tan difíciles de conseguir). Otro fallo con gravedad 8.8 en el servidor DNS parece menos probable de explotar.

El fallo que ya se conocía es una elevación de privilegios compleja de explotar.

Y la cola de impresión sigue en el ojo del huracán. Cuatro fallos corregidos, catalogados como importantes (permitirían la elevación), han sido corregidos. Parece que Microsoft está auditando bien este código desde el fiasco de printNightmare en julio de 2021.

Más información: https://msrc.microsoft.com/update-guide/vulnerability/

¿Crees que el ransomware se detiene solo cuando se cifra la información y se pide el pago? Vamos por varias generaciones de grupos de extorsión que se dedican exclusivamente al ransomware de compañías, y tanto el éxito como la oportunidad de mercado les empujan a la innovación en sus métodos. En realidad, nos encontramos ante unos intentos de extorsión múltiples que cubren todos los flancos para garantizar el éxito de los atacantes y dejar sin opciones a la víctima.

La primera extorsión es obviamente entrar en la empresa y cifrar información importante. Si no se paga, no se descifra y la compañía no puede continuar su operativa. Hace algunos años se introdujo una vuelta de tuerca: no solo cifran la información sino que además la roban, y cuanto más se tarde en pagar, más información de la empresa harán pública. Esto se intentó como método de presión falso con los usuarios domésticos años antes, pero no era cierto. El ransomware no robaba información al usuario medio. El modelo no escalaba. Si embargo con las grandes compañías ha funcionado bien porque sí que extraen y almacenan los datos.

La tercera extorsión además de las anteriores, es meter presión ejecutando ataques de denegación de servicio hacia las páginas públicas de la empresa atacada. Las hacen desaparecer de internet. La cuarta que se ha observado sería el acoso. Los atacantes, perfectamente organizados, contactan con proveedores, partners, clientes e incluso medios de comunicación para alertarles sobre el ataque y arruinar su reputación.

Pero además existe una quinta. LockBit desde hace algún tiempo invita a los atacados a ofrecer datos de terceros que les ayuden a entrar en su red (credenciales VPN, RDP…). Esto podría servir para que les “rebajara” el pago del rescate. Condenar a un tercero para aliviar la propia condena. Perverso pero, al parecer, efectivo.

Más información: https://www.linkedin.com/pulse/lockbit-introduce-un-nuevo-elemento-en-el-negocio-del-abraham-pasamar/

Microsoft ha corregido 71 vulnerabilidades este mes, un número relativamente pequeño para lo que nos tiene acostumbrados. Lo importante es que:

* Tres de ellas son críticas. Una en Exchange (CVE-2022-23277) y dos más en el tratamiento de extensiones de vídeo.

* Otra relevante previamente conocida se encuentra en el en cliente de RDP. Al conectarse a un potencial servicios malicioso, podría conseguir ejecutar código en el cliente vulnerable. El cliente RDP este mes tiene en total tres parches.

* Las otras dos conocidas previamente se encuentran en el servicio de Fax y en .NET y Visual Studio.

También se han corregido 41 fallos en Chromium, que ahora es el core de Edge. información: https://msrc.microsoft.com/update-guide/vulnerability/

Se están acumulando las vulnerabilidades de elevación en el Kernel Linux. Por un lado tenemos CVE-2022-0847, “Dirty Pipe”, que lleva ahí desde 2020 y es trivial de explotar (y aun así, se necesitaron meses para depurar el fallo y comprender la vulnerabilidad). Por otro, CVE-2022-0492 y CVE-2021-4034 que también permiten elevar.

En el caso de Dirty Pipe, Max Kellermann necesitó meses para entender por qué a un cliente de una distro se le corrompían ficheros. Después de mucho investigar entendió cómo convertir un error en una elevación. Primero escribiendo desde una cuenta no privilegiada una clave en el fichero de claves SSH… de root.

Así luego podía conectarse como tal por SSH. Al hacerlo público, otros tantos investigadores descubrieron cómo aprovecharla en ficheros con SetUID, escribir en ficheros read-only, crear tareas… etc.

El fallo está en la función splice que permite mover datos entre ficheros. En el momento en el que la información está en un búfer en memoria, se pueden escribir libremente datos. Está corregido en 5.16.11, 5.15.25 y 5.10.102 y también afecta a Android.

Por otro lado, en enero se descubrió un fallo en polkit que se llamó, PwnKit (CVE-2021-4034), otra elevación que estuvo ahí 12 años. La elevación más reciente es un fallo en «cgroups» CVE-2022-0492. Cgroups permite controlar los recursos de un grupo de procesos. En principio se trata de tocar el fichero release_agent para que ejecute tras la terminación de unos procesos como root. Ese fichero solo puede ser tocado como root, pero en entornos con contenedores, ser root no significa tener todo el control, por tanto en realidad este fallo permitiría controlar un conjunto de contenedores dado el caso y escapar de ellos.

Más información: https://arstechnica.com/information-technology/2022/03/linux-has-been-bitten-by-its-most-high-severity-vulnerability-in-years/

No es ningún secreto que desde hace unos tres años, Chrome sufre de muchos más fallos graves descubiertos mientras son aprovechados por atacantes. O sea, 0-days. Tanto es así que en Google han escrito una entrada explicando por qué. La respuesta rápida es una mezcla de muchos motivos que no llevan a ninguna sorpresa.

Primero alegan que no es que antes no ocurrieran, sino que se veían menos. O sea, hay más transparencia por parte de Chrome. El segundo argumento (aunque parece no complementar bien con el anterior) es que Chrome es ahora más popular y otras vías de explotación (como Flash) ya no les funcionan a los atacantes.

Otro argumento: antes bastaba un fallo para comprometer el navegador, ahora al menos dos: uno para ejecutar código y otro para salir de la sandbox. Esto engorda el número. Aunque lo cierto es que el aumento de 0-days en Chrome se experimenta desde 2019, y la sandbox de Chrome lleva desde 2015.

Por último, la mayor complejidad del navegador, y la inevitabilidad de los errores, hacen que el número haya crecido. Para contrarrestar esto, Chrome sigue mejorando su eficaz sandbox. Ahora con dos proyectos para eliminar los user-after-free (MiraclePtr y *Scan), escribiendo en lenguajes que mejoren el manejo de memoria y la seguridad, y aprovechando mejoras en combinación con el sistema operativo.

La realidad es que la cantidad de vulnerabilidades encontradas en Chrome aumenta, y los atacantes la aprovechan. Aunque sean cada vez más difíciles de explotar. Esto implica que los atacantes no escatiman recursos para conseguir su objetivo.

Más información: https://security.googleblog.com/2022/03/whats-up-with-in-wild-exploits-plus.html

La botnet Muhstik ha encontrado un nuevo impulso gracias a un fallo en la base de datos Redis bajo Debían y Ubuntu (aunque podría darse en más plataformas), que permite ejecutar código LUA en ella escapando de la sandbox. El fallo, que se encontró a principios de marzo, se une así al arsenal de vulnerabilidades que utiliza la botnet para propagarse desde 2018. Seis en total aprovechando problemas en Oracle WebLogic, Drupal, Confluence… Muhstik se encarga de, entre otras actividades realizar ataques de denegación de servicio distribuido.

Algunas curiosidades es que esta botnet utiliza IRC para comunicarse con su command and control y que el descubridor del fallo en Redis advirtió a Ubuntu del problema esperando que a su vez avisaran a Debian. Pero no fue así y tuvo que notificar por separado del problema.

Más información:
https://blogs.juniper.net/en-us/security/muhstik-gang-targets-redis-servers

0days, 0days everywhere. Recordando siempre su definición real: vulnerabilidades encontradas mientras son aprovechadas por atacantes (y no fallos recién descubiertos por investigadores). En este caso es Apple quien corrige CVE-2022-22675 en iOS y MacOS y CVE-2022-22674 solo en MacOS. La primera en AppleAVD, y la segunda en el driver gráfico de Intel.

Como es costumbre, Apple no ha dado ningún detalle. Los 0days están más activos que nunca. Si Apple corrigió 12 en 2021, en estos primeros tres meses de 2022 lleva ya 5. Y no solo Apple. Chromium (y por tanto Edge, Chrome y Opera) se han visto afectados desde hace tiempo por una insistente campaña de ataques que están poniendo a prueba su seguridad. Ahora que el motor está en dos de los navegadores más usados, la rentabilidad de cada fallo se multiplica. Y aunque con menor frecuencia Firefox tampoco se libra. En marzo se descubrieron dos 0days (CVE-2022-26485 y CVE-2022-26486).

¿Volvemos a la época en la que el navegador vuelve a ser el principal vector de ataque ahora que se está atajando la vía del correo?

Más información: https://threatpost.com/apple-rushes-out-patches-0-days-macos-ios/179222/

La nueva versión de la PCI DSS, de obligado cumplimiento para todas las pasarelas de pago, contempla medidas muy concretas contra el tipo de ataque Magecart. Se trata de grupos operando para perpetrar “skimming virtual” inyectando JavaScript en la página de la víctima y redirigir los datos de la tarjeta de crédito a sus propios servidores a la hora de realizar el pago.

En el punto 6.4.3 de la famosa normativa, se contemplan tres requerimientos. A) Implementar un método que confirme que cada script en la web está autorizado. B) Garantizar la integridad de los scripts. C) Un inventario de justificación de cada script para saber por qué es necesario.

Aunque no se menciona explícitamente, esta normativa está claramente orientada contra los métodos de ataque usados por Magecart y, de nuevo, aunque no se mencione, las recomendaciones mapean perfectamente sobre dos tecnologías ya existentes. El primer punto se satisface con las Content Security Policy correctas (de dónde están autorizados a cargar los scripts). El segundo, a través de Subresource Integrity (se define en la etiqueta script el hash del script que se carga y esto garantiza que no cambia).

La tercera parece meramente burocrática e implica identificar para qué es necesario, en la web de pago, que se carguen otros scripts no imprescindibles. Como indica Scott Helme, esta medida podría haber detenido el famoso ataque de Magecart a TicketMaster, puesto que en ese caso se atacó a Inbenta, que proporcionaba scripts de chatbot en la página de pago de Ticketmaster. Chatear con un bot en el momento de pago no es esencial y bajo la nueva PCI DSS se podría haber planteado eliminar preventivamente de la web de pago esos scripts que fueron finalmente atacados.

Más información: https://scotthelme.co.uk/pci-dss-4-0-its-time-to-get-serious-on-magecart/

El malware de Android sigue su evolución, ahora innovando con algo aparentemente superado en el escritorio: los troyanos bancarios. Desde el legendario Marcher se evolucionó a Exobot en 2016, de ahí a ExobotCompact. Ahora con nuevas funcionalidades, esta familia parece llamarse Octo. La capacidad más llamativa (entre las clásicas para robar todo lo posible) es la de acceder al smartphone directamente a través de una especie de VNC y por tanto, realizar el fraude sobre el propio dispositivo, controlándolo casi en tiempo real.

Esto aporta enormes ventajas para el atacante. Virtualmente actúa como el usuario, levantando menos sospechas ante el banco, como hacían los tradicionales troyanos bancarios de Windows que a mediados de los 2000, irrumpieron inyectándose en los navegadores.

Para conseguir ese acceso en tiempo real, se basan en la funcionalidad nativa de Android MediaProjection (para proyectar en pantallas) y AccessibilityService (para la accesibilidad, algo que ya es abusado abiertamente por los atacantes). El atacante envía el comando start_vnc al sistema y consigue proyectar la pantalla del dispositivo en el command and control. A continuación pone una pantalla en negro en el sistema para no ser descubierto, quita notificaciones y el brillo a cero.

Con toda la información recogida y la proyección, puede enviar comandos como “click_at”, “paste”, “long_click”, “set_text”… mientras controla a un ratio de 1 frame por segundo en el command and control, el efecto de sus actos. Los descubridores apuntan a que esta puede ser la versión manual. Porque con este nivel de control en realidad podrían simplemente automatizar un envío de comandos en lote a través de un archivo que ejecutar. Así el ataque ganaría en escalabilidad.

Por supuesto, han colado en Google Play aplicaciones maliciosas que servían de dropper para este malware.

Más información: https://threatfabric.com/blogs/octo-new-odf-banking-trojan.html