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

Man-in-the-middle-aanval treft Fox-IT

Het Nederlandse beveiligingsbedrijf Fox-IT heeft afgelopen september te maken gekregen met een man-in-the-middle-aanval. Door dns-gegevens aan te passen, onderschepte een aanvaller gedurende korte tijd bestanden.

Na enkele verkennende scans bij de infrastructuur van Fox-IT halverwege september, paste de aanvaller op 19 september de dns-records van clientportal.fox-it.com aan bij de registrar. De ClientPortal is de web-app van het beveiligingsbedrijf om bestanden met klanten uit te wisselen. Gedurende tien minuten ving de aanvaller e-mail voor Fox-IT af, door de registratie van een vals ssl-certificaat voor clientportal.fox-it.com.

Vervolgens vond de daadwerkelijke aanval plaats; de aanvaller liet verkeer naar de portal doorsturen naar een vps-aanbieder in het buitenland. De aanval vond vroeg in de ochtend plaats en diezelfde ochtend detecteerde het bedrijf dat de dns-instellingen gewijzigd waren. Fox-IT voorkwam dat klanten de ClientPortal nog langer konden gebruiken, maar liet de aanval op de 19e voortduren voor onderzoek.

Het bedrijf lichtte vervolgens de politie en de Autoriteit Persoonsgegevens in. Na onderzoek kwam het bedrijf tot de conclusie dat tijdens de aanval twaalf bestanden zijn onderschept, waarvan drie vertrouwelijk. "Bestanden die als staatsgeheim zijn gerubriceerd worden nooit uitgewisseld middels ClientPortal", meldt Fox-IT. Ook inloggegevens van negen gebruikers van de portal zijn in handen van de aanvaller, maar deze zouden niet bruikbaar zijn. Ook is een lijst van namen van ClientPortal-accounts onderschept.

Volgens het beveiligingsbedrijf was de hack mede mogelijk doordat het wachtwoord sinds 2013 niet gewijzigd was. Daarnaast ondersteunde de registrar geen tweetrapsauthenticatie. "Wij hebben onze dns-provider achttien jaar geleden gekozen toen 2fa nog geen overweging of optie was", aldus Fox-IT in een publicatie waarin het verloop van de aanval beschreven wordt. Over de toedracht en details over mogelijke aanvaller meldt het bedrijf niets.

Door Olaf van Miltenburg

Nieuwscoördinator

14-12-2017 • 14:31

169 Linkedin Google+

Submitter: Xyrr

Reacties (169)

Wijzig sortering
Het is nu december... is het netjes gemeld? Want volgens mij is dat verplicht toch?
Raar dat dit nu pas in het nieuws komt..
Dat staat in de tekst:
Het bedrijf lichtte vervolgens de politie en de Autoriteit Persoonsgegevens in.
"Het bedrijf lichtte vervolgens de politie en de Autoriteit Persoonsgegevens in."

In een lopend onderzoek mag je vaak geen mededelingen doen. Ik neem aan dat de klanten met getroffen informatie natuurlijk wel op de hoogte zijn gebracht tzt.
Pas in Mei 2018 is dit verplicht.
Incorrect. Dan is het verplicht om het te melden bij de EU: nieuws: Organisaties hoeven geen melding meer te doen als ze persoonsgegevens...

Dat ging overigens over iets anders, namelijk het verwerken van persoonsgegevens.
En gelijk weer een opdracht van de politie om onderzoek te doen naar hun eigen hack? :+
De vraag is niet of je gehackt kan worden, de vraag is wanneer je gehackt wordt. Elk apparaat wat aan het internet hangt is linksom of rechtsom te hacken.

Belangrijker is de vraag wat je hiervan leert en welke maatregelen je neemt om dit in de toekomst te voorkomen. Daarmee voorkom je wederom niet dat het ooit weer kan gaan gebeuren, je zorgt er alleen voor dat het steeds lastiger wordt.

Als een echte hacker (dus geen scripkiddie e.d.) ergens in wil, dan komt hij erin. Of dat nu 2 uur, 2 weken, 2 jaar of 20 jaar kost. Door je beveiliging op te schroeven en te leren van je fouten maak je die tijd steeds langer, en hoe langer dat het duurt hoe groter de kans dat een hacker afhaakt en andere bedrijven aan gaat vallen.
Ik vind dit eigenlijk wel erg kort beschreven: hoe heeft hij dit kunnen doen? Puur op basis van de DNS?
"Email: we weten dat de aanvaller gedurende maximaal 10 minuten Fox-IT email heeft onderschept en dat email gericht aan Fox-IT gedurende die 10 minuten is omgeleid naar een externe emailprovider. Omdat de verspreiding van email op internet decentraal geregeld is, kunnen we niet vaststellen welke e-mails gedurende die tijd door de aanvallers zijn onderschept."
Zoals in het volledige artikel staat: ja de bewering is puur via DNS.
Ik snap niet dat aangehaalde tekst niet duidelijk is voor iemand die beweerd informatica te hebben gestudeerd op HBO nivo. Het doel was schijnbaar een MitM, maar om dat voor elkaar te krijgen was het even nodig om al het mail verkeer te onderscheppen, na aanvraag/controle van het ssl certificaat zijn of de MX records weer hersteld of is de mail bij FoxIT afgeleverd met een MitM. Voor de 10m periode is het voor FoxIT dus niet mogelijk om te weten welke mail aangeboden is geworden op de rogue smtpd.
Wauw, subtiel. Dank je voor het in twijfel trekken van mijn opleiding.
Ik snap heel goed hoe een boel werkt, maar toevallig weet ik van de diepere zaken qua mail niet alles nee, jij weet wel alles? (in mijn tijd kreeg je dat niet op HBO Informatica, ik ben in 2004 afgestudeerd, zat jij toen al in de brugklas?)
Ik bedoel meer dat je met normale TTLs enzo over het algemeen niet even kunt kiezen wanneer je 10m mail kan onderscheppen, dat is moet je toch wel aardig timen. Of zou fox-it een f'ing lage TTL hebben op hun MX records?
Zou wel eens willen weten waar ze het domein dan geclaimed hebben. Ze hebben iig later zeker een keer verhuist..
Volgens de DNS hebben ze eigen servers.
Cloudflare staat er bij het domein en die bestaan pas sinds 2008
het ip adres van de clientportal verwijst naar Breedband Delft , en die bestaan ook nog geen 18 jaar.
Er klopt iets niet aan deze verklaring

[Reactie gewijzigd door citegrene op 14 december 2017 22:44]

Dit is gewoon een sollicitatie van een toekomstige werknemer. Hij heeft zijn visitekaartje afgegeven....
Met al die beste stuurlui hier zouden die vacatures bij https://www.fox-it.com/nl/werken-bij-fox-it/vacatures/ toch snel gevuld moeten kunnen zijn :+
Het is inderdaad schokkend dat ze geen DNSSEC enabled hebben voor hun eigen domein(en). Maar het gebruik ervan staat nog niet garant voor de onmogelijjkheid van deze MitM, zolang niet iedereen op valided ondertekening controleert zijn deze personenen/organisaties die dit niet doen vatbaar.

edit: het artikel lezende had DNSSEC niets uitgehaald, het lek zat bij de authoritative DNS servers. De records zouden dan ook netjes signed zijn geweest. De enige workaround is scheiden van signing en hosting van records. Dus zelf een master draaien en de publieke auth. servers daar een slave van maken. Het liefst met een airgap van de master naar de slaves.

[Reactie gewijzigd door Dorank op 14 december 2017 15:31]

DNSSEC had hier niet geholpen. Ik begrijp dat er met valide logingegevens een record is toegevoegd aan de zonefile van fox-it.com. Met deze manier van aanvallen had ook dat nieuwe record gewoon valide DNSSEC gehad.
Naast DNSSEC heb je ook nog TLSA. Waarschijnlijk zal de attacker een LetsEncrypt certificaat gebruikt hebben.
TLSA records zitten ook in dezelfde zonefile waar de hacker blijkbaar bij kon komen, dus dat had je hier ook niet gered.
Ze hadden de SOA timestamp kunnen monitoren,
Ik neem aan dat je de serial bedoelt? Maar als je bij de registrar de dnsservers, of laten we eens gek doen: het SOA record zelf, kan aanpassen, biedt dit geen enkele toegevoegde waarde.
Die kun je gewoon ongewijzigd laten. Kleine kans dat je slave NS'en dan niet sync'en, afhankelijk van de manier waarop ze changes pushen naar slave NS servers. Veel partijen doen dat inmiddels via database replicatie en niet via AXFRs.
Zoals ik zelf ook al gecorrigeerd had heeft DNSSEC geen toegevoegde waarde bij auto signing door de auth. servers. Maar het heeft daadwerkelijk wel toegevoegde waarde als de boel strict gescheiden wordt. Je registrar moet geen automatische koppeling hebben met de TLD beheerder om DNSSEC aan te passen en je DNS provider moet iemand anders zijn dan de registrar. Dan is er geen single point of failure voor dit soort aanvallen. Ze zijn nog steeds mogelijk, maar het vereist wat meer coordinatie bij aanvallen op verschillende organisaties.
Je registrar heeft altijd een koppeling met de TLD. Dat is toch het hele idee van een registrar? Wat moet je registrar nog meer doen dan mutaties uitvoeren bij de TLD?

Ik ben het met je eens dat de DNS onder brengen bij je registrar misschien niet altijd de beste keuze is, maar dat had hier niet perse de hack voorkomen. Ze hadden ook gewoon voor 10 minuten de DNS servers kunnen wijzigen.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True