Post by Ingo HeinscherPost by Andreas Beck[Angriff auf nicht geschlossenen angreifbaren Dienst via FTP-NAT]
Du hast Dich null,null damit beschäftigt, wie der Angriff funktioniert,
oder?
Du hast überhaupt nicht verstanden, was ich schreibe.
Nein, denn es ist wirres Zeug.
Post by Ingo HeinscherAber Du hast auch die Frage nicht beantwortet.
Doch, klar und deutlich. Ein Standardpaketfilter kann über einen
semiaktiven Angruff ausgehebelt werden, was den Zugriff auf verwundbare
Dienste hinter jenem Paketfilter ermöglicht. Punkt.
Die Logs meines FTP-NAT-Tests weisen das eindeutig nach. Allerdings in
der Regel für Maschinen hinter NAT. Ich guck mal eben nach, ob es schon
jemand ohne NAT ausprobiert hat ... na also:
2006-11-06 19:22:22 Local port 85.179.29.xxx:80 open via 85.179.29.xxx:80
2006-11-07 12:43:47 Local port 194.xxx.xxx.xxx:111 open via 194.xxx.xxx.xxx:111
Und letzteres ist auch kein false Positive von einem ohnehin
ungeschützten System. Ich hab den dank fester IP (daher die xxx) nochmal
gegengeprüft: per direkter Verbindung komme ich nicht auf die 111, sehr
wohl aber auf die (vermutlich absichtlich nach außen angebotene) 22.
Post by Ingo HeinscherDass, wenn man es fertigbringt, bösen Code auf dem fremden Rechner zum
Laufen zu kriegen, in jedem Fall ein Problem vorliegt, nimmst Du überhaupt
nicht zur Kenntnis.
man Sandbox.
Es ist scheißegal, ob in einer solchigen böser Code ausgeführt wird, das
ist Sinn einer Sandbox. Und Java-Applets sind nunmal Code aus unsicherer
Quelle. Man kann das Problem lösen, indem man Applets und Plugins
verbietet. Das ist aber für die Zielgruppe nicht akzeptabel.
Post by Ingo HeinscherEs ist nicht die Aufgabe des Paketfilters (ebensowenig wie die des
Diensteabschaltens), das zu verhindern, aber Du wirst es der
armen Technik vor, dass sie dagegen nichts tun kann.
Nein, ich werfe Dir vor, eine Technik zu propagieren, die in diesem
Szenario dem Abschalten von Diensten unterlegen ist. Mit abgeschalteten
Diensten passiert nicht. Mit Paketfilter, der nicht speziell für die
Situation angepaßt ist, schon.
Post by Ingo HeinscherPost by Andreas BeckWenn kein angreifbarer Dienst existiert (weil alle Dienste abgeschaltet
sind), kann man mit der Methode keinen Schaden anrichten.
Man kann einen Dienst installieren, z.B. mittels eines Java-Applets.
Nein. Nicht außerhalb der Sandbox. Das heißt mit Userrechten und mit
eingeschränktem Schadpotential. Maximal kann man ein bisschen
Rechenleistung abzocken.
Man kann mit Hilfe des Applets auf einen _beliebigen_ laufenden Dienst
konnektieren.
Szenario:
Normaler PC, zur üblichen Internetnutzung, also mit Browser und
Java-Plugin oder Flash oder ähnlicher clientside-Sprache, die in
einer Sandbox abläuft.
Wenn das schon nicht zur Diskussion steht, kannst Du hier aufhören zu
lesen, und Dich in einen Elfenbeinturm Deiner Wahl verkriechen.
Nehmen wir weiter an, einer der Dienste, den die Installation dieses PCs
normalerweise anbieten würde, sei verwundbar für eine Remote-Root-Lücke.
Wenn keiner der möglicherweise vorhandenen Dienste eine Lücke haben
darf, braucht man die ja weder abzuschalten, noch per Paketfilter
abzudecken.
So - jetzt die Varianten
A) Man hängt das so ans Internet. => Rechner ist remote aufknackbar.
Nach dem Dienst scannen, Exploitcode schicken, Root sein.
B) Die Dienste - darunter auch der mit der Lücke - werden abgeschaltet.
Damit ist sichergestellt, daß die Lücke nicht mehr ausgenutzt werden
kann.
C) Die Dienste - darunter auch der mit der Lücke - laufen weiter, und
eine "normale" Firewallkonfiguration, d.h. alles outbound erlaubt,
plus "established/related" mit allen relevanten Tracking-Helpern
um volle Funktionalität zu erhalten, wird zum Schutz eingesetzt.
In diesem Fall ist ein direktes Ausnutzen wie unter A) nicht mehr
möglich.
Kann ich nun den Nutzer aber dazu bewegen, eine ganz normale
Internetseite zu besuchen (mit Nutzerrechten, aktuellem Browser,
keine Sicherheitslücken in Browser oder Plugins), dann kann ich
in diese Seite ein Applet integrieren.
An sich ist ein Applet ja nichts böses. Es läuft mit Userrechten und
in einer Sandbox. es darf nicht auf die Platte schreiben, usw. usw.
Dieses hier ist aber böse. Es verhält sich wie ein FTP-Client.
Es verbindet zurück zu seinem Server (ist im Sandbox-Modell erlaubt)
auf Port 21 und tauscht mit dem Server ganz normale
FTP-Protokollnachrichten aus.
Diese werden _korrekt_ vom Paketfilter interpretiert und der
Paketfilter öffnet den Weg für eine hereinkommende
FTP-Data-Verbindung.
Da sich diese Verbindung auf einen _beliebigen_ Port leiten läßt,
kann ich damit den Dienst mit der Lücke angreifen. => remote root.
Das Applet selbst kann das _nicht_ - das wäre eine Verletzung der
Sandbox-Regeln, was zum Abbruch des Applet führen würde.
Angriff also: User auf die Seite locken, warten daß das Applet
anläuft, zum Dienst konnektieren, Exploitcode schicken, Root sein.
Mit dem Applet alleine kann man _nicht_ Root werden. Egal welches
Applet ich schicke.
Folgerung: Es gibt eine Situation, die bei einem für übliche Aufgaben
konfigurierten PC gut vorstellbar ist, in der ein verwundbarer Dienst
durch eine Standard-Firewall hindurch angreifbar ist.
Es gibt viele Möglichkeiten, diese Situation zu vermeiden:
- keine clientside-Sprachen einsetzen. Bzw. gar keine Plugins, die
ähnliche Effekte haben könnten. Streaming Video könnte man evtl.
auch benutzen.
- alle problematischen related-Helper abschalten.
- keine related-Regeln verwenden.
- die Firewallkonfiguration speziell gestalten, um den Zugriff auf
die relevaten Dienste explizit zu verbieten, bevor related-regeln
greifen.
Die ersten 3 Regeln bedeuten Funktionalitätseinschränkungen,
die letzte bedeutet, daß man eine nichttriviale Firewallkonfiguration
hinkriegen muß.
Ergo: Dienste abschalten ist der sicherere Zustand. Er erlaubt zumindest
diesen Angriff nicht, und man muß keine Funktionalitätseinschränkungen
hinnehmen.
Alternativ kann man die Firewall speziell so konfigurieren, daß die noch
laufenden Dienste explizit geschützt werden. Der Aufwand, das richtig
hinzukriegen ist in etwa vergleichbar mit dem, die Dienste abzuschalten.
=> Wenn man die Dienste abschalten kann, ist das die sicherste Methode.
Kann man das nicht, ist die nächstsicherere Methode, die Dienste nur ans
interne Interface zu binden. Dann sind sie auch nicht von außen zu
erreichen.
Kann man das auch nicht, muß man sich genaue Gedanken machen, wie man die
Firewall konfiguriert, damit sie die verbleibenden Dienste wirkungsvoll
schützt. Ich tue das in der Regel durch Verzicht auf Protokolle, die
inbound related Verbindungen annehmen müssen.
Will man das nicht, kann man versuchen, die übrigen Dienste explizit
abzudichten. Das kann auch nervig sein, wenn die z.B. via Portmapper auf
dynamischen Ports rumhopsen.
Post by Ingo HeinscherGegen diese Klasse von Angriffen
Welche? Das Laufenlassen eines Applets ist kein Angriff.
Das Untertunneln des Paketfilters mit Hilfe der related-helper ist einer.
Er unterläuft das Sicherheitslayer Paketfilter unter üblichen
Randbedingungen.
Der Angriff ist weniger massentauglich wie der direkte Portscan nach
offenen Ports, aber er ist problemlos machbar.
Post by Ingo Heinscherhilft weder ein hostbasierter Paketfilter (wobei, für eine Unterklasse
davon schon) noch das reine Abschalten lokaler Dienste.
Siehe oben. Das Abschalten lokaler Dienste hilft. Der Dienst, der nicht
zur Verfügung steht, kann nicht angegriffen werden.
Der Dienst, der vom Paketfilter verdeckt wird, kann angegriffen werden,
wenn nicht spezielle Maßnahmen im Paketfilter getroffen werden, um das
zu vermeiden. Diese Maßnahmen sind spezifisch für die betreffende
Rechnerkonfiguration und werden von üblichen Paketfilterkonfigurationen
nicht per Voreinstellung getroffen.
Post by Ingo HeinscherPost by Andreas BeckMan kann den Paketfilter dann zwar umgehen, aber das ist egal. Man
erreicht ja niemanden.
Doch, das Java-Applet, das natürlich auch in der Lage ist, einen lokalen
Dienst anzubieten,
Das ist egal. Es ist in einer Sandbox. Mit Hilfe des Applets wird man
nicht root. Mit einem verwundbaren Dienst schon.
Post by Ingo Heinscheregal ob Du nun alle abgeschaltet hast oder nicht. Meine Güte.
Meine auch. Dienst nicht da => ich kann nicht an ihn konnektieren => ich
kann die Sicherheitslücke darin nicht ausnutzen.
Das Applet kann den Dienst nicht starten und was es selbst zur Verfügung
stellt, läuft in der Sandbox.
Post by Ingo HeinscherPost by Andreas BeckKein Kommentar. Bzw. ab sofort /dev/null.
Ja, ist recht. Mach' ganz schnell den Kopf dicht, sonst gibt's ein break()
in der Denkschleife.
Ich konnte es mir nicht verkneifen ... irgendwie hab ich doch die
Hoffnung, daß Du doch nicht nur trollst, sondern wirklich Probleme hast,
das Beispiel zu verstehen.
Wenn's jetzt nicht klar ist, weiß ich aber auch nicht mehr weiter.
Der geneigte Leser wird es hoffentlich nachvollziehen können, dann ist
ja auch kein Schaden entstanden.
CU, Andy
BTW: break; ...