Angefangen hat es damit, dass die Onlineshopseite geeks.com Anfang 2008 die Kunden informiert hat, dass Zahlungsdaten Anfang Dezember 2007 kompromittiert wurden. Dies bedeutet, dass die Möglichkeit besteht, dass unautorisierte Personen im Besitz von Namen, Geburtsdaten und Kreditkarteninfos der Kunden von geeks.com sind.

Das Spezielle daran ist, dass die Webseite von geeks.com an diesem Tag als „Hacker Safe“ eingestuft wurde – einer Dienstleistung von scanalert.com. ScanAlert prüft Webseiten ihrer Kunden täglich auf Sicherheitslücken – doch wie konnte die Webseite trotzdem gehackt werden? Offenbar war eine XSS (Cross Site Scripting) Lücke dafür verantwort-lich. ScanAlert jedoch distanziert sich von XSS Lücken – damit könne man keine Websei-te hacken:

“Joseph Pierini, director of enterprise services for the ScanAlert „Hacker Safe“ program, maintains that XSS vulnerabilities can’t be used to hack a server.” (Link)

Interessante Ansicht – noch interessanter wenn man die Analyse von XSSed.com betrachtet, welche 62 weitere „Hacker Safe“ Webseiten mit einer XSS Lücke auflistet.

Für Onlineshops welche Kreditkartenzahlungen durchführen ist die PCI Compliance Pflicht – unter diesem Label wird schliesslich das „Hacker Safe“ Label auch vertrieben. Unabhängig davon, dass die Dienstleistung von ScanAlert nicht viel kostet, der Webseitenbetreiber verlässt sich auf das Label. Hacker Safe ist Hacker Safe – auch wenn der Hack via XSS im Browser durchgeführt wird – meine Kreditkarte ist trotzdem kompromittiert. Die erkennung einer XSS Lücke ist schliesslich kein Kunststück – das „programmieren“ einer Webseite jedoch anscheinend schon – ich sage dazu nur: Rapid Application Development 😉


Mit dem Beginn der Vernetzung deer Computer fing auch die Vernetzung der Malware an. Gegen Viren und Würmer gibt es aktuell gute Gegenmassnahmen, sei es als Antivirensoftware auf dem Client oder auf dem E-Mail Gateway. In diesem Sinne wird der Angreifer gezwungen neue Wege ins Unternehmensnetz zu suchen. Dieser neue Weg geht via Web – oder genauer über den Browser des Benutzers. Die davon ausgehende Gefahr ist aktuell weit grösser als man sich vorstellt. Einerseits liegt der Grund darin, dass dies meinst unbemerkt passiert und andererseits klare Symptome – wie beispielsweise ein langsamer Browser – auf das Betriebsystem oder die Browsersoftware abgeschoben werden.

Der Angriff findet dabei direkt über den Browser statt – in den meisten Fällen via JavaScript. Ein reduziertes Surfen durch den Benutzer auf bekannten Seiten nützt nichts was die Sicherheit anbelangt – via XSS Lücke kann auch die „sichere“ bekannte Webseite zur Gefahr werden lassen. Ein solcher Angriff kann relativ viel auf dem PC anrichten. Mittels JavaScript Feng Shui von Alex Sotirov kann schön der Heap des Browsers zeschossen werden und beispielsweise ein Keylogger installiert werden. Ein Ausschalten von JavaScript oder die Nutzung von NoScript vereitelt die meinsten Angriffe, deaktiviert jedoch die schönen Web 2.0 Anwendungen.

Der differenzierte Ansatz zum Vollständigen Deaktivieren des Internets ( 😉 ) ist die Nutzung eines Malware Scanning Web Proxies. Eine URL Blocklist reicht in diesem Falle schon lange nicht mehr, da die WebMalware irgendwo im Web gelagert werden kann – Rootserver mit guter Internetanbindung sind dazu prädestiniert. Inwiefern jedoch ein Malware Proxy (oder korrekterweise Anti-Malwareproxy) alle oder ein Subset der Attacken verhindern kann wird sich in Zukunft zeigen.


Dan Egerstad scheint es geschafft zu haben: Den Hack des Jahres! Schauen wir uns einmal im Detail an, was er gemacht hat.

Er hat auf gehosteten Server (sehr wahrscheinlich Dedicated Servers) TOR installiert. TOR wird benutzt um im Internet anonym zu surfen – d.h. die Requests des Webbrowsers werden mehr oder weniger zufällig über unbekannte TOR Proxies geschleust. Somit kann der Webseitenbetreiber nicht mehr auf den Surfer zurückschliessen.

Was mir nun neu ist, ist die Tatsache, das TOR ursprünglich von der U.S. Navy genutzt wurde. Dies hat zur Folge, dass das TOR-Netzwerk auch nach seiner GPLisierung immernoch durch staatliche Organisationen genutzt werden kann und offenbar auch genutzt wird.

Nun scheinen sich die TOR-Surfer sehr sicher zu sein was das Netzwerk anbelangt und lesen ihre E-Mails via unverschlüsselter Verbindung. Hätten diese https genutzt hätte auch Dans TOR-Endpunkt die Verbindung nicht nicht mitlesen können.

Ich kann es nicht genug erwähnen: Nach dem GMail Cookie Disaster und nach diesem Hack nochmal in aller Deutlichkeit:

Benutzt https im Internet wenn Passwörter übertragen werden! IMMER!

Wenn es bei einem Provider nicht geht, wechselt den Provider.


Google indexiert alles – ausnahmslos. Neustens bietet Google sogar ein mobiles Rechenzentrum an um 120 Terabyte Daten zu transportieren – mit der Bedingung dass Google eine Kopie der Daten behalten darf.

Da Google soviel indexiert werden natürlich ebenfalls Sachen indexiert, welche grundsätzlich nicht zum Indexieren gedacht waren. Beispielsweise kann mit dem Suchstring „filetype:ica“ Citrix Connectionfiles gefunden werden. Anhand diesen Links kann man sich direkt mit dem Citrix Server verbinden.

Allerdings hilft Google auch bei der Suche nach Phishing Sites. Eine Suche mit „inurl:paypal“ ergibt eine Liste mit Webseiten mit dem Wort paypal in der URL – durchaus mit einigen darunter welche phishy aussehen. Die meisten dieser Seiten sind jedoch nicht im Root (/) installiert sondern tiefer im Baum (Bsp: /eg/webscr.exe). Ruft man jedoch die Rootseite auf bekommt man einen „209 Host Locked“ Fehler. Basierend auf dieser Information kann die Suche nach Phishingsites auf diesen Suchstring reduziert werden: „inurl:paypal intitle:209“.

Wer nun den ersten Teil versucht hat soll doch auch den zweiten Teil machen und die Seiten gleich melden: http://www.us-cert.gov/nav/report_phishing.html