Mostrando las entradas para la consulta unhide ordenadas por fecha. Ordenar por relevancia Mostrar todas las entradas
Mostrando las entradas para la consulta unhide ordenadas por fecha. Ordenar por relevancia Mostrar todas las entradas

01 abril 2016

Análisis forense: Lo que había, lo que hay,... y lo que habrá

El mundo del peritaje forense ha cambiado mucho en estos años. Todavía recuerdo cuando en los primeros juicios a los que me presentaba comentaba en el informe que las evidencias se habían extraído con un Helix y marcaba la integridad de las evidencias con MD5. Por aquel entonces no había mucho escrito sobre forense, y era muy complicado explicar las cosas a alto nivel.

Después, y como todo en esta profesión, se fue actualizando más y más el campo del peritaje hasta el día de hoy, en el que existen numerosas herramientas, procedimientos y aproximaciones para extraer una evidencia.

Y aquí es donde surgen nuevos problemas. Ya no vale con marcar las evidencias con MD5, porque tanto jueces como abogados te pueden tirar las mismas alegando colisiones. Con las herramientas pasa un poco lo mismo. Personalmente he visto cómo en determinados juicios, se han tirado evidencias porque han logrado demostrar que la solución utilizada para la extracción de las mismas no lo hacía correctamente.

Del peritaje forense nació el contra-peritaje, que consiste básicamente en desmontar – de una manera técnica y a bajo nivel– las evidencias presentadas en un caso. Y para desmontar las evidencias no suele valer un “Le pasamos esta herramienta gratuita y como podéis comprobar….”, porque en ciertos escenarios, esa evidencia no valdrá nada ante un abogado que realmente sepa de lo que está hablando.

Cualquier perito decente os recomendará sin duda la utilización de herramientas como Encase o FTK, y no porque sean más o menos caras, sino porque en determinados escenarios, gracias a la mera utilización de la misma tendréis el caso ganado. Pensad por un momento un caso en donde tengáis que extraer información de determinados ficheros alojados en un disco duro con un sistema operativo de cualquier tipo, en el que no sólo residen esos ficheros, sino que también se encontrarán ficheros de carácter personal como fotografías o vídeos.

Gracias a estas herramientas y/o frameworks, los peritos se pueden concentrar en la búsqueda sin importar el tipo de dato que se encuentre en el sistema operativo. Más de un caso se ha caído debido a que en la búsqueda de esa información, el perito se topó con directorios que se encontraban fuera del ámbito de actuación y que no debería ver y/o analizar.

Hay que aplicar la medida justa para extraer la evidencia, ni más, ni menos. El conocimiento del entorno tanto a alto como a bajo nivel, así como la elección – o la fabricación - de la herramienta determinarán una buena actuación, amén de la profesionalidad del perito a la hora de llevar el caso. Porque no olvidéis que os citarán como experto en la materia.

También es importante tener amigos. En este caso, y dado la fragilidad de este campo, se recomienda que los peritos pertenezcan a algún tipo de asociación. Y por asociación quiero decir algo serio que resuelva las dudas puntuales que pueda tener un profesional. Para el caso que nos ocupa, y aquí en España tenemos ANCITE, que brinda muchos servicios y ayudas a los profesionales que día a día se enfrentan a juicios.

Y después tenéis a gente como Pedro Sánchez, Lorenzo Martínez o un servidor para echaros un cable siempre que lo necesitéis y esté dentro de nuestra mano. Como sabéis, Securízame organiza todos los años un curso de análisis forense para profesionales del sector. Gracias a estos cursos se han podido ver y estudiar escenarios nunca vistos como por ejemplo análisis de servicios basados en SQL Server, Exchange o Active Directory, por citar algunos en los que he sido invitado como profesor.

Como cada año, y anticipándonos a nuevos escenarios, el curso de este año está liderado por grandes profesionales del sector como por ejemplo Sergi Alvarez (@trufae), el cual es uno de los desarrolladores principales de radare, herramienta ampliamente utilizada en forenses de tipo avanzado y en donde se requiere un nivel de detalle importante en cuando a la presentación de evidencias.

También estará José Antonio Guasch (@secbydefault), el cual es uno de los editores de este humilde blog y reconocido profesional que ha sido invitado por Securizame para hablar a bajo nivel de navegadores, así como las buenas prácticas a la hora de montar un laboratorio forense, junto con Lorenzo Martínez (@lawwait).

El incombustible Pedro Sánchez (@conexioninversa) participará esta vez enseñándonos todo lo relacionado con Incident Response, disciplina que cada vez más se está demandando en clientes finales.

El gran Toni de la Fuente (@ToniBlyx) ha sido invitado para que nos enseñe cómo enfrentarnos a casos forenses en donde la información resida en la nube, algo que ya forma parte de nuestra rutina diaria.

La parte de Yago (@YJesus), editor también de este blog y creador de herramientas como unhide, es la de Backdooring, ocultación y búsqueda de tramas, no sólo en el sistema, sino también en red.

Por mi parte (@tr1ana) yo he sido invitado para dar la parte de OS en Windows. Pero no me voy a centrar este año en registro o ficheros. Este año toca centrarnos en servicios como Cortana (Sí, Cortana!), la interfaz Metro o la integración de aplicaciones con el escritorio. También dedicaré un apartado especial al análisis de memoria RAM, pero esta vez Volatility se quedará en el cajón y lo haremos mediante herramientas nativas de Microsoft, como son WinDBG o SysInternals.

En la URL del curso tenéis tanto el temario como horarios y profesores implicados en el mismo. Por mi parte, deciros que os veo en unas semanas para seguir explorando esta maravillosa disciplina.


Juan Garrido
MVP Enterprise Security
Leer más...

20 enero 2015

AntiRansom 2.5 is out !!

Aun con la enorme satisfacción de haber conseguido que Unhide fuese elegida 'Mejor herramienta de seguridad 2014' (Muchas gracias a todos los que votaron!!) todavía reciente, he decidido lanzar un update de otra herramienta: AntiRansom.

Ya en la versión 2.0 adelanté medidas proactivas para detener una infección en curso y en esta versión 2.5 las he afinado para que funcionen mejor.

Básicamente he mejorado el ratio de detección para 'cazar' al proceso que está haciendo lo que no debe y generar un volcado de su memoria.

He grabado un vídeo con una muestra real de ransomware para que se vea bien como funciona.

Si tenéis dudas sobre como instalar / desinstalar, visitad el post de la versión 2.0





Podéis obtener la versión 2.5 de AntiRansom en primicia desde aquí
Leer más...

18 enero 2015

Enlaces de la SECmana - 259

Leer más...

29 diciembre 2014

Vota Unhide como mejor herramienta 2014 !


















Como cada año, el prestigioso site 'ToolsWatch' organiza la encuesta para elegir la mejor herramienta del año, el año pasado ganó la enormemente famosa herramienta 'Zap' quedando también muy bien situadas herramientas como Burp o PEStudio (nada menos !!).

Este año me he decidido a presentar Unhide, una herramienta de la que he hablado largamente en este blog y de la que estoy preparando una 'release' que verá la luz próximamente.

Para el que no lo sepa (y no le apetezca leerse las entradas sobre la herramienta), Unhide es una herramienta anti malware para sistemas Unix que viene 'by default' en distribuciones Linux tan potentes como Fedora o Debian (y otras muchas más) orientada a verificar si un sistema se encuentra comprometido y alguien está ocultando cosas que deberían poder verse mediante herramientas del sistema.

Personalmente, agradecería MUCHO ese pequeño gesto si os tomarais apenas unos minutos para votarla como herramienta.

Podéis votar desde aquí

¡¡ Muchas gracias !!
Leer más...

21 agosto 2013

Crónica del CSI 2013 en Pereira - Colombia - Día 2 #CSI2013




Seguimos con la crónica del segundo día del evento CSI 2013 en Pereira - Colombia. Podéis ver la crónica del primer día en este enlace

TUMI: Desde el Fingerprint hasta el informe por Walter Cuestas 




Desde muy temprano, abrió el evento el peruano Walter Cuestas, hablándonos de una herramienta, basada en una interfaz web, que permite hacer pruebas unitarias en todo el proceso de una auditoría. La herramienta se llama Tumi. Está escrita en Python, utiliza Javascript para la interfaz de menús, llama por debajo a herramientas genéricas como nmap o sqlmap. Como ventaja principal es que es totalmente opensource y permite integrar scripts hechos por uno mismo. Se puede descargar la beta desde aquí


') UNION SELECT 'Esta_Platica' AS (Nuevas Técnicas de Optimización y Ofuscación') por Roberto Salgado




Esta era una de las charlas que esperaba con mayor expectación. Me habían hablado maravillas de este mexicano afincado en Canadá, socio de la empresa Websec, junto a Pedro Joaquín y Paulino Calderón, y pude comprobar que todo era cierto al 100%.

Fue una charla eminentemente técnica en la que comparó diferentes algoritmos utilizados para hacer Blind SQL Injections, fundamentalmente Bitwise y Bisection.

Además, explicó un algoritmo que descubrió él y que llamó Bin2Pos, mostrando estadísticas y pruebas en tiempo real para adivinar cadenas con todos los métodos, siendo Bin2Pos el que menor número de peticiones enviaba (de media).

Además, mostró diferentes consultas SQL en una sola línea, que permiten acelerar el proceso de una auditoría, enviando una única petición y obteniendo el mismo resultado que al dividirla en N peticiones, así como ofuscación y evasión de WAF en base a caracteres no estándar, además de diversas "rarities"que el servidor SQL sigue entendiendo y ejecutando, pero que el WAF no lo interpreta como un ataque,…  En esta línea dio ejemplos para saltarse la protección de mod_security, GreenSQL o libinjection.

Esta charla, que Roberto dio hace dos semanas en Blackhat, fue brutal. Hasta el día de hoy, la que más me ha gustado! 


RogueAP / SSLStrip por Carlos Betancour



El colombiano, miembro de la comunidad Buggly, quiso mostrar qué tan fácil era llevar a cabo un ataque en una red wireless, mediante un Man in The Middle utilizando la herramienta SSLStrip de Moxie Marlinspike. Lamentablemente, la red wireless de la Universidad era un jungla ya de por sí, y no fue posible verlo en modo práctico. En cualquier caso, nos lo creemos totalmente!

Actualización: Carlos dijo que ya que no funcionó en ese momento, lo grabaría en un video y lo pondría a disposición de todo el mundo.

  

"Advanced Topics for rootkits in Linux" por Marcos Ricardo Schejtman



Continuamos con otra de las charlas más técnicas del día. El ponente mexicano empezó introduciendo conceptos de arquitectura y privilegios de ejecución de procesos en Linux, estructura en anillos, sistemas de ficheros virtuales, etc,…
Siguió relatando los diferentes sitios donde Linux guarda objetos de los procesos, por lo que serán rutas a tener en cuenta a la hora de construir un rootkit. Además contó el funcionamiento de diferentes componentes del sistema operativo del pingüino, scheduler, tablas de procesos, mapas de memoria, syscalls, etc…
Luego nos deleitó con diferentes maneras para esconder procesos que incluso herramientas como rkhunter ni chkrootkit pudieron detectar.
Acordamos que se pondría en contacto con Yago para validar si Unhide sería o no capaz de detectarlo. El código fuente del rootkit que programó Natas no lo liberará, atendiendo a una política de Responsible Disclosure, esperando primero a que existan formas de detección de este tipo de rootkits, o incluso publicará él mismo una contramedida.

"Pentesting en la era post-pc" por Jaime Andrés Restrepo   



Aunque esta charla se la ví hacer a Jaime en el EHCon de 2012 en Santa Cruz de la Sierra en Bolivia, reconozco que la disfruto cada vez más. En este caso, Jaime enseñó la utilidad de diferentes elementos como keyloggers hardware, micrófonos simulados en pendrives USB, herramientas que se pueden utilizar sobre software de auditoría en dispositivos móviles como teléfonos, tabletas, etc,…  Dispositivos "mini", que llevan internamente un ordenador, con APs wireless levantados que permiten conectarse en remoto, piñas wireless camufladas en libros huecos, y un sinfin de ideas muy interesantes para llevar a cabo ataques basados en ingeniería social/wireless, y otras perversidades. La charla culmina con diferentes videos, en los que Jaime muestra los resultados de diferentes ejercicios, llevados a cabo en lugares públicos, consistentes en simular redes wireless abiertas.


"Software en Tiempos de Espías" por Roberto Olaya



Mi buen amigo ecuatoriano fue el protagonista de una excelente charla sobre un tema que actualmente está en boca de todos: las estrategias de inteligencia de diferentes paises, así como los diferentes sistemas utilizados (al menos los que se conocen). Sistemas de espionaje de comunicaciones como Echelon, Enfopol, Promis, Carnivore, etc,…  Agencias que se unieron en USA como la DEA, FBI, NGA, NRO, NSA, ODNI, US. Air Force, US ARmy, para formar un sistema de comunicación común….  Nos contó igualmente los avances implementados en elementos militares, como lo que llevan en el casco, traductores online, cámaras que emiten vía satélite "lo que el soldado ve", identificación humana a distancia mediante reconocimiento facial (incluso aunque se haya hecho cirugía estética) etc,…
Habló por supuesto de Prism, así como de una página muy curiosa, Prism-Break con herramientas que te resultan más recomendables si quieres mejorar tu privacidad.


"Sé el primero en auditar tu web"  por Jhon Cesar Arango [jcaitf]



Esta charla, la única que dio Jhon César, uno de los organizadores del evento, versó sobre diversas herramientas de auditoría web: Uniscan, W3AF, Nikto, Joomscan, plecost, sqlmap, zap, etc…. 
Hizo varias demos con las mismas, de manera que permite hacer ver de una forma bastante fácil, que con un poco de formación, es posible adelantarse a los "chicos malos", a fin de poder mitigar el riesgo de un montón de vulnerabilidades. Sólo con esto no aseguraremos que la web está segura al 100% pero siempre quedará menos por securizar.

"Robo de identidad digital" por Gustavo Nicolás Ogawa



En esta charla, el compañero Gustavo Ogawa hizo un caso de búsqueda de una persona, desde el principio, encontrando la identidad digital del objetivo a través de internet. A partir de ahí hizo varias demostraciones en las que usaba Facebook como medio de ataque, engañando a la víctima para explotar una vulnerabilidad de algún software (creo que fue un JRE no actualizado) con Metasploit, accediendo a su equipo.
Leer más...

11 abril 2013

Análisis de intrusión y malware en PHP: Un caso práctico




Sucedió hace unas semanas. Recibo la llamada de un cliente preocupado, en la que me dice que algo raro está pasando en dos de sus servidores, que las colas de los procesos de correo se han vuelto locos y que están brutalmente sobrecargados. Se trata de una humilde empresa que da servicios de hosting web y correo a varios clientes a través de dos servidores alquilados. Me envía las credenciales de acceso a los mismos, tanto para SSH como para Plesk.

Una vez conectado a las máquinas, y tras comprobar que la carga de las mismas no es excesivamente elevada, descargo un kit de herramientas para diagnosticar el problema. Mediante unhide, rkhunter y chkrootkit, veo que el sistema no muestra procesos ocultos ni malware conocido. La ejecución de unhide-tcp así como un nmap remoto completo, me deja ver que no hay sockets ocultos aparentes (me parecería extraño que hubiese algún malware que exigiese port knocking previo para activarse/desactivarse, aunque la idea es bastante buena). Por otra parte, el tipo de empresa, y la de sus clientes, no me pareció que fuesen a ser el objetivo de ninguna organización ni gobierno que quiera robar secretos nucleares, por lo que no me hago a la idea que vaya a ser muy complejo el mecanismo por el que le están atizando.

Sin embargo, las colas de correo siguen incrementándose más y más. La sangre no ha debido llegar al río suficientemente, puesto que amispammer no indica que las direcciones IP de mi cliente hayan sido incluídas en alguna lista antispam. Los logs de diferentes servicios no arrojan excesiva información, excepto el de qmail, que no para de mostrar montones de intentos de conexión a servidores de AOL, a los que no puede enviar determinados mensajes por no ser válidos los buzones buscados. ¿Pero esto de AOL no se había muerto ya hace años? Sin embargo, con un simple "top" observo que se ejecuta frecuentemente un mismo cgi en php. No veo un aumento significativo de recursos cada vez que se ejecuta, pero por echarle un vistazo, nada pierdo, ¿verdad?

Pues touché… según edito el fichero, me encuentro con un script php en una única línea, que claramente han ofuscado. ¿Adivináis la ruta? Dentro de un directorio con plugins para joomla de uno de los dominios clientes de hosting. En concreto en /components/com_content/newso2p.php y /components/com_content/statgpZO.php, con idéntico contenido.

Probé a subirlo a virustotal, y oh sorpresa, aparecía referenciado por muy pocos antimalware. En concreto, los únicos que lo detectaban eran ClamAV, DrWeb, Sophos, Trendmicro y VBA32… 



Entre otras acciones, como borrar los ficheros en concreto, le propuse al cliente que actualizara Joomla y sus componentes, eliminara los plugins inútiles, etc, etc, dentro de lo que el panel de hosting le permite.

A partir de aquí caben dos preguntas. ¿Cómo ha llegado ese PHP ahí? ¿Y qué es lo que hace?

La primera de las preguntas parece de fácil respuesta: dado que el fichero tenía como dueño el usuario de Apache, y dado el lugar donde estaba, tiene toda la pinta que por alguna vulnerabilidad de Joomla! que permita escribir ficheros en sus directorios de plugins o componentes. 

¿Qué hace el "malware"?
Como indiqué más arriba, el código PHP está ofuscado y, en una sola línea, hace bastante incómoda su lectura:




Por no liarme a buscar el ofuscador utilizado para este script, usé mi manido Perl para dejarlo de una forma más legible. Me hice un script quick & dirty que me permitiese pre-procesarlo:

Con lo que me queda en out.php, la idea era identificar las diversas variables del fichero, y cambiarlas por un valor más sencillo de ver, como por ejemplo $a en vez de $v1cb251ec, f1 en vez de n9a2d8ce3 para los nombres de funciones, etc,… Aproveché a eliminar funciones que no eran llamadas nunca, que simplemente confundían más al análisis.

Así, el script PHP quedaría de esta manera:


Fundamentalmente, el atacante, simplemente tenía que hacer llamadas a este PHP, mediante el método HTTP POST y en el POST DATA enviaba en varios campos diferentes la información necesaria para construir los correos: origen, destino, subject y cuerpo.

Inicialmente, estos datos vienen codificados en Base64 y se descodifican en tiempo de ejecución. Por otra parte, se procesa en el código, una lista con las direcciones  de correo destino, que viene también en la llamada. Se establecen las cabeceras necesarias del correo y el propio bicho busca si hay servidor de correo en localhost. Si lo hay, lo usa, y si no lo hay resuelve él mismo los registros MX de los correos que recibirán el spam y les abre un socket al puerto 25, estableciendo una comunicación SMTP, enchufándoles el contenido con cabeceras del correo generado.

Conclusiones
  • Pese a no ser un troyano muy mediático, el script está suficientemente bien hecho para que llame poco la atención dentro del sistema. No consume muchos recursos, ya que envía correos según se le hacen llamadas desde fuera, y en una sola llamada puede generar la ejecución de muchos correos de spam a la vez.
  • Los logs que deja no son muchos, debido a que al ser con POST, no quedan datos almacenados por los parámetros que tendría si se hiciese mediante GET.
  • Además, si da algún error la llamada POST, tampoco deja rastro, puesto que lo primero que hace en su ejecución, es deshabilitar cualquier tipo de traza así: "@error_reporting(0); @ini_set('error_log', NULL); @ini_set('log_errors',0); "
  • En cualquier caso, y supongo que para evitar WAFs o algunos IPS que analicen las llamadas HTTP, codifica los parámetros en base64. De esta manera evitas la detección de los ingredientes necesarios para construir correos con spam en base a patrones.
  • En este caso, quien se quejaba, era el sistema de monitorización de procesos del hosting, en los que el administrador veía que las estadísticas de envío de correo no eran normales, para lo que estaban acostumbrados a ver. 
  • Es interesante que se comunica con el atacante (o con el bot que lo ejecuta) mediante códigos OK + el md5 de "1234567890" cuando es correcto y un código de estado + el md5 de "0987654321" cuando es incorrecto. 
  • Los logs generados por Qmail se dispararon también en tamaño y un tcpdump del puerto 25 era como ver pasar las letras de Matrix pero a alta velocidad.
Leer más...

22 enero 2013

Unhide 20121229 is out !

Finalmente y tras haber lanzado la beta con una gran respuesta a nivel descargas y feedback,  ¡tenemos la versión final de Unhide!

Para los mas ansiosos, se puede descargar desde aquí

La nueva versión trae bastantes cambios con respecto a la anterior versión (20110113)

Copio y pego el 'Changelog':

IMPORTANT

  - unhide-linux26.c was renamed to unhide-linux.c
  - unhide.c was renamed to unhide-posix.c
  - The log file of unhide-linux is renamed 'unhide-linux_AAAA-MM-DD.log'
  - The log file of unhide-tcp is named 'unhide-tcp_AAAA-MM-DD.log'
  - By default, unhide-tcp now use /sbin/ss from iproute2 package, to use netstat as before '-n' option must be given on command line.
  - Display is more verbose and multi-lines for hidden processes (unhide-linux).
  - If asked to (-l and/or -f), display is more verbose and multi-lines for hidden ports (unhide-tcp).
  - sysinfo test is no more called as part of compound quick and sys tests as it may give false positives.

    It could still be run using the checksysinfo, checksysinfo2 or checksysinfo3 command line parameter.

NEW FEATURES

  - Major enhancement of unhide-tcp :

    * Add capability to output a log file (unhide-tcp_AAA-MM-DD.log)
    * Add capability to output more information (via lsof and/or fuser) on hidden port if available
    * Add verbose mode (disabled by default) to display warning
    * Add a new method (via option '-s') very fast on system with huge number of opened ports
  * Make a double check of port access to avoid false positive (previous single check version is available as unhide-tcp-simple-check.c if needed).

  - Add a quick port in C language of unhide.rb (unhide_rb.c) and guess what ...it's 40 times faster than original ruby unhide.rb
    
Note: unhide_rb doesn't take any option.

  - Add "-d" option for doing a double check in brute test, this reduce false positives.
  - Add "-o" option as synonym of "-f".
  - For found hidden processes, display the user and the working directory as extracted from the process environment. Note that it doesn't work well for kernel processes/threads nor for deamons.
  - For found hidden processes, display cmdline, exe link and internal command name.

MISCELLANOUS

  - Add french and spanish man page for unhide-tcp
  - Update english manpage of unhide-tcp to reflect changes
  - Minor corrections in french manpage of unhide
  - Display copyright and license information in start banners.
  - Make message from sysinfo tests more clear.
  - Add a NEWS file :)
  - Update README.txt, LISEZ-MOI.txt and LEEME.txt to clarify difference between unhide-posix and unhide-linux.
  - Remove sysinfo test from quick and sys compound tests as it may give false positive.
sysinfo test still can be used via the checksysinfo[2|3] command line parameters.

BUG FIXES

  - Suppress pedantic compilation warnings (glibc >=2.3, gcc >=4.6).
  - Correct the number of processes displayed for /proc counting in sysinfo test.

[+] Página principal de Unhide (unhide-forensics.info)
Leer más...

14 diciembre 2012

Unhide 20121212-Beta is out !!

Ha pasado algún tiempo desde la última vez que se liberó una versión nueva de Unhide.

En todo este tiempo, lejos de estar parados, el proyecto ha sufrido una transformación muy notable. Muchas partes se han re-escrito totalmente y la mano de mi compañero Patrick se ha dejado notar mucho.

Además también han enviado parches Leandro Lucarella y François Boisson.

Esta versión, como decía al principio, ha sido re-escrita en un gran porcentaje, de hecho, unhide-tcp se podría decir que es nuevo.

Por eso, me encantaría que toda persona amante de Linux, administrador de sistemas o simple usuario, lo pudiera ver y probar para poder lanzar cuanto antes una versión estable a partir de esta beta.

Para compilar:

gcc -Wall -O2 --static -pthread unhide-linux*.c unhide-output.c -o unhide-linux

gcc -Wall -O2 --static unhide-tcp.c unhide-tcp-fast.c unhide-output.c -o unhide-tcp

Si obtienes algún tipo de error usando esa forma de compilar, elimina --static (en Fedora suele dar ese error)

Una vez compilado los comandos son:

unhide-linux 
unhide-tcp

Agradecería mucho que, en caso de encontrar algún fallo, problema, sugerencia, mejora, etc lo reportaseis en el bug tracker de SourceForge para que todos los miembros del equipo lo vean y puedan asignarle parches.



¡¡ Muchas gracias a todos por la ayuda y el interés !!
Leer más...

22 noviembre 2012

OSSEC: Introducción


OSSEC es un Host IDS opensource que incluye características que lo convierten en una herramienta muy interesante para asegurar un sistema, ya sea de la familia Unix o Windows.

Nace como sistema de detención de intrusos basado en logs (LIDS o Log-based Intrusion Detection System)  pero en la actualidad ha evolucionado incluyendo otras funciones, entre ellas:
  • Control de integridad de ficheros: verifica que los ficheros relevantes del sistema no sean alterados de forma no gestionada.
  • Control de integridad del registro: igual al anterior, pero para claves del registro. De esta forma se puede monitorizar si se añade un nuevo servicio, y se conecta un dispositivo USB, si se agrega una aplicación para que arranque al inicio de windows, etcéterra.
  • Detección de rootkits: está basado en firmas y es un poco básico. No es tan completo como algunas soluciones específicas como unhide, rkhunter o chkrootkit.
  • Respuesta activa: actuando como IPS, puede añadir reglas al firewall para bloquear hosts que generen eventos determinados.
Aunque la parte más relevante es el análisis y sistema de alertas basado en los logs, para los que dispone de decenas de decodificadores que los procesará con lógica.

Existen dos métodos de instalación, uno local, para un único servidor y otro con orientación cliente-servidor, donde los Agentes desplegados mandan las alertas a un servidor central con funciones de Manager.

El manager recibe y se comunica con los agentes mediante el puerto 1514/udp, por el que se transmiten los registros de forma cifrada (blowfish) y comprimida (zlib).

La aplicación se compone de varios servicios con distintas funciones cada uno de ellos y que serán usados según la configuración. Los más importantes son:
  • syscheckd: se encarga de ejecutar los análisis de integridad.
  • logcollector: recoge todos los logs del sistema, ya sean de syslog, ficheros planos, eventos de windows, etc.
  • agentd: envía los registros al manager remoto.
  • execd: ejecuta las respuestas activas (bloqueo de direcciones IP)
  • remoted: recibe los logs de los agentes remotos.
  • analysisd: proceso principal, se encarga de todo el análisis.
  • maild: manda correos electrónicos con las alertas.

La instalación por defecto se realiza en el directorio /var/ossec. Del que cuelga la configuración en el archivo /var/ossec/etc/ossec.conf.

Los decoders de cada uno de los logs se encuentran en formato XML en el directorio /var/ossec/rules/ y tienen el siguiente aspecto:


Las alertas se almacenan por defecto en /var/ossec/logs/alerts.log, aunque está desplegado un gran número de agentes, es recomendable guardarlas en base de datos. De la que podrán ser procesados con alguna de las consolas existentes.
Leer más...

25 octubre 2011

Análisis de Jynx (Linux Rootkit)

Últimamente poco se había innovado en el campo de los Rootkits para sistemas Linux, muy atrás quedaron los tiempos en los que 'adore' (LKM) o 'SuckIT' (parcheo de la memoria en caliente) marcaban el paso en cuanto a rootkits para sistemas Linux.

Poco a poco el Kernel de Linux ha ido evolucionando y haciendo bastante mas compleja la labor de modificarlo para esos fines, así que actualmente la forma mas efectiva de instalar un rootkit en un sistema Linux es ir hacia la parte 'userland'

De esta clase de rootkits existen dos tipos, o bien los que cambian los típicos binarios del sistema asociados a obtener información (ps y amigos) y los rootkits más sofisticados que inyectan una librería en los procesos.

Desde hace tiempo han existido rootkits que actuaban de esa forma, pero habían permanecido un tanto ocultos, hace relativamente poco se ha hecho pública una implementación completa y funcional de un rootkit con capacidad para infectar un sistema Linux actual, su nombre: Jynx

Este tipo de rootkits actúan inyectando una librería compartida (.so) en todos los procesos del sistema.

Aun a riesgo de que un purista encuentre objeciones, podemos decir que este tipo de vectores en Linux serían análogos al 'API Hooking' en Windows, las librerías .so serían el análogo a las Dlls y el fichero /etc/ld.so.preload sería el análogo a la clave de registro

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

En resumen, lo que hacen este tipo de rootkits es añadir una línea en el fichero /etc/ld.so.preload apuntando hacia la librería del rootkit en la que se encuentran 're-escritas' ciertas funciones asociadas a la obtención de información del sistema. Luego, será el propio sistema Linux el que se encargue de hacer que cada proceso creado en el sistema lleve cargada esa librería con las funciones alteradas. La única salvedad son los binarios compilados de forma estática.

Si miramos en el fichero ld_poison.c de Jynx podemos ver claramente que funciones del sistema van a ser re-escritas:

static int (*old_fxstat)(int ver, int fildes, struct stat *buf);
static int (*old_fxstat64)(int ver, int fildes, struct stat64 *buf);
static int (*old_lxstat)(int ver, const char *file, struct stat *buf);
static int (*old_lxstat64)(int ver, const char *file, struct stat64 *buf);
static int (*old_open)(const char *pathname, int flags, mode_t mode);
static int (*old_rmdir)(const char *pathname);
static int (*old_unlink)(const char *pathname);
static int (*old_unlinkat)(int dirfd, const char *pathname, int flags);
static int (*old_xstat)(int ver, const char *path, struct stat *buf);
static int (*old_xstat64)(int ver, const char *path, struct stat64 *buf);

static DIR *(*old_fdopendir)(int fd);
static DIR *(*old_opendir)(const char *name);

static struct dirent *(*old_readdir)(DIR *dir);
static struct dirent64 *(*old_readdir64)(DIR *dir);

Y ahora un ejemplo real, he infectado con este rootkit un sistema linux ocultando dos procesos a la vista de ps y derivados, he creado un proceso bash y otro nc ocultos.

[campus@... ~]$ ./nc -l 9000

Si interrogamos a ps en busca de procesos nc:

[root@... ~]# ps aux | grep -i nc
[root@... ~]#

El comando ps no ve nada.

Ahora vamos a usar Unhide para detectar estos procesos. De entrada, si Unhide está compilado estáticamente (como se recomienda en el manual) es totalmente inmune a esta clase de rootkits, no obstante vamos a usar una versión de Unhide compilada de forma normal debido a que -lamentablemente- la mayoría de distribuciones Linux lo empaquetan así.

Empezamos con un escaneo empleando syscalls

[root@... unhide-20110113]# ./unhide-linux26 sys
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Hidden processes through getpriority() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through getpgid() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through getsid() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getaffinity() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getparam() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getscheduler() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_rr_get_interval() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through kill(..,0) scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through  comparison of results of system calls

[*]Searching for Hidden processes through sysinfo() scanning

HIDDEN Processes Found: 2       sysinfo.procs = 143   ps_count = 142

¡¡ Bingo !! los procesos son detectados, el comando identificado y también la ruta en la que se encuentra.

Ahora vamos a probar un escaneo empleando los tests proc

[root@... unhide-20110113]# ./unhide-linux26 procall
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Hidden processes through /proc stat scanning

[*]Searching for Hidden processes through /proc chdir scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through /proc opendir scanning

[*]Searching for Hidden thread through /proc/pid/task readdir scanning

En este caso el rootkit ha bloqueado y ocultado la presencia de los procesos ante stat, readdir, opendir y readdir pero como Unhide también emplea chdir ha caído en ese test.

Conclusión: Este tipo de rootkits son bastante efectivos a la hora de hacer su trabajo, pero no son infalibles.
Leer más...

19 octubre 2011

WinUnhide

Desde hace algún tiempo tenía en mente el portar Unhide a plataformas Windows, Unhide está muy ligado a plataformas Unix/Linux y el hacer un port a una plataforma como Windows suponía un reto interesante.

Finalmente he conseguido un port plenamente funcional sobre el que poder trabajar más adelante y añadir más funcionalidad.

Unhide es una herramienta orientada a detectar inconsistencias en el sistema operativo a la hora de mostrar los procesos que se están ejecutando y los puertos TCP/UDP que están en uso, este tipo de comportamiento suele estar asociado a sistemas troyanizados con 'rootkits'. Unhide consta de dos partes, una orientada a localizar procesos ocultos y otra para puertos TCP/UDP igualmente ocultados empleando algún tipo de rootkit.

La versión Unix de Unhide emplea el comando 'ps' para hacer un listado de procesos y ejecuta una serie de pruebas para discernir la fiabilidad de la información mostrada por ese comando. En el caso de Windows, existe una herramienta idéntica llamada 'tasklist' pero he preferido emplear la interface WMI para Windows con el comando 'wmic'.

En concreto estoy usando el comando 'wmic process get ProcessId' para hacer un listado de procesos visibles a través de este comando, posteriormente empleo openprocess() y Toolhelp para barrer un amplio espacio de PIDs intentando localizar procesos que sean accesibles mediante estas APIs pero no aparezcan con el comando wmic.

En el caso de Unhide-TCP, he preferido 'saltarme' la filosofía empleada en entornos Unix debido a que la idea de parsear el comando 'netstat' en Windows sin ayuda de sed / awk, me pareció bastante titánica. Probablemente usando pcre hubiese sido factible, pero me pareció complicar sobremanera el código así que usé otra aproximación al problema.

Lo que he hecho con WinUnhide-TCP es listar los puertos TCP/UDP visibles mediante las llamadas GetTcpTable() y GetUdpTable(), y luego emplear bind() sobre todo el espacio de puertos posible para detectar puertos que no aparecen listados con las llamadas anteriores y en los que no se puede hacer bind(), señal de que esas funciones han sido troyanizadas.

Existen herramientas 'anti-rootkits' para entornos Windows como por ejemplo GMER, que son bastante mas completas y complejas, mi idea es simplificar el concepto ejecutando una serie de tests que indiquen si el sistema se encuentra comprometido o no, en caso de encontrar indicios, sería el momento de entrar a usar herramientas más complejas para identificar exactamente el problema

Leer más...

19 enero 2011

Unhide 20110113 is out !

Calentita del horno sale la última versión de Unhide (20110113) ofrecida en primicia para SbD. Por si alguien anda despistado Unhide es una herramienta de análisis forense para sistemas Unix de la que hemos hablado aquí y aquí (por ejemplo)

En esta ocasión el lanzamiento de la última versión estable coincide con el lanzamiento en paralelo de su propio sitio web www.unhide-forensics.info

La novedad mas destacada es que Patrick Gouin, arquitecto senior en desarrollo de sistemas embebidos, se une al staff de forma estable, y de su mano han llegado bastantes de las novedades de esta versión.

Entre las novedades mas destacadas :
  • Mayor granularidad a la hora de ejecutar tests: Hasta ahora existían 'metatests' que estaban compuestos en algunos casos por múltiples tareas, en esta versión se pueden seleccionar específicamente que tests ejecutar (por ejemplo un test con una syscall determinada)
  • Añadido un nuevo e interesante test llamado 'reverse' para identificar sistemas en los que se haya comprometido /bin/ps para hacerle creer que existe un proceso en ejecución que realmente no lo esté
  • Ampliados los test sobre procfs añadiendo chdir / readdir
  • Posibilidad de volcar el resultado del scan a un fichero con la opción -f
  • Posibilidad de ejecutar un test específico (-r) para Kernels cuyo planificador no sea el estándar (error detectado en sistemas cuyo kernel era una versión 'pura' de kernel.org)
  • Mejor integración con rkhunter
Y muchas otras más que podréis ver reflejadas en la pagina man del proyecto.

Para descargar la última versión: www.unhide-forensics.info
Leer más...

19 noviembre 2010

Herramienta StegoSense: Automatizando la reja de cardano…

Vivimos tiempos intensos... Tiempos de lobbies, Sindes y demás tropa Goofy. Tiempos de Wikileaks, Climategate, Anonymous y V de Vendetta, de disclosure projects... de informaciones "reveladoras" para todos los gustos, sabores y creencias [1][2].

Hoy, como siempre, existe información, sensible o no, que debe ser protegida de miradas indiscretas, restringiendo su uso al personal oportuno. La criptografía históricamente ha facilitado esta tarea. Adicionalmente, a sus múltiples ventajas incluye un inconveniente: su visibilidad. Las comunicaciones cifradas pueden ser fácilmente detectadas, aunque no por ello necesariamente fáciles de invertir, y en según qué escenarios esto no es interesante que ocurra. A lo largo de los siglos la esteganografía ha aportado su grano de arena para proporcionar un nivel de seguridad adicional y minimizar esta problemática. No sólo las comunicaciones no serán legibles sino que además se ocultará la propia existencia de las mismas. Existen gran multitud de técnicas y procedimientos según el escenario de comunicación y el tamaño de la información a transmitir (un breve resumen puede verse en [3]), así como herramientas de estegoanálisis (algunas gratuitas, con sus limitaciones, como StegSecret) .

Hace aproximadamente 1 año inicie una serie de investigaciones, por diversos motivos, sobre un tipo concreto de esteganografía, la esteganografía lingüística, teniendo en mente una serie de criterios.

Dado que el artículo es un "poco" extenso lo he divido en 4 partes, de forma que el lector que lo desee pueda leerse el artículo entero o directamente ver como funciona la herramienta (la última parte) y dejar para un futuro, si es de su interés, su funcionamiento interno. Las 4 partes son: a) Criterios a considerar en la esteganografía lingüística, b) la reja de Cardano, c) algoritmo Ryfle y d) mini-tutorial y ejemplos de la herramienta stegoSense.

PARTE I. Criterios a considerar en la esteganografía lingüística.

Criterios que tengo en mente cuanto trabajo este tema.

1. El texto en lenguaje natural es el "contenedor" más difundido en las comunicaciones. Es el mejor estegomedio para enmascarar y distribuir una información oculta.

2. Esta ciencia será utilizada para ocultar información de pequeño tamaño (decenas o pocas centenas de bits) consiguiendo procedimientos muy seguros (probabilidad de detección muy baja). Si la información a ocultar es grande suele ser más conveniente utilizar otros procedimientos, no necesariamente esteganográficos. Por tanto, existirán entornos donde sea interesante su uso (por ejemplo, canales altamente monitorizados) y otros en los que no.

3. Los algoritmos serán públicos (a diferencia de propuestas de esteganografía textual que manipulan textos basados en algoritmos secretos u oscuridad) y su seguridad dependerá de una clave criptográfica.

4. El estegotexto (creado o modificado) será independiente de canal. Es decir, sólo trabajo algoritmos que permitan manipular el lenguaje (modificaciones léxicas, sintácticas y semánticas), de forma, que un mismo estegotexto generado pudiera ser transmitido por diversos canales sin perder la información (impreso en una revista, intercambiado por e-mail, leído por teléfono, etc.)

PARTE II. La reja de Cardano.

Actualmente los algoritmos, que he publicado en este sentido, automatizan la ocultación de información en texto natural y permiten la posibilidad de corregir los estegotextos manualmente, generando textos "con validez humana" que no puedan ser detectados por software automatizado ni, incluso, por analistas humanos. Esto es muy interesante porque cualquier persona sin conocimientos técnicos podría crear estegotextos de gran calidad, sólo necesitaría saber leer y escribir.

En esta dirección va, por ejemplo, la herramienta Stelin, publicada entre otros, en la Rooted Con 2010. Esta herramienta permite ocultar centenas de bits en textos en lenguaje natural de tamaño medio, si bien es cierto se necesita un cierto entrenamiento en esta herramienta y la utilización de textos fuente (por ejemplos, libros de narrativa) con validez lingüística y tamaño de más de 10.000 palabras. El resultado permite generar estegotextos con validez lingüística indistinguibles no sólo por máquinas sino también por seres humanos.

Al desarrollar Stelin, por algún motivo extraño, me vino a la cabeza la posibilidad de automatizar, de alguna forma, la reja de Cardano. Este procedimiento, la rejilla de Cardano, fue desarrollado en el renacimiento por Girolamo Cardano (1501-1576) y funciona de la siguiente manera:


Cada destinatario posee un pedazo de papel o cartón con agujeros cortados en él (la verja o rejilla). Cuando esta plantilla se pone encima de un mensaje inocente, los agujeros dejan ver letras específicas del mensaje, revelando el mensaje oculto. Este procedimiento, en tanto en cuanto la plantilla se mantenga privada, presenta una elevada seguridad (¿secreto perfecto?), aunque tiene muchos inconvenientes entre los que destaca la necesidad de intercambiar una plantilla por cada comunicación o forzar que distintos textos escritos, que se usan de tapadera, tenga en las posiciones que "destaca" la plantilla la información oculta. A todo esto, hay que sumarle la baja capacidad de ocultación de este procedimiento.
La automatización de esta idea no parece sencilla en principio.


El problema que se debe resolver es cómo sincronizar las posiciones que el emisor quiere modificar con las posiciones que el receptor debe conocer para recuperar la información ocultada. Si se encuentra solución al problema se conseguirá generar estegotextos muy difíciles de detectar.

PARTE III. Algoritmo Ryfle.

Aunque el problema anterior se podría abordar de diferentes formas, decidí un camino mezclando esteganografía basada en diccionario y corrección manual (idea sacada de Stelin). Con esto diseñé un algoritmo que es el que he implementado en la herramienta StegoSense que hago pública hoy y de la que hablaré más adelante.

El algoritmo que realicé para generar estegotextos es muy simple y consiste en lo siguiente (fue publicado en el Third IEEE International Symposium on Trust, Security and Privacy for Emerging Applications, June 2010. Brandford-UK.)

1. Seleccionar uno o más textos fuentes privados, conocidos sólo por emisor y receptor. No hay ninguna limitación en la "calidad" de estos textos (a diferencia de Stelin). Además, como se entenderá al leer este artículo, este algoritmo puede ser adaptado sin problemas a diferentes idiomas simplemente seleccionado un texto privado en otra lengua, por ejemplo en inglés.

2. El texto fuente es divido en grupos (W) de palabras en función de un clave secreta compartida entre emisor y receptor. Actualmente las palabras que forman cada grupo se seleccionan pseudoaleatoriamente basado en un PRNG AES CTR-Mode (block 256 bits - key 256 bits) que depende de la clave de usuario. Para ello reutilizó una implementación de Rijndael, validada, que hice en 2003 en C.

3. La información a ocultar es cifrada mediante AES CTR Mode (block 256 bits - key 256 bits) que depende de la clave de usuario. La información se pasa a binario.

4. De cada grupo se selecciona una palabra (estego-palabra). Cada estego-palabra, oculta log2W bits, es seleccionada en función de la información binaria a ocultar. Es decir, un bloque de 8 palabras ocultaría 3 bits, uno de 16 palabras ocultaría 4 bits por estego-palabra seleccionada, etc.

5. El estegotexto resultante será un conjunto de estego-palabras consecutivas sin validez sintáctica ni coherencia global. Las estego-palabras extraídas van todas en minúscula y sin signos de puntuación. Esto permite mayor flexibilidad al emisor al poder poner mayúsculas o símbolos de puntuación donde desee. Símbolos soportados: tildes, coma y ")(:;.¿?!¡-'. Estos símbolos se pueden añadir en cualquier palabra en cualquier posición.

6. Corregir a mano el estegotexto resultante, anteponiendo una o más palabras en cada posición, hasta producir un texto con validez lingüística. Pueden añadirse una o más palabras de cualquier tipo delante de cada estego-palabra del estegotexto, con la única condición que la palabra elegida no se encuentre en el grupo de posibles palabras de donde se ha extraído esa estego-palabra. En la versión actual, para un funcionamiento adecuado, se debe utilizar las teclas de posición (adelante - atrás) o el ratón para posicionarse y la tecla retroceso para borrar caracteres. Lo más práctico es escribir libremente e ir validando el estegotexto (VALIDATE: control+L). Después de la última estego-palabra se puede añadir tantas palabras como se desee sin restricción.

7. El receptor no necesita conocer los "retoques" introducidos por el emisor, sólo el texto privado (fuente), el estegotexto recibido y la clave criptográfica. En principio, el valor "Bits Word/group" al ser reducido (3, 4, 5 o 6) no haría falta compartirlo ya que se podría probar cada uno, esto permitiría mayor libertad al emisor en la selección del mismo y por tanto facilitarle la creación de un estegotexto u otro.




PARTE IV. Mini-tutorial y ejemplos de la herramienta StegoSense

En la parte III se explica el algoritmo publicado y ahora hago pública una aplicación gráfica para utilizarlo de manera sencilla. Es una versión beta (con lo que ello implica), y aunque este algoritmo tiene sus limitaciones se puede ver fácilmente su utilidad. Su uso recomendado (si no se quiere invertir mucho tiempo en edición) es para información pequeña, cómo el intercambio de claves criptográficas, urls (URIs en general), direcciones de mail, coordenadas gps, etc.

Por ejemplo, con la herramienta podríamos enviarle a nuestra amiga Sinde en un "texto inofensivo" un enlace a una web, donde tenemos N películas (cifradas o no), y que por algún motivo no queremos que nadie detecte que en realidad Sinde intercambia películas de vaqueros amorosos... Existen, pues, muchos usos legítimos y no legítimos de esta herramienta/tecnología, cada cual que piense los suyos... yo prefiero no dar ideas "raras".

En fin, la aplicación gráfica es muy sencilla de utilizar. Destaco algún punto:

1. File: Open Source (abrir fichero fuente) y Open stegoText (abrir un estegotexto recibido).

2. Stegotexto: Generate (generar estegotexto, necesita Open Source & Msg&Password), Unhide (recupera la información oculta, necesita Open Source & Password).

3. StegoTexto -> Validate

La utilidad principal de esta herramienta gráfica (StegoSense) es que permite mayor comodidad al emisor al redactar los estegotextos. Puedes desplazarte por el estego-texto con el teclado y ver el conjunto de palabras que no puedes añadir delante de cada estego-palabra. El funcionamiento más práctico consiste en dada una serie de estego-palabras, escribir libremente el estegotexto y luego darle a "Validate". Si hemos metido alguna palabra no válida la herramienta indicará, por orden de aparición, la primera en la que la hemos "cagado". De esta forma es más rápido construir estegotextos por este procedimiento.

4. Bits Word/group

El algoritmo construye bloques de palabras. Lógicamente si el bloque es más grande se oculta más información por estego-palabra seleccionada, pero es más difícil elegir palabras delante de ella. Por el contrario, menos palabras por bloque implican ocultar menos información, pero es más fácil hacer un estegotexto manualmente. Como se indica en el paper publicado (en la web de la herramienta) esto es un valor de compromiso. Los valores más adecuados son W=3 (8 palabras por grupo) o W=4 (16 palabras por grupo). En el software doy soporte hasta W=6 (64 palabras por grupo).

5. Alfabeto

Para generar estegotextos más pequeños sólo doy soporte a un alfabeto concreto (optimizo relación carácter-bits a ocultar), en el cuál las mayúsculas "ocupan más" (se generaría un código de mayúscula y el carácter en minúscula correspondiente).
El alfabeto soportado es: abcdefghijklmnñopqrstuvwxyzABCDEFGHIJKLMNÑOPQRSTUVWXYZ0123456789:;=@/?%&|!_"'<>()*.[]space +-

Si has llegado hasta aquí recuerdame que te debo una caña...

Ahora los ejemplos:

[Texto fuente]: Descargado de internet... (fuente.txt)

[EJEMPLO 1]

Clave: faletecome
Msg: spy@gmail.com
Bloque: 6 (15 stego-words generated)
Generado:

imagenes de aqui manos este lleno tus específicamente noche amo utilidades que envuelto montes de


StegoTexto Posible (stegotexto1):

Te envío imágenes de aquí, mi nuevo piso. Hoy tengo las manos destrozadas de limpiar este nidito lleno de posibilidades. Tus deseos, específicamente tus perversiones, esta noche serán satisfechos (te amo). Ya le sacaremos utilidades a todos estos rincones... que ganas. Te espero envuelto con sábanas construyendo montes de lujuria.

[EJEMPLO 2]

Clave: awikileakslegustanlosrusos
Msg: 5ps!7j4?
Bloque:4
Generado: (14 stego-words generated)

vivos estrechas mil cuando sierra murallas llama julio dos sobre el o sea racimos

StegoTexto posible (stegotexto2):

Todavía hay vivos intelectuales de estrechas miras. Mil veces repetiré, cuando sea necesario, que ni una sierra puede rajar esas mentes tan cerradas (murallas primitivas) ni una llama quemar sus prejuicios. En Julio quería haber escrito dos artículos sobre este asunto: a) el nuevo esnobismo o elitismo rancio y b) el corporativismo chusquero. Sea como fuere, bombas de racimos lanzaba yo a unos cuantos. A ver si saco tiempo...

[EJEMPLO 3]

http://bit.ly/d0bLRY

Clave: mandanga
Msg: d0bLRY
Bloque: 6
Generado (11 stegowords)

hacha verdad hacha padre mano es camino da ha medio claras

StegoTexto posible (stegotexto3):

Hacha afilada es mi verdad, hacha incisiva. No siempre fue así. Mi padre tiempo atrás (apretó mi mano con fuerza para aconsejarme) me recomendó medir mis palabras, no pude hacerle caso. Es mi camino no tengo dudas: da o recibe. Ha resurgido mi alma revolucionaria, medio dormida, ahora tengo claras mis ideas.

Conclusiones

Todavía quedan pendientes unas cuantas mejoras y corregir algún asunto. No obstante, se puede hacer uno una idea de la utilidad, ventajas y limitaciones de una propuesta "peculiar" de este tipo.

Para invertir poco tiempo en el maquillaje del estegotexto creado es aconsejable suprimir de la información a ocultar todos aquellos datos fácilmente deducibles, por ejemplo, de una url el http://.
A día de hoy no se conocen ataques a este algoritmo, en tanto en cuanto la clave criptográfica se mantenga en privado y adicionalmente no se pueda relacionar un estegotexto con un texto fuente concreto (agradezco sugerencias).

A veces, ideas sencillas... vencen a tecnologías complejas y caras de monitorización :)

Hasta la próxima tool...

Alfonso Muñoz  
http://stegosense.sourceforge.net

[1] http://www.disclosureproject.org
[2] http://video.google.com/googleplayer.swf?docid=-2425164651672376306&hl=es&fs=true"
[3] http://www.slideshare.net/chemai64/asegrit-iv-esteganografa-en-la-web-presentation
Leer más...