En esta nueva entrega vamos a ver una técnica para detectar un debugger sin recurrir a librerías del sistema como ocurría en las entregas anteriores (ver la anterior y la primera). Se basa en un concepto muy simple para detectar el “step-by-step” (paso a paso) cuando se está analizando la aplicación dentro de un debugger.

Como ya sabemos, la mayoría de los debuggers permiten avanzar de forma diferente en la ejecución del programa. Por ejemplo, en OllyDbg:

• Run (F9) → Ejecuta el programa hasta llegar al final o hasta encontrar una interrupción.
• Step into (F7) → Ejecuta una sentencia del programa cada vez (“step-by-step”).
• Step over (F8)→ Ejecuta el programa sin entrar a analizar las funciones (calls)
• etc. (Ver menú “Debug”)

[Read more…]

En la anterior entrada analizamos ciertas características estáticas que nos daban una idea de lo que hace o lo que podría llegar a hacer la librería. Ahora en esta segunda entrada vamos a analizar las funciones que exporta la librería. Para el análisis estático de la librería nos vamos a apoyar en las herramientas radare2, pestudio y ollydbg.

Como ya vimos en la anterior entrada con la herramienta PEstudio se exportan cinco funciones:

[Read more…]

Ser administrador del dominio o disponer de credenciales de acceso con máximos privilegios a repositorios de ficheros, bases de datos o sistemas ERP no sirve de mucho a la hora de plasmar los riesgos de la organización auditada en un informe, ya que “negocio”, muchas veces, no concibe las consecuencias que puede suponer el disponer de tales capacidades.

Es por eso que después de la fase de explotación y elevación de privilegios, comienza desde mi punto de vista la más importante de todas, la de obtención de información y toma de evidencias. De nada sirve conseguir ser administrador de un dominio Windows si no se pueden obtener datos sensibles o ejecutar acciones que puedan suponer un impacto para el auditado. Es en este momento donde entra en juego esta simple pero potentísima herramienta: OpenDLP.

Este software, que se despliega mediante un GUI Web en la máquina del pentester, permite realizar búsquedas masivas de información en miles de equipos de forma simultánea y con una baja carga, tanto para la máquina objetivo como para el equipo del auditor. A diferencia del buscador de Windows que identifica los patrones de búsqueda en los nombres de los documentos, OpenDLP permite inspeccionar el contenido de los ficheros mediante expresiones regulares. Como su nombre indica es un DLP o herramienta de prevención de fuga de información, pero la verdad es que dista mucho de las capacidades de las soluciones comerciales, por lo que para este propósito no lo recomendaría. Sin embargo descaradamente, OpenDLP ha sido desarrollado para cubrir la fase comentada anteriormente, dentro de un test de intrusión.

[Read more…]

(N.D.E. Primero vamos con Sandworm. En un rato, les hablamos de POODLE)

Se acumulan las malas noticias para los expertos en seguridad (y al final, para todos los administradores de sistemas). Ayer, la compañía de seguridad Isight Partners publicaba un informe en que destapaba a grupo de ciberespionaje ruso denominado “Sandworm Team” [PDF] (también llamado Quedach por F-Secure), que llevaba desde 2009 atacando a objetivos de interés en Ucrania y Europa del Este.

La noticia fundamental (más allá de la atribución rusa, que hasta disponer de más detalles es más bien difusa y hace sospechar a los paranoicos) es el uso de este grupo de un nuevo 0-day que afecta a ficheros de Office y para el que, hasta hoy, no había parche.

La vulnerabilidad (CVE-2014-4114), que afecta a Windows Vista en adelante (incluidas las versiones de servidor), explotaba la capacidad de Office de incluir ficheros OLE (Object Linking and Embedding) de localizaciones externas. Todo empezaba con un correo electrónico (un ataque de spear-phishing en el que se adjuntaba un fichero .ppsx ppsx (un fichero de Powerpoint que al abrirlo se pone automáticamente en modo presentación, lo único diferente a un .pptx standard).

[Read more…]

La mayoría de vosotros ya sabréis que OSSEC es un sistema de detección de intrusos basado en host (HIDS). Si aun no lo conocéis, os recomiendo echarle un vistazo a la entrada “OSSEC como herramienta de Incident Handling”.

En esta entrada vamos a comentar la capacidad de monitorizar en tiempo real las salidas de comandos personalizados en un sistema Linux. Esta utilidad se configura en el fichero “ossec.conf”, entre etiquetas “<localfile>” y “<command>”. Si miráis este fichero, podéis ver como ya existen algunos preestablecidos, como df, netstat o last. Nosotros podemos añadir los que queramos y sean de utilidad para nuestro entorno. Por ejemplo, un comando netstat más personalizado o un listado de los módulos cargados en el kernel de Linux con lsmod. En nuestro ejemplo, proponemos el siguiente comando personalizado de netstat:

netstat -antupd |sort |awk 'BEGIN{printf "%-8s %-20s %-20s %-20s %-10s\n","PROTO", 
   "IP/PUERTO LOCAL","IP/PUERTO REMOTO", "ESTADO CONEXION", "PROCESO 
   LOCAL"}/ESTABLISHED/{printf "%-8s %-20s %-20s %-20s %-10s\n",$1,$4,$5,$6,$7}'|uniq

[Read more…]

En el artículo de hoy os vamos a mostrar un pequeño script que hemos realizado JoseMi Holguín (@J0SM1) y un servidor, y cuya finalidad es poder tratar el conjunto de reglas activas en una instalación de Snort y, llegado el caso, realizar modificaciones a las mismas.

El script está realizado en python, y cuenta con dos clases, una llamada ruleDissector(), que se encarga de trocear cada regla y guardar sus parámetros por separado, y otra llamada ruleseParser(), que lee los ficheros de configuración de Snort y selecciona los ficheros de reglas que están activos.

Para utilizar el script únicamente es necesario importarlo, y llamar a la siguiente función (todos los parámetros son opcionales, y se muestran los valores por defecto):

ruleset = rulesetParser(basedir = '/usr/local/snort/etc', snortfile = 'snort.conf', 
    classiffile = 'classification.config', rulesdir = 'rules')

[Read more…]

Estaba haciendo el otro día mis pinitos con django, cuando por una negligencia, borré una aplicación que ya tenía terminada. La web no era compleja, tenía pocas líneas de código y creía que la podría volver a tener en menos de un día, pero sin embargo, vi la ocasión como una oportunidad para aprender a hacer una recuperación de datos en un disco SSD.

La configuración del disco de este equipo es la siguiente: particionado GPT con varias particiones formateadas con ext4 (nada de LVM). Mi experiencia previa en este tipo de casos siempre ha sido utilizar las herramientas más conocidas en entornos GNU/Linux: sleuthkit, autopsy, testdisk y photorec (éstas dos últimas suelen venir en el mismo paquete), dd, grep…

Volviendo al caso, nada más darme cuenta de lo que había hecho intenté mantener la calma y seguir lo que suele ser mi procedimiento estándar: montar la partición en la que estaba el proyecto como sólo lectura y crear una imagen de la partición con la herramienta ‘dd‘, de manera que las nuevas interacciones con el disco no sobreescriban ningún dato.

Creada la imagen, mi primera opción fue testdisk, un software de análisis forense y recuperación de datos que me ha dado muy buenos resultados en el pasado. No obstante, en esta ocasión me decía que la partición estaba corrupta, por lo que no podía recuperar el contenido del disco. A día de hoy, desconozco si fue por un error mío en las múltiples opciones que ofrece testdisk, o si bien por el contrario esta herramienta no se lleva bien con discos SSD o con particiones GPT.

Tras un primer intento fallido, probé suerte con sleuthkit y autopsy. En esta ocasión, todo iba como la seda. Tras establecer los parámetros iniciales del caso, empecé a “jugar” con las opciones de autopsy:

No obstante, parecía que el procedimiento iba para rato, ya que la imagen de disco tenía cierto tamaño y estaba almacenada en un disco duro externo USB. Como no me apetecía estar delante del PC sin hacer nada un viernes de madrugada, cancelé los procesos de sleuthkit y me puse a utilizar photorec.

Con photorec la cosa cambió: en cuestión de segundos, estaba recuperando multitud de ficheros, algunos de ellos borrados hacía meses. Como iba para rato, pero había podido comprobar que estaba haciendo su tarea, decidí dejar el proceso ejecutándose y continuar la mañana siguiente. Cual fue mi sorpresa al día siguiente al ver que photorec había encontrado unos cuantos miles de ficheros de tipo texto (extensiones txt, java (en este equipo nunca he programado en Java), html, py…).

Dado el gran número de ficheros, nada mejor que un poco de grep y unas cuantas expresiones regulares para encontrar el directorio y los ficheros que me interesaban. Al ser código en python, empleé sentencias que serían únicas de python, como import, nombres de variables que recordaba, tags html…

Al cabo de unas cuentas horas, pese a que parecía que había recuperado casi la totalidad del proyecto y que si faltaba algo podría recodificarlo, había una cosa extraña: el número de ficheros que tenía ahora del proyecto era más del triple del número de ficheros que tenía originalmente. Tras ojear los ficheros para poder cambiarles el nombre por el original (photorec tiene una pega: cambia el nombre del fichero por caracteres alfanuméricos, e incluso hay veces que no detecta correctamente la extensión del fichero), vi que muchos ficheros se correspondían con el mismo y que muchos otros no estaban completos.

Descarté en seguida que se tratara de copias de seguridad: no había considerado que fuese necesario crear una copia de seguridad para un proyecto como éste. Además, ¿qué sería de la vida sin pequeñas emociones? (N.d.E.: niños, no hagáis caso a este insensato)

Mirando los ficheros detenidamente, pude ver como los ficheros se correspondían a versiones viejas de los mismos, como si cuando hubiese hecho un cambio y lo hubiese guardado en disco, se creara un nuevo fichero y se borrase el viejo, almacenándose cada uno en secciones diferentes del disco. También había unos cuantos ficheros parciales, en los que se veían funciones del código pero no todas las que coexistían en el mismo fichero.

Tras indagar un poco, pude discernir entre “versiones”, realizar varias pruebas en la aplicación y ver que líneas tenía que añadir, borrar o modificar para tener la aplicación tal y como la tenía antes. No obstante, se me planteaban nuevas cuestiones. ¿Guarda eclipse varias versiones del mismo fichero? ¿Es cosa del Sistema Operativo? ¿Es por utilizar un disco SSD?

Como muchos lectores ya se habrán imaginado, el causante de este comportamiento es la forma en la que el disco SSD almacena los datos. Sin embargo, me gustaría dejar los detalles técnicos para una próxima entrega, más técnica y menos teórica que la actual.

Nos vemos en la próxima!