Mitternachtshacking

Seit jetzt, heute, Mitternacht gilt der neue § 202c StGB.

Bildnachweis: Chaos Computer Club

Marco Gehrcke gab in seinem Vortrag Online Search zu Beginn einen Überblick über die Diskussion zum Bundestrojaner, inzwischen Remote Forensic Software genannt, in den USA und in Deutschland. Interessant der Vergleich einer Hausdurchsuchung, die öffentlich erfolgen muss und einer Rechnerdurchsuchung, die geheim bleiben soll. Hier bestehen erhebliche verfassungsrechtliche Bedenken. Ich möchte die angesprochenen wichtigen Punkte nur mal in Stichwörtern zusammenfassen, es gibt genug Sekundärliteratur, die genauere Informationen liefert.

Begründung für den Trojaner:

• Verschlüsselung verhindert Strafverfolgung

Funktionen des Trojaner:

• Standort- bzw. IP-Adressbestimmung um Anonymisierungsdienste auszuschalten
• Aufzeichnung aller eingetippten Daten und gelesenen Dokumente
• Keylogger-Funktionen zum Auslesen von Passwörtern und Encryption Keys

Problem: Wie kommt der Trojaner auf den Rechner

• Installation vor Ort durch herkömmlichen Einbruch
• Definierte Schwachstellen durch die Betriebssystemhersteller

Gefahren:

• Zu wenig Ressourcen für die Polizei, um geeignete Software für alle Betriebssystem-Versionen zu entwickeln (OpenBSD-User sind immun?)
• Antivirus-Software erkennt die Remote Forensic Software nicht, Virenschreiber bauen auf diesen Funktionen auf
• Hintertüren im Betriebssystem können z.B. durch Kriminelle missbraucht werden
• Strafverfolgungsmöglichkeiten werden auf Bagatellstraftaten ausgedehnt (z.B. einfache Urheberrechtsverletzungen)
• Verletzung der staatlichen Souveränität bei grenzüberschreitenden Ermittlungen
• Durchsuchungen erfolgen heimlich (wie bei der Gestapo oder Stasi) und nicht mehr öffentlich wie das unser Grundgesetz fordert

Online Durchsuchungen verletzen elementare Grundrechte. Die notwendige Abwägung von Sicherheit gegenüber Freiheit scheint hier nicht erfolgt zu sein. Dazu gab es von Marco Gercke ein schönes Zitat: „Es ist nicht Aufgabe des Staates dafür zu sorgen, dass jedes noch so kleine Verbrechen effizient verfolgt werden kann.“

Was wäre die Alternative?

• Verbot anonymer Kommunikation
• Verbot von verschlüsselter Kommunikation

Gercke argumentierte nun, bevor diese Verbote kommen, sei eine gelegentlich stattfindende Online-Durchsuchung mit Richtervorbehalt das kleinere Übel. Ich denke hier genau umgekehrt. Die Online-Durchsuchung scheint von vielen, gerade technisch kaum versierten Mitbürgern akzeptiert zu werden, weil sie nicht verstehen worum es sich dabei handelt und vor allem, dass es sich um einen massiven Angriff auf die grundgesetzlich geschützten Bürger- und Freiheitsrechte handelt. Es steht zu befürchten, dass gerade auch durch die um Zuge des letzten G8-Gipfels in Heiligendamm erfolgte Ausweitung der Definition der „Terroristischen Vereinigung“ (§ 129a StGB) praktisch jeder Demonstrant unter Verdacht steht und damit heimlich durchsucht werden kann. In der ehemaligen DDR genügten dazu „Westkontakte“ in der Bundesrepublik zukünftig wohl „Demonstrationskontakte“. Ein Verbot von verschlüsselter Kommunikation würde jedoch auch der letzten Oma mit Internetbanking klar machen, dass hier etwas grundlegend verkehrt läuft. Der öffentliche Aufschrei würde folglich auch den sitzhaftesten Bundesinnenminister aus dem Amt rollen. Und das wäre dann das kleinstmögliche Übel.

Andreas Gietl berichtete über den Entwurf des neuen Telekommunikationsgesetzes und die Auswirkungen auf die Kommunikation. Die relevanten Gesetzesartikel sind:

§ 110 TKG-E

Enthält die Pflicht zur Speicherung von Kommunikationsdaten

§ 113a TKG-E

Enthält die diversen Regelungen zur Speicherung:

• Dienstanbieter muss für 6 Monate speichern
• DSL/Dialin-Anbieter müssen speichern
• WLAN-Anbieter wohl nicht, da es keine Teilnehmerkennung gibt
• Im Mobilfunk müssen IMSI, IMEI und Standortdaten gespeichert werden
• Bei E-Mail Kommunikation müssen Absender, Empfänger, IP-Adressen und jeder Abruf gespeichert werden
• Inhaltsdaten werden nach Abs. 8 nicht gespeichert
• Löschung einen Monat nach Ablauf der Speicherpflicht
• Anonymisierungsdienste werden praktisch verboten, da diese Dienste die Identitäten vor und nach der Anonymisierung speichern müssen
• Allerdings ist die Rechtsprechung nicht einig, ob Anonymisierungsdienste ein Telekommunikations- oder ein Mediendienst sind

§ 113b TKG-E

• Zweckbindung (Straftaten, erhebliche Gefahren, Nachrichtendienste)
• Zitiergebot

§ 110g StPO-E

• richterliche Anordnung
• bei erheblichen Straftaten

§ 161/163 StPO i.v.m. § 113 TKG

• Staatsanwaltliche Ermittlungen
• Beschränkt auf sowieso gespeicherte Daten
• Abgestufter Schutz, wenn Daten sowieso z.B. zu Abrechnungszwecken gespeichert werden dann ist das über den Staatsanwalt zulässig, für den Abruf der Daten aus § 113a TKG-E ist die richterliche Anordnung aus § 110g notwendig.

Die Vorratsdatenspeicherung widerspricht jedoch der Rechtsprechung des Bundesverfassungsgerichts zu Art. 10 GG (Volkszählungsurteil: Speicherung von persönlichen Daten ohne konkreten Zweck ist unzulässig). Die Bundesregierung versucht daher offensichtlich den Verfassungsverstoß über den Umweg einer EU-Richtlinie zu legitimieren. Bisher gibt es dazu die Solange-Urteile, die im Kern sagen, solange EU-Recht gleichen Rechtsstandards wie das Grundgesetz genügt, mischt sich das Bundesverfassungsgericht nicht ein. Die Vorratsdatenspeicherung könnte laut Gietl daher entweder ein Solange-3- oder ein JetztReichts-1-Urteil provozieren.

Ausgang: Unklar.

Weitere Informationen: www.andreas-gietl.de

Der Vortrag von Sergio ’shadown‘ Alvarez von n runs war irgendwie wieder so ein typischer n runs Vortrag wie auf dem Congress auch immer. Da wird ein aktuell relevantes Thema verwendet, dann etwas Forschung darum getrieben, die sicher gar nicht mal schlecht ist (Shadown hat über 80 Sicherheitsprobleme und Bugs an die diversen Virenscanner-Hersteller gemeldet) und dann wird für den CCC ein Vortrag zusammengestellt, der bestenfalls auf Management Niveau noch jemanden vom Hocker reißt, weil einfach gerade gar keine Details drin sind.

Sicher richtig ist, dass von Lücken in AV-Software rund 90% der Computer betroffen sind. Das ist nicht wenig. Andererseits ist es so, dass die AV-Hersteller eben auch eine sehr effektive Methode haben, über Updates der Scan-Engine auch die Fehler schnell zu beheben. Man vergleiche die täglichen Updates mit dem monatlichen Patchday von Microsoft.

Interessant fand ich gerade noch die Zusammenstellung der Mythen:

• AV-Software ist sicher
• AV-Software macht das Netzwerk sicherer
• AV-Software wird von Sicherheitsspezialisten entwickelt
• AV-Software verhindert alle Infektionen
• AV-Software entdeckt auch komplett unbekannte Viren

Die Realität ist eher:

• Sehr alte Viren werden oft nicht mehr entdeckt (richten aber auch keinen Schaden mehr an)
• Eine Reihe von Binary-Packern werden nicht erkannt
• Längst nicht alle Archiv-Formate werden erkannt (wenn auch alle wichtigen)
• Spezielle Funktionen in Archiv-Formaten sind nicht implementiert (z.B. gzip concatenation)

Die Probleme führt er auf folgende Hauptursachen zurück:

• Fest einprogrammierte Passwörter in Binaries (gut, kommt in den besten Familien vor)
• Fest einprogrammierte Verschlüsselungskeys in Binaries (kommt auch öfter mal vor)
• AdminConsole-Passwörter in Konfigurationsdateien (es gab da einen Fall von Trend Micro)
• Client Listener (das ist ein echter Knackpunkt)
• Null DACLs für Registry Settings, Config Files und Handles (auch das stimmt zu 100%)
• Schlechte Inputvalidierung (viele Integer-Fehler)
• Probleme mit großen Dateien >2GB
• Weit verbreitete Programme/Filetypen sind oft noch nicht enthalten
• Zu viele Formate, die ein Parser verstehen muss

Und dann gab es noch eine kurze Demo mit einem Fuzzer, bei dem er dann den Virenscanner zum Absturz gebracht hat. Cool … mit Fuzzing findet man also Virenscanner-Lücken. Das ist sooo neu, da braucht es gleich einen Month of the AV-Software Bug(MoAVSWB).

Fukami ist einfach gut. Der Vortrag über Testing und Exploiting Flash Applications war allererste Sahne. Am Anfang kurz die Grundlagen erklärt, dann typische Problemklassen beschrieben, die Sicherheitsrisiken an konkreten Beispielen vorgeführt und das alles so, dass der HighLevel-Betrachter verstehen konnte, dass Flash ein Problem sein kann aber gleichzeitig mit so vielen Details, dass mir jetzt auch klar ist, wo genau die Probleme sind.

1. Die Grundlagen

Von Flash gibt es eine Reihe von Generatoren, die Flash-Movies erzeugen können jedoch nur den offiziellen Player von Adobe, da keine weiteren Player erlaubt sind. Flash besteht aus einer Skriptsprache (ActionScript, aktuell ist v2 weit verbreitet und v3 kommt gerade mit neuen Funktionen). Flash ist u.a. für Audio/Video-Anwendungen sehr beliebt. Zu Flash kommt Flex dazu, eine SDK mit IDE, im Grunde besteht das aus Flash 9, Interface Libraries und einem Eclipse Plugin. AIR ist die Adobe Integrated Runtime für Desktop-Anwendungen. Bereits wenn man an dieser Stelle auf Flash guckt, fallen ein paar gefährliche Eigenschaften auf: Flash kann HTTP Request Forgery, kann JavaScript, … äh

2. Die Sicherheit

Flash hat seit Version 7 ein Security Modell, das hauptsächlich auf der „Same Origin Policy“ basiert. In Version 8 und 9 wurde das Modell vereinfacht, aber auch ein Player Version 9 wendet die alte Policy an, wenn ein Flash Version 7 Movie abläuft. Darüber hinaus gibt es in Flash einen Persistent Local Datastore für Shared Objects. Da kann der Flash-Movie beliebige Daten hereinlegen, maximal jedoch 100 KB. Die Daten haben kein Expiration Date, sind nicht einfach löschbar und auf einigen Plattformen sogar Cross-Browser erhalten. Damit hat man schon einen krass permanenten Speicher, wenn man einen Webseitenbesucher wieder identifizieren will.

3. Die Angriffe

Das fängt schon mal an mit Local Connection Objects die verwendet werden, damit zwei Flash-Movies miteinander Nachrichten austauschen können. Die Nachrichten werden nicht gefiltert, da kann mal also sehr gut XSS oder JavaScript durchschleusen. Und Flash kann ja bekanntlich Javascript. Lustig ist es auch mit den Variablen. Für uninitialisierte Variablen gilt in etwa das gleiche wie bei PHP mit register globals. Da man Variablen über die URL, FlashVar oder localVars.AS-Objekt übergeben kann, ist jede uninitialisierte globale Variable eine potentielle Gefahr. Die Sandbox in der Flash abläuft ist zwar ganz sinnvoll, aber weitgehend beschränkt auf die Same Origin (FQDN) Policy sowie eine Cross Domain Policy, die als XML-File geladen werden kann.

4. Client Side Attacks

Auf Client-Seite ist vieles möglich, XSS, XSF (Cross Side Flashing), Mass Exploits, Backdoors und vieles mehr. Die Funktion getURL() in ASv2 erlaubt beispielsweise JavaScript- und DOM-Aufrufe. Fukami spricht hier von PDNF (Potentially Dangerous Native Function). Außerdem gibt es HTML in Flash (HTML-Injection beispielsweise durch das CreateTextField oder den Anchor-Tag), dafür muss die Anwendung aber als Flash 7 kompiliert werden.

5. ActionScript v3

Noch viel lustiger wird es mit ActionScript Version 3, da gibt es lustige neue Funktionen. Auf jumperz.net gibt es einen in Flash programmierten Portscanner, der vom Client aus die IP-Adresse 127.0.0.1 scannt. Die Gefahr von Socket-Operationen sollte eigentlich bekannt sein, JavaScript verzichtet aus gutem Grund darauf.

6. Tools

• Flare – Decompiler
• MTASC – Compilter
• Flasm – Disassembler
• SWFmill – SWF/XML-Converter
• Debugger-Version des Flash Players
• SWFTools – Programme zur SWF-Manipulation, z.B. swfcombine
• haXe – ASv2/v3-Compiler

7. Neue Lücken

Neue Lücken werden kommen, beispielsweise:

• RTMP/AMF buffer overflows
• Data handling Fehler für Media Server / Plugins
• Breaking the Sandbox
• ASv3 Decompiler / Source Code Analyzer
• RTMP/AMF Proxy/Fuzzer
• DNS Rebinding

8. Weitere Informationen

www.flashsec.org

Zusammenfassend ein richtig klasse Vortrag mit coolen wenig bekannten Informationen.

Der Vortrag von Nibbler war ein reiner und sehr kurzer Grundlagenvortrag. Im Grunde wurden hauptsächlich die ganzen Protokolle von SS7 vorgestellt und kaum weitergehende Informationen geboten obwohl Nibbler den Eindruck hinterlassen hat, mehr zu wissen. Verglichen mit dem Internet ist das in etwa so, wie wenn man erwähnt, dass es die Protokolle IP, TCP und UDP gibt, außerdem die TCP-Protokolle HTTP, SMTP und FTP sowie die UDP-Protokolle DNS und NTP. Aha. Ein nicht informierter kann mit dieser Information praktisch nichts anfangen, ein Eingeweihter langweilt sich.

In Folge sind daher auch eine Reihe von Leuten bereits während des Vortrags gegangen und es gab kaum weitere Nachfragen zum Thema. Dabei wäre das vielleicht gar nicht so langweilig, da könnte man mehr daraus machen. Harald Welte entwickelt beispielsweise an einem OpenSource Mobiltelefon, die Kenntnisse über SS7 sind da durchaus hilfreich, um zu verstehen was an der GSM-Schnittstelle passiert. Das iPhone wird sukzessive gehackt, auch wenn das längst nicht so schnell geht, wie sich einige das erhofft haben. Auch hier ist grundlegendes Wissen über SS7 und GSM anscheinend hilfreich.

Zu den Inhalten: Im Gegensatz zu vorherigen Verfahren wie CCITT#5 ist das Signalisierungsverfahren Signalling System 7 (kurz SS7) ein Out of Band Verfahren, das daher von den Endgeräten kaum noch anzugreifen ist. Schwerpunkte in der Entwicklung waren Verlässlichkeit (Reliability bzgl. Nutzererfahrung und Billing) sowie die internationale Standardisierung. Die wichtigsten Komponenten sind SSP (Service Switching Point), STP (Signal Transfer Point) und SCP (Service Control Point). Die einzelnen Punkte sind via A- (Access), B- (Bridge bzw. Diagonale), C- (Cross), E- (Extended) oder F-Links (Fully Associated) miteinander verbunden, die jeweils unterschiedliche Aufgaben erfüllen. Als Layer 1 Protokoll kommt G.703 zum Einsatz, die interessanten Protokollfunktionen befinden sich auf den Layer 2 Signal Units. Die wichtigsten Units wurden angesprochen, u.a. ISUP, OMAP, SCCP und TCAP. Dieser Teil ging aber kaum über die Informationen hinaus, die auch bei Wikipedia zu finden sind.

Zusammenfassend … auch wenn das Thema vielversprechend ist, den Vortrag fand ich zu langweilig und trocken.

Der Chaos Computer Club veranstaltet sein alle paar Jahre stattfindendes Camp zur Zeit auf dem ehemaligen Militärflugplatz und jetzigen Museumsgelände in Finowfurt, etwa 60 km nördlich von Berlin an der A11 Richtung Stettin gelegen. In der Gegend bin ich gelegentlich und da ich nicht weit weg günstig übernachten kann, bietet es sich an, das Camp in diesem Jahr zu besuchen. Die Vortragsthemen sind zwar nicht ganz so spannend wie auf dem jährlichen Congress aber ein paar Vorträge dürften wertvoll genug sein, um die Reise zu rechtfertigen.

Das Camp ist gar nicht so einfach zu finden. In Finowfurt von der Ausfahrt Richtung Stadt, dann dem Schild zum Flugzeugmuseum folgen und dann immer gerade aus in den Wald. Irgendwo steht dann ein Aufpasser vom CCC der die Leute auf den Parkplatz lotst, damit die nicht direkt auf den Flughafen draufbrettern.

Das Gelände selbst ist im Grunde ein großes Freilichtmuseum mit diversen alten Flugzeugen aus der ehemaligen DDR und der früheren Sowjetunion. Die Vorträge finden in den ehemaligen Bunkerhangars statt, da ist es wenigstens schön kühl. Davor stehen die Zelte und Wohnmobile der Teilnehmer. Die meisten liegen faul unter Schutzplanen oder im Schatten der alten Militärflieger. Das hat schon was lässiges, so mit dem Notebook unter einem Flieger und wireless im Internet surfen. Nur mit dem Strom ist es ein wenig knifflig.

Den Tag gestern habe ich leider verpasst, da war ein wichtiger Kundentermin. Aber heute ist Action angesagt. Zu den Vorträgen schreibe ich noch eigene Beiträge.

Bildnachweis: Diese Bilder sind frei verwendbar, unter Nennung der Quelle: BerlinVR.de

Immunity hat einen Debugger veröffentlicht, der den Schwerpunkt auf die schnelle und effiziente Entwicklung von Exploits legt. Aus der Webseite:

• A debugger with functionality designed specifically for the security industry
• Cuts exploit development time by 50%
• Simple, understandable interfaces
• Robust and powerful scripting language for automating intelligent debugging
• Lightweight and fast debugging to prevent corruption during complex analysis
• Connectivity to fuzzers and exploit development tools

Ob der so toll ist, wird sich zeigen. Immunity ist schon immer recht gut im Marketing gewesen. Fefe hat dazu ja auch eine eigene Meinung.

Jedenfalls gibt es das Tool for free und ankucken kostet nichts (außer Zeit).

Jesse Ruderman von der Mozilla Foundation hat eine Reihe von Fuzzern zur Prüfung von Webbrowsern veröffentlicht, schreibt Heise. Die beiden Tools jsparsefuzz.js und jsfunfuzz.js erzeugen fehlerhaftes Javascript und können damit potentielle Sicherheitslücken aufdecken. Im Grunde nichts neues, Fuzzer für Webbrowser gibt es eine Reihe, beispielsweise die Browser Crash Test Suite von JdM.

Erstaunlich ist eher, dass Mozilla nicht früher selbst aktiv geworden ist sondern lange Zeit das Feld anderen überlassen hat. Von HD Moore, Michal Zalewski und eben JdM gibt es schon seit geraumer Zeit Fuzzer für Browser und bisher waren die Browser-Hersteller immer in der defensive. Das kann sich vielleicht nun ändern.

Im Grunde bestätigt das aber nur meine Meinung vom Juli. Browser Fuzzing ist kein relevanter Security Markt mehr. Die Fuzzer für Netzwerkprotokolle finde ich viel spannender. Bei VoIP und VPN geht bestimmt noch was. Und nicht zu vergessen, Milosch Meriac braucht dringend jemanden, der einen RFID-Fuzzer programmiert. Da geht noch viel!

War eigentlich klar.

Ich frage mich ja, ob man analog zur Versteigerungsplattform von WabiLabiSabi eine Plattform zum Verkauf von Viren, Trojanern und Botnetzen einrichten könnte. Oder wird das durch den § 202c illegal?