Spammen via perl script

[wdv]

Beste collega's,

Wij komen het de afgelopen weken ineens opvallend vaak tegen dat FTP gegevens van klanten misbruikt worden om perl scriptjes te uploaden, die vervolgens gestart worden om te spammen en daarna direct weer via FTP verwijderd worden om zo weinig mogelijk bewijs achter te laten.

Het is ons niet duidelijk hoe deze gegevens bemachtigd worden. Het gaat om standaard DirectAdmin systemen. Het gebeurd zelfs dat accounts misbruikt worden waarop verder geen gebruik wordt gemaakt van php of perl, dus exploits via HTTP zijn niet mogelijk. Bovendien zou een dergelijke exploit ook alleen werken als er dan ergens in een config.php bestandje FTP gegevens zouden staan.

Wij beginnen het vermoeden te krijgen dat er wellicht sprake is van virussen die FTP gegevens van klanten steelt.

Onze vraag is of er misschien collega's zijn die ook een opvallende steiging in deze aanvallen waarnemen en of zij wellicht enig idee hebben hoe de accounts misbruikt worden.

Waargenomen bestandsnamen:
check.cgi
vga.cgi
1601.cgi
hnc.cgi

Een topic op webhostingtalk.com wat hierover gaat:
http://www.webhostingtalk.com/showthread.php?t=741147

Echter lijkt niemand te weten hoe de FTP gegevens bemachtigd worden.

[Randy]

Hi,

Hier afgelopen week ook twee servers moeten restoren waarbij hetzelfde het geval was. In dit geval was het inloog via FTP en adware plaatsen in de index-bestanden. Ik ben al extra alert op de FTP logfiles.

[wdv]

Voor de duidelijkheid, met de server zelf is verder niks aan de hand. Het enige is dat de misbruikers op de één of andere manier achter de FTP gegevens kunnen komen.

Ik kan hier maar twee methoden voor bedenken:
1) Een PHP exploit (bijvoorbeeld via Joomla) die een config.php met FTP gegevens uitleest
2) Een virus op de computer van de klant zelf die opgeslagen FTP gegevens van bekende FTP programma's uitleest

Nummertje 1 kan ik inmiddels dus al uitsluiten aangezien we dit ook al bij accounts gezien hebben die verder helemaal geen perl of php scripts op hun account hebben staan.

[ivs]

Misschien de roundcube exploit?

[wdv]

Misschien de roundcube exploit?

Is bij ons in ieder geval gewoon up2date. Hoe zouden ze daarmee sowieso FTP gegevens moeten bemachtigen? Hmm.. wellicht als ze met hun hoofdaccount inloggen wat ook het FTP account is?

[Wido]

Hier het zelfde, kom ook check.cgi tegen op één DA systeem.

Deze draait onder "apache" en als ik een lsof er op los laat zie ik dat er connecties naar constant de zelfde SMTP servers in Rusland worden gemaakt.

Sta hier ook nog even voor een raadsel.

[PeterT]

Heb het hier (nog) nergens gezien. De DA servers worden dan ook nog niet voor klanten gebruikt maar alleen voor interne/development projecten. Ik neig dus toch naar een exploit van een of ander script.

[wdv]

Heb het hier (nog) nergens gezien. De DA servers worden dan ook nog niet voor klanten gebruikt maar alleen voor interne/development projecten. Ik neig dus toch naar een exploit van een of ander script.

Zoals gezegd, het komt ook voor bij accounts die geen enkel script draaien (confirmed). Bovendien zou er dan ook ergens in de bestanden van het account FTP gegevens moeten staan en ook dat is niet het geval.

[davinci]

bruteforce met simpele passwords?

[wdv]

bruteforce met simpele passwords?

Ook de usernames zouden dan gebruteforced moeten worden, het aantal mogelijkheden lijkt me in dat geval echt extreem groot. Zelfs met simpele wachtwoorden. Daarnaast zie ik ook geen indicaties van bruteforce attempts.

[Japje]

ik zie deze check.cgi ook veel voorbijkomen. deze worden geupload, gestart, en verwijderd binnen een paar secs.

Voorlopig heb ik op onze xferlog maar een regex gezet die me een berichtje stuurt wel account zodat ik het in de gaten kan houden.

[wdv]

Dat is inderdaad een tijdelijke 'oplossing', maar het is natuurlijk wachten totdat het bestandje anders heet. Ik ben meer benieuwd naar de oorzaak.

[Randy]

Even een aanvulling; op een van de servers die een probleem had draaide enkel eigen scripts. Geen ranzige Joomla shizzle. Dat staat wel in de top 5 van m'n vragenlijstje bij een intake .

[Tim.Bracquez]

Geen ranzige Joomla shizzle.

Joomla en nog enkele haalt de prijs naar boven van managed solutions
Hier nog niets tegen gekomen alvast maar op de boven genoemde namen een regex geplaatst, en ook een kill voor alle cgi scripts (op servers waar dit niet gebruikt wordt, kwasie overal dus...)
Nog even werk om dit overal op 'uit te rollen'...

toppic maar goed in het oog houden...

[Randy]

Valt wel mee. Gewoon zorgen dat je een veilige omgeving hebt (Fast-CGI / mod_ruid) en iet onder apache:www-data ofzeaux draait, dan valt het wel mee. En natuurlijk blijven updaten. Gelukkig zie je bij veel OSS al ingebouwde update systemen, bijvoorbeeld in Wordpress. Ik hoop dat Joomla dit voorbeeld gaat volgen. De upload gaat gelukkig al met ftp hetgeen ranzige apache:apache bestanden voorkomt bij mod_php gebruikers. $eindgebruikers vergeten alleen de meuk te updaten, niet alleen de core, maar ook de (nog ranzigere) modules. En daar zit een beetje het probleem. Met updaters als Installatron kun je naturlijk al een hoop ellende besparen.

Ikzelf heb nog even de ftp log doorgespit maar zag op die machine geen STOR commando's met CGI scripts. Enkel de index bestanden die opgehaald en teruggezet zijn, het laatste met adware in javascript.