Web-Sicherheit

September 28, 2011

Ein schlechter Scherz zum Thema Facebook-Datenschutz und eine echte Schwachstelle

Filed under: Allgemein — sebastiankuebeck @ 08:05
Tags: , , , ,

In den letzten Tagen bekam ich immer wieder folgende Meldung auf Facebook weitergeleitet:

Bitte tut mir einen Gefallen.
Mit dem Cursor über meinen Namen fahren, das Pulldownmenü abwarten
und über "Abonniert" fahren. Bei "Kommentare und Gefällt mir" das
Häkchen entfernen! ... Sonst macht ihr jedesmal, wenn Euch etwas
von mir gefällt, selbiges öffentlich und dem gesamten facebook
zugänglich ... Vielen Dank ! Copy and Paste, bitte, wenn Ihr nicht
wollt, dass dasselbe mit Euren Inhalten passiert.

Dabei handelte es sich um einen schlechten Scherz (Hoax), der von arglosen Facebook-Benutzern verbreitet wird (siehe auch Facebook Mythbusters 02 – Fremde Personen können eure Aktivität im Ticker sehen). In Wahrheit blockiert man mit dieser Einstellung nur alle Meldungen von der Person, die diese „Nachricht“ weitergeleitet hat.

Wer nicht will, dass Freunde von Freunden ihre Nachrichten sehen, kann das unter „Privatsphäre-Einstellungen“ im Menü „Konto“ einstellen: Unter „Funktionsweise von Verbindungen“ findet sich die Option „Wer kann Pinnwandeinträge von anderen Personen in deinem Profil sehen?“. Hier aktiviert man „Freunde“ statt der Standardeinstellung „Freunde von Freunden“ und schon wird das Anzeigen von Meldungen auf Freunde beschränkt.

Eine tatsächliche Schwachstelle hat sich bei facebook beim Hochladen von Bildern eingeschlichen (siehe Aufpassen: Facebook hat die Sichtbarkeit für neue Fotouploads geändert): Hier hat Facebook nämlich stillschweigend eine gravierende Änderung eingeführt. Macht der Anwender per Einstellung das Foto nur „Freunden“ sichtbar, heißt das nicht mehr, dass es nur Freunde zu sehen bekommen, sondern auch die markierten („getaggten“) Personen und deren Freunde. Taggt man also eine Person auf dem Foto und macht dieses Freunden zugänglich, erfahren das über den Ticker der getaggten Person sofort auch deren Freunde – und sie dürfen sich dieses Foto sogar ansehen.

Als Lösung empfiehlt Wiese, Fotos nur für individuelle Listen oder „enge Freunde“ freizugeben, denn dann funktioniert die Einschränkung tatsächlich.

Das Problem ist also nicht nur, dass die Sicherheitseinstellungen Benutzer überfordern, sie sind teilweise auch noch falsch implementiert. Die Situation ist so natürlich für facebook praktisch, denn kaum jemand wird freiwillig diese komplexen Einstellungen ändern und so kann facebook in aller Ruhe die Daten der Benutzer versilbern. Wenn sich einer beschwert, sagt man bei facebook einfach „Pech gehabt, Warum habt Ihr Eure Einstellungen nicht geändert?“.

MySQL.com infizierte Besucher mit Schadsoftware

Filed under: Allgemein — sebastiankuebeck @ 07:08
Tags: , , , , , , ,

Bereits im März wurde die Seite MySQL.com die von MySQL, – einer Tochterfirma von Oracle – betrieben wird, Opfer eins Hackerangriffs. Das ist offenbar wieder passiert, nur diesmal infizierte die Seite am Montag die Browser ihrer Besucher mit Schadsoftware. Die Schadsoftware suchte im Browser unter anderem nach verwundbaren Java-Plugins und installierte dann einen Schädling.

Um 20 Uhr hat MySQL dann offenbar reagiert und den Server bereinigt. Die Chancen stehen auch diesmal gut, dass es eine SQL-Injection-Schwachstelle war, die es dem Hacker ermöglichte, seine Schadsoftware auf dem Server von MySQL zu installieren…

September 16, 2011

Wie man den Cross-Site-Scripting-Filter von Googles Chrome umgeht

Filed under: Allgemein — sebastiankuebeck @ 15:53
Tags: , , , , , , ,

Googles aktueller Chrome Browser hat standardmäßig einen Filter gegen Cross-Site-Scripting-Angriffe eingebaut. Nick Nikiforakis zeigt auf seinem Blog, wie einfach man diese Schutzfunktion umgehen kann.

Damit man die geschilderte Angriffstechnik gleich ausprobieren kann, hat er folgendes PHP-Skripft veröffentlicht, dass die Parameter a und b in der URL entgegennimmt und ohne weitere Kodierung ausgibt:  http://securitee.org/files/chrome_xss.php.

Um zu testen, ob überhaupt eine Cross-Site-Scripting-Schwachstelle vorliegt, probieren wir erst einmal aus, ob der Überschrift-Tag in der folgenden Anfrage vom Browser ausgeführt wird (die meisten Filter reagieren lediglich auf Inhalte, die JavaScript enthalten oder nachladen. Begnügt man sich erst einmal mit einem harmlosen Tag, kann man einfach herausfinden, ob sich ein Angriff prinzipiell möglich ist):

http://securitee.org/files/chrome_xss.php?a=<h1>HTML_INJECTION<h1>&b=bar

Das funktioniert augenscheinlich ohne Probleme:

Der „naive“ Versuch, einfach einen Script-Tag einzuschleusen, funktioniert hingegen nicht:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);</script>&b=bar

Chrome entfernt den Inhalt des Script-Tags bevor er die Seite anzeigt:

Als nächstes untersuchte Nick Nikiforakis was passiert, wenn man den Script-Tag nicht abschließt:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);&b=bar

Dabei zeigte sich, dass der Browser den Script-Tag nicht entfernte sondern automatisch schloss. Da allerdings alles, was nach dem Script-Tag kommt nun im JavaScript-Context ausgeführt wird, gibt der JavaScript-Interpreter auf und führt den Code nicht aus:

Was wir nun erreichen müssen ist, dass der Browser den HTML-Code zwischen den beiden Parametern ignoriert, die wir übergeben und das funktioniert, indem wir ihn in einen JavaScript-Kommentar einschließen:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);/*&b=*/</script>

Und das funkioniert auch, wovon man sich leicht überzeugen kann…

Nick hat das Problem dem Chrome-Team gemeldet, allerdings haben die Chrome-Entwickler noch keinen Weg gefunden, solche Angriffe zu verhindern. Dabei hat Nick nur an der Oberfläche gekratzt und bei weitem nicht alle bekannten Tricks, mit denen man solche Schwachstellen ausnutzen kann, ausprobiert (das „Standardwerk“ zu diesem Thema ist übrigens das XSS Cheat Sheet auf ha.ckers.org).

Es zeigt sich also einmal mehr, dass man um das Absichern der Webanwendung selbst nicht herumkommt. Auch nicht mit noch so gut gemeinten Technologien auf Client- und Serverseite. Microsoft hat sich bei diesem Thema voriges Jahr auch die Finger verbrannt, denn eine Schwachstelle im Cross-Site-Scripting-Filter des Internet Explorer 9 führte dazu, dass Seiten, die bislang nicht verwundbar waren, durch den Filter plötzlich verwundbar wurden.

September 12, 2011

Neue Phishing-Mails haben es auf Kunden der PayLife abgesehen

Filed under: Allgemein — sebastiankuebeck @ 06:58
Tags: , , , , , ,

Nun haben es die Phisher auf die Kunden der österreichischen Kreditkartengesellschaft PayLife abgesehen. Nein, die Deutschkenntnisse der Phisher haben sich nicht verbessert (siehe den ähnlich gestalteten Phish von Mitte August). Auch ist das Formular, welches der E-Mail beiliegt nicht sonderlich ambitioniert gestaltet und beinhaltet keine Verschleierungstaktiken.

Betreff: Hinweis: Dies ist Ihre offizielle Mitteilung von PayLife Bank GmbH. 

Dies ist Ihre offizielle Mitteilung von PayLife Bank GmbH.

Wir haben pur neuen SSL-Server aktualisiert, um unseren Kunden 
für eine bessere und sichere Online-Transaktionen dienen. 
Aufgrund dieser jüngsten Aktualisierung werden Sie aufgefordert, 
Ihre Informationen an uns zu aktualisieren.

Hinweis: Dies ist verry wichtig für Ihre Kreditkarte Sicherheit.

Bitte laden Sie das beigefügte Formular und füllen Sie alle 
Schritte.

Vielen Dank für Ihr Verständnis,
Paylife Bank GmbH

Es ist also auch in diesem Fall „verry wichtig“, die Hinweise auf Sparkasse.de zu befolgen, welche natürlich auch für österreichische Kreditkarteninhaber gelten:

Geben Sie niemals Ihre PIN und TAN heraus! Auch wenn Sie von scheinbar seriöser Stelle dazu aufgefordert werden. Die Sparkassen [Visa, MasterCard, oder welcher Finanzdienstleister auch immer] werden Sie weder per E-Mail noch persönlich am Telefon auffordern, Ihre Zugangsdaten zum Online-Banking preiszugeben oder aus einer E-Mail heraus Webseiten zu öffnen, um dort Kontodaten oder Kreditkarten-Nummern einzugeben.

Bloggen auf WordPress.com.