Onderwerp: Welk account heeft het lek?

Kreeg vandaag een bericht van de firewall dat perl wat tijd actief was. Dus gelijk even gaan kijken.
Het betreft een Cpanel server en in de error_log van apache kwam ik het volgende tegen:

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
^M 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0^M100 975 100 975 0 0 753 0 0:00:01 0:00:01 --:--:-- 9558
Number found where operator expected at dar,jpg line 3, near "<TITLE>404"
(Missing operator before 404?)
Bareword found where operator expected at dar,jpg line 3, near "404 Not"
(Missing operator before Not?)
Bareword found where operator expected at dar,jpg line 6, near "<H1>Not Found</H1"
(Might be a runaway multi-line // string starting on line 4)
(Missing operator before H1?)
Semicolon seems to be missing at dar,jpg line 10.
Bareword found where operator expected at dar,jpg line 13, near "</BODY"
(Might be a runaway multi-line // string starting on line 12)
(Missing operator before BODY?)
Bareword found where operator expected at dar,jpg line 18, near ""feature" to"
(Missing operator before to?)
Bareword found where operator expected at dar,jpg line 20, near "512 bytes"
(Missing operator before bytes?)
syntax error at dar,jpg line 2, near "HEAD>"
Execution of dar,jpg aborted due to compilation errors.
sh: GET: command not found
sh: /usr/bin/wget: Permission denied
Can't open perl script "dar.jpg": No such file or directory
sh: /usr/bin/wget: Permission denied
sh: fetch: command not found

Zelfde voor een bestand genaamd run.txt en iso.txt. Deze 3 bestanden heb ik niet kunnen vinden. Alleen iso.txt was in /tmp aanwezig maar die was nog 0 bytes groot dus heb ik gewist. Wel in gekeken maar daar stond geen verwijzing naar een domein of account in.

Op een of andere manier konden ze dus gedeeltelijk sh commando's uitvoeren.
Ik kon geen bestand run.txt en ook geen bestand dar.jpg vinden op de server, wel 2 Russische ip's die geblokkeerd zijn. Na een herstart van apache was daarna het gebruik van perl ook afgelopen.

Maar in de log is dat dus 3x geprobeerd en telkens begint het met die statistieken die je ziet.
Erboven alleen een file not found maar van wisselende domeinen.

Hoe kun je er nu achter komen met cpanel op welk domein c.q. useraccount het lek zit? Dus via welke site ze dit konden doen?
Apache draait op die server nog als nobody overigens. Phpsuexec actief, csf/lfd firewall.

Vrijwel zeker gevonden waar het vandaan komt. Een te oude Oscommerce weer eens.
Maar dat is omdat ik een vermoeden had, de vraag blijft echter of zoiets echt uit andere logs of bestanden te herleiden is naar het lekke account.

Al gekeken naar de ownership van die files?

Yep, nobody was de owner. Apache dus.

Oorspronkelijk geplaatst door Blacky

Yep, nobody was de owner. Apache dus.

Nou ken ik cpanel niet helemaal maar waarom niet onder de gebruiker zelf draaien? Geeft een hoop voordelen zoals in dit geval.

Dan moet je suphp gaan doen enzo. Eigenaar van de server wilde dat niet.
Normaliter hebben de bestanden ook de gebruikersnaam in de directory. Maar betreffende gebruiker had zijn images directory op 777 staan en op een of andere manier middels een lek in Oscommerce hebben ze dus bestanden in die images directory kunnen schrijven. De webserver zelf draait namelijk onder nobody.
Net zoals in DA de webserver onder Apache draait. Alleen de DA servers waar ik mee werk zijn allemaal voorzien van mod-ruid.
De eigenaar van de Cpanel server wil het graag zou houden als het nu is, er gebeurt normaliter ook nauwelijks iets.

Maar ik vraag me nog steeds af, als ik geen vermoeden had gehad waar te zoeken, hoe ik dit op een of andere manier terug had kunnen leiden naar het betreffende gebruikersaccount.

Je kan ook voor mod_ruid2 kiezen. Daar draaien alle script ook onder de juiste username bij wie het daadwerkelijk hoort.

Indien het script nog draait kun je met "lsof -p [proces]" de gebruiker wel vinden.
In WHM kun je dit ook afvragen zonder eerst in te hoeven loggen via SSH.
Standaard wordt PHP overigens gecompileerd met suphp door cPanel bij een nieuwe installatie.

@Aar: op de DA servers heb ik ook overal mod_ruid2, werkt perfekt, maar Cpanel is wat apart en de server eigenaar wilde sowiezo geen suphp of mod_ruid op z'n server. Maar bedankt voor de tip.

@Dreamhost: Nja... een script draaide er niet, wel perl, maar als ik het me goed herinner draaide dat vanuit nobody, aangezien het om perl ging heb ik dat toen ook meteen gekilled.
Ik zit overigens sneller in SSH dan in WHM, ik neem aan dat je de procesmanager in WHM bedoeld?

mod_security is ook wel een aanrader. Die blokkeert een hoop requests die voor dit soort problemen zorgen, maar helaas ook wel een hoop false-positives. ook kan je bijv. met bijv. ossec geautomatiseerd zoeken naar oude versies van software.

Klopt, maar die moet je wel goed kunnen instellen. Die is ooit kort geinstalleerd geweest op die server, maar gaf toen meteen veel false positives bij een aantal forums en zorgde daar ook voor andere problemen. Ook bij de webshop van de eigenaar dus het moest er meteen weer af.
Ossec ga ik zeker eens naar kijken, bedankt voor de tip!