Bueno, si hace unos dias era a Symantec a quien le tocaba parchear, esta vez es ocasión para Kaspersky. Esta vulnerabilidad es diferente a las que han salido para otros Drivers. No se basa en ningún problema derivado del manejo erroneo de buffers de usuario.
Este caso, desde mi punto de vista, es un ejemplo claro de «Security through Obscurity». Kasperksy utiliza dos drivers para Hookear tanto a NDIS como a TDI respectivamente. Estos drivers implementan un sistema de plugins, los cuales son registrados (llamando a su rutina de entrada) utilizando un IOCTL en el cual se le pasa dicha dirección de la rutina de inicialización del Plugin. Óbviamente, estos plugins son de Ring0, por lo tanto es una llamada directa a esa dirección desde Kernel-Mode. Pues bien, ni el descriptor de seguridad del dispositivo de estos drivers estaba bien creado, ni habían puesto ninguna medida de seguridad para evitar que cualquiera puediera pasarle una dirección de user-mode. Irp.RequestorMode es lo que se tiene que usar en estos casos, ya que es donde se identifica si la Irp proviene de User-Mode o Kernel-Mode. Pues nada, tenéis dos exploits y el advisory preparados donde siempre. Saludos.
www.reversemode.com
Pobre viejuna :/

Con permiso de «Bixito Guapo» voy a seguir escribiendo entradas en el blog.

Bueno, Symantec acaba de publicar los parches y el advisory para una serie de fallos en diferentes Drivers de su motor antivirus que descubrí hace apenas un mes. Se han dado prisa, creo que son los que menos han tardado en reparar una vulnerabilidad (de las que he encontrado quiere decir) hasta ahora. Hombre, teniendo en cuenta que absolútamente todos los productos de Symantec para plataformas Microsoft están afectados, pues parece lógico que se dieran maña.

He decidido hacer públicos los exploits para demostrar que cualquier sobrescritura de memoria kernel puede ser explotada con éxito, no hace falta controlar los valores. La verdad es que este caso de Symantec me ha venido de puta madre para ilustrar las técnicas.
Para valores altos(punteros dentro del driver o cosas así), el método que he usado es sobrescribir MmUserProbeAddress, de esta manera ProbeForWrite se extiende hasta el valor que le hayamos pasado. Luego puedes usar el IOCTL que te de la gana de entre los muchos que te permiten personalizar valores, para sobrescribir ya valores controlados. Para ilustrar este método he usado el mrxsmb.sys que me permite generar valores usando la técnica de «ZwCreateFile – NULL» explicada en el paper que publiqué sobre este driver. Como Microsoft parcheó los permisos, pues para ejecutar los exploits necesitaréis privilegios de admin, pero vamos que es para ilustrar la base del método.

Hay 4 exploits disponibles para este método:

exploit 1

exploit 2

exploit 3

exploit 4

Para valores pequeños, he usado la técnica de sobrescribir la dirección a la tabla de funciones de NtQuerySystemInformation dentro del Kernel. En los exploits lo veréis más en detalle. Para este exploit no hacen falta privilegios especiales.

Para este método hay 2 exploits disponibles.

exploit 1

exploit 2

El advisory y esas cosas lo podéis encontrar donde siempre: www.reversemode.com

Un saludo!

while gets
  if /Ruby/
    print
   end
end

Últimamente he estado programando en lenguajes que antes me parecían muy raros. Los primeros que aprendí fueron en orden: Pascal, C, C++, y Java (también Visual Basic pero todos tenemos algo que ocultar). Nunca me había metido a investigar la familia Perl, Python, Ruby y similares. Admito que después de despojarme de algunos esquemas mentales le he cogido el gusto, sobre todo a Python y Ruby. Son sumamente expresivos, tienen librerias de clases muy completas, y casi cualquier cosa se resuelve con muy poco código. El trabajo con cadenas de texto, que es la pesadilla de la programación en C, es una maravilla con estos lenguajes. Lo mismo para el trabajo con listas, con XML, y con un montón de cosas más. Probablemente para muchos programadores que empezaron su carrera con ellos sea lo más natural del mundo asignar paralelamente los elementos entre dos listas, así…

foo, bar = a, b # foo = a y bar = b

..pero en los lenguajes a los que yo estaba habituado esto era ciencia-ficción. ¿Y que me dicen de esta joya?

a,b = b,a # intercambiar los valores de a y b

Cuando yo estudiaba programación en la universidad la clásica función swap era como una especie de algoritmo fundamental, básico, todo el mundo tenía que saber como se hacía un swap.

(más…)

Desde hace años siempre me han interesado las tecnicas anti-debug ya que en muchos casos suelen ser bastante ingeniosas en si mismas, o bien tiene que serlo el metodo para saltarselas. A continuacion os comento una que vi hace algun tiempo, muy sencilla de implementar y tambien una solucion para evitar la misma, si acaso alguien necesita depurar algun malware que haga uso de ella 🙂

La tecnica anti-debug es muy sencilla (seguro que la mayoria ya la habeis visto alguna vez) y simplemente consiste en borrar los registros de depuracion dr0, dr1, dr2 y dr3, de modo que depuradores de modo nucleo como SoftIce vean afectado su funcionamiento. Para hacer esto, es necesario que el malware en cuestion se ejecute en ring0:

xor eax, eax
mov dr0, eax
mov dr1, eax
mov dr2, eax
mov dr3, eax

¿Como podriamos implementar una solucion para evitar este truco molesto? Lo que explico a continuacion es una idea que podria ser aplicada por alguien que este desarrollando su propio debugger de modo nucleo y quiera implementarle algunos trucos anti-antidebug. En su dia, yo lo implemente para que funcionara con el SoftIce, pero dado que tuve que utilizar algunos trucos muy guarretes y ya que lo importante es la idea (aparte de que el SoftIce va a desaparecer) solo pongo las partes basicas de lo que hice, modificando aquello que tenia que ver con el SoftIce. Hace falta un poquito mas de trabajo para que lo siguiente funcione perfectamente.

(más…)

Después de escuchar un breve comentario de un periodista sobre la seguridad del nuevo Windows Vista, en relación con el SpyWare y Virus, cuya conclusion fue que nunca se logrará construir software libre de fallos, no he podido evitar dirigirme aqui y escribir este post.

Empecere diferenciando las tres clases de fallos que se dan en toda construccion software:

1. Bugs en los requisitos: Son aquellos que afectan a la funcionalidad requerida por el cliente y que no han sabido ser entendidos por las personsas encargadas de esta fase. Un par de ejemplos podria ser incluir solo el tipo de moneda en pesetas o que el motor no debe superar las 3000 rpm.
2. Bugs en el diseño: Aqui es donde empiezan a surgir los fallos que nos interesan, aquellos relacionados con la seguridad o funcionalidad crítiticas de la aplicacion. Los fallos surgen por considerar triviales, hacer caso omiso o por simple desconocimiento de los casos en los que se está trabajando. Ejemplos serían el fallo de seguridad que hace poco se presento en freeVNC o no contemplar el caso en que si el cohete supera la inclinacion permitida hay que reectificar la trayectoria.
3. Bugs en la implementación: En este ultimo tipo entrarían los fallos de tipo tecnologico, es decir, provocados por no entender las herramientas con las que se está trabajando. Los archiconocidos overflows o fallos en el parseo de cadenas son simplemente algunos, de los que seguramente sabreís mas que yo.

Desde mi punto de vista, estoy seguro que se conseguiran reducir los bugs en las aplicaciones a medida que se van estandarizando las tecnicas para construir las mismas, llegando a alcanzar aplicaciones 100% libres de bugs en la mayoria de los casos.

(más…)