El viejo bug del NTDLL

13 03 2008

Hola

Hoy he estado leyendo sobre una herramienta en cuestión, la cual también he probado, y fue bastante grande mi sorpresa al ver que un archivo que creaba la misma, no podía ser eliminado. Pero lo sorprendente no fue el hecho de no poder eliminarlo, si no porque me pareció increíble que un bug tan viejo de Windows siguiera sin resolverse. Hacía ya hace meses que conozco ese bug (por no decir más de un año) y pensé que ya se había solucionado, ya que para ese momento no tenía correctamente actualizado Windows, sumado a que varias páginas mencionan que el bug fue parcheado, cuando no es así.

Como dice el título, concretamente el problema se encuentra en la librería NTDLL.DLL (una de las librería más importantes de Windows) en la funciones RtlpWin32NTNameToNtPathName_U y RtlGetFullPathName_Ustr, que son las que se encargan de chequear las rutas de los archivos. Windows NT utiliza un estilo diferente de nombrado de archivos a los basados en DOS (debido al NTFS), es decir, que admite diferentes tipos de carácteres que antes no podían utilizarse. Po ejemplo, los espacios al final del archivo, lo cual es lo que genera esta vulnerabilidad. Es decir, que cuando intentamos acceder a un archivo que tiene peculiaridades del estilo NT (espacios al final, en este caso) mediante funciones basadas en DOS, no podremos acceder al mismo, ya que los espacios del final son eliminados por la función de chequeo de ruta y pasado un nombre de archivo incorrecto. Para los que no entendieron esta explicación, aquí va una explicación más sencilla:

  • Tenemos un archivo llamado “C:\archivo   ” (con tres espacios al final)
  • Un programa intenta acceder a “C:\archivo   “
  • Se llama la función RtlpWin32NTNameToNtPathName_U para verificar la ruta “C:\archivo   “
  • RtlpWin32NTNameToNtPathName_U automáticamente elimina los últimos tres espacios en blanco.
  • RtlpWin32NTNameToNtPathName_U devuelve la ruta “C:\archivo”, sin los espacios al final.
  • En vez de acceder a “C:\archivo   “, en realidad accedemos a “C:\archivo”, que no existe, o bien es otro archivo diferente.

Como verán, el problema es que al acceder al archivo en cuestión, en realidad estamos accediendo a otro, y con lo de acceder me refiero a modificar, copiar y eliminar.

Las librerías afectadas por este bug (o error de diseño, como quieran llamarle) son las siguientes:

    	
  • acledit.dll
  • ADVAPI32.DLL
  • cscdll.dll
  • CSRSRV.DLL
  • dskquoui.dll
  • EVENTLOG.DLL
  • GDI32.DLL
  • ifsutil.dll
  • KERNEL32.DLL
  • LSASRV.DLL
  • ntmarta.dll
  • OLE32.DLL
  • perfproc.dll
  • query.dll
  • rshx32.dll
  • scesrv.dll
  • sdbapiu.dll
  • setupdll.dll
  • sfc.dll
  • SHELL32.DLL
  • shim.dll
  • srvsvc.dll
  • trkwks.dll
  • ulib.dll
  • wow32.dll
  • AUTOCHK.EXE
  • autoconv.exe
  • autofmt.exe
  • NTVDM.EXE
  • os2srv.exe
  • posix.exe
  • regsvc.exe
  • SERVICES.EXE
  • smss.exe
  • WINLOGON.EXE

Las funciones afectadas son las siguientes:

    	
  • GetShortPathNameW
  • CopyFileW
  • MoveFileW
  • MoveFileExW
  • ReplaceFileW
  • CreateMailslotW
  • GetFileAttributesW
  • FindFirstFileExW
  • CreateFileW
  • GetVolumeInformationW
  • DeleteFileW
  • GetDriveTypeW
  • GetFileAttributesExW
  • CreateDirectoryW
  • FindFirstChangeNotificationW
  • GetBinaryTypeW
  • CreateNamedPipeW
  • SetFileAttributesW
  • MoveFileWithProgressW
  • GetVolumeNameForVolumeMountPointW
  • GetDiskFreeSpaceW
  • CreateDirectoryExW
  • DefineDosDeviceW
  • PrivMoveFileIdentityW
  • GetCompressedFileSizeW
  • SetVolumeLabelW
  • CreateHardLinkW
  • RemoveDirectoryW

Cualquier programador podrá darse cuenta de la potencialidad de esta vulnerabilidad, más aún si es utilizado con algún fin malicioso, como por ejemplo, una infección. Es más, la mayoría de los antivirus son vulnerables a este, lo que significa que al querer acceder a un archivo, no se podría o se estaría accediendo a otro, e imposibilitaría el análisis del mismo, lo cual demuestra obviamente que es un error de diseño bastante peligroso. En mi caso, uso NOD32 AntiVirus, el cual parece ser vulnerable al problema.

¿Cómo saber si mi AntiVirus es vulnerable?

Para verificar esto, sin riesgo alguno, podemos usar el test EICAR:

La prueba EICAR consiste en un archivo que sirve para comprobar la eficacia de los programas antivirus. La ventaja que tiene sobre otras comprobaciones es que el equipo queda libre de riesgos. Se trata de un inofensivo archivo de texto.

Consiste en copiar la siguiente cadena de caracteres:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

En el bloc de notas, y guardarlo con una extensión .com Un antivirus con protección en tiempo real debería detectarlo inmediatamente. Un escaneo en busca de virus también debería detectarlo. Esta prueba ya no es demasiado eficaz, es antigua y muy conocida por todos los fabricantes de software.

La idea es crear un archivo EICAR con espacios al final, para luego ver si el antivirus puede analizarlo y/o detectarlo.

Ahora, ¿Cómo acceder a estos archivos?, muy simple, utilizando el estilo de redirección NTFS, o alguno que no sea vulnerable. Para este caso, ralizamos lo siguiente:

1. – Desactivamos nuestra protección antivirus residente temporalmente para crear el archivo.

2. – Vamos a Inicio, Ejecutar… y tipeamos el siguiente comando:

  • type nul > “\\?\C:\eicar   “
  • notepad  “\\?\C:\eicar   “

En el caso de querer utilizar la carpeta raíz del disco C:\, y es muy importante poner uno o más espacios antes de la última comilla (“). Podrán ver que se abrirá el Bloc de Notas.

3. – Copiamos el siguiente texto al Bloc de Notas:

  • X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Luego, vamos al menú Archivo, y presionamos en Guardar…, o presionamos Ctrl + G.

4. – Una vez creado el archivo EICAR, reactivamos la protección antivirus, y analizamos el archivo.

En el caso de que el archivo no pueda ser analizado o nos de un error de que el archivo no existe, nuestro AntiVirus será vulnerable.

Si no fuera vulnerable, el archivo sería detectado al analizarlo o al hacerle clic (estando el residente activo, claro).



¿Cómo eliminar un archivo de este tipo?

Por ejemplo si quisieramos eliminar el “C:\archivo   ” del primer ejemplo, deberíamos ejecutar este comando:

  • del “\\?\C:\archivo   “

Obviamente, además podemos usar otras funciones y aplicaciones (aunque como dije, la gran mayoría son vulnerables) añadiendo la cadena de carácteres \\?\ al principio de la ruta.

Conclusiones

Este problema es grave, como ya venía diciendo, a nivel programático y también a nivel seguridad. La gran mayoría de los salvaguardas (AntiVirus, AntiSpywares, Firewalls), así que lo mejor sería una solución por parte de Microsoft. Cabe destacar que si nuestro AntiVirus residente está activado y es efectivo, la creación de un archivo será interceptada, únicamente si el archivo en cuestión se encuentra en la base de datos del software. Sinceramente, ver fallos como estos por parte de Microsoft, comienzo a recordar algunos de los motivos del porque uso Debian😐

Cualquier comentario es bien recibido, y agradecería que informen si su AntiVirus es vulnerable o no, para poder tener una lista de esto.

Salu2


Acciones

Information

4 responses

14 03 2008
» El viejo bug del NTDLL

[…] setya5785 wrote an interesting post today onHere’s a quick excerptHola Hoy he estado leyendo sobre una herramienta en cuestión, la cual también he probado, y fue bastante grande mi sorpresa al ver que un archivo que creaba la misma, no podía ser eliminado. Pero lo sorprendente no fue el hecho de no poder eliminarlo, si no porque me pareció increíble que un bug tan viejo de Windows siguiera sin resolverse. Hacía ya hace meses que conozco ese bug (por no decir más de un año) y pensé que ya se había solucionado, ya que para ese momento no tenía correctamente actualizado Windows, sumado a que varias páginas mencionan que el bug fue parcheado, cuando no es así. Como dice el título, concretamente el problema se encuentra en la librería NTDLL.DLL (una de las librería más importantes de Windows) en la funciones RtlpWin32NTNameToNtPathName_U y RtlGetFullPathName_Ustr, que son las que se encargan de chequear las rutas de los archivos. Windows NT […] […]

14 03 2008
GT

Hola HD el Avira paso la prueba y te comento que el Spysweeper estaba activo en el momento de crear el archivo y lo mando a cuarentena inmediatamente.
Luego lo desactive e hice la pueba activando el Avira y escaneando el archivo y lo detecto satisfactoriamente.

Comienzo del análisis: 2008-03-14 15:30

Comienza el análisis de ficheros:

Comienzo análisis en ‘C:\Users\GT\Desktop\eicar “.txt’
C:\Users\GT\Desktop\eicar “.txt
[DETECTION] Contains code of the Eicar-Test-Signature virus
[INFO] Se movió el fichero ‘483de14f.qua’

Fin del análisis: 2008-03-14 15:32
Tiempo empleado: 02:22 min

Se ha analizado todo.

0 Analizando carpetas
1 Ficheros analizadosi
1 se encontraron virus y/o programas indeseados
0 clasificado como sospechoso:
0 ficheros eliminados
0 ficheros reparados
1 se movieron ficheros a cuarentena
0 se renombraron ficheros
0 No se puede analizar los ficheros
0 Ficheros no concernidos
0 Se analizaron los ficheros
0 Alertas
0 Notas

31 03 2008
Rekkuza

Buenasss HD

Te comento que le hize la prueba a Kaspersky (Tambien aplica a Zone Alarm AV) y la paso sin problema alguno.

Proximamente le hare la prueba a AVG, ClamWin y Avast!.

Salu2!

25 04 2008
Marcapasos

Te has pasado de listo pringao, como casi siempre. Tu bug es inocuo, tiene tanto peligro como tu belleza, gilipollas!!.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s




A %d blogueros les gusta esto: