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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 52, views: 19.646 •

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)

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.
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?

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneMobiele besturingssystemen

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013