Archiv für Oktober, 2009

Das Laichen eine CMD-Eingabeaufforderung von MS Word oder Excel

15. Oktober 2009

Dies ist ein alter Trick, aber ich sehe noch eine Reihe von Administratoren, dass sie Benutzer aus der Eingabeaufforderung durch einfaches Entfernen Sie das Symbol aus dem Menü und dem Deaktivieren der Start-> Ausführen-Option gesperrt denken. In diesem Beitrag werde ich erörtern, wie Sie eine Eingabeaufforderung mit Visual Basic for Applications (VBA), und wie zu mildern (wenn auch nie vollständig zu beseitigen) das Risiko, von jemandem zu erreichen Zugriff auf die Eingabeaufforderung zu erstellen.

Erstellen Sie eine Eingabeaufforderung mit VBA

Diese Technik wird mit jeder Anwendung, VBA unterstützt die Arbeit, aber ich bin speziell werde Microsoft Word in meinem Beispiel zu verwenden. Hier ist was Sie tun müssen:

Starten Sie Microsoft Word
Drücken Sie die "ALT-F11" zu starten den VBA-Editor
Doppelklicken Sie auf "ThisDocument" im linken Bereich
Wenn das Editor-Fenster angezeigt wird, geben Sie den Text in Abbildung Nr. 1
Drücken Sie die Taste "F5"

Abbildung 1: Unsere einfache VB-Skript

Sie sollten ein Fenster der Eingabeaufforderung in der Taskleiste erscheinen. Hier ist eine Kopie des Codes müssen Sie in Schritt 4, so dass Sie kopieren können / paste:

Sub GetCMD ()
Shell "cmd.exe cmd.exe"
End Sub

Wie VBA aus Laich verhindern Sie eine Eingabeaufforderung

Die Ausführung der Eingabeaufforderung mit dem deaktiviert werden Gruppenrichtlinien-Editor -Tool. Hier sind die Schritte:

Klicken Sie auf Start -> Ausführen
Geben Sie "gpedit.msc" (ohne Anführungszeichen)
Klicken Sie auf Benutzerkonfiguration -> Administrative Vorlagen -> System
Suchen Sie in der Liste für "Zugriff auf die Eingabeaufforderung" und doppelklicken Sie darauf

Sie haben zwei Möglichkeiten zur Verfügung:

Aktivieren / Deaktivieren der Zugriff auf die Eingabeaufforderung
Ja / Nein Disable Eingabeaufforderung Scripting-Prozess

Wenn Sie nur deaktivieren die erste Option, den direkten Zugriff auf cmd.exe wird verhindert, sondern eine intelligente Benutzer kann weiterhin um es zu bekommen über eine Batch-Datei. Um zu verhindern, Zugriff auf das Skript, müssen Sie die zweite Option als auch deaktivieren. Dies verhindert, dass ALL-Scripting jedoch und kann leicht in viele Umgebungen spielen. Außerdem werden diese beiden Einstellungen auf dem Administrator-Konto als auch anzuwenden. Dies kann admin und Fehlersuche sehr viel schwieriger.

Auch mit den beiden Optionen deaktiviert, kann ein Benutzer immer noch um diese Einstellungen zu gelangen, indem command.com anstatt cmd.exe. Um dies zu beheben, müssen Sie den Zugriff auf command.com über Benutzerberechtigungen zu beschränken. Wenn Sie immer noch einige alte 16-Bit-Anwendungen, wird dieses Update zu brechen.

Alle diese Schritte nicht vollständig lösen das Problem jedoch. Ein Benutzer, was sie mit Debug Dabei kennt, kann einfach kopieren cmd.exe an einen anderen Ort und ändern Sie es so eine Aufforderung erreicht, wenn Sie es auf eine gefälschte Befehl auszuführen. So müssen wir auch "debug.exe" zu löschen.

Selbst dann kann eine versierte Programmierer erstellen eine ausführbare Datei zu umgehen, alle der oben genannten Sicherheits-Checks. Also müssen wir alle die Fähigkeit zu kopieren oder zu schreiben, um das Laufwerk als auch zu entfernen. Unnötig zu sagen, wir haben ein ziemlich nutzloses Computer an diesem Punkt.

Exec Zusammenfassung

Wenn jemand smart hat Zugriff auf Ihr System, ist es zweifelhaft, sind Sie in der Lage, ihn oder sie davor in der Befehlszeile zu verhindern. Die Gruppenrichtlinien-Editor können die meisten sicherlich erschweren, aber das Tool einfach reduziert das Risiko eines Angriffs. Sie können nicht vollständig eliminieren das Risiko, ohne ernsthaft behindert den Betrieb des Systems und Nützlichkeit.

Keine Kommentare »

Posted in 4-Ankündigung , Windows Security

Tags: windows command line Windows-Sicherheits- Fenster Tipps

PDF von "Schutz vor gezielten Angriffen" zu sprechen

14. Oktober 2009

Im Laufe der nächsten Wochen werde ich geben diesem Vortrag in einer Reihe von Standorten. Für diejenigen, und besuchte forderte eine PDF-Version der Folien möchten, hier ist der Link, den ich versprochen: Schutz-gegen gezielte Attacken-R2-

3 Kommentare »

Posted in 3-err , Allgemeine Sicherheit

Tags: Anwendung Whitelisting Malware

Tshark Challenge - Uber-Geek Antwort

13. Oktober 2009

In meinem letzten Beitrag habe ich links mit einer Frage: Angesichts dessen, was wir in der Dekodierung Datei mit tshark, welche Auswirkungen (wenn überhaupt) gäbe es, wenn wir eine Stateful Inspection Firewall zwischen dem Angreifer und dem Webserver Ort gesehen? Mit anderen Worten, wenn der Angreifer läuft ein Paket-Sniffer, würden sie immer noch die Web-Server ein Auslaufen von 404-Fehlern?

Und die Antwort ist ...

Vielleicht.

Nicht alle Stateful-Inspection-Firewalls sind gleich. Einige Griff Pakete etwas anders als andere. Zum Beispiel einige (wie Checkpoint, Netscreen und andere) lassen Nicht-SYN-Paketen zu ermöglichen Regeln erzeugen neue Staat Tabelleneinträge. Einige (Cisco, Netfilter und andere) erzeugt nur einen Staat Tabelle mit der richtigen Session-Aufbau (muss TCP drei Pakettypen Handshake zu sehen).

Die NIPS schickte eine gültige Reset-Paket an den Angreifer im Internet. Jede der oben genannten Firewalls würde die Reset-Paket und entfernen Sie den Eintrag aus dem Zustand Tisch. Wenn die Web-Server zu kommunizieren jedoch weiter, würde nur den ersten Satz von Firewalls lassen die Pakete austreten, um den Angreifer. Der zweite Satz von Firewalls würde einfach drop den Verkehr. In der Tat, wenn wir ihnen bei der Einrichtung mit einer deny-Regel statt eines Rückgangs der Regel würden sie die Sitzung auf dem Webserver zu töten damit das Problem zu lösen, indem die NIPS erstellt.

Warum haben manche Anbieter lassen Quittungspaketen erzeugen neuen Zustand Tabelleneinträge? Dies scheint ein wenig eingängig als eine legitime Sitzung immer los ist, mit einem SYN-Paket zu starten. Es gibt zwei Gründe dies macht gute funktionelle Sinn:

Die Aktualisierung der Firewall-Regeln nicht umbringt aktiven Sitzungen
Active-Active-Setup wird der Verkehr vor pass auf staatliche Tabelle sync

Natürlich haben wir die Funktionalität auf Kosten der Sicherheit erhöht. Leider ist die typische Trade-off.

Hoffe, Sie hatten Spaß mit dieser Herausforderung. Wenn Interesse besteht werde ich nach mehr in die Zukunft.

2 Kommentare »

Posted in 2-Alarm , Network Security , Packet Decoding

Tags: Firewall Netzwerksicherheit Packet Decoding

Tshark Challenge - The Final Antworten

9. Oktober 2009

In meinem letzten Beitrag hatten wir festgestellt, dass die Trace-Datei einer Sitzung, in einem einzigen geschliffen netzwerkbasierte Intrusion Prevention-System versucht, einen Angriff von einem HTTP-Client auf einem Webserver zu stoppen enthalten hatte. Wir schlossen daraus, dass der Client die Daten angefordert hat Blick eher verdächtig, und erwies sich das System eines Dritten (der NIPS) war verantwortlich für die Reset-Pakete während der Sitzung übermittelt.

In diesem Beitrag müssen wir noch zwei Fragen beantworten:

War der Angriff erfolgreich?
Warum hat die Web-Server ignorieren die TCP-Reset-Packet von der NIPS übertragen?

War der Angriff erfolgreich?

Der Angreifer war auf der Suche um herauszufinden, ob die Datei "startstop.html" in der "Administrator"-Verzeichnis wurde. Werfen wir einen Blick auf eines der Pakete an den Angreifer nach dem Reset-Pakete übermittelt wurden:

tshark-n-r challenge1.cap-x frame.number == 11
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
0000 00 50 8b EA 20 ab 00 b0 d0 20 7d e3 08 00 45 00. P.. .... } ... E.
0010 01 a7 37 47 40 00 40 06 73 8b 21 0c f7 04 94 4e .. 7G @. @. S..! ... N
0020 f7 0a 00 50 69 2a 3a 88 39 cd 6a 97 b9 4c 80 19 ... Pi *:.. 0,9 j. L..
0030 19 20 8c d4 00 00 01 01 08 0a 3d 76 0e d3 00 EC. ... ... ..= V ....
0040 48 4b 48 54 54 50 2f 31 2e 31 20 34 30 34 20 4e HKHTTP/1.1 404 N
0050 6f 74 20 46 6f 75 6e 64 0D 0A 44 61 74 65 3a 20 ot gefunden .. Datum:
0060 54 75 65 2c 20 32 35 20 4a 75 6e 20 32 30 30 32 Tue, 25 Juni 2002
0070 20 30 30 3a 33 34 3a 35 38 20 47 4d 54 0d 0a 53 00.34.58 GMT .. S
0080 65 72 76 65 72 3a 20 41 70 61 63 68 65 0d 0A 43 erver: Apache .. C
0090 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f 73 65 nschluss: close
00A0 0d 0A 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 .. Content-Type:
00B0 74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 61 72 73 text / html; chars
00C0 65 74 3d 69 73 6f 2d 38 38 35 39 2d 31 0D 0A 0D et = iso-8859 bis 1 ...
00d0 0a 3c 21 44 4f 43 54 59 50 45 20 48 54 4d 4c 20. <! DOCTYPE HTML
00e0 50 55 42 4c 49 43 20 22 2d 2f 2f 49 45 54 46 2f PUBLIC "- / / IETF /
00f0 2f 44 54 44 20 48 54 4d 4c 20 32 2e 30 2f 2f 45 / DTD HTML 2.0 / / E
0100 4e 22 3e 0a 3c 48 54 4d 4c 3e 3c 48 45 41 44 3e N ">. <HTML> <HEAD>
0110 0a 3c 54 49 54 4c 45 3e 34 30 34 20 4e 6f 74 20. <TITLE> 404 Not
0120 46 6f 75 6e 64 3c 2f 54 49 54 4c 45 3e 0a 3c 2f Found </ TITLE>. </
0130 48 45 41 44 3e 3c 42 4f 44 59 3e 0a 3c 48 31 3e HEAD> <BODY>. <H1>
0140 4e 6f 74 20 46 6f 75 6e 64 3c 2f 48 31 3e 0a 54 Nicht Found </ H1>. T
0150 68 65 20 72 65 71 75 65 73 74 65 64 20 55 52 4c er angeforderte URL
0160 20 2f 63 66 69 64 65 2f 41 64 6d 69 6e 69 73 74 / CFIDE / Administ
0170 72 61 74 6f 72 2f 73 74 61 72 74 73 74 6f 70 2e rator / StartStopp.
0180 68 74 6d 6c 20 77 61 73 20 6e 6f 74 20 66 6f 75 html nicht fou
0190 6e 64 20 6f 6e 20 74 68 69 73 20 73 65 72 76 65 nd auf dieser dienen
01a0 72 2e 3c 50 3e 0a 3c 2f 42 4f 44 59 3e 3c 2f 48 r. <P>. </ BODY> </ H
01b0 54 4d 4c 3e 0a 00 03 00 07 TML> ... ..

So die Antwort auf die Angreifer auf die Frage, "Ist die Datei auf dem Server befindet, ist in jedem Paket des Servers an den Client nach dem Reset-Pakete ausgegeben wurden beantwortet?. Nun stellt sich die Frage, hat der Angreifer sehen, diese Informationen?

Wenn Sie die Reset-Paket an den Angreifer geschickt wurde, sollte die Reset der TCP-Sitzung getötet haben. Dies bedeutet, dass, wenn diese Daten angekommen, der empfangende Port (TCP/26922) sollten in einem geschlossenen Zustand gewesen sein. Wäre dies tatsächlich wahr gewesen, würde ich erwarten, um zu sehen, ein Reset / ACK auf dem Rückweg von dem Angreifer das System sagt uns, dass TCP/26922 ist jetzt geschlossen. Wir sehen nie die Pakete.

Warum also nicht den entfernten Port zu schließen? Die Reset-Paket gültig ist, so sollte es die Sitzung beendet haben. Eine versierte Angreifer wird ein Paket-Sniffer im Hintergrund laufen, während Sie ihren Angriff. Es ist möglich, dass der Angreifer herausgefunden haben, was los war und einfach erstellt eine Firewall-Regel auf ihren Angriff System Herausfiltern aller eingehenden Reset-Pakete. Dies würde ihr Werkzeug erlaubt haben, um weiter funktionieren. Auch ohne die Firewall-Regeln ihre Paket-Sniffer würde die Antworten, die sie suchen, enthalten. So gibt es eine sehr gute Chance, der Angreifer hat, was wir sind anfällig für rechnete, trotz der Tat ein NIPS ist der Schutz des Netzwerks.

Warum hat die Web-Server ignorieren Sie die Reset-Paket?

Unsere letzte Frage ist, warum hat die Web-Server ignorieren Sie die Reset-Paket von der NIPS geschickt. Dies führt zu zwei Problemen:

Die Info der Angreifer wollte sich weiter austreten
Wenn der Angreifer mehrere Datei-Sonden konnten sie füllen die Session-Tabelle auf dem Webserver

Der zweite Punkt ist ein wenig beängstigend, weil es eigentlich die NIPS wodurch der Schutz vor DoS-Angriff wäre nur durch das Töten der einen Seite der Verbindung korrekt. Also selbst wenn wir gepatcht wurden und up to date, Lieferanten Gang, den wir bezahlt Geld für enden würde, tötet unsere Web-Server. Gee Ich hasse es, wenn ich Geld, um DoS mir zu verbringen.

Nehmen wir noch einen Blick auf die Reset-Pakete:

tshark-n-r challenge1.cap frame.number == 6 oder frame.number == 7
6 0.031319 12.33.247.4 -> 148.78.247.10 TCP 80> 26922 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
7 0.031385 148.78.247.10 -> 12.33.247.4 TCP [TCP ACK verloren Segment] 26922> 80 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0

Beachten Sie, dass tshark sagt uns Paket 7 ist ein verlorener Segment. In anderen Worten, tshark sagen uns, dass die TCP-Sequenznummer nicht innerhalb des Fensters den Host erwartet. Ein Blick auf die Reihenfolge und bestätigen Zahlen erklärt, warum. Die Werte sind identisch mit denen im Paket 6. Sie können aus dem letzten Beitrag nicht vergessen, dass Paket 6 und 7 hatten auch die gleiche IP-ID-Wert (45.298).

So scheint es, dass hier was passiert ist:

Client eine HTTP-Angriff auf unsere Web-Server
NIPS erkannt Angriff
NIPS schickte eine gültige TCP-Reset, um den Angreifer, um die Sitzung zu töten
NIPS vertauscht die Quell-und Ziel-IP-Adressen im Paket, neu berechnet die CRC, und dann an der gleichen wieder auf den Web-Server
Web-Server ignoriert das zurückgesetzt, da sie nicht enthalten ein akzeptables Sequenznummer

Vielleicht fragen Sie sich: "Wie hat der Verkäufer zu verpassen?". Meine beste Vermutung ist, dass der Verkäufer einige simulierte Angriffe liefen, die Angriffs-Tool nicht zeigen, sie anfällig Dateien, so dass sie davon ausgegangen war alles OK arbeitet. In anderen Worten, ein Anbieter, der ein Produkt zu Netzwerken auf den Draht zu schützen geschaffen nie die Mühe gemacht zu schauen, was ihr Produkt tatsächlich tat auf den Draht zu suchen. Hummm ...

Bonus Frage

OK, wenn Sie Spaß mit diesem, hier ist ein Bonus-Frage zu beantworten, die endgültig beweisen Sie Ihre uber-Aussenseiter-Status auf dem Gipfel des geheimen Pyramide:

Nehmen wir statt eine Stateful Inspection Firewall zwischen diesem Subnetz und den Angreifer. Will der Angreifer noch in der Lage sein, die Antworten mit einem Packet-Sniffer zu sehen?

Ich werde nach der Antwort nächste Woche.

Keine Kommentare »

Posted in 2-Alarm , Packet Decoding

Tags: Packet Decoding

Tshark Challenge - Hinweise 4

8. Oktober 2009

In meinem letzten Beitrag haben wir festgestellt, dass das Client-System war wahrscheinlich läuft eine Art Werkzeug, um auf bekannte gefährdete Dateien Sonde. Wir haben immer noch die Reset-Pakete jedoch zu erklären, als auch, warum der Server war, sie zu ignorieren.

Im Moment haben wir nicht einmal wissen, wo diese Paketerfassung in Bezug auf die beiden Endpunkte wurde. Ich werde tshark laufen mit dem "T-fields"-Schalter zum Ausdrucken der TTL Information. Durch die Analyse der TTLs, sollten wir in der Lage sein zu bestimmen, wo wir im Verhältnis zu dem Client und dem Server Sniffing. Ich bin auch zum Ausdrucken der IP-IDs, um zu sehen, ob es irgendwelche Auffälligkeiten im Paket bestellen sind.

Hier ist die Befehls-und Ausgang:

tshark-r challenge1.cap-T Felder-e frame.number-e ip.src-e tcp.srcport-e ip.ttl-e ip.id
1 148.78.247.10 26922 49 0x2a6b
2 12.33.247.4 80 64 0 × 0000
3 148.78.247.10 26922 49 0x2a95
4 148.78.247.10 26922 49 0x2a96
5 12.33.247.4 80 64 0 × 3743
6 12.33.247.4 80 255 0xb0f2
7 148.78.247.10 26922 255 0xb0f2
8 12.33.247.4 80 64 0 × 3744
9 12.33.247.4 80 64 0 × 3745
10 12.33.247.4 80 64 0 × 3746
11 12.33.247.4 80 64 0 × 3747
12 12.33.247.4 80 64 0 × 3748
13 12.33.247.4 80 64 0 × 3749
14 12.33.247.4 80 64 0x374a
15 12.33.247.4 80 64 0x374b
16 12.33.247.4 80 64 0x374c
17 12.33.247.4 80 64 0x374d

148.78.247.10 ist der Client. Wir wissen, dass, weil es die Sitzung initiiert hat und dessen Kommunikation über eine obere Quell-Port. 12.33.247.10 ist unser HTTP-Server kommuniziert über Port 80.

In Paket 1 sehen wir die Client verfügt über eine TTL von 49 Jahren. Der nächste Start TTL Übereinstimmung für ein bekanntes Betriebssystem ist 64, so dass dies sagt uns der Kunde ein Linux-, UNIX-oder Mac-System sitzen 15 Hops entfernt. In Paket 2 sehen wir den Server mit einem TTL-Wert von 64, also muss es einer der zuvor genannten Betriebssysteme sitzen auf dem lokalen Netzwerk befinden. Also, wir sind auf dem gleichen Kollision Domäne wie der Server, sondern saß 15 Hops vom Client.

Es gibt ein Problem jedoch. Schauen Sie sich Pakete 6 und 7. Hier sehen wir die TTL beider Systeme ändern zu 255. Ein OS wird sich nie ändern ist es TTL während einer Sitzung, so sieht das sehr suspekt. Darüber hinaus haben wir bereits festgestellt, dass der Kunde sitzt 15 Hops von uns entfernt. 255 ist die größtmögliche TTL-Wert als das TTL-Feld nur ein einziges Byte (Byte 8 im IP-Header). Also auch wenn die Quell-IP-Adresse Ansprüche auf den Remote-Client sein, es gibt keine Möglichkeit das Paket könnte überall, sondern aus dem lokalen Netzwerk stammen. Wenn das Paket einen oder mehrere Router überquert hatte, würde der TTL-Wert niedriger sein.

Die IP-ID-Informationen nicht richtig entweder zu suchen. In den ersten drei Pakete vom Client sehen wir die IP-ID-Werte 0x2a6b (10859), 0x2a95 (10.901) und 0x2a96 (10.902). Dies sagt uns der Kunde möglicherweise mit einer +1 inkrementelle IP ID, wir hatten einfach nicht sehen, 42 der Pakete zwischen dem ersten und zweiten Paket übertragen. Die nächste IP ID sehen wir aus der Client 0xb0f2 (45.298). OK, es sei denn, wir über 34.000 Pakete vermisst, ist diese IP-ID nicht jive.

Beachten Sie die obige Analyse wäre nur theoretisch gäbe es nicht die uneinheitliche TTL-Werte. Mit nur drei Pakete zu betrachten, können wir nicht genau identifizieren die IP-ID zu erhöhen. Es ist auch möglich, aber sehr sehr unwahrscheinlich, dass die IP-ID Inkrement völlig zufällig ist und das System nur zufällig zwei inkrementellen IP-IDs, einer nach dem anderen zuweisen. Dennoch verbinden die TTL und IP-ID-Informationen zusammen und sie zeigen, dass dieses letzte Paket konnte nicht aus dem gleichen System stammen.

Wir haben mehrere IP-ID-Daten vom Server zu arbeiten, also nehmen wir mal einen Blick auf die. Die IDs sind:

0 (0)
0 × 3743 (14147)
0xb0f2 (45298)
0 × 3744 (14148)
0 × 3745 (14149)
0 × 3746 (14150)
0 × 3747 (14151)
0 × 3748 (14152)
0 × 3749 (14153)
0x374a (14154)
0x374b (14155)
0x374c (14156)
0x374d (14157)

Werfen Sie einen Blick auf die dritte aufgeführten IP-ID, die vom Paket-6 in der Spur ist. Beachten Sie, dass alle anderen IP-IDs inkrementelle +1 sind, aber das IP ID nicht angehört. In der Tat können wir zeigen, dass der Server erhöht sie IP ID um +1 und das ist gibt es keine Möglichkeit dieses Paket vom Server stammen.

Humm. Ich frage mich, ob dieser Verdacht Pakete Line-Up mit den seltsamen setzt sahen wir:

tshark-r challenge1.cap-T Felder-e frame.number-e ip.src-e tcp.srcport-e ip.ttl-e ip.id-e tcp.flags.reset
1 148.78.247.10 26922 49 0x2a6b 0
2 12.33.247.4 80 64 0 × 0000 0
3 148.78.247.10 26922 49 0x2a95 0
4 148.78.247.10 26922 49 0x2a96 0
5 12.33.247.4 80 64 0 × 3743 0
6 12.33.247.4 80 255 0xb0f2 1
7 148.78.247.10 26922 255 0xb0f2 1
8 12.33.247.4 80 64 0 × 3744 0
9 12.33.247.4 80 64 0 × 3745 0
10 12.33.247.4 80 64 0 × 3746 0
11 12.33.247.4 80 64 0 × 3747 0
12 12.33.247.4 80 64 0 × 3748 0
13 12.33.247.4 80 64 0 × 3749 0
14 12.33.247.4 80 64 0x374a 0
15 12.33.247.4 80 64 0x374b 0
16 12.33.247.4 80 64 0x374c 0
17 12.33.247.4 80 64 0x374d 0

Ah ha! Also, wenn wir die Pakete mit dem seltsamen TTL und IP ID-Werte aussehen, das waren die seltsamen Reset-Pakete während der Sitzung übermittelt.

Es sieht für mich wie ein drittes System wird in das Gespräch springen, um die Reset-Pakete zu übertragen. Da diese seltsame Pakete eine TTL von 255 haben, wissen wir, es muss auf demselben Kollisionsdomäne wie, wo wir sind Sniffing werden. Da es auf dem gleichen Kollisionsdomäne ist, kann der Ethernet-Header-Informationen hilfreich sein:

tshark-r challenge1.cap-T Felder-e frame.number-e eth-e tcp.flags.reset
1 Ethernet II, Src: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3) 0
2 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0
3 Ethernet II, Src: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3) 0
4 Ethernet II, Src: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3) 0

5 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0
6 Ethernet II, Src: D-Link_8f: e0: 0c (00:50: ba: 8f: e0: 0c), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 1
7 Ethernet II, Src: D-Link_8f: e0: 0c (00:50: ba: 8f: e0: 0c), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3) 1
8 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0
9 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0
10 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0
11 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0
12 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0
13 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0
14 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0
15 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0
16 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0
17 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

So, wenn der Client aus dem Internet kommt, durchläuft es ein HP-System als entweder einen Router oder eine Firewall. Unser Web-Server auf Dell-Hardware läuft. Beachten Sie unsere zurückgesetzt (Pakete 6 und 7) sind beide durch das gleiche System mit einem D-Link NIC generiert.

Warum haben die D-Link-System versuchen, die Sitzung zu töten? Dies geschah kurz nach den Client gesendet die verdächtige Datei anfordern. Es sieht für mich wie die D-Link System ist eigentlich ein einziges geschliffen Intrusion Prevention System (IPS). Wenn ein Angriff erkannt wird, versucht das IPS den Angriff durch die Übertragung von Reset-Pakete an beiden Enden der Verbindung zu verhindern.

Aber wir haben noch einige unbeantwortete Fragen. War der Angriff erfolgreich und warum der Server scheinen die IPS Versuch, die Sitzung zu töten ignorieren?

Biegen Sie in die nächste Episode, um herauszufinden.

Keine Kommentare »

Posted in 2-Alarm , Packet Decoding

Tags: Packet Decoding

Tshark Challenge - Hinweise 3

7. Oktober 2009

Dies ist der dritte Satz von Hinweisen auf die tshark entschlüsseln Herausforderung, die ich letzte Woche veröffentlichten. Sie können eine Kopie der Dekodierung Datei packen die Herausforderung Seite .

In meinem letzten Beitrag entdeckten wir einige Unstimmigkeiten ist der TCP-Stream. Werfen wir einen genaueren Blick auf die Nutzlast zu sehen, ob alles sieht fehl am Platz. Der Befehl, den ich verwenden werde ist:

tshark-r challenge1.cap-x | less

Wenn Sie unter Windows ausgeführt werden, ersetzen Sie die "weniger"-Befehl mit dem Befehl "more".

Die "-x"-Schalter führt zu tshark der Payload jedes Paket zusammen mit dem Header Übersicht zu drucken. Wenn Sie Seite nach unten auf Paket 4 Sie sehen sollten:

4 0.030787 148.78.247.10 -> 12.33.247.4 HTTP GET / CFIDE / Administrator / startstop.html HTTP/1.0
0000 00 b0 d0 20 7d e3 00 50 8b EA 20 ab 08 00 45 00 ...} .. P.. ... E.
0010 01 11 2a 96 00 00 31 06 cf d2 94 4e f7 0a 0c 21 ..* ... 1 .... N ...!
0020 f7 04 69 2a 00 50 6a 97 b8 6f 3a 88 39 cd 80 18 .. i *. Pj .. o: .9 ...
0030 ff ff 42 fc 00 00 01 01 08 0a 00 ec 48 4b 3d 76 .. B ... ... ... HK = v
0040 0e 8b 47 45 54 20 2f 63 66 69 64 65 2f 41 64 6d .. GET / CFIDE / Adm
0050 69 6e 69 73 74 72 61 74 6f 72 2f 73 74 61 72 74 inistrator / start
0060 73 74 6f 70 2e 68 74 6d 6c 20 48 54 54 50 2f 31 stop.html HTTP / 1
0070 2e 30 0D 0A 48 6f 73 74 3a 20 31 32 2e 33 33 2e .0 .. Host-: 12.33.
0080 32 34 37 2e 34 0d 0a 55 73 65 72 2d 41 67 65 6e 247,4 .. User-Agen
0090 74 20 3a 4d 6f 7a 69 6c 6c 61 2f 35 2e 30 20 5b t: Mozilla/5.0 [
00A0 65 6e 5d 20 28 57 69 6e 39 35 3b 20 55 29 0d 0a en] (Win95; U) ..
00B0 52 65 66 65 72 65 72 3a 20 68 74 74 70 3a 2f 2f Referer: http://
00C0 31 32 2e 33 33 2e 32 34 37 2e 34 2f 0d 0a 58 2d 12.33.247.4/..X-
00d0 46 6f 72 77 61 72 64 65 64 2d 46 6f 72 3a 20 31 Forwarded-For: 1
00e0 34 38 2e 36 34 2e 31 34 37 2e 31 36 38 0d 0A 43 48.64.147.168 .. C
00f0 61 63 68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 6d 61 schmerzen-Control: ma
0100 78 2d 73 74 61 6c 65 3D 30 0D 0A 50 72 61 67 6d x-schalen = 0 .. Pragm
0110 61 3a 20 6e 6f 2d 63 61 63 68 65 0d 0a 0d 0a ce a: no-cache ... ..
0120 f8 43 76. Cv

Dies ist die "GET"-Anfrage für die verdächtige Datei-Namen. Es gibt ein paar Felder in diesem Nutzlast, die nicht aussehen, rechts. Die "HOST:"-Feld sollte ermitteln, welche Web-Server den Client hat versucht, zuzugreifen. Dies sollte immer ein Fully Qualified Domain Name, wie "www.fubar.com" oder ähnlich. Die Tatsache, dass der Server die IP-Adresse aufgeführt ist sagt mir, einen Web-Browser nicht benutzt wurde, um diese Sitzung zu generieren.

Es ist möglich, mehrere Websites auf dem gleichen physikalischen Server hosten. Der Server findet heraus, welche spezifischen Website, die Sie wollen durch die Analyse dieser Host-Feld zugreifen. Wenn Web-Browsern nicht folgten dieser Regel, Co-Location-Server mit mehreren Standorten auf dem gleichen physischen Box gehostet nie funktionieren würde. Also das sagt mir der Client nach dem eigentlichen Web-Server-Prozess, nicht eine Web site auf dem System gehostet werde.

Die "User-Agent:"-Feld sieht seltsam aus, wie gut. Zwar ist es möglich dem Kunden noch mit Windows 95 ist, ist es unwahrscheinlich.

Der Referer-Feld ist falsch, da gut. Dies sollte uns zeigen, die volle URI des Kunden zugreifen, wenn sie auf diese Seite verwiesen wurden war. Er sollte die Fully Qualified Domain Name, sowie die genaue Seite auf der Website, dass sie auf diese Seite verwiesen. In der Tat, wenn der Referer eine Suchmaschine ist, wird das Feld auch was Suchparameter verwendet wurden, wenn sie unsere Website geleitet wurden. Listing eine IP-Adresse ist völlig falsch.

Es gibt eine letzte interessante Information in diesem Nutzlast. Die "X-Forwarded-For:"-Feld zeigt uns, dass die Quell-IP-Adresse im IP-Header wird als HTTP-Proxy für was auch immer die IP-Adresse ist in diesem Feld aufgeführten handeln. Es ist nicht ungewöhnlich für Angreifer ihre Angriffe prallen an off eines öffentlichen Proxy-Server. Auf diese Weise, wenn Sie den Angriff erkennen in Ihrem Web-Server zugreifen anmelden, werden Sie denken, die Quell-IP-Adresse ist die feindliche Einheit als X-Forwarded-For-Feld werden nicht aufgeführt.

So haben wir eine verdächtige Datei Wunsch von einer IP, die versuchen, ihre Identität zu verbergen ist, mit Paketen, die verdächtige Werte aufweisen. Wir brauchen keinen IDS uns zu sagen, dies ist wahrscheinlich ein Angreifer auf der Suche nach einem bekannten gefährdeten Datei sein.

Nun nehmen Sie einen Blick auf Pakete 8 bis 17. Jeder ist der Server versucht, die Client "Es tut mir leid, ich bin nicht läuft, die anfällig Datei zu erzählen. Bitte versuchen Sie eine andere gefährdete Datei, wenn Sie mich kompromittieren wollen ", über 404-Fehlermeldung.

So die Strömung geht ungefähr so:

Client sendet eine Sonde für eine potenziell gefährdete Datei
Server setzt die Verbindung
Client setzt die Verbindung
Server ständig teilt dem Client ist nicht die Datei

Also, warum das setzt und warum ignorieren sie vom Server? Tune in Zukunft, um herauszufinden, ...

Keine Kommentare »

Posted in 3-err , Packet Decoding

Tags: Packet Decoding

Tshark Challenge - Hints2

6. Oktober 2009

Gestern haben wir aufgehört haben unter einen ersten Blick auf die Dekodierung Datei. Ein First-Pass hat uns kratzen unserem Kopf, weil wir einen 404-Fehler durch mehrfache Wiederholungen folgen sah. In diesem Hinweis werden wir in die Spur ein wenig tiefer zu graben.

Gehen wir zurück zu unserem ursprünglichen decodieren und verfolgen, was passiert paketweise:

tshark-r challenge1.cap
1 0.000000 148.78.247.10 -> 12.33.247.4 TCP 26922> http [SYN] Seq = 0 Win = 65535 Len = 0 MSS = 1460 WS = 0 TSV = 15485003 TSER = 0
2 0.000080 12.33.247.4 -> 148.78.247.10 TCP http> 26922 [SYN, ACK] Seq = 0 Ack = 1 Win = 5792 Len = 0 MSS = 1460 TSV = 1031147147 TSER = 15485003 WS = 0
3 0.029341 148.78.247.10 -> 12.33.247.4 TCP 26922> http [ACK] Seq = 1 Ack = 1 Win = 65535 Len = 0 TSV = 15485003 TSER = 1031147147
4 0.030787 148.78.247.10 -> 12.33.247.4 HTTP GET / CFIDE / Administrator / startstop.html HTTP/1.0
5 0.030841 12.33.247.4 -> 148.78.247.10 TCP http> 26922 [ACK] Seq = 1 Ack = 222 Win = 6432 Len = 0 TSV = 1031147150 TSER = 15485003
6 0.031319 12.33.247.4 -> 148.78.247.10 TCP http> 26922 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
7 0.031385 148.78.247.10 -> 12.33.247.4 TCP [TCP ACK verloren Segment] 26922> http [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
8 0.031610 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
9 0.031664 12.33.247.4 -> 148.78.247.10 HTTP HTTP/1.1 404 Not Found (text / html)
10 0.251838 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
12 1.631812 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
13 3.471773 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
14 7.153143 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
15 14.511594 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
16 29.231324 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
17 58.670815 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]

Unsere ersten drei Pakete sind die TCP-Handshake. Dieser Teil sieht ziemlich normal. In Paket 4 sehen wir den Client zu senden ein "GET"-Anfrage für eine Datei. Diese Datei Anfrage kommt mir verdächtig. Eine Datei namens "startstop.html" in der "Administrator"-Verzeichnis klingt nicht wie eine Datei würden wir sein wollen, dienen bis zur breiten Öffentlichkeit. Wir notieren Sie diese und kommen später darauf zurück.

In Paket 5 sehen wir den Server erkennen die Daten zu verlangen. Nach diesem Paket werden die Dinge ein wenig merkwürdig. In Paket 6, sehen wir den Server übertragen ein Reset-Paket, um die Verbindung zu töten. Dies ist ein Indiz, dass der Server fühlt sich etwas nicht mit der Sitzung falsch und dass sie nicht wiederhergestellt werden. Dies ist äußerst merkwürdiges Verhalten für TCP, da es sehr hart versucht, zuverlässig zu sein. Normalerweise sendet mehrere Versuche, eine Verbindung wiederherzustellen, wenn es etwas schief gelaufen denkt. Sie können sehen, normale Recovery-Verhaltens in Pakete 10 bis 17, die mehr mit dem übereinstimmt, wie TCP versucht, um die Verbindung aufrecht zu erhalten. Es gibt A .5 ms Unterschied in der Zeitstempel zwischen den Paketen 5 und 6. Ein normales Betriebssystem würde nie in so kurzer Zeit, dass die TCP-Sitzung wiederhergestellt werden können bestimmen.

In Paket 7, weiterhin Dinge, merkwürdig zu fungieren. Wir sehen den Client zum Server-Reset-Paket antworten mit einem Reset-Paket für sich. Dies ist sicherlich nicht normal IP Verhalten wie die RFCs Zustand Sie noch nie einen Fehler Packet reagieren sollte. So während einer normalen Sitzung, die Sie nie sehen würde diese Art von Fehler auszutauschen. Etwas ist natürlich sehr falsch.

In Paket 9, sehen wir den Server zu senden eine 404-Fehlermeldung. Es gibt ein paar Probleme hier. Um zu beginnen, der Server bereits geschickt ein Reset zeigt es als die Sitzung nicht wiederhergestellt werden. Ein System sollte niemals weiterhin Daten nach Ausgabe eines Reset-Paket sendet. In der Tat, setzt der Server den ganzen Weg zu Paket 17 zu übertragen. Was macht diese Tätigkeit noch seltsamer ist, dass der Client über eine Reset ausgegeben als auch. So der Server ist nicht nur ignoriert die Tatsache, dass es einen Reset ausgegeben, ist es auch ignorieren die Rücksetzung durch den Client gesendet.

So unnötig zu sagen, das ist sehr seltsam TCP Verhalten. In meinem nächsten Beitrag werde ich tiefer in die Nutzlasten um einen besseren Blick auf das, was vor sich geht.

Keine Kommentare »

Posted in 3-err , Packet Decoding

Tags: Packet Decoding

Tshark Challenge - Hints1

5. Oktober 2009

Letzte Woche habe ich verzeichnete einen Libpcap Datei und forderte sie, um herauszufinden, wie viel Sie können über die Spur mit tshark. In diesem Beitrag werde ich Sie durch den Prozess der Analyse der Dekodierung beginnen. Ich WIL NICHT decken sie vollständig. Mein Ziel ist es, ein Bein aufgeben, um die Leute, die nicht einmal wissen, wo ich anfangen soll. Ich füge mehr Details als die Woche geht weiter.

Erste Schritte

Das erste, was Sie tun sollten, haben Sie einen Blick auf den Inhalt der Datei. Ich benutze die Option-r in den Inhalt der Datei zu lesen. Dies überschreibt tshark die Standardeinstellung von Sniffing auf dem ersten erkannten Schnittstelle. Normalerweise würde ich die Ausgabe durch die "weniger"-Befehl (oder "mehr" unter Windows), aber es gibt nur 17 Pakete in der Datei.

tshark-r challenge1.cap
1 0.000000 148.78.247.10 -> 12.33.247.4 TCP 26922> http [SYN] Seq = 0 Win = 65535 Len = 0 MSS = 1460 WS = 0 TSV = 15485003 TSER = 0
2 0.000080 12.33.247.4 -> 148.78.247.10 TCP http> 26922 [SYN, ACK] Seq = 0 Ack = 1 Win = 5792 Len = 0 MSS = 1460 TSV = 1031147147 TSER = 15485003 WS = 0
3 0.029341 148.78.247.10 -> 12.33.247.4 TCP 26922> http [ACK] Seq = 1 Ack = 1 Win = 65535 Len = 0 TSV = 15485003 TSER = 1031147147
4 0.030787 148.78.247.10 -> 12.33.247.4 HTTP GET / CFIDE / Administrator / startstop.html HTTP/1.0
5 0.030841 12.33.247.4 -> 148.78.247.10 TCP http> 26922 [ACK] Seq = 1 Ack = 222 Win = 6432 Len = 0 TSV = 1031147150 TSER = 15485003
6 0.031319 12.33.247.4 -> 148.78.247.10 TCP http> 26922 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
7 0.031385 148.78.247.10 -> 12.33.247.4 TCP [TCP ACK verloren Segment] 26922> http [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0
8 0.031610 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
9 0.031664 12.33.247.4 -> 148.78.247.10 HTTP HTTP/1.1 404 Not Found (text / html)
10 0.251838 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
12 1.631812 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
13 3.471773 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
14 7.153143 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
15 14.511594 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
16 29.231324 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]
17 58.670815 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]

Einige Details, die sofort greifen meine Aufmerksamkeit:

Dies ist eine HTTP-Sitzung
Die Verbindung versucht, eine Datei, die nicht existiert (404 Fehler in # 9) Zugang
Es gab Kommunikationsprobleme mit der Session (# 10-17 sind Wiederholungen)

So sofort diese Spur hinterlässt bei mir einige Fragen:

Was ist los mit der Bitte um eine Datei, die nicht existiert?
Warum haben wir Kommunikationsprobleme?

Das war es für heute. Morgen werde ich nach einem anderen Hinweis.

Keine Kommentare »

Posted in 3-err , Packet Decoding

Tags: Packet Decoding

Tshark Decode Herausforderung

2. Oktober 2009

In meinem letzten Beitrag habe ich abgedeckt tshark und diskutiert, wie die Ausgabe in einer dekodieren zu manipulieren. Es gibt keinen besseren Weg, als learning by doing, also habe ich beschlossen, eine Herausforderung zu posten. In diesem Beitrag werde ich eine Libpcap Datei. Ihre Mission Mr. Phelps, sollten Sie es akzeptieren, ist der Versuch zu erkennen, was los ist in der Dekodierung Datei mit tshark.

Installieren tshark

Um tshark installieren, müssen Sie Wireshark installieren. Sie können eine aktuelle Kopie aus dem Grab Download-Seite . Sobald Sie das tun, ist die Installation abhängig, auf welcher Plattform Sie verwenden:

Linux / UNIX

Wenn Sie Fedora oder Red Hat sind, brauchen Sie nicht zur Download-Seite zu besuchen. Sie können Wireshark direkt installieren durch Yum:

su -
yum-y install wireshark.i586

Wenn Sie ein Unix oder auf einem anderen Linux-Distribution sind, müssen Sie das tar-Archiv aus dem obigen Link zu packen und zu kompilieren Wireshark für Ihr System. Achten Sie besonders auf die Abhängigkeiten, da viele von ihnen sind. Stellen Sie sicher, dass ". / Configure" erfolgreich abgeschlossen, bevor Aufbau Ihrer Binärdateien.

Windows-

Laden Sie die selbstextrahierende ausführbare Datei
Führen Sie die ausführbare
Accept Unknown Publisher Bildschirm, indem Sie "run"-Taste
Befolgen Sie die Anweisungen auf dem Bildschirm die Standardwerte zu übernehmen
Installieren Sie WinPcap (stellen Sie sicher markiert ist)
Installieren Sie NPF-Service, wenn Nicht-Administrator-Benutzer ausgeführt werden, wird das Werkzeug
Add "C: \ Program Files \ Wireshark" bis zum Ende Ihrer Pfadanweisung

OS X

Wählen Sie das Bild, dass Ihr Prozessor-Typ entspricht (Intel oder PPC)
Open with DiskimageMounter
Open the “Read me first.rtf”
Follow the “Quick Setup” instructions

The challenge

Here's the challenge file:

challenge1.cap

And here are the hashes of the file to verify your download:

MD5: ea92f08d9ba104c6cf7756564eb5aef9 challenge1.cap
SHA-1: 71041ab0f670c5b9558183a56fe1bb80e8b10506 challenge1.cap

Good luck and starting next week I'll post a little more info about the file every day to help move you through the decode process.

Keine Kommentare »

Posted in 3-err , Packet Decoding

Tags: Packet Decoding

Analyzing packets with tshark

1. Oktober 2009

In an earlier post I discussed how to adjust the display output in tshark . The post generated a lot of interest, so I decided to add some additional information on using tshark to decode packets. This post assumes you have read the one linked to above.

Why use tshark instead of tcpdump/windump?

Many old time decoders swear by tcpdump , and it's Windows counterpart windump . Both are great tools, but they have become a little dated. While patches are still released from time to time, little has been done to update or expand their decode capability. Wireshark on the other hand, as well as it's included tools such as tshark, include decode support for hundreds of protocols and the list is growing all of the time. While you can certainly analyze packets without the decoders, they make the process go far quicker.

Why use tshark instead of Wireshark?

Wireshark is a great tool when you are doing an in-depth payload analysis. It can be a little tedious however if you wish to follow a specific field over multiple packets. For example let's say we wish to watch the TCP sequence number increment over multiple packets. With Wireshark, I would have to note the sequence number location in the middle pane and page through each packet. Since there is no way to line up the value over multiple packets, I'm forced to remember previous values when performing my calculations. With tshark however, we can do something like this:

tshark -n -T fields -e ip.src -e tcp.seq -e tcp.len
64.111.96.38 0 0
64.111.96.38 1 0
64.111.96.38 1 363
64.111.96.38 364 1448
64.111.96.38 1812 1448
64.111.96.38 3260 1448
64.111.96.38 4708 1448
64.111.96.38 6156 1448
64.111.96.38 7604 1448
64.111.96.38 10500 310
64.111.96.38 9052 1448
64.111.96.38 10810 0

Remember that the TCP sequence number (the second field) should increment based on the size of the payload (the third field). Note that packets 10 and 11 where received out of order. This could mean there are multiple paths available between our location and the identified IP address. While Wireshark would show us this information as well, in this view it is a bit easier to follow the flow.

More on displaying fields

As discussed in my earlier post, as well as shown above, the “-T” switch can be used to manipulate the output being displayed. You can choose from XML, Postscript or plain text. The most useful option is “fields” as it lets you pick and choose which specific fields you want printed out. As shown above, the “-e” switch can then be used to identify which fields you wish to display. The complete list of filters can be found here . A nice cheat sheet of the most commonly used values can be found here .

If you define a specific protocol, tshark will display some of the more important fields from that header. For example to look at only the Ethernet header:

tshark -T fields -e eth
Ethernet II, Src: TyanComp_56:3b:14 (00:e0:81:56:3b:14), Dst: Dell_d1:fe:ef (00:12:3f:d1:fe:ef)
Ethernet II, Src: TyanComp_56:3b:14 (00:e0:81:56:3b:14), Dst: Dell_d1:fe:ef (00:12:3f:d1:fe:ef)
Ethernet II, Src: TyanComp_56:3b:14 (00:e0:81:56:3b:14), Dst: Dell_d1:fe:ef (00:12:3f:d1:fe:ef)

Note the type and CRC fields are not displayed, as they are not as “interesting” as the source and destination MAC address. We would have to define these fields specifically (ip.type and ip.trailer) if we wish to see them.

Ein Nebeneffekt des Drucks Felder ist, dass tshark wird eine leere Zeile für jedes Paket, das keine der angegebenen Feld hinzuzufügen. Dies kann ein Schmerz bei der Analyse von HTTP-Pakete als nicht jedes Paket einen URI enthält. Ein einfacher Weg, um dies zu reinigen, ist eine Pipe durch grep. Zum Beispiel:

tshark-T Felder-e http.request.uri | grep-v "^ $"
/
/ Styles.css
/ Templates / classic / images / starsnstripes.gif
/ Templates / classic / images / unionjack.gif
/ Templates / classic / images / amazon.header.gif
/ C_images/2009/05/07/71090.2.jpg

In meinem letzten Beitrag habe ich diskutiert grep sowie wo man eine kostenlose Version für Windows zu greifen. Die oben genannten Befehl grep verwendet die "-v"-Schalter, um alle Zeilen, die keine dem angegebenen Wert entsprechen. "^ $" Definiert eine leere Zeile. Das obige Befehl grep filtert alle Leerzeilen.

Weitere Anzeigeoptionen

Tshark hat eine Reihe anderer nützlicher Display-Optionen. Zum Beispiel können Sie Header am Anfang der Ausgabe zu drucken:

tshark-n-T Felder-e ip.src-e ip.dst-E header = y
ip.src ip.dst
64.111.96.38 12.5.200.100
64.111.96.38 12.5.200.100
64.111.96.38 12.5.200.100

Wenn Sie zum Importieren der Daten in eine Tabellenkalkulation oder Datenbank planen, können Sie definieren, welche Zeichen zwischen den Feldern zu verwenden:

tshark-T Felder-e ip.src-e ip.dst-e tcp.dstport-E header = y-E separator =;
ip.src; ip.dst; tcp.dstport
64.111.96.38; 12.5.200.100; 34831
64.111.96.38; 12.5.200.100; 34831
64.111.96.38; 12.5.200.100; 34831

Packet Statistiken

Tshark verfügt über eine solide statistische Funktion als gut. Wenn Sie viele Dateien verarbeiten müssen, ist es manchmal helfen, mit Blick auf die Roh-Statistik zu beginnen. Das "z"-Schalter wird benutzt, um die Statistiken, die Sie analysieren möchten angeben. Normalerweise werden diese am Ende der Dekodierung Informationen gedruckt werden, aber wenn man das "-q" verwenden Schalter nur die Stats gedruckt werden. Hier ein Beispiel:

C: \ Test> tshark-q-z http, stat,-z http-, Baum-r test.cap
================================================== =============
HTTP / Packet Zählerwert Rate Prozent
-----------------------
Insgesamt HTTP Packets 64915 0.048999
HTTP-Request-Packets 459 0.000346 0,71%
GET 24 0.000018 5,23%
HEAD 433 0.000327 94,34%
OPTIONS 2 0.000002 0,44%
HTTP-Response-Pakete 448 0.000338 0,69%
??: Broken 0 0.000000 0.00%
1xx: Informationelle 0 0,000000 0.00%
2xx: Erfolg 12 0,000009 2,68%
200 OK 12 0,000009 100,00%
3xx: Redirection 0 0,000000 0.00%
4xx: Client Error 436 0,000329 97.32%
404 Not Found 432 0,000326 99.08%
403 Forbidden 4 0,000003 0,92%
5xx: Server Error 0 0,000000 0.00%
Andere HTTP Packets 64008 0.048314 98,60%
================================================== =============
================================================== =============
HTTP Statistics
* HTTP Status Codes in reply packets
HTTP 200 OK
HTTP 403 Forbidden
HTTP 404 Not Found
* List of HTTP Request methods
GET 24
OPTIONS 2
HEAD 433
===============================================================

A couple of things stick out in this output. First, we have four 403 errors indicating that someone was attempting to access something they did not have permission to. Also, out of 459 HTTP requests, 432 of them were for non-existent files. We are also seeing a lot of “HEAD” requests which could be a proxy, or could be an attacker attempting to keep from being logged to the Web server's access log. Clearly this capture file includes some suspect traffic that warrants further investigation.

Tshark can even produce general throughput statistics if you need them. This is an excellent way to check for DoS attacks:

tshark -q -z io,stat,10 -r test.cap
===============================================================
IO Statistics
Interval: 10.000 secs
Column #0:
| Column #0
Time |frames| bytes
000.000-010.000 254 145081
010.000-020.000 145 80003
020.000-030.000 125 65527
030.000-040.000 4 264
===============================================================

Note tshark will print the frame and byte count for any interval specified, defined in seconds. The only problem is that if you are capturing packets off of the wire, stats are not displayed until the capture ends.

Exec Zusammenfassung

Tshark is an extremely capable packet analysis tool that has surpassed it's counterparts tcpdump and windump. Combine the extensive decode capability along with the flexible output display, and tshark has become the tool of choice for many packet decoders.

Keine Kommentare »

Posted in 2-alert , Network Security , Packet Decoding

Tags: Packet Decoding