Notizen
Gliederung
Network Intrusion Detection
... und wie man sie umgehen kann.
Network Intrusion Detection ...


"... yes, a game where people throw ducks at ballons, and nothing is what is seems..."
-- Homer J. Simpson
Grundlegende Funktionsweise
Netzwerkinterface(s) im Promiscous-Mode
Switches mit eigenem 'Mirror-Port'
Passive Protokoll Analyse
"Fail Open"
Grundlegender Aufbau
Sensoren
 (event generators, 'E-boxes')
Analyse-einheiten / Pattern Matching
 (analysis engines, 'A-boxes')
Speicherung
 (storage mechanism, 'D-boxes')
Gegenmaßnahmen
(countermeasures, 'C-boxes')
NIDS .. eigentlich unhackbar
Stealth - Konfiguration
keine IP-Adresse
gepachter (verkrüppelter) TCP/IP - Stack
umgebautes Patchkabel
Konfiguration mit SSH über zweites Interface (ev. eigener Backbone)
Angriffsebenen
Gesehen werden, aber in der Datenflut untertauchen
DoS / DDoS
Gesehen, aber nicht erkannt werden
0day's
Angriff "codieren" / verstecken
Ungesehen am NIDS vorbeikommen
unter der Alarm-Grenzschwelle bleiben
Schwächen des TCP/IP ausnützen
DoS
Senden von gespooften Angriffen
gespoofte Source-IPs
viele unterschiedliche Angriffe als "Trigger"
IDS besonders gefährdet, da als "Fail Open" implementiert
1) Überfüllen der Log-Dateien
eigentlicher Angriff wird nicht mehr geloggt.
2) Angriff im "Rauschen" untergehen lassen
DoS gegen das Security-Personal (Analysten)
DoS - unelegant & gefährlich
Versuchter Angriff fällt auf jeden Fall auf
Auftauchende Fragen:
Ist ein System kompromittiert worden?
Wenn ja: Welches? Wodurch?
--> viel Arbeit für das Sicherheits-Personal.
Hacker wird das geknackte System vermutlich nur für ganz kurze Zeit nützen können.
DoS - Tools: Stick
'Stick' - an IDS stress tool
"The tool uses the Snort rule set and produces a C program via lex that when compiled will produce an IP packet capable of triggering that rule from a spoofed IP range (or all possible IP addresses) into a target IP range. A function is produced for each rule and a loop then executes these rules in a random order. The tool currently produces these at about 250 alarms per second. .."
DoS - Tools: Stick
Auswirkungen:
A Linux based SNORT will hit 100% CPU and start dropping packets. The stress on recording and disk IO is another problem.
ISS Real Secure dies two seconds after the attack begins. This was tested numerous times. Other IDS and even sniffers (especially with DNS lookups) had problems of
their own.
DoS - Tools: Stick
gegen IDS mit "stateless analysis"
(überprüfen alle Pakete, nicht nur die gültiger Verbindungen)
Homepage:
http://www.eurocompton.net/stick
Sourecode:
http://packetstorm.securify.com/distributed/stick.tgz
DoS - Tools: BO2k noise generator
Führt zu falschem Einordnen des Scans durch IDS
"normaler" BO2k Scan (IDS würde Alarm geben):
192.168.1.23 : 1055  --> 10.0.0.1 : 31337
192.168.1.23 : 1055  --> 10.0.0.2 : 31337
192.168.1.23 : 1055  --> 10.0.0.3 : 31337
192.168.1.23 : 1055  --> 10.0.0.4 : 31337
Scan mit "Noise" (würde vermutlich als Portscan eingeordnet)
192.168.1.23 : 1055  --> 10.0.0.1 : 17023
192.168.1.23 : 1055  --> 10.0.0.3 : 31337
192.168.1.23 : 1055  --> 10.0.0.2 : 9873
192.168.1.23 : 1055  --> 10.0.0.2 : 31337
192.168.1.23 : 1055  --> 10.0.0.1 : 21032
192.168.1.23 : 1055  --> 10.0.0.2 : 37892
192.168.1.23 : 1055  --> 10.0.0.1 : 31337
0day exploits
= Neu entdeckte Sicherheitslücken
Signatur-basierte IDS sind chancenlos
(müssen erst in Datenbank aufgenommen werden)
SNORT: Regeln bei Bekanntwerden selbst schreiben!
Bekannte Exploits 'codieren'...
HEX-encoding: /cgi-bin/ --> "/%63%67%69%2d%62%69%6e/"
Multiple Slashes:
/cgi-bin//test/////some.cgi
Reverse traversal:
/cgi-bin/some-fake-dir/../some.cgi
Self-reference directories:
www.yahoo.com/././././index.html
Bekannte Exploits 'codieren'...
Long URLs:
/blah<lots of characters>blah/../index.html
Slash vs. Backslash
/cgi-bin\test\some.cgi
NULL method processing
GET%00 /cgi-bin/some.cgi HTTP/1.0
Bekannte Exploits 'codieren'...
Umgehen von signaturbasiertem IDS: (#bash):
(Befehl sollte von NIDS nicht mehr erkannt werden können)
[root@snafu /root]# mv /etc/passwd .
      wird zu:
[root@snafu /root]# NAME1=pass
[root@snafu /root]# NAME2=wd
[root@snafu /root]# export NAME1 NAME2
[root@snafu /root]# alias mv=x
[root@snafu /root]# x /etc/$NAME1$NAME2 .
low traffic scans / distributed scans
IDS werden Portscans ab einer erreichten Grenzschwelle melden.
ab x Ports / Minute
ab x Ports in einer Reihe
ab x Ports vom gleichen Host
Host-Detection: nmap & Co sind sehr 'laut':
nmap muss erst offenen und geschlossenen Port finden
senden von irregulären TCP/IP Paketen
low traffic scans / distributed scans
Möglichkeiten unterzutauchen:
Ports nicht 'hintereinander' scannen
nur wenige Ports / Stunde (bzw. pro Tag!)
Ports von verschiedenen IP's aus scannen
ziemlich zeitaufwendig, da
Grenzschwelle normalerweise unbekannt.
X / Xprobe - ICMP based fingerprinting
von Ofir Arkin & Fyodor Yarochkin
www.sys-security.com
sehr elegante Technik:
analysiert remote OS TCP/IP stack
keine 'malformed datagrams'
extrem schlank
(siehe auch Phrack #57  www.phrack.org)
X  /  Xprobe  - ICMP based fingerprinting
"X is a logic which combines various remote active operating system fingerprinting methods using the ICMP protocol ... into a simple, fast, efficient and a powerful way to detect an underlaying operating system a targeted host is using."
Xprobe: Tool, welches X automatisiert.
X / Xprobe - oder: da waren ja nur drei incoming packets..??
Identifzierung von Windows 2000 durch insgesamt nur 4 gültige ICMP Pakete!
2 gesendete, 2 empfangene
3. gesendetes Paket könnte schön der Angriff sein (bes. bei Web-Servern)
1. gesendetes Paket: 8 versch. OS (-klassen)
max. 4 gesendete Pakete reichen für alle OS.
X / Xprobe
geringes Datenaufkommen
nur gültige Pakete
schwer zu entdecken
(Gefahr der False Positives!)
TCP/IP
Standard: eigentlich in den RFC's der IETF (Internet Engineering Task Force) festgelegt.
Verschieden implementiert (NT4 vs *NIX)
Spielräume in der Spezifikation
Behandlung von "unmöglichen" Zuständen.
--> von versch. OS unterschiedlich gelöst
TCP/IP - kurze Erklärung
für unterschiedliche Medien konzipiert
MTU (maximum transmission unit) je nach Medium unterschiedlich (maximal Paketgrösse)
Paket kann von Routern/Gateways in kleinere Pakete aufgeteilt werden
Pakete können verschiedene Routen nehmen
werden am Ziel wieder zusammengesetzt
TCP/IP - kurze Erklärung
Grosses Paket kann bei Übergang auf anderes Netzwerk-segment in kleinere Fragmente zerlegt werden (Nummerierung: Sequence Nummern)
Fragmente werden durch den Ziel Host wieder zusammengesetzt.
TCP/IP - packet crafting
TCP/IP Pakete können auch 'von Hand' erzeugt werden (spoofing/raw sockets).
dadurch ist es möglich ungültige Pakete zu erzeugen
Behandlung dieser ungültigen Pakete je nach TCP/IP Stack unterschiedlich!
TCP/IP - overlapping fragments
normalerweise sind Fragmente einfach geteilte grössere Pakete
[xxxxxxxxxxxx] -> [xxxxxx][xxxxxx]
durch selbstbasteln können überlappende Fragmente erzeugt werden
[xxxxxxxxxxxx] -> [xxxxxxxxx]
   [xxxxxxx]
TCP/IP - overlapping fragments
Überlappende Fragmente werden von Betriebssystemen unterschiedlich behandelt.
Dadurch ist es möglich einen kompletten Datenstrom z.B. an einem Linux-basierten IDS vorbeizuschleusen und einen NT4 Rechner zu attackieren, ohne dass das IDS den Angriff überhaupt sehen kann!
                                [mixed-dataxxxxx]
hacker-software      [NT4xxxxxxxx]               <-- der Angriff
  [xxxxLINUX] <-- irgendein blindtext
TCP/IP - overlapping Fragments
Fragment 1a: GET /../../winnt/sam  HTTP/1.1
"überschreiben" durch
Fragment 1b: GET /index.html HTTP/1.1
WinNT 4 wird das nachfolgende Fragment verwerfen und den Inhalt des Paketes 1a ausführen, während der Linux TCP/IP Stack das Fragment 1b an das IDS zur Untersuchung weitergeben wird.
'Tunnelung' der Daten am IDS vorbei.
TCP/IP - Sequence Nummern
ähnliches Verhalten wie bei den Overlapping Fragments
Zwei Pakete mit gleicher Sequence-Nummer:
WinNT 4 wird das erste Paket annehmen,
BSD / Linux aber hingegegen das Zweite!
TCP/IP - Sequence Nummern
bei NIDS mit Stateful Inspection ließe sich u.U. eine Desynchronisation des NIDS erreichen (wenn es den Traffic anhand der Sequence Nummern mitverfolgt)
Folge: u.U. erreichen einer unüberwachten Verbindung
(Verfahren gleicht TCP-Hijacking)
Die Probleme...
NIDS besitzen zu wenig Wissen über das Netzwerk, dass sie überwachen.
Netzwerk-Standards werden nicht eingehalten
Nur gutausgebildete Netzwerk-Analysten können NIDS warten und die Logs und Alerts auswerten
Unzureichendes Sicherheitsbewusstein
Die Zukunft: IDS, die...
..die Verwundbarkeit der Clients kennen und Angriffe anhand ihrer Gefährlichkeit bewerten
.. den Admin nur mehr bei konkreter Gefahr für die Maschinen benachrichtigen
.. automatisch einen Bug-Fix vorschlagen
.. selbstständig auf Angriffe reagieren, ohne dadurch für DoS Attacken anfällig zu werden.
Vielen Dank.
wascy_@yahoo.com
irc.box.sk  #TUWien #linux
Literatur:
http://www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html
http://rr.sans.org/intrusion/anti-ids.php
http://www.sys-security.com
http://secinf.net/info/ids/idspaper/idspaper.html
http://www.eurocompton.net/stick/
etc.