Een aanval analyseren (deel 3)

Een aanval analyseren (deel 1)
Een aanval analyseren (deel 2)

Don Parker

In deel 2 van deze serie hebben we alle benodigde informatie voor een aanval op het netwerk van het slachtoffer achtergelaten. Laten we, met dat in gedachten, overgaan tot een daadwerkelijke aanval. Bij deze aanval worden meerdere aanvraagprogramma's verzonden om de aanval verder te kunnen exploiteren.

Het heeft geen zin om een ​​computer aan te vallen en je dan terug te trekken. Daarom voeren we een krachtige aanval uit. Meestal is het doel van een kwaadwillende aanvaller niet alleen om zijn aanwezigheid op een computernetwerk te vergroten, maar ook om deze te behouden. Dat betekent dat de aanvaller zijn aanwezigheid nog steeds wil verbergen en andere acties wil uitvoeren.

Interessante kwesties

Nu gaan we het Metasploit Framework gebruiken om een ​​echte aanval uit te voeren. Dit werkingsmechanisme is erg interessant, omdat het je veel verschillende soorten mijnbouw biedt en ook veel verschillende opties wat betreft de keuze van de lading. Misschien wilt u geen omgekeerde utility of VNC-injectie. De payload hangt vaak af van het toekomstige doel, de netwerkarchitectuur en het einddoel. In dit geval doen we het met een omgekeerd hulpprogramma. Dit is vaak een voordeligere aanpak, vooral in gevallen waarin ons doelwit zich achter de router bevindt en niet direct toegankelijk is. Bijvoorbeeld, u “raakt” een webserver, maar de belasting is nog steeds in evenwicht. Er is geen garantie dat het mogelijk is om er met een forward-hulpprogramma verbinding mee te maken. Daarom wilt u dat uw computer een reverse-hulpprogramma genereert. We gaan hier niet in op het gebruik van het Metasploit Framework, omdat dit mogelijk al in een ander artikel is behandeld. Laten we ons dus concentreren op zaken als pakketniveaus.

Deze keer gebruiken we niet de methode waarbij elke aanvalsstap wordt geïntroduceerd met korte afbeeldingen en codefragmenten, maar presenteren we een andere aanval. Wat er gedaan zal worden, is de aanval nabootsen met behulp van Snort. We maken gebruik van het binaire logbestand in de aanval die we hebben uitgevoerd en verwerken het vervolgens via Snort. Idealiter zou het er hetzelfde uitzien als alles wat we gedaan hebben. Wat er feitelijk geïmplementeerd zal worden is een bewijspakket. Het doel is om te kijken hoe nauwkeurig we de gebeurtenissen kunnen reconstrueren. Met dat in gedachten gebruiken we het binaire pakketlogboek dat alle uitgevoerde bestanden registreert en parseren dit via Snort, op basis van enkele van de standaardregels.

Snort-uitvoer

De syntaxis die wordt gebruikt om Snort aan te roepen is als volgt:

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

Deze syntaxis zorgt ervoor dat Snort een binair pakket met de naam article_binary analyseert. Het resultaat ziet u hieronder. We hebben de Snort-uitvoer afgekapt, zodat we elke sectie in detail kunnen bekijken.

==============================================================
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

Dit gedeelte is interessant omdat er 63 waarschuwingen werden geactiveerd door één aanval. Laten we het bestand alert.ids bekijken, dat veel details kan verschaffen over wat er is gebeurd. Herinnert u zich nog dat de aanvaller als eerste een netwerkscan uitvoerde met Nmap? Dat creëerde ook de eerste waarschuwing die door Snort werd geactiveerd.

[**] [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]

Op deze manier gebruikte de aanvaller netcat om de webserver te inventariseren en zo te achterhalen wat voor type webserver het was. Deze actie heeft geen Snort-waarschuwingen geactiveerd. Omdat we graag willen weten wat er is gebeurd, bekijken we het logboek van het pakket eens nader. Nadat we de gebruikelijke TCP/IP-handshakeprocedure hebben bekeken, zien we het onderstaande pakket.

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.

Er is niets opmerkelijks aan dit pakket, behalve het feit dat het een GET-verzoek bevat met enkele interne problemen die daarop volgen, zoals bijvoorbeeld slslsl. In werkelijkheid heeft Snort dus niets te doen. Het is daarom erg moeilijk om een ​​effectieve IDS-handtekening (of handtekening) te construeren die dit soort opsommingspogingen in gang zet. Daarom bestaan ​​er geen dergelijke handtekeningen. Het pakket dat daarna volgt, is de lijst waarin de webserver van het slachtoffernetwerk zichzelf vermeldt.

Zodra de opsomming is uitgevoerd, stuurt de aanvaller onmiddellijk een code om de exploit uit te voeren naar de webserver. Deze code geeft dan resultaten met Snort-handtekeningen ingeschakeld. Specifiek voor de exploit die hieronder wordt getoond, zien we deze Snort-handtekening.

[**] [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]

Zodra de aanvaller toegang heeft tot de webserver, begint hij de TFTP-client te gebruiken om 4 bestanden over te dragen: nc.exe, ipeye.exe, fu.exe, msdirectx.exe. Zodra deze bestanden zijn overgedragen, gebruikt de aanvaller netcat om een ​​hulpprogramma terug naar zijn computer te sturen. Vanaf daar kan hij de andere hulpprogramma's die het resultaat zijn van de eerste aanval loskoppelen en alle resterende werkzaamheden in het netcat-hulpprogramma uitvoeren. Interessant genoeg werden geen van de acties die de aanvaller via het omgekeerde hulpprogramma uitvoerde, door Snort geregistreerd. Desondanks gebruikte de aanvaller een rootkit die hij via TFTP verstuurde om procesinformatie voor netcat te verbergen.

Conclusie

In deel drie van deze serie zagen we een gedemonstreerde aanval met behulp van Snort. We kunnen één van de dingen die gedaan zijn volledig reproduceren, maar dan met gebruik van de rootkit. Hoewel IDS een nuttig stukje technologie is en onderdeel van uw netwerkverdedigingssysteem, is het niet altijd perfect. IDS'en kunnen u alleen waarschuwen voor verkeer dat het systeem kan detecteren. Met dat in gedachten leren we in het laatste deel van deze serie hoe we Snort-handtekeningen kunnen bouwen. Daarnaast leren we hoe we een digitale handtekening (handtekening) kunnen testen om de effectiviteit ervan te beoordelen.