Infecte, mais je ne sais pas quoi faire...

JacK

20/05/2004 à 20:44

sur les news:1dg2vjcldemr$
Noshi signalait:

On Wed, 19 May 2004 19:35:57 +0200, LaDDL wrote:
Pour les autres types de trojans ca les arrêteras.
Tous les trojans sont détectables si on maitrise son environnement.

La détection a 100% n'existe pas.

Hello,

Jusqu'à présent, je n'ai pu trouver aucun trojan ou POC qui ait pu bypasser
SSM. Même Sasser et Blaster sur une machine non patchée et sans FW ne
peuvent passer avec son module svcguard.

Connaîtrais-tu un exécutable quelconque qui y arriverait ?
--
JacK

Roland Garcia

20/05/2004 à 20:52

sur les news:1dg2vjcldemr$
Noshi signalait:

La détection a 100% n'existe pas.

Jusqu'à présent, je n'ai pu trouver aucun trojan ou POC qui ait pu bypasser
SSM.

Parce que c'est toi qui décide en final de ce que tu installes ou pas.

Roland Garcia

JacK

20/05/2004 à 21:04

sur les news:
Roland Garcia signalait:

sur les news:1dg2vjcldemr$
Noshi signalait:

La détection a 100% n'existe pas.

Jusqu'à présent, je n'ai pu trouver aucun trojan ou POC qui ait pu
bypasser SSM.

Parce que c'est toi qui décide en final de ce que tu installes ou pas.

Roland Garcia

Oui, bien sûr et heureusement ;), mais dans le cas de Blaster ou de Sasser
par exemple, sans lui, je n'ai pas ce choix.
De même avec un Trojan non backdoor qui fatalement échappe aux FW, je vois
ce qu'il veut faire et j'accepte ou pas ou encore avec l'une ou l'autre
cochonceté ajoutée avec un joiner à un programme à installer. Je cherche
depuis un bon moment comment le bypasser, sans succès
jusqu'ici.
--
JacK

Noshi

20/05/2004 à 21:22

On Thu, 20 May 2004 20:44:16 +0200, JacK wrote:

sur les news:1dg2vjcldemr$
Noshi signalait:
On Wed, 19 May 2004 19:35:57 +0200, LaDDL wrote:
Pour les autres types de trojans ca les arrêteras.
Tous les trojans sont détectables si on maitrise son environnement.

La détection a 100% n'existe pas.

Hello,

Jusqu'à présent, je n'ai pu trouver aucun trojan ou POC qui ait pu bypasser
SSM. Même Sasser et Blaster sur une machine non patchée et sans FW ne
peuvent passer avec son module svcguard.

C'est quoi SSM ?

Connaîtrais-tu un exécutable quelconque qui y arriverait ?

Euh ... comme ca non...

--
Noshi

JacK

20/05/2004 à 21:37

sur les news:
Noshi signalait:
[...]> C'est quoi SSM ?
System Safety Monitor http://www.optimix.be.tf/ssm.htm (le site officiel
est extrèmement lent)
--
JacK

AMcD®

20/05/2004 à 21:52

Oui, bien sûr et heureusement ;), mais dans le cas de Blaster ou de
Sasser par exemple, sans lui, je n'ai pas ce choix.
De même avec un Trojan non backdoor qui fatalement échappe aux FW, je
vois ce qu'il veut faire et j'accepte ou pas ou encore avec l'une ou
l'autre cochonceté ajoutée avec un joiner à un programme à installer.
Je cherche depuis un bon moment comment le bypasser, sans succès
jusqu'ici.

Salut.

Heu c'est quoi le défi ? Parce que moi c'est plutôt l'inverse : je n'ai
jamais vu un FW ou autre truc du genre qu'on ne pouvait pas fermer,
injecter, hooker, etc. (des techniques, ils y en a des valises).

En gros, ça sert à quoi ssm là ? Le site rame et je suis pas trop patient
:o).

--
AMcD®

http://arnold.mcdonald.free.fr/

JacK

20/05/2004 à 23:40

sur les news:40ad0c86$0$26906$
AMcD® signalait:

Oui, bien sûr et heureusement ;), mais dans le cas de Blaster ou de
Sasser par exemple, sans lui, je n'ai pas ce choix.
De même avec un Trojan non backdoor qui fatalement échappe aux FW, je
vois ce qu'il veut faire et j'accepte ou pas ou encore avec l'une ou
l'autre cochonceté ajoutée avec un joiner à un programme à installer.
Je cherche depuis un bon moment comment le bypasser, sans succès
jusqu'ici.

Salut.

Heu c'est quoi le défi ? Parce que moi c'est plutôt l'inverse : je
n'ai jamais vu un FW ou autre truc du genre qu'on ne pouvait pas
fermer, injecter, hooker, etc. (des techniques, ils y en a des
valises).

En gros, ça sert à quoi ssm là ? Le site rame et je suis pas trop
patient
o).

C'st bien pourquoi j'ai fait un miroir pour le dl/ et les explications sur
la page indiquée ;)
--
JacK

JacK

21/05/2004 à 00:01

sur les news:
JacK signalait:

sur les news:40ad0c86$0$26906$
AMcD® signalait:
Oui, bien sûr et heureusement ;), mais dans le cas de Blaster ou de
Sasser par exemple, sans lui, je n'ai pas ce choix.
De même avec un Trojan non backdoor qui fatalement échappe aux FW,
je vois ce qu'il veut faire et j'accepte ou pas ou encore avec
l'une ou l'autre cochonceté ajoutée avec un joiner à un programme à
installer. Je cherche depuis un bon moment comment le bypasser,
sans succès jusqu'ici.

Salut.

Heu c'est quoi le défi ? Parce que moi c'est plutôt l'inverse : je
n'ai jamais vu un FW ou autre truc du genre qu'on ne pouvait pas
fermer, injecter, hooker, etc. (des techniques, ils y en a des
valises).

'lut,

Je ne parle pas d'un malware spécifique qui viserait SSM ou son module
svcguard, c'est bien sûr faisable, mais d'un trojan ou POC qui pourrait
être exécuté et/ou bypasser le firewall, injecter une dll ou du code dans un
process en cours sans qu'il ne le prévienne.
--
JacK

LaDDL

21/05/2004 à 00:39

Frederic Bonroy wrote:

Autrement dans le même esprit pourquoi ne traduis-tu pas
enfin/définitivement l'expression anglosaxone "safe hex" ? Alors que tu
pourrais la traduire en français par : savoir
administrer/entretenir/optimiser son système.

Pour la raison très simple que safe hex est
a) un jeu de mots difficilement traduisible
Je vous suggère : Les bonnes pratiques pour entretenir son PC.

b) trois fois plus cours qu'"administrer son système"
C'est vrai que cette expression est pas grand public. Mais la

proposition que je viens de vous faire ci-dessus me plaît assez.

Conernant l'utilisation d'anglicismes je n'ai aucun reproche à me faire;
vous me connaissez très mal. ;-)
Je voulais vous faire comprendre que l'on ne critique pas qqun parce

qu'il emploie des émoticons/smileys et autres jargons US juste pour
mettre une petite touche sympathique. IMHO pas de quoi en faire tout un
plat. Et encore moins troller ou flamer.

Premièrement tout le monde ne parle pas anglais
C'est un fait. Mais il faut aussi tenir compte de la réalité où la

pratique de l'anglais domine les échanges/relations des individus à
travers le monde. Les réseaux numériques n'en font pas exception.

Ici nous sommes sur un forum francophone, nous pouvons partir du
principe que tout le monde ici est capable de communiquer en français.
Ne déformez pas la réalité. Nous échangeons en français que je sache.

L'emploi de qq anglicismes sont là uniquement pour mettre une petite
touche originale/sympathique.

Raison de plus pour la parler correctement et où il se doit
(c'est-à-dire pas sur les forums francophones).
Vous rendez-vous compte de ce que vous venez d'écrire. Et vous osez

donner des leçons de bonne conduite sur Usenet. La jeunesse n'a plus
aucune courtoisie et notion du respect d'autrui.

En ce qui me concerne, je me suis très souvent aperçu que, de manière
générale, hein, je ne veux marcher sur les pieds de personne, les
ceusses qui z'y parlent comme ça sont incapables de sortir une vraie
phrase en bon anglais.
[Troll]

Non, vérité.
Vous êtes plein de certitudes. Vous avez encore besoin de maturité.

Pour satisfaire ta curiosité, ces mots sont de l'argot/jargon
familier/urbain employés par toutes les personnes qqsoit leur classe
sociale.

Ouais, je vois devant moi un sénateur adresser la parole à un général au
sujet des sévices en Irak et lui demander "and u dude what do u know"?
lol

Si es joueur en réseau, essaies ArmyOps (le jeu de l'armée US online) tu
ne seras pas deçu du voyage. ;)

Frederic Bonroy wrote:

Autrement dans le même esprit pourquoi ne traduis-tu pas
enfin/définitivement l'expression anglosaxone "safe hex" ? Alors que tu
pourrais la traduire en français par : savoir
administrer/entretenir/optimiser son système.

Pour la raison très simple que safe hex est
a) un jeu de mots difficilement traduisible
Je vous suggère : Les bonnes pratiques pour entretenir son PC.

b) trois fois plus cours qu'"administrer son système"
C'est vrai que cette expression est pas grand public. Mais la

proposition que je viens de vous faire ci-dessus me plaît assez.

Conernant l'utilisation d'anglicismes je n'ai aucun reproche à me faire;
vous me connaissez très mal. ;-)
Je voulais vous faire comprendre que l'on ne critique pas qqun parce

qu'il emploie des émoticons/smileys et autres jargons US juste pour
mettre une petite touche sympathique. IMHO pas de quoi en faire tout un
plat. Et encore moins troller ou flamer.

Premièrement tout le monde ne parle pas anglais
C'est un fait. Mais il faut aussi tenir compte de la réalité où la

pratique de l'anglais domine les échanges/relations des individus à
travers le monde. Les réseaux numériques n'en font pas exception.

Ici nous sommes sur un forum francophone, nous pouvons partir du
principe que tout le monde ici est capable de communiquer en français.
Ne déformez pas la réalité. Nous échangeons en français que je sache.

L'emploi de qq anglicismes sont là uniquement pour mettre une petite
touche originale/sympathique.

Raison de plus pour la parler correctement et où il se doit
(c'est-à-dire pas sur les forums francophones).
Vous rendez-vous compte de ce que vous venez d'écrire. Et vous osez

donner des leçons de bonne conduite sur Usenet. La jeunesse n'a plus
aucune courtoisie et notion du respect d'autrui.

En ce qui me concerne, je me suis très souvent aperçu que, de manière
générale, hein, je ne veux marcher sur les pieds de personne, les
ceusses qui z'y parlent comme ça sont incapables de sortir une vraie
phrase en bon anglais.
[Troll]

Non, vérité.
Vous êtes plein de certitudes. Vous avez encore besoin de maturité.

Pour satisfaire ta curiosité, ces mots sont de l'argot/jargon
familier/urbain employés par toutes les personnes qqsoit leur classe
sociale.

Ouais, je vois devant moi un sénateur adresser la parole à un général au
sujet des sévices en Irak et lui demander "and u dude what do u know"?
lol

Si es joueur en réseau, essaies ArmyOps (le jeu de l'armée US online) tu
ne seras pas deçu du voyage. ;)

Vous avez filtré cet utilisateur ! Consultez son message

Frederic Bonroy wrote:

Autrement dans le même esprit pourquoi ne traduis-tu pas
enfin/définitivement l'expression anglosaxone "safe hex" ? Alors que tu
pourrais la traduire en français par : savoir
administrer/entretenir/optimiser son système.

Pour la raison très simple que safe hex est
a) un jeu de mots difficilement traduisible
Je vous suggère : Les bonnes pratiques pour entretenir son PC.

b) trois fois plus cours qu'"administrer son système"
C'est vrai que cette expression est pas grand public. Mais la

proposition que je viens de vous faire ci-dessus me plaît assez.

Conernant l'utilisation d'anglicismes je n'ai aucun reproche à me faire;
vous me connaissez très mal. ;-)
Je voulais vous faire comprendre que l'on ne critique pas qqun parce

qu'il emploie des émoticons/smileys et autres jargons US juste pour
mettre une petite touche sympathique. IMHO pas de quoi en faire tout un
plat. Et encore moins troller ou flamer.

Premièrement tout le monde ne parle pas anglais
C'est un fait. Mais il faut aussi tenir compte de la réalité où la

pratique de l'anglais domine les échanges/relations des individus à
travers le monde. Les réseaux numériques n'en font pas exception.

Ici nous sommes sur un forum francophone, nous pouvons partir du
principe que tout le monde ici est capable de communiquer en français.
Ne déformez pas la réalité. Nous échangeons en français que je sache.

L'emploi de qq anglicismes sont là uniquement pour mettre une petite
touche originale/sympathique.

Raison de plus pour la parler correctement et où il se doit
(c'est-à-dire pas sur les forums francophones).
Vous rendez-vous compte de ce que vous venez d'écrire. Et vous osez

donner des leçons de bonne conduite sur Usenet. La jeunesse n'a plus
aucune courtoisie et notion du respect d'autrui.

En ce qui me concerne, je me suis très souvent aperçu que, de manière
générale, hein, je ne veux marcher sur les pieds de personne, les
ceusses qui z'y parlent comme ça sont incapables de sortir une vraie
phrase en bon anglais.
[Troll]

Non, vérité.
Vous êtes plein de certitudes. Vous avez encore besoin de maturité.

Pour satisfaire ta curiosité, ces mots sont de l'argot/jargon
familier/urbain employés par toutes les personnes qqsoit leur classe
sociale.

Ouais, je vois devant moi un sénateur adresser la parole à un général au
sujet des sévices en Irak et lui demander "and u dude what do u know"?
lol

Si es joueur en réseau, essaies ArmyOps (le jeu de l'armée US online) tu
ne seras pas deçu du voyage. ;)

AMcD®

21/05/2004 à 01:07

JacK wrote:

Je ne parle pas d'un malware spécifique qui viserait SSM ou son module
svcguard, c'est bien sûr faisable, mais d'un trojan ou POC qui
pourrait être exécuté et/ou bypasser le firewall, injecter une dll ou
du code dans un process en cours sans qu'il ne le prévienne.

Ha oui, OK.

Quelques mots sur le sujet quand même.

La majeure partie des injecteurs de processus passent par la fameuse
fonction CreateRemoteThread(). Oui, oui, la même qu'un gars causant de trucs
trop vachement dangereux à la Magic Lantern/Good Luck semble redécouvrir
dans chacun de ses articles. Bref...

Comment detecter ça ? On va pas livrer tous les secrets, mais il y a deux
techniques de base. Hooker (crocheter, détourner) et espionner. Hooker,
c'est detecter tous les appels à une fonction donnée. Le processus est
simple, tu captes l'appel de la fonction, tu fais ce que tu veux et tu rend
(ou pas d'ailleurs) la main à l'appelant de la focntion. Le problème est que
ce n'est pas franchement discret puisqu'il faut passer par une DLL pour
faire un hook system wide (heu, global quoi). Je viens d'ailleurs de jeter
un oeil très furtif à ton SSM et je vois qu'il possède 2 DLLs dans son
répertoire. Si tu examines la DLL mchook9x.dll par exemple, tu vois dans les
fonction exportées :

...
InstallHook()
RemoveHook()
...

que ça doit servir à heu, hooker nan ? ;o). Donc, DLL peu discrète et
facilement repérable puisqu'injectée dans tous les processus ! En plus, ça
pénalise un peu les performances du système puisque il y a une file
d'attente qui permet de gérer les appels des différents hookeurs. Enfin,
c'est facilement bypassable. Tu peux patcher la DLL par exemple... Ou
empêcher que la DLL soit chargée dans ton processus ! Mais bon, je ne vais
pas donner d'exemple, j'en connais encore un qui va m'écrire pour me faire
la morale :o).

La deuxième technique, bien plus fun va plaire à notre nouvel ami LaDDL.
C'est en effet basé sur le RE (Reverse Engineering), chose dont les bien
pensants très peu au fait de la sécurité informatique veulent nous priver.
C'est d'ailleurs une technique de procéder assez passe partout et
génératrice de résultats très rapidement. Dans un des derniers MISC, l'ami
Brulez l'utilise par exemple pour trouver ses failles dans des fonctions.

Ici, on ne va pas chercher des failles, mais chercher à comprendre comment
l'OS fonctionne (mon sport favori). En effet, le gros problème quand tu
utilises un programme qui hookes, c'est que tu vas être sans cesse dérangé
par une fenêtre t'indiquant que telle appli essaye d'utiliser telle
fonction. Or, ces appels peuvent être très légitimes car tous simplement
provenant de l'OS. En général, tu peux créer des règles vis-à-vis de
l'application, mais si tu n'as pas de log, tu perds la trace des appels ! Le
mieux est de deceler directement les appels louches. En plus imagine un peu
le désarroi d'un débutant : "l'application zmurf.exe essaye d'utiliser la
fonction zwCreateThread(). cette fonction peut s'avérer dangereuse,
autoriser o/n?"...

Pour cela il faut donc dépasser les techniques de hook des revues à 2
euros...

Tu désassembles donc la fonction. Dans 9 cas sur 10, tu vas repérer des tas
de paramètres bizarres. En effet, les fonctions Windows possèdent "deux
jeux" de paramètres. Pour simplifier, disons que la fonction CreateThread()
(je prends au hasard) n'est qu'un wrapper, appelant une autre fonction de
ntdll.dll, qui possèdent d'autres paramètres d'appels supplémentaires.
Suvent, en étudiant très attentivement le code, tu vas detecter des choses
intéressantes.

Par exemple, tu vas noter que toute création de thread sous Windows utilise
en fait CreateRemoteThread() (simplifions). Hein ? Ton sang ne fait alors
qu'un tour. C'est donc que FORCÉMENT, lors de l'appel, un paramètre va
permettre de distinguer les appels "simples" CreateThread() des appels
"sournois" CreateRemoteThread()...

Pour faire simple (et surtout de mémoire !), dans le code désassemblé tu
remarqueras qu'en fait un paramètre empilé est le noeud de l'affaire. En
gros, si avant le call à CreateRemoteThread() figure un push 0xffffffff,
c'est une création de thread normale... et un CreateRemoteThread() sinon !
Donc que vas tu faire, eh bien detecter les appels vi-à-vis de cette valeur
:o).

Pour celà il faut passer par un driver. En effet, tu ne peux pas patcher la
DLL, n'importe quel hacker à deux balles se contentant en général de
dupliquer le code des fonction système dans son propre code, t'es coincé. Si
tu connais l'excellentissime article de Mark Russinovich sur l'API native,
tu sais que les fonctions kernel sont, en gros, appelées via l'interrupion
int 2Eh. Il te faut donc hooker cette interruption. Plus exactement la
détourner. Eh oui ! Un bon vieux déroutement d'interruption comme à l'époque
du DOS. Snif, l'émotion m'étreint là :o).

Voilà, voilà. Je ne donne pas de lien ou d'article précis, on ne vas pas non
plus susciter les vocations... Certes, c'est assez chaud à faire, faut au
minimun savoir coder un driver et se dépatouiller avec le kernel, mais c'est
tout à fait faisable. Le gros problème étant que ce genre de technique est
très très très très très difficilement contrôlable et permet de faire
quasimment n'importe quoi.

Pourtant, une fois n'est pas coutume, il y a même un truc en français là
dessus. C'est un article de Daniel Dupard, dans un vieux Hackademytrucbidule
Mag (un de leurs rares gars crédible à mon humble avis). C'était il y a un
bail quand même, genre 1 an et demi ou plus. J'ai la flemme de chercher :o).

Un petit article élémentaire sur les hooks tout de même :

http://www.codeproject.com/system/hooksys.asp?df0&forumid602&exp=0&selectx9256

Et celui de Mark Russinovich sur l'api native :

http://www.sysinternals.com/ntw2k/info/ntdll.shtml

Dois-je enfin rappeler que tout hacker qui se respecte doit possèder ceci ?

http://www.amazon.fr/exec/obidos/ASIN/1578701996/qid%3D1085094324/402-7942381-7079362

Que l'on trouve à des tarifs misérables dans des revendeurs de livres de fin
de stock.

Voilou.

--
AMcD®

http://arnold.mcdonald.free.fr/

JacK wrote:

Je ne parle pas d'un malware spécifique qui viserait SSM ou son module
svcguard, c'est bien sûr faisable, mais d'un trojan ou POC qui
pourrait être exécuté et/ou bypasser le firewall, injecter une dll ou
du code dans un process en cours sans qu'il ne le prévienne.

Ha oui, OK.

Quelques mots sur le sujet quand même.

La majeure partie des injecteurs de processus passent par la fameuse
fonction CreateRemoteThread(). Oui, oui, la même qu'un gars causant de trucs
trop vachement dangereux à la Magic Lantern/Good Luck semble redécouvrir
dans chacun de ses articles. Bref...

Comment detecter ça ? On va pas livrer tous les secrets, mais il y a deux
techniques de base. Hooker (crocheter, détourner) et espionner. Hooker,
c'est detecter tous les appels à une fonction donnée. Le processus est
simple, tu captes l'appel de la fonction, tu fais ce que tu veux et tu rend
(ou pas d'ailleurs) la main à l'appelant de la focntion. Le problème est que
ce n'est pas franchement discret puisqu'il faut passer par une DLL pour
faire un hook system wide (heu, global quoi). Je viens d'ailleurs de jeter
un oeil très furtif à ton SSM et je vois qu'il possède 2 DLLs dans son
répertoire. Si tu examines la DLL mchook9x.dll par exemple, tu vois dans les
fonction exportées :

...
InstallHook()
RemoveHook()
...

que ça doit servir à heu, hooker nan ? ;o). Donc, DLL peu discrète et
facilement repérable puisqu'injectée dans tous les processus ! En plus, ça
pénalise un peu les performances du système puisque il y a une file
d'attente qui permet de gérer les appels des différents hookeurs. Enfin,
c'est facilement bypassable. Tu peux patcher la DLL par exemple... Ou
empêcher que la DLL soit chargée dans ton processus ! Mais bon, je ne vais
pas donner d'exemple, j'en connais encore un qui va m'écrire pour me faire
la morale :o).

La deuxième technique, bien plus fun va plaire à notre nouvel ami LaDDL.
C'est en effet basé sur le RE (Reverse Engineering), chose dont les bien
pensants très peu au fait de la sécurité informatique veulent nous priver.
C'est d'ailleurs une technique de procéder assez passe partout et
génératrice de résultats très rapidement. Dans un des derniers MISC, l'ami
Brulez l'utilise par exemple pour trouver ses failles dans des fonctions.

Ici, on ne va pas chercher des failles, mais chercher à comprendre comment
l'OS fonctionne (mon sport favori). En effet, le gros problème quand tu
utilises un programme qui hookes, c'est que tu vas être sans cesse dérangé
par une fenêtre t'indiquant que telle appli essaye d'utiliser telle
fonction. Or, ces appels peuvent être très légitimes car tous simplement
provenant de l'OS. En général, tu peux créer des règles vis-à-vis de
l'application, mais si tu n'as pas de log, tu perds la trace des appels ! Le
mieux est de deceler directement les appels louches. En plus imagine un peu
le désarroi d'un débutant : "l'application zmurf.exe essaye d'utiliser la
fonction zwCreateThread(). cette fonction peut s'avérer dangereuse,
autoriser o/n?"...

Pour cela il faut donc dépasser les techniques de hook des revues à 2
euros...

Tu désassembles donc la fonction. Dans 9 cas sur 10, tu vas repérer des tas
de paramètres bizarres. En effet, les fonctions Windows possèdent "deux
jeux" de paramètres. Pour simplifier, disons que la fonction CreateThread()
(je prends au hasard) n'est qu'un wrapper, appelant une autre fonction de
ntdll.dll, qui possèdent d'autres paramètres d'appels supplémentaires.
Suvent, en étudiant très attentivement le code, tu vas detecter des choses
intéressantes.

Par exemple, tu vas noter que toute création de thread sous Windows utilise
en fait CreateRemoteThread() (simplifions). Hein ? Ton sang ne fait alors
qu'un tour. C'est donc que FORCÉMENT, lors de l'appel, un paramètre va
permettre de distinguer les appels "simples" CreateThread() des appels
"sournois" CreateRemoteThread()...

Pour faire simple (et surtout de mémoire !), dans le code désassemblé tu
remarqueras qu'en fait un paramètre empilé est le noeud de l'affaire. En
gros, si avant le call à CreateRemoteThread() figure un push 0xffffffff,
c'est une création de thread normale... et un CreateRemoteThread() sinon !
Donc que vas tu faire, eh bien detecter les appels vi-à-vis de cette valeur
:o).

Pour celà il faut passer par un driver. En effet, tu ne peux pas patcher la
DLL, n'importe quel hacker à deux balles se contentant en général de
dupliquer le code des fonction système dans son propre code, t'es coincé. Si
tu connais l'excellentissime article de Mark Russinovich sur l'API native,
tu sais que les fonctions kernel sont, en gros, appelées via l'interrupion
int 2Eh. Il te faut donc hooker cette interruption. Plus exactement la
détourner. Eh oui ! Un bon vieux déroutement d'interruption comme à l'époque
du DOS. Snif, l'émotion m'étreint là :o).

Voilà, voilà. Je ne donne pas de lien ou d'article précis, on ne vas pas non
plus susciter les vocations... Certes, c'est assez chaud à faire, faut au
minimun savoir coder un driver et se dépatouiller avec le kernel, mais c'est
tout à fait faisable. Le gros problème étant que ce genre de technique est
très très très très très difficilement contrôlable et permet de faire
quasimment n'importe quoi.

Pourtant, une fois n'est pas coutume, il y a même un truc en français là
dessus. C'est un article de Daniel Dupard, dans un vieux Hackademytrucbidule
Mag (un de leurs rares gars crédible à mon humble avis). C'était il y a un
bail quand même, genre 1 an et demi ou plus. J'ai la flemme de chercher :o).

Un petit article élémentaire sur les hooks tout de même :

http://www.codeproject.com/system/hooksys.asp?df0&forumid602&exp=0&selectx9256

Et celui de Mark Russinovich sur l'api native :

http://www.sysinternals.com/ntw2k/info/ntdll.shtml

Dois-je enfin rappeler que tout hacker qui se respecte doit possèder ceci ?

http://www.amazon.fr/exec/obidos/ASIN/1578701996/qid%3D1085094324/402-7942381-7079362

Que l'on trouve à des tarifs misérables dans des revendeurs de livres de fin
de stock.

Voilou.

--
AMcD®

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

JacK wrote:

Je ne parle pas d'un malware spécifique qui viserait SSM ou son module
svcguard, c'est bien sûr faisable, mais d'un trojan ou POC qui
pourrait être exécuté et/ou bypasser le firewall, injecter une dll ou
du code dans un process en cours sans qu'il ne le prévienne.

Ha oui, OK.

Quelques mots sur le sujet quand même.

La majeure partie des injecteurs de processus passent par la fameuse
fonction CreateRemoteThread(). Oui, oui, la même qu'un gars causant de trucs
trop vachement dangereux à la Magic Lantern/Good Luck semble redécouvrir
dans chacun de ses articles. Bref...

Comment detecter ça ? On va pas livrer tous les secrets, mais il y a deux
techniques de base. Hooker (crocheter, détourner) et espionner. Hooker,
c'est detecter tous les appels à une fonction donnée. Le processus est
simple, tu captes l'appel de la fonction, tu fais ce que tu veux et tu rend
(ou pas d'ailleurs) la main à l'appelant de la focntion. Le problème est que
ce n'est pas franchement discret puisqu'il faut passer par une DLL pour
faire un hook system wide (heu, global quoi). Je viens d'ailleurs de jeter
un oeil très furtif à ton SSM et je vois qu'il possède 2 DLLs dans son
répertoire. Si tu examines la DLL mchook9x.dll par exemple, tu vois dans les
fonction exportées :

...
InstallHook()
RemoveHook()
...

que ça doit servir à heu, hooker nan ? ;o). Donc, DLL peu discrète et
facilement repérable puisqu'injectée dans tous les processus ! En plus, ça
pénalise un peu les performances du système puisque il y a une file
d'attente qui permet de gérer les appels des différents hookeurs. Enfin,
c'est facilement bypassable. Tu peux patcher la DLL par exemple... Ou
empêcher que la DLL soit chargée dans ton processus ! Mais bon, je ne vais
pas donner d'exemple, j'en connais encore un qui va m'écrire pour me faire
la morale :o).

La deuxième technique, bien plus fun va plaire à notre nouvel ami LaDDL.
C'est en effet basé sur le RE (Reverse Engineering), chose dont les bien
pensants très peu au fait de la sécurité informatique veulent nous priver.
C'est d'ailleurs une technique de procéder assez passe partout et
génératrice de résultats très rapidement. Dans un des derniers MISC, l'ami
Brulez l'utilise par exemple pour trouver ses failles dans des fonctions.

Ici, on ne va pas chercher des failles, mais chercher à comprendre comment
l'OS fonctionne (mon sport favori). En effet, le gros problème quand tu
utilises un programme qui hookes, c'est que tu vas être sans cesse dérangé
par une fenêtre t'indiquant que telle appli essaye d'utiliser telle
fonction. Or, ces appels peuvent être très légitimes car tous simplement
provenant de l'OS. En général, tu peux créer des règles vis-à-vis de
l'application, mais si tu n'as pas de log, tu perds la trace des appels ! Le
mieux est de deceler directement les appels louches. En plus imagine un peu
le désarroi d'un débutant : "l'application zmurf.exe essaye d'utiliser la
fonction zwCreateThread(). cette fonction peut s'avérer dangereuse,
autoriser o/n?"...

Pour cela il faut donc dépasser les techniques de hook des revues à 2
euros...

Tu désassembles donc la fonction. Dans 9 cas sur 10, tu vas repérer des tas
de paramètres bizarres. En effet, les fonctions Windows possèdent "deux
jeux" de paramètres. Pour simplifier, disons que la fonction CreateThread()
(je prends au hasard) n'est qu'un wrapper, appelant une autre fonction de
ntdll.dll, qui possèdent d'autres paramètres d'appels supplémentaires.
Suvent, en étudiant très attentivement le code, tu vas detecter des choses
intéressantes.

Par exemple, tu vas noter que toute création de thread sous Windows utilise
en fait CreateRemoteThread() (simplifions). Hein ? Ton sang ne fait alors
qu'un tour. C'est donc que FORCÉMENT, lors de l'appel, un paramètre va
permettre de distinguer les appels "simples" CreateThread() des appels
"sournois" CreateRemoteThread()...

Pour faire simple (et surtout de mémoire !), dans le code désassemblé tu
remarqueras qu'en fait un paramètre empilé est le noeud de l'affaire. En
gros, si avant le call à CreateRemoteThread() figure un push 0xffffffff,
c'est une création de thread normale... et un CreateRemoteThread() sinon !
Donc que vas tu faire, eh bien detecter les appels vi-à-vis de cette valeur
:o).

Pour celà il faut passer par un driver. En effet, tu ne peux pas patcher la
DLL, n'importe quel hacker à deux balles se contentant en général de
dupliquer le code des fonction système dans son propre code, t'es coincé. Si
tu connais l'excellentissime article de Mark Russinovich sur l'API native,
tu sais que les fonctions kernel sont, en gros, appelées via l'interrupion
int 2Eh. Il te faut donc hooker cette interruption. Plus exactement la
détourner. Eh oui ! Un bon vieux déroutement d'interruption comme à l'époque
du DOS. Snif, l'émotion m'étreint là :o).

Voilà, voilà. Je ne donne pas de lien ou d'article précis, on ne vas pas non
plus susciter les vocations... Certes, c'est assez chaud à faire, faut au
minimun savoir coder un driver et se dépatouiller avec le kernel, mais c'est
tout à fait faisable. Le gros problème étant que ce genre de technique est
très très très très très difficilement contrôlable et permet de faire
quasimment n'importe quoi.

Pourtant, une fois n'est pas coutume, il y a même un truc en français là
dessus. C'est un article de Daniel Dupard, dans un vieux Hackademytrucbidule
Mag (un de leurs rares gars crédible à mon humble avis). C'était il y a un
bail quand même, genre 1 an et demi ou plus. J'ai la flemme de chercher :o).

Un petit article élémentaire sur les hooks tout de même :

http://www.codeproject.com/system/hooksys.asp?df0&forumid602&exp=0&selectx9256

Et celui de Mark Russinovich sur l'api native :

http://www.sysinternals.com/ntw2k/info/ntdll.shtml

Dois-je enfin rappeler que tout hacker qui se respecte doit possèder ceci ?

http://www.amazon.fr/exec/obidos/ASIN/1578701996/qid%3D1085094324/402-7942381-7079362

Que l'on trouve à des tarifs misérables dans des revendeurs de livres de fin
de stock.

Voilou.

--
AMcD®

http://arnold.mcdonald.free.fr/

Infecte, mais je ne sais pas quoi faire...

10 réponses

Veuillez sélectionner un problème