Entre Bits y Valores: El Debate Ético en Torno al Cifrado de Extremo a Extremo

 ¿Qué es el cifrado extremo a extremo y por qué es importante?

A lo largo de la última década, la seguridad de la información ha ido cobrando mayor importancia y concienciación, donde uno de los aspectos de la seguridad ha sido conversar de manera privada evolucionando los sistemas arcaicos de trasmisión de información en claro por sofisticados mecanismos de cifrado extremo a extremo. 

El cifrado de extremo a extremo (E2EE – End to End Ecryption) es un mecanismo de seguridad informática que permite garantizar la confidencialidad y la integridad de los datos en una comunicación entre dos partes a través de un canal potencialmente inseguro. Consiste en cifrar los datos en el extremo origen y descifrarlos en el destino (cliente-cliente) sin que esto se haga en el servidor del proveedor de servicios, asegurando que un tercero no logre interceptar los datos en claro sin la clave de descifrado pertinente. El par de claves asimétrico [1], se genera entre el remitente y el destinatario, lo que implica que sólo estas dos partes tienen acceso a las claves necesarias para descifrar los datos. Por tanto, la pérdida del par de claves impediría el acceso a los mensajes trasmitidos. 

Un ejemplo práctico se encuentra en aplicaciones de mensajería instantánea como Signal, proyecto de código abierto haciendo uso de cifrado robusto Extended Triple Diffie-Hellman [2] o Post-Quantum Extended Diffie-Hellman [3] a prueba de ordenadores cuánticos. En ésta se garantiza la privacidad desde el punto de vista tecnológico cuyo único dato vinculado es el número de teléfono. Aunque pueda parecer una aplicación ideal desde el punto de vista de la privacidad, la principal desventaja que presenta es su uso poco extendido. Otras aplicaciones muy conocidas como WhatsApp también se basan en el mismo esquema [4], donde la privacidad de las conversaciones se mantiene intacta (siempre y cuando no hayas sido reportado por un usuario [5]). Por contra, la gran cantidad de otros datos y metadatos del usuario no cifrados y recopilados en sus servidores podría poner en peligro la privacidad [6]. 

Otra arquitectura opuesta al cifrado extremo a extremo es el cifrado de datos en tránsito, que consiste cifrar el mensaje en el extremo emisor, descifrarlo en el servidor, volver a cifrarlo en éste y descifrarlo finalmente en el extremo receptor (cliente-servidor-cliente). Al igual que el anterior, protege la información durante su transmisión, pero permite que el servidor intermediario pueda hacer uso de los mensajes transmitidos [7].

Un ejemplo de esta arquitectura es el aplicativo Telegram, donde los mensajes privados utilizan la nube para alojar y procesar los datos transmitidos. No obstante, el aplicativo también ofrece la opción de cifrar extremo a extremo la comunicación mediante los ‘mensajes secretos’ [8]. 

Como se puede observar, las tecnologías en la privacidad son muy sofisticadas, donde a pesar de la arquitectura o los cifrados empleados, existen factores no tecnológicos como las condiciones y la gestión ofrecidas por las proveedoras de servicios que pueden influir de manera indirecta en la privacidad del usuario. 

Teniendo en cuenta el auge del cifrado E2EE no sólo en el ámbito de la mensajería instantánea con funciones básicas muy comunes entre ellas, sino también en el correo electrónico, videoconferencia u otros, existe un punto de inflexión donde los usuarios con intenciones fraudulentas podrían aprovechar las ventajas de la tecnología para transmitir contenido ilegal sin ser detectado. Tanto es así, que las instituciones gubernamentales podrían implementar restricciones en el uso de los protocolos extremo a extremo [9]  al verse entorpecidos en el control masivo de contenido ilícito mediante palabras clave u otros métodos, tal y cómo ocurrió en 1993 con Phil Zimmermann [10] bajo investigación por el haber publicado PGP (Pretty Good Privacy). Una posible medida podría consistir en obligar a las empresas tecnológicas a implementar mecanismos de control o escaneos de contenido en cada extremo antes del cifrado y su emisión al receptor, dejando la característica principal del protocolo inutilizado. 

Por recapitular, independientemente del dilema moral hasta dónde se debe permitir el acceso de las autoridades a nuestra privacidad, se recomienda el uso de aplicaciones que recojan el menor número de datos posibles, a ser posible de código abierto y no controlados por una compañía gigante conocida por sus fines comerciales. Adicionalmente se recomienda proteger el extremo más débil,  el terminal, no sólo a nivel de aplicativos con posible malware incrustado, vulnerabilidades explotables o backdoors, sino también mediante la protección de una contraseña robusta o el empleo de doble factor de verificación. 

¿Qué opinas sobre prohibir el uso de cifrados de extremo a extremo? 

¿Y sobre el uso de estos protocolos?

¿Está reñida la privacidad la finalidad de la comunicación?

Referencias

[1] J. Ramió Aguirre, «Class4crypt c4c10.4 Algoritmo RSA,» [En línea]. Available: https://youtu.be/w5dWeZwfK8w?si=70Arkine_WmHy3jX

[2] Wikipedia, [En línea]. Available: https://en.wikipedia.org/wiki/Post-Quantum_Extended_Diffie-Hellman

[3] Web. [En línea]. Available: https://en.wikipedia.org/wiki/Post-Quantum_Extended_Diffie-Hellman

[4] WhatsApp, [En línea]. Available: https://faq.whatsapp.com/820124435853543/?locale=es_LA

[5] WhatsApp, [En línea]. Available: https://faq.whatsapp.com/414631957536067/?helpref=hc_fnav

[6] Xataka, «Signal vs Telegram vs WhatsApp: cuáles son las diferencias y cuál cuida más tu privacidad,» [En línea]. Available: https://www.xataka.com/basics/signal-vs-telegram-vs-whatsapp-cuales-diferencias-cual-cuida-tu-privacidad

[7] «¿Qué es el cifrado de extremo a extremo y por qué lo necesitas?,» [En línea]. Available: https://www.kaspersky.es/blog/what-is-end-to-end-encryption/23862/

[8] Telegram, [En línea]. Available: https://core.telegram.org/api/end-to-end

[9] «Leaked Government Document Shows Spain Wants to Ban End-to-End Encryption,» [En línea]. Available: https://www.wired.com/story/europe-break-encryption-leaked-document-csa-law/

[10] «The Critical Hole at the Heart of Our Cell Phone Networks,» [En línea]. Available: https://www.wired.com/2016/04/the-critical-hole-at-the-heart-of-cell-phone-infrastructure/

Arturo Fernández,  Analista de Ciberseguridad en Zerolynx.

Auditoría básica de ciberseguridad a un dominio de Microsoft

El Directorio Activo (Active Directory) es un componente crítico en la infraestructura de muchas organizaciones, utilizado para gestionar recursos y usuarios en entornos Windows. La auditoría de Directorio Activo es esencial para garantizar la seguridad de la red y la integridad de los datos. A continuación, partiendo del compromiso asumido de que un usuario de dominio ha sido vulnerado, exploraremos los principales vectores de ataque que debemos identificar:

1. Escalada de Privilegios Local

Aunque no siempre es necesario, es altamente recomendable partir de permisos de administración en la máquina atacante. De esta manera el uso de herramientas será mucho más cómodo. Para ello se pueden utilizar herramientas como PowerUp, WinPeas o SeatBelt entre otras, para identificar caminos que permitan una escalada a administrador local.

2. Políticas de Contraseñas

Una política de contraseñas débil puede ser útil para realizar ataques de tipo passwordspraying (esto debe realizarse cuidadosamente para no bloquear cuentas) o para el posterior crackeo de hashes identificados. Además, en caso de que no exista política de bloqueo tras intentos fallidos, sería posible hacer fuerza bruta contra todo el dominio sin temor a bloquear las cuentas de usuario.

3. Identificar secretos en carpetas compartidas.

Una vez se dispone de un usuario de dominio, es recomendable enumerar las carpetas compartidas a las que se tiene acceso (por ejemplo, con smbclient). En ocasiones, se pueden identificar documentos que recogen algún tipo de credencial, la cual puede ser válida o servir como punto de partida para adivinar otras contraseñas.

4. Identificación de sistemas operativos obsoletos

Se debe verificar que no se estén utilizando sistemas operativos fuera de soporte y/o desactualizados. Este tipo de equipos pueden ser muy útiles, ya que es altamente probable que tengan vulnerabilidades explotables con exploits públicos. Aunque no se traten de objetivos relevantes, acceder a ellos puede ser interesante para obtener las credenciales que tengan almacenadas. Es muy importante avisar al responsable de IT de que se va a hacer uso de exploits, por si estos pudiesen causar una caída en el servicio de la empresa.

5. Identificación de cuentas privilegiadas

Es muy interesante realizar un proceso inicial de enumeración en el que se identifiquen las cuentas objetivo que permitan comprometer la totalidad del dominio. Durante esta fase de enumeración no solo se buscan las cuentas de Domain admin, si no que también es importante identificar cuentas con permisos especiales que permitan llevar a cabo movimientos en el dominio. En puntos siguientes veremos por qué esto es importante.

6. Identificación y Abuso de cuentas con Constrained Delegation

En un punto anterior se indicaba que era necesario identificar cuentas con permisos elevados, pues este es un tipo concreto de cuenta privilegiada. Estas pueden tener delegado en ellas el poder de impersonar a cualquier usuario del dominio para una serie de servicios determinados. Gracias a esto, si se consigue comprometer una cuenta con constrained delegation, es posible suplantar a cualquier usuario para servicios de Windows como host, RPCSS, http, wsman, cifs, ldap, krbtgt o winrm.

8. Identificación y Abuso de Unconstrained Delegation

Este es otro tipo de cuenta privilegiada de alto interés. Estas cuentas están autorizadas para recibir y almacenar los TGT (Ticket Granting Ticket) de kerberos de cualquier cuenta. Es por ello, que al acceder a ellas sería posible extraer los tickets almacenados en las mismas. Por otro lado, también es posible realizar ataques de autenticación forzada sobre esta máquina, es decir, forzar a cualquier máquina del domino a autenticarse contra la máquina unconstrained comprometida. De esta manera, la nueva víctima (el controlador de dominio, por ejemplo) enviaría una copia de su TGT a la máquina unconstrained, siendo posible su interceptación.

9. Identificar y Abusar Permisos de DCSync

Seguimos con cuentas privilegiadas interesantes. En este caso es necesario identificar cuentas con permisos de DCSync, es decir, cuentas que tengan los permisos DS-Replication-Get-Changes-All y DS-Replication-Get-Changes. Si conseguimos comprometer una credencial con estos permisos, podremos realizar un ataque de DCSync, o lo que es lo mismo, simular que somos un controlador de dominio que quiere sincronizar su base de datos (ntds.dit) con la del controlador de dominio real. De esta manera se obtendrían todos los hashes del dominio, incluyendo los del Domain Admin.

10. Identificar y Abusar Resource-Based Constrained Delegation

Si como atacantes podemos identificar una cuenta con permisos de “GenericWrite” o “GenericAll” sobre “ActiveDirectoryRights”, significará que esta cuenta tiene la capacidad de otorgar permisos de constrained delegation a cualquier cuenta del dominio. Esto quiere decir que, si comprometemos esta cuenta, podremos indicar que cualquier cuenta del dominio pueda pedir TGSs (Ticket Garanting Service) para servicios de cualquier máquina del dominio, incluyendo nuestro objetivo principal: el controlador de dominio.

11. Identificar y Abusar Plantillas de Certificados Vulnerables

Este tipo de ataque se basa en utilizar herramientas como certify o certipy para identificar plantillas de certificados vulnerables en la CA (certificate authority) corporativa. Existen una serie de escenarios vulnerables posibles, que permiten a un atacante solicitar certificados en nombre de otros usuarios, por ejemplo, de un Domain Admin o de cualquier cuenta privilegiada.

12. Identificar Servicios Vulnerables

Es posible que en los directorios activos se encuentren máquinas con servicios diferentes a los propios del directorio activo desplegados (aunque no es una buena práctica), por ejemplo, Jenkins o servicios SQL. Es importante identificar estos servicios para comprobar si son vulnerables, ya que en muchas ocasiones pueden servir como punto de acceso a la máquina en la que se están ejecutando. La situación ideal para un atacante sería identificar un servicio que poder explotar, y que este estuviese siendo ejecutado con un usuario administrador local de la máquina. De esta manera, al conseguir ejecución remota de código mediante el servicio explotable, sería posible comprometer toda la máquina.

13. Kerberoasting

Kerberoasting es un ataque que se basa en la explotación de cuentas de servicio que tienen asociados Service Principal Names (SPNs). Estos SPNs son registros que asocian un servicio o aplicación específica con una cuenta de servicio en el Directorio Activo.

El objetivo de hacer kerberoasting es solicitar tickets de estas cuentas de servicio para, posteriormente, descifrarlos offline y obtener las contraseñas originales. Esto es posible ya que parte del ticket solicitado está cifrado utilizando una clave derivada de la contraseña original.

14. Extracción de Credenciales

Una vez comprometida cualquier máquina, el procedimiento a seguir es extraer de la misma cualquier contraseña almacenada. Para ello se pueden utilizar herramientas como Mimikatz. Estas credenciales pueden ser útiles para realizar movimientos laterales a través del dominio, comprometiendo máquinas en las que los usuarios que se van recolectando sean administradores locales.

Conclusión

Acabamos de ver solo algunas de las técnicas mas utilizadas durante una auditoría, pero los atacantes descubren técnicas nuevas todos los días, cada cual más innovadora. Por ello os invitamos a que investiguéis y descubráis vuestros propios caminos hacia controladores de dominio.

Ignacio Sánchez, Analista de Ciberseguridad en Zerolynx.

Riesgos asociados a la suplantación de organizaciones

El aumento del uso de Internet ha generado consecuencias en la privacidad e intimidad de las personas. Gran cantidad de información personal puede encontrarse indexada en los principales buscadores o visible en perfiles de redes sociales. Además de toda aquella información personal presente en filtraciones de datos como las sufridas a lo largo del tiempo por grandes servicios como Facebook, Twitter, LinkedIn o Badoo entre muchos otros. 

En ocasiones, desde el departamento de Ciberinteligencia necesitamos transmitir a nuestros clientes la repercusión que estos hechos pueden tener sobre sus compañías y empleados, ya que la información expuesta o filtrada es utilizada por los atacantes para suplantar la identidad de personas con capacidad de decisión o con los medios para realizar pagos. La identificación de este tipo de riesgos sirve a nuestros clientes para prevenir o mitigar posibles ataques.

Algunas de las técnicas de suplantación de identidad más utilizadas son:

• Suplantación de dominio o dominio similar (typosquatting): variación del dominio que se pretende suplantar usando caracteres muy similares, agregando o eliminando otros de modo que pase inadvertido para la víctima. Otra variante es el uso de un TLD distinto, pero con el mismo nombre de dominio. Ejemplo: elcorteingles.es o vodafone.org.

Dicha suplantación se puede evitar mediante actividades de vigilancia digital, que permiten identificar estas situaciones en el momento de creación de los dominios.

• Suplantación de páginas web: uso del diseño, logo, imagen de marca de una web lícita para crear una falsa con la que robar credenciales, información de las tarjetas de crédito o realizar fraude vendiendo artículos sin luego enviarlos. 

Este tipo de técnicas son evitables, haciendo uso de herramientas que permitan identificar el clonado de una web.

• Adquisición de cuenta: robo de cuentas de correo debido a la filtración de sus contraseñas. El uso de las contraseñas en diversos servicios (reutilización) así como el uso de la cuenta de correo corporativo fuera del ámbito laboral facilita su robo. Este robo puede conllevar estafas económicas a gran escala utilizando como medio la cuenta robada.

La exfiltración de contraseñas se puede identificar, e incluso mitigar, haciendo uso de técnicas de vigilancia de estas en diferentes sitios donde se publican este tipo de leaks.

• Suplantación de correo electrónico y SMISHING: mediante el envío de malware o falsas notificaciones en las que es necesario introducir la contraseña a la cuenta de correo electrónico se genera el robo de las credenciales de esta para posteriormente acceder y realizar la suplantación. También se puede encontrar en este tipo de suplantación el envío de SMS fraudulentos que engañan al usuario para acceder a una web suplantada y robar información bancaria.

Con el fin de evitar la suplantación del correo electrónico, es altamente recomendable implantar técnicas de verificación, así como técnicas de vigilancia. El SMISHING se puede reducir con algunas de las medidas indicadas anteriormente, aunque nada de esto es realmente efectivo sin una concienciación en materia de ciberseguridad.

• Suplantación como servicio: se ha identificado la venta de conjuntos de contraseñas, números de teléfono, cuentas de correo de recuperación asociadas e información que puede utilizarse para saltar la autentificación multifactor de cuentas concretas, asegurando al atacante el acceso a estas y su robo.

Este tipo de técnicas son muy difíciles de mitigar, aunque es posible reducir este riesgo incluyendo listas negras en nuestro sistema de navegación.

Adicionalmente, es altamente recomendable establecer políticas de seguridad que promuevan el uso adecuado del correo electrónico corporativo (exclusivamente en el ámbito laboral), políticas de seguridad adecuadas que  eviten la reutilización de contraseñas y promuevan su cambio periódico así como  crear procedimientos  para reportar correos electrónicos recibidos de dudosa fiabilidad.

Desde Zerolynx defendemos el establecimiento de medidas de seguridad para evitar estos ataques, pero consideramos que el hecho de, llevar a cabo formaciones y la concienciación de los empleados y clientes puede mejorar la prevención, así como colaborar a que el impacto de estos ataques sea mínimo. Porque, a pesar de que no es posible exigir a los empleados el conocimiento en profundidad de las técnicas mencionadas, sí lo es el ayudarles a adquirir las herramientas necesarias para identificarlos y así evitar la materialización de estas amenazas.

Noelia B., Analista de Inteligencia.

Cómo evadir AMSI haciendo uso de DLL Hijacking

¡Muy buenas a todos! Hoy venimos con una última entrega (de momento) sobre el mundo del AMSI. En esta ocasión, vamos a descubrir cómo podríamos evadir el AMSI haciendo uso de una técnica llamada DLL hijacking. 

Cuando un binario está compilado con enlaces dinámicos, el sistema operativo buscará la DLL específica para cubrir una funcionalidad en tiempo de ejecución. En muchas ocasiones, el enlace a la DLL no se define con el path completo, sino únicamente con el nombre. 

Esto da pie a que Windows, mediante su modo de búsqueda, interprete cual es la DLL que el binario pretendía cargar en ese enlace. El orden de búsqueda es el siguiente:

• El directorio donde se encuentra la aplicación que se está ejecutando

• C:\Windows\System32

• C:\Windows\System

• C:\Windows

• El directorio donde se encuentra

• Todo lo que haya en la variable de entorno %PATH%

Por lo tanto, por culpa de este funcionamiento de Windows, cualquier persona con acceso de escritura en algún lugar del disco podría evadir AMSI. ¿Por qué? Porque si podemos copiar la PowerShell para tenerla en un lugar en el que tengamos permisos de escritura, y creamos un archivo llamado amsi.dll, en el momento que se abra esa PowerShell, cargará esa DLL por tema de preferencia. 

En el siguiente ejemplo podemos ver cómo, teniendo la PowerShell en un sitio como el escritorio, podemos hacer que cargue amsi.dll de ese mismo sitio.

El único requisito para utilizar esta técnica es tener una DLL (creada en C/C++) que tenga las funciones definidas de la misma manera que la DLL real. Es decir, no es necesario que la funcionalidad sea la misma, pero de cara a la PowerShell, la llamada a la función se tiene que dar de la misma forma: con el mismo nombre y los mismos argumentos.

PowerShell de 64 bits se puede encontrar en el siguiente directorio:

• C:\Windows\System32\WindowsPowerShell\v1.0

Mientras que PowerShell de 32 bits se puede encontrar en el siguiente directorio:

• C:\Windows\SysWOW64\WindowsPowerShell\v1.0

Una forma sencilla de realizar esta tarea es mediante el parcheo de la DLL original. En otras palabras, podríamos tomar amsi.dll y cambiar las instrucciones pertinentes para que se pierda la funcionalidad original, y no devuelva nunca que hay malware.

Anteriormente en el post Funciones AMSI  explicamos para qué servía cada función de AMSI.

Sabemos que AmsiScanBuffer devuelve un HRESULT, que es un código que representa si la función se ha ejecutado de forma exitosa o no. Si cambiamos AmsiScanBuffer para que siempre devuelva 0x80070057, AMSI dejará de funcionar y lo habremos evadido.

La siguiente imagen es una parte de la función AmsiScanBuffer. 

El primer if hace una serie de validaciones básicas y si las cumple, significa que los argumentos se han proporcionado de forma inválida y no se podrá realizar el escaneo, por lo que setea uVar2 a 0x80070057. 

Pero ¿Qué pasaría si dentro del else también se setea uVar2 a 0x80070057? La respuesta es que AMSI dejaría de funcionar correctamente, porque, a pesar de que AMSI se comunique con Windows Defender para enviar el buffer, si la función devuelve INVALIDARG, el comando se ejecutará de forma normal.

En ensamblador, para devolver un valor en un return, debemos cargar el contenido en un registro de retorno, por lo tanto, para devolver INVALIDARG, podríamos añadir lo siguiente:

• MOV        EAX,0x80070057

Si utilizas ghidra, seleccionando en la parte del decompile, la parte que nos interesa, podemos ver dónde se encuentra su ensamblador correspondiente. Para parchear esta función y que siempre devuelva INVALIDARG, podemos cambiar el último call.

Por lo tanto, la función quedaría como la siguiente:

Por último, quedaría exportar la DLL como PE y ya estaría.

Y con esto nos despedimos de AMSI por el momento. Si os habéis quedado con ganas de más, ¡escribidnos!

Justo Martín, Security Analyst at Zerolynx.