Tema destacado: Últimos eventos sobre seguridad/inseguridad
 Autor
|
Tema: Impedir matar un proceso de windows desde el TaskManager (Leído 7,389 veces)
|
|
Karcrack
|
La solucion al problema de este usuario ya esta dada. Mejora el metodo para evitar varias instancias... Mi pregunta es, porque empezais a hablar de Hooks? SIEMPRE se puede cerrar un proceso, por mucho que se proteja... Sobretodo en UserLand... Si no se pudiese cerrar de ninguna forma ya me diras tu que pasaria cuando quieras apagar el W$, y este intente cerrar el proceso con WM_QUIT 
|
|
|
|
|
En línea
|
|
|
|
RAID-MAM
 Desconectado
Mensajes: 58
|
La solucion al problema de este usuario ya esta dada. Mejora el metodo para evitar varias instancias... Mi pregunta es, porque empezais a hablar de Hooks? SIEMPRE se puede cerrar un proceso, por mucho que se proteja... Sobretodo en UserLand... Si no se pudiese cerrar de ninguna forma ya me diras tu que pasaria cuando quieras apagar el W$, y este intente cerrar el proceso con WM_QUIT Windows tiene un grado de permisos superior a todos los programas que corran en el  Yo propuse metodos de proteccion ustedes propongan metodos para conbatirlos karcrack me sorprende que como moderador no fomentes la discucion creativa
|
|
|
|
|
En línea
|
|
|
|
bizco
Desconectado
Mensajes: 698
|
* Es solo proteger el PEB para que no puedas inyectar una dll
* Desde modo kernel .. no veo mucho como podrias hacerlo crachear facilmente si se programa una pequeña proteccion
y por cierto si existen bastantes metodos menciona uno me tienes facinado esperandolo Bueno, ya he mencionado alguno. lo mejor es hacer un pequeño form sin nada y escribir esa proteccion, luego se testea y se discute sobre su eficacia etc. Este foro es de analisis y que mejor que atacar una proteccion para mejorarla. Desde modo kernel .. no veo mucho como podrias hacerlo crachear facilmente si se programa una pequeña proteccion
Todo es verlo, ¿quien de todos hace el driver para que podamos testear bien y discutir sobre esto?. Tambien estaria bien hablar y hacer practicas sobre metodos de evitar la deteccion sobre modificaciones en procesos etc.
|
|
|
|
« Última modificación: 21 Marzo 2010, 07:01 por ctlon »
|
En línea
|
|
|
|
|
Karcrack
|
Windows tiene un grado de permisos superior a todos los programas que corran en el Ring -1?? karcrack me sorprende que como moderador no fomentes la discucion creativa La discusion esta offtopic, el usuario ya tiene la solucion, si quereis hablar sobre como matar procesos 'inmortales' o como hacerlos cread un nuevo topic, no?
|
|
|
|
|
En línea
|
|
|
|
|
Hendrix
|
Para empezar, en modo kernel se puede hacer todo, un ejemplo de como se podría producir un crash es, usando el artículo que publiqué en el blog ( este) para sobrescribir toda la memoria del proceso (es un ejemplo, por decir algo), una vez sobrescrita la memoria, cuando el proceso salte a "nuestra basura" se producirá un crasheo. Cabe decir que hookear la SSDT te salva de las llamadas a las API's en modo usuario, ya que desde un driver puedes llamar directamente a la dirección correcta de la API sin tener que pasar por el Hook. Un método de protección, es cambiar el PID del proceso por el nº 4. Muchos programas que trabajan con drivers para manipular procesos (vease Rootkit Unhooker y IceSword) no pueden cerrarlos, ya que el PID 4 está reservado para el sistema  Un Saludo  |
|
|
|
|
En línea
|
"Todos los días perdemos una docena de genios en el anonimato. Y se van. Y nadie sabe de ellos, de su historia, de su peripecia, de lo que han hecho, de sus angustias, de sus alegrías. Pero al menos una docena de genios se van todos los días sin que sepamos de ellos". - Juan Antonio Cebrián |
|
|
APOKLIPTICO
Desconectado
Mensajes: 3.781
Toys in the attic.
|
Podes usar drivers, como los anti virus y firewalls, pero se pueden matar facilmente con un programa que utilize funciones a nivel kernel como el cheat engine... Yo creo que la mejor opción sería que lo inyectes en el proceso de otro ejecutable...
|
|
|
|
|
En línea
|
AMD Phenom II 1075T X6 @ 290 Mhz x 11 (HT 2036 Mhz NB Link 2616 Mhz) 1.23 Vcore
ASUS M4A89GTD-PRO/USB3
2x2gb G-Skill RipjawsX DDR3 1600 Mhz CL7 (7-8-7-24-25-1T)
Seagate 500 Gb
XFX HD4850 512Mb GDDR3. 650 Mhz/995 Mhz 1.1 Tflops.
|
|
|
RAID-MAM
Desconectado
Mensajes: 58
|
Para empezar, en modo kernel se puede hacer todo, un ejemplo de como se podría producir un crash es, usando el artículo que publiqué en el blog ( este) para sobrescribir toda la memoria del proceso (es un ejemplo, por decir algo), una vez sobrescrita la memoria, cuando el proceso salte a "nuestra basura" se producirá un crasheo. Cabe decir que hookear la SSDT te salva de las llamadas a las API's en modo usuario, ya que desde un driver puedes llamar directamente a la dirección correcta de la API sin tener que pasar por el Hook. Un método de protección, es cambiar el PID del proceso por el nº 4. Muchos programas que trabajan con drivers para manipular procesos (vease Rootkit Unhooker y IceSword) no pueden cerrarlos, ya que el PID 4 está reservado para el sistema Un Saludo Pero igual se podria averiguar el PID  Por bruteforce  Solo por una discucion con karcrack Hendrix podrias decir si windows tiene mas poder en los drivers que ellos en el o si se tienen los mismos poderes ?
|
|
|
|
|
En línea
|
|
|
|
bizco
Desconectado
Mensajes: 698
|
sin escribir un solo byte, llama a loadlibrary desde modo kernel en el contexto de un proceso y observa que pasa. personalmente prefiero agotar todos los recursos en modo usuario, aun teniendo que hookear las funciones necesarias en cada proceso. un hook mediante VEH es invisible al usuario y a mucho software de seguridad pero es igual de efectivo que un jmp corriente.
|
|
|
|
« Última modificación: 22 Marzo 2010, 02:33 por ctlon »
|
En línea
|
|
|
|
RAID-MAM
Desconectado
Mensajes: 58
|
sin escribir un solo byte, llama a loadlibrary desde modo kernel en el contexto de un proceso y observa que pasa. personalmente prefiero agotar todos los recursos en modo usuario, aun teniendo que hookear las funciones necesarias en cada proceso. un hook mediante VEH es invisible al usuario y a mucho software de seguridad pero es igual de efectivo que un jmp corriente.
pues ya empezemos Toma un codigo que hice , no es muy complicado y la verdad bastante cutre Pero bueno mediante lo vallas saltando lo voy modificando , aclarar que este codigo es solo para que no lo puedas crachear inyectando en el tu famosa dll  Por cierto para inyectar una DLL necesitas igual escribir bytes include "win32ax.inc"
.code
start:
invoke GetModuleHandle , "ntdll.dll"
invoke GetProcAddress,eax,"ZwTerminateProcess"
mov ebx,eax
invoke VirtualProtect,ebx,Fin-Codigo ,PAGE_EXECUTE_READWRITE,OriginalProtection
stdcall cRtlMoveMemory,ebx,Codigo,Fin-Codigo
invoke GetModuleHandle , "ntdll.dll"
invoke GetProcAddress,eax,"LdrShutdownProcess"
mov ebx,eax
invoke VirtualProtect,ebx,Fin2-Codigo2 ,PAGE_EXECUTE_READWRITE,OriginalProtection
stdcall cRtlMoveMemory,ebx,Codigo2,Fin2-Codigo2
invoke SetUnhandledExceptionFilter,Siempre
invoke CreateThread , 0, 0,BucleReponedor,0,0 , 0
invoke ExitProcess,0
BucleReponedor:
invoke SetUnhandledExceptionFilter,Siempre
jmp BucleReponedor
Siempre:
invoke Sleep,-1
Codigo:
jmp Siempre
Fin = $
Codigo2:
jmp Siempre
Fin2 = $
proc MiLdrShutdownProcess
jmp Siempre
ret
endp
proc MiZwTerminateProcess,p1,p2
xor eax,eax
ret
endp
;Descripcion: Esta función funciona igual que la winapi RtlMoveMemory
; by YST
proc cRtlMoveMemory,cBuffer,Cpuntero,cCantidad
push esi edi
xchg edi,[cBuffer]
xchg esi,[Cpuntero]
.bucleb:
dec [cCantidad]
movsb
cmp [cCantidad],0
jge .bucleb
pop edi esi
ret
endp
.data
OriginalProtection dd ?
.end start Ensamblado en FASMW
|
|
|
|
|
En línea
|
|
|
|
bizco
Desconectado
Mensajes: 698
|
estas mezclando temas, digo que desde modo kernel no es necesario escribir en toda la memoria de el proceso. por otra parte, en el ultimo comentario hablaba de hooks invisibles al usuario. pero bueno, con DebugActiveProcess sobra para cerrar ese proceso sin necesidad de injectar una dll en el.
|
|
|
|
|
En línea
|
|
|
|
|
Hendrix
|
digo que desde modo kernel no es necesario escribir en toda la memoria de el proceso
Como dije, era por decir algo, evidentemente se pueden hacer otras cosas para crashear el proceso Solo por una discucion con karcrack Hendrix podrias decir si windows tiene mas poder en los drivers que ellos en el o si se tienen los mismos poderes ? Supongo que estas diciendo que si el "propio windows" (te refieres al Kernel de este) tiene más poderes que los drivers. La respuesta es que tienen los mismos, ya que los drivers son módulos de kernel. Se ejecutan en su mismo espacio y anillo que el Kernel (ya que son modulos, lo mismo que las Dll's sobre un proceso). Pero igual se podria averiguar el PID Por bruteforce En las pruebas que hicimos sch3m4 y yo modificábamos el PID que esta dentro de la estructura EPROCESS del proceso: nt!_EPROCESS
+0x000 Pcb : _KPROCESS
+0x06c ProcessLock : _EX_PUSH_LOCK
+0x070 CreateTime : _LARGE_INTEGER
+0x078 ExitTime : _LARGE_INTEGER
+0x080 RundownProtect : _EX_RUNDOWN_REF
+0x084 UniqueProcessId : Ptr32 Void
+0x088 ActiveProcessLinks : _LIST_ENTRY
...
...
...
Con esto, los 2 softwares testados (RU y IceSword) en la prueba no pudieron cerrar el proceso ya que, al ser el PID nº 4 de sistema no lo cerraban. Un Saludo
|
|
|
|
|
En línea
|
"Todos los días perdemos una docena de genios en el anonimato. Y se van. Y nadie sabe de ellos, de su historia, de su peripecia, de lo que han hecho, de sus angustias, de sus alegrías. Pero al menos una docena de genios se van todos los días sin que sepamos de ellos". - Juan Antonio Cebrián |
|
|
bizco
Desconectado
Mensajes: 698
|
logico, como dices si tu cambias el pid por otro existente realmente cuando pides informacion sobre este te va a dar informacion sobre el proceso que realmente tiene ese pid y no sobre el proceso modificado. pero si obtienes el pid en modo usuario te va a mostrar el real y no el falso (por ejemplo mediante la ventana).
SecMAM referente a tu codigo sin siquiera injectar ya te dije como cerrarlo, pero vamos que tampoco hablamos de 4 lineas que te pongan la cpu al 50%.... eso ni es un caso real ni es aplicable siquiera a malware. no hay que centrarse en que no se pueda, en tema malware me parece que interesa mas que no se enteren de que esta ahi.
|
|
|
|
|
En línea
|
|
|
|
APOKLIPTICO
Desconectado
Mensajes: 3.781
Toys in the attic.
|
Con esto, los 2 softwares testados (RU y IceSword) en la prueba no pudieron cerrar el proceso ya que, al ser el PID nº 4 de sistema no lo cerraban. Un Saludo El cambio de PID se hace en tiempo de ejecución, en el código o en el executable? o quizas desde otro programa? cual es el proceso a seguir? hay q usar drivers?
|
|
|
|
|
En línea
|
AMD Phenom II 1075T X6 @ 290 Mhz x 11 (HT 2036 Mhz NB Link 2616 Mhz) 1.23 Vcore
ASUS M4A89GTD-PRO/USB3
2x2gb G-Skill RipjawsX DDR3 1600 Mhz CL7 (7-8-7-24-25-1T)
Seagate 500 Gb
XFX HD4850 512Mb GDDR3. 650 Mhz/995 Mhz 1.1 Tflops.
|
|
|
bizco
Desconectado
Mensajes: 698
|
en tiempo de ejecucion logicamente. en principio si hay que usar drivers, aunque tb puede hacerse desde modo usuario pero es otro tema. arriba lo ponen como hacerlo, cambiandolo en la eprocess y ya esta. de este mismo modo puedes mostrar un nombre de ejecutable que realmente no esta ejecutandose, es algo parecido a el filename spoof del peb.
|
|
|
|
|
En línea
|
|
|
|
|
Hendrix
|
en tiempo de ejecucion logicamente. en principio si hay que usar drivers, aunque tb puede hacerse desde modo usuario pero es otro tema. arriba lo ponen como hacerlo, cambiandolo en la eprocess y ya esta. de este mismo modo puedes mostrar un nombre de ejecutable que realmente no esta ejecutandose, es algo parecido a el filename spoof del peb.
Exacto
|
|
|
|
|
En línea
|
"Todos los días perdemos una docena de genios en el anonimato. Y se van. Y nadie sabe de ellos, de su historia, de su peripecia, de lo que han hecho, de sus angustias, de sus alegrías. Pero al menos una docena de genios se van todos los días sin que sepamos de ellos". - Juan Antonio Cebrián |
|
|
|
 |
