Security Professionals
- ipfw add deny all from eindgebruikers to any
Risico "Authenticator" apps
21-06-2021, 23:47 door Erik van Straten, 40 reacties
Aanleiding
Matthias Deeg van SySS GmbH heeft een "time traveler" kwetsbaarheid gevonden in een "Protectimus SLIM NFC" hardware TOTP token, zie https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2021-007.txt.
TOTP apps
Dat soort aanvallen, waarbij fysieke toegang vereist is en de aanvaller de eerste factor kent, zijn echter ook denkbaar bij TOTP Authenticator apps (zoals van Google en Microsoft, of van derden zoals Authy) - dit voor zover toegang tot zo'n app zelf niet is beveiligd (voor zover ik weet kun je toegang tot de Google Authenticator app niet beveiligen met bijv. een pincode of vingerafdruk). TOTP staat voor Time-based One Time Password.
Time traveler attack
Zo'n "time traveler attack" werkt als volgt:
1) De aanvaller, die gedurende korte tijd de smartphone (of hardware token) in handen heeft en toegang heeft tot apps op jouw smartphone, zet de klok (en eventueel de datum), in de systeeminstellingen, op een gewenst moment in de toekomst;
2) De aanvaller leest de TOTP-code (tweede factor) uit voor de gewenste logon en onthoudt deze (of schrijft deze op);
3) De aanvaller zet de klok weer op de juiste tijd (en/of op automatisch synchroniserend).
Zodra het gekozen tijdstip is aangebroken kan de aanvaller de onthouden (of opgeschreven) tweede factor code gebruiken.
Hoe werkt TOTP
Bij het opzetten van 2FA (MFA) genereert de server een random getal. Dit wordt het zogenaamde shared secret: de server bewaart dit "plain text" (dus onversleuteld en ook geen afgeleide/hash o.i.d.) in het database-record met jouw accountgegevens, en stopt het ook in een QR-code die jij moet scannen met jouw Authenticator app. Ook in die QR-code is dit "shared secret" niet versleuteld, en dus mag zo'n QR-code niet in verkeerde handen vallen.
Authenticatie gaat daarna als volgt:
Een HMAC is effectief een hash van twee "achter elkaar" geplakte parameters (dit gebeurt op een speciale manier om "hash extension attacks" te voorkomen). Meestal wijzigt een TOTP-code elke 30 seconden. Voor het geval dat de klok op de client niet exact gelijkloopt met de klok op de server, is het denkbaar dat de server ook vergelijkt met de zes-cijferige uitkomsten van 30 seconden eerder en 30 seconden later. Of daadwerkelijk de laatste 6 cijfers worden gebruikt weet ik niet, maar voor deze uitleg is dat niet belangrijk (als client en server maar hetzelfde doen).
Uit het "plaatje" kun je afleiden dat een aanvaller toekomstige 6-cijferige codes kan "voorspellen" door de systeemklok van de client vooruit te zetten (de aanvaller hoeft het shared secret dus niet te kennen voor dit type aanval).
Aanvalscenario's
Iemand die jouw smartphone "even leent" kan zo'n aanval uitvoeren. Voorwaarden daarvoor zijn wel:
- dat die aanvaller jouw "eerste factor" kent of kan nabootsen;
- dat die aanvaller toegang heeft tot het ontgrendelde scherm met jouw account en apps;
- dat de TOTP-app(s) op de smartphone zonder pincode of vingerafdruk toegankelijk zijn.
Middels sluwe social engineering kunnen vaak ook mensen, die dit totaal niet van zichzelf verwachten, in een val worden gelokt.
Preventie en andere adviezen
- Leen je smartphone nooit uit (ga in elk geval na welke apps je allemaal hebt waarvan je niet wilt dat een lener daarin kan neuzen of zelfs wijzigen of verzenden namens jou);
- Android: maak een extra account aan dat je selecteert als je je toch verplicht voelt om jouw smartphone uit te lenen (zie ook https://www.security.nl/posting/703662/Add+users+from+lock+screen);
- Met name zonder "uitleenaccount": gebruik zoveel mogelijk apps die je kunt beveiligen tegen openen zonder authenticatie;
- Verlies jouw smartphone niet uit het oog als je deze uitleent (een aanvaller die root weet te worden, kan wellicht ook shared secrets stelen);
- Deel jouw wachtwoorden met niemand;
- Bedenk vooraf wat de risico's zijn als je een smartphone ergens ter reparatie aanbiedt;
- Als een serverdatabase gekopiejat is, vervang dan niet alleen jouw wachtwoord, maar ook eventuele 2FA shared secrets (die staat immers in plain text op de server, terwijl van wachtwoorden meestal een lastiger te "reversen" afgeleide is opgeslagen).
Matthias Deeg van SySS GmbH heeft een "time traveler" kwetsbaarheid gevonden in een "Protectimus SLIM NFC" hardware TOTP token, zie https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2021-007.txt.
TOTP apps
Dat soort aanvallen, waarbij fysieke toegang vereist is en de aanvaller de eerste factor kent, zijn echter ook denkbaar bij TOTP Authenticator apps (zoals van Google en Microsoft, of van derden zoals Authy) - dit voor zover toegang tot zo'n app zelf niet is beveiligd (voor zover ik weet kun je toegang tot de Google Authenticator app niet beveiligen met bijv. een pincode of vingerafdruk). TOTP staat voor Time-based One Time Password.
Time traveler attack
Zo'n "time traveler attack" werkt als volgt:
1) De aanvaller, die gedurende korte tijd de smartphone (of hardware token) in handen heeft en toegang heeft tot apps op jouw smartphone, zet de klok (en eventueel de datum), in de systeeminstellingen, op een gewenst moment in de toekomst;
2) De aanvaller leest de TOTP-code (tweede factor) uit voor de gewenste logon en onthoudt deze (of schrijft deze op);
3) De aanvaller zet de klok weer op de juiste tijd (en/of op automatisch synchroniserend).
Zodra het gekozen tijdstip is aangebroken kan de aanvaller de onthouden (of opgeschreven) tweede factor code gebruiken.
Hoe werkt TOTP
Bij het opzetten van 2FA (MFA) genereert de server een random getal. Dit wordt het zogenaamde shared secret: de server bewaart dit "plain text" (dus onversleuteld en ook geen afgeleide/hash o.i.d.) in het database-record met jouw accountgegevens, en stopt het ook in een QR-code die jij moet scannen met jouw Authenticator app. Ook in die QR-code is dit "shared secret" niet versleuteld, en dus mag zo'n QR-code niet in verkeerde handen vallen.
Authenticatie gaat daarna als volgt:
CLIENT MET AUTHENTICATOR APP SERVER
Shared Secret Shared Secret
| |
v v
Datum + tijd ->[HMAC] [HMAC]<- Datum + tijd
| |
v v
[maak decimaal] [maak decimaal]
| |
v v
[toon laatste 6 cijfers] [neem laatste 6 cijfers]
| |
| v
`--> user voert in ---->[vergelijk]
Shared Secret Shared Secret
| |
v v
Datum + tijd ->[HMAC] [HMAC]<- Datum + tijd
| |
v v
[maak decimaal] [maak decimaal]
| |
v v
[toon laatste 6 cijfers] [neem laatste 6 cijfers]
| |
| v
`--> user voert in ---->[vergelijk]
Een HMAC is effectief een hash van twee "achter elkaar" geplakte parameters (dit gebeurt op een speciale manier om "hash extension attacks" te voorkomen). Meestal wijzigt een TOTP-code elke 30 seconden. Voor het geval dat de klok op de client niet exact gelijkloopt met de klok op de server, is het denkbaar dat de server ook vergelijkt met de zes-cijferige uitkomsten van 30 seconden eerder en 30 seconden later. Of daadwerkelijk de laatste 6 cijfers worden gebruikt weet ik niet, maar voor deze uitleg is dat niet belangrijk (als client en server maar hetzelfde doen).
Uit het "plaatje" kun je afleiden dat een aanvaller toekomstige 6-cijferige codes kan "voorspellen" door de systeemklok van de client vooruit te zetten (de aanvaller hoeft het shared secret dus niet te kennen voor dit type aanval).
Aanvalscenario's
Iemand die jouw smartphone "even leent" kan zo'n aanval uitvoeren. Voorwaarden daarvoor zijn wel:
- dat die aanvaller jouw "eerste factor" kent of kan nabootsen;
- dat die aanvaller toegang heeft tot het ontgrendelde scherm met jouw account en apps;
- dat de TOTP-app(s) op de smartphone zonder pincode of vingerafdruk toegankelijk zijn.
Middels sluwe social engineering kunnen vaak ook mensen, die dit totaal niet van zichzelf verwachten, in een val worden gelokt.
Preventie en andere adviezen
- Leen je smartphone nooit uit (ga in elk geval na welke apps je allemaal hebt waarvan je niet wilt dat een lener daarin kan neuzen of zelfs wijzigen of verzenden namens jou);
- Android: maak een extra account aan dat je selecteert als je je toch verplicht voelt om jouw smartphone uit te lenen (zie ook https://www.security.nl/posting/703662/Add+users+from+lock+screen);
- Met name zonder "uitleenaccount": gebruik zoveel mogelijk apps die je kunt beveiligen tegen openen zonder authenticatie;
- Verlies jouw smartphone niet uit het oog als je deze uitleent (een aanvaller die root weet te worden, kan wellicht ook shared secrets stelen);
- Deel jouw wachtwoorden met niemand;
- Bedenk vooraf wat de risico's zijn als je een smartphone ergens ter reparatie aanbiedt;
- Als een serverdatabase gekopiejat is, vervang dan niet alleen jouw wachtwoord, maar ook eventuele 2FA shared secrets (die staat immers in plain text op de server, terwijl van wachtwoorden meestal een lastiger te "reversen" afgeleide is opgeslagen).
Reacties (40)
22-06-2021, 09:31 door
majortom
Door Erik van Straten:- Als een serverdatabase gekopiejat is, vervang dan niet alleen jouw wachtwoord, maar ook eventuele 2FA shared secrets (die staat immers in plain text op de server, terwijl van wachtwoorden meestal een lastiger te "reversen" afgeleide is opgeslagen).
Het is niet per definitie zo dat deze shared secrets plain in de database staan. Ik hoop dat ze in ieder geval versleuteld opgeslagen zijn in de database of anders in een versleutelde vault terecht zijn gekomen, waarbij in beide gevallen de (master)key in een HSM zit.Toch denk ik wel verstandig om het advies te volgen en ook MFA niet te vergeten bij zo'n hack: je weet immers in veel gevallen niet welke beveiligingsmaatregelen zijn getroffen.
Hoewel uiteraard een extra account zonder apps die gevoelige gegevens bevatten natuurlijk aan te bevelen is, zou het natuurlijk nog beter zijn als de Authenticator app ook wordt beveiligd met een vingerprint/code bij openen. Of in ieder geval dat de mogelijk daar is om dat te doen. Want bij actief uitlenen, kun je een ander account selecteren. Maar als iemand ongevraagd je telefoon even "leent" die nog unlocked naast je ligt, is dat een ander verhaal.
Daarom zijn push authenticaties veel veiliger.
Of apps zoals DigiD doet, waarbij je eerst een code in de app moet invoeren.
Of apps zoals DigiD doet, waarbij je eerst een code in de app moet invoeren.
Hoezoo "Time traveler attack" kwetsbaarheid ?
De betere leverancier vertelt dit risico bij aanvang van de instructies aan beheerders.
Bij een pentest werd dit risico al in 2014 meegenomen en erover gerapporteerd.
Dit risico is een acceptatiecriterium!
De betere leverancier vertelt dit risico bij aanvang van de instructies aan beheerders.
Bij een pentest werd dit risico al in 2014 meegenomen en erover gerapporteerd.
Dit risico is een acceptatiecriterium!
Op een beetje systeem kan een gebruiker niet de klok aanpassen.
In dit geval zou een telefoon het aanpassen van de klok als een elevated-security setting moeten behandelen, dus moeten
vragen om de ontgrendelcode of vingerafdruk oid, zoals bij wel meer settings het geval is.
Geen idee waarom dat niet gedaan wordt.
In dit geval zou een telefoon het aanpassen van de klok als een elevated-security setting moeten behandelen, dus moeten
vragen om de ontgrendelcode of vingerafdruk oid, zoals bij wel meer settings het geval is.
Geen idee waarom dat niet gedaan wordt.
22-06-2021, 12:44 door
Erik van Straten
Door majortom: Ik hoop dat ze in ieder geval versleuteld opgeslagen zijn in de database of anders in een versleutelde vault terecht zijn gekomen, waarbij in beide gevallen de (master)key in een HSM zit.
Dat zou goed zijn, maar nog veel beter zou het zijn als wachtwoorden (ten minste plus salt, bij voorkeur plus pepper) versleuteld zouden worden opgeslagen (immers veel mensen hergebruiken wachtwoorden voor meerdere accounts, terwijl die TOTP shared secrets random gegenereerd zijn). Maar ik kan mij niet herinneren ooit na een account-DB datalek gelezen te hebben dat de gekopiejatte wachtwoord-afgeleiden onomkeerbaar versleuteld waren - vaak zal dit dus niet gebeuren. De kans dat dit dan wel wordt gedaan voor TOTP shared secrets lijkt mij -helaas- erg klein.Door Anoniem: Hoewel uiteraard een extra account zonder apps die gevoelige gegevens bevatten natuurlijk aan te bevelen is, zou het natuurlijk nog beter zijn als de Authenticator app ook wordt beveiligd met een vingerprint/code bij openen. Of in ieder geval dat de mogelijk daar is om dat te doen. Want bij actief uitlenen, kun je een ander account selecteren. Maar als iemand ongevraagd je telefoon even "leent" die nog unlocked naast je ligt, is dat een ander verhaal.
Juist dan is het van belang dat de "lener" zo min mogelijk kan met jouw smartphone. Dus verdient een toegangsbeveiligde TOTP-app de voorkeur.Door Anoniem: Hoezoo "Time traveler attack" kwetsbaarheid ?
De betere leverancier vertelt dit risico bij aanvang van de instructies aan beheerders.
Ik weet niet welke beheerders je bedoelt, maar identiteitsfraude betekent meestal een risico voor eindgebruikers.De betere leverancier vertelt dit risico bij aanvang van de instructies aan beheerders.
Door Anoniem: Op een beetje systeem kan een gebruiker niet de klok aanpassen.
In dit geval zou een telefoon het aanpassen van de klok als een elevated-security setting moeten behandelen, dus moeten
vragen om de ontgrendelcode of vingerafdruk oid, zoals bij wel meer settings het geval is.
Geen idee waarom dat niet gedaan wordt.
Op mijn OnePlus 6 smartphone kan ik zelfs vanuit het Guest-account (zonder unlock-screen wachtwoord) de systeem datum en tijd wijzigen; best bizar dat dit kan. Door vanuit zo'n account bijv. de datum te wijzigen zijn wellicht ook andere aanvallen denkbaar op de hoofdgebruiker (als Guest of vanuit een ander account heb je geen toegang tot TOTP-apps van de hoofdgebruiker).In dit geval zou een telefoon het aanpassen van de klok als een elevated-security setting moeten behandelen, dus moeten
vragen om de ontgrendelcode of vingerafdruk oid, zoals bij wel meer settings het geval is.
Geen idee waarom dat niet gedaan wordt.
Door Erik van Straten:
Op mijn OnePlus 6 smartphone kan ik zelfs vanuit het Guest-account (zonder unlock-screen wachtwoord) de systeem datum en tijd wijzigen; best bizar dat dit kan. Door vanuit zo'n account bijv. de datum te wijzigen zijn wellicht ook andere aanvallen denkbaar op de hoofdgebruiker (als Guest of vanuit een ander account heb je geen toegang tot TOTP-apps van de hoofdgebruiker).
Nou dat is helemaal slecht ja!Op mijn OnePlus 6 smartphone kan ik zelfs vanuit het Guest-account (zonder unlock-screen wachtwoord) de systeem datum en tijd wijzigen; best bizar dat dit kan. Door vanuit zo'n account bijv. de datum te wijzigen zijn wellicht ook andere aanvallen denkbaar op de hoofdgebruiker (als Guest of vanuit een ander account heb je geen toegang tot TOTP-apps van de hoofdgebruiker).
Op een dergelijk platform zou een app die een betrouwbare tijd nodig heeft (zoals TOTP apps) geen gebruik mogen maken
van de systeem tijd, maar deze zelf moeten opvragen via NTP, liefst encrypted NTP bij een eigen server waarvan de
encryptiekeys bekend zijn.
Eigenlijk zou de systeemklok altijd gesynchroniseerd moeten zijn en als de gebruiker zelf de tijd aanpast zou alleen een
offset moeten worden bijgehouden zodat de getoonde systeemtijd aangepast kan worden als gebruikers dit nou zo graag
willen, maar er ook altijd een betrouwbare UTC tijd in het systeem beschikbaar is waar je niet zomaar mee kunt rommelen.
Deze kan gesynchroniseerd worden met GPS als dat in de telefoon zit, met internet via NTP, etc.
22-06-2021, 14:33 door
Briolet
Door Anoniem: Eigenlijk zou de systeemklok altijd gesynchroniseerd moeten zijn en als de gebruiker zelf de tijd aanpast zou alleen een offset moeten worden bijgehouden zodat de getoonde systeemtijd aangepast kan worden als gebruikers dit nou zo graag
willen, maar er ook altijd een betrouwbare UTC tijd in het systeem beschikbaar is waar je niet zomaar mee kunt rommelen.
willen, maar er ook altijd een betrouwbare UTC tijd in het systeem beschikbaar is waar je niet zomaar mee kunt rommelen.
Mijn eerste Android device was uit 2011. Toen gebruikte Android geen NTP server en de tijd ging dan ook na verloop afwijken. Volgens mij iets van een seconde per dag. Ik had er wel een app op staan die de tijd via een NTP server liet zien, maar Android had wel een beveiliging dat de tijd niet door een app aangepast kon worden. Je moest dan handmatig steeds de tijd aanpassen aan die van de tijdserver.
Ik gebruikte met dat tablet ook al een TOTP app. En regelmatig faalde die en moest je eerst weer de systeemtijd aanpassen. Dat was toen een Android versie die voor de telefoon bedoeld was en waarschijnlijk synchroniseerde hij alleen via G3/G4 netwerken. Maar in het tablet zat geen telefoonkaart.
Door Erik van Straten:
- dat die aanvaller toegang heeft tot het ontgrendelde scherm met jouw account en apps;
- dat de TOTP-app(s) op de smartphone zonder pincode of vingerafdruk toegankelijk zijn.
- dat die aanvaller toegang heeft tot het ontgrendelde scherm met jouw account en apps;
- dat de TOTP-app(s) op de smartphone zonder pincode of vingerafdruk toegankelijk zijn.
Dank je Erik, voor je inhoudelijk waardevolle bijdragen. Voor wie het nog niet weet: er bestaan zogeheten app lockers. Maak daar goed gebruik van, zeker in het geval van DigiD, Authy en uw bank app. Eén van de betere commerciële oplossingen is G Data Mobile Security (www.gdata.nl), maar een gratis AppLocker van F-Droid is ook prima:
https://search.f-droid.org/?q=locker
Door Erik van Straten: Middels sluwe social engineering kunnen vaak ook mensen, die dit totaal niet van zichzelf verwachten, in een val worden gelokt.
Onderschat het niet. Vaak overschatten ICTer hun eigen kunde. Als ze niet door hebben dat ze in sociaal inzicht tekort schieten dan trappen ze er zo met ogen open in. Dit vergt mensenkennis, eerder dan technisch inzicht. Als je je daar als ICT expert of brave burger beter tegen wilt kunnen wapenen, dan ben je flink wat hoofdstukken aan zelfstudie zoet:
https://en.wikipedia.org/wiki/Social_engineering_(security)
1 Information security culture
2 Techniques and terms
2.1 Six key principles
2.1.1 Authority/Trust
2.1.2 Intimidation
2.1.3 Consensus/Social proof
2.1.4 Scarcity
2.1.5 Urgency
2.1.6 Familiarity / Liking
2.2 Four social engineering vectors
2.2.1 Vishing
2.2.2 Phishing
2.2.3 Smishing
2.2.4 Impersonation
3 Other concepts
3.1 Pretexting
3.2 Vishing
3.3 Spear phishing
3.4 Water holing
3.5 Baiting
3.6 Quid pro quo
3.7 Tailgating
3.8 Other types
3.9 Countermeasures
4 The lifecycle of social engineering
2 Techniques and terms
2.1 Six key principles
2.1.1 Authority/Trust
2.1.2 Intimidation
2.1.3 Consensus/Social proof
2.1.4 Scarcity
2.1.5 Urgency
2.1.6 Familiarity / Liking
2.2 Four social engineering vectors
2.2.1 Vishing
2.2.2 Phishing
2.2.3 Smishing
2.2.4 Impersonation
3 Other concepts
3.1 Pretexting
3.2 Vishing
3.3 Spear phishing
3.4 Water holing
3.5 Baiting
3.6 Quid pro quo
3.7 Tailgating
3.8 Other types
3.9 Countermeasures
4 The lifecycle of social engineering
https://en.wikipedia.org/wiki/Social_engineering_(security)
Door Anoniem: Voor wie het nog niet weet: er bestaan zogeheten app lockers. Maak daar goed gebruik van, zeker in het geval van DigiD, Authy en uw bank app.
Met alle respect, maar voegen dat soort apps echt wat toe?Als ik Android goed genoeg begrijp moeten apps elkaar onderling niet zomaar kunnen beïnvloeden. Ik kan me voorstellen dat zo'n app verhindert dat je een beschermde app via diens "snelkoppeling" zomaar kunt starten, maar een app starten kan op meer manieren (via de play store, instellingen of met third party apps zoals Total Commander).
Bovendien moet jij zelf zo'n AppLock app kunnen verwijderen, ook als je het wachtwoord daarvan vergeten bent of als je vingerafdruk niet meer werkt bijv. na klussen met cement. Killen van zo'n app behoort waarschijnlijk ook tot de mogelijkheden om deze te bypassen. Op Internet zoeken naar Android AppLock bypass levert veel tips op.
Zolang zoiets geen standaard functionaliteit is van Android zou ik alleen vertrouwen op in apps zelf ingebouwde functionaliteit. Ik heb het niet getest maar meen gelezen te hebben dat je zowel Authy als Microsoft Authenticator kunt "dichtzetten" met vingerafdruk of pincode. Authy verzamelt echter gegevens van je in de USA (https://www.twilio.com/legal/privacy/authy) en Microsoft doet dat hoogstwaarschijnlijk ook; dit zijn ten slotte commerciële bedrijven. Google doet dat ook natuurlijk, maar daar zit je sowieso aan vast als je Android zo veilig mogelijk wilt gebruiken (en dus Play Store Services aan hebt staan).
Na het bovenstaande geschreven te hebben, bedacht ik me dat ik wel eens zoiets gezien heb op m'n OnePlus 6 smartphone. Inderdaad! Onder "settings > Utilities" staat "App locker".
Als test heb ik daar Google Authenticator aan toegevoegd (elke wijziging van Applocker-instellingen vereist het invoeren van mijn account wachtwoord, prima). Inderdaad moet ik nu mijn vingerafdruk scannen als ik Google Authenticator start, zelfs als ik dat doe vanuit Total Commander! Eerst leek het erop dat als ik een "Force stop" doe van die "App locker" (in "settings > Apps & notifications > See all nn apps > drie verticale puntjes > show system > applocker > Force stop") dat ik Google Authenticator weer kan starten zonder vingerafdruk (voor het uitvoeren van zo'n "Force stop" hoef ik geen wachtwoord in te voeren of vingerafdruk te scannen) maar dat lijkt niet juist: dat ik dit dacht kwam door de volgende bug.
Security-bug: alleen bij de eerste keer (na "inloggen", unlock screen dus) starten van Google Authenticator moet ik mijn vingerafdruk scannen; bij elke volgende keer Google Authenticator opstarten hoeft dat niet meer! En dit gedrag is niet specifiek voor Google Authenticator, ook bij Calculator gaat het er zo aan toe.
Schijnveiligheid dus wat mij betreft, in elk geval van deze met OxygenOS meegeleverde "App locker" app. Ik ben benieuwd of andere "App locker" apps het er veel beter vanaf brengen...
Aanvulling, nog een security bugje: als je in de instellingen van App locker zit en deze pagina niet sluit maar met het vierkante knopje rechtsonder naar een andere app overschakelt, kun je door terug te schakelen naar die instellingenpagina van App locker settings wijzigen zonder een wachtwoord in te hoeven voeren (zoals beschermde apps verwijderen). Dit is ook het geval als je tussendoor uit- en weer inlogt.
Door Erik van Straten: ... Ik heb het niet getest maar meen gelezen te hebben dat je zowel Authy als Microsoft Authenticator kunt "dichtzetten" met vingerafdruk of pincode. Authy verzamelt echter gegevens van je in de USA (https://www.twilio.com/legal/privacy/authy) en Microsoft doet dat hoogstwaarschijnlijk ook; dit zijn ten slotte commerciële bedrijven. ...
Ja (Authy heeft pincode) en (Authy) 'verzamelen' gegevens alleen ter ondersteuning v.d. beveiliging, niet voor commerciële doeleinden (lees tekst achter jouw link). Microsoft is zonder meer niét te vertrouwen in dit soort zaken.
Door Toje Fos:
Ja (Authy heeft pincode) en (Authy) 'verzamelen' gegevens alleen ter ondersteuning v.d. beveiliging, niet voor commerciële doeleinden (lees tekst achter jouw link). Microsoft is zonder meer niét te vertrouwen in dit soort zaken.
Aan dit soort beweringen hebben we helemaal NIKS.Ja (Authy heeft pincode) en (Authy) 'verzamelen' gegevens alleen ter ondersteuning v.d. beveiliging, niet voor commerciële doeleinden (lees tekst achter jouw link). Microsoft is zonder meer niét te vertrouwen in dit soort zaken.
"mijn favoriete bedrijf" is hardstikke lief en doet goede dingen, "dat andere bedrijf" is evil en niet te vertrouwen.
Maar een jaar later zijn de rollen omgekeerd, dus beter maar niet dat soort dingen stellen.
23-06-2021, 22:43 door
Erik van Straten
Door Anoniem: Voor wie het nog niet weet: er bestaan zogeheten app lockers. Maak daar goed gebruik van, zeker in het geval van DigiD, Authy en uw bank app.
Bij nader inzien: bedankt voor de tip!Ik ga de "App locker" van Oneplus voorlopig gebruiken en heb alle mogelijke apps ermee beveiligd (maar eens kijken hoe irritant dit is en of ik tegen nog meer issues aanloop). De drie grootste nadelen/risico's, die ik tot nu toe ken, zijn:
1) Zodra een app "unlocked" is moet ik m'n screen locken om die app (na screen unlock) weer locked te krijgen. Dit is nauwelijks een probleem, want mijn smartphone is zo ingesteld dat het uitzetten van het scherm meteen een locked screen betekent;
2) Ik moet erom denken om de instellingen niet in de pagina met "App locker" settings te laten staan (want dan heb je geen wachtwoord nodig om de beveiliging van apps af te kunnen halen);
3) Voor een aantal apps werkt "App locker" niet of niet altijd. Met bijv. de camera-app beveiligd, kun je nog steeds (zonder enige vorm van authenticatie) foto's nemen vanaf een locked scherm. En als ik mijn smartphone uit zou lenen zodat iemand anders ermee kan bellen, dan kan die persoon mijn contacten zien (maar geen details ervan, en editten kan ook niet).
In elk geval lijkt mij dit handig voor Google Authenticator (die ik zelden gebruik), en voor een bank-app (die ook een pincode vereist). Doordat m'n webbrowsers nu ook beveiligd zijn kan iemand, als ik nog ingelogd ben op security.nl of tweakers.net, niet zomaar namens mij berichten posten (of, vooral op tweakers, oude berichten wijzigen). Ik gebruik mijn gmail account niet, maar een mail-app als Gmail beveiligd met een vingerafdruk maakt het een dief van mijn smartphone wellicht iets lastiger (mochten zij een screenlock bypass kennen) om namens mij te e-mailen.
Kortom, deze beveiliging is verre van perfect (vooral voor gebruikers die de gebreken niet kennen), maar ik ga er maar eens een tijdje mee spelen.
Er zijn open-source oplossingen zoals AndOTP. Daar zit geen commercieel bedrijf achter.
Daarnaast slaat de app alles encrypted op + pincode/wachtwoord
Zoek niet naar het bekende maar naar het onbekende
Groeten,
meiner
Daarnaast slaat de app alles encrypted op + pincode/wachtwoord
Zoek niet naar het bekende maar naar het onbekende
Groeten,
meiner
De aanvaller, die gedurende korte tijd de smartphone (of hardware token) in handen heeft
Tja, in dat geval kan de aanvaller ook per direkt inloggen. Voordeel is dat de meeste threat actors nimmer je hardware token in handen hebben.
24-06-2021, 12:12 door
Erik van Straten
Door Anoniem:
Tja, in dat geval kan de aanvaller ook per direkt inloggen. Voordeel is dat de meeste threat actors nimmer je hardware token in handen hebben.
Ik heb, toen ik nog consultancy-klussen deed, vaak sleutelbossen met hardware-tokens op bureau's (ook flexplekken waar lang niet iedereen elkaar kent) zien slingeren terwijl de eigenaar niet op diens plek zat (lunch, meeting, toilet, roken etc). Na schoudersurfen voor het wachtwoord (of eerder een keylogger te hebben geïnstalleerd), heb je maar weinig tijd nodig om zo'n toekomstige TOTP-code te achterhalen. Dat is veel minder opvallend dan zo'n token stelen of er direct (ter plaatse) mee inloggen.De aanvaller, die gedurende korte tijd de smartphone (of hardware token) in handen heeft
Tja, in dat geval kan de aanvaller ook per direkt inloggen. Voordeel is dat de meeste threat actors nimmer je hardware token in handen hebben.
Is dit een groot risico? Nee, want de kans is klein (het gebeurt natuurlijk niet vaak). Maar kun je zoiets uitsluiten? Nee. En de impact zal vaak groot zijn, je hebt immers niet voor niets 2FA met een hardware-token.
Overigens zou een smartphone met TOTP-app wel eens veiliger kunnen zijn dan zo'n hardware-token, want de meeste mensen sjouwen hun smartphone overal mee naartoe - waardoor de kans dat zij deze ergens vergeten waarschijnlijk kleiner is dan een hardware-token (vooral het type USB dat men in een PC kan laten zitten). Bovendien zijn smartphones van enigszins security-aware eigenaren voorzien van schermvergrendeling (toegegeven niet altijd sterk, maar het kan toch tijdrovend zijn om die te doorbreken). Het risico dat een aanvaller zo'n hardware-token vervangt door eentje die er hetzelfde uitziet en de eigenaar die verwisseling pas opmerkt bij de volgende keer inloggen (en dan wellicht eerst aan een defect denkt), lijkt me ook veel groter dan het risico dat een verwisselde smartphone niet heel snel ontdekt wordt.
Door Erik van Straten:
Door Anoniem: Voor wie het nog niet weet: er bestaan zogeheten app lockers. Maak daar goed gebruik van, zeker in het geval van DigiD, Authy en uw bank app.
Bij nader inzien: bedankt voor de tip!Graag gedaan :-)
Door Erik van Straten: Voor een aantal apps werkt "App locker" niet of niet altijd. Met bijv. de camera-app beveiligd, kun je nog steeds (zonder enige vorm van authenticatie) foto's nemen vanaf een locked scherm. En als ik mijn smartphone uit zou lenen zodat iemand anders ermee kan bellen, dan kan die persoon mijn contacten zien (maar geen details ervan, en editten kan ook niet).
Omdat men het alarmnummer 112 altijd moet kunnen bellen, wordt het niet toegestaan dat de Telefoon functie met een app locker wordt geblokkeerd. De Camera app kan op de herkenning van iemands gezicht zijn ingesteld. Als de eigenaar in nood is, dan mag die persoon niet worden buitengesloten door ook nog een extra app locker.
Het is al moeilijk genoeg om onder extreme stress een PIN-code of swipe patroon juist in te voeren. Probeer dat na een zware sport exercitie maar eens met 180 hartslagen per minuut. Daar is de Emergency of Noodgeval functie voor, zonder PIN-code. De vraag of iemand in doodsangst het zich nog herinnert dat die functie bestaat, is vers twee.
De app van de Contacten lijst is vaak ook niet met een app locker te blokkeren, omdat iemand in nood, of de hulpverlener, anders kan worden buitengesloten van ingestelde SOS nummers (dus geen 112, maar de familie, thuiszorg, etc.). Hetzelfde geldt voor het de te tonen 'Informatie bij nood'. Er zijn dus een paar apps die je beter niet kunt blokkeren.
Door Erik van Straten:
Overigens zou een smartphone met TOTP-app wel eens veiliger kunnen zijn dan zo'n hardware-token, want de meeste mensen sjouwen hun smartphone overal mee naartoe - waardoor de kans dat zij deze ergens vergeten waarschijnlijk kleiner is dan een hardware-token (vooral het type USB dat men in een PC kan laten zitten).
Dit was bij ons in ieder geval wel een belangrijke overweging om de hardware tokens (die dedicated sleutelhanger dingen) uit te faseren! Niet alleen werden die dingen voortdurend vergeten (wat met de smartphone bijna nooit gebeurt) maar ook raakten ze zoek en werden ze uitgeleend aan collega's die thuis wilden werken oid.Overigens zou een smartphone met TOTP-app wel eens veiliger kunnen zijn dan zo'n hardware-token, want de meeste mensen sjouwen hun smartphone overal mee naartoe - waardoor de kans dat zij deze ergens vergeten waarschijnlijk kleiner is dan een hardware-token (vooral het type USB dat men in een PC kan laten zitten).
En nu hebben we helemaal geen TOTP meer, de verificatie gebeurt nu via een telefoontje. Wij zijn niet zo bang voor geheime diensten die lokale GSM masten neerzetten en de boel om de tuin leiden, en dat soort scenario's die vast ooit wel ergens zijn voorgekomen maar in de praktijk geen probleem zijn.
Door Anoniem:
Omdat men het alarmnummer 112 altijd moet kunnen bellen, wordt het niet toegestaan dat de Telefoon functie met een app locker wordt geblokkeerd. De Camera app kan op de herkenning van iemands gezicht zijn ingesteld.
Je hoeft je smartphone helemaal niet te unlocken om 112 te kunnen bellen. Daar heb je de camera dus niet voor nodig (noch vingerafdruk, pincode, wachtwoord of veegpatroon).Door Erik van Straten: Voor een aantal apps werkt "App locker" niet of niet altijd. Met bijv. de camera-app beveiligd, kun je nog steeds (zonder enige vorm van authenticatie) foto's nemen vanaf een locked scherm. En als ik mijn smartphone uit zou lenen zodat iemand anders ermee kan bellen, dan kan die persoon mijn contacten zien (maar geen details ervan, en editten kan ook niet).
Omdat men het alarmnummer 112 altijd moet kunnen bellen, wordt het niet toegestaan dat de Telefoon functie met een app locker wordt geblokkeerd. De Camera app kan op de herkenning van iemands gezicht zijn ingesteld.
Elke app die vanaf een vergrendeld scherm beschikbaar is, vergroot het aanvalsoppervlak enorm. Daarom zou ik de camara-app op het locked screen willen kunnen disablen.
25-06-2021, 09:30 door
Erik van Straten
Door Anoniem:
Ik vrees inderdaad dat dit soort dongles/hardware-tokens niet de o.a. door de FIDO gedroomde oplossing zijn. Uit https://www.theregister.com/2021/06/24/wouldbe_passwordkiller_fido_alliance_aims/:Door Erik van Straten:
Overigens zou een smartphone met TOTP-app wel eens veiliger kunnen zijn dan zo'n hardware-token, want de meeste mensen sjouwen hun smartphone overal mee naartoe - waardoor de kans dat zij deze ergens vergeten waarschijnlijk kleiner is dan een hardware-token (vooral het type USB dat men in een PC kan laten zitten).
Dit was bij ons in ieder geval wel een belangrijke overweging om de hardware tokens (die dedicated sleutelhanger dingen) uit te faseren! Niet alleen werden die dingen voortdurend vergeten (wat met de smartphone bijna nooit gebeurt) maar ook raakten ze zoek en werden ze uitgeleend aan collega's die thuis wilden werken oid.Overigens zou een smartphone met TOTP-app wel eens veiliger kunnen zijn dan zo'n hardware-token, want de meeste mensen sjouwen hun smartphone overal mee naartoe - waardoor de kans dat zij deze ergens vergeten waarschijnlijk kleiner is dan een hardware-token (vooral het type USB dat men in een PC kan laten zitten).
Would-be password-killer FIDO Alliance aims to boost uptake with new UX guidelines
Throws a bone to complex enterprise deployment, too
Gareth Halfacree Thu 24 Jun 2021 // 20:30 UTC
[...]
"While FIDO definitely does provide a simpler, stronger approach to user authentication, there is still a need to get users more accustomed to the user experience – and to optimise these flows as much as possible," FIDO Alliance executive director Andrew Shikiar admitted.
[...]
"Unfortunately we are in desperate need of phishing-resistant and privacy-enhancing sign-in experiences as threat actors become better at targeting their prey," ESET UK cybersecurity expert Jake Moore told The Register.
[...]
Throws a bone to complex enterprise deployment, too
Gareth Halfacree Thu 24 Jun 2021 // 20:30 UTC
[...]
"While FIDO definitely does provide a simpler, stronger approach to user authentication, there is still a need to get users more accustomed to the user experience – and to optimise these flows as much as possible," FIDO Alliance executive director Andrew Shikiar admitted.
[...]
"Unfortunately we are in desperate need of phishing-resistant and privacy-enhancing sign-in experiences as threat actors become better at targeting their prey," ESET UK cybersecurity expert Jake Moore told The Register.
[...]
Door Anoniem:
Door Erik van Straten:
Overigens zou een smartphone met TOTP-app wel eens veiliger kunnen zijn dan zo'n hardware-token, want de meeste mensen sjouwen hun smartphone overal mee naartoe - waardoor de kans dat zij deze ergens vergeten waarschijnlijk kleiner is dan een hardware-token (vooral het type USB dat men in een PC kan laten zitten).
Dit was bij ons in ieder geval wel een belangrijke overweging om de hardware tokens (die dedicated sleutelhanger dingen) uit te faseren! Niet alleen werden die dingen voortdurend vergeten (wat met de smartphone bijna nooit gebeurt) maar ook raakten ze zoek en werden ze uitgeleend aan collega's die thuis wilden werken oid.Overigens zou een smartphone met TOTP-app wel eens veiliger kunnen zijn dan zo'n hardware-token, want de meeste mensen sjouwen hun smartphone overal mee naartoe - waardoor de kans dat zij deze ergens vergeten waarschijnlijk kleiner is dan een hardware-token (vooral het type USB dat men in een PC kan laten zitten).
Er zijn veel instanties en ondernemingen waar men de USB-tokens van de bewaking bij de receptie 's ochtend bij de aanmelding ontvangt, waarna men die 's middags of na het einde van de dienst weer moet inleveren. Een kleine moeite. Men kan de USB-tokens van een ID-sleutelhanger met een tracker voorzien. Het komt op het ICT security beleid aan.
En nu hebben we helemaal geen TOTP meer, de verificatie gebeurt nu via een telefoontje. Wij zijn niet zo bang voor geheime diensten die lokale GSM masten neerzetten en de boel om de tuin leiden, en dat soort scenario's die vast ooit wel ergens zijn voorgekomen maar in de praktijk geen probleem zijn.
De mobiele telefoonie is zo lek als een mand. Gebruik maken van een Android mobieltje met een TOTP-app is vragen om moeilijkheden, zeker als die ook voor privédoeleinden wordt gebruikt, Eerst een telefoontje plegen? Een gesproken stem kan tegenwoordig met kunstmatige intelligentie realistisch worden nagebootst.
Door Anoniem:
Er zijn veel instanties en ondernemingen waar men de USB-tokens van de bewaking bij de receptie 's ochtend bij de aanmelding ontvangt, waarna men die 's middags of na het einde van de dienst weer moet inleveren. Een kleine moeite. Men kan de USB-tokens van een ID-sleutelhanger met een tracker voorzien. Het komt op het ICT security beleid aan.
Door Anoniem:
Door Erik van Straten:
Overigens zou een smartphone met TOTP-app wel eens veiliger kunnen zijn dan zo'n hardware-token, want de meeste mensen sjouwen hun smartphone overal mee naartoe - waardoor de kans dat zij deze ergens vergeten waarschijnlijk kleiner is dan een hardware-token (vooral het type USB dat men in een PC kan laten zitten).
Dit was bij ons in ieder geval wel een belangrijke overweging om de hardware tokens (die dedicated sleutelhanger dingen) uit te faseren! Niet alleen werden die dingen voortdurend vergeten (wat met de smartphone bijna nooit gebeurt) maar ook raakten ze zoek en werden ze uitgeleend aan collega's die thuis wilden werken oid.Overigens zou een smartphone met TOTP-app wel eens veiliger kunnen zijn dan zo'n hardware-token, want de meeste mensen sjouwen hun smartphone overal mee naartoe - waardoor de kans dat zij deze ergens vergeten waarschijnlijk kleiner is dan een hardware-token (vooral het type USB dat men in een PC kan laten zitten).
Er zijn veel instanties en ondernemingen waar men de USB-tokens van de bewaking bij de receptie 's ochtend bij de aanmelding ontvangt, waarna men die 's middags of na het einde van de dienst weer moet inleveren. Een kleine moeite. Men kan de USB-tokens van een ID-sleutelhanger met een tracker voorzien. Het komt op het ICT security beleid aan.
En hoe moeten de mensen dan thuiswerken? Niet erg praktisch lijkt me.
En nu hebben we helemaal geen TOTP meer, de verificatie gebeurt nu via een telefoontje. Wij zijn niet zo bang voor geheime diensten die lokale GSM masten neerzetten en de boel om de tuin leiden, en dat soort scenario's die vast ooit wel ergens zijn voorgekomen maar in de praktijk geen probleem zijn.
De mobiele telefoonie is zo lek als een mand. Gebruik maken van een Android mobieltje met een TOTP-app is vragen om moeilijkheden, zeker als die ook voor privédoeleinden wordt gebruikt, Eerst een telefoontje plegen? Een gesproken stem kan tegenwoordig met kunstmatige intelligentie realistisch worden nagebootst.
Het is een automatisch systeem, je wordt gebeld op het van jou bekende nummer en je moet een pincode intoetsen gevolgd door een #.
Ik weet het, het bulkt hier van de doemdenkers die denken dat dat makkelijk te hacken is, maar ik denk dat dit in de praktijk hard meevalt.
Door Anoniem: En hoe moeten de mensen dan thuiswerken? Niet erg praktisch lijkt me.
Thuiswerkers en de medewerkers van de buitendienst geeft men ieder een aparte op ID gestelde USB-tokens mee, voor een VPN-account met zeer sterk ingeperkte permissies. Voor toegang tot de admin, database, usb en printer accounts dient men zich op het kantoor te vervoegen bij de bewakingsdienst. Zoals ik al aangaf: het komt aan op het ICT beleid.
Ik weet het, het bulkt hier van de doemdenkers die denken dat dat makkelijk te hacken is, maar ik denk dat dit in de praktijk hard meevalt.
Er is geen koe zo bont of er zit wel een vlekje aan. Niets is perfect. Er zit natuurlijk wel een verschil tussen zoiets als een 'saaie' firma en het debiteuren gebeuren bij een grote verzekering, maar als je voorkennis hebt in de termijnhandel kan dat voor bedreven hackers en speculanten ook heel interessante informatie zijn.
Door Anoniem:
"mijn favoriete bedrijf" is hardstikke lief en doet goede dingen, "dat andere bedrijf" is evil en niet te vertrouwen.
Maar een jaar later zijn de rollen omgekeerd, dus beter maar niet dat soort dingen stellen.
Door Toje Fos:
Ja (Authy heeft pincode) en (Authy) 'verzamelen' gegevens alleen ter ondersteuning v.d. beveiliging, niet voor commerciële doeleinden (lees tekst achter jouw link). Microsoft is zonder meer niét te vertrouwen in dit soort zaken.
Aan dit soort beweringen hebben we helemaal NIKS.Ja (Authy heeft pincode) en (Authy) 'verzamelen' gegevens alleen ter ondersteuning v.d. beveiliging, niet voor commerciële doeleinden (lees tekst achter jouw link). Microsoft is zonder meer niét te vertrouwen in dit soort zaken.
"mijn favoriete bedrijf" is hardstikke lief en doet goede dingen, "dat andere bedrijf" is evil en niet te vertrouwen.
Maar een jaar later zijn de rollen omgekeerd, dus beter maar niet dat soort dingen stellen.
Een gewaarschuwd mens telt voor twee en dat jij de ogen wil sluiten voor het grootste kwaad, tja, succes daarmee. De nieuwste ontwikkeling is het afserveren van Windows 10 gebruikers en hun computers. https://www.security.nl/posting/709297#posting709453
Door Anoniem:
Thuiswerkers en de medewerkers van de buitendienst geeft men ieder een aparte op ID gestelde USB-tokens mee, voor een VPN-account met zeer sterk ingeperkte permissies. Voor toegang tot de admin, database, usb en printer accounts dient men zich op het kantoor te vervoegen bij de bewakingsdienst. Zoals ik al aangaf: het komt aan op het ICT beleid.
Door Anoniem: En hoe moeten de mensen dan thuiswerken? Niet erg praktisch lijkt me.
Thuiswerkers en de medewerkers van de buitendienst geeft men ieder een aparte op ID gestelde USB-tokens mee, voor een VPN-account met zeer sterk ingeperkte permissies. Voor toegang tot de admin, database, usb en printer accounts dient men zich op het kantoor te vervoegen bij de bewakingsdienst. Zoals ik al aangaf: het komt aan op het ICT beleid.
Ja maar het komt ook aan op het meegaan met de tijd en het lijkt er op dat jij in de vorige eeuw bent blijven steken,
wellicht zelfs in de DDR.
De manier waarop er thuis gewerkt wordt is inmiddels wel wat veranderd, zeker het afgelopen jaar.
Ik vind het een interessant topic, maar bij mij is de Microsoft Authenticator alleen te openen met face unlock op iOS. Neem aan dat je dat altijd kunt instellen? Dan is deze aanval al niet meer mogelijk, of althans een stuk ingewikkelder. Of mis ik iets?
27-06-2021, 01:19 door
Erik van Straten
Door Anoniem 26-06-2021, 18:47: Ik vind het een interessant topic, maar bij mij is de Microsoft Authenticator alleen te openen met face unlock op iOS. Neem aan dat je dat altijd kunt instellen? Dan is deze aanval al niet meer mogelijk, of althans een stuk ingewikkelder. Of mis ik iets?
Nee, het probleem dat ik aankaartte betreft de situatie dat een aanvaller zowel de klok van een device kan verzetten als TOTP-codes kan uitlezen, bijv. in de situatie dat een slachtoffer diens smartphone uitleent (en dus het scherm unlockt). Als de TOTP-app niet zomaar geopend kan worden door de aanvaller, bestaat deze kwetsbaarheid niet. Maar zie ook hieronder.Door Anoniem 24-06-2021, 08:10: Er zijn open-source oplossingen zoals AndOTP. Daar zit geen commercieel bedrijf achter. Daarnaast slaat de app alles encrypted op + pincode/wachtwoord
Dank voor de tip!Het lijkt er echter op dat deze app (nog) geen unlock met vingerafdruk ondersteunt (zie https://github.com/andOTP/andOTP/issues/707) en dat vind ik jammer; we moeten al veel te veel pincodes en wachtwoorden onthouden (en tijd verspillen bij het invoeren, vooral als je door kleine toetsen vaak typfouten maakt). Als een aanvaller jouw primaire authenticatiefactor (vaak wachtwoord) kent of kan voorspellen, is een pincode voor zo'n app waarschijnlijk een kleine drempel (vooral indien het slachtoffer dezelfde pincode voor het unlocken van de TOTP app gebruikt als voor het ontgrendelen van het scherm, en de aanvaller die laatste afkijkt). Biometrie is een ander type factor en vermoedelijk (hopelijk) lastiger te kopiëren.
Echter, indien Anoniem van 18:47 ook face unlock gebruikt om het scherm van diens toestel te ontgrendelen, zou een lener van het toestel hem/haar er wellicht van kunnen overtuigen dat hij/zij nogmaals in de camera moet kijken omdat het scherm weer gelocked zou zijn (bijv. door daarbij het scherm grotendeels af te dekken zodat de eigenaar niet ziet dat het nu om het ontgrendelen van de TOTP app gaat). Bij gebruik van een vingerafdruk zou ik het toestel zelf vast willen houden, dan lijkt mij deze truc lastiger uit te voeren (maar niet ondenkbaar).
Nb. dit klinkt wellicht allemaal wat vergezocht, maar dat is precies wat cybercriminelen doen: net zolang mogelijkheden overwegen tot je er een gevonden hebt waarmee het doel bereikt wordt. Als je die mogelijkheden zelf kent, kun je je er beter tegen wapenen.
27-06-2021, 01:30 door
Erik van Straten
Door Anoniem: De manier waarop er thuis gewerkt wordt is inmiddels wel wat veranderd, zeker het afgelopen jaar.
Hoe wordt dat nu beveiligd dan?
27-06-2021, 11:30 door
Briolet
Door Erik van Straten: …Het lijkt er echter op dat deze app (nog) geen unlock met vingerafdruk ondersteunt…en dat vind ik jammer; we moeten al veel te veel pincodes en wachtwoorden onthouden
Helemaal mee eens. Waarom zou de app een andere pincode moeten hebben dan het toestel zelf? Als je het toestel al uitleent, dan unlock je hem zelf.
Apps als een bankapp gebruiken gewoon een bibliotheek functie om de authenticatie van het toestel opnieuw op te vragen. Voor een programmeur is het toevoegen van zo'n vingerafdruk check waarschijnlijk minder werk dan het inbouwen van weer een extra pincode die de app dan ook weer veilig op moet slaan.
Het mooiste zou zijn dat gebruikers niet met de tijd kunnen knoeien. Op de iMac moet ik altijd het wachtwoord van een beheerder opgeven om de tijdinstellingen te kunnen veranderen. Ik werk standaard onder een useraccount.
Door Briolet:
Het mooiste zou zijn dat gebruikers niet met de tijd kunnen knoeien. Op de iMac moet ik altijd het wachtwoord van een beheerder opgeven om de tijdinstellingen te kunnen veranderen. Ik werk standaard onder een useraccount.
Ja ik denk dat in een fatsoenlijk OS de gebruiker hooguit de tijdzone kan aanpassen maar niet de daadwerkelijke klok.Het mooiste zou zijn dat gebruikers niet met de tijd kunnen knoeien. Op de iMac moet ik altijd het wachtwoord van een beheerder opgeven om de tijdinstellingen te kunnen veranderen. Ik werk standaard onder een useraccount.
Dwz het systeem zelf blijft intern op dezelfde tijd (UTC waarschijnlijk) lopen maar het klokje op het scherm kun je per
uur of half uur verzetten bijv als je een tijdzonegrens over gaat.
Wil je het supervriendelijk maken voor onduidelijke tiepjes dan laat je zelfs toe om de klok 5 minuten vooruit te zetten
(op het scherm dan) "zodat ze nooit te laat komen" maar in werkelijkheid is dat alleen een offset tov UTC net zoals je
tijdzone.
Een TOTP app werkt uiteraard met UTC tijd (dat doet ie altijd al) en wordt hier dus niet door beinvloed.
De UTC tijd wordt gesynchroniseerd met GPS, NTP, mobile network time, etc. en kun je dus niet aanpassen.
(zelfs niet als admin wat mij betreft)
Door Briolet: Het mooiste zou zijn dat gebruikers niet met de tijd kunnen knoeien.
Ik ga een stap verder: het beste zou het zijn, op elk besturingssysteem, als de device-eigenaar voor elke eerste OS-instelling die hij/zij wil wijzigen, opnieuw zou moeten authenticeren (met een timeout van bijv. 5 minuten en een onmiddelijke reset bij lock screen). Met een vingerafdruk is dat zo gepiept, en nu ik dat (als experiment) voor elke app -waarvoor dat mogelijk is- heb aangezet, mis ik dat als ik naar "instellingen" ga.Als je jouw smartphone of tablet aan bijvoorbeeld een jong kind (of aan een aardig lijkende crimineel of wantrouwende partner) uitleent, wil je immers niet dat deze (onbedoeld) systeem-instellingen kan wijzigen of zelfs een factory reset kan uitvoeren. Ook wil je niet dat malware die je zelf (of een kind etc.) uitvoert dat soort wijzigingen kan doorvoeren zonder jouw toestemming of dat je überhaupt weet dat er instellingen worden gewijzigd.
Of ik op mijn OnePlus 6 met Android 10 daadwerkelijk een factory reset kan uitvoeren zonder te authenticeren, weet ik niet zeker, maar ik kom wel heel ver in de betrokken menu's. Wel moet ik authenticeren om een (root/self-signed) certificaat toe te voegen (prima). Dat laatste lijkt ook het geval op mijn iPhone (iOS 14.6). Maar ook op die iPhone kan ik, zonder authenticeren, de datum en tijd wijzigen.
Ik heb nu even geen tijd om verder onderzoek te doen, maar feit is dat er nog veel verbeterd kan worden aan beveiliging, in elk geval in iOS en Android.
Aanvulling: overigens vind ik wel dat de eigenaar (hoofdaccount) de datum en tijd moet kunnen aanpassen, want op vakantie in Duitsland en Frankrijk een paar jaar geleden had ik op veel plaatsen (met veel natuur) helemaal geen "GSM" bereik, en als de kleine hotelletjes al WiFi hadden, vond ik dat te onbetrouwbaar. Ik kan me goed voorstellen dat deze situatie op veel plaatsen buiten Europa nog veel slechter is. Bovendien is NTP vaak slecht beveiligd en eenvoudig te spoofen. Ten slotte is een deadlock niet ondenkbaar als de datum volledig fout staat en daardoor certificaten niet worden vertrouwd. Kortom, in noodgevallen moet de hoofdgebruiker op z'n minst de datum kunnen corrigeren - maar wel graag pas na de bevestiging dat het de hoofdgebruiker is die dat wil.
28-06-2021, 23:51 door
Briolet
Door Erik van Straten: … Bovendien is NTP vaak slecht beveiligd en eenvoudig te spoofen.
Dit risico valt mee. Het NTP protocol staat slechts toe dat er een beperk aantal seconden per uur gecorrigeerd mag worden. Daar loop je tegenaan wanneer de tijd van je device ongebruikelijk sterk afwijkt. En voor deze aanval gaat het niet om seconden correctie, maar om vele uren of dagen. Dus een afwijkende tijd via een fake NTP server versturen zal de klok marginaal kunnen aanpassen.
Voor een grote correctie heb je toch handmatig ingrijpen nodig en dat kun je op het device beveiligen.
Door Briolet:
Dit risico valt mee. Het NTP protocol staat slechts toe dat er een beperk aantal seconden per uur gecorrigeerd mag worden. Daar loop je tegenaan wanneer de tijd van je device ongebruikelijk sterk afwijkt. En voor deze aanval gaat het niet om seconden correctie, maar om vele uren of dagen. Dus een afwijkende tijd via een fake NTP server versturen zal de klok marginaal kunnen aanpassen.
Voor een grote correctie heb je toch handmatig ingrijpen nodig en dat kun je op het device beveiligen.
Door Erik van Straten: … Bovendien is NTP vaak slecht beveiligd en eenvoudig te spoofen.
Dit risico valt mee. Het NTP protocol staat slechts toe dat er een beperk aantal seconden per uur gecorrigeerd mag worden. Daar loop je tegenaan wanneer de tijd van je device ongebruikelijk sterk afwijkt. En voor deze aanval gaat het niet om seconden correctie, maar om vele uren of dagen. Dus een afwijkende tijd via een fake NTP server versturen zal de klok marginaal kunnen aanpassen.
Voor een grote correctie heb je toch handmatig ingrijpen nodig en dat kun je op het device beveiligen.
Nooit van ntpdate gehoord? ;)
29-06-2021, 09:53 door
Briolet
Door Anoniem: Nooit van ntpdate gehoord? ;)
ntpdate is iets wat lokaal aangeroepen moet worden. Als je daar al toegang tot hebt, hoef je geen fake NTP server te gebruiken.
Door Anoniem: Ja maar het komt ook aan op het meegaan met de tijd en het lijkt er op dat jij in de vorige eeuw bent blijven steken, wellicht zelfs in de DDR. De manier waarop er thuis gewerkt wordt is inmiddels wel wat veranderd, zeker het afgelopen jaar.
Ik zie niet in wat een goed doordacht IT beleid met het communisme van de voormalige DDR van doen heeft, maar dat er de afgelopen decennia ontegenzeggelijk veel in de IT wereld is veranderd, dat kun je wel stellen. Als je niet heel goed op je tellen let, dat ben je zo de sigaar. Dan krijg je huilende en erg boze klanten aan de lijn of op de stoep.
https://nos.nl/artikel/2387092-als-je-bedrijf-platligt-door-ransomware-klanten-stonden-met-knuppels-op-de-stoep
Door Briolet:
Dit risico valt mee. Het NTP protocol staat slechts toe dat er een beperk aantal seconden per uur gecorrigeerd mag worden.
Het NTP protocol beschrijft in de eerste plaats hoe je, via een verbinding met variabele vertragingen, packet loss etc. zo nauwkeurig mogelijk een tijdstip van een time server kunt overnemen.Door Erik van Straten: … Bovendien is NTP vaak slecht beveiligd en eenvoudig te spoofen.
Dit risico valt mee. Het NTP protocol staat slechts toe dat er een beperk aantal seconden per uur gecorrigeerd mag worden.
Ik betwijfel (niet opgezocht) of het een "eis" is van het ntp-protocol om slechts kleine aanpassingen per keer te maken: dat is vooral iets wat je vaak client-side wilt (omdat processen die iets met timing doen, zoals timeouts genereren, onverwachte fouten kunnen geven als je de systeemklok een slinger geeft - vooral als je een klok achteruit zet en een datum+tijd nogmaals "voorbij komt").
Probleem: als de datum en tijd flink fout zijn is het vaak onwenselijk dat de klok met kleine stapjes wordt bijgeregeld. Als OS-bouwer zit je dus met het dilemma wat te doen als NTP, bij herhaling, blijft zeggen dat de klok bijv. 1 dag, 1 maand of zelfs jaren fout staat.
In elk geval is het zo dat als ik onder Android:
1) "Use network-provided time" uitzet
2) De systeemklok een paar uur vooruit zet
3) "Use network-provided time" aanzet
de systeemklok met één klap teruggaat naar de juiste tijd.
Natuurlijk bewijst dit niet zoveel, maar ik heb (nog) niet onderzocht wat er gebeurt als de klok flink zou driften in een periode dat je geen bereik hebt en de verbinding wordt hersteld. Denkbaar is ook dat de datum en tijd vanuit GPS worden gecorrigeerd.
Echter, zelfs alle signed doch onversleuteldel timing informatie uit betrouwbare bron, ontvangen via radioverbindingen, is kwetsbaar voor eenvoudig replay attacks. Probleem: GPS en NTP zijn totaal niet secure.
Ik ben benieuwd hoe Android en iOS reageren als zij, bij herhaling, aanwijzingen krijgen dat de systeem-datum en tijd hartstikke fout staan.
Door Briolet: Daar loop je tegenaan wanneer de tijd van je device ongebruikelijk sterk afwijkt. En voor deze aanval gaat het niet om seconden correctie, maar om vele uren of dagen. Dus een afwijkende tijd via een fake NTP server versturen zal de klok marginaal kunnen aanpassen.
Zie boven.Door Briolet:Voor een grote correctie heb je toch handmatig ingrijpen nodig en dat kun je op het device beveiligen.
Op smartphones [*] is de kans dat de gebruiker het foutstaan van de klok ontdekt en handmatig ingrijpt (en we zijn het er kennelijk over eens dat de toegang daartoe beveiligd zou moeten worden), maar een klok die 1 minuut foutloopt levert al vette problemen op met TOTP-apps en kan dus leiden tot helpdesk calls.Sterker, vanuit Google Authenticator kun je de systeemklok synchroniseren (zou moeten kunnen, hij meldt bij mij nu, via 4G, "There was a problem contacting Google's server. Please check your network settings and try again"). Ik weet niet welk protocol hiervoor gebruikt wordt, maar als dat "ntpdate" is (zoals Anoniem Gisteren, 09:39 benoemt), en jij de server kunt faken, gaat dit alsnog fout.
Door Erik van Straten:
Ik betwijfel (niet opgezocht) of het een "eis" is van het ntp-protocol om slechts kleine aanpassingen per keer te maken: dat is vooral iets wat je vaak client-side wilt (omdat processen die iets met timing doen, zoals timeouts genereren, onverwachte fouten kunnen geven als je de systeemklok een slinger geeft - vooral als je een klok achteruit zet en een datum+tijd nogmaals "voorbij komt").
Toch staat dat wel in de NTP RFC. Dit komt ook omdat de RFC ooit gemaakt is door de schrijver van de referenceIk betwijfel (niet opgezocht) of het een "eis" is van het ntp-protocol om slechts kleine aanpassingen per keer te maken: dat is vooral iets wat je vaak client-side wilt (omdat processen die iets met timing doen, zoals timeouts genereren, onverwachte fouten kunnen geven als je de systeemklok een slinger geeft - vooral als je een klok achteruit zet en een datum+tijd nogmaals "voorbij komt").
implementatie, waarin dit allemaal goed geregeld is.
Dat sluit niet uit dat er implementaties zijn die dit niet goed doen. Behalve een NTP client kan er ook sprake zijn
van een SNTP client die gewoon eens per zoveel tijd de tijd opvraagt (met een subset van het NTP protocol) en het
geretourneerde antwoord gewoon in de systeemklok ramt.
Met name simpele devices zoals routers die werken vaak op die manier.
Probleem: als de datum en tijd flink fout zijn is het vaak onwenselijk dat de klok met kleine stapjes wordt bijgeregeld. Als OS-bouwer zit je dus met het dilemma wat te doen als NTP, bij herhaling, blijft zeggen dat de klok bijv. 1 dag, 1 maand of zelfs jaren fout staat.
In elk geval is het zo dat als ik onder Android:
1) "Use network-provided time" uitzet
2) De systeemklok een paar uur vooruit zet
3) "Use network-provided time" aanzet
de systeemklok met één klap teruggaat naar de juiste tijd.
Natuurlijk bewijst dit niet zoveel, maar ik heb (nog) niet onderzocht wat er gebeurt als de klok flink zou driften in een periode dat je geen bereik hebt en de verbinding wordt hersteld.
In elk geval is het zo dat als ik onder Android:
1) "Use network-provided time" uitzet
2) De systeemklok een paar uur vooruit zet
3) "Use network-provided time" aanzet
de systeemklok met één klap teruggaat naar de juiste tijd.
Natuurlijk bewijst dit niet zoveel, maar ik heb (nog) niet onderzocht wat er gebeurt als de klok flink zou driften in een periode dat je geen bereik hebt en de verbinding wordt hersteld.
Dit is precies het gedrag wat je van een goede NTP implementatie mag verwachten. Bij normaal bedrijf alleen
langzaam bijregelen en bij stoppen/starten tijdelijk in een mode werken waarin een grotere sprong mogelijk is.
Dat betekent dat als jij zelf de netwerk sync aanzet en constateert dat het goed gaat, een "aanvaller" niet zomaar
even met het geven van rare NTP antwoorden de tijd behoorlijk kan beinvloeden. Een tijd die "helemaal fout" is
zal normaalgesproken genegeerd worden, en een tijd die "een beetje afwijkt" zal het regelsysteem in werking
stellen waarmee de systeemklok langzaam naar die nieuwe waarde loopt. Wil je daarmee een klok een paar uur
verzetten dan moet je gedurende meerdere dagen precies uitgedokterde foute NTP antwoorden kunnen geven
waarmee je die client langzaam van slag brengt, en al die tijd moet het de gebruiker niet opvallen dat de klok
verkeerd staat. Niet erg waarschijnlijk dat dit lukt.
Op smartphones [*] is de kans dat de gebruiker het foutstaan van de klok ontdekt en handmatig ingrijpt (en we zijn het er kennelijk over eens dat de toegang daartoe beveiligd zou moeten worden), maar een klok die 1 minuut foutloopt levert al vette problemen op met TOTP-apps en kan dus leiden tot helpdesk calls.
Nee hoor, een minuut is geen probleem, de grens ligt meestal verder weg bijvoorbeeld bij 5-15 minuten.
Sterker, vanuit Google Authenticator kun je de systeemklok synchroniseren (zou moeten kunnen, hij meldt bij mij nu, via 4G, "There was a problem contacting Google's server. Please check your network settings and try again"). Ik weet niet welk protocol hiervoor gebruikt wordt, maar als dat "ntpdate" is (zoals Anoniem Gisteren, 09:39 benoemt), en jij de server kunt faken, gaat dit alsnog fout.
Dat zou geen zin hebben. Ik denk eerder dat dit een eigen protocol van die authenticator is dat bijvoorbeeld via een https verbinding met een Google server de tijd ophaalt.
Zelfs een willekeurige webserver waarvan je weet dat de klok goed staat daar kun je de tijd vanaf halen, weliswaar slechts met een resolutie van 1 seconde maar dat is goed genoeg om hem binnen NTP "vangbereik" te brengen en om TOTP te laten werken.
Dus Google zou dit gewoon met google.com kunnen doen. Hoe ze er in slagen om een probleem daarmee te krijgen weet ik ook niet.
30-06-2021, 14:14 door
Briolet
Door Erik van Straten:Ik betwijfel (niet opgezocht) of het een "eis" is van het ntp-protocol om slechts kleine aanpassingen per keer te maken: dat is vooral iets wat je vaak client-side wilt (omdat processen die iets met timing doen, zoals timeouts genereren, onverwachte fouten kunnen geven als je de systeemklok een slinger geeft - vooral als je een klok achteruit zet en een datum+tijd nogmaals "voorbij komt").
Het veranderen van de tijd in zeer kleine stapjes is inderdaad om te voorkomen dat andere processen verstuurd raken.
Ik kan me één geval herinneren van een IP camera die steeds een drift vertoonde. De zomertijd checkbox was niet goed ingesteld en de gebruiker zette de tijd steeds via de klok op de zomertijd. Maar omdat de checkbox op wintertijd bleef staan, probeerde de ntp-deamon hem weer langzaam op wintertijd te zetten. Dat uur correctie nam steeds enige tijd in beslag.
De maximale correctie (step threshold) is 128 ms. De polling interval van een tijdserver ligt tussen de 64 en 1024 seconden. (Een kortere pollinginterval dan 64 seconden wordt als abuse gezien) Na elke polling wordt de klok maximaal 128 ms gecorrigeerd.
Na even de ntpd handleiding gelezen te hebben, zie ik dat er ook een "Panic threshold" is die standaard op 1000 seconden staat. Wordt deze afwijking overschreden stopt de ntp-deamon zelfs compleet en corrigeert helemaal niet meer. Dat maakt het nagenoeg onmogelijk dat een fake timeserver de klok überhaupt substantieel kan verzetten.
30-06-2021, 21:27 door
Erik van Straten
Door Erik van Straten: Op smartphones [*] is de kans dat de gebruiker het foutstaan van de klok ontdekt en handmatig ingrijpt (en we zijn het er kennelijk over eens dat de toegang daartoe beveiligd zou moeten worden), maar een klok die 1 minuut foutloopt levert al vette problemen op met TOTP-apps en kan dus leiden tot helpdesk calls.
Dit was ik vergeten toe te voegen:[*] We hebben steeds meer aan internet gekoppelde apparaten (IoT) waarbij de systeemdatum en -tijd niet (zo prominent) zichtbaar zijn als op een smartphone. Ook daarop wordt het steeds belangrijker (dan je mogelijk denkt) dat de systeemdatum en -tijd binnen een kleine marge synchroon loopt met systemen waarmee wordt gecommuniceerd; zo wordt er steeds meer met digitale certificaten gewerkt die steeds minder lang geldig zijn. En om replay-attacks te voorkomen, wordt steeds vaker "getimestamped", en dan is een correct lopends klok essentieel. Bijv. ook Kerberos vereist behoorlijk synchrone klokken.
Het dilemma hierbij is de afweging wat erger is: het weerstaan van een aanval waarbij wordt geprobeerd de klok radicaal te verzetten, of dat het helemaal niet om een aanval gaat maar dat, om welke reden dan ook, de systeemklok al radicaal fout staat en juist gecorrigeerd moet worden. Het NTP-protocol alleen kan zo'n probleem niet oplossen en lijkt ontworpen voor systemen waar een mens de boel (logs etc.) in de gaten houdt.
Door Anoniem: Een tijd die "helemaal fout" is zal normaalgesproken genegeerd worden
Bij veel apparaten is dat onacceptabel. Van een PC die opstart met de systeemdatum op 1990-01-01 o.i.d. omdat de CR2032 leeg is wil je niet dat dit zo blijft. De meeste OS'en zullen dan `ntpdate` of een equivalent uitvoeren.Door Anoniem:
Nee hoor, een minuut is geen probleem, de grens ligt meestal verder weg bijvoorbeeld bij 5-15 minuten.
Dat lijkt mij totale onzin. Google Authenticator genereert elke 30 seconden een nieuwe code, dat is niet voor niks zo freqeunt. Nog even los van dat 15 minuten de gebruikte 6 cijfers met een factor 30 zou verzwakken: als zo'n code 15 minuten geldig zou zijn, hoeft de aanvaller de systeemklok niet eens vooruit te zetten. Hij/zij heeft dan tijd zat om naar een ander vertrek te lopen of de code naar een handlanger door te bellen/appen/SMS'en. Uit https://en.wikipedia.org/wiki/Time-based_One-Time_Password#Security:Door Erik van Straten: maar een klok die 1 minuut foutloopt levert al vette problemen op met TOTP-apps en kan dus leiden tot helpdesk calls.
Nee hoor, een minuut is geen probleem, de grens ligt meestal verder weg bijvoorbeeld bij 5-15 minuten.
For subsequent authentications to work, the clocks of the authenticatee and the authenticator need to be roughly synchronized (the authenticator will typically accept one-time passwords generated from timestamps that differ by +- 1 time interval from the authenticatee's timestamp). [1]
[1] https://tools.ietf.org/html/rfc6238
[1] https://tools.ietf.org/html/rfc6238
Door Anoniem:
Dat zou geen zin hebben. Ik denk eerder dat dit een eigen protocol van die authenticator is dat bijvoorbeeld via een https verbinding met een Google server de tijd ophaalt.
Ik heb geen idee, als ik een keer zin en tijd heb ga ik dit waarschijnlijk wel een keer wiresharken.Sterker, vanuit Google Authenticator kun je de systeemklok synchroniseren (zou moeten kunnen, hij meldt bij mij nu, via 4G, "There was a problem contacting Google's server. Please check your network settings and try again"). Ik weet niet welk protocol hiervoor gebruikt wordt, maar als dat "ntpdate" is (zoals Anoniem Gisteren, 09:39 benoemt), en jij de server kunt faken, gaat dit alsnog fout.
Dat zou geen zin hebben. Ik denk eerder dat dit een eigen protocol van die authenticator is dat bijvoorbeeld via een https verbinding met een Google server de tijd ophaalt.
Door Anoniem: Zelfs een willekeurige webserver waarvan je weet dat de klok goed staat daar kun je de tijd vanaf halen,
Maar hoe weet je of de klok van een webserver op tijd loopt als je zelf geen betrouwbare referentietijd hebt? Zelf heb ik overigens een DCF-77 horloge - maar ook dat is een totaal onbeveiligd protocol. Trouwens, ik heb ook de redactie van security.nl er wel eens op gewezen dat hun systeemklok meer dan 1 minuut fout liep (is toen gecorrigeerd).Door Anoniem: Dus Google zou dit gewoon met google.com kunnen doen. Hoe ze er in slagen om een probleem daarmee te krijgen weet ik ook niet.
Geen idee, misschien dat iets signaleert dat ik dit via 4G probeer (waar ik nu zit heb ik geen WiFi en die time sync via 4G werkt nog steeds niet).Door Briolet: Na even de ntpd handleiding gelezen te hebben, zie ik dat er ook een "Panic threshold" is die standaard op 1000 seconden staat. Wordt deze afwijking overschreden stopt de ntp-deamon zelfs compleet en corrigeert helemaal niet meer.
Het is ook mijn ervaring (met zeer tijdkritische apparaten draaiend op Linux-based firmware) dat de ntp-daemon stopt bij onverwachte problemen, maar dat is natuurlijk nooit een oplossing voor een probleem - sterker, meestal wordt dat probleem er alleen maar groter door. Handmatig ingrijpen is echter, helaas, niet altijd (snel) mogelijk en vaak is de diagnose niet zo simpel omdat soms de meest vreemde zaken misgaan. Als je dan ontdekt wat er mis is en de systeemklok goed zet, is het balen als je er na een week achterkomt dat de klok opnieuw is weggedrift, deze keer omdat ntpd niet meer draaide.Door Erik van Straten:
Het dilemma hierbij is de afweging wat erger is: het weerstaan van een aanval waarbij wordt geprobeerd de klok radicaal te verzetten, of dat het helemaal niet om een aanval gaat maar dat, om welke reden dan ook, de systeemklok al radicaal fout staat en juist gecorrigeerd moet worden. Het NTP-protocol alleen kan zo'n probleem niet oplossen en lijkt ontworpen voor systemen waar een mens de boel (logs etc.) in de gaten houdt.
Het kan gebeuren dat NTP de handen er vanaf trekt en de klok niet meer bijstelt maar de kans is groter dat dat gebeurtHet dilemma hierbij is de afweging wat erger is: het weerstaan van een aanval waarbij wordt geprobeerd de klok radicaal te verzetten, of dat het helemaal niet om een aanval gaat maar dat, om welke reden dan ook, de systeemklok al radicaal fout staat en juist gecorrigeerd moet worden. Het NTP-protocol alleen kan zo'n probleem niet oplossen en lijkt ontworpen voor systemen waar een mens de boel (logs etc.) in de gaten houdt.
als er iemand de boel besodemietert dan in normale gevallen.
Door Anoniem: Een tijd die "helemaal fout" is zal normaalgesproken genegeerd worden
Bij veel apparaten is dat onacceptabel. Van een PC die opstart met de systeemdatum op 1990-01-01 o.i.d. omdat de CR2032 leeg is wil je niet dat dit zo blijft. De meeste OS'en zullen dan `ntpdate` of een equivalent uitvoeren.daarna niet meer. De klok springt niet als je batterij leeg is, maar alleen als je met een lege batterij stroomuitval hebt en
daarna weer start.
Dan worden de NTP replies even vertrouwd en daarna gaat ie weer in "volg" mode waardoor een aanval niet meer
werkt.
Door Anoniem:
Nee hoor, een minuut is geen probleem, de grens ligt meestal verder weg bijvoorbeeld bij 5-15 minuten.
Dat lijkt mij totale onzin. Google Authenticator genereert elke 30 seconden een nieuwe code, dat is niet voor niks zo freqeunt.Door Erik van Straten: maar een klok die 1 minuut foutloopt levert al vette problemen op met TOTP-apps en kan dus leiden tot helpdesk calls.
Nee hoor, een minuut is geen probleem, de grens ligt meestal verder weg bijvoorbeeld bij 5-15 minuten.
De server onthoudt steeds welke code de gebruiker ingevoerd heeft en bepaalt op die manier hoeveel de klok fout staat.
Dus als jij iedere dag een keer inlogt en iedere keer de code geeft die 1 interval verderop geldig is dan gaat de server langzaam aan jouw tijdoffset verhogen. Als je klok niet goed gelijk loopt maar na een paar weken langzaam aan een paar minuten voor is gaan lopen dan is dat dus geen probleem.
De problemen komen pas als je hem dan plotseling goed zet. Want dat kan dan een te grote sprong zijn.
Door Anoniem: Zelfs een willekeurige webserver waarvan je weet dat de klok goed staat daar kun je de tijd vanaf halen,
Maar hoe weet je of de klok van een webserver op tijd loopt als je zelf geen betrouwbare referentietijd hebt? Zelf heb ik overigens een DCF-77 horloge - maar ook dat is een totaal onbeveiligd protocol. Trouwens, ik heb ook de redactie van security.nl er wel eens op gewezen dat hun systeemklok meer dan 1 minuut fout liep (is toen gecorrigeerd).Lukt het je niet om dat voor www.google.com voor elkaar te krijgen dan kun je een aparte server optuigen waar dat wel het geval is.
Inderdaad, er zijn zat webservers die niet goed lopen dus je moet niet een willekeurige server pakken.
Door Briolet: Na even de ntpd handleiding gelezen te hebben, zie ik dat er ook een "Panic threshold" is die standaard op 1000 seconden staat. Wordt deze afwijking overschreden stopt de ntp-deamon zelfs compleet en corrigeert helemaal niet meer.
Het is ook mijn ervaring (met zeer tijdkritische apparaten draaiend op Linux-based firmware) dat de ntp-daemon stopt bij onverwachte problemen, maar dat is natuurlijk nooit een oplossing voor een probleem - sterker, meestal wordt dat probleem er alleen maar groter door. Handmatig ingrijpen is echter, helaas, niet altijd (snel) mogelijk en vaak is de diagnose niet zo simpel omdat soms de meest vreemde zaken misgaan. Als je dan ontdekt wat er mis is en de systeemklok goed zet, is het balen als je er na een week achterkomt dat de klok opnieuw is weggedrift, deze keer omdat ntpd niet meer draaide.Dat is inderdaad een ongelukkige keuze die gelukkig tegenwoordig meestal niet meer actief is (door betere default config).
De ntpd auteur is een beetje een eigenwijze gast, maar configfiles kunnen hem overrulen.
En de code is de laatste jaren ook wel wat beter geworden: de versies van 5-10 jaar geleden waren sneller in paniek of op andere manieren onstabiel dan die van tegenwoordig.
Wel zul je natuurlijk vaak embedded spullen vinden met antieke versies erin omdat men dat nooit meer update zelfs niet als er nieuwe firmware voor zo iets uitkomt.
En er bestaan betere NTP implementaties zoals chrony (en slechtere zoals openntpd).
Zelf heb ik op mijn machine chrony draaien met 2 lokale referentieklokken (GPS en DCF77) en een aantal remote
servers via 2 verschillende netwerken. Ik denk niet dat het realistisch is dat iemand dit allemaal in een keer weet
te spoofen. En hij zal de meerderheid van de referenties in 1 keer op dezelfde manier moeten veranderen anders
wordt die source niet meer vertrouwd. Zo werkt dat in NTP.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
