Skip to content

XSRF Schwachstelle auf dem ePetitions Server

Der ePetitions-Server des Deutschen Bundestages hat leider ein Sicherheitsloch. Das Eintragen und Austragen aus den Petitionslisten erfolgt durch einen einfachen HTTP GET Request ohne Sicherung durch ein Shared Secret (nonce). Deswegen ist es sehr trivial auf einer beliebigen Web Seite Bilder oder iFrames einzubauen die bei einem Besuch unbemerkt für den Besucher eine Anfrage an den Petitionsserver absenden. War der Besucher auf dem Petitionsserver angemeldet so wird die Aktion ohne weitere Nachfrage durchgeführt. Dies geht natürlich nur, wenn der Benutzer auf dem Server bereits angemeldet ist. Aber eine Gültige Login Session beim ePetitionsserver hat jeder der dort schon mal mitdiskutiert hat (das Session cookie läuft solange der Browser nicht geschlossen wird). Auf folgender Seite habe ich einen Proof of Concept erstellt. Besucher dieser Seite (nach der Vorschaltseite) werden in der Liste gegen das Gendiagnose-Gesetz eintragen. Sie müssen sich dort selbst wieder austragen. Wenn Sie die Seite besuchen wollen, so kopieren Sie den Link in die Browser Adresszeile. http://eckenfels.net/w/CompXSRFPetition Das BSI hat übrigend eine Studie zum Web2.0 veröffentlicht in der XSRF als eines der größten Sicherheitsprobleme genannt wird. Man kann zwar nicht behaupten dass der E-Petitionsserver sehr Web2.0 ist, aber immerhin hätte der Bund Ressourcen zur Verfügung gehabt dieses Sicherheitsloch selbst zu entdecken. Übrigens glaube ich nicht, dass die Schwäche in der eingesetzten Foren-Software SMF ist (da diese es an anderer Stelle wie Logout oder Profil richtig macht) sondern eher an der Erweiterung für die Abstimmungen. Über die Firma hinter dem Projekt findet sich einiges im Artikel von Alvar Freude. Vielen Dank an Matthias Bauer für den Hinweis auf dieses Problem.

OAuth Problem

We’d like to publicly show our appreciation for Twitter’s role in helping to minimize premature publicity of this threat, even at its own expense, taking the heat as if it was their own issue in order to allow other companies to address this threat.
Die Abschaltung der OAuth Authentifizierung bei Twitter Services führte zu einem Pressesturm. Das ReadWrite Web Blog hat jetzt eine (etwas aufgeblasene) Zusammenfassung der Ereignisse veröffentlicht. Persönlich finde ich - jetzt nachdem die Fakten klar sind - die ganzen Reaktionen etwas übertrieben. Immerhin ist es weiterhin so, dass Millionen von Anwender OAuth nicht nutzen (können) und Ihre Web 2.0 Passwörter weiterhin in dutzenden Third-Party Anwendungen eingeben um deren Dienste zu nutzen. Ein Session Fixation Angriff, wie er bei OAuth möglich ist hat dabei doch wesentlich weniger weitreichende Konsequenzen. Entsprechend ist auch das Ergebnis, dass alle OAuth APIs wieder aktiviert wurden, und das Protokoll nur in einem langfristigen Community Prozess noch etwas verbessert werden kann. Interessanterweise scheint die Flickr API Authentication dieses Problem z.B. nicht zu haben. Zum einen wird nach einem Authorisierungsversuch der Benutzer auf eine festgelegte WebSeite des Anbieters verwiesen, und zum anderen kann der Authorisierungstoken (frob) nur vom Dienstanbieter mit einem Signierten Request in einen Auth Token umgewandelt werden. Ich hab mir mal ne Mühe gemacht eine kleine Google Appengine Anwendung zu erstellen die diesen Vorgang vorführt.

Datenschutz bei Bahn und Telekom

Gerade fand auf dem 25C3 (Der jährliche Hauskongress des CCC, 2008 unter dem Motto "Nothing to hide") noch ein Vortrag darüber statt, dass die in Deutschland existierenden Grundsätze zum Datenschutz (insbesondere die einstmals fortschrittlichen Grundsätze zur Informellen Selbstbestimmung) eventuell nicht mehr der Bedrohungslage gerecht werden, und eher kontraproduktiv sind: The Trust Situation Why the idea of data protection slowly turns out to be defective Sandro Gaycken Eine These des Vortrags ist es, dass aktuelle in den Medien breit getretene Datenpannen auch positiv auf das Risikobewusstsein der Bevölkerung wirken. Entsprechend war auch der Datenpannen 2008 Vortrag auf dem 25C3 eine gute Zusammenfassung des Jahres. Und weil ich gerade von Pannen rede: der Spitzel-Skandal bei der DB ist ja grade die prominenteste Panne, aber als politischen Selbstmord muss man wohl die letzte Aktion der DB werten: sie haben Netzpolitik.org abgemahnt wegen Veröffentlichung eines Gesprächsprotokolles (das etwas Licht in die Machenschaften der DB bringt, zum Beispiel die Tatsache dass die Bahn ihre Top Manager und deren Ehepartner hat durchleuchten lassen. Delikaterweise wurden die Ehepartner über die Verkäufe der (verbilligten) Fahrkarten für Angehörige ermittelt). Alle Daten die erhoben werden, werden auch missbraucht... Genauso wie die Telekom hat auch die Bahn keinerlei Skrupel auf Bewegungsdaten Ihres Geschäftsbetriebes zuzugreifen (und diese auch noch an Ermittlungsfirmen weiterleiten). Dass die Ermittlungsfirma Network Deutschland GmbH unter anderem Telefonate und Kontenbewegungen durchleuchtet hat legt nahe, dass sie generell an solchen Listen Interesse haben. Update: wie zu erwarten zieht das Thema weite Kreise, bei der TAZ findet sich diese amüsante Zusammenfassung:
Die Bahn legt Wert auf Transparenz. Deshalb stochert sie auch gerne mal in den Privatdaten ihrer Mitarbeiter herum. Wenn es aber um die eigenen Angelegenheiten der Bahn AG geht, sieht es ganz anders aus. Informationen über den jüngsten Datenschutzskandal versucht die Bahn mit juristischen Mitteln zu unterdrücken. Es handele sich hierbei um Geschäftsgeheimnisse, schreiben ihre Anwälte.

Security Checklisten (Einfacher durch SCAP)

Das Hardening von Rechnern besteht typischerweise aus einer Abarbeitung von Checklisten. Ebenso gibt es jede Menge verbindlicher Standards und Security Profile, die eine gewisse Konfiguration von Rechnern voraussetzen. In der Vergangenheit waren diese Arbeiten immer mit handgestrickten Scripten oder kommerziellen Produkten verbunden. Dank der Amerikanischen Cyber Terror Angst werden aber durch diverse Behörden und Regierungsnahe Stellen immer wieder sehr nützliche Innovationen vorangetrieben. Einiges läuft dort inzwischen unter dem Information Security Automation Program: OVAL ist eine XML Sprache zur Beschreibung von Platform Checks. Mit einem OVAL Interpreter können diese ausgeführt werden, und die entsprechenden Reports helfen somit bei der Systemadministration. Neben der OVAL Language gibt es auch das OVAL Repository das eine Reihe von Prüfungen (Vulnerabilities, Patches, Inventory) frei anbietet. Neben der Referenzimplementierung des OVAL Interpreters werden auch noch weitere Open Source Projekte entsprechende Tools anbieten. So zum Beispiel OpenVAS 2.0 Beta. Neben OVAL das auf die Systemtechnische Seite von Security Empfehlungen eingeht gibt es noch das XCCDF (The Extensible Configuration Checklist Description) Format. Schwerpunkt hier ist es die ganzen Punkte einer Checkliste formalisiert darzustellen. Unterstützt werden dabei sowohl Profile (Subsets von Controls) als auch die Integration von automatisierten Checks (z.B. mittels OVAL). In dem Umfeld gibt es eine ganze Reihe Protokollen:
  • CVE - Die öffentliche Software Schwachstellen Datenbank
  • CCE - Configuration Items
  • CPE - Platformen
  • CME - Malware
  • CWE - Software Weakness und
  • CAPEC - Angriffsmuster
Besonders CVE ist dabei sehr weit verbreitet, da es die Unzahl vor Hersteller und Distributoren spezifische Codes vereinheitlicht hat. Diese Notwendigkeit ist insbesondere im Linux Umfeld entstanden, da jeder Distribution ihr eigenes Süppchen gekocht hat. Aber auch die Vereinheitlichung der anderen Dimensionen der Klassifizierung von Schwachstellen macht das Leben eines Systemadministrators oder Security Officers einfacher.

Hash Funktionen

Es gibt Neuigkeiten im Bereich Kryptographie, insbesondere im Bereich der sicheren Hash Funktionen: Halloween war Einreichungsschluss beim NIST Wettbewerb "NIST hash competition" der unter dem Namen SHA-3 einen würdigen Nachfolger für die in Verruf geratenen Hash Algorithmen SHA-1 und MD5 sucht. Es gibt noch keine offiziellen Ergebnisse, aber eine inoffizielle Bewertung im SHA-3 Zoo Wiki der TU-Graz. Außerdem hat NIST eine neue Revision des Secure Hash Standards (SHS) in FIPS 180-3 (PDF) veröffentlicht. Hier werden die folgenden fünf Algorithmen definiert: SHA-1, SHA-224, SHA-256, SHA-384 und SHA-512. Auf die bekanntgewordenen Angriffe gegen SHA-1 geht die FIPS Publikation allerdings nicht ein, die Sicherheitsbewertungen wurden aber entfernt, damit diese in Special Publications schneller aktualisiert werden können. (Via D-kriptik Blog)

DoD über CC

In einem Report (PDF) des U.S. DoD findet man folgende - doch recht amüsante - Anmerkung:
The primary process relied upon by the DoD for evaluation of the assurance of commercial products today is the Common Criteria (CC) evaluation process. The task force believes that Common Criteria is presently inadequate to raise sufficiently the trustworthiness of software products for the DoD. This is particularly true at Evaluation Assurance Level-4 (EAL4) and below, where penetration testing is not performed. Nonetheless, Common Criteria evaluation is an international program, well established, and not easy to change.
Es ist interessant zu sehen, dass einer der Haupt-Initiatoren der Common Criteria nun erkennt, dass diese nicht sehr nützlich ist - und was noch viel interessanter ist - nicht so einfach geändert werden kann, da diese nun im Standardisierung-Morast festsitzt. Auf den Report hat übrigen's Oracle's CSO Mary Ann Davidson hingewiesen.

Zufall?

Da ich davon beim abendlichen Beercall erzählt bekam gehe ich davon aus, dass es schon alte News ist und sage dazu nichts weiter... naja außer vielleicht:
2ecki@calista:~> dpkg -l openssl
||/ Name                Version             Description
+++-===================-===================-======================================================
ii  openssl             0.9.7e-3sarge5      Secure Socket Layer (SSL) binary and related cryptogra

Gefahren des DRM

Digital Rights Management (DRM) ist eine Methode Abspiel- und Kopier Möglichkeiten von Medien einzuschränken. Inhaltsanbieter sagen sie können damit günstigere Preise machen indem die Rechte auf ein vom Kunden benötigtes Maximum eingeschränkt werden. Kunden hingegen fühlen sich dadurch insbesondere mehrfach abgezockt. So oder so hat DRM große Probleme, weil dem Kunden (dem Käufer) einiges an Rechte weggenommen wird. Das kann dann so weit gehen, dass man gekaufte Songs nicht mehr abspielen kann, weil die DRM Server nicht erreichbar sind, oder keine Geräte mehr das Verfahren unterstützen. Microsoft hat den DRM Skeptikern einst versucht mit Ihrer "Plays for Shure" Campagne zu entgegnen. Ironischer weise schaltet Microsoft diesen Dienst jetzt ab, was dazu führt dass man die gekauften Medien nicht mehr von einem Gerät zum anderen übertragen kann (sondern nur noch auf den 5 registrierten Geräten). Wieder einmal zeigt sich, dass offene Formate eine sichere Zukunftsinvestition sind. Via Kris. Update: auch im Spiegel.