Son muchos los casos en los que programadores dejan para su propio uso parámetros de configuración no documentados o funcionalidad «oculta» en las aplicaciones que desarrollan. El otro día dimos con lo que a primera vista parecía uno de estos casos:

Nos encontrabamos Miguel y yo en plena reunión matutina (el desayuno con pincho de tortilla incluido), cuando me comentaba que en una de sus frecuentes sesiones de depuración creía haber encontrado funcionalidad en el propio API de Windows para ocultar threads, no sin antes acabar el pincho de tortilla nos pusimos a comentarlo…

El código en cuestión se encontraba en la función RtlQueryProcessDebugInformation, exportada por NTDLL.DLL, esta función es usada por varias funciones de Tool Help exportadas por KERNEL32.DLL, las cuales son usadas para obtener información sobre los procesos activos en el sistema.

(más…)

Parece que tal y como comentabamos en un post anterior (echad un vistazo a los comentarios 😉 ), después del pequeño revuelo montado a raiz del tema de los NTFS Streams, algunos productos han decidido actualizar sus motores, es el caso de F-Secure, el cual anuncia en su blog que da soporte a esta tecnología en su producto anti-rootkit BlackLight, me hace un poco de gracia el comentario que hacen….

«Many of our readers have probably heard of Alternate Data Streams (ADS) on NTFS. They’re not that well documented and there are only a few tools that can actually handle them.»

En cualquier caso, no comentan nada de que la tecnología esté también disponible en su producto antivirus, ya que BlackLigth es una herramienta aparte de este, y parece que como viene siendo habitual aparece el soporte después de que se produzca la «incidencia»

Bueno me acabo de poner a mirar el driver parcheado y ha sucedido lo que me temía, de hecho lo puse en la web ¡¡hay miles de testigos!! xDD. La verdadera causa de la vulnerabilidad sigue sin estar arreglada. Símplemente han añadido al mrxsmb.sys un código que sirve como wrapper para evitar el handle «chungo».

He programado un driver que operaba igual que el anteriormente vulnerable y con el Kartoffel lo acabo de probar y pun. Ahí sigue la vulnerabilidad.

Como he escrito en Bugtraq, Microsoft tendrá sus propias razones para hacerlo. Símplemente me gustaría que si eso es considerado como una característica, se documente como tal, ya que un desarollador no tiene porqué conocer este comportamiento interno de NtClose/ZwClose.

Veremos en que acaba la cosa.

Bueno, ya puestos a estrenar cosas, acabo de sacar la primera versión de un paper que lleva por título «Generic Detection and Classification of Polymorphic Malware using Neural Pattern Recognition» . En él explico cómo construir un sistema de reconocimiento de patrones con un clasificador basado en una red neuronal que nos permite discriminar automáticamente ,y con un margen de error prácticamente nulo, entre ficheros generados por el famoso packer/cypher Morphine y goodware u otros engines polimorficos como Upolyx.

Pese a no estar para nada optimizado, los resultados son áltamente satisfactorios a mi modo de ver. Este método se podría aplicar al desarrollo de signatures inteligentes para los antivirus, para detectar shellcodes polimórficas rulando por una red corporativa, etc…

Pero sobre todo, para evitar que a algunos se les pongan los ojos como al amigo Alex, el de la foto, detectando bichos polimórficos, que más de una vez ha pasado 😉

Espero que os guste.

Descargar el paper

Los Microsoftnianos acaban de publicar el boletín de seguridad de Junio. Éste soluciona,entre otras, dos vulnerabilidades que había descubierto el año pasado.

Ambas tienen como denominador común, el Microsoft Server Message Block Redirector Driver (mrxsmb.sys). La primera de ellas, permite a cualquier usuario sin ningún privilegio especial, tan solo logueado, ejecutar código en Ring0 debido a un fallo del Driver al validar los buffers de usuario.

La segunda, es un deadlock que permite a cualquier proceso volverse «unkillable». Para que nos entendamos, no lo podrían borrar ni antivirus, ni sistema operativo…Según Microsoft, el fallo está dentro del driver al pasarle un handle inválido.No estoy de acuerdo. Como podéis leer en el paper, el fallo está en el Kernel Object Manager, lo que pasa que para explotarlo tenemos que usar una IOCTL del driver, pero cualquier driver que use NtClose contra un handle síncrono,abierto en modo usuario a su propio dispositivo provocará el deadlock. No se si habrán solucionado el problema símplemente metiendo un pegote en el driver o lo habrán solucionado en el Kernel. No lo he mirado.
Qué más, ah pues también he liberado la primera versión del «Kartoffel», una herramienta Open Source para verificación de Drivers. Podréis testear rápidamente estas vulnerabilidades con ella, o dedicaros a enredar por ahí a ver si encontráis alguna 🙂 .

Bueno pues todos los papers, exploits y tal os lo podéis bajar en www.reversemode.com,

siento no poneros los links directos, pero es que son unos cuantos y la verdad, estoy quemao.