Bluetooth Low Energy Hacking für Anfänger

Nachdem ich mich nun schon einige Zeit mit dem Thema Bluetooth Low Energy (BLE) Hacking beschäftige, kommt eine Frage immer wieder auf: Wie fange ich damit an?

Nun – man könnte sicherlich beginnen, die über 3000 Seiten lange Spezifikation (aktuell Version 5.3) zu lesen, welche durch die Bluetooth Special Interest Group veröffentlicht wird. Allerdings ist hier die gesamte Spezifikation sowohl für Bluetooth Classic als auch für jede einzelne Protokollschicht enthalten. Das ist äußerst umfangreich und daher selbst für erfahrene ITler ein eher unkonstruktives Vorgehen. Wie also dann? Einmal durch die Internet Blogs der letzten 10 Jahre wühlen?

Meiner Erfahrung nach empfiehlt es sich, direkt Hand anzulegen und sich die Sache Stück für Stück in der Praxis anzusehen. Dabei entwickeln sich spezifischere Fragen und Stichworte, mit denen […]

Von Sarah Mader|2023-03-08T09:47:00+01:0022. Dezember 2022|

Fuzzing: Putting it all together (Teil 4/4)

Im ersten Teil der Blogserie haben wir 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. Im zweiten Teil wurde der Fuzzer Boofuzz vorgestellt und die Anforderungen für einfache erschöpfende Tests erklärt. Der dritte Artikel widmete sich einem konkreten Gerät, wie Boofuzz zum Fuzzen und automatisierten Detektieren von Schwachstellen von Embedded-Webservern verwendet werden kann. Dieser Artikel beschreibt nun die Umsetzung der im dritten Artikel gelösten Problemstellungen und die finale Implementierung.

Im dritten Artikel wurden drei Problemstellungen gelöst, diese werden nun als Funktion in Python abgebildet.

1. Funktion: Starten des Webservers über die Telnet-Schnittstelle

s ist hierbei ein üblicher python socket. Die Funktion until() ist eine […]

Von Martin Steil|2022-06-20T15:15:23+02:0020. Juni 2022|

Fuzzing: Rückkanal (Teil 3/4)

Im ersten Teil der Blogserie haben wir 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. Im zweiten Teil wurde der Fuzzer Boofuzz vorgestellt und die Anforderungen für einfache erschöpfende Tests erklärt. Dieser Artikel widmet sich nun einem Implementierungsansatz, wie Boofuzz zum Fuzzen und automatisierten Detektieren von Schwachstellen von Embedded-Webservern verwendet werden kann.

Da wir in der Regel im Namen von Herstellern Geräte testen, können wir bereits auf Entwicklergeräte zurückgreifen, die Zugriff auf Shell-Ebene zulassen. Normalerweise sind solche Entwicklerschnittstellen durch SSH-Server oder UART ausgeführt. Angreifer müssten für dieses Level an Zugriff bereits Schwachstellen ausnutzen oder auf (im Falle von UART) unsichere oder vergessene Entwicklerschnittstellen […]

Von Martin Steil|2024-09-26T10:19:53+02:009. Juni 2022|

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 so genannter 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 […]

Von Alexander Poth|2023-01-19T13:20:44+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 NSIDE|2024-01-15T08:18:52+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 NSIDE|2024-01-15T08:19:04+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|

Red Team Assessment

Penetrationstest

Trainings & Workshops

Allgemein

BLEIBEN SIE AUF DEM LAUFENDEN