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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.