Hallo,

ich habe folgendes Problem:
Ein Script soll eine whois-Abfrage an den Ripe senden und das Ergebnis
weiter verarbeiten.

der betreffende Befehl lautet:
$info=shell_exec("whois -h whois.ripe.net $ip");
wobei $ip die IP-Adresse enhält.

Der Cron Job wird richtig ausgeführt, allerdings bleibt die Variable
$info dabei leer.

Starte ich das Script händisch, d.h. via Browser, funktioniert es
einwandfrei.

Safe_Mode ist via PLESK ausgeschalter für die gesamte Domain.

Wie kann man die unterschiedlichen Resultate erklären? Welche
Einstellungen muss ich überprüfen.

Vielen Dank für jeden Hinweis!!!

Stefan

Stefan König schrieb:

> der betreffende Befehl lautet:
> $info=shell_exec("whois -h whois.ripe.net $ip");
> wobei $ip die IP-Adresse enhält.
>
> Der Cron Job wird richtig ausgeführt, allerdings bleibt die Variable $info
> dabei leer.
>
> Starte ich das Script händisch, d.h. via Browser, funktioniert es
> einwandfrei.

Womöglich kennt der Cronjob das Tool "whois" nicht (andere $PATH). Benutze
doch mal exec() und schau dir den Returncode an. Hier könnte dann helfen,
einen absoluten Pfad zu benutzen.

Gruß
Carsten

Carsten Wiedmann schrieb:

>> $info=shell_exec("whois -h whois.ripe.net $ip");
[...]
> Benutze doch mal exec()

*grusel*

Wievele direkte und indirekte Shell-Befehle gibt es eigentlich?

system()
shell_exec()
exec()

Ich beschäftige mich gerade mit der UNsicherheit von Uploadskripten. Zur
Untersuchung potetieller Schadskripte (c99.php, cwings.php, r57shell.php,
.... da gibt es eine ganze Kollektion) ist die Kenntnis von Shellbefehlen
unabdingbar.

Minimalshell:
<? system($_GET['cmd']); ?> => Name: shell.php.gif

Naive Uploadscripte lassen den Upload von sowas zu, weil sie möglicherweise
$_FILES['userfile']['type'] vertrauen (davon ist dringed abzuraten!) und
erlauben das Auszuführen, indem man die Scheingrafik aufruft:

http://example.com/shell.php.gif?cmd= ... was immer beliebt

Martin

Martin Lemke schrieb:
> Carsten Wiedmann schrieb:
>
>>> $info=3Dshell_exec("whois -h whois.ripe.net $ip");
> [...]
>> Benutze doch mal exec()
>
> *grusel*
>
> Wievele direkte und indirekte Shell-Befehle gibt es eigentlich?
>
> system()
> shell_exec()
> exec()

Frueher waren es bis zu 7 Arten worueber man externe Programme starten
konnte. Da sind dann noch Backticks, popen() und proc_open() und dann
kamen ja die Streamwrapper.

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Hallo Martin, etwas OT ;)

mit

<FilesMatch "\.(php|php3)$">
deny from all
</FilesMatch>

in der .htaccess im Upload-Ordner ist man meiner Meinung nach auf der
sicheren Seite. Wo nix ausgeführt wird, können die User gerne gifs und
jpegs mit exploits hochladen... :)

Welche Lösung favorisierst du nach deiner Recherche?

stefan


Martin Lemke schrieb:
> Carsten Wiedmann schrieb:
>
>>> $info=shell_exec("whois -h whois.ripe.net $ip");
> [...]
>> Benutze doch mal exec()
>
> *grusel*
>
> Wievele direkte und indirekte Shell-Befehle gibt es eigentlich?
>
> system()
> shell_exec()
> exec()
>
> Ich beschäftige mich gerade mit der UNsicherheit von Uploadskripten. Zur
> Untersuchung potetieller Schadskripte (c99.php, cwings.php, r57shell.php,
> ... da gibt es eine ganze Kollektion) ist die Kenntnis von Shellbefehlen
> unabdingbar.
>
> Minimalshell:
> <? system($_GET['cmd']); ?> => Name: shell.php.gif
>
> Naive Uploadscripte lassen den Upload von sowas zu, weil sie möglicherweise
> $_FILES['userfile']['type'] vertrauen (davon ist dringed abzuraten!) und
> erlauben das Auszuführen, indem man die Scheingrafik aufruft:
>
> http://example.com/shell.php.gif?cmd= ... was immer beliebt
>
> Martin

Stefan König schrieb:

Danke für den Tipp mit .htaccess. Das Problem ist, dass in einer
Linux-Umgebung Skripte beliebige Extensions haben dürfen. Dann muss
allerdings der Pfad zum Prozessor in der ersten Zeile stehen:

#!/usr/bin/perl

So etwas lässt sich natürlich entdecken.

Wenn einen Server ausschließlich php-Skripte korrumpieren könnten, wäre die
Welt ja viel zu einfach. Also reduziert sich Dein Vorschlag auf pures

deny from all

Das ist schon mal keine schlechte Idee. Da hätte ich wirklich selber drauf
kommen müssen.

In meinem Fall ist das leider etwas komplizierter, weil mein Forum, in dem
die hochgeladenen Bilder eingelinkt werden, auf einer anderen Subdomain als
die Uploads liegen. Da muss ich erst nochmal nachlesen. Ich muss Zugriffe
von meinen Subdomains erlauben und alle anderen sperren.

> Welche Lösung favorisierst du nach deiner Recherche?

Ich will einen Schritt weiter gehen und Skript-Kiddies überführen (die
operieren tatsächlich nicht alle über Proxies). Nach dem Upload wird das
Skript gesichert und ein individueller Link angezeigt. Wird dieser
aufgerufen, wird der Vorgang geloggt und ich habe die Beweise für einen
Angriffsversuch beisammen.

Diese Skript-Kiddies rauben mir einen nicht unerheblichen Teil meiner Zeit.
Vielleicht kann ich bei dem einen oder anderen Schadensersatzansprüche
geltend machen.

Es wird Zeit, dass Sabotageversuche nicht länger als legitimer Ausdruck der
Spaßgesellschaft angesehen werden.

Martin

Martin Lemke wrote:

> Ich will einen Schritt weiter gehen und Skript-Kiddies überführen (die
> operieren tatsächlich nicht alle über Proxies). Nach dem Upload wird das
> Skript gesichert und ein individueller Link angezeigt. Wird dieser
> aufgerufen, wird der Vorgang geloggt und ich habe die Beweise für einen
> Angriffsversuch beisammen.
>
> Diese Skript-Kiddies rauben mir einen nicht unerheblichen Teil meiner Zeit.
> Vielleicht kann ich bei dem einen oder anderen Schadensersatzansprüche
> geltend machen.

Mir stellt sich die Frage warum bei Dir überhaupt Hinz & Kunz was
hochladen kann? Warum erachtest Du das als Notwendig? Bei mir gibts
sowas nur im abgesicherten Bereich der Admins vorbehalten ist. Und dort
stellt sich die Problematik nicht.

> Es wird Zeit, dass Sabotageversuche nicht länger als legitimer Ausdruck der
> Spaßgesellschaft angesehen werden.

Wer denkt denn so? Gauner ist Gauner...

MfG, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

Martin Lemke <usenet [at] maaaddin.de> schrieb:
> Danke für den Tipp mit .htaccess. Das Problem ist, dass in einer
> Linux-Umgebung Skripte beliebige Extensions haben dürfen. Dann muss
> allerdings der Pfad zum Prozessor in der ersten Zeile stehen:
>
> #!/usr/bin/perl

dazu müsste das upload Verzeichnis mit einem ScriptAlias versehen und das
script mit execute rechten gespeichert werden.

bye,
- michael

Martin Lemke schrieb:

> Das Problem ist, dass in einer
> Linux-Umgebung Skripte beliebige Extensions haben dürfen.

Wieso ist das ein Problem?
Man gibt einem Skript das Recht von $benutzer ausgeführt werden zu dürfen
und macht sowas nicht an unsinnigen Dateinamenendungen (die zudem bei
mindestens einem OS per default ausgeblendet werden) fest.

> Dann muss
> allerdings der Pfad zum Prozessor in der ersten Zeile stehen:

Nein, muß nicht. Ein: exec("/bin/sh $pfad/$skript") bei Erreichbarkeit und
Ausführrecht von /bin/sh führt das Skript auch aus.

--
Gruß Kürsche
Wenns 'ner net gwittern tun tut ;)

Heiko Kuerschner schrieb:

> Ein: exec("/bin/sh $pfad/$skript") bei Erreichbarkeit und
> Ausführrecht von /bin/sh führt das Skript auch aus.

Stimmt.

Martin

Ulf Kadner schrieb:

> Mir stellt sich die Frage warum bei Dir überhaupt Hinz & Kunz was
> hochladen kann? Warum erachtest Du das als Notwendig?

Ich unterhalte ein Forum in dem naturwissenschaftliche Fragen beantwortet
werden, die man ohne wenigstens ein Foto zu zeigen, nicht beantworten kann.
Ich möchte nicht, dass sich jeder, der nur mal eine einzige Frage hat,
anmeldet (Karteileichen).

Aber vielleicht sollte ich Deine Frage zum Anlass nehmen, über temporäre
Useraccounts nachzudenken. Das ist einerseits eine Überlegung wert und
andererseits mit relativ wenig Aufwand realisierbar. Ich denke mal darüber
nach.

> Wer denkt denn so? Gauner ist Gauner...

Man liest viel über Hacker-Ehrencodexe und solchen Quatsch. Seit ich
letztes Jahr aufgrund eines zu naiv implementierten Upload-Skriptes
cwings.php auf dem Server hatte, finde ich das überhaupt nicht mehr
witzig.

Martin

Heiko Kuerschner schrieb:
> Martin Lemke schrieb:
>
>> Das Problem ist, dass in einer
>> Linux-Umgebung Skripte beliebige Extensions haben dürfen.
>
> Wieso ist das ein Problem?
> Man gibt einem Skript das Recht von $benutzer ausgeführt werden zu dü=
rfen
> und macht sowas nicht an unsinnigen Dateinamenendungen (die zudem bei
> mindestens einem OS per default ausgeblendet werden) fest.
>
>> Dann muss
>> allerdings der Pfad zum Prozessor in der ersten Zeile stehen:
>
> Nein, muß nicht. Ein: exec("/bin/sh $pfad/$skript") bei Erreichbarkei=
t und
> Ausführrecht von /bin/sh führt das Skript auch aus.
>

Ein "Options -ExecCGI" fuer das Verzeichnis und dann hat sich das bzw.
garnicht erst einschalten. Dran denken das SSI fuer auch aktiv sein kann.=


Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Joerg Behrens schrieb:

>>> Dann muss
>>> allerdings der Pfad zum Prozessor in der ersten Zeile stehen:
>>
>> Nein, muß nicht. Ein: exec("/bin/sh $pfad/$skript") bei Erreichbarkeit
>> und Ausführrecht von /bin/sh führt das Skript auch aus.
>>
>
> Ein "Options -ExecCGI" fuer das Verzeichnis und dann hat sich das bzw.
> garnicht erst einschalten. Dran denken das SSI fuer auch aktiv sein kann.

Das hat aber miteinander nichts zu tun.

--
Gruß Kürsche
Wenns 'ner net gwittern tun tut ;)

Heiko Kuerschner schrieb:
> Joerg Behrens schrieb:
>
>>>> Dann muss
>>>> allerdings der Pfad zum Prozessor in der ersten Zeile stehen:
>>> Nein, muß nicht. Ein: exec("/bin/sh $pfad/$skript") bei Erreichbark=
eit
>>> und Ausführrecht von /bin/sh führt das Skript auch aus.
>>>
>> Ein "Options -ExecCGI" fuer das Verzeichnis und dann hat sich das bzw.=

>> garnicht erst einschalten. Dran denken das SSI fuer auch aktiv sein ka=
nn.
>
> Das hat aber miteinander nichts zu tun.
>

Du kannst ueber SSI externe Programme aufrufen und somit halte ich das
fuer Relevant. Nuetzt ja nix nur PERL oder dergleichen abzuschalten aber =

die Hintertuer offen zulassen.

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Martin Lemke wrote:
> Ulf Kadner schrieb:
>
>> Mir stellt sich die Frage warum bei Dir überhaupt Hinz & Kunz was
>> hochladen kann? Warum erachtest Du das als Notwendig?
>
> Ich unterhalte ein Forum in dem naturwissenschaftliche Fragen beantwortet
> werden, die man ohne wenigstens ein Foto zu zeigen, nicht beantworten kann.
> Ich möchte nicht, dass sich jeder, der nur mal eine einzige Frage hat,
> anmeldet (Karteileichen).
>
> Aber vielleicht sollte ich Deine Frage zum Anlass nehmen, über temporäre
> Useraccounts nachzudenken. Das ist einerseits eine Überlegung wert und
> andererseits mit relativ wenig Aufwand realisierbar. Ich denke mal darüber
> nach.

Auf jeden Fall! Aber temporär? Bau doch ne ordentliche Nutzerverwaltung
ein. Da kann man auch durchaus noch ne Fallunterscheidung für
unauthorisierte und authoriesierte Nutzer machen. Die eine durfen z.B.
nur schreiben und nicht hochladen. Die anderen dürfen auch Hochladen und
haben sonstige Vergünstigungen wie z.B. BBCode oder eingebettete URLs.

Das aber je nach Geschmack und Notwendigkeit.

>> Wer denkt denn so? Gauner ist Gauner...
>
> Man liest viel über Hacker-Ehrencodexe und solchen Quatsch.

Naja... Das es die gibt ist klar. Nur bezeichnen sich halt auch
böswillig gestimmte Personen gern als Hacker. Das es da keine Ehre geben
kann sollte klar sein. (Auch wenn die sich gern mit diese Phrase umgeben)

> letztes Jahr aufgrund eines zu naiv implementierten Upload-Skriptes
> cwings.php auf dem Server hatte, finde ich das überhaupt nicht mehr
> witzig.

Ach Du warst das damals hier mit dem Posting dazu. Ja jetzt fällts mir
wieder ein. :-) Leider müßen die meisten erst auf die "Schnautze" fallen
bevor sie mitbekommen das Sicherheit nicht von alleine kommt.

Jaja, PHP ist so schön einfach. Damit kann man sich so wunderbar einfach
ins Knie schießen wenn man unbedarft losprogrammiert.

MfG, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^