Meet a Pentester – Interview mit Benedikt Strobl

Unser langjähriger Mitarbeiter Benedikt Strobl wird Ende des Monats ein fünfmonatiges Sabbatical antreten. Bevor er sich auf die Reise macht, hat er sich die Zeit für ein kurzes Interview genommen und die wichtigsten Fragen zum Thema Penetrationstests und zu seiner Arbeit als Pentester beantwortet. Wir wünschen viel Spaß beim Lesen und Benedikt eine tolle und abenteuerreiche Zeit!

Hallo Bene, wir starten am besten mit einer kurzen Vorstellung: Wie lange arbeitest du schon im Bereich Offensive Security und was sind deine Schwerpunkte?

Meine Name ist Benedikt Strobl, ich bin 31 Jahre alt und arbeite seit 6 Jahren bei der NSIDE als Security Analyst. Meine ersten Berührpunkte mit der IT Security hatte ich im Rahmen meines Studiums und bei CTFs. Meine Schwerpunkte haben sich dabei über die Jahre etwas […]

Von NSIDE|2023-03-23T08:32:28+01:0022. März 2023|

Cobalt Strike und sein besserer kleiner Bruder Brute Ratel

Vielen ist Cobalt Strike mittlerweile ein Begriff. Sei es, weil mal wieder eine Ransomware-Gruppe damit ganze Unternehmen lahmgelegt hat oder weil Akteure gezielt Unternehmen angegriffen haben und in der anschließenden Analyse festgestellt wurde, dass Cobalt Strike im Einsatz war. Der ein oder andere hat vielleicht auch mitbekommen, dass ein anderes Tool namens Brute Ratel in letzter Zeit Wellen geschlagen hat. Doch warum ist das so?

Was sind Command&Control-Frameworks?

Bevor wir auf die Einzelheiten und Unterschiede eingehen, sollte zumindest grundlegend geklärt werden, was der allgemeine Einsatzzweck von Tools wie Cobalt Strike oder Brute Ratel ist. Beide Tools sind sogenannte Command&Control-Frameworks. Command&Control-Frameworks werden von Penetrationstestern und Red Teamern verwendet, um möglichst realistisch „echte“ Malware zu simulieren (wobei sie darin so gut sind, dass sie in den Händen von […]

Von Tobias Wicke|2023-05-23T14:01:37+02:0021. März 2023|

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|2022-06-13T11:36:02+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 Bettina Noglik|2022-02-24T16:20:37+01:0024. Februar 2022|

NSIDE Tech Blog

BLEIBEN SIE AUF DEM LAUFENDEN