Vor einigen Tagen hat das BSI die neuen Grundschutzkataloge veröffentlicht, also die Version 2009 (mit Bezug auf den Erstellungszeitraum). Wir freuen uns der Grundschutz-Community wie schon im letzten Jahr einen Vergleich aller Änderungen bereitstellen zu können.

Das Archiv befindet sich auf unserem Webserver und enthält aller Maßnahmen als PDF Dokumente, sortiert nach den üblichen Schichten des IT-Grundschutz. Alle Änderungen zur vorherigen Version 2008 sind mit Änderungsmarkierungen hervorgehoben.

Wir danken dem BSI für die Erlaubnis die Daten bereitstellen zu dürfen und wünschen allen Anwendern viel Spaß beim Lesen nach Änderungen.

/sf

Hier treffen sich Menschen, die sich beruflich oder privat mit Webanwendungen und deren Sicherheit auseinandersetzen, egal ob Entwickler, Manager, Pentester oder Webmaster. Die Atmosphäre bei Veranstaltungen der OWASP ist sehr offen und locker. Es geht um Erfahrungsaustausch, der auch bei den regelmäßigen Treffen durch einen Vortrag unterstützt wird. Wer Produkte verkaufen will, ist hier falsch.

Wir treffen uns am 01.02.10 um 19 Uhr im Restaurant Wartburg Tol(l)eranz.

Programm:
19.00h Beginn
19.30h Vortrag Vorstellung OWASP Whitepaper: “Projektierung der
Sicherheitsprüfung von Webanwendungen”, Tobias Glemser im Anschluss Diskussion

Für die Planung bitte ich potentielle Interessenten mir bis 28.01. eine kurze Mail schicken bzw. hier auf Xing auf “nehme teil” zu klicken zwecks Reservierung. Wer das verschwitzt darf aber auch kommen..

Bei Fragen zum Stammtisch einfach kurz anschreiben oder mal auf die Webseite der OWASP klicken.

Alle Infos zum Event auch auf:
https://www.xing.com/events/2-owasp-stammtisch-stuttgart-01-02-stuttgart-455385
https://lists.owasp.org/pipermail/owasp-germany/2010-January/000126.html

…irgendwer hat beim Aufräumen wohl auf den falschen Knopf gedrückt, oder so ähnlich. Sicher ist, da fehlt etwas.

/sf

Dies geschieht natürlich nur, weil sich der Provider Sorgen um die Performance der mobilen Verbindung macht und daher die Bilder besser komprimiert. Oder geschieht dies, da sich der Provider sorgen um das Datenvolumen seiner Nutzer macht und daher die Bilder bis zur Unansehnlichkeit komprimiert? In Werbefirmen und Grafikabteilungen wird dieses Vorgehen sicher nicht auf Begeisterung stoßen.

Was kann man tun? Immer fleißig “Shift + A” drücken. Denn sonst kanns teuer werden.

/fh

Zurück zum Artikel auf heise. Neugierig habe ich das dort Beschriebene ausprobiert: mit dem IE eine Seite als PDF-Dokument drucken. Zuvor noch die Kopf- und Fußzeile angepasst, sodass die URL verschwindet (ja ich weis, das war nicht erwähnt) und siehe da: Entgegen der Behauptung des Autors ist der Pfad nicht im Dokument aufgetaucht (zum Einsatz kamen  IE 8 und FreePDF XP). Ich frage mich, wie der Autor darauf kam… Schuld daran könnte der von ihm verwendete PDF-Drucker gewesen sein, who knows

/sb

Leider erleben wir (und andere Ausbildungsbetriebe) sehr häufig, dass Bewerber sich vorher nicht mit der Firma, bei der sie sich bewerben auseinander gesetzt haben. Wir starten nun einen kleinen Versuch: Sofern Sie sich bei uns bewerben möchten (oder dies bereits getan haben), lassen Sie uns in Ihrem Anschreiben wissen, dass Sie diesen Blog-Eintrag gelesen haben. Das zeigt uns auf rasche Art und Weise, dass Sie sich mit uns im Vorfeld auseinandergesetzt haben. Damit steigen die Chancen Ihrer Bewerbung deutlich.

Wir freuen uns darauf, von Ihnen zu lesen!

/gt

Hallo zusammen,

so, endlich kommen die Schwaben mal in die Gänge

Andy Kurtz und ich freuen uns, Euch zum ersten OWASP Stammtisch Stuttgart
einzuladen. Hat ja nur vom Chapter Meeting in Mannheim bis heut gedauert

Wir treffen uns erstmals am 30.11. um 19 Uhr im Restaurant Columbus
(http://www.columbus-stuttgart.de/ – steht aber nicht viel drauf). Das
Restarant ist direkt neben dem Universitätscampus Vaihingen, daher mit Auto
und Bahn recht gut erreichbar.

Das erste Treffen dient dem Beschnuppern und gemeinsamen Pläne schmieden für
die nächsten Male, also:
– Kennenlernen
– Standortwechsel?
– Interessenslage für Vorträge
– Sonstiges

Der Stammtisch wird dann ab Februar 2010 jeden ersten Montag im Monat
stattfinden. Wer also seine Jahresplanung gerade gestaltet: Kalender auf und
gleich reinschreiben

Für die Planung wäre es spitze, wenn mir potentielle Interessenten bis
27.11. eine kurze Mail schicken würden zwecks Reservierung. Wer das
verschwitzt darf aber auch kommen..

Wohlan, wir freuen uns auf Eure Teilnahme, sagt es Euren Kollegen und
Freunden weiter.

Viele Grüße

Tobias

/gt

Die meisten interessieren sich für die Auswirkungen, daher die
Zusammenfassung
vorab:
Mit den neuartigen Angriffen ist es möglich, dass ein Angreifer bestimmt, welche Anfrage an einen Server gesendet wird. Dies ist nur in einem Man-in-the-Middle Szenario möglich. Durch den neuen Angriffsvektor ist es dem Angreifer jedoch zu keinem Zeitpunkt möglich:

• die ursprüngliche Anfrage im Klartext zu sehen
• die Antwort im Klartext zu sehen
• Antwortdaten zu verändern

Allerdings

ist es ihm ggf. durch Schwachstellen der Webanwendung und dem Zweck der Webanwendung, auf die ein Client zugreift möglich Transaktionen durchzuführen oder Daten zu versenden (siehe Beispiele).

Wie funktioniert’s?
Leider sind zunächst einige technische Grundlagen nötig:

Session Renegotiation
Kurzbeschreibung: Erstellt einen neuen kryptographischen Kontext.
Beschreibung: Nach dem Aufbau einer verschlüsselten Verbindung zwischen Server und Client kann jede Seite eine “Session Renegotiation” initialisieren, die vollständig im
verschlüsselten Kanal abläuft. Hierbei werden die Verschlüsselungsparameter neu verhandelt. Jedes Session erhält eine Session-ID.

Session resumption
Kurzbeschreibung: Performance-Optimiering, um eine vorhandene Session wieder nutzen zu können.
Beschreibung: TLS erlaubt die Fortsetzung (resumption) einer Session. Hierbei gibt der Client die Session-ID an und die Session wird ohne Neuaushandlung der Parameter weitergeführt. Es ist also kein Sicherheitsmerkmal, sondern dient der Performance-Steigerung.

Das Problem
Bei einer Session Renegotiation (kann entweder der Client oder der Server anfragen) wird ein vollständig neuer kryptografischer Kontext erstellt. Das heißt, dass zwischen der Anfrage vor und der Anfrage nach einer Session Renegotiation keine logische Verbindung besteht, wenn auch beide verschlüsselt sind.
Kurzbeispiel: Ein Client sendet eine unvollständige HTTPS-Anfrage an den Webserver, veranlasst eine Session Renegotiation und sendet dann den Rest der HTTPS-Anfrage. Der Webserver erhält vom SSL-Modul dann die vollständige Anfrage und “merkt” nicht, dass diese aufgeteilt war.
Da zwischen den beiden Sessions wie gesagt keine logische Verbindung besteht, kann der erste Teil der Anfrage von einem Angreifer kommen, der zweite Teil der Anfrage vom Opfer. Hierfür muss der Angreifer in der Lage sein Anfragen von einem Opfer abzufangen, es ist also eine Man-in-the-Middle-Szenario erforderlich.

Beispiel zertifikatsbasierte Client-Authentisierung
Die Authentisierung des Clients kann verzeichnisspezifisch erfolgen. Daher muss der Server erst die Anfrage des Pfades kennen, um die Gültigkeit des Zertifikats zu prüfen. Auf welches Verzeichnis der Client zugreifen möchte, ist also erst nach einer verschlüsselten Sitzung für den Server ersichtlich. Es wird also zunächst immer eine TLS-Verbindung ohne client-seitige Authentisierung aufgebaut und sofern der Client auf ein geschütztes Verzeichns zugreifen möchte, muss der Server die TLS-Verbindung neu verhandeln, um das Client-Zertifikat erneut zu erhalten. Bei der Neuverhandlung besteht durch die fehlenden logische Verknüpfung zwischen den Anfragen eine Authentisierungslücke zwischen der ursprünglichen Anfrage und der Authentisierung: Es wird in der Folge die ursprüngliche Anfrage, die nicht authentisiert ist, durch den Server durchgeführt.

Konkret gesprochen:

TLS Renegotiation

Beispiel Bank (Theorie)
Nehmen wir an, eine Bank lässt Transaktionen zu, ohne eine TAN zu verlangen. So würde folgender Aufruf 10 EUR an das Zielkonto 12345 mit der BLZ 99999 versenden. Dieses gehört dem Angreifer:

GET /banking/ueberweise.jsp?knr=12345&blz=99999&amount=10&cur=EUR

Das Opfer meldet sich an und ruft irgendeine Seite des Bankung aus, z. B.
GET /banking/umsaetze.jsp
Cookie: cookie_des_opfers

Der Angreifer verändert diese Anfrage nun wie folgt:
GET /banking/ueberweise.jsp?knr=12345&blz=99999&amount=10&cur=EUR
X-Ignoriere-dies: GET /banking/umsaetze.jsp
Cookie: cookie_des_opfers
Ein X-Header wird immer vom Webserver ignoriert. Mit diesem Angriff wird also an die “böse” GET-Anfrage des Angreifers die GET-Anfrage des Clients angehängt. Sofern der Angreifer Kenntnis der Webanwendung hat und durch einen Aufruf, nicht mehrere, eine “böse” Aktion auslösen kann, ist die Schwachstelle praxisrelevant. Sofern im Beispiel also eine TAN im Nachgang abgefragt würde (und das Opfer sich wundert, warum er eine TAN für eine Überweisung eingeben soll, die er nicht veranlasst hat), bekommt der Angreifer keine 10 EUR, da der Angriff nicht mit nur einem Aufruf erfolgreich wäre.

Beispiel Twitter (echte Welt)
Twitter hat(te) ein Problem. Dies kommt aber erst nur durch die neue Schwachstelle zum Tragen. Dabei zeigt sich, dass der Angriffsvektor vergleichbar mit Cross Site Request Forgery (CSRF, siehe hier und hier).
Mit dem neuartigen Angriff kann man wie beschrieben vor die Anfrage des Opfers seine eigene Anfrage schreiben.

Man kann hierbei nicht nur GET-Parameter verarbeiten, sondern auch POST-Parameter, sofern die Webanwendung mit Formularen arbeitet. Im Falle der Twitter-API wird mit Hilfe einer POST-Anfrage die Statusmeldung aktualisiert:
$curl -u "benutzer:passwort" -d "status=Schreibe einen Blog-Artikel" https://twitter.com/statuses/update.xml
Die Option “-d” gibt an, dass es sich um eine POST-Anfrage handelt. Mit Hilfe der Schwachstelle kann ein Angreifer die ersten 140 Zeichen (maximale Länge einer Twitter-Nachricht) in sein Tweet posten.
Das Opfer sendet die oben stehende Anfrage, der Angreifer hängt die Anfrage des Opfers an seine eigene, folgende Anfrage:
"POST /statuses/update.xml HTTP/1.1\r\n" \
"Authorization: Basic %s\r\n" \
"Host: twitter.com\r\n"\
"Accept: */*\r\n"\
"User-Agent: curl/7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8\r\n"\
"Content-Length: 147\r\n"\
"Content-Type: application/x-www-form-urlencoded\r\n\r\n"\
"status="

Als Statusnachricht wird also die die POST-Anfrage des Opfers angegeben. Die ersten 140 Zeichen der POST-Anfrage werden daher in das Tweet des Angreifers geschrieben. Darin enthalten ist die Base64-codierte Kombination aus Benutzername und Passwort des Opfers für die API.
Wichtig: Der Angreifer hat auch hier zu keiner Zeit die Antwort auf die Anfrage des Opfers einsehen können! Die sensitiven Daten wurden durch die Anfrage in der Webanwendung gespeichert und wurden dadurch erst einsehbar. Digest-Authentication fällt dem Angriff also nicht in jedem Szenario, sondern nur in sehr speziellen Szenarien zum Opfer.

Quellen/Weitere Informationen
http://www.ietf.org/mail-archive/web/tls/current/msg03928.html
http://extendedsubset.com/?p=8 (unbedingt die “helpful protocol diagrams” beachten!)
http://www.links.org/?p=780
http://www.securegoose.org/2009/11/tls-renegotiation-vulnerability-cve.html
http://blogs.iss.net/archive/stealingcookieswiths.html
http://blog.g-sec.lu/2009/11/tls-sslv3-renegotiation-vulnerability.html

/gt

Bereits 2008 wurde das Tool angekündigt, aber erst just durch Softwarepiraten in den dunklen Sphären des Internets veröffentlicht. An sich gar nicht schlecht, immerhin werden regelmäßig Entwicklerversionen neuer MS-Betriebssysteme veröffentlicht.

Man darf gespannt sein, welche Details in den nächsten Tagen zu den technischen Methoden der Strafermittler noch veröffentlicht werden.

/gt

Vorstellung des Open Web Application Security Project (OWASP)
Nach einer kurzen Begrüßung des German Chapter Board Members Georg Heß hat Boris Heitkamp einen guten Überblick über die OWASP Struktur und Projekte gegeben. Erwähnenswert sind aus meiner Sicht noch nicht so bekannte Projekte (neben der Top 10 natürlich):

• owasp.tv (Videos von Appsec Konferenzen)
• OWASP ESAPI Project (zentrale Sicherheits-”Toolbox” für Webanwendungen in verschiedenen Sprachen)
• Moderated RSS Feed (gutes RSS-Feed rund um die OWASP und Web-Application Security)

OWASP Education Project
Martin Knobloch hat in der ihm eigenen Mischung aus holländischem und heidelberger Akzent das Projekt vorgestellt und um Mithilfe gebeten. Ziel sind einheitliche und gute Schulungsunterlagen, die jeder frei verwenden kann. In jedem Fall einen Blick wert.

Praktische Erfahrung mit dem Secure Software Lifecycle
Ziel des Vortrags war ein Praxisbericht über verschiedene SDLC in vier Firmen. Anfangs wurde z. B. CLASP vorgestellt, allerdings die Praxisrelevanz in Frage gestellt, vor allem aufgrund der Komplexität. Und ich hab nochmal eine andere Bedeutung der Abkürzung BSI gelernt. Build Security In vor National Cyber Security Division. Im Gegensatz zu CLASP oder dem Microsoft Vorgehensmodell ist es nicht prozessgetrieben, sondern eine Sammlung von Best Practices. Interessanter Ansatz in einer mehr und mehr prozessgetriebenen Welt.

Der Ansatz von Bruce Sams ist quasi nach dem KISS-Prinzip: Möglichst einfach, nah an den Entwicklern, auf der anderen Seite muss auch die Security-Abteilung abgeholt werden, also meist “Compliance” nachgewiesen werden.

Kernaussage: Einen Secure Software Development Lifecycle muss man sich in jeder Firma erarbeiten und existierender Ansätze ständig anpassen und optimieren.

Sichere Entwicklung und gängige Schwachstellen in eigenentwickelten SAP-Web-Anwendungen
Sehr spannendes Thema: SAP-Security. Sebastian Schinzel stellte diverse Frameworks, die für SAP bestehen vor und zeigte Schwachstellen auf. Auf der anderen Seite ging er auf Aspekte der sicheren Entwicklung in SAP-Umgebungen ein. Insbesondere beim Customizing gibt es hier viele Probleme und Schwachstellen, die man von den “normalen” Webanwendungen kennt. Interessant: Bei einer Kurzumfrage gab es niemand, der die Meinung vertrat, dass es zwei identische SAP-Installationen gibt.
Interessant waren die Ausführungen über den SAP Web Server, der von Haus aus schon einen Blacklist-Filter für einige wenige Angriffewie XSS, die leicht umgangen werden können.

Die Abbildung der OWASP Top 10 auf die SAP Business Server Pages zeigt, dass bis auf A7 Broken Authentication und Session Management eigentlich alles geht. Sebastian hat XSS und Injection Flaws vorgestellt und Gegenmaßnahmen skizziert.

Der Vortrag war sehr angenehm präsentiert und spannend, vor allem, wenn man nicht in der SAP-Welt zu Hause ist. Also: Auf jeden Fall den Vortrag herunterladen!

Adaptive Sicherheit durch Anomalieerkennung
Ein wunderschöner Titel muss ich sagen Die Idee ist eine “Next Generation WAF”, die mittels Anomalie-Erkennung mehr erkennen soll, als eine klassiche WAF. Aus Sicht des Referenten Hartmut Keil bieten die statischen Regelwerke (Black- und Whitelisting) keinen realistischen Ansatz mehr dar. Der Ansatz der Anomalie-Erkennung kennt man z. B. aus Spam-Filtern oder heuristischen Modulen in Virenschutzprogrammen. Es gibt nun also einen ersten Proof-of-Concept, der mit einer Learning-Phase automatische Regeln generiert, für Antworten des Webservers und Anfragen von Clients. Dabei werden auch Beziehungen zwischen Requests/Response-Paaren gelernt. Die Diskussion im Anschluss des Vortrags war sehr kontrovers und zeigte diverse Probleme des Modells auf.

Design Bugs
Nach kleinen Zeitproblemen aufgrund eines kurzfristig einberufenen Beamer-Streiks hat Alexios Fakos in der ihm eigenen Vortragsweise anhand der OWASP Top 10 (A6 bis A9) klasissche Design-Fehler vorgestellt. Eingangs durch den Referent erwähnt: Keine technisch allzu anspruchsvolle Darbietung, da u. A. die Marketing-Abteilung die Zielgruppe darstellt. Die angeführten Beispiele waren IMHO nicht ganz optimal, z. B. wurde als schlecht dargestellt, dass sofern der Benutzername bei einem Forum bereits vergeben ist, dem Nutzer dies dargestellt wird. Das liegt nunmal in der Natur der Sache, dass man einen Benutzernamen nicht doppelt registrieren kann und der Benutzer dies auch angezeigt bekommen muss. Nun gut, hat mich persönlich jetzt nicht umgerissen, viele Beispiele mit bedingter Aussagekraft.

JavaScript from Hell – advanced client side injection techniques of tomorrow
Einer der wenigen technischen Voträge am heutigen Tag, ich war im Vorfeld sehr gespannt auf die JS-Injection von morgen. Zunächst gabs eine kleine Geschichtsstunde, im Anschluss einige Obfuscation-Beispiele. Sehr nett war das Firebug-Beispiel, in dem mit der Funktion toSource sehr stark verschleierter JS-Code im Klartext angezeigt wird. Logisch: Was der Browser ausführen soll, muss man auch im Klartext anzeigen lassen können. Schlussfolgerung: Ohne Sandboxing ist eine WAF eigentlich geliefert, wobei auch die Sandbox einem DoS ausgeliefert werden kann. Im Anschluss kamen sehr ausgefallene Obfuscation-Beispiele, z. B. aus der ASCII-Tabelle eines chinesischens Zeichen die hohe Zahl zu extrahieren, zu slicen und neu zusammenzusetzen.
Auf jeden Fall also ein Vortrag, der die Hoffnung erfüllte, auch wenn die Payload-Übergabe an eine Webanwendung im beliebten Fall persistententes XSS schwierig scheint. Insbesondere geht es also darum, bösen Code durch Dritte eingeschleust zu bekommen, z. B. in Frameworks.
Sehr nett ist der Verweis auf den Hackvertor, mit dem man mit verschiedenen Methoden seine Payload obfuskieren kann.

Wir hängen nun übrigens knapp eine Stunde im Zeitplan

Projektierung der Sicherheitsprüfung von Webanwendungenen
Zu meinem eigenen Vortrag kann ich natürlich nicht sonderlich viel sagen (außer vielleicht, dass er vorgezogenwurde), daher einfach nur der Verweis auf das Whitepaper.

Pentestvorbereitung: Sitemap für Webanwendungen (Tools)
Sitemaps von komplexen Webanwendungen zu erstellen ist sehr schwierig, Achim Hoffmann hat sich des Themas angenommen, wie man am Besten die “Schuhgröße” einer Prüfung im Vorfeld bewerten kann. Es wurden noch einige Tools vorgestellt, mit denen man rasch ans Ziel kommt. Aus dem Auditorium kam der Hinweis, dass ein Mitarbeiter der Fachabteilung und ein Techniker wohl die besten Tools darstellen

Fazit
Scheh wars, die Vorabendveranstaltung war sehr nett, wir haben uns gut unterhalten und das Essen war auch lecker Die Vorträge dieses Jahr waren meist untechnisch, dennoch auch für mich interessant. Allerdings hoffe ich ehrlich gesagt für das kommende Jahr wieder auf zwei Tracks. Wir werden sehen..

/gt