|
|
|
... und wie man sie umgehen kann. |
|
|
|
|
"... yes, a game where people throw ducks at ballons, and nothing is
what is seems..." |
|
-- Homer J. Simpson |
|
|
|
|
|
|
|
Netzwerkinterface(s) im Promiscous-Mode |
|
Switches mit eigenem 'Mirror-Port' |
|
Passive Protokoll Analyse |
|
|
|
"Fail Open" |
|
|
|
|
Sensoren
(event
generators, 'E-boxes') |
|
Analyse-einheiten / Pattern Matching
(analysis
engines, 'A-boxes') |
|
Speicherung
(storage
mechanism, 'D-boxes') |
|
Gegenmaßnahmen
(countermeasures,
'C-boxes') |
|
|
|
|
|
Stealth - Konfiguration |
|
keine IP-Adresse |
|
gepachter (verkrüppelter) TCP/IP - Stack |
|
umgebautes Patchkabel |
|
|
|
Konfiguration mit SSH über zweites Interface
(ev. eigener Backbone) |
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
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) |
|
|
|
|
|
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. |
|
|
|
|
|
|
|
'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. .." |
|
|
|
|
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. |
|
|
|
|
|
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 |
|
|
|
|
|
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 |
|
|
|
|
|
= Neu entdeckte Sicherheitslücken |
|
Signatur-basierte IDS sind chancenlos |
|
(müssen erst in Datenbank aufgenommen werden) |
|
SNORT: Regeln bei Bekanntwerden selbst
schreiben! |
|
|
|
|
|
|
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 |
|
|
|
|
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 |
|
|
|
|
|
|
|
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 . |
|
|
|
|
|
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 |
|
|
|
|
|
|
|
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. |
|
|
|
|
|
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 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. |
|
|
|
|
|
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. |
|
|
|
|
|
geringes Datenaufkommen |
|
|
|
nur gültige Pakete |
|
|
|
schwer zu entdecken |
|
(Gefahr der False Positives!) |
|
|
|
|
|
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 |
|
|
|
|
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 |
|
|
|
|
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 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! |
|
|
|
|
|
normalerweise sind Fragmente einfach geteilte
grössere Pakete |
|
[xxxxxxxxxxxx] -> [xxxxxx][xxxxxx] |
|
durch selbstbasteln können überlappende
Fragmente erzeugt werden |
|
[xxxxxxxxxxxx] -> [xxxxxxxxx] |
|
[xxxxxxx] |
|
|
|
|
|
Ü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 |
|
|
|
|
|
|
|
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. |
|
|
|
|
|
ä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! |
|
|
|
|
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) |
|
|
|
|
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 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. |
|
|
|
|
|
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. |
|