Mitternachtshacking

Seagate/Maxtor hat in Taiwan ein paar mobile 500 GB Festplatten ausgeliefert, die mit zwei Trojanern (autorun.inf und ghost.pif) infiziert waren. Ich finde die Idee ja cool, darauf bin ich nicht mal bei meinen Virenideen gekommen.

„The tainted portable hard disc uploads any information saved on the computer automatically and without the owner’s knowledge to www.nice8.org and www.we168.org, the bureau said.“

Die Taiwanesen verdächtigen jetzt die Chinesen der Spionage. Angeblich werden solche großen Platten hauptsächlich von Regierungsbehörden verwendet. Mehr in der Teipei Times.

(via Fefe)

… zumindest wenn man sich an Salesforce wendet. Da hat ein Mitarbeiter doch tatsächlich eine Kundendatenbank rausgegeben.

„Salesforce management said it has been re-educating its staff to the dangers of phishing.“

Das kursive finde ich jetzt nett. Awareness ist halt alles.

Aber meine Rede ist ja schon die ganze Zeit, man gibt keine solchen Daten extern. Egal ob es sich um ein Blog oder sonstige Daten handelt. Ich könnte wetten, auch in den Salesforce-AGB steht drin, dass die Daten eh Salesforce gehört haben und Kunden halt Pech hatten.

(von Fliers Welt kopiert, Copyrightvermerk: „Jeder private User darf meine Cartoons kopieren und weiterleiten.“ Danke)

Ein Amerikanischer Security Consultant (alles Verbrecher, alleine wer sich schon als „Security Consultant“ bezeichnet … wo ist mein Bullshit Bingo?), John Kenneth Schiefer (kennt den irgendwer?) ist mit einem Botnetz von 250.000 Rechnern erwischt worden. Er hat damit Identitäten gestohlen und Bankdaten ausgespäht.

Ich frage mich ja ab und an, wo der Nutzen dabei liegt. Bankdaten schön und gut, aber irgendwann muss man auch irgendwie das Geld cash auf die Tatze bekommen. Die vielen Phisher haben ja das gleiche Problem. PINs und TANs ausspähen scheint recht einfach zu sein. Irgendwelche Idioten zu finden, die das Geld auf ihrem Privatkonto entgegennehmen und dann mit Western Union nach Estland verschicken ist offensichtlich schwieriger. Und auf das eigene Konto überweisen lassen ist leider auch keine Lösung. Das Geld ist schneller wieder weg als man es ausgeben kann.

Und wie groß war der Gewinn? Er zahlt 19.128,35 USD zurück, die Summe die er mit Affiliate-Gebühren eingenommen hat. Ich vermute mal, ein brauchbarer Security Consultant kann das mit (halbwegs) ehrlicher Arbeit in einem Monat verdienen. Erinnert sich noch jemand an Andreas von Zitzewitz, den ehemaligen Vorstand von Infineon der sich bei einem Millionengehalt mit müden 300.000 Euro mutmaßlich hat bestechen lassen und dann zurücktreten musste? Ich denke, jeder ist käuflich oder würde für genug Geld kriminell werden. Aber dann muss die Summe auch stimmen. Ein schlappes Monatsgehalt wäre mir da zu wenig.

Mehr bei The Register.

Die Schnarchnasen beim Bund kapieren es auch nach dem Ärger mit der Elster-Software immer noch nicht, dass es auch andere Betriebssysteme außer Windows gibt. Die Online-Vergabeplattform des Bundes (lustige Webadresse evergabe-online.info, ist das vielleicht in Wirklichkeit eine Phishing-Seite?) funktioniert leider nur mit Windows, berichtet Heise.

Der Berliner Fachanwalt Michael Schinagl geht daher davon aus, „dass sämtliche Ausschreibungen des Bundes zur Zeit angreifbar sind“.

Da kann man nur hoffen, dass möglichst viele Ausschreibungen auch wirklich angegriffen werden, damit die Bundesidioten endlich kapieren, dass es außer Windows auch noch was anderes gibt.

Es gibt viele Sicherheitslücken für die keine öffentlichen Exploits verfügbar sind und scheinbar auch nicht mehr entwickelt werden. Ein Beispiel ist eine der aktuellen Sicherheitslücken in Apple Quicktime. Hier gibt es auf SecurityFocus eine Meldung „Apple QuickTime Panorama Sample Atoms Remote Heap Buffer Overflow Vulnerability“ mit der Bugtraq-ID 26342 und wenn man nach dem Exploit schauen möchte erhält man die Meldung:

„Currently we are not aware of any exploits for this issue. If you feel we are in error or if you are aware of more recent information, please mail us at: vuldb@securityfocus.com.“

Klingt gut. Die Risikobewertung sieht dann vielleicht so aus:

Das Problem mit dieser Risikobewertung ist der zeitliche Verlauf. Aufgrund der Einstufung einer Schwachstelle als „normal“ unterbleibt gerade bei Systemen in einer Produktionsanlage oft das Testen und Installieren eines Patches. Gerne auch mal für einige Jahre. Wenn dann sehr viel später ein Exploit programmiert wird, springt das Risiko von „normal“ auf „hoch“, es gibt jedoch niemanden mehr, der diese Schwachstelle und das zugehörige Exploitpotential beobachtet.

Ein sehr schönes Beispiel ist gerade auf SecurityFocus zu finden. Die Schwachstelle „Sun Solaris RWall Daemon Syslog Format String Vulnerability“ mit der BID 4639 ist schon etwas älter, genau genommen 2002 von Gobbles (kann sich eigentlich noch jemand an den Gobbles-Krieg gegen Theo de Raad und den Apache-scalp.c chunked encoding Bug Exploit erinnern?) entdeckt worden und hat lange keine größere Rolle gespielt.

Jetzt steht diese uralte Lücke plötzlich ganz weit oben mit dem Vermerk „Updated: Nov 08 2007 12:05 AM“ und auf der Exploit-Seite findet man den Hinweis:

„UPDATE: Core Security Technologies has developed a working commercial exploit for its CORE IMPACT product. This exploit is not otherwise publicly available or known to be circulating in the wild.“

Den gleichen Vermerk findet man in mehreren Einträgen, vermutlich Folge eines neuen Releases von Core Impact. Betroffen sind mindestens die BID 3681, 4639 und 1480.

Beobachtet eigentlich noch irgendwer die alten ungepatchten Lücken über die man vor vier oder fünf Jahren mal lange diskutiert hatte?

Das US-Verteidigungsministerium wurde von einem Advisory Board gewarnt, dass zukünftige automatische Waffenkontrollsysteme von Schadcode durchsetzt sein könnten, da die gesamte Software inzwischen in Indien und China entwickelt wird.

Der Artikel  ist von The Register und dort nennt das sonst „Rise of the Machine„. Diesmal komischerweise nicht. Ich rieche einen Hauch von Skynet.

Hihi, laut BBC hat eine durchgeknallte Zentralverriegelung eines Autos dazu geführt, dass auf einem Parkplatz in England alle anderen Funkschlüssel nicht mehr funktioniert haben.

„Ofcom was finally called and a survey found a small family car was intermittently sending out signals blocking other fobs in a 164ft (50 m) radius.“

Ich finde, da kann man mehr daraus machen … Irgendwelche Hardware-Hacker irgendwo? Milosch Meriac vielleicht?

Es gibt mehrere Möglichkeiten, einen Benutzer einer Webseite zu authentisieren. Die klassischen beiden Methoden sind:

• HTTP Basic/Digest Authentication
• Form-based Authentication mit Cookies

Die meisten Webseiten verwenden heute formularbasierte Authentisierung, d.h. irgendwo in der Webseite ein Eingabeformular für Login und Passwort, das an ein Programm auf dem Webserver geschickt wird der die Eingabe überprüft und bei korrekter Anmeldung ein Session-Cookie zurückgibt, das als Nachweis der erfolgreichen Anmeldung fungiert. Praktisch alle Seiten die ich kenne und auch alle Freemailer, egal ob z.B. web.de, GMX, Hotmail, etc. und alle Banken arbeiten so. Das hat mehrere Gründe:

1. Das Formular lässt sich beliebig im Design der Webseite unterbringen während das HTTP Authentication Popup durch den Browser dargestellt wird und sich nicht im Corporate Design darstellen lässt.
2. Die formularbasierte Authentisierung wird von einem serverseitigen Programm angenommen, das die Benutzer z.B. gegen eine SQL-Datenbank verifizieren lässt. Eine große Anzahl von Benutzern lässt sich so einfach verwalten.
3. Die formularbasierte Authentisierung unterstützt problemlos auch Einmalpasswörter, Token (z.B. RSA SecurID) und Zertifikate. Die HTTP Basic/Digest Authentisierung wird meistens direkt vom Webserver durchgeführt und verwendet einfache Passwort-Dateien (ja, es gibt z.B. für den Apache Module die starke Authentisierung ermöglichen aber dann wird es schnell beliebig kompliziert).
4. Das HTTP Basic/Digest Authentication Passwort wird vom Browser ohne eine Lebenszeit gespeichert während sich einem Cookie trivial eine Lebenszeit und damit eine Gültigkeitsdauer mitgeben lässt.

Wenn auf einer Webseite dann doch noch HTTP Basic/Digest Authentisierung verwendet wird ist das folglich ein Grund, einmal genauer nachzuschauen. Als Beispiel verwende ich hier eine Seite des CCC, das Paper Submission System für den 24C3 Kongress auf Pentabarf.org, viele andere Seiten leiden aber unter dem gleichen Problem.

Die Anmeldung auf der Seite nach Anlegen eines Benutzers und eines Passworts erfolgt über das Popup-Fenster des Webbrowsers: „Geben Sie Benutzernamen und Passwort für Pentabarf ein“. Das Fenster selbst wird durch den Browser erzeugt, hier wird offensichtlich HTTP Basic/Digest Authentisierung verwendet:

Firefox bietet mir hier an, das Passwort im Passwort-Manager zu speichern aber das will ich normalerweise lieber nicht haben. Nach der Anmeldung kann man dann seinen Vortrag für den 24C3 eintragen.

Ich will ja eigentlich schon seit geraumer Zeit mal was erzählen aber bisher habe ich weder ein ausreichend spannendes Thema noch genug Zeit gefunden, einen ansprechenden Vortrag vorzubereiten. Naja, vielleicht 2008 😉

Die Seite bietet in der linken Spalte einen Menüpunkt „Logout“. Das ist interessant, weil es keine triviale Methode gibt, das im Browser gespeicherte Passwort zu löschen. Mal sehen, was passiert:

Hier fangen die Probleme an. Da es keine einfache Möglichkeit gibt, den Browser das Passwort vergessen zu lassen, versucht die Seite hier einen etwas unsauberen Trick. Die einzige Möglichkeit, einen Browser das Passwort einer Domain vergessen zu lassen ist, den Browser für die gleiche Domain eine neue Login/Passwort-Kombination speichern zu lassen. Dafür richtet man üblicherweise eine spezielle Seite ein, für die z.B. die Kombination logout/<kein Passwort> gültig ist. Der Nutzer klickt auf den Logout-Link, das alte Passwort ist ungültig und wenn der Nutzer bestätigt, wird die gespeicherte Login/Passwort-Kombination im Browser überschrieben.

Leider kann man dabei ein paar Sachen falsch machen:

Wenn der Anwender oben auf „nein“ bzw. „cancel“ klickt, übernimmt der Browser die neuen Anmeldedaten nicht, das alte Login/Passwort bleibt weiterhin gültig.

Die Logout-URL verwendet „logout@cccv.pentabarf.org“, Benutzername in einer URL wird jedoch vom Internet Explorer seit dem kumulativen Sicherheitsupdate für den Internet Explorer (832894) vom 2. Februar 2004 nicht mehr unterstützt. Da gab es leider zu viele Phishing-Versuche und ahnungslose Nutzer sind reihenweise auf URLs wie www.postbank.de@xyz.hk reingefallen und haben ihre PINs und TANs eingegeben. Das Verfahren funktioniert mit dem Internet Explorer so folglich gar nicht.

Mein Firefox (2.0.0.9) ist davon auch nicht beeindruckt, er scheint sich das alte Passwort und das neue Passwort auch gleich zu merken. Jedenfalls komme ich mit der „Back“-Taste oder einem Relogin ohne Eingabe des Passworts wieder auf die Inhalte:

In meinem Firefox kann ich via Extras -> Private Daten löschen (Strg+Umschalt+Entf) alle gespeicherten Daten löschen, dann sind die Passwörter auch weg. Auf meinem Arbeitsplatzrechner ist mir das eigentlich auch egal, da kommt niemand außer mir hin. Im Internet Café muss man leider dran denken, die Passwörter niemals in den Passwort-Manager zu übernehmen und den Browser nach dem Zugriff auf so eine Seite immer schließen, damit die gespeicherten Daten verloren gehen.

Das ist jetzt sicher keine gefährliche Lücke aber mit den aufkommenden Cross Site Request Forgeries (CSRF) sollte man auf solche Probleme vermehrt achten. Ach ja, ich schätze die Schwachstelle nicht so kritisch ein, dass ich sie vorher hätte melden müssen.

Schade. Sehr schade.

(via und von Fefe)