3psilon website

Sommaire

 - Présentation
 - Résultat de l’intérieur
 - Résultat de l’extèrieur
 - Conclusion

Les tests réalisés l’on était avec Kaspersky Internet security 6.0.1.411. Je suis volontairement resté avec la configuration de KIS par défaut, je n’ai rien paramétré dans le module anti-hacker. Je posséde également un compte admistrateur sur le poste.

Objectif du test : Pouvoir arrêter la suite KIS et utiliser un programme accédant au réseau.

But du test : S’assurer que KIS est fonctionnel dans toutes les circonstances.

Les outils utilisés : (Seem),(IceSword), (Gmer).

Je lance Seem. KIS m’informe que Seem s’appréte à réaliser de l’injection de DLL. Je le bloque. Je décide de retirer le module ’Réseau’. J’arrive ensuite à lancer Seem avec le chargement du driver, sans message d’alerte. Pour terminer les processus, Seem utilise ZwTerminateProcess directement en noyau. Je n’arrive pas à terminer la suite : ’Accès refusé’.

C’est normal, en regardant de plus près, on voit que KIS hook plusieurs fonctions de la SSDT dont ZwTerminateProcess. Alors, pourquoi ne pas restaurer cette fonction pour éviter le crochettage ?

Je prends GMER. Lors du lancement, KIS me prévient : Gmer : "Suspicious driver installation". Etonnant, je n’ai pas eu ça avec Seem, la cause probable : Gmer inclus son driver dans l’exécutable pour l’extraire ensuite dans le system32/. J’accepte l’installation du driver. Je tente une restauration de la fonction ZwTerminateProcess : restauration réussie mais le ZwTerminateProcess reste inopérant. Je soupconne plusieurs redirections, de ce fait, une restauration seule ne suffirait pas. Je tente donc de restaurer d’autres fonctions >> BSoD.

Soit je tente plusieurs combinaisons de restauration, soit je cherche une autre méthode ... j’opte pour une autre méthode.

IceSword réalise un patch _inline de la fonction ZwTerminateProcess, alors pourquoi s’embêter à trouver la bonne combinaison des restaurations au risque de tomber sur plusieurs BSoD. Je prends donc IceSword. Au chargement, même message que pour GMER : "Suspicious driver installation". J’accepte l’installation du driver.

Et effectivement, avec ce procédé, on outre-passe le hook et il est possible de stopper la suite KIS.

Pour info, la visualisation des patchs _inline peut être donné par GMER :

Quels sont les effets produit dans le cas ou la suite est arrêtée ?

Bonne nouvelle : les règles déjà définies s’appliquent. Cela indique que les drivers chargés par KIS sont toujours actifs et réalise leur travail. Néanmoins, pour les nouveaux programmes n’ayant jamais été exécuté ... aucun barrage icon_surprised.gif , ils accèdent sans problème au net. Il aurait été intéressant pour KIS de bloquer tout nouveau programme dans le cas d’anomalie.

Que l’on ai pu arrêter la suite ou pas, toute tentative de connexion sera vouée à l’échec

07/01/2007 14:31:33 Scan.Generic.TCP ! Attacker’s IP address : 192.168.0.1. Protocol/service : TCP on local port 525. Time : 07/01/2007 14:31:33

Toute cette partie est dépendante de la configuration du module Anti-hacker.

Si l’on possède un exécutable avec son driver, en chargant le driver comme avec Seem (exe+sys), si ce driver réalise un patch _inline de ZwTerminateProcess : il est possible de stopper la suite KIS. Ensuite, plus aucun bloquage n’est réalisé, néanmoins les règles déjà existantes s’appliquent. Dans le cas ou la partie Anti-hacker laisse des trous, il est possible aux nouveaux programmes d’accèder à Internet ... cela fait quand même beaucoup de condition shifty.gif

Tous ces tests peuvent être traduit en une ligne :

Si la suite est arrêtée par un malware (ce qui est prouvée), plus aucune intéraction avec les nouvelles détections/intrusions n’est possible, elles seront donc dépendantes de la configuration réalisée en amont.