References & case studies

Für einen globalen Konzern wurde von uns eine Webanwendung, sowie ein Rich Client zur Software-Entwicklung getestet. Zudem war dabei eine Agent-Anwendung von Bedeutung, die über die Anwendung angesteuert werden konnte. Hierbei handelte es sich um ein komplexes System aus vielen zusammenspielenden Komponenten - und vielen Möglichkeiten für Angriffe über Sicherheitslücken.

Manchmal macht es sich durchaus bezahlt, einen längeren Testzeitraum zu wählen, um Anwendungen oder Systeme gründlichst auf Herz und Nieren zu prüfen. Denn in den letzten Tagen des Projekts waren wir nicht nur in der Lage, beliebige Kommandos über die Client-Anwendung am Agent auszuführen, sondern auch Server-Instanzen in der Systemumgebung des Kunden zu erzeugen und zu stoppen.

Für ein globales Sportartikelunternehmen sollte an drei Firmenstandorten die Sicherheit der Zahlungsprozesse untersucht werden. Ein grundsätzlich unterschätzter Angriffsvektor ist dabei die Absicherung der verwendeten Schnittstellen zwischen den Tools und bis hin zur Bank. Wenigen ist bewusst, dass hier oft sogenannte Zahlungsdateien (meist XML) verwendet werden, welche alle Kontoinfos und somit auch das Empfängerkonto enthalten.

Dateitransfer, you say? Das Wort Schnittstelle ist in diesem Kontext nicht immer korrekt, weil hierbei die Schnittstelle der Mensch ist. Das heißt die Zahlungsdatei wird vom lokalen Gerät von einer Person auf eine Dateifreigabe im Netzwerk kopiert. Dies führt dazu, dass die Datei nicht nur potentiell bei der Übertragung, sondern auch überall dort modifiziert werden kann, wo sie abgelegt wird. Interne Angreifende können dies nutzen, um das Empfängerkonto in der Datei auf das eigene zu ändern. Je nach Zahlungsart fallen dabei durchaus nennenswerte Summen an.

Wie kann man das verhindern? Kurzfristig lohnt es sich, die Zahlungswege mit bestehenden einfachen Mitteln abzusichern. Das bedeutet, Übertragungswege verschlüsseln und Berechtigungen so gut wie möglich einzuschränken. Auf lange Sicht handelt es sich hier leider um einen aufwändigeren Task! Da müssen Strukturen und Schnittstellen geschaffen werden, die Zugriffe durch Mitarbeitende unnötig machen.

Um in einem Social Engineering Assessment interner Netzwerkzugriff zu erhalten, mussten wir zuerst Zutritt zum Gebäude erlangen. Deshalb entwarfen wir folgendes Szenario und setzen es um:

Ein Mitarbeiter von uns wartete in Anzug und Krawatte vor dem Unternehmen auf sein Stichwort. Ein zweiter Mitarbeiter tätigte aus sicherer Entfernung einen Anruf von der gefälschten Nummer eines Vorgesetzten an den Empfang: Er habe ein sehr wichtiges Meeting und der Kunde ist verspätet. Wenn der Kunde kommt, müsste dieser bitte so schnell wie möglich durchgeschleust werden.

Der erstgenannte Mitarbeiter lief nun gehetzt zum Empfang, musste gar nicht mehr viel sagen und wurde ohne Kontrolle vorbeigelassen. Das Resultat: Freie Bewegungsmöglichkeit innerhalb des Gebäudes!

Hin und wieder erreichen uns auch außergewöhnliche Anfragen: Zum Beispiel der Auftrag eines Unternehmens zur Absicherung des eigenen Webportals gegen Denial-of-Service-Angriffe. Salopp gesagt: „Schickt Anfragen bis zu einer gewissen Obergrenze und wir sehen, ob wir diesen standhalten!“ Die besondere Herausforderung daran war, dass gezielt logische Schwächen ausgenutzt werden sollten.

Für uns war das durchaus ein neuartiges Projekt, da wir üblicherweise keine Denial-of-Service-Angriffe durchführen, die besondere Angriffsart machte uns jedoch neugierig. Das hat sich letztendlich auch bezahlt gemacht, da es durch einen Programmierfehler möglich war, im Zuge der Überprüfung die Seite nicht nur während des Angriffs unerreichbar zu machen, sondern sie auch vollständig zum Absturz zu bringen.

Für die Entwicklungsabteilungen eines größeren Softwareunternehmens wurde ein Workshop zu gängigen Schwachstellen in Web-Applikationen (Fokus auf OWASP Top 10:2021) veranstaltet. Dabei wurde darauf geachtet, die Schwachstellen nach Möglichkeit praktisch vorzuführen beziehungsweise im Rahmen von praktischen Übungen selbstständig erkennen und ausnutzen zu lassen.

Am Ende des Workshops wurde ein Capture-the-Flag-Wettbewerb abgehalten, um den einzelnen Gruppen eine Möglichkeit zur Anwendung der erworbenen Erkenntnisse zu geben.

Ein großes Energieunternehmen beauftragte ein Purple Teaming Assessment. Ziel war Initial Access, Detection Tests auf bekannte Angriffsverhalten, Ausführung eines Implants bei aktivem EDR, , Testen der Möglichkeiten der Erkennung durch EDR bzw. Monitoring-Lösung, sowie die Ausführung von TTP's für Lateral Movement bzw. Persistence 

Im Zuge des Assessments konnte das Blue Team eigene custom-made Detections in der EDR-Konsole erstellen, um Angriffsverhalten zu erkennen, die vom EDR nicht abgedeckt wurden. 

Ausgangssituation war hier der Zugang zu einem Bürogebäude. Trotz bestehenden Sicherheitsmaßnahmen war es möglich online öffentliche Informationen zur Kleiderordnung und Ausweisgestaltung des Unternehmens zu erhalten. 

Durch Anpassung des Kleidungsstils und Erstellung ähnlicher Ausweise war Tailgating (Folgen von zutrittsberechtigten Personen) ohne Probleme möglich. Die Testenden konnten sich nach Eintritt ungestört im gesamten Gebäude bewegen, wo sie ungesicherte Netzwerkanschlüsse und Zutrittskarten auffanden. 
 

Ein Energie-Unternehmen hatte bereits ein Zonenkonzept für die gesamte Anlage und wollte durch eine physische Begehung dieses Konzept überprüfen lassen. Kritische Bereiche sollten hierbei besonders abgesichert werden. Bereits bestehenden waren Vereinzelungsschleusen am Eingang, auch für LKWs.

Durch unsere Begehung fiel auf, dass an den richtigen Stellen die Vereinzelungsschleusen umgangen werden konnten und dies Angreifenden einen direkten Zugang zum Unternehmensgelände ermöglichte. Ebenfalls konnten Zutrittstüren mit einer Türangel oder Öffnungsnadel geöffnet werden. Wir empfahlen weitere bauliche Maßnahmen zur Sicherung des Geländes und das Ersetzen der Zutrittstüren durch einbruchhemmende Türen mit Sicherheitsbändern.

Die Raumpläne einer Bildungseinrichtung waren öffentlich einsehbar, wodurch kritische Räume, wie Server-, Heiz- oder Archiv-Räume für den Auftrag zum Physical Security Penetration Test („legalen Einbruch“) ausfindig gemacht werden konnten. 

Vor Ort waren die beschriebenen Räume meist nicht versperrt und konnten mit einfachen Mitteln in kurzer Zeit geöffnet werden. Zugriff auf den Serverraum war nicht möglich, dafür aber auf die Heizsteuerung und Räume mit wichtigen Dokumenten.

Unsere Empfehlung war es ähnliche Sicherheitsmaßnahmen wie für die Serverstruktur anzuwenden und die öffentlichen Raumpläne nach einem Need-to-Know-Prinzip zu gestalten.

Aufgabe war es Zugang zu einem großen Bürogebäude mit Portier zu erlangen. Im Internet konnte im Vorfeld ein Gebäudeplan des Architekten mit den genauen Räumen für die ersten beiden Stockwerke aufgefunden werden. 

Aus dem Plan konnten fünf Eingänge und Wege identifiziert werden, wodurch die Portierloge umgangen werden konnte. Die meisten dieser Zugänge waren geschlossen, aber nicht versperrt, und konnten mit einfachen Mitteln geöffnet werden. 

Versicherungen verarbeiten personenbezogene Daten. Daher wurde eine Webanwendung mit Fokus auf KFZ-Registrierung einer Sicherheitsüberprüfung unterzogen. Hierbei ergeben sich neben den klassischen Webangriffen auch Risiken wie die Manipulation von Daten nach Abschluss eines Vertrages. Dies kann zu Versicherungsbetrug durch Kund:innen und Mitarbeitenden der Versicherung führen.

Im Gesundheitssektor wurde von uns ein interner Penetration Test durchgeführt. Da hier vertrauliche Daten verarbeitet werden, müssen diese Systeme gegen Angriffe im internen Netzwerk abgesichert werden. Die Systeme sollten nach dem Least-Privilege-Prinzip konfiguriert sein, um die medizinischen Daten nicht für Unbefugte erreichbar zu machen.

Für ein Phishing Assessment nutzten wir eine MS-Teams-Nachricht, um die Eingabe von Zugangsdaten zu erfragen. Mit den erlangten Zugangsdaten war eine VPN-Verbindung möglich, die weiters internen Netzwerkzugriff ermöglichte. Durch fehlerhafte Konfigurationen in Zertifikatsdiensten konnten unsere Testenden Privilege Escalation auf Domain-Admin-Berechtigungen durchführen. 

Durch ein, als Lebenslauf getarntes, Word-Dokument mit Macros war es möglich in ein System einzudringen, um internen Netzwerkzugriff zu erlangen.  Dies ermöglichte lokal gespeicherte Zugangsdaten auszulesen und anschließend Zugriff auf einen Fallback Jump Host im Internet zu bekommen. Über den Jump Host war es schlussendlich möglich Zugriff auf das vereinbarte Ziel, das Developer-Netz, zu erlangen. 

Im Rahmen einer externen Sicherheitsüberprüfung war es für uns möglich, schlechte bzw. schwache Passwörter für mehrere Konten zu finden. Ganz klassisch wurden hier Teile des Namens, Jahreszeiten oder Firmennamen verwendet. Damit können nicht nur persönliche Daten der Mitarbeitenden identifiziert werden, sondern im schlimmsten Fall bis in das interne Netzwerk vorgedrungen werden.

Um diese Art von Angriff zu verhindern, ist es wichtig, nicht nur eine gute Passwort-Policy zu etablieren, sondern auch sicherzustellen, dass diese flächendeckend umgesetzt ist. Sehr alte Konten verwenden oft noch schwache Passwörter, weil diese "vergessen" wurden. Hier ist es wichtig, solche Konten zu sperren, wenn sie nicht mehr verwendet werden. Multi-Faktor-Authentifizierung sollte forciert werden und auch hier dürfen alte Accounts nicht vergessen werden, sonst können Angreifende einfach selbst einen zweiten Faktor hinzufügen in dem Moment, in dem ein Konto gekapert wurde.