Analyse dune attaque (partie 3)

Analyse d'une attaque (Partie 1)
Analyse d'une attaque (Partie 2)

Don Parker

Dans la partie 2 de cette série, nous avons laissé toutes les informations nécessaires requises pour une attaque sur le réseau de la victime. Ceci étant dit, passons à une attaque réelle. Cette attaque implique la transmission de plusieurs programmes de requêtes pour pouvoir aller plus loin dans l'exploitation d'une attaque.

Il serait inutile d'attaquer simplement un ordinateur puis de battre en retraite, nous allons donc lancer une attaque puissante. En général, l’objectif d’un attaquant malveillant n’est pas seulement d’accroître sa présence sur un réseau informatique, mais également de la maintenir. Cela signifie que l'attaquant souhaite continuer à cacher sa présence et effectuer d'autres actions.

Problèmes intéressants

Nous allons maintenant utiliser Metasploit Framework pour faciliter une véritable attaque. Ce mécanisme de travail est vraiment intéressant car il vous offre de nombreux types d'exploitation minière différents ainsi que de nombreuses options différentes lorsqu'il s'agit de choisir des charges utiles. Peut-être que vous ne voulez pas d'utilitaire inverse ou d'injection VNC. La charge utile dépend souvent de votre cible à venir, de l’architecture du réseau et de l’objectif final. Dans ce cas, nous le ferons avec une utilité inverse. C'est souvent l'approche la plus avantageuse, en particulier dans les cas où notre cible se trouve derrière le routeur et n'est pas directement accessible. Par exemple, vous « touchez » un serveur Web, mais la charge est toujours équilibrée. Il n'y a aucune garantie qu'il soit possible de s'y connecter avec un utilitaire de transfert, vous devrez donc que votre ordinateur génère un utilitaire inverse. Nous n'aborderons pas la manière d'utiliser Metasploit Framework, car cela a peut-être été abordé dans un autre article. Concentrons-nous donc sur des éléments tels que les niveaux de package.

Cette fois, au lieu d'utiliser la méthode consistant à présenter chaque étape d'attaque avec de brèves images et des extraits de code, nous présenterons une attaque différente. Ce qui sera fait est de recréer l'attaque avec l'aide de Snort. Nous allons tirer parti du journal binaire de l'attaque que nous avons effectuée, puis l'analyser via Snort. Idéalement, cela ressemblerait à tout ce que nous avons fait. En fait, ce qui sera mis en œuvre est un package de preuve. L’objectif ici est de voir avec quelle précision nous pouvons reconstituer ce qui s’est passé. Dans cet esprit, nous utiliserons le journal des paquets binaires qui a enregistré tout ce qui a été exécuté et l'analyserons via Snort en utilisant certaines de ses règles par défaut.

Sortie Snort

La syntaxe utilisée pour invoquer Snort est la suivante :

C:\snort\bin\snort.exe –r c:\article_binary –dv –c snort.conf –A full

Cette syntaxe amène Snort à analyser un paquet binaire appelé article_binary, le résultat est affiché ci-dessous. Nous avons tronqué la sortie Snort afin de pouvoir examiner chaque section en détail.

==============================================================
Snort processed 1345 packets.
==============================================================
Breakdown by protocol:
TCP: 524 (38.959%)
UDP: 810 (60.223%)
ICMP: 11 (0.818%)
ARP: 0 (0.000%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
ETHLOOP: 0 (0.000%)
IPX: 0 (0.000%)
FRAG: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
==============================================================
Action Stats:
ALERTS: 63
LOGGED: 63
PASSED: 0

Cette section est intéressante car 63 alertes ont été déclenchées par une action d'attaque. Nous allons examiner le fichier alert.ids, qui peut fournir de nombreux détails sur ce qui s'est passé. Maintenant, si vous vous souvenez, la première chose que l'attaquant a faite a été d'utiliser Nmap pour effectuer une analyse du réseau, ce qui a également créé la première alerte déclenchée par Snort.

[**] [1:469:3] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2]
08/09-15:37:07.296875 192.168.111.17 -> 192.168.111.23
ICMP TTL:54 TOS:0x0 ID:3562 IpLen:20 DgmLen:28
Type:8 Code:0 ID:30208 Seq:54825 ECHO
[Xref => http://www.whitehats.com/info/IDS162]

De cette façon, l'attaquant a utilisé netcat pour énumérer le serveur Web afin de découvrir de quel type de serveur Web il s'agit. Cette action n’a déclenché aucune alerte Snort. Nous voulons également savoir ce qui s'est passé, alors examinons de plus près le journal du package. Après avoir observé la procédure habituelle de négociation TCP/IP, nous verrons le paquet ci-dessous.

15:04:51.546875 IP (tos 0x0, ttl 128, id 9588, offset 0, flags [DF], proto: TCP (6), length: 51) 192.168.111.17.1347 > 192.168.111.23.80: P, cksum 0x5b06 (correct), 3389462932:3389462943(11) ack 2975555611 win 64240
0x0000: 4500 0033 2574 4000 8006 75d7 c0a8 6f11 E..3%[email protected].
0x0010: c0a8 6f17 0543 0050 ca07 1994 b15b 601b ..o..C.P.....[`.
0x0020: 5018 faf0 5b06 0000 4745 5420 736c 736c P...[...GET.slsl
0x0030: 736c 0a sl.

Il n'y a rien de remarquable dans ce package, si ce n'est qu'il contient une requête GET suivie de quelques problèmes internes comme slslsl par exemple. Donc en réalité, Snort n'a rien à faire. Il est donc très difficile de construire une signature IDS efficace (ou signature) pour déclencher ce type de tentative d'énumération. C’est pourquoi il n’y a pas de telles signatures. Le paquet suivant est celui dans lequel le serveur Web du réseau victime se répertorie.

Une fois l'énumération effectuée, l'attaquant envoie immédiatement un code pour exécuter l'exploit au serveur Web. Ce code donnera alors quelques résultats avec les signatures Snort activées. Spécifiquement pour l'exploit montré ci-dessous, nous pouvons voir cette signature Snort.

[**] [1:1248:13] WEB-FRONTPAGE rad fp30reg.dll access [**]
[Classification: access to a potentially vulnerable web application] [Priority:
2]08/09-15:39:23.000000 192.168.111.17:1454 -> 192.168.111.23:80
TCP TTL:128 TOS:0x0 ID:15851 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x7779253A Ack: 0xAA1FBC5B Win: 0xFAF0 TcpLen: 20
[Xref => http://www.microsoft.com/technet/security/bulletin/MS01-035.mspx][Xref
=> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-0341][Xref => http://www.s
ecurityfocus.com/bid/2906][Xref => http://www.whitehats.com/info/IDS555]

Une fois que l'attaquant a accédé au serveur Web, il commencera à utiliser le client TFTP pour transférer 4 fichiers : nc.exe, ipeye.exe, fu.exe, msdirectx.exe. Une fois ces fichiers transférés, l'attaquant utilise netcat pour renvoyer un utilitaire sur son ordinateur. À partir de là, il peut déconnecter l’autre utilitaire résultant de l’attaque initiale et effectuer tout le travail restant dans l’utilitaire netcat. Il est intéressant de noter qu’aucune des actions effectuées par l’attaquant via l’utilitaire inverse n’a été enregistrée par Snort. Cependant, indépendamment de cela, l'attaquant a utilisé un rootkit qu'il a transmis via TFTP pour masquer les informations de processus pour netcat.

Conclusion

Dans la troisième partie de cette série, nous avons vu une attaque démontrée utilisant Snort. Nous pouvons recréer complètement l’une des choses qui ont été faites, à l’exception de l’utilisation du rootkit. Même si l'IDS est une technologie très utile et fait partie de votre système de défense réseau, il n'est pas toujours parfait. Les IDS ne peuvent vous alerter que du trafic qu'ils peuvent détecter. Dans cet esprit, nous apprendrons à créer des signatures Snort dans la dernière partie de cette série. Parallèlement à cela, nous apprendrons également à tester une signature numérique (signature) pour évaluer son efficacité.