Sinds begin 2010 speuren we structureel naar phishing-sites onder .nl-domeinnamen. Samen met onze registrars willen we gebruikers vrijwaren van deze vorm van internetcriminaliteit. Phishing-sites zijn slecht voor de reputatie van ons nationale topleveldomein en vormen een aantasting van het vertrouwen in internet. Daarnaast zorgen ze voor (soms forse) financiële schade.[meer...]

Ondanks een kordate aanpak (veelal is de malafide website onder .nl al binnen een uur offline gehaald, of geblokkeerd via Google’ s 'Safe Browsing lijst'), zien internetcriminelen kennelijk toch nog voldoende brood in deze vorm van oplichting en neemt die nog elk jaar toe, zoals ook is te lezen in deze blogpost van Google.

Ook in het .nl-domein zien we deze stijging terug in onze statistieken:

Phishingaanvallen per maand 
Ten opzichte van drie jaar geleden een dikke verdrievoudiging van het aantal gedetecteerde phising-sites.

Doelwitten
De doelwitten van phishing zijn voornamelijk buitenlandse financiële instellingen. Hoewel ook identiteitsdiefstal, bijvoorbeeld van Facebook- of Gmail-accounts, voor komt. PayPal staat met stip op nummer één in onze statistieken. Ruim een kwart van alle ontdekte phishing-websites heeft hier betrekking op. Geen wonder dus, dat Paypal stevig inzet op alle mogelijke vormen van beveiliging, waaronder DKIM en DNSSEC.

Phishing-pagina’s gericht tegen klanten van Nederlandse banken, zoals ABN Amro, ING en Rabobank komen minder vaak voor onder .nl-websites, al noteerden we in de laatste weken wel een opmerkelijke stijging.

De ene phish is de andere niet
Phishing is er in diverse soorten en maten. De meest geavanceerde is een aanval op basis van DNS cache poisoning, maar veelal is zo’n complexe aanval niet nodig. Bovendien is die prima te voorkomen met DNSSEC. Maar kennelijk trappen nog genoeg gebruikers in de aanzienlijk minder gesofisticeerde nep e-mails, die zogenaamd afkomstig zijn van een bank (al dan niet in gebrekkig Nederlands). Soms hebben de criminelen daarbij nog de moeite genomen om een enigszins relevante domeinnaam te registreren (zoals ‘uwbankbeveiligingsupdate.nl’), maar ze werken net zo gemakkelijk met compleet willekeurige domeinnamen of met phishing-pagina’s die zijn verstopt onder in het geheel niet gerelateerde websites, die ze hebben gehackt. In alle gevallen worden er partijen gedupeerd, bijvoorbeeld hosters, die het nodige werk moeten verzetten om de malafide websites op te schonen. PKI-certificaten hebben de phishing-sites geen van allen. Men gaat er vanuit dat een deel van de gebruikers hier simpelweg niet op controleert.

Met zoveel verschillen, is een URL op juistheid controleren zeker niet voor iedereen even triviaal en met de komst van mobiele devices wordt het er niet overzichtelijker op:
 

Maar een klein deel van de gebruikers neemt in het geheel niet de moeite om te controleren of ze wel op de website van hun bank zijn terechtgekomen.

Onderzoek door SIDN Labs
Uiteraard blijven we bij SIDN werken aan de bestrijding van het phishing-probleem. Dat doen we niet uitsluitend met onze phishing-alert service (richting registrars) en aanvullend onderzoek naar de aard en omvang van het probleem (en betere tooling ter bestrijding er van). Maar bijvoorbeeld ook door tijd vrij te maken voor deelname aan een expertpanel voor DKIM (een internetstandaard die inmiddels is opgenomen op de ‘pas-toe-of-leg-uit’- lijst van de overheid). We nemen daarnaast deel aan de Abuse Information Exchange, werken samen met organisaties als het NCSC en initiëren vanuit SIDN Labs onderzoeken samen met academische instellingen, bijvoorbeeld op het gebied van gebruikersinteractie en bestrijdingsmaatregelen. De komende maanden zullen we regelmatig verslag doen van deze projecten, dus blijf deze blog volgen!

Referenties

Op zoek naar een goede methode om onze R&D Linux-systemen nog beter te beveiligen, bedachten we dat een ‘Time-based One-time Password (TOTP)’ wel heel sjiek zou zijn. Een token, bijvoorbeeld een software-token, waarmee je een verificatiecode genereert die eenmalig en slechts een paar seconden geldig is. Dat zou een goede, extra laag in de beveiliging kunnen toevoegen. Google doet zoiets ook al een tijdje met zijn ‘two-step verification’. En dat is wel zo veilig. [meer...]

Afbeelding Google Authenticator

De voordelen van open standaarden
Uiteraard zochten we naar een oplossing die een open standaard is. OATH-ondersteuning, bijvoorbeeld in de vorm van RFC6238 zou mooi zijn. Dus de ‘Google Authenticator’ viel bij voorbaat af. Of... toch niet? De software van Google volgt gewoon de standaarden! Via Google’s project-hosting vonden we hierover goede  informatie en PAM-software die vrij vlot was geïnstalleerd.
Nadat de PAM-software was gecompileerd en /etc/pam.d/sshd was uitgebreid met een klein regeltje, waren we klaar om te testen.

auth required pam_google_authenticator.so

Met de officiële ‘authenticator apps’ voor Android en iOS waren we meteen in business. Maar daarnaast zijn er nog tal van andere software-tokens (zelfs hardware-tokens) te vinden, die waarschijnlijk allemaal goed werken. Weer een voordeel van de interoperabiliteit die met een open standaard haalbaar is. Ook elders is veel te vinden, zoals de HTML5-google-authenticator, waarmee je jouw ‘token’ zelfs zonder dat je een telefoon bij de hand hebt, toch kunt opvragen. Deze maakt gebruik van ‘web storage’ om je gegevens te onthouden.

Eenvoudige exercitie
Al met al bleek het ‘aanzetten’ van ‘two-step’ verification op onze R&D-systemen echt heel eenvoudig. Daarentegen is de beveiliging tegen onbevoegde toegang enorm toegenomen. Een nuttige toevoeging dus, die we iedereen kunnen aanraden.

Referenties:

ANY-plaag deel 2

Een tijdje terug schreef ik over de DNS-amplification aanvallen die we met enige regelmaat voorbij zien komen op de ‘authoritative nameservers’ voor het .nl-domein. Ik gaf aan, dat we destijds ‘vooralsnog’ hadden gekozen voor een manier van ‘rate limiting’ op basis van IPtables-filtering. Dat werkte goed en voelde beter dan een destijds nog redelijk experimentele patch loslaten op onze BIND-nameservers. Bovendien was die patch er niet voor de andere door ons gebruikte software, NSD. De tijd heeft niet stil gestaan; de kwaadwillenden met hun aanvallen werden, zoals was te verwachten, weer ietsje gehaaider. Recentelijk zagen we bijvoorbeeld dat ze hun ANY-queries hebben aangepast. Ze vroegen niet alleen meer naar ‘.nl’, maar ook naar ‘.NL’ met hoofdletters en ook naar ‘.nL’ en ‘.Nl’. Uiteraard met de bedoeling om onze filters te omzeilen, wat aanvankelijk ook lukte.[meer...]

Op onderstaande grafiek zien we de voorbereidende handelingen voor de op handen zijnde aanval, die uiteindelijk ook in alle hevigheid losbarst.
Queries by QType 
En dat betekende voor ons een verviervoudiging van het aantal IP-tables regels, voor elke mogelijke variant een regel.

Kat en muis
Aan de kant van de tegenmaatregelen heeft men ook niet stil gezeten. Er is inmiddels heel wat ervaring met de ‘Response Rate Limiting’ (RRL) op nameserversoftware. Niet alleen is dit in BIND beschikbaar, maar sinds release 3.2.15 ook in NSD.  En dat bood voor ons nieuwe perspectieven.

De ‘RRL manier’ van rate limiting spreekt ons wel aan, want het biedt wat meer mogelijkheden om tegenwicht te bieden aan het misbruik van DNS voor DDoS-aanvallen. Het zit eigenlijk best slim in elkaar. Een paar zaken vielen mooi samen. We moesten bijvoorbeeld toch al een upgrade ronde inplannen, omdat BIND9.7 ‘end-of-live’ is, en konden die mogelijkheid dus mooi aangrijpen om alle .nl-nameservers uit te rusten met RRL.

Daarmee zijn we de kwaadwillenden voorlopig weer een stapje voor.

Inmiddels krijgen we ook in toenemende mate signalen dat de ‘bad guys’ aan het uitwijken zijn naar andere slachtoffers voor hun DNS-amplification aanvallen. Alle reden dus om nog eens goed naar uw eigen nameservers te kijken.

1
2 3 4 5 6 7