Fuzzing-Tool: Boofuzz (Teil 2/4)

Im ersten Teil der Blogserie wurde bereits erläutert, was die grundsätzliche Zielsetzung von Fuzzing ist, welche Qualitätsunterschiede hinsichtlich der Abdeckung möglich sind und auf welche Einschränkungen und Hürden wir in unseren Assessments oft stoßen. Das Ziel dieses Artikels ist es, den Fuzzer Boofuzz vorzustellen, der auf dem „Sulley Fuzzing Framework“ aufbaut und viele Möglichkeiten für Gray-Box-Ansätze bietet, wie wir sie oft in unseren Analysen vorfinden.

Vor allem die folgenden vier Eigenschaften machen den Fuzzer zu einem mächtigen Werkzeug:

Die Fuzzing-Eingaben werden automatisch generiert. Pro Parameter werden hier tausende Eingaben versucht (die teilweise auf dem korrekten Wert des untersuchten Parameters beruhen). Wenn man dies mit der manuellen Suche nach sinnvollen Fuzzing-Eingaben vergleicht, ist hier eine weitaus größere Abdeckung möglich.
Es werden verschiedene […]

Von Martin Steil|2022-03-18T10:06:55+01:0018. März 2022|

Fuzzing – Holzhammer oder Geheimwaffe? (Teil 1/4)

Es stimmt natürlich beides. Der Begriff „Fuzzing“ an sich bedeutet lediglich, dass einer Schnittstelle automatisiert Daten gesendet werden, mit welchen die Schnittstelle nicht unbedingt rechnet. Im Optimalfall werden dabei Daten gefunden, die von der Schnittstelle zwar akzeptiert werden, jedoch in der Programmlogik nicht oder falsch bedacht wurden. Das Ziel eines solchen Fuzzing-Tests ist dabei, den Dienst oder das Gerät reproduzierbar zum Absturz zu bringen. Sobald eine Eingabe gefunden wurde, die den Dienst erfolgreich zum Absturz bringt, kann untersucht werden, ob die entdeckte Schwachstelle womöglich eine Kompromittierung des Systems erlaubt, oder auch, an welcher Stelle im Code der Fehler entsteht und wie dieser behoben werden kann. Ziel hierbei ist, das System gegen Angriffe zu härten. Im Entwicklungsprozess eingesetzt kann das Ziel aber auch […]

Von Martin Steil|2022-05-24T11:50:12+02:0017. März 2022|

Logic Analyzer

Als in den 1960er Jahren integrierte Schaltungen auf dem Vormarsch waren, begannen Probleme aufzutauchen, für welche die auch heute noch bekannten Oszilloskope keine Lösung boten.

Kompaktes Oszilloskop von 1997
(Quelle: https://de.wikipedia.org/wiki/Oszilloskop#/media/Datei:Digitaloszilloskop_IMGP1971_WP.jpg)

Zum ersten Mal in der Geschichte der Computertechnik war es unerlässlich, eine große Anzahl von Signalen gleichzeitig anzuzeigen. Frühe Lösungen versuchten, mehrere Oszilloskope zu kombinieren. Unordnung auf den Displays, ein Mangel an eindeutiger Dateninterpretation sowie Platzbeschränkungen machten diese Lösung aber nur marginal brauchbar, weswegen sog. Logic Analyzer ihren Einzug fanden. Heute ist dieses Messmittel das wohl wichtigste Gerät im Sammelsurium eines Hardware-Hackers.

8-Kanal USB Logic Analyzer
(Quelle: https://de.wikipedia.org/wiki/Logikanalysator)

Unbekannte Pins / Interfaces auf der Platine

Bei der Untersuchung einer Hardwareplatine stehen […]

Von Alexander Poth|2022-03-02T09:37:17+01:0028. Februar 2022|

FCC- Hardware-Informationsbeschaffung zu IoT-Geräten

Hardware-Analysten, aber auch Angreifer stehen wiederkehrend vor der Problematik, Geräte zu finden, welche anfällig gegenüber Hardware-Angriffen sind. Das generelle Vorgehen ist meist ein blinder Einkauf von Geräten, nur um dann enttäuscht festzustellen, dass das Gerät bspw. über keine Interfaces wie UART oder JTAG auf der Platine verfügt, welche für Angriffe ausgenutzt werden können.

Nachfolgend wird beschrieben, wie Hardwareinformationen zu Geräten abseits von gängigen Suchmaschinen abgerufen werden können, um sich bereits vor dem Kauf ein Bild von genutzter Hardware und möglichen Schwachstellen zu machen.

FCC (Federal Communications Commission)

Sämtliche Geräte mit eingesetzten Drahtlostechnologien (Bluetooth, WLAN, Zigbee, etc.), welche auf dem amerikanischen Markt etabliert werden, müssen vor Markteinführung von der amerikanischen FCC-Behörde zertifiziert werden. Typische Geräte sind Router, Bluetooth-Lautsprecher, aber auch neuartige Medizingeräte, welche Daten über Funktechnologien transferieren.

Von Alexander Poth|2022-02-25T15:45:46+01:0025. Februar 2022|

Verbindung von Jira und Dradis

In diesem Artikel möchten wir zeigen, wie sich mithilfe des Jira ScriptRunners eine Interoperabilität zum Reporting-Tool Dradis umsetzen lässt.

Die Software Jira wird heutzutage verstärkt auch im operativen Projektmanagement verwendet. Eines der wichtigsten Features von Jira, der Workflow bzw. das Tracking des Fortschritts von einzelnen Projekten, lässt sich auch bei Projekten für Sicherheitsanalysen anwenden. Als vereinfachtes Beispiel könnte ein solches Projekt die Phasen „Planung“, „Durchführung“ und „Abschluss“ durchlaufen. Während der Phase „Durchführung“ würden Analysten den praktischen Teil des Projekts ausführen und typischerweise auch ihre Findings dokumentieren. Ist ein Reporting-Tool im Einsatz, welches technische Interoperabilität erlaubt, kann Jira dazu angeleitet werden, Informationen zum Projekt in das Reporting-Tool zu übertragen und somit den Analysten formale Arbeit abnehmen.

Das Reporting-Tool Dradis, […]

Von Bettina Noglik|2022-02-24T16:20:37+01:0024. Februar 2022|

Pentest-Dokumentation mit Dradis

Ein Penetrationstest bzw. eine Sicherheitsanalyse wird typischerweise genau dokumentiert, sodass am Ende ein umfangreicher Bericht entsteht. Der Kern des Berichts sind gefundene Schwachstellen und ihre „proof of concepts“ zur technischen Nachstellung. Zusätzlich kann der Bericht einige weitere Komponenten beinhalten, wie z.B. Risiken und Empfehlungen zur Behebung der Schwachstellen oder eine zusammenfassende Einschätzung des getesteten Systems bzw. Software der Analysten. Die Dokumentationsarbeit und Erstellung des finalen Berichts kann manuell über Textverarbeitungsprogramme wie z.B. Microsoft Word erfolgen oder auch über dedizierte Tools, die speziell für den Anwendungsfall Pentesting als Dienstleistung ausgelegt sind.

Zu den Letztgenannten gehört Dradis. Das Tool stellt eine Web-Oberfläche bereit, die den Sicherheitsanalysten sowohl kollaborative Dokumentation ermöglicht als auch bei der projektbezogenen Organisation behilflich ist. Zur Erstellung von portierbaren Ergebnisdokumenten stellt Dradis […]

Von Bettina Noglik|2022-02-24T16:18:18+01:0024. Februar 2022|

Log4j – RCE-PoC Teil 2

Technischer Hintergrund

Im ersten Teil unseres Blogposts haben wir die Herkunft der Log4j- bzw. Log4Shell-Schwachstelle und die Implikationen für das Internet besprochen. In diesem Teil werden wir uns die technischen Hintergründe anschauen, um die Schwachstelle im Detail zu verstehen.

Dabei hilft es immer, den Quellcode zu untersuchen, um festzustellen, wie die Schwachstelle funktioniert. Der folgende Codeabschnitt zeigt die Schwachstelle in Zeile 7:

Quelle: Screenshot https://logging.apache.org/log4j/2.x/manual/api.html

Ohne die verwundbare Log4j-Bibiliothek wäre diese Zeile unproblematisch, da sie nur dafür sorgt, einen bestimmten HTTP–Header (X-Api-Version) zu loggen. Im folgenden Fall entpuppt sich diese Zeile allerdings als ein Einfallstor für Angreifer, um das System vollständig zu kompromittieren und gegebenenfalls erhöhte Privilegien zu erlangen (root). Welche Privilegien […]

Von Christian Gross|2022-02-17T14:38:15+01:0015. Dezember 2021|

LOG4J – Was bisher bekannt ist

1 Die Schwachstelle Log4Shell

Wer selbst schon mal eine Anwendung programmiert hat, weiß, dass man sich um verschiedene Arten von Status-, Warnungs- oder Fehlermeldungen kümmern muss. Das ist eigentlich der weniger spannende Teil, denn man möchte ja gerne neue Funktionen einbauen, anstatt zu protokollieren. Dennoch sind aussagekräftige Meldungen sehr wichtig für den Betrieb jeder Anwendung, denn nur sie ermöglichen ein effektives Debugging.

In einigen Fällen reicht es, eine simple print-Funktion zu nutzen, um Statusmeldungen auszugeben. In Java wäre das bspw. System.out.print(). Diese Funktion bietet allerdings keine weiteren Features und ist damit ungeeignet für komplexere Applikationen. Für nahezu jede Programmiersprache bzw. jedes Framework gibt es daher eigene Bibliotheken, die es einem Programmierer ermöglichen, Logging durchzuführen. Somit muss das Rad nicht bei jeder weiteren Anwendung neu […]

Von Christian Gross|2022-02-17T11:50:29+01:0015. Dezember 2021|

BorgBackup: Härtung der Sicherheit von BorgBackup und Borgmatic mittels Docker (Teil 3/3)

Dieser Beitrag ist eine Fortsetzung von Teil 1 (Einführung) und Teil 2 (Automatisierung und WSL) unserer Reihe, in welchem bereits die Grundlagen von BorgBackup und Borgmatic sowie die Unterstützung von Windows mittels Windows Subsystem for Linux (WSL) vorgestellt wurden.

Soll die Sicherung auf dem Quellsystem nicht nur im Kontext eines aktuell angemeldeten Benutzers, sondern systemweit erfolgen, werden hierfür entsprechend hohe Berechtigungen (bspw. root) benötigt. Erfolgt die Sicherung zudem auf einem Remote-Zielsystem, ist die Nutzung von SSH und borg serve empfehlenswert. Um die Sicherheit von sowohl des Quell- als auch des Zielsystems zu erhöhen bzw. den etwaigen Schaden im Falle einer erfolgreichen Kompromittierung zu minimieren, können für BorgBackup, Borgmatic und SSH Container eingesetzt werden.

Nachfolgend ist eine mögliche Umsetzung mittels Docker beschrieben.

Hinweis: […]

Von Bernhard Doll|2022-02-17T11:35:51+01:0030. November 2021|

Härtungsmaßnahme Protected Process Light

Eine der meistverwendeten Techniken in Hacker-Angriffen oder eben auch in einem Red Team Assessment ist das Auslesen von Zugangsdaten (Passwörter, Hashes, Tickets, Sessions Keys, etc.) aus dem Arbeitsspeicher. Zentraler Angriffspunkt für diese Technik ist die Local Security Authority (LSA) bzw. der zugehörige Windows-Prozess Local Security Authority Server Service (LSASS). Dieser Prozess ist dafür verantwortlich, entfernte und lokale Login-Prozesse durchzuführen und eventuelle Einschränkungen zu erzwingen. Entsprechend befinden sich im Arbeitsspeicher des Prozesses eine Vielzahl an sensiblen Informationen, die für diese Abläufe notwendig sind. Da unter Windows jeder Administrator standardmäßig über das Debug-Privileg (SeDebugPrivilege) verfügt und daher den Arbeitsspeicher jedes Prozesses einsehen kann, sind diese Daten dort vor einem Hacker mit administrativen Rechten nicht wirklich sicher. Tools wie mimikatz oder WCE […]

Von Benedikt Strobl|2022-02-17T11:37:34+01:0023. November 2021|

Unbekannte Pins / Interfaces auf der Platine

FCC (Federal Communications Commission)

Technischer Hintergrund

1 Die Schwachstelle Log4Shell

BLEIBEN SIE AUF DEM LAUFENDEN