Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 52 reacties

Een lek in de website van het Spoorwegmuseum had tot gevolg dat 125 andere websites op dezelfde server eveneens toegankelijk waren. De permissies klopten niet. Ook een andere server was door een lek voor iedereen toegankelijk.

SpoorwegmuseumBeveiligingsonderzoeker Ingratefully ontdekte het beveiligingsprobleem. Hij bemerkte niet alleen dat het Spoorwegmuseum kwetsbaar was voor sql-injectie, ook kon hij via het cms inloggen op het ftp-account van de website.

Daar bleek een upload-script te staan dat hij vervolgens gebruikte om een tool te uploaden waarmee hij via php shell-commando's kon uitvoeren. Dit bleek niet alleen toegang te verschaffen tot alle bestanden op de Spoorwegmuseum-site, maar ook tot die van 125 andere websites. Onder meer de broncode van de websites en database-backups waren toegankelijk, onder andere van de site van de VVV Maastricht, maar vooral van kleinere sites. Dat was het gevolg van slecht ingestelde permissies; normaliter hoort dat niet te kunnen.

Hetzelfde lek was aanwezig op de website van museum Het Domein, van dezelfde ontwikkelaar, en ook in dat geval waren circa 125 andere websites kwetsbaar. Ingratefully schat in totaal toegang te hebben gehad tot in ieder geval 100.000 e-mailadressen, waarvan de helft uit de database van het Spoorwegmuseum kwam.

Volgens Lukas van der Hijden, directeur van BIC Multimedia, dat de sites ontwikkelde, is het beveiligingsprobleem inmiddels opgelost. "In september is er ook al iemand binnengedrongen in ons cms", aldus van der Hijden. Dat zou echter los hebben gestaan van het jongste probleem. Volgens hem en een andere medewerker van het bedrijf deed het probleem met de uploadfunctie zich voor door een verhuizing, waarna htaccess-bestanden niet meer werden geaccepteerd.

Volgens BIC treft echter ook de hostingprovider, e-Quest, blaam; die had zijn permissiesysteem niet goed afgedicht, waardoor ook andere websites toegankelijk waren. Patrique Dankers, directeur van e-Quest, zegt echter: "Volgens mij proberen ze nu de bal naar ons door te spelen, maar zij hebben bij ons een webserver staan." Later geeft hij echter toe die claim niet te kunnen onderbouwen; er staan ook andere sites op de server.

Dankers stelt ook dat geen naw-gegevens toegankelijk waren, maar dat is in strijd met de claims van onderzoeker Ingratefully. Dankers stelt vragen bij de expertise van de beveiligingsonderzoeker, wil weten wie er achter de naam Ingratefully schuilgaat en dreigt zelfs met aangifte. De directeur zegt de dupe te zijn geworden van het beveiligingslek in het Spoorwegmuseum. "Anders was die onderzoeker nooit op de server gekomen." Volgens een andere medewerker van e-Quest waren de permissies onjuist omdat BIC daar om vroeg. "Bepaalde grote klanten willen dat, dat vinden ze handiger", zegt hij. "Wij willen het liever niet."

Reacties (52)

Reactiefilter:-152051+123+24+30
Moderatie-faq Wijzig weergave
"Bepaalde grote klanten willen dat, dat vinden ze handiger", zegt hij. "Wij willen het liever niet."
LAAT ZE DAN EEN EIGEN SERVER HUREN!!!
"Wij" is hier e-Quest (en niet een klant die een website wil laten hosten), die zegt het niet te willen dat de rechten met opzet fout worden ingesteld. Maar het toch doet... :r Om maar geen grote klanten kwijt te raken.
Met zo'n instelling is 't geen wonder dat 't mis gaat. Een instelling die het gevolg is van een te ver doorgeschoten hang naar vrije marktwerking (in het algemeen).

[Reactie gewijzigd door kimborntobewild op 14 maart 2012 04:48]

Standaard reactie van meneer de directeur. Hij kan duidelijk de fout niet toegeven en reageert met beschuldigingen richting de beveiligingsonderzoeker om de aandacht van zich weg te leiden.

Als nu Ingratefully negatief in het nieuws komt kan Dankers zich (deels) goed praten, maar 't klinkt wel heel erg als een stuiptrekking gezien het feit dat hij en zijn bedrijf er duidelijk voor gekozen hebben om specifieke klantwensen te verkiezen boven de algehele beveiliging.

Ook de schuld leggen bij het Spoorwegmuseum is schijnheilig, iedereen hier weet dat de hosting provider eindverantwoordelijke is voor de beveliging tussen verschillende websites op je server.
Dit is een veelvoorkomend probleem met shared-webhosting, voornamelijk met Plesk en Cpanel oplossingen. Hiervan hebben we afgelopen week al genoeg gezien op tweakers.

Shared hosting moet je alleen maar gebruiken voor websites die geen of weinig prive gegevens bevatten van bezoekers of klanten tenzij je er vanuit kan gaan dat de hoster veel server/hosting beveiligings ervaring heeft. Iedereen kan namelijk een Ubuntu bak met Plesk opzetten, wat niet aangeeft dat ze er ook echt iets van begrijpen.

We kunnen hier wel alleen de webhoster de schuld van geven, maar als we eerlijk zijn, weten we dat de standaard instellingen van PHP bijna alles toelaten.

[Reactie gewijzigd door 316234 op 14 maart 2012 00:24]

Dankers stelt vragen bij de expertise van de beveiligingsonderzoeker...
Hij stelt zich wel vragen bij de expertise van de beveiligingsonderzoeker, maar niet bij de expertise van zijn eigen personeel of zijn eigen beslissingen?
Hij wil weten wie er achter de naam Ingratefully schuilgaat en dreigt zelfs met aangifte.
Waarom denk je dat de persoon in kwestie een schuilnaam gebruikt? Je kan maar proberen, natuurlijk. :X
"Bepaalde grote klanten willen dat, dat vinden ze handiger"

Dus "bepaalde grote klanten" staan op een webserver met 124 andere sites, blijkbaar, en hebben daarmee zeggenschap over de veiligheid van al die andere klanten? Lekker is dat.

Hoe groot ben je overigens als klant als je op shared-hosting account staat met zoveel anderen? Of is die "webserver" een heel rack?
Dus "bepaalde grote klanten" staan op een webserver met 124 andere sites, blijkbaar, en hebben daarmee zeggenschap over de veiligheid van al die andere klanten?
Het is uiteraard onwetmatig het zo in te stellen dat een beheerder van een website zomaar bij andere bestanden op die server kan die niet van zijn bedrijf zijn.
e-Quest zou zeker vervolgd moeten worden. Dat gaat niet gebeuren (vrije marktwerking is heilig, he...). M.a.w: deze malafide praktijken zoals e-Quest die doet, blijven gewoon voortduren.
Slechte zaak dit, ik neem aan dat ze dit wisten want in de tekst staat:
Volgens hem en een andere medewerker van het bedrijf deed het probleem met de uploadfunctie zich voor door een verhuizing, waarna htaccess-bestanden niet meer werden geaccepteerd.
Dus ze hebben het aangepast, maar nooit meer naar omgekeken?
De directeur zegt de dupe te zijn geworden van het beveiligingslek in het Spoorwegmuseum. "Anders was die onderzoeker nooit op de server gekomen."

Volgens een andere medewerker van e-Quest waren de permissies onjuist omdat BIC daar om vroeg. "Bepaalde grote klanten willen dat, dat vinden ze handiger", zegt hij. "Wij willen het liever niet."

Nou fijn bedrijf dat E-quest, "heeft u vertrouwen in onze kennis en kunde" ....
nou NEE echt niet meer, het lijkt me voor elke tweaker zo klaar als een klontje, al was spoorwegmusuem zo lek als een zeef, dan nog hadden de "hackers" NOOIT bij andere sites mogen komen , dat is wel degelijk 100% de verantwoordelijkheid van e-quest met al hun kunde .. hoe stom kan je zijn om zo te reageren en dan vooral waar alle tweakers het lezen.

de 2e reaktie zegt ook genoeg over de kennis en kunde van de medewerkers, wij willen het liever niet, zou moeten zijn, dat het domweg niet is toegestaan.
Je neemt me de woorden uit de mond. Als klanten dat anders willen dan geeft dat mij de indruk dat daar een goede reden voor moet zijn geweest. Gevalletje ik kan geen bestanden wijzigen, dus gebruik maar chmod 777?

"Dankers stelt vragen bij de expertise van de beveiligingsonderzoeker, wil weten wie er achter de naam Ingratefully schuilgaat en dreigt zelfs met aangifte."
Je weet dat je beveiliging niet op orde is, word vervolgens gehackt (door een whitehat) en gaat dan dreigen met aangifte terwijl je wist het niet op orde was?? 8)7 Ieder die de moeite neemt om je op een lek te wijzen en er geen 'echt' misbruik van maakt zou je juist dankbaar moeten zijn. (Hij doet zijn naam niet echt eer aan...).
Je weet dat je beveiliging niet op orde is, word vervolgens gehackt (door een whitehat) en gaat dan dreigen met aangifte terwijl je wist het niet op orde was??
Ik denk niet dat Dankers weet wat white-hat is. Erg slecht voor de veiligheid dat de directeur zo'n totale computerleek is. En dan ook nog zo stom zijn om je technische werknemers onder druk te zetten onveilige zaken toe te staan. Als je er geen verstand van hebt... Bemoei je er dan niet mee! Ga dan lekker ergens anders een baan zoeken... vakken vullen in een supermarkt ofzo.
Dit is volgens mij gedeeltelijk een fout van de hosting provider (e-quest). Die moet er voor zorgen dat je niet bij de andere accounts kan komen.
Ik herken het wel, ik heb jaren geleden hetzelfde ondekt bij de provider waar ik een website hostte. Via een normaal http adres was er niets aan de hand, maar via script talen kon ik in gedeelten komen waar ik geen rechten toe behoorde te hebben. Iets in de trand van:
/ was de root van mijn account,
../ was de directory waar alle websites in stonden.
Ik kon zelfs terug tot de linux root, en /etc directories. Later is dit gepatched, en was het niet langer mogelijk.
Dat je bij / en /etc kan op een 'shared' server is niet zo heel ongebruikelijk volgens mij (maar waarschijnlijk wel onwenselijk; beter kan je webhosting klanten gewoon jailen ofzo). Maar simpelweg de webserver zo configureren (m.b.v. FastCGI oid) dat je PHP scripts met de user van de klant draait geeft je in ieder geval de mogelijkheid om websites te isoleren. Alleen zie je nog wel eens dat shared hosting omgevingen waar je wel je eigen user met beperkte rechten krijgt, dat PHP scripts gewoon als de webserver user (apache) draaien, waardoor je dus toegang tot andere sites kan krijgen.
Ik maak doorgaans per gebruiker twee UNIX users aan: eentje waarmee alles is aan te passen binnen het account, en een speciale web user waaronder de PHP scripts e.d. draaien. De webserver start de scripts per virtual host als de juiste users met FastCGI o.i.d...

Dus bv. sfynx en www_sfynx.
De www_ variant is de web user die binnen het account dan alleen kan lezen, tenzij de owner/group/permissies erin zo staan dat deze mag schrijven (voor file uploads e.d.) of juist bepaalde bestanden niet mag lezen.

Zo voorkom je twee dingen:
- geen algemene www gebruker die bij alle accounts iets kan uitrichten
- toegang als de web user betekent geen toegang tot het hele account, dat is uit het perspectief van de klant namelijk een persoonlijke 'root' account.

Dat voldoet wel doorgaans voor een shared setup dacht ik zo :)

[Reactie gewijzigd door Sfynx op 13 maart 2012 19:33]

Ligt aan de contractovereenkomsten. Een eigen server welke colocated bij de hoster staat heeft e-quest helemaal niks meer mee te maken

[Reactie gewijzigd door kmf op 13 maart 2012 14:14]

125 websites op 1 webserver O_O
Shared hosting, look it up.
Freebsd bak met 6000 virtualhosts is gewoon prima te doen
...als het allemaal kleine, onbekende, zelden bezochte sites zijn.

[Reactie gewijzigd door kimborntobewild op 14 maart 2012 05:02]

Dat kan prima, is geen probleem. Vooral als het veel persoonlijk websites en blogs zijn. Die zien niet snel meer dan 100 bezoekers per dag, een server trekt makkelijk 12500 bezoekers op een dag :).

Wel vind ik dat de hoster heel veel blaam treft hier. Dat de site niet goed was en dat er daardoor wat geupload kon worden is kwalijk maar daar had alleen de site van het museum zelf last van. Doordat de host niet alle permissies goed had ingesteld kon je bij alle websites komen, iets wat normaal echt niet hoort te kunnen. Deze horen compleet afgescheiden te zijn van elkaar (op een virtueel niveau). Er was nu niet eens een echte hack nodig om bij de rest te komen.
Je weet dat dat niks voorstelt? Op vele hosting servers staan er nog veel meer :)
is vrij normaal volgens mij. Je zit met kleine websites altijd gedeeld op een grote server waar je een eigen mapje krijgt die voor jou alleen toegankelijk is (zo ging het bij hosting2go.nl tenminste) Plesk login was ook "server 18" en dan je acount invoeren.

Maar dit is wel ronduit schandalig van het hostings bedrijf. Dat betekt dus dat de eigenaren van een kleine site ook gewoon bij het spoorwegmuseum site hadden kunnen komen, en bijvoorbeeld het betalings script voor de webshop aanpassen waardoor het geld op hun rekening kwam.
Dat betekt dus dat de eigenaren van een kleine site ook gewoon bij het spoorwegmuseum site hadden kunnen komen
Ja, exact.
en bijvoorbeeld het betalings script voor de webshop aanpassen waardoor het geld op hun rekening kwam.
Nee, er is binnen Linux strict onderscheid tussen "read", "write" en "execute". Ze hadden alle bestanden kunnen lezen, maar waarschijnlijk niet kunnen aanpassen.
[...]
Ja, exact.
Als iedere klant zijn eigen account heeft, en enkel het account van het spoorwegmuseum heeft meer rechten gekregen, dan waren deze 'hacks' niet vanuit andere sites uit te voeren.
Nee, er is binnen Linux strict onderscheid tussen "read", "write" en "execute". Ze hadden alle bestanden kunnen lezen, maar waarschijnlijk niet kunnen aanpassen.
Niet alleen binnen Linux hoor. Maar als je bestanden van andere klanten in een dergelijke configuratie al kunt lezen, dan kun je er donder op zeggen dat schrijven ook geen probleem was.
Nee, er is binnen Linux strict onderscheid tussen "read", "write" en "execute". Ze hadden alle bestanden kunnen lezen, maar waarschijnlijk niet kunnen aanpassen.
Mooie aanname.
Maar als de rechten verkeerd staan, dan zouden die restricties ook "zomaar" teveel kunnen zijn. Je weet namelijk niet op welk niveau en hoe de rechten fout stonden.
Gevalletje 777 op alle bestanden en mappen recursief toepassen, ben het vaak zat tegengekomen.. Zoals ook in het artikel wordt gezegd "dat vinden ze handiger" uhu.. |:(
Dit is gewoon een gevalletje van slechte permissies. Honderden klanten op één server is geen probleem. Met de cloud is het nog erger. Dan gebruik je vele servers om slechts één platform te genereren. Dan heb je dus tienduizenden websites op de cloud, die bij slechte beveiliging dus allemaal in één keer slachtoffer kunnen worden.

Dit is gewoon afschuwelijk slecht van de hostingprovider. Ze hebben zulke grote klanten die waarschijnlijk meer dan een paar tientjes per jaar betalen. Uit dit artikel kan ik opmaken dat ze gewoon een standaard-Linuxinstallatie draaien en niet eens de moeite hebben genomen om te kijken of elke gebruikersaccount slechts bij zijn eigen account kan. Indien normale accounts bij alle data kunnen van andere gebruikers, dan kun je niet spreker over een beveiligingslek, maar een gebrek aan beveiliging.

Ik ben zelf heel lang webhoster geweest en er werden elke week wel 3 of 4 websites gehackt. Indien je honderden websites per server draait, dan is het cruciaal dat je de beveiliging van de server op orde hebt, want hacks zijn als webhoster de normaalste zaak van de dag.
Honderden klanten op één server is geen probleem.
In theorie niet. Maar in de praktijk dus wel.
En de praktijk is wat telt.
Maar ik neem aan dat het hier om een webshell gaat die men geupload heeft, bijgevolg gebeuren alle commandos met de gebruiker van de httpd. Is het dan niet normaal dat deze ook aan de directory kan van andere sites die op dezelfde server worden gehost? Of zijn er webservers die elke vhost van een aparte user/chroot voorzien zodat je binnen een container blijft?
Per website hoort er gewoon een user te zijn die niet bij de bestanden van andere websites kan. Dan maakt het niet uit op wat voor manier (http, ftp, ssh etc) de hacker binnen komt. Verder dan de bestanden van die user kan die niet.
Precies, ondanks dat dit een lek is in de website van het spoorwegmuseum, blijft het een kwetsbaarheid in de instellingen van de server, en DUS iets dat je de hoster zou moeten aanrekenen.
Wat ik dan niet snap is dat iedereen hierboven over linux praat terwijl ik op de site van e-quest alleen maar shared hosting onder Windows terug zie.
Dan zou het helemaal raar zijn dat je rechten niet goed zijn aangezien je dan gewoon op user niveau aan het werk bent en je in IIS aan kunt geven welke mappen de betreffende user mag bereiken.

Of zie ik het nu verkeerd?

Bron:
http://www.e-quest.nl/shared-hosting.html

P.s.
Ze hosten zelfs Frontpage *proest*.
Ik vond 't ook raar dat iedereen er maar vanuit ging dat 't Linux was.

Maar voor Windows geldt hetzelfde als Linux; je kunt het best makkelijk vernaggelen. Op IIS hoef je namelijk helemaal niet een user per applicatie te hebben. Als je verstand van zaken hebt werk je inderdaad op user niveau, maar dat zullen ze wel niet gehad hebben, daar men via Spoorwegmuseum direct toegang kreeg op de overige websites.

Ze zullen volgende keer wel twee keer nadenken bij het inrichten van hun serveersoftware.
Site op dit moment niet meer benaderbaar.

Ietwat offtopic:

Onder Linux geeft het pingen van "www.e-quest.nl" rare verwijzingen van andere domeinen terug (zelfde registrars). Wellicht wat aan de hand met DNS...

Op dit item kan niet meer gereageerd worden.



Microsoft Windows 10 Home NL Apple iPhone 6s Star Wars: Battlefront (2015) Samsung Galaxy S6 Edge Apple Watch Project CARS Nest Learning Thermostat Besturingssystemen

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True