Bueno después de una temporada en la que hemos andado un poco escasos de entradas en el blog, volvemos a la carga con una nueva seccion dedicada a «retos 48bits», este primer reto ha sido preparado por erg0t, se trata de una especie de «crackme», el objetivo es conseguir programar un generador de llaves ( usuario y password ) universal (no os fieís de erg0t … probadlo en más de una máquina y descargad el fichero más de una vez ) .

Para ello necesitaís un kernel 2.6, tráfico UDP permitido hacia internet y libz. Las soluciones enviadlas a staff@48bits.com, al ganador como somos pobres lo único que podemos ofrecerle (por lo menos de momento) es una cuenta para que pueda blogear en 48bits :-).

Ah, el ejecutable que necesitaís está aquí, dudas y comentarios en este post.

Un saludo!

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…)