Bekijk Volledige Versie : Spammen via perl script
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.
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.
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.
Misschien de roundcube exploit?
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?
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.
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.
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.
bruteforce met simpele passwords?
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.
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.
Dat is inderdaad een tijdelijke 'oplossing', maar het is natuurlijk wachten totdat het bestandje anders heet. Ik ben meer benieuwd naar de oorzaak.
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
06/03/09, 17:47
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...
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.
logs?
//edit;
Kan het zo zijn dat jullie soft/hardware routers compromised zijn??
All your data belongs to sniffer.pl
logs?
Kan je ook met zinnige bijdrages komen? Je hebt niet te maken met Jan met de pet op die voor het eerst een shell van dichtbij ziet.
Kan het zo zijn dat jullie soft/hardware routers compromised zijn??
All your data belongs to sniffer.pl
Kijk, dat is een zinnige opmerking. De enige netwerkapparatuur die wij beheren zijn HP 2650 switches, dus dan zou er wat bij Equinix gehacked moeten zijn. Ik vermoed echter dat als dat het geval zou zijn het aantal compromises veel en veel hoger zou liggen.
misschien intressant om wat hostnames te vergelijken van de ip's die hier die dingen uploaden. Ik zal de extacte hostnames niet melden omdat ik niet 100% zeker ben.
Maar keywords zoals nocdirect, ezzi , baku, servhost in de hostnames..
en dan nog een heleboel unresolvable naar het buitenland.
oh en misschien ook leuk.. ik heb al onze gerotate logs ge'zcat en op datum ge count:
291 Sep
1036 Oct
2066 Nov
1519 Dec
212 Jan
1524 Feb
507 Mar
dit is echter alleen check.cgi, dan heb ik nog niet eens de andere getelt.. dit komt van 7 accounts wat een fractie is van het aantal accounts wat we hosten.
ik zie geen onderscheid in TLD's, zie van alles voorbij komen.. ook de accounts hebben goede wachtwoorden. Ik zie geen expliciete php pakketten voorbij komen.. sterker nog ik zie zelfs account met alleen HTML..
zo ver ik dus kan zien en mn ervaring leert is dit een virus/trojan/keylogger/spyware achtig iets geweest wat het wachtwoord en de username hebben achterhaald en dit misbruiken.
Volgens mij is het een script die de FTP probeerd te hacken.
Hier in mijn logfiles staan honderden van zulke regels:
ProFTPd [1822] ::ffff:85.92.128.192 [06/Mar/2009:23:57:20 +0100] "GET / HTTP/1.1" 500
ProFTPd [1822] ::ffff:85.92.128.192 [06/Mar/2009:23:57:20 +0100] "HOST: hmnet.nl" 500
ProFTPd [1822] ::ffff:85.92.128.192 [06/Mar/2009:23:57:20 +0100] "CONNECTION: Close" 500
ProFTPd [1831] ::ffff:85.92.128.192 [06/Mar/2009:23:57:21 +0100] "USER hmnet" 331
ProFTPd [1831] ::ffff:85.92.128.192 [06/Mar/2009:23:57:21 +0100] "PASS (hidden)" 530
ProFTPd [1832] ::ffff:85.92.128.192 [06/Mar/2009:23:57:21 +0100] "USER hmnet" 331
ProFTPd [1832] ::ffff:85.92.128.192 [06/Mar/2009:23:57:21 +0100] "PASS (hidden)" 530
Het IP heb ik laten staan omdat ze hier niks te zoeken hebben.
Ook andere IP reeksen komen voor.
Ze proberen het niet alleen bij mijn account maar ook bij andere account's op de server.
Ik vraag mij dus ook af hoe ze aan de account namen komen?
Volgens mij is het een script die de FTP probeerd te hacken.
Hier in mijn logfiles staan honderden van zulke regels:
Het IP heb ik laten staan omdat ze hier niks te zoeken hebben.
Ook andere IP reeksen komen voor.
Ze proberen het niet alleen bij mijn account maar ook bij andere account's op de server.
Ik vraag mij dus ook af hoe ze aan de account namen komen?
Bij veel accounts is de username de domainname exclusief tld, bij jou ook zo te zien.
Kan je ook met zinnige bijdrages komen? Je hebt niet te maken met Jan met de pet op die voor het eerst een shell van dichtbij ziet.
Kijk, dat is een zinnige opmerking. De enige netwerkapparatuur die wij beheren zijn HP 2650 switches, dus dan zou er wat bij Equinix gehacked moeten zijn. Ik vermoed echter dat als dat het geval zou zijn het aantal compromises veel en veel hoger zou liggen.
Blijkbaar wel, je zou de volgende stappen ondertussen al een keer of 100 gecheckt moetenhebben:
Wat voor passwds reiken jullie uit, hoe versturen jullie die, waar gaan die doorheen (switch/router), hoe gaat de gebruiker met die informatie om (en met zijn pc), hoe is het gesteld met de security van je netwerk??
Gebruiken jullie een standaard password voor elke user ?? (denk aan test321, $username123, blabla )
Maken jullie gebruik van het default(lees random) password create menutje van adduser ?
Hoe versturen jullie zulke informatie, per post, per encrypted/plain text e-mail??
worse case senario:
Het zou zo kunnen zijn dat 1 of meerdere van jullie (of hogerop) switches / routers door een of andere bug / oud medewerker "gehackt" kan zijn en dat ze alle data van jullie sniffen en de username / passwords via een grep / awk eruit filteren.
Hoe is het met de security gesteld van die doos (http://www.procurve.com/docs/eos/announcement/2600_Series_End_of_Sale_Announcement_Feb_09_NA_eng .pdf) ?
Hoe word er ingelogged, puur via ftp of ook per ssh ?
Misschien een tip/idee om je klanten beter om te laten gaan met passwoords, ip's en login gegevens. Schop ze om naar ssh-keys + scp.
Maar hey, who am i, 'k ben maar een bouwkundig tekenaar :O
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.
Toevallig nog een webmin daar naast draaien?
Op het DA forum heeft iemand over een "Security leak in Apache"
Zie: http://www.directadmin.com/forum/showthread.php?t=30065
Het zal er wel niet veel mee te maken hebben, maar wat ik zo lees (als het zo is) dan is dit ook een gevaarlijk lek.
Google is your friend? (na vandaag niet meer!)
http://www.google.com/search?hl=en&lr=&safe=off&num=100&c2coff=1&q=filetype%3Aphp+HAXPLORER+%22Server+Files+Browser %22&btnG=Search
Op het DA forum heeft iemand over een "Security leak in Apache"
Zie: http://www.directadmin.com/forum/showthread.php?t=30065
Het zal er wel niet veel mee te maken hebben, maar wat ik zo lees (als het zo is) dan is dit ook een gevaarlijk lek.
[/url]
Is al een tijdje bekend, heb de oplossing er ff neergezet voor je :)
Maar hey, who am i, 'k ben maar een bouwkundig tekenaar :O
Je verhaal was inderdaad goed van toepassing geweest indien alle servers zich in hetzelfde netwerk bevonden. Een niveau erboven wordt al wat onwaarschijnlijker :)