Je me permets d'écrire un petit post après la publication du dernier article par mon jedi ; il concerne l'analyse d'un driver tout droit venu de l'orient.
En effet, sudami et son blog avait déjà interpellé notre ami Ivan, il contenait les sources d'un rootkit kerneland assez puissant d'après ce que les sources inspiraient.
Cette fois-ci il s'agit d'un PoC concernant une technique de DKOM afin de rendre un processus interminable ; du jamais vu pour ma part.
C'est pour cela qu'en dévorant ce jolie article, je me suis empressé de coder un PoC.
J'ai donc remarquer que lorsque le PoC était "complet", autrement dit toutes les modifications au niveau des structures étaient effectuées le processus était "inerte".
Interminable certes, mais un processus qui ne peux plus rien faire c'est assez embêtant, voir presque inutile (apart pour embeter la victime avec une fenêtre en plein milieu de l'écran..un peu à la sudami :)).
Celui-ci est disponible en fin de page bien évidemment.
Cependant, le fait que le processus était larvaire après avoir appliqué les manipulations de structures kernel, ivan me proposa de jouer en désactivant quelques "protections" afin d'obtenir un processus assez difficile à tuer mais un processus actif, une technique bien utile vous pouvez me croire dans le cadre d'un quelconque malware.
Pour moi l'implentation plus ou moins idéal reste de modifier le champ KernelApcDisable à l'offset 0x0d4 de la structure ETHREAD.
Concernant de plus amples explications concernant ces APCs kernel je vous suggère une petite lecture de l'analyse d'ivan.
Concernant l'activité que je peux avoir sur mon blog ces temps-ci, autrement dit, une activité assez limitée dirons nous, celle-ci est due à mon engagement dans divers projets qui verront leurs concrétisations dans quelques temps (avant la rentré j'esepère) wait and see .
Sinan en attendant je vous conseil quelques liens :
- #carib0u@irc.worldnet.net déjà :p.
- http://joe-is-a-rocknroll-star.blogspot.com/ -> une personne que j'apprécie beaucoup, des écrits clair toussa, continue :).
- http://md5.sh4ka.fr/ -> un service de très grande qualité codé par un très bon ami concernant la recherche de plaintext MD5 ; celui-ci possède en plus d'opérer à des recherches sur de multiples sites du même genre une base de donnée plutôt bien garnis et qui ne cesse de s'aggrandir !
- http://www.rootkit.com/ -> Faut peut-être pas l'oublier :).
Les PoCs :
- SudamiKillMe.c.
- SudamiKillMe Idéal (?).c.
Voilà pour les nouvelles, si vous trouvez mieux concernant cette technique je suis tout à fait preneur sur ce bonne soirée.
jeudi 17 juillet 2008
Sudami KillMe PoC.
Libellés :
apc kernel,
dkom process,
EPROCESS,
ethread,
killMe,
md5 sh4ka,
poc sudami,
processus immortel,
processus inkillable,
ring0,
sudami,
sudamiKillMe
Inscription à :
Publier les commentaires (Atom)
2 commentaires:
Salut 0verclock, j'ai pas encore lu l'article d'Ivan je le ferai cet aprem, mais juste une petite coquille : KernelApcDisable c'est dans KTHREAD, pas ETHREAD, si tu regardes le source du kernel tu vois qu'il manipule souvent que KTHREAD.
A+ je lirai ton poste aussi
Salut à toi,
Si on regarde la définition de la structure ETHREAD :
lkd> dt nt!_ETHREAD
+0x000 Tcb : _KTHREAD
+0x1c0 CreateTime : _LARGE_INTEGER
+0x1c0 NestedFaultCount : Pos 0, 2 Bits
+0x1c0 ApcNeeded : Pos 2, 1 Bit
+0x1c8 ExitTime : _LARGE_INTEGER
+0x1c8 LpcReplyChain : _LIST_ENTRY
+0x1c8 KeyedWaitChain : _LIST_ENTRY
+0x1d0 ExitStatus : Int4B
+0x1d0 OfsChain : Ptr32 Void
+0x1d4 PostBlockList : _LIST_ENTRY
+0x1dc TerminationPort : Ptr32 _TERMINATION_PORT
+0x1dc ReaperLink : Ptr32 _ETHREAD
+0x1dc KeyedWaitValue : Ptr32 Void
+0x1e0 ActiveTimerListLock : Uint4B
+0x1e4 ActiveTimerListHead : _LIST_ENTRY
+0x1ec Cid : _CLIENT_ID
+0x1f4 LpcReplySemaphore : _KSEMAPHORE
+0x1f4 KeyedWaitSemaphore : _KSEMAPHORE
+0x208 LpcReplyMessage : Ptr32 Void
+0x208 LpcWaitingOnPort : Ptr32 Void
+0x20c ImpersonationInfo : Ptr32 _PS_IMPERSONATION_INFORMATION
+0x210 IrpList : _LIST_ENTRY
+0x218 TopLevelIrp : Uint4B
+0x21c DeviceToVerify : Ptr32 _DEVICE_OBJECT
+0x220 ThreadsProcess : Ptr32 _EPROCESS
+0x224 StartAddress : Ptr32 Void
+0x228 Win32StartAddress : Ptr32 Void
+0x228 LpcReceivedMessageId : Uint4B
+0x22c ThreadListEntry : _LIST_ENTRY
+0x234 RundownProtect : _EX_RUNDOWN_REF
+0x238 ThreadLock : _EX_PUSH_LOCK
+0x23c LpcReplyMessageId : Uint4B
+0x240 ReadClusterSize : Uint4B
+0x244 GrantedAccess : Uint4B
+0x248 CrossThreadFlags : Uint4B
+0x248 Terminated : Pos 0, 1 Bit
+0x248 DeadThread : Pos 1, 1 Bit
+0x248 HideFromDebugger : Pos 2, 1 Bit
+0x248 ActiveImpersonationInfo : Pos 3, 1 Bit
+0x248 SystemThread : Pos 4, 1 Bit
+0x248 HardErrorsAreDisabled : Pos 5, 1 Bit
+0x248 BreakOnTermination : Pos 6, 1 Bit
+0x248 SkipCreationMsg : Pos 7, 1 Bit
+0x248 SkipTerminationMsg : Pos 8, 1 Bit
+0x24c SameThreadPassiveFlags : Uint4B
+0x24c ActiveExWorker : Pos 0, 1 Bit
+0x24c ExWorkerCanWaitUser : Pos 1, 1 Bit
+0x24c MemoryMaker : Pos 2, 1 Bit
+0x250 SameThreadApcFlags : Uint4B
+0x250 LpcReceivedMsgIdValid : Pos 0, 1 Bit
+0x250 LpcExitThreadCalled : Pos 1, 1 Bit
+0x250 AddressSpaceOwner : Pos 2, 1 Bit
+0x254 ForwardClusterOnly : UChar
+0x255 DisablePageFaultClustering : UChar
L'on voit en effet que le premier membre est une structure de type KTHREAD.
Par abus de language, j'ai donc dis
que ce champ était contenu dans ETHREAD.
Merci bien Taron, à plus.
Enregistrer un commentaire