Mitternachtshacking

Soso, die Franzosen haben es auch schon gemerkt:

„Grund sei die Tatsache, dass alle Blackberry-Daten über Server in den USA und in Großbritannien laufen. Paris fürchte, dass der US-Geheimdienst NSA, der weltweit Kommunikationswege überwacht, damit Zugriff auf geheime Regierungsdaten bekomme.“

schreibt die ARD dazu. Ok, das stimmt zwar nicht ganz, weil die Server in Kanada stehen und nicht in den USA aber so groß ist der Unterschied auch nicht.

Wer erinnert sich eigentlich noch an President Clinton? Der hat 1997 den US-Geheimdiensten ein größeres Engagement bei der Wirtschaftsspionage verordnet. Seither wissen wir im Grunde, dass Echelon nicht gegen Russland sondern gegen die großen europäischen Wirtschaftsunternehmen wie z.B. Airbus Industries und Panavia eingesetzt wird. Aber der Blackberry ist ja so ein schönes Managementspielzeug, da will keiner drauf verzichten. Und die Risiken werden einfach ausgeblendet.

Das Bundesamt für Sicherheit in der Informationstechnik ist 2005 schon zum gleichen Ergebnis gekommen. Die Studie wurde kurz in der Öffentlichkeit gezeigt und ist dann ganz schnell wieder verschwunden. Und FX hat auf dem 2005 CCC ebenfalls ein paar nette Lücken aufgezeigt.

Wie Blackberry funktioniert sieht man in diesem Artikel bei Heise. Ich finde ja, die Exchange-Anbindung gehört zu den größten Risiken. Aber wenn’s scheee macht?

Der neueste Trick der Börsenspammer ist ja nun, einen Disclaimer einzufügen in dem steht, dass der Absender selbst in diesen Aktien involviert ist. Vermutlich versucht sich da jemand auf sehr schwache Weise aus der Strafbarkeit herauszuschreiben. Anwälte irgendwo die das bestätigen können?

Jedenfalls finde ich den neuesten Spam Disclaimer schon lustig:

„Verzicht: Diese Anzeige wurde gesendet, um dich über diese Firma zu informieren. Deine eigene Forschung tun, bevor Sie kaufen. Der Absender wurde $25.000 für diese Sendung ausgeglichen.“

Nicht schlecht: 25.000 USD für ein wenig Spam verschicken! Ich glaube ich bastle mir jetzt auch ein Botnet.

Hab ich schon erwähnt, dass ich nicht gerne in Hotels der Accor-Gruppe übernachte?

Darum hier mal wieder eine Hotel-Empfehlung im Raum Münster: Hotel Wermelt. Der Landgasthof mit angeschlossenem Restaurant liegt etwa 2 km außerhalb von Greven (leider nur mit dem Auto zu erreichen). Von hier aus kommt man dafür perfekt in das Industriegebiet Münster-Nord. Einfach nur vom Hotel aus immer gerade aus fahren … da. Das war sogar meinem Navi zu einfach.

Hotel Landgasthaus Wermelt
Nordwalder Str. 160
48268 Greven
Telefon: 02571 / 9270
Telefax: 02571 / 927152

Die Zimmer sind groß und sauber, das Hotel ist ruhig gelegen, das Frühstück ist mit Rührei und Speck und was mir ja immer wichtig ist: kostenloser Internet-Zugang!

Nur die Webseite … das geht gar nicht!

Ich habe eine Nacht darüber geschlafen, was dieses Urteil wirklich aussagt.

In vielen Kommentaren liest man, dass die Richterin keine Ahnung hat (was vermutlich durchaus zutreffend sein kann) und, dass es technisch unmöglich ist den RAM nach jeder Änderung zu sichern (was auf jeden Fall zutreffend ist). In diesem Urteil geht es aber um etwas ganz anderes.

Zum Hintergrund: Die Filmindustrie, vertreten durch Columbia Pictures hat eine Torrent-Seite auf Herausgabe der IP-Adressen aller Nutzer verklagt, die einen Torrent-Tracker heruntergeladen haben. Mit Hilfe des Torrent-Trackers kann dann die eigentliche Datei gefunden und gesaugt werden. Die Torrent-Seite hat sich damit entschuldigt, dass sie keine Logfiles schreibt und daher diese Informationen nicht vorliegen würden.

Das Urteil der Richterin sagt eigentlich erst einmal nur folgendes aus: Wenn die gesuchten Informationen an irgendeiner Stelle auf dem System vorliegen, und sei es nur im RAM, dann ist der Betreiber des Systems auch verpflichtet, diese Informationen zu sichern und auch herauszurücken. Damit ist in keinster Weise gemeint, dass ständig, permanent und nach jeder Änderung der RAM gesichert werden muss, ganz im Gegenteil. Aber damit ist gemeint, wenn irgendwann irgendwo die Daten vorliegen, dann müssen sie auch protokolliert werden.

Faktisch heißt das, in den USA ist es dadurch verboten, einen öffentlichen Dienste ohne Protokollierung der Zugriffe zu betreiben. Webserver ohne Logfile? Verboten! Es könnte ja jemand wissen wollen, von welcher IP-Adresse der neueste AACS-Key gepostet worden ist. Anonymisierungsdienst? Verboten! Es könnte ja jemand den amerikanischen Präsidenten bedrohen, was nach US-Recht eine schwere Straftat ist. Unserem Innenminister Schäuble muss es da ganz feucht im Schritt werden, endlich werden die Bürger verpflichtet zu protokollieren. Und in den USA reicht ja ein billiger Subpoena, um dann an die Daten zu kommen. Oder eben ein National Security Letter vom FBI. Der zwingt einen dann gleich noch zur Geheimhaltung, wenn man alle Daten herausgerückt hat. Da braucht es dann wirklich keinen Datenschutz mehr.

… und müssen laut Urteil eines amerikanischen Gerichts zukünftig gesichert werden.

Hier das Urteil im Wortlaut:

Based upon the court’s consideration of the extensive arguments and evidence presented, the court’s assessment of the credibility of the declarants and witnesses who testified at the evidentiary hearing in this matter, and the applicable law, the court finds: (1) the data in this issue is extremely relevant and within the scope of information sought by plaintiffs‘ discovery requests; (2) the data in issue which was formerly temporarily stored in defendants‘ website’s random access memory („RAM“) constituted „electronically stored information“ and was within the possession, custody and control of defendants; (3) the data in issue which is currently routed to a third party entity under contract to defendants and received in said entity’s RAM, constitutes „electronically stored information,“ and is within defendants‘ possession, custody or control by virtue of defendants‘ ability to manipulate at will how the data in issue is routed; (4) defendants have failed to demonstrate that the preservation and production of such data is unduly burdensome, or that the other reasons the articulate justify the ongoing failure to preserve and produce such data; (5) defendants must preserve the pertinent data within their posession, custody or control and produce any such data in a manner which masks the Internet Protocol addresses („IP addresses“) of the computers used by those accessing defendants‘ website; (6) sanctions against defendants for spoliation of evidence are not appropriate in light of the lack of precedent for requiring the retention of data in RAM, the lack of a preservation request specifically directed to data present only in RAM, and the fact that defendants‘ failure to retain such data did not violate any preservation order; and (7) awarding attorney’s fees and costs are not appropriate.

Quelle

Auf dem Security Blog von ZDnet gibt es einen Artikel Windows v Linux – Days of risk in 2006, der mal wieder zumindest zur Hälfte an der Realität vorbei geht. Das ist wie mit den von Microsoft bezahlten Studien und vermutlich fragt sich der Autor Ryan Naraine, warum der Artikel jetzt gerade mit -7 bewertet wird. Oder er fragt es sich nicht und denkt da sind die üblichen Microsoft Basher am Werk.

Worum geht es? Microsoft hat unter dem Titel „Average OS Days-of-Risk“ eine Grafik veröffentlicht, die auflistet wie lange die Benutzer eines Betriebssystems im Jahr 2006 angreifbar waren, bevor ein Patch veröffentlicht wurde. Die Tabelle dazu sieht so aus:

Die Zahlen sind soweit sicher richtig. Nur, sie beruhen leider auf der falschen Datenbasis.

Die informierten Leser dieses Blogs werden sich vermutlich jetzt fragen: „Wie kommt Microsoft auf im Schnitt 28,9 Tage, wenn eEye für jede Lücke eine Patch Development Time zwischen 120 und 250 Tagen anzeigt?“ Ganz einfach, diese Tage werden bei Microsoft in der Statistik nicht mitgezählt!

Der Trick funktioniert so: Angezeigt werden die Average Days of Risk, d.h. die durchschnittliche Zahl an Tagen, die der Benutzer gefährdet war. Und das war der Benutzer nach Definition von Jeff Jones von Microsoft nicht, wenn eine Security Research Firma eine Lücke an Microsoft meldet (der Zeitpunkt an dem eEye zu zählen anfängt) sondern erst, wenn im Internet verbreitet Exploits für die Lücke auftauchen (und das passiert oft erst, nachdem der Patch veröffentlicht wurde). Open Source Programme haben natürlich den Nachteil, dass ihr Code öffentlich ist, d.h. eine behobene Lücke z.B. in Firefox kann sofort anhand des Source Codes analysiert und ein Exploit programmiert werden, noch bevor Novell oder Red Hat das Update zu den Anwendern schieben können.

Diese Bewertung geht leider an zwei Punkten an der Realität vorbei. Zum einen ist die Lücke und in der Regel auch ein Exploit bekannt, sobald der Fehler an den Hersteller gemeldet ist. Niemand kann garantieren, dass kein anderer Hacker die Lücke entdeckt oder der Forscher die Lücke versehentlich veröffentlicht. Im Grunde muss man zählen, sobald die Lücke dem Hersteller bekannt ist. Zum zweiten ist es natürlich so, dass viele Exploits im Internet erst allgemein bekannt werden, nachdem der Patch heraus ist.

Solange ein Hacker auf einem 0-day Exploit für Windows sitzt, wird er diesen natürlich nicht allgemein im Internet veröffentlichen (außer es ist ein Hacker der bekannt werden will oder besonders blöd ist). Wenn von diesem Hacker z.B. ein Rechner aus dem Honeynet Project attackiert wird, erfährt Microsoft von der Lücke und entwickelt einen Patch. Weil aber die Lücke nicht allgemein bekannt ist, zählt diese Zeitspanne bei Microsoft nicht in die Statistik. Und schon sieht man wie der beste Hersteller aus.

Eine Statistik, die statt dessen aufzeigen würde, wie lange braucht der Hersteller zur Veröffentlichung eines Patches nachdem ihm die Lücke gemeldet wurde … da wäre Microsoft ganz klar an letzter Stelle wie die Zahlen von eEye beweisen.

Fazit: Traue keiner Statistik die Du nicht selbst gefälscht hast. Ich finde es nur schade, dass die Journalisten bei ZDNet die bunten Tabellen von Microsoft so kommentar- und kritiklos veröffentlichen. Investigativer Journalismus sieht für mich anders aus.

Auf der DailyDave Mailingliste gefunden:

Nach der Veröffentlichung eines Patches dauert es in der Regel heute weniger als eine Woche bis die ersten Exploits und oft sogar direkt Viren oder Würmer verbreitet werden, die diese Sicherheitslücke ausnutzen. Wie ich das letzte mal geschaut habe, hat Symantec den Wert auf 6,9 Tage geschätzt (leider keine Quelle).

Wie einfach das geht haben die Jungs von Sabre Security gerade eben wieder vorgeführt. Der Flash-Film (Achtung, groß), zeigt die Analyse der MS07-031 Sicherheitslücke (SChannel Off-By-One Heap Corruption, gefunden von Thomas Lim von Coseinc) mittels BinDiff. Die Jungs um Halvar Flake sind gut, das ist nichts neues und wurde durch den Gewinn des deutschen IT-Sicherheitspreises eindrucksvoll bestätigt.

Der Flash-Film zeigt, wie die beiden Binaries automatisch deassembliert und verglichen werden. Unterschiedliche Code-Segmente werden gelb eingefärbt, komplett neue Code-Segmente erscheinen rot. So kann innerhalb kurzer Zeit analysiert werden, welche Veränderungen am Code vorgenommen wurden und oft lässt sich daraus bereits auf einen möglichen Exploit schließen.

Kuckt es Euch an …

Nach einem Bericht auf SecurityFocus will die NATO sich zukünftig auch darum kümmern, kritische IT-Infrastruktur abzusichern.

Ich habe ja schon ein paar mal angemeckert, dass in Europa zu wenig passiert. Aber ob ausgerechnet die NATO dafür geeignet ist … ich habe meine Zweifel. Das erinnert mich ein wenig an das Überfliegen von Demonstranten mit Kampffliegern.

“Wie Kriminelle werden die Bürger gezwungen, ihre Fingerabdrücke beim Staat abzuliefern, ohne dass die Bundesregierung jemals sinnvoll begründet hat, warum diese biometrische Vollerfassung nötig ist”, sagte der CCC-Sprecher Andy Müller-Maguhn.

Der Chaos Computer Club ruft daher alle Bürger auf, die Abnahme der Fingerabdrücke zu boykottieren. Bereits wenn sich ein kleiner Teil der Bevölkerung der erkennungsdienstlichen Behandlung verweigert, kann die Totalüberwachung noch verhindert werden.

Mehr auf der Webseite des CCC

Ich sterbe gleich vor lachen … das ist die schönste Form, Passwörter zu sammeln, die ich je gesehen habe … aber dazu gleich mehr.

Social Engineering ist bekanntlich die beste und erfolgreichste Hacking Technik die es gibt und jemals geben wird. Und wenn man so zu sensiblen Daten und Passwörtern kommt, umso besser. In der Theorie unterscheidet man drei verschiedene Begriffe:

1. Computer-based Social Engineering: Das sind alle Betrugsversuche, die Computertechnik beinhalten. Angefangen von der E-Mail vom BKA mit dem wichtigen Attachment (die unser ach so kompetenter bayrischer Innenminister Beckstein beinahe angeklickt hätte, weil er dachte es handelt sich um eine dienstliche Mail. Seine Frau hat ihn davor bewahrt, die gäbe vermutlich auch einen kompetenteren Innenminister ab) über die gängigen Phishing-Webseiten bis hin zu allen möglichen Tricks im Internet.
2. Human-based Social Engineering: Also alle Betrugsversuche, die keinen Computer benötigen. Angefangen von den Cold Call Techniken am Telefon zum Wechsel des Anbieters über die Tricks in die Disko zu kommen bis hin zum genialen Diamantendiebstahl neulich in Antwerpen.
3. Reverse Social Engineering: Die beste Technik überhaupt. Da muss ich nicht etwa den Benutzer dazu bringen, mit etwas zu geben sondern der Benutzer kommt mit einem Problem bereits zu mir und benötigt eine Lösung.

Computer-based Social Engineering ist dabei in der Regel das einfachste, man erstellt eine clever gestaltete E-Mail oder Webseite und schon ist man dabei.

So wie diese hier von Mark Burnett auf xato.net. Die Idee ist so trivial wie einfach: Ein Eingabefeld und dazu der Text:

Online Password Checker – How Common is Your Password? Just enter your password in the text box and click on the […] button.

Köstlich. Den muss ich gleich mal ausprobieren. Am besten mit unserem Root-Passwort. Da wollte ich schon lange mal wissen, wie gut das ist. Und kluger Weise schreibt er dann auch sofort dazu: „no this isn’t a way to collect your passwords“. Ich bin echt beeindruckt.

Gut, bei Mark ist das vermutlich kein Phishing-Versuch, die Suche geht wirklich zu Google. Ok, Google speichert das Passwort dann die nächsten 24 Monate. Aber die Datenkrake weiß ja sowieso schon alles, oder?