Desactivar entorno gráfico para arrancar Debian en modo Terminal de Texto

Ya que muchas veces omito el modo gráfico de debian.
Esta entrada me sirve a modo de recordatorio de cómo forzar al sistema que sólo arranca en modo texto o terminal, sin arrancar las X.

Para ello:

Editamos Editamos el siguiente archivo de configuración de nuestro servidor gráfico:

$sudo nano /etc/X11/default-display-manager

nos aparece la siguiente línea: /usr/sbin/gdm3
Añadimos un stop al final: /usr/sbin/gdm3 stop

Guardamos los cambios y al reiniciar el equipo éste arranca en modo terminal. Para acceder a tu escritorio gráfico se puede utilizar el comando startx para un acceso puntual o volver a editar el default-display-manager suprimiendo la palabra stop

Cómo usar Metasploit en Armitage desde 0 a modo colaborativo

Hoy vamos a explicar el potencial de Armitage, una interfaz gráfica sobre el conocido framework  de explotación Metasploit, la cual nos va a ayudar en nuestras auditorías, llegando al punto de poder colaborar al mismo tiempo con varios compañeros en nuestro Pentesting. Antes de nada comentar que vamos a usar una máquina atacante con una distribución Kali Linux 2.0 y otra máquina vulnerable Windows como víctima.

Configuración Inicial
Antes de nada vamos a configurar la máquina del atacante. Dado que Armitage trabaja sobre Metasploit y este a su vez trabaja con una base de datos Postgresql, lo primero que debemos hacer es levantar el servicio de la base de datos.

Ahora arrancamos Armitage, donde lo primero que nos pedirá es conectarse al servidor de Metasploit RPC, en caso de que no esté levantado nos preguntará si lo queremos levantar. Acto seguido pedirá los datos de conexión, donde introducimos los datos por defecto que podemos ver en la siguiente imagen.

Configuración por defecto

Primeros pasos

Una vez tenemos Armitage funcionando lo primero que se haría ahora sería escanear la red. Armitage incorpora una función para poder escanearla con Nmap. Para ello nos vamos a la pestaña Hosts → Nmap Scan y aquí elegiríamos el tipo de escaneo, en nuestro caso Intense Scan.

 Introducimos la dirección IP de la red y el CIDR (el nº de unos de la máscara).

Una vez finalice el escaneo podemos apreciar como salen los hosts de nuestra red.

Encontrado vulnerabilidades
Una vez tenemos el esquema de la red y los equipos que podemos encontrar, nos iremos uno por uno a escanear los posibles fallos de seguridad. Para ello le damos clic derecho sobre nuestro objetivo y seleccionamos Scan.

Una vez hecho esto, tendríamos que irnos a la pestaña Attacks → Find attacks.

Con esa funcionalidad conseguimos que se busquen los diferentes exploits que pueden afectar a los diferentes vectores de ataques encontrados en el escaneo. Vemos en la siguiente imagen como se van consultando al servicio de Metasploit.

Una vez terminado nos vamos a la máquina víctima y hacemos clic derecho para ver la opción Attack, donde encontramos las posibles exploits que pueden afectarle a nuestro objetivo.

En nuestro caso es una máquina XP con una vulnerabilidad muy conocida en el puerto 445 (MS08-067) que aunque parezca sorprendente sigue existiendo en muchas máquinas a día de hoy. Aquí os dejo referencias sobre la misma:

• http://www.cvedetails.com/cve/2008-4250
• https://technet.microsoft.com/library/security/ms08-067
• https://www.rapid7.com/db/modules/exploit/windows/smb/ms08_067_netapi

Atacando a la víctima

Ahora que ya tenemos varias ataques posibles podemos elegir el que queramos. Nosotros seleccionaremos el exploit a lanzar en Attack → smb → ms08_067_netapi. Una vez hecho esto debemos configurar las opciones del exploit como haríamos en la consola de Metasploit. 

¿Cómo sabemos que nuestro ataque ha funcionado? Podemos ver en la consola si las diferentes fases del exploit se han ejecutando correctamente y si hemos conseguido alguna sesión de meterpreter, shell... Aquellos equipos que sean comprometidos saldrán marcados como en la imagen.

Explotando el objetivo
Ahora ya tendríamos el control del equipo víctima y pasaríamos a la fase de explotación. Un consejo es crear varias sesiones de meterpreter sobre cada víctima previamente a la explotación por si alguna falla. En cuanto a la explotación en si sólo tendríamos que irnos a la sesión que queremos y elegir qué hacer. En la siguiente imagen vemos como podemos ejecutar un keylogger para ver que escribe la víctima Meterpreter1 → Explore → Log keystrokes.

Tenemos gran cantidad de posibilidades como explorar los archivos, tomar capturas de pantalla de lo que está viendo la víctima en cada momento o incluso obtener las contraseñas que hay almacenas en la RAM.

Modo colaborativo
Una funcionalidad muy interesante de Armitage es el modo colaborativo o lo que se conoce como multiplayer. Básicamente nos permite que varios usuarios compartan la información del pentest a través de la interfaz Armitage, para ello todos se conectan a la misma bbdd compartida en tiempo real, donde se almacenan los diferentes vulnerabilidades encontradas. Esto es muy útil en auditorías internas grandes ya que hace que sea mucho más fácil la coordinación entre el grupo de pentesters.

Además de ver que es lo que hace cada uno, podemos comunicarnos con los diferentes usuarios, así como ver los escaneos y máquinas vulneradas. 

¿Cómo usamos el modo multiplayer?

Básicamente en el modo multiplayer tenemos un Armitage en modo servidor y el resto en modo cliente (arquitectura Cliente-Servidor típica). Lo primero que tendremos que hacer para levantar el servidor es irnos a la carpeta de Armitage, que en Kali Linux está en /usr/share/armitage/ :

Y ahora tenemos que iniciar el archivo teamserver pasándole los parámetros de nuestra IP y la contraseña que queremos ponerle. En nuestro caso la IP es 192.168.0.107 y la contraseña wwh. En la siguiente imagen vemos el resultado de la ejecución así como los parámetros que necesitarán el resto de compañeros para conectarse al servidor.

Ahora ejecutamos Armitage desde los diferentes clientes, tanto desde nuestra máquina como desde las del resto de compañero de equipo. Se puede apreciar en la imagen anterior la IP de la máquina donde está el servicio, el puerto, usuario, contraseña y el Fingerprint del servidor. Una vez ejecutado nos pedirá los parámetros de configuración del servidor de los que hablábamos.

Si las credenciales son válidas nos saldrá lo siguiente:

El Fingerprint del servidor del equipo debe ser el mismo, sino estaríamos conectando a uno diferente. Nos pedirá acto seguido nuestro nick para poder hablar con el resto de compañeros:

En la siguiente imagen vemos en el Log de Eventos de Armitage los diferentes usuarios conectados y lo que están haciendo en cada momento. En la imagen vemos como un usuario ha lanzado un escaneo y todos los usuarios verán los resultados. Los avances que lleven a cabo todo el equipo serán compartidos por todos.

Bueno pues esto ha sido todo, espero que os haya gustado la herramienta. Para el que no me conozca me llamo Rafa Sojo, soy estudiante de "Sistemas Microinformáticos y Redes" y me encanta la seguridad. Os dejo mi twitter por si queréis contactar conmigo.

Un saludo.

@RaSr98

Apache + ModSecurity instalación y configuración

Hoy le toca el turno a ModSecurity.

ModSecurity es un módulo para servidores HTTP (Apache, NGINX y Microsoft IIS) cuyo propósito es reforzar la seguridad de las aplicaciones Web. Es efectivamente un sistema de prevención y detección de intrusos para servidores Web, técnicamente hablando es un Firewall a nivel de Aplicación WAF.

Es de multiplataforma y de código abierto, y lo que nos permite es implementar protecciones avanzadas. Esto significa que es posible filtrar tráfico HTTP, directamente en el servidor Web, según el contenido de las peticiones de los clientes, lo cual permite detectar y bloquear ataques de tipo XSS (Cross Site Scripting), SQLi (SQL injection), session hijacking, etc.

Las características principales de ModSecurity son su capacidad de log y filtrado. El log de auditoría permite almacenar el detalle de cada petición en un archivo de log, incluyendo los payloads de los POST HTTP.

En el post anterior, indicaba cómo podemos configurar un Proxy Inverso con Apache si bien es cierto que hablando con Kino @kinomakino sobre la mejor forma de implementar un WAF, me recomendaba montar el proxy inverso con nginx tal y cómo el lo explica en su blog (http://kinomakino.blogspot.com.es - Ya podrías comprar el dominio Kino :D ) , que tiene bastantes entradas dedicadas a este tema y, todo hay que decirlo, del que estoy aprendiendo a manejarlo y configurar bien las reglas, así que gracias Kino :)

Dicho esto, al lío:

Lo primero que tenemos que hacer es instalar modsecurity, como recordatorio indico que estoy sobre un sistema Debian y la forma de instalarlo en otras distribuciones puede variar, en mi caso:

#apt-get install libapache2-modsecurity

Para verificar que realmente se ha instalado:

#apachectl -M | grep --color security

Una vez ejecutado el comando anterior, nos tiene que devolver algo como:

...security2_module(shared)

Nos indicará que el módulo se ha instalado correctamente, antes de "recargar" la configuración de apache, vamos a hacer un par de cositas más.

En la propia web de modsecurity  existen distintas reglas, algunas gratuitas y otras de pago, yo me he decantado por las reglas OWASP que están dentro de la misma web y en un proyecto de GitHub, la url del mismo https://github.com/SpiderLabs/owasp-modsecurity-crs

Ahora toca descargar dichas reglas, así que lo primero que voy a hacer es crearme un directorio para las reglas dentro de /etc/apache2 llamado crs y es ahí donde voy a descargar mis reglas owasp:

# wget https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master

# tar xzf master

# mv SpiderLabs-owasp-modsecurity-crs-ebe8790 owasp-modsecurity-crs

El siguiente paso es hacer una copia del fichero de configuración:

# cp modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf

Ahora hay que decirle a apache que use el módulo de mod_security. Vuelvo a hacer hincapié en que estoy sobre un sistema debían y que la configuración difiere de algún que otro sistema, en este caso para decirle a apache que use el módulo hay que modificar el fichero ports.conf ubicado dentro del directorio /etc/apache2 y hemos de añadirle las siguiente líneas:

<IfModule security2_module>

    Include /etc/apache2/crs/owasp-modsecurity-crs/modsecurity_crs_10_setup.conf

    Include /etc/apache2/crs/owasp-modsecurity-crs/base_rules/*.conf

</IfModule>

Bien, ya tenemos la instalación del módulo casi lista, ahora nos queda recargar el servicio apache. Así que:

# service apache2 reload

Para comprobar que todo ha ido bien, listaremos el directorio log de apache:

# ls /var/log/apache2

Y veremos que existe un nuevo fichero llamado modsec_audit.log

Hasta ahora hemos instalado y puesto en marcha modsecurity sobre apache y le hemos cargado las reglas de OWASP. Ahora le toca el turno de configuración al propio modsecurity.

Por defecto modsecurity viene configurado en modo DetectionOnly esto que quiere decir, pues que sólo va a ir recogiendo las peticiones sin realizar ningún bloqueo, esta es la opción recomendada para ir viendo cómo funcionan las reglas antes de pasarlo a producción.

Para ver las distintas opciones que nos permite la configuración de modsecurity, editaremos su fichero de configuración que está alojado en /etc/modsecurity y se llama modsecurity.conf

Al editar el fichero veremos una serie de parámetros, los cuales voy a intentar explicar:

• SecureRuleEngine DetectionOnly (esta la comenté anteriormente, así que cuando tengamos todo preparado la cambiamos a On)
• SecuResponseBodyAccess esta directiva es usada para almacenar de forma temporal (yo entiendo que es a modo de cache), lo cual habilita la protección de fuga de datos y demás, lo malo es que el tamaño del registro aumenta. Sus modos de trabajo son On y Off, por defecto está en On
• SecRequestBodyLimit esta directiva indica el tamaño máximo de los POST, si se intenta subir un fichero con mayor tamaño, nos devolverá un error 413 Request Entity Too Large. Para qué nos vale esto, fácil, si nuestra web no trabaja con ningún tipo de formulario de subida de fichero y demás lo podemos bajar. El valor por defecto es de SecRequestBodyLimit 13107200 que son 12.5Mb así que la podemos reducir. Esta directiva trabaja conjuntamente con:
• SecRequestBodyNoFilesLimit que sería el tamaño mínimo de fichero que podemos subir, viene predefinida con 131072 que son 128Kb
• SecRequestBodyInMemoryLimit puedo decir que está es más directa, con ella podemos especificar que cantidad de datos vamos a almacenar en las peticiones (POSTed data) y será almacenada en la memoria ram de nuestra máquina, por defecto viene marcada con 131072 que son 128Kb, un dato a tener muy en cuenta dependiendo de la RAM de nuestra máquina.

Estos parámetros lo podemos modificar a nuestro antojo hasta que demos con la configuración idónea a nuestras necesidades.

Con estas pautas ya tendremos nuestro WAF funcionando.

En el siguiente post lo pondremos a prueba y además, para seguir fortaleciendo nuestro servidor, veremos como funcionan las reglas y analizaremos las mismas con más detalle.

Apache Reverse Proxy

Tras meses y meses sin escribir nada, hoy voy a utilizar esta entrada para tenerla de documentación propia, y si así le ayuda a alguien mejor que mejor.

El caso es que me ví en la necesidad de configurar un proxy inverso para un escenario de pruebas que estoy montando, para posteriormente instalar modsecurity.

Mi escenario sería el siguiente:

En mi caso he usado dos VM con SO debian 8, normalmente para las configuraciones de proxy inverso se suele utilizar nginx pero yo me he decidido por apache que lo conozco más.

Al lío, lo primero es instalar apache en la máquina, eso no lo voy a explicar, entiendo que todos sabemos usar apt-get o aptitude.

Una vez lo tengamos instalado y funcionando es donde tenemos que añadir los módulos de apache para que funcione como Proxy Inverso o Reverse Proxy.

Los pasos a seguir:

• Instalar los módulos necesarios en apache
• Crear un nuevo host 
• Configurar un alias al DNS en el equipo para que apunte hacia el servidor interno
• Habilitar el host y reiniciar el servicio.

Como root y con apache instalado habilitar los siguiente módulos.

#a2enmod proxy proxy_http

Crear el virtualhost

Ahora toca crear el host virtual, en Debian el directorio de instalación de apache está en /etc/apache2

El lugar donde tenemos que configurar nuestro host virtual está en /etc/apache2/sites-enabled 

Dentro de este directorio crearemos el fichero con el nombre que queramos, además tenemos uno como ejemplo que se llama 000-default.com, yo en mi caso al fichero que he creado lo he llamado visibles.conf  y tiene el siguiente contenido.

<VirtualHost *:80>

    ErrorLog "/var/log/apache2/maquina-visible-error.log"

    CustomLog "/var/log/apache2/maquina-visible-access.log" common

    ServerName IP_SERVER_EXTERNO

    ProxyRequests Off

    ProxyPreserveHost On

    ProxyPass / http://HOSTNAME_IP

    ProxyPassReverse / http://HOSTNAME_IP

</VirtualHost>

- ServerName: hace referencia a la máquina que recibe la petición, en este caso sería la máquina que está en la DMZ

- ProxyRequests Off: evita que el equipo de la DMZ sea utilizado como proxy.

- ProxyPreserveHost On: permite que las peticiones recibidas a la máquina de la DMZ sean enviadas a la máquina interna siendo para el usuario transparente. Además, nos aseguramos que el servidor ubicado en la red interna no es accesible desde internet.

- ProxyPass y ProxyReverse: gestionan el salto de ida y vuelta de un servidor a otro.

Ni hace falta explicar que hace falta otra máquina que haga de servidor web para que sea realmente la que muestre la web.

Realmente lo que hacemos es crear un host virtual que redirecciona a otra máquina, de ahí la directiva ProxyPass. Aquí podemos tener tantos host virtuales como queramos para que redireccionen a distintas máquinas.

En el siguiente post instalaremos el WAF ModSecurity y lo configuraremos.