Het wordt pas echt interessant als de URL's aanpassen van waar de definities staan...dan kan je wellicht op een handige manier malware verspreiden.

Wat ik me nou vorige week al afvroeg, is alleen de DNS naar www.antivirusbedrijf.domein gewijzigd, of heeft dit ook een effect gehad op de de UPDATE server(s) van betreffende bedrijven waar de virusupdates vandaan komen?

Er wordt door de anti-virus bedrijven gedaan alsof dit geen probleem is.
Maar op deze manier zijn natuurlijk ook de update-servers aan te vallen, waardoor fraudulente updates kunnen worden gepushed.
Voor mij is het onbegrijpelijk dat deze bedrijven geen gebruik maken van DNSSec.

"Beide virusbestrijders merken op dat ze niet gehackt zijn en dat klantgegevens geen enkel moment risico liepen."

De klantgegevens niet, wellicht. Maar hoe zit het met de virusbescherming?
Als men het domein kan omleiden dan wordt ook het downloaden van virus signatures omgeleid.
Dit zal in ieder geval tot uitstel van updates leiden en als je pech hebt zelfs tot downloaden van een malafide update
die je hele systeem omzeep helpt.

Mbt ESET, dit gebeurde afgelopen zaterdag 12 Oktober. Het heeft voor ESET slechts enkele minuten geduurd, Kort nadat de DNS records waren gewijzigd zijn deze hersteld. Het kan zijn dat op bepaalde plaatsen wat langer de defaced pagina te zien was, dat heeft betrekking op het hoe snel de DNS wijzigingen worden doorgevoerd op lokale caches, ed.

Zo te zien komen alle antivirusprovider-websites aan de beurt,dus vermoedelijk kunnen o.a. ook Symantec Norton, Kaspersky Labs, Panda Security zo'n actie verwachten.Dat Registrar heeft duidelijk zn zaakjes qua veiligheid niet op orde en zou wellicht moeten worden vervangen.En ik neem aan dat zowel Registrar als de getroffen antivirusbedrijven aangifte doen bij de politie? De antivirus bedrijven tezamen met de politie zouden deze hackers toch moeten kunnen achterhalen? En dan maar een flinke celstraf opleggen.

Als hackers je DNS omzetten naar een eigen server en daar een TTL van een jaar op zetten, dan komt deze entry in
caches van resolvers en klanten terecht en kan daar een jaar blijven staan.
Dan kun je wel binnen een paar minuten het probleem opgelost hebben, maar daarna moet je al die klanten nog gaan
uitleggen hoe ze hun eigen cache kunnen flushen, en dat ze hun provider moeten bellen dat die de cache van hun resolver
moeten gaan flushen.

Een tijdje geleden had je het probleem dat op deze manier de DNS van een hoster gehacked was en hoewel dat na
enige tijd was opgelost heeft het nog een dag geduurd voordat alles weer normaal was. En dat alleen maar omdat de
hackers een TTL van een dag gebruikt hadden. Dat doen ze de volgende keer wellicht niet meer!

Security bedrijven hebben toch als specialiteit security?

Hoe kan het dan toch nog gebeuren als je al gewaarschuwd was doordat het anderen ook was overkomen?
Waarom moet ik als gebruiker dergelijke bedrijven nog serieus nemen als zij waarschuwingen niet oppikken, preventief weten te voorkomen?
Het eerste slachtoffer heeft een zeker excuus, de anderen die daarna volgen, alsnog ook slachtoffer worden niet meer, punt uit.

Het is mogelijk dat er geprobeerd wordt een update binnen te halen van een update-server met het nieuwe (na de hijack) IP nummer. Maar er zijn dan 2 mogelijkheden:

1. Op het IP nieuwe is geen update server. De ESET software schakelt om naar een voor geprogrammeerde update server om de updates te halen.

2. Op het nieuwe IP adres is wel een update server. De ESET software is intelligent genoeg om te zien dat dit geen legitieme update server is en zal niets downloaden van deze server, waarna de ESET software omschakelt om naar een voor geprogrammeerde update server te gaan om de updates te halen. Zelfs in het geval dat er wel iets gedownload wordt, dan nog loopt de gebruiker geen gevaar. Legitieme downloaded/update paketten hebben verschillende veiligheidsmechanismen ingebouwd. Het missen van deze mechanismen betekent een “rogue update” en de update wordt niet geinstalleerd. De ESET software schakelt om naar een voor geprogrammeerde update server om alsnog de legitieme updates te halen.

Dus in beide scenarios is er niets aan de hand met betrekking tot de updates!

Beetje voorlichting aan de klanten door de internetsecurity-bedrijven over het gebeurde en hoe klanten hun eigen cache kunnen moeten flushen zou geen kwaad kunnen.Immers,niet iedereen heeft evenveel verstand van internet(security) en computers.De meeste mensen zullen niet weten dat ze hun cache moeten flushen,laat staan hoe men dat kan doen.

Wellicht moet je eerst door hebben wat er gebeurd is voordat je zo van de toren blaast!

Het zijn hier niet de security bedrijven die "gehacked" zijn, het is de registrar waar de domeinen geregistreerd staan. Daar hebben de security bedrijven niets mee te maken. Het zijn de registrars die laks met verzoeken tot wijzigingen van de gegevens omgaan.

En ja... Security bedrijven hebben als specialisatie security... Zoals ik eerder al schreef, de updates van ESET liepen gewoon door omdat wij ooit bedacht hebben dat eea zou kunnen gebeuren, buiten onze controle/schuld om. Gewoon een stukje pro-activiteit.

"Vorige week wisten de aanvallers de DNS van Rapid7.com en Metasploit.com te wijzen door een wijzigingsverzoek naar de registrar te faxen." Dit moet toch niet voor kunnen komen zonder verificatie van de klant?

Wij draaien zelf met ESET antivirus en als ik het update mechanisme goed begrijp kan een hacker gewoon een copie
maken van een update server, de DNS namen naar deze server omzetten en dan zal ESET antivirus niks in de gaten
hebben en denken dat er op dat moment gewoon geen update is. Ook niet omschakelen, want die server ziet er goed
uit.
De aanvaller kan dan vervolgens virussen in omloop brengen die door ESET niet herkend worden omdat de klanten geen
updates meer krijgen. Deze situatie duurt minstens enkele dagen, dan komt er wel een rood icoontje om aan te geven
dat er enige tijd geen updates geweest zijn.

Noem het maar "niks aan de hand"...

Ja bovendien is dat helemaal niet voldoende want de meeste mensen zullen gebruik maken van een recursive resolver
van hun provider, en die cached ook. Dus EERST moet DAAR de cache leeg gemaakt worden, en DAN pas moet je
je eigen cache leeg maken, en dan is het pas opgelost.

Toen dit in Nederland speelde (waardoor bijvoorbeeld conrad.nl naar malware verwees) duurde het bijna de volle 24 uur
voor de resolver cache bij XS4ALL geflushed werd (toen het al bijna geen zin meer had). Men was daar niet op de hoogte
van het probleem. Ik neem dus aan dat er vele andere providers zijn waar dit ook niet gedaan was, want XS4ALL is vaak
toch wel wat actiever dan gemiddeld.
En dan was deze hack nog maar beperkt tot 24 uur omdat de hackers zo dom geweest waren om een TTL van 24 uur
in hun trojan DNS server te zetten. Hadden ze daar 1 jaar in gezet dan waren er nu nog steeds mensen die niet bij
conrad.nl kunnen komen.

Bedenk dat er geen mechanisme is waarmee een DNS server kan announcen "alle caches flushen graag". Je bent dus
helemaal afhankelijk van de timeout en eventuele slimmigheden in de resolvers (zoals limiteren van de TTL).

Tenzij ..... (vul maar in)