lunes, 27 de octubre de 2014

Hacker? Hacker Etico? Auditor? y qué mas os da el nombre?

Seguro que todos habéis leído la publicación por la RAE de la inclusión de varios términos, en concreto HACKER referenciado como pirata informático.

Me hace mucha gracia el revuelo que ha creado esto en la comunidad de seguridad informática y he decidido expresar aquí mi opinión al respecto.

Pregunta a cualquier persona ajena a este mundo, que significa la palabra HACKER. ¿Qué te va a responder? pirata informático. En la televisión, en el cine, en las entrevistas, en todos los medios ajenos al propio colectivo, el término HACKER implica consideraciones "ilegales".

Como digo, estos términos se emplean en medios AJENOS, aunque en muchas ocasiones dentro de nuestro colectivo.

Voy a hacer un paralelismo con algo similar, con lo que llevo luchando toda mi vida, y con el paso de los años he aprendido a gestionar, a no hacer caso, ya que no soy muy purista con el lenguaje, y mucho menos con la tendencia a clasificar y etiquetarlo todo.

Desde que tengo uso de la razón ( realmente hace muy poco tiempo  :-) ) he sido y soy un apasionado del Hip Hop. Desde que era pequeño escucho música RAP. Me siento parte del colectivo Hip-Hop, un movimiento reivindicativo, anti-sistema, un medio de expresión artística mediante el graffiti, el rap,dj´s y el break dance.

Cuando alguien de mi entorno conocía esta afición, siempre me han asociado con "El principe de Bell Air". Ese estilo de ropa "cagada", americana, con gorra, incluso la mayoría de la gente al descubrir estos gustos, imitaban saludos "raperos" con gestos de manos etc.

Si piensas en Rapero o Rappers, seguro que piensas en esa imagen.


Un rapero es aquel que canta Rap. Punto. El termino está desvirtuado por los medios ajenos, que no tienen ni idea. A mi, ME DA IGUAL lo que la gente opine, y como quieran llamarme. Lo que si es seguro es que mi estilo de vestir no tiene nada que ver con el que se supone que debería tener un rapero.

Si piensas en un rockero, no piensas en una persona que le gusta el Rock, casi seguro que pienses en un tipo con pelos largos, camisetas oscuras, conciertos y posiblemente cerveza/calimocho en mano.


Voy a ir más allá, Disc Jockey. En la RAE lo identifican como "pincha discos". Entonces, los DJ de ahora que pinchan música con el pc, no son DJ? Si le preguntas a un purista en la materia, te dirá que si no usas Vinilo no seas DJ, pero TODO el mundo llama DJ a cualquier persona que mezcla canciones, analógico o digital.

Para la gente con pensamientos políticos de izquierdas, la derecha es FACHA, pija.


Para la gente con pensamientos políticos de derechas, la izquierda es Perroflauta, hippie.


Alguna vez has usado?:
  • No hay moros en la costa.
  • Vas hecho un gitano.
  • Trabajas más que un negro.
  • etc.

Volviendo al término Hacker. Para mi, un hacker tiene varias connotaciones. Metiéndome en la piel de mi profesión, el término Hacker es el que todos conocemos, quizás el famoso debian-hacker, que se puede resumir como una persona con inquietudes más allá del funcionamiento deseado por un sistema, descubriendo nuevas funcionalidades, restricciones, etc.

Si me meto en la piel de un ciudadano de la calle, tengo que asumir, que Hacker es un pirata informático.

Me parece genial distinguir entre Hacker y Hacker ético, porque no siendo PURISTA, representa el término Hacker, orientado a hacer el bien o el mal.

Por poco que nos guste, en la sociedad en la que vivimos, el término Hacker está asociado a que te roben la clave de Hotmail, el perfil de Facebook, o las conversaciones de Whatsapp del novio/a de turno. Tanto os preocupa?

Cuando voy a un congreso de seguridad informática y escucho las típicas bromas sobre Windows, yo no monto en cólera y "lucho" por aquello que creo: tu Windows es malo porque TU no sabes usarlo. Pues no, me la trae al paire. Con esto me pasa lo mismo, es más, me parece super curioso que la gente se mueva con esto.

Para mi, mi profesión es la administración de sistemas, de manera segura, quizás un poco de seguridad informática, medidas defensivas ,en las que me toca conocer las medidas ofensivas, pero ni por allá paso me considero un Hacker, ni ético ni no ético.

Creo que de toda la comunidad que sigues, seguimos, hay muy pocos hackers, y la mayoría somos profesionales de la seguridad. Por eso, no se por qué tanto revuelo.

Voy a ir más allá. He leído que el Sr. Alonso ha creado una iniciativa para cambiar este término. Bien, siendo purista, el blog no se llama "un informático en el lado DEL MAL" ? todos sabemos que es una broma, una manera de escribir, con cierto gancho, pero todos sabemos que Chema Alonso no hace el mal, sino el bien. Nos ponemos puntillosos con el nombre del blog?

He hecho un pequeño muestreo con Google hacking... de los sitios de seguridad informática más populares en castellano, los que admiro, sigo y aprendo a diario y en casi todos he encontrado referencias erròneas el término hacker, es decir, nosotros mismos lo empleamos supuestamente MAL.

Se que soy yo, que por mi manera de pensar, me da igual con que palabra me encasillen, ya que lo que realmente me preocupa es mi carrera profesional, mis inquietudes, y lo que la gente me diga no me preocupa, pero insisto, me parece de risa que os preocupa tanto esto.

Gracias por leerme, qué opinas tu? o mejor dicho, que transcendencia tiene que gente que no sabe de nuestro oficio, no emplee los términos exactos? realmente no te identificas con Hacker ético?


Qué hace un CISO aparte de ver gatitos en Internet?

En la entrada de hoy voy a comentaros algunas de las labores que debería realizar un CISO (Chief Information Security Officer).

Tanto si eres uno de ellos, o quieres serlo, o simplemente eres un administrador de sistemas sin tantas siglas, seguro que alguno de los ámbitos te recuerda que hoy debes mirar los logs :-)


Seguramente los consultores de RRHH especializados en esta área deben conocer, con lo bien que hacen su trabajo, pero bueno, si alguno cree bien usarlo, que lo use, es gratis.


  • PREVENCION DE AMENAZAS.
    • Seguridad de aplicaciones.
    • Gestión de vulnerabilidades.

  • DETECCION DE AMENAZAS.
    • Gestión de LOGS, correlación, SIEM.
    • Gestión de ALERTAS, file integrity monitor, AV, WAF, IDS/IPS, etc.
    • Data Lost Prevention.

  • GESTION DE INCIDENTES.
    • Respuesta ante incidentes,
    • Relación con los medios.
    • Investigación forense.

  • GESTION DE LA IDENTIDAD.
    • Cuentas, usuarios, contraseñas, 2AF, roles,integración con RRHH. 

  • GESTION DEL RIESGO.
    • Seguridad física.
    • Pentesting.
    • Revisión de código.
    • Políticas y procedimientos.

  • ASPECTOS LEGALES.
  • AUDITORIA Y CUMPLIENTO DE ESTANDARES.
  • ARQUITECTURA DE SEGURIDAD.
    • Redes.
    • Aplicaciones.
    • Acceso remoto.
    • Tecnologías de cifrado.
    • Backup, recuperación, plan anti-desastres.

  • REQUISITOS DEL NEGOCIO.
    • Presupuestos.
    • SLA.
Espero que os sirva de ayuda, para ampliar más información en todas estas áreas de conocimiento o trabajo que todo buen CISO debe gestionar.

Gracias por leerme !!!

jueves, 23 de octubre de 2014

Reglas para Mod Security Free. Comodo y Atomic.

Como vimos en la pequeña introducción del anterior capítulo, cuando hablamos de Mod Security debemos hablar de un conjunto de reglas que sirvan de patrón al WAF para detectar intrusiones.

En esta entrada os voy a comentar simplemente un par de recursos disponibles, de manera gratuita, para nuestras implementaciones de Mod Security.


La primera es el conjunto de reglas del firewall Comodo para Mod Security.
Debes realizar el registro para descargar las reglas.

Si en tu fichero de configuración de Mod Security tienes algo como así:

<IfModule mod_security2.c>
    # ModSecurity Core Rules Set configuration
        Include modsecurity.d/*.conf
        Include modsecurity.d/activated_rules/*.conf

    # Default recommended configuration
    SecRuleEngine DetectionOnly

Pues simplemente copia los ficheros en esa ruta y realiza un service httpd reload (o similar) para que cargue las reglas.

Os recomiendo realizar esta gestión en un entorno de pre-producción o testing, para no cortar el tráfico legítimo.

Si simplemente estas jugando, puedes habilitar el DetectionOnly para revisar el comportamiento de Mod Security, sin cortar tráfico. repito, SIN CORTAR TRAFICO !!!.


El otro conjunto de reglas que vamos a incorporar es la versión de trial de 30 días de Atomic Corp.
Podemos registrarnos y descargar el conjunto de reglas. Podremos usarlas ilimitadamente, pero no podremos actualizarlas pasados los 30 días.

El link de descarga es este.

Algunas de las utilidades que empleo es apachectl configtest Cuando haces un restart del servicio Apache puedes ver los errores que pueden producir que no arranque Apache, como por ejemplo un problema con alguna de las reglas. Cuando realizas un reload, el comando no tira ninguna opción, por lo que si tienes algún problema debes usar apachectl configtest para delimitar el problema.

Por ejemplo, si cargas las reglas Atomic, una buena recomendación es hacerlo de fichero en fichero, para ir haciendo Reload y validando reglas. Si copias el fichero 10_asl_rules.conf, el de mas tamaño, tendrás un problema al hacer Reload.

service httpd reload
Reloading httpd: not reloading due to configuration syntax error
                                                           [FAILED]

Con el comando:

apachectl configtest
Syntax error on line 241 of /etc/httpd/modsecurity.d/activated_rules/10_asl_rules.conf:
Error creating rule: Could not open phrase file "/etc/httpd/modsecurity.d/activated_rules/sql.txt": No such file or directory

Vamos a hacerle caso y a copiar tambien el fichero en cuestión. Hacemos service httpd reload y bingo, recarga apache.

Ahora a mi me gusta hacer un tail  y revisar el log que tira, buscando las nuevas reglas.
tail -F /var/log/httpd/modsec_audit.log |grep -A8 -B17 10_asl_rules


Con la salida del grep A8 y b17 saco las lineas after y before de encontrar el nombre de la regla, para ver la IP, y el resto de reglas que han podido saltar. Lanzo un Nikto y veo que ocurre.

Como podéis apreciar, me saltan 3 reglas, las de Comodo, las de Atomic, y una regla custom que yo tenía creada "parecida". Ya que no vamos a actualizar las reglas Comodo/Atomic por su restricción "trial", podemos modificar directamente el fichero de reglas y comentar las que no nos interesen. Recuerda que cuantas menos reglas procese Apache, mas ligero correrá. Aparte, me hace difícil gestionar esa regla en mi consola OSSIM.

Mando el tail a un fichero, y lanzo Nikto, w3af, openvas, wpscan, joomscan, o cualquiera de las tools que quieras comprobar. Con esta gestión, podemos depurar las reglas para darles un poco mas de coherencia al uso de 3 motores de reglas.


El siguiente paso sería realizar varios circuitos funcionales, para detectar falsos positivos. Realizar una compra, escribir un post, subir una imagen, cualquier proceso que ocurre legítima en tu aplicación web.

Recuerda que como trabajamos en DetectionOnly no estaremos cortando tráfico legítimo.

Una de las inquietudes que se plantean con este sistema es en entornos de producción en los cuales se trabaja directamente con el entorno, sin pre-producción o testing, corremos el riesgo de modificar cualquier comportamiento en nuestra aplicación que haga que alguna regla haga MATCH, días después de haber validado la regla, por lo que se hace casi imprescindible tener con un entorno de validación, algo lógico pero no siempre puesto en práctica por la mayoría de PYMES.

Tanto si te toca defender tus aplicaciones, como si realizas labores de pentesting, recomiendo contar con un entorno de WAF para comprobar como se detectan los ataques que sufrimos/producimos.

Como siempre, espero que os guste y gracias por leerme !!!










jueves, 16 de octubre de 2014

Introduccion a Mod Security y reglas free Owasp.

Como alguna vez hemos hablado en este blog aquí y aquí, Mod security es el Web Application Firewall del mundo software libre más usado.

Mod Security funciona como módulo embebido de Apache o para cualquier web server como reverse proxy.



Las funciones que nos permite este WAF son las clásicas:
  • Monitorización en tiempo real de los accesos web. Podemos delimitar el acceso a nuestros recursos web no solo con htaccess, sino con reglas específicas.
  •  Virtual Patching. Este concepto me parece muy interesante, al igual que con Snort, tenemos la posibilidad de crear una regla que detecte un exploit concreto contra una vulnerabilidad concreta, y podemos parar la ejecución, aún contando con la vulnerabilidad sin parchear. Muy útil para sistemas heredados, integrados o con dificultad para actualizar.
  • Logging. Como herramienta de registros de la actividad http/s.
  • WEB Hardening. Podemos crear reglas para securizar nuestro webserver. Por ejemplo, podemos crear una regla que inspeccione el Body Response y detecte una fuga de información de una caída de Mysql, inyectando código en la respuesta o redirección a otro recurso, para evitar dan información al atacante. Hay muchas, algunas las iremos comentando en Inseguros.
  • ...
Como habéis podido leer, funciona como un ids tipo Snort/Suricata, en el que el motor mod security examina todo el tráfico en base a una reglas, y en el caso de que hagan "Match", que encuentre el patrón de la regla, podemos vincular una acción.


Es decir, aparte de la potencia de procesamiento de Mod Security, lo importante son las reglas.
Si te vas a animar en probar Mod Security sobre tus webserver, puedes hacerlo de una manera muy sencilla.
El proceso es bajar mod security, compilarlo (hay millones de tutoriales) habilitar el módulo en Apache. Bajar las reglas que más te gusten y trabajar.


No tengas miedo en montar Mod Security y pensar en que vas a parar tráfico legítimo, o que vas a cargar el web server. Mis pruebas dan que Mod Security carga el webserver en un 8%/10%. Las reglas las podemos evaluar antes de que corten, en modo DetectionOnly. Cuando hayamos "trasteado" con las reglas podemos pasar a la acción habilitando las acciones, pero podemos estar tranquilos en que mientras lo analizamos, no estaremos cortando tráfico legítimo.

El conjunto clásico de reglas que todo el mundo se baja de manera gratuita es Owasp Core Rule Set.
Vamos a ver una regla simple para que os hagáis una idea de su simpleza, o quizás de su complejidad xD.

SecRule REQUEST_HEADERS:User-Agent "@pmFromFile modsecurity_35_bad_robots.data" \
"chain,phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,block,msg:'Rogue web site crawler',id:'990012',tag:'OWASP_CRS/AUTOMATION/MALICIOUS',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',severity:'4',capture,logdata:'%{TX.0}'"

Esta regla se engloba en modsecurity_crs_35_bad_robots.conf
Lo que tenemos es un fichero .data que almacena los user_Agent maliciosos conocidos...(actualizar de vez en cuando) y si en el Request Headers detecta alguno en User-Agent hace un BLOCK, con un mensaje concreto en la alerta. Esto es lo más relevante de momento de esta regla. Ya entraremos en detalle con las reglas, simplemente quiero que veáis como se hacen, y que son "asequibles" de programar o interpretar.

Vamos a interpretar una alerta generada por esa regla de arriba.

--e2b5db05-A--
[16/Oct/2014:10:16:06 +0200] VD9@xrIhfmwAADLzPPYAAAAA ip origen 15866 ip destino 80
--e2b5db05-B--
GET /*************/?gclid=*************************** HTTP/1.1
Host: dominio atacado
User-Agent: NIKTO
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: ******************
Cookie: cookie_****=1; __utma=*******************                                                  971.72.39.utmgclid=CKCyoq3dsMECFSuWtAodRyMAxg|utmccn=(not%20set)|utmcmd=(not%20set); optimizelySegments=%7B%221               
Connection: keep-alive
Cache-Control: max-age=0

--e2b5db05-F--
HTTP/1.1 403 Forbidden
Last-Modified: Wed, 07 Aug 2013 10:59:35 GMT
ETag: "*************"
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 546
Connection: close
Content-Type: text/html

--e2b5db05-H--
Message: Access denied with code 403 (phase 2). Matched phrase "nikto" at REQUEST_HEADERS:User-Agent. [file "/e                                                         tc/httpd/modsecurity.d/activated_rules/modsecurity_15_customrules.conf"] [line "16"] [id "990002"] [rev "2"] [msg "Request Indicates a Security Scanner Scanned the Site"] [data "nikto"] [severity "CRITICAL"] [ver "OWASP_CR S/2.2.6"] [maturity "9"] [accuracy "9"] [tag "OWASP_CRS/AUTOMATION/SECURITY_SCANNER"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"]
Action: Intercepted (phase 2)
Stopwatch: 1413447366270242 2499 (- - -)
Stopwatch2: 1413447366270242 2499; combined=530, p1=165, p2=356, p3=0, p4=0, p5=8, sr=63, sw=1, l=0, gc=0
Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.6.
Server: Apache
Engine-Mode: "ENABLED"

--e2b5db05-Z--

Para esta regla, he resaltado los campos más relevantes en negrita, que como puedes comprobar, coinciden con la regla comentada.

Tengo que decir que el conjunto de reglas Owasp para mi es como un "Pattern & design". Me explico. Imaginaros un ataque web concreto, con una url asi:  http://dominio/admin.php?user=hygugugu&cmd=cmd.exe.

Es una tontería pero sirve de ejemplo. Tenemos un ataque que mediante una url concreta de un fabricante, con un parámetro concreto de un usuario, nos permite ejecutar una consola de sistema. Mod Security no va a detectar el ataque concreto contra ese fabricante, sino que detecta un "ataque" porque según el conjunto de reglas Owasp, hacer una llamada a CMD.exe es de por si un ataque.


Esto tiene algo bueno y malo. Lo bueno es que detectará los ataques pasados, presentes y futuros que empleen CUALQUIER llamada por url a CMD.exe. Lo malo es si tu usas esta función?

Ese es el trabajo que debemos realizar una vez instalamos Mod Security y las reglas Owasp en modo DetectionOnly. Detectar que comportamientos legítimos de nuestras aplicaciones son detectadas como alertas, y tenemos que o modificar la aplicacion... xD  o hacer whitelist de esa regla para una ip, dominio, vhost o regla concreta.

Pongo otro ejemplo, si en tu aplicación web entras por dominio, pero existen enlaces hacia url por IP, OWASP rules detecta esto como un ataque...

Quería hablar de otro conjunto de reglas, pero me he animado a escribir esta pequeña guia para ver si os animáis a instalar vuestro mod security en cualquier máquina virtual ,en cualquier apache que tengas por ahí, y así poder seguir los artículos. Vamos !!!

Si tenéis alguna duda en la instalación inicial o en el setup, podéis contactar conmigo por correo en minick @ hotmail.com.

Gracias por leerme, espero que os guste !!!.

jueves, 9 de octubre de 2014

Prevención de fugas de información en logs. Campo Passwords y Mod security

Cuando un atacante pretende comprometer un sistema, una de las ubicaciones que debe observar son los logs. Imaginaros el caso de un sistema comprometido, en el que el atacante accede a los logs del sistema, en el que se muestran en claro los usuarios y contraseñas de nuestros usuarios. Se lo pondríamos muy fácil.


En algún cliente me ha ocurrido la situación de  presentar una solución tipo Snort, Mod Security e incluso un simple Squid Proxy para proporcionar elementos de seguridad, y ser la propia gerencia la que descartaba este tipo de soluciones por la exposición de información sensible, y casi siempre personal, al departamento IT o el departamento que accede a los logs ( redundante, los informáticos lo vemos todo, desde el de micro-informática hasta el sysadmin-boss).

Con un proxy podemos ver los hábitos de navegación de nuestros director de ventas, que son muy decorosos...Con Snort podemos detectar aplicaciones prohibidas, como pueda ser el famoso BroadCast de Dropbox...

Para proporcionar un nivel de seguridad y confianza en la gestión de logs de Mod Security, vamos a crear una pequeña regla al respecto.

Lo que hacemos es crear una regla tan sencilla como la siguiente. Con ella simplemente lo que hacemos es que en fase 5,la parte de logging, sanitice !*"!^·*!^"*·! (limpie los caracteres de un campo con asteriscos).

SecRule &ARGS:password "@eq 1" "phase:5,t:none,id:123458,nolog,pass,sanitiseArg:password"


Esta regla de por sí no generará alarma, simplemente que en nuestras reglas existentes, cuando detecte un campo password, "limpiará" el registro con ****.

Veamos un ejemplo. Lanzo un "ataque" ficticio sobre una aplicación, para que salte cualquiera de las alarmas que tenemos configuradas ( en este caso salta una alarma por hacer match de la palabra UNION).


Como puedes ver, aparece la contraseña en claro.
Sin embargo una vez activada nuestra nueva regla, podemos comprobar que el mismo ataque, genera la misma alerta, pero limpia el campo.


Como puedes ver, esta simple regla puede propiciar que gerencia vea con buenos ojos tu medida de seguridad, y no estés viendo todas las passwords de los clientes. Pobres ilusos xD pero bueno, creo que todo el mundo es consciente de que este tipo de información es manejada por el departamento IT.

Como siempre, espero que os guste, gracias por leerme !!!



Seguridad "Management" o seguridad "Tech".

El propósito del blog Inseguros, entre otros, es el de acerca el mundo de la seguridad a los profesionales de la administración de sistemas, técnicos e incluso principiantes en el hacking ético.

En el mundo de la seguridad informática existe una distinción entre los perfiles de los participantes que me gustaría comentar.

El hacking ético es una área puramente técnica, en la que la persona suele poseer grandes conocimientos en redes, protocolos, seguridad web, móviles, reversing, análisis de tráfico, etc, pero suelen tener poco conocimiento de la gestión de la seguridad.


La seguridad defensiva suele ser un perfil en el que el participante cuenta con un conocimiento mas o menos general de la parte de hacking ético, pero sobre todo conocen las medidas defensivas a implementar para conseguir solucionar o mitigar los incidentes de seguridad.

Existe un perfil de analista de malware/cibercrime el cual es altamente técnico, y suele coincidir con una gran base de conocimiento respecto al hacking ético y la seguridad defensiva.

Aunque existen mas perfiles, creo que con estos ejemplos ilustro la vertiente tecnológica de estas ramas.


Bajo otra rama podríamos llamar a los participantes como "security management".
Suele ser un perfil de gestión. Conocen la teoría de los riesgos, en el mejor de los casos, conocen las medidas teóricas para su defensa, pero no tienen por qué conocer la parte técnica.

En la comunidad hacker este perfil es el más despreciado, ya que consideramos que es muy fácil hablar de gestión de incidentes, pero es difícil implementar una solución técnica que realmente me aporte seguridad, no solo control.


Yo pienso que los extremos son malos, y tanto un perfil muy técnico, como un perfil muy de gestión adolecen de debilidades.

Voy a poner algunos ejemplos. Como técnicos podemos implementar una solución UTM Vpn Ipsec http ssl rsa 2048 con 2af. Muy bien, una buena ristra de siglas y tecnologías. Bien. Perfecto, eres un freak tecnológico, un gurú de la seguridad !!! Y si la semana que aparece HeartBleed, o mejor dicho, ese mes, estabas de vacaciones y no parcheastes? Estabas de luna de miel en Cancún sin posibilidad de conectarte. Has hecho bien tu trabajo? NO. Debería existir un plan de contingencia en el que se contemple un equipo de gestión de incidentes para estos casos. Puede que el equipo de gestión seas tu mismo, pero tiene que estar regulado que al ocurrir un incidente tan importante como este, exista la posibilidad de actuar, y no depender de un viaje, o que es fin de semana y tienes el móvil apagado.


Vamos a poner el caso contrario. Eres un gran gestor de la seguridad de la información. Implementas un SGSI en el que documentas todas tus medidas de seguridad, pero eres incapaz de montar un sistema de prevención (no detección) de intrusos. Puede que a nivel gestión identifiques con su Score la criticidad del incidente, pero lo importante es remediarlo.

El otro día fui a una entrevista de trabajo en mi ciudad. La empresa me llamó una mañana para asistir a la sede esa misma tarde. Con mi vena freak pensé en hacer un pequeño análisis de seguridad. Bueno, mas bien un análisis básico del "estado de la nación IT".
Comprobé el registrador del dominio, los registros DNS. Como muchas empresas, tenían la web en un proveedor de renombre, pero el registro MX apuntaba a una ip local, la típica de Ono-Telefónica...
Realice un fast port scan por la red TOR, no con el fin de encontrar nada, sino con el fin de detectar si implementaban medidas de seguridad.

Encontré una serie de servicios web. Un Apache en el puerto http/s suele estar medio protegido, pero un Apache en el puerto 100 me pareció curioso.

En efecto, era un Joomla sin actualizar, vulnerable. Una clave DEBIL. Era la típica web que hace el informático de turno para un cliente, un nuevo CMS o similar que está probando, pero que publica en Internet para enseñárselo a su jefe.


El caso es que a pesar de tener unos 5 appliances de seguridad, de Fortinet (Fortiweb, Fortimail, Forti Gay...) tenían un fallo de seguridad que me permitió "sentarme" en una de sus máquinas virtuales. Una vez dentro, aparte de acceder a todas las claves de conexión a BBDD averigüé su infraestructura interna. No quise seguir ya que no tenía autorización, y no me lo iban a pagar, pero podría haber petado TODA la empresa, y a algunos de sus clientes.

Aparte de la charla de que buscaban un informático puntero, comprometido, dedicado, innovador, entregado,etc por 15.000€/brutos estuvimos hablando de la seguridad. Es curioso porque SOLO con una auditoría de seguridad y pentesting ya hubiera "producido" casi el mismo dinero que me ofrecía por un año !!!

El sujeto, el gerente, un poco avergonzado se excusaba en que esa web era de pruebas, que era un portal oculto, que no tenía información de producción, etc.


Intentó hacerme sentir que no había hecho ningún trabajo de seguridad importante, y que cualquiera podría haberlo hecho. BIEN, pero entonces, asumes que por esa tonteria, podrías haber sufrido un ataque SERIO con bastante perdida de información ( los backups de contingencia estaban disponibles para borrarlos).

Que importa que el incidente se hubiera producido por un fallo TONTO de actualización, o de contraseña, o que hubiera sido un avanzado APT con 0 days y un procedimiento digno de una novela? Al final, sea cual sea la técnica, lo importante es el acceso.

Una solución muy sencilla, aparte de la formación al informático, hubiera sido programar una auditoría semanal, en la que se hubiera revelado el nuevo servicio en el puerto 100, y alguien debería haber preguntado eso que era, como estaba, si era seguro. Una medida NO TECNICA, porque en vez de una auditoría semanal, el informático podría haberlo comunicado verbalmente.

Si repasas las charlas de las conferencias en las que los "gurús" explican accesos o intrusiones practicadas en clientes, en la mayoría de los casos, se parte de un pc mal actualizado, un antivirus mal actualizado o inexistente, un fallo de ingeniería social (un click, un usb, una url)medidas "low tech" que por muchas medidas de seguridad técnicas que implementes, la gestión de las mismas es una pieza clave.

No se trata de hacerse un experto en ISO 27001/2, LOPD o similares, pero tampoco pensar que el mundo es mar de bits, en el que todo se controla con la tecnología, ya que la tecnología la manejamos humanos.

Si yo quiero juackear tu empresa, como robar un banco, no voy a entrar por tu firewall mas o menos bien configurado, al igual que en el banco no pretenderías robar por la puerta de la caja de seguridad. En un banco intentarías entrar por las rejillas de ventilación, o por un túnel. Con el hacking pasa lo mismo. Cualquier medida es buena, para conseguir tu objetivo.

Si anoto unos cuantos mails de tu empresa, de trabajadores en Linkedin. Y mando a varios empleados un mail diciendo: soy amigo de XXX, lo vi el otro día por XXX sitio y me ha dicho que te mande un currículum a ti. Gracias. Cuanta gente pincharía en el enlace?

Espero que este texto mal escrito te sirva de reflexión para analizar cual es tu "vertiente". Si eres Tech te sugiero que amplíes tus conocimientos con algún proceso formal o metodología que te ayude a gestionar tu seguridad. Si eres un manager, te sugiero que profundices en las medidas técnicas que emplean los cibercriminales y su parte defensiva.

No te fíes de los gurus de la técnica, ni de los gurus de la gestión, ya que vivimos en un mundo en el que nos toca lidiar con la fea y con la guapa, con los High-tech y con los script-kiddies. Con ataques de Rusia y con ataques de alguien de tu pueblo.

Espero que os guste el artículo, gracias por leerme.



miércoles, 1 de octubre de 2014

OSSIM 20. Wireless IDS Kismet y prueba de concepto de ataque.Parte 1.


En el capítulo de hoy de Inseguros sobre la serie OSSIM vamos a hablar de Kismet.
(1234567 , 89 101112 1314.,15, 16 ,17 18, 19)



Kismet es un sistema de detección de intrusos wireless. No me refiero a monitorizar la red wifi con snort, y detectar los ataques de la red cableada ( brute force, exploit,etc), sino detectar específicamente los ataques que se producen sobre la infraestructura wifi.


Para ponernos en situación, mejor leer el manual oficial de Kismet para saber que tipos de ataques detecta, lo que serían las "reglas" de snort/modsec/etc.




    Alert name:       NETSTUMBLER
    Alert type:       Fingerprint  
    Alert on:         Netstumbler probe requests
    WVE:              WVE-2005-0025
    Alert name:       DEAUTHFLOOD
    Alert type:       Trend
    Alert on:         Deauthenticate/Disassociate Flood
    WVE:              WVE-2005-0019
                      WVE-2005-0045
                      WVE-2005-0046
                      WVE-2005-0061
    Alert name:       LUCENTTEST
    Alert type:       Fingerprint  
    Alert on:         Lucent link test  
    Alert name:       WELLENREITER
    Alert type:       Fingerprint
    Alert on:         Wellenreiter SSID brute force attempt
    WVE:              WVE-2006-0058
    Alert name:       CHANCHANGE
    Alert type:       Trend  
    Alert on:         Previously detected AP changing to a new channel
    WVE:              WVE-2005-0019
    Alert name:       BCASTDISCON
    Alert type:       Fingerprint
    Alert on:         Broadcast disconnect/deauthenticate
    WVE:              WVE-2005-0019
                      WVE-2005-0045
                      WVE-2005-0046
                      WVE-2005-0061
    Alert name:       AIRJACKSSID
    Alert type:       Fingerprint
    Alert on:         SSID of 'airjack'
    WVE:              WVE-2005-0018
    Alert name:       PROBENOJOIN
    Alert type:       Trend
    Alert on:         Clients probing for networks, being accepted by that
                      network, and continuing to probe for networks.
    Alert name:       DISASSOCTRAFFIC
    Alert type:       Trend
    Alert on:         Traffic from a source within 10 seconds of a
                      disassociation
    WVE:              WVE-2005-0019
                      WVE-2005-0045
                      WVE-2005-0046
                      WVE-2005-0061
    Alert name:       NOPROBERESP
    Alert type:       Fingerprint
    Alert on:         Probe response packet with 0-length SSID tagged 
                      parameter
    WVE:              WVE-2006-0064
    Alert name:       BSSTIMESTAMP
    Alert type:       Trend
    Alert on:         Invalid BSS timestamps indicative of an access point 
                      being spoofed.
    WVE:              WVE-2005-0019
    Alert name:       MSFBCOMSSID
    Alert type:       Signature
    Alert on:         MAC src address used as CPU instructions by MSF when 
                      exploiting the Broadcom SSID overflow
    WVE:              WVE-2006-0071
    Alert name:       LONGSSID
    Alert type:       Signature
    Alert on:         SSID advertised as greater than IEEE spec of 32 bytes
    Alert name:       MSFDLINKRATE
    Alert type:       Signature
    Alert on:         Beacon frame with over-long 802.11 rates tag containing
                      exploit opcodes
    WVE:              WVE-2006-0072
    Alert name:       MSFNETGEARBEACON
    Alert type:       Signature
    Alert on:         Large beacon frame containing exploit opcodes
    Alert name:       DISCONCODEINVALID | DEAUTHCODEINVALID
    Alert type:       Signature
    Alert on:         Unknown / reserved / invalid reason codes in deauth and
                      disassoc packets
    
Como puedes observar, son los clásicos ataques Wifi.

Para realizar este despliegue he optado por instalar el sniffer wifi, Kismet, en una máquina independiente. El motivo es que OSSIM está instalado sobre Vmware y como todos sabemos, Vmware no es buen amigo de los interfaces Wifi.


Es un Kali con una tarjeta de red wifi. La típica máquina P4 2,4ghz 512 Mb. Pero que funciona de lujo.


Lo que vamos a hacer es integrar dos "opciones" de Kismet con OSSIM. Una serán las alertas cuando se produzcan los ataques. Otra opción será documentar nuestra infraestructura Wifi obtenida con Kismet, para el inventario de áctivos. Un requisito de la famosa PCI- DSS es monitorizar la red wifi, algo que me parece perfecto.


Lo primero que hacemos en el servidor OSSIM es habilitar el tráfico de logs desde el sensor e indicarle la ubicación de los mismos en local:


if $fromhost == 'ip_wids' then /var/log/kismet.log
&~

Ahora habilitamos el envio desde el WIDS hacia Ossim:

echo "*.* @ip_ossim > /etc/rsyslog.d/wids_alienvault.conf
Service rsyslog restart en ambos extremos.

Con esto ya podemos ver los logs del sistema WIDS en ossim mediante un tail a la ruta indicada.

El siguiente paso es ejecutar Kismet en el Wids y comprobar que tenemos actividad.

/usr/bin/kismet_server -t kismet -f /etc/kismet/kismet.conf 2>&1 | logger -t kismet -p local7.1

Si nos devuelve a bash, no ha funcionado. 
Vamos a configurar alguna cosa más en el kismet.conf, como:

Descomentamos ncsource=wlan0 o cualquiera que sea el nombre de tu adaptador wifi.
gps=false.
Cambiamos el prefíjo de los logs:
logtemplate=/var/log/kismet/%n_%D-%i.%l

Aprovechamos este momento para editar la regla apspoof=Foo... en donde cambiamos el nombre y cambiamos el ssid "Foobar" por el nombre de un ap que esté en nuestro alcance. De esta manera vamos a comprobar que como no hemos cambiado la mac que aparece, al detectar el AP y no coincidir con la mac proporcionada, nos generará una alarma.
En el proceso normal de uso debemos añadir una regla por cada AP que tenga un nombre SSID distinto. Si es el mismo, basta con añadir mas direcciones mac mediante una coma.

La alerta generada sería así:

Oct  1 08:34:06 localhost kismet: ALERT: APSPOOF Unauthorized device (C8:D7:19:FB:67:01) advertising for SSID 'MySSID', matching APSPOOF rule Foo2 with SSID which may indicate spoofing or impersonation.

Lanzamos un ataque DOS Deauth. Comprobamos que Kismet detecta el ataque.

airodump-ng wlan0 -> anotamos un bssid y su channel.
iwconfig wlan0 channel x > ponemos nuestra tarjeta en el mismo canal.
aireplay-ng --deauth 0 -a bssid wlan0



Espero que os guste el artículo. En el siguiente episodio terminaremos con la 
integración en OSSIM. Gracias por leerme.