Aanvallers kraken website SIDN - update 2

Een voor registrars bedoelde website van de Stichting Internet Domeinregistratie Nederland is gekraakt. Momenteel is de website uit voorzorg afgesloten. Bij de aanval is een bestand met logingegevens en wachtwoorden buitgemaakt.

De website die was getroffen is bedoeld voor registrars en wordt door hen gebruikt om bijvoorbeeld facturen, factuurbijlagen en rapportages te downloaden, zegt ict-manager Cees Toet van de SIDN. Registrars zijn partijen die domeinnamen mogen registreren bij de SIDN, die het .nl-domein beheert.

Bij de aanval werd een bestand met een onbekend aantal loginnamen en versleutelde wachtwoorden buitgemaakt. De wachtwoorden zijn voorzien van salts, verzekert Toet. Bovendien werd op de webserver malware aangetroffen, al zou die niet aan gebruikers zijn geserveerd. Om welke malware het gaat, is nog niet duidelijk.

De getroffen website is een andere dan de site die wordt gebruikt om domeinnamen te registreren, de zogenoemde DRS-website. Uit voorzorg is de toegang tot de DRS-website wel beperkt. Zo zijn er restricties op het registreren en verhuizen van domeinnamen. Ook zijn de wachtwoorden van alle gebruikers gereset. Daarnaast is de publicatie van de zogenoemde zonefile uit voorzorg stopgezet. In de zonefile staat de dns-zone opgeslagen; als kwaadwillenden daar toegang toe krijgen, zouden ze de dns-instellingen van domeinnamen kunnen wijzigen en ze bijvoorbeeld laten doorverwijzen naar malafide websites. Voor zover bekend is dat niet gebeurd.

Waarschijnlijk is de aanval begonnen via een sql-injectie op de site 25jaarvan.nl, die op dezelfde server als de registrarwebsite staat, en die was bedoeld om te vieren dat het .nl-domein 25 jaar oud is. "We zijn nu aan het onderzoeken hoe lang de website malware aanwezig was", zegt Toet. Hij kan niet aangeven of het een kwestie van dagen of uren is. Dinsdag werd de toegang tot de registrarwebsite al geblokkeerd. Toet verwacht dat de site later vandaag weer bereikbaar is. De publieke website van de SIDN is niet getroffen.

Update, 11:50: Aanvankelijk meldde dit artikel dat de SIDN-website malware bevatte. Dat is een misverstand, zo blijkt. Er was wel malware aanwezig op de webserver van de SIDN, maar die werd niet daadwerkelijk geserveerd aan gebruikers. Het stuk is bijgewerkt met die informatie.

Update, 14:06: De frontpage van de beheerder van het .be-domein, DNS.be, is dinsdag eveneens gehackt, zo blijkt uit een mail aan klanten. Een woordvoerder van DNS.be zegt dat er voor zover bekend geen gebruikersgegevens zijn buitgemaakt, maar het onderzoek naar de aanval is nog niet voltooid. Wel is de voorpagina van DNS.be tijdens de aanval gedefaced.

Reacties (39)

[Booster]

Wellicht is het ook een goed idee om leestekens toe te gaan staan in wachtwoorden die voor DRS gebruikt moeten worden. Deze ondersteuning mist momenteel en had de hashes uit de gestolen data mogelijk een stuk lastiger gemaakt om te kraken.

Zowel SIDN als DNSBE zijn natuurlijk gewilde targets. SIDN is een van de grootste landendomeinnamen en daarmee kan er dus veel data buit worden gemaakt.

[Reactie gewijzigd door Booster op 22 juli 2024 23:11]

[Urk]

Goed punt. Dit heb ik als deelnemer ook reeds 2 keer gevraagd aan SIDN. Toevallig gisterochtend voor het laatst voor de aanval...
Eerder werd gemeld dat dit binnenkort in een nieuwe DRS release zou zitten. Gister bleek van niet maar dat het er binnenkort aan zit te komen en in de planning staat.

Het is toch triest dat ze veilige wachtwoorden willen en geeneens leestekens toestaan?!!

[tiguan]

Idd, ik moest net een nieuw wachtwoord invoeren en verbaasde me dat mijn 'sterke' wachtwoord gewoon niet geaccepteerd werd door hun website.

[Scraxxy]

Hier intern bericht:

- English version will follow shortly -

Dinsdag 9 juli 2013 is gebleken dat een aantal SIDN-websites kwaadaardige software bevatten dan wel gecompromitteerd zijn. Om mogelijk misbruik en ongewenste mutaties in de domeinregistratiedatabase te voorkomen zijn vannacht diverse maatregelen genomen, die impact hebben voor .nl-registrars. Zo is sinds 1.15 uur de DRS-webapplicatie preventief afgesloten en is de zonefilepublicatie uitgesteld. De laatste publicatie was op 09 juli om 22.00 uur. Ook de RTO om dezelfde reden momenteel niet beschikbaar. In dit bericht zetten we de getroffen maatregelen verder uiteen.

Wachtwoorden DRS-webinterface gereset
Alle wachtwoorden die toegang geven tot de DRS-webinterface zijn preventief gereset. Gebruikers van de webinterface ontvangen een nieuw wachtwoord op het notify e-mailadres. Wij raden u dringend aan dit initiële wachtwoord direct weer te wijzigen.

Wachtwoorden EPP-interface wijzigen
We raden gebruikers van de EPP-interface van DRS dringend aan om per ommegaande hun wachtwoorden te wijzigen.

Openstelling DRS-webinterface en publicatie zonefile
Onderzoeken van vannacht van de logging van diverse servers hebben vooralsnog geen onregelmatigheden aan het licht gebracht. Deze uitkomst in combinatie met de getroffen maatregelen zijn voor ons aanleiding om de DRS-webinterface om 09.00 uur weer open te stellen. Tevens zijn wij weer aangevangen met de publicatie van de zonefile (eerste per 08.00 uur)

Registrarssite niet beschikbaar
Zojuist is besloten om ook de toegang tot de registrarssite preventief te blokkeren. Correspondentie over dit incident verloopt tot nader order via e-mailberichten die worden verzonden aan het mailadres van de registrarcontactpersoon.

Achtergrond
Door de inbraak in één van onze webservers heeft men toegang gekregen tot een bestand met logingegevens voor de registrarssite. Het gaat hier om registrarnummers en de daaraan gekoppelde – versleutelde – wachtwoorden. Met de gegevens in dit bestand is dus nog geen directe toegang tot de registrarssite mogelijk. Omdat we willen uitsluiten dat dit alsnog kan gebeuren zijn bovenstaande maatregelen noodzakelijk.

Vragen
Heeft u vragen naar aanleiding van dit bericht of hulp nodig bij één van de hierboven beschreven maatregelen, neemt u dan contact op met onze supportafdeling via mailadres [e-mail], Twitter (@SIDNsupport) of telefoonnummer 026 352 55 55.

Met vriendelijke groet,
SIDN

- einde bericht / end of message -

[zndrwrk]

Ik krijg net bericht van dns.be dat ook hier in België er hack problemen waren.
"Yesterday morning, Tuesday 9 July, we discovered a deface hack on the DNS.be website."

Toeval, of... ?

[daverdty]

Het is nu wachten tot EURid gehacked wordt / of dat ze dat al zijn...

[P-e-t-j-e]

Waarom komt iedereen telkens terug op sql-injectie? Of op het feit dat de systemen niet beveiligd zouden zijn? Het zou zomaar kunnen zijn dat bij het uploaden van de 25jaar website geinfecteerde bestanden door de websitebouwer zijn geplaatst. Of dat via een andere weg de accountgegevens van een SIDN medewerker met toegang tot het CMS zijn buitgemaakt.

In mijn ogen is SIDN een professionele organisatie die een professioneel serverpark in gebruik heeft. Daar zullen echt de nodige beveiligingen in aangebracht zijn, zoals het gescheiden houden van het DRS netwerk en registrarsite (zoals ik hierboven lees). Ze zullen echt geen websitebouwertje van om de hoek aan hebben getrokken om de site te maken, ik verwacht dat men daar echt wel weet wat men aan het doen is.

Daarnaast is SIDN voor mijn gevoel een van de voorstanders van goede veiligheidsprotocollen. De DNSSEC implementatie is bijvoorbeeld als goed op gang, alsmede het .nl control traject. Ik vind de reactie op het constateren van de malware dan ook goed te noemen.

[Scraxxy]

Update 2:

Vanochtend heeft SIDN in verband met een security-incident de wachtwoorden voor de DRS-webinterface gereset. Hiervoor is gebruik gemaakt van de standaard functionaliteit in DRS. Dit betekent dat u een automatisch gegenereerd bericht op uw notify e-mailadres heeft ontvangen met de tekst: ‘De door u aangevraagde wijziging is door SIDN doorgevoerd.’ Omdat de wijziging niet door u is aangevraagd heeft dit mogelijk voor verwarring gezorgd. Wij benadrukken: het betreft hier een standaard bericht dat DRS uitgestuurd heeft als reactie op het resetten van uw wachtwoord door SIDN.

Tevens ontvangen wij opmerkingen over het feit dat de wachtwoorden niet versleuteld verzonden zijn. Wij zijn ons bewust van deze onvolkomenheid in DRS. Omwille van de snelheid om DRS weer volledig operationeel te krijgen is voor het verspreiden van de nieuwe initiële wachtwoorden toch gekozen om gebruik te maken van bestaande functionaliteit, met daarbij het verzoek het initiële wachtwoord direct te wijzigen. Vanzelfsprekend bestaat er wel een RFC voor het aanpassen van DRS op dit gebied.

Vragen
Heeft u vragen naar aanleiding van dit bericht of hulp nodig bij een van de hierboven beschreven maatregelen, neemt u dan contact op met onze supportafdeling via mailadres [e-mail], Twitter (@SIDNsupport) of telefoonnummer 026 352 55 55.

Met vriendelijke groet,
SIDN

* * * * * * *

[Reactie gewijzigd door Scraxxy op 22 juli 2024 23:11]

[cctld]

Gaat lekker zo

• iedr.ie http://www.internetnews.m...-about-security-incident/
• Pakistan, google.pk en yahoo.pk redirected
• NIC GP http://thehackernews.com/...in%20registrar%20hacked#_
• NIC Peru (21 oct 2012)
• NIC RO, google.ro, yahoo.ro redirected
• DNS BE
• SIDN

[Niemand_Anders]

Eigenlijk wel slim om malware bij een partij als SIDN te plaatsen. Alle Nederlandse banken hebben immers een .nl domein en als je eenmaal de login gegevens hebt van een aantal (grote) registers, maakt dit het ook mogelijk de contact informatie van bijvoorbeeld het ING.nl domein aan te passen.

Vervolgens kun je middels de gewijzigde domein gegevens een EV-SSL certificaat aanvragen voor de phishing website.. Immers de bevestiging wordt doorgaans naar het techincal/administrative email adres van het domein gestuurd en deze is lang niet altijd hetzelfde als het domein waarvoor het certificaat wordt aangevraagd want veel domeinen worden beheerd door een andere partij dan de eigenaar, meestal de provider.

[makafeli]

Bij een EV-SSL word er geen validatie d.m.v een mail gestuurd naar de klant, bij de A brand CA's
moet je de volgende validatiestappen doorlopen:

*CSR moet exact overeen komen met de KVK
*Klant gegevens moeten exact overeen komen met de KVK
* Telefoonnummer moet bekend zijn vanuit een 3de bron of evt. KVK of aangeleverd
vanuit een notaris.
* Telefonische validatie met de Admin Contact en daarnaast een HR medewerker of Eigenaar
* WHOIS moet exact overeen komen met de KVK gegevens.


Om aan een EV-SSL te komen gaat niet zo makkelijk zoals je het hierboven omschrijft.

[RobIII]

Een EV-certificaat (Extended Validation zegt 't al) heb je niet "zomaar" effe gescoord AFAIK. Daarbij verwacht ik dat ze raar opkijken als je voordat je de hack uitvoert een EV-cert probeert te scoren (wat je zult moeten doen wil je niet alle werk voor niets doen als je hack na 4 uur ontdekt wordt waarna je je EV-cert never-ever al zult hebben) als het bestaande certificaat op een andere naam staat

[Reactie gewijzigd door RobIII op 22 juli 2024 23:11]

[Sfynx]

Vervolgens kun je middels de gewijzigde domein gegevens een EV-SSL certificaat aanvragen voor de phishing website.. Immers de bevestiging wordt doorgaans naar het techincal/administrative email adres van het domein gestuurd en deze is lang niet altijd hetzelfde als het domein waarvoor het certificaat wordt aangevraagd want veel domeinen worden beheerd door een andere partij dan de eigenaar, meestal de provider.

Bij EV certificaten bellen ze ook je organisatie op, en dan weten ze van niks natuurlijk.

[Verwijderd]

Waarschijnlijk is de aanval begonnen via een sql-injectie op een andere site van de SIDN, die op dezelfde server als de registrarwebsite staat.

Juist hiervoor zijn Virtual Machines of FreeBSD Jails nuttig om een duidelijke scheiding te brengen tussen verschillende services. Dan kan het binnendringen van service A geen of veel moeilijker gevolgen hebben voor andere services die op dezelfde fysieke machine draaien.

Voor zoiets belangrijks als de services van SIDN had ik wel verwacht dat dergelijke beveiligingsmaatregelen van toepassing zouden zijn. Wat mij betreft dus best wel een domper!

@RobIII: het gebruik van Jails betekent niet automatisch dat alles 100% veilig is, dat klopt. Maar toch wordt het je wel extreem moeilijk gemaakt, zeker als je de rest ook dichtbouwt. Zo kun je configureren dat Jail A alleen maar op poort 80 verkeer mag ontvangen en geen netwerkverkeer met andere lokale servers of VMs of Jails mag hebben. Je kunt jails ook configureren dat er geen normale utilities zijn (denk aan wget/fetch) zodat het binnenhalen van malware vrijwel onmogelijk is omdat je zelfs de meest basale utilities mist. De Jail beschikt dan enkel over de libraries en binaries die strict noodzakelijk zijn voor de dienst.

Met andere woorden, juist met Jails evenals virtualisatie kun je het zaakje goed dichttimmeren. Daar lijkt hier geen sprake van te zijn. Sowieso is het natuurlijk een domper als je slachtoffer bent van SQL-injectie. Dan is het ergens goed mis gegaan met de gouden regel voor softwareontwikkeling:
DO NOT TRUST USER INPUT!

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:11]

[RobIII]

Misschien zijn die maatregelen wel genomen Je zegt zelf: "Dan kan het binnendringen van service A geen of veel moeilijker...". Moeilijk != onmogelijk Je conclusie vind ik dus een tikkie voorbarig

Of die maatregelen ook daadwerkelijk zijn getroffen is een tweede natuurlijk (en het zal niet voor 't eerst zijn dat ze "vergeten" / "overgeslagen" / "voor volgende week gepland waren" zijn).

[Reactie gewijzigd door RobIII op 22 juli 2024 23:11]

[mae-t.net]

Volgens de razor-eliminatie, gebeuren makkelijke dingen veel vaker dan moeilijke of heel moeilijke. De kans dat de maatregelen vergeten of ingepland waren lijkt me dus zéér groot.

@Yggdrasil: Ik reken niemand af hoor. Iedereen wordt wel een keer 'gehackt', hoe zorgvuldig je ook te werk gaat.

@RobIII: Zelfs bij de rechter komt wel eens statistiek kijken, en daar gaan ze ook wel eens mee de fout in, maar vanzelfsprekend lijkt me een veroordeling op gammele statistische gronden ongewenst. De rechercheur gebruikt het scheermes waarschijnlijk wel om zijn onderzoek efficienter te maken (zonder daarbij oogkleppen op te zetten als het goed is). Ik had duidelijker moeten vermelden dat ik (en in principe de meeste mensen die op goedbedoelde speculaties ingaan) het niet vanuit het standpunt van een rechter bekijken maar vanuit het standpunt van een rechercheur (troubleshooter, tweaker).

[Reactie gewijzigd door mae-t.net op 22 juli 2024 23:11]

[Yggdrasil]

Maar het heeft geen nut voor ons om daarover te speculeren. SIDN zal die overweging vast maken bij het doen van de post-mortem analyse, en dus eerst de meest voor de hand liggende oorzaken onderzoeken.

Wij hebben echter op dit moment te weinig informatie om in te schatten wat er gebeurd is, dus is het voorbarig om SIDN te gaan afrekenen op basis van kansberekening.

[RobIII]

Stel je voor dat je voor de rechter staat en er hangt je een grote straf boven 't hoofd en die knakker/dame hanteert gewoon Occam's razor i.p.v. bewijslast te bekijken, getuigen te verhoren etc. Dat een kans (zéér) groot is maakt 't nog niet waar en de conclusie is dus een beetje voorbarig. En dat was precies wat ik zei.

[Reactie gewijzigd door RobIII op 22 juli 2024 23:11]

[Sfynx]

Je bent wel een koning als je uit een VM of FreeBSD jail weet te breken, dan verdien je deze aandacht zeker.

[Tozz]

SIDN meldt in een e-mail naar registrars zelfs dat 1 van de webservers is gehacked. Dat geeft mij de indruk dat het niet om een webbased aanval gaat, maar dat een server op een ander niveau is gepenetreerd. Immers, als het om een SQL injectie gaat of iets dergelijks dan zou je verwachten dat alle webservers hetzelfde serveren en dat was hier blijkbaar niet het geval.

[djiwie]

Wellicht heeft men door de SQL injection op de de25jaarvan.nl site een gebruikersnaam en wachtwoord achterhaald van een SIDN-medewerker die dat wachtwoord ook gebruikte voor andere (wel kritieke) systemen. Een technische jail voorkomt een dergelijk scenario niet.

DRS zit overigens in een compleet ander netwerk dan de websites van SIDN.

[sfranken]

Ook een VM of een jail is te doorbreken. Een VM wat makkelijker gok ik dan een Jail.

[Sfynx]

Ik denk juist andersom. Een jail deelt de kernel met het host systeem, dus meer mogelijke aanvalsroutes.

[Urk]

Zeker netjes door SIDN gemeld, ze steken gelukkig niet hun kop in het zand zoals je vaak merkt met dit soort kwesties...

Wel zou ik graag willen weten welke malware geserveerd is en wat er gebeurd zou zijn aangezien ik gister voordat dit verhaal bekend werd nog op de registrarsite ben ingelogd.

[Yggdrasil]

Zie de update die inmiddels aan het bericht is toegevoegd. Tweakers was voorbarig met het melden van malware. In de berichtgeving vanuit SIDN is daarvan namelijk geen sprake. Je hoeft je daarover dus op dit moment geen zorgen te maken.

[Urk]

Mooi, goed te lezen, tnx!

[sumac]

Waarom zetten ze die 25jaar website op dezelfde server? Neem een simpel hostingpakket van een paar tientjes bij een provider en je loopt minder risico. Lijkt me voor een dienst als SIDN vanzelfsprekend dat ze dit goed gescheiden houden.

[s.stok]

Neem een simpel hostingpakket van een paar tientjes bij een provider en je loopt minder risico.

ISDN heeft aardig wat servers on zijn beheer dus een pakketje bij een hosting provider is wel erg armzalig.

Ik ben zeer benieuwd naar de achtergrond van deze aanval (waren de systemen idd gescheiden, maakten ze verbinding met deze database), want een vitaal onderdeel van je infrastructuur gehackt laten worden via een reclame-site die je zelf beheerd is erg amateuristisch, zelfs ISDN.