安全代码的洞察

Der XML External Entity Injection-Angriff, manchmal einfach als XXE-Injection abgekürzt, ist relativ neu im Vergleich zu einigen der klassischen Sicherheitslücken, die Jahre nach ihrer Einführung immer noch die Runde machen. Aber er ist derzeit bei Hacker-Communities extrem beliebt und wächst mit zunehmender Erfolgsrate noch mehr.

Tatsächlich listet OWASP die XXE-Injektion jetzt als eine der zehn häufigsten Sicherheitslücken auf, auf die Websites achten und gegen die sie sich aktiv verteidigen müssen. Aber keine Sorge, die XXE-Injektion ist nicht leistungsfähiger als andere Exploits, die bei Cyberangriffen eingesetzt werden. Es ist nur ein bisschen neuer und ein bisschen weniger verstanden. Es kann verhindert und sogar vollständig gestoppt werden.

In dieser Folge werden wir lernen:

• Wie Angreifer XXE-Injektionen verwenden
• Warum die XXE-Injektion gefährlich ist
• Techniken, die diese Sicherheitsanfälligkeit verhindern können.

Wie lösen Angreifer eine XXE-Injektion aus?

Die XXE-Injection-Schwachstelle kann auftreten, wenn einem böswilligen Benutzer die Möglichkeit gegeben wird, XML-Code einzureichen. Sie nutzen diese Fähigkeit, um einen Verweis auf eine externe Entität zu erstellen. Die externe Referenz und der Code sind so konzipiert, dass sie an einem XML-Parser mit Standardeinstellungen oder einem Parser mit schwach konfigurierten Einstellungen vorbeirutschen.

Der Angreifer nutzt die Tatsache aus, dass der XML-Standard das Konzept einer Entität als Speichereinheit eines bestimmten Typs definiert, dieser Speicher jedoch extern oder intern sein kann. Richtig eingesetzt, kann er XML-Prozessoren den Zugriff auf Remote-Ressourcen ermöglichen. In den meisten Fällen nutzen Angreifer diese Fähigkeit, um stattdessen Dinge wie die interne Struktur einer Website zu untersuchen, einen Denial-of-Service-Angriff zu starten, indem sie große Systemprozesse auslösen, die versuchen, auf Remote-Ressourcen zuzugreifen, oder um sogar Daten von einem lokalen Host auf einen von ihnen kontrollierten Remote-Host zu übertragen. "Dies ist eine gute Technik, um wichtige Daten wie Passwörter oder persönliche Informationen in der XML-Datenbank zu extrahieren.

Der eigentliche Code, der an dem Angriff beteiligt ist, ist oft ziemlich simpel und nutzt lediglich die Entitätsfunktionalität aus. Dies könnte beispielsweise einem Hacker den Zugriff auf die Master-Passwortdatei ermöglichen:

<!

Warum ist die XXE-Injektion gefährlich?

Es gibt einige Gründe, warum XXE-Injection-Angriffe so gefährlich und auch häufig sind. Zum einen handelt es sich derzeit um eine weniger bekannte Sicherheitslücke. Und die Gewinne, die ein Angreifer erzielen kann, wenn er sie ausnutzt, sind beträchtlich. Zum einen kann es hartnäckigen Angreifern ermöglichen, langsam alle Pfade in einem internen Netzwerk abzubilden oder sogar Ports zu scannen. Dies kann zwar einige Zeit in Anspruch nehmen, aber es besteht fast keine Chance, dass die Aktivitäten eines Hackers durch aktive Abwehrmaßnahmen im Zielnetzwerk aufgedeckt werden, da er lediglich XML-Code an einen Server sendet, der gerade vom vertrauenswürdigen XML-Parser gelöscht wird.

Sobald die Angreifer die Karten gefunden haben, können sie dieselben XXE-Injection-Techniken verwenden, um alle benötigten Dateien abzufangen. Dabei können sie entweder direkt Informationen stehlen oder gültige Benutzeranmeldeinformationen kompromittieren und sie für sekundäre Angriffe verwenden. Schließlich können Angreifer, die einfach nur Lärm machen und bösartig sein wollen, Dinge wie Denial-of-Service-Angriffe auslösen und der Anwendung befehlen, auf entfernte Ressourcen zuzugreifen, um das System zum Stillstand zu bringen.

Beseitigung der XXE-Injection-Schwachstelle

Aufgrund der raschen Zunahme von XXE-Injection-Angriffen beginnen viele XML-Parser, externe Entitäten, manchmal DTDs genannt, standardmäßig vollständig zu deaktivieren. Für diese liegt der Schlüssel einfach darin, diese Funktionalität nicht zu aktivieren.

Aber selbst bei Parsern, die DTDs zulassen, kann diese Funktionalität deaktiviert werden. Im Allgemeinen wird eine Anweisung wie die folgende benötigt, um sie vollständig zu blockieren, aber schauen Sie in Ihrer lokalen Framework-Dokumentation nach, um den genauen Code zu erhalten, der benötigt wird.

factory.setFeature (“ http://apache.org/xml/features/disallow-doctype-decl „, wahr);

Gemäß den Sicherheitsprinzipien sollten alle Benutzereingaben mithilfe von anwendungsweiten Filtern bereinigt und validiert werden. Vergessen Sie nicht, GET- und POST-Parameter, HTTP-Header und Cookies einzubeziehen. Sie können auch eine Whitelist mit bestimmten DTDs und Befehlen erstellen, die der Parser verarbeiten soll, und alles andere verbieten.

Whitelisting und Filtern funktionieren zwar, aber aufgrund der steigenden Anzahl von XXE-Injection-Angriffen wird dennoch empfohlen, die DTD-Unterstützung vollständig zu deaktivieren, wenn die Funktionalität nicht benötigt wird.

Weitere Informationen zu XXE-Injektionen

Zum weiteren Lesen können Sie sich ansehen, was OWASP dazu sagt XXE-Injektionsangriffe. Sie können Ihr neu gewonnenes Defensivwissen auch auf die Probe stellen mit dem kostenlose Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Blog von Secure Code Warrior.

Einfach ausgedrückt ist SQL (oder Structured Query Language) die Sprache, die für die Kommunikation mit relationalen Datenbanken verwendet wird; es ist die Abfragesprache, die von Entwicklern, Datenbankadministratoren und Anwendungen zur Verwaltung der täglich werden riesige Datenmengen generiert.

Unsere Daten werden schnell zu einem der wertvollsten Rohstoffe der Welt... und wenn etwas wertvoll ist, werden Bösewichte es zu ihrem Vorteil in die Hände bekommen wollen.

Angreifer verwenden SQL-Injection -- eine der ältesten (seit 1998!) und die lästigsten Datenlücken, die es gibt — zum Stehlen und Ändern vertraulicher Informationen, die in Millionen von Datenbanken auf der ganzen Welt verfügbar sind. Es ist heimtückisch, und Entwickler müssen verstehen, wie SQL-Injection funktioniert (und wie wir uns davor schützen können), wenn wir unsere Daten schützen wollen.

Zu diesem Zweck werden wir drei wichtige Aspekte der SQL-Injection erörtern:

• 操作方法
• Warum es so gefährlich ist
• Wie kann man sich dagegen wehren

Verstehen Sie SQL Injection

SQL-Injection kann mit einem Wort verstanden werden: Kontext.

Innerhalb einer Anwendung gibt es zwei Kontexte: einen für Daten, den anderen für Code. Der Codekontext teilt dem Computer mit, was ausgeführt werden soll, und trennt ihn von den zu verarbeitenden Daten.

Eine SQL-Injection tritt auf, wenn ein Angreifer Daten eingibt, die vom SQL-Interpreter fälschlicherweise als Code behandelt werden.

Ein Beispiel ist ein Eingabefeld auf einer Website, in das ein Angreifer '“ OR 1=1" eingibt und es an das Ende einer SQL-Abfrage angehängt wird. Wenn diese Abfrage ausgeführt wird, gibt sie für jede Zeile in der Datenbank „true“ zurück. Das bedeutet, dass alle Datensätze aus der abgefragten Tabelle zurückgegeben werden.

Die Auswirkungen der SQL-Injection können katastrophal sein. Tritt dies auf einer Anmeldeseite auf, werden möglicherweise alle Benutzerdatensätze zurückgegeben, möglicherweise einschließlich Benutzernamen und Kennwörtern. Wenn eine einfache Abfrage zum Herausnehmen von Daten erfolgreich ist, gilt dies auch für Abfragen zum Ändern von Daten.

Schauen wir uns einen anfälligen Code an, damit Sie sehen können, wie eine SQL-Injection-Schwachstelle in der Natur aussieht.

Schau dir diesen Code an:

Zeichenkettenabfrage = „WÄHLEN SIE DEN KONTOSTAND VON user_data WHERE user_name =“
+ request.getParameter („Kundenname“);
versuche {
Anweisungsanweisung = Connection.createStatement (...);
ResultSet-Ergebnisse = Statement.executeQuery (Abfrage);
}

Der Code hier hängt einfach die Parameterinformationen vom Client ohne Validierung an das Ende der SQL-Abfrage an. In diesem Fall kann ein Angreifer Code in ein Eingabefeld oder URL-Parameter eingeben und dieser wird ausgeführt.

Das Wichtigste ist nicht, dass Angreifer jeder SELECT-Abfrage nur '“ OR 1=1" hinzufügen können, sondern dass ein Angreifer jede Art von SQL-Abfrage (INSERT, UPDATE, DELETE, DROP usw.) manipulieren und sie um alles erweitern kann, was die Datenbank unterstützt. Es gibt großartige Ressourcen und öffentlich verfügbare Tools, die zeigen, was möglich ist.

Wir werden bald lernen, wie wir dieses Problem beheben können. Lassen Sie uns zunächst verstehen, wie viel Schaden angerichtet werden kann.

Warum SQL Injection so gefährlich ist

Hier sind nur drei Beispiele für Sicherheitslücken, die durch SQL-Injection verursacht wurden:

• Website des Wahlausschusses von Illinois wurde verletzt aufgrund von SQL-Injection-Schwachstellen. Die Angreifer stahlen die persönlichen Daten von 200.000 US-Bürgern. Aufgrund der Art der festgestellten Sicherheitslücke hätten die Angreifer die Daten ebenfalls ändern können, obwohl sie dies nicht getan haben.
• Hetzner, ein südafrikanisches Website-Hosting-Unternehmen, wurde verletzt in Höhe von 40.000 Kundendatensätzen. Eine SQL-Injection-Schwachstelle führte zum möglichen Diebstahl aller Kundendatensätze in ihrer Datenbank.
• Ein katholischer Finanzdienstleister in Minnesota, Vereinigte Staaten, wurde verletzt mit SQL Injection. Kontodaten, einschließlich Kontonummern, von fast 130.000 Kunden wurden gestohlen.

Sensible Daten können verwendet werden, um Konten zu übernehmen, Passwörter zurückzusetzen, Geld zu stehlen oder Betrug zu begehen.

Sogar Informationen, die nicht als sensibel oder persönlich identifizierbar gelten, können für andere Angriffe verwendet werden. Adressinformationen oder die letzten vier Ziffern Ihrer behördlichen Identifikationsnummer können verwendet werden, um sich bei Unternehmen als Sie auszugeben oder Ihr Passwort zurückzusetzen.

Wenn ein Angriff erfolgreich ist, können Kunden das Vertrauen in das Unternehmen verlieren. Die Wiederherstellung nach Systemschäden oder behördlichen Bußgeldern kann Millionen von Dollar kosten.

Aber für dich muss es nicht so enden.

Besiege SQL Injection

Die SQL-Injection kann verhindert werden, indem Teile Ihrer Anwendung eindeutig gekennzeichnet werden, sodass der Computer weiß, ob es sich bei einem bestimmten Teil um Daten oder Code handelt, der ausgeführt werden muss. Dies kann mithilfe parametrisierter Abfragen erfolgen.

Wenn SQL-Abfragen Parameter verwenden, verwendet der SQL-Interpreter die Parameter nur als Daten. Er führt ihn nicht als Code aus.

Beispielsweise funktioniert ein Angriff wie '“ OR 1=1" nicht. Die Datenbank sucht nach der Zeichenfolge „OR 1=1" und findet sie nicht in der Datenbank. Es zuckt einfach mit den Achseln und sagt: „Entschuldigung, ich kann das nicht für dich finden.“

Ein Beispiel für eine parametrisierte Abfrage in Java sieht so aus:

Die meisten Entwicklungsframeworks bieten integrierte Schutzmaßnahmen gegen SQL-Injection.

Objektrelationale Mapper (ORMs), wie Entitätsframework in der .NET-Familie parametrisiert Abfragen standardmäßig. Dadurch wird die SQL-Injektion erledigt, ohne dass Sie sich darum kümmern müssen.

Sie müssen jedoch wissen, wie Ihr spezielles ORM funktioniert. Zum Beispiel Überwintern, ein beliebtes ORM in der Java-Welt, kann immer noch verwundbar sein bei falscher Verwendung zur SQL-Injection.

Die Parametrisierung von Abfragen ist die erste und beste Verteidigung, aber es gibt noch andere. Gespeicherte Prozeduren unterstützen auch SQL-Parameter und können verwendet werden, um eine SQL-Injektion zu verhindern. Beachten Sie, dass die gespeicherten Prozeduren muss auch richtig gebaut werden damit das funktioniert.

//Das sollte auch WIRKLICH validiert werden
Zeichenfolge customname = request.getParameter („customerName“);
//Eingabevalidierung durchführen, um Angriffe zu erkennen
Zeichenkettenabfrage = „WÄHLEN SIE account_balance AUS user_data AUS WO user_name =? „;

PreparedStatement pstmt = Connection.PreparedStatement (Abfrage);
pstmt.setString (1, benutzerdefinierter Name);
ResultSet-Ergebnisse = pstmt.executeQuery ();

Validieren und desinfizieren Sie Ihre Eingaben immer. Da einige Zeichen, wie z. B. „OR 1=1", nicht von einem legitimen Benutzer Ihrer Anwendung eingegeben werden, müssen Sie sie nicht zulassen. Sie können dem Benutzer eine Fehlermeldung anzeigen oder sie aus Ihrer Eingabe entfernen, bevor Sie sie verarbeiten.

Verlassen Sie sich dabei nicht allein auf Validierung und Desinfektion, um sich zu schützen. Kluge Menschen haben Wege gefunden, das zu umgehen. Das sind gute Defense-in-Depth-Strategien (DiD), aber Parametrisierung ist der todsichere Weg, um alle Grundlagen abzudecken.

Eine weitere gute DiD-Strategie besteht darin, die „geringsten Rechte“ innerhalb der Datenbank zu verwenden und Eingaben auf die Whitelist zu setzen. Die Durchsetzung der geringsten Rechte bedeutet, dass Ihre Anwendung innerhalb der Datenbank nicht über unbegrenzte Funktionen verfügt. Sollte sich ein Angreifer Zugriff verschaffen, ist der Schaden, den er anrichten kann, begrenzt.

OWASP hat eine großartige Spickzettel für SQL-Injection verfügbar, um zu zeigen, wie man mit dieser Sicherheitslücke in mehreren Sprachen und Plattformen umgeht... aber wenn Sie noch einen Schritt weiter gehen möchten, können Sie jetzt auf unserer Plattform eine SQL Injection-Challenge in Ihrer bevorzugten Sprache spielen; hier sind einige der beliebtesten, um loszulegen:

SQL-Injektion in C#

SQL-Injektion in Node.js

SQL-Injektion in Python Django

SQL-Injektion in Java Spring

Die Reise beginnt

Sie haben große Fortschritte beim Verständnis von SQL Injection und den zur Behebung des Problems erforderlichen Schritte erzielt. Fantastisch!

Wir haben besprochen, wie eine SQL-Injection abläuft. In der Regel verwendet ein Angreifer Eingaben, um Ihre Datenbankabfragen für seine eigenen schändlichen Zwecke zu steuern.

Wir haben auch den Schaden gesehen, der durch die Ausnutzung von SQL-Injection-Schwachstellen verursacht wird: Konten können kompromittiert werden und Millionen von Dollar verloren gehen... ein Albtraum und noch dazu ein teurer.

Wir haben gesehen, wie eine SQL-Injektion verhindert werden kann:

• Parametrisierung von Abfragen
• Verwenden objektrelationaler Mapper und gespeicherter Prozeduren
• Benutzereingaben validieren und auf die Whitelist setzen

Jetzt liegt es an dir. Üben ist der beste Weg, um weiter zu lernen und sich weiterzuentwickeln. Schauen Sie sich doch unsere an Ressourcen zum Lernen auf SQL Injection, dann probiere unsere kostenlose Demo von der Plattform? Du bist auf dem besten Weg, ein Secure Code Warrior zu werden.

XQuery-Injection-Angriffe werden manchmal als der kleine Bruder der verbreiteteren angesehen. SQL-Injection-Angriffe. Sie haben ähnliche Ursachen, und die Befehle, die Angreifer nutzen, um sie beide auszulösen, sind ebenfalls sehr ähnlich. Es ist nur so, dass XQuery-Injection-Angriffe nur während einer XPath-Abfrage für XML-Daten auftreten können. Aus diesem Grund werden sie manchmal als XPath Injection oder einfach als XPath-Angriffe bezeichnet, da dies die verwendete Übermittlungsmethode ist.

Eine große Mehrheit der Websites verwendet XML-Datenbanken, um wichtige Funktionen wie das Speichern von Benutzeranmeldedaten, Kundeninformationen, persönlichen Identitätsinformationen und vertraulichen oder sensiblen Daten auszuführen, sodass XQuery-Angriffe einen ziemlich großen Angriffsfußabdruck haben.

In dieser Episode werden wir lernen:

• Wie Angreifer XQuery-Injektionen verwenden
• Warum XQuery-Injektionen gefährlich sind
• Techniken, mit denen diese Sicherheitsanfälligkeit behoben werden kann.

Wie lösen Angreifer eine XQuery-Injection aus?

Wie bei den meisten Computersprachen wurde der Code für XPath aus Gründen der Einfachheit entworfen. Tatsächlich ist XPath eine Standardsprache, und alle Notationen und Syntaxanweisungen sind unverändert, unabhängig davon, welche Anwendung sie verwendet. Das bedeutet, dass die Befehle, die zur Manipulation einer XPath-Abfrage verwendet werden, allgemein bekannt sind und sogar automatisiert werden können.

Im Kern ist eine XPath-Abfrage eine einfache Anweisung, die der XML-Datenbank mitteilt, welche Informationen gesucht werden sollen. In einem der einfachsten Beispiele wird es verwendet, um zu überprüfen, ob ein Benutzerdatensatz existiert, und dann, um seine Anmeldeinformationen abzurufen. Da XPath-Abfragen Benutzereingaben enthalten, können Hacker die Abfrage manipulieren, um Informationen zurückzugeben, die geschützt werden sollten.

Wenn ein Angreifer beispielsweise versucht, die Anmeldesicherheit zu umgehen, kann er am Ende seiner XPath-Abfrage Variablen hinzufügen, die den gesamten Prozess umgehen. Ein Beispiel könnte so aussehen:

//Mitarbeiter [Benutzername/text () =irgendjemand oder 1=1 oder a=a Und Passwort/text () =spielt keine Rolle]

Hier wird das Feld Benutzername so gestaltet, dass es aufgrund der 1=1- oder a=a-Anweisung jedem Benutzer entspricht. Das Passwortfeld spielt keine Rolle, da nur der erste Teil der Abfrage wahr sein muss.

Warum ist XQuery Injection gefährlich?

Ein Hauptgrund dafür, dass XQuery-Injection-Angriffe so gefährlich sind, liegt darin, dass sie es Angreifern ermöglichen, die Anmelde- und Kontosicherheit zu umgehen. Und sie ermöglichen eine automatisierte Ausführung mithilfe einer Standardsprache, die sich je nach Anwendung nicht unterscheidet. Angreifer können Websites und Anwendungen automatisch nach dieser Sicherheitslücke durchsuchen und handeln, sobald sie entdeckt wird. Wenn Ihre App anfällig ist, werden die Angreifer sie kompromittieren. XQuery-Angriffe gefährden nicht nur die Kontosicherheit, sondern können auch zur Datenexfiltration verwendet werden. Ein Angreifer könnte beispielsweise alle Datensätze aus der XML-Datenbank übertragen.

Eliminierung von XQuery-Injection-Angriffen

Wie bei ähnlichen Sicherheitslücken besteht eine wichtige Abwehr darin, Benutzereingaben einfach nicht zu vertrauen. Jedes Mal, wenn ein Benutzer Informationen eingeben kann, unabhängig davon, ob er eine Datenbankabfrage stellt oder nicht, sollte der Vorgang genau unter die Lupe genommen werden. Es ist nicht anders, als die Fenster und Türen eines physischen Gebäudes zu sichern, da dies die Hauptwege sind, über die sich Menschen Zugang verschaffen können.

Für den XQuery-Injektionsschutz erfolgt dies durch Bereinigen von Benutzereingaben durch Filtern oder durch eine Whitelist-Eingabevalidierung von Benutzereingaben. Sie können auch eine parametrisierte XPath-Schnittstelle verwenden, ähnlich wie vorbereitete Anweisungen für SQL-Abfragen.

Stellen Sie abschließend sicher, dass Sie allen Anwendungen die geringsten Rechte zuweisen. Das könnte bedeuten, dass Sie einen Benutzer mit Leseberechtigungen erstellen müssen, der alle Anwendungsabfragen ausführen kann.

Mithilfe dieser Techniken ist es möglich, alle XQuery-Injection-Versuche gegen Ihre Website oder Anwendung zu stoppen.

Weitere Informationen zu XQuery Injections

Für weitere Informationen können Sie sich ansehen, was OWASP über XQuery Injections sagt. Sie können Ihr neu gewonnenes Defensivwissen auch mit einem auf die Probe stellen kostenlose Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Sicherer Code Krieger Blog.

Forscher von VirginiaTech veröffentlichten eine Papier nach der Analyse von Hunderten von Beiträgen im beliebtesten Entwicklerforum (Stack Overflow). Sie befassten sich mit der Art der Fragen, die zum Thema Sicherheit gestellt werden, mit den beliebtesten Antworten der Community und mit den Auswirkungen, die dies auf Programmierer hat.

Keine wirkliche Überraschung für Leute, die schon eine Weile im Bereich Cybersicherheit tätig sind, aber aus Entwicklersicht ist mehr Bewusstsein für dieses Problem erforderlich:

• Sicherheitsfunktionen, die von Coding-Frameworks (z. B. JAVA Spring) bereitgestellt werden, sind zu kompliziert und schlecht dokumentiert
• Eine beträchtliche Anzahl von Entwicklern scheint die Auswirkungen von Codierungsoptionen auf die Sicherheit nicht zu verstehen, was auf einen Mangel an Cybersicherheitsschulungen hindeutet
• Viele der Vorschläge und „Korrekturen“ in diesen Foren sind nicht sicher, aber wir haben positive Stimmen erhalten und somit höhere Bewertungen.

Der Bericht schlägt die folgenden Lösungen vor:

• Umschulung der Belegschaft
• Halbautomatische Erkennung und Behebung von Sicherheitslücken

Wir müssen die Sicherheit für Entwickler einfach und von Anfang an integrieren, um die Geschwindigkeit aufrechtzuerhalten, mit der Unternehmen heute arbeiten.

„Die Bedeutung dieser Arbeit besteht darin, dass wir empirische Beweise für eine erhebliche Anzahl alarmierender Probleme mit der sicheren Codierung geliefert haben, über die bisher nicht berichtet wurde“, heißt es in dem Artikel. „Diese Probleme haben eine Vielzahl von Gründen, darunter den schnell steigenden Bedarf an Sicherheitsanwendungen für Unternehmen, den Mangel an Sicherheitsschulungen der Mitarbeiter in der Softwareentwicklung und schlecht konzipierte Sicherheitsbibliotheken.“

https://www.theregister.com/2017/09/29/java_security_plagued_stack_overflow/

Eine Version dieses Artikels erschien ursprünglich in DevOps Digest. Es wurde hier aktualisiert und syndiziert.

An diesem Punkt bin ich mir sicher, dass wir alle des Ausdrucks „in diesen beispiellosen Zeiten“ ein wenig überdrüssig werden... aber dies sind wirklich beispiellose Zeiten. Wer hätte Ende letzten Jahres gedacht, dass wir in diesem Jahr einen Wettlauf um die Bekämpfung einer global zerstörerischen Pandemie machen und alles in unserer Macht Stehende darauf verwenden würden? Es wäre fast lächerlich erschienen und eher einer neuen Netflix-Science-Fiction-Serie als Teil unserer weltweiten Realität ähnlich. COVID-19 hat unser soziales Leben, unsere Wirtschaft und unsere Arbeitsplatzsicherheit völlig verändert, ganz zu schweigen von den politischen Prioritäten.

Einer der Gegenangriffe gegen COVID-19 erfolgte durch Technologie. Viele Länder haben Apps zur Kontaktverfolgung eingeführt. In Australien gibt es CovidSafe nach dem Vorbild von TraceTogether aus Singapur. Hongkong, Taiwan, China, Südkorea, Israel und Deutschland haben alle eine Technologie zur Kontaktverfolgung implementiert oder sind auf dem Weg. Großbritannien war mit Zehntausenden von Todesfällen im Zusammenhang mit Viren und einer hohen Infektionsrate die am stärksten betroffene Region in Europa. Die Veröffentlichung ihrer App steht unmittelbar bevor. In den USA, die ebenfalls tief betroffen sind, weil viele Menschen auf tragische Weise ihr Leben verloren haben, werden ebenfalls Technologien eingeführt, aber ihr Ansatz zur Kontaktverfolgung von Bundesstaat zu Bundesstaat macht ihre Situation ziemlich komplex.

Mit Ausnahme von stärker staatlich kontrollierten Ländern wie China und Taiwan ist die Nutzung dieser Apps freiwillig, sodass die Bürger die Technologie von sich aus herunterladen und verwenden müssen. Einige sind erfolgreicher als andere. Beispielsweise hatte die TraceTogether-App in Singapur eine Akzeptanzrate von 25%, was sie für den gewünschten Zweck ziemlich ineffektiv macht.

Die Idee hinter Apps zur Kontaktverfolgung ist solide. Wenn diese Technologie gut funktioniert, würde sie sicherstellen, dass Hotspots schnell erkannt werden und umfassende Tests durchgeführt werden können — beides wichtige Komponenten zur Bekämpfung der Ausbreitung eines ansteckenden Virus. Die Worte „Regierung“ und „Rückverfolgung“ klingen jedoch nicht gerade sehr einladend, und es ist natürlich, dass die Leute vorsichtig sind, was das Herunterladen von so etwas für sie bedeuten würde.

Also, was sind die Hauptanliegen der Nutzer? Wenn man sich auf Online-Kommentare verlassen kann, gehören zu diesen Bedenken:

• Mangelndes Vertrauen in die Regierung, die gesammelten Daten verantwortungsbewusst zu verwenden
• Befürchtungen darüber, wie gut personenbezogene Daten vor Cyberangriffen geschützt werden
• Unklarheit darüber, welche Daten tatsächlich gesammelt werden, wo sie gespeichert werden und mit wem
• ... und für die Entwickler/Geeks unter uns, wie solide die Apps tatsächlich gebaut sind.

Es ist immer ein bisschen besorgniserregend, wenn Apps schnell erstellt werden und diese Apps zur Kontaktverfolgung in Rekordzeit eingeführt werden müssen. Es ist ein Albtraum für Entwickler, Sicherheitspersonal und Regierungsbehörden.

Also, ist Misstrauen eine gültige Reaktion? Und was sollten wir bei unserer Bewertung der COVID-19-Apps zur Kontaktverfolgung und der Sicherheit der Endbenutzer als Priorität betrachten? Als Sicherheitsexperte geht es mir natürlich instinktiv darum, die Cybersicherheitselemente des Programms genauer unter die Lupe zu nehmen, nämlich wie sicher die Codebasis für eine App ist, zu deren Installation wir alle (aus besten Absichten) gedrängt werden.

Viele der Apps sind Kopien voneinander (und erben dieselben Probleme).

Australiens COVIDSafe-App basiert im Wesentlichen auf Rennen öffnen, ebenso wie Singapurs TraceTogether-Software. Das Problem ist jedoch, dass bei TraceTogether eine Reihe von Problemen gemeldet wurden und diese nur schlecht genutzt wurden. Nur 25 Prozent der Bevölkerung meldeten sich als Benutzer an — weit weniger als 75% sind erforderlich, damit es wirksam ist. Es gab Beschwerden über die allgemeine Leistung, insbesondere unter iOS, einschließlich der sehr schnellen Entleerung der Batterien. CovidSafe hat eine potenzieller UX-Fehler in der iOS-Version, wobei das Telefon entsperrt und die App im Vordergrund ausgeführt werden muss, um alle Daten ordnungsgemäß aufzuzeichnen.

Die oben genannten Probleme sind zwar ärgerlich, die dringendere Sorge ist jedoch, dass Bluetooth-Schwachstellen weit verbreitet sind und weder TraceTogether noch das australische Unternehmen COVIDSafe davor gefeit sind. Am 14. Mai NIST berichtete, dass COVIDSafe eine Denial-of-Service-Sicherheitslücke aufwies, sodass ein Angreifer die App aus der Ferne zum Absturz bringen kann, wenn er sich in Bluetooth-Handshake-Entfernung befindet. Auf diese Weise könnte ein organisierter Angriff die Kontaktverfolgung in dicht besiedelten Gebieten stören, wo sie am nützlichsten ist — etwas ausführlich erklärt vom Sicherheitsforscher Richard Nelson. Es ist bekannt, dass es CovidSafe, TraceTogether, ProteGo aus Polen und AbtraceTogether aus Kanada betrifft — alle erben das Problem von OpenTrace Manudata.Unterdaten anrufen.

Es gibt auch andere Datenschutz- und Sicherheitsprobleme im Zusammenhang mit der Bluetooth-Funktionalität im Allgemeinen. Die Tatsache, dass diese Technologie verwendet wird, um menschliche Bewegungen anhand einer eindeutigen ID (TempID) nachzuverfolgen und aussagekräftige Daten zu sammeln, wird unweigerlich ein gesteigertes Interesse an Angriffen zur Folge haben. Zu welchem Zeitpunkt genau, was erfasst wird, wo es gespeichert wird und für wie lange, muss unter die Lupe genommen werden.

Einige Apps zeigen bereits Anzeichen einfacher Fehler, die zu komplexen Schwächen führen.

Australischer Softwareingenieur Geoffrey Huntley hat den Quellcode von COVIDSafe studiert, und leider gibt es Probleme, die uns, den Endbenutzern, nicht unbedingt bewusst gemacht werden.

Ein kritisches Beispiel war ein logischer Fehler, der es einem Angreifer ermöglichen würde, Geräte langfristig zu verfolgen. Dies stellt ein enormes Risiko für gefährdete Benutzer dar, ganz zu schweigen davon, dass es gegen die Datenschutzrichtlinie der App selbst verstößt.

Es ist wichtig zu beachten, dass diese logischen Sicherheitslücken am 14. Mai gepatcht wurden, aber das dringendere Problem ist, dass sie 17 Tage lang ungepatcht blieben, nachdem Herr Huntley sie gemeldet hatte. Er und andere Mitglieder der großartigen Sicherheitsgemeinschaft verfolgen CVEs im Zusammenhang mit der COVIDSafe-App hier.

Eine Sache, auf die Huntley nach dem Patch hinweist, ist, dass selbst der Fix Anzeichen von, nun ja, Inkompetenz aufweist. In seiner Öffentlichkeit Log, stellt er fest, dass der Patch das Hinzufügen von Logik beinhaltete, anstatt einfach einen fehlerhaften Cache zu löschen, wobei letzteres eine weitaus robustere Lösung darstellt. Beides funktioniert, aber der Live-Lösung mangelt es an Finesse — ein Problem bei einer so wichtigen Anwendung.

Obwohl wir fleißige Mitglieder der Gesellschaft haben, die ihre eigene Zeit und ihr Fachwissen nutzen, um den Quellcode zu durchforsten und Probleme aufzuzeigen, ist ihre Arbeit viel schwieriger, als wenn der Code von Anfang an Open Source wäre. So wie es aussieht, 28 Apps sind immer noch für Sicherheitsforscher gesperrt.

Die sichere Codierung bringt uns an der Ziellinie immer wieder zum Stolpern.

Ich kann zwar durchaus Verständnis für überlastete Entwickler haben — ebenso wie für die höchst ungewöhnliche Situation, inmitten einer Pandemie eine lebensrettende App herausbringen zu müssen — aber das oben Gesagte sollte verdeutlichen, dass ein paar einfache Sicherheitslücken in einer im Wesentlichen gemeinsamen Codebasis zu erheblichen Problemen für Millionen von Benutzern führen können.

Ich würde gerne glauben, dass die meisten Menschen gute Bürger sein, die App unterstützen und allen die bestmögliche Chance geben wollen, Kontakte zu verfolgen und Ausbrüche dieses schrecklichen Virus zu kontrollieren. Auch ich unterstütze Technologien, die dazu beitragen können, dies zu erreichen, aber in vielerlei Hinsicht hat dies den allgemeinen Mangel an sicheren Codierungsprinzipien aufgedeckt, der Entwicklern auf der ganzen Welt innewohnt.

In jeder Situation, in der Software schnell geschrieben werden muss, sind Fehler nicht gerade unerwartet. Häufig auftretende Sicherheitslücken wie Logikfehler, Fehlkonfigurationen und Codeinjektionsfehler sollten jedoch bereits beim Schreiben des Codes verhindert werden können, und nicht erst, nachdem freiwillige White Hats die Codebasis auseinandergenommen haben.

Und es ist übrigens nicht die Schuld der Entwickler. Sie verlassen ihre Hochschulausbildung mit geringen Kenntnissen in sicherem Programmieren, und in ihrer Karriere beziehen sich ihre KPIs fast immer auf die Funktionalität der Funktionen und die Geschwindigkeit der Bereitstellung — um den Sicherheitsaspekt muss sich jemand anderes kümmern, wenn sie fertig sind. Wir müssen schnell einen Endzustand der sicheren Codierung erreichen, und obwohl jetzt nicht der richtige Zeitpunkt ist, um in den Abteilungen, die diese Apps entwickeln, seismische Veränderungen vorzunehmen, ist dies eine rechtzeitige Erinnerung daran, dass unser digitaler Risikobereich expandiert und sie in der Poleposition sind, um etwas zu bewirken, wenn sie die Tools und das Wissen erhalten, um gemeinsam die Verantwortung für bewährte Sicherheitsverfahren zu übernehmen.

Ist es sicher, die App herunterzuladen?

Hier ist die Sache: Für mich, einen Sicherheitsfachmann, bin ich zu dem Schluss gekommen, dass die Vorteile der App die Probleme überwiegen. Es ist nicht ideal, dass die oben genannten Sicherheitslücken in dieser Software vorhanden sind oder waren, aber die Auswirkungen, wenn sie als Waffe eingesetzt werden, sind Worst-Case-Szenarien. Gegenwärtig ist die Kontaktverfolgung ein wichtiger Bestandteil, um unsere medizinischen Helden auf der ganzen Welt dabei zu unterstützen, die Ausbreitung einzudämmen, den Zustrom von Krankenhauseinweisungen einzudämmen und sich gegenseitig so sicher wie möglich zu schützen.

Es dient dazu, hervorzuheben, dass wir eine lang Ein weiter Weg, wenn es darum geht, bewährte Sicherheitsmethoden standardmäßig in einem Software-Build umzusetzen, und es ist wichtig, dass die Öffentlichkeit über die Informationen verfügt, die sie benötigt, um fundierte Entscheidungen zu treffen.

Meine Familie und ich werden es weiterhin verwenden, obwohl wir wachsam bleiben, um mit unseren Android-Patches auf dem Laufenden zu bleiben, wie wir es alle sollten.

Ein Betriebssystem-Command-Injection-Angriff kann immer dann erfolgen, wenn eine Anwendung Benutzern erlaubt, Eingaben in eine Shell vorzunehmen, aber keine Maßnahmen ergreift, um zu überprüfen, ob die Eingabezeichenfolgen gültig sind. Auf diese Weise kann ein Angreifer Befehle direkt in das Betriebssystem übertragen, das die Anwendung hostet, und zwar mit den für die gefährdeten Anwendungen festgelegten Berechtigungsstufen.

OS-Command-Injection-Angriffe können von Anfängern und weniger erfahrenen Hackern ausgeführt werden, was sie zu einer der häufigsten Schwachstellen von Sicherheitsteams macht. Zum Glück gibt es einige sehr effektive Möglichkeiten, um zu verhindern, dass sie erfolgreich sind. In dieser Episode werden wir lernen:

So funktionieren sie

Warum sie so gefährlich sind

Wie Sie Abwehrmechanismen einrichten können, um sie zu stoppen.

Wie verwenden Angreifer OS Command Injection?

Das erste, was ein Angreifer tun muss, um einen Betriebssystem-Command-Injection-Angriff zu starten, ist, Benutzereingaben innerhalb einer Anwendung zu lokalisieren. Formulare, die Benutzer ausfüllen, sind potenziell gute Ausgangspunkte. Die cleversten Angreifer können auch Dinge wie Cookies oder sogar HTTP-Header als Ausgangspunkt verwenden, was von fast jeder Anwendung oder Website verwendet wird.

Das zweite, was sie tun müssen, ist herauszufinden, welches Betriebssystem die Anwendung hostet. Angesichts der Tatsache, dass es nur eine Handvoll Auswahlmöglichkeiten gibt, können Versuch und Irrtum in dieser Phase gut funktionieren. Die meisten Anwendungsserver werden entweder Windows-basiert sein (die Art von Windows spielt normalerweise keine Rolle), irgendeine Art von Linux-Box oder möglicherweise Unix.

An diesem Punkt ändert der Hacker die Eingabe, um einen Betriebssystembefehl in eine scheinbar harmlose Eingabe einzufügen. Dies kann das Hosting-Betriebssystem dazu verleiten, unbeabsichtigte Befehle auf jeder Berechtigungsstufe der Anwendung auszuführen.

Beispielsweise kann der folgende Befehl von gültigen Benutzern innerhalb einer Anwendung verwendet werden, um den Inhalt einer Datei anzuzeigen, in diesem Fall die Notizen einer monatlichen Vorstandssitzung.

exec („cat" + Dateiname)

In unserem Beispiel würde dies den folgenden Befehl ausführen und die Besprechungsnotizen an den Benutzer zurückgeben.

$. /cat MeetingNotes.txt

Bei der Juli-Sitzung waren drei Mitglieder des Exekutivausschusses anwesend. Das neue Haushaltsprojekt wurde erörtert, es wurden jedoch keine Maßnahmen ergriffen oder Abstimmungen getroffen.

Dies passiert, wenn ein Angreifer am Ende der Eingabe zusätzliche Befehle hinzufügt, z. B. den Befehl, der zum Auflisten des Inhalts eines Verzeichnisses unter Linux verwendet wird. In diesem Fall wird immer noch der ursprüngliche Befehl ausgeführt, der die Besprechungsnotizen anzeigt. Dem böswilligen Benutzer wird aber auch angezeigt, was sich sonst noch in dem Verzeichnis befindet und welche anderen Befehle er bei nachfolgenden Angriffen auf Betriebssystembefehle verwenden kann. Sie geben ein:

$. /cat MeetingNotes.txt && ls

Und hol dir stattdessen das:

Bei der Juli-Sitzung waren drei Mitglieder des Exekutivausschusses anwesend. Das neue Haushaltsprojekt wurde erörtert, es wurden jedoch keine Maßnahmen ergriffen oder Abstimmungen getroffen.

MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
formatieren.c
falsch. C
kein Fehler. C
trunk.c
schreib was woher.c

Wie Sie sehen können, wurde dem Hacker in diesem Fall nicht nur der Inhalt des Verzeichnisses angezeigt, sondern auch ein Menü mit anderen Befehlen angezeigt, mit denen er "Befehle verwenden konnte, von denen sie jetzt wissen, dass sie sie auf dem Host-Betriebssystem ausführen können.

Warum sind OS Command Injection-Angriffe so gefährlich?

Es ist äußerst riskant, Benutzern zu erlauben, den Zweck der Zielanwendung zu umgehen und sie zum Ausführen von Betriebssystembefehlen zu verwenden. Ein Angreifer kann leicht verheerende Aktionen ausführen, wie zum Beispiel vertrauliche Daten stehlen oder ein ganzes Serverlaufwerk formatieren. Die Optionen, die einem Angreifer zur Verfügung stehen, werden nur durch die zulässigen Befehle innerhalb des Betriebssystems und durch seine Kreativität bei der Verwendung dieser Befehle eingeschränkt.

Betriebssystembefehle werden auf derselben Berechtigungsstufe wie die Anwendung ausgeführt. Apps, die mit Administratorrechten ausgeführt werden, bedeuten, dass Hacker, die sie kompromittieren, jeden Betriebssystembefehl ausführen können.

Die Angriffsmuster für OS Command Injection sind bekannt und dokumentiert. Eine anfällige Anwendung ist für Script-Kiddies genauso anfällig wie für professionelle Hacker. Angreifer mit sehr geringen Fähigkeiten können versuchen, Betriebssystembefehle auszuschneiden und in Anwendungen einzufügen, um zu sehen, was passiert.

Ein Sicherheits-OK gegen Betriebssystem-Befehlsinjektionen erhalten

Es gibt mehrere gute Techniken, mit denen Betriebssystembefehle verhindert werden können. Der erste Schritt besteht darin, Anwendungen mit den geringsten Rechten auszuführen, die für die Ausführung ihrer Funktion erforderlich sind. Dadurch wird ein Angriff nicht verhindert, sollte es dennoch zu einer Sicherheitsverletzung kommen, wird der Schaden minimiert.

Die meisten Programmiersprachen und Frameworks bieten API-Aufrufe für gängige Betriebssystemmethoden wie das Auflisten von Verzeichnisinhalten, das Erstellen oder Lesen von Dateien auf der Festplatte. Eine perfekte Methode, um Betriebssystembefehle aus Ihrer Umgebung zu eliminieren, besteht darin, dass alle Anwendungen diese API-Aufrufe anstelle der Betriebssystembefehle direkt verwenden.

Wenn dies nicht möglich ist, überprüfen Sie Benutzereingaben, bevor Sie sie in Betriebssystembefehlen verwenden. Whitelists können verwendet werden, um sicherzustellen, dass nur ein kleiner Satz vertrauenswürdiger Werte verwendet werden kann. Es ist technisch möglich, dies auch mit einer Blacklist zu tun, aber es gibt wahrscheinlich viel weniger zulässige Befehle, sodass das Whitelisting fast immer einfacher ist. Vergessen Sie nicht, gültige POST- und GET-Parameter sowie häufig übersehene Benutzereingabevektoren wie Cookies in Ihre Whitelist aufzunehmen.

Wenn keine Programmier-API verfügbar ist und eine Whitelist nicht verwendet werden kann, verwenden Sie schließlich eine Sanitisierungsbibliothek, um alle Sonderzeichen in Benutzereingaben zu maskieren, bevor Sie sie in Betriebssystembefehlen verwenden.

Weitere Informationen zu OS Command Injection-Angriffen

Für weitere Informationen können Sie sich die OWASP ansehen schreiben Sie auf Angriffe mit Betriebssystem-Befehlsinjektion. Sie können Ihr neu gewonnenes Defensivwissen auch mit dem auf die Probe stellen kostenlose Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Sicherer Code Warrior-Blog.

Stellen Sie sich vor, Sie gehen zur Tür eines alten Speakeasy- oder Underground-Clubs. Das kleine Loch in der Tür öffnet sich und ein stämmiger Türsteher fragt nach dem Passwort. Der potenzielle Besucher kennt das Passwort nicht und rätselt es. Es ist falsch, also lässt der Türsteher sie nicht rein.

Das würde normalerweise passieren. Stellen Sie sich nun vor, der Besucher, der das falsche Passwort erraten hat, versucht es sofort erneut, versteht es falsch und ihm wird erneut der Zugriff verweigert. Stellen Sie sich dann vor, der potenzielle Besucher öffnet das Wörterbuch und beginnt, Wörter vorzulesen. Er beginnt mit etwas wie Erdferkel und probiert jedes einzelne mögliche Wort aus.

Höchstwahrscheinlich würde der Bouncer solche Aktivitäten nicht zulassen, aber Websites und Anwendungen mit unzureichender Anti-Automatisierung tun genau das. Sie ermöglichen es Benutzern, Passwörter immer wieder auszuprobieren, sogar mithilfe von Automatisierungstechniken, bis sie schließlich auf das richtige Schlagwort stoßen.

In dieser Episode werden wir lernen:

• Wie Angreifer unzureichende Anti-Automatisierung ausnutzen
• Warum Anwendungen mit unzureichender Antiautomatisierung gefährlich sind
• Techniken, mit denen diese Sicherheitsanfälligkeit behoben werden kann.

Wie nutzen Angreifer unzureichende Anti-Automatisierung aus?

Der Einsatz von Automatisierung oder Angriffen im Wörterbuchstil, wie es unser imaginärer Speakeasy-Besucher getan hat, ist in der Cybersicherheit nichts Neues. Tatsächlich gehörten diese Angriffe im Brute-Force-Stil zu den ersten Hackertechniken, die jemals eingesetzt wurden. Und als Computer schneller wuchsen, wurden sie immer effizienter. Ein schneller Computer kann in nur wenigen Minuten ein ganzes Wörterbuch von Wörtern durchgehen, abhängig von der Geschwindigkeit der Verbindung zwischen dem Angriffscomputer und dem Zielsystem.

Diese Art von automatisierten Angriffen war der Grund, warum Anti-Automatisierungssoftware und -techniken entwickelt wurden. Es gibt Anwendungen die Möglichkeit, festzustellen, ob die von einem Benutzer ausgeführten Aktionen nicht den Normen des typischen menschlichen Verhaltens entsprechen.

Wenn eine Anwendung über unzureichende Antiautomatisierungsprüfungen verfügt, können Angreifer Passwörter einfach weiter erraten, bis sie eine Übereinstimmung finden. Oder sie verwenden Automatisierungssoftware, um andere Dinge wie Spam-Kommentare in Website-Foren zu erledigen.

Warum ist ein unzureichender Automatisierungsschutz gefährlich?

Es kann gefährlich sein, böswilligen Benutzern zu erlauben, mithilfe von Automatisierung zu versuchen, Sicherheitsvorkehrungen zu umgehen. Der Grund dafür, dass Angriffe vom Typ Automatisierung seit den Anfängen der Computertechnik bis heute andauern, ist, dass sie sehr effektiv sein können. Wenn Sie einem Automatisierungsprogramm eine unbegrenzte Zeit geben, um Passwörter einzureichen, ohne dass eine falsche Vermutung Konsequenzen hat, wird es irgendwann das richtige finden.

Wenn es in einem Forum verwendet wird, können Wellen von offensichtlich geskripteten Kommentaren legitime Benutzer frustrieren oder sogar wie eine Art Denial-of-Service-Angriff wirken, bei dem Systemressourcen verschwendet werden. Automatisiertes Posten kann auch als Tool für Phishing- oder andere Angriffe verwendet werden, um die Köder so vielen Menschen wie möglich zugänglich zu machen.

Behebung unzureichender Anti-Automatisierungsprobleme

Um das Problem der unzureichenden Antiautomatisierung zu lösen, müssen alle Anwendungen in der Lage sein, festzustellen, ob die ergriffenen Maßnahmen von einem Menschen oder einer Automatisierungssoftware implementiert werden. Eine der beliebtesten und am weitesten verbreiteten Techniken ist die Vollständig automatisierter öffentlicher Turing-Test, um Computer und Menschen voneinander zu unterscheiden, oder CAPTCHA.

Das CAPTCHA ist im Grunde ein Turing-Test, erstmals 1950 vom Informatiker Alan Turing vorgeschlagen, wodurch das Verhalten von Mensch und Computer getrennt und identifiziert werden kann. Moderne CAPTCHAs stellen Probleme dar, die Menschen leicht lösen können, mit denen Computer jedoch zu kämpfen haben oder die sie einfach nicht lösen können. Ein beliebtes Beispiel zeigt ein Foto, das durch ein Raster getrennt ist, und fordert die Benutzer auf, alle Sektoren zu identifizieren, in denen sich ein bestimmtes Objekt befindet, z. B. eine Blume oder ein Gesicht. Der Computer kann nicht verstehen, wonach gefragt wird, und kann daher nicht einmal versuchen, das Bild zu scannen. Selbst wenn das möglich wäre, übersteigt die Bilderkennung die meisten Programme, die nicht speziell dafür entwickelt wurden.

Andere Beispiele für CAPTCHAs sind das Anzeigen von verschwommenem Text, das Stellen einer einfachen logischen Frage oder das laute Ausspielen der Frage. Die Implementierung einer CAPTCHA-Herausforderung an kritischen Stellen in einer Anwendung, z. B. bei der Aufforderung zur Eingabe eines Passworts, kann Automatisierungsprogramme zum Erliegen bringen.

Es ist auch möglich, Automatisierungsprogramme zu stoppen, indem einfach die Anzahl falscher Schätzungen aus derselben Quelle begrenzt wird. Wenn zu viele falsche Schätzungen gesendet werden, kann das Konto vorübergehend gesperrt werden, wodurch das Automatisierungsprogramm über den Punkt hinausgeht, an dem es nützlich ist, oder es könnte sogar erforderlich sein, dass ein menschlicher Administrator die Sperre aufhebt. Wenn Sie all das tun, sollten Sie Sicherheitslücken gegen die Automatisierung innerhalb einer Anwendung verhindern.

Weitere Informationen zu unzureichender Antiautomatisierung

Zum weiteren Lesen können Sie sich ansehen, was OWASP dazu sagt unzureichende Antiautomatisierung. Sie können Ihr neu gewonnenes Defensivwissen auch auf die Probe stellen mit dem kostenlose Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Blog von Secure Code Warrior.

Sind Sie bereit, eine unzureichende Anti-Automatisierung sofort zu finden und zu beheben? Teste deine Fähigkeiten in unserer Spielarena: [Fangen Sie hier an]

Bei Blogs oder Artikeln wie diesem werden die Leser durch Satzzeichen unterstützt. Beispielsweise teilen Punkte den Lesern mit, wo ein Satz endet, während Kommas entweder Artikel in Listen trennen oder harte Pausen einfügen, um Ideen voneinander zu trennen. Bei einem gut geschriebenen Blog (wie diesem) ist die Interpunktion fast unsichtbar, sie ist nur ein Teil des Standard-Hintergrundcodes, den wir alle vor vielen Jahren zu verarbeiten gelernt haben.

Aber was passiert, wenn ein Hacker in diesen Artikel gerät und seltsame Satzzeichen an den falschen Stellen einfügt? So wie das:

Sogar ohne! ändern. das, texten... es? kann. schaffe es! viel? schwieriger. Zu? verarbeiten! die, Information!

Das passiert im Grunde genommen bei einem CRLF-Injektionsangriff. Die CRLF-Buchstaben stehen für Carriage Return und Line Feed, die einzeln oder zusammen verwendet werden, um das Ende einer Leitung zu kennzeichnen. Wenn ein Angreifer einen CR- oder LF-Code in eine bestehende Anwendung einfügen kann, kann er manchmal deren Verhalten ändern. Die Auswirkungen sind im Vergleich zu den meisten Angriffen weniger leicht vorherzusagen, können aber für die Zielorganisation nicht weniger gefährlich sein.

In dieser Folge werden wir lernen:

• Wie Angreifer eine CRLF-Injektion auslösen können
• Warum CRLF-Injektionen gefährlich sind
• Techniken, mit denen diese Sicherheitsanfälligkeit behoben werden kann.

Wie lösen Angreifer eine CRLF-Injektion aus?

CRLF-Zeichen in vorhandenen Code einzufügen und zu versuchen, ein bestimmtes Ergebnis zu erzielen, ist ziemlich schwierig, wenn auch nicht unmöglich. Dies wird noch schwieriger, da ein Angreifer je nach Betriebssystem und anderen Faktoren des Zielsystems unterschiedliche CRLF-Kombinationen verwenden müsste. Moderne Windows-Computer benötigen beispielsweise sowohl CR als auch LF, um eine Zeile zu beenden, während unter Linux nur der LF-Code benötigt wird. HTTP-Anfragen benötigen immer einen präzisen CRLF-Code, um eine Zeile zu beenden.

Abgesehen von der Tatsache, dass CRLF-Angriffe schwierig zu implementieren sind und ihre Ergebnisse noch schwieriger vorherzusagen sind, werden sie auf die gleiche Weise initiiert wie andere Angriffe vom Typ Injektion. Ein böswilliger Benutzer gibt einfach Daten in einen beliebigen Bereich einer Website oder Anwendung ein, der dies zulässt. Nur er gibt den CRLF-Code anstelle von oder nach normalen Eingabedaten ein.

Ein Angreifer könnte beispielsweise den ASCII-Code eingeben, der einen Wagenrücklauf (%0d) gefolgt von ASCII für einen Zeilenvorschub (%0a) am Ende eines HTTPS-Headers darstellt. Die gesamte Abfrage würde dann so aussehen:

https://validsite.com/index.php?page=home%0d%0a

Wenn die Daten nicht bereinigt oder gefiltert werden, kann der obige Code dazu führen, dass auf der Zielanwendung oder Website seltsame Dinge passieren.

Warum sind CRLF-Injektionen gefährlich?

CRLF-Injektionsangriffe sind zwar weniger präzise als die meisten anderen, können aber zumindest zeitweise ziemlich gefährlich sein. Im unteren Bereich kann das Hinzufügen einer zusätzlichen Zeile die Protokolldateien durcheinander bringen, wodurch automatische Cybersicherheitsmaßnahmen ausgelöst werden, um Administratoren vor einem Problem zu warnen. Dies könnte jedoch genutzt werden, um Ressourcen von einem tatsächlichen Angriff abzuhalten, der zur gleichen Zeit stattfindet.

CRLF-Angriffe können aber auch direkt schädlich sein. Wenn eine Anwendung beispielsweise so konzipiert ist, dass sie Befehle akzeptiert und dann nach einer bestimmten Datei sucht, kann das Hinzufügen eines CRLF-Codes zur Abfrage dazu führen, dass die Anwendung diesen Prozess auf dem Bildschirm anzeigt, anstatt ihn versteckt zu halten, was einem Angreifer wertvolle Informationen liefern könnte.

CRLF-Injektionen können auch verwendet werden, um einen sogenannten Response-Splitting-Angriff auszulösen, bei dem die Codes am Ende einer Zeile eine gültige Antwort in mehrere Teile zerlegen. Das kann Hackern die Kontrolle über den Header nach dem CRLF-Code geben, der zum Einfügen von zusätzlichem Code verwendet werden kann. Es kann auch verwendet werden, um eine Öffnung zu schaffen, in die der Angreifer seinen eigenen Code vollständig einfügen und wahrscheinlich eine andere Form von Angriff auslösen kann, und zwar in jede Zeile, die auf den Teil folgt, der durch den CRLF-Angriff unterbrochen wurde.

Beseitigung der CRLF-Injektionsanfälligkeit

Wenn es eine wichtige Botschaft gibt, die wir aus dieser Serie mitnehmen können, dann ist es, niemals Benutzereingaben zu vertrauen. Die meisten Sicherheitslücken, die wir in dieser Serie behandelt haben, betrafen auf die eine oder andere Weise Benutzereingabebereiche, und der CRLF-Injection-Fehler ist da keine Ausnahme.

An jedem Punkt, an dem ein Benutzer Eingaben eingeben kann, müssen Filter angewendet werden, um zu verhindern, dass unautorisierter Code injiziert wird, der von der Anwendung oder dem Server falsch interpretiert werden könnte. Bei CRLF-Angriffen ist das Sperren von HTTP-Headern besonders wichtig, aber Sie dürfen auch die GET- und POST-Parameter oder sogar Cookies nicht vergessen. Eine gute Möglichkeit, gezielt zu verhindern, dass CRLF-Codes dazu beitragen, weitere Injektionen auszulösen, besteht darin, die HTML-Codierung auf alles und jedes anzuwenden, was an den Browser eines Benutzers zurückgesendet wird.

Weitere Informationen zu CRLF-Injektionen

Zum weiteren Lesen können Sie sich ansehen, was OWASP dazu sagt CRLF-Injektionen. Sie können Ihr neu gewonnenes Defensivwissen auch auf die Probe stellen mit dem kostenlose Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Blog von Secure Code Warrior.

Im Gegensatz zu Angriffen, die direkt auf Website- oder Anwendungsbetreiber abzielen, besteht das Ziel vieler Cross-Site Request Forgery (CSRF) -Angriffe darin, Geld, Waren oder Anmeldeinformationen direkt von einem Benutzer zu stehlen. Dies bedeutet nicht, dass Webseitenbetreiber Sicherheitslücken im CSRF-Code ignorieren sollten, da letztlich für den Ersatz gestohlener Gelder im Falle eines rein monetären Angriffs die Hosting-Website mit dem unsicheren Code verantwortlich sein kann. Und wenn der Zielbenutzer stattdessen seine Anmeldeinformationen verliert oder sein Passwort unwissentlich geändert wird, kann ein Krimineller mit dieser gestohlenen Identität Chaos anrichten, insbesondere wenn das Opfer privilegierten Zugriff hat.

CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, viele Dinge müssen zugunsten des Angreifers kaputt gehen, damit es funktioniert. Trotzdem sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff Geld direkt an einen Hacker überweisen oder ihn so einrichten kann, dass er sich ungestraft auf einer Website bewegen kann. Wenn alles in die Richtung eines Hackers geht, erfährt der Zielbenutzer möglicherweise nicht einmal, dass er Opfer eines Angriffs geworden ist.

Die gute Nachricht ist, dass, weil so viel richtig laufen muss, damit ein CSRF-Angriff funktioniert, es eine ganze Reihe großartiger Abwehrtechniken gibt, die sie aufhalten können.

Zu diesem Zweck werden wir drei wichtige Aspekte von CSRF-Angriffen erörtern:

• So funktionieren sie
• Warum sie so gefährlich sind
• Wie Sie Abwehrmechanismen einrichten können, um sie vor der Erkältung zu schützen.

Wie funktionieren CSRF-Angriffe?

Da erfolgreiche CSRF-Angriffe die Fähigkeit haben, direkt Geld, Waren oder Anmeldeinformationen von Zielnutzern zu stehlen, sind sie trotz des hohen Arbeitsaufwands, der zu ihrer Erstellung erforderlich ist, beliebt. Und weil sie oft auf verschiedenen Plattformen versucht werden, haben sie sich im Laufe der Jahre eine Vielzahl von Namen und Spitznamen angeeignet. Möglicherweise hören Sie CSRF-Angriffe, die als XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery oder Hostile Linking bezeichnet werden. Microsoft bezeichnet sie in den meisten seiner Dokumentation gerne als One-Click-Angriffe. Aber es sind alles CSRF-Angriffe, und die Techniken, um sie abzuwehren, sind identisch.

Ein CSRF-Angriff kann auftreten, wenn ein Benutzer auf einer Website angemeldet ist, um Geschäfte zu tätigen oder seine Arbeit zu erledigen. Der Schlüssel ist, dass der Benutzer angemeldet und aktiv auf einer Website oder Anwendung authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail aus gestartet. Oft verwenden Angreifer Social-Engineering-Techniken, um Benutzer dazu zu bringen, auf einen Link in einer E-Mail zu klicken, der sie zu einer gefährdeten Website mit dem Angriffsskript führt.

Die kompromittierte Website enthält ein Skript, das den aktiven Browser anweist, Befehle auszuführen, die normalerweise bösartig sind, wie das Ändern des Passworts eines Benutzers oder die Überweisung von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, geht die Website davon aus, dass die Befehle vom autorisierten Benutzer ausgegeben werden. Warum sollte es das nicht tun? Der Benutzer hat sich bereits authentifiziert und alle Passwörter eingegeben, die für den Zugriff auf die Website erforderlich sind. Sie befinden sich möglicherweise sogar innerhalb eines Geofences und befinden sich direkt an ihrem Büroterminal. Wenn sie ihr Passwort ändern oder Geld überweisen möchten, gibt es keinen Grund, nicht zu glauben, dass sie es sind, die die Anfrage gestellt haben.

Wenn man die Elemente des Angriffs aufschlüsselt, ist klar, warum dieser Angriff für den Angreifer so schwierig durchzuführen ist. Zunächst muss der Benutzer aktiv bei der Site authentifiziert werden, auf der der Angriff stattfindet. Wenn eine E-Mail mit einem Angriffsskript eingeht, nachdem ein Benutzer seine Browsersitzung beendet oder sich abgemeldet hat, schlägt der Angriff fehl.

Der Angreifer ist außerdem gezwungen, auf der Zielseite viele Auskundungen durchzuführen, um zu wissen, welche Skripte diese Site akzeptiert. Angreifer können den Bildschirm eines Opfers nicht sehen, und jegliches Feedback von der Website geht an das Opfer, nicht an den Angreifer. Sofern der Angreifer nicht in der Lage ist, Beweise dafür zu sehen, dass sein Angriff funktioniert, z. B. wenn plötzlich Geld auf seinem Konto erscheint, wird er nicht einmal sofort wissen, ob der Angriff erfolgreich war.

Angesichts der schwierigen, aber nicht unmöglichen Parameter, dass der Benutzer zum Zeitpunkt des Angriffs angemeldet ist und weiß, welche Skripts die Zielseite akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website selbst variiert.

Nehmen wir an, eine Bank- oder Finanzanwendung verwendet GET-Anfragen, um Geld zu überweisen, wie folgt:

HOLEN SIE SICH http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

Dieser Code würde eine Anfrage zur Überweisung von 100$ an einen Benutzer namens NancySmith12 senden.

Wenn der Zielbenutzer jedoch eine E-Mail erhalten hat, vielleicht eine, die als von einem Kollegen getarnt ist, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet werden:

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Können Sie diesen Quartalsbericht schnell durchlesen? <a></a></a>

Wenn der Zielbenutzer auf den Social-Engineering-Link hereinfiel und darauf klickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, forderte sein Browser die Anwendung auf, 100.000$ an das Konto von ShadyLady15 zu senden.

Das Skript könnte sogar in einem unsichtbaren Bild versteckt sein, das der Benutzer nicht sehen würde, das aber dennoch den Browser veranlassen könnte, die Anfrage zu stellen, wie folgt:

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

Das Ergebnis ist dasselbe. ShadyLady15 erhält 100.000$, ohne dass jemand den Angriff bemerkt.

Warum ist CSRF so gefährlich?

CSRF-Angriffe sind heute aus dem gleichen Grund beliebt, aus dem Ransomware-Angriffe weiterhin die Runde machen. Es gibt nur sehr wenige Sprünge zwischen Angreifern und dem Geld eines Opfers. Bei einem Ransomware-Angriff werden Systeme verschlüsselt und Benutzer werden um Geld für die Entschlüsselung dieser Daten erpresst. Bei einem CSRF-Angriff sind es noch weniger Schritte. Wenn sie arbeiten, schicken die Opfer einfach Geld an die Angreifer, ohne es zu wissen.

Neben direkten Angriffen auf das Geld eines Opfers oder die Finanzen eines Unternehmens können erfolgreiche CSRF-Angriffe dazu verwendet werden, ein Netzwerk mithilfe gültiger Benutzer zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte einen CSRF-Exploit verwenden, um das Passwort eines Administrators zu ändern. Sie könnten dieses Passwort sofort verwenden, um Daten zu stehlen, Sicherheitslücken im Netzwerk zu öffnen oder Hintertüren zu installieren.

Obwohl es eine Menge Arbeit und bis zu einem gewissen Grad Glück ist, kann ein erfolgreicher CSRF-Angriff für Hacker unabhängig von ihrem ultimativen Ziel wie ein Lottogewinn sein. Bei einem Angriff auf ein Netzwerk wäre für fast jede andere Art von Angriff monatelange, langsame Aufklärungsarbeit erforderlich, um unter dem Radar der SIEM- und Cybersicherheitsteams zu bleiben. Im Gegensatz dazu können bei einem einzelnen CSRF-Angriff einige Schritte entlang der Cyber-Kill-Chain übersprungen werden, sodass sie ihrem ultimativen Ziel sehr nahe kommen.

Wie stoppe ich CSRF-Angriffe?

Im Gegensatz zu den meisten Sicherheitslücken liegt der Fehler bei CSRF-Angriffen nicht wirklich im Code, sondern in einem Exploit, den Angreifer erstellt haben, um einen Browser zu zwingen, Anfragen zu stellen, die ein Benutzer nicht möchte und von denen er möglicherweise nicht einmal weiß. Aber sie können besiegt werden.

Eine der besten Methoden besteht darin, Entwickler dazu zu bringen, der Identität eines Benutzers ein CSRF-Token hinzuzufügen, wenn eine neue Sitzung generiert wird. Es sollte aus einer Reihe eindeutiger und zufälliger Zeichen bestehen und für Benutzer unsichtbar sein. Fügen Sie als Nächstes die CSRF-Token-Anfrage als verstecktes Feld zu Formularen hinzu, die vom Server überprüft werden, wenn eine neue Anfrage eingereicht wird. Angreifer, die Anfragen über den Browser eines Benutzers einreichen, wissen nicht einmal von dem versteckten Token-Feld, geschweige denn, sie können herausfinden, um welches es sich handelt, sodass alle ihre Anfragen fehlschlagen.

Eine noch einfachere Methode, die nicht viel Programmierung erfordert, besteht darin, vertraulichen Dingen wie Passwortänderungsanfragen oder Geldüberweisungsaufträgen eine Captcha-Herausforderung hinzuzufügen. Es kann so einfach sein, einen Benutzer zu bitten, auf eine Schaltfläche zu klicken, um zu bestätigen, dass es sich bei dem Anforderer nicht um einen Roboter oder in diesem Fall um ein CSRF-Skript handelt. Angreifer werden nicht in der Lage sein, eine Antwort auf die Herausforderung zu schreiben, und Benutzer, die plötzlich eine CAPTCHA-Aufforderung erhalten, ohne zuvor etwas wie eine Geldtransferanfrage zu stellen, wissen, dass etwas nicht stimmt. Alternativ kann die Generierung eines Einmalkennworts mithilfe eines Drittanbieter-Tokens, z. B. eines Smartphones, verwendet werden, je nachdem, wie stark ein Unternehmen die Arbeit im Namen der Sicherheit verlangsamen möchte.

Schließlich haben viele Browser wie Microsoft Edge oder Google Chrome jetzt, obwohl es nicht unumstößlich ist Politik des gleichen Ursprungs Es gibt Einschränkungen, um Anfragen von allen außer dem lokalen Benutzer zu blockieren. Wenn Sie Benutzer dazu zwingen, mit Ihrer Website über die aktuellsten Versionen dieser Browser zu interagieren, kann dies dazu beitragen, eine weitere CSRF-Sicherheitsebene aufzubauen, ohne die Entwicklungsteams überhaupt zu belasten.

CSRF die Tür zuschlagen

Bei einem so hohen Auszahlungspotenzial werden CSRF-Angriffe wahrscheinlich nie vollständig verschwinden, aber wir hoffen, dass Sie erfahren haben, warum sie so hartnäckig sind und wie Sie sie endgültig von Ihrem Netzwerk fernhalten können.

Weitere Informationen finden Sie im OWASP Cross-Site Request Forgery Prevention Cheat Sheet, das als lebendes Dokument dient, das die Entwicklung dieser Sicherheitslücke dokumentiert. Wenn Sie Ihr Sicherheitswissen wirklich erweitern möchten, können Sie lernen, wie Sie diese und viele weitere Bedrohungen abwehren können, indem Sie die Sicherer Codekrieger Blog.

Denken Sie, Sie sind bereit, Ihr neues Defensivwissen auf die Probe zu stellen? Spiel ein bisschen mit dem kostenlose Demo der Secure Code Warrior-Plattform heute.