SET 39 Call For Papers

¿Eres un hacker? Si deseas pasar a formar parte de la historia del hacking hispano, colabora con la próxima edición de SET 39 enviándonos un artículo. No esperes más, esta es tu oportunidad de demostrar lo que sabes. Ayúdanos a construir una revista de hackers para hackers. SET Staff

Entendiendo el trafico NFS

      4787

Autor: Paseante
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
o 07. ENTENDIENDO EL TRAFICO NFS                                            o
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

 
Vamos a dedicar este articulo a algo perfectamente inutil para lo que hace
falta una buena preparacion tecnica, grandes dosis de sentido comun,
mucha paciencia y no tener nada mejor que hacer (algo realmente dificil a
menos que seas un calamar).
Hoy es el gran dia, vamos a hablar del trafico NFS (no os desmayeis por
favor).
Como supongo que entre nosotros habra quien no sepa lo que es NFS (incultos
profesores universitarios, ancianos pastores y periodistas informaticos
mayormente) diremos que es el acronimo de Network File System y ahora que
esta claro pasemos a poner las manos en la masa.

Se trata de un modo de integrar ficheros locales y remotos que se utiliza
profusamente y en redes que van desde las pocas decenas de ordenadores a
gigantescas redes con miles de ordenadores entrelazados asi que campo para
experimentar no nos faltara.
Para analizar trafico de un sistema de ficheros distribuido tenemos que
tener acceso a la red (Ethernet mostly) y poner nuestra tarjeta en
ese modo "de la cosa sesua" promiscuo que tan famoso han hecho los sniffers.

Hemos quedado que los ficheros distribuidos viajan a traves de redes, por
lo tanto habra que 'escuchar' a los servidores de ficheros (asombroso!) para
estar al loro de sus actividades (seguramente insurgentes).
Para enterarnos de algo tendremos que decodificar los paquetes de la red y
extraer las operaciones NFS de bajo nivel que luego trasladaremos desde ese
bajo nivel a comandos de usuario. Para lo primero se necesita un
decodificador RPC y un analizador NFS para lo segundo.
Una red NFS esta compuesta por servidores en los que se hallan fisicamente
los ficheros distribuidos y clientes que ejecutan acciones como si los
discos donde se hallan los ficheros fuesen "locales". Como de costumbre
una maquina puede ser cliente, servidor o ambos. (otro concepto
revolucionario)


*NFS Basico*

Para un usuario los ficheros NFS y locales se comportan igual, puede
manejarlos igual que los locales y no tiene porque darse cuenta de que pide
un fichero a otro ordenador. Capici?
La manera en que se comunican un cliente y un servidor es mediante una
serie de 17 instrucciones RPC (Remote Procedure Call), cada fichero y
directorio esta identificado inequivocamente por un "file-handler", los
ficheros se pueden leer, escribir, se pueden crear ficheros, consultar
atributos y directorios...
La mayor parte de operaciones son similares a la de cualquier S.O salvo que
no hay implementados comandos del tipo Open/Close.


*RPC en NFS*

El dialogo RPC consiste en un mensaje de llamada con una serie de argumentos
que el cliente pasa al servidor, este contesta entonces con un mensaje que
incluye los datos requeridos, estas llamadas se transmiten mediante conexion
IP/UDP. (aqui vendria un tipico diagrama pero no me siento con ganas, que
estamos en verano!!!!)

Como sabe el cliente a que llamada corresponde la respuesta recibida?
Elemental querido tocho, el mensaje de llamada incluye un identificativo que
el servidor devuelve para que el cliente pueda saber a que peticion responde.

Como sabe el servidor el formato en el que enviar los datos?
Como el servidor NFS suele ser bastante ignorante lo que se hace es que
los datos vienen codificados en XDR para facilitar la integracion de
diferentes plataformas.

Una caracteristica muy llamativa de NFS es que no guarda ninguna informacion
sobre los clientes y no sabe nada de lo que se hace con los archivos a
excepcion de los argumentos que se le envian.

                                       


*El decodificador RPC*

Un decodificador de RPC producira un archivo conteniendo los
principales datos de la transaccion RPC (recordemos que la transaccion se
compone de dos mensajes: llamada y respuesta). Esto incluye.

- Marca de tiempo
- Nombre del servidor
- Cliente
- Tiempo de ejecucion del comando
- Comando RPC ejecutado
- Argumentos de comando / datos retornados

Estos datos pueden ser utilizados directamente (trivial para la gente como
vosotros, popes del hack hispano) o pasados a otro programa (como un
analizador NFS) para que los convierta en algo mas entendible.

* La marca de tiempo
Tiempo en el que llega el mensaje respuesta

* Nombre del servidor
Nombre o IP del servidor (quien lo diria!)

* Cliente
Nombre o IP del cliente (guauu!) y el _usuario_ que libro el comando.

* Tiempo de ejecucion del comando
Tiempo en microsegundos entre el mensaje llamada y respuesta

* Comando RPC
La clase de comando (read, getattr...)

* Argumentos/Datos retornados
Argumentos con que se paso el comando y valores que se devuelven.

Ha quedado claro?. Me lo temia, veamos entonces un...

Ejemplo:


488987781.265508 - 9998 - cesid - lucas.nek - read -
{"6b34a0087e83d", 0, 4096} - ok, 1775

Que seria una salida tipica producto de nuestro decodificador RPC.
El mas listo de la clase.. si tu, el de las gafas marrones, si el del
fondo!. Tu ya lo sabes verdad?. Para los menos espabilados vamos a
explicarlo.

Habia una vez un usuario "nek" en una maquina cliente llamada "lucas" que
queria leer un archivo (comando read) de un servidor llamado "cesid".
A tal efecto envio el comando NFS con los argumentos del file-handler (que
identifica el fichero con una cadena hexadecimal) del inicio de lectura
(en el byte 0) y de los bytes a leer (4096).
Nuestro servidor respondio en 488987781.265508 (tiempo Unix claro esta)
a una peticion librada "9998" microsegundos antes.
El comando se ejecuto con exito "ok" y envio "1775" bytes de datos, aparte
claro esta de los bytes a leer pero eso es otra historia y de ella hablaremos
en otra ocasion. :-)

Por ultimo recordar que segun las leyes espa€olas el decodificador tiene
que ser compatible "Multicrypt" ;-) (cambiando de tercio, la parodia de
Aznar, Cascos..como hermanos Marx pidiendo descodificadores Multicrypt fue
genial!!!- Noticias del Gui€ol- Canal+- Algun dia de Julio del 97)

                           
*Un analizador NFS por favor*

Si queremos otra forma de ver los datos obtenidos, si no estamos contentos
con lo anterior, si nuestro ordenador se colapsa incapaz de procesar tanta
informacion, entonces necesitas tomarte un respiro. No, perdon, entonces
necesitas el arma definitiva, el analizador NFS (y seras el tipo mas guay
del barrio, ni siquiera los Men in Black tienen uno)

Tanto los decoders como los analizadores estan disponibles en muchos FTP
dedicados a la seguridad (y no me refiero a sites hack sino a organizaciones
que investigan temas de seguridad aunque en los primeros tambien los puedas
hallar).
En cualquiera de ambos casos un usuario anonimo no debe tener problemas para
hacerse con estos u otros programas similares.
Si eres incapaz de hallar uno no te preocupes, no sabrias utilizarlo aunque
te lo diesen. (ohh que duro!. Pero es rigurosamente cierto.)

Los datos presentados por un analizador NFS tipico son:

Marca de tiempo - Tiempo transcurrido- Direccion- Identificativo fichero-
Cliente- Transferencia- Tama€o.

Y esto?. Pues esto es:

* Marca de tiempo
Lo mismo de antes, si no lo has leido vuelve a empezar el articulo

* Tiempo transcurrido
Todo el tiempo que nos pasamos manipulando el fichero hasta dejarlo tranquilo

* Direccion
Lees o escribes? (algunos comandos poseen ambas direcciones)

* Identificativo fichero
Aqui aparecen tanto el servidor del fichero como el file-handler del mismo

* Cliente
Y aqui el cliente desde el que se hace la peticion y el usuario que la hace

* Transferencia
Ta claro norrr?. Los bytes que viajan en la direccion que sea.

* Tama€o
Del fichero. (O que te pensabas?) ;>


Pero ya se que hay algunos que sin un ejemplo no se enteran y todo les
suena a chino, asi que dedicado a los cibertarugos (mayoritariamente miembros
de la BSA y seguidores de las Spice Girls) el siguiente...

Ejemplo:

786542198.999111 - 36800 - read - moncloa:5e2f00011000d00f - pp.bigotin - 0 -
76542

Y ahora fijo que ya, si que no os habeis aclarado. :-?
No, que es muy facil, el usuario 'bigotin' del ordenador 'PP' lee un
ficherito (con handler '5e2....') del servidor 'Moncloa', esto pasa
cuando son las '78654..' (recordamos tiempo Unix) y despues de que el
cliente lo pidiese '36800' microsegundos antesss.
Pero seguro que el espabilado de antes y algun otro que ya le va cogiendo
el truco del almendruco dice: Y el 0?. Ese 0 que pinta donde tenia que
salir el numero de bytes transferidos?. Pues me alegro de que me hagais esa
pregunta porque demuestra que estais muy atentos y muy interesados en
culturizaros y vitamineralizaros.
No habiamos dicho, lo hacemos ahora, que si el cliente lee el fichero del
**cache** entonces en el campo de bytes transferidos aparece un 0 (logico
porque no ha habido que transferir nada).
O sea que en este caso 'bigotin' pudo leer el archivo directamente de la
cache de su ordenador.

LLegado este momento habra algun impaciente que exclame:
Pero esto para que COJ*NES vale???


Hombre pues aparte de la cultura que aporta, puede ser interesante saber
los habitos de trabajo de un departamento/usuario, se puede aprender de los
usuarios viendo que ficheros leen y/o escriben, en sitios comerciales podria
darnos una idea de que ficheros son importantes, en que proyectos se esta
trabajando... No, si realmente inutil no es.
Sobre todo porque esto que estamos viendo se puede aplicar casi directamente
al trafico NIS y porque algo como la "caza de claves" (eso del sniffer que
se ha puesto de moda entre los ???ers. Donde hay un sniffer?. Como funciona?
Dadme uno!!) es esto mismo, la mecanica es esta asi que quiza ahora os
parezca algo mas interesante el articulo. ;-)
Y si leeis el articulo sobre firewalls vereis que NFS ha sido historicamente
"puerta abierta" para las incursiones (glubbs!).

Pero no introducazmos malvadas ideas y sigamos con el inocente? analisis del
trafico NFS.

De que me sirve saber que 'bigotin' lee '5e2..' no se que es eso!!
Un documento secreto, un juego, una imagen porno?. Seria interesante saberlo
porque sino la utilidad del analisis desciende mucho, quiero saber a que
dedican mis empleados su tiempo libre, hacerme una idea de los ficheros
mas usados, etc....
No desesperarse porque es posible _mapear_ los file-handlers a nombres de
ficheros aunque no siempre sera un mapeado exacto dependiendo mucho de la
carga del sistema y de la profusion de borrados y renombrados.
Pero asi nuestro analizador NFS cambiara de decirnos que:

'bigotin' leyo el archivo '5e2f00011000d00f' a darnos un nombre descriptivo
como:

'bigotin' leyo el archivo 'M0-TRK27J.~TM'. Observad la ganancia de claridad!!

Hombre si tenemos esa mala suerte no nos habra servido de mucho pero si
el archivo tiene un nombre descriptivo como:
'comisiones.ps'
'timo.html'
'chupona.jpg'
'aquiguardolasclavesdetodo'
Pues la cosa sera algo mas interesante.


Lo que produce un analizador NFS no es mas que una aproximacion a la
actividad del usuario ya que como hemos dicho NFS ni guarda informacion sobre
sus clientes ni implementa comandos open/close por lo que el analizador suele
utilizar tecnicas heuristicas y ofrece resultados consistentes observados
a nivel general.
En plain ASCII, ya que NFS no guarda mucha informacion sobre sus clientes
no pretendais obtener maravillas de el, tendreis que a€adir algo de sentido
comun.

Si os pensais dedicar al arte del analisis NFS como trabajo estable puedo
aseguraros que tendreis una vida de lo mas aburrida, si vuestro objetivo
es "foguearos" para saber analizar otro tipo de trafico..es cosa vuestra
pero no espereis que os vaya a ver a la carcel.

En cualquiera de ambos casos debeis tener en cuenta que si el volumen de
trafico es alto se perderan datos, habra llamadas de las que no se obtenga la
respuesta a causa de crashes, desbordamiento de buffers...
Pero en fin, cosas mas inutiles se hacen. Y recordad que en la escala social
del underground os colocareis justo por encima de los que envian mensajes a
las news con el Subject: "Add me"
o en su equivalente hispano ===> "Apuntame a mi tambien a la lista warez"

Ps: Por cierto, interesan unos CD piratillas por 1.500?. Escribid a
    soy_un@completo.bobo para detalles. };->>