# Rechner Hacken mit nur einem Paket

## LL0rd

Hallo,

man liest ja in vielen Zeitschriften und Werbeanzeigen der Hardwarefirewall Hersteller darüber, dass heutzutage sogar schon ein einziges Paket ausreicht, um einen Rechner zu "Hacken". Ich frage mich deshalb, ob es wirklich stimmt und wenn ja, was man erreichen kann.

----------

## TheCurse

Kommt natürlich drauf an, was du unter "Hacken" verstehst. Man kann z.B. bestimmte Programme aus dem Tritt bringen, wenn man ein manipuliertes Paket sendet. Ein Beispiel dafür wäre eine (Software)Firewall. Man schickt ein manipuliertes Paket, die Firewall kann es nicht verarbeiten und stürzt ab. 

Ein anderes denkbares Scenario ist, dass die Firewall nicht einfach abstürzt, sondern ein BufferOverflow die folge ist und dadurch beliebiger Code auf dem Rechner ausgeführt werden kann.

----------

## LL0rd

Stimmt, Hacken ist ein eher allgemeiner Begriff. Aber ich denke, dass die Hersteller damit alles meinen, was mit Computermanipulation von Außen gemeint sein kann. 

Aber nehmen wir jetzt mal einfach unser Linux mit einer iptables Firewall. Diese Firewall ist ja dann eine Software Firewall. Jetzt lasse ich einfach jeden eingehenden Traffic an der eth0 Schnittstelle per iptables DROPen. Wie kann dann ein (manipuliertes) Paket etwas anrichten? Und wo ist jetzt der Unterschied zwischen so einer Software Lösung und den sauteueren Hardware Firewalls?

----------

## b3cks

 *LL0rd wrote:*   

> Und wo ist jetzt der Unterschied zwischen so einer Software Lösung und den sauteueren Hardware Firewalls?

 

Prinzipiell gar keiner. Denn sowohl die Software- als auch die Hardware-Firewall bestehen aus den Komponenten Hardware, Betriebsystem und der eigentlichen Firewall-Software, um laufen zu können. Bei einer Hardware-FW ist das alle eben in einer Box integriert und diese dient eben ausschließlich dafür den Traffic zu prüfen. Hardware und Software sind aufeinander abgestimmt, womit eine höhere/bessere Perfomance gewährleistet werden soll. Man könnte sich eigentlich ausmalen, welche Vor- und auch Nachteile sich daraus ziehen. Da das ganze ein Komplettpaket ist, bieten sich bei der FW weniger Angriffspunkte, wie es z.B. bei einer Software-FW sein kann. Diese läuft beispielsweise auf einem Server, wo zusätzlich noch x andere Applikationen, die von außen kontaktierbar sind und somit Angriffsfläche bieten (um darüber die Firewall-Applikation abzuschalten), laufen. Die SW-FW ist halt die einfache Applikation die auf einem beliebigen System läuft, wie es z.B. bei der Dekstop-Firewall der Fall ist. Da man hier die Hardware spart, welche man sich aber wiederum andersweitig besorgen muss, und man nur für die SW bezahlt, ist diese vermeindlich günstiger.

Sicherlich kann man sich eine HW-FW Konstruktionen auch selber zusammenschustern, indem man schlicht weg einen PC/Server nimmt, auf diesem nur die SW laufen lässt und beide (oder mehr) Netze verbindet. Komm so ziemlich auf dasselbe hinaus.

Es ist halt so wie bei vielem. Ich kann mir auch eine SSL-VPN-Box für ~3000 kaufen oder mir was mit OpenVPN selber basteln, wenn ich das Equipment besitze.

----------

## LL0rd

Ich verstehe aber trotzdem nicht, wo die z.T. astranomischen Preise herkommen. Ich könnte mir ja auch einen 0815 Thin Client (mit mehreren ethx Schnittstellen) herstellen, der kaum Strom verbraucht) und auf diesem dann einen kostenlosen fli4l Router aufsetzen.

Kosten: 

400 Hardwarekosten

5-10 Stunden á 50 = 250-500

---------------------------------------

Somit habe ich für max 900 eine individuell angefertigte und konfigurierte Firewall. Wie kommen also die 3k Preise für (mehr oder weniger) Massenproduktionen zustande?  Aber wenn das so einfach wäre, dann würden sich Unternehmen die teuere Hardware ja nicht kaufen.

----------

## TheCurse

 *LL0rd wrote:*   

> Aber nehmen wir jetzt mal einfach unser Linux mit einer iptables Firewall. Diese Firewall ist ja dann eine Software Firewall. Jetzt lasse ich einfach jeden eingehenden Traffic an der eth0 Schnittstelle per iptables DROPen. Wie kann dann ein (manipuliertes) Paket etwas anrichten?

 

Ganz einfach, iptables muss ja erstmal das Paket analysieren, ob vielleicht eine deiner Regeln zutrifft. Wenn aber beim analysieren irgendwas passiert (Beispiel buffer overflow) kann dadurch die Firewall lahmgelegt oder code ausgeführt werden. Also mit anderen Worten durch einen Bug in der Firewall kann etwas passieren.

Die darstellung ist zwar wahrscheinlich nicht so gaaanz korrekt, aber prinzipiel müsste es so sein.

----------

## think4urs11

 *LL0rd wrote:*   

> Hallo,
> 
> man liest ja in vielen Zeitschriften und Werbeanzeigen der Hardwarefirewall Hersteller darüber, dass heutzutage sogar schon ein einziges Paket ausreicht, um einen Rechner zu "Hacken". Ich frage mich deshalb, ob es wirklich stimmt und wenn ja, was man erreichen kann.

 

Hi,

die Aussage bezieht sich auf SQL-Slammer.

War ein nettes Teilchen vor einiger Zeit das sämtliche Windows basierten SQL-Server angegriffen hatte, und zwar mittels exakt *eines* (afair) ~500 Bytes großen udp pakets.

Das gemeine war das sich das Dingen explosionsartig verbreitet hat und auch sämtliche auf Clients installierten SQL-Engines angriff.

War feeeein damals. (Schonmal einen 6513 von Cisco schwitzen sehen? *g*)

----------

## c_m

 *Think4UrS11 wrote:*   

> War ein nettes Teilchen vor einiger Zeit das sämtliche Windows basierten SQL-Server angegriffen hatte[...]

 Etwas schwammig formuliert *find* Um genau zu sein: es war MS SQL Server 2000 betroffen bzw alle Produkte die die SQL-Desktop-Engine MSDE verwendet haben. Schlimm find ich nur, dass seit nem halben Jahr ein Patch für die Lücke existierte *gg* TecChannel Bericht

Aber ja, das Ding ist sehr cool. Ich würd mal sagen: Proof-of-Concept ist geglückt ^^

----------

## amne

 *LL0rd wrote:*   

> Ich verstehe aber trotzdem nicht, wo die z.T. astranomischen Preise herkommen. Ich könnte mir ja auch einen 0815 Thin Client (mit mehreren ethx Schnittstellen) herstellen, der kaum Strom verbraucht) und auf diesem dann einen kostenlosen fli4l Router aufsetzen.
> 
> 

 

Support, Zertifizierung, Wartungsvertrag, 3 Jahre Garantie, Produkt vom Weltmarktführer, läuft einfach ohne Probleme zu machen, Rundum-Wohlfühllösung usw - vielen Firmen ist sowas das Geld teilweise wert, da sie mit dieser einmaligen Investition sicher sein können, dass sie sich jetzt zurücklehnen können und sicher keine weitere Mannminute mehr investieren müssen. Je nach Hersteller kann das auch wirklich der Fall sein.

----------

## think4urs11

 *c_m wrote:*   

> Etwas schwammig formuliert *find* Um genau zu sein: es war MS SQL Server 2000 betroffen bzw alle Produkte die die SQL-Desktop-Engine MSDE verwendet haben.

 

A jo, ich wollte nur niemanden hier mit OS-fremden Details langweilen, sondern nur den Kontext zum Originalzitat herstellen. Und genaugenommen waren das ja (fast) alle Server/Client-Engines; bei uns gabs jedenfalls kaum eine (verSQLte) Kiste die nicht betroffen war *g*

----------

## sschlueter

 *LL0rd wrote:*   

> Somit habe ich für max 900 eine individuell angefertigte und konfigurierte Firewall. Wie kommen also die 3k Preise für (mehr oder weniger) Massenproduktionen zustande?  Aber wenn das so einfach wäre, dann würden sich Unternehmen die teuere Hardware ja nicht kaufen.

 

Na, das liegt natürlich daran, dass diejenigen, die das entscheiden nicht diejenigen sind, die das technische Verständnis haben.

Darüber hinaus handelt es sich um eine emotionale Entscheidung, wie amne das bereits angedeutet hat.

Es ist zwar pervers, dass sich die Leute mit einer untransparenten Blackbox, die verschlüsselte Kommunikation mit dem Hersteller betreibt, wohler fühlen als mit einer transparenten selbsterstellen Lösung, aber so funktioniert die Psyche dieser Leute eben.

----------

## LL0rd

Es stimmt, es sind überwiegend emotionale Entscheidungen, die zum Kauf von teuerer Hardware führen. Ich habe mir auch eine Cisco Aironet WLAN Karte gekauft, weil da Cisco draufstand  :Wink: 

Aber mal ehrlich: Wann Funktioniert denn schon Hardware ohne Probleme? Sei es nur eine Portfreigabe die man braucht oder ein Update, oder sonstwas: es muss immer jemand da sein, der sich um das Zeugs kümmert. Ich vermisse irgendwie die Zeiten, als alles noch einfacher war. Man konnte ohne Probleme im Netz surfen, auch ohne firewall. Man konnte seine Daten problemlos irgendwo angeben, ohne gleich eine Rechnung zu bekommen. Keine Scram Mails.......

Okay, verlassen wir mal die Fenster®­-Welt, wie siehts denn da jetzt wirklich aus. Kann man dort wirklich etwas anrichten, wenn man tcp und udp auf einem Interface dropt?

----------

## think4urs11

theoretisch könnte es einen Bug/buffer overlow in iptables bzw. generell im IP-Stack des Kernels geben der angegriffen werden kann.

Das letzte Mal das es sowas gab war glaube ich irgendwann zu 2.2x Zeiten, jedenfalls schon (IT technisch gesehen) Äonen her.

Und die Chance dafür das genau das gleiche auf einer $teuer$-Lösung von $vendor$ passiert ist prinzipiell genauso hoch.

Solche Lösungen werden immer dann bevorzugt wenn $sales-droid$ gut mit $manager-droid$ kann und letzteren davon überzeugt das nur gut sein kann was teuer ist. Hintergedanke ist meistens 'jaaa und wenn da mal was ist dann kann ich ja auf den Hersteller eindreschen, bei Linux/BSD kann ich das nicht'.

Ich hätte auch manchmal lieber eine iptables/pf-Firewall statt einer Checkpoint aber Konzernvorgabe ist nunmal letzteres, was willst du da machen?

----------

## sschlueter

 *LL0rd wrote:*   

> Okay, verlassen wir mal die Fenster®­-Welt, wie siehts denn da jetzt wirklich aus. Kann man dort wirklich etwas anrichten, wenn man tcp und udp auf einem Interface dropt?

 

Im Prinzip natürlich schon. Es wird dann trotzdem vom Kernel noch Code ausgeführt, der potentiell Sicherhetslücken enthalten kann. Wenn Routing oder Bridging aktiviert ist, ist es vermutlich noch mehr Code.

Ausserdem hast du ICMP vergessen.

Und du hast vermutlich nur an IPv4 gedacht. Vielleicht hast du ja nen IPv6-enabled Kernel und per netfilter nur IPv4 gefiltert.

Ausserdem hast du Layer2-Protokolle vergessen.

Richtig wenig durch Netzwerkverkehr an eth0 verusachter Code wird vermutlich nur dann ausgeführt, wenn du ifconfig eth0 down ausgeführt hast. Und selbst da wäre ich mir nicht sicher. Vermutlich müßte man das Kernel-Modul für eth0 entladen, damit wirklich kein Code mehr ausgeführt wird.Last edited by sschlueter on Wed Apr 19, 2006 6:40 pm; edited 1 time in total

----------

## sschlueter

 *Think4UrS11 wrote:*   

> theoretisch könnte es einen Bug/buffer overlow in iptables bzw. generell im IP-Stack des Kernels geben der angegriffen werden kann.
> 
> Das letzte Mal das es sowas gab war glaube ich irgendwann zu 2.2x Zeiten, jedenfalls schon (IT technisch gesehen) Äonen her.
> 
> 

 

Aber remote DoS-Anfälligkeiten (also, wo der Angreifer nicht seinen eigenen Code zur Ausführung bringen kann, aber das System immerhin lahmlegen kann) gab es im Laufe der Zeit immer wieder mal.

----------

## think4urs11

 *sschlueter wrote:*   

> Aber remote DoS-Anfälligkeiten (also, wo der Angreifer nicht seinen eigenen Code zur Ausführung bringen kann, aber das System immerhin lahmlegen kann) gab es im Laufe der Zeit immer wieder mal.

 

Im IP-Stack?

Wir reden hier doch von der Situation das am externen Interface alles weggedropt wird ... bei einem 'offenen' Zugang sieht das sicher anders aus.

----------

## LL0rd

 *sschlueter wrote:*   

> 
> 
> Ausserdem hast du ICMP vergessen.
> 
> 

 

Nee, ich habe da schon an ein bestimmtes Test-System gedacht. nmap hat da folgendes rausgeworfen:

```
Interesting ports on 192.168.8.1:

(The 1021 ports scanned but not shown below are in state: filtered)

PORT      STATE  SERVICE

53/tcp    open   domain

....

65301/tcp closed pcanywhere

MAC Address: 00:A0:24:5E:93:DD (3com)

Device type: general purpose

Running: Linux 2.1.X|2.2.X

OS details: Linux 2.1.19 - 2.2.25

Uptime 15.919 days (since Mon Apr  3 12:59:19 2006)
```

----------

## sschlueter

 *Think4UrS11 wrote:*   

>  *sschlueter wrote:*   Aber remote DoS-Anfälligkeiten (also, wo der Angreifer nicht seinen eigenen Code zur Ausführung bringen kann, aber das System immerhin lahmlegen kann) gab es im Laufe der Zeit immer wieder mal. 
> 
> Im IP-Stack?
> 
> Wir reden hier doch von der Situation das am externen Interface alles weggedropt wird ... bei einem 'offenen' Zugang sieht das sicher anders aus.

 

Jo, ich denke schon, dass es von den zahlreichen DoS-Anfälligkeiten auch einige gibt, die sich selbst dann ausnutzen lassen, wenn man alles dropt. 

Mh, hab mal grad kurz gesucht. Was hältst du von http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0454 ?Last edited by sschlueter on Wed Apr 19, 2006 7:29 pm; edited 1 time in total

----------

## sschlueter

 *LL0rd wrote:*   

> Nee, ich habe da schon an ein bestimmtes Test-System gedacht. nmap hat da folgendes rausgeworfen:
> 
> 

 

Mh, ich bin mir jetzt ehrlich gesagt nicht sicher, ob wir nicht eventuell aneinander vorbeireden...

99,999% der remote ausnutzbaren Sicherheitslücken kommen von Diensten. Wir sprechen jetzt gerade über die restlichen 0,001%   :Wink: 

----------

## think4urs11

 *sschlueter wrote:*   

> Mh, hab mal grad kurz gesucht. Was hältst du von http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0454 ?

 

Güldet ned  :Wink: 

Würde voraussetzen das ICMP aufs externe Interface nicht gedropt wird so wie ich das sehe. Aber OT wirds nun langsam schon oder?

----------

## sschlueter

 *Think4UrS11 wrote:*   

>  *sschlueter wrote:*   Mh, hab mal grad kurz gesucht. Was hältst du von http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0454 ? 
> 
> Güldet ned 
> 
> Würde voraussetzen das ICMP aufs externe Interface nicht gedropt wird so wie ich das sehe. Aber OT wirds nun langsam schon oder?

 

Naja, wir wärs mit http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0209 ?

OT? Hatte ich jetzt bislang nicht so empfunden, aber diese 0,001% sind ja tatsächlich nicht so interessant.

----------

## think4urs11

 *sschlueter wrote:*   

> Naja, wir wärs mit http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0209 ?
> 
> OT? Hatte ich jetzt bislang nicht so empfunden, aber diese 0,001% sind ja tatsächlich nicht so interessant.

 

Nö leider auch nicht  :Wink: 

Trifft nur zu wenn passend 'kaputtfragmentierte' Pakete durch die forward-chain laufen, wir wollten aber dropen.

Wie auch immer, es ist jedenfalls *sehr* unwahrscheinlich das man auf so einen Fehler läuft. Kommerzielle Anbieter wie Cisco und Checkpoint sind da auch nicht besser, nur teurer.

----------

## think4urs11

 *LL0rd wrote:*   

> Aber nehmen wir jetzt mal einfach unser Linux mit einer iptables Firewall. Diese Firewall ist ja dann eine Software Firewall. Jetzt lasse ich einfach jeden eingehenden Traffic an der eth0 Schnittstelle per iptables DROPen. Wie kann dann ein (manipuliertes) Paket etwas anrichten? Und wo ist jetzt der Unterschied zwischen so einer Software Lösung und den sauteueren Hardware Firewalls?

 

Auch eine 'Hardware-Firewall' muß letztlich Software laufen lassen, notfalls ASIC-unterstützt. Bei Linux heißt sowas eben iptables, bei Cisco heißts IOS etc.

Dann gibt es da noch Netzwerkkarten mit eigenem Prozessor, die liegen irgendwo dazwischen.

 *LL0rd wrote:*   

> Nee, ich habe da schon an ein bestimmtes Test-System gedacht. nmap hat da folgendes rausgeworfen:
> 
> ```
> Interesting ports on 192.168.8.1:
> 
> ...

 

Damit ist das genaugenommen schon keine Firewall mehr - es läuft eine Applikation, nämlich ein DNS. Eine Firewall im klassischen Sinn (also ein Paketfilter) tut auch nur exakt das, nämlich Pakete filtern und ist in keiner Weise remote ansprechbar - Managment erfolgt wenn man konsequent ist über eine Console bzw. Nullmodemkabel.

In deinem Fall würde ein Hacker erstmal versuchen den DNS irgendwie zu hacken bevor andere Sachen ausprobiert werden. (Merke: je höher im Stack ein möglicher Angriffspunkt liegt desto höher ist auch die Wahrscheinlichkeit das es irgendwelche Lücken gibt. Ist zwar sehr verallgemeinert aber als Richtschnur gar nicht so verkehrt.)

Außerdem scheint mir dein nmap nicht so ganz auf dem aktuellsten Stand zu sein, kann das sein? Sonst müßten da imho >1600 ports scanned auftauchen.

----------

## sschlueter

 *Think4UrS11 wrote:*   

> 
> 
> Trifft nur zu wenn passend 'kaputtfragmentierte' Pakete durch die forward-chain laufen, wir wollten aber dropen.
> 
> 

 

Hehe, verstehe, naja, du kannst jetzt zu allen Beispielen nein sagen, aber dann wäre die Kiste auch nicht mehr in der Lage, irgend etwas zu tun, und damit wird dieser kleine Ausflug nicht nur unspannend, sondern auch hochgradig realitätfern. In der Realität würde man angesichts der heutigen Strompreise dann nämlich lieber den Stecker ziehen.

 *Think4UrS11 wrote:*   

> 
> 
> Wie auch immer, es ist jedenfalls *sehr* unwahrscheinlich das man auf so einen Fehler läuft. Kommerzielle Anbieter wie Cisco und Checkpoint sind da auch nicht besser, nur teurer.

 

Habt ihr mal so verfolgt, wie das mit Fehlern im IOS aussieht?   :Shocked:   Da müssen Linux und die BSDs sich wirklich nicht verstecken.

----------

