NTFS y Alternate Data Streams. El peligro está oculto

El sistema de ficheros NTFS tiene un peculiaridad bastante llamativa derivada de proporcionar compatibilidad con HFS (Hierarchical File System) de Macintosh. En HFS la información de un fichero se almacena en bifurcaciones (forks) de datos y de recursos. Los forks de datos mantienen la información del contenido propiamente dicho mientras que los forks de recursos indican metadatos como por ejemplo tipo de fichero

 Esta propiedad provoca que un mismo recurso tenga varios identificadores y puede sacarse provecho para ocultar ficheros en NTFS. EL formato es conocido como Alternate Data Stream ADS.

 Mejor, veamoslo con un ejemplo.

La sintaxis de un ADS es sencilla. Para crear un ADS asociado con un fichero, basta con añadir el carácter dos puntos ":" al nombre del fichero, por ejemplo:
Creamos un fichero de texto:

C:\Users\Usuario\ADS>echo "Fichero de texto" > file.txt
C:\Users\Usuario\ADS>dir

 El volumen de la unidad C no tiene etiqueta.

13/12/2011 11:00 <DIR> .
13/12/2011 11:00 <DIR> ..
13/12/2011 11:00 21 file.txt

 1 archivos 21 bytes
 2 dirs 367.935.696.896 bytes libres
　

C:\Users\Usuario\ADS>type file.txt

"Fichero de texto"

Ahora utilizando la sintaxis apropiada creamos un fichero ADS:

C:\Users\Usuario\ADS>echo "Texto oculto" > file.txt:hidden


Comprobamos como, aparentemente nada ha cambiado:

C:\Users\Usuario\ADS>dir

  El volumen de la unidad C no tiene etiqueta.
 Directorio de C:\Users\Usuario\ADS
13/12/2011 11:00 <DIR> .
13/12/2011 11:00 <DIR> ..

13/12/2011 11:01 21 file.txt
 1 archivos 21 bytes
 2 dirs 367.935.696.896 bytes libres

C:\Users\Usuario\ADS>type file.txt
"Fichero de texto"

El fichero no existe con estructura como tal ....

C:\Users\Usuario\ADS>type file.txt:hidden
El nombre de archivo, el nombre de directorio o la sintaxis de la etiqueta del volumen no son correctos.

... pero podemos extraer el stream por ejemplo, haciendo uso de la redirección hacia el comando more:

C:\Users\Usuario\ADS> more < file.txt:hidden
"Texto oculto"



Como vemos, hemos podido "asociar" un stream a un fichero de modo que aparentemente sólo sea visible el fichero "file.txt" pero asociado a él existe el stream oculto "file.txt:hidden" con su propio contenido. Obsérvese que el tamaño del fichero no cambia ya que realmente sigue siendo el mismo. De hecho son independientes, es sólo una forma de demostrar que añadiendo los dos puntos ":" asociamos el data stream al mismo y será  invisible en un listado usual. Esta propiedad de los sistemas de ficheros NTFS contituye en cierto modo un  riesgo de seguridad  al permitir ocultar al usuario contenidos, permitiéndose incluso insertar de forma silenciosa archivos ejecutables.

Afinando un poco,  podemos listar y encontrar ADS usando la opción /R del comando DIR en windows:

C:\Users\Usuario\ADS> help DIR
Muestra la lista de subdirectorios y archivos de un directorio.

DIR [unidad:][ruta][archivo] [/A[[:]atributos]] [/B] [/C] [/D] [/L] [/N]
  [/O[:]orden]] [/P] [/Q] [/R] [/S] [/T[[:]fecha]] [/W] [/X] [/4]

...
..
  /R          Muestra las secuencias alternativas de datos del archivo.

..

De este modo, entonces:

C:\Users\Usuario\ADS>dir /R

El volumen de la unidad C no tiene etiqueta.
Directorio de C:\Users\Usuario\ADS
13/12/2011 11:00 <DIR> .
13/12/2011 11:00 <DIR> ..
13/12/2011 11:01             21 file.txt
13/12/2011 11:01           6.002 file.txt:hidden:$DATA






Existen varias herramientas para buscar y detectar cómodamente ficheros ADS. Por ejemplo Nirsoft, proporciona el programa AlternateDatastreamView que nos permite de forma muy sencilla escanear el disco en busca de este tipo de archivos:

Mas info:

http://www.securityfocus.com/infocus/1822

http://cwe.mitre.org/data/definitions/69.html

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q101353

X Forwarding y túneles ssh

Puff, ya hacía tiempo que no posteaba. Mucho lío , poco tiempo , muchas cosas... o una combinación de todas.
Bueno pues voy a hablar del forwarding de X en sesiones ssh, cosa que más de una vez me ha "salvado la vida".

Tunelizando conexiones a servidor X


Cuando necesitemos acceso a otra máquina y hacer uso de herramientas gráficas, pero sólo podemos acceder vía ssh, podemos usar un túnel ssh y a través de la conexión  hacer  forwarding, de modo que las aplicaciones ejecutadas en la máquina remota tengan acceso al servidor X local.

El mecanismo es el siguiente:

Para establecer la sesión ssh con túnel para las x, ejecutaremos

ssh -X <host_remoto>  (*)
login: userx
Password:
Have a lot of fun...
/usr/bin/xauth:  creating new authority file /home/userx/.Xauthority
userx@server>$

(*) Si no inidcamos la opción -X, debemos tener habilitado el forwading  del servidor local de X (ForwardX11 yes) en el fichero de configuración del cliente ssh (/etc/ssh/ssh_config)

Con esto, el  cliente ssh local genera una cookie de autenticación y la envía al servidor ssh remoto que añadirá al fichero $HOME/.Xauthority de la máquina remota en la conexión.

El servidor remoto, abre el socket TCP 6010 en modo escucha. Además, inserta en el entorno del usuario que se logea la variable de entorno DISPLAY=localhost:10.0. En el caso de que el socket estuviese ya ocupado, asignará el siguiente (TCP 6011) y la correspondiente variable de entorno DISPLAY=11.0 y así sucesivamente.

Observemos la siguiente salida de netstat que nos muestra el estado de los sockets LISTEN en la máquina remota:

Sockets Listen en la máquina remota

Conexiones establecidas

Tenemos que:

Se crea una conexión ssh entre la máquina local 10.70.4.11 y la remota 10.70.4.4.  En la máquina remota se lanza una aplicacion gráfica (iceweasel). Esta  leerá la cookie del fichero $HOME/.Xauthority e iniciará una conexión TCP al socket local que corresponda, en este caso el 6010. El cliente recibirá la cookie y comprueba que, efectivamente, es la que él generó inicialmente. A continuación establece una conexión con el servidor X local. A partir de este momento el túnel está establecido.

En este ejemplo la sesión que abrió el socket 6010 y se  ejecutó iceweasel:

userx@server>$ pstree 15094
sshd----bash----iceweasel-----22*[{iceweasel}]

Conexión al servidor X. Tipos

La conexión de una aplicación al servidor X puede realizarse por varios métodos. En GNU/Linux los métodos son socket local (socket Unix)  y TCP. Es la aplicación cliente la que escoje el protocolo y la localización del servidor con la variable DISPLAY o bien con la opción --display.
En el caso de usar socket unix local , la variable DISPLAY será un signo de dos puntos seguido del número de display, generalmente 0 (aunque puede ser distinto si se ejecutan varios servidores de X). Opcionalmente puede añadirse un punto y número de pantalla (también suele ser cero salvo que el servidor X controle varias pantalllas) .Entonces DISPLAY tomará generalmente el valor :0 (o :0.0). El socket local se creará en /tmp/.X11-unix/Xn siendo n el número de display:

linux:/etc/ssh # ls -l /tmp/.X11-unix/
total 0
srwxrwxrwx 1 root root 0 Dec  5 10:53 X0

Cuando la conexión es por socket TCP, DISPLAY será el hostname o IP del servidor X seguido de dos puntos y el número de display. Al igual que antes puede añadirse punto y el numero de pantalla. Por ejemplo en una conexión local pero por TCP el valor será DISPLAY=localhost:0. El puerto TCP mas usado es el 6000 mas el número de display.
Téngase en cuenta que las comunicaciones con el servidor X no están cifradas por lo que si se usa TCP las comunicaciones pueden monitorizadas. Es por ello que GNU/Linux no permite la conexión al servidor X por TCP. Esto puede comprobarse observando el parámetro -nolisten tcp en el proceso X:

linux:/etc/ssh # ps -ef | grep X

root      4177  4163  0 10:53 tty7     00:00:07 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-APoml7/database -nolisten tcp vt7 

Nota: En el ejemplo, la conexión de la aplicación cliente (en la máquina remota) se conecta al servidor X a través de un túnel ssh, con lo cual realmente el puerto TCP 6010 (6000 + 10 display) remoto está redirigido al túnel ssh y  la conexión al servidor X local a través de él