Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Wachtwoordprompt macOS is te omzeilen met eenvoudige truc - update

In macOS is het mogelijk om een beveiligingsprompt waar om het wachtwoord van een administrator wordt gevraagd, te omzeilen door 'root' in te vullen en het wachtwoordveld leeg te laten. Het lek werkt op de recentste versie van macOS High Sierra.

Het lek werd ontdekt door gebruiker Lemi Ergin, die zijn bevindingen op Twitter deelde. Hij geeft aan dat er soms meerdere pogingen gedaan moeten worden, maar het in principe altijd lukt. Ook is het mogelijk om op deze manier op een vergrendelde computer in te loggen of vanuit een gastaccount een administratoraccount aan te maken. Tweakers heeft de bug op meerdere Apple-computers weten te reproduceren. Het lijkt alleen te werken op High Sierra, niet op eerdere versies, zoals gebruiker Pendora aangeeft.

Apple heeft nog niet op de bug gereageerd. Of en wanneer er een oplossing voor komt, is nog niet bekend. In de tussentijd is er een workaround beschikbaar door de rootgebruiker in te schakelen en daar een wachtwoord aan toe te kennen. Op de website van Apple is een stappenplan beschikbaar dat uitlegt hoe dit te doen.

Het is niet de eerste keer dat er een slordige bug in macOS boven komt drijven. In oktober bleek dat het mogelijk was om het wachtwoord van een apfs-volume te tonen op de plaats van de hint. Apple heeft toen snel een update uitgebracht die het probleem verhielp.

Update woensdag: Apple heeft inmiddels een patch uitgebracht die het probleem oplost.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Door Emile Witteman

Nieuwsposter

28-11-2017 • 21:56

211 Linkedin Google+

Reacties (211)

Wijzig sortering
Heel bizar. Ik heb direct een wachtwoord ingesteld voor de root user.

Hoe doe je dit:
1. Open Systeemvoorkeuren en ga naar Gebruikers en Groepen.
2. Klik op het slotje. Bij het wachtwoordscherm kan je dus root zonder wachtwoord gebruiken...
3. Klik op Inlogopties
4. Klik op Verbind (of Wijzig)
5. Klik op Open Adreslijsthulpprogramma
6. Klik op het slotje. Ook hier werkt root zonder wachtwoord.
7. In de menubalk vind je nu bij Wijzig de optie om het root wachtwoord te wijzigen.

Ik kan nu de truc met root zonder wachtwoord niet meer gebruiken, gelukkig.

edit: Je kunt met hetzelfde stappenplan root helemaal uitschakelen, dat zal het probleem ook wel oplossen hoop ik. Niet geprobeerd.

[Reactie gewijzigd door rb338 op 28 november 2017 22:17]

Uitschakelen / deactiveren lijkt niet te helpen. Indien uitgeschakeld: wordt bij een login-poging weer geactiveerd zonder dat er een wachtwoord is ingesteld, zelfs als je voorheen een wachtwoord had ingesteld. Dan kun je dus gewoon weer met root zonder ww inloggen...
Jawel helpt wel maar je moet even een wachtwoord zetten als volgt in terminal:

sudo passwd root (en vul een wachtwoord in)
dsenableroot -d (en geef je eigen wachtwoord)

Je root account is nu van een wachtwoord voorzien -> zo kun je met de truuk niet opnieuw enablen
EN je root account is disabled zodat je die niet ziet op je login window.
Een toevoeging: je root user disablen werkt wel, maar de volgende keer dat iemand ermee de truc probeert uit te halen wordt deze opnieuw geactiveerd. Hij kan er dan niet meer mee inloggen, er staat immers een wachtwoord op, maar het account wordt wel weer gewoon actief!

Edit: Dit is in ieder geval zo op build 17C83a van de public beta...
Edit 2: ik ben volgens mij niet helemaal meer wakker. Ik heb over het terminal gedeelte heengelezen.

Edit 3: als je inderdaad deze stappen zo uitvoert via terminal, dan wordt het ww veranderd en root kan niet meer actief worden door de truc. Voer ze echter wel beide uit, ook als je je root ww al aangepast hebt via directory utility! Doe je dit niet, dan vervalt dat wachtwoord en kan de truc wl weer worden uitgevoerd.
Edit 4: wat ik ook raar vind: als ik mijn settings probeer te wijzigen met de disabled root user met het nieuw ingestelde wachtwoord, dan unlockt hij toch, ook al is root gedisabled.

[Reactie gewijzigd door computer1_up op 29 november 2017 00:09]

ook even geprobeerd, dit is ook in de 10.13.1 (17B48) versie zo

Edit: ik heb 'm nu ook via de terminal uitgevoerd (dus NA de tip van rb888 die ik uitvoerde), mijn root account blijft uit, maar ik kan wel systeembeheervensters ontgrendelen met root + password 8)7

[Reactie gewijzigd door monsieurpinot op 29 november 2017 00:07]

Als je root uitschakeld kun je er niet meer mee inloggen, om elevated rights te krijgen moet je natuurlijk wel een root/Admin account kunnen gebruiken.

Het wachtwoord aanpassen is dus de enige echte bescherming. Uitschakelen heeft geen nut aangezien je de elevated rights gewoon alsnog kunt krijgen.

[Reactie gewijzigd door mjl op 30 november 2017 00:02]

dus uitgeschakeld ≠ niet bruikbaar? En dan alleen om rechten te verkrijgen (want inloggen kun je er niet mee)
Prima bruikbaar, alleen niet zichtbaar bij het login scherm. Waarom Apple zo een grote fout maakt is een apart iets, het lijkt haast ergens wel op een Kernel bug. En niet iets in hun user interface zaken.
Het vervelende is dat het root-account dus weer automatisch in wordt geschakeld als je deze truc gebruikt. Uitschakelen heeft dus geen zin.
ik stelde eerste een wachtwoord voor de root account in en schakelde hem vervolgens uit,
vervolgens verdwijnt in het inlogscherm de optie om met een 'Andere' account in te loggen.

[Reactie gewijzigd door monsieurpinot op 28 november 2017 23:28]

En voor wie het liever wat geautomatiseerder wil omdat ie bijv. een hele reeks machines moet doen en daarbij ook graag een compleet random en sterk wachtwoord wil, is er een script verkrijgbaar op de volgende link: https://derflounder.wordp...unt-on-macos-high-sierra/
In eerdere versies van OSX stond root standaard uit. Ongelooflijk dit.
Als ik het goed begrijp staat dit account standaard ook uit in Sierra maar is de bug dat er een root account zonder wachtwoord wordt aangemaakt zodra je ermee probeert in te loggen in dat settings menu zonder wachtwoord.
Grappig, ik heb dit geprobeerd, maar bij mij doet hij het echt echt niet. Ik draai gewoon de laatste versie van MacOS en kan mij niet herinneren dat ik ooit het root wachtwoord heb gewijzigd. Misschien is het wel zo, maar die kans acht ik klein.

Ik heb al 200 keer root ingevuld zonder wachtwoord, maar ervaar dit probleem helemaal niet.

Toch maar voor de zekerheid wel even het wachtwoord van root nu gewijzigd, wel zo verstandig (just in case)
Het werkte bij mij het beste als ik als root probeerde in te loggen en een paar keer om enter ramde. Dan kwam ik er eigenlijk altijd in.

Tot nu toe is gebleken dat iedereen die claimt dat hij niet getroffen is door deze bug, de bug niet op de juiste wijze probeert te misbruiken.
Nouja, ik heb precies zo gedaan zoals in meerdere artikelen, posts en video's beschreven en voorgedaan word. Juister dan dat wordt het niet vrees ik..
Meerdere keren snel achter elkaar op enter geramd?
Zelfs dat.
Verschillende benaderingen geprobeerd. Helemaal noppes. Maargoed, dat is alleen maar beter. Daarnaast is de patch er al dus ik vind het wel prima.
Getest en werkt bij mij ook. Kan ook inloggen door bij het login scherm "other user" te kiezen en vervolgens in te loggen met root zonder wachtwoord.

Ernstige bug dit!

Snelle fix is:
- terminal starten
- sudo bash (om root prompt te krijgen)
- passwd (wachtwoord wijzigen)

[Reactie gewijzigd door Ascension op 28 november 2017 22:02]

Doe eens

https://apple.stackexchan...strator-account-on-my-mac

In theorie maak je dan ook een nieuw administratoraccount, waarmee je ook beveiliging omzijlt?
Deze 'theorie' klopt, sterker nog, deze methode bestaat al behoorlijk lang en wordt niet gezien als 'bug' zoals bij de methode in dit nieuwsartikel wel het geval is.

.AppleSetupDone verwijderen is niet mogelijk als:
- FileVault aanstaat.
- Er een Firmware Wachtwoord is ingesteld.

Er van uitgaande dat de persoon die dit doet de bovenstaande wachtwoorden niet weet natuurlijk :)

FileVault aanzetten is altijd een goed idee in mijn ogen, zorgt er voor dat je data niet zomaar toegankelijk is zonder wachtwoord maar het versleutelde volume zou wel verwijderd kunnen worden van buitenaf bij directe toegang tot het apparaat. (dus een schone installatie is mogelijk zonder wachtwoord)
Een Firmware wachtwoord is ook goed, zorgt er voor dat er niets anders kan opgestart worden behalve het als standaard ingestelde volume, wil je wat anders opstarten zal je het wachtwoord in moeten vullen, dit zorgt er ook voor dat een versleuteld volume niet zomaar verwijderd kan worden.

Deze 2 in combinatie aanzetten is de beste optie, ze complimenteren elkaar namelijk erg goed.

Kantnotitie: een beetje professionele dief heeft geen probleem om een firmware wachtwoord te verwijderen, ook zal een firmware wachtwoord eraf gehaald of doorgespeeld moeten worden als je mac ooit service nodig heeft bij een ARS / AASP.

[Reactie gewijzigd door joon op 29 november 2017 08:49]

Niet helemaal waar. Met Firmware password kan dit nog steeds. Alleen dan wel via extern apparaat. Zo heb ik ooit een macbook kunnen redden van de shredder.

Firware password verwijderen is met een beetje hardware echt een peulenschil. Kost letterlijk 10 minuten als je je huiswerk hebt gedaan en anders zelfs nog minder.
Je hebt gereageerd vr mijn edit, jammer :D
ik ben idd op de hoogte van dit soort apparatuur en de gemakkelijkheid hiervan, sterker nog, dit is al mogelijk in luttele seconden.

[Reactie gewijzigd door joon op 28 november 2017 23:03]

Haha. Dan nog kan je AppleSetupDone verwijderen als er een firmware password aanwezig is met de juiste tools. Simpel de schijf extern aan een andere mac hangen en je kan dat doen. Werkt dus alleen met macs tot 2015. Daarnoven blijkt geintegreerde opslag ineens best wel handig tegen diefstal.
Oh zo, ja, inderdaad.
Je kan ook het beste een firmware wachtwoord + filevault in combinatie gebruiken imo, heb m'n reactie daarop aangepast zodat dit wat duidelijker is :Y)

[Reactie gewijzigd door joon op 29 november 2017 08:57]

Had je bug eerst al geprobeerd in het Settings-menu zoals je in de video ziet?
Ik heb zonet eerst de bug gereproduceerd en daarna het root-wachtwoord aangepast via de Terminal. Ik kan nu niet meer inloggen als root in de System Preferences, dus deze fix werkt.
Ik kan inderdaad de bug reproduceren via het System Preferences venster.
Het vreemde is dat als ik via terminal su - doe en dan enter vlam (geen wachtwoord) hij netjes 'Sorry' zegt en niet root wordt. Dus het wachtwoord is niet leeg zo lijkt het?
Ja bij mij werkt hij ook in het settings-menu.
Nog interessant, in het filmpje lukt het pas na vaak proberen. Als ik in de gebruiker 'root' invul en dan mijn cursor in het lege wachtwoord veld laat staan, werkt het steeds direct.

[Reactie gewijzigd door samuvisser op 28 november 2017 23:45]

Ik vraag mij eerder af hoe het komt dat het soms niet werkt? Dat je kan inloggen als root zonder wachtwoord is logisch als die geen wachtwoord heeft. Maar waarom kan je soms niet inloggen als root zonder wachtwoord?
Het root account is standaard ge-disabled.
Als je als root probeert in te loggen wordt het root account ge-enabled maar wordt je nog niet ingelogd.

Als je hierna weer probeert in te loggen lukt het wel aangezien het root account nu ge-enabled is.

Daarom de fix: root account enablen en zelf een wachtwoord aanmaken.
Of Apple links laten liggen de komende tijd aangezien ze de laatste tijd echt extreem slordige fouten maken.
Waarschijnlijk kunnen ze zich geen goede systeemprogrammeurs meer veroorloven. De winst moet namelijk omhoog om de aandeelhouders tevreden te houden.
Je wordt wel naar beneden gemod, maar ik denk dat er wel een kern van waarheid in zit. De kwaliteit van OSX/macOS (en nu ook iOS11) laat serieus te wensen over de laatste jaren wat betreft bugs en stabiliteit. Zowel persoonlijke ervaring als een shitload aan klachten op internet.

Maar ja, het OS levert niet direct omzet op, dus zal het inderdaad snel als kostenpost worden gezien.
Wat een toepasselijke nick heb jij :)
Ken macos niet.

Maar ga er niet blind wachtwoord opzetten, tenzij je zeker weet dat er geen processen zijn die root zonder suid of authorized_keys gebruiken.

Heeft die root ook root rechten of kom je in een jail terecht ?
Je kan altijd wanneer je wil root activeren en een wachtwoord instellen, dat vormt dus geen probleem voor normale users.

[Reactie gewijzigd door WhatsappHack op 28 november 2017 22:47]

“sudo passwd -u root”
Is wat sneller en makkelijker :)
Bij deze kan ik bevestigen dat deze workaround werkt, dank!
Ik kan de bug ook reproduceren op 10.13.2 beta 5 (ongeveer 5 uur geleden uitgekomen).

En deze gebruiker vond de bug 2 weken geleden en dacht dat het een feature was (onderste reactie): https://forums.developer.apple.com/thread/79235
wow. Inderdaad.
Het is niet (meer) de onderste reactie, hier de direct link https://forums.developer.apple.com/thread/79235#277225
https://twitter.com/fristle/status/935670476214378496

13 november werd deze ‘hack’ als helpful tip op de de developer forums van apple geplaatst 8)7
Foutje op het einde van het artikel:
> In de tussentijd is er een workaround beschikbaar door de rootgebruiker uit te schakelen.
Dit is NIET de correcte workaround, de rootgebruiker is op macOS standaard uitgeschakeld. Deze bug activeert de uitgeschakelde rootgebruiker en dat zonder wachtwoord!
Om jezelf te beschermen tegen deze bug moet je dus zelf de rootgebruiker activeren en een wachtwoord toekennen.
Bedankt voor het erop wijzen. Het is inmiddels aangepast.
Als de bug niet enkel in die dialog box van System Preferences werkt maar ook vanop afstand via bijvoorbeeld Screen Sharing (geen idee of dit zo is), dan maakt het niet uit of je hem reproduceert of niet.

In ieder geval, better safe than sorry lijkt me :)
Wat ontzettend stom om dat zo op Twitter te zetten. Daar hebben we responsible disclosure voor. Wat een rotactie.

Ook stom van Apple maar dit is niet de manier om dat bekend te maken.
Hoezo? Alple heeft geen bug bounty voor mac os dus daar valt niks te winnen, en deze persoon heeft nu veel meer publiciteit dan wanneer er over een weekje een artikel zou verschijnen waarin staat dat apple een bug gepatched heeft die door iemand ondekt was.
Ja, maar wij hebben bij ons op het werk rond de duizend Macs waar vertrouwelijke informatie op staat, die nu iedereen die aan het overwerken is kan bekijken op de computer van hun collega's. Lekker dus... |:(

Dit is geen manier om met zoiets om te gaan dat zulke grote consequenties heeft. Je eigen eergevoel en financieel gewin als ontdekker is daar mijns inziens ongeschikt aan. Je aanzien in de security wereld trouwens ook. Als je als bughunter serieus genomen wil worden, moet je dit soort dingen absoluut niet doen. Bedrijven in de security sector zien gelukkig de waarde van responsible disclosure wel in.

[Reactie gewijzigd door GekkePrutser op 28 november 2017 23:06]

Ik heb jammer genoeg geen ervaring met het beheren van apple apparatuur. Echter is er voor apple niet net zoiets als voor Windows? Neem aan dat je met zoveel machines in een omgeving wel aan beheer doet.
In een Windows omgeving kan je dan bv dmv je SCCM pakket (of welk beheer/distributie programma je gebruikt) toch een script uit sturen om op alle machines die aan staan of gaan meteen het wachtwoord te wijzigen?
Ik heb jammer genoeg geen ervaring met het beheren van apple apparatuur. Echter is er voor apple niet net zoiets als voor Windows? Neem aan dat je met zoveel machines in een omgeving wel aan beheer doet.
In een Windows omgeving kan je dan bv dmv je SCCM pakket (of welk beheer/distributie programma je gebruikt) toch een script uit sturen om op alle machines die aan staan of gaan meteen het wachtwoord te wijzigen?
Dit hebben we bij ons helaas nog niet. Omdat de Macs nogal verspreid zijn over een heleboel landen, locaties en minder dan 1% van de computers uitmaken is dit denk ik nooit een prioriteit geweest. Dit is precies iets waar ik nu mee bezig ben (ik ben hier pas twee maanden geleden aan toegewezen), maar het is nog niet in produktie. Technisch werkt het al maar bij ons komt er veel procedure bij kijken. Inderdaad zou het dan zo opgelost zijn.

Overigens heeft Apple niet zelf iets dergelijks. Maar er zijn wel third party oplossingen zoals Jamf Pro (wat ook in Microsoft inTune geintegreerd wordt) en VMWare AirWatch. Wij gaan AirWatch gebruiken omdat we dat ook al voor mobiele apparaten hebben. SCCM kan je ook gebruiken maar de functionaliteit op Mac is zeer beperkt.
Met 1000 Mac's deed ik de aanname dat het wel een groot deel van het bedrijf was... zoveel bedrijven hebben dat niet eens dus blijkbaar werk jij in een mega concern.
Jammer dat je nog niet zoiets hebt want dat had jou een hoop werk gescheeld.
Nogmaals ik heb geen ervaring met het beheer van apple apparatuur maar ik geloof dat Ivanti/LANdesk het ook kan (mocht Airwatch toch niet bevallen)

Succes in ieder geval :)
Opzich lijken de consequenties in mijn ogen niet zo erg groot. Mij lijkt dat de meeste bedrijven of nog niet hebben gepdate om dit soort kinderziektes te vermijden of de root user al een ander wachtwoord hebben gegeven. Verder is het wachtwoord veranderen van de root user ook niet erg ingewikkeld.
Niet groot, todat jouw loonstrookje op straat ligt ;) Hoe vertrouw je jouw collega's? Trust is good, control is better :) (En ja ik weet wie dit gezegd heeft maar in de security wereld geldt dit wel).

Inderdaad zijn de meeste users nog niet over naar High Sierra, bij ons met name omdat er nog een vervelende bug was in 10.13.1 die in 10.13.2 opgelost gaat worden (die is nog niet uit). Namelijk dat de autoproxy configuratie niet werkt voor processen die als LaunchDaemon draaien.

Niettemin zijn sommige users dat wel, en daarvoor is dit wel degelijk een probleem. De root user is meestal niet ingesteld omdat Apple juist afraadt om dit te doen. Als deze disabled is zou je toch niet moeten kunnen inloggen. En dat is precies wat er nu stuk is.

Maar inderdaad, het is een geluk bij een ongeluk dat dit geen 2 maanden later is gebeurd en iedereen over was geweest op High Sierra. Maar dit is geen kwestie van 'de kat uit de boom kijken'. Dit soort bugs kunnen op elk moment ontdekt worden. Daarom zijn er juist procedures over hoe je er mee omgaat.

Wel vind ik het heel stom van Apple dat dit blijkbaar niet iets is waar ze geautomatiseerd op testen. Juist gezien hun advies de root user niet aan te zetten.

[Reactie gewijzigd door GekkePrutser op 28 november 2017 23:23]

Ik vind dit nog redelijk responsible.
Dit is iets wat erg makkelijk te fixen is door de user zelf. Als mensen afhankelijk van een patch waren was het inderdaad een compleet ander verhaal geweest.

Verder is dit geen bug maar een functie( no joke).

https://mobile.twitter.co...35632943669792769/video/1

Zelfs op keynotes laten ze zien dat het root account wordt enabled na de eerste keer "foutief" inloggen.

Dat dit in een build zit die klanten op hun pc hebben.... En dat 2 maanden na die password hash bug... Windows XP is er niks bij.
Uhhh.... Hate to be the one to break it to you... Maar dat filmpje is nep.
Waarom zit er dan ooit code in een build die ervoor zorgt dat het root account wordt enabled.
“Niet groot, todat jouw loonstrookje op straat ligt”

Wat maakt het uit dat iemand weet wat je verdiend? Mensen doen altijd zo geheimzinnig over salarissen Haha.
Altijd leuk dit soort reacties. Gooi maar even een scan van je salarisstrook online dan :|
1863 netto verdien ik, lekker belangrijk dat mensen dat weten.
Als een loonstrookje niet beveiligd is is dat een apart probleem. In ieder bedrijf waar je werkt heb je sowieso altijd wel mensen die hun compute niet locken.
Computer niet locken = usererror. 1ste keer waarschuwen, 2e keer serieus gesprek, 3e keer ontslag!

Als een gebruiker zijn computer niet locked dan moet je in principe alle data van die gebruiker als "publiek bekend" beschouwen, want misschien stond zijn wachtwoordmanager open of was die wachtwoordmanager te openen zonder een nieuw wachtwoord in te hoeven voeren.
Ik heb nog nooit van een bedrijf gehoord waar dit de werkelijkheid is, wellicht wishfil thinking vanuit security, maar geen praktijk.
Ondanks dat Apple zelf geen bug bounty programma heeft, zijn er verschillende andere bedrijven, zoals Zerodium, die graag willen betalen voor een zero-day root authentication bypass vulnerability.
Even een vraagje: wat doet zerodium er dan mee? Kan dat niet zo snel op hun site terugvinden of ze dit bijvoorbeeld meteen aan apple zouden melden. Het op deze manier de wereld inslingeren heeft tenminste het voordeel dat apple aan het einde van de week een security update klaar heeft staan en gebruikers er wat aan kunnen doen.
Zij verkopen het door aan overheden.
Zoals @Sammiejj aangeeft, denk ik inderdaad dat Zerodium dit doorverkoopt. Op de FAQ van Zerodium staat:

Who are ZERODIUM's customers?
ZERODIUM customers are mainly government organizations in need of specific and tailored cybersecurity capabilities, as well as major corporations from defense, technology, and financial sectors, in need of protective solutions to defend against zero-day attacks.

Access to ZERODIUM solutions and capabilities is highly restricted and is only available to a very limited number of organizations.
In de macOS/tech wereld staat Zerodium daar bekend om.
Vergeet niet: fysieke toegang is schijf eruit en iedereen kan alles lezen - tenzij je je hele schijf versleuteld hebt natuurlijk.
Uiteraard merk je het wel als iemand je schijf steelt en is deze manier veel makkelijker te misbruiken en dus wel veel enger - maar wil het wel een klein beetje in perspectief plaatsen.
Juist op Macs heeft bijna iedereen filevault aan, omdat het gewoon zo ontzettend gemakkelijk is. Er zitten eigenlijk geen nadelen aan.

Schijf er uit kan ook heel moeilijk bij Macs, bij de nieuwste zit zelfs de SSD op het moederboard gesoldeerd. En de oudere types zijn meestal van een type dat alleen in een zelfde soort Mac werkt. Bovendien ben je dan uit FileVault geknikkerd. En deze bug werkt niet op een Mac die niet geboot is (filevault kan je als root user namelijk niet unlocken).

En verder: In een kantoor omgeving een computer openschroeven na werktijd valt nogal op. Met deze bug kan je zo ff naar de computer van je collega lopen (denk aan personeelszaken of loonadministratie), "root" intypen en je tegoed doen aan alle informatie die er op staat. Vergeet de impact daarvan niet.

[Reactie gewijzigd door GekkePrutser op 28 november 2017 23:28]

Ah, oke, dat wist ik niet helemaal.
Dus in principe zijn bestanden dus versleuteld bij de meeste mensen.
Maar als je computer dus opstart, kun je dus direct inloggen met root zonder ww en dan is de hele, versleutelde, schijf wel gemount en beschikbaar?
Nee, je moet bij het aanzetten een paswoord invoeren van een gebruiker die admin rechten heeft. Alleen hun wachtwoorden worden als encryptiesleutel voor het versleutelde volume opgeslagen. Dit moet een normale gebruiker zijn, 'root' is dat niet.

Dus het inlogproces wordt verplaatst van na het booten naar voor het booten; na het inloggen in filevault logt de Mac na het booten gelijk door naar je desktop (dat is ook een reden dat mensen het vaak aan zetten, geen wachttijd meer tussen aanzetten en inloggen).

Dus als de computer uit staat kan je er met deze bug niet in. Staat hij aan of in de slaapstand dan dus wel. (Slaapstand weet ik niet 100% zeker overigens maar ik neem aan dat de disk niet geunmount wordt).

[Reactie gewijzigd door GekkePrutser op 28 november 2017 23:04]

Helder.
Dat maakt het eigenlijk dus nog erger: een versleuteld volume was dus onbenaderbaar, maar nu hoef je enkel maar te wachten tot iemand wegloopt (en de mac wel vergrendeld) en dan kun je dus overal bij...
Dan kan ik het toch niet laten dit wat te relativeren.

Ik wed dat de meeste Macs-gebruikers juist niet heel de harde schijf hebben versleuteld. Dat heeft niet alleen maar voordelen natuurlijk. Als er een keer wat 'hapert' – ja echt, Macs zijn ook maar apparaten met veel standaard onderdelen die kapot kunnen gaan – is file recovery etc geen optie meer. En met name op laptops zal de accuduur er niet beter op worden. Daarbij denk ik dat de gevoeligheid van de inhoud in veel gevallen niet boven het niveau uitkomt van.. sites met vrouwelijk / mannelijk schoon. Inloggegevens etc zet je gewoon in een password manager – dus wel versleuteld – uiteraard.

Bij de nieuwste 15' MacBook Pro zit de SSD blijkbaar vastgesoldeerd maar dan weer niet op het 13' model. Verder er zijn nog Mac Mini's, Mac Pro's, iMacs.. Dit is dus tot nu toe eerder de uitzondering dan de regel!

'Even' eruit halen zal sowieso bij laptops niet aan de orde zijn maar bij eerdere laptops en zeker de desktop modellen kan k het zelfs.. ;)
Bij mij staat het uit om precies die reden: data terughalen als er iets stuk gaat en de backup (nog) niet gemaakt is.
Klopt, tegenwoordig zelfs standaard aangevinkt bij iedere macOS installatie.
Nu wordt het iig snel gepatched ;).
Ja nu gaan ze haasten om een patch uit te brengen. Dan zijn ze nog enkele dagen te laat, en introduceren ze wellicht problemen die ze tijdens het haasten van de patch niet gevonden hebben.

Hoe dan ook is dit niet de situatie die je wil hebben als je met Macs in een zakelijke omgeving werkt.
Het lijkt me niet echt een lastige patch.
Toch hebben ze een fout gemaakt tijdens het haasten van die patch en daarbij filesharing stukgemaakt:

https://www.theguardian.c...rity-flaw-emergency-patch

Precies mijn punt dus...
Voor zover ik kan zien gaat het niet om een Security specialist. Voor hetzelfde geld ontdekt iemand het toevallig en komt hij op Tweakers vragen of hij iets verkeerd geconfigureerd heeft en ligt het via deze weg op de straat.
Nog beter, je kan zelfs als root inloggen op het login scherm.

Beetje zoals in Windows 95/98 dat je gewoon een gebruiker kon invoeren die nog niet bestond en dan maakte hij een nieuw account voor je aan... Alleen is dit account dan het machtigste account op het systeem.
Maar onder welk account log je dan daadwerkelijk in? Echt als root user, of pakt ie gewoon de default gebruiker op t systeem?
Echt als root.

Bovenin staat ook "System Administrator" en "whoami" op de terminal geeft ook root

EDIT: Oplossing is om even gewoon als root het wachtwoord te veranderen ("passwd") of volgens apple (Zie artikel) om het root account compleet uit te schakelen.
Ziet er naar uit dat ze gewoon vergeten zijn om no-login zonder wachtwoord aan te zetten voor root

[Reactie gewijzigd door smiba op 28 november 2017 22:12]

Bi-zar. Wel knap dat dit zolang onopgemerkt is gebleven eigenlijk!
Zoals in het artikel staat hebben eerder versies hier geen last van, dus het is niet zo wonderbaarlijk dat het nog niet gevonden was.
Wat eng dit, zojuist geprobeerd en het werkt gewoon in n keer. Vervolgens heb ik inderdaad toegang tot alle bestanden op mn mac.

Wtf Apple
Deze bug schakelt je root user in als het uitstaat, dus je zult het aan moeten zetten en vervolgens een sterk wachtwoord instellen.
In Windows 95/98 kon je gewoon op annuleren drukken en dan werd je gewoon ingelogd :P
Nog erger dan ik me herinnerde dus :+
Je zou toch hopen dat Apple leerde van fouten van de concurrentie, 20 jaar geleden...!
De Windows 95/98 login functionaliteit was ook nooit bedoeld als sluitende beveiliging (je had sowieso rechten naar alle andere accounts toe), maar om gebruikersprofielen te laden.
Het is niet de eerste keer dat er een degelijke bug in macOS boven water komt drijven. In oktober bleek dat het mogelijk was om het wachtwoord van een apfs-volume te tonen op de plaats van de hint.
Alleen heeft die bug gewoon niks gemeen met deze bug en was het ook geen globale bug, alleen een bug in Disk Utility wanneer je een custom APFS container ging maken. De bug was dat nadat je de textboxes van het wachtwoord en de hint ingevuld had de waarde van het wachtwoord veld twee keer gelezen werd, een keer om het wachtwoord te lezen en een keer om de hint op te slaan, terwijl dat natuurlijk de textbox voor de hunt had moeten zijn.
Nou, die bug is nog erger dan deze root-bug.
Bij de root-bug lijkt fysieke toegang nodig en iedereen weet: fysieke toegang is einde van elke beveiliging. Bij Windows kun je met een usb-stick booten en het admin-ww eraf halen en anders haal je gewoon de schijf eruit en lees je hem elders in.

Bij de apfs-bug ging je juist een versleutelde schijf maken op juist deze ellende tegen te gaan, en dan wordt dat wachtwoord weer weggegeven. Als je beide bugs dus op je systeem present hebt, kan iemand dus gewoon inloggen als root en daarna je versleutelde volume mounten met het wachtwoord wat erbij wordt gegeven :-)
Met bitlocker aan geld dit natuurlijk niet, dan kan je die truuckjes niet meer doen.
Bij de root-bug lijkt fysieke toegang nodig
Blijkbaar werkt dit ook over remote logins.
Misschien hebben de bugs technisch niets met elkaar gemeen, maar ze zijn wel vergelijkbaar in die zin dat ze beide van een bijna ongelooflijke slordigheid zijn. Dit soort bugs verwacht je in goedkope chinese ip-camera's en obscure cms-systemen, maar niet bij Apple. En dat is zorgwekkend.
Wat een enorm slordig lek in MacOS... ben ik niet van ze gewend. Ben benieuwd hoe dit er in hemelsnaam in heeft kunnen sluipen en hoe snel ze dit gaan patchen..
Je kunt Apple vandaag de dag echt niet vergelijken met Apple van 5 jaar geleden.
Alles muv de prijs gaat naar beneden.
Ja sinds Steve Jobs er niet meer is gaat het bergafwaarts.
Je ziet het, je mag dat hier niet zeggen want dan krijg je direct een -1 op dit forum.
Maar een feit is een feit en daar ontkomt niemand aan.

Alles kost steeds meer en de vernieuwingen zijn dingen weghalen bij Apple. Als je kijkt naar de security issues en de bugs na nieuwe releases dan is er een duidelijke downtrend zichtbaar.
Je went er wel aan hoor ;) . Maar alle gekheid op een stokje, het is vreemd genoeg niet de eerste keer dat we dit soort fouten zien. Recent nog hadden we het wachtwoord dat als hint werd opgeslagen. Het lijkt er dan ook op dat er een onervaren persoon met de login code heeft zitten knoeien en er verschillende security flaws in heeft gestoken. Ik hoop dat na dit tweede probleem op korte termijn men bij Apple een grondige audit van heel dit deel van de code gaat doen.

Op dit item kan niet meer gereageerd worden.


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

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