entwickler.com

Eine das lokale Netz schützende Firewall läßt sich durch ein ähnliches Vorgehen wie beim in About Security #136 beschriebenen Ausspähen der in einem DSL-Router gespeicherten Internetzugangsdaten manipulieren. Ein entsprechender CSRF-Angriff wurde bereits in About Security #127 beschrieben. Der Angreifer kann sich (wie in About Security #136 beschrieben) die Informationen über die Firewall zuschicken lassen und danach den CSRF-Angriff in deren Logfiles einschleusen. Der Rest läuft dann wieder wie in About Security #127 und #136 beschrieben ab. Voraussetzung ist natürlich wieder, dass die webbasierte Administrationsoberfläche der Firewall für XSS und CSRF anfällig ist. Bei eigenständigen Firewall-Appliances sind solche Schwachstellen selten, Security-Appliances, egal für welchen Zweck, nutzen in der Regel gehärtete Betriebssysteme und sorgfältig ausgewählte und konfigurierte Software. Anders sieht es dagegen bei den in SOHO-Routern integrierten Firewall-Funktionen aus: Ist der Router von entsprechenden Schwachstellen betroffen, ist im Allgemeinen auch die über die gleiche Oberfläche konfigurierte Firewall manipulierbar.

Weitere Ziele

Weitere lohnende Ziele in lokalen Netzen sind z.B. lokale Webanwendungen, Datenbanken, zentral gespeicherte Konstruktions- oder Planungsunterlagen – kurz: Alles, von dem man nicht möchte, dass Konkurrenten oder böswillige Dritte es bekommen. Gezielte Trojaner-Angriffe im Rahmen von Wirtschaftsspionage sind inzwischen weit verbreitet. Bisher wurden dafür über Schwachstellen im Betriebssystem oder in Anwendungsprogrammen eingeschleuste Trojaner verwendet, aber es spricht nichts dagegen, den Webbrowser als Ausgangspunkt für weitergehende Angriffe zu übernehmen. Zwar werden in Intranets oft speziell entwickelte Webanwendungen eingesetzt, sodass ein Angreifer keine bereits bekannten Schwachstellen darin ausnutzen kann. Allerdings laufen diese Webanwendungen auf Standardsystemen.

Statt eine Schwachstelle in der Webanwendung kann der Angreifer also eine Schwachstelle im verwendeten Web- oder Application-Server auszunutzen versuchen. Oder er sucht aus dem Browser heraus in der Webanwendung nach Schwachstellen. Dass so etwas möglich ist, wurde von SPI Dynamics mit der Vorstellung von Jikto bewiesen: Jikto ist ein Schwachstellen-Scanner in JavaScript, der beliebige Webseiten nach Schwachstellen durchsuchen kann. Die Same Origin Policy wird durch die Nutzung von Google Translate umgangen. Das Programm war eigentlich nur für Demozwecke gedacht, gelangte aber in die "freie Wildbahn" und ist leicht über eine Suchmaschine wie z.B. Google zu finden. Das Programm ist ziemlich klein, es umfasst ca. 875 Zeilen kommentierten Code. Ein Angreifer, der gezielt bestimmte Schwachstellen finden und im Anschluss ausnutzen möchte, kommt sicher mit deutlich weniger Code aus.

Fernsteuerung

Einen Schritt weiter geht das Browser Exploitation Framework BeEF. Das läuft auf einem Server, mit dem sich die über XSS übernommenen Clients verbinden. Danach können vom Server aus verschiedene Aktionen auf dem Client gestartet werden. Deren Spannweite reicht vom Auslesen des Clipboards, einem JavaScript Portscan oder der Installation eines Keyloggers bis zur Ausnutzung von Browserschwachstellen zum Öffnen einer Shell.

Ausnutzen von Browserschwachstellen

Wer die Kontrolle über den Browser hat, ist nur einen Schritt von der Kontrolle über das System entfernt - er muss nur eine Schwachstelle im Browser oder dessen Komponenten finden und ausnutzen. Dazu ein paar Zahlen aus dem Symantec Internet Security Threat Report (1. Jahreshälfte 2007) (PDF):

• 39 Schwachstellen im Microsoft Internet Explorer, 34 in Mozilla-Browsern, 25 in Apple Safari und 7 in Opera.
• 237 Schwachstellen in Browser-Plug-ins (im 2. Halbjahr 2006: 74)
  89 % davon betreffen ActiveX-Komponenten (im 2. Halbjahr 2006: 58 %).
• Mehr als 50 % der durch die Betriebssystemanbieter geschlossenen Schwachstellen mit hoher Gefahrenstufe betrafen Webbrowser

Ein Angreifer hat also meist etliche Schwachstellen zur Auswahl, um über den Webbrowser die Kontrolle über den angegriffenen Rechner zu übernehmen. Und statt sein Opfer auf eine eigene präparierte Webseite zu locken, kann er den Schadcode auch über eine XSS-Schwachstelle in vertrauenswürdige Webseiten einschleusen. Im Falle von persistenten XSS-Schwachstellen muss der Benutzer dann nicht mal einen präparierten Link anklicken, um seinen Rechner zu infizieren – der Besuch der entsprechenden Seite reicht aus.

Fazit

Die vorgestellten Beispiele steigerten sich in mehreren Stufen:

• Ein Angreifer, der JavaScript ausführen kann, hat die Kontrolle über den Browser
• Wer die Kontrolle über den Browser hat, befindet sich im lokalen Netz – und damit hinter der Firewall
• Wer die Kontrolle über den Browser hat, kann die Kontrolle über das System erlangen

Man sollte XSS also nicht unterschätzen: Auch wenn diese Schwachstellen zurzeit meist für Phishing genutzt werden, besitzen sie ein großes Potenzial für weitergehende Angriffe.

Ab der nächsten Folge geht es nur noch indirekt um XSS: Das Thema sind dann Webwürmer, die unter anderem XSS-Schwachstellen für ihre Verbreitung nutzen.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen – Cross-Site Scripting"

• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #129: Cross-Site Scripting, reloaded
• About Security #130: DOM-basiertes XSS abwehren
• About Security #131: XSS-Angriffe (1)
• About Security #132: XSS-Angriffe (2)
• About Security #133: XSS-Angriffe (3): JavaScript Ping & Co.
• About Security #134: XSS-Angriffe (4): JavaScript Portscan
• About Security #135: XSS-Angriffe (5): JavaScript Portscan vorbereiten
• About Security #136: XSS-Angriffe (6): DSL-Router ausspähen
• About Security #137: XSS-Angriffe (7): Weitere Ziele