Humor: Como se hizo Chrome!!

encontrado via billytec.com

Ver todos los dispositivos USB que fueron conectados en Windows

Como ya he comentado en anteriores post, los dispositivos USB de almacenamiento, son muy prácticos, pero puede resultar un problema de seguridad, porque a través de ellos pueden infectar nuestro sistema o ser usados para llevar información crítica del sistema.

Con la herramienta USBDeview podemos ver que dispositivos USB fueron conectados al sistema y cuando. Esta herramienta puede mostrar la siguiente información sobre el dispositivo: nombre, descripción, tipo de dispositivo, letra de unidad, número de serie, fecha de instalación, fecha de última conexión y desconexión.

También permite bloquear los dispositivos que seleccionemos, desinstalarlos o bloquear todos los dispositivos USB que se conecten al sistema. Es una aplicación que apenas ocupa 84 Kb lo que la convierte en una herramienta para añadir a nuestra colección de software portable de seguridad.

Más información y descarga de USBDeview:
http://www.nirsoft.net/utils/usb_devices_view.html

Auditar uso de dispositivos USB, FireWire y PCMCIA:
http://vtroger.blogspot.com/2006/09/...tivos-usb.html

5 comandos para detectar ataques en windows

Hoy vamos a aprender a examinar una maquina en busca de malware o conexiones no apropiadas de una maquina.
Como muchos sabemos los programas espias , troyanos etc.. utilizan una parte de conexion a internet para mandar datos a su creador o a la persona que nos infecto, hoy vamos a aprender como podemos identificarlos , ya queda en ustedes investigar el nombre del proceso y que tipo de software pueden tener instalado que pueden dañar su integridad , por razones de extencion no vamos a ver que tipos de programas malware existen.
Bueno espero que les guste y aprendan



1) WMIC: Un mundo de aventura espera
Instrumentación de Dirección de Ventanas (WMIC) ; WMIC deja a usuarios administrativos tener acceso a todas las clases de información detallada sobre una máquina en Ventanas, incluyendo los atributos detallados de unos miles de ajustes y objetos. WMIC es construido en D.O.S.
Para usar WMIC, los usuarios deben digitar el comando wmic en el interprete de comandos(D.O:S) el automanticamente lo instalara y estaremos listos para empezar.

C: \>wmic process

De seguro saldra un resultado casi no leible, por la razon que no le dimos comandos para organizar la salida de la consulta.
Wmic nos permite organizar la salida de las consultas de forma de lista o full.
Por ejemplo, podemos mirar un resumen(sumario) de cada proceso que corre sobre una máquina :

C: \> wmic process list brief

Mostrará el nombre, ID y prioridad de cada proceso, así como otros atributos interesantes. Para Conseguir aún más detalle, digitamos:

C: \> wmic process list full

Muestra todas las clases de detalles, incluyendo el hilo del ejecutable asociado con el proceso y su invocación de línea de mando. Si Investigamos una máquina por una infección, un administrador debería mirar cada proceso para determinar si tiene procesos legítimos sobre la máquina.
Más allá de mirar el l alias de un proceso, los usuarios podrían incluir en el arranque un proceso determiando, para conseguir una lista de todos los programas de inicio sobre una máquina utilizaremos el siguiente comando:

C: \> wmic startup list full

Mucho malware automáticamente utiiliza el autoinicio añadiendo una entrada de autorun junto a los procesos legítimos que pueden pertenecer antivirus y varios programas de bandeja de sistema.
Una opción práctica dentro de WMIC es la capacidad de controlar un mando de la información creciente en una base repetida por usando la sintaxis " / cada: [N] " .[La N] es un número entero, indicando que WMIC debera controlar la orden dado cada [N] segundos. Así, los usuarios pueden buscar cambios de los ajustes del sistema con el tiempo. Usando esta función para tirar un resumen(sumario) de proceso cada 5 segundos, usuarios podrían correr:

C: \> wmic process list brief /every:1

CTRL+C para parrar el ciclo.


2) El comando net:

Los administradores pueden usar esto para mostrar todas las clases de información útil.
Por ejemplo, " net user" muestra todas las cuentas de usuario definidas sobre la máquina. " net localgroup " muestra los grupos, " net localgroup administrators" muestra los usuarios del grupo de administradores " net start " muestra los servicios que estan corriendo.
Los atacantes con frecuencia añaden a usuarios a un sistema o ponen sus propias cuentas en los grupos de administradores, entonces esto es siempre una idea buena de comprobar la salida de estas órdenes para ver si un atacante ha manipulado las cuentas sobre una máquina. También, algunos atacantes crean sus propios servicios en una máquina.


3) Openfiles:


Como su nombre implica, este mando muestra todos los archivos que son abiertos sobre windows, indicando el nombre de proceso que actúa recíprocamente con cada archivo,esto mostrará todos los archivos abiertos , dando el nombre de proceso y el camino de cada archivo.

Por la cantidad de datos que nos arrojan las estadisticas debemos fltrar la salida de informacion

C: \> openfiles /local on

C: \> openfiles /query /v

Este mando mostrará la salida verbosa, que incluye la cuenta de usuario y cada proceso abierto activo. Cuando terminado con el mando de openfiles, puede ser cerrada y el sistema vuelve a sul funcionamiento normal :

C: \> openfiles /local off

4) Netstat: Muéstra la red

este comando muestran la actividad de red, enfocando TCP y UDP por defecto. Como los malware a menudo se comunica a través de la red, los usuarios pueden buscar conexiones desconocidas en la salida de netstat, para esto ejecutamos así:

C: \> netstat -nao

La opción-n dice a netstat que muestre números en su salida, no los nombres de máquinas y protocolos, y en cambio muestra direcciones de IP Y TCP o números de puerto de UDP. El-a indica que muestre todas las conexiones y puertos de escucha. La opción-o dice a netstat mostrar el número de processID de cada programa que actúa recíprocamente con el puerto de UDP O UN TCP. Si, en vez de TCP Y UDP, usted está interesado en ICMP, netstat tambien lo puede hacer:

C: \> netstat-s-p icmp

Esto devolverá la estadística (-s) del protocolo ICMP. Aunque no tan detallado como el TCP y UDP, los usuarios puedan ver si una máquina envía el tráfico frecuente e inesperado ICMP sobre la red. Algunas puertas traseras y otro malware comunican la utilización de la carga útil de mensajes de Eco de ICMP.


Como WMIC, el comando netstat también nos deja controlarlo cada N segundos. Pero, en vez de usar la sintaxis WMIC " de / cada: [N] ", los usuarios simplemente siguen su invocación netstat con un espacio y un número entero. Así, para catalogar el TCP y puertos UDP en el empleo sobre una máquina cada 2 segundos, usuarios pueden correr:

C: \> netstat-na 2

5) Find:: Busqueda

La mayor parte de las órdenes de las que he hablado hasta ahora dan mucha informacion de salida , que podría ser difícil o maluca la examinacion para una persona encontrar un artículo específico.
Invocado con el mando /c, contará el número de las líneas de su salida que incluyen un valor dado. Los usuarios a menudo quieren contar el número de líneas en la salida de un mando, determinar cuántos procesos controlan, cuantos procesos de arranque están presentes. Para contar las líneas de salida, los usuarios podrían simplemente hacerlo con /c/v " ". Este mando contará (/c) el número de las líneas que no tienen (/v) una línea en blanco (" ") en ellos.


Por ejemplo, para mirar información cada segundo sobre procesos que corren sobre de cmd.exe :

C: \> wmic process list brief /every:1 | find "cmd.exe"

O, para ver que procesos autoinician, son asociados con el registro HKLM :

C: \> wmic startup list brief | find /i "hklm"

Contar el número de archivos que se abren sobre una máquina sobre la cual openfiles es activada:

C: \> openfiles /query /v | find /c /v ""

RESUMEN:


Con estos cinco instrumentos, los usuarios pueden conseguir mucha información sobre la configuración y el estado de seguridad de una máquina por medio de Ventanas(D.O.S) en busca de denticar un compromiso o ataque, sin embargo, un usuario tiene que comparar los ajustes que corren en la maquina examinada con una máquina "normal", no infectada.


by bad_robot

humor mas

Stone vs iPhone 3G

---------------------------------------------------------------------------------------------

20 cosas por las cuales un programador podría perder la cabeza

1. Que se caiga la conexión de internet cuando uno vaya en un 99% de descargar un archivo de 100MB y no tenga forma de reiniciar la descarga desde el Downloader.

2. Que cuando uno por fin se haya matado haciendo un código de 1000 líneas, se de cuenta que el mismo control lo encuentra gratis y estaba en uno de los sitios que más visita.

3. Desarrollar un sitio ASP.NET sin medir consecuencias y en el justo momento de entregarlo tu cliente te diga que tiene un servidor Apache y que no puedes montar MONO en la máquina.(Para los menos expertos,,, que haga uno un sitio que solo funcione en windows y el cliente tenga linux en el servidor).

4. Que cuando uno termine de montar la PC (instalar desde cero) se dé cuenta que la causa de tus bloqueos se debia a que el mouse estaba sucio.

5. Que cuando llama uno a EPM a que le arreglen la internet,,, como por arte de magia se arregle y una vez uno tira la bocina,,, plof! comienza a agonizar el DSL.

6. Que cuando llueva se caiga la conexión a internet,,, será solo en mi casa que sucede esto?

7. Que en mi casa limpien el teléfono y se caiga la internet.

8. Que el dia que tengas todo el proyecto de tu vida terminado para entregar y listo para probar en una presentación, se te quede en la casa todo el trabajo del fin de semana y llegues a la presentación sin la memoria USB que tiene el trabajo guardado pegado de tu pc,,, en tu casa !

9. Que por ahorrarse uno 10 dólares termine uno involucrado en una batalla campal internacional por un proveedor de dominios(registerfly.com) que habla en inglés y que aun piensa que en Colombia usamos taparrabos.

10. Que tu salario sea inversamente proporcional a tus aspiraciones tecnológicas.

11. Que mi monitor LCD haga interferencia con el secador de cabello de mi tía cuando lo enciende en el segundo piso,,, me siento como si estuviera viendo televisión en una peluquería.

12. Que se vaya la luz a las 0.00 Hr un domingo sin que hayas guardado una sola línea de la investigación de controles web que estabas haciendo y que ya tenías todo listo para comenzar a elaborar el control que soñabas tener. Te odio Notepad.

13. Que mientras que chateo con una persona me llame y me diga que si estoy viendo lo que le estoy escribiendo,,, eso es un sacrilegio y una saturación a los medios de comunicación,,, eso me acuerda cuando transmiten las previas de los partidos de fútbol en directo desde los noticieros y
las personas detrás del presentador llaman desde sus celulares a la familia para que las vean haciendo morisquetas en TV.

14. Que 24 horas de buscar un problema se resuelva con un Commit();.

15. Que 48 horas de buscar un problema se resuelva con unas comillas.

16. Que 72 horas de buscar un problema te des cuenta que Windows te prohibe hacer eso y tu jefe quiere que lo hagas,,, A quien le hago caso, a Windows o a mi jefe?

17. Que hacer una conexión ASP.NET con ORACLE sea más enredado que ver parir un cruce entre erizo y oveja. Pero funcionó como 3 días después sin motivo ni razón alguna,,, eso es lo que yo llamo Teoria de la Relatividad Aplicada a la Programación con Oracle.

18. Que te levantes una mañana comun, silvestre y tranquila y digas "Me encantan los sábados de flojera", siendo miércoles. (Pasa en los Simpson, me pasa a mí y muchas veces me ha pasado, malditos sabados falsos).

19. Que armes toda una teoría Kepleriana de la recursividad para explicar que la recursividad es el resultado de la recursividad de la recursividad y te digan que por qué repites tanto la palabra recursividad, que no es correcto en español repetirla,,, Señora profesora Maria(), como hago para explicarle a un programador Junior qué es recursividad sin utilizar la palabra recursividad más de una vez?

20. Y la última, la que casi siempre me hace perder la cabeza,,, cuando uno está programando y preguntan que como va y uno dice que bien,,, que la persona le responda a uno,,, Gracias a Dios {El Líder},,, A Dios? Ojalá dios {El Líder} estuviera en mi asiento programando, de seguro ya habría mandado cerrar Microsoft y a los creadores de Visual C++. Debe ser muy divertido ver cómo un hiciera una plegaria a un software y apareciera código solito y contante,,, sería genial,,, pensaré en ese algoritmo para realizar como segundo proyecto, después de la descendiencia de los blogs. Amo al Líder.

Notas: En este blog estamos teniendo una tendencia fuerte hacia el Líder, si eres cristiano o católico o musulmán o judío o lo que sea, tendrás que abandonar tu religión para seguirnos leyendo porque estamos convirtiendo este blog a la secta de los movimientarios. Amamos al Líder. Terminator su amo y señor, asi que todos van a morir por dejar de adorarme. Para esto, les dejo una fotografía de mi Canciller para Latinoamérica para que vayan rezando sus últimas plegarias que no serán escuchadas por él, por las razones que mostramos a continuación (se compró un iPod el desgraciado):

fuente:alejandroge.blogspot.com

Pass correcto, este es tu código de verificacion, guardalo
4bfd34a63a15e69a4c49173f1754976b
Meter mi código

mas humor xD

Por razones de estudio , no he podido postear nuevos temas , ademas de los laboratorios , pido disculpas por la demora , mientras tanto les dejo mas humor para que rian un rato gracias a chistesgeeks.com saludos

« Microsoft lanza un reloj

Use el raton para abrir la ventana »

TIPOGRAFIAS

Les dejo esta tipografia para que ustedes descubran cual es:

---------------------------------------------------------------------------------------------

MEDITACION GEEK

------------------------------------------------------------------------------------------

Novias geeks

Seguimos comparando sistemas operativos con “cosas” hoy con mujeres:

Novia Vista: Es la que uno elige porque la ve bonita y esta medio buena, pero después de un tiempo te das cuenta que no hace lo que tu quieres, y fue una mala elección.
Novia XP: Es del tipo más común, es la novia normal, no es la gran cosa, pero uno lleva tanto tiempo con ella, que no es capaz de dejarla.
Novia 98: Uno lleva tantos años con ella que ¡para que cambiarla!, si uno ya se acostumbró a todas sus mañas.
Novia Tux: Se le saca en mayor rendimiento con el menor esfuerzo. Trata de no molestar aunque a veces lo hace. Y no es tan fea como muchos piensan.
Novia *nix: Casi nadie la conoce, no es bonita ni fea, pero ella se presta para hacer muchas cosas. No cualquiera es capaz de manejarla.
Novia Ubuntu: Es la que uno dice, “¡con ésta me voy a casar!”. Prometedora, bonita, pero como toda novia, tiene sus mañas escondidas.
Novia Mac: No la tiene cualquiera, para llegar a una de estas hay que tener mucha plata, su mantenimiento es mas caro que cualquiera de las anteriores. Pero tiene sus ventajas: no molesta tanto, es la más bonita ¡y es la que todos querrían tener!

--------------------------------------------------------------------------------------

Sistemas operativos y comidas.

Hagamos un paralelismo entre las comidas y los sistemas operativos.

Windows: Comida rapida

• Es fácil de conseguir.
• Sirve para saciar el apetito, pero tiene carencias nutricionales.
• El usuario tiene muy poco control sobre la personalización de la comida (con queso, sin queso, con pepinillos, sin pepinillos y poco más)
• Los dueños de los restaurantes de comida rápida dicen ser filántropos, pero jamás regalarán su producto a menos que tengan un beneficio comercial en tal acción.
• La publicidad sobre el producto raramente refleja el producto real (prometen mucho más de lo que el comprador recibe al adquirirla).

Mac: Comida Gourmet

• Es cara.
• La presentación es casi más importante que el producto en sí.
• El usuario no puede aderezar libremente la comida. Tiene que comerla como se la sirven y si cuestiona el sabor, generalmente se le tachará de tener mal gusto.
• Mucha gente la come no porque crea que es más sabrosa, sino porque al hacerlo aparenta ser un entendido culinario frente a sus amigos.

Linux: Comida Casera

• Siempre estuvo ahí, no se inventó por negocio, sino por necesidad y por placer.
• Se ajusta a todos los bolsillos, puede ser barata, cara o incluso gratuita.
• Puedes compartir las recetas con tus amigos. No hay secretos.
• A veces se te puede quemar, pero a la próxima ya sabes cómo evitarlo y te saldrá cada vez mejor.
• Una vez que la tienes servida en tu plato, lista para comerla, te darás cuenta que nada de lo que puedas comprar por ahí se compara con tu propia comida casera, preparada a tu gusto.

El post original y la lista completa en Geektool

--------------------------------------------------------------------------------------------

El comando que le falta a mi mujer

Me presento. Soy Fernando (alias Ferticidio) Tengo 22 años. Y desde hoy voy a intentar divertirlos un rato :p

Creo que no hay nada mas que decir.

vía: Mozilla Wiki y xkcd

-------------------------------------------------------------------------------------

Windows vs Linux

Mas comandos para DOS

Hace poco postee casi 151 comandos para el inicio-ejecutar xD, aqui les traigo otro complemento y proximamente una pag dedicada a tener todos los comandos existentes

PD: para los que han tratado de ejecutar el inuse.exe les tengo la solucion pero para la proxima sera...

1. Mapa de Caracteres = charmap.exe ( Para Modificar Caracteres Indefinidos con sus Fontes)

2. Limpieza de Disco = cleanmgr.exe

3. Area de Transferencia = clipbrd.exe ( Verifica que está en el clipboard, o que está copiado en la Memória Temporária)

4. Dr Watson = drwtsn32.exe ( Herramienta àra Solucionar Problemas )

5. DirectX diagnóstico = diag.exe (Testeador de DirectX, Video & Placas de Sonido )

6. Editor de Cuentas Privadas = eudcedit.exe ( Pude Crear o Modificar Cuentas ( Incluyendo la Administrador ))

7. IExpress Wizard = iexpress.exe ( Compactador de Archivos , WinRAR ou WinZip No es Necesario Tenerlos )

8. Mcft Synchronization Manager = mobsync.exe ( Permite La Sincronizacion de Archivos en Redes Locales )

9. Windows Media Player 5.1 = mplay32.exe (Abre una V5.1 o Mayor )

10. ODBC Data Source Administrator = odbcad32.exe ( Base de Datos )

11. Gerenciador de Objetos = packager.exe

12. System Monitor = perfmon.exe ( Todo o Lo que Usted Quiera Saber de Performan de su PC, para usuários avanzados )

13. Gerenciador de Programas = progman.exe

14. Remote Access phone book = rasphone.exe

15. Registry Editor = regedt32.exe ou regedit.exe ( Para Ver / Modificar El Registro de Windows )

16. Services = services.msc ( Inicia, Para una Configuracion de Servicios de Windows )

17. Network shared folder wizard = shrpubw.exe ( Cree Archivos Compatibles en Red )

18. File signature verification tool = sigverif.exe ( Verifica el Estado de un Archivo )

19. Volume Control = sndvol32.exe ( Control de Volumen )

20. System Configuration Editor = sysedit.exe ( Modifique System.ini y Win.ini )

21. Syskey = syskey.exe ( Protege Bases de Datos de Cuentas de Windows - Use Con Cuidado )

22. Mcft Telnet Client = telnet.exe ( Publicar Publicamente Telnet en DOS )

23. Driver Verifier Manager = verifier.exe ( Para Monitorear la Actividad de Driver´s )

24. Windows for Workgroups Chat = winchat.exe ( Para Crear un Verdadero Chat en la Red Local )

25. System configuration = msconfig.exe ( Para Habilitar / Desabilitar Programas que se Inicien con Windows )

26. Diretivas de grupo - gpedit.msc ( Permite Editar Objetos de Directiva de Grupo )

Saludos y proximamente empezare con los laboratorios que prometi :D

otro post dedicado al humor xD

Examen Geek

Examen… se te pone la cabeza en blanco… No sabes que hacer… ¿Y si…?

Yo le daría un punto por la originalidad…

-------------------------------------------------------------------------------------------

AMOR GEEK

Sigo con el PHP, ahora una remera para poder demostrarle a esa chica tan especial todo lo que la queres.

---------------------------------------------------------------------------------------------

POESIA GEEK

Un fragmento del gran libro de la poesia geek:

Saludos y agradecimientos a chistesgeeks.com por el rato agradable :)

USB hecho de goma

Cada vez sorprenden más los gadgets que construyen en instructables. En este caso se trata de un USB Flash Drive que lo hicieron en base a una goma de borrar y nos dejan los 5 pasos para que probemos en nuestras casas si podemos armarlo. Si alguien se anima a hacerlo que nos avise!

fuente:www.puntogeek.com

Post dedicado a las imaganes en linux

AcetoneISO2 es una completa aplicación para gestionar imágenes de CD/DVD. Podrás montar imágenes de los formatos ISO, BIN, NRG, MDF y IMG. Todo ello con una simple interfaz de usuario (GUI).


Con AcetoneISO2 también podrás convertir a imagen ISO entre varios tipos de imagen de disco (te puede interesar).

Aparte cabe destacar:

• Extrae el contenido de las imágenes a una carpeta
• Reproduce una imagen de DVD con Kaffeine / VLC / SMplayer y descarga automáticamente la cubierta desde Amazon
• Genera una imagen ISO de una carpeta o CD / DVD
• Puede cifrar o descifrar una imagen de disco
• Ripea los juegos de PS2 a *.bin para que funcionen en los emuladores epsxe/psx
• Crea copias de seguridad de CDs de Audio a formato *.bin
• Descarga vídeos de Youtube :P
  
• y mucho más...
  

.- Como descargar/instalar
Puedes descargar el AcetoneISO2 desde cualquiera de los siguientes enlaces (por arquitectura).

• Ubuntu 32bit
• Ubuntu 64bit
• Más distribuciones y codigo fuente
  

Una vez descargado puedes instalarlo con doble clic, y ejecútalo desde:

Accesorios > AcetoneISO

fuente:belinuxmyfriend.blogspot.com
------------------------------------------------------------------------------------------

El otro día me hizo falta convertir una imagen .mdf (Alcohol 120%) a ISO para poder copiarlo y al buscar di con un pequeño how-to de como convertir entre varios tipos de imágenes (CUE/BIN, NRG, IMG, MDF) a ISO.

Listado de aplicaciones que usan este tipo de extensión (principalmente):

• CUE/BIN : CloneCD (y CloneDVD)
• NRG: Nero
• MDF: Alcohol 120%
• IMG: Varios

.- Como convertir imágenes CUE/BIN, NRG, IMG, MDF a ISO
Lo primero que tendremos que hacer es instalar, desde los repositorios de Ubuntu (Universe), las aplicaciones necesarias, todas ellas para consola, para llevar acabo dicha conversión. Después de instalarlas tendremos que convertir los archivos, así de fácil:


.- CUE/BIN a ISO: bchunk

$ sudo aptitude install bchunk

Lo usamos:

$ bchunk imagen-fuente.cue (o imagen-fuente.bin) imagen-destino.iso

-----

.- IMG a ISO: ccd2iso

$ sudo aptitude install ccd2iso

Lo usamos:

$ ccd2iso imagen-fuente.img imagen-destino.iso

-----

.- MDF a ISO: mdf2iso

$ sudo aptitude install mdf2iso

Lo usamos:

$ mdf2iso imagen-fuente.mdf imagen-destino.iso

-----

.- NRG a ISO: nrg2iso

$ sudo aptitude install nrg2iso

Lo usamos:

$ nrg2iso imagen-fuente.nrg imagen-destino.iso


Fuente: howtodothings

belinuxmyfriend.blogspot.com

Análisis forense MSN Messenger: MSN Shadow

Hola,

MSN Shadow es una herramienta de análisis forense orientada a MSN Messenger (recientemente rebautizado como Windows Live Messenger), ya que puede realizar operaciones específicas de análisis basadas en el Microsoft Notification Protocol, el protocolo de mensajería instantánea desarrollado por Redmond del que se abastece el popular Messenger.

MSN Shadow permite capturar el tráfico de texto y de vídeo de las sesiones Messenger, pudiendo exportarlas a HTML y AVI respectivamente. Adicionamente, permite la realización de pruebas de concepto relacionadas con el spoofing de autoría de mensajes (reenviando los números ack de las conversaciones mediante paquetes reset RST) y el secuestro de sesiones (igual que el método anterior, pero creando dos reglas específicas iptables para gestionar los paquetes, lo que hará que se abra una nueva ventana para continuar la conversación como si fuéramos la persona cuya sesión ha sido secuestrada)

Este software está pensado para analizar el tráfico de Messenger y para poder verificar si es factible la suplantación y el secuestro de sesiones, lo que podría tener utilidad como prueba pericial en un caso donde se presenten evidencias en la forma de logs de mensajería instantánea. Bajo ningún concepto entiendo que esté orientado a espiar/perjudicar/engañar/molestar a nadie.

El proyecto tiene un blog en http://msnshadow.blogspot.com/ y las descargas se pueden efectuar en la página de Sourceforge http://sourceforge.net/projects/msnshadow. Hay un tar genérico y un paquete Debian para facilitar la instalación a los usuarios de esta distribución y sus derivados. Tiene, como dependencias, libmimic, QT y libpcap.

Para instalar MSN Shadow debe ejecutarse el tradicional ./configure & make & make install. Lamentablemente para los usuarios de Windows, no existe un binario ejecutable para esta plataforma en la actualidad.

Un saludo,

fuente:www.sahw.com

Anti-Forensics: Teoría de Evasión Forense

un texto mas completo sobre anti-forense

Anti-Forensics: Teoría de Evasión Forense

Con el desarrollo progresivo de los métodos de investigación forense, en los foros públicos, BBS's empezaron a aparecer posts referentes a las técnicas que los intrusos pueden utilizar para evitar que un forense cualificado pueda llevar acabo su trabajo con éxito. El trabajo del investigador forense depende de las pruebas encontradas en el sistema de ficheros de la máquina comprometida en todo caso, en el supuesto de que no exista ninguna prueba la eficacía de la investigación se reduce a nada.

El objetivo detrás de cualquier investigación realizada por un forense o un equipo de respuesta rápida sobre un sistema de ficheros puede ser de tipo 'legal' o 'casual'. Teniendo en consideración que estos términos no tienen un significado estandarizado para describir los motivos de una investigación y cada uno de ellos se diferencia bastante del otro debemos detallar más.

Investigación Legal: La mayoría de las investigaciones forenses de tipo legal tienen como objetivo asistir a los órganos oficiales a llevar acabo una investigación criminal a fin de llevar ante la justicia al culpable del delito. En investigaciones de este tipo es imprescindible seguir de forma estricta los procedimientos para el tratamiento de pruebas que van a ser presentadas en el juzgado. Por ejemplo, el mero error de sobreescribir cualquier prueba en el sistema de ficheros por información aleatoria (pérdida de datos) es suficiente para considerar el resto de las pruebas de la misma índole como inviables por parte de un juez o fiscal. Investigaciones legales, a menudo, únicamente se limitan a la conservación de datos y esfuerzos de mantener la integridad de información en el sistema de ficheros una vez el hecho del compromiso ha sido probado. Las pruebas tras ser tratadas de forma correcta se transfieren al poder de órganos oficiales para ser analizados por parte de sus recursos. El nivel de participación del forense en la investigación una vez las pruebas han sido transferidas depende del deseo del denunciante y la voluntad de órganos oficiales.

Investigación Casual: Cualquier tipo de investigación casual no tiene como objetivo la persecución legal del individuo responsable del acto criminal. La investigación se realiza por el interés desde el punto de vista forense, por lo tanto las técnicas, herramientas y metodología utilizada puede ser usada de forma más agresiva. La realización de una investigación forense casual requiere más conocimiento y experiencia por parte del investigador, ya que en estos casos no existen requerimientos estrictos de terceros referentes a la cantidad y calidad de pruebas obtenidas.

Indiferentemente del tipo de investigación los pasos iniciales deben ser básicamente los mismos en cada caso:

• El sistema de ficheros debe ser salvada
• La información que contiene el sistema de ficheros debe ser recogida
• Esa información debe ser tratada y almacenada como prueba
• Las pruebas deben ser examinadas

El concepto de prueba se forma por el contenido de los ficheros (datos) y la información sobre los ficheros (meta-datos). Basándose en las pruebas obtenidas del sistema de ficheros el investigador debe intentar a:

• Quien - Reunir la información sobre el/los individuo/s involucrados en el compromiso
• Que - Determinar la naturaleza exacta de eventos ocurridos
• Cuando - Reconstruir la secuencia temporal de los hechos
• Como - Descubrir que herramientas o exploits han sido utilizados para el compromiso

Como un ejemplo de proceso forense examinaremos un caso de recuperación de un fichero eliminado.

Cuando hablamos de borrar un archivo bajo GNU/Linux, Unix queremos decir que el contador interno de enlaces inode (i_links_count) se decrementa a 0. El decremento es alcanzado eliminando todos los pares de inodes de la tabla de directorio referentes al nombre del fichero. Una vez el inode es eliminado, el núcleo marcará este recurso como disponible para uso por otros ficheros o procesos, nada más. El inode eliminado va a seguir conteniendo la información sobre el fichero referenciado y los bloques de datos a que el inode hace referencia seguirán teniendo el contenido del archivo. Este estado se mantendrá hasta que el espacio se re-asigne y se reuse sobreescribiendo los datos residuales. Por lo tanto la recuperación de ficheros eliminados es esencial para cualquier analista forense, dicho en otras palabras la recuperación de archivos se reduce a la búsqueda de inodes con datos pero con el contador de enlaces a 0 (es decir no vírgenes). El resultado es el listado de inodes borrados. Los punteros indicarán el offset de bloques que contienen los datos del fichero, lo que permitirá posiblemente recuperar el/los archivo/s eliminados. Aunque los bloques de datos ya estén ocupados por otra información (imposible recuperar el/los fichero/s) el analista puede obtener mucha información sobre lo que ha ocurrido en el sistema de ficheros examinando los meta-datos presentes en el directorio de entradas y inodes.

Los meta-datos no son asequibles a través de la interfaz de llamadas de sistema del núcleo, por lo tanto no son alterables por las herramientas estándares del sistema operativo (desde el punto de vista forense). La industria forense digital hasta ahora tenía pocos problemas para analizar de forma efectiva sistemas de ficheros de servidores comprometidos, pero este hecho está cambiando.

[Subir]

a. Introducción

Definición: El término de evasión forense (anti-forensics) se refiere a las técnicas de eliminación y/o de ocultación de pruebas para complicar o imposibilitar la efectividad del análisis forense.

El análisis forense informático está ocupando rápidamente un lugar importante en procedimientos de respuesta a incidentes. Hace varios años sólo existía un número limitado de profesionales y aplicaciones capaces de detectar de forma estandarizada los indicios en una investigación forense, incrementándose últimamente la demanda de estos profesionales y el número de herramientas disponibles.

Es asombroso, que a pesar del interés creciente en el área de informática forense, dentro de la industria de seguridad informática, se habla muy poco sobre temas de evasión forense o anti-forensics. Para remediar la carencia de la cobertura, este anexo, basado en la publicación del Phrack, presenta algunas técnicas y estrategias de evasión al análisis forense sobre sistemas de ficheros GNU/Linux y Unix. Están incluidos ejemplos de estas técnicas utilizando como base el sistema de ficheros utilizadas de forma más común - ext2fs.

[Subir]

b. Resumen Sistema de Ficheros ext2fs

Esta sección describirá la teoría del sistema de ficheros de Unix sin centrarse en las implementaciones o distribuciones específicas, cubriendo la estructura interna de meta datos usados para organizar el sistema de ficheros. Los archivos dentro del sistema operativo Unix son streams continuos de bytes de longitud arbitraria usados para la entrada y salida. Este documento se centrara en archivos en su sentido amplio de almacenamiento de datos en el disco y su organización por sistemas de ficheros.

Los datos en un disco con sistema de fichero Unix se dividen normalmente en dos grupos, la información sobre los archivos y los datos dentro de los archivos. La información de organización y estadística de sistema de ficheros (normalmente sólo visible al núcleo) se llama los "meta datos", e incluye los siguientes partes: el super-block, los inodes y los datos de directorio. El contenido almacenado dentro de los ficheros se considera simplemente como "información".

Para crear la imagen abstracta de un fichero el kernel tiene que traducir de forma transparente al usuario los datos almacenados en uno o más sectores del disco duro en una secuencia de bytes. El sistema de ficheros se utiliza para no perder de vista cuales, y en qué orden deben ser agrupados los datos para montar un fichero. Además, los grupos de sectores deben ser guardados de forma separada y ser visibles al sistema operativo de forma individual. Por esa razón existen varios tipos de "meta-datos", siendo cada uno de los tipos responsable de realizar una de las siguientes tareas.

El contenido de un archivo se almacena en bloques de datos que son clusters lógicos de sectores del disco duro. Cuanto más alto es el número de sectores por bloque de datos cuanta más rápida es la velocidad de la E/S del disco, mejorando el rendimiento del sistema de ficheros. Al mismo tiempo, cuanto más grande es el tamaño de bloques de datos más espacio de disco duro se derrocha para los archivos que no terminan en los límites del bloque. Los sistemas de ficheros modernos típicamente tienen el tamaño del bloque de 4096 o 8192 bytes y combaten el despilfarro del disco con "fragmentación" (algo no tratado en este documento).

La parte del disco dedicada a bloques de datos se organiza como un array, y los bloques son referidos por sus offsets dentro de este array. El estado de un bloque particular, es decir "libre" contra "utilizado", se almacena en un bitmap llamado "block bitmap".

Los bloques de datos son ordenados y organizados en archivos por inodes. El inode es la estructura de meta datos que representa archivos visibles al usuario; un inode para cada archivo único. Cada inode contiene un array de punteros del bloque de datos y otra información adicional sobre el archivo. Esa información adicional incluye los parámetros de UID, GID, tamaño, permisos, MAC, y otros ciertos datos. La cantidad de espacio limitada disponible para los inodes significa que el array del bloque puede contener solamente un número reducido de punteros.

Para permitir que los tamaños de los ficheros tengan un tamaño substancial, los inodes emplean "bloques indirectos". Un bloque indirecto actúa como una extensión al array del bloque, almacenando punteros adicionales. Los siguientes bloques indirectos contienen referencias a otros bloques indirectos, y estos otros bloques indirectos contienen referencia a siguientes bloques respectivamente (hasta almacenar el fichero). Los inodes se almacenan en un array llamado inode table, y son referidos por sus índices basados en 0 dentro de esta tabla. El estado de un inode, es decir libre contra utilizado, se almacena en un bitmap llamado de forma original "inode bitmap".

Los archivos, es decir, inodes, están asociados a nombres de los ficheros a través de las estructuras especiales llamadas directory entries y almacenadas dentro de ficheros de directorio. Estas estructuras se almacenan uno al lado del otro dentro del archivo de directorio. Las entradas de directorios tienen siguiente estructura básica:

struct dirent {
  int inode;
  short rec_size;
  short name_len;
  char file_name[NAME_LEN];
  };

El elemento 'inode' de la estructura dirent contiene el número del inode que hace referencia al nombre del fichero, almacenado en la variable 'file_name'. Para ahorrar el espacio, la longitud real del nombre del fichero se registra variable 'name_len' y el espacio restante en el array file_name bajo el índice NAME_LEN y se utilizar por la siguiente estructura de entrada de directorio. El tamaño de un dirent se redondea generalmente hasta aproximadamente 2**2, y este dato se almacena en la variable 'rec_size'. Cuando se quita el enlace del nombre/inode del archivo, el valor del inode se fija a 0 y 'rec_size' del dirent precedente se extiende para abarcar el dirent eliminado. Esto tiene el efecto de almacenar los nombres de archivos suprimidos dentro de ficheros de directorio.

Cada vez que un nombre del archivo se asocia a un inode, el contador interno dentro del inode se incrementa. Asimismo, cada vez que se quita este enlace, el contador se decrementa. Cuando este contador alcanza el valor de 0, no quedan referencias al inode dentro de la estructura del directorio; eso significa que el archivo es borrado. Los archivos que han sido suprimidos pueden tener sus recursos, bloques de los datos, el inode sí mismo liberados con seguridad. Esto se logra modificando los bitmaps respectivos.

Los archivos de directorios se organizan de forma lógica como un árbol que empieza desde el directorio raíz. Este archivo de directorio de raíz se asocia al inode conocido (2) de modo que el núcleo pueda localizarlo, y monta el sistema de ficheros.

Para montar un sistema de ficheros el núcleo necesita conocer el tamaño y la ubicación de meta datos. La primera parte de meta datos - el "super block", se almacena en una ubicación conocida. El super-block contiene la información sobre el número de inodes y de bloques, del tamaño de un bloque, y mucha otra información adicional. Basándose en los datos contenidos dentro del super-block, el kernel puede calcular las localizaciones y los tamaños de la tabla de inodes y de la porción de los datos del disco.

Por razones del rendimiento, ningún sistema de ficheros moderno tiene sólo una tabla del inode y un array del bloque. Al contrario, los inodes y los bloques se organizan en grupos distribuidos a través del disco. Estos grupos normalmente contienen sus bitmaps privados de sus inodes y bloques, así como las copias del super-block para facilitar la recuperación en caso de la pérdida de datos.

En la siguiente sección cubriremos más en detalle la organización del sistema de ficheros ext2fs.

[Subir]

c. Organización de ext2fs

El 'second extended file system' (ext2fs) es un sistema de ficheros estandar de Linux OS. Este capítulo proporcionará detalles necesarios para conocer a fondo la organización de este sistema de ficheros. La lectura de este paper no servirá como sustitución al estudio de las especificaciones de este sistema de ficheros y examen de de los src del kernel y de la librería ext2fs. A continuación está la descripción del sistema de ficheros ext2 empezando por los bloques de datos, inodes y concluyendo con directorios.

Bloques - La unidad básica de un sistema de ficheros es un bloque de datos utilizado para almacenar el contenido de los ficheros. Tipicamente, desde el punto de vista físico y independientemente del sistema de ficheros, la unidad más pequeña de espacio en el disco duro es un sector (512 bytes), pero es muy poco desde el punto de vista del ratio entrada/salida de datos. Para incrementar el rendimiento múltiples sectores están agrupados en un cluster y son considerados como una unidad de almacenamiento de datos - bloque. Un bloque típico puede tener en ext2fs un tamañode 4096 bytes, pero también puede ser de 2048 bytes y incluso 1024 (8, 4 y 2 sectores respectivamente).

Inodes - La segunda parte del sistema de ficheros son inodes - el corazón del sistema de ficheros ext2fs. Los inodes contienen meta-datos sobre cada fichero incluyendo punteros (1) a los bloques de datos asociados, permisos (2) de los ficheros, tamaños (3), propietarios (4), grupos (5) así como mucha otra información útil. El formato de un inode ext2 es el siguiente:

---------------------------------------------------------------------------
  struct ext2_inode {
      __u16 i_mode; /* Modo del Fichero */
      __u16 i_uid; /* UID Propietario */
      __u32 i_size; /* Tamaño en bytes */
      __u32 i_atime; /* Fecha de Acceso */
      __u32 i_ctime; /* Fecha de Creación */
      __u32 i_mtime; /* Fecha de Modificación */
      __u32 i_dtime; /* Fecha Eliminación */
      __u16 i_gid; /* GID Propietario */
      __u16 i_links_count; /* Contador de enlaces */
      __u32 i_blocks; /* Contador de bloques */
      __u32 i_flags; /* Marcadores Fichero */
  union {
      struct {
       __u32 l_i_reserved1;
     } linux1;

   struct {
       __u32 h_i_translator;
     } hurd1;

      struct {
        __u32 m_i_reserved1;
     } masix1;
    } osd1; /* Información dependiente del Sistema Operativo 1 */

      __u32 i_block[EXT2_N_BLOCKS];/* Punteros a los Bloques */
      __u32 i_version; /* Versión de fichero NFS */
      __u32 i_file_acl; /* Fichero ACL */
      __u32 i_dir_acl; /* Directorio ACL */
      __u32 i_faddr; /* Dirección del fragmente */

    union {
     struct {
      __u8 l_i_frag; /* Número Fragmento */
      __u8 l_i_fsize; /* Tamaño Fragmento */
      __u16 i_pad1;
      __u32 l_i_reserved2[2];
     } linux2;

    struct {
      __u8 h_i_frag; /* Número Fragmento */
      __u8 h_i_fsize; /* Tamaño Fragmento */
      __u16 h_i_mode_high;
      __u16 h_i_uid_high;
      __u16 h_i_gid_high;
      __u32 h_i_author;
    } hurd2;
 
    struct {
      __u8 m_i_frag; /* Número Fragmento */
      __u8 m_i_fsize; /* Tamaño Fragmento */
      __u16 m_pad1;
      __u32 m_i_reserved2[2];
    } masix2;

 } osd2; /* Información dependiente del Sistema Operativo 2 */
};

---------------------------------------------------------------------------

Existen dos uniones porque ext2fs ha sido diseñado para ser utilizado por sistemas operativas ligeramente diferentes (implementaciones, distros). Aparte de las cosas puntuales los únicos elementos de la unión que importan son estructuras linux1 y linux2, el resto de las estructuras simplemente ahora pueden ser consideradas como facilidades adicionales ya que en la última implementación ext2fs se ignoran. El uso del resto de los valores de un inode están explicadas a continuación:

• i_mode - El modo del fichero, se refiere a los permisos octales de cualquier sistema GNU/Linux.
• i_uid - Este elemento contiene el UID del propietario del fichero.
• i_size - El tamaño de los ficheros en bytes. El tamaño máximo de un fichero puede ser de 4Gb por el tipo de variable unsigned int de 32 bit. El soporte para los tamaños de ficheros de 64 bits ha sido inventado creando una definición #define i_size_high i_dir_acl
• i_atime - La fecha de último acceso al fichero. Todos los valores temporales se expresan en el modo estandar de Unix de contar el tiempo - en segundos desde el inicio del siglo.
• i_ctime - La fecha de creación del fichero.
• i_mtime - La fecha de la última modificación del fichero.
• i_dtime - Fecha eliminación del fichero. Si el fichero todavía no ha sido eliminado el valor de este registro contiene 0x00000000.
• i_gid - El GID del fichero.
• i_links_count - Este registro contiene el contador de veces que el fichero se referencia en el sistema de ficheros de nivel superior. Es decir que cada hard link al fichero incrementa este contador. Cuando el último enlace del sistema de ficheros ha sido eliminado el valor del registro es 0, significa que el fichero ha sido eliminado. Los bloques asociados al inode están marcados en el bitmap como libres.
• i_blocks - El número de bloques referenciados por el inode. Este bloque no incluye bloques indirectos, sólo aquellos que contienen el contenido real del fichero.
• i_flags - Los atrubutos adicionales del ext2fs consisten en valor único o una combinación de los siguientes valores:
  

---------------------------------------------------------------------------
  #define EXT2_SECRM_FL 0x00000001 /* Borrado Seguro */
  #define EXT2_UNRM_FL 0x00000002 /* Recuperación */
  #define EXT2_COMPR_FL 0x00000004 /* Compresión del Fichero */
  #define EXT2_SYNC_FL 0x00000008 /* Actualización Sincronizada */
  #define EXT2_IMMUTABLE_FL 0x00000010 /* Fichero inmutable */
  #define EXT2_APPEND_FL 0x00000020 /* Únicamente añadir contenido */
  #define EXT2_NODUMP_FL 0x00000040 /* No permitir el dump del fichero */
  #define EXT2_NOATIME_FL 0x00000080 /* No actualizar el registro atime */
  /* Reservado para el uso de compresión de datos... */
  #define EXT2_DIRTY_FL 0x00000100
  #define EXT2_COMPRBLK_FL 0x00000200 /* Comprimir clusters */
  #define EXT2_NOCOMP_FL 0x00000400 /* No realizar compresión */
  #define EXT2_ECOMPR_FL 0x00000800 /* Error de compresión */
  /* Fin marcadores de compresión --- algunos no se utilizan */
  #define EXT2_BTREE_FL 0x00001000 /* formato directorio btree */
  #define EXT2_RESERVED_FL 0x80000000 /* reservado para la librería ext2 */
---------------------------------------------------------------------------

• i_block[] - Un array de punteros de bloques. Hay 15 elementos en el array, los primeros 12 elementos son punteros directos a bloques, estos contiene el contenido real de los ficheros. El puntero número 13 contiene la referencia al bloque que sirve como extensión para el array. Este bloque es un bloque indirecto, y los punteros que contiene apuntan al resto de los bloques directos adicionales. El elemento 14 del array contiene una referencia a otro array que incluye un array de punteros a los bloques indirectos. Este elemento es un bloque indirecto doble, mientras que el último elemento del array contiene referencia a los bloques indirectos dobles:
  

---------------------------------------------------------------------------
  #define EXT2_NDIR_BLOCKS 12
  #define EXT2_IND_BLOCK EXT2_NDIR_BLOCKS
  #define EXT2_DIND_BLOCK (EXT2_IND_BLOCK + 1)
  #define EXT2_TIND_BLOCK (EXT2_DIND_BLOCK + 1)
  #define EXT2_N_BLOCKS (EXT2_TIND_BLOCK + 1)
---------------------------------------------------------------------------

• i_version - La versión del fichero. No se utiliza actualmente.
• i_file_acl - Un puntero a una lista ACL. En la versión ext2fs no se utiliza ya que no exiten listas ACL, puede que se utilice en las siguientes versiones del sistema de ficheros.
• i_dir_acl - Un puntero a una lista ACL. En la versión ext2fs no se utiliza como ACL sino como el valor de i_size_high. Estos son 32 bit del de espacio adicional para el tamaño del fichero. Permite tene el tamaño del fichero a 64 bits unsigned int.
• i_faddr - Dirección del fragmeto. Los fragmentos no se utilizan en ext2fs por lo tanto el valor de este registro es 0.

Algunos inodes tienen un significado especial dentro del sistema de ficheros.

---------------------------------------------------------------------------
  #define EXT2_BAD_INO 1 /* Inode de bloques dañados */
  #define EXT2_ROOT_INO 2 /* Inode de Raiz */
  #define EXT2_ACL_IDX_INO 3 /* Inode ACL */
  #define EXT2_ACL_DATA_INO 4 /* Inode ACL */
  #define EXT2_BOOT_LOADER_INO 5 /* Inode del boot loader */
  #define EXT2_UNDEL_DIR_INO 6 /* Inode de recuperación de un directorio borrado */
---------------------------------------------------------------------------

El inode de bloques dañados contiene punteros a los bloques de datos que contienen sectores dañados en el disco duro. El inode raiz es el directorio raiz que contiene el inicio del todo el arbol de directorio. El resto de los inodes no se utilizan normalmente en sistemas de producción. El primer inode utilizado para los ficheros de usuarios es el 11. Este inode es el directorio "lost+found", creado por la herramienta mkfs.

Superblock - El superblock es el único medio básico para proporcionarl al kernel la información del estado del sistema de ficheros. Este bloque indica el número de inodes, bloques, grupos y además mucha otra información adicional. Los elementos dentro del superblock cambian más frecuentemente que la información sobre inodes o datos del grupo porque libext2fs añade más funcionalidades a ext2fs que puede no ser implementado dentro del kernel. El formato que examinamos es de e2fsprogs-1.19. El super block es de 1024 bytes, y su offset está a 1024 bytes del inicio de una partición.

El formato del super block es el siguiente:

---------------------------------------------------------------------------
  struct ext2fs_sb {
  __u32 s_inodes_count; /* Contador de inodes */
  __u32 s_blocks_count; /* Contador de bloques */
  __u32 s_r_blocks_count; /* Contador bloques reservados */
  __u32 s_free_blocks_count; /* Contador bloques libres */
  __u32 s_free_inodes_count; /* Contador inodes libres */
  __u32 s_first_data_block; /* Primer bloque de datos */
  __u32 s_log_block_size; /* Tamaño del bloque */
  __s32 s_log_frag_size; /* Tamaño fragmento */
  __u32 s_blocks_per_group; /* # Bloques por grupo */
  __u32 s_frags_per_group; /* # Fragmentos por grupo */
  __u32 s_inodes_per_group; /* # Inodes por grupo */
  __u32 s_mtime; /* Fecha de montura */
  __u32 s_wtime; /* Fecha escritura */
  __u16 s_mnt_count; /* Contador de montura */
  __s16 s_max_mnt_count; /* Contador número máximo monturas */
  __u16 s_magic; /* Firma mágica */
  __u16 s_state; /* Estado sistema de ficheros */
  __u16 s_errors; /* Comportamiento al encontrar errores */
  __u16 s_minor_rev_level; /* Nivel de revisión - menor */
  __u32 s_lastcheck; /* Fecha de última comprobación */
  __u32 s_checkinterval; /* Periodo máximo entre comprobaciones */
  __u32 s_creator_os; /* Sistema Operativo */
  __u32 s_rev_level; /* Nivel de Revisión */
  __u16 s_def_resuid; /* UID por defecto para bloques reservados */
  __u16 s_def_resgid; /* GID por defecto para bloques reservados */
  /*
  * Estos campos son para superblocks de EXT2_DYNAMIC_REV.
  *
  * Nota informativa: la diferencia entre las carácteristicas compatibles y
  * las incompatibles es que si dentro de las carácteristicas no soportadas
  * un valor está marcado y kernel no lo reconoce, rechazará la montura del
  * del sistema de ficheros.
  *
  */
  __u32 s_first_ino; /* Primer inode no reservado */
  __u16 s_inode_size; /* Tamaño estructura inode */
  __u16 s_block_group_nr; /* grupo de bloques # de este superblock */
  __u32 s_feature_compat; /* características compatibles */
  __u32 s_feature_incompat; /* características incompatibles */
  __u32 s_feature_ro_compat; /* carácteristicas de solo lectura */
  __u8 s_uuid[16]; /* Uuid de 128-bit del volumen */
  char s_volume_name[16]; /* nombre volumen */
  char s_last_mounted[64]; /* último punto de montura */
  __u32 s_algorithm_usage_bitmap; /* para compresión */
  /*
  * Sugerencias de rendimiento. Si el registro EXT2_FEATURE_COMPAT_DIR_PREALLOC
  * está activado, los directorios se reservan.
  */
  __u8 s_prealloc_blocks; /* Número de bloques intentar reservar */
  __u8 s_prealloc_dir_blocks; /* Número bloques reservar para directorios */
  __u16 s_padding1;
  /*
  * Soporte para journaling.
  */
  __u8 s_journal_uuid[16]; /* uuid del superblock del journal */
  __u32 s_journal_inum; /* número inode del fichero journal */
  __u32 s_journal_dev; /* número de dispositivo del fichero journal */
  __u32 s_last_orphan; /* inicio de la lista de inodes a eliminar */
 
  __u32 s_reserved[197]; /* Marca de finalización del bloque */
  };
---------------------------------------------------------------------------

• s_inodes_count - Número total de inodes dentro del sistema de ficheros.
• s_blocks_count - Número total de bloques dentro del sistema de ficheros.
• s_r_blocks_count - Número de bloques reservados para el usuario root. En caso de que el sistema de ficheros se llene, éstos evitarán que los uauarios puedan hacer que el sistema de ficheros vuelva inestable.
• s_free_blocks_count - Número de bloques sin utilizar. Éste número se actualiza constantemente ya que cada momento los bloques se liberan y se ocupan.
• s_free_inodes_count - Número de inodes sin utilizar. Este valor se actualiza constantemente ya que cada momento los bloques se liberan y se ocupan de nuevo.
• s_first_data_block - Puntero al primer bloque de datos después de los bloques que sirven para almacenar tablas de inodes, bitmaps y grupos. El valor puede ser 0 o alternativamente el valor correcto.
• s_log_block_size - Tamaño del bloque. El valor se almacena de forma desplazada. El valor a desplazar es 1024, por lo tanto para obtener el tamaño del bloque real debemos utilizar la fórmula: bs = 1024 <<>
• s_log_frag_size - Tamaño del fragmento. Este valor se almacena de forma desplazada. Fragmentos no se utilizan en ext2fs por lo tanto el valor de este registro se ignora.
• s_blocks_per_group - Número bloques en un grupo.
• s_frags_per_group - Número de fragmentos en el grupo.
• s_inodes_per_group - Número de inodes en el grupo.
• s_mtime - Última fecha de montura del sistema de ficheros.
• s_wtime - La fecha de última escritura en el sistema de ficheros.
• s_mnt_count - Número de veces el sistema de ficheros fue montada.
• s_max_mnt_count - Número máximo de veces un sistema de ficheros puede ser montada antes de realizar un fsck. El valor por defecto es 20.
• s_magic - Número mágico del sistema de ficheros: 0xEF53.
• s_state - Estado del sistema de ficheros, puede ser clean o dirty. Los siguientes son los flags:
  

--------------------------------------------------------------------------
  #define EXT2_VALID_FS 0x0001 /* Desmontado correctamente */
  #define EXT2_ERROR_FS 0x0002 /* Errores detectados */
---------------------------------------------------------------------------

• s_errors - Cuando un error se detecta el comportamiento a tener en cuenta. Los siguientes son los valores:

---------------------------------------------------------------------------
  #define EXT2_ERRORS_CONTINUE 1 /* Continuar ejecución */
  #define EXT2_ERRORS_RO 2 /* Remontar el sistema de ficheros en solo lectura */
  #define EXT2_ERRORS_PANIC 3 /* Generar Pánico */
  #define EXT2_ERRORS_DEFAULT EXT2_ERRORS_CONTINUE
---------------------------------------------------------------------------

• s_minor_rev_level - Número menor de la revisión de la revisión ext2fs. El valor puede ser ignorado perfectamente.
• s_lastcheck - La fecha de la última verificación del sistema de ficheros fsck, almacenada en formato estandarizado de Unix.
• s_checkinterval - Periodo máximo de tiempo entre verificaciones de fsck. El sistema de ficheros tiene que ser verificada si el valor de este registro o del s_max_mnt_count se ha excedido.
• s_creator_os - El sistema operativo creador del sistema de ficheros. Los valores pueden ser los siguientes:

---------------------------------------------------------------------------
  #define EXT2_OS_LINUX 0
  #define EXT2_OS_HURD 1
  #define EXT2_OS_MASIX 2
  #define EXT2_OS_FREEBSD 3
  #define EXT2_OS_LITES 4
---------------------------------------------------------------------------

• s_rev_level - Revisión del sistema de ficheros. La única diferencia en valores tiene que ver con el tamaño de inodes. La versión actual de ext2 utiliza el tamaño de 128 bytes de inode. Los siguientes son los valores válidos para el registro:

---------------------------------------------------------------------------
  #define EXT2_GOOD_OLD_REV 0 /* Formato original */
  #define EXT2_DYNAMIC_REV 1 /* Formato V2 con tamaño de inodes dinámico */
  #define EXT2_CURRENT_REV EXT2_GOOD_OLD_REV
---------------------------------------------------------------------------

• s_def_resuid - UID por defecto de los bloques reservados. El valor por defecto es 0.
• s_def_resgid - GID por defecto para bloques reservados. El valor por defecto es 0.
• s_first_ino - El primer inode no reservado. Inodes menores de 10 están reservados, entonces el primer número inode válido es 11. Casi siempre el inode está asociado con la entrada "lost+found".
• s_inode_size - Tamaño del inode. El tamaño actual es 128 bytes.
• s_block_group_nr - El grupo de bloque dónde se almacena el superblock.
• s_feature_compat - Valores de carácteristicas soportadas por ext2fs. Los siguientes son los valores:
  

---------------------------------------------------------------------------
  #define EXT2_FEATURE_COMPAT_DIR_PREALLOC 0x0001
---------------------------------------------------------------------------

• s_feature_incompat - Valores de carácteristicas no soportadas. Las siguientes son las incompatibilidades aceptadas.
  

---------------------------------------------------------------------------
  #define EXT2_FEATURE_INCOMPAT_COMPRESSION 0x0001
  #define EXT2_FEATURE_INCOMPAT_FILETYPE 0x0002
---------------------------------------------------------------------------

• s_feature_ro_compat - Valores de compatibilidad soportadas en modo solo lectura. Los siguientes son los valores posibles:

---------------------------------------------------------------------------
  #define EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER 0x0001
  #define EXT2_FEATURE_RO_COMPAT_LARGE_FILE 0x0002
  #define EXT2_FEATURE_RO_COMPAT_BTREE_DIR 0x0004
---------------------------------------------------------------------------

• s_uuid - ID único de éste sistema de ficheros particular de tipo ext2fs.
• s_volume_name - Nombre del volumen. Este registro no tiene mucha importancia.
• s_last_mounted - El punto de montura que fue utilizado la última vez que el sistema de ficheros fue montado.
• s_algorithm_usage_bitmap - No dispongo de datos del uso de este registro, pero no presenta ningún interes en nuestro whitepaper.
• s_prealloc_blocks - Número de bloques a intentar reservar para un fichero.
• s_prealloc_dir_blocks - Número de bloques a intentar reservar para un fichero de directorio.
• s_padding1 - Padding.
• s_reserverd[] - Padding para rellenar el superblock de más de 1024 bytes.

Grupos- Grupos Ext2fs se utilizan para organizar los clusters de bloques y inodes. Cada uno de los grupos contiene un bitmap libre de inodes y un inode libre. De forma adicional cada grupo tiene una copia del superblock para ayudar en la prevensión de la pérdida de datos. Descriptores de grupos están almacenados en el bloque después del super block, y luego a continuación están los bitmaps y tablas de inodes. Luego vienen los bloques de datos.

El formato de los descriptores del grupo son siguientes:

-----------------------------------------------------------------------------
  struct ext2_group_desc
  {
  __u32 bg_block_bitmap; /* Bloque del bloque bitmap */
  __u32 bg_inode_bitmap; /* Inodes del bloque bitmap */
  __u32 bg_inode_table; /* Bloque de tablas inode */
  __u16 bg_free_blocks_count; /* Contador de libres bloques */
  __u16 bg_free_inodes_count; /* Contador de libres inodes */
  __u16 bg_used_dirs_count; /* Contador de directorios */
  __u16 bg_pad;
  __u32 bg_reserved[3];
  };
-----------------------------------------------------------------------------

• bg_block_bitmap - Puntero del bloque que lleva al bitmap. Los bits en el bitmap sirven para indicar si está ocupado o libre.
• bg_inode_bitmap - Puntero del bloque que lleva al bitmap de los inodes. Los bits en el bitmap sirven para indicar si está ocupado o libre.
• bg_inode_table - Puntero del bloque que lleva al inicio de la tabla de los inodes.
• bg_free_blocks_count - El número de bloques dentro del grupo que están disponibles para el uso.
• bg_free_inodes_count - El número de inodes dentro del grupo disponibles para el uso.
• bg_used_dirs_count - El número de inodes del grupo utilizados para ficheros de directorio.
• bg_pad - Padding.
• pg_reserved[] - Padding.

Directorios - Directorios se utilizan para organizar ficheros a nivel del sistema operativo. El contenido del fichero de directorio es un array de estructuras de directorios. Cada fichero de directorio contiene el nombre del fichero dentro del mismo directorio y el inodel del fichero.

El formato de entradas de directorios en ext2 es el siguiente:

---------------------------------------------------------------------------
  struct ext2_dir_entry_2 {
    __u32 inode; /* Número Inode */
    __u16 rec_len; /* Tamaño de la entrada */
  __u8 name_len; /* Tamaño del nombre */
    __u8 file_type;
    char name[EXT2_NAME_LEN]; /* Nombre del fichero */
  };
---------------------------------------------------------------------------

• inode - El número inode del fichero dentro del directorio. Si el fichero ha sido eliminado, el número inode debe ser 0.
• rec_len - El tamaño de la entrada de directorio. Como el nombre puede ser cualquier cadena de más de 255 bytes, eso permite un uso de espacio más eficiente en el fichero de directorio.
• name_len - El tamaño del nombre del fichero. Puede ser hasta 255 bytes.
• file_type - El tipo de fichero, por ejemplo symlink, dispositivo, etc... Los siguientes son los valores válidos:

---------------------------------------------------------------------------
  #define EXT2_FT_UNKNOWN 0
  #define EXT2_FT_REG_FILE 1
  #define EXT2_FT_DIR 2
  #define EXT2_FT_CHRDEV 3
  #define EXT2_FT_BLKDEV 4
  #define EXT2_FT_FIFO 5
  #define EXT2_FT_SOCK 6
  #define EXT2_FT_SYMLINK 7
---------------------------------------------------------------------------

Eso concluye la descripción del nivel físico del sistema de ficheros ext2fs.

[Subir]

d. Técnicas de Evasión

En el capítulo anterior se trataron los conceptos básicos de análisis forense y también se hizo una mención indirecta de algunos métodos de subversión del análisis, mientras que, de aquí para adelante, nos centraremos en el tema de evasión forense.

Evasión forense es un intento de mitigar la cantidad y calidad de información un investigador puede encontrar. Cada uno de los pasos del análisis puede ser explotado y subvertido. Este white paper se centra principalmente en la subversión de la fase de recolección de datos del sistema de ficheros durante la investigación.

Los mecanismos principales para alcanzar este objetivo son: técnicas de destrucción (1) y ocultación (2) de datos. A lo largo del white paper se hará referencia a la explotación de algunas vulnerabilidades del proceso de análisis y recolección de datos.

El estudio forense es extremadamente vulnerable a subversión cuando la información, en su estado básico (raw data image), se convierte en pruebas (por ejemplo emails). Cada paso de la conversión es vulnerable por la complejidad y procesos abstractos que se realizan sobre los datos. Cuando se trabaja con los datos cualquier despiste puede resultar en pérdida de detalles y los detalles en realidad son las partes más importantes del rompecabezas. Cuando los detalles desaparecen, se crean vacíos importantes que pueden ser explotados. El despiste no es la única fuente de errores, sino también los fallos en las herramientas forenses frecuentemente utilizadas. Bugs en las implementaciones de estas herramientas proporcionan mejores oportunidades de explotación para agentes evasivos.

Pocas cosas pueden ser hechas de forma remota por un agente evasivo a fin de prevenir que el sistema de ficheros se salve, asimismo nos centraremos en la siguiente fase del análisis forense - prevención de recogida de pruebas del sistema de ficheros. Se puede frenar la recogida de información a través de destrucción o ocultación de la misma. De estos dos mecanismos la destrucción de datos es la más fiable ya que no deja ninguna pista el investigador puede recoger y analizar. Esta técnica proporciona medios para la eliminación segura de huellas y pruebas existentes para cubrirse las huellas del atacante de forma más efectiva.

Ocultación de información sólo es efectiva cuando el analista no sabe dónde buscarla, siendo la integridad del medio de almacenamiento imposible de garantizar a largo plazo. Por esa razón, la ocultación de datos debe ser combinada con ataques a las fases de estudio de datos recogidos (por ejemplo formatos propietarios de ficheros) y de examen (por ejemplo cifrado). Técnicas de ocultación son útiles en caso de que los datos se tengan que guardar durante un periodo esencial de tiempo (por ejemplo fotos artísticas de señoritas posando).

Los dos toolkits incluidos en la siguiente sección del white paper proporcionan una demostración de las dos técnicas de evasión forense: destrucción de datos y ocultación. Utilizaremos estos toolkits para dar ejemplos detallados de destrucción y ocultación de datos a continuación. La primera técnica que examinaremos en detalle es la ocultación.

[Subir]

e. Herramientas Evasivas

Aquellos hackers con conocimientos superiores que rozan la frontera de imaginación de los wannabes no dejan nada a la suerte y gracias a ellos han empezado existir series de herramientas de evasión o de encubrimiento de huellas. Si nos hubieran dicho por los años 1999 que aparte del zapper clásico existían herramientas que permitían borrar el rastro o por lo menos hacerlo tan confuso para el investigador, nos sorprenderíamos, pero no tanto como se sorprenden cada día miles de administradores de servidores cuando saben que hubo compromiso pero no encuentran huellas con las más avanzadas técnicas de investigación. En esta sección del whitepaper hablaremos sobre las herramientas más avanzadas y secretas que existen para encubrir huellas y daremos pistas de como detectar su uso.

[Subir]

e1. RuneFS Tool

Una de las herramientas más comúnes para el análisis forense del sistema de ficheros Unix es "The Coroner's Toolkit" desarrollada por Dan Farmer y Wietse Venema. A pesar de ser casí la única aplicación en la que han confiado los analistas forenses durante años, la herramienta podría ser mejorada a lo largo de años y los fallos que ocurrían en las primeras versiones siguien produciendose hoy en día. El sistema de ficheros más utilizada de Unix tiene un error que permite al atacante almacenar datos aleatorios en ubicaciones que TCT no puede ni localizar ni examinar.

El TCT falla a la hora de recrear las especificaciones de sistema de ficheros a la hora de analizar implementaciones de Berkley Fast File System (FFS o UFS), y Second Extended File system (ext2fs). El fallo consiste en asumir que ningún bloque de datos puede ser asignado al inode antes del root inode, fallando también a tener en cuenta los inodes de los bloques dañados.

Historicamente, el inode de bloques dañados fue utilizado para referenciar bloques que contienen sectores dañados en el disco duro, previniendo que estos bloques estén utilizados por el sistema operativo. El FFS dejó de utilizar este método, lo que evita la explotación de este error, pero ext2fs siguie utilizando la misma técnica de marcación.

La realización del ataque de ocultación al sistema de ficheros significa para un intruso la manipulación del sistema de ficheros dentro de las especificaciones implementadas de la herramienta de verificación de integridad del FS: fsck. Sería de interés saber que pocos investigadores han pensado en utilizar un fsck para detectarlo y intrusos incautos pueden haber sobrepasado el marco de seguridad de las especificaciones.

La versión de esa herramienta diseñada para funcionar con el sistema de ficheros ext2 todavía utiliza los inodes de bloques dañados para estos sectores en el disco, por lo tanto las especificaciones permiten tener un número ilimitado de bloques dañados, y este hecho no levanta sospechas a la hora de realizar un chequeo del disco. Desgraciadamente la parte del código de reconocimiento del sistema de ficheros en TCT no realiza verificación del inode de bloques dañados ya que no lo considera de interés alguno. El código de TCT así como de TASK realiza la siguiente verificación errónea:

/*
* Verificación de integridad
*/

if (inum <> ext2fs->fs.s_inodes_count)
             error("invalid inode number: %lu", (ULONG) inum);

El primer inode que puede ser reservado en un sistema de ficheros ext2 es de hecho el inode de bloques dañados (inode 1) y no el inode de raíz (inode 2). Por razones de fallos en implementación es posible almacenar información en bloques marcados como bloques dañados, es decir referenciados por el inode de bloques dañados. Usando esa técnica se puede almacenar allí la información y tenerla oculta de cualquier analista que usa herramientas como TCT o TASK. Para ilustrar la gravedad de este tipo de ataques a continuación están algunos ejemplos que muestran como crear un espacio oculto, copiar allí la información y sacarla de allí cuando se necesite (ver también el código de la aplicación RuneFS adjunto).

Ejemplo de creación de espacio oculto:

# df -k /dev/hda6
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda6 1011928 20 960504 1% /mnt


# ./bin/mkrune -v /dev/hda6
+++ bb_blk +++
  bb_blk->start = 33275
  bb_blk->end = 65535
  bb_blk->group = 1
  bb_blk->size = 32261
+++
rune size: 126M
# df -k /dev/hda6
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda6 1011928 129196 831328 14% /mnt
# e2fsck -f /dev/hda6
e2fsck 1.26 (3-Feb-2002)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hda6: 11/128768 files (0.0% non-contiguous), 36349/257032 blocks
#

Este ejemplo demuestra la reserva de 126 mb. para el espacio oculto en el disco duro, demostrando que la pérdida de este espacio se queda registrada por el núcleo. Es evidente que el espacio oculto no viola las especificaciones ext2, por lo tanto fsck no se queja.

Ejemplo de uso del espacio oculto:

# cat readme.tools | ./bin/runewr /dev/hda6
# ./bin/runerd /dev/hda6 > f
# diff f readme.tools
# 

Este segundo ejemplo muestra como datos pueden ser insertados y extraídos del espacio de almacenamiento oculto sin pérdida de datos. Mientras que este ejemplo no entra en detalle de técnicas de almacenamiento en el espacio oculto, es suficiente para presentar el uso de RuneFS.

Ejemplo de mala implementación de reconocimiento de sistema de ficheros ext2fs.

# ./icat /dev/hda6 1
/icat: invalid inode number: 1
#

Este ultimo ejemplo ilustra como un analista forense es incapaz de localizar el almacenamiento oculto con herramientas TCT. Es evidente que pueden haber muchos problemas cuando se examina el sistema de ficheros con herramientas con fallos.

Aunque los últimos ejemplos son realimente asombrosos, existen ciertos problemas con RuneFS. Esa versión de RuneFS que viene a continuación es bastante anticuada; Gnugq, el redactor del Phrack en que me baso para cumplimentar mi white paper, la ha escrito en Noviembre del año 2000. La versión actual de RuneFS tiene soporte para reserva de espacio dinámica, soporta cifrado y estructura de directorios y puede llegar a ser hasta 2 Gb. Afortunadamente el software de Gnugq es privado y no se distribuye al público.

Al fin y al cabo el uso la última versión de RuneFS tiene una mayor desventaja ya que el secreto y la técnica de implementación ya es de dominio público (obviamente, por el número de lectores Phrack, y espero de éste artículo). Esta desventaja subraya que técnicas de ocultación de datos se encuentran bastante anticuadas y no serán útiles si el analista sabe dónde buscar la información. La ocultación sólo puede ser utilizada en combinación con métodos de ofuscación y/o cifrado de datos.

[Subir]

e2. The Defilers Toolkit

El sistema de ficheros (supuestamente) contiene el seguimiento completo de operaciones de entrada y salida de datos del equipo. El analista forense involucrado en la investigación intenta extraer esa información para examinarla.

Aparte de las dificultades impuestas por los fallos en las implementaciones de herramientas forenses comúnmente utilizadas, el analista lo tendrá mucho más difícil todavía extrayendo la información del sistema de ficheros en caso de que simplemente no esté allí.

Esta sección cubrirá técnicas y herramientas utilizadas por los intrusos para eliminar cualquier evidencia de compromiso en el sistema de ficheros. Estas metodologías han sido reunidas en la aplicación “The Defiler’s Toolkit (TDT)” que puede ser descargada al final del artículo.

La mayor complicación con la reunión de pruebas es que deben estar allí para recogerlas. Los datos no existentes, obviamente, no pueden ser recogidos, siendo por lo tanto imposible sin estos datos seguir con la investigación.

La limpieza del sistema de ficheros es una de las prácticas de evasión utilizadas por los intrusos con un nivel alto de conocimientos. El resultado de la aplicación de ésta metodología resulta en la eliminación definitiva de las pruebas de borrado de ficheros existidos anteriormente. The Defiler’s Toolkit proporciona herramientas para eliminar huellas del sistema de ficheros con precisión quirúrgica, erradicando de forma selectiva la información que puede ser utilizada posiblemente como prueba. Utilizando este juego de herramientas el intruso puede frustrar desde el principio toda la investigación.

Dentro del sistema de ficheros Unix todos los siguientes elementos pueden contener pruebas de las actividades del intruso:

• Inodes
• Entradas de Directorio
• Bloques de Datos

Desgraciadamente las herramientas más avanzadas de eliminación de datos borran solo el contenido de bloques de datos, dejando intactos las entradas de directorio y inodes. Junto con este white-paper viene una versión del toolkit capaz de realizar una limpieza selectiva del disco duro. TDT consiste de dos aplicaciones: necrofile y klismafile que conjuntamente hacen un trabajo perfecto de eliminación segura de existencia de fichero. El objetivo de cada una de esas aplicaciones será descrito de forma individual a continuación.

[Subir]

Necrofile Tool

Necrofile es una herramienta de detección y eliminación segura de inodes “borrados”. La aplicación puede ser utilizada para:

• Localizar a todos los inodes que cumplen con un criterio de fecha de eliminación.
• Realizar una limpieza exhaustiva dejando los inodes limpios.

Los inodes “vírgenes” no proporcionan ninguna información al investigador sobre la existencia o borrado del fichero manipulado por el intruso.

Necrofile también incluye la funcionalidad de erradicar de forma segura el contenido de los bloques de datos a los que hace referencia el inode. Sin embargo, en este momento no es conveniente utilizar esa funcionalidad por los conflictos con los procesos de lectura y escritura del disco controlados por el núcleo.

Al ejecutar la aplicación se le debe proporcionar un sistema de ficheros donde realizar la búsqueda y informar de como se debe proceder con los inodes “borrados” localizados en la partición. Necrofile verifica de forma reiterada todos los inodes del sistema de ficheros especificada y verificando el estado de cada uno de ellos. En caso de que la aplicación haya sido arrancada con la opción de limpieza Necrofile limpia el inode “borrado” y lo inserta en la tabla de inodes en su estado virgen.

[Subir]

Ejemplo de localización de inodes borrados utilizando TCT:

   # ./ils /dev/hda6
  class|host|device|start_time
  ils|XXX|/dev/hda6|1026771982
  st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_dtime|st_mode|\
  st_nlink|st_size|st_block0|st_block1
  12|f|0|0|1026771841|1026771796|1026771958|1026771958|100644|0|86|545|0
  13|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|546|0
  14|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|547|0
  15|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|548|0
  16|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|549|0
  17|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|550|0
  18|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|551|0
  19|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|552|0
  20|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|553|0
  21|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|554|0
  22|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|555|0
  23|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|556|0
  24|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|557|0
  25|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|558|0
  26|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|559|0
  27|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|560|0
  28|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|561|0
  29|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|562|0
  30|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|563|0
  31|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|564|0
  32|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|565|0
  33|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|566|0
  34|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|567|0
  35|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|568|0
  36|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|569|0
  37|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|570|0
  #

Ejemplo de utilización de Necrofile para localizar y limpiar los inodes borrados.

   # ./necrofile -v -v -v -v /dev/hda6
  Scrubbing device: /dev/hda6
  12 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  13 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  14 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  15 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  16 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  17 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  18 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  19 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  20 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  21 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  22 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  23 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  24 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  25 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  26 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  27 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  28 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  29 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  30 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  31 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  32 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  33 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  34 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  35 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  36 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
  37 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f

   #

Ejemplo de como TCT no es capaz de localizar ningún inode borrado:

   # ./ils /dev/hda6
  class|host|device|start_time
  ils|XXX|/dev/hda6|1026772140
  st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_dtime|st_mode|\
  st_nlink|st_size|st_block0|st_block1
  #

Se necesita poco comentario para acompañar los ejemplos. La utilidad “ils” que forma parte de TCT muestra los inodes borrados para su posible recuperación.

Necrofile se ejecuta en el modo más detallado soportado por la aplicación, para demostrar como se localiza y limpia los mismos inodes encontrados por ils.

El uso de esta herramienta puede ser más efectivo si se utiliza para eliminar las huellas dejadas en los periodos determinados de tiempo, de esta manera los forenses tienen dificultades detectando la limpieza intencionada de los inodes.

En caso de que Necrofile se utilice para limpiar todos los inodes “borrados” del disco y el forense encuentre que no hay ningún inode “borrado” se confirmará su sospecha del compromiso y eliminación intencionada de pruebas por un hacker.

Después de que los inodes “borrados” hayan sido convertidos en inodes “vírgenes” ils no es capaz de localizarles.

Una vez los meta-datos que forman parte del inode han sido limpiados con éxito el intruso procede a barrer sus huellas en otros lugares del sistema de ficheros - las entradas de directorios.

Klismafile Tool

Klismafile permite borrar de forma segura las entradas de directorio borradas. Cuando el nombre del fichero o el enlace inode se termina, el contenido de la entrada de directorio no se sobrescribe, sino se añade al espacio de la entrada precedente. Klismafile realizará una búsqueda en el fichero de directorio para localizar las entradas eliminadas y las sobrescribirá. Las expresiones regulares pueden ser utilizadas para limitar el número de entradas quitadas.

Para ejecutar la herramienta se debe proporcionarla con un directorio dónde realizar la búsqueda, y también puede realizar búsqueda recursiva en todos los directorios que encuentre.

Klismafile intentará localizar dirents eliminados y una vez encontrados los comparará con la expresión regular ‘file_name’ proporcionada como argumento del programa. Por defecto el ‘file_name’ es ‘*’. La utilidad sobrescribirá los dirents que coinciden con la expresión regular con ceros.

Klismafile no es una herramienta totalmente segura, y puede ser detectada su utilización observando que la entrada del directorio precedente al eliminado tiene el campo rec_len mayor de lo que debería ser, por lo tanto se puede asumir que herramientas como Klismafile o similares han manipulado el contenido del fichero de directorio. Actualmente no existen herramientas para realizar esa detección de forma automática, pero no tardarán en aparecer.

Ejemplo: la utilidad fls proporciona el listado de entradas de directorio.

# ./fls -d /dev/hda6 2
  ? * 0: a
  ? * 0: b
  ? * 0: c
  ? * 0: d
  ? * 0: e
  ? * 0: f
  ? * 0: g
  ? * 0: h
  ? * 0: i
  ? * 0: j
  ? * 0: k
  ? * 0: l
  ? * 0: m
  ? * 0: n
  ? * 0: o
  ? * 0: p
  ? * 0: q
  ? * 0: r
  ? * 0: s
  ? * 0: t
  ? * 0: u
  ? * 0: v
  ? * 0: w
  ? * 0: x
  ? * 0: y
  ? * 0: z
#

Ejemplo de como Klismafile realiza la limpieza.

# ./klismafile -v /mnt
  Scrubbing device: /dev/hda6
  cleansing /
  -> a
  -> b
  -> c
  -> d
  -> e
  -> f
  -> g
  -> h
  -> i
  -> j
  -> k
  -> l
  -> m
  -> n
  -> o
  -> p
  -> q
  -> r
  -> s
  -> t
  -> u
  -> v
  -> w
  -> x
  -> y
  -> z
  Total files found: 29
  Directories checked: 1
  Dirents removed : 26
# 

Ejemplo de como fls no es capaz de encontrar ninguna entrada.

# ./fls -d /dev/hda6 2
#

Estos ejemplos demuestran claramente que la utilidad ‘fls’ – una parte de la caja de herramientas TCT-UTILS, sirve para examinar los ficheros de directorios. En el primer ejemplo el uso de la utilidad devuelve el listado de entradas de directorio borradas en el directorio raíz del sistema de ficheros.

Klismafile se ejecuta en modo detallado, visualizando y sobrescribiendo cada entrada de directorio que encuentra. Una vez acabado el trabajo de sobrescritura, fls no es capaz de mostrar ninguna entrada eliminada en el fichero de directorio.

Aviso: El núcleo de linux 2.4.x utiliza la técnica de cacheo del fichero de directorios en la memoria, por lo tanto si el intruso no tiene cuidado a la hora de utilizar esta herramienta sus cambios pueden no haberse realizado en la versión física del fichero sino sólo en la memoria (una razón más para desenchufar el equipo y no apagarlo de forma correcta).

fuente:www.loquefaltaba.com