Archiv der Kategorie: IT-Sicherheit

Verwundbarkeiten beim Autoupdate

Hallo zusammen,

derzeit scheinen Audits von automatischen Update-Funktionen (wieder) hoch im Kurs zu sein. So aktuell auf heise.de zu Keepass 2. Auch ASUS-Geräte ziehen ihre Updates über unverschlüsselte HTTP-Verbindungen. Vor wenigen Tagen fand man auch etwas bei Lenovo-Geräten auf golem.de – wobei Lenovo bzgl. unsicherer Bloatware häufiger in der Kritik steht. Die Frage ist, woher diese Probleme stammen.

Eine unverschlüsselte Verbindung ist auf den ersten Blick nicht zu entschuldigen, denn immerhin werden hier Daten übertragen, die bzgl. ihrer Integrität geschützt werden müssen. Viele Security Consultants werden in so einem Fall empfehlen, man soll (einfach!) mittels SSL/TLS die Verbindung schützen, das Zertifikat (Signatur, Common Name, etc.) innerhalb der Applikation auf Gültigkeit prüfen und nur über eine solch geschützte Verbindung das Update beziehen. Damit hat man sowohl Vertraulichkeit als auch Integrität erschlagen. Anschließend werden die Findings im Audit-Bericht von rot auf grün gesetzt und eine Rechnung geschrieben. Während der Umsetzung wird man jedoch schnell merken, dass es doch nicht so einfach ist.

Ist SSL/TLS erstmal aktiviert muss man sich nämlich der Frage stellen, welche Settings beim Web-Server eingestellt werden. Je restriktiver und damit „sicherer“ ich diese Konfiguration vornehme, desto eher nehme ich Inkompatibilitäten mit alten Browsern in Kauf. Sind die Settings „zu stark“, schließe ich Clients aus und sind sie „zu lasch“, ruft dies wieder Kritiker hervor. Ein Beispiel ist z.B. Perfect Forward Secrecy was bei Windows XP-Nutzern zu Problemen führen kann. Auf ssllabs.com (wer möchte, kann dies z.B. mit „https://webtracking.org“ testen) können diese Settings geprüft werden und man erhält im Anschluss ein Rating. Dabei werden auch Verbindungstests mit Clients durchgeführt und zeigt, welche Betriebssystem/Browser-Kombinationen mit den aktuellen Settings ausgeschlossen werden. Natürlich muss diese Abwängung stets durchgeführt werden, wenn man eine Webseite im Internet anbietet. Allerdings kann man hier ggf. auch einen HTTP-Fallback bereitstellen. Dies ist im Autoupdate-Fall nicht möglich.

Die Software kann natürlich mit allen notwendigen Software-Librarys ausgeliefert werden, damit ein „immer funktionieren“ garantiert ist. Aber ob es tatsächlich wünschenswert ist, dass jede Kleinstanwendung Bibliotheken für einen SSL-fähigen Webclient beinhaltet ist sehr fraglich. Denn so müsste die Anwendung auch für alle Sicherheitslücken in diesen Librarys aktualisiert werden. Das zieht einen riesigen Rattenschwanz hinter sich her.

Noch schwieriger ist die Überprüfung des Zertifikates. Entweder man verlässt sich hierbei auf die PKI oder man führt eine manuelle Überprüfung des Fingerprints durch. Die Nutzung der PKI hat den Vorteil, dass ich nur (einem oder mehreren) Wurzelzertifikat(en) vertraue und so jederzeit ein neues Zertifikat ausgestellt werden kann. Der Nachteil ist, dass andere dies ggf. ebenfalls können: ich also gezwungen bin, der organisatorischen Sicherheit einer PKI zu vertrauen. Ein manueller Fingerprintvergleich führt zu dem Problem, dass sobald das eigene Zertifikat kompromittiert oder verloren ist, die Anwendung manuell aktualisiert werden müsste.

Eins ist sicher: Viel kritischer als ein fehlendes Update-Verfahren ist ein implementiertes, dass nicht (mehr) funktioniert. Und auch wenn der Einsatz von HTTPS mittlerweile ein Standard ist, führt es leicht zu unvorhersehbaren Problemen, die man vorher nur aufwendig testen kann. Bei so einem wichtigen Mechanismus möchte man jedoch nur ungern Fehler riskieren.

Der Beitrag soll NICHT den Eindruck vermitteln, diese Probleme wären nicht lösbar. Es soll nur zeigen, dass es keine ganz einfache Lösung gibt bzw. solche Systeme denkintensiver sind, als sie auf den ersten Blick scheinen. Alternative Verfahren, z.B. Softwaresignaturen, bleiben an dieser Stelle mal out of scope.

Hinweis: Dieser Webauftritt bietet aktuell noch kein HTTPS an. Da weder Cookies verteilt, noch ein Login angeboten wird, gab es bis zum heutigen Tage auch noch keinen Grund für einen solchen Schutz der Vertraulichkeit. Trotzdem soll dies in naher Zukunft geändert werden.

 

NICHT(kein-APT) im Bundestag

Hallo zusammen,

was macht man an einem Feiertag mit schönem Wetter üblicherweise? Richtig, man sieht sich den vom BSI veröffentlichten Bericht zur Lage der IT-Sicherheit in Deutschland 2015 an! Man muss vorab schon mal sagen, dass der Bericht sehr schön ausgestaltet ist – sowohl optisch, als auch inhaltlich.

Mein persönliches Highlight war der Abschnitt über den Cyber-Angriff auf den Deutschen Bundestag. Nach der Aussage im Dokument wurde dabei nach der „klassischen APT-Methode“ vorgegangen. APT (Advanced Persistent Threat) ist ein Sammelbegriff für professionelle/gezielte Angriffe. Es gibt jedoch keine klare Abgrenzung zu „einfachen“ Angriffen, sondern wird eher über Beispiele definiert: Stuxnet war ein APT – eine Ransomware im Krankenhaus ist kein APT. Durch diese Verknüpfung mit besonders kritischen Beispielen zuckt jeder IT-Verantwortliche innerlich zusammen, wenn er von einem APT hört.

Das Vorgehen der Angreifer wird auf Seite 26 beschrieben und kann so zusammengefasst werden:

  • Einzelne Arbeitsplatzrechner wurden infiziert.
  • Tools wurden nachgeladen.
  • Backdoors wurden installiert, sowie weitere Schadprogramme und Keylogger.
  • E-Mail-Postfächer wurden sich angesehen.

Mit anderen Worten: Ein Angreifer erlangt unberechtigt Zugriff, installiert sich weitere Software auf dem System und schaut anschließend was es noch alles gibt.

Man kann natürlich nicht widerlegen, dass es ein gezielter Angriff sein könnte. Ich bezweifle nur ein wenig die Argumentation dafür im Dokument, Zitat:

„Bei der Ausbreitung im internen Netz („Lateral Movement“) setzen die Angreifer auf gängige Methoden und öffentlich verfügbare Tools, wie sie auch von weniger professionellen Tätern verwendet werden. Dies kann dadurch begründet sein, dass man eine Zuordnung des Angriffs erschweren wollte.“

Es war also deshalb ein APT, weil es nicht aussieht wie ein APT. Gut, die Informationen sind hier auch sehr knapp gehalten. Aber ich habe trotzdem die Spur eines Verdachts, dass hier auch politischen Gründe im Spiel waren: Da einfache Angriffe auf einer so kritischen Infrastruktur ja grundsätzlich ausgeschlossen sind, muss es ein professioneller gewesen sein.

Weiteres aus dem Bericht FYI:

  • Schwachstellen. Abbildung 2 (Seite 10) zeigt eine Auflistung von verbreiteten Softwareprodukten und deren Schwachstellen im Jahr 2015. Wenig überraschend ist Flash mal wieder auf Platz 1. Platz 9 wird euch sicher überraschen … Java. Aus der Hardware-Ecke wird ein Angriff vom Juli 2015 beschrieben, welche über ein USB-Stick eine Fernsteuerung des Rechners durch das Intel-Management-System (vPro) ermöglicht.
  • Kryptographie. Hier gab es im Jahr 2015 wohl wenig Neues (zumindest aus Sicht des BSI). Erwähnt werden die Angriffe FREAK (SSL/TLS) und Logjam.
  • Ransomware im Krankenhaus. Das kennen wir natürlich schon. Immerhin wird der Angriff, wie von mir auch, als „heute Alltag“ eingestuft. Das Wort „Cyber-Kriminelle“ hätte man sich jedoch auch sparen können.
  • Social Engineering per Telefon. Auch in meinem erweiterten Bekanntenkreis ist jemand Opfer von einem „Microsoftmitarbeiter“ geworden, der den naiven Nutzer zur Installation von Fernwartungssoftware aufgefordert hat.
  • Statistiken zu Spam und Botnetzen.
  • Eine Drive-by-Exploit Übersicht (Abbildung 10, Seite 32) hat mir sehr gut gefallen. Es zeigt in einer Zeitleiste die kritischen Exploits und die ausgenutzte Schwachstelle (CVE).
  • Außerdem gibt es noch einen Ausflug ins neue IT-Sicherheitsgesetz, welches seit Mitte 2015 in Kraft ist.

Es gibt jedoch noch mehr, mal drüberblättern lohnt sich auf jeden Fall.

 

Virenanfälligkeit

Hallo zusammen,

soziale Netzwerke sind ein endloser Quell der Freude:

[BLOG] 8 wichtige Gründe, warum du Java lernen solltest. → Nr. 6 wird dich überraschen

[…]

6) Durch die Programmierung in Bytecode ist Java weniger Virenanfällig

Java-Programme können vor der Ausführung verifiziert werden, da sie keine Zeiger haben und in Bytecode vorliegen. Die Verifizierung wird von Web-Browsern benutzt, um sicherzustellen, dass keine Viren enthalten sind. Java verwendet nicht Adressen aus Zahlen, sondern Namen für Funktionen und Methoden, die leicht überprüft werden können. So kann kein Java -Applet etwas ausführen oder auf etwas zugreifen, was nicht ausdrücklich im Verifizierungsprozess definiert worden ist.

Quelle: http://www.javavideokurs.de/blog/8-gruende-warum-du-java-lernen-solltest-336/

Es stimmt, 6 hat mich überrascht. Wenn man sich anschaut, dass die Java SRE allein 2016 auf sechs 10er CVE-Ratings gekommen ist, ist das schon sehr bezeichnend. Für die, die es nicht kennen: die Skala beschreibt die Schwere der Verwundbarkeit mit einer Zahl zwischen 1.0 (unbedeutend) und 10.0 (katastrophal).

Es ist zwar schon richtig, dass seit Java 7u51 das Applet gültig signiert sein muss. Aber wenn die darunterliegende Sandbox kompromitiert ist, kann man sich das natürlich sparen. Nicht umsonst bleibt in Browsern wie Firefox das Java-Plugin deaktiviert bis es wirklich gebraucht wird. Außerdem war es noch nie ein Problem an „irgendein“ gültiges Zertifikate zu kommen – man ist ja hier nicht auf ein bestimmtes angewiesen. Sowas kennen wir auch schon aus dem Hause Microsoft.

Es gibt ganz sicher gute Gründe Java zu lernen, die Security würde ich dabei jedoch nicht anführen.

 

Peer to Peer – Sicherheit

Hallo zusammen,

vor Kurzem ist in einem Spieleforum die Frage aufgekommen, wie es mit der Sicherheit von Peer-to-Peer Systemen aussieht. Vermutlich werden jetzt viele Leser an die juristischen Folgen durch, populär ausgedrückt, „illegale Downloads“ denken. Damit soll sich dieser Beitrag allerdings nicht befassen. Außerdem muss auch die Frage geklärt werden, wieso sich ein „Spieler“, eine möglicherweise leicht Klieschee behaftete Gruppe, dafür interessiert.

Insbesondere MMORPGs zeichnen sich durch einen sehr dynamischen Inhalt aus, was für viele einen Reiz darstellt, eine beachtliche Menge an Zeit zu investieren. Dies erfordert jedoch einen permanenten Aktualisierungsvorgang aller Clients. Viele „Kleinigkeiten“, wie Art/Position/Verhalten von s.g. NPCs können durchaus „on the fly“ dem Spieler mitgeteilt werden. Umfangreichere Änderungen, insbesondere neue Grafiken, erfordern jedoch eine Änderung des Programms bzw. der verwendeten Bibliotheken. Hiervon soll allerdings der Spieler möglichst wenig betroffen sein – insbesondere soll er nicht gezwungen sein auf dubiosen Webseiten die Patches zu laden und dann auf dem jeweiligen Rechner zu installieren. Jedoch ein Client-Server Modell, bei dem ein Server die Daten für alle Clients bereitstellt, ist nur für geringe Benutzerzahlen praktikabel. So bedeutet ein 100 MB Update, was durchaus nicht selten ist, bei 100.000 Spielern nunmal 10.000.000 MB Traffic, also 10 TB. An dieser Stelle sei noch anzumerken, dass es durchaus Spiele mit 5-10 Millionen aktiven Spieler gibt. Außerdem besteht ein betriebswirtschaftliches Interesse, die Kosten solcher Prozesse möglichst gering zu halten.

Was also tun? Das Thema liefert die Antwort: Peer to Peer Netzwerke, kurz P2P. Wie funktioniert das?
Nunja, viele leichtverständliche Informationen findet man auf einschlägigen Webseiten. Ich möchte an dieser Stelle insbesondere auf das P2P Netz eingehen, welches überwiegend beim Filesharing eingesetzt wird. Auch wenn „Filesharing“, „Peer to Peer“, etc. vielen Lesern die roten Alarmglocken schlagen lässt: es ist eine Technik, die von vielen Unternehmen eingesetzt wird und daran ist überhaupt nichts Illegal. Sie eignet sich allerdings auch zum Tausch von geschütztem Material wodurch sie häufig in einen falschen Zusammenhang gesetzt wird. Um dieses System in kurzen Worten zu erklären, möchte ich mich der Schneeball-Metapher bedienen:

Durch umfangreiche Aufklärungsarbeit der öffentlich rechtlichen Funk und Fernsehanstalten sollte vielen Lesern bekannt sein, wie ein Schneeballsystem (oder ein Kettenbrief) funktioniert. Wir definieren eine Person, die ein Produkt an eine Reihe von Personen anbietet und nennen diesen Tracker. Diese Reihe von Personen bemühen sich, aus eigenem Interesse, möglichst viele weitere Personen für dieses Produkt zu gewinnen. Wir bezeichnen alle Personen, die daran interessiert sind, als Schwarm. Angenommen jeder Teilnehmer gibt das Produkt (oder die Information) nur an zwei Andere weiter, haben wir nach 30 Schritten schon eine Schwarmgröße von 1.073.741.823 (2^30-1). Der Aufwand für den Einzelnen, 2 weitere zu „finden“ bzw. zu bedienen, war relativ gering – in der Gesamtheit war das Produkt jedoch ein riesen Erfolg.

Als Informatiker möchte ich jedoch an dieser Stelle anmerken, dass es sich hierbei um einen Baum der Ordnung 2 handelt – hingegen ein P2P System als ein Multigraph anzusehen ist. Übertragen auf das „Updateproblem“: der Tracker wirft den Patch also in die Menge (den Schwarm) und die Spieler organisieren sich untereinander diesen zu verteilen. Also läd man, bei diesem Vorgang, nicht vom offiziellen Server, sondern von Personen „wie dich und mich“ – jedoch natürlich nur von den Beteiligten.

Nun zurück zu dem besorgten Spieler. Grundsätzlich handelt es sich hierbei auch um Programmaktualisierungen. D.h. der Programmcode wird entweder ersetzt oder Neuer wird eingefügt – je nach Updatestrategie. Ein Beweis hierfür ist auch leicht erbracht: Updater sind immer „extra“ Programme, also kein Unterprozess. So findet sich in dem entsprechenden Spielordner stets das Spiel selbst, als auch ein Updater als ausführbare (exe) Datei.

Und daher nun endlich die Frage: Können mir andere Spieler „Schadcode“ übergeben, der sich dann, durch den Updatevorgang, auf meinem Rechner befindet?

Damit habe ich mich etwas Näher befasst. Zunächst muss natürlich klar sein, dass diese Frage nicht für alle Spiele geklärt werden kann. Grundsätzlich werden Daten von unbekannten Quellen geladen und diese können durchaus Fehlerhaft sein – gewollt oder ungewollt. Das ist die schlechte Nachricht. Die Gute ist, dass sich viele Spielebetreiber Techniken bedienen, die sich mittlerweile als Standard etabliert haben. Das relativ bekannte „BitTorrent“ Protokoll ist eines dieser – wofür es auch sehr viele und gute Clients gibt. Bei dieser Technik erhält der Client ein File genannt „Torrentfile“. Dieses enthält eine Auflistung der Dateien, die geladen und verteilt werden müssen – zusätzlich weitere triviale Informationen.
Am Ende, das lässt uns wieder aufatmen, ein SHA-1 Hash für jeden Part. Wer mag, kann an dieser Stelle einen Exkurs zum aktuellen Stand der Technik bzgl. der Sicherheit des SHA-1 unternehmen.

~

Wieder zurück? Gut. Denn selbst wenn wir ein Programm hätten, das uns „günstig“ Kollisionen des SHA1 aufzeigt, wäre es sehr unwahrscheinlich, dass dabei ein Teil eines ausfühbaren Programmes herauskommt und gleichzeitig auch den gewollten Schadcode enthält. Diese Thematik lässt sicherlich Platz für Diskussionen – allerdings kann an dieser Stelle und an diesem Tag festgehalten werden, dass der SHA-1 Hashalgorithmus für diesen Einsatzzweck noch völlig genügt. Was ein Hashcode „genau“ ist, habe ich in diesem Beitrag beschrieben: http://cryptblog.de/2008/06/18/hacken-fur-anfanger/

Es besteht also keinen Anlass zur Beunruhigung. Sofern der Tracker das Torrentfile korrekt an den Benutzer überträgt, ist ein P2P System (basierend auf BitTorrent), für diesen Einsatzzweck ausreichend sicher.

ITS-Quiz für Zwischendurch

Hallo,

es handelt es sich um Protokollsicherheit in Verbindung mit asymmetrischer Verschlüsselung. In diesem Szenario möchte die Partei A eine geheime Information an Partei B senden. A besitzt den geheimen Schlüssel zum öffentlichen Schlüssel PK_A, und B äquivalent PK_B. Hierbei wird folgendes Protokoll verwendet:

(1) A –> B:     (A, E(PK_B, A|M), B)
(2) B –> A:     (B, E(PK_A, A|M), A)

also: (Absender, Nachricht, Empfänger) wobei Nachricht = Absender|Information.

Schritt für Schritt: A sendet an B eine Nachricht, diese besteht aus

  • dem Absender (A),
  • dem asymmetrisch verschlüsselten Text M wobei dieser noch mit  und dem Absender verbunden wurde (A|M),
  • dem Empfänger (B).

daraufhin bestätigt B den Erhalt der Nachricht durch:

  • den Empfänger (B),
  • die exakt identische Nachricht, diesmal allerdings mit dem öffentlichen Schlüssel des ursprünglichen Absenders – also des neuen Empfängers (PK_A) verschlüsselt,
  • den Absender der usprünglichen Nachricht (A).

E(PK_X, M) ist die asymmetrische Verschlüsselung, z.B. RSA, mit Hilfe des öffentlichen Schlüssels X, im obrigen Beispiel also jeweils des Empfängers. Das Ganze etwas anders ausgedrückt: Die Partei A sendet eine Nachricht an B, wobei diese mit dem öffentlichen Schlüssel des Empfängers verschlüsselt wurde und außerdem auch den Absender enthält.

Im Zuge einer Umstellung wurde das Protokoll abgeändert auf:

A –> B:     (A, E(PK_B, M), B)
B –> A:     (B, E(PK_A, M), A)  (Bestätigung)

Der Unterschied: der Absender ist hier nun nicht mehr innerhalb der verschlüsselten Nachricht enthalten.

Frage: ergibt sich daraus ein Problem? Wo ist der Unterschied bzw. gibt es überhaupt einen?

„Sicher im Internet“

Ich möchte an dieser Stelle  nur kurz auf den neuen Bereich „Sicher im Internet“ hinweisen.  Es handelt sich dabei um einen Teil meiner Abschlussarbeit. 

Im Laufe der zunehmenden Verbreitung des Internetzugangs sind Anwender häufig damit überfordert die Gefahren richtig einzuschätzen, die im Umgang mit den neuen Medien entstehen können. Die Anzahl der Internetnutzer – sowohl geschäftlich als auch privat –  steigt kontinuierlich. Im Mai 2007 wurde festgestellt, dass bereits jeder 5. Mensch (1,23 Milliarden) daran teilnimmt.

Nach Untersuchungen des Antivirus-Herstellers „Kaspersky Lab“ ist jeder zehnte PC Teil eines Bot-Netzwerkes. Die Ursache liegt häufig in Fehleinschätzungen von E-Mail Dateianhängen oder heruntergeladenen Dateien aus dem Internet. Nur in seltenen Fällen sind sog. Exploits die Ursache, bei denen der Anwender keine Mitschuld trägt.

Probleme dieser Art lassen sich häufig schon durch Aufklärung vermeiden oder zumindest eindämmen. Informationsmaterial zu dem Thema PC–Sicherheit, welches auch für Laien verständlich und leicht zugänglich ist, soll dem Benutzer helfen Gefahren rechtzeitig zu erkennen. Innerhalb der Abschlussarbeit wurden verschiedene Gefahrenquellen analysiert und in geeigneter Weise aufgearbeitet.
Eine Quiz soll u. A. zur Wissensvermittlung dienen.

 >>> Hier geht es zum Quiz

DLC-Container

Zur Abwechslung mal wieder etwas aus der Praxis. Heute geht es um die mittlerweile verbreiteten DLC-Container. Für die Leute, die damit nichts anfangen können, zunächst eine Zusammenfassung.

Dieses System wurde entwickelt, um Links zu verschlüsseln bzw zu verdecken. Die Benutzer sollen fähig sein, Daten von Servern herunter zu laden, ohne sehen zu können wo diese nun genau liegen. Also eine Containerdatei die Text (Linklisten) enthält, aber nicht von dem Benutzer – zumindest nicht auf einfache Art und Weise – eingesehen werden soll. Der Sinn bzw. Zeck kann von jedem selbst nachgeforscht werden.

Etwas nicht sehen dürfen? Also eine Verschlüsselung. Die Frage ist allerdings, wie hält man etwas vor dem Benutzer geheim, welcher den Inhalt allerdings selbst benötigt. Kurz gesagt: das geht natürlich in der elektronischen Welt nicht. Es ist z.B. durch einen modifizierten Proxy oder das Mitschneiden des Netzwerkverkehrs trotzdem möglich die Links zu erhalten. Die Frage, die allerdings nun hier beantwortet werden soll: „ergibt das Ganze dann noch Sinn?“. Und die Antwort darauf ist erstaunlicherweise: Ja.

Zunächst wollen wir uns Schritt für Schritt dem System nähern. An dieser Stelle muss ich sagen, das obwohl dieses eigentlich Open Source und „Dokumentiert“ ist, es keine wirklich brauchbaren Informationen darüber gibt wie es umgesetzt wurde. Wahrscheinlich um zu verhindern das jemand Schwachstellen findet, wie es bei ähnlichen Systemen geschehen ist. So musste ich ziemlich alles selbst erarbeiten, allerdings denke ich, das meine Argumentation schlüssig ist.

Zuerst war das Wort.. oder die Datei. In diesem Fall der DLC-Container, welchen ich über ein Webinterface der Herstellerseite erstellt habe. Im Cryptool betrachte ich den Inhalt:

dlcbase641

Nun, dies ist offensichtlich kodiert. Ja – kodiert und nein, das ist (bisher) keine Verschlüsselung. Es handelt sich um die Base64 Kodierung, welche häufig in Protokollen oder beim Übertragen chiffrierter Daten verwendet wird. Informationen darüber finden sich an jeder Ecke; an dieser Stelle genügt es zu sagen, das wir diese verlustfrei dekodieren können:

dlcclear1

Auf den ersten Blick sieht es tatsächlich so aus, als ob es uns nichts Neues gebracht hätte.  Dann betrachten wir das Ende dieser Datei etwas genauer:

dlcclearend

Was ist hier zu sehen? Zunächst unlesbarer Text bei welchem es sich offensichtlich um verschlüsselten Inhalt handelt, dann ein Nullbyte (0000 0000), und dann, sehr unerwartet, erneut ein Base64. Dieser kann nun erneut dekodiert werden, wobei sich daraus (ähnlich wie oben) lediglich unlesbarer Inhalt ergibt.

Was ist das alles nun? Naja, im oberen Teil befinden sich offensichtlich die Hauptinformationen. Wie eine Signatur liegt dort nun eingebettet eine Zeichenkette, die Besonders zu sein scheint. Nun ist die Frage was man damit machen kann. Zuerst war die Vermutung das es sich dabei um ein asymmetrisch verschlüsseltes Passwort handelt. Allerdings müssten dann die Informationen zum dechiffrieren hartkodiert im Quelltext vorliegen womit das System (insbesondere bei einer Java Anwendung) sehr schnell geknackt wäre.

Nach längerem überlegen kam ich zu dem Entschluss, das es also nur 2 Möglichkeiten gibt: die Sache ist einfach nur sehr oberflächlich und daher „simpel“, oder wirklich clever. Vorweg, ich musste erfahren das letzteres zutrifft.

Um diesem Problem nun gegenüber zu treten, habe ich den verursachten Traffic der Anwendung mitgeschnitten: also mir angeschaut was das Programm von meinem Computer aus ins Internet sendet. Und siehe da, dort war die Lösung. Und zwar gibt es beim Verarbeiten der DLC-Datei einen Datenaustausch zwischen einem Server und der Anwendung. Zuerst schickt das Programm eine Anfrage an den Server, welcher wiederrum antwortet. Und was dort uA gesendet wird ist hier zu sehen:

etherreal

Erneut wird im Base64 eine Zeichenkette über den Äther geschickt. An dieser Stelle war ich der Verzweiflung nahe, da es sich hierbei erneut um einen String handelt, den ich vorher noch nicht gesehen hatte. Wieder stand ich vor einem Problem, dessen Lösung allerdings recht einfach war:

mitschnittbase641

Und zwar ist das die Base64 Zeichenkette aus der DLC-Datei, erneut in einen Base64 eingepackt. Dies ergibt eigentlich keinen Sinn und scheint eher ein „Fehler“ zu sein bzw. Faulheit der Programmierer. Egal, es ist nun nachgewiesen das diese „besondere“ Signatur zum Server gesendet wird. Nach dieser Anfrage, antwortet der Server mit einer Base64 Zeichenkette (FVZ+8D1u+4Tey+5pSkwNP+SgUTaGXGlRt8kMywjdEkM=), die ich schonmal für uns im Cryptool ausgepackt habe:

passwort

Damit ist der Beweis erbracht. In der Datei ist eine Zeichkette enthalten, die nur vom Server entschlüsselt werden kann und das Passwort enthält, mit welchem die Datei vom Programm nutzbar gemacht werden kann. Wieso? Nunja, wir betrachten das letzte Bild, also die Antwort vom Server nach unserer Anfrage. Es handelt sich dabei um ganz exakt 256 Bit. Die typische Länge für z.B. einen AES256. Es kann an dieser Stelle kein asymmetrischen Verfahren verwendet worden sein, da dieses niemals unter 1024 Bit lang wäre. Es ist also sehr wahrscheinlich das hier der Schlüssel dirkt oder zumindest teilweise enthalten ist.

Nach dem was hier zu sehen war, funktioniert das System meiner Meinung nach so: möchte der Benutzer eine DLC-Datei auswerten, läd er diese in das entsprechende Programm. Da der Inhalt verschlüsselt ist, kann die Anwendung damit zunächst nichts anfangen. Innerhalb der Datei befindet sich allerdings das (verschlüsselte) Passwort zum entschlüsseln der Daten, welches jedoch nur vom Betreiber entschlüsselt werden kann. Die Applikation sendet also dieses verschlüsselte Passwort zum DLC-Server, welches die entschlüsselte Version zurückliefert. Damit kann der Inhalt dechiffriert werden kann. Nochmal zusammengefasst:

  1. das Öffnen der DLC-Datei mit dem Programm,
  2. die Anwendung sendet das verschlüsselte Passwort zum Server des Betreibers,
  3. der Betreiber dechiffriert dieses und sendet das entschlüsselte Passwort zurück,
  4. mit diesem Passwort kann der Inhalt dechiffriert werden und die Links „liegen offen“.

Wofür das Ganze? Der Betreiber kann auf diese Art und Weise kontrollieren, wer (von welcher IP-Adresse) wie häufig eine Datei entschlüsseln möchte. Der Sinn ist zu verhindern, das jemand große Mengen dieser Container entschlüsselt und damit die Links alle freilegt. Ohne Zusammenarbeit mit dem Server ist das entschlüsseln dieser Dateien bzw.der dort enthaltenen Links nicht möglich.

Insgesamt halte ich dieses System für ganz gelungen. Unter Umständen werde ich in einem separaten Eintrag noch einige Anmerkungen dazu machen.

24 (twenty four)

Nachdem ich nun in den letzten Wochen Staffelweise 24 geschaut habe, will ich einige Aussagen (die ich so gehört habe) kommentieren.

„das ist Blowfish verschlüsselt, das erkennt man am Header.“

Klingt gut, ist aber Unsinn. Eine verschlüsselte Datei bzw. ein verschlüsselter Container besitzt keinen besonderen Header. Natürlich könnte man dem zurecht entgegenhalten das dies Anwendungsspezifisch ist. Jedoch wo liegt der Sinn einem Angreifer schon vor Eingabe des Passworts den Algorithmus zu verraten (lassen wir Kerkhoff außen vor).  Sofern kein besonderer Verschlüsselungsalgorithmus ausgewählt ist, führen Programme „Probeentschlüsselungen“ durch und prüfen auf Plausibilität. 

Decryption is considered successful if the first 4 bytes of the decrypted data contain the ASCII string “TRUE“, and if the CRC-32 checksum of the last 256 bytes of the decrypted data (volume header) matches the value located at byte #8 of the decrypted data (this value is unknown to an adversary because it is encrypted – see the section Header Key Derivation, Salt, and Iteration Count). If these conditions are not met, the process continues from (3) again, but this time, instead of the data read in (1), the data read in (2) are used (i.e., possible hidden volume header). If the conditions are not met again, mounting is terminated (wrong password, corrupted volume, or not a TrueCrypt volume).

Quelle: http://www.truecrypt.org/docs/encryption-scheme.php

Außerdem ist Blowfish (128 Bit) schwer veraltet.

Definieren wir das Ganze einfach mal als zweifelhaft.

 

Als nächstes:

„das ist eine affine Chiffre, die kann man nicht knacken“

Okay, Blowfish geht, aber eine (linear) affine Chiffre nicht. Die Affine Chiffre ist (das findet auch jeder in Google) eine einfache Blockchiffre, welche allerdings im Gegensatz zur einfachen Verschiebechiffre noch einen 2. Schlüssel hat. Der Schlüssel ist also ein zwei-Tupel: k=(a,b). Wenn wir eine Alphabetsgröße von 26 festlegen, verschlüsselt sich Text mit Hilfe folgender Formel:

c = a*p + b mod 26

Wobei c das neue Chiffre- und p ein Klartextzeichen ist. Ein Beispiel:

Klartext: „ABC“, Key: (2,3)

2 * 0 (A) + 3 mod 26 = 3 (C)
2 * 1 (B) + 3 mod 26 = 5 (E)
2 * 2 (C) + 3 mod 26 = 7 (G)

Chiffretext = „CEG“

Zum entschlüsseln muss ein mulitplikatives Inverses berechnet werden.

Das versteht man also unter einer affinen Chiffre. Natürlich ist etwas kniffeliger als eine reine Verschiebe oder Vignerechiffre, jedoch nicht wirklich ein Problem. Mit ein wenig Verstand bekommt man es auch noch gut auf dem Papier hin.
Diese Aussage können wir zweifelsfrei als Unsinn bezeichnen.

One Time Password

Was haben Banken, World of Warcraft und einige große Unternehmen gemeinsam? In allen kann ein Gerät, welches ein „One Time Password“ erstellt, zum authentifizieren verwendet werden.

Wie sieht sowas aus und wie wird es verwendet?

Das Gerät besitzt ein oder zwei Knöpfe und ein kleines Display. Nachdem ein Knopf betätigt wurde zeigt dieser einen meist 6-stelligen Code an. Dieser muss dann im System (z.B. für die Banküberweisung) eingegeben werden. Bei erneutem betätigen wird wiederrum eine andere Ziffernfolge (pseudozufällig) erstellt.

Wie funktioniert das?

Sofern das Gerät keine innere Uhr besitzt (meist der Fall), müssen 2 Modi unterstützt werden:
TAN-Generierung und Synchronisation. Sobald also, wie oben geschildert, der Benutzer aufgefordert wird eine Tan einzugeben, berechnet das Gerät aus dem aktuellen Index einen Code. Der Index ist die Anzahl der bisher erstellten TANs.

Also ein Beispiel: G(I,K) ist die zweistellige Generatorfunktion, I ist der Index und K ein Passwort, welches fest im Gerät „eingebrannt“ und nicht auslesbar ist:

beim ersten Mal: G(0001,“abc123″) -> 495096
beim zweiten Mal: G(0002,“abc123″) -> 938237
beim dritten Mal: G(0003,“abc123″) -> 294921

Der Index wird also immer weiter inkrementiert.

Der Server, auf der anderen Seite, kennt auch das Passwort K. Dies hat der Hersteller so eingerichtet. Nach jedem benutzen inkrementiert der Server, genau wie das Gerät, den Index wodurch synchronisation zwischen Gerät und Server hergestellt wird.

Beispiel: Der Benutzer betätigt die Taste des Geräts und lässt sich ein Key berechnen: G(0325, „abcdefg“). Der Benutzer gibt die ausgegebene Ziffernfolge (439323) in das Formular ein. Der Server kennt die Anzahl der bisherigen Logins (324) und berechnet nun den aktuellen Index: 0325. Dadurch ist es möglich die Eingabe zu validieren.

Angenommen ein Benutzer betätigt versehentlich die Taste ist das System asynchron. Daher muss, wie schon angedeutet, die Möglichkeit bestehen, den aktuellen Index auszugeben.

Sicherheit?

Das System eliminiert das recht große Sicherheitsloch des unsicheren Benutzerpassworts. Es stetig wechselndes Passwort bietet durchaus Vorteile. Allerdings ist das System nicht resistent gegen Man-in-the-Middle. Beispiel: Der Server sendet an den Benutzer die Aufforderung zur Eingabe. Dieser kommt dem natürlich sofort nach und sendet die entsprechende Tan. Der Angreifer fängt diese Antwort ab, ändert den Inhalt (Überweisung auf ein anderes Konto) und schickt diese zum Server. Grund zur Angst besteht allerdings nicht, da Online-Banking mittels SSL resistent dem gegenüber ist.

SSL Check

Die Stiftung Warentest bietet einen Onlinedienst zum prüfen der SSL Sicherheit einer Webseite an.

http://www.test.de/themen/computer-telefon/ssl_check

In einem guten Browser wird dies allerdings auch übersichtlich angezeigt, wofür das Ganze also?

Das wird vielleicht klar, wenn wir mal ein Beispiel betrachten. Die Webseite https://www.sofortueberweisung.de/ ist auch SSL geschützt. Schauen wir uns an, was der Test dort ausspuckt:

Vom Server unterstützte SSL-Version: 3
Bevorzugte Verschlüsselung: Triple-DES (168/112 Bit)

Wenn ich allerdings mit meinem Browser die Webseite betrete erhalte ich eine andere Information

sofuebscreenshot

Woher kommt das?

Dafür muss man sich das SSL (Secure Sockets Layer) bzw. TLS (Transport Layer Security) Protokoll etwas genauer anschauen. Bei der Kontaktaufnahme teilt der Client dem Server mit, welche sym. / asm. Verschlüsselungskombinationen er „versteht“. Diese werden auch Ciphersuites genannt. Mein Browser teilt also dem Server der Webseite mit, das er AES 256 bevorzugt was auch durchaus in meinem Interesse ist.

Aber angenommen ich wäre einem Man-in-the-middle Angriff ausgesetzt, d.h. jemand kann meinen Traffic komplett auslesen und verändern, dann hätte er bei SSL nur dann eine Chance, wenn die Verschüsselung unsicher ist. Wenn also der Bösewicht in der Mitte dafür sorgt das eine schwache Verschlüsselung (CipherSuite) ausgesucht wird, wäre er in einer eindeutig besseren Lage als vorher.

Aus diesem Grund wählt der SSL Check eine möglichst schlechte Verschlüsselung aus um herauszufinden wo der Server noch mitspielt und wann nicht mehr. Würde er also DES (effektiv 56 Bit) und gleichzeitig AES (128 – 256) unterstützen, wäre der SSL Schutz vielleicht nicht mehr so sicher, wie er auf den ersten Blick erscheint.

Daher ist dieser Check, obwohl er vielleicht auf den ersten Blick nicht so wichtig erscheint, eine gute Sache.