Bits, Bytes and my 5 cents http://blog.encodingit.ch Life is just a technical game Wed, 04 May 2016 10:36:57 +0000 de-DE hourly 1 http://blog.encodingit.ch/wp-content/uploads/2014/02/cropped-panorama_shanghai-2-32x32.jpg Bits, Bytes and my 5 cents http://blog.encodingit.ch 32 32 BADLOCK – Most Overhyped Bug http://blog.encodingit.ch/2016/05/badlock-most-overhyped-bug/ http://blog.encodingit.ch/2016/05/badlock-most-overhyped-bug/#respond Wed, 04 May 2016 10:36:57 +0000 http://blog.encodingit.ch/?p=5312 Badlock ist sicherlich jedem ein Begriff – genug darüber geschrieben und gesprochen wurde ja schliesslich in vergangener Zeit:

Doch wieso wurde diesem Bug so viel Aufmerksamkeit geschenkt, wieso hat der Bug ein Logo und einen Namen während Andere nur eine CVE-Nummer bekommen?
Eigentlich liegt der Schluss somit ja nahe, dass er kritischer oder heikler ist als andere… Ist somit spezielle Vorsicht nötig?

Problematisch ist sicherlich die Entwicklung, welche der Bug durchgemacht hat: Vor knapp einem Monat wurde die Lücke veröffentlicht, jedoch nur mit dem Namen, einem coolen Logo und ohne zusätzliche Details. Da die Medien dies ziemlich schnell aufgriffen, fingen die wildesten Spekulationen an, welche Software-Teile betroffen sein könnten oder wie weitrechend die Auswirkungen wirklich sind… Dazugekommen ist, dass der Name auch sehr viel Spielraum für Spekulationen offen lässt und auf den ersten Blick vielleicht eher in Richtung Locking und Concurrent Programming führen könnte.

Jetzt, nachdem die Details bekannt sind, muss man sicherlich auch mal relativieren: Der Bug ist durchaus heikel, aber nicht so heikel, dass man jetzt in Panik verfallen müsste, wie das auch schon bei z.B. Shellshock der Fall war. Versteht mich nicht falsch, ich sage nicht, man soll die Lücke nicht patchen und schliessen, aber das geht auch wie bei jedem anderen Bug sonst auch und braucht keine 1-monatige Marketingkampagne bevor einzelne Infos darüber veröffentlicht werden. Das ist simple Effekthascherei…
Und schliesslich kann jeder einem Bug einen Namen und ein Logo geben, das ändert aber noch lange nichts an der Wichtigkeit oder der Reichweite eines einzelnen Bugs. Badlock hat auch „nur“ eine CVSS score von 7.1 erhalten und selbst Microsoft stuft den Fix nur als „Wichtig“ und nicht „Kritisch“ ein…

Ich denke mal, wir befinden uns hier auf einem guten Weg für den Pwnie Award „Most Overhyped Bug“… 🙂

]]>
http://blog.encodingit.ch/2016/05/badlock-most-overhyped-bug/feed/ 0
Online-Dienst zur Identifizierung von Ransomware http://blog.encodingit.ch/2016/04/online-dienst-zur-identifizierung-von-ransomware/ http://blog.encodingit.ch/2016/04/online-dienst-zur-identifizierung-von-ransomware/#respond Fri, 22 Apr 2016 11:37:55 +0000 http://blog.encodingit.ch/?p=5304 Bei der Incident Response von Ransomware-Ausbrüchen ist es essenziell, dass man ziemlich schnell weiss, mit welchem Typ von Malware man es zu tun hat, um die First Response auch entsprechend ableiten zu können. Nicht gerade Vorteilhaft, wenn man auf eine statische Analyse warten muss, um weitere Infos zu erhalten, wonach man überhaupt sonst noch so suchen muss. Oder als Worst Case: Man hat nur die verschlüsselten Files und keine Malware und kann nicht feststellen, wie genau die Malware sich verhält oder wo man weitersuchen könnte…

Das selbe Problem scheint auch der Twitter-User Michael Gillespie (@demonslay335) zu kennen und hat deshalb eine Plattform „ID Ransomware“ ins Leben gerufen, auf welcher entweder die Erpresser-Files oder aber gleich verschlüsselte Daten hochladen und analysieren lassen kann:

id_ransomware

Nach eigenen Aussagen erkennt man aktuell 59 Ransomware-Familien:

7ev3n, AutoLocky, BitMessage, Booyah, Brazilian Ransomware, BuyUnlockCode, Cerber, CoinVault, Coverton, Crypt0L0cker, CryptoFortress, CryptoHasYou, CryptoJoker, CryptoTorLocker, CryptoWall 2.0, CryptoWall 3.0, CryptoWall 4.0, CryptXXX, CrySiS, CTB-Locker, DMA Locker, ECLR Ransomware, EnCiPhErEd, Hi Buddy!, HOW TO DECRYPT FILES, HydraCrypt, Jigsaw, JobCrypter, KeRanger, KryptoLocker, LeChiffre, Locky, Lortok, Magic, Maktub Locker, MireWare, Mobef, NanoLocker, Nemucod, OMG! Ransomcrypt, PadCrypt, PClock, PowerWare, Radamant, Radamant v2.1, RemindMe, Rokku, Samas, Sanction, Shade, SuperCrypt, Surprise, TeslaCrypt 0.x, TeslaCrypt 2.x, TeslaCrypt 3.0, TeslaCrypt 4.0, UmbreCrypt, VaultCrypt, WonderCrypter

Meine Tests mit CryptoLocker und HydraCrypt haben leider weder mit verschlüsselten noch mit Erpressungs-Files funktioniert, aber einerseits hat die Plattform ja noch potenzial zu wachsen und andererseits ist im Falle eines Ausbruches jedes Mittel recht, selbst wenn es nur bei 10% der Samples etwas hilfreiches hervor bringt…

Zu finden ist die Plattform unter id-ransomware.malwarehunterteam.com.

Bei sehr konstanter Erkennungsrate wäre es natürlich ganz cool eine API zu haben. Ich stelle mir hier Dinge vor wie automatische Alarms auf verdächtige Files, welche dann über die API geprüft und eindeutig identifiziert werden, etc. Zukunftsmusik aber eigentlich gar nicht mal so verkehrt der Gedanke… 🙂

]]>
http://blog.encodingit.ch/2016/04/online-dienst-zur-identifizierung-von-ransomware/feed/ 0
Neues Ransomware Sample mit IOC http://blog.encodingit.ch/2016/04/new-sample-of-ransomware/ http://blog.encodingit.ch/2016/04/new-sample-of-ransomware/#comments Thu, 21 Apr 2016 05:44:21 +0000 http://blog.encodingit.ch/?p=5294 Vor kurzem bin ich über eine mir bisher noch nicht untergekommene Variante einer Ransomware gestossen. Die Erkennungsrate nach auch einem ganzen Tag lässt leider noch immer massiv zu wünschen übrig – gerade mal 11 von 56 (Link) erkennen die Bedrohung bisher und anhand der Malware-Familien, welche zugeordnet werden, scheinen das auch nur Behaivoral-Analysen zu sein und sicherlich keine Pattern…

Die Infektion mit der Ransomware scheint wie in letzter Zeit so üblich, über das Angler-EK zu laufen und die Einstiegspunkte dafür sind sehr vielfältig.

Ist die Malware auf dem Client, so erkennt man sie am besten daran, dass sie sich in jeden verschlüsselten Ordner selbst kopiert, aktuell unter dem Namen „Backup Instruction.exe“ mit folgenden Eigenschaften:

MD5:		a0fed8de59e6f6ce77da7788faef5489
SHA1:		96ebbf821f37dc2dcebc177fc3a6c17b3171aab3
SHA256:	004cdc6996225f244aef124edc72f90434a872b3d4fa56d5ebc2655473733aef

Ist die Ransomware einmal aktiv, so werden die Daten verschlüsselt nach folgendem Muster:

FILENAME_ID_email_xoomx@dr.com_.code

Zusätzlich wird die Datei mit weiteren Instruktionen in einer HTML Datei abgelegt mit dem Namen „HELP_YOUR_FILES.HTML“:

Name:		HELP_YOUR_FILES.HTML
Grösse:	1913 bytes
Typ:		HTML document, ASCII text
MD5			4cb837255571d2d27d6b1f8f9bc672ef
SHA1		e3717b3a2d7e98abdfe8451b6d4efe3a51c65347
SHA256	f44737eb9ef658251f8f5bf5b0f59186a554a8a9ef6b1cf78b927866a0143a27

Erkennen lässt sich die Ransomware an der Netzwerkkommunikation, womit der entsprechende Key übermittelt wird:

21-04-2016 07-33-20

Spannend fand ich, dass der Key vom Host an den C2 übermittelt wird und nicht umgekehrt:

21-04-2016 07-35-27

Somit ist der übermittelte Key entweder der Private-Key zum Entschlüsseln, oder aber der Public Key, was aber bedeutet, dass die Ransomware selbst über hartkodierte und einprogrammierte Keys verfügen muss und diese sind ja bekanntlich nicht unendlich vielfältig. Sicherlich ein guter Punkt zum Einsteigen für ein mögliches Entschlüsselungsprogramm…

Als IOC sind aus der Analyse die folgenden Infos zusammengekommen:

FileHash-MD5:			a0fed8de59e6f6ce77da7788faef5489
FileHash-SHA1:		96ebbf821f37dc2dcebc177fc3a6c17b3171aab3
FileHash-SHA256:	004cdc6996225f244aef124edc72f90434a872b3d4fa56d5ebc2655473733aef
IPv4:							46.8.45.174
URL:							hXXp://46.8.45.174/bobi/piok.php
]]>
http://blog.encodingit.ch/2016/04/new-sample-of-ransomware/feed/ 5
Analyse von Cryptolocker / TeslaCrypt Sample http://blog.encodingit.ch/2016/03/analyse-von-cryptolocker-teslacrypt-sample/ http://blog.encodingit.ch/2016/03/analyse-von-cryptolocker-teslacrypt-sample/#respond Fri, 18 Mar 2016 16:24:46 +0000 http://blog.encodingit.ch/?p=5266 Bei fast allen Typen von Ransomware, welche ich bisher analysiert hatte, waren die entsprechenden Locker-Samples ziemlich einfach aufzufinden: Diese kopieren sich nämlich einfach mal schnell ins Home-Directory des Users und verstecken sich dort (hidden Files). Doch wieso geht man so fahrlässig damit um? So ist das Sammeln von IOCs und anderen Verhaltensmustern ja ziemlich einfach und man muss andauernd wieder neue Versionen produzieren und verteilen… Natürlich ist es mittlerweile dank Packer und anderen Tools sehr einfach aus einem Sample gleich hundert neue zu generieren, doch wieso macht man sich den Aufwand überhaupt, wenn man es auch von Anfang an richtig machen könnte? Würde man den Locker lediglich aus dem Memory starten, so wäre es weitaus schwieriger, das Sample in die Finger zu bekommen, da man in der Regel den Stop der Verschlüsselung einer forensisch Tiefen Analyse des Clients vorzieht…

Diese Gedanken sind wieder aufgekommen, als mir vor kurzem ein Sample einer Variante von TeslaCrypt zugetragen wurde. Dieses ist aktuell noch nicht erkannt von den bekannten AV-Herstellern (Stand 17.03.2016), weshalb ich hier gerne meine IOCs weitergebe:

Netzwerk

Wie bei allen aktuellen Ransomware Samples gibt es auch hier natürlich einen initialen Kontakt mit C2 Systemen, mindestens um den entsprechenden Public-Key anzufordern, der sich durch charakteristisch klar erkennbare HTTP-Posts zeigt:

POST /*/*.[php|cgi] HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.3 rv:11.0) like Gecko
Host: *
Content-Length: 645
Cache-Control: no-cache

Insgesamt findet die Kommunikation mit 2 verschiedenen Servern und mehreren URLs statt:

IP Domain Data
174.136.12.119 esbook.com POST /phsys.php HTTP/1.1
Accept: , \x90\x01\xb2, , , , , ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., w, ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.3 rv:11.0) like Gecko
Host: esbook.com
Content-Length: 645
Cache-Control: no-cache
174.136.12.119 esbook.com GET /cgi-sys/suspendedpage.cgi HTTP/1.1
Accept: , \x90\x01\xb2, , , , , ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., w, ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (Windows NT 6.3 rv:11.0) like Gecko
Host: esbook.com
Cookie: _asomcnc=1
Cache-Control: no-cache
66.147.244.86 hmgame.net POST /phsys.php HTTP/1.1
Accept: , \x90\x01\xb2, , , , , ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., w, ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.3 rv:11.0) like Gecko
Host: hmgame.net
Content-Length: 645
Cache-Control: no-cache

File

Das File selbst kommt laut Metainfos von einer Firma namens „Cerious Software, Inc.“ und ist unter dem Namen „Recogniser Payslips“ in der Version „0.8.250.145“ verfügbar. Immerhin waren die Schreiber so ehrlich und haben die Software nur als Pre-Release veröffentlicht. 😀

Die gedroppten Files selbst bestehen aus einem Buchstaben-String von zufälligen Buchstaben. Bei meiner Ausführung war dies rwhiti.exe und jdlsfg.exe, zwei Namen, jedoch nur eine Datei dahinter… Die Files starten sich mehrfach selbst als Kindsprozesse, wohl um die Analyse zu erschweren. Nebenbei wird auch noch ein CMD.exe gestartet, mit dem Versuch rwhiti.exe zu löschen. Wieso hierbei aber auf das Löschen von jdlsfg.exe verzichtet wird, ist mir ein Rätsel, aber vielleicht kommt das ja noch, sobald wir die Stable-Version der Ransomware erreicht haben…

Einnisten tun sich die Files in der Registry an den üblichen Orten:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\"" = "%System%\CMD.EXE /C START %UserProfile%\My Documents\*.exe.

Das File selbst hat die folgenden Eigenschaften:

FILE NAME rwhiti.exe
FILE SIZE 406096 bytes
FILE TYPE PE32 executable (GUI) Intel 80386, for MS Windows
MD5 36876e94ffe785addb9b21e85f78b2fd
SHA1 e228d0cdd3ad649c5a31c464252646183d7b0fbf
SHA256 613e13ba403ad91777298999e968f3a0610c53e0ecdf99657db92fc508873a5c

Eine Zusammenfassung der IOC gibt es hier. Happy Hunting!

]]>
http://blog.encodingit.ch/2016/03/analyse-von-cryptolocker-teslacrypt-sample/feed/ 0
„Jemand hat bezahlt“ oder die wahren Verursacher von Unwissenheit http://blog.encodingit.ch/2016/03/jemand-hat-bezahlt-oder-die-wahren-verursacher-von-unwissenheit/ http://blog.encodingit.ch/2016/03/jemand-hat-bezahlt-oder-die-wahren-verursacher-von-unwissenheit/#respond Thu, 17 Mar 2016 06:58:13 +0000 http://blog.encodingit.ch/?p=5267 Gestern trumpfte eine Meldung in der 20min.ch mit der Überschrift „Schweizer Unternehmen liess sich erpressen„. Dabei ging es um den konkreten Fall einer Schweizer Unternehmung die angeblich auf die Erpressungen reagiert hat und sich freigekauft hat… Es geht mir auch gar nicht um diese Unternehmung selbst, doch viel mehr um die falschen Anreize, welche diese Aktion nun schafft! Ich meine, es gibt ja auch einen einfachen Grund wieso man offiziell die Haltung lebt, dass man mit Erpressern nicht verhandelt. Selbst wenn am Ende hintenrum immer mal wieder Geld fliest, so muss die offizielle Botschaft ganz klar lauten: WIR LASSEN UNS NICHT ERPRESSEN, da sonst falsche Anreize geschaffen werden, entweder für neue Täter oder aber auch für den selben Täter wieder. Dies aus dem einfachen Grund, dass man gesehen hat das Modell lohnt sich, selbst wenn ein zweiter Täter gar nicht die technischen Einrichtungen besitzt, um den Angriff tatsächlich durchzuführen, wenn bereits auf die Androhung hin bezahlt wird, so ist das klar ein neues Geschäftsmodell…

Und jetzt? Die „Schweizer Unternehmung“ ist nun Schuld, dass andere auch angegriffen werden?

Aber das Problem liegt hier in meinen Augen gar nicht wirklich bei der Unternehmung, die gezahlt hat, selbst, sondern viel mehr beim Bund, MELANI, GovCERT und all diesen Einrichtungen. Zwar gibt es von diesen offizielle Stellungnahmen und ein paar kurze Whitepapers, doch sind diese viel zu oberflächlich und allgemein… So heisst es:

„Typischerweise suchen Sie hier eine Lösung in enger Zusammenarbeit mit Ihrem ISP und/oder einem spezialisierten DDoSMitigation-Provider. (Quelle)“

Ahja! Und wie soll jemand, der schon keine Ahnung hat, dass es überhaupt Provider für DDoS-Protection gibt nun verstehen, was ein „spezialisierten DDoSMitigation-Provider“ ist und wo er nun einen findet? Ausserdem klingt das so hochgestochen, dass wohl jede mittelgrosse Unternehmung zum Schluss kommt, das kann sich ja niemand leisten:

«Wir hatten immer mal wieder DDoS-Angriffe, eine Attacke in diesem Ausmass gab es aber noch nie», sagt Stefan Meile, Inhaber von Insmoke.ch, der auch die Website Wernersheadshop.ch und fünf weitere Domains betreibt. Insgesamt arbeiten 13 Personen im Betrieb. Am Sonntag begannen die Angriffe. Erst waren die Websites nur für eine Stunde offline.«Am Montag waren wir für drei und am Dienstag für sieben Stunden nicht erreichbar», sagt Meile. Einen DDoS-Schutz hat der Betreiber bisher nicht. «Für KMUs ist das fast nicht bezahlbar», sagt er. (Quelle)

Umso mehr verstehe ich solche Aussagen. Eigentlich gibt es diverse DDoS-Protection-Services für einfache Webshops bereits ab CHF 20.- pro Monat, doch wenn man nicht weiss, wonach man schauen muss… Wieso also macht man sich von offizieller Seite nicht die Mühe, und veröffentlicht ein management-gerechtes Paper mit konkreten Beispielen, einem Proof Of Concept oder einer Success-Story. Oder MELANI setzt sich mal mit den grösseren ISP’s zusammen und definiert eine einfache Lösung inklusive Kontaktpunkt, wovon auch KMUs profitieren können (Gesamtpaket), denn wie soll man als kleine Unternehmung schon sinnvoll mit einem grossen Provider verhandeln, wenn man keine Ahnung hat, was man eigentlich braucht?

]]>
http://blog.encodingit.ch/2016/03/jemand-hat-bezahlt-oder-die-wahren-verursacher-von-unwissenheit/feed/ 0
Alternative Root-Cause-Analyse für aktive Ransomware http://blog.encodingit.ch/2016/03/alternative-root-cause-analyse-fuer-aktive-ransomware/ http://blog.encodingit.ch/2016/03/alternative-root-cause-analyse-fuer-aktive-ransomware/#respond Fri, 11 Mar 2016 17:30:37 +0000 http://blog.encodingit.ch/?p=5248 Wie findet man die Ursache für eine laufende Verschlüsselung durch eine Ransomware in einem Netzwerk mit mehreren hundert Clients schnell und effektiv? Natürlich hat man ein SIEM, dass die Logs auswertet und korreliert und schnell und einfach anzeigen kann, welche Person wie viele Dateien auf ein Laufwerk geschrieben hat – ist ja klar!

Doch wie genau erkennt man die Ursache wenn das SIEM nun mal keine Ergebnisse liefert, weil zum Beispiel die Logs nicht angekommen sind oder nicht sauber verarbeitet wurden? Dann bleibt nur noch die Lösung, alle verschlüsselten Laufwerke zu identifizieren und zu schauen, welche Person als Schnittstelle auf allen Verzeichnissen Schreibrechte hat. Nur kann dieser Prozess selbst bei 20 möglichen Usern in drei bis 4 verschiedenen Gruppen durch manuelles aussortieren sehr lange gehen, während dem frisch fröhlich immer weiter verschlüsselt wird – und das gerade dann, wo jede einzelne Minute kritisch wäre!

group_member_analysis

Mit diesem Gedanken im Hinterkopf habe ich vor kurzem ein kleines Tool entworfen, in welchem sich bis zu vier Gruppen pro verschlüsseltem Laufwerk auslesen und dann mit ebenfalls bis zu vier weiteren Gruppen pro weiterem Laufwerk korrelieren lassen, bis die Schnittmenge im Idealfall nur noch eine einzelne Person ist. Natürlich ist dies je nach Anwendungsfall und Berechtigungskonzept nicht immer zielführend, aber meistens kann der Kreis der Verdächtigen damit fast immer auf eine Handvoll eingeschränkt werden, was die Analyse schon massiv vereinfacht und verkürzt.

Wer an dem Tool interessiert ist, der findet das C#.NET Projekt (Visual Studio) auf Github. Feedback ist gerne Willkommen, Verwendung wie immer auf eigene Gefahr!

]]>
http://blog.encodingit.ch/2016/03/alternative-root-cause-analyse-fuer-aktive-ransomware/feed/ 0
Wenn übermässige Sicherheit zu Unsicherheit führt http://blog.encodingit.ch/2016/01/wenn-uebermaessige-sicherheit-zu-unsicherheit-fuehrt/ http://blog.encodingit.ch/2016/01/wenn-uebermaessige-sicherheit-zu-unsicherheit-fuehrt/#respond Fri, 29 Jan 2016 07:08:37 +0000 http://blog.encodingit.ch/?p=5235 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…

]]>
http://blog.encodingit.ch/2016/01/wenn-uebermaessige-sicherheit-zu-unsicherheit-fuehrt/feed/ 0
FortiOS SSH Backdoor ignoriert interne Sicherheitsfeatures http://blog.encodingit.ch/2016/01/fortios-ssh-luecke-ignoriert-jegliche-sicherheitsfeatures/ http://blog.encodingit.ch/2016/01/fortios-ssh-luecke-ignoriert-jegliche-sicherheitsfeatures/#respond Fri, 15 Jan 2016 08:59:19 +0000 http://blog.encodingit.ch/?p=5204 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!

]]>
http://blog.encodingit.ch/2016/01/fortios-ssh-luecke-ignoriert-jegliche-sicherheitsfeatures/feed/ 0
Erkennen von Schwachstellen in verschlüsselten Daten http://blog.encodingit.ch/2015/11/erkennen-von-schwachstellen-in-verschluesselten-daten/ http://blog.encodingit.ch/2015/11/erkennen-von-schwachstellen-in-verschluesselten-daten/#respond Thu, 05 Nov 2015 00:42:10 +0000 http://blog.encodingit.ch/?p=5184 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.

]]>
http://blog.encodingit.ch/2015/11/erkennen-von-schwachstellen-in-verschluesselten-daten/feed/ 0
Passwörter als GET-Variable :: Danke Netvibes! http://blog.encodingit.ch/2015/10/passwoerter-als-get-variable-danke-netvibes/ http://blog.encodingit.ch/2015/10/passwoerter-als-get-variable-danke-netvibes/#respond Thu, 29 Oct 2015 07:15:53 +0000 http://blog.encodingit.ch/?p=5173 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!

]]>
http://blog.encodingit.ch/2015/10/passwoerter-als-get-variable-danke-netvibes/feed/ 0