Einträge für datenritter

Die Firma HVFX bietet Teslaspulen in einem leitfähigen Rad und in einer leitfähigen (durchsichtigen) Kugel, um z.B. Verkaufsstände spektakulär zu bewerben ohne die Passanten wegzubruzzeln.

Stuntshows, bei denen Leute mit leitfähiger Kleidung Blitze fangen, gibt es auch. Die Rechtsform der Firma ist die Limited, "overseas agents" gibt es nur in Pakistan, Spanien, der Türkei und den Vereinigten Arabischen Emiraten. Ich frage mich, ob das Zufall ist, oder ob da gewisse Risiken abgefangen werden. Und was die wohl gegen Funkstörungen machen?

Die Seite zeigt, dass man mit Teslaspulen durchaus Geld verdienen kann, und deren Geräte sehen recht professionell aus.

Anstatt wie andere Unternehmen Blitzschlag für Experimente mit Geräten oder Filmaufnahmen zu simulieren, macht HVFX einfach echte, wie man auf der Stuntseite sehen kann. Angucken!

Ein technischer Direktor (CTO) eines größeren Internetdienstanbieters plaudert aus dem Nähkästchen:

Einmal hatte ich so einen richtig scharfen Hund von Mitarbeiter der Staatsanwaltschaft, der sagte, ich solle mit dem Hinhaltekram aufhören und ob ich wisse, welche Folgen es für unsere Firma haben könnte, wenn ich trotz richterlicher Anweisung nicht kooperiere. (Das passiert selten, die meisten Polizisten/Richter etc. sind durchaus nachdenklich und wissen, dass sie keine Ahnung vom Thema haben.) Ich solle nun bitte die verlangten Daten durchfaxen und ihm die Ausflüchte und „ja aber“ ersparen, es entstünde der Eindruck, ich wolle Kriminelle decken.

Gut.
Habe ich dann gemacht.

Nach ca. 150 Faxseiten rief er an und fragte, wieviel noch kommen. Musste ich ihm antworten: Noch etwa 420.000 Seiten (...).

Bei Seite 200 ist sein Fax nicht mehr rangegangen. Ich habe als pflichtbewusster Bürger natürlich noch vier Tage lang versucht, die Sachen durchzufaxen (...).

Quelle: http://www.spreeblick.com/2007/04/27/sag-mal-bka/#comment-411022

Spreeblick hat dann mal nachgehakt, das entstandene Interview mit dem anonymen CTO ist hier zu lesen: Spreeblick: Ertrunken in der Datenflut - “Man kann mit solchen Maßnahmen nichts verhindern”. Darin geht es munter weiter:

Viele Polizisten verstehen zum Beispiel nicht, dass man gar nicht sicher sagen kann, wie lange sich jemand eine Webseite angesehen hat, dass die Tatsache, dass ein Mailserver ein Mail empfangen hat, noch nicht heißt, dass sie jemandem zugestellt wurde oder dass sie jemand gelesen hat (um nur mal 2 häufige Probleme zu nennen), vielfach wird nicht einmal erfasst, wer überhaupt zu fragen ist.

(...)

Wir hatten auch schon Fälle, wo Leute bei uns im Büro standen und mal eine Festplatte eines Kundenrechners beschlagnahmen wollten, nur um dann festzustellen, dass es bei einem Shared Webhosting „die Festplatte des Kunden“ nicht gibt, sondern die Daten überall verstreut rumliegen, die Datenspeicherinstallation außerdem irgendwo ganz anders in Deutschland steht UND man einen Lastwagen brauchen würde, um das Ganze zu transportieren.

(...)

Es gibt bei keiner mir bekannten Polizeistelle Rechner, die in der Lage wären, ein 4 GB Logfile einzulesen und nach Einträgen zu durchsuchen, oder Software, die Apache-Logfiles auswerten kann oder Sniffer, die IP-Mitschnitte interpretieren und aufbereiten könnten.

Hat irgendjemand Grund, an dieser Darstellung zu zweifeln? Und: Ist es gut oder schlecht, wenn die Planlosen einen schlechten Plan haben, oder die mit dem schlechten Plan planlos sind, oder hat die Planlosigkeit schlechte Pläne verhindert? Würden "SIE" etwas planen, wenn sie einen Plan hätten? Wenn ich einen Plan male, findet ein Strafverfolger dann seinen Weg, oder ist das Planwirtschaft?

• Things to Do With a Photoflash Unit — Man kann aus Einwegkameras einen kleinen(?) Taser, oder eher einen Elektroschocker bauen. Würde ich aber lassen, die Wikipedia-Artikel sind hoffentlich deutlich genug.

• Hier gibt's das ganze mit Bildern: Stun Gun / Portable HV Generator. Angeblich ungefährlich, aber schmerzhaft.

• Alternativ nimmt man das Ding als Wikipedia: RFID-Zapper.

• Fun With a Microwave Oven — Eine Antenne in der Mikrowelle. (Aber bitte nicht in solchen, in denen man noch Essen zubereiten will.)

• Man muss nicht die eigene Mikrowelle opfern, um das mit der CD endlich mal auszuprobieren. Tolle Fotos gibt es schon: The Microwaved CD. Ich bin ziemlich sicher, dass die Daten weg sind.

Die Angriffsmöglichkeit durch alte Zertifikate hat sich bestätigt. Laut einem Artikel bei heise Security bestehen zudem die Möglichkeit, dass die Systeme, die mit schwachen Schlüsseln ausgestattet waren, bereits früher angegriffen bzw. belauscht wurden.

Es ist schon übel, dass der heise-Newsticker vorgestern nur am Rande in WWW, der "Wochenschau von Hal Faber" über die bestehende Angriffsmöglichkeit durch das OpenSSL-Debakel berichtete:

Es gibt Leute, die viel davon verstehen und die erklären können, wie selbst unsere Selbsteintreibungs-Software ELSTER davon betroffen ist, dass Revocation Lists für Zertifikate nicht funktionieren: Skalierender Schlüsselrückruf ist ein ungelöstes Problem.

Die von mir hervorgehobene Formulierung suggeriert, dass das schon das Ende der Gefahrenstange sei. Das ist nicht der Fall, es kann auch Online-Banking-Webseiten oder andere sensible Bereiche treffen. Nach einem Hinweis antwortete mir Jürgen Kuri, er werde die Leute bei heise Security noch einmal darauf hinweisen.

Heute erschien dann die Meldung "Tausende deutsche Server laden zum Einbruch ein". Dort wird berichtet, dass viele ihre SSH-Schlüssel noch nicht ausgetauscht haben, Provider ihre Kunden nicht benachrichtigen:

Kurze Stichproben von heise Security enthüllten Erschreckendes: In den Netzen von Root-Server-Providern verwendeten von 1938 erreichbaren SSH-Servern 114 bekanntermaßen schwache Schlüssel – das sind immerhin rund fünf Prozent.

Das ist schlimm, aber wartet, es kommt schlimmer.

Man hat sich bei heise Security auch die Mühe gemacht, einen interessanten Artikel über die verschiedenen Gefahren zu schreiben — leider steht zu befürchten, dass den schon aufgrund der Länge kaum jemand liest. Das ist schade, denn auf Seite drei steht der erschreckende Sachverhalt, vor dem ich warnte, in einem Absatz zusammengefasst:

Insbesondere für Phishing und Pharming sind Originalzertifikate eines Webservers zusammen mit den passenden privaten Schlüsseln Gold wert. Gelänge es einem Phisher, seine Opfer beispielsweise mittels des sogenannten Pharmings seine Opfern per DNS-Spoofing oder untergeschobene Hosts-Einträge auf seine eigene Seite umzudirigieren, so könnte der Anwender den Angriff nicht mehr erkennen. Sein Browser würde anzeigen, dass das Sicherheitszertifikat des Servers zur eingegebenen URI passt und dass es von einer vertrauenswürdigen CA ausgestellt wurde.

Und tatsächlich: Alexander Klink berichtet auf der Mailingliste full disclosure, er habe eine Bank ausgemacht, deren altes Zertifikat schwach war. Das Zertifikat ist noch etwa 3 Jahre gültig - so lange sind Man-In-The-Middle-Attacken auf diese Bank möglich.

Als wäre das nicht genug, erklärt der Artikel auch noch, dass aufgezeichnete verschlüsselte Verbindungen nun nachträglich entschlüsselt werden könnten. Es ist durchaus davon auszugehen, dass immer dann, wenn sensible Daten abgegriffen werden sollten, auch verschlüsselte Verbindungen auf Vorrat aufgezeichnet wurden, gerade im Bereich Industriespionage dürfte das üblich sein.

Doch der wahre Schrecken lauert auf Seite fünf:

Wer immer sich in den vergangenen 20 Monaten die Mühe gemacht hat, eine Datenbank mit (...) öffentlichen Schlüsseln zu pflegen, konnte vermutlich ungefähr ab Oktober 2006 die erstaunliche Beobachtung machen, dass in dieser Datenbank Kollisionen auftreten, wo eigentlich keine passieren dürften. Aufgrund des Geburtstagsparadoxons genügen schon 500 schwache Schlüssel gleicher Länge, um unter ihnen mit rund 95-prozentiger Wahrscheinlichkeit ein Duplikat zu finden. Vom Entdecken eines solchen Duplikats ist es nur noch ein kleiner Schritt, um über den ungefähren Zeitpunkt und den Kontext der betroffenen Schlüssel auf das Debian-Betriebssystem zurückzuschließen und die in dem Zeitraum vorgenommenen Änderungen am Quellcode der kryptographisch relevanten Programmpakete zu untersuchen.

Das ist DESASTRÖS. Denn es ist mehr als wahrscheinlich, dass Kriminelle, Geheimdienste, vielleicht auch andere Organisationen Schlüssel gesammelt und das Problem bereits vor langer Zeit bemerkt und für Einbrüche und Lauschaktionen genutzt haben.

Bei hack a day gibt es ein Howto, in dem das Löten mit bleifreiem Lötzinn erklärt wird: hack a day: Go green with lead free solder. Definitiv lesenswert.

Und natürlich gibt es Diskussionen über Sinn und Unsinn der RoHS-Richtlinie, die den Einsatz von Blei in der EU verbietet. Jemand behauptet:

it's known that non-leaded solder has a severe problem with whiskers. of course, why would you expect a european government to know about what it's regulating?

Whisker sind hier keine Schnurrhaare, sondern haarförmige Einkristalle, die sich im Metall bilden, wenn mit bleifreiem Lot gearbeitet wird. Sie entstehen unter Umständen erst nach jahren und können Kurzschlüsse verursachen, brennen allerdings auch schnell weg. Da dies trotzdem gefährlich sein kann, werden sicherheitskritische Geräte weiterhin mit bleihaltigen Loten hergestellt.

Uns Konsumenten schadet das ganze kaum, da die Lebensdauer von Elektronik sowieso massiv durch die technische Entwicklung eingeschränkt ist, so schnell wie ein WLAN-Router überholt ist, kann der gar nicht kaputt gehen.

Felix von Leitner schreibt in seinem Blog über eine wirklich gefährliche Angriffsmöglichkeit, die sich aus dem OpenSSL-Debakel ergibt. Alle Verbindungen zu Servern, die ein "schlechtes" SSL-Zertifikat hatten, sind wahrscheinlich immer noch verwundbar. Felix berichtet, dass dies bei einem Server von Akamai der Fall ist, und über Akamai werden Daten für das Steuerprogramm ELSTER übermittelt.

Wie es funktioniert

Die Angreiferin, nennen wir sie Carol, ruft Daten von einer Webseite ab, deren URL mit https beginnt, also über eine SSL-verschlüsselte Verbindung — z.B. beim Online-Banking. Sie erhält dabei das Zertifikat der Webservers, welches sie speichert. Dieses Zertifikat und der geheime Schlüssel dazu sind nun aber mit der kaputten Version von OpenSSL erzeugt worden.

Mit dem Zertifikat und dem enthaltenen öffentlichen Schlüssel alleine kann Carol nichts anfangen, es ist ganz normal, dass man diese übermittelt bekommt. Wichtig ist allerdings, dass das Zertifikat von einer Zertifikatsautorität (CA) signiert wurde, wodurch die Echtheit sozusagen "offiziell" beglaubigt ist.

Der geheime Schlüssel ist außerdem dank des OpenSSL-Fehlers leicht ermittelbar — Carol erzeugt alle möglichen geheimen Schlüssel einfach selbst und prüft, welcher zu dem öffentlichen Schlüssel des Servers passt.

Nun hat Carol also sowohl den geheimen Schlüssel, den eigentlich nur der Server kennen sollte, als auch ein "von offizieller Stelle" signiertes Zertifikat.

Die Zertifikate der "offiziellen Stellen", also der CAs sind in jedem Webrowser vorinstalliert, das heißt jeder Webbrowser erkennt auch das Zertifikat ohne weitere Prüfung oder Abfrage als gültig an, obwohl es unsicher ist:



Natürlich haben die Betreiber die verwundbaren Zertifikate schon ausgetauscht. Aber Carol war schnell, und hat das alte vorher gespeichert, gleich nachdem der OpenSSL-Fehler bekannt wurde. (Zukünftig wird Carol dies automatisieren, ein kleines Programm speichert die Zertifikate während sie im Web surft. Denn vielleicht gibt es nochmal so einen Fehler.)

Zwar überprüft ein Browser das Ablaufdatum, welches unveränderlich im Zertifikat steht und dieses nach einer bestimmten Zeit automatisch ungültig macht, aber das ist schlichtweg noch nicht erreicht.

Dagegen gibt es natürlich auch einen Schutzmechanismus, nämlich zentrale Stellen, die Listen mit vorzeitig für ungültig erklärten Zertifikaten enthalten, sogenannte CRLs (Certificate Revocation Lists). Doch diese Listen muss der Browser auch abrufen.

Tut er aber nicht:



Die Standard-Einstellung des Browsers Firefox ist, keine CRLs abzurufen. Das dürfte bei vielen Programmen so sein, und auch E-Mail-Programme, Homebanking-Programme und Programme zur Übermittlung der Steuererklärung benutzen SSL.

Schaltet man die Prüfung ein, so funktioniert sie möglicherweise nicht, was die Funktion einfach nur lästig macht:



Mit dem privaten Schlüssel und dem signierten Zertifikat kann Carol nun dem Browser irgendeines Users glaubhaft vormachen, ihr eigener (manipulierter) Server sei der Server, dessen Zertifikat sie "übernommen" hat. Sie kann sich also als Mittelsmannfrau in die vermeintlich geschützte Verbindung einklinken, und somit Daten mitlesen, unterdrücken oder gar verändern, also zum Beispiel Schadcode, etwa einen Trojaner, einschleusen.

Man nennt dies eine Man-In-The-Middle-Attacke, kurz MITM. (Oder WITM. Wegen der Gleichberechtigung.)

Der Haken beim PKI-Verfahren

Wie Felix ganz richtig schreibt, ist das ganze Prinzip der PKI, der Echtheitsprüfung durch irgendwelche Zentralstellen, die der User gar nicht kennt, ihnen also auch nicht vertrauen kann, schon allein durch die Zahl der standardmäßig installierten CA-Zertifikate der eigenartigsten CAs höchst zweifelhaft.

Es ist keine Diskriminierung, sondern reine Vernunft, wenn ich sage, dass ich eigentlich nicht möchte, dass die mir völlig unbekannte Stelle "TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş" (Türkei) oder die"NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado" (Ungarn) Zertifikate für gültig erklärt, mit denen mein Browser verschlüsselte, also vermeintlich sichere Verbindungen aufbaut.

Ich muss überhaupt nicht an Geheimdienste denken, ganz normale Kriminelle werden schon ihre Wege finden, die ein oder andere CA für ihre Zwecke zu missbrauchen.

Was tun?

Das einzige, was Server-Betreiber gegen diesen Angriff tun können, ist das alte Zertifikat dadurch unbrauchbar zu machen, dass sie ihre Domain ändern, bis die alten Zertifikate abgelaufen sind. Dumme Sache.

Benutzer müssen bei vielen Webseiten, die keine "offiziell beglaubigten" Zertifikate haben, ohnehin selbst entscheiden, ob sie das Server-Zertifikat

• nur temporär akzeptieren (es könnte gefälscht sein)
• dauerhaft akzeptieren (sie kommunizieren zumindest immer mit dem selben Server und halten es für unwahrscheinlich, dass Carol dahinter steckt) oder
• verifizieren.

Um diese Entscheidung immer selbst zu fällen, können sie alle CAs, denen sie nicht vertrauen — das werden wohl nahezu alle sein — in den Einstellungen ihrer Software deaktivieren.

Wenn es wichtig ist, und sie das Zertifikat verifizieren müssen, — die Fingerprints überprüfen, in dem sie den Betreiber anrufen.

Bei so etwas wichtigem wie dem Online-Banking oder der Steuerrerklärung z.B. sollte man das unbedingt tun!

Banken und Behörden werden sich natürlich wundern, aber es ist deren Schuld, schließlich schicken die den Kunden zwar stapelweise Papier mit PINs, TANs und iTANs, aber die Fingerprints ihrer Banking-Webseiten und Steuerdatenserver fehlen in den Unterlagen.

Aus bekannten Gründen müssen auch X.509-Zertifikate, welche zwischen September 2006 und Mai 2008 auf Debian-Systemen erzeugt wurden, neu generiert werden.

Mit EASY-RSA, einer Sammlung von Scripten aus dem OpenVPN-Paket, oder TinyCA, einem Frontend für OpenSSL, bekommt man zwar relativ leicht seine eigene Zertifikats-Hierarchie aufgebaut. Doch alle mir bekannten OpenSSL-Howtos zur manuellen Vorgehensweise sind eher mittelmäßig, da oft wichtige Details untergehen oder ganz fehlen und die Konfigurationsdateien chaotisch sind. Und über die Man-Pages der OpenSSL-Werkzeuge kann man bestenfalls sagen, dass sie eine gute "Idiotenbremse" sind.

Nicht jede in diesem Howto gezeigte Einstellung ist auch nötig oder hundertprozentig korrekt. Die verwendeten Parameter ermöglichen aber eine schnelle und systematische Erzeugung der Zertifikate, und die Konfigurationsdateien sind lesbar. "eigene X.509-Zertifikats-Hierarchie mit ... »

Bei teslastuff.com bekommt der "kleine Hochspannungstechniker" alles, was das Herz begehrt:



Zur Berechnung von Selbstbau-Spulen gibt es das Programm Teslamap. Es ist in Java geschrieben und funktioniert daher auch unter Linux.

Ist schon mal jemandem aufgefallen, wieviel Altmetall man mit einem alten Prozessor so zum Elektroschrott trägt?

Die Kühlkörper sind riesig und haben oft nach ein oder zwei Prozessorgenerationen ausgedient. Wenn man dann mal wieder seinen eigenen Fluxkompensator zusammenlötet, muss man für einen Kühlkörper Apothekenpreise zahlen.
"Prozessorkühler-Recycling" vollständig lesen »