image

GitHub-gebruikers doelwit van phishingaanval die ook 2FA-codes steelt

donderdag 22 september 2022, 16:46 door Redactie, 10 reacties

Gebruikers van het populaire ontwikkelaarsplatform GitHub zijn het doelwit van een nieuwe phishingaanval waarbij ook wordt geprobeerd om codes voor tweefactorauthenticatie (2FA) te stelen. Daarvoor waarschuwen GitHub en CircleCI. De laatstgenoemde is een populair devops-platform gebruikt voor softwareontwikkeling dat met GitHub is te integreren.

Aanvallers versturen berichten die van CircleCI afkomstig lijken en stellen dat de ontvanger op GitHub moet inloggen om de nieuwe algemene voorwaarden te accepteren. De link in het bericht wijst echter naar een phishingpagina. Deze pagina probeert niet alleen de inloggegevens van GitHub-gebruikers te bemachtigen, maar in het geval ze 2FA hebben ingeschakeld ook hun 2FA-codes in real-time.

Wanneer de aanvaller toegang tot het GitHub-account heeft verkregen maakt de aanvaller GitHub personal access tokens (PATs) aan, die als alternatief voor wachtwoorden zijn te gebruiken, worden OAuth-applicaties geautoriseerd en SSH-keys aan het account toegevoegd om toegang te behouden, mocht de gebruiker zijn wachtwoord wijzigen. Daarnaast download de aanvaller private repositories van de gecompromitteerde gebruiker.

GitHub heeft inmiddels alle gedupeerde gebruikers en organisaties die het heeft kunnen identificeren gewaarschuwd en hun wachtwoorden gereset. Daarnaast zijn accounts van de aanvaller uitgeschakeld.

Image

Reacties (10)
23-09-2022, 01:23 door Erik van Straten
Daarvoor waarschuwen GitHub [1] en CircleCI [2].
[1] https://github.blog/2022-09-21-security-alert-new-phishing-campaign-targets-github-users/
[2] https://discuss.circleci.com/t/circleci-security-alert-warning-phishing-attempt-for-login-credentials/45408

echt: circleci.com
fake: circle-ci.com

De aanvallers gebruikten (vanzelfsprekend, snel en geen geldspoor) Let's Encrypt certificaten voor hun nepsite (zie https://crt.sh/?q=circle-ci.com).

Naast domeinnaam-registrars en hostingboeren, vinden uitgevers van DV (Domain Validated speelgoed-) certificaten het namelijk niet hun taak om te controleren of "circle-ci.com" een phishingsite van "circleci.com" zou kunnen zijn. Mocht dat zo zijn dan is dat jouw probleem.

Omdat bijna niemand lijkt te (willen) inzien dat:
1) je niets aan encryptie hebt als je niet weet met welke partij je communiceert (d.w.z. met de bedoelde partij of juist met misleiders die zich voordoen als), en

2) authenticatie van de server al vele jaren het enige doel is van https servercertificaten, en

3) uitgevers van DV-certificaten niet controleren wie de eigenaar is van een domeinnaam, noch of die domeinnaam misleidend kan zijn,

gebruiken ook ook [1] en [2] speelgoedcertificaten van Let's Encrypt (naast de idioterie van domeinnamen zoals "github.blog" in plaats van "blog.github.com").

Dat een arme sloeber die een thuis-NAS aan internet wil hangen daar zo'n Let's Encrypt certificaat voor gebruikt begrijp ik, maar als ook "officiële" websites (zoals [1] en [2] maar ook ggd.nl en ggdghor.nl) dat doen, kan een bezoeker niet snel aan de hand van de certificaatuitgever zien dat het waarschijnlijk om een phishingsite gaat (laat staan dat je in zo'n certificaat meer identificerende informatie van een organisatie kunt vinden dan slechts de domeinnaam, die hier juist misleidend is).

Met andere woorden, omdat bijvoorbeeld
ggdghor.nl een Let's Encrypt certificaat gebruikt, is het risico op phishing met
ggd-ghor.nl onnodig groot (omdat phishers ook bij voorkeur Let's Encrypt certificaten gebruiken).

Terug naar circle-ci.com: de meeste vormen van 2FA/MFA, zoals SMS of TOTP (Time-based One Time Password via bijvoorbeeld Google Authenticator, Authy of Microsoft Authenticator) bieden geen enkele bescherming tegen dit soort "proxy"-aanvallen.

Kortom, tenzij je een FIDO2 hardware key in WebAuthn modus gebruikt (of een PassKey, of een "slimme" wachtwoordmanager en jij je niet laat verleiden tot handmatige invoer), die in jouw plaats domeinnamen onthoudt en je uitsluitend op sites met herkende domeinnamen laat inloggen, zit er niets anders op dan zelf te onthouden dat "circleci.com" exact zo gespeld moet zijn (zonder minnetje en met uitsluitend letters uit de ASCII karakterset) om te voorkómen dat je in dit soort phishing-aanvallen trapt.

En mocht je een mail krijgen dat je naar
ggd-ghor.nl moet voor een vette tegoedbon als je een prikafspraak maakt (of een boete als je dat niet doet), of om een binnenkort noodzakelijke QR-code aan te vragen (en je dat het beste snel kunt doen omdat het binnenkort storm loopt), zul je moeten weten dat er geen minnetje in die domeinnaam hoort te staan. Want voor zo'n nepsite heb je zelfs geen hardware key of passkey die voorkómt dat je bijvoorbeeld allerlei persoonsgegevens prijsgeeft aan criminelen en/of "inlogt" via een -eveneens valse- DigiD website (met een smoes dat de DigiD-app tijdelijk niet werkt).
23-09-2022, 09:17 door Anoniem
Blijkbaar is het dan toch te makkelijk om belangrijke dingen te doen, zoals het toevoegen van sleutels zonder daar nog eens een keer extra een wachtwoord voor te vragen.

Zelf gebruik ik FIDO2 sleutels voor zowel het inloggen op de site als voor mijn ssh sleutels.
23-09-2022, 09:46 door Anoniem
Door Erik van Straten:

Je doet nu net of let's encrypt fishing in de hand speelt. Het probleem dat let's encrypt oplost (dat veel websites niet beveilgd waren) weegt ruimschoots op tegen de eventuele nadelen. Dat hele systeem van uitgevers die je dan maar op hun blauwe ogen moet vertrouwen is natuurlijk ook echt hopeloos verouderd.

Je kunt veel beter mensen leren hoe fishing te herkennen en hoe het te voorkomen. Regel nummer één: klik nooit op een link om vervolgens in te loggen. Als je gaat inloggen, typ je altijd zelf de URL in.
23-09-2022, 10:19 door Erik van Straten
Door Anoniem: Zelf gebruik ik FIDO2 sleutels voor zowel het inloggen op de site als voor mijn ssh sleutels.
Een FIDO2 sleutel helpt alleen tegen dit soort aanvallen als die sleutel de domeinnaam checkt en weigert als die domeinnaam niet klopt.

Als die FIDO2 sleutel tevens de mogelijkheid heeft om, bijvoorbeeld met een knopje op dat ding, handmatig een 2FA-code in te vullen in een 2FA-veld of op andere wijze op te sturen - ongeacht de domeinnaam van de server -, en je zelf niet gezien hebt dat de domeinnaam niet klopt en toch zo'n code opstuurt, helpt zo'n hardware key geheel niet tegen dit soort "proxy" aanvallen - waarbij de aanvallers onmiddelijk als jou inloggen op de echte site.
23-09-2022, 11:30 door Erik van Straten
Door Anoniem:
Door Erik van Straten:

Je doet nu net of let's encrypt fishing in de hand speelt.
DV-certificaten waren al een probleem vóórdat Let's Encrypt begon, maar LE heeft het phishers enorm veel eenvoudiger gemaakt doordat hun certificaten gratis zijn (geen money trail) en een certificaat volledig geautomatiseerd en binnen seconden geïnstalleerd is. Ideaal voor phishers met wegwerpdomeinen dus.

Door Anoniem: Het probleem dat let's encrypt oplost (dat veel websites niet beveilgd waren) [...]
Het gaat niet om beveiliging van websites, maar om beveiligde verbindingen.

Omdat het versleutelen van een verbinding met een website van criminelen, zoals "circle-ci.com", totaal zinloos is (uit oogpunt van de bezoeker), is het noodzakelijk dat de bezoeker zeker weet dat diens webbrowser een verbinding heeft met een website van de bedoelde eigenaar, ongeacht de domeinnaam (die er sterk op kan lijken). DV-certificaten helpen websurfers hier geheel niet mee; integendeel, hen is geleerd dat een slotje voor een "veilige website" staat.

Door Anoniem: [...] weegt ruimschoots op tegen de eventuele nadelen.
Zo te zien heb je er geen idee van hoe ondermijnend dit soort aanvallen zijn voor het internet en digitalisering in het algemeen.

Door Anoniem: Dat hele systeem van uitgevers die je dan maar op hun blauwe ogen moet vertrouwen is natuurlijk ook echt hopeloos verouderd.
Ik zie niet wat dat met deze aanval te maken heeft: tenzij je er heel diep induikt en alle rootcertificaten die je niet vertrouwt verwijdert of blokkeert, ben je afhankelijk van dit systeem.

Door Anoniem: Je kunt veel beter mensen leren hoe fishing te herkennen en hoe het te voorkomen. Regel nummer één: klik nooit op een link om vervolgens in te loggen. Als je gaat inloggen, typ je altijd zelf de URL in.
Klinkt leuk maar heel vaak bevatten links in mails aanvullende informatie om, na inloggen, een speciale handeling uit te voeren (zo ook in dit geval). Doordat de meeste organisaties mails met links erin versturen, wordt mensen juist geleerd om te klikken op links in mails. Als je dat niet doet moet je op de kennelijke website op zoek naar die functionaliteit - en iedereen die dat wel eens gedaan heeft, weet hoe eenvoudig dat meestal niet is.

Interessant vind ik ook de boze reacties in [2] die ik eerder noemde: circleci zou DMARC onjuist hebben geconfigureerd (p=none). Dat is onhandig, maar of dat veel slachtoffers had voorkómen, betwijfel ik.

Want als je een mail-account bij Microsoft hebt en *@circleci.com als "safe sender" hebt aangemerkt, wordt DMARC genegeerd en komt de mail van een ander afzenderdomein, dat zich voordoet als circleco.com, gewoon in jouw inbox.

Daarnaast vraag ik mij af hoeveel van die slachtoffers het zou zijn opgevallen als de criminelen "circle-ci.com" als afzenderdomein hadden gebruikt (dat de aanvallers zelf van geldige SPF, DKIM en DMARC hadden kunnen voorzien).
23-09-2022, 13:39 door Anoniem
2FA is iets wat je kwijt kan raken plus iets wat je kan vergeten.

Gebruikers zouden altijd zelf de afweging moeten kunnen maken of ze dit willen. Zelf wil ik alleen 2FA voor mijn bank en verder niets. Vooral geen dingen waarbij ik toegang verlies tot al mijn data en documenten. Als het echt belangrijk is zet ik er wel een goed wachtwoord op en zorg ik dat ik die alleen invoer op vertrouwde apparatuur.
23-09-2022, 14:12 door Anoniem
Ik had Js uit staan dus mijn originele uitgebreide/onderbouwde reactie is waarschijnlijk verloren gegaan.

Korte samevatting:

Dit is geen technisch probleem. of tenminste, het is een ander technisch probleem.

De oplossing is on computergebruik zo moeilijk te maken dat je er zonder goede basis geen gebruik van kunt maken.

PEBKAC
23-09-2022, 22:14 door Anoniem
Door Erik van Straten: Omdat bijna niemand lijkt te (willen) inzien dat:
1) je niets aan encryptie hebt als je niet weet met welke partij je communiceert
Een van de redenen om desondanks HTTPS te prefereren boven HTTP is dat sommige internetproviders waren begonnen om advertenties te injecteren in pagina's die via HTTP werden geladen. Voor zover ik weet is dat niet in Nederland gebeurd, maar in het VK wel. Je hebt het dan over een soort MITM-aanval waarbij het er niet toe doet met welke server je eigenlijk verbinding maakt, het gaat erom dat er iets aangepast kan worden. Vanuit het perspectief van aanbieders van webpagina's die bewust geen advertenties bevatten is het zeer onwenselijk dat er internetproviders zijn die doodleuk advertienties aan de pagina's gaan toevoegen. Vanuit het perspectief van aanbieders van pagina's met advertenties trouwens ook. HTTPS blokkeert dat soort ongein.

En het maakt verschil voor elke netwerk node waar netwerkverkeer langs komt. HTTP staat echt wagenwijd open voor MITM-aanvallen. Zelfs zonder dat je weet wie eigenlijk die HTTPS-webserver bestiert voegt het al wat toe dat in ieder geval geregeld is dat je een foutmelding krijgt als er met het verkeer tussen jou en die server geknoeid is.

Voor zover ik het begrepen heb is dat de motivatie geweest voor Let's Encrypt, of een belangrijk deel van de motivatie.

Ja, het zou geweldig zijn als de verificatie van alle certificaataanvragers zo sterk zou zijn dat het slotje in de adresbalk zekerheid zou geven dat je met een bona fide partij in verbinding staat. Maar die zekerheid had je voor Let's Encrypt ook al niet, CA's hadden allang de verwachtingen op dat vlak beschaamd. In de praktijk lijkt dat een gepasseerd station te zijn.
Gisteren, 12:03 door Anoniem
Door Anoniem:
Door Erik van Straten: Omdat bijna niemand lijkt te (willen) inzien dat:
1) je niets aan encryptie hebt als je niet weet met welke partij je communiceert

Ja, het zou geweldig zijn als de verificatie van alle certificaataanvragers zo sterk zou zijn dat het slotje in de adresbalk zekerheid zou geven dat je met een bona fide partij in verbinding staat. Maar die zekerheid had je voor Let's Encrypt ook al niet, CA's hadden allang de verwachtingen op dat vlak beschaamd. In de praktijk lijkt dat een gepasseerd station te zijn.

Juist, en dan nog: Ten eerste zouden er genoeg zijn waar dit zelfs niet genoeg voor zou zijn. Ten tweede zouden de aanvallers andere manieren vinden om menselijke zwakheden te exploiteren.

Men zou misschien iets gebaseerd op virusscanners of spamfilters kunnen implementeren (maar dan in reverse). Bijvoorbeeld een laagje tussen de gebruiker en de programma's. Iets met plugins and signatures. Een gebruiker wil een programma starten (bijv. browser) maar in werkelijkheid start de gebruiker een browser specifieke plugin wrapper die competentie test (gebaseerd op signatures voor een plugin die je kunt bijwerken) alvorens al dan niet tot uitvoeren van het doel programma over te gaan. Niet scherp genoeg? -> Access denied.

Die plugins en signatures kunnen dan op maat gemaakt worden voor betreffende programma's. Je kunt ze bijwerken zodat dingen met de tijd mee gaan. (subscription model $$$$$$)
Gisteren, 14:19 door Erik van Straten
Door Anoniem:
Door Erik van Straten: Omdat bijna niemand lijkt te (willen) inzien dat:
1) je niets aan encryptie hebt als je niet weet met welke partij je communiceert
Een van de redenen om desondanks HTTPS te prefereren boven HTTP is dat sommige internetproviders waren begonnen om advertenties te injecteren in pagina's die via HTTP werden geladen.
[...]
Voor zover ik het begrepen heb is dat de motivatie geweest voor Let's Encrypt, of een belangrijk deel van de motivatie.

Veiligheidsdiensten
Als ik mij niet heel erg vergis werd het belangrijkste argument aangedragen door Edward Snowden, namelijk dat internetverkeer massaal werd afgeluisterd door veiligheidsdiensten. Vandaar dat de EFF zo'n voorstander was en is van https.

Omdat veiligheidsdiensten zelfs versleuteld (https) verkeer massaal zouden opslaan wordt de symmetrische sessiesleutel allang niet meer door de webbrowser gegenereerd en versleuteld met de public key uit het servercertificaat (waarna alleen degene die over de bijpassende private key beschikt, normaal gesproken de webserver, die sessiesleutel kan decrypten), maar wordt het Diffie-Hellman (DH) algoritme gebruikt voor de symmetrische "key agreement".

Sterker, in moderne https-certificaten staat dat de public key daarin uitsluitend gebruikt mag worden voor het checken van digitale handtekeningen. Zo'n "signing" certificaat heeft dan ook geen enkele relatie meer met het versleutelen van https verbindingen; het enige doel is het bewijzen van de identiteit van de server (doordat de server de hash van een aantal verbindingsparameters versleutelt, waardoor iedereen die het certificaat met public key heeft kan checken of aan de clientzijde gebruik gemaakt wordt van exact dezelfde verbindingsparameters, en er dus geen aanvaller tussen zit).

Doel van DH en "signing certificates": mocht een geheime dienst ooit de private key van de server opeisen, dan kan daarmee, dankzij DH, niet alle eerder door die veiligheidsdienst opgeslagen versleutelde communicatie worden ontsleuteld (daarom wordt het gebruik van DH en signing certs "forward secrecy" genoemd; pas vanaf het moment dat een derde de private key van een webserver in bezit heeft, kan die partij zich voordoen als die webserver).

Om dezelfde reden wordt DoH aangemoedigd en ondersteunt TLSv1.3 versleutelde SNI.

Adverteerders
Ongetwijfeld werden de EFF en andere privacy-organisaties hierbij enorm gesteund door partijen die leven van advertentie-inkomsten, zoals Google, Facebook en dergelijke. Niet omdat die adverteerders zich zorgen maken over de privacy van burgers, of dat burgers teveel advertenties zouden zien, maar omdat (zoals je schreef) hun advertenties in webpagina's werden vervangen door die van anderen, maar ook vanwege "click fraud": partijen "onderweg" die deden alsof de gebruiker "aan het einde van de lijn" op een advertentie klikte.

Derde partijen buiten de deur
Een versleutelde verbinding tussen een webserver gegeven diens domeinnaam en een webbrowser voorkómt de meeste vormen van toegang tot die verbinding door derde partijen. Daar bestaan uitzonderingen op, maar dat zijn incidenten vergeleken met de eenvoud en massaliteit waarmee http-verkeer werd afgeluisterd, gewijzigd en/of omgeleid.

Voor de (vertegenwoordigers van de) adverteerders (de twee-en-een-halfde partijen) zijn DV (Domain Validated) certificaten goed genoeg; die houden die derde partijen buiten de deur. Ook als je alleen maar wilt dat veiligheidsdiensten (ook derde partijen) niet massaal kunnen afluisteren, volstaan in de meeste gevallen DV-certificaten.

Nb. veiligheidsdiensten kunnen nog steeds meta-data vergaren (in elk geval van-naar IP-adressen, het aantal uitgewisselde bytes en daarmee zelfs versleutelde webpagina's identificeren) en onversleuteld aftappen bij hosting- en CDN-providers. Ook kunnen ze actieve aanvallen uitvoeren door een server direct vóór de echte server te plaatsen (met hetzelfde IP-adres dus), daar een DV-certificaat voor aanvragen (bijvoorbeeld van Let's Encrypt) en daar (desgewenst selectief, bijv. afhankelijk van het IP-adres van de client) nauwelijks detecteerbare Attacker-in-the-Middle aanvallen mee uitvoeren. Maar dit is allemaal veel meer gedoe en/of levert minder "intel" op dan http-verkeer afluisteren deed.

Je hebt (deels) gelijk
Je hebt dus gelijk dat DV-certificaten derde partijen buiten de deur houden (niet de twee-en-een-halfde partijen: adverteerders, analytics-boeren en ordinaire meekijkers waarvan de website-eigenaar vindt dat zij mogen meekijken en manipuleren).

Echter, voor burgers die zich netjes aan de wet houden (dus niets te vrezen zouden moeten hebben van veiligheidsdiensten), en die zelf geen last hadden van vervangen advertenties en/of klik-fraude, zijn deze certificaten irrelevant. Voor hen is het van primair belang dat een website, van een tweede partij, van de organisatie is waarvan zij denken dat die website is, en dat zij niet om de tuin worden geleid door cybercriminelen.

Door Anoniem: En het maakt verschil voor elke netwerk node waar netwerkverkeer langs komt. HTTP staat echt wagenwijd open voor MITM-aanvallen.
Klopt. Ik heb dan ook altijd gepleit voor https i.p.v. http.

Maar waar het hier om gaat is niet http versus https, maar https met een legitieme partij versus https met een criminele partij die zich voordoet als een legitieme partij.

Door Anoniem: Zelfs zonder dat je weet wie eigenlijk die HTTPS-webserver bestiert voegt het al wat toe dat in ieder geval geregeld is dat je een foutmelding krijgt als er met het verkeer tussen jou en die server geknoeid is.
Wat een onzin. "Mijn bankrekening is geplunderd maar gelukkig kreeg ik geen https foutmelding en kon er niemand meekijken!"

Sterker, als jouw router en/of jouw ISP http verkeer op kwaadaardige links en/of content scannen, zou http wel eens veiliger kunnen zijn dan https. Niet voor niets zijn er organisaties en virusscanners die je rootcertificaten laten installeren om "TLS-inspectie" te kunnen doen.

Zonder dat soort (controversiële en nieuwe risico's introducerende) maatregelen zijn organisaties volledig afhankelijk van "endpoint security" maatregelen, die een single point of failure vormen (en te vaak niet werken). Ik zeg niet dat we naar http terug moeten, maar wel dat we veel te weinig zekerheden hebben over de andere kant van versleutelde verbindingen.

Door Anoniem: Ja, het zou geweldig zijn als de verificatie van alle certificaataanvragers zo sterk zou zijn dat het slotje in de adresbalk zekerheid zou geven dat je met een bona fide partij in verbinding staat.
Dat is larie want dat kan nooit. Als jij zaken doet met iemand waarvan jij precies weet wie het is, zegt dat totaal niets over de betrouwbaarheid van die persoon. Hooguit weet je hoe die persoon zich in het verleden heeft gedragen, maar dat biedt geen harde garanties voor de toekomst.

Het beste dat we met techniek voor elkaar kunnen krijgen, is dat je redelijk zeker weet met welke partij je communiceert en dat dit niet eenvoudig gespoofed kan worden. DV-certificaten blijken in de praktijk veel te eenvoudig te misbruiken door criminelen.

Vergelijkbaar: als je vindt dat er teveel jongeren met grote messen rondlopen en verbieden niet helpt, kun je er ook voor zorgen dat die grote messen niet "bij de HEMA voor het grijpen liggen".

Door Anoniem: Maar die zekerheid had je voor Let's Encrypt ook al niet, CA's hadden allang de verwachtingen op dat vlak beschaamd. In de praktijk lijkt dat een gepasseerd station te zijn.
Er zijn incidenten geweest (zoals de hack van Diginotar). Maar die wegen nauwelijks op tegen hoe vaak het goed ging en gaat. En dat is nodig ook, want er bestaat, in de praktijk, geen alternatief.

Helaas zijn EV-certificaten onderdrukt doordat de USA geen fatsoenlijke federale kamer van koophandel heeft (waardoor onderzoekers konden demonstreren dat je in elk van twee staten een andere organisatie kon oprichten die dezelfde EV-karakeristieken kreeg, bijvoorbeeld "Duplicate, Inc. [USA]").

Nog veel meer helaas is dat webrowsers sindsdien niet in één oogopslag duidelijk maken dat de server een DV- of een betrouwbaarder certificaat heeft opgestuurd.

Zoals ik al eerder aangaf: een gebruiker heeft niets aan een DV-certificaat als hij/zij niet weet of een domeinnaam van de bedoelde organisatie is of niet - vooral niet als misbruik supereenvoudig is omdat Let's Encrypt (maar ook andere DV-cert-uitgevers), zonder blikken of blozen, certificaten uitgeven die duidelijk bedoeld zijn voor phishing, en dat in no time, zonder enige vorm van authenticatie van de aanvrager en geheel gratis. Dat is de kat op het spek binden.

Voorbeelden: microsoft-sso.net, mlcrosoft.cloud en mlcrosoft.info (die laatste krijgt al meer dan 2 jaar DV-certs, zie https://crt.sh/?q=mlcrosoft.info). Drie voorbeelden uit een lange lijst met domeinnamen te vinden in https://blog.group-ib.com/0ktapus (bron: https://www.security.nl/posting/765689/Tienduizend+accounts+bij+130+organisaties+getroffen+door+grote+phishingaanval).
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.