Información blog

Linux, tutoriales, noticias, sistemas, redes y seguridad informática, entre otras cosas.

martes, 30 de mayo de 2017

Cómo extraer una contraseña Windows de la memoria RAM con Volatility y Hashcat en Linux

Anteriormente hice un pequeño artículo explicando cómo poder consultar información de la RAM con GNU/Linux, usando LiME para extraer un volcado de ésta, y Volatility para analizar dicho volcado, pero lo cierto es que si bien dicha combinación es útil, solamente se mostró un atisbo de lo que Volatility puede hacer... Volatility es una herramienta forense de gran potencia que tiene una enorme cantidad de opciones y si bien es obvio que dominar, e incluso conocer, todas es muy complicado, sí que hay una serie de opciones que son, en mi opinión, realmente interesantes. Una de ellas es nada más y nada menos que la extracción de una contraseña.

RAM_portada

Supongamos que nos han dado un volcado de memoria RAM en mano, llamado /root/volcado.dmp, y que no tenemos información alguna de dicho volcado más allá de que procede de un Windows... Es decir que no sabemos siquiera de qué sistema operativo procede... ¿Qué hacer con dicho volcado? Doy por supuesto que Volatility está instalado (en caso contrario recomiendo leer primero el artículo citado arriba); aún así, simplemente para recordar la estructura de esta herramienta, ésta sería:

volatility -f volcado_a_analizar --profile perfil_del_volcado acción

A sabiendas de ésto, lo primero que tendríamos que hacer sería un análisis global de dicho volcado, aunque sea para tener una idea general de lo que tenemos en nuestras manos... En este caso sabemos que el volcado viene de un sistema Windows, pero no sabemos que versión de éste, con lo que lo primero que haremos será una extracción global de la información de la imagen, lo cual se hace gracias a la acción imageinfo, que no requiere de perfil alguno:

volatility -f /tmp/volcado.dmp imageinfo

Volatility_imageinfo
Información global volcado RAM volatility

De aquí el dato más importante para nosotros sería el de "Suggested Profile(s)" ya que éste nos diría qué perfil nos recomienda usar Volatility... En este caso el perfil que usaremos será el de Win7SP1x86... Lo bueno que tiene Volatility es que ya tiene varios perfiles creados que podemos usar a nuestro gusto, si bien la desventaja que tiene es que los perfiles de sistemas Linux tienen que ser creados por nosotros... En este caso no tenemos la necesidad de crear el perfil, con lo que ya podemos extraer la información que queremos con el perfil sugerido.

En este caso en concreto queremos extraer la contraseña, cosa que es más sencillo de lo que parece, ya que solo requiere de un comando:

volatility -f volcado.dmp --profile Win7SP1x86 hashdump > /tmp/hashes.txt

Este comando nos volcará los hashes de las contraseñas de los diferentes usuarios en un fichero llamado hashes.txt alojado en /tmp/; Hashes que obviamente, son completamente ilegibles, al menos en un principio. En mi caso el contenido del fichero hashes.txt sería el siguiente:

hash

O para verlo mejor:

Ivan:1000:aad3b435b51404eeaad3b435b51404ee:b9f917853e3dbf6e6831ecce60725930:::

Con los hashes en nuestro poder, tenemos dos opciones: Instalar Hashcat en nuestra distribución de Linux o usar un equipo/máquina virtual con Kali que tiene dicha herramienta instalada. Por experiencia propia recomiendo la segunda opción, al instalar Hashcat en nuestra distribución habitual (Debian, Ubuntu o derivados...) suelen haber problemas a la hora de ejecutarlo.

Hashcat usaría la siguiente estructura:

hashcat --force -m tipo_hash -a tipo_ataque -o fichero_salida fichero_hash ruta_diccionario --show

Aquí hay dos puntos que hay que tener en cuenta:

El primero es el tipo de hash... Aquí no basta con poner el tipo en modo texto, sino que se asigna mediante un numero que la herramienta asocia a un tipo de hash hay decenas y decenas de tipos de hash, pero aquí basta saber con que el valor numérico que nos vale a nosotros en este caso en concreto es el 1000: NTLM. En caso de querer conocer más tipos de hashes y su respectivos números, recomiendo visitar la wiki oficial: https://hashcat.net/wiki/doku.php?id=hashcat

El segundo es el tipo de ataque... Aquí también se le dice un número para decirle qué tipo de ataque queremos... 0 diccionario, 1 sería híbrido (fuerza bruta y diccionario) y 3 sería por fuerza bruta... El tipo más común sería el híbrido (1), si bien requiere de un diccionario, diccionario que Kali ya tiene incorporado de por sí por defecto. El diccionario que nosotros usaremos se llamará wordlist.txt y en Kali se encuentra en: /usr/share/sqlmap/txt.

Con toda esta información el descifrado de éste hash sería tan sencillo como hacer:

hashcat --force -m 1000 -a 1 -o /tmp/crackeado.txt hashes.txt /usr/share/sqlmap/txt/wordlist.txt --show

Dependiendo de la fortaleza de la contraseña, el resultado tomará más o menos tiempo... En mi caso, al haber puesto una contraseña muy débil el resultado ha sido casi instantáneo... Para comprobar el resultado simplemente habría que consultar el fichero /tmp/crackeado.txt cuyo contenido, en este caso sería:

b9f917853e3dbf6e6831ecce60725930:passw0rd

Lo cual significaría que la contraseña del usuario Ivan sería passw0rd. Ahora bien, tras ver todo este proceso hay varios puntos a tener en cuenta.

El primero es que el proceso de extracción de hash, solamente es aplicable a un volcado de memoria RAM procedente de un sistema operativo Windows, ya que los sistemas GNU/Linux tienen otra forma de trabajar y almacenan los hashes de forma diferente.

Como segundo punto, habría que tener en cuenta que la extracción de un hash puede realizarse de diferentes formas... Aquí se ha mostrado con Volatility con el objetivo de mostrar que la memoria RAM tiene mucha más información de lo que en un principio nos puede parecer.

Otro punto importante es que Hashcat no está limitado a hashes de Windows, puede ser usado para hashes MD5,SHA-216... Es decir que si bien aquí se ha usado con un hash de Windows, con el fin de combinarlo con Volatility, puede ser usado con muchísimos más.

Por último, es importante ser conscientes de que el fin de este procedimiento es ser conscientes de la información almacenada en la memoria RAM y además tener la conciencia de que una contraseña insegura o un cifrado débil, puede tener consecuencias desastrosas...

Espero que este artículo os haya sido útil.

Saludos.

lunes, 22 de mayo de 2017

DNSspoof; qué es y cómo reconocerlo

Existen hoy en día miles de forma de que la seguridad de uno se pueda ver afectada. Desde el reciente escándalo de WannaCry a ataques simples, pero efectivos que si bien son populares y conocidos, siguen siendo efectivos. Existen muchos, pero hoy me centraré en uno de ellos bastante interesante, tanto por su sutileza como por las formas en las que uno puede reconocerlo: El DNS Spoofing.

DNS_spoofing

Lo primero de todo que uno se puede preguntar es: ¿Qué es dicho concepto? ¿En qué consiste? Primero de todo hay que tener claro que la función del DNS (Domain Name Service) es la conversión de un nombre de dominio (el nombre de una web, por ejemplo) a una dirección de IP; por defecto toda comunicación entre equipos se realiza vía IP, pero debido a que recordar éstas es muy difícil para un humano, los DNSs hacen que solamente tengamos que recordar nombres; encargándose éste de la traducción. Es decir que lo que haríamos sería preguntar al DNS qué IP tiene el nombre de dominio al que queremos acceder, ya sea Facebook, Google, este blog o cualquier página a la que queramos acceder. Para tener más claro este concepto he aquí el siguiente esquema, que resume el funcionamiento de forma muy simplificada:

Diagrama_DNS
Diagrama DNS

La cuestión está que estas peticiones pueden ser interceptadas y ser redirigidas a otro lugar con el fin de engañar al usuario... Es decir que el DNS puede ser suplantado o spoofeado para que a la hora de decirle al equipo la IP del nombre de dominio, en vez de darle la IP correspondiente le de una falsa para que el equipo acceda a ésta. El pequeño esquema simplificado de a continuación puede ayudar a aclarar este punto:

diagrama_dns_spoof
Diagrama DNS spoofing

Esta suplantación puede parecer complicada, pero desgraciadamente no lo es tanto; solamente requiere de las herramientas adecuadas... La prueba de concepto de a continuación se ha realizado con un equipo Debian como atacante/suplantador, pero puede hacerse con cualquier otra distribución de Linux. Imaginemos que tenemos un equipo de sobremesa normal y corriente (no importa el S.O que esté usando) y otro equipo con Debian instalado... ¿Cómo puedo hacer con Debian para que el otro equipo acceda a una IP bajo mi control cuando quiera acceder a una página web conocida (Facebook, Twitter, Google...)?  Las IPs que usaré a modo de prueba serán la 192.168.1.1 (router), 192.168.1.2 (equipo que queremos que se dirija a otro DNS) y la 192.168.1.3 (equipo atacante).

Lo primero que hay que tener instalado en Debian sería el paquete dsniff, que incluye un conjunto de herramientas que incluye una serie de utilidades de pentesting, entre otras, estarían utilidades para ataques de Man in the middle y DNS spoofing. Esto es tan sencillo como hacer:

apt-get install dsniff

Con las herramientas en nuestro poder, el primer paso para suplantar el DNS sería el realizar un ataque de man in the middle entre el equipo victima (192.168.1.2) y el router (192.168.1.1) para así manipular más adelante el tráfico entre ambos. Hay varios tipos de ataques (para más detalles podéis acceder al link anterior) pero el que usaremos en esta ocasión será el arp spoffing, el cual consiste de únicamente 3 comandos:

El primer comando para realizar el ataque con éxito, sería la activación de reenvío de paquetes en la máquina atacante para que así al lograr realizar el ataque con éxito, no se corte la comunicación:

echo 1 > /proc/sys/net/ipv4/ip_forward

Ahora pasaríamos a realizar un envenenamiento de la tabla ARP tanto del router como del equipo, lo cual obedece a la sintaxis:

arpspoff -i interfaz_red -t equipo1 equipo2
arpspoff -i interfaz_red -t equipo2 equipo1

Lo que si lo aplicamos a este caso en concreto sería:

  1. arpspoff -i eth0 -t 192.168.1.2 192.168.1.1
  2. arpspoff -i eth0 -t 192.168.1.1 192.168.1.2

Con el ataque de man in the middle realizado, ahora tocaría tener claro qué nombre de dominio queremos suplantar y a qué IP lo queremos dirigir... Por ejemplo podemos decirle a la victima que cuando pida la IP del nombre de dominio facebook, la IP no sea la de facebook sino la del equipo atacante... Para ello, antes de nada vamos a crear un fichero llamado, por ejemplo, dominio_falso.txt con el siguiente contenido:

192.168.1.3  facebook.es

Este txt estaría diciendo que la IP de facebook.es sería la 192.168.1.3, es decir la IP del equipo atacante; ahora obviamente habría que hacerle creer a la victima que en efecto el nombre de dominio hace referencia a dicha IP.

dnsspoof -i eth0 -f dominio_falso.txt

Esto haría que toda petición realizada al nombre de dominio facebook.es, será redirigida a la IP falsa, IP que sería en este caso la del atacante. Este atacante tendría que tener un servidor web levantado con una apariencia similar al nombre de dominio original, cosa que se podría conseguir con herramientas especializadas tales como SET (Social Engineering toolkit), pero el objetivo de este post no es enseñar cómo hacer que la apariencia del sitio web falseado sea lo más "realista" posible, sino demostrar la relativa facilidad con la que se ha podido interceptar la petición DNS, con lo que no ahondaremos en dicho tema...

Obviamente lo suyo sería que el ataque hubiese sido bloqueado por herramientas de análisis de red o por diferentes políticas de seguridad pero... ¿Cómo podemos saber que el sitio web al que hemos accedido es el autentico? Hay diferentes cosas que se pueden tener en cuenta:

  • Ping: Al hacer ping al sitio web, veríamos que la IP no corresponde a una de las IPs pertenecientes a la web; es más para este ataque estaríamos viendo que al hacer ping a facebook estaríamos viendo que se está haciendo ping a una IP de clase C, usada para redes locales, cosa que no tiene sentido en una web pública.
  • Certificado: Los portales de login del 99% de los sitios web usan certificados SSL para securizar la conexión; si vemos una pantalla de login sin certificado alguno (es decir, si vemos que la web es HTTP y no HTTPS), habría que salir de allí de inmediato. Algunos ataques de DNSspoof usan certificados SSL hechos por ellos mismos, pero son certificados no validados por entidades certificadoras con lo que el navegador diría que la web estaría usando un certificado cuya veracidad no esté asegurada.
  • Analizador de red: Si usamos un analizador de red, podemos ver que habrá una brutal cantidad de paquetes arp fluyendo en nuestra interfaz de red, pues los ARP spoofing son muy agresivos y veremos, que no solo hay muchas ARP requests y replies ¡Si no que veremos que la MAC del atacante está duplicada y que pertenecerá a su propio equipo y al router!
  • ARP: Si consultamos nuestra tabla ARP con arp -n (Linux) o arp -a (Windows) veremos que habrá una MAC que pertenecerá a dos IPs distintas, lo cual será indicativo de haber sufrido un Man In The Middle.
  • DNSSEC: En caso de tener un DNS propio que esté protegido por DNSSEC, podemos verificar que nuestro DNS es efectivamente el que tiene que ser mediante el comando: dig DNSKEY nombre_dominio +multiline

Como veis existen diferentes recursos para comprobar la veracidad del sitio al que queremos acceder; desafortunadamente la mayoría de ellos requieren ser algo paranoico y que se realicen varias comprobaciones antes de entrar a un sitio, si bien eso no significa que dichas comprobaciones no sean recomendables, ya sea para este tipo de ataques u otros.

Espero que os haya resultado útil.

Saludos.

miércoles, 10 de mayo de 2017

Cómo manipular el rendimiento de la CPU en Linux

El rendimiento de la CPU es algo que, dependiendo de la situación, puede resultar de vital importancia... A veces necesitamos que ésta actué de una forma distinta a la habitual y queremos sacarle el máximo partido para que se adapte a nuestras necesidades de la mejor forma posible... En el último artículo he hablado sobre la priorización y reserva de núcleos del procesador, cosa que nos puede resultar útil para sacarle el máximo partido, pero en este caso voy a hacer referencia a otro punto... A la manipulación frecuencia de las CPU dentro de Sistemas GNU/Linux.

CPU_Portada

La CPU puede trabajar a mayor o menor rendimiento si bien dependiendo la configuración que tengamos implantada en el equipo podemos tener una CPU a la que no estemos sacando partido, una CPU que está trabajando siempre a pleno rendimiento sin necesidad o una CPU cuya frecuencia varíe dependiendo del uso de la "demanda" del sistema. Cada una tiene sus ventajas y desventajas... A veces nos interesa tener la CPU trabajando siempre al mínimo, ya que puede ser que estemos usando un portátil y queramos que el consumo de batería sea bajo, además de que el tener la CPU en  un sistema de refrigeración "pobre" como el de un portátil (por ejemplo) hace que uno tema sobre-calentarla.

Todo esto es posible en cualquier sistema Linux, si bien dependiendo de las características del equipo que estemos manipulando, podremos hacer una serie de modificaciones u otras. Para poder hacer estas modificaciones tendremos que tener instalado el paquete cpufrequtils, el cual puede ser instalado desde los repositorios tal que así:

apt-get install cpufrequtils

Con este paquete y sus correspondientes dependencias instaladas, podríamos pasar a la manipulación de la CPU, cosa que no depende de comandos, sino del propio sistema, ya que los ficheros encargados de las tareas de la CPU estarían en: /sys/devices/system/cpu/cpuX/cpufreq/. Allá donde X haría referencia del número de núcleo que queremos modificar, pues esta modificación debe de ser hecha núcleo por núcleo... Si tuviese un sólo núcleo tendríamos solo cpu0, si tuviésemos dos cpu0 y cpu1 y así sucesivamente...

En este directorio veremos varios ficheros, de los cuales hay dos en especial que nos interesarían: scaling_governorscaling_available_governors.

El primer fichero contendría el comportamiento actual del procesador, mientras que el segundo mostraría todos los comportamientos disponibles para el susodicho... Aquí, tal y como he comentado antes, podemos encontrar diferentes opciones dependiendo de nuestro equipo, pero... ?Qué opciones tenemos y qué significa cada una de éstas? He aquí una explicación de cada comportamiento:


  • performance: Con esta opción lo que haríamos sería que el equipo trabajase con la CPU siempre con la frecuencia máxima. Esto no es demasiado recomendable a menos que se tenga un equipo alimentado a la corriente eléctrica y que tenga un buen sistema de refrigeración.
  • powersafe: Esta opción suele estar puesta por defecto en el scaling_governor de los portátiles, ya que tiene como objetivo que la CPU tenga la menor frecuencia posible y así consuma la menor batería posible al mismo tiempo que el equipo tendría menor riesgo de sobrecalentamiento.
  • ondemand: Sube o baja la frecuencia de la CPU dependiendo del uso de ésta... A mayor el uso de procesador, mayor la frecuencia y viceversa. Es la opción más popular y fiable de todas.
  • conservative: Actúa igual que Ondemand, con la diferencia de que este último realiza el cambio de frecuencia de forma paulatina, mientras que el anterior realiza el cambio de golpe.
  • userspace: Permite que un usuario con privilegios (como root) manipule a mano la frecuencia de la CPU... Esta opción no es demasiado fiable ya que da pie a que alguien introduzca un valor erróneo o un valor que empeore el rendimiento global del sistema.

Para cambiar el comportamiento de la CPU, solamente habría que introducir uno de los mencionados arriba en el fichero scaling_governor. Por ejemplo, si deseásemos que la CPU siempre trabajase al máximo y dicha opción apareciese en scaling_available_governors, ejecutaríamos el siguiente comando como root:

for i in /sys/devices/system/cpu/cpu[0-$(cat /proc/cpuinfo |grep 'processor' |wc -l)]/cpufreq; do echo 'performance' > $i/scaling_governor; done

Con este comando haríamos el cambio en todos los núcleos al mismo tiempo en vez de ir uno por uno realizando el cambio con el riesgo de dejarnos alguno por el camino. El problema que tiene el realizar el cambio de dicha forma es que en caso de reiniciar el equipo, los cambios realizados se perderían, cosa que generalmente no desearemos... Para evitar dicho problema, tendremos que hacer dicho cambio persistente, lo cual afortunadamente es muy sencillo, pues simplemente habría que crear un fichero llamado cpufrequtils dentro del directorio /etc/default y he introducir allí el valor GOVERNOR="comportamiento_deseado"; por ejemplo podríamos hacer:

  1. touch /etc/default/cpufrequtils
  2. echo 'GOVERNOR="ondemand"' > /etc/default/cpufrequtils

Gracias a esto, el comportamiento de la CPU sería el especificado por dicho fichero.

Si queremos saber exactamente a qué frecuencia estaría actualmente trabajando la CPU tendríamos que revisar el fichero cpuinfo_cur_freq dentro del mismo directorio que los dos ficheros anteriores, es decir en: /sys/devices/system/cpu/cpuX/cpufreq/. Dicho fichero mostraría la frecuencia en la que está trabajando el núcleo en MHZ, y se podrían consultar los ficheros correspondientes a todos los núcleos con el comando:

for i in /sys/devices/system/cpu/cpu[0-$(cat /proc/cpuinfo |grep 'processor' |wc -l)]/cpufreq; cat $i/cpuinfo_cur_freq; done

Si modificáis el valor de scaling_governor y luego consultáis el fichero cpu_cur_freq, veréis que su valor varía dependiendo del comportamiento introducido en el primer fichero, con lo que con cada modificación que se haga, uno se puede hacer una idea de a qué frecuencia se trabaja dependiendo del comportamiento seleccionado.

Como veis, la manipulación de la frecuencia de la CPU no es tan complicada como parece, simplemente hay que conocer los diferentes comportamientos y decidir cual de ellos se ajusta mejor a nuestras necesidades.

Espero que os haya resultado útil.

Saludos.