Telnet-daemon FreeBSD bevat al twintig jaar groot beveiligingsprobleem
Het opensource-besturingssysteem FreeBSD bevat al twintig jaar een groot beveiligingsprobleem in de telnet-server, waardoor extern root-toegang kan worden verkregen. De bug is mogelijk ook in Mac OS X en Linux-distro's te vinden.
Ontwikkelaars van FreeBSD kondigden het beveiligingsprobleem vlak voor het kerstweekend aan en hebben updates vrijgegeven om het probleem te verhelpen.
Volgens de ontwikkelaars werden ze daartoe gedwongen omdat de bug actief in het wild wordt misbruikt. De bug in de telnet-daemon maakt het mogelijk om extern root-toegang tot een server te krijgen.
De impact van het probleem valt waarschijnlijk mee, omdat gebruik van telnet al jaren wordt afgeraden: ssh is veel betrouwbaarder. Opvallend is wel dat de bug al twintig jaar in de software zit, en dus ook was te misbruiken toen telnet nog wel gangbaar was. Pas in 2001 werd telnet in FreeBSD standaard uitgeschakeld.
Thexploit schrijft dat het gaat om een buffer overflow-kwetsbaarheid, waarbij software de maximale lengte van een string niet goed controleert. Een aanvaller kan daardoor eigen code toevoegen, en in dit geval dus root-toegang krijgen.
Mogelijk is ook Mac OS X kwetsbaar, indien de telnet-daemon is ingeschakeld: uit de broncode van de telnet-client die Apple conform de licentievoorwaarden online heeft geplaatst, blijkt dat deze dezelfde code bevat. Ook de Debian-implementatie van de telnet-daemon was kwetsbaar, maar alleen als het Kerberos-protocol werd gebruikt. Debian wordt net als FreeBSD veel gebruikt in servers en onder meer Ubuntu is op Debian gebaseerd.
Reacties (66)
is toch niemand meer die dat gebruikt voor z'n servers neem ik aan?! voor switches ofzo wel.. maar server..
Een beetje switch doet tegenwoordig ook gewoon ssh hoor, bij mijn cisco stack heb ik telnet zelfs gedisabled
Zal voor switches waarschijnlijk ook niet van toepassing zijn, tenzij dat ze de code van die telnet daemon ook gebruikt hebben.
Mijn router draait telnet ... (Al denk ik niet dat hij via het internet benaderbaar is & alleen maar via LAN kant)
Werd het maar niet voor serveromgevingen gebruikt... ik beheer zelf helaas nog een systeem wat gebouwd is op een 20 jaar oud platform wat bovenop telnet draait. Valt niet te upgraden omdat de client alleen geen veilige protocollen ondersteunt en de client absoluut noodzakelijk is.
Ik denk dat in de zakelijke wereld, waar ook het 54 jaar oude Fortran nog niet uitgeroeid is, er nog echt teveel software met telnet werkt. Patchen dus maar...
Ik denk dat in de zakelijke wereld, waar ook het 54 jaar oude Fortran nog niet uitgeroeid is, er nog echt teveel software met telnet werkt. Patchen dus maar...
Tja, herkenbaar. Firewall ervoor, router erop en alle telnet via vpn's gecontroleerd tunnelen? Dure oplossing, wel veilig.
ahum, ooit gehoord van ssh tunnels? op de client gewoon te installeren?
Op een 20 jaar oud OS en hoogstwaarschijnlijk net zulke oude hardware?
Ik denk van niet.
Ik denk van niet.
Als die handel gewoon op het huidige netwerk zit is het goed te doen. Gewoon de verbinding via een ouwe pc oid sturen die alles wat van die oude computer naar buiten gooit direct een tunnel in stuurt. Tenminste, ik neem aan dat die telnet geen service is die naar buiten open moet staan.
Trouwens, een 20 jaar oud OS waarvan de netwerkstack nog in functie is heeft vast wel ernstigere lekken dan alleen een onbetrouwbare telnetd. Een oude Fortran-versie kan geen kwaad
Trouwens, een 20 jaar oud OS waarvan de netwerkstack nog in functie is heeft vast wel ernstigere lekken dan alleen een onbetrouwbare telnetd. Een oude Fortran-versie kan geen kwaad
Wel het zal vast n VAX-VMS systeem zijn, daar zit over het algemeen niet zoveel slechts in, en dan nog zijn er denk ik weinigen die uberhaupt weten hoe ze een dergelijk systeem zouden moeten aanvallen als ze het al kunnen.
De service hoeft niet naar buiten open te staan om misbruikt te kunnen worden, nog steeds vind een groot deel van de hacks op het interne netwerk plaats.
Voor wat Fortran betreft ben ik het met je eens.
De service hoeft niet naar buiten open te staan om misbruikt te kunnen worden, nog steeds vind een groot deel van de hacks op het interne netwerk plaats.
Voor wat Fortran betreft ben ik het met je eens.
Fortran mag dan 54 jaar geleden bedacht zijn, maar dat wil niet zeggen dat het al 54 jaar stil staat.
De code heeft geen GPL-licentie, maar een BSD-licentie (wat, gezien de afkomst, best logisch is...uit de broncode van de telnet-client die Apple conform de gpl-voorwaarden online heeft geplaatst...
)Welke code?
De telnet daemon heeft idd de BSD licentie (meeste 4-clause, maar er zit ook een stukje OpenBSD 3-clause uit '97 in).
Echter, de client is helemaal niet gelicenseerd onder BSD, maar onder superset APSL;
APSL 2.2 (c):
"(c) If You Externally Deploy Your Modifications, You must make Source Code of all Your Externally Deployed Modifications either available to those to whom You have Externally Deployed Your Modifications, or publicly available. "
De telnet daemon heeft idd de BSD licentie (meeste 4-clause, maar er zit ook een stukje OpenBSD 3-clause uit '97 in).
Echter, de client is helemaal niet gelicenseerd onder BSD, maar onder superset APSL;
APSL 2.2 (c):
"(c) If You Externally Deploy Your Modifications, You must make Source Code of all Your Externally Deployed Modifications either available to those to whom You have Externally Deployed Your Modifications, or publicly available. "
"uit de broncode van de telnet-client die Apple conform de gpl-voorwaarden online heeft geplaatst", en dan volg je de link, zie je een BSD licentie, of vergis ik mij? 
Verder, "actief in het wild gebruikt". Ik vraag me af wie in godsnaam nog telnet op zich actief gebruikt... de impact zal dus nog wel meevallen.
Verder, "actief in het wild gebruikt". Ik vraag me af wie in godsnaam nog telnet op zich actief gebruikt... de impact zal dus nog wel meevallen.
Bosjes mensen. Ik zie het regelmatig gebruikt worden voor virtual hosting. Net als FTP, overigens.
Het is blijkbaar populair om te zeggen dat Apple systemen een kwetsbaarheid bevatten tegenwoordig, maar in dit geval is niets minder waar: Geen enkel systeem heeft tegenwoordig nog telnet aanstaan (Linux, Mac, Windows,...) Dit is een beetje hetzelfde als zeggen "Windows 98 bevat nieuw ontdekte kwetsbaarheid". Niemand gebruikt het. Sterker nog: Als iemand telnet nu nog had openstaan was dat feit op zich al een groter security risico dan wat nu opgelost is.Mogelijk is ook Mac OS X kwetsbaar
Het verbaast me trouwens niet dat er bugs in zitten: Als een programma door bijna niemnd nog gebruikt wordt (of toch zeker niet in omgevingen waar security een issue is), zal er ook niet bijster veel meer op ontwikkelt worden.
Wat mij betreft: Iemand die heden ten dage nog telnet gebruikt verdient het gewoon om gehackt te worden
edit:
Nee! daar doel ik nu net op: Niemand is kwetsbaar behalve de wannabee tweaker die zijn telnet aanlegt. Het komt over alsof er een groot beveilingsprobleem, terwijl dat bijlange zo niet is. Moest deze bug bvb in de SSH code zitten, dan is er een groot probleem.OSX is gebaseert op BSD , en die bevat ook elementen van bsd , dus het zou best mogelijk zijn dat OSX ook kwetsbaar is.. Alle software heeft fouten is gewoon heel normaal
[Reactie gewijzigd door iMispel op maandag 26 december 2011 11:29]
Waarom nu weer bashen daarop? De nieuwpost gaat over de BSD telnet client en ook Debian en aanverwanten worden genoemd en dat ene zinnetje haal jij er dan weer uit ...
OSX is gebaseert op BSD. Dus OSX bevat ook elementen van BSD , dus het zou best mogelijk zijn dat OSX ook kwetsbaar is.. Alle software heeft fouten is gewoon heel normaal[...]
Het is blijkbaar populair om te zeggen dat Apple systemen een kwetsbaarheid bevatten tegenwoordig, maar in dit geval is niets minder waar: Geen enkel systeem heeft tegenwoordig nog telnet aanstaan (Linux, Mac, Windows,...) Dit is een beetje hetzelfde als zeggen "Windows 98 bevat nieuw ontdekte kwetsbaarheid". Niemand gebruikt het. Sterker nog: Als iemand telnet nu nog had openstaan was dat feit op zich al een groter security risico dan wat nu opgelost is.
Het verbaast me trouwens niet dat er bugs in zitten: Als een programma door bijna niemnd nog gebruikt wordt (of toch zeker niet in omgevingen waar security een issue is), zal er ook niet bijster veel meer op ontwikkelt worden.
Wat mij betreft: Iemand die heden ten dage nog telnet gebruikt verdient het gewoon om gehackt te worden
[Reactie gewijzigd door demilord op maandag 26 december 2011 11:26]
Ik vraag me af of traditionele bufferoverflows nog te exploiteren zijn. Er zijn tegenwoordig heel veel beschermingen ingebouwd tegen dit soort zaken; non-executable memory ranges (zoals de stack) en random maken van geheugenlayouts, sandboxing e.d.
Daarnaast wordt telnet natuurlijk nauwelijks meer gebruikt. Shell access staat default uit op Mac OS X, en als men het al weet te vinden en weet wat men doet zal men voor ssh kiezen en niet voor telnet.
Dus ja in theorie is het een kwetsbaarheid maar in de praktijk valt het reuze mee.
Daarnaast wordt telnet natuurlijk nauwelijks meer gebruikt. Shell access staat default uit op Mac OS X, en als men het al weet te vinden en weet wat men doet zal men voor ssh kiezen en niet voor telnet.
Dus ja in theorie is het een kwetsbaarheid maar in de praktijk valt het reuze mee.
Bij het gebruik van telnet wordt het wachtwoord in klare text verstuurd. Dat alleen is al een risico.
FTA:
"The timing, to put it bluntly, sucks. ... we try very hard to avoid issuing advisories any time close to holidays ... ... The start of the Christmas weekend -- in some
parts of the world it's already Saturday -- is absolutely not when we want to be
releasing security advisories.
Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd)
is a remote root vulnerability which is being actively exploited in the wild;
bugs really don't come any worse than this."
Maw: Als het zo moeilijk was om te exploiteren hadden ze vast wel tot woensdag 4 januari o.i.d. gewacht.
"The timing, to put it bluntly, sucks. ... we try very hard to avoid issuing advisories any time close to holidays ... ... The start of the Christmas weekend -- in some
parts of the world it's already Saturday -- is absolutely not when we want to be
releasing security advisories.
Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd)
is a remote root vulnerability which is being actively exploited in the wild;
bugs really don't come any worse than this."
Maw: Als het zo moeilijk was om te exploiteren hadden ze vast wel tot woensdag 4 januari o.i.d. gewacht.
OSX zou kwetsbaar kunnen zijn, als je de kennis hebt om in OSX telnet aan te zetten. Daar is geen GUI voor namelijk. In de GUI 'remote login' aanzetten, zet SSH aan.
[Reactie gewijzigd door CyBeR op maandag 26 december 2011 11:44]
ja of nc -l -p 666
Dat echo't alleen alle packets op TCP/666 op je huidige terminal... Wat heb je daar aan?
Voor Telnet zie je precies netjes alle wachtwoorden voorbij lopen.. mja, da's niet poort 666...
BSD is heel wat anders als FreeBSD. Wat bij OS X wel zo is, is dat ze voornamelijk de userland van FreeBSD hebben overgenomen (cd, ipfw, etc.).
Bij dit soort systemen staan al dit soort services standaard uit. Zeker tegenwoordig omdat telnet vrijwel niet meer gebruikt wordt. Voor Microsoft dan ook de reden om het maar gewoon in Windows Vista en 7 weg te laten (je moet het nu zelf handmatig installeren, ook wanneer je alleen de client wil). De client wordt vaak nog wel gebruikt om in te loggen op mailservers en hier bepaalde tests op uit te voeren. De security bulleting gaat echter alleen om een vullnerability in telnetd dus de daemon (in dit geval de server) en niet de client.
Of OS X vatbaar is valt te bezien. Ze hebben namelijk niet alle userland spullen overgenomen (in Lion zit wel pf maar in Leopard en Snow Leopard niet terwijl pf wel in FreeBSD zat in die tijd!) en een telnet server aanzetten in OS X is ook vrijwel niet te vinden. Houdt je de client over en die is dus niet kwetsbaar. Nou kun je het wel via Macports, Fink, Homebrew, enz. dit soort dingen installeren maar dat is niet hetzelfde als wat er in FreeBSD zit dus ook hier weer de vraag of je last hebt van die kwetsbaarheid. Roepen dat OS X er mogelijk last van heeft is eigenlijk een schot in het duister. Vergezocht maar niet helemaal ondenkbaar.
Om weer even terug komen op het FreeBSD verhaal: let wel op als je freebsd-update gebruikt om de updates binnen te halen. Het zijn er in totaal 5 stuks waaronder eentje voor libc. Voor wie de sources niet geinstalleerd heeft staan zal bij de libc patch tegen een probleem aan lopen. Hij probeert namelijk iets in /usr/src (de sources dus) te patchen. Als hij niets op die locatie vindt zal hij dat als foutmelding teruggeven en deze patch niet installeren. Helaas blijft de patch nog wel terugkomen wanneer je freebsd-update fetch draait en zal het systeem 'm ook weer willen installeren bij een freebsd-update install. Oplossing is vrij simpel: sources installeren. Voor wie dat niet wil/kan schijnt de directory die hij vraagt aanmaken ook al voldoende te zijn. Zie ook het topic op het FreeBSD forum: with freebsd-update install i get -> libc_dlopen.c: No such file or directory .
Bij dit soort systemen staan al dit soort services standaard uit. Zeker tegenwoordig omdat telnet vrijwel niet meer gebruikt wordt. Voor Microsoft dan ook de reden om het maar gewoon in Windows Vista en 7 weg te laten (je moet het nu zelf handmatig installeren, ook wanneer je alleen de client wil). De client wordt vaak nog wel gebruikt om in te loggen op mailservers en hier bepaalde tests op uit te voeren. De security bulleting gaat echter alleen om een vullnerability in telnetd dus de daemon (in dit geval de server) en niet de client.
Of OS X vatbaar is valt te bezien. Ze hebben namelijk niet alle userland spullen overgenomen (in Lion zit wel pf maar in Leopard en Snow Leopard niet terwijl pf wel in FreeBSD zat in die tijd!) en een telnet server aanzetten in OS X is ook vrijwel niet te vinden. Houdt je de client over en die is dus niet kwetsbaar. Nou kun je het wel via Macports, Fink, Homebrew, enz. dit soort dingen installeren maar dat is niet hetzelfde als wat er in FreeBSD zit dus ook hier weer de vraag of je last hebt van die kwetsbaarheid. Roepen dat OS X er mogelijk last van heeft is eigenlijk een schot in het duister. Vergezocht maar niet helemaal ondenkbaar.
Om weer even terug komen op het FreeBSD verhaal: let wel op als je freebsd-update gebruikt om de updates binnen te halen. Het zijn er in totaal 5 stuks waaronder eentje voor libc. Voor wie de sources niet geinstalleerd heeft staan zal bij de libc patch tegen een probleem aan lopen. Hij probeert namelijk iets in /usr/src (de sources dus) te patchen. Als hij niets op die locatie vindt zal hij dat als foutmelding teruggeven en deze patch niet installeren. Helaas blijft de patch nog wel terugkomen wanneer je freebsd-update fetch draait en zal het systeem 'm ook weer willen installeren bij een freebsd-update install. Oplossing is vrij simpel: sources installeren. Voor wie dat niet wil/kan schijnt de directory die hij vraagt aanmaken ook al voldoende te zijn. Zie ook het topic op het FreeBSD forum: with freebsd-update install i get -> libc_dlopen.c: No such file or directory .
Het lijkt er anders zeer sterk op dat ze (Apple) het meeste wel rechtstreeks van Free/OpenBSD hebben overgenomen, kijk maar eens hoe vaak FreeBSD in de code genoemd is:
http://opensource.apple.c...rk_cmds-85/telnetd.tproj/
Hier gaat het echter om het Kerberos protocol, dat is ontwikkeld in Zweden (Heimdal) (GitHub-link) en de cryptografie waar het hier om gaat zo te zien aan MIT.
http://opensource.apple.c...rk_cmds-85/telnetd.tproj/
Hier gaat het echter om het Kerberos protocol, dat is ontwikkeld in Zweden (Heimdal) (GitHub-link) en de cryptografie waar het hier om gaat zo te zien aan MIT.
Ze doen leentjebuur bij voornamelijk FreeBSD wat userland zaken betreft maar vergeet niet dat FreeBSD dit ook doet bij NetBSD, OpenBSD en waar het allemaal mee begon: BSD4.4 zelf. Dat zie je aan de manuals van de diverse tools maar ook aan de manier waarop bepaalde zaken werken. Dat pf verhaal is iets wat ze van FreeBSD hebben overgenomen die het weer van OpenBSD heeft overgenomen want OpenBSD is de geestelijke vader van pf. De kernel van OS X is weer een ander verhaal, dat komt elders vandaan.
Al met al is OS X dus een mix van tools en code die uit diverse hoeken, maar voornamelijk die van BSD en FreeBSD, vandaan is gehaald. Voor veel FreeBSD gebruikers is dit wel de reden geweest om voor hun desktop een Mac te gebruiken. Idem voor andere UNIX(-achtigen) gebruikers. Dit gegeven zorgt er echter ook voor dat je moet oppassen met het wijzen met je vingertje. Het is niet zo dat alles bij FreeBSD vandaan wordt geplukt en dat bugs in FreeBSD dan ook altijd van toepassing zijn op OS X. Het is niet meer dan een mogelijkheid.
Al met al is OS X dus een mix van tools en code die uit diverse hoeken, maar voornamelijk die van BSD en FreeBSD, vandaan is gehaald. Voor veel FreeBSD gebruikers is dit wel de reden geweest om voor hun desktop een Mac te gebruiken. Idem voor andere UNIX(-achtigen) gebruikers. Dit gegeven zorgt er echter ook voor dat je moet oppassen met het wijzen met je vingertje. Het is niet zo dat alles bij FreeBSD vandaan wordt geplukt en dat bugs in FreeBSD dan ook altijd van toepassing zijn op OS X. Het is niet meer dan een mogelijkheid.
[Reactie gewijzigd door ppl op donderdag 29 december 2011 12:36]
Ik had bij de laatste ontdekte security exploit in de telnet daemon van FreeBSD al geen telnet daemons meer draaien, en zo uit m'n hoofd was dat in 1999. Het staat per default ook uit sinds tijden.
Sinds 2001 staat dat uit. Staat in het artikel.
ik blijf me toch verbazen over de hoeveelheid meldingen over toegang tot systemen door simpel een buffer-overflow te veroorzaken. dit is al zo lang bekend als toegangsmethode voor hackers dat je toch zorgt dat dat binnen je eigen pakket op een juiste manier wordt tegengegaan 
Als het actief ontwikkelde software zou zijn: ja. Maar je maakt mij niet wijs dat er nog actief ontwikkeld wordt aan de telnet daemon van FreeBSD. Het is niet alsof het veel gebruikte software betreft. (de telnet daemon, that is, FreeBSD wordt wel veel gebruikt).
Het kan ook best zijn dat er al een hele tijd niemand meer actief / specifiek verantwoordelijk was voor telnetd binnen het FreeBSD project. Dan kunnen dit soort geintjes er makkelijker tussendoor glippen.
Het kan ook best zijn dat er al een hele tijd niemand meer actief / specifiek verantwoordelijk was voor telnetd binnen het FreeBSD project. Dan kunnen dit soort geintjes er makkelijker tussendoor glippen.
Dit zit er dus al 20 jaar in, en 20 jaar terug was het wel anders. Overigens zijn er nog steeds virtual hosting aanbieders die er gewoon telnet en ftp bij stoppen, en dus bosjes mensen die dat nog braaf gebruiken.
@A4-tje: buffer-overflows komen vaak voor, net als SQL injecties nog vaak voorkomen, of passwords in plain text. Er zijn gewoon veel programmeurs die niet tot nauwelijks kunnen programmeren. En die het wel kunnen maken nu en dan wel eens een foutje ;-).
@A4-tje: buffer-overflows komen vaak voor, net als SQL injecties nog vaak voorkomen, of passwords in plain text. Er zijn gewoon veel programmeurs die niet tot nauwelijks kunnen programmeren. En die het wel kunnen maken nu en dan wel eens een foutje ;-).
Dat schijnt inherent te zijn aan het gebruik van C. Voor iedere string die je kopieert wordt een routine gebruikt die de lengte van de bestemmingsbuffer niet als parameter meegeleverd krijgt. Die moet dus vooraf gecontroleerd worden, en dat wordt wel eens vergeten. Hoog tijd voor een andere opzet zou ik toch denken.
goed, jij bedenkt dus de programmeertaal die C gaat vervangen, begrijp ik? Succes.Hoog tijd voor een andere opzet zou ik toch denken.
Schijnt, maar in werkelijkheid heb je behalve al sinds jaar en dag een functie als strncpy naast de oude onveilige functie strcpy.
Dat veel gemakzuchtige of slecht ingelichte programmeurs de verkeerde functie pakken... Tsja...
Dat veel gemakzuchtige of slecht ingelichte programmeurs de verkeerde functie pakken... Tsja...
[Reactie gewijzigd door mae-t.net op maandag 26 december 2011 17:42]
strncpy is een stuk jonger dan deze flaw volgens mij.
Ik heb in de jaren 90 C geprogrammeerd en toen was er op vrij zeker en al een strncpy maar bovenal bekendheid met dit probleem.
Had u even de Apple-broncode nagebladerd, had u gezien dat OpenBSD's 'strlcpy' is gebruikt en niet strncpy. "strlcpy" is juist gemaakt omdat strncpy onveilig is.
Artikel hier.
Artikel hier.
Als ik dat artikel zo lees, dan zijn die functies gemaakt omdat strcpy onveilig is. Strncpy blijft ook nog steeds veiliger dan strcpy, maar strlcpy heeft nog wat meer toegevoegde waarde.
Er is helemaal niets mis met strcpy... als je al eerder gecontrolleerd hebt hoe groot je buffers zijn...
Hmm..... wel goed dat dit naar buiten is gekomen, zullen alle routers, switches en ander appliances eindelijk standaard SSH gaan krijgen?
Ook ssh kan lekken bevatten.
Als SSH komende 20 jaar niet ontwikkeld wordt is er geheid ook een lek gevonden die root toegang blootstelt na die periode.
Als SSH komende 20 jaar niet ontwikkeld wordt is er geheid ook een lek gevonden die root toegang blootstelt na die periode.
Wat een lamme fix trouwens. http://security.freebsd.org/patches/SA-11:08/telnetd.patch
Iemand stuurt duidelijk een bufferoverflow en dan wordt daar practisch niks mee gedaan behalve dan het teveel aan gestuurde informatie negeren.
Iemand stuurt duidelijk een bufferoverflow en dan wordt daar practisch niks mee gedaan behalve dan het teveel aan gestuurde informatie negeren.
wat ook prima is om met de teveel aan informatie te doen. Want die hoeveelheid informatie hoort niet, protocol technisch. Discarden is dus een valide methode.Iemand stuurt duidelijk een bufferoverflow en dan wordt daar practisch niks mee gedaan behalve dan het teveel aan gestuurde informatie negeren.
Het discarden moet gebeuren maar ik zou toch graag een log-entry zien.
Als je 100+ servers beheert kan zo'n log entry je aan je reet roesten Bovendien lijkt het me dat security-minded beheerders telnet sowieso niet aan hebben staan.
Bovendien lijkt het me dat security-minded beheerders telnet sowieso niet aan hebben staan.Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
