Tim Mackey, Principal Security Strategist bei Synopsys, berichtet im Interview von seinen Erfahrungen mit Credential Theft. [...]
Welchen Stellenwert hat Credential Theft, also der Missbrauch von Zugangsdaten, wenn man die Angriffsfläche eines durchschnittlichen Unternehmens zugrunde legt? Wie groß ist das Problem tatsächlich?
[Tim Mackey] Die nahezu komplette Umstellung auf Remote Working hat vieles verändert. Für einen CISO heißt das, er hat hoffentlich alle Sicherheitsanforderungen in Sachen Zugangsdaten überprüft und die damit assoziierten Bedrohungsmodelle aktualisiert. Warum ist das wichtig? Weil die üblicherweise zugrunde liegenden Bedrohungsmodelle vermutlich eine geschützte Büroumgebung voraussetzen. Und genau diese Voraussetzungen haben sich entscheidend verändert. Bedrohungsmodelle sollten die veränderten Arbeitsbedingungen mit einbeziehen. Dazu gehört auch das Zugriffsmanagement für Notebooks, Tablets und so weiter. Anschließend gilt es die Zugriffskontrollen zu überprüfen, um legitime von illegitimen Zugriffsversuchen zu unterscheiden.
Um welche Art von Angriffen handelt es sich? Credential Stuffing auf Basis von geleakten Datenbanken? Reine Brute-Force-Attacken? Welche Methoden werden sonst noch häufig verwendet?
[Tim Mackey] Brute-Force- und Wörterbuch-Angriffe spielen nach wie vor eine Rolle. Bei einer überwiegend remote tätigen Belegschaft sollte man sich aber eher auf Social Engineering und die diversen Phishing-Varianten, wie etwa Spear-Phishing, konzentrieren. Ein Unternehmen macht beispielsweise publik, die Büros für einen bestimmten Zeitraum zu schließen, oder wenn es gibt einen regionalen Lockdown. Cyberkriminelle können dann auf Daten aus früheren Angriffen zurückgreifen und Mitarbeiter identifizieren, die vermutlich ins Home Office gewechselt haben und diese gezielt ins Visier nehmen. Es stehen ungeheure Mengen an gehackten Daten zur Verfügung. Angesichts dessen, welchen Wert geschäftliche Daten haben, sollten Firmen sämtliche Zugriffsberechtigungen anhand des Mitarbeiterprofils überprüfen, um unübliche Verhaltens- und Nutzungsmuster zu erkennen.
Welche möglichen Auswirkungen hat der Missbrauch von Zugangsdaten?
[Tim Mackey] Der Missbrauch von Zugangsdaten öffnet einer ganzen Reihe verschiedener Angriffe Tür und Tor. Wenn man den Schaden begrenzen will, kommt man nicht umhin, den Zugriff auf Daten entsprechend dem jeweiligen Zweck richtig zu segmentieren. Dazu gehört es auch, zu überprüfen, ob ein bestimmtes Rechtelevel eventuell mit erweiterten Privilegien einhergeht. Zeichnet ein Mitarbeiter etwa für das Erstellen von Berichten und die Analyse von Trends verantwortlich, dann sollten die Standardzugriffsberechtigungen genau auf diesen Arbeitsbereich begrenzt sein. Das gilt auch für den Zugriff auf die jeweiligen Datenfelder. Muss der Mitarbeiter einen Datensatz aktualisieren, ist das eine atypische Aktion, die eine andere Art von Zugriffsberechtigung erfordern (und dementsprechend überprüft werden sollte). Ein System sollte immer so ausgelegt sein, dass es bei alltäglichen Aufgaben nur minimale Reibungspunkte aufweist, bei selten auftretenden Aktionen aber Prüfungen erfordert.
Sind bestimmte Bereiche oder Unternehmenstypen eher anfällig als andere? Wenn ja, warum?
[Tim Mackey] Angreifer legen die Regeln fest, und das Ziel sind zunehmend Daten, die sich verkaufen lassen. Welche Daten das im Einzelfall sind, mag unterschiedlich sein. Transaktionsverläufe, Geschäftsgeheimnisse, Kundenlisten, Mitarbeiterdaten, Zugangsdaten für die Cloud, Produktdesigns – das alles sind ausgesprochen wertvolle Daten. In einigen Fällen bestimmen die verfügbaren Daten dann auch die zukünftigen Phasen eines Angriffs, z. B. die Installation von Software, um Daten in Echtzeit auf Server der Angreifer zu spiegeln oder für Crypto-Mining.
Inwieweit ist nur das Benutzerkonto selbst gefährdet oder wo kommen erweiterte Rechte/Privilegien zum Einsatz?
[Tim Mackey] Meist ist das individuelle Benutzerkonto das Sprungbrett in einer ganzen Kette von Ereignissen. Ein Konto mit niedrigen Privilegien kann z.B. für den einfachen Zugriff auf Daten verwendet werden. Es kann aber für einen Social-Engineering-Angriff auf einen Mitarbeiter mit höheren Zugriffsrechten benutzt werden.
Warum haben 2FA oder MFA dieses Problem nicht lösen können? Liegt es an der unzureichenden Implementierung oder gibt es technologische Grenzen?
[Tim Mackey] Die erste MFA-Regel lautet: Wo sie verfügbar ist, sollte man sie nutzen. Gibt es Ausnahmen, wie einen Superadministrator, der vielleicht Autorisierungssysteme konfigurieren muss, sollte dieses Konto nicht für den normalen alltäglichen Betrieb verwendet und intensiv geprüft werden. In einer Unternehmenskultur, in der Administratoren, Entwickler oder Führungskräfte von der MFA ausgenommen sind, sollten CISOs sich nicht scheuen auf das erhöhte Geschäftsrisiko hinzuweisen und ausgleichende Kontrollen wie intensive Nutzungsprüfungen einziehen.
Ist Rate Limiting, also die Begrenzung der Durchsatzraten eine Antwort auf diese Art von Angriffen oder sind Cyberkriminelle längst in der Lage solche Methoden zu umgehen?
[Tim Mackey] Rate Limiting ist eine durchaus sinnvolle Maßnahme. Man sollte aber nicht aus den Augen verlieren, dass die Angreifer, die Regeln des Angriffs festlegen. Erkennt ein Angreifer etwa, dass eine Rate Limiting ein Konto deaktiviert, kann er dieses Wissen nutzen, um DoS-Benutzerkonten einzurichten und den IT-Betrieb zu stören. Regionale Begrenzungen sind hier die bessere Wahl: wenn ein Unternehmen z.B. nur Niederlassungen in Großbritannien hat, dann sollte ein Zugriff von außerhalb Großbritanniens nur ausnahmsweise erfolgen. Rate Limiting und IP-Ursprungskarten tragen dazu bei, Authentifizierungsversuche von aggressiven IP-Adressen zu blockieren, während man gleichzeitig die Illusion einer funktionierenden Webseite vermittelt.
Erhöht der Missbrauch von Zugangsdaten angesichts der zunehmenden API-Verbreitung das Risiko? Wenn ja, auf welche Weise?
[Tim Mackey] APIs werden verwendet, um von einer Software auf eine andere zuzugreifen. Ein sicherer Zugriff lässt sich am besten dadurch gewährleisten, dass ein Satz von Anmeldeinformationen eines Benutzers in einen Token umgewandelt wird. Dieser wird von der Anwendung generiert, die die API bereitstellt. Verwendet man einen Token für den Zugriff, werden weder Benutzername noch Passwort weitergegeben. Sollte der Token kompromittiert werden, ist der genaue Zugriffsbereich nicht bekannt. In der Regel werden solche Tokens nicht ungültig, wenn das Passwort geändert wird. Ein Token ermöglicht also weiterhin den Zugriff und überdauert eine Passwortänderung. Allerdings auch dann, wenn das Benutzerkonto kompromittiert wird. Besteht Grund zu der Annahme, dass der Zugriffstoken kompromittiert wurde, sollte der Aussteller den Token widerrufen und einen neuen ausstellen.
Wie begrenzt man am besten den potenziellen Missbrauch von APIs?
[Tim Mackey] Bei der Entwicklung einer API ist eine der ersten Fragen, die man sich stellen sollte, wie die Autorisierung von statten gehen soll. Einfache Stateless APIs verwenden möglicherweise für jede Anfrage ein Zugriffstoken, während komplexe APIs von einem Autorisierungsrahmen wie OAuth2 profitieren. Ist das Autorisierungsmodell definiert, sollten Designer ihre Aufmerksamkeit auf das Bereichsmanagement lenken. Tatsächlich ist das Ziel, genau festzulegen, welche Berechtigungslevel für bestimmte Aufgaben nötig sind und wie das zugehörige Datenmodell aussieht. Beispielsweise verfügt ein System für die Bestellabwicklung über eine API, die eine Liste früherer Käufe bereitstellt, aber auch eine separate API, die die Lieferadresse für jede Bestellung vorhält. Diese Datensegmentierung definiert eine Sicherheitsgrenze. Die Versanddetails erfordern dabei ein höheres Berechtigungslevel als andere Bereiche.
Wir können Unternehmen generell das Risiko senken?
[Tim Mackey] Man sollte den Prozessen Vorrang einräumen, die es erleichtern, auf Vorfälle zu reagieren. Dazu braucht man ein klares Verständnis darüber, wo die Autorisierung bei jeder Anwendung erfolgt und welche Art von Authentifizierungsoptionen vorhanden sein könnten – einschließlich von Details zum Beispiel zum Wiederherstellen von Konten. Von da aus arbeitet man sich weiter vor und überprüft die existierenden Audit-Kapazitäten. Immer mit dem Ziel, mit möglichst aktuellen Bedrohungsmodellen zu arbeiten.
Worin liegen die größten Herausforderungen für Unternehmen bei der Implementierung von Lösungen?
[Tim Mackey] Ist eine Implementierung zu kompliziert, versuchen Anwender fast zwangsläufig, sie zu umgehen. Das wohl bekannteste Beispiel sind komplexe Passwörter und die Regelung von Änderungsintervallen. Noch immer schreiben Mitarbeiter ihre Passwörter auf oder zählen ein Ziffern-Suffix hoch. Wenn man weiß, wo die Schwachstellen eines Systems liegen, sollte man angemessen planen, um sie zu beheben. Das ist schon rein budgettechnisch sinnvoll. Deswegen sollte man sein Augenmerk auf verbesserungswürdige Bereiche lenken, wenn man mit einem Bedrohungsmodell oder der Simulation eines Incident Recovery beginnt. Sollte es tatsächlich zu einem Datenschutzvorfall kommen, wird man ohnehin in Maßnahmen investieren, die eine Wiederholung verhindern sollen. Warum also nicht schon im Vorfeld die nötigen Tests durchführen und Investitionen priorisieren, statt erst im Nachgang?
Was kann man speziell in Bezug auf APIs tun, um sie besser als bisher zu schützen?
[Tim Mackey] APIs muss man anders betrachten als die übrigen Formen des Datenzugriffs. Im Grunde handelt es sich um eine Machine-to-Machine-Schnittstelle. Sie sollte als solche reaktionsfähig sein und Daten zurückgeben, die dann Teil eines weiteren API-Aufrufs sein können. Rate Limiting spielt an dieser Stelle eine Schlüsselrolle, gleiches gilt für den Umfang der Daten, ihren Geltungsbereich und den gleichzeitigen Zugriff darauf. API-Endpunkte sollten alle erforderlichen Elemente validieren – einschließlich der MIME-Typen – und auch, ob die damit verbundenen Rechte tatsächlich korrekt sind und mit den Berechtigungen der genutzten Token übereinstimmen. Sollte das nicht der Fall sein, sollte eine Fehlermeldung („Fehlerhafte Daten“) zurückgegeben werden. Mit anderen Worten, API-Entwickler sollten davon ausgehen, dass sich Angriffe zunächst gegen diese Annahmen und Dokumentationen richten. Sie sollten aber vor allem wissen, dass alle zusätzlichen und nicht dokumentierten Datenelemente für jeden Angreifer von Natur aus interessanter sind.
Be the first to comment