En esta ocasión indicaré el uso de W3AF para evadir sistemas de detección de intrusos y sistemas de prevención de intrusos (IDS/IPS), en este caso concreto, se intentará indicar las pruebas que se han realizado contra Snort ejecutándose como NIDS. Para esto se utilizan técnicas de evasión en W3AF (en algunas ocasiones accediendo y modificando directamente el código del proyecto que se encuentra escrito en Python). Estas técnicas ejecutan procedimientos de evasión partiendo de la base que muchos de los IDS/IPS del mercado detectan amenazas en función a determinadas “firmas” o patrones de comportamiento que son identificados como anómalos o maliciosos. Los “tips” de evasión presentados aquí lo que realmente hacen es modificar las peticiones realizadas a un servidor web para que dichas peticiones no se ajusten a los patrones que esperan los IDS/IPS.
Mes: febrero 2012
En la entrada anterior se han establecido las bases para utilizar Nmap y ejecutar un ataque de reconocimiento de forma “sigilosa”, evadiendo mecanismos de seguridad en el objetivo y evitando ser detectados en nuestras acciones, en este orden de ideas, anteriormente se han definido algunas de las opciones disponibles en Nmap para este propósito, inclusive se utilizó una técnica muy efectiva conocida como Idle Scan.
En esta ocasión, se intentará evadir las reglas y preprocessors de Snort para que de este modo, el escaneo efectuado contra el objetivo, sea lo mas silencioso posible, tratando de no despertar sospechas ni levantar ninguna alarma de las definidas en Snort (con las reglas y opciones de los preprocessors correctamente configuradas). Con esto en mente, se intenta utilizar diferentes opciones de Nmap para realizar el escaneo a diferentes máquinas en el segmento de red (Snort se ejecutará como NIDS) de esta forma se medirá el nivel de eficiencia de Snort y las opciones de configuración disponibles ante las diferentes técnicas de evasión existentes en NMAP.
Existen distintas técnicas que permiten conocer cuales puertos se encuentran abiertos en una máquina remota, cada una estas técnicas utilizan distintos tipos de envío de paquetes y protocolos, sin embargo, cuando hay un Firewall o un IDS de por medio, lo más probable es que los escaneos sean infructuosos, dado que la salida más frecuente, será precisamente ver todos los puertos bloqueados. Por ejemplo, si ejecutamos un clásico escaneo de puertos contra una máquina windows sin un firewall activo, podríamos ver lo siguiente:
VBSMEM es un encoder incluido en las versiones de MetaSploit FrameWork superiores a la 3.8, nace de la necesidad de una solución al problema que se enfrentar los pentesters a la hora de generar payloads con msfpayload, codificarlos múltiples veces con msfencode para que al final, sean detectados por el AV en la maquina objetivo y no sea posible obtener una sesión meterpreter, lo que desde luego, es bastante frustrante. Se basa en la idea de que, los payloads con VBScript no son detectados por los AV actuales, esto ocurre, porque se ejecutan en memoria y no realizan ningún tipo de operación de escritura en disco, evidentemente el AV confiá en el contenido de una macro que se ejecute dentro de un programa de Microsoft Office (por ejemplo), esto se ha detallado hace unas cuantas entradas, para revisar dicha entrada ver aquí http://thehackerway.com/2012/02/13/intentando-evadir-anti-virus-usando-metasploit-framework-y-visual-basic-contra-plataformas-windows-parte-ii/ tomando este enfoque, se ha implementado el encoder VBSMEM, el cual escribe un shellcode en un fichero VBScript el cual utiliza una librería llamada Dynawrap.dll la cual ejecuta llamadas nativas del sistema operativo en concreto las funciones:
1. VirtualAlloc: Separar un espacio en memoria para la ejecución del shellcode.
2. WriteProcessMemory: Copiar el shellcode en el segmento de memoria separado.
3. CreateThread: Ejecutar el shellcode cargado en memoria.
Por lo demás, para el funcionamiento de este encoder, se utilizan las mismas técnicas de ofuscación para VBScript para ocultar el Shellcode actual de un software AV en la máquina objetivo, la ventaja de esto es que se crea un fichero ejecutable (.vbs) con las mismas características de ofuscación de un fichero en ms office con una macro maliciosa, por lo tanto no es detectable (al menos a día de hoy) por ningún AV del mercado. Los pasos a seguir para conseguir esto son los siguientes:
Existen diferentes técnicas para el establecimiento de una conexión entre dos máquinas que se encuentran separadas y condicionadas por un firewall que evita que determinados puertos, protocolos y/o hosts puedan establecer conexiones, aunque se trata de un mecanismo bastante eficiente, en muchas ocasiones estas reglas no restringen absolutamente todo por diferentes razones, como por ejemplo, la necesidad de tener determinados puertos abiertos para realizar conexiones a un servicio externo, entre otras cosas. Esta situación es bastante frecuente en algunas organizaciones, donde alguna de las aplicaciones internas necesita acceso a un servicio externo y para este fin se debe dejar abierto uno o varios puertos. En este escenario se puede realizar un ataque de “fuerza bruta” en busca de una conexión pasando por el firewall, para este fin se utilizan los payload windows/*/reverse_tcp_allports que intentan capturar alguno de estos puertos abiertos e iniciar la transferencia del stage.
En la entrada anterior se ha indicado como crear un instalador DEB malicioso utilizando msfpayload, lo que ha permitido obtener una consola en la máquina remota que se deseaba atacar.
Partiendo de la publicación anterior, se intentará crear un programa simple que acceda a la información de todos los usuarios del sistema y dicha información se intentará enviar a una máquina remota por medio de un socket. A continuación se indica paso a paso, el uso de algunas librerías propias en C/C++ (en concreto, contenidas en el paquete libc y build-essentials) y como se ha codificado está pequeña puerta trasera. El objetivo de lo que se indica a continuación, es solamente para fines ilustrativos, no se tienen en cuenta factores de seguridad vitales en la máquina atacada tales como firewalls, AV y/o IDS, de esta forma, un hacker con conocimientos medios en programación puede darse una idea de la cantidad de operaciones que puede llevar a cabo en una máquina objetivo con un vector de ataque como este.
En entradas anteriores sobre Payloads en MetasSploit, se ha hecho énfasis especial sobre Payloads contra plataformas Windows y como estos conseguían burlar la seguridad de la víctima. En esta ocasión se intentará indicar el procedimiento que frecuentemente se lleva a cabo para conseguir estos mismos resultados sobre plataformas GNU/Linux, en este caso particular sobre distribuciones Debian/Ubuntu por medio de envenenamiento de paquetes de instalación (*.DEB)
El procedimiento es muy sencillo, a continuación se listan los pasos que se deben de llevar a cabo para conseguir una consola remota usando un DEB infectado.
En la anterior entrada, se ha indicado la forma de realizar un “bypass” utilizando MetaSploit Framework y una plantilla simple escrita en lenguaje C, en esta ocasión, se intentará explicar la forma de “infectar” un documento de MicroSoft Office (word, excel, etc.) por medio de una macro maliciosa generada por metasploit framework, la virtud de tipo de ataques es que no son detectables por un AV, ya que los AV normalmente suelen confiar en el contenido que se ejecuta dentro de los procesos de programas instalados y frecuentemente utilizados, (como en este caso un programa ofimatico) lo que le permite a un atacante enviar un documento malicioso a un usuario con el fin de comprometer su máquina, no obstante, existen mecanismos de seguridad en Office que no permite la ejecución de Macros, pero si el documento es generado directamente por el atacante y enviado a la víctima, evidentemente el nivel de seguridad que intentará establecer para el documento será bajo de tal forma que cuando el objetivo del ataque abra el documento, no encontrará nada sospechoso en él.
Esta es la primera de una serie de entradas que intentarán indicar las técnicas de hacking que frecuentemente se utilizan con el fin de comprometer una maquina remota que implementa mecanismos de seguridad y restricciones que dificultan las labores de penetración de un pentester o un hacker, en esta serie de entradas se indicará como es posible evadir dichas restricciones (restricciones de AV, IDS o Firewalls).
En muchos casos nos encontramos con la necesidad de distribuir un backdoor o cualquier tipo de troyano en una maquina objetivo con el fin de tener acceso a los recursos de dicha máquina para ejecutar alguna clase de tarea, sin embargo, estos son fácilmente detectados por antivirus como NOD32, AVG, Norton, etc. Esto ocurre debido a su gran cantidad de registros e información relacionada con virus, troyanos, puertas traseras, etc. Ademas de los mecanismos que incorporan para detectar de forma efectiva algún tipo de amenaza que pueda representar un riesgo para el sistema. Un antivirus frecuentemente verifica si un fichero representa un riego o no por medio de determinadas firmas o “signatures” que tiene un programa ejecutable, estas firmas corresponden a una serie de patrones de comportamiento que tiene el programa, estos patrones son obtenidos por un antivirus por medio de un proceso de desensamblaje que convierte el código ejecutable en código en ensamblador, si dentro de este código, existe al menos una de las firmas registradas en el antivirus, este programa es marcado como no fiable, ya que probablemente se trate de un troyano o algún otro tipo de amenaza.
Aunque en esta serie de entradas se ha profundizado principalmente en TOR, I2P y FREENET, existen muchas más soluciones que van por la misma linea y que intentan preservar la privacidad de sus usuarios, no obstante en esta serie de publicaciones se ha optado por explicar las 3 soluciones anteriormente indicadas principalmente por las siguientes razones:
-
Estabilidad.
-
Volumen de usuarios
-
Funcionalidades
-
Resistencia a la censura.
Actualmente TOR, I2P y FreeNet son las redes que se encuentran en un estado más avanzado en los puntos anteriores, por lo tanto no se puede desestimar ninguna ni pretender que alguna es “superior” a otra, siempre es necesario tener presente que se trata simplemente de herramientas que intentan conseguir el mismo fin: Preservar el anonimato y la privacidad de sus usuarios. Sin embargo, cuando alguien desea que sus “acciones” sean anónimas, necesita conocer muy bien estas soluciones y determinar cual se ajusta a sus necesidades concretas, en algunos casos, los usuarios se decidirán por el uso de TOR dadas sus capacidades de “Outproxy” mientras que otros preferirán I2P o FREENET por sus capacidades de “Inproxy” y VPN, se trata simplemente de una decisión que el usuario debe tomar en un momento determinado dependiendo de lo que quiera hacer. No obstante es importante en este punto resaltar y comparar las principales funcionalidades de estas 3 redes con el fin de proporcionar un “marco de decisión” más amplio al usuario final e identificar cuales son los puntos fuertes y los puntos débiles de cada una de estas soluciones con respecto a las otras.
