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 , , 65 reacties

Een beveiligingsonderzoeker heeft in websites van tien banken, waaronder ING, de Rabobank en ABN Amro, een xss-kwetsbaarheid gevonden. Daardoor konden kwaadwillenden eigen formulieren in de websites van de banken injecteren. Het probleem is inmiddels opgelost.

Naast ING, de Rabobank en ABN Amro hadden ook de websites van Binck, Alex, ASN, Knab, SNS, Triodos en de Belgische Van Lanschot-site last van het cross site scripting-probleem, zegt onderzoeker Wouter van Dongen van DongIT tegenover Nu.nl. "Die zaten voor het overgrote deel in Flash-bestanden", zegt hij tegenover Tweakers.

De xss-kwetsbaarheden bevonden zich in de voorpagina's van de bankensites. Een aanvaller had het probleem kunnen misbruiken door eigen code te injecteren in de website, maar hij moest zijn potentiële slachtoffers er dan wel toe verleiden om op zijn link te klikken. De techniek zou onder meer kunnen worden gebruikt in phishing-mails. Gebruikers worden vaak opgeroepen om de url van de site te controleren. Die zou dan kloppen, terwijl de aanvaller zijn eigen code kan injecteren.

Van Dongen heeft een proof of concept gemaakt waarbij de html-elementen op de bankensites beginnen te schudden. "Ik heb expres geen eigen formulieren op de bankensites gezet", aldus Van Dongen. Inmiddels hebben de banken het beveiligingsprobleem opgelost.

Woordvoerder Ronald van Buuren van ING bevestigt de bevindingen van Van Dongen. "We zijn in november benaderd, en daarna is het beveiligingsprobleem vrij snel opgelost", aldus Van Buuren. Hoe snel het probleem is opgelost, is niet bekend. Van Buuren zegt blij te zijn met hulp van onderzoekers als Van Dongen. Ook woordvoerder Margo van Wijgerden van de Rabobank bevestigt het lek. Volgens haar ging het om een relatief klein probleem.

Update, 20:57: Reactie Rabobank toegevoegd.

Moderatie-faq Wijzig weergave

Reacties (65)

Dit is nou een voorbeeld van hoe het wel moet. White-hat hacker doet bevinding, meldt dit netjes. Het probleem wordt opgelost, en zodra het probleem is opgelost stapt de onderzoeker naar de media. Geen aangiftes en toch weer een veiligere wereld.
Let wel, hier is er met (zeg iets in de trant van) 45 dagen iets aan gedaan, bij de lek in Windows duurde het meer dan 90 dagen, geloof maar dat deze beveiligings-onderzoeker na 90 dagen ook publiek was gegaan, dat is heel normaal.

Dat Microsoft zicht nu gedraagt als "geslagen hond" betekend niet dat ze gelijk hebben.
Maar laten we die discussie lekker in het betreffende artikel voeren ;)
Datzelfde google laat oude android gebruikers qua veiligheid nu barsten, oude android versie en browser, zoek het maar uit. Wat zegt dat over google.

45, 90 dagen het gaat er om hoe je er mee omgaat. De ene vindt 90 dagen genoeg de ander 30. Het hangt allemaal samen de de aart van de bug, hoe kritsich is deze hoe snel op te lossen, wat voor extra problemen kan een patch geven.

In dit geval is het netjes gedaan zoals het hoort.
Oude versie van Windows/IE zoek het maar uit, wat zegt dat over Microsoft?

Het is ook een drukmiddel om mensen te doen overstappen naar iets nieuwers en dus te consumeren.
Dat doen heel veel bedrijven, en soms zijn de motivatie's misschien minder netjes maar het werkt vaak wel.
oudere versies, 10 jaar oud tegen 2 jaar oud google.
Denk dat je heel goed weet dat MS heel lang ondersteuning geeft engoogle tja 2 jar spreekt voor zich
Langer, dat klopt maar ik heb er dan ook aardig voor m'n windows licenties moeten betalen. Van Google mag ik gratis android gebruiken, is om die reden alleen al niet echt te vergelijken. 2 jaar is bovendien best lang in de mobiele wereld waar de ontwikkelingen zich nog steeds in een hoog tempo opvolgen.
android is niet gratis je betaald met je privacy en google dat alles van jou logt.

Voor sommige mensen is dat gratis maar dat is het dus keihard niet.
Publiceren doe je om de 'beheerder' te dwingen een beveiligingsissue op te pakken. Als je 90 dagen niet reageert, snap ik dat je gaat publiceren. Als je binnen 90 dagen keurig reactie krijgt dat het opgepakt / opgelost wordt (maar wel nét buiten de 90 dagen), vind ik publiceren niet netjes. Ik snap heel goed dat MS nu pissed is, deze publicatie dient immers geen enkel doel behalve MS zwart maken.
Uit persoonlijke ervaring kan ik zeggen dat een 'belofte om het te fixen' bij lange na geen garantie is dat er ook daadwerkelijk een patch volgt. Het is dan ook geheel redelijk om 90 dagen als harde deadline te hanteren; ik vind het persoonlijk zelfs nog wat te ruim.
wat ik me dan wel afvraag, bij wie zou jij de schuld gelegd hebben als het lek wat door google is bloot gelegd, misbruikt zou worden bij jou bedrijf, en jij er schade door zou hebben ondervinden?

MS heeft google om uitstel gevraagd zodat ze het met aankomende patch ronde konden mee sturen. Daar heeft google dus op geantwoord door het lek op en bloot kenbaar te maken.

Als er schade door zou ontstaan zou ik linea recta naar google gaan, en niet naar MS. Iets kenbaar maken is wat anders dan je concurrentie op deze manier een hak zetten en bewust publiekelijk proberen te kleineren.
Let op: Microsoft vroeg Google om 2 dagen uitstel, maar ze bedoelde hierbij 2 weken. Dat is best een flinke fout.

Overigens, als er schade zou ontstaan, is dit de schuld van diegene die het lek misbruikt, en daarna Microsoft. Google is niet verantwoordelijk voor het lek. Iedereen met kennis van dit lek had het meteen kunnen publiceren.
Heb ook verschillende posts gelezen (waarheid kan ik niet verifieren) waar MS helemaal geen tijdsbestek aangeeft, maar gewoon vraagt of google gewoon de tijd geeft om de patch met de nieuwe ronde mee te laten lopen.

Weet dus nog niet helemaal of die 2 dagen een fout is, of dat het een interpretatie is van een journalist en dat het gewoon over genomen word.
Iedereen met kennis van dit lek had het meteen kunnen publiceren.
voor zover bekent is het toch een zero day lek? Dus niemand had de kennis voor zover bekent. De kennis is bekent geworden nadat google het openbaar maakte. Zolang het een zero day exploid is, vind ik google meer verantwoordelijk als MS in dat geval.
voor zover bekent is het toch een zero day lek?
Dat zegt niets over het al dan niet gebruikt zijn van het lek, enkel over de status van publicatie (al dan niet bedoeld).
Ik heb begrepen dat google wil dat het een vanzelfsprekendheid wordt dat het na 90 dagen openbaar wordt.
Denk dat dat een goede zaak is.
Dat Microsoft zicht nu gedraagt als "geslagen hond" betekend niet dat ze gelijk hebben.

Blijkt dus dat Microsoft niet "niets" gedaan had, maar dus een fix klaar en deze wereldwijd op de gebruikelijke (!) Patch Tuesday ging uitbrengen.

Maar Google verzuimde even de telefoon te pakken en te bellen ... Nu is iedereen in de admin en security wereld bekend met Patch Tuesday dus onwetenheid bij Google kan men niet pleiten. Google heeft inmiddels toegegeven gewoon geen contact gezocht te hebben en enkel als automatisme op een semi-feesdag het lek wereldkundig gemaakt te hebben.

Ofwel, zeker iets waar Google ongetwijfeld van geleerd heeft en de volgende keer beter zal doen.
Persoonlijk vind ik het hele concept van een 'Patch Tuesday' bijzonder onverantwoordelijk en zelfs nalatig, waar het draait om beveiligingslekken. Dit soort patches dienen direct na het testen uitgegeven te worden.
Dat gebeurde vroeger ook. Het probleem is alleen dat bugfixes eerst goed getest moeten worden op een bedrijfssysteem om te controleren of geen programma's niet omvallen. Omdat dit veel tijd kost, werden bugfixes opgespaard om een hoeveelheid in één keer te testen. Dit is op zich geen probleem, behalve dat de bugfix ook een publieke bekendmaking is van de kwetsbaarheid en derhalve zal deze vlak daarna ook (vaker) misbruikt gaan worden. Via patch tuesday wordt een goede balans gezocht tussen theoretische veiligheid en de praktijk. 0-days die al misbruikt worden, worden nog steeds zo snel mogelijk out-of-band uitgebracht.
Waarom lukt het diverse Linux-distributies als Debian dan wel om beveiligingspatches buiten een cyclus uit te brengen, zonder dat daardoor systemen omvallen?

Wat betreft je laatste punt: je weet niet of 0-days al misbruikt worden. Dat is waarom je aan moet nemen dat ieder lek al misbruikt wordt, en zo spoedig mogelijk moet patchen.
ja heeeel goed... krijgt niet voor betaald... kost hem veel werk en tijd en de bedrijven krijgen de info gratis en dat kan gewoon weg niet ...

en een dom tshirt helpt ook niet.
Ik vind het filmpje niet echt duidelijk het probleem in beeld brengen. Er bestaan algemene harlemshake-scriptlets die je als URL/bookmark kan invoeren die de elementen laten bewegen op de maat van de muziek. Is er ook wat meer bekend over de werkwijze hoe hij deze hack uitvoert?

Als de werking van de hack meer iets meer uit de doeken werdt gedaan, tot op zeker hoogte, dan zouden anderen ook zich tegen deze hack kunnen wapenen. Denk eens aan webwinkels of andere sites met transactiemogelijkheden.

[Reactie gewijzigd door AW_Bos op 12 januari 2015 16:24]

Van de eerste drie banken kan je de URL nog vaag zien in het filmpje. Voor wat betreft Knab.nl #2 was JW Player de oorzaak, en Rabobank #3 had blijkbaar nog ergens AnyChart.swf staan in hun CSS folder. Van beide zijn er XSS exploits bekend in oudere versies.

Waar het dus op neer komt is dat je altijd op je hoede moet zijn bij het gebruik en / of installatie van 3rd party tools op je website. Up to date houden is één zaak, volledig verwijderen van je website zelfs als ze niet actief in gebruik zijn is ander. ;)

[Reactie gewijzigd door Ravefiend op 12 januari 2015 17:31]

heb het maar even opgezocht: ING Woordvoerder Ronald van Buuren
Hadden de andere banken nog wat te melden?

[Reactie gewijzigd door Peter R op 12 januari 2015 16:15]

Kennelijk niet O-)

Overigens wil dat niet zeggen dat andere banken stil zitten. Zo was ABN-AMRO bijvoorbeeld vatbaar voor de TLS variant van POODLE. Op 9 december was er een fix klaar, maar pas begin januari had ABN-AMRO die fix uitgerold. Geen sneer, want juist het uitrollen en testen van zo'n fix duurt erg lang en dan waren er ook nog de feestdagen.

Dus men werkt gewoon vaak ook in stilte aan problemen die niet in de media komen.
Hmmm, ING had 'TLS Poodle' anders binnen 24 uur opgelost. En die XSS was bij de meeste banken in een 'promotioneel' onderdeel; niet het internet-bankieren gedeelte.

Maar goed, daar de ABN-AMRO tot 2.5x zo duur is als de goedkoopste NL bank (voor 'particulier internetbankieren'), ben ik daar als klant best wel verbolgen over ... de goedkopere concurrentie kan het blijkbaar beter :(
ING zit achter Akamai, ABN-AMRO heeft eigen load balancers dus ik denk dat het daar in zat. Maw ING was waarschijnlijk nooit kwetsbaar voor POODLE TLS anders dan hun caching servers. Bij ABN-AMRO waren de eigen servers kwetsbaar.

Grote banken zoals Bank of America en Chase hebben het ook pas begin januari gefixt. Waarschijnlijk was toen bepaalde USA certifciatie pas klaar.
Jawel; het ging bij ING om Mijn ING (die staat niet achter Akamai lijkt het), niet om www.ing.nl. Blijkbaar was ING wel in staat om haar eigen servers/loadbalancers te patchen. Certificering staat daar helemaal los van lijkt me, juist ING doet wel zaken in USA en Canada, waar ABN-AMRO dat volgens mij (stukken) minder / niet doet ...

[Reactie gewijzigd door SKiLLa op 12 januari 2015 23:15]

Dat is waar ik op doelde. Bij ING was het enkel het Nederlandse telebankier deel. Ofwel een relatief kleine site die vrijwel zeker niet onder buitenlandse wetgeving valt. Het merendeel van ING.nl zit namelijk zoals gezegd bij Akamai.

Bij ABN-AMRO was het de hele site. Vandaar dat mijn vermoeden is dat er externe certificering aan te pas kwam. De fix was namelijk letterlijk op dezefde dag als Chase en Bank of America. Toeval? Ik denk het niet ...

Immers je kunt natuurlijk wel gewoon stoer aannemen dat men zit te slacken :) maar een patch flashen is niet zo moeilijk dus de vertraging komt ongetwijfeld door test-werk.
Maar goed, daar de ABN-AMRO tot 2.5x zo duur is als de goedkoopste NL bank (voor 'particulier internetbankieren'), ben ik daar als klant best wel verbolgen over ... de goedkopere concurrentie kan het blijkbaar beter :(
Ik betaal voor m'n cj betaalrekening 2 euro p.p.p.m met daarbij ook een kostenloze creditcard standaard in het pakket. Ongetwijfeld kan het goedkoper, maar zo hard drukken die twee euro niet op mijn maandlasten, voor die twee euro krijg je wel een degelijke uitgebreide website en de meest geavanceerde app in de markt. Je kan chillen op de schiphol lounge, en itt een internetbank, kun je wel gewoon contant geld opnemen.
Ik kan mij zo voorstellen, dat als je het toen al opgelost had, je het niet direct wilde melden, omdat je collega's wellicht nog wel kwetsbaar zijn. Pas als alle banken het opgelost hebben, is het aan een bank/de banken om het te melden. De enige bank waarvoor dit 'probleem' actueel is en die het tegelijkertijd mag melden, is dan de hekkensluiter.
Dank voor de extra info, ik vroeg me al af welke woordvoerder de moeite had gedaan te antwoorden. Pluspuntje voor de ING dus, netjes dat ze hier goed en (op aanvraag) openlijk mee omgaan.
"Die zaten voor het overgrote deel in Flash-bestanden", zegt hij tegenover Tweakers.
Eigenlijk weer een argument waarom Flash z.s.m. uitgebannen moet worden.
Toevallig heeft dit artikel ook een Flash element (de video), waarom is dat geen HTML5?
Het is embedded YouTube, ik denk dat je dan daar HTML5 moet inschakelen. Hier heb ik geeneens flash aanstaan en de video speelt gewoon af.
Ah thx, zit hier met een oudere Firefox te werken, daar staat het standaard uit!
Ik heb de youtube HMTL5 player anders, die heeft inderdaad een flash fall back.
Werkt dit trouwens nog wel bij de Rabobank? Al enige tijd moet ik het bedrag voor de komma invoeren in de random reader. Als ik dus een code genereer voor een CD van 20 euro en moet opeens 5000 invullen als tweede controle getal dan moet dat doorgaans een belletje doen rinkelen.

Maar goed, dit zal net zo goed bij de kleine minderheid er door heen glippen..
Ja, ze zouden dan het rekeningnummer kunnen wijzigen, terwijl hij op jouw scherm netjes het rekeningnummer weergeeft van diegene waarvan je de CD koopt.
Athans, dat verwacht ik dat ze ermee kunnen, uit het verhaal is het niet geheel op te maken. Wel tricky dat de browser gewoon aangeeft dat se site veilig/echt is.
De vraag is of deze kwetsbaarheid ook daadwerkelijk direct van invloed was op het gedeelte van de sites waar je transacties uitvoert. Het artikel heeft het over de voorpagina van de sites. Dan denk ik eerder dat je hoogstens richting vissen naar inlog codes moet denken door een fake inlogformulier in een pagina te smokkelen. Nog steeds erg link natuurlijk.
Het wijst op een structureel probleem.
De meeste XSS-problemen kun je voorkomen door de juiste programmeertools te gebruiken. Sterker nog, het is haast niet te doen om een moderne, veilige website helemaal met de hand te schrijven. Er kan zo ontzettend veel mis gaan dat je wel gespecialiseerde tools moet gebruiken.

Als je dit soort gaten in je front-page hebt dan heb je niet de juiste tools gebruikt en zitten er waarschijnlijk ook vergelijkbare fouten in andere pagina's.
Voor zover ik begreep waren het hier juist externe tools/plug-ins waar de kwetsbaarheden in zaten, doordat die niet up to date waren. Ik kan me zo voorstellen dat er voor de daadwerkelijke bankierpaginas strengere interne eisen en controles gelden en daar niet van dergelijke externe componenten worden gebruikt.

Hoe dan ook een kwalijk verhaal.
Maar dan nog, als ik lees dat het probleem bij de Rabobank in AnyChart.swf zat, en ik me bedenk dat, als ik bij de Rabo inlog er grafiekjes van mijn in- en uitgaven gegenereerd wordt, dan kan ik me voorstellen dat hier mogelijk een verband tussen zit, en daarmee het dus mogelijk is geweest ook binnen het gedeelte waar transacties worden uitgevoerd code te te injecteren.
Tsja wat verwacht je van een browser dan he?
Ik bedoel de webserver zal gewoon nog het ingestelde certificaat blijven leveren. De content komt van de "echte" webserver van de bank en vervolgens word er met XSS andere zooi geïnjecteerd.

Een browser kan moeilijk snapshots gaan nemen van HTML van elke mogelijke website ofzo en dat vergelijken met wat een gebruiker binnen trekt. Of eigenlijk niet binnen trekt, want dat is in dit geval correct, maar wat er uiteindelijk allemaal met de DOM gebeurt.
Dit kan je de browsers niet kwalijk nemen en zullen hier ook nooit je voor tegen beveiligen. Dat is aan de programmeurs van de site in kwestie, browsers doen al erg veel om slordigheidjes van die programmeurs aan te pakken.

[Reactie gewijzigd door jozuf op 12 januari 2015 16:49]

Wederom zeer slordig van de banken! Op Nu.nl: Volgens Martin Knobloch van de Open Web Application Security Project is dit type fout een veelgemaakte. "Dat komt met name doordat het probleem niet goed bekend is in alle voorkomende vormen", zegt hij. "Helaas richt men zich bij het voorkomen alleen op de meest bekende vormen ervan."
correctie: "zeer slordig van de tct-afdeling" Of de persoon in kwestie. Het komt maar al te vaak voor dat de ICT-man het afraffelt, en wel 5000¤ in de maand verdiend met zijn onkunde en of blufpokeralwetendheid.
Het zijn er dan wel een heleboel. Ik neem aan dat dezelfde man niet werkt voor alle genoemde getroffen partijen ;)
Hm interessante vraag!

Ik neem het niet zomaar 'aan' dat dat 'niet' zo is, het kan natuurlijk zo zijn dat ze de zelfde 'school' hebben, of er is idd 1 bedrijf die het overgrote deel van de ict bij banken faciliteert . (er zijn voorbeelden van nog stommer(e) acties dan deze die ik nu noem)

[Reactie gewijzigd door mell33 op 12 januari 2015 16:58]

Ik vind het eerder slordig van de banken. Zij hebben zelf ict personeel in dienst. Je mag van de banken verwachten dat ze de verantwoordelijkheid nemen om hun personeel goed trainen op het gebied van security. En stel dat een externe partij deze steek heeft laten vallen, dan nog is de bank verantwoordelijk. Het lijkt mij logisch dat je dit soort software tot in detail moet testen.
Wederom zeer slordig van de banken!
Het blijft mensenwerk en mensen maken nu eenmaal fouten. Niet wenselijk, maar wel de realiteit.

Gelukkig is deze fout nu opgelost en kunnen we door naar het volgende probleem....
Dat het een veel voorkomende fout is (XSS staat inderdaad hoog in de OWASP top 10) wil niet zeggen dat het daarom een makkelijk te voorkomen fout is. Integendeel. Zelfs wanneer je rekening houdt met security tijdens de ontwikkeling en een pentest uit laat voeren kunnen dit soort fouten erin blijven zitten.

Dus als jij een goede suggestie hebt om dit soort problemen te voorkomen hoor ik het graag van je :)
Dit is niet zo slordig, fouten maken zijn menselijk er snel op springen en de ontdekker danken, dat is hoe het moet.
Het viel mij op dat je op de publieke terminals van de Rabobank kan je elke willekeurige website kan bezoeken. Ik durf die dingen niet te gebruiken, wie garandeert dat de virus-scanner op die computers up to date is?

De mevrouw achter de balie vertelde mij dat ze alles heel goed in de gaten hield, en dat als er iemand 'verdacht' lang bezig was dat ze polshoogte ging nemen. Weinig besef van security.
Ik moest onwillekeurig toch even gniffelen bij de bedrijfsnaam; ik dacht die levert normaal aan xhamster ofzo.

Enfin, goed werk en op een heel nette manier opgelost :)
Het toont wel weer aan dat je goed moet oppassen met banken. De laatste tijd ontstaat er toch weer het idee dat banken de veiligheid op orde hebben omdat ze iedereen aan het waarschuwen zijn over zaken als phising, maar zelf hebben ze de zaken ook lang niet altijd op orde; en het zijn altijd de basis dingetjes (zoals een XSS) waar ze niet zo goed op letten... Beginnersfout, eigenlijk. De kleine en basale fouten zijn juist degene die mogelijk de zwaarste impact hebben.
Ook in de apps kunnen nog wel eens beveiligingsproblemen zitten.

Met andere woorden: blijf altijd op je hoede, en vertrouw ook de sites van de banken gewoon niet.
Wel zijn er plugins beschikbaar om je wat extra veiligheid te geven... Maarja, dan moet je de devs daarvan weer vertrouwen. ;) You're never safe! :P
Van Dongen heeft een proof of concept gemaakt waarbij de html-elementen op de bankensites beginnen te schudden. "Ik heb expres geen eigen formulieren op de bankensites gezet", aldus Van Dongen. Inmiddels hebben de banken het beveiligingsprobleem opgelost.
En dan een Harlem shake video maken, als dit dumpert was, had jij een +1 van mij gekregen. Het is super gaaf dat je op een leuke en grappige manier dit soort, toch wel vrij serieuze, problemen aan de kaak stelt.

Maar ik vraag me toch altijd iets af, kreeg Van Dongen hier eigenlijk iets voor terug?

[Reactie gewijzigd door Frozen op 12 januari 2015 16:21]

Hij krijgt er zeker wat voor terug, naamsbekendheid, mogelijke klanten, 15 minutes of internet fame...
Altijd dat gedoe dat een beloning een soort verplichting is teegnwoordig...
Nou kijk, hij had het ook kunnen verkopen op de zwarte markt voor flink wat centen. Ik bedoel maar, als jij iets kan verkopen voor 5000 en de ander geeft je helemaal niets dan tja...

Als ik over een maand een artikel lees denk ik namelijk niet van "Van Dongen", ahhhh dat was die toen bij die banken. :S
Nee maar de bedrijven die dit nu lezen denken wel aan DongIT welke ze wel eens in het nieuws voorbij hebben zien komen ipv 'AnoniemeBeveiliging B.V.' welke niemand kent ;)
Overigens vraag ik me af wat de zwarte markt ermee heeft te maken, ik kan werken en een eerlijk loon verdienen, of drugs amerika in smokkelen en een gigantische bak geld ontvangen, toch lijkt die tweede een wat, slechte, keuze ;)
Een beetje beveiligingsexpert kan prima anoniem een kwetsbaarheid bij banken verkopen voor een bovenmodaal bruto maand salaris. Dat is het punt niet.

Het punt is dat banken dit eigenlijk zelf hadden moeten checken!
Hij doet iets ongevraagds. Een geldelijke beloning is dan ook niet op z'n plaats. Geen strafvervolging en een positief verhaal in de pers is al heel wat.
media aandacht voor zijn bedrijfje ;)
"De xss-kwetsbaarheden bevonden zich in de voorpagina's van de bankensites."

Schandalig.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 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