PDA

Bekijk Volledige Versie : Hackscript voor root toegang?



Blacky
01/12/14, 04:53
Kan dit tegenwoordig nog kwaad op een cpanel server?
Vannacht probeerden hackers in te breken op onze cpanel server. Gelukkig had csf en maldet het snel genoeg in de gaten.
Dus files gewist en account waarvan het geprobeerd werd suspended.
Maar in het geheugen bleef nobody toch nog mooi een r00t.pl draaien die via wget dit hackscript probeerde te halen:
http://pastebin.com/hxKynFxR

Na een herstart van httpd en een kill van de wget was het over. Meteen ook wget beveiligd.

Deze cpanel server draait helaas niet op mod_ruid2 (is nog niet stabiel in cpanel dacht ik) maar ook niet op suphp omdat de eigenaar dat nog steeds niet wil ondanks mijn herhaalde waarschuwingen en aandringen.:(
Met als gevolg de nodige scripts met 777 directory's enzo en alle gevolgen van dien. 1x lek scriptje en je kunt leuke malware scriptjes als nobody draaien.

Ik ben in niet zo thuis in scripting, maar het is al een dingtje uit 2012. Men zou er root toegang mee kunnen krijgen, kan dat nog?
http://pastebin.com/hxKynFxR
Ik neem aan dat er weinig tegen te doen is zonder mod_ruid of suphp? Ik heb zelfs bij lekke scripts en mod_ruid2 nog soortgelijke grappen zien gebeuren.

SebastiaanStok
01/12/14, 09:10
" maar ook niet op suphp omdat de eigenaar dat nog steeds niet wil ondanks mijn herhaalde waarschuwingen en aandringen."
Hoeveel is een gehackte systeem tegenover één klant waard?

Is deze klant echt zo belangrijk dat je een gehackt systeem kan veroorloven?

systemdeveloper
01/12/14, 10:41
suPHP helpt je toch niet tegen een perl script...

SebastiaanStok
01/12/14, 11:12
Hehe, daar heb je een goed punt :D ik las zoals gewoonlijk weer veel te snel :pinch:

Voor PHP bestaat er naast mod_ruid2 alleen suphp en PHP-FPM als oplossing.
PHP-FPM heeft mijn voorkeur omdat de gebruiker word gewisseld voor het forking proces wat het een stuk moeilijker maakt om fouten in PHP zelf te misbruiken.
Ik weet alleen niet hoe de cPanel ondersteuning voor PHP-FPM is.

Voor Perl is er eigenlijk maar één (buiten mod_ruid2) oplossing (naar mijn weten) en dat is suexec.

joriz
01/12/14, 12:30
Het kan kwaad afhankelijk van hoe je server is geconfigureerd. Bij ons staan gevoelige PHP-functies zoals system uit. Daarnaast kan een mod_security configuratie en CXS veel tegen houden.

Als het script daadwerkelijk is uitgevoerd heb je mogelijk een groot probleem.

Domenico
01/12/14, 16:05
Ik dacht zoals joriz ook aan mod_security.

En wat SebastiaanStok en systemdeveloper zeggen. :)

Blacky
01/12/14, 16:11
Hoeveel is een gehackte systeem tegenover één klant waard?
Ehmz LoL, lees eens 1 regel hoger die je quote.... die man is eigenaar schreef ik. Dus geen klant van me in die zin. Ik doe wel support op de server voor hem.

Suexec staat bij mijn weten wel aan. Mod_ruid2 is zogezegd experimental in Cpanel dus hoe stabiel is dat? Heeft wel mijn voorkeur. En php-fpm geen idee. Mod_security heb ik eens geprobeerd maar toen ging gelijk vanalles mis (teveel geblocked met een default config), daar weet ik gewoon te weinig van om daarmee te rommelen. Ik vind zelf gewoon dat ie suphp of mod_ruid maar moet toelaten, wil ie dat niet dan loopt ie zekere risico's.
De andere beveiligingen staan in elk geval wel aan en compilers en wget is beveiligd dus dat maakt het ze ook moeilijk.


Als het script daadwerkelijk is uitgevoerd heb je mogelijk een groot probleem.
Niet ik, maar hij. :)
Kunnen ze echt root krijgen met zo'n script dan? Het scriptje heeft gedraaid, maar die website die dat script met wget probeerde te bereiken, was niet actief, daarnaast was dat ip geblokkeerd en geen wget rechten dus ze kregen de benodigde rommel niet binnen.

Maar dat is dus eigenlijk ook de vraag, is apache dan nog zo lek dat ze via nobody dan toch root toegang kunnen krijgen?

RayManZ
01/12/14, 17:38
Als perl toch niet gebruikt wordt kun je deze toch ook gewoon uitschakelen net zoals wget. Gewoon alleen de zaken aanzetten die ook echt nodig zijn. Zelfde geld voor php functies en CGI.

Blacky
02/12/14, 16:19
Met perl is het een beetje een probleem. Deze wordt namelijk ook door de firewall CSF en plugin gebruikt.
Heb deze op een DA server al eens beveiligd met als gevolg dat de CSF plugin in het adminpanel een wit scherm gaf en niet meer werkte totdat ik perl weer op 755 zette.
Zal eens proberen of die plugin op cpanel blijft werken, zoja, dan gaat perl ook weer op veilig, chmod 700 zou moeten voldoen,toch?

Voor php heb ik momenteel dit al: disable_functions = "dl,show_source,system,shell_exec,passthru,popen,pr oc_open"
Had er eerst nog wat meer disabled maar dan begon Magento met plugins of een andere shop te mauwen.