References & case studies

Für eine Unternehmen im Energiesektor wurden zwei Webapplikationen überprüft. Der Fokus lag dabei auf Angriffsmöglichkeiten, die sowohl interne als auch externe Accounts in diesen Webapplikation haben könnten.

Während des Tests wurden mehrere Cross-Site-Request-Forgery-Schwachstellen identifiziert. Mit CSRF-Angriffen können Befehle im Kontext des Opfers durchgeführt werden, sollte das Opfer auf einen manipulierten Link  klicken. Somit kann ein CSRF-Angriff, auf interne als auch auf extern registrierte User, zur Änderung des Account-Passworts durchgeführt werden. Dies hätte zur Folge, dass der Account des Opfers vollständig kompromittiert wird.

Um CSRF-Attacken zu verhindern, darf es nicht möglich sein, eine gültige Anfrage an die Webapplikation bereits im Vorfeld vorzubereiten. Meist wird dies mit einem Zufallswert sichergestellt, der sich mit jedem Aufruf ändert und auf Serverseite mit jeder erhaltenen Anfrage validiert wird.

Für ein Unternehmen im Gesundheitsbereich führten wir eine Sicherheitsüberprüfung der internen Backupinfrastruktur durch. Ziel dieses Tests war es die Konfiguration der Dienste sowie die Server, die der Backupinfrastruktur angehören, zu überprüfen.

Während der Überprüfung wurde der Port 161/tcp identifiziert auf dem ein SNMP-Endpunkt lief. Zusätzlich war es möglich, den Community String „public“ zu verwenden, um Informationen über Accountnamen, die laufenden Dienste sowie über das Betriebssystem    herauszufinden. Die identifizierte Betriebssystemversion war Microsoft Windows CE Version 6.0 (Build 0). Diese Embedded Version des Betriebssystems Windows wurde 2006 released und ist seit 2022 End-of-Life. In Zusammenhang mit anderen offenen Ports und damit verbundenen Schwachstellen wurde ein erhöhtes Risiko für dieses System konstatiert. Da es sich um ein Festplattenmanagement-System handelte, könnten erfolgreiche Angriffe Zugriff auf schützenwerte Daten des Unternehmens liefern.

Es wurde empfohlen, Dienste, die nicht verwendet werden, abzuschalten. Immer wieder kommt es uns während Penetration Tests unter, dass teilweise Endpunkte, die vor Jahren in Verwendung waren, nicht mehr verwendet werden, jedoch immer   noch die gleiche Konfiguration aufweisen. Sollten diese Endpunkte trotzdem verwendet werden, um z.B. Informationen über das System zu eine Monitoring-Anwendung zu schicken, muss der Dienst abgesichert werden, um das Auslesen von Informationen durch Dritte zu verhindern.   Zusätzlich empfahlen wir, alle Systeme auf dem aktuellsten Stand zu halten, um bereits bekannte Schwachstellen via Sicherheitspatches zu neutralisieren. Im konkreten Fall wurden auch die Erreichbarkeit der Dienste auf Netzwerkebene eingeschränkt, um das Risiko zu minimieren.

Für einen globalen Konzern wurde ein Re-Check einer Sicherheitsüberprüfung durchgeführt. Der Fokus lag dabei auf einer Anwendung, die komplexe Datenstrukturen visualisiert.

Bei einem Pentest-Re-Check (oder Retest) wird überprüft, ob die bei einem ersten Penetrationstest festgestellten Sicherheitsschwachstellen behoben wurden. Nachdem das Unternehmen Korrekturen vorgenommen hat, überprüfen die Testenden dieselben Bereiche erneut und überprüfen, ob die zuvor ausgenutzten Schwachstellen behoben wurden . Durch diese erneute Überprüfung wird sichergestellt, dass die Abhilfemaßnahmen wirksam waren und nicht versehentlich neue Schwachstellen eingeführt wurden. Re-Checks sind für die Aufrechterhaltung der Sicherheitslage und der Konformität unerlässlich, da sie bestätigen, dass das Risikoniveau gesenkt wurde. Ohne Re-Checks könnten ungelöste Schwachstellen fortbestehen, die Systeme ungeschützt bleiben und die Ziele und Investitionen der ursprünglichen Sicherheitsüberprüfung zunichtemachen.  

Nachdem diese Überprüfung durchgeführt wurde, wurden zusätzlich auch die Teile der Applikation untersucht, die im zuvor durchgeführten Penetrationstest keine Schwachstellen aufwiesen. Hierbei wurden mehrere Schwachstellen durch Reflected Cross-Site Scripting (XSS) identifiziert, welche es Angreifenden erlauben würde, sollten Opfer auf einen manipulierten Link klicken, Operationen im Kontext des Opfers auszuführen. Um Injektions-Schwachstellen wie XSS zu unterbinden, wird empfohlen, jeglichen Input in die Applikation zu verifizieren und die Spezialzeichen zu kodieren.

Für eine Bank führten wir ein Red Team Assessment durch, welches zum Ziel hatte realistische Angriffsszenarien nachzustellen, um unerkannt Zugriff auf das interne Netzwerk zu erlangen, ohne dass das Unternehmen beziehungsweise das interne Blue Team den Angriff erkennt.

Hierbei wurde im ersten Schritt nach Informationen über das Unternehmen mittels freiverfügbarer Quellen gesucht (OSINT). Nachdem keine gültigen Passwörter oder verwundbaren Systemen identifiziert werden konnten, wurden im nächsten Schritt Phishing-E-Mails an ausgewählte Mitarbeitende ausgesendet. Das Unternehmen war sehr gut aufgestellt und hatte eine Phishing-E-Mail erkannt sowie sofort gemeldet. Eine weitere Phishing-E-Mail wurde nicht erkannt und der Payload wurde grundsätzlich von einer mitarbeitenden Person ausgeführt, allerdings wurde die Code-Ausführung geblockt. Denn es war Mitarbeitenden auf den Systemen nicht erlaubt, neue Programme auszuführen.

Für eine weitere Analyse der internen Server wurde interne Tests von einem zur Verfügung gestellten Notebook durchgeführt. Dabei konnten mehrere Schwachstellen festgestellt werden, welche eine Rechteerweiterung ermöglichten. Auch hier war das Unternehmen sehr gut aufgestellt und das Blue Team reagierte sehr schnell auf die erhaltenen Alerts. Deshalb wurde empfohlen, die Präventions-Maßnahmen auszubauen und die internen Systeme noch weiter zu härten sowie das Sicherheitsbewusstseins bei Beschäftigten weiter zu stärken.

Für einen internationalen Konzern wurde ein Rich Client zur Verwaltung von internen Versicherungsverträgen durchgeführt. Der Fokus lag bei dieser Sicherheitsüberprüfung auf dem Ausbruch aus dem Kiosk-Modus des Clients. Dieser Client wurde von einem Drittunternehmen zur Verfügung gestellt und diente dem Unternehmen zur Verwaltung von Versicherungen  der eigenen Mitarbeitenden .

Wird dieses Worst-Case-Szenario  während des Tests erreicht, ergibt sich eine neue Angriffsfläche für potentielle Schwachstellen hinsichtlich auf die Konfiguration des zugrunde liegenden Betriebssystems. Daher werden normalerweise in dieser Kategorie von Sicherheitsüberprüfung auch das Betriebssystem und die Konfiguration und das Patch-Management überprüft .  
In diesem Fall konnte das Worst-Case-Szenario über mehrere Wege erfüllt werden. Es war möglich Microsoft-Office-Anwendungen zu starten und über die Developer-Tools ein Visual-Basic-Script zu starten, welches eine PowerShell öffnete. Ein weiterer Weg wie das Worst-Case-Szenario erfüllt wurde, war mit Hilfe des File-Explorers unter Windows, welcher es ermöglichte mittels SHIFT+Rechtsklick ein Kontextmenü zu öffnen mit dem sich ein PowerShell-Fenster öffnen ließ .

Bei Rich Clients ist es speziell wichtig alle Dateien und Programme nach dem Least-Privilege-Principle zu konfigurieren. Dies würde das Ausführen von Programmen verhindern, welche es erlauben direkt mit Teilen des Betriebssystems zu kommunizieren, welche nicht Teil der Applikation sind. 

Die interne Infrastruktur eines IT-Dienstleistungsunternehmen einer öffentlichen Stelle, sowie deren externer Perimeter wurden durch uns einer Sicherheitsüberprüfung unterzogen. Dabei waren mehrere tausend Objekte im Scope des Tests. Vor allem Schwachstellen in der Active-Directory-Konfiguration, die Konfiguration der Passwort-Policy sowie das Berechtigungskonzept weisen meist Mängel auf, die von Angreifenden ausgenützt werden können.

Bei Passwörtern und deren Account-Policies werden oft Dienstkonten vergessen und weisen des Öfteren schwache Passwörter auf, welche von Angreifenden verwendet werden können, um, mit teilweise erhöhten Berechtigungen, sich auf Systemen zu authentifizieren. Deshalb sollte immer darauf geachtet werden die Security-Best-Practices einzuhalten.

Im vorliegenden Fall wurden Network Access Accounts (NAA) identifiziert, welche verwendet wurden, um die Betriebssysteme auf den Hosts zu installieren. Das Problem dabei ist, dass der Account sich über das Netzwerk auf dem Host-System anmeldet und somit die Zugangsinformationen im Speicher des Systems landen. Diese können mit entsprechenden Berechtigungen ausgelesen werden. Diese NAA-Accounts haben, um ihre Tätigkeit durchzuführen meist erhöhte Rechte auf Systemen in der Active-Directory-Umgebung. Werden somit die Zugangsdaten ausgelesen, können Angreifende so ihre Privilegien erweitern.

Zusätzlich konnten auf Dateifreigaben Klartext-Passwörter identifiziert werden. Grundsätzlich sollte die Anzahl an Dateien auf Freigaben so gering wie möglich gehalten werden und die Berechtigungen der Dateifreigaben nach dem Least-Privilege-Principle konfigurieret werden. Des Weiteren sollten Passwörter niemals im Klartext gespeichert werden, um das Auslesen durch Unberechtigte zu unterbinden.

Für ein großes Energieunternehmen führten wir einen Grey-Box-Check durch, der sich auf die kritische Infrastruktur des Unternehmens konzentrierte. Ziel war die Identifikation von Eintrittspunkten in das OT-Netzwerk aus dem Internet beziehungsweise aus dem internen Office-Netzwerk. Zudem wurden auch physikalischen Eintrittspunkte betrachtet.

Durch die Auswertung der Firewall-Regeln wurden mehrere Systeme identifiziert, welche Zugriff auf das OT-Netzwerk hatten. Es war zwar dadurch kein direkter Zugriff möglich, über beispielsweise Code-Execution-Schwachstellen, jedoch wurden mehrere Schwächen in den Systemen und der Netzwerktrennung festgestellt. Zudem gab es im OT-Netzwerk keine weitere Segmentierung der Systeme. Dadurch genügt der Zugriff auf ein System im OT-Netzwerk, um die gesamten Systeme in der OT-Landschaft erreichen zu können.
Bei der physikalischen Begehung des Standortes wurden mehrere Schwächen identifiziert, wodurch es möglich war, mehrere Sicherheitszonen zu überwinden und in kritische Zonen zu gelangen. Angreifende könnten dadurch unbemerkt vom öffentlichen Raum bis in kritische Zonen des Unternehmens vordringen.

Deshalb wurde von uns empfohlen, die Firewall-Regeln weiter einzuschränken, die Systeme nur über zusätzlich abgesicherte Verbindungen erreichbar zu machen und das flache OT-Netzwerk zu segmentieren. Für die physikalische Sicherheit des Standortes sollten die Barrieren besser angebracht werden und die Awareness der Mitarbeitenden durch Schulungen gestärkt werden.

Für ein großes Industrieunternehmen wurde der externe Perimeter sowie die Cloud-Infrastruktur in der Form eines Grey-Box-Checks überprüft. Dabei war das Ziel Schwachstellen aus der Sicht einer externen angreifenden Person zu identifizieren und die Cloud-Infrastruktur auf Schwächen in der Konfiguration zu untersuchen.

Bei der externen Überprüfung wurde eine kritische Schwachstelle identifiziert. Das Unternehmen betrieb einen veralteten Server, der direkt über das Internet erreichbar war und  öffentlich bekannten Schwachstellen aufwies, welche zur Ausführung von Code führen können. Des Weiteren konnten einige weitere Softwareversionen mit bekannten Schachstellen sichergestellt werden. Systeme, welche den Login über unverschlüsselte Verbindungen erlauben, und weitere Konfigurations-Schwachstellen konnten im externen Perimeter sichergestellt werden. In der Cloud-Umgebung wurden ebenfalls mehrere unverschlüsselte Kommunikationswege sichergestellt. Fehlende Multi-Faktor-Authentifizierung, unverschlüsselte Datenbanksysteme, fehlende Zugriffsregeln und weitere Schwächen boten Angreifenden Möglichkeiten, um Zugriff auf schützenswerte Daten zu erhalten.

Es wurde empfohlen, den Prozess für die Aktualisierung von Systemen zu überarbeiten und die Systeme zeitnahe zu aktualisieren, vor allem  nach Bekanntwerden von kritischen Schwachstellen. Schützenswerte Daten, wie zum Beispiel Zugangsdaten, sollten nie über unverschlüsselte Verbindungen übertragen werden. Es wurde empfohlen, die Cloud-Umgebung mithilfe des CIS-Benchmarks zu härten.

Für ein großes Energieunternehmen führten wir einen Grey-Box-Check eines Energie-Management-Systems durch. Ziel war es kritische Schwachstellen in der Produkt-Lösung zu identifizieren.

Das Energie-Management-System stellt eine Client-Anwendung zur Verfügung, um mit dem System zu kommunizieren. In dieser Client-Anwendung konnte eine Buffer-Overflow-Schwachstelle identifiziert werden, welche über eine zusätzlich API ausgelöst werden konnte. Die Schwachstelle konnte, aufgrund des zeitlich begrenzten Testzeitraumes, nicht vollständig ausgenutzt werden. Eine erfolgreiche vollständige Ausnutzung der Client-Schwachstelle kann jedoch in Folge zur Kompromittierung des Energie-Management-Systems führen.

Es wurde empfohlen, sichere Funktionen in der Client-Anwendung zu verwenden und jegliche User-Eingabe sorgfältig zu validieren.

Wir wurden beauftragt die Steuersoftware für die OT (Operative Technology) eines großen Zulieferunternehmens im Energiesektor zu überprüfen. Aufgabe der Software ist es, Mitarbeitenden die Möglichkeit zu geben, über ein grafisches Interface physische Komponenten der Energieversorgung eines Landes zu steuern, zu überwachen und zu warten. Aufgrund der Kritikalität des Anwendungsfalls war es unsere Aufgabe sicherzustellen, dass die gelieferte Software, bekannt als Human Machine Inferface oder kurz HMI, geeignet war dahinterliegende Systeme vor unberechtigtem Zugriff zu schützen.

Während unserer Untersuchungen gelang es uns zahlreiche Wege zu finden, um aus dem Kiosk-Modus der HMI Anwendung auszubrechen. Wir erhielten dadurch Zugriff auf das darunterliegende System. Einer angreifenden Person hätten ab diesem Zeitpunkt zahlreiche Möglichkeiten offen gestanden, um sich weiter im geschützten Bereich des Netzwerkes auszubreiten und Schwächen in der Konfiguration der untersuchten Systeme auszunutzen. 

Unsere Empfehlungen umfassten, neben den üblichen Vorschlägen zur Verbesserung und Härtung des Systems, zielgerichtete Maßnahmen, um potentielle Angreifende bereits am Verlassen des Kiosk-Modus zu hindern. Sollte dies dennoch gelingen, sorgen Maßnahmen nach dem Security-in-Depth Prinzip dafür, dass eine angreifende Person wenig Chancen hat sich weiter im System auszubreiten. Viele diese Maßnahmen konnten relativ einfach durch Funktionalität des Betriebssystems umgesetzt werden.

Von einem Fintech-Unternehmen wurde der Auftrag erteilt, zwei Webapplikationen zu testen, ein Review der zugehörigen AWS-Cloud-Infrastruktur durchzuführen, sowie die mobilen Apps für Android und iOS zu überprüfen. Ein derart großes Projekt hat den Vorteil, dass durch den gesamtheitlichen Ansatz ein besserer Einblick in das Zusammenspiel der Komponenten, sowie deren sichere Programmierung und Konfiguration erlangt werden kann.

Im Zuge der Sicherheitsüberprüfung konnte dadurch beispielsweise im Admin-Backend eine Template-Injection-Schwachstelle identifiziert werden, welche die Ausführung von Betriebssystembefehlen erlaubte. Hier wurde empfohlen, keine bereitgestellten Daten in Templates zu inkludieren und, wenn nicht anders möglich, diese vorher zu validieren. In der mobilen App konnte außerdem die Multi-Faktor-Authentifizierung umgangen werden. Hier ist wichtig, darauf zu achten, dass es keine Schnittstellen in der Webanwendung gibt, welche den Zugriff ohne Multi-Faktor-Authentifizierung erlauben. In AWS wurden Daten unverschlüsselt vom Load Balancer übertragen, weswegen eine Verschlüsselung der Daten auf allen Übertragungswegen empfohlen wurde.

Eine enge Zusammenarbeit zwischen Personen, welche Prozesse designen und Personen, die diese in der IT umsetzen, ist von großer Bedeutung. Bei einem unserer Projekte zum Thema "Sicherheit im Zahlungsverkehr" für ein großes Industrieunternehmen konnten wir so feststellen, dass die Hauptzahlungsprozesse bereits sehr gut abgesichert waren. Nebenprozesse, wie zum Beispiel Personalzahlungen in anderen Ländern, waren jedoch noch von vielen manuellen Schritten geprägt.

Aufgrund unverschlüsselter Verbindungen zu verwendeten File Shares wäre somit ein Eingriff in den Zahlungsverkehr und dadurch eine Manipulation der Zielbankkonten in Zahlungsdateien möglich. Dies würde dazu führen, dass Überweisungen auf falsche Konten umgeleitet werden können, ohne dass es im Prozess in den späteren Schritten auffällt.

Wir empfehlen hier immer, beim Design von Prozessen darauf zu achten, dass Mitarbeitende keinen Zugriff auf Zahlungsdateien (ob bei der Speicherung oder während der Übertragung) erhalten können. Dies wird beispielsweise durch die Aktivierung von verschlüsselter Übertragung, Härtung verwendeter Systeme, sowie der Umsetzung des Principle of Least Privilege verbessert.

Für eine renommierte Bank haben wir ein umfassendes Red Team Assessment durchgeführt, das speziell auf die Identifizierung von Schwachstellen im Bereich des technischen Phishings ausgerichtet war. Ziel war es, die Angriffsfläche der Bank für Phishing-Angriffe aus der Perspektive einer angestellte Person zu testen und potenzielle Sicherheitslücken zu identifizieren, die Angreifenden den Zugang zu vertraulichen Systemen ermöglichen könnten.

Neben weiteren Schwachstellen stellte sich jedoch eine als besonders kritisch heraus: Während einer internen Überprüfung nach dem „Assume Breach“-Prinzip entdeckten wir veraltete Systemabbilder auf freigegebenen Netzlaufwerken, die für alle Domain-Konten zugänglich waren. In diesen Abbildern befanden sich die Zugangsdaten eines noch aktiven Administrationskonto, was eine erhebliche Bedrohung für die gesamte Infrastruktur darstellte.

Dieses Assessment verdeutlichte eindrucksvoll, wie wichtig es ist, kontinuierlich umfassende Sicherheitsüberprüfungen durchzuführen. Kritische Schwachstellen wie alte zugängliche Systemabbilder, zusammen mit weiteren identifizierten Risiken, dazu führen können, dass Angreifende Zugang zu vertraulichen Bereichen der IT-Infrastruktur erhalten und erheblichen Schaden anrichten. Solche Schwachstellen frühzeitig zu erkennen und zu beheben, ist entscheidend, um die Sicherheit von IT-Systemen langfristig zu gewährleisten.

Für ein großes Software-Unternehmen wurde ein Datenbank-Management-System für Gebäude auf Schwachstellen untersucht. Dabei wurde ein Red-Team-Ansatz durchgeführt und bei dem das Blue Team nicht darüber informiert wurde , dass eine Überprüfung durchgeführt wird. Der Ausgangspunkt für das Test-Szenario war der Fall eines gestohlenen Notebooks.

Im Zuge der Überprüfung konnten mehrere Schwachstellen identifiziert  werden. Über eine unverschlüsselte Verbindung auf einen höheren Port wurden Zugangsdaten unverschlüsselt übertragen. Die auf dem System laufenden Anwendungen wurde in JAVA geschrieben und waren auf Deserialisierungs-Schwachstellen anfällig, welche zur Ausführung von Code führen können. Nach Absprache mit dem auftraggebenden Unternehmen wurde die Ausführung von Code hier unterlassen, da es sich um ein Produktivsystem handelte. Des Weiteren wurden Cross-Site-Scripting-Schwachstellen, veraltet Software und Schwachstellen zur Erweiterung der Rechte festgestellt. Die Aktivitäten lösten keine Alarmierung aus und die Testenden konnten somit vor dem Blue Team verborgen handeln.

Es wurde empfohlen, nur verschlüsselte Verbindungen zu verwenden, Patches für die Mitigierung von Deserialisierungs-Schwachstellen sowie Softwareupdate einzuspielen, jegliche Usereingabe zu bereinigen und zu codieren, und das System weiter zu härten. Zusätzlich wurde empfohlen, die Alarmierung und die Erkennung auf den Notebooks zu schärfen.

Ein globales Technologieunternehmen führte ein Purple Team Assessment durch, bei dem die Tester aus einer "Assume Compromise"-Position agierten. Dazu erhielten sie Zugriff auf ein Windows-Notebook im Firmennetzwerk sowie auf einen Linux-Server, um von innen heraus Angriffe zu simulieren. Der Schwerpunkt lag auf der Erkennung von Angriffen und der Kommunikation mit dem IT-Security-Team des Unternehmens.

Ein besonders bemerkenswertes Ergebnis dieses Assessments war die Konfiguration eines Windows-Dienstes auf allen Clients, die eine Privilege Escalation von einem normalen Benutzer zu einem Administrator wie aus dem Lehrbuch ermöglichte. Durch dieses Assessment konnte das IT-Security-Team daher nicht nur seine Erkennungsmaßnahmen testen und in einem realistischen Szenario trainieren, sondern es wurden auch kritische Schwachstellen aufgedeckt.

Da öffentliche Infrastruktur alle betrifft, ist es umso wichtiger potenzielle Schwachstellen in diesem Bereich frühzeitig zu erkennen und Behebung dieser zu ermöglichen. Deshalb wurden wir von einem Unternehmen für eine Sicherheitsüberprüfung der IT- und OT-Umgebung beauftragt, der zusätzlich einen Review der in der Cloud betriebenen Teile der Infrastruktur inkludierte.

Im Zuge des Projekts wurden von unterschiedlichen Entwicklungsunternehmen  hergestellte Applikationen überprüft, die für die Kommunikation zwischen kritischen Infrastruktur-Teilen eingesetzt wird. Um ebenfalls die Sicherheit der Umgebung beurteilen zu können, wurde eine Überprüfung des Netzwerks vorgenommen. Aus Effizienzgründen wurde dabei der erste Schritt, Kompromittieren der Umgebung, ausgelassen und sofort von einem bereitgestellten Client aus getestet („Assume-Breach-Assessment“).

Der Test zeigte, dass robuste Prozesse vor allem bei länger bestehenden Umgebungen das „A“ und „O“ sind. Daher wurden neben technischen Verbesserungsmaßnahmen ebenfalls ein Review und der Ausbau des Patch-Management-Prozesses sowie der Umgang mit Accounts angeraten. Bezüglich der Cloud-Umgebung hat sich gezeigt, dass Standardeinstellungen in den letzten Jahren zwar sicherer werden, jedoch nicht blind darauf vertraut werden sollte und einige Maßnahmen nach wie vor auf die Umgebung abgestimmt werden müssen.

Für ein Energie-Unternehmen wurde eine Überprüfung des externen Perimeters und verwendeten Firewalls durchgeführt. Der externe Perimeter war dabei gut abgesichert und es konnte nur die Verwendung von veralteten kryptographischen Algorithmen identifiziert werden.

Die Firewall-Analyse wurde als Konfigurations-Review durchgeführt, bei dem keine praktischen Angriffe getätigt werden, jedoch innerhalb von kurzer Zeit viele Einstellungen erhoben werden können. Durch den Review konnten Schwachstellen aufgedeckt werden, die durch ein Update der Firewall auf aktuelle Software, Aktivierung der Verschlüsselung für Kommunikationsverbindung von und zur Firewall, sowie eine Einschränkung von Firewall-Regeln behoben werden konnten.

Gemeinsam mit unserem Partnerunternehmen Schwabe, Ley und Greiner (SLG) führen wir Überprüfungen der Zahlungsprozesse von Unternehmen durch. Die Kolleg:innen von SLG sind dabei für den prozessualen Teil zuständig und geben Verbesserungsvorschläge diesbezüglich. Wir übernehmen den technischen Teil und versuchen Wege aufzudecken, wie Zahlungen manipuliert und umgeleitet werden können. Durch die Kombination aus Prozesswissen und Technik können hierbei neue technische Angriffsmöglichkeiten identifiziert werden.

Für ein großer deutsches Unternehmen im Wohnungs- und Industriebau wurde ein solches Assessment durchgeführt. Bei einer stichpunktartigen Kontrolle der Passwortqualität des ERP- und des TMS-Systems wurde festgestellt, dass einige schwache Passwörter in Verwendung waren. Bei einem schwachen Datenbankpasswort kann dies dazu führen, dass sämtliche in den Anwendungen vorhandenen Sicherheitsvorkehrungen umgangen werden können und interne Angreifende direkt auf die Datenbank Zugriff erlangen können. Eine solche Schwachstelle kann auch leicht die Modifikation von Zahlungsdaten zur Folge haben, was zu manipulierten Überweisungen führen kann.

Oft sehen wir, dass zum Beispiel für Datenbanksysteme beim Aufsetzen ein schwaches Passwort vergeben wird, das später nicht mehr geändert wird und somit dann in der Produktivumgebung im Einsatz ist. Deshalb empfehlen wir auch einen speziellen Augenmerk auf Datenbankpasswörter sowie SAP-System-Accounts zu legen, da diese bei der Etablierung von Passwort-Policys gerne vergessen werden.

Bei der Überprüfung einer Webapplikation für HR-Dienstleistungen eines globalen Konzerns wurden mehrere kritische Sicherheitslücken entdeckt. Es war möglich, die Authentifizierung zu umgehen und dadurch Adminrechte zu erlangen. Darüber hinaus konnte bei der automatisierten Prüfung der Webapplikation ein Denial-of-Service-Zustand (DoS) erzeugt werden, der nur durch das Eingreifen des Backend-Teams behoben werden konnte.

Dieses Assessment unterstreicht die Bedeutung der Kombination von automatisierten Tools und manueller Überprüfung. Ohne diese ganzheitliche Herangehensweise könnten kritische Schwachstellen unentdeckt bleiben und im schlimmsten Fall während eines Angriffs ausgenutzt werden.

Online-Shopping und Kunden-Support – beinahe jeder kennt diese Dinge aus dem Alltag und in der Industrie-Branche spielen diese Themen ebenfalls eine Rolle. Zum Beispiel wenn ein Industrie-Unternehmen zwei Portale zu den jeweiligen Themen betreibt und für die sichere Erfahrung mit den beiden Diensten eine regelmäßige Überprüfung anstrebt bzw. benötigt. Dass eine regelmäßige Prüfung – und vor allem auch eine Überprüfung der umgesetzten Maßnahmen – sinnvoll ist, ging in diesem Fall besonders hervor.

Denn zum Anlass der Zusammenlegung der Portale wurde ein erneuter Test von HACKNER Security durchgeführt und kam zum Ergebnis, dass bestehende Maßnahmen zwar teilweise eingeschränkt, aber am Ende doch nicht ganz behoben wurden.

Aufgrund geplanter Infrastrukturänderungen wurde ebenfalls der verwendete Reverse-Proxy geprüft, bei welchem zusätzliche Schwachstellen (hier jedoch frühzeitig) identifiziert und entsprechende Empfehlungen zu deren Behebung ausgearbeitet werden konnten.

Wir wurden von einem global tätigen Pharmakonzern mit einem externen IT-Red-Teaming beauftragt. Im Gegensatz zu einem typischen Red-Teaming gab es dabei Einschränkungen im Scope: Social Engineering (einschließlich Phishing) sowie physischer Zugang waren vom Test ausgeschlossen. Das bedeutet, dass das testende Team einen Weg über die externe IT-Infrastruktur ins Unternehmen finden musste. Weitere Angriffe innerhalb des internen Netzwerks waren ebenfalls nicht Teil des Scopes.

Das Assessment begann mit einer OSINT (Open Source Intelligence)-Phase, in der Informationen aus öffentlich zugänglichen Quellen gesammelt wurden. Dazu gehörten IP-Adressen, Domains, E-Mail-Adressen, Passwörter sowie andere unternehmensrelevante Informationen. Die Unternehmensgröße spiegelte sich dabei in der Menge der verfügbaren Informationen wider. Anschließend begann die nächste Phase, in der potenzielle Angriffsvektoren aus dem Internet ermittelt wurden. Aufgrund der großen externen IT-Landschaft des Kunden wurde vor jedem tatsächlichen Angriff eine kurze Abstimmung durchgeführt, um sicherzustellen, dass keine kritischen oder Out-of-Scope-Systeme angegriffen wurden.

Im Verlauf des Red-Teamings konnte mittels geleakter Zugangsdaten ein administrativer Zugriff auf eine Webapplikation erlangt werden. Diese Webapplikation ermöglichte den Zugriff auf die Backend-Datenbank. Aufgrund diverser Einschränkungen war es jedoch nicht möglich, Shell-Zugriff auf das System zu erhalten.

Wie lässt sich so etwas verhindern? Geleakte Passwörter sind für Angreifende nur solange nützlich, solange die Passwörter noch gültig sind. Deshalb ist es wichtig, Tools und Dienste zu nutzen, die kontinuierlich das Darknet und andere Quellen nach geleakten Zugangsdaten durchsuchen und Warnungen ausgeben, wenn Unternehmensdaten betroffen sind. Zusätzlich sollte besonderes Augenmerk auf Legacy-Systeme gelegt werden, die möglicherweise nicht mit der zentralen Userdatenbank verbunden sind.

Eine Webapplikation zum Erstellen und Verwalten von Veranstaltungen eines Unternehmens im Bereich IT Services wurde überprüft. Weiters sollte auch die nachfolgende Version der Webapplikation geprüft werden.

Da die Hauptfunktion solcher Anwendungen das Verschicken von Einladungen zu Events ist, wurde als Hauptangriffsvektor der Versuch andere Gäste via Phishing anzugreifen, um Daten zu erlangen, festgelegt. Zusätzlich sollte, wie bei jeder Applikation, darauf geachtet werden, dass die Anwendung nicht durch beispielsweise Injection-Angriffe direkt attackiert werden kann.

Der Test zeigte, dass die bestehende Applikation bereits sehr robust war, die neue jedoch noch ein paar Schwachstellen enthielt, die bei der Entwicklung übersehen wurden. Diese Erfahrung zeigt, dass bei Neuentwicklungen immer Probleme auftauchen können, auch wenn bisherige Produkte bereits beinahe makellos waren.

Wer kennt es nicht? Viele (potenzielle) Kund:innen, eine lange Liste von Verträgen und Produkten sowie keine Lust auf Excel-Tabellen. Genau dieses Problem hatte eines unserer beauftragenden Unternehmen, weshalb eine Applikation zur Verwaltung der Informationen entwickelt und von HACKNER Security getestet wurde, um deren Sicherheitsniveau zu erheben und Verbesserungsmaßnahmen zu geben.

Da die Verträge auch durch die jeweiligen Vertragspartner einsehbar waren, war vorrangig das Autorisierungssystem im Fokus der Überprüfung. Schließlich will niemand, dass plötzlich andere Preise als verhandelt im Vertrag eingefügt werden oder Unbefugte Zugriff auf Daten von Vertragspartnern bekommen!

Die Veränderung von Daten konnte während des Tests zwar nicht erreicht werden, die Überprüfung hat sich jedoch trotzdem gelohnt, da, neben anderen Schwachstellen, die Möglichkeit identifiziert wurde, unberechtigt Verträge anderer Vertragsparteien einzusehen. Wie immer wurden entsprechende Lösungen für das gegebene Szenario erhoben und entsprechend mit dem auftraggebenden Unternehmen besprochen.

Ein großes deutsches Klinikum beauftragte uns einen externen Black-Box-Check durchzuführen. Hauptaugenmerk lag dabei auf dem Scan von 15 IP-Adressen.

Zuerst führten wir einen Portscan durch, um die Dienste auf den Servern zu erkennen. Als wir diese Dienste genauer untersuchten, fanden wir bekannte Schwachstellen (u.a. eine Server-Spoofing-Schwachstelle am Exchange-Server). Auch gab es Schwachstellen, die so gut wie immer vorhanden sind. Im Sinne von Defense-in-Depth ist das Aufzeigen dieser jedoch genauso wichtig: Hierbei fielen uns ungültige Zertifikate, schwache TLS Cipher Suites und die Preisgabe von Informationen auf.

Wir empfahlen das Update der alten Systeme auf die neueste Version, sowie eine Härtung der externen Dienste (verbesserte kryptographische Algorithmen für Ciphers Suites, Verwendung von gültigen Zertifikaten und Einschränkungen der preisgegeben Informationen).

Systeme im OT-Bereich haben oft hohe Sicherheitsanforderungen, da ein Ausfall des Systems schwerwiegende Konsequenzen haben könnte. Wir haben im Rahmen einer Sicherheitsüberprüfung ein Steuerungsgerät getestet, dass im Energiesektor eingesetzt wird.

Das Gerät kann über einen Touchscreen bedient werden. Durch Zuhilfenahme von Maus und Tastatur war es hier möglich, aus dem eingeschränkten Kioskmodus auszubrechen und vollständigen Zugriff auf das Gerät zu erlangen. Über ein proprietäres Protokoll konnte zusätzlich über das Netzwerk mit einem Standardaccount Admin-Zugriff erlangt werden.

Für den Ausbruch aus dem Kioskmodus wurde die Deaktivierung der Verwendung von Peripheriegeräten empfohlen. Zusätzlich sollte am verwendeten Betriebssystem darauf geachtet werden, dass keine Anwendungen (z.B. eine Linux-Konsole) geöffnet werden können. Für den Angriffsvektor über das Netzwerk wurde eine Einschränkung der Berechtigungen des Standardaccounts empfohlen, damit dieser nicht auf Funktionalitäten zugreifen kann, welche für den Betrieb gefährlich sein können.

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.

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. 

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. 

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.

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.

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. 

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.

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.

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 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. 

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.

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.

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!

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.

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.