Schädlich…

…sind laut Google sämtliche Suchergebnisse, zumindest waren sie das Heute Nachmittag.

Die Ursache…

…ist die Liste mit Bruchstücken schädlicher URLs, die Google offenbar führt, und gegen welche alle Suchergebnisse geprüft werden. Aufgrund eines `menschlichen Fehlers` hat beim heutigen Update ein einzelner Slash (`/`) seinen Weg in die Blacklist gefunden – ein leider nicht seltener Bestandteil vieler gültiger URLs, vor welchen als Folge lauthals gewarnt wurde. Vollkommen unabhängig davon, ob nun Google selbst, die Wikipedia oder eine beliebige andere Seite das Ziel war, jede Webseite `kann ihren Computer beschädigen` und jeder Besucher bekam die Google-eigene Vorschaltseite vorgesetzt, auf der ausdrücklich vor dem Besuch der betreffenden Seite gewarnt wird. Nun, generell mag ja gesunde Vorsicht im Internet angebracht sein, besonders, wenn es sich um Google handelt…

…und die Wirkung…

…war letztlich nicht nur ein leichter Image-Verlust seitens Google und verwunderte, zuweilen entsetzte Äusserungen einiger Google-User in diversen Boards. Auch die Webseite des gemeinnützigen Projekts StopBadware.org, mit dem Google kooperiert, wurde für Stunden ausser Gefecht gesetzt – der Grund dafür war ein Link auf StopBadware, der auf der zwischengeschalteten Warnseite zu finden war und weiterführende Informationen versprach. Angesichts dessen, dass es wohl einige Besucher interessiert hat, warum die Webseiten ihrer Bank oder die Wikipedia urplötzlich ihren Computer gefährden sollen, war StopBadware.org in Folge einem typischen – nur `etwas` stärkeren – Slashdot-Effekt ausgesetzt, einem Besucheraufkommen, mit dem die Betreiber wohl schwer rechnen konnten.

Generell scheint fraglich…

…in wie weit die Erkennung `böser` Seiten seitens Google überhaupt wünschenswert ist – und das nicht erst seit diesem Vorfall. Jeder sollte wissen, dass man seinen Browser und die verwendeten Plugins auf dem neusten Stand halten sollte und von bestimmten, nicht näher zu erwähnenden Browsern, die in der Vergangenheit immer wieder durch über längere Zeit offene und währenddessen auch aktiv ausgenutzte Schwachstellen aufgefallen sind, Abstand nehmen soll – nicht weniger klar ist, dass man das seltsam anmutende Binary, welches einem eine Webseite automatisch zum Download anbietet, nicht herunterladen und schon gar nicht ausführen sollte. Für viele User ist dies selbstverständlich – für alle anderen besteht eine Gefahr ähnlich derjenigen bei der Verwendung von Malwarescannern oder Desktop-Firewalls: Aus einer Implikation kann stillschweigend eine Äquivalenz angenommen werden; warnt Google, ist die Webseite vermutlich `böse` (was man auch immer darunter verstehen mag…), warnt Google allerdings nicht, bedeutet dies selbstverständlich nicht, dass man nun jedes Binary, das einem die Webseite anbietet, blind herunterladen und ausführen soll. Ausserdem besteht die Gefahr einer `Brandmarkung` von Webmastern und ihren Webseiten durch falschpositive Treffer – was das bedeutet, muss nach dem heutigen Vorfall vermutlich nicht näher erörtert werden.

1337 XOR Elite

…wobei sich dieser Artikel nicht um 13375p34k (Leetspeak) drehen soll, sondern viel eher um die 1337crew (oder neu auch 1337-crew, da wohl die SLD 1337crew unter der TLD `to` schon vergeben war, und die Befürchtung umgeht, die frühere `info`-Second-Level-Domain könnte deaktiviert werden). Hinter dieser zweifelsohne kindischen Bezeichnung verbirgt sich eine Community, die zumindest zu einem grossen Teil aus Personen mit dunklen Hüten und Skript-Kiddies besteht. Neben einigen wenigen durchaus legitimen Themen finden sich vor allem Anfragen von Skript-Kiddies, wie man $seite `hacke` (auch ich hatte vor einiger Zeit einen Fan dort), wie man $malwarebaukasten bediene oder wie man die damit erstelle Malware vor Malwarescannern verstecken könne. Zur Anonymisierung steht unter anderem eine eigene Tor-Node zur Verfügung, samt Anleitung, wie man Tor angeblich dazu bringt, statt des üblichen Circuits aus 3 Nodes nur die 1337crew-Node zu verwenden (dass dies das grundlegende Konzept von Tor – dass die Anonymität niemals auf dem Vertrauen zu einer einzigen Autorität beruhen darf – untergräbt, sollte klar sein. Ich will nicht behaupten, dass die 1337crew-Node loggt; wenn sie es aber – aus welchem Grund auch immer – täte, dann würden sämtliche Informationen anfallen, die zur De-Anonymisierung der Nutzer notwendig sind).

Von `hochwertigen Angeboten`…

Es wäre jedoch falsch zu glauben, die Community bestünde nur aus Skript-Kiddies – eine andere, wesentlich unschönere Seite sind die `hochwertigen Angebote`. Hier werden gestohlene Kreditkartennummern von Privatpersonen, Malware-Generatoren, gestohlene Accounts, Keys für diverse Spiele und ähnliches verkauft. Auch kann man das Botnetz von 13speedtest37 für DDoS-Attacken `mieten`.
Wie mittlerweile bekannt sein dürfte, habe ich für vieles Verständnis, nur nicht für solcherlei Handel. Und für die Verbreitung von Malware auch nicht – wobei es zum Glück (oder leider, das hängt ganz vom Standpunkt ab) bei Baukasten-Malware immer noch sehr populär ist, zur Übertragung der gestohlenen Daten nicht verschlüsselnde Protokolle wie FTP oder SMTP zu nutzen – und das meist nicht als Drop-Box. Wenn da rein zufällig ein Netzwerksniffer läuft…

…und dem Umgang mit Kritik

Das Botnetz des Inhabers ist freilich nicht nur da, um vermietet zu werden – nein, auch gegen die Kritiker (ob nun sachlich oder nicht, sei dahingestellt) der Crew, respektive gegen die Server, die deren Webseiten ausliefern, werden DDoS-Attacken gefahren. Opfer war erst dug-portal.com, wohl weil ein Mitglied einen abfälligen Kommentar bei newsbox.cc eingestellt hatte (in der Folge war auch newsbox.cc `temporär überlastet`). Im Verlauf des Werbethreads im G:B, der in einen Diskussionsthread ausartete, wurde erst onesworld und etwas später – komischerweise kurz nach einem Post von Mati, der einen Link zu FreiBrief.net in seiner Signatur stehen hatte – auch YourFTP (unbeteiligt; das ist aber egal, schliesslich war FreiBrief.net darauf gehostet) seltsamerweise Opfer von DDoS-Attacken – aber das war wohl nur ein seltsames Zusammentreffen unglücklicher Umstände…

DDoS Mania…

Der kritische Thread liegt nun schon einige Wochen zurück. Ob YourFTP jemals zurückkommt, steht in den Sternen – wobei man fairerweise anmerken muss, dass das nach eigenen Angaben nicht nur mit der DDoS-Attacke in Verbindung steht. onesworld ist wieder da, FreiBrief.net war einige Zeit bei CroneKorkN auf einem Homeserver gehostet, wo auch alles glatt lief – doch wenige Stunden nach dem Umzug auf einen neuen Webspace gingen die Angriffe wieder los, wobei die angeforderten URIs darauf schliessen lassen, dass ein gewisser Administrator der 1337crew wohl auf die etwas kritischen, zuweilen leicht sarkastischen Posts CroneKorkNs im Ankündigungsthread auf FreiBrief aufmerksam wurde. Seit jenem Tag ist ein ständiges auf und ab – zeitweise lassen die Attacken nach, einige Stunden später sind die Zombies wieder da – gang und gäbe.

Update: 13speedtest37 hat seine Angriffe unter der Voraussetzung, dass einige von CroneKorkNs Posts, die wohl zugegebenermassen etwas über das Ziel hinausgeschossen sind, entfernt werden, eingestellt.

Designfehler von CCF 3.0…

…wurden vor einigen von Lukas und laxity untersucht und veröffentlicht (an dieser Stelle sei angemerkt, dass keine direkte Gefahr für diejenigen besteht, die den Container zum Schutz ihrer Links eingesetzt haben. Es gibt momentan keinen öffentlichen Decoder dafür, und die Autoren des Artikels haben keine Intention, einen solchen zu veröffentlichen).

Eine Ergänzung…

meinerseits: Der Cipher ändert die Daten nicht mehr, sobald des niederwertigste Byte des Schlüssels einmal 0×00 ist. In diesem Fall findet in jedem Schritt eine Bitrotation der Schlüssels um 0 statt und die Daten werden mit 0×00 XOR-Verknüpft. Beides hat offensichtlich keine Änderung des inneren Zustandes mehr zur Folge und die Ausgabe entspricht fortan der Eingabe.
Schwach sind nun die Schlüssel, die nach wenigen Durchläufen diesen Zustand erreichen. Die triviale Lösung ist natürlich ein Schlüssel, der zu Beginn schon in dieser Form vorliegt, mit einem low-Byte von 0×00 (was im Artikel genannt wurde). Ebenfalls ungut ist aber z.B. der Schlüssel `00 ?? ?? 08`. Die erste Bitrotation (Links, um 8 Bit) wird den Schlüssel in `?? ?? 08 00` überführen, womit der Endzustand wiederum erreicht wäre. Ähnlich beim Schlüssel `?? ?? 02 01` – hier wird das das letzte Bit bei der ersten Rotation (Rechts, um 1 Bit) ans andere Ende des Keys rotiert, das letzte 0-Bit des nächsten Bytes (02) rutscht nach. In Binärdarstellung – vor der ersten Rotation:

???????? ???????? 00000010 00000001

…und danach:

1???????? ???????? ?0000001 00000000

Clickjacking – CSRF, revisited!

Seit kurzem ist eine neue Form von Cross-Site Request-Forgery (oder auch `UI Redress Attack`, da der Angriff eben keine CSRF-Attacke im klassischen Sinne darstellt) im Gespräch – das so genannte Clickjacking. Während beim klassischen CSRF versucht wird, einen Request (z.B. durch das Abschicken eines versteckten Formulars) an eine fremde Seite zu schicken, in der Hoffnung, das Opfer wäre dort z.B. per Cookie authentifiziert (was dazu führt, dass der Request in `seinem Namen` ausgeführt wird), ist der Weg beim Clickjacking ein anderer. Hier wird die Seite, auf der man das Opfer bestimmte Aktionen vornehmen lassen will, in einem (unsichtbaren) IFRAME geladen. Nun wird versucht, das Opfer auf bestimmte Bereiche klicken zu lassen (die Bereiche, wo sich – rein zufällig – die Buttons und Links im unsichtbaren IFRAME befinden).

Vom Klickdieb…

Bis die Technik von Robert Hansen und Jeremiah Grossman näher untersucht wurde, wurde sie vor allem mit Manipulation von Umfragen in Verbindung gebracht. Die Analyse brachte jedoch zu Tage, dass solche Angriffe weitaus gefährlicher sind, als bisher angenommen – Scheinbar sind die Informationen darüber so brisant, dass Adobe die Forscher bat, den angekündigten Vortrag OWASP-Konferenz zurückzuziehen – was sie am Ende auch taten.

…zum Spion

Nun hat aber Guy Aharonovsky ein Proof-of-Concept einer solchen Attacke veröffentlicht. Seine Demo-Seite simuliert ein JavaScript-basiertes Klickspiel (bei dem es – angeblich – darum geht, möglichst viele Buttons in möglichst kurzer Zeit anzuklicken). Im Hintergrund wird die Seite
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager06.html
geladen – das Privacy-Tab des Flash-Einstellungsmanagers. Durch Mischung von wirklich sinnlosen `Spielklicks` und Klicks, die im unterliegenden IFRAME mit der Flash-Einstellungsseite Aktionen auslösen, wird schlussendlich erreicht, dass der (in diesem Fall hoffentlich nicht ahnungslose) Benutzer für die Domain in den Webcam- und Mikrofonenstellugen das `immer zulassen`-Flag setzt. Die im ursprünglichen Proof-of-Concept gezeigte Schwachstelle wurde durch Macromedia soweit behoben, als dass das Einbinden der obigen Seite in einen IFRAME durch einen JavaScript-Hack verhindert wird. Dies hindert einen Angreifer jedoch nicht daran, direkt die Flash-Datei
http://www.macromedia.com/support/flashplayer/sys/settingsmanager.swf?defaultTab=privacy
in den IFRAME zu laden. Ein entsprechend gepatchtes PoC findet sich hier.

Und nun?

Es dürfte nun klar sein, dass die Gefahren, die von einem Benutzer ausgehen, der gutgläubig da klickt, wo es ihm eine bestimmte Webseite vorgibt, nicht zu unterschätzen sind. Wie kann man sich schützen? Schutz verspricht die Firefox-Erweiterung Noscript seit Version 1.8.2 – aus dem Changelog:

New „ClearClick“ protection, specifically addressing Clickjacking, Clickjacket and other UI-redressing vulnerabilities: UI interaction with embedded objects is disabled if they’re obstructed or not clearly visible (thanks Sirdarckcat, RSnake, Michal Zalewski and Matt Mastracci for inspiration and discussion)

In den folgenden Versionen wurde der `ClearClick` genannte Algorithmus weiter verbessert.
Eine weitere Lösung bestünde natürlich darin, sich zu überlegen, welche Webseiten man besuchen will und welche nicht – und darin, JavaScript, Flash und ähnliche Spielereien nur dort zu aktivieren, wo man sie auch braucht…

Freie Software und ein erfreuliches Beispiel…

…dafür, wie schnell man sich um Fehler und mögliche Sicherheitsprobleme kümmert, stellt der Mac OS X-Multi-Protokoll-Messenger Adium dar. Vor kurzem fiel mir beim Löschen eines Kontakts von der Kontaktliste auf, dass der Screen-Name des Kontakts im anschliessenden Bestätigungsdialog als Format-String interpretiert wird – mit allen unguten Folgen, die das hat.

Ich meldete dies gleich in #adium-devl, und war positiv überrascht, wie schnell man sich des Problems annahm.

Wed, 07 Oct 2008
[22:02:44] _Kugelfisch_
Hi folk. I just discovered a possible security problem – when deleting an user from my contact list, its name seems to get parsed as a format string in a *printf()-family call. This can cause Adium to crash and possibly allows the execution of arbitrary code. I’m using Adium 1.3.1 with a localized (german) interface.
[22:05:37] hal2k
_kugelfisch_: do you have the file where that happens?
(the name of it)
or did you just have issues with a name that contains a %
[22:06:25] _Kugelfisch_
Just rename any Buddy to `%x%x` and have a look at the confirmation dialog box when trying to remove him from your contact list.
[22:07:25] hal2k
ok, I’ll look into it
[--SNIP--]
[22:16:56] CIA-17
am * r25322 /trunk/Source/AIContactListEditorPlugin.m:
Fixed an issue where printf-style escapes caused troubles in an alert when deleting the contact. Reported by _Kugelfisch_ in #adium-devl.
http://trac.adiumx.com/changeset/25322
[22:17:02] hal2k
_kugelfisch_: there you go
thanks for the report

Fazit: Nach kaum 15 Minuten war der Fehler im Subversion-Trunk des Projekts behoben, mit der nächsten Version wird das auch für die User der Fall sein. Bis dahin lässt sich das Problem umgehen, indem man keine Kontakte, deren Screennamen Format-String-Tokens enthalten, löscht – oder diese vorher umbenennt.

Um einen ähnlichen, aber weitaus gefährlicheren Fehler in ihrem proprietären Client zu beheben, hat ICQ Inc. im Frühjahr knapp 2 Monate gebraucht. Und das, obwohl die Ausnutzungsmöglichkeiten bekannt und die Schwachstelle aktiv ausgenutzt wurde – wenn auch nur, um den Client abstürzen zu lassen.

Update, 10.10.08: Die soeben veröffentlichte Version 1.3.2 behebt das Problem.

`Im Löschrausch`…

…ist wohl eine passende Bezeichnung für das gegenwärtige Verhalten von RapidShare.com. Nachdem die Tatsache, dass man fremde Unternehmen Dateien direkt löschen liess, schon Wirkung zeigte, wurde nun auch RapidShare-eigener Content – genauer gesagt: der RapidGames-Mirror von `Frets on Fire` – gelöscht.

`Diese Datei darf nicht verteilt werden.` – warum sie dann auf RapidGames verlinkt ist, ist genauso fraglich wie die Auffassung, dass ein GPL-lizenziertes Spiel nicht verteilt werden dürfe…

Von `ProMedia` und einem `Versehen`…

…spricht man, wenn ein etwas fülliger Chefermittler der ProMedia GmbH freie, Creative-Commons-lizenzierte Musik von RapidShare löscht. Ein knappes Duzend Tage ist’s her, als ich mir ein solches Szenario rein theoretisch konstruiert habe, als aufgrund einer Computer-Bild-Reportage weithin bekannt wurde, dass ProMedia-Mitarbeiter Dateien bei RS.com direkt löschen können. Nun ist der GAU tatsächlich eingetreten, das Album «Das Kreft» des Netlabels Zellophon, das CC-lizenziert ist und von den Urhebern selbst bei RS.com eingestellt wurde, «[...] wurde im auftrag der proMedia GmbH (luengen@antipiracy.de) gelöscht. Um die genaue Begründung zu erfahren bitten wir sie diese zu Kontaktieren.», wie RapidShare sagt. Eine Nachfrage bei der ProMedia GmbH brachte nebst einer `Entschuldigung` die Ursache zutage – der «[...] Link wurde auf dem Gulli-Board mit vielen anderen urheberrechtlich geschützten Dateien (NOFX-Alben) gefunden und ist aus versehen mitgelöscht worden.» – wir hoffen doch alle, dass sich solcherlei Vorfälle nicht wiederholen, ansonsten könnten gewisse Personen auf unangenehme Gedanken kommen, etwa, dass sich die Mainstream-Labels von den Netlabels ins Abseits gerängt fühlen…

ICQ ist 1337?

Viele, die sich 1337 fühlen, nutzen ICQ – und versuchen, eine möglichst kurze – meist sechsstellige – Nummer zu ergattern. ICQ, das proprietäre Chatsystem, wo sich die Betreiber die Freiheit nehmen, die übermittelten Informationen anderweitig zu nutzen.

Als wären dies nicht Gründe genug, ICQ links liegen zu lassen, kommen noch die kürzlich entdeckten und bisher ungepatchten Sicherheitslücken im offiziellen ICQ6-Client erschwerend hinzu. Zum einen besteht die Möglichkeit, über den Titel der sogenannten `tZers` aufgrund mangelnder Prüfung beliebigen HTML-Code einzuschleusen. Da ICQ6 zum Rendern der Chats unvorsichtigerweise auf eine bereits installierte Komponente des Internet Explorers zurückgreift, ist es auch möglich, dadurch eine der nicht gerade knapp bemessenen Sicherheitslücken im IE auszunutzen, um die Kontrolle über das System des angegriffenen zu übernehmen oder seinen ICQ-Client abstürzen zu lassen. Die zweite Sicherheitslücke hat vermutlich noch schlimmere Folgen – ICQ6 scheint sämtliche empfangenen Nachrichten als erstes Argument in einem printf()-ähnlichen Funktionsaufruf zu verwenden, wodurch eine Format-String-Vulnerability entsteht. Diese kann ausgenutzt werden, um ICQ6 abstürzen zu lassen, zum Beispiel indem durch mehrere `%s`- oder `%n`-Tokens ein Zugriff auf einen nicht gemappten Speicherbereich provoziert oder durch Grössenpräfixe der Tokens (`%042000000s`) riesige Ausgaben erzeugt werden. Auch der schreibende Zugriff auf gewisse Speicherbereiche im Adressraum des Programms ist möglich, was die Ausführung von beliebigem Code erlaubt. Auch Secunia und Heise haben das Problem mittlerweile entdeckt.

Ist ICQ nun wirklich so 1337 ?

Update, 7.3.08: Nachrichten der Form /%[\.0-9]+[a-zA-Z]+/ werden nun vom ICQ-Server verworfen. Dass dies die Sicherheitslücke nicht fixt, dürfte jedem klar sein, und jeder, der sich auch nur ein wenig mit Format-Strings auseinandersetzt, wird Wege finden, seine Nachrichten am Filter vorbei ans Ziel zu bringen…

Update 2.0, 9.3.08: Der Filter wurde angepasst, nun wird scheinbar alles, was auf /%\S+/ zutrifft, verworfen. Die Sicherheitslücke an sich ist immer noch nicht gefixt, und auch diese Filterregel lässt sich mit dem nötigen Wissen problemlos umgehen…

Update 3.0, 17.4.08: Die Format-String-Schwachstelle wurde mit ICQ6 Build 6059 wie es scheint behoben.

Achtung, Linux-Server-Betreiber…

…ihr solltet vorsichtig sein, wem ihr eine Shell auf eurem Server gebt. Und in nächster Zeit noch besser auf die Sicherheit eurer PHP-Skripte achten. Denn ein Local-root-Exploit gegen Kernelversionen bis 2.6.24.1 wurde kürzlich veröffentlicht. Somit kann jeder, der beispielsweise über eine Remote File Inclusion Code – wenn auch als eingeschränkter User – auf eurem Server zur Ausführung bringen kann, volle root-Rechte erlangen.

YouTube – Service Unavailable!

Mindestens einer der Server des Videoportals YouTube hat momentan Probleme – surft man www.youtube.com an, bekommt man bloss `HTTP/1.1 Service Unavailable` (in schönem HTML verpackt) als Antwort zurück.

Auch der HTTP-Statuscode der Antwort ist 503 – was ebenfalls `service unavailable` bedeutet.

ozean-osx:~ iFish$ telnet www.youtube.com 80
Trying 208.65.153.238...
Connected to www.youtube.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 503 Service Unavailable
Server: NS_6.1
Content-Length:62
Connection: close

<strong>Http/1.1 Service Unavailable</strong>
Connection closed by foreign host.

Über den Ursprung der Probleme ist momentan noch nichts bekannt – auch nicht, wann der Service wieder verfügbar sein wird.

Update: YouTube ist bereits wieder verfügbar. Wesentlich länger als eine Stunde war der Ausfall nicht, kaum genügend Zeit, um davon zu erfahren, Screenshots zu machen und einen Blog-Post zu schreiben…