macOS FS Tricks
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Permissions in a directory:
read - you can enumerate the directory entries
write - you can delete/write files in the directory and you can delete empty folders.
But you cannot delete/modify non-empty folders unless you have write permissions over it.
You cannot modify the name of a folder unless you own it.
execute - you are allowed to traverse the directory - if you don’t have this right, you can’t access any files inside it, or in any subdirectories.
How to overwrite a file/folder owned by root, but:
One parent directory owner in the path is the user
One parent directory owner in the path is a users group with write access
A users group has write access to the file
With any of the previous combinations, an attacker could inject a sym/hard link the expected path to obtain a privileged arbitrary write.
If there are files in a directory where only root has R+X access, those are not accessible to anyone else. So a vulnerability allowing to move a file readable by a user, that cannot be read because of that restriction, from this folder to a different one, could be abuse to read these files.
Example in: https://theevilbit.github.io/posts/exploiting_directory_permissions_on_macos/#nix-directory-permissions
If a privileged process is writing data in file that could be controlled by a lower privileged user, or that could be previously created by a lower privileged user. The user could just point it to another file via a Symbolic or Hard link, and the privileged process will write on that file.
Check in the other sections where an attacker could abuse an arbitrary write to escalate privileges.
Files with .fileloc extension can point to other applications or binaries so when they are open, the application/binary will be the one executed.
Example:
If you can make a process open a file or a folder with high privileges, you can abuse crontab to open a file in /etc/sudoers.d with EDITOR=exploit.py, so the exploit.py will get the FD to the file inside /etc/sudoers and abuse it.
For example: https://youtu.be/f1HA5QhLQ7Y?t=21098
If a file/folder has this immutable attribute it won't be possible to put an xattr on it
A devfs mount doesn't support xattr, more info in CVE-2023-32364
This ACL prevents from adding xattrs to the file
AppleDouble file format copies a file including its ACEs.
In the source code it's possible to see that the ACL text representation stored inside the xattr called com.apple.acl.text is going to be set as ACL in the decompressed file. So, if you compressed an application into a zip file with AppleDouble file format with an ACL that prevents other xattrs to be written to it... the quarantine xattr wasn't set into de application:
Check the original report for more information.
To replicate this we first need to get the correct acl string:
(Note that even if this works the sandbox write the quarantine xattr before)
Not really needed but I leave it there just in case:
macOS xattr-acls extra stuffBundles contains the file _CodeSignature/CodeResources which contains the hash of every single file in the bundle. Note that the hash of CodeResources is also embedded in the executable, so we can't mess with that, either.
However, there are some files whose signature won't be checked, these have the key omit in the plist, like:
It's possible to calculate the signature of a resource from the cli with:
A user can mount a custom dmg created even on top of some existing folders. This is how you could create a custom dmg package with custom content:
Usually macOS mounts disk talking to the com.apple.DiskArbitrarion.diskarbitrariond Mach service (provided by /usr/libexec/diskarbitrationd). If adding the param -d to the LaunchDaemons plist file and restarted, it will store logs it will store logs in /var/log/diskarbitrationd.log.
However, it's possible to use tools like hdik and hdiutil to communicate directly with the com.apple.driver.DiskImages kext.
If your script could be interpreted as a shell script you could overwrite the /etc/periodic/daily/999.local shell script that will be triggered every day.
You can fake an execution of this script with: sudo periodic daily
Write an arbitrary LaunchDaemon like /Library/LaunchDaemons/xyz.hacktricks.privesc.plist with a plist executing an arbitrary script like:
Just generate the script /Applications/Scripts/privesc.sh with the commands you would like to run as root.
If you have arbitrary write, you could create a file inside the folder /etc/sudoers.d/ granting yourself sudo privileges.
The file /etc/paths is one of the main places that populates the PATH env variable. You must be root to overwrite it, but if a script from privileged process is executing some command without the full path, you might be able to hijack it modifying this file.
You can also write files in /etc/paths.d to load new folders into the PATH env variable.
This will generate a file that belongs to root that is writable by me (code from here). This might also work as privesc:
POSIX shared memory allows processes in POSIX-compliant operating systems to access a common memory area, facilitating faster communication compared to other inter-process communication methods. It involves creating or opening a shared memory object with shm_open(), setting its size with ftruncate(), and mapping it into the process's address space using mmap(). Processes can then directly read from and write to this memory area. To manage concurrent access and prevent data corruption, synchronization mechanisms such as mutexes or semaphores are often used. Finally, processes unmap and close the shared memory with munmap() and close(), and optionally remove the memory object with shm_unlink(). This system is especially effective for efficient, fast IPC in environments where multiple processes need to access shared data rapidly.
macOSCguarded descriptors are a security feature introduced in macOS to enhance the safety and reliability of file descriptor operations in user applications. These guarded descriptors provide a way to associate specific restrictions or "guards" with file descriptors, which are enforced by the kernel.
This feature is particularly useful for preventing certain classes of security vulnerabilities such as unauthorized file access or race conditions. These vulnerabilities occurs when for example a thread is accessing a file description giving another vulnerable thread access over it or when a file descriptor is inherited by a vulnerable child process. Some functions related to this functionality are:
guarded_open_np: Opend a FD with a guard
guarded_close_np: Close it
change_fdguard_np: Change guard flags on a descriptor (even removing the guard protection)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
