1. Februar 2009
„Cost Risk Assessment (CRA) is a term used to describe a broad program of risk based assessment being conducted within Washington State Department of Transportation. CRA is also a term that describes a workshop process similar but less intense than a Cost Estimate Validation Process (CEVP). Risk Management is an integral part of the WSDOT Project Management Process.“
Und das vom Washington State Department of Transportation. Das muss ich mir mal genauer anschauen.
31. Januar 2009
Ich habe lange gewartet, bevor ich mich heute dazu aufgerafft habe, De-Mail zu kommentieren. Das liegt daran, dass DE-Mail einige brauchbare Ideen hatte und ich erst die konkreten Pläne der Umsetzung abwarten wollte bevor ich das Projekt verbal in Grund und Boden ramme. Inzwischen sind die wichtigsten Karten auf dem Tisch und wenn nicht noch ein Wunder (oder ein typisches Zypries-Gesetz) passiert, dann ist De-Mail so eine Fehlgeburt wie die meisten IT-Großprojekte der Bundesregierung und wird uns wie die Gesundheitskarte oder Elster oder der ePass zwangsweise auf’s Auge gedrückt.
Zuerst zu den guten Ideen: Fehlende rechtssichere E-Mail Kommunikation ist schon länger ein Hindernis in der wirtschaftlichen Entwicklung hier in Deutschland. Insbesondere die im Signaturgesetz geforderte fortgeschrittene digitale Signatur mit ihren komplexen und umfangreichen Sicherheitsanforderungen hat sich als massiver Hemmschuh herauskristallisiert. Die fehlenden Smartcards und teuren Signaturkomponenten sind ein weiteres Problem, insbesondere die gedachte Kopplung mit dem Personalausweis oder der Gesundheitskarte hat nicht gerade für Vertrauen in der Bevölkerung gesorgt.
Die Umsetzung ist jedoch alles andere als vertrauenerweckend
Zum einen behält das Bundesinnenministerium die Federführung des Projekts. Das betrifft sowohl die E-Mail Adresse als auch den geplanten sicheren Datenspeicher „De-Safe“. Im Ergebnis werden wir zwar vermutlich eine per Gesetzesdefinition rechtssichere Kommunikation bekommen, die dafür leider nicht vertraulich sein wird. Ich bin sicher, mit De-Mail sieht Schäuble die einmalige Chance, einen Schnüffelstaat Orwell’scher Dimension einzurichten und der paranoide Verfassungsfeind wird sich diese Möglichkeit vermutlich nicht entgehen lassen wollen.
Dann ist das BSI für die Akkreditierung der De-Mail Anbieter zuständig. Das BSI, das sind die mit den BSI Grundschutzkatalogen. Die Umsetzung des Grundschutzes ist recht umfangreich und verlangt so viele Ressourcen, dass sich voraussichtlich nur große Provider eine solche Zertifizierung leisten wollen. Die Parallelen zur typischen Wirtschaftspolitik in Deutschland, bei der großen Konzernen das Geld nachgeworfen wird, auch wenn diese die Arbeitsplätze ins Ausland verlagern während gleichzeitig der Mittelstand vor die Hunde geht ist frappierend.
Ein weiterer grundsätzlicher Fehler im Design ist die fehlende lebenslange universelle Adresse. Der Aufbau der Adresse soll nach dem Format „erika.mustermann.123@providerxy.de-mail.de“ erfolgen. Die Nummer ist notwendig, um verschiedene Nutzer gleichen Namens zu unterschieden. Bei einem Providerwechsel erhält der Nutzer jedoch eine neue Mailadresse, die alte Adresse wird vermutlich nach einigen Monaten wieder freigegeben. Ein Nutzer gleichen Namens kann so potentiell Zugriff auf wichtige Mails seines Namensvetters erhalten.
Am meisten aber amüsiert mich die Vorstellung, für De-Mail-Mails auch noch Porto zu bezahlen. Ich bin ja gespannt, wie man einem an Flatrate gewöhnten Internet-Nutzer vermitteln will, für eine De-Mail-Mail Geld zu bezahlen, auch wenn es nur 10 Cent sein sollten wenn es bei Web.de und GMX kostenlose Postfächer für jeden gibt.
Warum etwas wie De-Mail trotzdem kommt!
Die Behörden suchen schon seit geraumer Zeit eine günstige Möglichkeit, digital aber rechtssicher mit dem Bürger zu kommunizieren. Die vom Gesetzgeber gestellten Anforderungen an digitale Signaturen sind jedoch so hoch, dass außer ein paar Datev-Steuerberater und die Finanzbehörden niemand sie erfüllen will. Die Kosten dafür liegen einfach in keinerlei Verhältnis zum Nutzen für den Bürger. Weil der Staat aber immer mehr Arbeit auf den Bürger verlagern will, erfolgt das eben per Gesetz.
Beispiel Elster. Ich habe selten in meinem Leben eine so grottenschlecht gestrickte peinliche Software gesehen, wie die erste Version der Elster-Software. Eigentlich sollten sich die verantwortlichen Pappnasen in Grund und Boden schämen. Trotzdem wurden Unternehmen per Verordnung verpflichtet, ihre Umsatzsteuererklärung zukünftig mit dieser Dreckssoftware digital einzureichen. Ohne digitale Signatur, ohne ausreichende IT-Sicherheit, ohne zuverlässige Identitätskontrolle, das war alles scheißegal. Für die Unternehmen gab es die Kosten, für die Finanzbehörden den Vorteil.
Das gleiche wird jetzt mit De-Mail auch passieren. Warum noch ein teures Einschreiben verschicken, wenn man dem Bürger irgendwelche Mails einfach in sein De-Mail-Postfach stecken kann. Mit der Zustellung in das De-Mail Postfach ist die Mail zugestellt. Ob der Bürger darüber irgendwie informiert werden kann, z.B. per SMS oder selbst dran denken muss, täglich in das De-Mail-Postfach zu gucken ist doch den Behörden egal. Und wenn der Bürger vergisst ins Postfach zu gucken und damit Fristen versäumt … selber schuld. Die Behörden profitieren, für den Bürger wird alles schlechter.
Natürlich ist das den aufgeklärten Internetnutzern recht egal. Deshalb wird es in absehbarer Zeit eine nette Verordnung geben. Beispielsweise, dass Steuererklärungen nur noch digital über einen De-Mail Account eingereicht werden können. Wenn der Bürger also zuviel gezahlte Steuern zurück will, dann nur via De-Mail. Und schon kann man die anderen Mails auch rechtssicher zustellen.
Ich fürchte, De-Mail wird noch ein schönes Ärgernis
30. Januar 2009
Mich wundert ja, dass sowas noch funktioniert. Aber gut, HTML-„Programmierer“ gibt es eben überall. Als Suchanfrage habe ich einen einzelnen Singlequote verwendet:

Ach ja, schon vor Wochen. Aber bei Münchenticket scheint nicht nur die Suche nicht richtig zu funktionieren, auch die Benachrichtigung der Administration hat offensichtlich eine Macke.
25. Januar 2009
Hypo Real Estate
2000 Mitarbeiter
Insgesamt 92 Milliarden Euro Beihilfen und Garantien
BayernLB
5170 Mitarbeiter (Bank)
19985 Mitarbeiter (Konzern)
Förderung: 10 Milliarden Euro Eigenkapital, 15 Milliarden Garantien
Insgesamt 25 Milliarden Euro Beihilfen und Garantien
Commerzbank
36767 Mitarbeiter (Konzern)
Förderung: 10 Milliarden Euro Eigenkapital (für 25%), 8,2 Milliarden Einlage, 15 Milliarden Garantien
Insgesamt knapp 35 Milliarden Euro Beihilfen und Garantien
Qimonda
13481 Mitarbeiter (Konzern)
40000 Mitarbeiter (indirekt in Sachen abhängig)
Förderung: Fehlanzeige, ist ja keine Bank
Mit einer Milliarde hätte Qimonda vermutlich gerettet werden können. Aber Zukunftsindustrien wie Halbleitertechnik brauchen wir in Deutschland nicht. Wir haben ja die tolle Autoindustrie mit ihren riesigen Spritschluckern. Scheiß Politik.
21. Januar 2009
Zwei Wochen nicht ganz gesund und schon geht es hier mit dem Spam rund. Naja, egal … ist sicher schneller von mir gelöscht als von den ganzen SEO-Deppen getippt.
Jedenfalls … darüber musste ich dann doch herzlich lachen:

Das meinen die hoffentlich nicht ernst? Sonst muss ich in den SMTP-Dialog meines Mailservers noch reinschreiben, dass dieser Rechner nur kommuniziert und nicht berechtigt ist, in meinem Namen eine Policy anzunehmen.
Naja, ist der Mailgateway der Stadt München. Ich fürchte, da war einem Beamten mal wieder langweilig und er konnte nicht schlafen.
29. Dezember 2008
FX von Phenoelit ist einer der wenigen, die sich mit Cisco IOS beschäftigen und Sicherheitslücken gefunden sowie Exploits geschrieben haben. Cisco hat den größten Marktanteil und ist relativ schwierig zu hacken, im Gegensatz beispielsweise zu Juniper, deren JunOS weitgehend auf FreeBSD basiert. Natürlich ist Cisco deshalb auch für Hacker interessant. Router und Switches sind auch interessant, weil man damit die komplette Netzwerkinfrastruktur übernehmen kann. Man IST dann das Netzwerk.
- IOS-Geräte sind lange in Betrieb und werden selten aktualisiert
- IOS-Geräte werden immer komplexer mit immer mehr Software, die Angriffsoberfläche wird größer
- Es gibt diverse Backdoored IOS Images die unbedarfte Admins aus dem Internet runterladen
Im Gegenzug sind Angriffe gegen IOS sehr komplex und schwierig. Ein Angreifer möchte einen zuverlässigen Halt im netzwerk erhalten und nicht schnell wieder rausfliegen. Allerdings sind inzwischen gute Windows Exploits mit Rootkit ebenfalls in der Preisklasse von 40.000 USD, daher lohnt es sich laut FX langsam, insbesondere für Agencies, andere Systeme ins Visir zu nehmen.
Die Angriffe lassen sich in verschiedene Klassen aufteilen:
- Functionality attacks
- weak passwords
- weak SNMP communities
- posting the configuration in Internet forums
- Access check vulnerabilities
- Ciscos HTTP Level 16++ vulnerability (alt)
- SNMPv3 HMAC verification vulnerability (Buffer Overflow von 2008: memcmp(MyHMAC, PackHMAC, PackHMAC_len);)
- Debianized SSH Keys
- Queuing Bugs
- Router Service Vulnerabilities
- diverse Phenoelit-Exploits
Erfolgreiche Angriffe können auf verschiedenen Wegen erkannt werden:
- SNMP, Syslog
- Configuration Monitoring/Polling
- Router Monitoring
- Traffic Monitoring
Beweise einer Kompromittierung sind schwierig zu erhalten, die beste Möglichkeit ist Core Dumps zu analysieren. Dabei hilft die Defaulteinstellung von Cisco, Core Dumps zuschreiben und zu rebooten (was relativ häufig bei Fehlern vorkommt). FX hat deshalb einen Cisco Core Dump Analyzer mit umfangreichen Funktionen geschrieben. Zur Zeit ist das vermutlich das beste Tool zur Analyse von Cisco Coredumps, das verfügbar ist. Auf die Funktionen will ich im Detail hier jedoch nicht eingehen.
FX erklärte dann im Detail, welche Möglichkeiten es gibt, IOS-Exploits zu schreiben und verläßliche Exploits zu konstruieren, da es etwa 100.000 verschiedene IOS-Images gibt, von denen vielleicht noch 19.000 von Cisco supported werden. Das ist elend kompliziert und ich bin sicher, ich werde in absehbarer Zeit keinen Cisco-Exploit schreiben. Aber ich bin mir sicher, wir werden in Zukunft mehr Arbeiten in diese Richtung sehen. insbesondere, da Cisco angekündigt hat, IOS auf VMware anbieten zu wollen.
Die beste Schutzmaßnahme sind ACLs auf dem Router, die Pakete direkt an den Router gerichtet blockieren.
Sehr nett übrigens, man scannt bei Eggcode im RAM heute nicht mehr nach 0x0E66C0DE sondern nach 0xFEFEB106 (Leetspeek für Fefe-Blog 🙂
Targeted Attacks unterscheiden sich von Drive-By Attacks dadurch, dass die Angreifer in der Regel detaillierte Informationen zum angegriffenen Ziel sammeln, z.B. über eingesetzte Sicherheitsprodukte wie Virenscanner. Besonders beliebt sind targeted Attacks im Bereich der Industriespionage. Besonders betroffen ist mit Microsoft der Arbeitgeber von Bruce.
Targeted Attacks in Microsoft Office-Dokumenten sind deshalb geeignet, weil Office zu weit verbreitet ist und viele Leute Microsoft Office-Dokumente gedankenlos austauschen. Außerdem sind sie aufgrund der Komplexität und bescheidenen Dokumentation der Formate trotz inzwischen auf Druck der EU veröffentlichten Spezifikationen schwer zu erkennen. Das Office Binary Format ist für Parser eine echte Krankheit. Auf Details will ich hier gar nicht eingehen. Microsoft selbst bezeichnet das als „filesystem in a file“. Leider ist das Parsen daher nicht „byteweise“ möglich.
OffVis ist ein Microsoft-Tool, das die interne Struktur eines Office-Dokuments defragmentiert so, dass es leichter zu parsen ist. Ansonsten sieht es mit praktikablen Schutzmaßnahmen von Microsoft eher mau aus, außer dem (teuren) Wechsel zu Office 2007 fällt ihnen leider nichts ein.
Die Schadprogramme sind recht straight-forward. Es gibt einen Exploit, den Payload (irgendeinen Shellcode, meist ein Trojaner-Dropper) und ggf. ein harmlos aussehendes Dokument, damit es dem Betrachter nicht auffällt, was im Hintergrund passiert. Der Exploit basiert meist darauf, die Kontrolle über den EIP zu erlangen, z.B. mit einem klassischen Buffer Overflow. Die Payloads sind meistens verschlüsselt und daher schwerer zu erkennen.
Ein möglicher Ablauf kann wie folgt aussehen:
- Shellcode decodes itself and runs
- Builds up list of function pointers
- Finds itself in memory
- Read data from specific location in file
- Extract the trojan and clean the document
- Restarts application with clean document
Den gleichen Vortrag hat Bruce auch schon auf der Recon 2008 in Montreal und der Black Hat Conference dieses Jahr in Japan gehalten. Dort findet man auch die Slides zur Präsentation. Insgesamt jedoch bringt der Vortrag nur Entwickler von Virenscannern weiter, für den typischen Hacker fehlen natürlich Details und Source Code.
PS: Bruce, if you’ve never seen so much Macs on one place … get used to it. 🙂
Flash ist inzwischen ein beliebter Loader für Malware und andere Schadprogramme, da Flash eine Reihe von Sicherheitslücken enthält. Fukami von SektorEins ist vermutlich einer der besten Flash-Experten die es bei uns gibt. BeF ist der Autor von erlswf. Die Analyse von Flash ist nicht trivial, weil Flash mit Obfuscation-Techniken gesichert werden kann.
Javascript kann via ExternalInterface.call() geladen werden. Darüber sind eine Vielzahl von Angriffen möglich. Erlswf prüft Flash-Dateien und kann typische Probleme wie ungültige Komprimierung oder unbekannte Opcodes herausfiltern. Dazu muss man das SWF-Format kennen.
SWF ist ein Containerformat und besteht aus einem Header, einem File Attribute Tag, diversen Daten-Tags und einem End Tag. Die Daten-Tags können Aktionen (DoAction, …) Mediadaten (Bilder, Filme), etc. enthalten. Dabei unterscheiden sich die Tags bei ActiveScript2 und 3 grundlegend. doAction aus AS2 besteht aus einem Header, vielen Actions und einem EndAction Tag. doABC besteht aus einem Opcode und Optionen. Flash 9 unterstützt außerdem die Funktion loadBytes, mit der eine Bytefolge gelesen, on the fly verändert und interpretiert werden kann.
Zur Analyse von Flash-Dateien gibt es keine brauchbaren dynamischen Tools wie Sandboxen, die den Flash-Lauf analysieren. In der Praxis beschränkt man sich zur Zeit daher auf die statische Analyse der Flash-Dateien. Dabei ist die Obfuscation natürlich störend. Ein Großteil des Vortrags beschäftigt sich mit den Möglichkeiten, Flash zu analysieren und Obfuscation aufzudecken. Insgesamt eine coole umfangreiche Arbeit aber wiedermal etwas, das für mich keine besondere Relevanz hat.
In der Agenda stehen nur Ralf-Philipp Weinmann, Andreas Schuler, Erik Tews, auf der Bühne saßen sie jedoch zu viert und erklären uns, wie DECT funktioniert. Für diesen Vortrag habe ich mich kurzfristig entschlossen. Leider ist auf ihrer Webseite deDECTed.org noch nichts online.
Vorläufer von DECT sind CT1(+) und CT2. CT1 und CT1+ darf ab 01.01.2009 nicht mehr verwendet werden, da die Frequenzen für GSM reserviert sind. DECT wird praktisch überall verwendet, in Schnurlostelefonen, Wireless ISDN, Babyfon, Notrufen, Türöffnungssystemen, schnurlosen EC-Kartenleser und sogar Verkehrsleitsysteme (u.a. von Siemens). Vermutlich gibt es über 30 Millionen DECT-Endgeräte in Deutschland.
Typische Kürzel:
- FP – Fixed Part (Basisstation)
- PP – Portable Part (Handgerät)
- RFPI – Radio Fixed Part Identity (Identifikationsnummer)
- IPUI – International Portable Users identity (Nummer des eingewählten Geräts)
- DSC – DECT Standard Cipher (geheim)
- DSAA – DECT Standard Authentication Algorithm (geheim)
- UAK – User Authentication Key
DECT ist standardisiert im ETSI Standard 300175, verwendet GFSK Modulation und nutzt in Europa die Frequenz 1880-1900 MHz. Das DECT-Protokoll mit A- und B-Feld erinnert ein wenig an ISDN und den D- und B-Kanal. Das Telefon sendet nicht im Idle-Mode (keine Funkaktivität!), synchronisiert sich mit der Basisstation und initiiert die Verschlüsselung. Bei einem Gespräch wird der aktuell beste Kanal (wenig Rauschen, keine Aktivität) verwendet.
Sniffen ist nicht so einfach, da die Stationen nicht synchronisiert sind. Viele Pakete enthalten keine Adressen, die Zuordnung ist daher nur über Kanal und Slot möglich, das durch die fehlende Synchronisation erschwert wird. Außerdem ist nicht bekannt, in welchem Kanal und Slot ein Endgerät anfängt zu senden. Zum Descrambling der Pakete muss zusätzlich die Framenummer bekannt sein, ein Problem wenn Frames verloren gehen.
- USRP DECT Sniffer, kann alle Pakete aller Kanäle sniffen jedoch nicht senden. Insbesondere ist das Time-Multiplexing ein Problem. Kosten ca. 1000 Euro.
- ComOnAir II DECT Sniffer, als Basisstation für SIP gedacht. Kosten ca. 23 Euro. Kommt jedoch nur mit Windows-Treiber. Linux-Treiber Entwicklung ist knifflig, da der Baseband-Chip ein spezieller DECT-Chip ist, der nirgendwo sonst verwendet wird.
- ComOnAir III Karte ist etwas größer, hat eine LED, kann zerlegt werden. Kernchip ist ein SC14421.
Wenn keine Verschlüsselung aktiv ist, kann man DECT ganz einfach mitsniffen und damit Gespräche abhören und aufzeichnen. Dafür genügen Standard-DECT-Geräte. Wenn Verschlüsselung aktiv ist, dann wird es etwas komplizierter. Man muss eine Basisstation simulieren und mit dem Telefon unverschlüsselt kommunizieren. Die Gespräche relayed man dann an die eigentliche Basisstation. Das funktioniert, weil sich das Netzwerk nicht am Endgerät authentisieren muss. Das erinnert mich an die IMSI-Catcher im GSM-Netz, die machen das ganz genauso. Ein klassischer Man-in-the-Middle Angriff mit Rouge Basestation.
DECT setzt einen geheimen Algorithmus zur Verschlüsselung ein, DSAA. Praktisch besteht das aus vier Algorithmen, A11, A12, A21 und A22, die reverse engineered wurden. Das ist schon sehr cool 🙂 Die Details führe ich hier nicht auf, die kann man später sicher noch nachlesen. Die Cryptanalysis hat mehrere Schwächen im Algorithmus gezeigt, insbesondere für rundenreduzierte Versionen des Cassable-Algorithmus, die volle Version ist jedoch noch nicht gebrochen. Die Cryptanalysis wird im Detail auf der CT-RSA 2009 vorgestellt, Source Code in Java und C ebenfalls.
Ein weiterer Angriffspunkt sind die verwendeten Zufallszahlengeneratoren, die in allen untersuchten Geräten schlecht waren. Hier bietet sich ein weiterer Ansatz, die Verschlüsselung zu brechen