MacOS-bug toont wachtwoord in plaats van hint bij apfs-volume - update

Apples macOS High Sierra bevat een bug waardoor het besturingssysteem het wachtwoord van een versleuteld apfs-volume prijsgeeft. Na het unmounten en opnieuw mounten van het volume, toont het OS het wachtwoord in plaats van de hint.

De bug is aangetroffen door Matheus Mariano, die het probleem inmiddels aan Apple gemeld heeft. Een fix voor het probleem is er nog niet. Apple bracht macOS 10.13 High Sierra op 25 september uit na een bètaperiode van een aantal maanden. De software vervangt het hfs+-bestandssysteem door het Apple File System, of apfs, bij systemen met ssd's.

Wie met Disk Utility een versleuteld schijfvolume op basis van apfs toevoegt aan de container, moet een wachtwoord invoeren, samen met een hint voor dat wachtwoord. Wie vervolgens het schijfvolume verwijdert en weer toevoegt, moet het wachtwoord invoeren. Wie zijn hint daarvoor wil tonen, krijgt van het besturingssysteem echter direct het wachtwoord te zien. Ook na een restart blijft het venster het wachtwoord weergeven bij het mounten van het schijfvolume. Het probleem doet zich voor bij de bètarelease en de officiële release van High Sierra. Wanneer Apple het probleem verhelpt, is niet bekend.

Update, 21.40: Apple heeft een update voor High Sierra uitgebracht en adviseert gebruikers een back-up te maken en een nieuw apfs-volume en vervolgens een nieuw apfs encrypted-volume te maken om de data op terug te kunnen zetten.

Reacties (71)

[nils83]

Er is reeds een update van Apple die deze bug verhelpt

Updaten via App Store

Hier staat meer info:
https://support.apple.com/en-us/HT208168

Was trouwens reeds beschikbaar voordat het artikel gepubliceerd was. Wel een zeer kwalijke bug, goed dat Apple zeer snel gereageerd heeft.

[Reactie gewijzigd door nils83 op 25 juli 2024 03:17]

[johnkeates]

Er was ook vrij snel een Security Advisory op de security list van Apple:

APPLE-SA-2017-10-05-1 macOS High Sierra 10.13 Supplemental Update

macOS High Sierra 10.13 Supplemental Update is now available
and addresses the following:

StorageKit
Available for: macOS High Sierra 10.13
Impact: A local attacker may gain access to an encrypted APFS volume
Description: If a hint was set in Disk Utility when creating an APFS
encrypted volume, the password was stored as the hint. This was
addressed by clearing hint storage if the hint was the password, and
by improving the logic for storing hints.
CVE-2017-7149: Matheus Mariano of Leet Tech

Security
Available for: macOS High Sierra 10.13
Impact: A malicious application can extract keychain passwords
Description: A method existed for applications to bypass the
keychain access prompt with a synthetic click. This was addressed by
requiring the user password when prompting for keychain access.
CVE-2017-7150: Patrick Wardle of Synack

[Maurits van Baerle]

Interessant, de fix test waarschijnlijk dus of ze met de inhoud van het hint veld de schijf kunnen decrypten. Als dat zo is dan weten ze dat het wachtwoord in het hint veld terecht is gekomen en wissen ze het hint veld.

Tenzij een aanvaller dus die hint heeft bekeken voordat de fix was geinstalleerd (maar dat stil heeft gehouden) kunnen ze dus niet op het volume. Desalniettemin is het nog steeds verstandig om je wachtwoord te veranderen nadat je de fix hebt gedraaid.

[Infor40]

Het advies van Apple doet vermoeden dat een simpele verandering van wachtwoord niet genoeg is, maar dat je het hele volume opnieuw moet encrypten... Das even een flinke klus meer dan een ww veranderen.

[MsG]

Dat is toch logisch als inhoud geencrypt is op basis van je wachtwoord?

[GekkePrutser]

Zo werkt het niet. De disk wordt ge-encrypt met een random key, vervolgens wordt die key ge-encrypt met het wachtwoord.

Op die manier kan je ook met meerdere wachtwoorden een drive unlocken (nodig voor bijvoorbeeld secure booten in een multiuser omgeving).

[Superstoned]

Dat is dan geen slimme encryptie. Irritanter en dommer nog is dat ze dus het wachtwoord zelf opslaan ipv een hash. Je kunt best een key maken voor de encryptie, met met een 2e key encrypten, en 2e die beschermen met een gehashed wachtwoord. Dan hoef je bij verandering van het wachtwoord niet opnieuw te encrypten en je hoeft ook het wachtwoord zelf niet op te slaan.


Nou ja ik ben geen expert dus misschien mis ik iets, Apple heeft goede cryptography experts aan boord en ik neem aan dat er over is nagedacht.

[Reactie gewijzigd door Superstoned op 25 juli 2024 03:17]

[Woutske]

Vervelend als je de hint dus ook echt nodig hebt (bijvoorbeeld volgnummer in extern systeem zoals velen doen). De hints die voor de fix van deze bug zijn ingevoerd kunnen dus als verloren worden beschouwd.

[killercow]

waarom is dat wachtwoord uberhaupt ergens opgeslagen en niet gewoon netjes een hash van het wachtwoord?

Dit betekend dat het wachtwoord dus ergens unencrypted te vinden moet zijn buiten de geencrypte container, samen met de andere meta-data zoals de hint.

[Reactie gewijzigd door killercow op 25 juli 2024 03:17]

[JPDeckers]

Gokje:

Het is netjes gehasht, zoals het hoort.
Echter, door een off-by-one error wordt bij de hint ipv field[2] (je zelf ingevulde hint) nu field[1] (je password) opgeslagen. Als tekst natuurlijk, want dat is je hint.
Oops

[Sniperlogit]

Waarschijnlijk niet want de naam Test zie je gewoon staan terwijl die volgens jou gehasht zou zijn?

[Verwijderd]

Ze slaan de hint niet op, maar het wachtwoord wordt opgeslagen in de hint variabele. (Vermoedelijk)

[Qlusivenl]

Test is de naam van het volume, niet van het wachtwoord of hint.

[HENNESSY]

Het wachtwoord hoort sowieso niet opgeslagen te worden, ook niet een hash. Waarschijnlijk is dit een fout in het opslaan van de hint waarbij het password wordt opgeslagen ipv de hint. Typo in variabel naam.

[Neko Koneko]

Als je geen hash van het wachtwoord opslaat, hoe wil je dan controleren of iemand het juiste wachtwoord heeft ingevuld?

[Sacrome]

Door te checken of de schijf ontsleuteld kan worden met het ingevoerde wachtwoord.
Er hoeft geen hash van een wachtwoord opgeslagen te worden, omdat deze fungeert als sleutel. Is de sleutel onjuist, dan blijft de schijf onleesbaar.

[RuudAnders]

Kleine toevoeging: waarschijnlijk gebruiken ze het wachtwoord niet direct, maar om een sterkere key (2048-bits of groter) te ontsleutelen, welke uiteindelijk gebruikt wordt voor de versleuteling van het volume. Dit mechanisme passen ze een aantal jaren toe voor de versleuteling op iOS.

[HENNESSY]

Het is geen controle of iemand het juiste wachtwoord invult. Er is dus geen vergelijking of het wachtwoord of een hash ervan overeenkomt. Het is de sleutel om te decrypten, met een verkeerde sleutel kan je niet decrypten (niet omdat sleutel niet overeenkomt maar omdat de output van het decrypten met een andere sleutel onleesbaar is).

[Reactie gewijzigd door HENNESSY op 25 juli 2024 03:17]

[johnkeates]

Om dat het wachtwoord nergens mee vergeleken hoeft te worden, het is namelijk zelf sleutelmateriaal.

[ro8in]

Hij is gewoon gehashed ze slaan alleen het wachtwoord veld op in de hint inplaats van de hint zelf. Een foutje, maar wel een hele domme!

[Loggedinasroot]

Een hash kan maar 1 kant op niet?

[ro8in]

Ja dus tijdens het opslaan neemt hij de informatie uit het wachtwoord veld en slaat deze op waar het hoort, maar ook op de plek van de hint waar die niet hoort... De bug is niet dat het hint scherm de verkeerde informatie toont, maar dat het hint maak scherm het verkeerde veld uit leest.

[Reactie gewijzigd door ro8in op 25 juli 2024 03:17]

[Loggedinasroot]

Ahh nu snap ik wat je bedoelt. Dit is dan wel een erg slordige fout. Er is dan blijkbaar niet getest of het opslaan van een hint werkt?
Het zal vast iets ingewikkelder liggen.

[ro8in]

Ik denk dat het echt zo simpel is als per ongeluk het verkeerde veld uitlezen en die data opslaan. Zelfs de big boys maken soms stomme foutjes...

[Loggedinasroot]

De fout kan makkelijk gemaakt worden tijdens het programmeren, maar je kijkt toch of iets werkt? En misschien schrijf je wel een testcase.
En in al die maanden van beta testen heeft niemand de hint functie getest/gebruikt?

[MaxxMark]

Dat het het 'oogkleppen' probleem of het 'blind voor je eigen code worden'. Als je eenmaal diep genoeg in je code zit en de (user)testrondjes al eindeloze keren hebt gedaan, ga je dingen over het hoofd zien. Waaronder zoiets stoms als dit. Dikke kans ook dat er met het testen getest wordt met "askjhaskfhsfjk" als hint of iets dergelijks.

Natuurlijk zal je met dingen als unit-tests iets dergelijks al af kunnen vangen. Maar het zou vervolgens prima kunnen zijn dat de unit test te beperkt was alleen maar checkt of er een waarde is geset, en of die uit te lezen is.

Verder kan ik me zomaar voorstellen dat bij dergelijke low-level zaken er domweg geen fully automated test cases zijn die een volume aanmaken, een ww setten, een hint setten, en vervolgens na het encrypten de informatie nog een keer test.

En als laatste (en die kans acht ik zeer groot) zal de tijdsdruk heel erg mee hebben gespeeld en is er last-minute iets gewijzigd en heeft daar iemand een fout gemaakt.

Neemt niet weg dat het slordig is

[Mellow Jack]

Vaak heb je meerdere soorten testen. Unit testen (programmeur die eigen code test) zijn vaak geïsoleerd het hoeft niet fout te gaan bij het opslaan maar kan ook fout gaan in de UI. Daarnaast heb je nog veel type testen om zo elk aspect van een programma te testen. Van functioneel tot penetratie en stress testen. Maar het is helaas een utopie om 100% codecoverage te hebben want zoiets is te duur. Zelfs binnen beta testen is het lastig, natuurlijk gaat iedereen spelen maar na een tijdje gaan de meesten het gewoon gebruiken zoals ze dat altijd doen. Meeste Beta testers zijn it savy lijkt mij dat die niet dagelijks de hint functie zullen gebruiken

[aikebah]

100% code coverage is, afhankelijk van de logica, regelmatig nog wel te realiseren (niet meer realistisch zodra er code-branches dealen met vrijwel niet tijdens testen te simuleren omgevings-falen), maar 100% input-variaties coverage zeker niet. Het aantal mogelijke hints nadert tot oneindig (ik neem aan dat er ook aan de hint wel een limiet zit, maar gecombineerd met het aantal mogelijke waarden per karakter is alleen voor het volledig doortesten van alle mogelijke hint-waarden een gruwelijk hoog aantal testgevallen, dus 100% van het waardebereik van de hints (laat staan 100% van het hints waardebereik testen voor ieder van de 100% mogelijke passwords) testen is niet realistisch, terwijl er toch theoretisch een waarde zou kunnen zijn die bijvoorbeeld een buffer-overflow kan triggeren).

100% code-coverage garandeert nog geen bug-vrij systeem, maar is voor veel stukken software wel te realiseren tegen acceptabele kosten als iets echt veilig moet zijn.

[CorbataGames]

Waarschijnlijk hebben ze per ongeluk het wachtwoord opgeslagen en niet de hint. Wel erg kwalijk!

[RobertMe]

Als dat zo is is het wel een interessant probleem. En dan verwacht ik dat de oplossing van Apple wordt dat ze de hint maar weghalen (totdat je een nieuwe hint instelt). Want dit kunnen ze natuurlijk nooit meer corrigeren.

[supersnathan94]

Waarschijnlijk wordt de hint helemaal niet opgeslagen doordat het verkeerde veld wordt beschreven. Beetje jammer want zoiets test je toch juist?

Juist voor dit soort kleine statische meuk heb je unittests.

[Coolstart]

Vrij simpel: Elke Apple aparaat heeft een ‘Keychain’ dat is een soort wachtwoord manager zoals Onepass maar dan verwerkt in Icloud. De wachtwoorden zijn natuurlijk gehased geëncrypteerd en niet in plain text opgeslagen.

Keychain beheert alle wachtwoorden. Ftp toegang, externe servers, root certification, wifi toegang, kredietkaart gegevens etc. Als je een iphone hebt met touch id kan je automatisch encrypted data lezen of wachtwoorden worden automatisch ingevuld in webforms het staat in verbinding met uw andere apple devices.

Het betekend dus niet dat het wachtwoord standaard unecrypted wordt opgeslagen. Ze decrypten de keys met 256bit AES. Net zoals 1password. Wat je ziet is simpelweg de decrypted versie van uw hash wachtwoord net zoals dat in een webformulier of in een app automatisch in plain text wordt ingevuld (al dan niet via touch id). Wat er in de bug gebeurd is moeilijk te zeggen.


Edit: Klopt, een Hash is iets anders en nagenoeg onomkeerbaar maar je kan het wel gebruiken om 2 hashes te vergelijken.

Jij schreef: "waarom is dat wachtwoord uberhaupt ergens opgeslagen en niet gewoon netjes een hash van het wachtwoord?"

1-password werkt ook zo. Zodra er autofill aan te pas komt gebeurd de autofil op basis van plain tekst. Dus als je zou hashen kan keychain geen autofill meer toepassen. Net zoals 1password.

[Reactie gewijzigd door Coolstart op 23 juli 2024 09:00]

[killercow]

Bijna goed. Een hash kun je niet decrypten. Je haalt encryptie en hashing door elkaar.

Hoe het waarschijnlijk werkt:
Je disk is encrypted met iets als AES 256Bits, daar is een secret voor nodig. Dat secret kan een wachtwoord zijn ingevoerd door de gebruiker, of een Hash van dat wachtwoord. Of een secret dat opgeslagen is in een los lijstje ergens.

Hoe komen we dan aan dat secret? We voeren een wachtwoord in en dat is het secret. Of we voeren een wachtwoord in en hashen dat en komen zo aan t secret. Je kunt natuurlijk ook een secret uit een keychain halen die je met je wachtwoord had unlocked, maar zoals ik al zei. Een secret. niet het wachtwoord is nodig om de boel te decrypten.

edit:
265 inderdaad

[Reactie gewijzigd door killercow op 25 juli 2024 03:17]

[Krulliebol]

265 nog wel!

[SoloH]

Nee die passwords van je mounts ed staan in je Keychain. Een db van passwords op macos. Die is wel encrypted met je user pw.
Ze zijn wel 2 way. Je kan ze dus altijd inzin mbv je user pw.

[killercow]

ik heb *alles* te verbergen.

[nassau]

Vervelende bug.

Even voor de niet tweakers onder ons:

• Dit heeft NIETS te maken met FileVault schijven! Dit mechanisme gebruikt vrijwel iedereen. Geen actie nodig dus.
• Bug is geïntroduceerd met de Disk Utility van High Siera en alleen voor APFS encrypted containers.
• De fix is ook al uitgerold in nieuwe High Sierra installs. Dus als je vandaag gaat updaten zit de fix er al in.
• Aangezien APFS nu nog alleen op SSD werkt heeft dit geen gevolgen voor andere media

[iCore]

Maar dan is je wachtwoord ergens op geslagen buiten de container...

Nog wat informatie over verbeteringen:
https://www.iphoned.nl/nieuws/macos-high-sierra-functies/

[itsme]

Nee, het wachtwoord is gebruikt en voor de versleuteling en in het hint veld. De hint is nergens opgeslagen.

[M.Koers]

Een hint tonen voor een wachtwoord is uberhaupt erg slecht.
In Windows inmiddels ook verplicht in te vullen, ok een simpele . volstaat maar toch.
Wij Tweakers denken hier nog wel over na, maar je kan er vanuit gaan dat er genoeg mensen zijn die hele vragen als hint opgeven. Beetje simple google werk naar een persoon en je kan een mooi eind komen

[mikesmit]

Een hint moet ook op een wachtwoord slaan die eventueel over iets peraoonlijks gaat (iets is niet peraoonlijk als je er via een beetje social enginering achter kan komen)

[MadEgg]

Hints laat ik altijd leeg of indien niet toegestaan gevuld met garbage, even rammen op het toetsenbord.

"Secret Questions" beantwoord ik ook nooit naar waarheid maar gebruik ik om een alternatief veilig wachtwoord In te vullen. Daar zijn password managers voor per slot van rekening.

Het idee van secret questions is echt een van de slechtste ideeën ooit en indien gebruikt zoals het suggereert gebruikt te moeten worden een extreme security loophole.

[Blokker_1999]

Ik heb voor die geheime vragen gewoon wat standaard antwoorden. Wordt alleen maar lastig als je op een site komt en die site vraagt je eerst wat je geheime vraag was ...

[Verwijderd]

Ja je kunt veel zeggen maar sneller gepached dan het posten op news sites. Hehe.

[BikkelZ]

Ik háát hints en van die persoonlijke vragen. Al mijn wachtwoorden zien er uit als random ASCII braaksel en persoonlijke vragen zijn net wat te makkelijk terug te vinden.

[Verwijderd]

Je kunt zeggen wat je wilt, maar Apple maakt het echt wel simpel voor je. Dit is nog eens een goede hint! Wedden dat het de meest succesvolle hint functionaliteit in de geschiedenis is? Succes ratio 100%

All jokes aside, slordige fout.

[Snake]

Heeft Apple's (Cocoa dan) Passwordfield geen extra security measures om dit te vermijden?

BV: WPF: PasswordBox & SecurePassword

[Blokker_1999]

En hoe ga jij beschermen tegen een programmeur die per ongeluk de verkeerde variabele doorgeeft? Zo een fout is enorm snel gebeurd, 1 moment van onoplettendheid.

[PolarBear]

En geen momenten van testen

[jabwd]

Ze hebben hier een hele nieuwe filesystem in minder dan 6 jaar tot volwassen en stable gekregen. Dat is nite een makkelijk iets en heel erg knap juist. Dat er iets fout is gegaan, is niet zo heel raar. Meeste filesystems hebben decades nodig.

Een filesystem maken is echt net ff wat lastiger dan een simpele poep site met wat wachtwoord hashen.

[nassau]

Even voor de duidelijkheid. De bug zit in Disk Utility. Niet in het APFS filesysteem...

[Gronaldo]

Wel een goede hint dan, heel handig

[walkstyle]

En toch zul je zien, dat er nog mensen niet in kunnen loggen