Mitternachtshacking

Microchips können entweder über Kontakte oder über Funk (RFID) mit Strom versorgt werden, prinzipiell ist das für das Reverse Engineering jedoch egal. RFID-Chips sind meist einfacher, weil sie auf wenig Stromverbrauch optimiert sind. Interessant ist das Reverse Engineering beispielsweise um sogenannte Fuses (Schalter) umlegen zu können, mit denen Speicherbereiche Read-Only abgesichert sind. Ein weiterer Anwendungsbereich ist das Abhören interner Busse und schließlich das Reverse Engineering proprierärer Kryptoalgorithmen. Unter anderem war Starbug am Dekodieren von Mifare Classic (Crypto1), Legic Prime und DECT (DSC) beteiligt. Interessant ist das Verfahren auch bei Hardware Security Modulen (z.B. in Geldautomaten im Einsatz).

Vorgehensweise in Kurzfassung:

• Extrahieren des Chips aus dem Kartenkörper -> Azeton (löst das Polycarbonat)
• Entkapseln des Chips aus Epoxidharz -> Rauchende Salpetersäure (Vorsicht!)
• Alternativ kann Kolophonium verwendet werden, das beschädigt jedoch den Chip

Schichtweises Abtragen des Chips:

• Ätzen mit Flusssäure (für Transistorlayer)
• Plasmaätzen, Focused Ion Beam (FIB) (geringe Abtragsrate)
• Polieren (manuell, automatisch)

Ein Problem beim Polieren ist eine Verkippung des Chips, wenn man Ebenen also schief abschleift. Man kann den Chip jedoch auch eingießen (benötigt sehr plane Oberfläche).

Die meisten Chips haben mehrere Ebenen, z.B. der Mifare Classic eine Cover Layer (zum Schutz des Chips), dann drei Interconnection Layer (die Verdrahtung) und dann kommt die Logic Layer und die Transistor Layer. Anhand der Transistoren und der Verbindungen in der Logic Layer lassen sich die Funktionen des Chips erkennen. Auf Siliconzoo.org findet man Beispiele dieser Bilder. Die Bilder selbst lassen sich für ältere Chips noch mit guten optischen Mikroskopen erstellen. Bei aktuellen Chips ist die Strukturbreite so gering (kleiner 150 nm), dass man entweder ein Rasterelektronenmikroskop oder einen Focused Ion Beam zur Aufnahme.

Also für meinen Hausgebrauch ist das alles eher nichts. Aber schon cool.

Schlossöffnung ohne Lockpicking 🙂

Als erstes stellt Ray die Impressionstechnik vor. Dabei wird ohne Vorlage ein Schlüsselrohling so gefeilt, dass sich damit am Ende ein Schloss öffnen lässt. Der Rohling wird dafür in das Schloss gesteckt und bewegt. Nicht passend sitzende Stifte hinterlassen Markierungen. An diesen Stellen feilt man vorsichtig nach. Benötigt werden ein passender Rohling mit dem richtigen Profil, ein Griff zum Halten des Rohlings, eine Feile, eine Lupe mit Lampe (Leuchtlupe) und ggf. eine Schieblehre. Für die Impressionstechnik ist ein Messingrohling ideal, inzwischen gibt es auch kommerzielle Impressionsgriffe. Für die Feile wird ein spezieller Schliff („Schweizer Schliff #4“), der beim Schleifen eine feine rauhe Oberfläche erzeugt, die vom Stift im Schloss poliert wird. Der Weltrekord liegt heute bei 1,5 Minuten. Ein Handbuch ist Online.

Das Master Lock Speed Dial wird durch Bewegung (hoch/runter/links/rechts) geöffnet. Im Prinzip sind unendlich lange Codesequenzen möglich, das Schloss kennt jedoch nur 7501 (5*5*5*15*4) Zustände (12 Bit Entropie). Die längste eindeutige, nicht kürzbare Sequenz besteht aus 11 Bewegungen. Zur Öffnungstechnik wurde per Software die Hashfunktion der Mechanik revertiert und ein Verfahren entwickelt mit dem man einzelne Räder im Schloss durch geeignete Kombinationen weiterdrehen kann. Ein Artikel von mh ist online, ebenfalls die Analyse (PDF).

Einige Hotelsafes (die kleinen grauen Teile mit einer Batterie und Tastenfeld) lassen sich durch Draufschlagen öffnen. Der Stift wird durch eine (schwache) Feder gehalten und durch einen Elektromagneten weggezogen. Weil nur wenig Strom den Stift bewegen muss, kann man durch Schlagen oder Schütteln den Stift ebenfalls bewegen.

Echte Tresorschlösser sind dagegen sehr komplex, da es sehr viele Kombinationen gibt und man längst nicht mehr nach Gehör gehen kann. Man kann jedoch versuchen, die Kontaktpunkte zu fühlen an denen der Hebel einrastet. Das Standardwerk dazu ist von Matt Blaze (PDF). Dazu gibt es bei Matt auch einen Blogeintrag.

Das dn42 ist  ein privates, auf OpenVPN basierendes Netz, das dynamisches Routing mittels BGP implementiert und weitere Dienste wie DNS, etc. zur Verfügung stellt. Aktuell besteht dn42 aus etwa 86 IPv4 Netze, 49 IPv6 Netze und 32 namentlich bekannte Teilnehmer.

Verwendete Hardware: Cisco, Juniper, Force10, Brocade

Verwendete Software: Quagga, OpenBGPd, Xorp, Bird

Peering: u.a. zu Freifunk und ChaosVPN

Geplant: Whois-Server, mehr IPv6, Anbindung von Hackerspaces

Kontakt: über das dn42-Wiki

Cloud = Wolke, Computing = Rechnen, Cloud Computing ist also das „Rechnen in der Wolke“. Ok, ich denke nach 30 Sekunden, den Vortrag hätte ich mir sparen können. Für meinen Geschmack wird das zu trivial und oberflächlich.

Lustige (und unvollständige) Liste der Cloud Computing Anbieter (alphabetisch): 3tera, Amazon, Google, Microsoft, Rackspace, Salesforce.com, Yahoo, Zoho.

Lustige Unterscheidung: Public und Private Cloud. Na gut. Public = bei anderen; Private = bei mir.

Lustige Abkürzungen: IaaS (Infrastructure as a Service = man mietet sich virtuell einen Server), z.B. Amazon EC2, 3tera; PaaS (Platform as a Service = man mietet sich ein Framework auf einer definierten Betriebssystemplattform), z.B. Google App Engine, Windows Azure und SaaS (Software as a Service = man mietet sich ein Programm), z.B. Google Apps, Salesforce.com.

Lustige Anwendungszwecke: Online-Backup, File-Sharing, Online-Communitys (Facebook, Twitter, etc.), Online-Dienste (Mail, Office, Kalender).

Lustige Open Source Frameworks: Eucalyptus (Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems), openQRM und Ubuntu Enterprise Cloud (UEC).

Die Vor- und Nachteile der Cloud werden im Vortrag einfach direkt zusammengewürfelt, ohne zwischen den Anbieterformen (IaaS, PaaS, SaaS) und den konkreten Angeboten zu unterscheiden. Ein virtuelles System kann man ggf. zu einem anderen Anbieter umziehen. Bei Amazon kann man sogar das Rechenzentrum spezifizieren (wenn z.B. Daten in der EU gespeichert werden müssen). Eine Google App kann man halt nicht umziehen und die Daten auch nur schwer exportieren.

Was mir in dem Vortrag fehlte, war vor allem eine Analyse von Cloud Computing zum Thema Datenschutz und Datensicherheit. Was ist, wenn die Daten bei einem US-Anbieter liegen? Wie sieht es allgemein mit der Sicherheit aus, kann man sich z.B. auf das Patchmanagement des Anbieters verlassen? Wie können Schlagwörter wie „Virenschutz in the Cloud“ interpretiert werden.

Und ja, es war zu trivial und oberflächlich.

Politisch ist das Profilierung ein heikles Thema, das gesellschaftlich in der angewandten Form sicher nicht akzeptiert würde. Praktisch ist es hochspannend zu sehen, wie knappe Ressourcen zugewiesen werden. Ich denke, vergleichbares werden wir in der Medizin (Medikamente, Operationen) in naher Zukunft auch verstärkt erleben.

Profiliert wird laut Vortrag nach den Kriterien:

• Arbeitsmark (wie hoch ist die lokale Arbeitslosigkeitsrate, wie viele offene Stellen gibt es)
• Motivation (wie bereit ist der Arbeitslose, Stellen in der größeren Entfernung zu suchen, weniger Gehalt zu akzeptieren, etc.)
• Qualifikation (welche Berufserfahrung hat ein Arbeitsloser)
• Hemmnisse (welche weiteren Probleme stehen einer Arbeitsaufnahme entgegen? beispielsweise Alter über 50, Kinder, kein Führerschein, keiin Auto, …)

Unterschieden wird nach

• Marktkunden (dürften leicht wieder eine Stelle finden) erhalten eine hohe finanzielle Förderung aber wenig Betreuung
• Aktivierungskunden (müssen motiviert (und/oder schikaniert) werden) und
• Förderungskunden (werden qualifiziert, erhalten Weiterbildungsmaßnahmen) erhalten eine mittlere finanzielle Förderung aber eine intensive Betreuung
• Betreuungskunden (werden nur noch verwaltet) erhalten kaum finanzielle Förderung und wenig Betreuung.

Sobald ein „Kunde“ zwei „Probleme“ hat, fällt er praktisch in die Gruppe der Betreuunngskunden hinein, die nur noch verwaltet werden. Insbesondere Arbeitslose in wirtschaftlichen Randgebieten haben weniger Chancen auf Förderung als Arbeitslose in wirtschaftlich guten Gebieten, da der schlechte Arbeitsmarkt bereits als erstes Prroblem gilt und ein zweites Problem dann zum Betreuungskunden führt. Ein gleichqualifizierter und gleichmotivierter Arbeitsloser würde beispielsweise in München gefördert (wirtschaftlich gute Region), in Neubrandenburg (Mecklenburg-Vorpommern) jedoch nicht.

Ziel der Förderung der Arbeitsagenturen ist oft primär, durch Einsatz von Mittel die Bezugsleistung des Arbeitslosengeldes zu verringern und damit Bundesgeld einzusparen. Bezieher von Hartz 4 erhalten ihr Geld von den Kommunen, deren Förderung ist der Arbeitsagentur weitgehend egal, da das Geld aus einem anderen Haushalt kommt.

Während der Laufzeit eines Programms lassen sich noch einige Tricks umsetzen, um die Sicherheit von Programmen zu verbessern, indem beispielsweise Exploits für mögliche Buffer Overflows erschwert oder verhindert werden. Dafür kommen Techniken wie Stack Randomization (d.h. der Stackanfang wird bei jedem Programmstart zufällig auf eine etwas andere Adresse gesetzt, Einsprungadressen für Exploits verändern sich dann bei jedem Programmaufruf, ein Exploit wird unzuverlässig), Shared Library Randomization (d.h. gemeinsam genutzte Bibliotheken wie die Libc werden in zufälliger Reihenfolge und zufällig an unterschiedliche Adressen gemappt, sogenannte Return-to-Libc-Exploits, die eine bestimmte Adresse der in der Libc anspringen müssen werden dadurch unzuverlässig), etc. zum Einsatz.

Aktuelle verbreitete Maßnahmen sind:

• data/code separation (siehe Harvard Architektur)
• randomized stack bottom
• shared libs randomization
• randomized malloc

Viele dieser Maßnahmen wurden als erstes in  OpenBSD implementiert. Mögliche Verbesserungen enthalten

• section starting address randomization (16 Bit Entropie)
• randomized loading order (abhängig von der Anzahl der Bibliotheken)

Zu den obskureren Verfahren gehört dann wohl

• executable randomization (pie executables)
• gaps filled with bad stuff (keine NOP-Sleds mehr)
• morphing executables (ah … die Virenscanner freuen sich)

Einige dieser Maßnahmen würden bis zu 10% Performanceeinbußen mitbringen, hier wäre eine Abwägung zwischen Leistung und Sicherheit notwendig.

SmartMeter (intelligente Stromerfassungsgeräte) im Selbstbau und Selbstversuch. Ein SmartMeter kann dazu verwendet werden, das Stromverbrauchsprofil zu analysieren. Insbesondere kann der zeitliche Ablauf sehr genau analysiert werden um unnötige Verbraucher z.B. Standby in der Nacht zu ermitteln. Spätestens Ende 2010 müssen alle Energieversorger einen Tarif  anbieten, der einen Anreiz zum Energiesparen setzt. Zukünftig ist eine monatliche Stromrechnung geplant.

Anhand von detaillierten Verbrauchsprofilen kann man beispielsweise genutzte Geräte wie Kühlschrank, Backofen, etc. identifizieren. Daraus entstehen detaillierte Rückschlüsse auf die Lebensgewohnheiten.

Gesetzlich ist nicht geregelt, ob und wie der Energieversorger erfasste Daten nutzen darf, wie oft er Daten erfassen darf (zeitliche Auflösung) und wie Daten gegebenenfalls weitergegeben werden (Aggregierung, Anonymisierung). Die Kombination aus Nutzeridentifizierung und hoher zeitlicher Auflösung ist dabei kritisch zu sehen.

Den Volkszähler muss man sich selbst einbauen, Kenntnisse in E-Technik und Stromversorgung sind dabei seeeehr hilfreich. Es gibt einzuschleifende Hutschienenzähler, optische Zähler, Stromzangen (mit und ohne Spannungsmessung) und Zwischenstecker. Für die Weiterleitung und Auswertung der Daten gibt es ebenfalls mehrere Lösungsansätze. In Frage kommen ein zentraler Server im Internet, ein eigener Server oder z.B. eine Speicherkarte.

Beim Controller und bei der Auswertung ist noch vieles in der Entwicklung.

Das Wiki dazu wird von Wikia gehostet.

IPv6 ist bekanntlich der Nachfolger von IPv4 und wird seit rund 20 Jahren entwickelt. Inzwischen ist man soweit, dass man IPv4 durch IPv6 ersetzen könnte. Es bewegt sich nur nichts.

Mythos 1: Sicherheit – IPv6 bringt vor allem einen größeren Adressraum. Das Internet wird durch IPv6 nicht per se sicherer. Der einzige Vorteil (für die staatlichen Überwacher) wäre, dass man mit fest zugeordneten Adressen den Nutzer eindeutig adressieren kann. Für Administratoren treten eher Sicherheitsprobleme durch unausgereifte Implementierungen und fehlende oder unvollständige Unterstützung in Firewalls auf. NAT selbst hat noch nie eine wirklich größere Sicherheit geliefert.

Mythos 2: Geschwindigkeit – Das Internet wird auch nicht schneller, QoS lässt sich im Internet praktisch kaum flächendeckend umsetzen, IPv4 wird genau wie IPv6 inzwischen in Hardware gehandhabt.

Mythos 3: Einfache Konfiguration – IPv6 unterstützt Stateless Address Autoconfiguration und Stateless DHCP, DHCP funktioniert mit IPv4 aber längst auch stabil.

Mythos 4: Mobility – Mobile IP ist mit IPv6 zwar deutlich besser gelöst, eine feste IPv6-Adresse könnte über beliebige Netzwerke mitgenommen werden. Praktisch scheitert das meist am automatischen Netzwerkzugang. Ohne Seamless Roaming bringt Mobile IPv6 folglich wenig.

Security-Aspekte

Der Betrieb von Firewalls wird in der Anfangszeit mühsam. Alle IPv6-Objekte müssen neu erfasst werden, alle Regeln müssen praktisch doppelt (für IPv4 und IPv6) getestet werden. Windows Vista und 7 tunneln automatisch IPv6 durch IPv4, wenn der Zielrechner eine IPv6-Adresse hat. Das selbst dann, wenn am lokalen Interface nur IPv4 konfiguriert ist. Dafür fallen ein Teil der Portscans weg, weil der Adressraum extrem groß wird.

Privacy

Mobile IPv6 Clients sind unheimlich gut durch verschiedene Netze und Provider und dadurch auch räumlich trackbar. Deshalb gibt es eine extra Privacy Extension (RFC 3041).

Insgesamt war der Vortrag gespickt mit Informationen zu IPv6, da werde ich das eine oder andere sicher noch nachlesen …

Link: SixXS IPv6 Tunnel Provider

Florian Schießl berichtet über den Zwischenstand des freien Linux-Desktops der Stadt München. OpenOffice ist ausgerollt und in Verwendung, der Linux-Basisclient ist noch nicht soweit. Bisher sind 3000 Arbeitsplätze komplett auf Linux umgestellt. Die anderen Arbeitsplätze verwenden noch Microsoft Windows, nutzen aber OpenOffice, Thunderbird, Firefox, Gimp, etc. Basis des Linux-Clients ist aktuell Debian Etch mit KDE. Der Basisclient ist für alle Arbeitsplätze identisch. Software-Verteilung erfolgt mit FAI der Uni Köln.

Makros, Formulare und Vorgänge werden plattform- und Office-Anwendungsunabhängig mit Hilfe der Eigenentwicklung WollMux (ein Wortspiel aus der eierlegenden Wollmilchsau und dem Maskottchen Mux) abgebildet, die Formulare z.B. mit Hilfe von Datenbankabfragen automatisch füllen kann. Datenaustausch erfolgt überwiegend mit PDF nach außen, wenn Bearbeitung erfolgen soll mit ODF. Ziel ist jedoch immer die Verwendung offener, standardisierter Formate.

Links:

• LiMux-Webseite der Stadt München
• WollMux-OpenOffice-Plugin
• LiMux-Blog

There is no answer to the question „How far can TCP go?“

TCP Authentication Option (AO)

TCP MD5 (RFC 2385)  wird  abgelöst von Authentication Option (AO). Die MD5-Prüfsumme steht in einer TCP-Option. Das Segment wird verworfen, wenn die Prüfsumme nicht stimmt. AO erlaubt beliebige Hash-Algorithmen, unterstützt Rekey, Replay-Protection und benötigt 16 Byte im TCP-Header. TCP-AO ist aktuell als IETF-Draft verfügbar. Schlüsselwörter: Sequence Number Extension (SNE), Master Key Tuple (MKT). Links: Draft TCP-AO, Draft TCP-AO Crypto.

SACK Loss Recovery

Frühzeitige Erkennung von verlorengegangenen TCP-Paketen Mit Hilfe der TCP-Option Selective Acknowledgement. Links: Draft SACK Recovery.

Mobile Ad-hoc Netzwerke

Mobile Ad-hoc Netze müssten über ein dynamisches Routingprotokoll benachbarte Systeme erkennen. Verwendet wird dafür das Optimized Link State Routing Protocol (OLSR, RFC 3626). Schlüsselwörter: Mobile Ad-hoc Netzwerk (Manet). Links: Draft OLSRv2, Draft DYMO, Draft SMF.

Staukontrolle

Staukontrolle (RFC 2581) soll eine zu hohe Belegung des Netzwerks verhindern. Dabei werden verschiedene Verfahren der Congestion Control verwendet. Die Hauptarbeiten stammen von Van Jacobsen, der Congestion Control in TCP entworfen hat. Bei UDP fehlt die Staukontrolle. Deshalb wird versucht mit einem eigenen Protokoll, Datagram Congestion Control Protocol (DCCP, RFC 4340) dieses Problem anzugehen. Zusätzlich könnte man sich die ermittelte Bandbreite zu einem Kommunikationspartner auch nach Ende der Verbindung merken. Ein weiteres Hilfsmittel ist Quick Start TCP.

TCP Cookie Transaction

Damit soll verhindert werden, dass Daten einer alten mit einer neuen Verbindung vermengt werden. Früher hat man einfach einen Socket und Port länger gesperrt, inzwischen versucht man das Problem anders zu lösen. Dabei kommt ein TCP Cookie zum Einsatz. Links: Draft TCP TIME_WAIT, Draft TCP CT.

Interessant ist für mich jetzt primär die Entwicklung von TCP-AO. Ich könnte mir vorstellen, dass es in naher Zukunft Netzwerkkarten gibt, die die komplette TCP-AO-Berechnung auf der Karte durchführen (Offloading) und damit ein großer Teil zukünftiger Netzwerkverbindungen mit TCP-AO authentisiert werden kann. Dann würden vermutlich Man-in-the-Middle-Angriffe erheblich erschwert. Die anderen Punkte beschäftigen sich hauptsächlich mit der Verlässlichkeit und Verfügbarkeit von Datenübertragungen und das finde ich persönlich jetzt nicht so interessant.

In diesem Zusammenhang verweise ich auch gerne auf den TCP Security Draft von Gont.