En una empresa de ciberseguridad, elegir una tecnología no es solo una decisión técnica: es una decisión que impacta en el desarrollo, el mantenimiento y la operación durante años.

En nuestro caso, tratamos de mantener un enfoque muy pragmático. No buscamos usar lo último ni lo más “interesante”, sino lo que realmente resuelve un problema sin agregar complejidad innecesaria.

1. Partimos siempre de una necesidad real

Antes de evaluar cualquier tecnología, lo primero que definimos es si existe una necesidad concreta.

No trabajamos sobre hipótesis del tipo:

“esto nos podría servir en el futuro”

Si no hay una necesidad real hoy, no se incorpora nada.

Esto nos permite evitar una de las principales fuentes de complejidad en los sistemas: agregar herramientas “por las dudas”.

2. Evitar nuevas tecnologías siempre que sea posible

Una vez identificada la necesidad, el siguiente paso no es buscar una herramienta nueva.

Es preguntarnos:

• ¿Podemos resolver esto con lo que ya tenemos?

• ¿Podemos extender alguna tecnología existente?

Un ejemplo muy común es el uso de bases de datos no relacionales.

Ante la necesidad de manejar datos sin estructura fija, muchas veces la reacción inmediata es incorporar herramientas como MongoDB o Elasticsearch.

Sin embargo, en muchos casos esa necesidad se puede cubrir usando PostgreSQL con tipos de datos como JSON o JSONB.

Esto nos permite:

• evitar sumar una nueva tecnología

• reducir costos de mantenimiento

• mantener el stack más simple

La lógica es bastante simple:

Si podemos evitar incorporar una tecnología nueva, mejor.

3. El costo oculto de cada tecnología

Cada tecnología que se incorpora no es solo una herramienta más.

Implica:

• instalación

• mantenimiento

• monitoreo

• capacitación del equipo

• posibles dependencias adicionales

Y muchas veces, una tecnología nueva no viene sola.

Puede arrastrar otras decisiones que terminan modificando el stack completo.

Por eso priorizamos mantenernos lo más cerca posible de lo que ya usamos.

4. Qué tecnologías descartamos rápidamente

Hay algunos patrones claros que nos llevan a descartar tecnologías:

❌ Tecnologías que no encajan con el stack

Si una herramienta nos obliga a cambiar demasiado nuestro entorno (por ejemplo, sistema operativo o ecosistema), la descartamos salvo que sea estrictamente necesario.

❌ Tecnologías demasiado nuevas o no probadas

En sistemas críticos, evitamos herramientas que:

• no tengan suficiente adopción

• no estén bien documentadas

• no tengan comunidad o soporte

Esto no significa no innovar, sino ser estratégicos según el contexto.

❌ Tecnologías en declive

También evitamos herramientas que claramente están quedando en desuso.

Adoptar una tecnología que el mercado está abandonando es comprar un problema a futuro.

5. El error más común: seguir modas

El error más frecuente que vemos en equipos es dejarse llevar por tendencias.

Adoptar tecnologías porque:

• “están de moda”

• “todos las usan”

• “parecen interesantes”

sin validar si realmente resuelven una necesidad.

Otro problema asociado es no dimensionar el impacto de estas decisiones.

Elegir una tecnología no es algo reversible en el corto plazo.

Son decisiones con las que una empresa puede convivir durante años.

6. La regla más importante

Si tuviéramos que resumir todo en una idea:

Elegir una tecnología es asumir un compromiso a largo plazo.

Por eso:

• analizamos antes de implementar

• priorizamos simplicidad

• evitamos sumar complejidad innecesaria

Porque en la práctica, muchas veces:

menos tecnología = mejores sistemas

La suplantación de identidad por correo electrónico (email spoofing) sigue siendo una de las técnicas más utilizadas en fraudes, phishing e ingeniería social.
En muchos casos, no requiere comprometer servidores ni credenciales, sino simplemente aprovechar una mala configuración de SPF y DMARC.

En esta guía técnica repasamos:

• Cómo funcionan SPF y DMARC a nivel práctico

• Qué errores de configuración son más comunes

• Ejemplos reales de registros DNS

• Buenas prácticas para reducir el riesgo de suplantación

Modelo de ataque típico

Desde el punto de vista del atacante, el escenario es simple:

1. Identifica un dominio sin SPF o con SPF laxo

2. Envía correos usando cualquier servidor SMTP

3. El correo aparenta venir de usuario@empresa.com

4. El receptor confía en el remitente

5. Se ejecuta el fraude o phishing

Sin SPF y DMARC bien configurados, el dominio no tiene forma de “defender su identidad”.

SPF en detalle

¿Qué hace SPF exactamente?

SPF permite declarar, mediante DNS, qué servidores están autorizados a enviar correos para un dominio.

Cuando un servidor recibe un correo:

1. Extrae el dominio del MAIL FROM

2. Consulta el registro SPF del dominio

3. Evalúa si la IP emisora está autorizada

4. Decide si el correo pasa o falla SPF

Ejemplo básico de SPF

v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

Este registro indica:

• v=spf1: versión

• ip4:203.0.113.10: servidor propio autorizado

• include:_spf.google.com: autoriza Google Workspace

• -all: rechaza todo lo demás

👉 Este -all es clave: sin él, el SPF no protege realmente el dominio.

Errores comunes en SPF

1. SPF demasiado permisivo

v=spf1 +all

Esto equivale a:

“Cualquiera puede enviar correos por este dominio”

Desde el punto de vista de seguridad, es lo mismo que no tener SPF.

2. SPF incompleto

v=spf1 include:_spf.google.com ~all

• ~all (softfail) no bloquea

• Muchos proveedores siguen aceptando estos correos

Sirve como etapa de prueba, pero no como configuración final.

3. Demasiados include

SPF tiene un límite de 10 consultas DNS.
Excederlo provoca fallos SPF incluso si los servidores son legítimos.

Este problema es muy común cuando:

• Se agregan herramientas de marketing

• Se usan múltiples proveedores externos

• Nadie revisa el SPF históricamente

DMARC en detalle

¿Qué agrega DMARC?

DMARC actúa como una capa de control y política sobre SPF (y DKIM).

Permite:

• Definir qué hacer si SPF falla

• Recibir reportes de abuso del dominio

• Reducir drásticamente el spoofing

Ejemplo básico de DMARC

v=DMARC1; p=none; rua=mailto:dmarc@empresa.com; ruf=mailto:dmarc@empresa.com; fo=1

Este registro:

• Activa DMARC

• No bloquea correos (p=none)

• Habilita reportes agregados (rua)

• Habilita reportes forenses (ruf)

Es ideal como primer paso.

Políticas DMARC

Modo monitoreo

p=none

• No bloquea correos

• Permite ver quién está enviando emails

• Recomendado como etapa inicial

Cuarentena

p=quarantine

• Correos sospechosos pueden ir a spam

• Reduce ataques sin ser demasiado agresivo

Rechazo

p=reject

• Correos no alineados son rechazados

• Máxima protección contra suplantación

• Requiere que SPF esté bien configurado

Error común: DMARC “activo” pero inefectivo

Muchos dominios tienen DMARC así:

v=DMARC1; p=none

Esto no protege, solo observa.
Si nunca se avanza de p=none, el dominio sigue siendo suplantable.

Alineación SPF + DMARC

DMARC no solo verifica SPF, sino que exige alineación:

• El dominio del MAIL FROM

• Debe coincidir (o alinearse) con el dominio visible

Errores de alineación:

• Subdominios mal definidos

• Proveedores externos mal configurados

• Reenvíos de correo

Este es uno de los puntos donde más errores se cometen.

Riesgos reales de una mala configuración

En escenarios reales hemos visto:

• Facturas falsas enviadas desde dominios legítimos

• Correos de “cambio de CBU” a proveedores

• Phishing interno a empleados

• Caída de reputación del dominio (emails legítimos a spam)

Todo esto sin comprometer infraestructura interna.

¿Por qué no basta con “seguir un tutorial”?

Aunque SPF y DMARC parecen simples:

• Cada entorno es distinto

• Cada proveedor agrega complejidad

• Un error puede bloquear correos críticos

Los problemas más comunes aparecen cuando:

• Se endurece DMARC sin analizar reportes

• Se olvida autorizar un proveedor externo

• Se rompe la alineación SPF

• Se superan límites de DNS

¿Cómo puede ayudar Securetia?

En Securetia ayudamos a:

• Analizar SPF y DMARC existentes

• Detectar riesgos reales de suplantación

• Corregir configuraciones sin impacto operativo

• Definir políticas progresivas y seguras

• Dejar todo documentado y mantenible

Si querés revisar el estado de tu dominio o necesitás ayuda para corregirlo correctamente, podés contactarnos y lo vemos en conjunto.

Conclusión

SPF y DMARC son controles simples en concepto, pero críticos en impacto.
Una mala configuración deja el dominio expuesto a suplantación, fraude y pérdida de confianza.

Detectar el problema es fácil.
Corregirlo bien es lo que realmente protege.

Estamos muy contentos de anunciar que Vulseek ya está oficialmente disponible en AWS Marketplace. Este paso representa un gran hito para nosotros y reafirma tanto la madurez de nuestro producto como nuestro compromiso de seguir trabajando junto al ecosistema de AWS.

El proceso para llegar hasta aquí fue exigente y enriquecedor. Pasamos por varias instancias de revisión y val

idación, incluyendo la presentación de nuestro diagrama de arquitectura para garantizar que cumplimos con los estándares de seguridad, escalabilidad y confiabilidad que AWS exige. Cada una de estas etapas fue una oportunidad para reforzar y perfeccionar nuestro producto.

¿Por qué es importante para nuestros clientes?

Estar en AWS Marketplace trae beneficios directos:

• Facturación integrada: ahora nuestros clientes pueden realizar la facturación directamente a través de AWS, simplificando procesos administrativos y optimizando la gestión financiera.

• Confianza y validación: el hecho de haber superado el riguroso proceso de aprobación de AWS es una garantía adicional de calidad y seguridad.

• Acceso simplificado: adquirir y comenzar a usar Vulseek es tan fácil como hacerlo desde cualquier otro servicio del ecosistema AWS, sin configuraciones complejas.

Una experiencia que nos impulsa

Más allá de la parte técnica y los requisitos formales, esta experiencia reafirma que estamos en el camino correcto: construir soluciones sólidas, confiables y enfocadas en aportar valor real a nuestros clientes. Publicar en AWS Marketplace no es solo un logro comercial, sino también un testimonio de nuestra capacidad para cumplir con los más altos estándares del mercado.

Ahora que Vulseek está disponible en AWS Marketplace, el siguiente paso es simple: comenzar a usarlo y aprovechar al máximo sus capacidades para la gestión y detección de vulnerabilidades.

https://aws.amazon.com/marketplace/pp/prodview-oxi3fp4s6p4s6

Sabemos que muchos querían volver a repasar algunas de las charlas, o quizás no pudieron asistir al evento. Por eso, ya están disponibles para descargar en formato PDF las presentaciones utilizadas por los speakers durante la jornada.

¿Qué vas a encontrar?

• Investigaciones originales y casos reales de vulnerabilidades

• Herramientas open source explicadas desde adentro

• Técnicas de Red Team y defensas modernas

• Automatización y uso de inteligencia artificial aplicada a seguridad ofensiva

• Y mucho más...

🎥 Próximamente vamos a estar publicando los videos completos de las charlas en nuestros canales oficiales. Si todavía no te suscribiste a nuestro canal de YouTube, este es un buen momento para hacerlo.

🙏 Queremos agradecer especialmente a la Universidad de Palermo por abrirnos las puertas y acompañarnos en esta iniciativa. Sin su apoyo, este evento no hubiera sido posible.

Gracias a todos los que participaron en esta edición de H4CK3D. Si te quedaste con ganas de más, seguinos en nuestras redes para enterarte de lo que se viene 👀

📥 Accedé a las presentaciones desde este enlace:

https://drive.google.com/drive/folders/188q4Jt770wZVD7P1TquzV-NhN8XYjvV0?usp=sharing

Te vamos a mostrar cómo ocurren estos ataques, qué impacto real pueden tener en tus sistemas y, lo más importante, cómo prevenirlos desde el código. Todo explicado con ejemplos prácticos y recomendaciones concretas para aplicar en tus desarrollos.

🔒 El desarrollo seguro no es opcional: es una responsabilidad. Sumate a esta charla pensada especialmente para quienes quieren escribir código más robusto, confiable y seguro.

🧠 ¿Qué vas a aprender?

• Qué es una SQL Injection y cómo se explota

• Qué tipos de XSS existen y cómo afectan a los usuarios

• Casos reales de vulnerabilidades mal gestionadas

• Buenas prácticas y herramientas para prevenir ataques

• Cómo integrar la seguridad en tu proceso de desarrollo

🎯 Público objetivo

Este webinar está pensado para:

• Desarrolladores/as de software (back y front)

• Líderes técnicos

• Equipos de QA y testing

• Arquitectos/as de software

• Personas interesadas en seguridad informática

• Estudiantes avanzados de programación o sistemas

📝 Inscripción

La participación es gratuita pero los cupos son limitados.

¡Reservá tu lugar hoy!

https://www.eventbrite.com.ar/e/securetia-webinar-desarrollo-seguro-tickets-1452796536549?aff=oddtdtcreator

Fue una jornada intensa, con charlas técnicas, desafíos en vivo, comunidad y mucho entusiasmo. Si estuviste ahí, probablemente te cruces con alguna cara conocida. Y si no pudiste venir, esta es una buena forma de asomarte a lo que fue el evento.

Próximamente también vamos a estar subiendo los videos completos de las charlas a nuestro canal de YouTube, así que si no querés perdértelo, te recomendamos suscribirte.

Gracias a todos los que participaron y ayudaron a que H4CK3D sea lo que fue.
¡Nos vemos en la próxima!

—
El equipo de Securetia

La presentación —que podés descargar al final de este artículo— se enfocó en los desafíos reales que enfrentamos durante el desarrollo del producto, así como en las decisiones que tomamos para que Vulseek sea una solución rápida, útil y fácil de mantener.

🚧 Desafíos técnicos reales, decisiones concretas

Uno de los temas centrales de la charla fue el tiempo hasta obtener resultados útiles. Quienes trabajamos en seguridad sabemos que los escaneos de vulnerabilidades pueden ser lentos, variables o incluso inestables. Por eso, desde el inicio nos propusimos que Vulseek pudiera ofrecer resultados en menos de 5 minutos, incluso en escenarios complejos.

Para lograrlo, implementamos una arquitectura basada en colas priorizadas, escaneos paralelizados y entrega progresiva de resultados. Usamos AWS para resolver la parte de mensajería y autoscaling, pero siempre priorizamos que la solución fuera sencilla de mantener: somos un equipo chico y eso nos obliga a optimizar todo lo que hacemos.

El segundo gran desafío que abordamos fue el de entregar resultados consistentes. Incluso usando herramientas conocidas como Nmap, los resultados pueden variar enormemente según la latencia, los filtros de red o incluso la versión del sistema operativo del escáner. Analizamos ejemplos reales durante la charla (que también están en la presentación), mostrando cómo distintas configuraciones pueden generar diferencias que no son triviales de interpretar.

💡 Principios de diseño: SYLPA

Una de las ideas que más resonó durante la charla fue la noción de "SYLPA": que las cosas Sirvan Y Las Podamos Administrar.
Este principio lo aplicamos tanto a nivel técnico como organizacional. No basta con que algo funcione: tiene que poder mantenerse en el tiempo, escalar si hace falta, y no convertirse en un caos si una persona del equipo se va o cambia de rol.

Desde el diseño del stack (Python, PostgreSQL, contenedores, etc), hasta el uso de IA para priorización de vulnerabilidades (con integración de modelos como los de Anthropic), todo está pensado para que la solución funcione hoy y siga siendo viable en el futuro.

📄 Descargá la presentación

Podés ver todos estos temas en detalle descargando la presentación que usamos en el evento. Está en español y pensada tanto para perfiles técnicos como para quienes estén explorando cómo construir su propio SaaS en el mundo de la ciberseguridad:

🔍 ¿Querés probar Vulseek?

Si todavía no conocés Vulseek, podés registrarte y empezar a probarlo gratis. No pedimos tarjeta de crédito y la interfaz está completamente en español.

🔗 https://www.securetia.com/vulseek

Estamos constantemente mejorando el producto y cualquier feedback que puedas darnos es más que bienvenido.
Gracias por acompañarnos en este camino!

Vulseek Internals H4ck3d 2025

1.19MB ∙ PDF file

Download

Download

📬 Notificaciones por correo: configuralas como quieras

Ahora podés elegir cómo y cuándo recibir notificaciones de Vulseek directamente en tu correo electrónico.

🔧 Configurá esta opción desde tu perfil, dentro del apartado "Datos".

Además, si tu usuario tiene rol de Administrador, vas a poder gestionar las notificaciones de otros miembros de tu equipo desde la pantalla de Usuarios. Seleccioná el usuario que quieras modificar, hacé clic en "Editar" 📝 (esquina superior derecha del listado) y ajustá su configuración.

🖥️ Identificación de Sistemas Operativos con un solo vistazo

¿Querés saber qué sistema operativo corre en cada uno de tus activos?
Ahora en las pantallas de Direcciones IP públicas y Direcciones IP privadas, vas a ver una nueva columna con el logo del sistema operativo que Vulseek detectó automáticamente.

🔍 Pasá el cursor sobre el ícono para ver más detalles.
🖱️ Hacé clic para acceder al listado completo de activos que usan ese sistema operativo dentro de tu cuenta.

Seguimos trabajando para brindarte mayor capacidad de prevención, detección y respuesta contra ciberamenazas.

Introducción

El post se centrará principalmente en cómo recolectar los datos del disco rígido sin la alteración de los mismos utilizando una herramienta OpenSource y gratuita.

En nuestro caso de estudio trabajaremos con la distribución de DEFT Zero, la cual dispone de todas las herramientas necesarias para realizar la toma de evidencia. Para la misma utilizaremos una herramienta muy sencilla y util a la vez: dd.

Sin embargo, daremos un paseo por un listado de buenas prácticas que son recomendables realizar previo a la recolección de la evidencia.

Buenas Prácticas antes de comenzar la recolección

Según las Buenas Prácticas del Servicio Secreto de Estados Unidos, estos son algunos puntos importantes a tener en cuenta al momento de comenzar con la recolección de la evidencia dentro del ámbito de la Informática Forense:

• No utilizar la computadora ni intentar buscar evidencia.

• Fotografiar el equipo del frente y de atrás tal como se encuentra, con los cables y dispositivos conectados.

• Si la computadora se encuentra apagada, no encenderla.

• Si la computadora se encuentra encendida y en la pantalla se muestre algo, sacar una fotografía a la misma. En el caso de que la pantalla esté apagada, encenderla; y en el caso de que no se muestre la imagen en la misma mover el mouse para que se muestre en pantalla alguna imagen y luego fotografiar la misma.

• Desconectar el cable de tensión por detrás del equipo.

• En el caso de tratarse de una Notebook y que la misma no se apague al desconectar el cable, extraer la batería de la misma para que el equipo se apague.

• Etiquetar los cables para luego identificar los dispositivos conectados.

• Desconectar todos los cables y dispositivos.

• Documentar todo el procedimiento realizado.

• Mantener todos los medios, incluyendo el gabinete, lejos de imanes, radiotransmisores y otros elementos potencialmente dañinos.

• Entre otras acciones.

Identificando unidades

Tal como indicamos al comienzo e iremos recordando durante todo el post, lo más importante es que, al momento de la recolección, la evidencia no sea alterada. Por tal motivo, es indispensable que el sistema con el que trabajemos no monte las unidades conectadas de manera automática, ya que si el mismo es montado la evidencia se altera. La versión de DEFT Zero que utilizaremos no monta las unidades automáticamente.

En nuestro caso, sabemos que contamos con 2 unidades de disco. Ambos de tecnología SATA, por lo tanto, el sistema los reconocerá como sd. El que contiene la evidencia a recolectar tiene un tamaño de 100MB y el otro de 1GB. Para ver cómo los reconoce el sistema es necesario ver los logs.

En donde identificamos ambos discos. En el caso de la evidencia el sistema lo detectó como sda y el otro como sdb. Por lo tanto, para guardar la evidencia necesitaremos montar nuestro disco, en particular la unidad lógica del mismo (sdb1).

Recolectando la evidencia

La recolección de evidencia se puede hacer por partición o por disco. Es recomendable trabajar con el disco completo, ya que si eligiésemos trabajar con particiones y fuese necesario buscar información borrada en el disco no estaremos analizando las partes que no se encuentren particionadas. Durante todo el post se realizarán copias de disco completo, o como se lo conoce: Adquisición Física.

dd

Es un comando de la familia de los Sistemas Operativos Unix/Linux que permite copiar a bajo nivel (bit a bit o bloque a bloque) cualquier archivo dentro del sistema. Es importante recordar que para este tipo de Sistemas Operativos todo es un archivo. Uno de los puntos fuertes de dd es que copia los datos en crudo (raw data) y otro punto muy importante es que viene por defecto con todas las distribuciones de Unix/Linux.

Un ejemplo de cómo utilizar el comando puede ser el siguiente:

En este caso le estamos especificando que el archivo de entrada es /dev/sda, el archivo de salida es /mnt/root/forensic/artefacto01.dd y que el tamaño en que leerá los bloques será de 64 bytes.

Uno de los puntos a tener en cuenta es el tamaño del bloque, ya que cuanto más chico sea más tardará en realizar la copia. Por ejemplo, utilizando un bloque de 4096 bytes el tiempo será mucho menor.

Para determinar este tipo de tamaño es importante saber si la unidad se encuentra dañada o no, ya que de estarlo es preferible utilizar bloques más pequeños de manera de reducir la cantidad de datos corruptos. En el caso de encontrar errores en la unidad también es recomendable utilizar las opciones conv=noerror,sync. La opción noerror permite continuar después de encontrar errores y la opción sync permite rellenar los errores encontrados con 0’s.

Si bien con ambos archivos se crean en momentos diferente y se utiliza el parámetro bs distinto, se puede ver que los HASH’s tanto del dispositivo y de las evidencias tomadas son iguales.

Una buena metodología para corroborar la integridad de la evidencia es tomando los HASHs de los mismos. En este post se utilizaremos SHA256, esto es debido a que MD5 y SHA1 son algoritmos que se encuentran rotos.

Problemas de espacio

Debido a que en la actualidad los discos rígidos son muy grandes y en el hipotético caso de que necesitemos partir el archivo, podemos utilizar el comando split (también incorporado en todos los sistemas Linux)

    split -d -b 50m artefacto01.dd artefacto-partido

Cuando necesitemos volver a ensamblarlo podemos utilizar el comando cat de la siguiente manera:

cat artefacto-partido* >> artefacto-reensamblado.dd

Siempre tenemos que tener presente comprobar que el HASH sea el mismo que el original, hay que recordar que estamos manejando evidencia y que la misma tiene que ser integra y consistente.

Otra manera de reducir el tamaño de la evidencia es comprimir el archivo al momento de generarlo utilizando el comando gzip

Claramente el tamaño del archivo comprimido es muy inferior, pero no debemos olvidar de corroborar su integridad comparando los HASH’s.

Adquisición Indirecta

En el caso que estemos imposibilitados de realizar la copia en el mismo equipo (Adquisición directa), podemos enviar la evidencia por la red a algún equipo donde podamos almacenar el archivo. Para este proceso podemos utilizar el comando nc.

Nuevamente corroboramos que tanto el origen como el destino tienen el mismo contenido.

Una de las contras de dd es que no muestra progreso y que todas las comprobaciones deben realizarse de forma manual, aunque podemos utilizar las siguientes alternativas:

Utilizando el comando kill, el cual viene con todas las distribuciones Linux podremos ver el estado de nuestra copia bit a bit.

Ojo que si lo utilizamos mal podríamos matar el proceso de copia y no queremos volver a empezar.

Para que nos diga el estado de dd le pasaremos el parámetro -USR1, también es necesario pasarle el PID. Nos quedará algo por el estilo algo por el estilo:

    kill -USR1 $(ps -ef | fgrep .dd | grep -v grep | awk '{print $2}')

El comando

    ps -ef | fgrep .dd | grep -v grep | awk '{print $2}'

nos permite extraer el PID, siempre y cuando hayamos utilizado la extensión .dd.

La ejecución del kill nos dará la siguiente pantalla:

También podríamos utilizar otra herramienta que nos mantenga al tanto de lo que hace dd, como por ejemplo pv.

pv no viene por defecto con esta distro, con lo cual hay que instalarla desde el repo

    apt-get update
    apt-get install pv

Como no podía ser de otra manera, tenemos que corroborar el HASH de nuestra copia.

Bueno, hemos hecho un largo recorrido con el copiado bit a bit de la mano de dd, les dejo para que prueben Uds. otros comandos que suelen utilizarse para realizar adquisiciones bit a bit: dc3dd, dd_rescue, ewfadquire y para los que les gusta el entorno gráfico Guymager.

Una vez que hayan probado los mismos podrán decidir Uds. mismos qué herramienta por software utilizarán para realizar Adquisiciones Forenses.

Espero que les haya resultado interesante el artículo.

Nos vemos en el próximo post.

En este caso voy a hacer una breve revisión sobre algunas de las distribuciones que tenemos disponibles para llevar adelante con nuestra labor.

El fin del mismo no es recomendarles una de ellas sino presentarles algunas de las herramientas gratuitas para llevar a cabo algunas de las tareas pertenecientes a las acciones de identificación, preservación y análisis vistas en el post anterior. Y no presentaré todas las existentes, ya que, son muchas las que hoy tenemos en la actualidad, sino que nos basaremos en cuatro que son de uso gratuito, aquellas que no podemos dejar de conocer. Muchas de ellas surgen de alguna distribución de Linux. En particular, vamos a estar hablando sobre 4 de ellas, le dedicaremos este post a DEFT, Huemul, SIFT y Santoku.

No todas estas distros las utilizaremos bajo las mismas circunstancia, a medida que hablemos de cada una de ellas veremos bajo qué condición nos convendrá una u otra.

Antes de comenzar con la presentación de cada una, lo que debemos que tener presente, para considerar que una distribución es forense, es que la herramienta que utilicemos *no debe alterar bajo ningún concepto el objeto a peritar*.

DEFT

Arranquemos por DEFT, DEFT es el acrónimo de Digital Evidence & Forensic Toolkit tenemos dos sabores para esta distribución, una de ellas es DEFT 8.2 y la otra DEFT Zero rc1.

DEFT 8.2

La primera de ellas es la versión 8.2, la misma se encuentra basada en Lubuntu 12.10, tiene un tamaño de 3.1 GB y dispone de una gran variedad de herramientas para realizar nuestras labores forenses, tanto para la adquisición como para el análisis del mismo. Como vemos en la siguiente imagen, en DEFT tenemos distribuídas las aplicaciones en los siguientes grupos: Analysis, Antimalware, Data Recovery, Hashing, Imaging, Mobile Forensics, Network Forensics, OSINT, Password recovery y Reporting tools.

DEFT 8.2 también viene con DART, acrónimo de Digital Advanced Response Toolkit, el cual es un conjunto de herramientas que trabaja bajo entornos Microsoft. Posee tools de Adquisición entre las que cabe destacar la aplicación FTK Imager, herramienta gratuita perteneciebte a una empresa lider en el ámbito forense. Data Recovery, Forensics, Incident Response, Networking, Password, Visualize y Utility son otros de los tópicos dentro de DART.

Descarga DEFT 8.2

DEFT Zero

La segunda es DEFT Zero rc1, la cual es una distro reducida que tiene un tamaño de únicamente 403 MB. Esto es debido a que el fin de la misma es para que realicemos únicamente la adquisición forense para después utilizar un nuestro laboratorio las herramientas que consideremos necesarias.

Descarga DEFT Zero

Huemul

Toca el momento de hablar de Huemul, esta es una distro argentina la cual se encuentra en su versión 1.0. La misma se encuetra basada en Debian.

Una característica de esta distribución es que está separado su menú en Etapas, en donde aparecen la Etapa de Adquisición, Clonación y Análisis. También en el menú nos encontramos con Borrado seguro, Celulares y Cifrado. Otra característica de esta distro es que en el menú, tal como puede apreciarse en la siguiente imagen, no aparece solo el nombre de la aplicación sino una breve descripción de la misma.

Descarga Huemul

Santoku

Por último, tenemos a Santoku 0.5, una distribución basada en Ubuntu 14.04.1 LTS con sponsor de VIA Forensic. Una particularidad que tiene esta distro es que tiene varias herramientas para trabajar con telefonía mobile, tanto para la adquisición como así también para el análisis. Posee tools para realizar reversing de aplicaciones desarrolladas para Android y algunas otras para hacking.

En su menú tiene los siguientes grupos de aplicaciónes: Development Tools, Device Forensics, Penetration Testing, Reverse Engineering y Wireless Analyzers. Esta puede ser una buena opción en el caso de tener que trabajar con dispositivos con Android como Sistema Operativo.

Descarga Santoku

Como hemos visto en muchas de estas distribuciones, entre las herramientas forenses nos encontrado con varias tools de hacking. Por qué? se preguntaran, la realidad es que en muchos casos es necesario romper algunas barreras para llegar a realizar la labor propuesta. Pero ojo, siempre debemos disponer de la autorización del dueño del activo y/o del Juez interviniente en la causa.

Obviamente nosotros podemos armar nuestra propia distribucuón Linux con las herramientas que más nos guste pero para un caso legal, cuanto más conocida sea la distribución que utilicemos menos tendremos que defenderla, ya que, será el mismo mercado quien avale nuestra herramienta forense.

En los próximos posts empezaremos a incursionar dentro de las acciones a realizar dentro de un proceso forense utilizando herramientas provistas por alguna de las distribuciones aquí mencionadas.

Como indica el título, comenzaré por una introducción a la Informática Forense para enmarcar los próximos artículos que hablarán sobre la temática, los cuales tendrán mayor profundidad técnica.

En esta Ciencia es muy importante tener una metodología, ya que, debería poder reproducirse las acciones tomadas llegando al mismo resultado con posterioridad. No debemos olvidarnos de llevar una bitácora de las acciones realizadas.

En algunos casos nos encontraremos con los artefactos presentados como prueba digital los cuales posteriormente podrían convertirse en evidencia de la cual se nutra el Juez para dictar sentencia.

En el camino podremos encontrarnos con artefactos con barreras criptográficas que pueden dar bastante dolor de cabeza al momento de tener que aplicar forense sobre los mismos.

Definiciones

Arranquemos por algunas definiciones que nos servirán para introducirnos en este asombroso mundo de la Informática Forense.

Seguramente muchos de los lectores saben la definición pero cuando les pregunto a mis alumnos que definan Qué es la Informática? muchos se quedan pensando sin poder definirla correctamente. Para esto, citaré a la definición contenida en la RAE que indica que la Informática es un “Conjunto de conocimientos científicos y técnicas que hacen posible el tratamiento automático de la información por medio de computadoras”.

Teniendo nuestra primer definición en el bosillo, pasamos a la segunda que tiene que ver con el concepto de Ciencias Forenses, en donde la explicación más acertada es decir que “Es la aplicación de prácticas científicas dentro del proceso legal”.

No podemos dejar de nombrar a Edmon Locard quien fuera un criminalista francés, considerado uno de los principales pioneros de esta ciencia. Es famoso por enunciar el conocido “Principio de intercambio de Locard” en donde enuncia que “Siempre que dos objetos entran en contacto transfieren parte del material que incorporan al otro objeto”. Una lectura recomendable es el “Manual de Técnica Policíaca” de Locard.

Ahora necesitamos hacer un mix de las definiciones antes descriptas, la cual nos dará como resultado que la “Informática Forense es la aplicación de técnicas científicas y analíticas especializadas a infraestructura tecnológica que permiten identificar, preservar, analizar y presentar datos que sean válidos dentro de un proceso legal”.

Forense sobre Informática Forense

Dimos la definición que nos interesa, Informática Forense, es el momento de desensamblarla para comprender cada una de sus acciones.

Cuando hablamos de identificar es introducirnos en el momento, el entorno, la causa y el activo informático al cual hay que realizarle forense. Tendremos distintas metodologías para las distintas situaciones que nos surjan.

En la preservación de los artefactos que vayamos adquiriendo durante el proceso es esencial mantener la integridad de los mismos. De otro modo se estaría contaminando la evidencia y la misma no tendría valor alguno.

El analisis será nuestro próximo paso dentro de nuestro proceso forense, en donde a partir de lo adquirido llegaremos a conclusiones que harán a la causa.

Por último, se encuentra la acción de presentar, el armado del Informe Pericial o simplemente un Informe. Este siempre tiene que tener el vocabulario necesario para su comprensión por las personas que vayan a hacer lectura del mismo. En un Informe que hará vista un Gerente de Sistemas, Tecnología o Seguridad Informática de la entidad que nos solicitó el trabajo tendrá un vocabulario técnico-gerencial. Sin embargo, cuando se trata de un Informe Pericial y nuestro lector es un Juez hay que tener presente que su expertise se encuentra en el campo de las Leyes y no en el de la Informática, con lo cual debe ser claro el mensaje ya que será leído por una persona que no tiene sufuciente conocimiento sobre nuestra disciplina. Ojo, esto no quiere decir que no utilicemos ninguna palabra técnica, sino que al momento de utilizarlas se debe dar una breve descripción para darle al Juez el conocimiento necesario para la comprensión de nuestro Informe Pericial.

Algunas definiciones más

Durante lo descripto ut supra (ut supra? Si, son palabras que suelen encontrarse en causas judiciales ya que a los letrados les gusta utilizar expresiones del latín. En este caso, “ut supra” significa literalmente “como arriba” y se emplea en ciertos documentos para referirse a una fecha, cláusula o frase escrita más arriba y evitar su repetición) nos encontramos con palabras que necesitaremos tener presente:

Artefactos

Objetos obtenidos sobre el proceso de adquisición forense.

Prueba digital

Parte de la Documental presentada en una Causa Judicial, la cual deberá ser constatada por un Perito Informático.

Evidencia digital

Se habla de evidencia cuando una prueba ha sido constatada por el experto, en donde se tiene una certeza clara y manifiesta de la que no se puede dudar.

Criptografía

Se describirá brevemente este concepto, ya que, requeriríamos de una serie de artículos sobre esta temática, lo cual no descarto pero esa, esa es otra historia.

Podríamos definir como criptografía al arte y técnica de escribir con procedimientos y claves secretas o no tan secretas, de tal forma que lo escrito solamente sea inteligible para quien sepa y posea de la/s clave/s necesaria/s para descifrarlo.

Existe la Criptografía Simétrica y la Asimétrica. Ejemplos de la primera podrían ser los algoritmos 3DES y AES, los cuales utilizan la misma clave tanto para cifrar como para descifrar. Por el lado de los algoritmos criptográficos Asimétricos se encuentran RSA y DSA, en este caso se utiliza una clave para cifrar y otra para descifrar.

HASH

Es un algorítmo critográfico bastante particular, debido a que, el mismo no tiene una función de retorno, esto quiere decir que de un objeto (por ejemplo un archivo) aplicandole un algoritmo de hash obtendríamos el hash de dicho objeto pero desde este resultado será imposible obtener el objeto original.

Este algoritmo va a tener un gran valor en cuestiones forenses, ya que, con el mismo podremos asegurar la integridad de los artefactos desde el momento de la adquisición hasta el momento de la entrega del Informe Pericial.

Cadena de Custodia

La Cadena de Custodia es otro concepto muy importante dentro de la Informática Forense. Es la manera en que se asegura la NO alteración de los artefactos recolectados desde su adquisición hasta la presentación de la evidencia.

En este primer artículo aprendimos algunos conceptos claves dentro del apasionante mundo de la Informática Forense, en los siguientes artículos hablaremos sobre Mejores Prácticas en esta disciplina, forensia sobre Android, entre muchos más dentro de la temática.

También en Video!

El contenido de este artículo también se encuentra publicado en formato de video, está disponible en el siguiente link:

KRACK - Ataque de Reinstalación de Clave

Fue a mediados de Octubre que se dió a conocer el Ataque de Reinstalación de Clave o mejor conocido como KRACK (Key Reinstallation Attacks).

En este caso, la víctima es WPA2. WPA2 es un sistema que se utiliza para proteger redes inalámbricas y es el mecanismo de seguridad más utilizado en la actualidad, ya que, es, o mejor dicho, era un mecanismo seguro. Digo era porque con la llegada de KRACK ha puesto en jaque la seguridad de WPA2.

Según la investigación de Mathy Vanhoef y Frank Piessens el problema radica en el 4-way handshake con la cual se genera la clave de sesión. Ellos demostraron que el 4-way handshake permite un ataque de reinstalación de clave. En su paper indican que con WPA2 utilizando AES-CCMP un adversario pouede reproducir y descifrar paquetes, esto permite que se realice la técnica hijack TCP stream y se inyecte datos maliciosos dentro de ellos. Para el caso de WPA-TKIP el impacto es catastrófico, debido a que, los paquetes pueden ser reproducidos, descifrados y falsificados.

Para esta vulnerabilidad se encuentran múltiples CVEs asociados, entre ellos: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088

La prevención es mediante la actualización, tanto en clientes como en Access Point. Tanto Microsoft, la comunidad Linux, Intel, F5, TP-Link y muchas otras han sacado el la corrección para que KRACK no los afecte.

ROCA - Return of Coppersmith’s Attack

ROCA es la segunda vulnerabilidad sobre criptografía que hablaremos durante este post. En este caso, investigadores de la Universidad Masaryk (República Checa) descubrieron el problema en la generación de claves RSA utilizadas por una biblioteca de software adoptada en tarjetas inteligentes criptográficas, tokens de seguridad y otros chips de hardware seguros fabricados por Infineon Technologies AG permite un ataque de factorización práctico, en el que el atacante calcula la parte privada a partir de una clave públida RSA.

El ataque es factible para claves de longitud comúnmente utilizadas, incluyendo 1024 y 2048 bits, y afecta a los chips fabricados a partir de 2012.

La vulnerabilidad se caracteriza por la estructura de los primos generados que utiliza RSA, lo que hace prácticamente posible la factorización de longitudes de clave comúnmente utilizadas que incluyen 1024 y 2048 bits. Solo se necesita el conocimiento de una clave pública y no se requiere acceso físico al dispositivo vulnerable. La vulnerabilidad NO depende de un generador de números aleatorios débil o defectuoso: TODAS las claves RSA generadas por un chip vulnerable se ven afectadas. El ataque fue prácticamente verificado por varias claves RSA de 1024 bits seleccionadas al azar y por varias claves seleccionadas de 2048 bits.

En pruebas de laboratorio se obtuvo que el precio en el caso más desfavorable de la factorización en una instancia de cálculo en Amazon AWS es $ 76 para la clave de 1024 bits y aproximadamente $ 40,000 para la clave de 2048 bits.

En la primera semana del mes de febrero la vulnerabilidad fue revelada a Infineon Technologies AG, siguiendo el principio de divulgación responsable, se acordó un período de 8 meses antes de una divulgación pública. Los principales proveedores, incluidos Microsoft, Google, HP, Lenovo y Fujitsu, ya publicaron las actualizaciones de software y las directrices para una mitigación.

Pasados los 8 meses acordados, se ha hecho pública la vulnerabilidad y ha sido Octubre el mes de su publicación.

DUHK - Don’t Use Hard-coded Keys

DUHK (No usar claves codificadas) es una vulnerabilidad que afecta a los dispositivos que usan ANSI X9.31 generador de números aleatorios (RNG) junto con una clave de inicialización codificada. ANSI X9.31 RNG es un algoritmo que hasta hace poco se usaba comúnmente para generar claves criptográficas que aseguran las conexiones VPN y las sesiones de navegación web, evitando que terceros lean las comunicaciones interceptadas.

DUHK permite a los atacantes recuperar claves secretas de cifrado de implementaciones vulnerables y descifrar y leer comunicaciones que pasan por conexiones VPN o sesiones web cifradas. Los datos cifrados podrían incluir datos comerciales confidenciales, credenciales de inicio de sesión, datos de tarjetas de crédito y otro contenido confidencial. Las implementaciones afectadas fueron históricamente compatibles con FIPS, las Normas federales de procesamiento de información.

¿Quién es vulnerable?

El tráfico de cualquier VPN que utilice FortiOS 4.3.0 a FortiOS 4.3.18 puede ser descifrado por un adversario que escuche de forma pasiva en la red y que pueda observar el tráfico de enlace cifrado. Otros ataques de recuperación de claves en diferentes protocolos también pueden ser posibles.

También se han encontrado otras once implementaciones históricamente certificadas por FIPS que documentan claves de semilla X9.31 RNG codificadas en sus productos. La lista completa, descubierta hasta el momento, se encuentra en el paper de referencia.

Los usuarios de los productos afectados deberían aplicar las últimas actualizaciones de software.

Un dispositivo es vulnerable a DUHK si:

Utiliza el generador de números aleatorios X9.31

y

La clave de semilla utilizada por el generador está codificada en la implementación

y

La salida del generador de números aleatorios se usa directamente para generar claves criptográficas

y

Al menos algunos de los números aleatorios antes o después de los utilizados para hacer las claves se transmiten sin cifrar. Este es típicamente el caso para SSL / TLS e IPsec.

Conclusión

Octubre sin duda a dado que hablar en el ambiente criptográfic. Si bien no afecta directamente a algún algoritmo sino que afecta a implementaciones que utilizan algoritmos criptográfico, no deja de ser un golpe duro para dicha disciplina.

La recomendación, parece obvia y hasta suele aburrir repetirla, es tener un Patch Management adecuado dentro de nuestras infraestructuras para evitar que problemas conocidos afecten la Seguridad de nuestro negocio.

Referencias

KRACK ROCA DUHK

Introducción

Tarde o temprano, el código que escribimos va a dejar de funcionar.

Por modificar algo en una librería, por no contemplar una determinada dependencia o por mil otras razones diferentes.

Sabiendo que va a fallar, tenemos que intentar manejar esos fallos de la mejor manera posible.

Eso lo logramos a través de dos cosas:

1. Pruebas unitarias

2. Integración contínua

Además, tenemos que pensar que nuestro código tiene que ser mantenido, ya sea por nosotros o por alguna otra persona, por lo tanto, tenemos que volver ese código fácil de leer y entender.

Eso lo logramos siguiendo las mejores prácticas para la escritura de código.

En este artículo vamos a resolver esos tres puntos.

Pruebas Unitarias

Las pruebas unitarias apuntan a verificar que las porciones de nuestro código (por ejemplo, funciones de una librería) funcionan como deberían.

Dichas pruebas también van a ser escritas en código Python, y van a ser simples funciones que verifican los resultados devueltos por las funciones que queremos probar.

Python, en su librería estándar, ya cuenta con el módulo unittest, pero nosotros vamos a utilizar el módulo PyTest, que es más fácil de utilizar y ofrece salidas más completas y claras.

    pip install pytest

A continuación, vamos a crear el directorio ‘tests’ dentro del directorio principal de nuestro proyecto.

Y vamos a escribir algunos tests sencillos para nuestra librería xor.

Estos tests los vamos a poner en un archivo llamado ‘test_xor.py’.

El hecho de que el nombre del archivo empiece con ‘test’ y esté dentro del directorio ‘tests’, le permite a PyTest encontrar las pruebas y ejecutarlas de una forma sencilla.

El contenido del archivo ‘test_xor.py’ va a ser el siguiente:

    from habu.lib.xor import xor



    def test_xor():
        text = b'text to encrypt'
        encrypted = xor(text)
        assert text == xor(encrypted)


    def test_xor_w_key():
        text = b'text to encrypt'
        key = b'secret'
        encrypted = xor(text, key)
        assert text == xor(encrypted, key)

Como podemos ver, tenemos dos funciones, las dos muy parecidas.

La primera, ‘test_xor()’, xorea el texto de la variable ‘text’ y luego verifica que al volver a xorearlo, se obtenga el texto original.

La función ‘asset’ nos permite verificar una condición y hacer que el éxito o el fracaso del test dependa de ella.

En este caso, estamos verificando que ‘text’ sea igual al resultado de ‘xor(encrypted)‘.

La segunda, ‘test_xor_w_key()’, hace lo mismo que la primera, pero utiliza el parámetro que define la clave con la cual vamos a xorear.

Si guardamos el archivo y ejecutamos el comando ‘pytest -v’ (el parámetro ‘-v’, como es habitual, habilita el modo verbose, para que obtengamos más datos acerca de la ejecución de pytest):

    $ pytest 
    =================== test session starts =============================
    platform linux -- Python 3.5.2, pytest-3.0.3, py-1.4.31, pluggy-0.4.0
    rootdir: /home/f/p/habu, inifile: pytest.ini
    collected 2 items 

    test_xor.py::test_xor PASSED
    test_xor.py::test_xor_w_key PASSED

    =============== 2 passed in 0.02 seconds ============================

Como podemos ver, los tests pasaron (‘PASSED’).

Si modificamos la función ‘test_xor()’ y la cambiamos por:

    def test_xor():
        text = b'text to encrypt'
        encrypted = xor(text)
        assert text != xor(encrypted)

Vamos a generar que la prueba falle (cambiamos el == por un !=), es decir, la prueba espera que text sea diferente al resultado de xor(encrypted).

    ====================== test session starts ====================================
    platform linux -- Python 3.5.2, pytest-3.0.3, py-1.4.31, pluggy-0.4.0
    cachedir: ../.cache
    rootdir: /home/f/p/habu, inifile: pytest.ini
    collected 2 items 

    test_xor.py::test_xor FAILED
    test_xor.py::test_xor_w_key PASSED

    =========================== FAILURES ==========================================
    ___________________________ test_xor __________________________________________

        def test_xor():
            text = b'text to encrypt'
            encrypted = xor(text)
    >       assert text != xor(encrypted)
    E       assert b'text to encrypt' != b'text to encrypt'
    E        +  where b'text to encrypt' = xor(b'DUHD D_ U^SBI@D')

    test_xor.py:8: AssertionError
    ============== 1 failed, 1 passed in 0.04 seconds =============================

Claramente, PyTest nos está explicando qué fue lo que falló.

Deberíamos escribir pruebas para todas las funciones, o por lo menos, para las que consideremos más importantes.

Esto también nos fuerza a escribir funciones pequeñas, que hagan cosas claras.

Es muy difícil crear tests para funciones complejas.

Nota: En los ejemplos, podemos ver que los tests que acabo de escribir no son perfectos. Un simple caso de error sería el caso en el que la función xor() no esté haciendo absolutamente nada, y devolviera los valores sin modificar. En ese caso, las pruebas serían exitosas. Eso podríamos arreglarlo mejorando las pruebas, o creando otras pruebas adicionales, que verifiquen puntualmente el hecho de que el resultado de ‘xor()’ sea el esperado.

Integración Contínua

Con la integración contínua hacemos que nuestros tests sean ejecutados en uno o varios ambientes, para verificar que no funcionan únicamente en nuestras PC.

(Es muy habitual que las cosas funcionen solo en la máquina del desarrollador, y esto es un claro signo de que algo anda mal)

Como Habu es un proyecto hosteado en GitLab, podemos utilizar directamente su solución de integración contínua de forma gratuita.

(Para los que hosteen sus repositorios en GitHub, pueden utilizar Travis https://travis-ci.org).

Para que GitLab sepa que queremos utilizar su CI, debemos generar un archivo llamado ‘.gitlab-ci.yml’ en el directorio raíz de nuestro repositorio.

En el caso de Habu, el archivo contiene lo siguiente:

    test:
      script:
      - apt-get update -qy
      - apt-get install -y python3-dev python3-pip
      - pip3 install virtualenv
      - virtualenv --python=/usr/bin/python3 venv
      - venv/bin/pip install -r requirements.txt
      - venv/bin/pip install -r dev-requirements.txt
      - venv/bin/pip install -e .
      - venv/bin/python setup.py pytest

Como podemos ver, son simplemente los comandos que debemos ejecutar para obtener un entorno en el cual se pueda instalar Habu y ejecutar sus tests.

Cada vez que hagamos un nuevo commit del código, veremos el resultado de los tests en la interfaz web de GitLab.

NOTA: Si tienen dudas sobre el funcionamiento de GitLab-CI, pueden visitar el siguiente link: https://docs.gitlab.com/ce/ci/quick_start/README.html.

Otro de los cambios que debemos hacer para que esto funcione, es agregar las dependencias de PyTest y PyTest-Runner (este último ayuda a que sea más fácil ejecutar de forma automática PyTest).

Para esto, editamos el archivo ‘setup.py’, y lo configuramos de la siguiente forma:

    with open('README.rst') as f:
        readme = f.read()

    setup(
        name='habu',
        version='0.0.10',
        description='Ethical Hacking Utils',
        long_description=readme,
        author='Fabian Martinez Portantier',
        author_email='fportantier@securetia.com',
        url='https://gitlab.com/securetia/habu',
        license='GNU General Public License v3 (GPLv3)',
        install_requires=[
            'Click',
            'Requests',
        ],
        tests_require=[
            'pytest',
            'pytest-runner',
        ],
        packages=['habu'],
        include_package_data=True,
        entry_points='''
            [console_scripts]
            habu.ip=habu.cli.cmd_ip:cmd_ip
            habu.xor=habu.cli.cmd_xor:cmd_xor
        ''',
        classifiers=[
            "Environment :: Console",
            "Intended Audience :: Developers",
            "Intended Audience :: Information Technology",
            "Intended Audience :: System Administrators",
            "License :: OSI Approved :: GNU General Public License v3 (GPLv3)",
            "Topic :: Security",
            "Topic :: System :: Networking",
            "Programming Language :: Python :: 3.0",
            "Programming Language :: Python :: 3.6",
        ],
        keywords=['security'],
        zip_safe=False,
        test_suite='py.test',
    )

Las partes importates para lo que vimos hasta ahora son:

1. tests_require: Define qué paquetes son necesarios para ejecutar los tests

2. test_suite: Define cuál es el comando a ejecutar para correr los tests

Calidad de Código

Python cuenta con varias mejores prácticas a la hora de escribir código. La mayoría de las cuales están detalladas en el documento PEP8 https://www.python.org/dev/peps/pep-0008/.

Para verificar que nuestro código cumple con dichas mejores prácticas, y validar algunas otras que no están definidas en PEP8, podemos utilizar el módulo ‘flake8’, que reúne varias pruebas y las pone a disposición a través del comando ‘flake8’.

    $ pip install flake8

Ahora, si ejecutamos ‘flake8’, podremos ver algo como lo siguiente:

    $ flake8 
    ./habu/lib/xor.py:2:1: F401 'datetime.datetime' imported but unused
    ./habu/lib/xor.py:4:1: E302 expected 2 blank lines, found 1
    ./habu/lib/xor.py:9:26: E203 whitespace before ':'
    ./habu/lib/xor.py:11:14: E225 missing whitespace around operator
    ./habu/lib/xor.py:14:1: W391 blank line at end of file

Veremos varios problemas que agregué a propósito para demostrar el funcionamiento de flake8, y no están en el repositorio de código.

Más allá de cuestiones de estilo, como el hecho de dejar o no espacios entre operadores, podemos ver que nos está alertando sobre la importación de un módulo que no ha sido utilizado (datetime).

Corregir todas estas alertas puede ser tedioso, pero hace que nuestro código sea mucho más legible y aceptable por toda la comunidad Python.

En el caso de que flake8 no envie ninguna salida por pantalla, quiere decir que no ha encontrado ningún error.

Conclusión

Hemos visto varias formas de mejorar nuestro código, y detectar las fallas que pudieran introducir nuestras modificaciones lo antes posible.

En los próximos artículos

Vamos a agregar nuevas funcionalidades a Habu, más relacionadas con el Ethical Hacking (perdón, pero hablar de la calidad del código era necesario antes de seguir escribiendo nuevas funcionalidades).

Primero, empezaré por diferenciar estos colores de cajas. Con respecto al BlackBox se puede definir como un Pentest en el cual disponemos de poca información, en el cual tendremos que ir zurcando nuestro camino al igual que lo haría un atacante real hasta llegar a un objetivo específico.

Por otro lado, si queremos hacer una diferencia con el GreyBox, en este caso tendremos información mínima sobre la Infraestructura y podríamos disponer de un usuario con privilegios mínimos en la aplicación a analizar para ver si es posible el escalamiento de privilegios, entro otras cosas. Por ejemplo, en este caso podríamos ser un usuario descontento de la aplicación.

Por último, cuando hablamos de un Pentest de tipo WhiteBox, nos referimos a que disponemos de un conocimiento completo sobre la Infraestructura Informática, el auditor podrá tener acceso a la configuración de los activos para relevar su configuración o hasta la revisión del código fuente de la aplicación. En este caso, podríamos estar posicionados como un integrante del equipo que conoce de la infraestructura o el código de la aplicación en cuestión.

Una vez analizada rápidamente los distintos colores de la caja, veamos la diferencia principal entre un Pentest y un VA. La principal diferencia está relacionada con que en un VA el auditor va a estar analizando todas las vulnerabilidades disponibles en el objetivo a testear, mientras que en un Pentest podremos explotar aquellas vulnerabilidades que nos permitan llegar a comprometer nuestro objetivo.

Ahora bien, este post está enfocado en dar conocimiento sobre las Fases existentes, con las cuales el analista deberá familiarizarse para inmiscuirse en el proceso del Pentesting. Al finalizar podrán identificar qué fases corresponden a un Pentest y cuáles a un VA.

Fases

Dentro del proceso de un Pentest tendremos diversas fases que deben seguirse y dependerá de la tarea a desarrollarse el tiempo que se le dedique a cada una de estas fases.

Entre las mismas nos encontramos con la primera que es la firma del Contrato de Confidencialidad o NDA (Non-Disclosure Agreement) la cual será firmada tanto por el cliente como por nosotros. Para qué? Preguntarás… Paciencia… No te preocupes, en breve estaré especificando cada de las fases, este es el momento de la presentación de cada una de ellas.

La siguiente fase se la conoce como Reconocimiento y su fin es precisamente reconocer el campo de batalla.

Seguidamente se encuentra la fase de Enumeración, en la cual estaremos haciendo un relevamiento exhaustivo sobre nuestro objetivo.

La fase llamada Ganar Acceso será, para los más técnicos, la más entretenida y la que, seguramente, todos los que estén comenzando en esta disciplina estarán ansiosos por poner en práctica.

Posteriormente, nos encontramos con la fase conocida como Mantener Acceso, esta es la indicada para utilizar algún tipo de backdoor que nos permita seguir teniendo control de nuestra víctima.

Cerrando esta labor técnica nos encontramos con la fase Borrar Rastros, su fin es eliminar los rastros de la intrusión ocasionada.

Para finalizar nuestra tarea, requerimos realizar un Informe que explique a nuestro cliente en qué condiciones se encuentra el objetivo víctima planteado.

Llegó el momento de profundizar en cada una de las Fases para una mejor comprensión de las mismas.

NDA

La firma del Contrato de Confidencialidad o también conocido como NDA es esencial en este proceso. El mismo consiste en que se explicite en dicho contrato las labores a realizarse de manera minuciosa, debe estar bien claro cuáles serán las tareas a realizar durante el proceso de Pentesting pactado con el cliente. Debe especificar como será tratada la información Confidencial que vaya recolectándose durante el proyecto.

El fin de este NDA es para dar tranquilidad a ambas partes. Para el cliente será imprescindible, ya que, le dará certeza de cómo serán tratadas las vulnerabilidades encontradas y los datos confidenciales y/o sensibles recolectados. Para nosotros, será de mucha importancia, ya que es un docuento firmado por el responsable de la organización solicitando el servicio evitándonos posibles inconvenientes legales.

Habiendo descripto esta fase meramente burocrática pero no por eso menos importante, pasaré a desarrollar la siguiente fase.

Reconocimiento

Nota mental: No arrancamos ninguna tarea sin haber firmado el NDA!

La fase de Reconocimiento tiene como fin identificar el entorno en el cual se deberá trabajar. El mismo es un reconocimiento pasivo en donde podremos determinar muchas cuestiones que nos facilitarán la siguiente fase. El hecho de que sea un reconocimiento pasivo lo que quiere decir es que no vamos a estar utilizando herramientas invasivas sobre la infraestructura o sistema a analizar. Se buscará información que sea de importancia para el proyecto por medio de redes sociales, buscadores, encabezados de correos electrónicos, registros DNS, navegando los sitios tal como lo haría un usuario estándar, entre otras acciones.

El tiempo a invertir en esta fase dependerá de la tarea a realizar, por lo general se le dedica algunas horas de investigación, salvo que la labor que debamos llevar a cabo esté asociada con Ingeniría Social, en este caso el tiempo invertido será mayor.

Enumeración

A la fase de Enumeración también se la conoce como un reconocimiento activo, en esta fase empezaremos a utilizar herramientas que analizarán nuestro objetivo profundamente. Dependerá de la labor a realizar, ya que, tenemos herramientas para analizar infraestructura, aplicaciones Web, escaneadores de vulnerabilidades, clonadores de sitios web, técnicas para acceder a información de un usuario por medio de correos electrónicos, entre otros.

Ganar Acceso

Y al fin… Llegamos al proceso que todos estaban esperando, el momento de explotar!. Partiendo de las vulnerabilidades descubiertas en la fase anterior, tendremos que dedicarle un tiempo a la investigación de las herramientas y técnicas para explotar las mismas. Una vez encontrado estos exploits, procederemos a explotar las vulnerabilidades. La pregunta es: Es necesario explotar todas las vulnerabilidades que se encuentren en la fase de Enumeración? La realidad es que si quisiéramos explotar todas las vulnerabilidades se debería invertir muchísimo tiempo, el cual, por lo general los clientes no están dispuestos a pagar. Por esto es que deberemos explotar aquellas vulnerabilidades que nos permitan llegar a cumplir con nuestro objetivo. Por ejemplo, si nuestro objetivo es tomar control de la infraestructura informática y dicho entorno dispone de un Active Directory y encontramos 30 vulnerabilidades críticas en toda la infraestructura informática pero una de ellas es de uno de los DC, entonces ya sabemos por dónde comenzar.

Al ser esta una tarea intrusiva, por más que se haga de manera controlada, debe quedarle claro al cliente de las acciones que llevaremos en esta fase y en nuestro NDA firmado es donde se especifica dicha cuestión.

Mantener Acceso

En la fase de Mantener Acceso, el fin es no perder el control de los recursos tomados. Para ello en primera instancia lo que uno suele hacer es migrar de proceso, no vaya a ser cosa de que explotemos alguna vulnerabilidad de alguna herramienta la cual el usuario pueda cerrar y de esta manera quedarnos sin control del activo informático. El siguiente paso sería dejar persistente nuestro acceso, dejando un backdoor en el activo que nos permitirá volver a tomar el control de dicho recurso.

Este es otro de los puntos que debe tener claro nuestro cliente ya que a nadie le gusta que le dejen backdoors en sus sistemas, no olvidemos informar de todos los backdoors que dejemos en los sistemas para que con posterioridad puedan eliminarlos. Calculo que a esta altura no sería necesario indicar dónde tiene que especificarse, no? Por las dudas, el NDA será el lugar indicado.

Borrar Rastros

Borrar rastros es la técnica antiforense que se utilizará en el proceso. Al mejor estilo Ninja, se borrarán todos los rastros que dejemos durante las fases anteriores. Teniendo en cuenta los residuos de los exploits que utilicemos, los logs de los Sistemas Operativos y aplicaciones con las que hayamos trabajado, de forma tal de identificar cuan seguro se guardan las trazas de las acciones realizadas dentro de los sistemas de la Organización.

Generar Informe

Como última fase tenemos la Generación del Informe. El mismo debe tener el contenido adecuado para su destinatarios. Qué quiere decir esto? Tiene que ver con el lenguaje que utilizaremos en cada reporte. Suelen realizarse 2 (dos) informes finales, un Gerencial y uno Técnico.

En el Informe Gerencial debe especificarse las tareas realizadas, una conclusión con respecto a los resultados obtenidos a partir del análisis realizado. Debe ser claro y conciso, tratando de utilizar palabras no técnicas para que pueda ser comprendido por gente del Negocio. Algo que no debe faltar en este informe es el estado de situación del objetivo analizado.

Luego tenemos el Informe Técnico, este último tendrá todo el contenido necesario como para que el área técnica de la Organización comprenda las acciones realizadas durante el proceso, debe indicar las herramientas utilizadas, evidencias y recomendaciones de mejora. No se asusten si en el primer Informe Técnico en una empresa en la cual no ha realizado este tipo de actividades sean cientos de páginas. Es algo normal que a medida que aumenta el Nivel de Madurez de la Organización con respecto a la Seguridad Informática este número de páginas se reduzca drásticamente.

Concluyendo

Bien, hemos pasado por las diferentes Fases de un Pentest. Obviamente, siempre que no hayamos llegado a nuestro cometido podremos iterar entre la fase de Ganar Acceso y la de Enumeración con el fin de ir identificando nuevos horizontes.

Espero haberles llevado un poco de claridad sobre el proceso de un Pentest. En los siguientes posts empezaremos a utilizar técnicas y herramientas utilizadas por los ciberdelincuentes para comprometer la Infraestructuras Informáticas de las Organizaciones.

Introducción

Como bien lo explica la Wikipedia, ‘XOR’ puede referirse a varias cosas (todas ellas muy relacionadas entre sí):

• La puerta XOR, en electrónica.

• El operador XOR, en lógica, matemáticas y programación.

• El cifrado XOR

El ‘o exclusivo’ (eXclusive OR) es un operador lógico simbolizado como XOR, EOR, EXOR, ⊻, o ⊕ es un tipo de disyunción lógica de dos operandos.

Nota: El operador XOR en python es ^

Una disyunción solamente es verdadera cuando ambas partes tienen valores diferentes de verdad, es decir, cuando una u otra es verdadero. No en el caso de que ambos sean verdaderos o ambos sean falsos.

Por eso, siempre que hagamos un XOR de un valor consigo mismo vamos a obtener falso (A ^ A = False)

Observemos los siguientes ejemplos:

• True ^ True = False

• True ^ False = True

• False ^ True = True

• False ^ False = False

Lo mismo, pero en python:

    $ python
    Python 3.5.2 (default, Jun 28 2016, 08:46:01)
    [GCC 6.1.1 20160602] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> True ^ True
    False
    >>> True ^ False
    True
    >>> False ^ True
    True
    >>> False ^ False
    False

NOTA: Aquí estamos utilizando Python en modo interactivo. A partir de ahora, los ejemplos en modo interactivo van a estar marcados por el prompt ”>>>” y voy a omitir todos los demás mensajes de versión y ayuda para hacer el código más breve.

Aplicaciones de XOR

XOR tiene una propiedad que la hace ser muy importante para el uso en la criptografía:

“La doble aplicación de XOR resulta en la identidad”

Esto quiere decir que si aplicamos la función XOR a un valor, y luego se la volvemos a aplicar, obtenemos el valor original, lo podemos explicar así:

(A ^ B) ^ B = A

En Python:

    >>> (True ^ True) ^ True
    True
    >>> (True ^ False) ^ False
    True
    >>> (False ^ True) ^ True
    False
    >>> (False ^ False) ^ False
    False

Viendo esto, podemos determinar que, si tenemos una secuencia de valores True o False, que vamos a llamar “A”, y otra secuencia de valores que vamos a llamar “B”, y a “A” le aplicamos XOR utilizando B, obtenemos una tercer secuencia de valores, que llamaremos “C”. Si a “C” le aplicamos XOR con “B”, volvemos a obtener “A”.

¿Qué es lo importante de esto? Acabamos de cifrar los datos.

Con una función tan básica como XOR, y una clave, podemos empezar a cifrar datos.

Siempre debemos recordar que todos los datos, en las computadoras, terminan siendo representados por un 0 o por un 1.

(Muchas veces vamos a ver el mapeo de True = 1, False = 0)

Creando la Función XOR

Vamos a desarrollar, paso a paso, la función XOR que luego vamos a implementar como un comando de Habu.

Para eso, primero vamos a introducir la función os.urandom(), que sirve para solicitar una n cantidad de datos aleatorios a nuestro sistema operativo. https://docs.python.org/3/library/os.html#os.urandom

    >>> import os
    >>> A = os.urandom(8)
    >>> for x in A:
    ...     print(x)
    ...
    216
    122
    245
    149
    246
    94
    189
    27

En el código anterior asignamos a ‘A’ 8 bytes aleatorios. Luego recorremos los 8 bytes y mostramos cada uno con la función ‘print’.

Cada byte aleatorio va a tener un valor entre 0 y 255, porque un byte son 8 bits, y con 8 bits podemos representar valores desde el 0 al 255.

NOTA: Como a continuación vamos a utilizar una función llamada ‘zip()’, primero vamos a explicar para qué sirve.

La función zip permite agregar varios iterables, devolviendo un iterable de tuplas, en los que cada elemento i de la tupla se corresponde con los elementos i de cada uno de los iterables que se pasaron como parámetro.

Un ejemplo:

    >>> A = ['pera', 'manzana', 'limon']
    >>> B = ['verde', 'roja', 'amarillo']
    >>>
    >>> list(zip(A,B))
    [('pera', 'verde'), ('manzana', 'roja'), ('limon', 'amarillo')]

Como detalle, tenemos que marcar que estoy convirtiendo el resultado de zip a una lista, para poder mostrarlo más facilmente con la función print.

Ahora vamos a hacer el ejercicio de trabajar con los valores A, B y C. Teniendo el valor A, lo vamos a XORear con B, para obtener C. Al valor C, lo vamos a XORear con B, y obtendremos el valor A.

    >>> import os
    >>>
    >>> A = os.urandom(8)
    >>> B = os.urandom(8)
    >>>
    >>> list(A)
    [151, 82, 79, 150, 128, 52, 105, 103]
    >>>
    >>> list(B)
    [166, 90, 35, 99, 7, 42, 171, 28]
    >>>
    >>> C = bytes([ a^b for a,b in zip(A,B) ])
    >>>
    >>> list(C)
    [49, 8, 108, 245, 135, 30, 194, 123]
    >>>
    >>> D = bytes([ c^b for c,b in zip(C,B) ])
    >>>
    >>> list(D)
    [151, 82, 79, 150, 128, 52, 105, 103]
    >>>
    >>> A == D
    True

Acabamos de hacer muchas cosas en pocas líneas, que ahora vamos a pasar a explicar…

Primero, creamos las variables A y B, con 8 bytes aleatorios cada uno.

    >>> A = os.urandom(8)
    >>> B = os.urandom(8)

Mostramos los valores de A y B, convirtiéndolos en listas con la función list().

    >>> list(A)
    [151, 82, 79, 150, 128, 52, 105, 103]
    >>>
    >>> list(B)
    [166, 90, 35, 99, 7, 42, 171, 28]

Creamos C, que se calcula de la siguiente forma:

Con zip(), generamos un iterador con un tupla para cada elemento de A,B. Por ejemplo, la primer tupla generada va a ser (151, 166).

Para cada tupla de ese iterador, asignamos los valores en ‘a’ y ‘b’, es decir, en la primera iteración sobre el iterador, el valor de ‘a’ = 151 y el de ‘b’ = 166.

Aplicamos la función XOR sobre los valores de ‘a’ y ‘b’ (a^b).

Generamos una lista con todos los valores obtenidos de las iteraciones.

Esa lista, la convertimos al tipo de dato ‘bytes’, para que tenga el mismo tipo de dato que A y B, con el propósito de poder comprarlos más adelante.

    >>> C = bytes([ a^b for a,b in zip(A,B) ])

Con ‘list(C)’ lo que hicimos fue mostrar por pantalla una representación de C en formato de lista, porque si mostramos el dato en bytes, se va a ver algo así:

    b'1 lõ‡ Â{'

Llegado a este punto, ya obtuvimos el resultado de XORear A con B, y lo almacenamos en la variable C.

Ahora, vamos a repetir el proceso, XOReando C y B, y almacenando el resultado en la variable D.

    >>> D = bytes([ c^b for c,b in zip(C,B) ])

Anteriormente dijimos que: (A ^ B) ^ B = A

Entonces, si XOReamos C con B, deberíamos obtener el valor de A.

Con ‘A == D’, verificamos que A y D tengan el mismo valor y, como podemos ver, el resultado de la comparación fue True, por lo que, efectivamente, obtuvimos en D el valor de A.

    >>> A == D
    True

Acabamos de cifrar el valor de A con la clave B, para obtener C. Luego desciframos C con la clave B, y volvimos a obtener el valor de A.

Datos y Claves de Diferente Longitud

En el ejemplo anterior, A y B tenían la misma longitud (8 bytes) y eso le permitía a la función zip() generar un iterable con 8 tuplas (una por cada byte).

Hay un detalle, y es que, si la función zip() encuentra que los dos o más iterables que se le pasan como parámetro, tienen distinta longitud, va a devolver un iterable del tamaño del menor de los iterables que se le pasó como parámetro.

(Si A tuviera 8 bytes y B tuviera 10 bytes, el resultado de zip va a ser un iterable de 8 tuplas, y los últimos 2 bytes de B van a ser descartados)

Cada vez que ciframos datos, es muy habitual que la clave de cifrado sea de menor longitud que los datos que estamos cifrando (salvo que estemos usando un One Time Pad, pero eso va a ser para un próximo artículo).

Para resolver este problema, podemos utilizar la función cycle(), del módulo itertools, que nos permite recorrer un iterable y, una vez que sea han terminado los elementos, empezar a recorrerlo nuevamente todas las veces que sea necesario.

Solamente tenemos que hacer unos pocos cambios en el código: (voy a poner unicamente el código modificado)

    >>> from itertools import cycle
    >>>
    >>> C = bytes([ a^b for a,b in zip(A,cycle(B)) ])

NOTA: Si bien no es habitual, en el caso de que B tenga mayor longitud que A, no debemos preocuparnos, porque vamos a poder XORear sin problemas. Si intentamos utilizar cycle() tanto para A como para B, el programa va a empezar a consumir toda la memoria de nuestro sistema, porque nunca va a saber donde encontrar un fin.

Implementación Final

A continuación muestro el código final de la implementación de la función xor(), tal como está en el repositorio de habu:

    def xor(a, b='0'.encode()):

        return bytes([ a^b for a,b in zip(a,cycle(b)) ])

El único cambio que se hizo es el de definir un valor por defecto a la función xor().

En el caso de que no sea pase un segundo valor (la clave), el XOReado se va a realizar con ‘0’, lo cual no representa un nivel de seguridad, pero permite realizar el proceso, el cual muchas veces es utilizado para ofuscar datos.

Y a continuación podemos ver el código del comando habu.xor:

    import click
    from habu.lib.xor import xor

    @click.command()
    @click.option('-k', default='0', help='Encryption key')
    @click.option('-i', type=click.File('rb'), required=True, help='Input file')
    @click.option('-o', type=click.File('wb'), required=True, help='Output file')
    def cmd_xor(k, i, o):
        """XOR cipher"""
        o.write(xor(i.read(), k.encode()))


    if __name__ == '__main__':
        cmd_xor()

Como podemos ver, click hace un gran trabajo con el manejo de parámetros, y se encarga automáticamente de abrir y cerrar los archivos que se pasan por parámetro.

Conclusión

En este artículo vimos una implementación de XOR en Python y cómo implementar un comando utilizando el paquete ‘Click’ que permite utilizar archivos como parámetro.

En los próximos artículos

Vamos a ver cómo podemos mejorar la calidad de nuestro código, siguiendo las mejores prácticas e implementando pruebas unitarias, para verificar que nuestro código verdaderamente funciona como lo esperamos.

Introducción

En Securetia, al momento de realizar Penetration Tests lo hacemos de forma “artesanal”, es decir, que no nos limitamos a ejecutar herramientas automatizadas (como OpenVAS), si no que también realizamos un análisis manual, con herramientas particulares de acuerdo a cada situación.

Esto nos ha llevado a desarrollar algunas herramientas y scripts para cada caso particular.

Voy a aprovechar estos artículos para unificar estos pequeños programas en una herramienta un poco más organizada y documentada. Además de ser código abierto y hostearla en gitlab.

Como va a estar escrita con espíritu pedagógico, la herramienta va a ser desarrollada poco a poco, empezando por conceptos básicos e irá implementando funcionalidades más avanzadas a medida que pasen los artículos.

Software Necesario

Para trabajar en este proyecto, necesitamos lo siguiente:

• Python 3.x

• Git

Virtualenv

En Python se suelen utilizar entornos virtuales para aislar los paquetes instalados que son necesarios para cada proyecto en el que trabajamos o utilizamos. Esto nos va a beneficiar muchísimo al momento de evitar colisiones entre distintas versiones de los paquetes.

Para gestionar los entornos virtuales vamos a utilizar virtualenvwrapper, el cual podemos instalar a través de pip:

    $ sudo pip install virtualenvwrapper

Una vez instalado, vamos a poder crear un nuevo entorno virtual:

    $ mkvirtualenv habu
    Using base prefix '/usr'
    New python executable in /home/fabian/.python-envs/habu/bin/python3
    Not overwriting existing python script /home/fabian/.python-envs/habu/bin/python (you must use /home/fabian/.python-envs/habu/bin/python3)
    Installing setuptools, pip, wheel...done.
    (habu)$

(No es necesario que el entorno virtual se llame de ninguna forma en particular, pero ponerle el mismo nombre del proyecto en el que estamos trabajando, ayuda a simplificar las cosas)

Como habremos notado, nuestro prompt ahora incluye el nombre del entorno virtual en el que estamos trabajando.

Esto ha cambiado (entre otras cosas) cuál es nuestro intérprete de python por defecto:

$ which python
/home/fabian/.python-envs/habu/bin/python

Cada vez que instalemos un paquete estando dentro del entorno virtual, el mismo se va a instalar únicamente para ese entorno virtual.

Podemos utilizar ‘deactivate’ para desactivar el entorno virtual, y ‘workon’ para entrar en el entorno virtual:

(habu)$ which python
/home/fabian/.python-envs/habu/bin/python
(habu)$ deactivate 
$ which python
/usr/bin/python
$ workon habu
(habu)$ which python
/home/fabian/.python-envs/habu/bin/python

Estructura del Proyecto

Vamos a intentar mantener esto lo más sencillo posible, con el objetivo de hacerlo amigable a los que no estén tan familiarizados con Python. Así que la estructura no va a tener grandes cosas.

El repositorio de código está hosteado en https://gitlab.com/securetia/habu.

Para traernos el proyecto:

$ git clone https://gitlab.com/securetia/habu
Cloning into 'habu'...
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), done.

Ahora tenemos el directorio habu, con una estructura similar a la siguiente:

├── dev-requirements.txt
├── docs
├── habu
│   ├── cli
│   │   ├── __init__.py
│   │   └── cmd_ip.py
│   ├── __init__.py
│   └── lib
│       └── ip.py
├── LICENSE
├── README.md
├── setup.py
└── tests

Es una estructura relativamente sencilla, la cual detallaremos poco a poco. Por ahora, nos interesa saber lo siguiente:

• dev-requirements.txt: Lista de paquetes necesarios para trabajar en el desarrollo de habu

• docs: Documentación

• habu: Directorio donde va a ir el código del proyecto

• LICENSE: Licencia del proyecto

• README: Archivo ‘leeme’ en formato markdown (para gitlab)

• setup.py: Instrucciones para la instalación del paquete a través de pip

• tests: Directorio con los tests de calidad del proyecto

Uno de los archivos más importantes es ‘setup.py’, que contiene instrucciones para la instalación del paquete a través de pip, e información como las dependencias.

$ cat setup.py 
from setuptools import setup

with open('README.md') as f:
    readme = f.read()

with open('LICENSE') as f:
    license = f.read()

setup(
    name='habu',
    version='0.0.1',
    description='Penetration Testing Utils',
    long_description=readme,
    author='Fabian Martinez Portantier',
    author_email='fportantier@securetia.com',
    url='https://gitlab.com/securetia/habu',
    license=license,
    install_requires=[
        'Click',
        'Requests',
    ],
    packages=['habu'],
    include_package_data=True,
    entry_points='''
        [console_scripts]
        habu.ip=habu.cli.cmd_ip:cmd_ip
    ''',
)

Por ahora, las partes más importantes son:

• install_requires: Define las dependencias del paquete

• entry_points: Define los comandos que va a proveer el paquete

Librería y Ejecutables

El objetivo del proyecto es el de proveer comandos útiles para las tareas de un Penetration Test, así como también una librería que ponga a disposición las funciones utilizadas por los comandos, para que el proyecto pueda ser utilizado para la construcción rápida de otras herramientas.

Por eso, existen los directorios ‘lib’ y ‘cli’ en los cuales residen las funciones y los comandos, respectivamente.

Cuál es mi IP

Una de las funciones más básicas que podemos implementar, para demostrar la forma de trabajo del proyecto, es la de conocer cuál es nuestra dirección IP pública.

Para eso, tenemos la librería ip (lib/ip.py), que contiene la función ‘get_ip’:

import requests

def get_ip():
    return requests.get('https://api.ipify.org').text

if __name__ == '__main__':
    print(get_ip())

Esta librería utiliza el paquete ‘requests’ para facilitar el trabajo con peticiones HTTP.

La función ‘get_ip’ simplemente realiza una petición al servicio

https://api.ipify.org

, que devuelve un string con únicamente nuestra dirección IP pública, y devuelve ese string como resultado.

En el caso de que el módulo sea ejecutado directamente (if name == ’main’) se ejecuta la función get_ip()

Esto nos permite hacer lo siguiente:

$ python lib/ip.py 
182.13.121.142

De todos modos, eso no sería muy práctico, por lo que definimos el archivo ‘cli/cmd_ip.py’, con lo siguiente:

import click
from habu.lib.ip import get_ip

@click.command()
def cmd_ip():
    """Example script."""
    print(get_ip())

Aquí utilizamos el paquete ‘click’ para ayudarnos a construir nuestra interfaz CLI.

Decoramos la función cmd_ip con ‘click.command()’ para declarar que es un comando.

Nota: ‘Decorar’ una función nos permite llamar a otra función para modificar su comportamiento. En otros artículos vamos a usar más decoradores y a explicarlos mejor.

entry_points='''
    [console_scripts]
    habu.ip=habu.cli.cmd_ip:cmd_ip
''',

Eso le indica a pip que tiene que poner a disposición el comando ‘habu.ip’ que, al ser ejecutado, va a llamar a la función cmd_ip, que reside dentro del archivo cmd_ip.py, que a su vez reside dentro del módulo cli, que a su vez reside dentro del paquete habu (por eso la sintáxis: habu.cli.cmd_ip:cmd_ip)

Para instalar el paquete habu en nuestro entorno virtual, podemos pararnos en la raíz del paquete y utilizar el siguiente comando:

$ pip install -e .
Obtaining file:///home/fabian/habu
Collecting Click (from habu==0.0.1)
Collecting Requests (from habu==0.0.1)
  Using cached requests-2.11.1-py2.py3-none-any.whl
Installing collected packages: Click, Requests, habu
  Running setup.py develop for habu
Successfully installed Click-6.6 Requests-2.11.1 habu

Como podemos ver, no solamente se ha instalado el paquete habu, si no también sus dependencias (eso es gracias a que están detalladas en el archivo setup.py).

Ahora disponemos del ejecutable ‘habu.ip’:

$ habu.ip 
186.19.120.102

Ejecutando Fuera del Entorno Virtual

Si salimos del entorno virtual, no vamos a tener acceso al comando habu.ip, pero eso es simplemente porque no va a estar en nuestro PATH.

No es una buena idea agregar el directorio en el cual reside el comando, debido a que hay otros comandos que colisionarían, como pip, python, etc.

Una forma bastante sencilla es incluir lo siguiente en nuestro .bashrc (en el caso de no usar bash, tendremos que verificar la documentación de nuestra shell)

for f in $(ls -1 ~/.python-envs/habu/bin)
do
    alias $(basename $f)="~/.python-envs/habu/bin/$f"
done

Esto genera un alias para cada comando que empieza con ‘habu.’, además, los scripts generados por setuptools permiten que los comandos funcionen fuera del entorno virtual (se encargan de que cada comando ingrese al entorno virtual antes de ejecutarse)

Conclusión

En este artículo hemos hecho una buena introducción a cómo empezar a trabajar en un proyecto Python para generar una interfaz de línea de comandos y una librería.

Ya contamos con los fundamentos para empezar a modificar el código y jugar con las diferentes funcionalidades.

En los próximos artículos

Vamos a implementar más funcionalidades asociadas a los Penetration Tests (la funcionalidad que vimos en este artículo fue un ejemplo muy básico).

En el artículo anterior hicimos un análisis de cómo se debe planificar el proceso de inteligencia, para dimensionarlo de forma adecuada.

Tipos de Recolección

El concepto de “recolectar” información a través de OSINT puede tomar varias formas, las cuales van a determinar, en muchos casos, el orden de la recolección, su fiabilidad, etc.

Recolección Pasiva

En este tipo de recolección, nunca enviaremos tráfico directamente a los sistemas de nuestro objetivo. Esto quiere decir que podemos consultar únicamente información archivada o almacenada en otras bases de datos y registros.

Debido a que esta información puede ser incorrecta o estar desactualizada, debemos intentar determinar la veracidad de dicha información antes de tomarla en serio.

Recolección Semi Pasiva

En este caso vamos a interactuar con los sistemas de nuestro objetivo, pero únicamente enviando tráfico que podría ser considerado “normal”. Por ejemplo, podemos visitar el sitio web de nuestro objetivo, para obtener datos de forma manual, pero no podemos lanzar un escaneo de vulnerabilidades.

La clave de esto es no generar sospechas acerca de nuestras actividades.

Recolección Activa

Este tipo de actividades posiblemente sea detectada por los sistemas objetivo, debido a que incluyen la emisión de tráfico sospechoso o malicioso. En esta categoría entran los escaneos de puertos, análisis de vulnerabilidades, etc.

Otra de las tareas que entra en esta categoría es la de emitir tráfico malicioso y determinar si el sistema objetivo lo bloquea utilizando medidas de protección, como IPS, WAF, etc.

Ordenamiento

Es habitual que las técnicas de recolección sean ordenadas de la misma forma en la que acaban de ser presentadas. Es decir, primero realizar las tareas pasivas, luego las semi pasivas y, por último, las tareas activas.

Debemos tener en cuenta que, como hemos analizado anteriormente, cada una de las tareas de recolección puede disparar la necesidad de realizar nuevas tareas (cada vez que una de las tareas aporta nuevos datos, estos datos pueden requerir la realización de nuevas tareas).

Por ejemplo, si a través de una técnica de escaneo de vulnerabilidades (activa) detectamos una nueva dirección IP asociada a nuestro objetivo, podemos buscar información relacionada a esa IP en bases de datos públicas (una técnica pasiva).

Por lo tanto, el ordenamiento de “Pasivo, Semi Pasivo, Activo” es únicamente el orden inicial de las tareas.

Similitudes Con Pruebas de Intrusión

La tareas anteriormente descritas pueden resultar similares (y en muchos casos iguales) a las tareas que se realizan en las fases de “Enumeración” y “Escaneo” de las Pruebas de Intrusión o “Penetration Tests”.

La diferencia fundamental entre un “Pentration Test” y el “Proceso de Inteligencia” es que este último resulta ser un proceso constante, que se nutre de forma interminable. Mientras que, un Penetration Test, tiene un final bien marcado, que resulta en un informe final.

Cuando hablamos de “Inteligencia”, vamos a obtener actualizaciones constantes de información, lo que puede generar informes de inteligencia periódicos, pero ninguno de ellos puede determinarse como “final”, debido a que existen cambios constantes en las situaciones que analizamos.

Legalidad De Las Pruebas

Así como en los Penetration Test, debemos verificar que contamos con los permisos adecuados para la realización de las tareas antes de llevarlas a cabo.

Las tareas de inteligencia conllevan el análisis tanto de la organización para la cual trabajamos (ya sea que formamos parte de la organización o que somos sus proveedores de servicios de seguridad), así como también de otras organizaciones de interés, como la competencia, proveedores de internet, etc.

Es muy importante que tengamos bien claro qué acciones podemos tomar de forma “legal” y qué otras no nos están permitidas. Para evitar cualquier tipo de problemas, nunca deberíamos realizar acciones “Activas” contra sistemas para los cuales no contamos con una autorización escrita.

En el artículo anterior hicimos un análisis de los requerimientos de inteligencia que puede tener nuestra organización, y cómo podemos beneficiarnos de llevar a cabo un proceso de inteligencia.

Desarrollo de la Arquitectura de Inteligencia

Para el desarrollo de la arquitectura de inteligencia debemos tener en cuenta varios factores, como los recursos que vamos a asignar, y las fuentes de información que vamos a consultar.

Esto debe ser claro desde el inicio, debido a que los resultados que podemos llegar a esperar, van a depender de esto.

Cuando hablamos de “recursos”, debemos tener en cuenta los siguientes tres tipos:

1. Personas

2. Dinero

3. Tiempo

De ser posible, siempre va a ser mejor contar con un balance entre los tres.

En cualquier caso, es importante que seamos concientes de cuáles son las limitantes que nos impone la situación actual, y nos ajustemos oportunamente a ella.

Por otra parte, debemos considerar que el “tiempo” y el “dinero” son recursos mucho más fáciles de medir que las “personas”. Debido a que hay factores determinantes, como la capacitación y experiencia de las personas con las que contamos.

Plan de Recolección

El plan de recolección se vuelve fundamental en los casos en los que el equipo de inteligencia es relativamente grande, y debe poder coordinarse para no malgastar esfuerzos. Aunque de todos modos es útil en equipos pequeños, debido a la necesidad de coordinar y ordenar las tareas de recolección.

Se deberán armonizar las capacidades de recolección y análisis, para no generar una sobrecarga de datos (si recabamos una cantidad de datos que no tenemos forma de analizar, perdemos el tiempo).

Fuentes de Información

Existen una gran cantidad de fuentes de información con las que podemos nutrir nuestro proceso de inteligencia. Eso, aunque al principio no lo parezca, genera dos inconvenientes que debemos resolver:

1) Seleccionar Las Fuentes Más Adecuadas

Teniendo tantas fuentes de información para consumir, vamos a vernos tentados de “consumirlas todas”, lo cual puede volverse rápidamente una tarea monumental y una total pérdida de tiempo.

Es necesario que aumentemos gradualmente la cantidad de fuentes de datos que consumimos, en la medida en la que podemos manejar las existentes.

Por lo tanto, es recomendable empezar por una o pocas fuentes de información, e ir agregando más a medida que completamos las tareas de procesamiento y análisis de forma exitosa.

Llegado el momento, vamos a contar con un proceso de inteligencia que pueda consumir datos desde varias fuentes de información, procesándolas y analizándolas de forma correcta.

2) Determinar El Origen Real De Los Datos

Cuando seleccionamos una fuente de información, debemos estar seguros de cuál es la fuente de datos que está utilizando esa misma fuente.

¿Suena confuso?

Pensemos en que las fuentes de datos, a su vez, utilizan fuentes de datos.

Imaginemos que un periodista publica una noticia en un diario, y que varios medios de comunicación repiten la noticia sin citar la fuente. Da la impresión de que la noticia es verdadera, debido a que aparece en múltiples medios pero, en realidad, es una única publicación, que simplemente fue repetida una y otra vez. Independientemente de si la noticia es cierta o no, la repetición genera una sensación de fiabilidad.

Debido a esto, debemos tener mucho cuidado al agregar fuentes de información, y tener en cuenta que no debemos agregar fuentes que se nuestran la una de la otra.

Esto está relacionado con el siguiente punto.

3) Asignar Fiabilidad

Podemos tener un caso como el ejemplo anterior, en el que pensamos que una noticia es verdadera porque ha aparecido en varios medios, cuando en realidad fue un único medio el que la publicó y los otros se limitaron a publicarla (sin verificarla).

También podemos tener casos en los que pensamos que estamos trabajando con información actualizada, cuando en realidad estamos tratando con información que ha quedado obsoleta.

Pensemos en las listas de bloqueo de direcciones IP.

Si una organización publica informes sobre las direcciones IP desde las cuales ha recibido ataques, pero no indica durante cuánto tiempo las direcciones se mantienen en la lista luego de que hayan cesado los ataques, se pueden generar varias confusiones.

Por ejemplo, si la organización publica los ataques del último mes (30 días), y nosotros pensamos que es información diaria, podríamos estar procesando información que ya no es válida. Ya sea porque los ataques se han interrumpido, o porque el atacante a cambiado de dirección IP.

Es por eso que debemos saber qué tan fiables son los datos y cada cuánto son actualizados.

En artículos posteriores, analizaremos diversas tareas de ciberinteligencia.

En el artículo anterior hicimos una introducción acerca de qué es la inteligencia, los tipos de inteligencia existenes y el ciclo de inteligencia.

Identificación y Priorización

Debemos preguntarnos “¿Cuáles son nuestras necesidades de inteligencia?“. Es decir, para qué es que vamos a invertir recursos en el proceso de inteligencia, con qué fines.

En particular, vamos a centrarnos en las necesidades comunes de las organizaciones comerciales, aunque los procesos y tareas son relativamente similares para cualquier tipo de actividad.

Podemos definir una lista de posibles preguntas a responder a través de la inteligencia, comunes a la mayoría de las organizaciones:

1) ¿Qué información de inteligencia puede ser obtenida acerca de nosotros?

Podemos citar muchas fuentes que remarcan la importancia del autoconocimiento. Tal vez, el más famoso es “El Arte de la Guerra”, de Sun Tzu, que dice:

Si conoces a los demás y te conoces a ti mismo, ni en cien batallas correrás peligro; si no conoces a los demás, pero te conoces a ti mismo, perderás una batalla y ganarás otra; si no conoces a los demás ni te conoces a ti mismo, correrás peligro en cada batalla.”

Con esto podemos apreciar que conocernos a nosotros mismos es igual o más importante que conocer a nuestros posibles adversarios.

Por eso, las organizaciones deben estar al tanto de cuál es la información de inteligencia que puede ser obtenida acerca de ellas. Conceptualmente, es muy similar al hecho de realizar un Penetration Test, donde intentamos atacarnos a nosotros mismos para ver hasta dónde podría llegar un atacante real.

Algunos datos que podrían llegar a ser de utilidad son:

• Dominios y Sitios Web

• Direcciones IP

• Direcciones de Email Válidas

• Cuentas en Redes Sociales

• Ubicaciones Geográficas

• Datos Sobre Miembros de la Organización

• Reputación en Bases de Threat Intelligence

• Software y Proveedores de Servicio

2) ¿Qué Amenazas Podrían Afectarnos?

Debemos estar al tanto de cuáles son las amenazas que podrían llegar a generar un impacto negativo en nuestra organización.

Para eso es necesario que podamos monitorizar tanto las tendencias de ataque generales (valores estadísticos, nuevas vulnerabilidades, métodos de ataque, etc.), como los ataques particulares que recibe nuestra organización (monitorización de logs y eventos).

Esto va a permitirnos implementar tanto medidas preventivas, como medidas reactivas.

Si bien suele decirse que es mejor ser “preventivos”, debemos prestar mucha atención a que las medidas reactivas no son “malas”, pero es muy importante considerar el tiempo que tardamos en reaccionar.

Por ejemplo, la inteligencia puede ayudarnos a detectar que un grupo activista va a lanzar un ataque de Denegación de Servicio (DoS) contra nosotros, y permitirnos ajustar nuestra infraestructura (y la de nuestros proveedores de internet), para poder mitigarlo.

Esa sería la “situación ideal”. Pero también es importante que podamos reaccionar rápido ante un ataque DoS inesperado, que podamos detectarlo y mitigarlo en la menor cantidad de tiempo posible.

Aquí es donde la información de inteligencia se mezcla con la respuesta a incidentes.

Incluso, podemos utilizar la inteligencia para realizar la investigación sobre incidentes de seguridad, es decir, no sólo para prevenir o reaccionar ante eventos, si no también para investigarlos y obtener más inteligencia de ellos.

A continuación tenemos una lista de posibles datos de interés:

• Descubrimiento de vulnerabilidades para el software que utilizamos

• Tendencias de ataque que podrían afectar al rubro en el que nos manejamos

• Nuevos vectores de ataque utilizados por los ciberdelincuentes

• Ataques de phishing que intenten suplantar nuestra organización

• Filtraciones de datos con cuentas comprometidas

• Estadísticas de ataques y malware (internos, globales, segmentados, etc)

Más Adelante

En la próxima entrega de esta serie analizaremos la planificación de nuestro proceso de inteligencia, para dimensionar de forma adecuada las herramientas y los recursos que vamos a utilizar.

“La inteligencia es la información que se ha analizado y refinado para que sea útil al momento de tomar decisiones.”

Ciclo de Inteligencia

El FBI define el ciclo de inteligencia como un proceso de seis tareas, en el cual, la información obtenida en una de las tareas puede disparar la realización de alguna de las otras cinco. Es decir, que no es un proceso necesariamente secuencial. En realidad, llegado el caso, todas las tareas pueden estar realizándose al mismo tiempo.

1) Requerimientos

Se deben identificar las necesidades de información (“¿Qué es lo que debemos saber para poder protegernos?”).

2) Planeamiento

Se refiere a los planes de implementación para lograr los objetivos requeridos en tiempo y forma.

3) Recolección

Es la obtención de información en crudo, que luego será procesada.

4) Procesamiento

Convertir la información de forma tal que pueda ser analizada, ya sea por personas o por sistemas automatizados.

5) Análisis

Convertir la “información” en “inteligencia”. Incluye la integración, evaluación y análisis de la información disponible.

Para esto se deben considerar la fiabilidad, validez y relevancia de la información que se está analizando. Para poder “producir” la inteligencia, se deben incluir tanto los datos en crudo como los datos analizados.

Los datos en crudo son muchas veces llamados “los puntos” (piezas individuales de datos). Los reportes de inteligencia “conectan los puntos”, poniendo la información en contexto y sacando conclusiones acerca de sus implicaciones.

6) Difusión

Se distribuye la inteligencia generada a las partes interesadas. Esto debe realizarse en un formato adecuado para que cada parte interesada pueda hacer el mejor uso posible de la inteligencia.

Fuentes de Inteligencia

Existen varios tipos diferentes de fuentes de inteligencia, cada una de ellos puede ser de mayor o menor utilidad dependiendo de cuáles sean nuestras áreas de interés y nuestros objetivos.

A continuación presentamos las seis “disciplinas de recolección de inteligencia” o “INTs”:

Inteligencia Humana (HUMINT)

Es la recolección de información a través de personas. Puede ser realizada de forma abierta, a través de cuestionarios, entrevistas, etc., como también a través de actividades clandestinas (espionaje).

Inteligencia de Señales (SIGINT)

Se refiere a transmisiones electrónicas que pueden ser recolectadas por barcos, aviones, satélites, etc. La “Inteligencia de Comunicaciones” (COMINT) es un tipo de SIGINT y se refiere a la intercepción de comunicaciones entre dos partes.

Inteligencia de Imágenes (IMINT)

También llamada “Inteligencia de Fotos” (PHOTINT). Actualmente la mayor parte de IMINT es realizada utilizando imágenes satelitales. Pero hace referencia a cualquier tipo de análisis de imágenes.

Inteligencia de Medición y Firmas (MASINT)

Es la menos conocida de las seis, utilizada casi exclusivamente en los ambientes militares. Analiza las señales que emiten los equipamientos como armas y dispositivos de rastreo.

Generalmente los datos son obtenidos a través de técnicas de SIGINT.

Inteligencia Técnica (TECHINT)

Tiene como objetivo principal la recolección de información acerca de qué tecnologías están en poder de terceras partes, para evitar ser sorprendidos cuando dichas partes hagan uso de las mismas.

Inteligencia de Fuentes Abiertas (OSINT)

Se refiere a una gran cantidad de información que suele estar disponible para todo el mundo (diarios, televisión, radio, publicaciones, conferencias, internet, etc).

La principal ventaja de OSINT, con respecto a las demás INTs, es la facilidad con la cual podemos acceder a la información.

Lo que se vuelve difícil es determinar el origen real de los datos, así como su fiabilidad.

Ciberinteligencia y OSINT

OSINT es el tipo de inteligencia más utilizada en los ambientes corporativos, debido a que el resto requiere de grandes cantidades de recursos y, en muchos casos, la utilización de equipamiento militar y/o actividades que podrían llegar a ser ilegales si no se cuenta con determinados permisos especiales (como lo tienen las agencias de gobierno).

Podemos definir a la Ciberinteligencia como “La utilización de tecnologías informáticas para la obtención y procesamiento de inteligencia”. Dicho esto, vamos a centrarnos particularmente en las herramientas informáticas que podemos utilizar para obtener y procesar inteligencia acerca de las organizaciones, a fin de protegerlas de posibles amenazas.