miércoles, 13 de marzo de 2019

Gestión de incidentes... The hive. Cortex. Mips. Episodio 1. El incidente...

Estimados amigos de Inseguros !!!

La gestión de incidentes es algo que puede dar para varios libros, el DFIR (Data forensic & Incident Response) pero desde el blog quiero daros unas pinceladas, unas opiniones y algunas guías de cómo podemos abordar este proceso tan interesante y puede que a su vez complejo.

Voy a empezar desde lo más bajo, lo más simple, un incidente. Cuando hablamos de incidente, más allá de las nomenclaturas, definiciones, taxonomías y demás historias, vamos a hablar en términos generales para un sysadmin, un responsable de informática como TU, que no tienes porque trabajar en el vertical de la seguridad pero si te gusta.

Imagina el caso de un Ransomware en una empresa, ¿has vivido alguno? lo hayas sufrido en primera persona, en segunda, seas tú el responsable, el técnico, el amigo al que llaman... al final, creo que todos hemos vivido alguna situación relacionada con el Ransomware.

Creo que podemos coincidir sin duda, en que algo común en las empresas en las que pasa, es que se produce un desmadre !!!


El primer punto de desmadre o desconcierto si queremos emplear alguna palabra más acertada es la parte no técnica. A quién llamamos? cómo actuamos? cómo se ha producido? qué pasos damos?

Es normal que esto pase. La gente está parada, hemos perdido o sospechamos que vamos a perder información y estamos "jodidos"...

Si la empresa es pequeña, llamarán al usuario-avanzado-informático que hará lo que pueda, y en paralelo llamarán a una empresa de informática o gurú-freelance para que les ayude.

Si la empresa es mediana, lo mismo, primero al departamento, luego apoyos.

Si la empresa es algo más que mediana, lo mismo el incidente lo detecta programación, se lo pasa a sistemas, estos a seguridad o al pobre que se dedica a la seguridad, a la empresa x, a la y y por si acaso a la Z.

Unos hacen unas cosas, otros recomiendan, asesoran, presupuestan !!!!. este punto es importante.

Es normal en tiempos de crisis que llegue una empresa a "ayudar" y hacer el agosto. Mezclar la fase de urgencia, de remediación, con la consolidación de sistemas, o mejor dicho, implementación de nuevos sistemas es algo habitual. Me explico: tienes un ransomware, lo vas a perder todo, pero aprovecha para mejorar TODA tu infraestructura informática, que es mala o inexistente, pero hazlo ya !!! a prisa !!! porque tienes un ransomware y no queremos que vuelva a pasar !!!!

En la mayoría de los casos habrá que realizar mejoras, pero hay que separar las fases.

Sin haberlo estudiado, con sentido común, lo normal es separar el problema actual del Ransomware, ver como ha entrado, y una vez haya pasado el temporal proponer acciones de mejora.

Comprar antivirus de gama alta, renovar el firewall, aprovechar para replicar en la nube el pequeño servidor, mil copias de seguridad de distinta índole no sirve de nada, si el problema lo tenían con una clave débil en un RDP, o en un Wifi...

Coincides conmigo en que tenemos que ser profesionales ante un incidente. Hay que tener en cuenta una cosa, y es que vamos a vivir pocos incidentes SERIOS en nuestra vida profesional, esto no es una cosa que pasa todos los días y aprendes, sino que debes aprender a "ciegas" o confiar en profesionales muy preparados.

Otro problema muy importante en los incidentes es su detección. Detectar un Ransomware es sencillo, evidente, aparente. trazar su entrada es muy "facilico" también, pero hay datos que avalan que los incidentes de seguridad en las empresas son detectados, de media, 150 días después...

Pongo el caso reciente del ministerio de no se donde de no se qué país...


Calculan que ha estado 3 meses comprometido el sistema...

Recuerdo otro incidente famoso que todo el mundo conoce, Wannacry. Un fallo de seguridad infantil, tontico, sin mucho mérito, provocó un caos monumental, y que he dicho siempre que Telefónica gestionó con maestría.

Recuerdo tener amigos y clientes que me llamaban porque otros informáticos les habían aconsejado apagar internet. no conectarse a internet porque si usaban telefónica, era MUY probable que se infectaran. Hablo de empresas GORDAS recomendando a empresas GORDAS apagar Internet, sin haber estudiado e investigado NADA.

Como es normal, esto es algo que requiere de departamentos complejos o empresas dedicadas, pero dentro de nuestras posibilidades, podemos gestionar estos incidentes o supuestos incidentes de una manera organizada apoyándonos en un software como el que vamos a relatar en las serie.



Vamos a poner otro ejemplo de incidente menos "cantoso" pero que seguro has manejado: un e-mail con spear phishing, con un ataque dirigido hacía alguien de la empresa. O aún más sencillo... un intento de ataque que para el IPS.

Imagina que tu UTM, Firewall, Next Gen o máquina de café te informa de que ha parado un exploit contra un servicio expuesto a las 7:00 am. Perfecto... el correo funciona !!! me llegan notificaciones.

Me llega otro intento a las dos horas. Soy una Pyme y no tengo SIEM ni nada de esto...

A las 3 horas, tercer exploit que detectó. Esto es algo normal, solo si tienes logs ves estas cosas, pero... y si compruebas que la dirección de origen es de una ip de tu ciudad... podrías sospechar que hay alguien "cercano" intentando darte caña? no es lo mismo un ataque así que uno de una botnet que se sabe que recorre internet a diario en busca de...

Realizar esa pequeña comprobación de la ip de origen frente a fuentes públicas puede ayudarte en ponerte alerta.

Esto es una gestión de incidente !!! abres tu ticket, documentas, le pasas un análisis de whois, blacklist, etc y ejecutar una remediación técnica, bloqueas la ip 7 días. Todo esto lo documentas en un software de tickets "dedicado" a los incidentes, y a correr.

Espero que te vayas animando en descubrir algo más de la gestión de incidentes y que profesionalices en la medida de tus posibilidades estas acciones.

En próximos artículos hablaremos de procesos y software que nos ayude en el camino.

Como siempre, gracias por leerme !!!




lunes, 11 de marzo de 2019

Matriz del Mitre...

Estimados amigos de Inseguros !!!

Tanto si te dedicas a la seguridad ofensiva, al famoso Red Team, como si tus problemas son los logs, la respuesta a incidentes y la parte defensiva, el Blue Team, coincidiras conmigo en que la matriz del Mitre es algo que habrás visto en la redes, conferencias y demás.




Yo personalmente la menciono y trabajo en mis charlas, porque creo que es un framework, un marco de trabajo, una taxonomía, una biblioteca... podría darle bastantes calificativos.

En este post voy a presentaros algunos opiniones y explicaciones al más puro estilo murciano para centraros en este "mundillo" que seguro os apasiona.

En primer lugar, quien son MITRE.  Una organización, empresa, que indica en su texto de presentación: Nosotros solventamos problemas para hacer el mundo más seguro. Lejos de ser una consultora de informática, tienen distintas líneas de actuación, y solo una de ellas es la línea de trabajo dedicada a la ciberseguridad.

Desde hace 5 o 6 años han desarrollado varias matrices de datos, las conocidas como Attack en las que aglutinan conocimiento en base a técnicas, tácticas y procedimientos conocidos en el mundo del ciber...

Pero lo mejor es ver una imágen para que lo entiendas.



Como puedes ver, a la izquierda, podemos filtrar entre recursos por sistemas y desde hace poco para entornos móviles.

La matriz selecciona en distintas columnas las tácticas que se emplean, y en filar las técnicas exactas, pudiendo éstas estar en distintas tácticas. Por ejemplo, la fuerza bruta puede ser un elemento de acceso inicial, pero también de escalada de movimiento lateral.


Initial Access
Execution
Persistence
Privilege Escalation
Defense Evasion
Credential Access
Discovery
Lateral Movement
Collection
Exfiltration

Command and Control

El número de técnicas que documentan crece y es muy amplio, pero voy a dejaros dos pantallazos para que os hagáis una idea.


Si nos fijamos en la información que nos muestra, podemos ver la explicación de la técnica, como mitigar el ataque, como detectarlo !!! casi más importante que nada...

Nos muestra bibliografía relacionada, herramientas usadas, grupos de cibercriminales que las han usado, informes públicos en los que aparece esta táctica/técnica.

Al final, es una gran base de datos de conocimiento que podemos usar para muchos propósitos.

Una de las informaciones que manejo son Data Source. Qué fuentes de datos monitorizan o alertan de este ataque.

En el trabajo defensivo, el Blue Team, no solo debemos confiar en un Firewall/UTM, o en un Endpoint o EDR, o en un IDS/IPS, o en un WAF, o en... al final, debemos tener MUCHOS elementos de monitorización para detectar en mayor medida la cantidad de ataques, o intentos, o actividades maliciosas que ocurren en la red y que muchas deben ser estudiadas.

Pongo en mis charlas siempre el ejemplo de imaginar que el atacante tiene la clave de un admin de la red. Ahí ya no valen el 90% de las protecciones "habituales" en la pyme... y luego a luego solo en SOC´s muy preparados.

En la matriz de Mitre podemos encontrar muchos data source: ['File monitoring', 'Process monitoring', 'Process command-line parameters'], ['Packet capture', 'Netflow/Enclave netflow', 'Malware reverse engineering', 'Process use of network'] ['WMI Objects'] etc etc etc

Un buen atacante sería aquel que conoce y controla todas las técnicas implicadas en la matriz, y un buen defensor sería aquel que tendría la manera de detectar/mitigar/parar estos ataques.

El camino es largo amigo... y más si tienes dos o tres elementos. Como he indicado, no creo que haya ningún SOC que sea capaz de darte un 100% de Mitre, no me refiero a la seguridad, porque Mitre no recopila TODO, recopila lo que sabe...

Volvemos al ruedo. Si usas un SIEM para aglutinar la información en un SOC, ya sea este externo, interno, toda una organización o un pequeño software en una VM que nadie ve, al final, tendrás que haberte visto liado con las taxonomías. Cómo categorizar los incidentes, o mejor, los eventos, porque muchas veces el paso de evente a incidente debería ser automático, y no que necesitará la ayuda de un analista... pero bueno, esto son otras cosas.

Imagina que tienes en tu SIEM aparejadas las alarmas con técnicas del Mitre, por ejemplo, cuando un fail2ban detecta una fuerza bruta en un ssh, manda un log al siem, y aparte de los datos típicos, añade : T1078 Valids Account. En esta técnica indica que los data sources que la monitorizan son los logs de autenticación, y la monitorización de procesos, en nuestro caso son los logs de la autenticación.

No podemos decir que para todos los servicios que requieran "account" que requieran login y password tengamos monitorización, pero si sabemos que para el SSH si.

Si vinculamos todas nuestras técnicas a "técnicas Mitre" podemos hacer un estudio mensual por ejemplo, y pedirle al sistema, en base a las alertas que has generado, dame los data sources que tengo.
Tendríamos una lista de Data source, que nosotros ya sabemos, pero estos se identifican dinámicamente según las apariciones de alertas. Digamos que es una vía más de control de si estamos haciendo las cosas bien.

Esta cuestión va dirigida a la auto-evaluación de nuestras capacidades, pero antes de seguir por ahí, vamos a hablar de otro recurso no-Mitre pero muy interesante, y luego seguimos con el Mitre.


Hablo de un proyecto muy interesante para medir las capacidades del SOC a varios niveles, no solo a nivel de la capacidad de correlación, monitorización, respuesta a incidentes, sino desde todos los planos. incluyendo el organizativo, empresarial, reporting, etc. El proyecto recopila una seria de preguntas en formato Excel guiado y mediante unas fórmulas nos da el grado de madurez del servicio.

Podemos descargar gratuitamente el proyecto desde https://www.soc-cmm.com/ y realizar nuestros "self assesment".

Pero ahora volvemos al Mitre, y al concepto de medir nuestras capacidades.

Tenemos un mapa Mitre sobre el que podemos "trabajar" ubicado en : https://mitre-attack.github.io/attack-navigator/enterprise/#

Por supuesto es un proyecto que podemos bajar a nuestros servidores y así "garantizar" la seguridad del mismo. Si hacemos uso de las numerosas api´s de consulta que hay ( yo uso la api https://github.com/Cyb3rWard0g/ATTACK-Python-Client/blob/master/notebooks/Usage_Basics.ipynb del señor @Cyb3rWard0g ) podemos hacer "chulas"

Por ejemplo, a mi se me ha ocurrido usar una capa sobre la matriz original, que según el grado de madurez del data source, busque las técnicas asociadas y coloree, según un gradiente, el mayor o menor estado de la monitorización. Bien para informes, para clientes, para control interno, para tener un mapa de ataques por técnicas Mitre, por lo que sea, podemos jugar con casi todo.

Un ejemplo de json sencillo:

{
    "domain": "mitre-enterprise",
    "name": "example",
    "gradient": {
        "colors": [
            "#ffffff",
            "#ff6666"
        ],
        "maxValue": 100,
        "minValue": 0
    },
    "description": "hello, world",
    "version": "2.1", 
    "techniques": [
{
"techniqueID": "T1213",
"score": 85
},
{
"techniqueID": "T1092",
"score": 15
},
{
"techniqueID": "T1200",
"score": 10
},
{
"techniqueID": "T1119",
"score": 20
},
{
"techniqueID": "T1160",
"score": 10
},
{
"techniqueID": "T1188",
"score": 10
},

Si subimos esta capa a la matriz navegable obtenemos algo así:


Podemos usar una tabla intermedia para construir el json que vaya incrementando el valor de la detección según los data sources, pero sobre elementos distintos, para no creernos que con monitorizar el ssh estamos cubiertos, ni mucho menos. Tanto la gestión como organización de esta información es algo tedioso, que necesita de bastante dedicación, y que solo para estructuras de SOC formales con personal cualificada tendrá sentido trabajar.

Otra cosa es que como he dicho, como atacante o defensor, usas este matriz para evaluarte y guiarte en tus estudios, o en tu trabajo. 

Sin duda,  ir aumentando el grado de "control" de las técnicas es algo básico tanto para Red como para Blue.

Espero que os haya gustado la medio explicación de la matriz de Mitre y que os sirve de inspiración las distintas vías de interacción que nos permita el framework.

Hay muchas aproximaciones que podemos hacer con la matriz, como por ejemplo, usar este magnífico recurso que correla eventos de Windows con posibles técnicas de ataque.

Tenemos otros recursos en forma de aplicaciones de entrenamiento, Caldera y RedCanary, similares a Infection Monkey que vimos aquí hace años. Son colecciones de ataques basados en las taxonomías de Mitre que nos ayudan a evaluarnos, de una manera ordenada.

Muchas gracias por leerme, un saludo !!!

viernes, 8 de marzo de 2019

Linux más seguro: claro que no guapiiii !!!

Estimados amigos de Inseguros !!!

Hoy voy a reflexionar o contar una pequeña anécdota laboral pero que realmente aporta valor en la reflexión de muchos de mis argumentos cuando discuto con algún fanboy/talibán de mi también querido Linux.



Me gusta lo mismo Mac, Windows, Linux... son herramientas con las que trabajo, es como a quien quiero más, a Papá o Mamá...


Por supuesto, tengo mis preferencias, prefiero MICROSOFT, pero lo que tengo claro es que los 3 son válidos, y siempre intento ser objetivo a la hora de usar unos u otros en beneficio del cliente/solución/necesidad, etc. Los que sólo reivindican uno u otro, sois unos pringuis, jejejeje.

Entonces ahora sigo con la reflexión.

Auditoría interna a empresa NORMAL, ni ibex35, ni banca, ni pyme, empresa NORMAL, con 150 equipos, no muchas medidas de seguridad, un montón de fallos, un montón de cosas que también hacían bien...si si, has leído bien, aunque esto no lo ponemos en los informes hay empresas que también hacen algunas cosas bien.


En esta empresa usaban una red Active Directory basada en 2012 server. Los equipos eran medio recientes con Windows 10. No es esa mirda de escenario de algunas demos con DC 2008, windows 7, smb1, wdigest y Mimimatz hasta la cocina porque no hay antivirus en el servidor. Esta empresa no era así, eran normales !!!! su sysadmin hacía las cosas normal, ni muy pro seguridad ni muy cafre.

Tenía un Wsus para actualizar los equipos y una herramienta de gestión y monitorización de equipos. Ahora es cuando un fanboy me diría un Nagios... un Zabbix.... NO, una RMM tools. Con sus indicadores, gestión de parches de aplicaciones cliente, soporte, etc... * no digo que las dos herramientas Software Libre que menciono no sean buenas, sino que no son RMM, son solo M*

Los equipos tenían un antivirus normalito, con su consola centralizada empresarial. La verdad es que el antivirus no era el más pelado, pero tampoco era un EDR, simplemente que aparte de por firmas, detectaba algún comportamiento raro, algo de Threat I... eso, que no era como ClamAv...

La empresa tenía departamento de programación y diseño (marketing), tanto para la web como para procesos internos de integración, reporting, tambien algo normal. En estos departamentos se usaban 3 equipos MAC para diseñadores y 4 linux, 3 debian y 1 ubuntu creo.

El resultado de la parte interna fué el esperado, cocina, clave del administrador y un porrón de servicios vulnerados.

La cuestión es, que es a donde voy, en cómo medimos la seguridad. Si me apuras, podría incluso medio aceptar que el diseño del kernel de linux y su funcionamiento puede ser un poco más seguro que el de Windows. Quizás borre esto algún día, pero la vida no es Kernel, la vida es MUY compleja.


Dentro del catálogo de recomendaciones generales que hicimos a dirección, encontramos que:

1.- los antivirus en linux/mac no existían. Y que no me digan que no hay virus en LINUX porque virus quizás no, pero cuando auditas un equipo que tiene un AV y te pilla la webshell, o la shell meterpreter, o la ejecución de algún exploit conocido, te complica más el asunto, y si tienen monitorización ponen al perro en guardia...

2.- las actualizaciones de los equipos regían por el criterio del usuario, osea, ninguno. Encontramos en el entorno Microsoft un relación de software más o menos bien controlado, mientras que en linux/mac, a pesar de usar la misma herramienta RMM, tenían disparidad de versiones, por las particularidades del diseñador/programador.

3.- los entornos no cumplian la LOPD ni la gestión centralizada del servicio de directorio,en este caso Active Directory, porque no tenían instalado los agentes. complejidad de contraseña, revocación, bloqueo de escritorio, GPO´s varias, NADA.

4.-en estos equipos se encontró un montón de software no controlado por permisos de instalación. Máquinas virtuales de pruebas al antojo del usuario eran la tónica general de estos sistemas. Normal, el programador levantaba su entorno de PRE. sin control ninguno. Insisto, eran una empresa normalita, no había team master, DEVops y ni versionado de aplicaciones.

Al final de las muchas recomendaciones que emitimos en el informe, y de los fallos que aparecieron, muchos estaban relacionados a cómo se gestionaban o como NO-gestionaban estos equipos.

Como es normal, para estos 4 casos que os pongo, si eres un buen sysadmin, tiene solución. Una buena monitorización, un directorio activo LDAP standard, Ansible, etc etc, pero hablo de la REALIDAD de las empresas. De las empresas en las que he trabajado que el usuario Linux suele ser el avanzado, el de departamento de informática, los programadores, y al final, son puntos habituales de fallos. ya sabes, dejale el root del servidor al programador y que haga lo que quiera...

Entonces, vuelvo a mi planteamiento inicial, Es más seguro Linux? en este caso NO. Como siempre, abogo porque la seguridad está en las manos de quien administra, pero insisto en que esta tendencia que indico en el post, no es de un o dos clientes, suele ser la tónica general respecto a linux, igual que tener un AD bien configurado no es la tónica general, también tengo que aclarar...

No obstante, las cosas están cambiando. Esta mañana he leído en Barrapunto que era el año del Escritorio basado en Linux...

Gracias por leerme.

martes, 26 de junio de 2018

Generación de diccionario de usuarios tipo jmolina@ gracias a linkedin scraping.

Estimados amigos de Inseguros !!!

Una de las opciones que tenemos a la hora de realizar un pentest o auditoria es la fuerza bruta.

Debemos detectar aquellos sistemas que no protegen de ataques de este tipo, pero debemos ir un paso más allá e intentar demostrarlo mediante la obtención de una clave válida.

Ahora vamos a imaginarnos un escenario de auditoria bastante común en las empresas, los nombres de usuario.

Conoces alguna empresa en la que la nomenclatura del usuario sea napellido@  o n.apellido@ ?

Contar con un diccionario de este tipo sin duda te ayudará para detectar usuarios.

Si a esto le sumas la capacidad de usar las redes sociales corporativas, como pueda ser Linkedin, para realizar un proceso de búsqueda de empleados que trabajan en la empresa objetivo, podemos crear un diccionario de usuarios más acercado a la realidad que uno descargado de internet con los ene mil nombres de usuario más comunes...



Para realizar la tarea de scrapping linkedin puedes usar esta herramienta muy cómoda.

https://github.com/test4a/linkScrape

No usa ni API ni nada sofisticado, te pide tu usuario y contraseña linkedin para poder acceder...



Ahora podemos usar la magia del lenguaje de programación que más te guste para combinar nombres y apellidos en una lista usable.

Durante varios procesos he creado una lista con nombre +apellido de los apellidos más habituales, creo que es útil para completar con tu proceso de scrapping de linkedin.

Si quieres descargar mi lista la tienes en mi github:

https://github.com/kinomakino/hackingtools/tree/master/diccionarios

Espero que te sirva !!!

Gracias por leerme !!


miércoles, 6 de junio de 2018

Usando DefectDojo para control de vulnerabilidades

Estimados amigos de Inseguros !!!

Cuando ofrecemos servicios de auditoría o pentesting, o incluso como cliente te planteas hacer un proyecto de este tipo, es indudable que aparezca el temor a que el resultado del trabajo sea un entregables, en papel, más o menos bonito, con un montón de hallazgos y soluciones, pero escasas herramientas de tracking de cambios.

En algunos clientes se acompaña el trabajo de auditoria con el trabajo de gestión del proyecto global, incluidos los resultados. Me eeeeeexplicoooooo.



Si en una auditoría se detecta la necesidad de hacer una actualización puntual, se crea un ticket en la plataforma de incidentes del cliente ( o nuestra) para poder establecer un control sobre la remediación. Qué persona se va a encargar, cuando, como, rellenar una KB, etc etc.

A las malas malas malas, estoy hablando de usar ese libro gordo de petete del resultado de la auditoría, e ir "tachando" qué se va a haciendo !!!

Una de las cosas que se mide en la mayoría de normativas de seguridad y certificaciones es el control de las auditorias. Bueno, en primer lugar es que la organización pase auditorías, pero lo segundo es que se vayan controlando los cambios y solucionando los hallazgos.

Para meternos más en este mundo, voy a comentar una aplicación que he visto por las redes sociales que me parece muy interesante para esta gestión. Quizás más interna por lo que veremos ahora, pero vamos paso a paso y vamos a instalarla. Me refiero a DEFECT DOJO.

Como en todo lo "moderno", podemos usar contenedores tanto en Docker como en vagrant, pero yo soy de montarme mi máquina virtual en Azure e instalar desde cero.

El proceso es sencillo, instala Mysql y corre el script de instalación. Nota mental, en las nuevas Debian 9 mysql es Mariadb, y hay alguna librería de desarrollo que cambia y da problemas, asegúrate de montar el aplicativo sobre Mysql.

También tendrás que permitir los allowed_host para la app en django y poco más...


Vamos a hacer uso de las integraciones que nos trae el framework de casa.



Vamos a crear un producto, vamos a establecerle unos test y vamos a subir un report de Burp con una Sql Injection.



Como se aprecia en la imagen, se adquiere la información de Burp y se pueden añadir imágenes.

El framework permite añadir una plantilla para cada tipo de elemento, lo típico de nuestro trabajo de tener el texto en castellano con nuestra explicación...

Sin duda es una herramienta con mucho potencial, gracias a su integración con JIRA y la gestión de tickets.

Voy a darle unas pocas vueltas y otro día vemos más cosas.

Un saludo, gracias por leerme !!!


Aquí te paso un video de una demo por si te interesa ampliar información:

https://youtu.be/3Voscdxg4FA
Related Posts Plugin for WordPress, Blogger...