Lekke cms'en bezorgen providers hoofdbrekens

Niet dat ik dit soort lekken-misbruikende bots nou zo prettig vind, maar misschien wordt dit soort grappenmakers eindelijk eens het zetje in de rug dat die providers nodig hebben om te gaan upgraden naar PHP5 :-)

www.gophp5.org/

Ik denk dat het tijd wordt om standaard in een cms een functionaliteit te hebben die de admin eens per dag oid per mail waarschuwt als er een security-update uit is. Moet niet zo heel moeilijk te programmeren zijn.

Herkenbaar probleem. Echter ondervangen wij een hoop door o.a. onze servers uit te rusten met mod_security, niet te schuitig te zijn met open_basedir en de /tmp als noexec te mounten. Daarbij wordt er actief (zowel handmatig als automatisch) gecontroleerd wat er verder nog aan scripts etc in de tmp belandt. Sinds deze maatregelen hebben we het aantal geslaagde hackpogingen (even afkloppen) teruggebracht naar 0 (en in de logs is te zien dat er wel continu druk geprobeerd wordt)

En nu wachten op de eerste die roept: PHP is onveilig... Het zijn dus mensen die niet of brak kunnen/willen programmeren en dus prehistorische versies gebruiken die php een onveilige naam geven. Gehackte php sites beginnen allemaal met bekende issues die ook spelen bij ASP (bv. SQL injection en het klakkeloos toestaan van uploads).

Conclusie: een programmeertaal is niet onveilig, maar de programmeur.

Vind je het gek dat ze het drukker krijgen: het is zomervakantie. Alle scriptkiddos ter wereld zijn weer lekker hun vrije dagen aan het opvullen met zinloos gecomputer...

Mhhh.... Waarom bieden deze providers het installeren van die patches dan niet gewoon als service aan? Ze kunnen het eenvoudig automatiseren en hebben zelf als geen ander zicht op welke update belangrijk zijn en welke niet.

Deze 'providers' weten duidelijk niet waar ze mee bezig zijn. En zodoende is dit artikel aardig wat anti-reclame voor ze. Wij hebben deze problemen al jaren opgelost door o.a. :

- uitgaand IRC verkeer te blokkeren in de firewall.
- up- en download binaries als wget, curl etc root-only te maken, zodat Apache er niet bij kan.
- mod_security te gebruiken als URL-filter (houdt sowieso al bijna alles tegen)
- open_basedir te zetten in php
- evt. /tmp als noexec te mounten.

Beetje admin moet dit toch zelf ook kunnen verzinnen.

Lekkere reklame voor jezelf... Hosting-aanbieder Dig|talus weet blijkbaar niet hoe ze voor hosting-aanbieder moeten spelen.

Net zoals iedere "huis-tuin-en-keuken copy-paste-programmeur" zichzelf sitebouwer durft te noemen, zo roept ook iedere knul met een colo-servertje dat hij "hosting provider" is.

Kortom, ga je schamen, in een klein hoekje. En voor Maarten Reijnders, fijn te weten dat persberichtjes van je vrienden nog steeds klakkeloos worden overgenomen door webwereld. Ze zullen het nodig hebben in hun komkommermomentje.

Enfin, we hebben weer gelachen. Jammer dat door dit soort brutselhosting aanbieders en papagaaijournalisten de branche als geheel slecht in het nieuws komt.

Nu kunnen de handige harries wel lopen brullen dat de extra kosten op de sitebouwers moeten verhalen, maar jullie houden er geen rekening mee dat content zoals Joomla en Mambo , gratis wordt aan geboden. De meeste "amareur" sitebouwer, zoals ik , gaan er van uit dat een nieuwe versie van een cms veilig is..En na een tijdje blijkt deze dus niet (meer) veilig is. Als ik een component of module cq plugin installeer, ga ik er wel vanuit dat het veilig is. Ik kan nl. niet programeren, en heb ook geen behoefte om het te leren. Daarom zijn dit soort systemen zo handig. Iedereen kan er mee overweg. Het goed beveiligen van een site is dus bijna een onmogelijke opgave.

De genoemde CMS'en in dit artikel heb ik geprobeerd maar snel links laten liggen en begonnen met CMS Made Simple, snel en makkelijk aanpasbaar en voor zover ik dat kan inzien voldoende veilig.
Mijn CMS is nog niet gehacked in tegenstelling tot mijn forum wat draaide op een PHPBB versie die door vakantie van mijn kant 3 maanden niet onderhouden was.

Dat is al jaren bekend!

SAFE_MODE aan op die dump bakjes.

Ja hier hebben we ook wel wat klanten gehad die problemen ondervonden met de email module uit Joomla waardoor er veel spam verstuurd kon worden. Gewoon het CMS up to date houden of eventueel gebruikmaken van CAPTCHA scripts maar deze kunnen inmiddels ook worden gedetecteerd door bepaalde software, zie http://blogs.pandasoftware.com/blogs/images/PandaLabs/2007/07/24/xrumer.swf .

Het probleem is dat de mensen zichzelf webmaster noemen zonder dat ze uberhaupt een simpel scriptje kunnen maken die controleerd of de waardes wel correct worden ingevuld, laat staan een update voor de scripts uit te voeren met bv patch files.

De problemen moet gewoon gezocht worden bij de hostingproviders. Ongeveer 99 van de 100 zijn er erg onveilig ingericht. Digitalus moet de schuld dan ook bijzich zelf en NIET bij z'n klanten. Als ze de servers goed hadden ingericht dan mag het NOOIT voorkomen dat een gebruiker schade KAN aanrichten aan de rest van de server. Als bij een klant dan zijn stukje wordt gehacked dan mogen andere klanten daar geen last van hebben.

Door chrooten en/of virtualisatie is dat zeer goed mogelijk. Alleen heeft dat wat meer resources nodig en kunnen hostingproviders minder klanten kwijt op één server. Dus minder geld in het laatje en een onveilige server...

De volgende versie van Drupal, Drupal 6, zal een update notification module bevatten, waardoor gebruikers onmiddellijk een bericht ontvangen wanneer een nieuwere versie van een bepaalde module (plugin) beschikbaar is. Allicht zal dit ook een deel van het probleem oplossen.

Raar artikel het CMS de schuld geven, in bijna geen enkel geval is het de CMS zelf (uitzonderingen daar gelaten) het gaat meestal om veel gebruikte plugins die niet van de CMS bouwer zelf afkomen. Daarbij wordt het gewoon een simpel PHP scriptje neergezet (wget niet nodig hoor, laat ook zien hoe goed sommige hier van weten) waar men gezellig een PHP upload doet van het volgende tooltje (lees= deface van pagina, spam script, phising site noem het maar op).

Je kunt uiteraard als provider besluiten om PHP uploads te verbieden (dmv setting in php), maar denk dat je dan snel je deuren kan sluiten.

Uiteraard zijn een aantal modules zoals mod_security wel handig, maar zeker niet voldoende tegen modules die gewoon zo lek zijn als een mandje.

Eigenlijk vindt ik dat dit soort script kiddies tegen de muur gezet moeten worden; maar dat mag niet helaas.

derick 16-08-2007 09:12
PHP 5 gaat dit natuurlijk niet verbeteren. Het blijft gewoon de verantwoordelijkheid van de gebruikers om alle updates te installeren, en dat is ongeacht van welke programmeertaal er nu gebruikt wordt.
PHP 5 gaat dit wel degelijk verbeteren, onder andere doordat een aantal brakke design features gewoon standaard uit staan c/q niet meer backwards compatible zijn of beter beveiligd zijn. (open basedir, register globals, php.ini) Feit blijft inderdaad dat je óók met PHP5 brakke code kan schrijven die bijv SQL injectie of root access toelaat maar dat ligt eerder aan een programmeur.

Oke ik wil toch even reageren omdat er hier toch wat mensen kort reageren over mijn antwoorden (ik ben die Krist). Ik vind het knap dat jullie ons als prutsers weten te bestempelen zonder te weten hoe ons hosting platform in elkaar zit. Ik zal hier niet te diep over in gaan maar in ieder geval draaien onze sites in een jail en gebruiken wij ook nog een applicatie firewall. Als mensen dan nog aan komen met als oplossing het mounten van de /tmp dir als noexec en het blokkeren van irc verkeer (6667), dan moet ik wel even lachen ... *kuch* helpt niets. Maar ja de beste beveiligers zitten aan de wal natuurlijk :)

Waarom was het tot nu toe eigenlijks echt mogelijk om websites te hacken (bij Digitalus)? Juist omdat een heel groot aantal van onze klanten zaken zoals register_globals eisten. Nu makers van Joomla het vereisen dat register_globals uit willen hebben, hebben wij onze verantwoordelijkheid ook genomen.

Dit probleem speelt niet bij ons alleen, dit speelt bij ALLE hosting partijen.Zolang je cgi/php diensten aanbied zal misbruik worden gemaakt. Maar uiteraard zal je altijd achter feiten aanblijven lopen...

Goed dit was mijn kant van het verhaal.

Zolang CMS oplossingen als web applicaties draaien blijft er altijd een risico omdat feitelijk de hele wereld bij de applicatie kan komen. Als je bedenkt dat, laten we zeggen, 25% van de sites met een populair CMS niet, of niet goed worden geupdate is dit een zeer interessante doelgroep voor kwaadwillende. Dit is ook exact de reden geweest waarom wij een offline CMS hebben ontwikkeld voor onze klanten. Dit heeft wel andere nadelen, maar veiligheid is er niet één van! Ik wil hier geen reclame maken. Als je meer wilt weten hoe het wel veilig kan kan je mijn gebruikersnaam ombouwen tot URL.