Webhosting bedrijf vertikt lek in server te dichten!

[Puntslash]

Ja ik weet niet of dit hier thuis hoort, lijkt me wel.

Ik kwam laatst op een site die gebruik maakte van php. Het bleek echter niet in safemode te draaien. Die site is van een aantal bekenden van mij dus ik dacht: eens kijken hoever ik kom..

Dmv wat commando's uit tevoeren wist ik de mysql user/pass te achterhalen, deze bleek hetzelfde te zijn als het unix account dus ik kon via ftp de index veranderen, gewoon voor de gein.

Nah het geintje werd wel gewaardeerd door die lui maar de sysadmin van die server vertikt nu om safemode aan te zetten met het risico dat dit weer gebeurd.
zie hier de conversatie:

http://www.blueyellow.nl/...thread.php?tid=268&page=2

Wat vinden we hiervan, hoe kan je die sysadmin aan zijn verstand peuteren zodat hij wel die optie aanzet??

[SyphOn]

[..]
Dan ziet ie wel in dat hij het aan gaat zetten.

Adminbreak: Nee, dat lijkt me niet de bedoeling, en daar gaan we mensen hier niet voor aanmoedigen.

[ Voor 67% gewijzigd door Roelant op 25-02-2003 10:43 ]

[bruto]

Geen PNS

Voor de rest: contract ontbinden en bij een hoster gaan zitten die wel op security gesteld is.
Als je die thread leest dan lijkt het erop dat hij de commercieele belangen voor de veiligheid kiest. Kortom: eieren voor je geld kiezen, sowiezo afspreken dat je niet betaald eer ze die zooi niet uitzetten.

[Roelant]

Professional Networking & Servers >> Internet & Telefonie

Normaal gesproken is het eigenbelang voor de hostingprovider om dergelijke dingen te dichten, dus dit is wel een vrij unieke situatie. Ik zou ook niet echt weten in hoeverre je een hostingprovider kunt verplichten om een bepaald lek te dichten, daar zou je je contracten (SLA) eens op na moeten kijken.

Overigens is het vrij gebruikelijk dat PHP niet in safe mode draait, omdat je dan toch al toegang moet hebben om scripts te plaatsen om daar misbruik van te kunnen maken. Daarnaast is het "lek" in dit geval ook gedeeltelijk te wijten aan de gebruiker, want om nou hetzelfde wachtwoord te gebruiken voor je DB als voor je shell user is niet echt handig.

[Bigs]

Ik host zelf ook een aardig aantal websites, maar ik heb geen safemode aan staan hoor.. gewoon om de reden dat dat gruwelijk irritant is. Er zijn genoeg andere manieren om je bestanden en rest van het systeem te beveiligen.

[Roelant]

Precies

Als ik het goed begrijp zit het "probleem" hem in het feit dat je met PHP toegang hebt tot de broncode van de (je eigen?) scripten op de server, en daar een database password uit kan halen.

Dat het database password en het password van de shell user hetzelfde zijn, is namelijk niet te verwijten aan de provider, maar aan de gebruiker

[weerdo]

Safemode = verlies van functionaliteit. Hoe je het wendt of keert..

De webhoster verliest klanten op het moment dat hij die optie aanzet. Kon je info van andere domains ophalen die bij die webhoster gehost waren of was alleen dat desbetreffende domain kwetsbaar?

Ik zou als webhoster een default .htaccess file installeren waarin safemode standaard aan wordt gezet. Als de gebruiker dan die .htaccess aanpast: prima, maar dan ben je op eigen risico bezig.. Als de webhoster een chrooted jail heeft geimplementeerd, dan ben je sowieso van een aantal problemen verlost.

En dat de username-password combo voor mysql gelijk is aan de username password-combo van het account is ook niet erg gezond..

[Stewie!]

xxplosiefje schreef op 25 February 2003 @ 10:19:
Ja ik weet niet of dit hier thuis hoort, lijkt me wel.
Dmv wat commando's uit tevoeren wist ik de mysql user/pass te achterhalen, deze bleek hetzelfde te zijn als het unix account dus ik kon via ftp de index veranderen, gewoon voor de gein.

Wat vinden we hiervan, hoe kan je die sysadmin aan zijn verstand peuteren zodat hij wel die optie aanzet??

wat jij hier zegt is geheel ten onrechte. Beetje dom van je zelfs.
Als die "vrienden" van je konden php schrijven, dan hadden ze die scripts wel dichtgetimmerd, biujvoorbeeld doormiddel van alle input validation! Doen ze dat niet, en jij weet toevallig bij welke scripts je moet starten, dan kom je inderdaad ver ja. Maar dat heeft niks met de server te maken, het is zelfs belachelijk dat een betaalde host php in safe mode zou draaien, dan kan je een hoop namelijk niet.

Conclusie: leer je vrienden secure php proggen en val BY niet meer lastig
* Stewie! is niet echt fan van BY, maar je moet hem ook weer niet vals beschuldigen

[Verwijderd]

weerdo schreef op 25 February 2003 @ 11:01:
Safemode = verlies van functionaliteit. Hoe je het wendt of keert..

De webhoster verliest klanten op het moment dat hij die optie aanzet.

Dat is onzin, it's all about de juiste manier van proggen en scripten. Er zijn maar weinig mensen die 'safemode uit' ECHT nodig hebben. Op een virtual server gaat veiligheid echt boven wat 1 op de 150 klanten wil. Klanten die persee safemode aan willen kunnen danwel ontheffing daarvoor vragen bij $webhoster danwel een eigen server planten/leasen.

$webhoster heeft als verplichting de boel veilig en up-to-date te houden, zowel voor zichzelf (denk aan claimes) als voor zijn klanten. Als hij dat niet doet terwijl hij op de hoogste is van het lek, dan heb je prima het recht simpelweg de overeenkomst te ontbinden en/of schade te gaan claimen.

[ Voor 4% gewijzigd door Verwijderd op 25-02-2003 11:31 ]

[weerdo]

Verwijderd schreef op 25 February 2003 @ 11:24:
Dat is onzin, it's all about de juiste manier van proggen en scripten. Er zijn maar weinig mensen die 'safemode uit' ECHT nodig hebben. Op een virtual server gaat veiligheid echt boven wat 1 op de 150 klanten wil. Klanten die persee safemode aan willen kunnen danwel ontheffing daarvoor vragen bij webhoster danwel een eigen server planten/leasen.

Eens, wat echter gesuggereerd werd, was dat safemode per default aan werd gezet, zonder dat de klant daarop enige uitzondering kon maken. Reken maar dat een webhoster klanten verliest of niet krijgt op het moment dat hij de policy "safemode is aan, geen uitzondering mogelijk" doorvoert..

Kun je trouwens die 1:150 claim hard maken?

webhoster heeft als verplichting de boel veilig en up-to-date te houden, zowel voor zichzelf (denk aan claimes) als voor zijn klanten. Als hij dat niet doet terwijl hij op de hoogste is van het lek, dan heb je prima het recht simpelweg de overeenkomst te ontbinden en/of schade te gaan claimen.

Hangt er vanaf hoe de overeenkomst is opgezet en waar de precieze schuldvraag in dit soort gevallen ligt. Het is heel gemakkelijk om bouwer-fouten op de webhoster af te wentelen; er ligt ook een verantwoordelijkheid bij de klant. En mijn mening is: zolang een klant door scriptfouten zijn eigen site om zeep laat helpen, dan is dat zijn probleem, niet die van de webhoster.

Als een webhoster verzaakt, waardoor een exploit in een script van een klant de veiligheid van een webserver zodanig aantast waardoor kwaadwillenden bij gegevens van andere klanten kan komen..

[ Voor 19% gewijzigd door weerdo op 25-02-2003 11:45 ]

[Verwijderd]

weerdo schreef op 25 February 2003 @ 11:38:
[...]

Eens, wat echter gesuggereerd werd, was dat safemode per default aan werd gezet, zonder dat de klant daarop enige uitzondering kon maken. Iets wat niet zo makkelijk is door te voeren. Maar reken maar dat een webhoster klanten verliest of niet krijgt op het moment dat hij de policy "safemode is aan, geen uitzondering mogelijk" doorvoert.

Ik denk dat $webhoster meer klanten zal verliezen als blijkt dat alle gegevens (en dus ok privacy gevoelige gegevens) open en bloot liggen en elke mede-klant gewoon zijn website kan aanpassen/wissen/vervangen, mysql database kan uitlezen/aanpassen/wissen etc.

[...]

Hangt er vanaf hoe de overeenkomst is opgezet en waar de precieze schuldvraag ligt. (En in dit soort gevallen kan men niet altijd de webhoster rechtstreeks aanwijzen; er ligt ook een verantwoordelijkheid bij de klant).

Je kunt bij dit soort dingen wel $webhoster aanwijzen, het is namenlijk zeer zeker aannemelijk te maken dat $webhoster er voor moet zorgen dat de gegevens van de klant veilig zijn. Zeker als $webhoster deze taak overduidelijk verzuimt door een 'lek' open te laten, sta je in het volste recht wat te ondernemen alswel een claim alswel ontbinding van het contract.

[jep]

What about safemode/basedir_restriction . Doe ik ook aan. Geen safemode, en toch niet buiten je directory kunnen. Veilig, en functioneel.

[ Voor 41% gewijzigd door jep op 25-02-2003 12:03 ]

[Puntslash]

DaMorpheus schreef op 25 February 2003 @ 11:04:
[...]

wat jij hier zegt is geheel ten onrechte. Beetje dom van je zelfs.
Als die "vrienden" van je konden php schrijven, dan hadden ze die scripts wel dichtgetimmerd, biujvoorbeeld doormiddel van alle input validation! Doen ze dat niet, en jij weet toevallig bij welke scripts je moet starten, dan kom je inderdaad ver ja. Maar dat heeft niks met de server te maken, het is zelfs belachelijk dat een betaalde host php in safe mode zou draaien, dan kan je een hoop namelijk niet.

Conclusie: leer je vrienden secure php proggen en val BY niet meer lastig
* Puntslash is niet echt fan van BY, maar je moet hem ook weer niet vals beschuldigen

Het is mijn intensie ook niet geweest om hem lastig te vallen, ik wil hem slechts wijzen op een zwak punt op zijn server
Die input validation is nu ook al actief

jep schreef op 25 februari 2003 @ 12:03:
What about safemode/basedir_restriction . Doe ik ook aan. Geen safemode, en toch niet buiten je directory kunnen. Veilig, en functioneel.

Dat zou idd een goeie optie zijn..