30 sept 2020

[PoC] Cifrado AES256 mediante audio: La Teoría

Todo empezó con una idea que llevaba tiempo rondándome la cabeza. En mi vida tengo dos pasiones. Una es la seguridad, y la otra la música, así que muchas veces me apetece investigar sobre cosas en las que ambas cohesionen.

La idea inicial fue "Necesito crear alguna herramienta relacionada con passwords musicales". Cuando te planteas realizar este tipo de proyecto ya sabes que vas a trabajar con frecuencias, y eso significa que probablemente el planteamiento matemático no es trivial. Así que para entender todo lo que va a explicarse a continuación, os recomiendo echarle un vistazo al post Teleco in a nutshell v3.0: Señales y espectros de mi compi Helena.

Me puse manos a la obra y empecé a recopilar información relativa al espectro en frecuencia. Mi idea era usar música como contraseña, para poder descifrarlo a posteriori repitiendo una melodía. Para ello, se necesita saber cuales son las frecuencias que componen el audio y a que notas corresponden.


Para que se entienda mejor he cogido una referencia de las notas musicales representadas sobre un piano. Partimos de que la frecuencia audible, o campo tonal, para el ser humano está comprendida entre 19Hz y 19KHz. Obviamente el margen varía según la persona y se estrecha con la edad. Equivale aproximadamente a 10 octavas de un piano. Cada octava, dobla los valores en su homónima siguiente. Es decir, si nos fijamos en la primera escala (obviamos la 0 porque no todos sus valores son audibles), vemos que el Do1, equivale a una frecuencia de 16.35 Hz por tanto el Do2, estaría en 32.70 Hz, Do3 en 65,40 y así sucesivamente. Esto radica en que si podemos obtener las frecuencias que componen un archivo de audio, es posible transcribirlo en notas musicales como tal. 

De la imagen anterior, podemos también asumir dos cosas. La primera es que en el caso de que no quisiéramos diferenciar escalas, para nosotros cualquiera de las notas,independientemente de la escala en la que se encuentre, podría ser la misma. La segunda es que existiría la posibilidad de trabajar usando el espacio entre frecuencias de tal forma que daría igual que el audio cambiase de tono (puede que si intentas repetirlo cantando no empieces siempre en la misma frecuencia), ya que seguiría habiendo la misma distancia entre las frecuencias existentes.

Hasta aquí todo bien. El problema es que una onda de audio se representa en 2 dimensiones, amplitud en función del tiempo. Y es aquí donde entra el post de Helena y mi reciente reconciliación con mi antiguo archienemigo Fourier. Su transformada, nos permite convertir una onda del dominio del tiempo al dominio de la frecuencia. Para mostrároslo he elegido un audio con el sonido del Sinsajo, que consta de solo 4 notas.

Forma de onda del audio del Sinsajo

A partir de la forma de onda, podemos ver que existen 4 "bloques" de sonido diferenciados. El 1º y el 3º con más amplitud (volumen) que el 2º y el 4º, pero no tenemos forma de saber cuales son las frecuencias que predominan en esos puntos, y por tanto no podemos asociarlo a ninguna nota.

Sin embargo, si aplicamos la transformada de Fourier, obtendremos el espectro de onda, donde pueden verse las frecuencias asociadas a cada instante de tiempo.

Espectrograma del audio de Sinsajo

Es complicado que un audio esté tan limpio como para que se dibujen solo y exactamente la información que buscamos, pero si podemos visualizar para cada instante de tiempo, cual es la frecuencia que aparece con más potencia. En este caso, si hacemos zoom sobre el espectro...


Si buscamos la correspondencia de estas frecuencias predominantes, en la primera imagen, podemos obtener las notas.

Notas obtenidas aproximadas:
  • 1.55-1.6KHz -> Sol6
  • 1.85-1.9KHz -> La#6
  • 1.75-1.82KHz -> La6
  • 1.10 - 1.2KHz -> Re6
Siendo el audio original un silbido, tenemos que asumir la inexactitud del mismo, pero si tocamos las notas en un piano, la melodía es, efectivamente, el sinsajo.


Ya está bien de mates por hoy. Nos vemos en la 2ª parte de esta PoC pero no sin antes añadir la pregunta que surgió, y que cambió el curso de esta investigación. 

¿Y si no sabes cantar?¿Y si no tienes forma de crear el audio?

29 sept 2020

Cifrando en PowerShell para bypassear un antivirus perimetral (ya no tan noob):

¡Muy buenas!

Hace unos meses, en este post, os mostramos unos scripts muy sencillitos para codificar y descodificar en base 64 un script malicioso para intentar bypassear algún equipo perimetral. Os comentamos que esa era la solución de andar por casa y sin ganas de arremangarse mucho, y que la forma "leet" de hacer este bypass de perímetro era cifrando el contenido, que obviamente no es tan trivial. 
En el post de hoy me gustaría hablaros de SecureString. Esto es una clase .NET que representa un texto que debe mantenerse confidencial (por ejemplo, mediante su eliminación de la memoria del equipo cuando ya no se necesite). Pese a que no se recomienda su uso, ya que el contenido secreto... no es tan secreto en memoria como nos gustaría, nos puede servir perfectamente para bypassear un antivirus perimetral. Para ello, debemos saber que SecureString usa DPAPI para almacenar una variable string de hasta 65.536 caracteres cifrada en memoria, y que permite "devolver" este objeto a un string cifrado en AES o en texto plano: esto es lo que nos interesa :).

Bien... ¿y cómo? Lo primero, definiremos la variable de texto que queremos enviar:

$secret_SS = <SECRETO> | ConvertTo-SecureString -AsPlainText -Force

Ahora mismo tenemos la variable almacenada cifrada en memoria... pero esto no nos sirve de mucho, ¿verdad?

Como veis, una SecureString a pelo no es muy útil en este caso...

Lo que nos interesa es sacar el valor de esta variable cifrado con AES, para lo que necesitaremos una clave (un array de 128-bit (16 bytes), 192-bit (24 bytes) o 256-bit (32 bytes)). Podemos definir el array de bytes a capón o usar una función hash para hacer esto más leet y agradable.

[Byte[]] $key = (1, 255, 232, 211, 123, ... , 159, 81) #Definimos el array directamente
---
$sha256 = New-Object System.Security.Cryptography.SHA256CryptoServiceProvider #Queremos una clave de 32 bytes
$key = $sha256.ComputeHash([system.Text.Encoding]::UTF8.GetBytes(<CONTRASEÑA>)) #Hacemos el SHA256 de la contraseña que hayamos elegido, devolviendo un array de bytes

En cualquier caso, una vez hemos definido la clave, podemos obtener el secreto cifrado en AES con el siguiente comando

$secret_AES = $secret_SS| ConvertFrom-SecureString -Key $key

Aquí vemos cómo obtenemos al contenido cifrado en AES-256

Ahora nos toca descifrar este texto lo cual, como podréis intuir, es un proceso muy similar. Primero, una vez definida la variable con el string en AES, definimos de nuevo la clave de descifrado, al igual que en el lado cifrador. Tras esto, pasamos el string en AES a SecureString con la clave usada para cifrar:

$secret_SS = $secret_AES | ConvertTo-SecureString -Key $key

Finalmente, sólo nos faltaría recuperar el valor de la SecureString en claro. Para ello existen dos maneras en función de la versión de PowerShell usada:
  • Powershell < v6.0 (en Windows vale para cualquier versión):
$clearSecret = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($secret_SS))
  • PowerShell >= v6.0:
$clearSecret = ConvertFrom-SecureString -SecureString $secret_SS -AsPlainText
Aquí desciframos el secreto cifrado en AES-256

Como veis, este método es relativamente sencillo para cifrar nuestros payloads entre sistemas con PowerShell (recordad que la versión 7 se puede instalar en Linux) y bypassear un antivirus perimetral, o lo que surja. Ahora bien, ¿hay una forma de cifrar en AES a bajo nivel para interactuar con otros lenguajes y no depender exclusivamente de PowerShell? ¿Y si yo quisiera cifrar en Python y descifrar en PowerShell?

Pues eso os lo contamos otro día :)

¡Gracias por leer!


28 sept 2020

Have I been Pwned? Hacking para niños

Have I been Pwned se ha convertido en un servicio estándar dentro del mundo cyber. Para los que no lo conozcáis, se trata de un sitio web que hace una búsqueda sobre filtraciones de datos de usuario (e-mails y contraseñas). Basta con poner un e-mail para que nos indique si ha aparecido en alguno de los data leaks que ellos tienen registrados. Un servicio simple y útil. Sin embargo, me llamó la atención que en las últimas actualizaciones de Google Chrome, y más recientemente en iOS 14, se ha implementado un sistema similar que comprueba que nuestras credenciales no han aparecido en estas filtraciones.


Password leak protection on Chrome


Password leak protection on iOS 14

En principio, parece una herramienta inocua que nos ayuda a proteger nuestra vida digital. Pero después de ver ambos, me puse en modo ITSec, y se me ocurrió la eterna pregunta de... "¿Y si...?".

Aunque Have I been Pwned dispone de una API para integrar su servicio en nuestras APPs, doy por hecho que tanto Google, como Apple, utilizan una base de datos propia. Sin embargo, es cuestión de probar un poquito para darse cuenta de que prácticamente disponen de los mismos leaks.

Creo que es bueno que existan servicios como éste. Asustar un poquito de vez en cuando al usuario medio nunca viene mal para protegerle. De hecho, yo sigo en mi campaña personal por hacer que la gente que me rodea no relacionada con el mundo IT comience a usar gestores de contraseñas.

Que Have I been Pwned nos avise de que nuestras credenciales se han filtrado está bien. El problema viene cuando comienza a darnos información de dónde y cuándo se ha producido ese leak. A día de hoy no es muy difícil encontrar estos leaks, la mayoría son públicos, sobre todo si ha pasado bastante tiempo desde el mismo. Esto facilita enormemente desde el punto de vista de un atacante la obtención de estas contraseñas. Es tan fácil como ir a la web, poner el correo del que queramos comprobar la información y esperar a que nos diga dónde y cuándo se han filtrado.

Una vez tenemos esta información, basta con usar la mejor herramienta de hacking que existe, "Google" (o en su defecto, tu motor de búsqueda preferido, osease Google :P), y encontrar el leak, que generalmente estará enlazado en algún foro de dudosa procedencia. Una vez tenemos la información del mismo, basta con buscar el usuario para obtener la contraseña en plano.

Desde mi punto de vista, es bueno que tanto Google, como Apple, tomen iniciativas de este tipo, pero por otro lado, no creo que sea necesario el exceso de información para un posible atacante. El problema es que muchas veces no somos conscientes de la gravedad de la situación hasta que es demasiado tarde.

Decálogo del password seguro:

  • Siempre hemos de tener un password distinto para cada servicio.
  • Los password han de ser no solo largas, si no también con un amplio set de caracteres. Es un engorro, pero llegará un momento en el que diréis, bendito el día en que puse este password del infierno.
  • Es evidente que no podemos recordarlos todos, usad un gestor de contraseñas como Keepass. En su defecto, por cuestiones de comodidad, podréis servicios multiplataforma (1Password, Lastpass...) o los propios integrados en vuestros sistemas como el de Chrome o Apple Keychain.
  • Evitad contraseñas que tengan que ver con vosotros, con vuestros familiares, fechas, nombres, productos, palabras de diccionario, etc. Los gestores permiten generarlas aleatoriamente. Cuanta menos influencia personal tenga el password, más compleja será la tarea para el atacante.
  • Cambiad las contraseñas cada cierto tiempo, atendiendo a la importancia del servicio. Los gestores de contraseñas también nos facilitan esta tarea. De hecho, la mejor opción que podemos seguir es que los gestores nos generen contraseñas largas y aleatorias que no seamos capaces de recordar, para obligarnos a nosotros mismos a utilizarlos.
De todas formas, estoy seguro de que si estás leyendo ésto, es que es lector asiduo de Flu Project y, por tanto, ya cumples todas las recomendaciones del decálogo ¿verdad?. Por lo que lo único que te pido es que prediques la parábola de Keepass y ayudes a tus familiares y amigos a fortificar un poco más su vida digital :)


25 sept 2020

Crónicas del Malware I: WannaCry, aka cómo pasar del inminente plan de actualización, al dónde está mi backup.

La cafetera sonó como otro día cualquiera. Con algo más de sueño de lo habitual, me dispuse a salir corriendo dirección a la estación de cercanías más próxima a casa, mochila en la espalda, móvil personal en el bolsillo izquierdo, de empresa en el derecho, y en la mano el típico paquete de galletas de mantequilla, que se estila hoy en día en esas cafeterías que se hacen llamar modernas, y en cuya carta reluce su pack de desayuno por solo 6,99€ "Happy Friday Lunch".

Como todos los viernes, algo de electrónica LO-FI  pretendía hacerme más corto el viaje en transporte público hasta la sede del cliente al que me encontraba auditando. En Atocha, había quedado con mi compañero del curro, Eugenio, mi guerrero en la lucha diaria. Desde que coincidimos en la empresa, y más concretamente en el proyecto, combatimos a diario contra la habitual burocracia que existe en grandes empresas; equipos y máquinas con sistemas arcaicos sin actualizar, antivirus cuyo último paquete de firmas de malware data de allá por el 2005 o servidores cuyos administradores nunca consideraron un problema dejar contraseñas "by default".

El cartel de RENFE anunciaba los 4 minutos restantes para la llegada del siguiente cercanías. Nada parecía fuera de lo normal. Una vez en el vagón, las conversaciones rutinarias poniéndonos al tanto en lo personal, en noticias, recordando eventos del día y casos de pendiente resolución, iban apareciendo de forma indirectamente proporcional al sueño que ambos teníamos.

Entramos en la oficina cual equipo de Men In Black, bebiéndome el que para mi ya era el segundo café de la mañana. Saludo al chico de seguridad mientras hago uso del sistema de fichaje biométrico en la entrada, esperamos en la puerta del ascensor y, cuando nos toca subir, lo hacemos reiterando el odio al típico empleado que no contempla la opción de subir a la primera planta por las escaleras. Una vez llegué a mi puesto, y pasada la batería de saludos diaria entre las caras conocidas de la oficina, procedí a encender mi equipo.

Llevábamos varias semanas testeando la seguridad de los sistemas del cliente, aunque realmente este era el segundo año que nos habían elegido para pasar su auditoría. Eugenio empezó a hablarme sobre algunos detalles técnicos del report que se encontraba redactando en ese momento. La empresa no había aplicado prácticamente ninguna de las recomendaciones que habían sido propuestas en anteriores controles, entre otras cosas, la red era prácticamente plana, y por si fuera poco, aún quedaban bastantes máquinas con Windows XP. Sin embargo, aún desconocíamos lo que empezaba a suceder de forma simultánea en muchos otros rincones del mundo.

Tenía meeting de seguimiento, así que aproveché para tirar algunos escaneos a varios rangos de IP en NMAP, y los dejé trabajando para así ahorrar algo de tiempo después. Ese día, la reunión estaba siendo soporífera. Se me hizo realmente largo el viaje a través de la lista de KPI's, que conseguíamos completar semanalmente entre los diferentes equipos. Pero esta vez el balance final había sido bueno, pues había conseguido fecha para el protocolo de actualización de todas las máquinas coetáneas al apatosaurus, en un período menor a tres meses. Pero, sin yo saberlo, algo estaba apunto de frustrar el plan de actualización que tanto me había costado fechar. Tras la parte de ruegos y preguntas, se dio por concluida la reunión y nos dirigimos de nuevo a los puestos, pero, esta vez, aún desde lejos, me pareció que mi pantalla estaba encendida, algo que no suele ser habitual, pues es bien sabido para cualquiera del gremio que dejar un equipo sin bloquear con el típico "Win+L" puede tener graves consecuencias, no solo a nivel de ciberseguridad, sino también de reputación y orgullo entre los compañeros de Infosec.


Al llegar al equipo, una ventana roja adornaba de forma sugerente el escritorio del equipo. Sin intención de resultar agorero, el candado que podía verse en la parte superior izquierda y un llamativo banner con el logo de Bitcoin en la parte inferior, no formaban parte de ninguna de las aplicaciones que suelo usar en mi jornada de trabajo diaria.

El desastre estaba llamando a nuestras puertas. Examiné la interfaz de la aplicación y mis "ganas de llorar" empezaron a acuciar desde lo más profundo de mi pequeña alma de Hacker. Estábamos siendo atacados, me dije. Atacados por un ransomware. La falta de software antivirus con soporte EDR, la obsolescencia del software que utilizábamos y probablemente un desconocido 0-day, comenzaron a hacer mella en el cliente, propagándose rápidamente gracias a la arquitectura plana de la red, de cuyas debilidades llevabamos tiempo avisando. Avisé corriendo a Eugenio y ambos procedimos a desconectarnos de la red, pero era tarde. Demasiado tarde.

Le pedí a mi compitrueno que avisara al equipo de IR (respuesta ante incidentes) para que aplicase el protocolo pertinente, mientras yo entraba en Internet, a ver si conseguía informarme de si éramos los únicos afectados para intentar entender cómo el gusano había llegado a la red, y si existía forma alguna de mitigarlo.

De forma escalonada muchos de los compañeros de la oficina comenzaron a recibir el mismo mensaje que yo acababa de ver en la máquina corporativa. La mayoría de archivos de los equipos habían sido cifrados y se solicitaba el ingreso de una cantidad equivalente a 300$ en Bitcoins en una cartera para revertir la situación. No fuimos los únicos. De hecho el ataque se estaba expandiendo a nivel mundial y, sin garantía alguna de que el posible pago del rescate devolviese el sistema a su estado original, no quedaban demasiadas opciones.

Tras algunos intercambios de correos por nuestra parte tanto con el equipo de IR como con arquitectura de red, empezaron a llevarse a cabo las acciones pertinentes para reducir el alcance de la amenaza. Se expulsó de la red a todos los equipos que no pertenecían a infraestructura crítica de la empresa. Durante unas horas, aquello pareció el Apocalipsis. Las redes sociales se inundaron de mensajes relativos al ataque. La gente, nerviosa pensando en los meses de trabajo que podrían haberse perdido. En solo unos momentos, se pasó de la incertidumbre por conocer la magnitud del ataque, a la incredulidad al ver el potencial del mismo.

Por suerte para nosotros, y sobre todo para el cliente, éste había contratado un sistema de copias de seguridad en la nube que se ejecutaba cada noche de forma transparente. Pasarían varios días hasta que todo pudiese volver a la normalidad. Pero allí estaban ellos, los olvidados, los ninguneados. Esta vez eran ellos quienes debían tomar protagonismo y hacerse cargo del problema, los verdaderos héroes del momento, los backups.

No fue hasta ya entrada la tarde, habiéndose alargado la jornada laboral durante varias horas más de lo habitual, cuando Eugenio y yo pudimos volver a casa exhaustos, con la cabeza embotada, y casi sin fuerzas para hablar. Al llegar de nuevo a Atocha, nos despedimos como cada día, y una vez solo, volví a ponerme los cascos, para hacer el camino restante a casa, dando vueltas a todo lo que no había, pero habría podido pasar. Me puse ropa cómoda, preparé cual autómata una cena ligera, encendí la tele, abrí Netflix, puse a reproducir un capítulo de Dark y no tardé mucho en dormirme pensando que ese día, mi historia le ganaba en lo surrealista...

24 sept 2020

Libertarismo y ciberseguridad: ¿Qué tiene que ver el tocino con la velocidad?

¡Muy buenas!

Antes de empezar este post, quiero hacer un pequeño disclaimer: voy a intentar usar temas económicos para intentar llevar a cabo un razonamiento chapucero, pero que me parece curioso. Como hoy en día todo tiene un deje ideológico determinado (y, por tanto, una serie de prejuicios y enfados varios en mucha gente), simplemente, me gustaría dejar claro que no tengo ni la más remota idea de economía y, ni apoyo, ni critíco las teorías económicas que voy a mencionar. Dicho esto, comenzamos :)

Estaba yo este verano aprovechando las vacaciones al máximo, mirando Twitter tirado en el sofá (porque la playa es para los que se quieren quemar y llenar de arena), cuando me di cuenta por primera vez que en mi timeline me aparecía muy a menudo una bandera que me descolocaba:

Bandera de Gadsen
La dichosa bandera (Bandera de Gadsen)

¿Quién se pone una serpiente en una bandera? Si es el animal que más connotaciones negativas tiene del mundo... Pero me picó la curiosidad, porque entonces me di cuenta de que muchísima gente en Twitter tiene en su nombre el emoji de la serpiente o algo con color amarillo.

Acabé descubriendo que es la bandera que usan los libertarios. Y a mí eso no me sonaba de nada en absoluto.

Tras una extensa investigación en Wikipedia (una horita, no nos vamos a engañar) aprendí un poco sobre este mundo, que os resumo en unos pocos puntos para que podáis seguir mi razonamiento:

  • El liberalismo es una corriente de pensamiento económico que rechaza que el Estado interfiera en la economía, y que busca reducir los impuestos todo lo posible para afectar lo más mínimamente que se pueda a la capacidad económica (o libertad) del individuo.
  • Con el tiempo, cierto sector del liberalismo se ha ido percibiendo que el concepto se iba volviendo algo muy "soft": se intenta reducir el peso del Estado en la economía, así como los impuestos... pero tampoco demasiado. Digamos que no se salen del concepto del "Estado del Bienestar" donde existen unos servicios públicos como educación, sanidad, etc.
  • Por tanto, este sector pasa a autodenominarse como "libertarios". Estos tienen un pensamiento más "hard" del liberalismo. De aquí derivan dos ramas (permitidme llamarlas) "extremas":
    • El minarquismo o "Estado Mínimo", que defiende que el Estado debe gestionar la defensa, seguridad y justicia; nada más. Por tanto, un Estado minárquico únicamente tendría un ejército, policía y juzgados públicos, el resto funcionaría mediante empresas privadas.
    • Los anarcocapitalistas, que defienden la eliminación del Estado en su conjunto y donde todo funcionaría siguiendo las reglas del capitalismo. Todos los servicios, incluidos defensa, seguridad y justicia, serán dados por empresas privadas que compitan en un libre mercado.
Bueno, ¿y por qué hablo de estos temas en un blog de ciberseguridad? Pues por un detalle muy simple: por los minarquistas. Me explico ;)

Me llamó mucho la atención que exista un sector de la población que abogue por reducir el Estado a su mínima expresión posible y considere que el único servicio indispensable que debe dar el Estado, el último reducto de la gestión pública, sea la seguridad. No la educación o la sanidad. No las infraestructuras o el transporte: la seguridad física y jurídica.

Bien. Pues si añadimos a toda la población con pensamientos liberales "clásicos" o que sí aceptan que el Estado intervenga en la economía, podemos concluir que prácticamente cualquier persona que te encuentres por la calle crea que la seguridad es algo que debe ser gestionado por el Estado para garantizar la supervivencia del país. 

Dejadme reducir al absurdo: casi todo el mundo piensa que, para estar seguros, debe garantizarse que se invierte un dinero determinado y estable a un conjunto de personas preparadas para hacer un trabajo determinado (militares, policías y jueces), en lugar de competir por ver quién es más barato en dar dicho servicio.

¿Veis por donde van los tiros? Traslademos esto de un país a una empresa cualquiera del sector privado: ¿creéis que se tiene esa misma mentalidad? ¿Tendría sentido que la defensa de un país la llevase una empresa que ganó por precio ya que sus "soldados" defienden el país con pistolas de balines, para ahorrar el dinero? ¿Mantenemos la lógica cuando añadimos el prefijo "ciber" a la seguridad?

Prometo no meterme más en estos jardines, pero me parecía curioso presentaros esta ida de pinza por mi parte :). Si habéis llegado hasta aquí, y como muestra de arrepentimiento por la chapa, os dejo un vídeo del libertario por excelencia: el gran Ron Swanson (os recomiendo ver la serie Parks and Recreation, y The Office de paso :) ).


¡Saludos!

23 sept 2020

CVE-2020-1472 - Zerologon: Por qué debes priorizar el parcheo antes que la detección

¡Buenas a todos!

En este artículo se mostrarán algunos detalles de la vulnerabilidad CVE-2020-1472 (Zerologon) de Microsoft que afecta directamente a los controladores de dominio y que fue anunciada durante el mes de Agosto de 2020 en su parche mensual. Recientemente la vulnerabilidad está apareciendo en los medios de comunicación y redes sociales por su facilidad a la hora de ser explotada, ya que un potencial atacante que tenga conectividad con el controlador de dominio podría hacerse administrador del mismo fácilmente.

El siguiente artículo se dividirá en distintas partes:

  • Introducción: explicación breve de la vulnerabilidad.
  • PoCs: recopilación de las distintas pruebas de concepto publicadas hasta la fecha y uso de una de ellas.
  • Consideraciones: reflexiones sobre las implicaciones de utilizar esta vulnerabilidad durante una auditoría interna o red team.
  • Mitigaciones: recomendaciones en cuanto a parcheo y detecciones.
 

Introducción

El 11 de Septiembre, investigadores de Secura publicaron un análisis de una vulnerabilidad crítica llamada coloquialmente Zerologon. En este análisis se explica detalladamente como la vulnerabilidad fue encontrada abusando de un bug del protocolo Netlogon, donde se explica que la vulnerabilidad reside en sí en un uso inseguro del cifrado por bloques AES-CFB8. Esto permitiría a un atacante suplantar los mensajes de actualización de contraseñas a este servicio RPC, pero solo por una contraseña vacía.

¿Qué quiere decir esto? Que cualquier usuario de una red que sea capaz de alcanzar el controlador de dominio, es capaz de realizar este ataque, lo que permitiría a un potencial atacante cambiar la contraseña de máquina de un controlador de dominio. Una vez ejecutada esta vulnerabilidad con éxito, el atacante podría extraer con total facilidad el contenido de la base de datos NTDS del directorio activo que posee ese controlador de dominio. Esto implicaría que a partir de este momento, el atacante puede hacerse administrador del dominio con total libertad.

Sin embargo, esto no es indetectable, y obviamente cambiar la contraseña de una máquina controladora de dominio lleva consigo consecuencias y riesgos muy nefastos. A continuación, se listan una serie de pruebas de concepto publicadas por varios investigadores de seguridad del sector y que obviamente se recomienda evitar su uso fuera de un entorno de pruebas.

PoCs

Durante estos días se han publicado diversas pruebas de concepto para esta vulnerabilidad, estas pruebas de concepto no tienen una fiabilidad total, y siempre es recomendable su uso en entornos de laboratorio. (En este artículo no se cubrirá el uso de la herramienta Mimikatz para explotar la vulnerabilidad).
  • Checker [Python]: Un script publicado por los propios investigadores de Secura para comprobar si el controlador de dominio es vulnerable al CVE.
  • zer0dump [Python]: Una prueba de concepto que se encarga de explotar la vulnerabilidad y reparar la contraseña de máquina del controlador de dominio.
  • dirkjanm-Exploit [Python]: La primera prueba de concepto funcional publicada tras la investigación de Secura.
  • SharpZeroLogon [C#]: Prueba de concepto creada para ser usada directamente a través de la DLL netapi32 y con el objetivo de ser utilizado a través de Cobalt Strike.
  • Invoke-Zerologon [Powershell]: PoC realizada por el equipo de BC-Security a partir del exploit publicado en C# por NCC Group.
Para las pruebas se ha utilizado la máquina retirada Forest de HackTheBox, ya que se trata de un entorno de pruebas bastante directo para este tipo de exploits y fácilmente reversible. Con el fin de facilitar la explotación de las PoCs se ha asignado el nombre forest.htb en /etc/hosts a la máquina.
 

 
Seguidamente suponiendo una instalación completa de la librería impacket en su última versión, hacemos uso de los exploits escritos en Python con total libertad.

Checker

 zerologon_tester.py FOREST forest.htb

En caso de que el controlador de dominio que intentemos atacar sea vulnerable a este CVE obtendremos una salida por pantalla de este tipo: 


En este momento el atacante sabría que el controlador de dominio es vulnerable al CVE y procedería a su explotación. 

zer0dump 

zer0dump.py forest.htb -target_da Administrator -port 445 -target_machine FOREST 

Una vez lanzado el comando donde se toma como objetivo el usuario administrador de dominio llamado Administrator se obtiene directamente su hash NTLM.

 
A partir de este momento, las posibilidades para un potencial atacante para ganar persistencia en el sistema y en la red son casi infinitas, tantas como su imaginación y TTPs puedan aportar. Un ejemplo básico para el uso de estas credenciales sería la ejecución de código a través de un consola obtenida por WinRM. Para ello se ha utilizado Evil-WinRM:
evil-winrm -i forest.htb -u Administrator --hash '32693b11e6aa90eb43d32c72a07ceea6'

dirkjanm-Exploit

cve-2020-1472-exploit.py FOREST forest.htb

En este caso el exploit se ha completado tal y como se explica en la investigación de Secura, estableciendo así la contraseña del usuario de máquina a una vacía. Para demostrarlo, vamos a realizar un volcado de la base de datos NTDS.dit del DC haciendo uso de la herramienta secretsdump:

secretsdump.py -just-dc -no-pass FOREST\$@forest.htb

En este momento podría procederse tal y como en el exploit anterior y realizar cualquiera de los muchos caminos para conseguir nuestro objetivo dentro del dominio.

SharpZeroLogon

./SharpZeroLogon.exe FOREST.htb.local -reset

Invoke-Zerologon

. ./Invoke-ZeroLogon.ps1; Invoke-ZeroLogon FOREST.htb.local 1

Ambas pruebas de concepto, tanto SharpZeroLogon como Invoke-ZeroLogon, necesitan resolver el FQDN del controlador de dominio para poder realizar correctamente el ataque, es por ello que se recomienda realizar desde una máquina que se encuentre unida al mismo dominio que el controlador.

Consideraciones

A partir de las pruebas de concepto publicadas es sencillo convertirse en administrador de dominio con tan solo unos pocos clics, sin embargo, las implicaciones que tiene utilizar este exploit en un entorno de producción son nefastas. Una vez cambiada la contraseña de la cuenta de máquina de un controlador de dominio, este pierde toda la confianza que tenía con los servidores a su alrededor, esto implicaría que los servidores no puedan autenticarse de nuevo contra el dominio.

Recientemente, el investigador @_dirkjan publicó junto a su exploit un hilo en Twitter explicando cuales serían algunas de las consecuencias del uso de este exploit en un entorno de producción. Recomendamos una lectura tranquila del propio hilo para su entendimiento, y desaconsejamos totalmente el uso del exploit fuera de un entorno no controlado.

Mitigaciones

La vulnerabilidad de Zerologon debe ser parcheada con la mayor brevedad posible. Sin embargo, no siempre es posible realizar este tipo de medidas inmediatamente, por ello, se recomienda monitorizar las conexiones a los controladores de dominio, así como prestar especial atención a los eventos nativos de Windows Logs y Sysmon.

Si bien el objetivo de este artículo es detallar las distintas pruebas de concepto que se encuentran actualmente publicadas, se recomienda prestar atención a los siguientes eventos de Windows para detectar la vulnerabilidad:
  • Event Code 5805: Ocurre cuando una máquina realiza una conexión fallida contra el controlador de dominio.
  • Event Code 4624 + 4742: Un evento 4624 seguido de un 4742, esto quiere decir que se ha realizado un cambio de contraseña en la cuenta de máquina del controlador de dominio y que acto seguido se ha realizado un inicio de sesión "Anónimo".
De igual forma, se recuerda que el parche de esta vulnerabilidad se encuentra dividido en dos partes. Una primera parte en el parche de Agosto de 2020 y una segunda parte que aparecerá en Febrero 2021, para la aplicación del parche se recomienda seguir las indicaciones proporcionadas por Microsoft en el siguiente enlace.

Cualquier comentario que se realice para corregir cualquier error de concepto sobre la vulnerabilidad o que pueda ayudar a su detección es bienvenido y se añadirá al contenido de este artículo.

22 sept 2020

Suites de TLS/SSL (Parte IV)

En este cuarto y último post de este hilo vamos a terminar de tratar las vulnerabilidades asociadas a diferentes malas configuraciones en servidores SSL.

Bar Mitzvah - CVE-2015-2808

  • Descripción:
    • Explota la generación pseudo-aleatoria de claves que usa el algoritmo RC4, y con ella poder conseguir los 100 primeros bytes de una conexión TLS/SSL.
  • Recomendación: Deshabilitar el uso de RC4.


LOGJAM - CVE-2015-4000

  • Descripción:
    • Posee una lógica similar a la vulnerabilidad FREAK ya que ambos buscan hacer downgrade al servidor, pero con la diferencia de que en este caso vulnera aquellos servidores que soportan DHE_EXPORT (debido a un fallo en el protocolo TLS) forzándolos a usar un grado menor de exportación en las conexiones de 512bits, el cual puede ser descifrado con relativa facilidad.
  • Enlace de referencia de la vulnerabilidad: https://weakdh.org/
  • Recomendación: Deshabilitar DHE_EXPORT e implementar Diffie-Hellman 2048-bit.


Lucky13 - CVE-2013-0169

  • Descripción:
    • Este ataque es más teórico debido a las condiciones que deben establecerse en la configuración del servidor y el gran número de peticiones que debe realizar, explotando el uso de CBC (Cipher-Block-Chainning) y el cálculo del MAC.
  • Recomendación: Deshabilitar el uso de CBC.

POODLE - CVE-2014-3566

  • Descripción:
    • Parte de que, cuando un intento de conexión segura falla, se procede a intentar realizar de nuevo esa conexión pero con un protocolo de comunicación más antiguo. De esa forma, un atacante podría ocasionar intencionadamente errores de conexión en protocolos seguros como TLS 1.2, TLS1.1 y TLS1.0 y forzar así el uso de SSL 3.0 para aprovechar la vulnerabilidad.
  • Recomendación: Deshabilitar SSLv3, TLS1.0 y TLS1.1 en el servidor.

 


SWEET32 - CVE-2016-2183

  • Descripción:
    • Facilitaría que un atacante remoto pueda obtener información confidencial debido a un error en el cifrado DES/3DES.
    • Un atacante podría realizar ataques MiTM con la captura de grandes cantidades de tráfico cifrado entre el servidor SSL/TLS y el cliente, y recuperar los datos de texto sin cifrar.
  • Enlace de referencia de la vulnerabilidad: https://sweet32.info/
  • Recomendación: Deshabilitar SSLv3, TLS1.0 y TLS1.1 en el servidor.

 RACCOON - CVE-2020-1968

  • Descripción:
    • Hace uso del intercambio de claves de Diffie-Hellman durante el handshake en TLS1.2 (y versiones anteriores), de forma que descifra la conexión entre un cliente y el servidor.
    • La vulnerabilidad se encuentra en la clave Premaster Secret usada a la hora de generar las claves de cifrado en la comunicación, la cual se usa como variable de entrada en la KDF (Key Derivation Function). La KDF se basa en hashes con diferentes perfiles de tiempo, de forma que dichas mediciones de tiempo pueden ayudar a un atacante a generar nuevas claves Premaster Secret, reenviando al servidor esta clave para suplantar la identidad de un cliente en una nueva conexión.
    • Este ataque es complejo de explotar, dado que se deben realizar un gran número de peticiones para construir una nueva clave, y a su vez depende de la configuración del server timing behavior.
  • Enlace de referencia de la vulnerabilidad: https://raccoon-attack.com/
  • Recomendación: Deshabilitar el uso de Diffie-Hellman para el intercambio de claves (DH key exchange) en TLS1.2 y versiones inferiores.

Esperamos que con este hilo hayáis comprendido mejor el funcionamiento de las suites de cifrado y las consecuencias más conocidas de sus malas configuraciones en los servidores SSL.

Muchos maullidos!

M

21 sept 2020

Suites de TLS/SSL (Parte III)

Siguiendo con este hilo, vamos a enumerar y describir las vulnerabilidades más conocidas que nos encontramos asociadas a los protocolos y algoritmos usados en las suites de cifrado. En este post trataremos la primera mitad de este conjunto de vulnerabilidades.

BEAST (Browser Exploit Against SSL/TLS) - CVE-2011-3389

  • Descripción:
    • Permite realizar ataques MiTM para obtener información de una sesión que usa SSL/TLS1.0.
    • Esta vulnerabildad es muy compleja de explotar ya que necesita realizar fuerza bruta para conseguir información útil.
    • Es originada por los vectores de inicialización de TLS1.0 en los cifrados de CBC y RC4.

  • Recomendación: Deshabilitar SSLv3, TLS1.0 y TLS1.1 en el servidor.


CRIME (Compression Ratio Info-leak Made Easy) - CVE-2012-4929

  • Descripción:
    • Se basa en el secuestro de sesiones en los protocolos HTTPS y SPDY a través del robo de las cookies de sesión, explotando la compresión HTTP con fuerza bruta. Esta explotación es posible ya que SSL/TLS y SPDY usan un algoritmo de compresión llamado DEFLATE, que elimina strings duplicadas durante la conexión entre el cliente y el servidor.
    • A pesar de esto, la compresión TLS se encuentra deshabilitada actualmente en los navegadores Chrome, Mozilla, Opera Safari e Internet Explorer, por lo que deshabilitarla en el servidor ayudaría a proteger a aquellos usuarios que usen navegadores desactualizados.
  • Recomendación: Desactivar la compresión en TLS y en HTTP en el servidor.


BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) - CVE-2013-3587

  • Descripción:
    • Es una variante del ataque CRIME, que se diferencia de éste en que BREACH se centra en el ataque de las respuestas HTTP, las cuales usan la compresión a nivel de HTTP (en vez de a nivel de TLS, como es el caso de CRIME), que a su vez es más común.
  • Enlace de referencia de la vulnerabilidad: http://breachattack.com/
  • Recomendación: Desactivar la compresión en TLS y en HTTP en el servidor.


FREAK (Factoring RSA Export Keys) - CVE-2015-0204

  • Descripción:
    • Se centra especialmente en los servidores que aceptan RSA_EXPORT en sus suites de cifrado.
    • Consiste en interceptar las comunicaciones HTTPS entre el cliente y el servidor, y forzar al servidor a usar cifrados obsoletos o vulnerables (es decir, a hacer downgrade) para romper las claves.
  • Enlace de referencia de la vulnerabilidad: https://censys.io/blog/freak
  • Recomendación: Deshabilitar RSA_EXPORT y versiones inferiores a TLS1.2


Heartbleed - CVE-2014-0160

  • Descripción:
    • Permite que un atacante pueda leer la memoria de un cliente o servidor, pudiendo conseguir las claves privadas de un servidor SSL y comprometiendo tanto la integridad del servidor como la de los usuarios que se conecten al mismo, además de su confidencialidad.
  • Enlace de referencia de la vulnerabilidad: http://heartbleed.com/ 
  • Recomendación: Deshabilitar SSL en el servidor.


En el siguiente post continuaremos viendo el resto de estas vulnerabilidades.

Muchos maullidos!

M

18 sept 2020

El peligro de los bulos automáticos en Twitter

Buenas a todos, que vivimos en la sociedad de la "desinformación" no es ningún secreto. Tanto es así que hasta el propio Centro Criptológico Nacional creó recientemente en su página web una nueva sección sobre desinformación:

https://www.ccn-cert.cni.es/comunicacion-eventos/comunicados-ccn-cert/10406-el-ccn-crea-en-su-pagina-web-una-nueva-seccion-sobre-desinformacion.html

También tenéis algunos documentos interesantes como el "CCN-CERT BP/13", dedicado a los riesgos de la desinformación y que podéis descargar gratuitamente desde el siguiente enlace:

https://www.ccn-cert.cni.es/informes/informes-de-buenas-practicas-bp/3549-ccn-cert-bp-13-desinformacion-en-el-ciberespacio/file.html


Hoy quería hablaros de una de las cientos de herramientas que circulan por la red y que, por desgracia, gente con malas intenciones o por la simple ignorancia de creer que hace gracia sin pensar en las posteriores repercusiones, utilizan para distribuir bulos que en numerosas ocasiones pueden resultar tan creíbles que es complejo distinguirlos de la verdad. En especial, cuando la persona que los lee no tiene una formación tecnológica suficiente, y puede dar por buenos contenidos que, gente que está más familiarizada con Internet como nosotros, no lo darían.

La herramienta que he seleccionado como ejemplo para este artículo es Tweetgen, a la que podréis acceder desde el siguiente enlace:

https://www.tweetgen.com/


Su uso es tan sencillo que, usuarios con poco conocimiento y que, no serían capaces de hacer una edición de gran calidad con una herramienta como Photoshop, podrían generar fácilmente bulos como por ejemplo, que Flu Project habría sido bloqueada:


O que Flu Project se retiraría:



Tan solo haría falta compartir esas imágenes en nuestras redes sociales con un hashtag atractivo, y a esperar. 

Servicios como el de Maldito Bulo hacen un gran trabajo por luchar contra la desinformación en Internet. Aunque lo único que podemos hacer para luchar contra esta lacra es formar adecuadamente al usuario final, para que se cuestione cualquier contenido dudoso y trate de buscar siempre la fuente original.

¿Seremos capaces de conseguirlo o tenemos la batalla perdida?

Saludos!

17 sept 2020

NIST Cloud Computing Forensic Science Challenges

El pasado mes de agosto fue publicada la versión final del "NIST Cloud Computing Forensic Science Challenges - NISTIR 8006", que sustituye a la versión de junio de 2014. Este documento impulsado por el NIST, estudia y presenta la investigación realizada por los miembros del grupo de trabajo acerca de los desafíos forenses a los que se enfrentan los expertos, al responder a incidentes sobre entornos cloud.

A continuación, os dejamos con el índice del documento:


Dentro del trabajo de investigación, han enumerado una serie de desafíos forenses en la nube, con 65 categorías que, si bien indican que no han sido ordenadas de acuerdo a ningún criterio, ayudarán a los forenses a establecer unas líneas base a tener en cuenta en este tipo de actuaciones:


El documento puede descargarse gratuitamente desde el siguiente enlace:

https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8006.pdf

Saludos!

16 sept 2020

Winbindex - The Windows Binaries Index

Muy buenas! en esta ocasión queremos comentar sobre una utilidad que puede ayudarnos en caso de realizar una investigación o simplemente tras sufrir el daño de algún archivo de nuestro sistema operativo.

¿Cómo nació la idea? todo surgió cuando el investigador Michael Maltsev (m417z), según cuenta en su blog, se encontraba realizando una investigación sobre un bug en Windows 10. Tenía conocimiento de que dicho bug estaba parcheado en alguna de las actualizaciones liberadas para ese sistema operativo, pero se le hacía muy difícil localizar, dentro del historial de actualizaciones, aquella que contenía el archivo en el que el bug había sido resuelto. 

A partir de ello crea una herramienta web llamada Winbindex - "the Windows Binaries Index", que permite descargar archivos de diversas extensiones (.exe, .dll, .sys), que han formado parte de las diferentes actualizaciones del sistema operativo Microsoft Windows 10.

Sacar provecho de la herramienta es muy sencillo, sólo debemos indicar el nombre (o el hash) del archivo buscado y nos mostrará una tabla con las diferentes versiones del archivo, sobre la que podremos ordenar y filtrar los resultados. Nos mostrará también información como hash, versión, sistema operativo, arquitectura y tamaño. Además, tendremos la opción de  acceder a datos extra del fichero y, por supuesto, descargarlo en nuestro equipo.


 Resultados para calc.exe
 

 Detalle para el binario calc.exe de 64-bit para la versión Windows 10 2004

Si bien su creador indica que por el momento el listado no es completo, posee una gran cantidad de archivos indexados y no descarta que en un futuro pueda incluir archivos de otras versiones del sistema operativo de Microsoft.

Espero que les sea de utilidad.

Saludos!



15 sept 2020

Suites de cifrado TLS/SSL (Parte II)

Good  meowrning! Dado que en el anterior post estuvimos comentando en qué consistía cada sección de una suite de cifrado, en este vamos a listar un conjunto de herramientas que nos ayudan a comprobar las suites de cifrado que acepta un servidor SSL/TLS, y si dicha configuración contiene vulnerabilidades asociadas.

- Con herramientas online como:


- Con herramientas a importar en nuestra máquina Kali/Parrot/Arch, tenemos las siguientes, que nos permiten solicitar un mayor nivel de detalle de las vulnerabilidades obtenidas.

  • Nmap

root@miau# nmap --script=ssl-enum-ciphers -p 443 target

root@miau# sslscan target -p 443

root@miau# testssl target

root@miau# sslyze --regular target


En la última parte de este hilo hablaremos de las vulnerabilidades que obtenemos ante configuraciones incorrectas :)

Muchos maullidos!

M

14 sept 2020

Suites de cifrado TLS/SSL (Parte I)

Meowy buenas! A la hora de configurar o analizar suites de cifrado en un servidor SSL/TLS nos encontramos diferentes parámetros a tener en cuenta, pero ¿sabemos qué significa cada parámetro o cuál es la solución más apropiada según nos aplique?, ¿cómo comprobar si nuestra solución realmente es segura o si convendría aplicar otras?, ¿entendemos las vulnerabilidades asociadas a estas malas configuraciones? Tanto si estamos en el equipo rojo o en el azul, puede ser interesante conocer estos detalles.

En este primer post nos vamos a centrar en los conceptos y aspectos a tener en cuenta para comprenderlo (que no pensemos ¿y esto cómo se comía?).

Empecemos por el concepto clave, ¿qué es una suite de cifrado? Es un conjunto de algoritmos de cifrado, cada uno con una función determinada, y que en su conjunto permiten establecer comunicaciones cifradas entre un cliente y un servidor. Antes de poder realizar la conexión establece el SSL handshake, en el que: 

  1. El servidor deber tener configuradas un conjunto de suites de cifrado que acepta.
  2. El cliente le envía aquellas versiones de TLS/SSL, suites de cifrado y métodos de compresión que soporta, en orden de preferencia (a.k.a. ClientHello).
  3. El servidor escoge entre ellas la suite más favorable para comenzar a cifrar los datos (a.k.a. ServerHello).
  4. El servidor envía su certificado.
  5. Con la verificación del certificado (y, por tanto, la identidad del servidor), se negocia una clave secreta llamada Master Secret, teniendo en cuenta la suite de cifrado escogida.
  6. El cliente envía un mensaje cifrado al servidor.
  7. El servidor verifica que el MAC (ojo, en este caso las siglas significan Message Authentication Code, usado para la autenticación) es correcto y el mensaje puede ser descifrado correctamente. 
  8. El servidor responde al mensaje, el cual es verificado también por el cliente.

Como hemos dicho previamente, una suite de cifrado está formada por varios algoritmos, de modo que el siguiente paso es descomponer una suite de cifrado. Para entenderlo mejor, vamos a tomar los ejemplos que vemos en la siguiente imagen (partiendo de TLS, ya que el uso de SSL lo consideramos obsoleto):

A continuación vamos a describir cada uno de los elementos con más detalle:

  • Protocolo. Nos indica el tipo de protocolo a usar, siendo SSL (ya obsoleto) o TLS, con sus correspondientes versiones.
  • Algoritmo de intercambio de claves (Key Exchange). Algoritmo a emplear para compartir las claves simétricas con las que se cifrarán las comunicaciones.
  • Firma digital. Verifica las identidades tanto del cliente y como del servidor durante la sesión. En este punto se debe hacer mención que el algoritmo RSA puede hacer función tanto de algoritmo de intercambio de claves como de firma digital.
  • Algoritmo de cifrado y la longitud de la clave. Algoritmos simétricos usados para cifrar la comunicación (con la longitud correspondiente de cada algoritmo).
  • Modo de cifrado. Se tratan de cifrados en bloque. Su uso depende del algoritmo de cifrado usado previamente.
  • Hash. Algoritmo de cifrado irreversible que verifica la integridad de los mensajes.
  • Tamaño de la curva elíptica. Esta opción no es obligatoria, y depende del algoritmo de intercambio de claves elegido previamente.

De forma práctica y esquematizando los conceptos anteriores, en la siguiente tabla se listan un conjunto de algoritmos asociados dentro de cada una de sus secciones correspondientes, indicando en color naranja aquellos que no se recomienda su uso (ya sea porque se encuentran obsoletos o porque se consideran inseguros), y en color verde la preferencia de su uso ante otros algoritmos. 
Por otra parte, es importante recalcar que aquellos que se encuentran en color blanco dependen de la combinación que se realice con el resto de algoritmos, para que la suite resultante sea considerada insegura o no. 

Adicionalmente, tenemos que tener en cuenta que hay suites definidas para TLS1.2 que no deben ser usadas en TLS1.3, además de que hay algoritmos considerados legacy que se han eliminado para el uso de TLS1.3 (como SHA-1, RC4, DES, 3DES, MD5, AES-CBC... entre otros).

Si tenéis más curiosidad, podéis encontrar el RFC de TLS1.3 en este enlace :) 

En la siguiente parte de este hilo veremos diferentes formas para comprobar las suites aceptadas por un servidor.

Muchos maullidos!

M