Donnerstag, 24. November 2011


Topthema

Donnerstag, 22. April 2010 | Topthema

About Security #251: Schwachstellen-Suche im Überblick (3)

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/055071)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Im dritten Teil des Überblicks über die Schwachstellen-Suche in Webanwendungen geht es zuerst um die Suche nach typischen Schwachstellen in kompilierten Programmen. Auch wenn Webanwendungen meistens in Skriptsprachen geschrieben werden, können Pufferüberlaufschwachstellen etc. darüber ausgenutzt werden: Entweder in externen Programmen, oder im Interpreter der Skriptsprache selbst, der ja i.A. auch nichts anderes als ein kompiliertes Programm ist.

Schwachstellen in kompilierten Programmen

Den Anfang macht der Klassiker schlechthin: Pufferüberlauf-Schwachstellen. Zur Suche werden für verdächtige Parameter einfach sehr große Werte eingegeben und das Verhalten der Anwendung analysiert (siehe About Security #196). Fehlermeldungen externer Programme werden meist von der Webanwendung abgefangen, da sie ja i.A. weder für den Benutzer gedacht noch für ihn von irgend einem Wert sind. Stattdessen wird dann meist eine allgemeine Fehlermeldung ausgegeben, und meist gibt es Unterschiede zwischen den Reaktionen auf falsche normallange Eingaben und auf überlange Eingaben. Kann eine Pufferüberlauf-Schwachstelle nicht behoben werden, reicht es aus, die zu langen Werte von der betroffenen Komponente fern zu halten (#197). Weitere typische Schwachstellen sind die verschiedenen Integer-Schwachstellen: Integerüberläufe (Integer Overflows) und Vorzeichenfehler (Signedness Errors), die ebenfalls mit entsprechenden Testwerten gefunden werden können (#198). Zu guter Letzt sind Formatstring-Schwachstellen an der Reihe: C-Funktionen, die formatierten Text ausgeben können, erwarten als zusätzlichen Parameter Formatierungsanweisungen. Gelingt es einem Angreifer, dafür eigenen Anweisungen einzuschleusen, kann er Teile des Speichers überschreiben und eigenen Code ausführen. Auch diese Schwachstellen findet man mit entsprechenden Testmustern, wobei wie im Fall der Pufferüberlauf-Schwachstellen wieder auf die Reaktion der Anwendung geachtet werden muss, da Fehlermeldungen externer Programme wie bereits oben erwähnt meist von der Webanwendung abgefangen werden (#199).

Bei Anwendungen, die aus mehreren Schichten bestehen, können Schwachstellen in einer bzw. Angriffe auf eine Schicht sehr schnell zur Kompromittierung des Gesamtsystems führen. In Umgebungen, in denen verschiedene Anwendung die gleiche Infrastruktur nutzen, können Schwachstellen in bzw. Angriffe auf eine der Anwendungen entweder zur Kompromittierung der Infrastruktur und/oder aller anderen Anwendungen führen. Im Folgenden geht es daher um

Angriffe auf die Architektur der Webanwendung

In Schichtenarchitekturen gibt es meist besondere Vertrauensbeziehungen zwischen den verschiedenen Schichten, z.B. vertraut eine Schicht oft darauf, dass die ihr übertragenen Aufgaben von einem von der sie aufrufenden Schicht korrekt authentifizierten Benutzer ausgelöst wurden etc.. Diese Vertrauensbeziehungen kann ein Angreifer u.U. ausnützen (#201). Dabei gibt es für Angriffe zwei Möglichkeiten: Schwachstellen in der einen Schicht werden ausgenutzt, um Schutzmaßnahmen einer anderen Schicht zu unterlaufen, oder nach dem erfolgreichen Angriff auf eine Schicht wird davon ausgehend eine andere Schicht angegriffen. Um Schwachstellen zu finden, muss bei jeder Schwachstelle in einer Schicht geprüft werden, ob darüber Angriffe auf die anderen Schichten möglich sind (#202).

In Umgebungen, in denen verschiedene Anwendungen die gleiche Infrastruktur nutzen, können Schwachstellen in bzw. Angriffe auf eine der Anwendungen entweder zur Kompromittierung der Infrastruktur und/oder aller anderen Anwendungen führen. Typische Fälle solcher Umgebungen sind das Shared Hosting und Application Service Provider. Schwachstellen können dabei z.B. in den verschiedenen Zugriffsmechanismen auftreten (#203). Ein weiteres Problem sind interne Angriffe, die von einem kompromittierten oder böswillig genutzten Teil der Umgebung auf die anderen Teile ausgehen (#204). Ein konkretes Beispiel für so einen Angriff ist ein im April 2010 durchgeführter Angriff auf WordPress-Nutzer, die ihre Websites bei Network Solutions gehosted hatten, siehe auch die Security-Hinweise vom 12. April 2010: WordPress speichert die Zugangsdaten für die Datenbank als Klartext in der Datei wp-config.php. WordPress empfiehlt für Shared-Hosting-Installationen für diese Datei die Rechte 750 zu verwenden, viele Benutzer beließen es aber bei der Standard-Einstellung, so dass die Datei für alle Benutzer lesbar war. Ein bösartiger Benutzer von Network Solutions durchsuchte die Server mit einem Skript nach diesen Dateien und sammelte die Zugangsdaten ein, mit denen er dann auf die Datenbanken zugreifen und sie manipulieren konnte.

Bei der Suche nach Schwachstellen in Shared Environments muss man zwei Bereiche berüchsichtigen: Zum einen Schwachstellen in den vorhandenen Webanwendungen, die einen Angriff auf das gesamte Shared Environment erlauben. Dabei geht man genau so vor, wie bei der Suche nach Schwachstellen in einzeln gehosteten Webanwendungen. Zum anderen muss man nach Schwachstellen im Shared Environment selbst suchen (#205).

In der nächsten Folge wird diese Zusammenfassung fortgesetzt.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren