Mac Wipe Reverts OS

[ltorresmdc]

Hey guys, I noticed that wiping our Macs reverts them to Ventura from Sonoma and was wondering if this is expected behavior. If it is, does anyone have recommendations for how we can get them updated as soon as they've restarted? If this is not expected behavior, does anyone know of a proper fix?

[AlexHoffman · Accepted solution]

This is expected behavior with M-chips. What I've been doing instead is going into system settings > general > transfer or reset and wiping the mac from there. This method reinstalls a fresh copy of the current OS installed on the device. In my testing, if a device is wiped from the Recovery environment, the recovery disk always reverts to the original OS the device shipped with, I have yet to find a way to update the recovery partition OS to the latest version permanently. 

[jamf-42]

if the Mac is on 14 and you send a wipe from JAMF it will do an 'remove content and settings' and won't change the OS.. no need for any endpoint interaction.. 

[howie_isaacks]

You can also download the IPSW firmware restore files here:

https://mrmacintosh.com/apple-silicon-m1-full-macos-restore-ipsw-firmware-files-database/

Use Apple Configurator on another Mac to do a full restore of the Mac and install what ever (compatible) version you want. 

https://support.apple.com/en-ca/guide/apple-configurator-mac/apdd5f3c75ad/mac

Normally I use Erase All Contents and Settings. It's a lot faster but sometimes it's necessary to revert to an older macOS.

[Bol]

@ltorresmdc There are fallback recovery's that are created / updated after macOS updates. I believe laying down IPSW restore as @howie_isaacks mentioned, will also create / update those partitions.
More details: https://eclecticlight.co/2022/06/29/startup-and-recovery-modes-on-m1-and-m2-macs/

With erasing, one of the tools i make available, is a Self Service item (script / api call) that sends the mdmerasedevice command;

mdmCommand=$( /usr/bin/curl \
--header "Authorization: Bearer ${bearerToken}" \
--header "Content-Type: text/xml" \
--request POST \
--silent \
--url "${jamfpro_server_address}/JSSResource/computercommands/command/EraseDevice/passcode/000000/id/${computerID}" )
echo $mdmCommand;

 Oh wait, an awesome @talkingmoose has already posted his for everyone!? :D Thank you for sharing all your hard work, it's always appreciated!!
https://gist.github.com/talkingmoose/d8dbdbc920cbaddd7d60f44f17bf268a

[mjhersh]

A word of advice to anyone considering this: it is extremely dangerous to put Jamf API credentials in a policy script. Regardless of whether it is hardcoded in the script or passed as an argument in the policy, this can be extracted on the client side. In this particular example, a user with those credentials would be able to erase any device enrolled in Jamf.

Anything that requires credentials should be run on a secure server, not on clients. You can accomplish this in Jamf using webhooks; it's a pain to set up, but it is the only way to do something like this securely.

[jamf-42]

Agreed, been saying it for years and have had JAMF confirm this.. API calls are one to many.. from your admin Mac or app.. they are not many to many from endpoints to JAMF..  

[Bol]

It wasn't really about how the token was being generated but there's one in every thread..

I have a function in my script using the encrypted strings found here;
https://github.com/brysontyrrell/EncryptedStrings

[mjhersh]

That's better than nothing, for sure, but ultimately it is only obfuscation. Both the encrypted string AND the decryption key are available on the local Mac, and could be extracted by a savvy adversary. For credentials with the ability to erase any Mac in Jamf, I'd want to be very very careful.

I don't presume to know what's appropriate in your environment, but I still want to point out for other readers that this is not best practice in general, and it increases your attack surface.

[Bol]

Only the salt and passphrase are local, encrypted string is stored in the policy.
You may be right about best practise but at least it should make you feel less dirty

[mjhersh]

Arguments configured in the policy are also available on the local Mac, just in a different place. You can see them using `ps ax`. The arguments can be viewed without root access, while the script file itself is only readable by root.

Using encrypted arguments solves a few problems; it is much more secure than passing UNencrypted arguments, and it allows you to hide the information from other Jamf admins who have access to only scripts (which are global) or only policies (which are site-based). These are legitimate use cases, and I don't mean to suggest that the EncryptedStrings technique is invalid. Just be aware that it does not effectively hide anything from the end user if they are a local admin with sudo rights.