'Network time protocol is te misbruiken voor aanvallen op https en dnssec'

Onversleuteld verkeer op basis van het network time protocol is te onderscheppen waarna de tijd van clients is aan te passen. Dit gegeven is te misbruiken bij onder andere https-, dnssec- en bitcoin-aanvallen, claimen onderzoekers.

De onderzoekers van Boston University beschrijven de manieren waarop een aanvaller verkeer naar een ntp-server kan onderscheppen en wat de gevolgen kunnen zijn van het aanpassen van de tijden. Het network time protocol of netwerktijdprotocol is een protocol uit 1985 dat voor kloksynchronisatie tussen systemen zorgt. Dat ntp-servers te misbruiken zijn voor ddos-aanvallen was al bekend en ook werd er al op de mogelijkheid van man-in-the-middle-aanvallen gewezen. De onderzoekers hebben nu de verschillende aanvallen en hun implicaties in kaart gebracht.

De beveiliging en correcte werking van veel protocollen en programma's berust op de juistheid van de tijd, beschrijven ze. Sommige applicaties, zoals authenticatiesoftware en bitcoin, kunnen al in de war gestuurd worden bij het verschuiven van de tijd met enkele uren of dagen, terwijl bijvoorbeeld tls-certificaten en dnssec aangevallen kunnen worden door maanden of jaren aan te passen.

"Een ntp-aanvaller die een client terug in de tijd zet, kan ervoor zorgen dat een host certificaten accepteert die een aanvaller frauduleus heeft uitgegeven, maar na die tijd zijn ingetrokken", staat onder andere in het rapport. Door de tijd bij een dns-resolver naar voren te schuiven, kan een ntp-aanval ervoor zorgen dat de cryptografische dnssec-validatie mislukt waardoor de resolver en al zijn clients de verbinding met domeinen die beveiligd zijn met dnssec verliezen.

Door de systeemtijd van een bitcoin-gebruiker aan te passen zou een gedupeerde in theorie een legitiem block van de blockchain af kunnen wijzen. De blocks bevatten namelijk een timestamp en een geldigheidstermijn van ongeveer twee uur, constateren de onderzoekers. Ze wijzen erop dat ntp weliswaar ondersteuning voor cryptografische authenticatie heeft, maar dat deze in de praktijk zelden gebruikt wordt.

Naast zogenoemde on-path-aanvallen waarbij verkeer onderschept wordt, benoemt het rapport ook een off-path-dos-aanval. Hierbij spooft de aanvaller een enkel kiss-of-death-packet van een server: de client stopt dan de queries bij de server en kan zijn lokale klok niet meer bijwerken. De kiss-of-death-packets zijn bedoeld om de load op een ntp-server te verminderen als deze teveel queries ontvangt, maar volgens de onderzoekers zijn deze heel eenvoudig te spoofen.

De universiteit van Boston heeft een pagina online gezet met tips over hoe ntp-servers en -clients te beschermen zijn tegen aanvallen.

Reacties (61)

[Verwijderd]

"Een ntp-aanvaller aanvaller die een client terug in de tijd zet, kan ervoor zorgen dat een host certificaten accepteert die een aanvaller frauduleus heeft uitgegeven, maar na die tijd is ingetrokken", staat onder andere in het rapport.

Erg ver gezocht. Ja het is misbruikbaar maar dan moet deze situatie al bestaan.

Door de systeemtijd van een bitcoin-gebruiker aan te passen zou een gedupeerde in theorie een legitiem block van de blockchain af kunnen wijzen. De blocks bevatten namelijk een timestamp en een geldigheidstermijn van ongeveer twee uur, constateren de onderzoekers.

IMO zuigt Bitcoin al van alle kanten. IMO voor bepaalde mensen de meest overschatte valuta.

[Bor]

"Een ntp-aanvaller aanvaller die een client terug in de tijd zet, kan ervoor zorgen dat een host certificaten accepteert die een aanvaller frauduleus heeft uitgegeven, maar na die tijd is ingetrokken", staat onder andere in het rapport.

Erg ver gezocht. Ja het is misbruikbaar maar dan moet deze situatie al bestaan

Dat is juist helemaal niet ver gezocht. Certificaten verlopen niet voor niets natuurlijk. Dit omdat o.a. soms encryptiestandaarden na verloop van tijd soms toch niet meer zo veilig blijken. Natuurlijk hoort een client die een cerrtificaat krijgt aangeboden ook te kijken of deze niet op een certificate revocation list (crl) staat maar in de praktijk doen lang niet alle systemen dat. Wannneer je niet actief checked op ingetrokken certificaten kun je op deze manier dus een verlopen certificaat geaccepteerd krijgen.

[Wim-Bart]

Misschien kan het op Linux systemen maar Windows systemen zullen tijd niet corrigeren als de delta naar verleden te groot is.

[djwice]

Dus doe je dat in 100 kleine stapjes?

[Wim-Bart]

Onder Windows worden dat wel hele kleine stapjes. Want wanneer Windows tijd heeft gecorrigeerd dan zal het zeker een paar uur duren voordat hij dat weer doet, 100 kleine stapjes zal je ongeveer een week mee bezig zijn

[aadje93]

Als je eenmaal iemand getarged hebt kun je er rustig een paar weken over doen voor je de slag slaat, het hoeft niet gelijk morgen te gebeuren, echter zullen bedrijven (neem ik aan) zelf een "lokale" ntp server draaien *ondergetekende althans wel* die eens per maand even synchroniseert, het gaat hoogstens om een seconde of 2-3 wat ik aan afwijking heb, het hoeft echt niet elke 5 minuten gecontroleerd te worden, de gemiddelde pc doet niet aan atoomfysica

[Wim-Bart]

Meeste bedrijven hebben 1 time source en werken met een piramide voor tijd synchronisatie waarbij je in theorie dus een heel netwerk plat kan leggen door de bron van de piramide te manipuleren. Alleen zit je dan met het issue van bijvoorbeeld hoe tijd synchronisatie in een windows domein werkt, daar zal men heel lang nodig hebben om de tijd te manipuleren.

Ook zijn er voldoende mogelijkheden om een interne atoomklok gebaseerde tijd oplossing neer te zetten waardoor manipulatie vanuit buiten onmogelijk is. Overigens zijn er ook al goedkopere devices die een "reliable" source bieden door gebruik te maken van GPS.

[The_Worst]

Ik kreeg wel eens een foutmelding met de tijdsynchronisatie in Windows dat de afwijking meer was dan 2 uur. Ik moest de tijd handmatig corrigeren, oftewel met een maximale afwijking van 2 uur, voordat de tijd werd gesynchroniseerd.

[aadje93]

Zelf ook ondervonden, een bios die verkeerde tijd gaf, windows kon daardoor geeneens internet verbinding krijgen gezien hij ook die tijd aanhield, alle DNS resolvings failde, pas na lang zoeken kwam ik erachter dat de datum een jaar of 2 verkeerd stond, de tijd klopte exact waardoor het niet direct duidelijk was.

[Verwijderd]

Wannneer je niet actief checked op ingetrokken certificaten kun je op deze manier dus een verlopen certificaat geaccepteerd krijgen.

Sterker nog: meestal staan alleen niet-verlopen certificaten staan op de CRL. Een verlopen certificaat in de CRL laten staan was immers onzinnig. Geen enkele browser die een verlopen certificaat ook nog eens gaat checken met de CRL.

Wellicht dat daar nu tijdelijk verandering in komt, de betreffende RFC staat dit toe, maar dan nog gaat het alleen om certificaten die expliciet zijn ingetrokken en niet om alle verlopen certificaten.

[Armin]

Geen enkele browser die een verlopen certificaat ook nog eens gaat checken met de CRL.

Alleen is het scenario is nu net een verlopen - doch ingetrokken - certifciaat gebruiken in combinatie met een teruggezette systeemtijd. Het certifcaat is dan niet verlopen aldus de client, en dus zal men wel degelijk een revocation check doen.

Certifiaten worden bovendien ook gebruikt voor andere zaken dan authenticatie, denk aan code signing, en dan blijven certifciaten 'geldig' nadat ze verlopen zijn. Een revocation check doen blijft dus nuttig.

[Verwijderd]

[...]


Dat is juist helemaal niet ver gezocht. Certificaten verlopen niet voor niets natuurlijk. Dit omdat o.a. soms encryptiestandaarden na verloop van tijd soms toch niet meer zo veilig blijken. Natuurlijk hoort een client die een cerrtificaat krijgt aangeboden ook te kijken of deze niet op een certificate revocation list (crl) staat maar in de praktijk doen lang niet alle systemen dat. Wannneer je niet actief checked op ingetrokken certificaten kun je op deze manier dus een verlopen certificaat geaccepteerd krijgen.

Het gaat hier volgens het artikel over "frauduleus heeft uitgegeven, maar na die tijd is ingetrokken" certificaten, dus geen verlopen certificaten.

[Verwijderd]

Het is inderdaad een simpele methode helemaal als je fysiek toegang hebt tot een systeem.

[jp]

Als een aanvaller fysiek toegang heeft tot je systemen is het veranderen van de systeemtijd zo'n beetje het kleinste probleem wat je hebt.

[Mithrildor]

DigiNotar vergeten? Het lijkt mij dat dit bijzonder prettig is voor Iran, aangezien ze die ingetrokken certificaten van DigiNotar nu kunnen blijven gebruiken.

[HMS]

DigiNotar is als CA geblacklist, dat is niet tijdsgebonden. Elk certificaat met een DigiNotar signature is niet vertrouwd.

[CAPSLOCK2000]

DigiNotar is als CA geblacklist, dat is niet tijdsgebonden. Elk certificaat met een DigiNotar signature is niet vertrouwd.

Zo'n blacklist werkt alleen voor systemen die een blacklist gebruiken en die ook kunnen bijwerken. Mijn TV heeft geen netwerkaansluiting maar gebruikt wel SSL om de firmware-updates te controleren die ik via USB aanlever. Die TV heeft een ingebouwde lijstje certificaten/CA's en dat is niet meer aan te passen. Dan is het wel prettig dat oude certificaten vanzelf verlopen (al kan het ook een nadeel zijn als je ooit een oude firmware terug wil zetten).

[Armin]

Als de TV echter een beetje fatsoenlijk geprogrameerd was, deed het ook een revocation check via een CRL of OSCP (Staple)

[CAPSLOCK2000]

Klopt, maar helaas zijn er nu eenmaal veel apparaten die het niet goed doen. Zelfs als we die morgen allemaal uit de winkel halen zal het nog jaren duren voor ze allemaal met pensioen zijn.

[roy-t]

Er zijn een hoop nep certificaten die uiteindelijk verworpen zijn. Zo was er een paar jaar terug de geheime sleutel van zo'n certificaat organisatie gestolen waardoor er een hoop certificaten gemaakt kunnen worden die niet van echt te onderscheiden zijn, behalve dan dat ze achteraf zijn ingetrokken.

[Blokker_1999]

Behalve dat het root CA ook is ingetrokken waarschijnlijk, en dat doe je niet ongedaan door de tijd aan te passen.

[Armin]

Er zijn een hoop nep certificaten die uiteindelijk verworpen zijn

Behalve dat intrekken en verlopen twee verschillende zaken zijn. Schoenmaker blijf bij je leest is ook hier van toepassing. Ik denk overigens dat de onderzoekers het wel wisten, maar dat Tweakers het van ArsTechncia overnam, waar deze foute conclusie als eerste geopperd werd. (Geen sneer naar Tweakers overigens.)

De tijd veranderen heeft geen effect op het al dan niet ingetrokken zijn van een certifciaat. Mits je Internet Explorer, Firefox of Opera gebruikt (geen Chrome, iOS of Android) dan wordt bovendien altijd een poging tot certifciaat controle gedaan geheel los van de systeem-tijd.

Meeste wat hier geopperd wordt is al jaren bekend en dus geen nieuws. De onderzoekers hebben wel goed werk gedaan in kwantifceren van de problemen, maar de meeste aanvallen zijn erg lastig uit te voeren en de producten die NTP gebruiken hebben diverse verdedigingsmechanismen.

[roy-t]

Thanks, met je reactie hier snap ik het nu beter!

[FreqAmsterdam]

Absoluut niet ver gezocht. Gezien de hoeveelheid SSL certificaten er in de omloop zijn, en ze om de zoveel tijd vernieuwd moeten worden, zal het vast niet heel moeilijk zijn om een verlopen certificaat te vinden. Dan even misbruik maken van het NTP protocol, en onderscheppen maar.

Het lijkt me een zeer reëel scenario. Je reactie is dan ook een beetje vreemd. Je opmerking over Bitcoins zal ik niet eens op in gaan.

[InsanelyHack]

Hoezo deze situatie al bestaan? FireFox bv heeft een certificatendatabase lokaal en wordt geupdate bij iedere nieuwe versie van de browser. Je kan dus deze database vergelijken en je weet welke certifcaten zijn verlopen en welke dus te misbruiken zijn. Google gebruikt demicrosoft database..

[xFeverr]

Correctie: de Windows versie van chrome gebruikt de database van Windows

[Yuri_MB]

Wat is er volgens jou zo slecht aan bitcoin dan?

[Kain_niaK]

Dat het moeilijk te begrijpen is. Makkelijk om te zeggen dat het zuigt dus, maar moeilijk om dat de onderbouwen.

[Verwijderd]

IMO zuigt Bitcoin al van alle kanten

Nou nou, dat valt ook wel mee

[Firestormer]

Maar als mijn systeemklok langer als een dag achterloopt lukt het mij niet meer om beveiligde verbindingen op te zetten.

Als mijn systeemklok één minuut achterloopt is hetniet meer mogelijk om 2FA uit te voeren.

Met betrekking tot bitcoin: Ok dan kan men een block afwijzen.. so what ?
zolang dit maar niet netwerkbreed gebeurt zie ik geen problemen.

Maar het geeft wel aan dat het Network time protocol door té veel kritieke toepassinge gebruikt wordt en daardoor vaker doelwit gaat worden van aanvallen

Misschien moeten ze alle moederborden maar uitrusten met een atoomklok.

[Verwijderd]

Maar als mijn systeemklok langer als een dag achterloopt lukt het mij niet meer om beveiligde verbindingen op te zetten.

Als mijn systeemklok één minuut achterloopt is hetniet meer mogelijk om 2FA uit te voeren.

Met betrekking tot bitcoin: Ok dan kan men een block afwijzen.. so what ?
zolang dit maar niet netwerkbreed gebeurt zie ik geen problemen.

Maar het geeft wel aan dat het Network time protocol door té veel kritieke toepassinge gebruikt wordt en daardoor vaker doelwit gaat worden van aanvallen

Misschien moeten ze alle moederborden maar uitrusten met een atoomklok.

Mij lijkt het zinvoller om goedkope GPS klokken (ontvangers) te maken. Die de ntp tijd lokaal op je netwerk zetten.
Momenteel zijn deze nog vrij duur.

[francisp]

Er bestaan ook insteekkaarten die de lokale tijd gelijk zetten met de atoomklok via radio. Zelfde systeem als bvb wekkerradio's die je niet moet gelijk zetten als het zomer/winteruur weer eens verspringt.

[Firestormer]

Jah dat is helemaal een prachtig systeem. dan is het écht een fluitje van een cent
om die klokken terug te draaien. dat timing signaal is niet eens gecodeerd.

[Firestormer]

Op zich leuk bedacht.
Maar wat als ik ik deze GPS bakens opvang met een antenne, record en deze op een later tijdstip retransmit ? dan denkt jou pc ook dat het een andere tijd is.
en dan kan ik nog steeds de boel manipuleren.
de hardware om dit te doen kost om en nabij de 50 euro en ligt hier voor mij op mijn bureau.
Dus wellicht een goedkope oplossing maar helaas geen goede oplossing.

[Reactie gewijzigd door Firestormer op 29 juli 2024 01:26]

[Verwijderd]

Op zich leuk bedacht.
Maar wat als ik ik deze GPS bakens opvang met een antenne, record en deze op een later tijdstip retransmit ? dan denkt jou pc ook dat het een andere tijd is.
en dan kan ik nog steeds de boel manipuleren.
de hardware om dit te doen kost om en nabij de 50 euro en ligt hier voor mij op mijn bureau.
Dus wellicht een goedkope oplossing maar helaas geen goede oplossing.

Dan moet je ten eerste zien te achterhalen dat de gene een gps tijd server gebruikt.
Weten waar deze staat. Ik neem aan dat de zender geen flink vermogen heeft.
En weten dat het zinvol is om bij deze persoon of bedrijf zo'n "extreme" actie te ondernemen c.q. kosten baten analyse.

[Firestormer]

Er is natuurlijk altijd een kosten baten analyse.
Maar ik denk dat jij als specialist ook wel wat fysieke locaties kan bedenken.
waar gevoelige data staat opgeslagen.

Of hun gebruik maken van gps Date/Time is makkelijk te achterhalen door gewoon naar die locatie toe te gaan en met een sterk signaal in te stralen. en kijken hoe de servers/services zich anders gaan gedragen.
Gebeurt er niks dan maken ze gebruik van NTP of een ander mechanisme en dat verandert de angle of attack.

Natuurlijk kun je gebruik maken van een combinatie van NTP en GPS echter
de vraag is dan welk mechanisme bij afwijking ten opzichte van elkaar nog vertrouwd kan worden.
(je zou een mechanisme in kunnen bouwen dat kijkt naar de omvang van de afwijking en op basis van dat beslissing maakt)

Als er een atoomklok in de server zou zitten zou dit onmogelijk zijn.
de enige manier die ik dan nog kan bedenken is het manipuleren van fundamentele natuurwetten.

Echter ben ik bang dat mijn kennisniveau daar veel te laag voor is en dan het knoeien met deze fundamentele wetten ook andere atoomklokken kan ontregelen.
Ik denk dat als een atoomklok 5 seconden verspringt er wel overal belletjes gaan rinkelen.

Maar ik ben benieuwd wat jij als counter maatregelen kunt verzinnen

[Macshack]

https://www.schneier.com/...2/08/detecting_spoof.html

[Verwijderd]

Er is natuurlijk altijd een kosten baten analyse.
Maar ik denk dat jij als specialist ook wel wat fysieke locaties kan bedenken.
waar gevoelige data staat opgeslagen.

Of hun gebruik maken van gps Date/Time is makkelijk te achterhalen door gewoon naar die locatie toe te gaan en met een sterk signaal in te stralen. en kijken hoe de servers/services zich anders gaan gedragen.
Gebeurt er niks dan maken ze gebruik van NTP of een ander mechanisme en dat verandert de angle of attack.

Natuurlijk kun je gebruik maken van een combinatie van NTP en GPS echter
de vraag is dan welk mechanisme bij afwijking ten opzichte van elkaar nog vertrouwd kan worden.
(je zou een mechanisme in kunnen bouwen dat kijkt naar de omvang van de afwijking en op basis van dat beslissing maakt)

Zo'n mechanisme zit er al in. NTP heeft er heel veel moeite mee om in het verleden te gaan en zal zich zelf stoppen als de stap in het verleden te groot is. Dit is de orde van minuten.

Als een fatsoenlijke monitoring ingericht hebt zul je direct zien dat ntp het niet meer doet of aan het driften is.

Daarom zul je een stap van maanden of jaren zo goed als onmogelijk zijn binnen een goed gemanagede omgeving.
Daarom is het misbruiken van certificaten in dit geval ook zo goed als uitgesloten.

[Firestormer]

Bedankt voor dat inzicht we gaan er binnenkort bij de vereniging maar eens een beetje mee rommelen. want mijn uitspraken zijn voornamelijk gebaseerd op speculatie

Ik heb de beschreven methoden zelf nog niet getest maar dat gaan we zeker nog doen

[Verwijderd]

Bedankt voor dat inzicht we gaan er binnenkort bij de vereniging maar eens een beetje mee rommelen. want mijn uitspraken zijn voornamelijk gebaseerd op speculatie

Ik heb de beschreven methoden zelf nog niet getest maar dat gaan we zeker nog doen

Mag ik, uit nieuwsgierigheid, vragen om welke vereniging het gaat?

[Bor]

Misschien moeten ze alle moederborden maar uitrusten met een atoomklok.

Dat is totaal niet realistisch op dit moment. Het is erg lastig om een goede atoomklok te maken en hier komen erg veel randvoorwaarden bij kijken zoals een constante temperatuur. Bovendien is een atoomklok veelal erg groot. (dat doet me gelijk denken aan dit artikel: nieuws: Wetenschappers werken aan accurate atoomklok met grootte van Rubiks kubus)

Hiernaast is het niet alleen zaak een heel nauwkeurige tijd te verkrijgen maar vooral dat de systemen dezelfde tijd hanteren. Het is helemaal niet zo heel erg om bv in de tijd achter te lopen zolang alle systemen dat maar allemaal doen. Het NTP protocol is zo geschreven om bijvoorbeeld het tijdsverschil door latency etc zo klein mogelijk te houden. Het hele idee is hierbij dat je allemaal synchroniseert met dezelfde "authoritative" tijdsbron.

[Firestormer]

Vooralsnog heb je gelijk door te zeggen dat dit op DIT moment niet realistisch is.
Maar wij zijn hier niet bezig met wat is. maar met wat nog moet worden.

Als je naar deze kickstarter kijkt is de wil om dit te doen al sterk aanwezig.
https://www.kickstarter.c...mic-wristwatch-the-cesium

De rede dat er nog geen atoomklokken op moederborden zitten is dat daar tot op heden weinig vraag naar is.

De enige manier om te weten wat je doet is door zelf heel precies de tijd bij te houden.
want dat is het enige waar je zeker van kunt zijn. alles buiten de black box is manipuleerbaar.

Dat deze systemen dezelfde tijd hanteren is dan vanzelfsprekend.
en zoniet dan weet je dat er "iets" mis is.
en zouden er in ieder geval geen kritieke beslissingen genomen mogen worden.

[Reactie gewijzigd door Firestormer op 29 juli 2024 01:26]

[Bor]

De rede dat er nog geen atoomklokken op moederborden zitten is dat daar tot op heden weinig vraag naar is.

De reden dat er geen atoomklokken op moederborden zitten is niet alleen dat er geen vraag zou zijn maar ook vooral de omvang en de prijs. Als voorbeeld; het concept uit jouw kickstarter project kost al $6000,- per stuk. Totaal onrealistisch voor een klok op een moederbord waar je ook nog eens te maken hebt met niet ideale omstandigheden in temperatuur en andere invloeden van buitenaf in een afgesloten kast.

Je kunt wel stellen dat we hier niet bezig zijn met wat is maar met wat nog moet komen maar is dat wel zo? De besproken methodes voor misbruik uit dit artikel zijn al te gebruiken; dat is geen toekomstmuziek! Je hebt dus vooral een oplossing nodig die direct voorhanden is.

[Firestormer]

Hoeveel denk je dat die I7 in jou moederbord 15 jaar geleden gekost zou hebben?
En om deze aanvals technieken toe te passen moet je ook over redelijk wat resources beschikken.

zoals kennis, apparatuur en tijd. en ik denk dat je dan wel boven de 6000 dollar uitkomt.
Bovendien zijn er mensen die over meer dan 6000 dollar aan bitcoins beschikken.

Die het er misschien best voor over hebben een eigen atoomklok neer te zetten.

En net zoals dat niet iedereen een kopie van de blockchain heeft. hoeft ook niet iedereen over zo'n klok te beschikken.

Als je niet over waarde beschikt dan heb je ook geen kluis nodig.

[Bor]

Met een setup om een aanval als beschreven in het rapport uit te voeren kun je meer systemen als doel nemen dan een enkel systeem dat een atoomklok zou hebben.

Wat een i7 in het verleden heeft gekost is totaal niet relevant. Zoals ik al zei hebben we nu niets aan een oplossing die over 10+ jaar misschien een keer commodity wordt gezien de aanvallen nu al mogelijk zijn. Je kunt bovendien veel interessantere aanvallen uitvoeren dan alleen een denial of service op bitcoins. Een atoomklok op een moederbord is in de toekomst wellicht een oplossing maar nu nog totaal niet realistisch op grotere schaal. Vooruitkijken is een goede eigenschap maar hou het heden ook in het vizier!

[Blokker_1999]

Dat het niet lukt is omdat je een andere tijd hebt dan de tegenpartij. Wanneer iemand je verbinding wenst te misbruiken dan kunnen ze de klok aan beide kanten gelijk houden.

Een aanval op je bitcoin is nooit leuk, zelfs al zijn de gevolgen niet netwerkbreed, je eigen bitcoins zijn voor jezelf nog altijd het belangrijkste.

[Firestormer]

Er worden wel vaker blocks afgekeurd in het netwerk.
zolang dit niet de meerderheid is zo dit probleem op zichzelf voor de werking van bitcoin nog niet veel uit moeten maken.
het wordt lastiger in een geval van een multi vector attacks .

er moeten dan wel meer verificaties op het desbetreffende block worden uitgevoerd.
En dat kost tijd. wat wel nieuwe mogelijkheden creëert voor de aanvaller. omdat het netwerk dan met andere zaken bezig is ( verifiëren van blocks ipv het stapelen van transacties)

Bitcoin is niet perfect. Maar wel het slimste jongetje van de klas.
(ok ok, er zullen forks zijn met betere security implementaties maar die worden nog door vrijwel niemand gebruikt)

[Niemand_Anders]

Er is geen enkel network protocol afhankelijk van NTP. Wel zijn veel netwerk protocollen afhankelijk van de systeemtijd en die systeemtijd kun je manipuleren met NTP..

Er zijn ook 2FA authenticaties welke niet direct gebruik maken van de systeemtijd zoals de hardware RSA SecurID. Als je de Software SecurID gebruikt, dan ben je wel vatbaar.

Maar het grote gevaar zit niet zozeer bij desktop gebruikers, maar juist een MITM attack bij een data center. Servers draaien vaak dagenlang onbeheerd en juist daar kunnen de gevolgen groot zijn. Daarnaast zullen veel systeembeheerders ook de NTP update meldingen uit de logs filteren omdat er zeer regelmatig kleine aanpassingen worden gedaan. Dus zolang de wijzigingen niet te groot zijn, zullen deze onopgemerkt blijven..

[Firestormer]

Idd in het datacenter is het probleem veel groter.

[CAPSLOCK2000]

Goed dat het onder de aandacht wordt gebracht maar echt nieuw is het niet. Dat dit probleem bestaat weten we al jaren en de meeste NTP servers/clients hebben enige vorm van beveiliging ingebouwd. Al te grote veranderingen worden bijvoorbeeld geweigerd. Een volhoudende aanvaller kan met een heleboel kleine veranderinge hetzelfde gedaan krijgen maar dat duurt (hopelijk) zo lang dat het geen zin heeft.

Ik heb hier toevallig een handleiding van Cisco uit 2008 naast me liggen en daar staan al adviezen in om NTP te beveiligen tegen manipulatie door aanvallers.

The time kept on a machine is a critical resource and it is strongly recommend that you use the security features of NTP to avoid the accidental or malicious setting of incorrect time. The two security features available are an access list-based restriction scheme and an encrypted authentication mechanism.

Het probleem met veel oude protocollen is niet dat ze inherent onveilig zijn, voor de meeste protocollen zijn (inmiddels) ook versies die wel veilig zijn. De meeste beheerders zijn echter niet genoeg met security bezig en maken geen gebruik van de beveiliging. Of dat aan de beheerders ligt of aan hun bazen of klanten laat ik maar even in het midden.

[Yariva]

Idd, documentatie beschrijft dat dit al een tijdje een probleem is. Op examens leer je al dat je door middel van tijd manipulatie tijd gebaseerde ACL's kan ontwijken en certificaten kan misbruiken.

[FreqAmsterdam]

Ik heb nog niet gezocht op Google, maar wellicht dat jij wat meer informatie kunt verstrekken over beveiliging van NTP? Heb je misschien een linkje naar een nuttig document? Ik zou dit graag willen toepassen op servers in mijn beheer.

P.S. sowieso al bedankt voor je post. Geeft me weer stof tot nadenken.

[Reactie gewijzigd door FreqAmsterdam op 29 juli 2024 01:26]

[Yariva]

Even googelen op "securing ntp" wil nog wel is helpen

[FreqAmsterdam]

Uiteraard, maar je vindt veel informatie. Het is dan altijd prettig om iemand te hebben die al wat meer ingewijd is in de materie en je de juiste richting op kan sturen. Niet dat je geen gelijk hebt trouwens haha.

[HMS]

De meeste NTP clients hebben volgens mij een maximum zitten op wat de lokale klok mag afwijken van de referentie klok. Uit mijn hoofd iets van een kwartier. Bij een te grote afwijking moet de sysadmin handmatig de klok corrigeren voordat er gesynchroniseerd kan worden.

Dus ja, het is weer een 'oud' plaintext protocol dat misbruikt kan worden maar hoe groot is de impact nou echt? Krijgen we straks (in navolging van DNS) ook een NTPSEC?

[Blokker_1999]

Als je dan elke 10 minuten een ntp update kan triggeren dan kan je vrij snel alsnog een redelijke afwijking afdwingen. Bijkomend kan 10 minuten al voldoende zijn voor bepaalde aanvallen zoals in de tabel in het artikel te zien is.

[FireDrunk]

Grappige is alleen, dat 99% van de gebruikers permanent een klok in beeld heeft op een PC. Als jij elke 10 minuten de klok terug zet, gaat dat wel opvallen

[Xudonax]

Hoe vaak kijk je nu daadwerkelijk op de klok op je PC? Ik misschien een keer per 1 a 2 uur, echt niett veel vaker. Daar komt dan wel bij dat er hier ook een desktop telefoon staat met klok, dus een afwijking gaat wel opvallen. Maar als ik 1x kijk en het is, zeg, 10 uur volgens de klok, en bij een volgende blik (~2 uur later) zegt het ding pas 10.30 dan is dat vaak best te geloven.

[WhatsappHack]

Het enige probleem is dat dit niet enkel PC's als aanvalsvector heeft.
In het geval van bitcoin bijvoorbeeld hebben de professionele miners allemaal dedicated systemen draaien, en die draaien niet op Windows noch hebben ze een gui.

[zvbhvb]

Vreemd dat de onderzoekers niet opgemerkt hebben dat het ipv6 protocol geen fragmented packets geimplementeerd heeft.Het ipv6 protocol zou aanvals vector 4 onmogelijk maken.

[Verwijderd]

Wel goede artikelen onder de links in de topictekst.