image

Kaspersky verslikt zich in Rabobank-malware

vrijdag 21 januari 2011, 13:48 door Redactie, 23 reacties

Een nieuwe versie van Carberp, een Trojaans paard dat ook Nederlandse bankklanten aanvalt, maakt vooral veel slachtoffers onder gebruikers van Kaspersky Anti-virus. Volgens Seculert Research Lab ontwikkelt Carberp zich in hoog tempo. Zo versleutelt de malware alle gestolen informatie met het RC4-algoritme. De RC4-sleutel wordt willekeurig gegenereerd en is onderdeel van de HTTP request. "Dit is de eerste keer dat we zulk gedrag tegenkomen", aldus de beveiliger. Andere banking Trojans, zoals Zeus, zouden slechts één RC4-sleutel gebruiken die in de malware zelf zit ingebed.

Daarnaast noemt de malware zich voor het eerst zelf ook Carberp. Een naam die in eerste instantie door de beveiligingsindustrie was gegeven en door de malwaremakers is overgenomen. Verder verstuurt het Trojaanse paard informatie over de aanwezige virusscanner. De meeste slachtoffers gebruiken Kaspersky Anti-virus. "Dit komt waarschijnlijk omdat het botnet voornamelijk mensen uit Rusland aanvalt."

Seculert verwacht aan de hand van het "succes" van Carberp, dat andere malware zal volgen. Het gaat dan met name om de communicatie met de Command & Control server de over het slachtoffer gestolen informatie. "Het is tijd dat de beveiligingsindustrie deze nieuwe malware evolutie aanpakt en letterlijk 'out of the box' gaat denken over malware detectie en preventie." De eerste versie van Carberp viel drie Nederlandse banken aan, waaronder de Rabobank.

Reacties (23)
21-01-2011, 14:04 door Syzygy
Kaspersky verslikt zich in Rabobank-malware

Mooie kop, Rabobank maakt dus ook al Malware, ja met bankieren kunnen ze het niet meer verdienen zeker.

Redactie, toe nou .
21-01-2011, 14:13 door Anoniem
De piechart is een beetje misleidend, het mist namelijk het aantal bots waarbij de virusscanner niet herkend werd of er geen geinstalleerd werd (dit was het grootste gedeelte).
21-01-2011, 14:31 door Eerde
De eerste versie van Carberp viel drie Nederlandse banken aan, waaronder de Rabobank.
Waarom enkel de Rabo noemen en niet alle drie, bij de Rabo zal de malware n.l. weinig succes hebben...
21-01-2011, 14:48 door Syzygy
Door Eerde:
De eerste versie van Carberp viel drie Nederlandse banken aan, waaronder de Rabobank.
Waarom enkel de Rabo noemen en niet alle drie, bij de Rabo zal de malware n.l. weinig succes hebben...

Het is ook om inlog gegevens bij klanten weg te kapen.

heeft volledige controle over al het verkeer van en naar de browser, waaronder HTTPS met EV-SSL certificaat. De gegevens die de Trojan steelt, worden in real-time naar de criminelen doorgestuurd, die hier vervolgens online bankrekeningen mee leegroven.
21-01-2011, 15:36 door Eerde
Leg het mij dan even uit Syzygy ...
Bij de Rabo krijg ik het totaalbedrag moet de 's' code genereren.
Dan kan het bedrag niet meer veranderen, ook zit dat in de 'challence' verwerkt.
Dus ik zie niet hoe het kan.
Daarbij zijn alle codes zijn éénmalig en met tijdslot.
21-01-2011, 15:51 door 2tirds
@eerde: Bij IT is de grondslag nog steeds binair... voeg wat reeksen toe en verander daarmee bestaande reeksen en je hebt totaal wat anders dan wat je in gebruik dacht te hebben. Zo ook bij de malware ontwikkeling die gewoon meer en meer volwassen wordt

Voorbeeld. (Eerlijk: ben NIET bekend met rabobank security technieken)
1. 's' code is gegenereerd waarschijnlijk met een draadloos op baterijen functioneren algoritme reken apparaat?
2. hoe staat dit in verbinding met je challenge? *GAPEND GAT, zeker weten mits ik het dan ongeveer goed heb met mijn aannames op dit vlak nu.

1. een code die niet eenmalig is duidt op poepluier hashing

1. tijdslot? hoe dan precies? *GAPEND GAT, ook weer bijna zeker weten ;)

n.b. noem mij gek; ik betaal NIET digitaal dan slechts een speciale rekening waar ik vooraf telefonisch via mijn contact persoon naartoe overmaak. Op alle anderen zijn mijn voorwaarden dat ik NIET wil dat het zelfs MOGELIJK is.
21-01-2011, 15:58 door Eerde
@2turds
De codes bij de Rabo random reader zijn éénmalig.
Het tijdslot zit in de 'response' je kan dus niet vantevoren codes maken voor als je op vakantie gaat., verder zijn ze in sequence.
Je hebt mij nog niet overtuigd van de onveiligheid.
Voor paranoia* piepeltjes raad ik een live-CD aan voor internetbankieren.

* gezien je laatste n.b. opmerking.
PS welke bank heb jij ?
21-01-2011, 16:12 door 2tirds
@Eerde
- Codes bij random reader die NIET eenmalig zijn, zijn per definitie bijzondere bullshit. Met md5 hashing kun je zoiets al maken, meeste hashing methodes van banken die ik wel mee te maken heb gehad zijn ronduit onvolwassen implementaties te noemen (het begint te beteren, en ja natuurlijk is dat ook onvolwassen ... ook een bank moet zich mee ontwikkelen met de tijd, ze proberen het in ieder geval steeds beter vindt ik)

- Zelfs als het tijdslot in de response zit MOET er verband zitten tussen die tijd (of andere gerelateerde factoren) bij jou. Anders is het single-shake security; per definitie te kraken.

- Blijf zeggen dat jij mij ook niet zo snel technisch goed kan uitleggen hoe de beveiliging van rabo in elkaar steekt, daarvoor zijn er gewoonweg too much factors into play. Met mijn rabo bank kennis wordt het dus per definitie moeilijk je te overtuigen. Dit is slechts globale indruk zeg maar.

- Die live CD is helemaal super suggestie van je. Zorg bovendien dat je een mem sync hebt, ALLE services dicht. Ik heb een implementatie van openbsd waar werkelijk alleen XCFE werkt en alles in de jail plus services dicht en een memory sync loop. Niet zo heel moeilijk te maken en sterke beveiliging.

Ik gebruik voor persoonlijk bankieren de ING en voor internet betalen een internet rekening van paypal in combinatie met een credit card en afspraken /voorwaarden met ing/paypal.

[oh en hacktivisme edit]
Daarnaast heb ik contact met paypal opgenomen en ze gevraagt of ik op een vruchtbare samenwerking kan vertrouwen in verband met discutabele politieke opstelling van een financiele instelling. Of zij dan ook kunnen helpen bij de bevordering van garantie van bijvoorbeeld EPD's en wanneer zij mij hier niet juridische verantwoord van kunnen overtuigen, ik met terugwerkende kracht via wet openbaarheid bestuur en tig aanklachten van mijn advocaat wil dat zij mij juridisch verantwoord overtuigen over de discretie met betrekking tot onze samenwerking de laatste 5 jaren (zo lang betaal ik dus precies online, wanneer niet anders kan)[/edit]
21-01-2011, 16:19 door [Account Verwijderd]
[Verwijderd]
21-01-2011, 16:25 door 2tirds
Omdat als je er alle AV oplossingen in wil verwerken dan ben je over een week met verouderd nieuws bezig en dat is bij dergelijke dingen toch wel vaak een dure vorm van te lang wachten met belangrijk nieuws om de volledigheid te dienen (die toch nooit volledig te behalen is lol).
21-01-2011, 16:35 door RichieB
Door 2tirds: meeste hashing methodes van banken die ik wel mee te maken heb gehad zijn ronduit onvolwassen implementaties te noemen
Geef eens wat meer details? Welke banken? Wat was er precies mis met de hashing methodes?

- Zelfs als het tijdslot in de response zit MOET er verband zitten tussen die tijd (of andere gerelateerde factoren) bij jou.
De Rabobank calculator kan best een interne tijdklok hebben (ik weet niet zeker of dat ook echt zo is). Daarmee kan tijd best een factor zijn in het hashing algoritme.

Anders is het single-shake security; per definitie te kraken.
Echt waar? Een SHA-256 over het bedrag en de rekeningnummers van de transactie (plus wat zout uit je calculator) is te kraken? Leg uit aub.
21-01-2011, 16:52 door 2tirds
Door RichieB:
Door 2tirds: meeste hashing methodes van banken die ik wel mee te maken heb gehad zijn ronduit onvolwassen implementaties te noemen
Geef eens wat meer details? Welke banken? Wat was er precies mis met de hashing methodes?

http://mareichelt.de/pub/notmine/linuxbsd-comparison.html

vanwege clausules kan ik geen exacte voorbeelden geven. kan je wel vertellen dat hashing block cipher implementatie's slechts het afgelopen jaar meer professioneel worden. SSL communicatie is jarenlang een wanabe-security-gevoel-creatie geweest en duidelijk onvoldoende stevig geimplementeerd om de strijd met de cybercrimineel aan te gaan; getuige de huidige aanvallen. En dan met name de eenvoud ten opzichte van de bekende mogelijkheden.

- Zelfs als het tijdslot in de response zit MOET er verband zitten tussen die tijd (of andere gerelateerde factoren) bij jou.
De Rabobank calculator kan best een interne tijdklok hebben (ik weet niet zeker of dat ook echt zo is). Daarmee kan tijd best een factor zijn in het hashing algoritme.

Anders is het single-shake security; per definitie te kraken.
Echt waar? Een SHA-256 over het bedrag en de rekeningnummers van de transactie (plus wat zout uit je calculator) is te kraken? Leg uit aub.
[/quote]
Door middle-man attacks, SSL-block verbanden (zie MS-SQL OLAP functionaliteit o.a. of cloudcomputing voor het razendsnel vinden van verbanden) en dan hebben we het nog niet over client side phishing gehad (ook voor de betere block comparisments) en nou ja.. single-shake (dus alleen via een redirect via de client terug te pasen hashes) zijn gewoon erg gevoelig. Je zou er op zijn minst een client side hashing overheen moeten gooien inderdaad vanaf SHA-256 om het wat meer veilig te krijgen. En hoe valideer je die dan weer server-side? Lol het blijven shoot the messenger manieren ;)

p.s. hoe is dit niet te kraken dan? Wedden dat hier binnen het jaar om de voornoemde kraakreden weer alternatieven op zijn ontwikkeld? Gelukkig ook.. voor dat bewustzijn ;)
21-01-2011, 17:12 door RichieB
Door 2tirds: Door middle-man attacks, SSL-block verbanden
Dus de hackers kunnen via man-in-the-middle SSL kraken? Dat is groot nieuws! Het enige wat bekend is, is dat je SSL via man-in-the-middle uit kan schakelen (sslstrip) of 1 enkel request kan inserten (CVE-2009-3555, reeds gefixed).

en dan hebben we het nog niet over client side phishing gehad (ook voor de betere block comparisments)
Phishing lokt gebruikers naar een valse website: gewoon goed opletten dus. Malware is gevaarlijker, als een aanvaller controle heeft over de client is het al snel game-over. De aanvaller kan dan de hele Rabobank site spoofen, en de rekeningnummers veranderen. Het bedrag veranderen kan niet ongemerkt (moet je invoeren in je calculator), en bij grote bedragen kan hij het rekeningnummer niet veranderen (moet ook worden ingevoerd in de calculator). Dus het risico dat hier grootschalige schade door ontstaat is vrij klein, mits de gebruikers goed op blijven letten natuurlijk.

p.s. hoe is dit niet te kraken dan? Wedden dat hier binnen het jaar om de voornoemde kraakreden weer alternatieven op zijn ontwikkeld?
Het phishing probleem heeft geen technische oplossing. Het probleem van een gecompromitteerde gebruikers-PC is heel erg lastig op te lossen, maar de Rabobank doet nu al een goede poging om het risico te verminderen. Wat stel jij voor?

PS: ik werk niet voor een bank ;-)
21-01-2011, 17:14 door Eerde
@2turds
Grappig dat je als expert niet je html code correct kan krijgen, maar dat terzijde. (je mist b.v. een "/")

1. Hoe vaak moet ik nog herhalen dat de codes van de Rabobank randomreader éénmalig zijn ? Steeds herhalen dat NIET éénmalige codes gevaarlijk zijn is onzinnig.

2. PayPal (aka Poen-Pleitos) wordt je ondergang ! Let op mijn woorden, 'read my lips'.
21-01-2011, 17:34 door 2tirds
Door Eerde: @2turds
Grappig dat je als expert niet je html code correct kan krijgen, maar dat terzijde. (je mist b.v. een "/")

1. Hoe vaak moet ik nog herhalen dat de codes van de Rabobank randomreader éénmalig zijn ? Steeds herhalen dat NIET éénmalige codes gevaarlijk zijn is onzinnig.

2. PayPal (aka Poen-Pleitos) wordt je ondergang ! Let op mijn woorden, 'read my lips'.

Allereerst ben ik hier voornamelijk NIET bezig met html code die toch bijna altijd veranderd en waar ik gewoon niet zoveel tijd voor heb. Net zomin als ik niet 'certified secure' ben om grote probleempadstellingen kapot te denken, het gewoon lkkr toch wel doe ;-) Spelenderwijs probeer ik het wel goed te doen hoor, al was het maar om die berichten van mij minder kritiek te laten ontvangen op ongelooflijk slecht en onduidelijke stijl; nogmaals sorry daarvoor. Wat ik wel vindt dat jij dat in vergelijk trekt met het woord expert (wat ik nooit over mezelf gezegt heb) is totaal niet met elkaar te vergelijken.

1. Nogmaals, en hoe vaak moet ik dat nog zeggen (sorry geintje lol blijven lachen), mochten die codes van randomreader ofzo NIET eenmalig zijn, zou het per definitie de functionaliteit verliezen. Steeds herhalen dat ze eenmalig zijn is hetzelfde als steeds zeggen dat brood met meel gebakken wordt?

2. Dat zou wel eens kunnen maar ook zij maken een ontwikkeling door en ben daar liever een constructieve rol in. En ik let heel erg goed op je woorden want de tedens die jij IN IEDER GEVAL ZIET is er ZEER ZEKER. Bedankt voor het, naar mijn bezopen en ongrammaticale mening ongetwijfeld, goed kijken! ;)
21-01-2011, 17:42 door 2tirds
Door RichieB:
Door 2tirds: Door middle-man attacks, SSL-block verbanden
Dus de hackers kunnen via man-in-the-middle SSL kraken? Dat is groot nieuws! Het enige wat bekend is, is dat je SSL via man-in-the-middle uit kan schakelen (sslstrip) of 1 enkel request kan inserten (CVE-2009-3555, reeds gefixed).

### het ENIGE wat bekend is? man o man wat loop jij achter! ;-)

en dan hebben we het nog niet over client side phishing gehad (ook voor de betere block comparisments)
Phishing lokt gebruikers naar een valse website: gewoon goed opletten dus. Malware is gevaarlijker, als een aanvaller controle heeft over de client is het al snel game-over. De aanvaller kan dan de hele Rabobank site spoofen, en de rekeningnummers veranderen. Het bedrag veranderen kan niet ongemerkt (moet je invoeren in je calculator), en bij grote bedragen kan hij het rekeningnummer niet veranderen (moet ook worden ingevoerd in de calculator). Dus het risico dat hier grootschalige schade door ontstaat is vrij klein, mits de gebruikers goed op blijven letten natuurlijk.

p.s. hoe is dit niet te kraken dan? Wedden dat hier binnen het jaar om de voornoemde kraakreden weer alternatieven op zijn ontwikkeld?
Het phishing probleem heeft geen technische oplossing. Het probleem van een gecompromitteerde gebruikers-PC is heel erg lastig op te lossen, maar de Rabobank doet nu al een goede poging om het risico te verminderen. Wat stel jij voor?

### dat ze zo doorgaan, want zoals ik stel komt er dikke verbetering in, meer en meer dus wat dat betreft ben ik in ieder geval onvoldoende met de rabo security bekend om te stellen dat ze onvoldoende met hun markt meegaan. De rootkits en hun simpelheid ten opzichte van wat allang bekend is aan methodes bewijzen anders toch echt wel dat het niettemin op dit moment ONVOLDOENDE is.

PS: ik werk niet voor een bank ;-)

Nee ik ook niet zo vaak en iig niet vast, gelukkig :D

nog ff wat snelle ssl info:
http://www.google.nl/url?sa=t&source=web&cd=1&ved=0CBkQFjAA&url=http%3A%2F%2Fwww.sans.org%2Freading_room%2Fwhitepapers%2Fthreats%2Fssl-man-in-the-middle-attacks_480&ei=Qbg5TdiYOsacOtvbubcL&usg=AFQjCNGs4-hNjWJwaTkJXYB76Ssp_zaC6g PDF alert
http://www.sslshopper.com/article-moxie-marlinspikes-new-ssl-attack-is-nothing-new.html als voorbeeld dat de ontwikkeling van SSL gewoon in volle gang is en er nog heel veel aan wordt gewerkt (kijk naar al die hacker expo's waar het een levensgroot onderwerp is, moet je nog meer bewijs?); moet wel zeggen dat SSL een van de technologieen is waar beveiliging HEEL SNEL gaat. OS'en, browser, AV branche kan hier een voorbeeld aan nemen.

http://www.networkworld.com/community/node/43983
http://www.schneier.com/blog/archives/2010/09/uae_man-in-the-.html

kijk maar der wordt genoeg over nagedacht ;)
[edit]
http://www.eff.org/deeplinks/2010/12/2010-trend-watch-attacks-cryptography

en bedenk je goed dat alleen al omdat SSL dusdanig meer volwassen is, het specialisten werk is van mensen die echt geen zerodays zomaar gaan verspreiden, veel wordt dus in stilte opgelost. maar alsjeblieft zeg nou niet dat die bovenstaande de enige methodes zijn.. dat is SO NIET waar...
[/edit][edit2]
http://redmondmag.com/articles/2010/02/10/microsoft-reports-bug-in-web-security-protocols.aspx

http://www.scmagazineus.com/black-hat-2010-even-with-ssltls-browsers-still-are-susceptible-to-attack/article/175911/

hier ^ wordt het nogmaals bevestigd: "You'd have to be a very determined attacker," Hansen said. "And determined attackers have a lot of other avenues for attack."

omdat het dus door de snelle ontwikkeling heel moeilijk is, wordt hier door aanvallers niet (meer) echt op gefocussed. Maar zeg nou niet dat er geen flaws die misbruikt kunnen worden zonder controle over werkstation gevonden worden, gewoon NIET waar.

Nog bedankt overigens.. had ssl al een tijdje laten versloffen ben nu bezig wat bugtracks na te wandelen, ouderwets belangrijk onderwerp namelijk.[/edit2]
21-01-2011, 19:07 door RichieB
@2tirds: sorry hoor, maar als die links hebben het alleen maar over sslstrip en CVE-2009-3555. Wat is er concreet vandaag de dag nog meer mogelijk om SSL te kraken? Je blijft steeds zo vaag.
21-01-2011, 20:20 door 2tirds
@RichieB

1. Nou je hoeft nergens sorry voor te zeggen, je hebt het volste recht om die ui te pellen.
2. Zo in de snelheid is die laatste publicatie van redmondmag een andere aanval dan de aanvallen die jij beschrijft.
3. Zoals alle beveiliging komt SSL niet op zichzelf, zoals met alle beveiliging is het zo sterk als de zwakste schakel. Zelfs bij veel banken kom je erop uit dat SSL dus net zo sterk is als de zwakste clients. Gelukkig sinds de laatste jaren wordt dus de versleuteling meer en meer dynamisch door keyrolling et al. [edit]in SSL v3 / TLS zelfs al ingebakken keyrolling lijkt het? ben nog ff bezig[/edit]

4. Nog een aantal websites die duiden dat er genoeg mogelijk is met SSL:
http://rdist.root.org/2008/01/07/ssl-pkcs-padding-attack/
http://msmvps.com/blogs/alunj/archive/2009/11/18/1740656.aspx
http://www.linuxtoday.com/it_management/2010013100235SCNT (deze zegt het al: several attack methods discovered etc)

5. en zoals al aangegeven.. inhoudelijk technisch beperk ik me tot bekende problemen het laatste jaar (je kan nu eenmaal niet alles inhoudelijk blijven volgen, daarbij is SSL een dusdanig in beweging zijnde hoogwaardige up-to-date techniek dat ik me beter kan beperken en minder zwak maken van zwakste schakels waardoor dus SSL meer en meer werkelijk veilig wordt); dus mocht jij je aanbevelen voor het leveren van een zeroday bewijs, ga je gang dan houdt ik er rekening mee dat dat een jaar duurt met dergelijke complexe software.

6. Bovenstaande plus de laatst bekende aanvallen (die niet geheel in publiek zijn uitgelicht) zoals de google attack moeten genoeg aantonen voor je om te weten dat het ECHT ONZIN is dat die twee aanvallen de enige zijn. Dat durf ik gewoon keihard te stellen en daar heb ik mijn feiten al bij alleen al met contact met collega's en nou ja, jij moet er gewoon je eigen mening over vormen. Het is echt onzin nogmaals om te stellen dat dat de enige werkelijke aanvalsmethodes tot SSL zijn. Nogmaals: keiharde onzin. Ga het aan gonrijp van xs4all ofzo vragen als je mij niet geloofd.

7. je hebt me wel een beetje wakker geschud op mijn eigen ssl kennisniveau en ik ben daar eigenlijk door jou nu weer mee bezig. ongetwijfeld kom ik daar wat tegen en mocht je dat ook willen weten dan mail mij even drietweede@whazdat.nl; kan je eigenlijk wel garanderen dat ik binnen een paar weken een andere keiharde bugregistratie voor je hebt, misschien zelfs toch een exploitatie zelfs!!

8. het lijkt er wel op dat de door u voornoemde twee, de enige twee ECHT door userland geexploiteerde SSL-specifieke attacks zijn, moet ik je nageven. Dat betekend dus exclusief de chinese overheid wat geen userland is die over meerdere technieken beschikt mbt SSL wat nu pas langzaam bekend begint te worden; en meer van dit soort dingen (nogmaals ONZIN te stellen dat voornoemde twee het enige mogelijke is, echt tig andere bugs gevonden ZEKER WETEN die werkelijk exploitatie mogelijkheden bieden. En dan heeft u maar een andere mening dan die van mij. Zal best ;-)
21-01-2011, 22:50 door RichieB
@2tirds: bedankt voor het uitgebreide antwoord. Dat stelt me weer gerust. :-) Ik heb nooit gezegd dat sslstrip en CVE-2009-3555 de enige mogelijke werkende aanvallen op SSL zijn. Het zijn alleen momenteel de enige werkende die bekend zijn. Mochten er meer bekend worden, dan is dat groot nieuws en lezen we dat zeker ook hier op security.nl. Tot die tijd is SSL best veilig zo lang je als gebruiker maar:

1) de juiste site gebruikt (dus zelf intypen)
2) zeker weet dat SSL echt aanstaat (zie sslstrip!)
3) SSL waarschuwingen goed leest, en de sessie afbreekt als er iets niet klopt (certificaat waarschuwing, etc))
4) geen malware op je PC toestaat (vooral een probleem bij Windows gebruikers)
21-01-2011, 23:44 door Anoniem
RichieB: ja precies en dat is ook het probleem meteen.. die ssl wordt juist dubbel ontkracht zo.

En die malware, of beter: het probleem gebruikers, moet echt wat aan gebeuren zij zijn het grootste voordeel van de cyberdief.
22-01-2011, 01:29 door Anoniem
2thirds, dank je wel voor je reacties!
Het doet me echt deugd om die te lezen, zeer open, verfrissend en (naar mijn bescheiden menig) zeer helder en een ik denk voor velen een eye-opener.. De reacties van Syzygy, Eerde en PeterV kennen we ondertussen wel, jouw uitgebreide en goed onderbouwde antwoorden zijn toch een compliment waard.
Net als bij jou heeft het de SSL-vlam weer doen ontwaken bij mij... Dank voor de links, dat wordt weer een tijdje puzzelen!
22-01-2011, 21:04 door Anoniem
ik lees in het hele artikel niet wat er met kaspersky gebeurd of wat er dan fout gaat.

Broodje aapverhaal als je het mij vraagt.
25-01-2011, 15:15 door Anoniem
Beste mensen,

1. Er is helemaal niet zo veel mis met de security van telebankieren.
2. De zwakke schakel is je operating systeem en browser. En dat zie ik voorlopig niet beter worden.
3. De zwakste schakel ben je zelf. De meeste mensen in mijn omgeving gaan gewoon te onzorgvuldig om met security op de personal computer.

@ttertje
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.