Exploiting Directory Permissions on macOS

okay uh welcome everyone to my talk about exploiting directory permissions on mac os my name is uh chabafitsu and i'm working for offensive security so just a briefly about myself right now i'm a content developer at offensive security i used to be a red and blue teamer before that for about eight years and recently i started to do mac os research exploitation i have live two kids i love hiking uh especially in the alps and i love to do yoga so what i will talk about today uh briefly first i will discuss the mac os file system permissions the entire model then we will talk about how to find box then i will talk about other box

and lastly how we can prevent these attacks i will start with going over the mac os file system permission model which we need to understand uh in order to exploit all these permissions issues now mac os is based on a psd so on a on a very base case it follows the pro 6 5 permission model um if you are familiar with any nik space system [Music] essentially this is what you will see everywhere else so every file and directory has a set of permissions uh on the computer which consists of the user owner permission then the group owner permissions and lastly and everyone or the world permission as it's being called now each of these uh one by one has a

read write and execute permission so in overall we have nine bits basically that controls the very basic permissions now with files having read write execute permissions is kind of straightforward it speaks to itself like if you have a read access to a file you can read it if you have bright access to it you can write to it and if you have execute permission on the file file then you can execute it uh if it's uh if it's an executable now with directories it's not that straightforward i think a read permission on a directory means that you can enumerate the directory entries so basically you can list what's inside the directory right access to the directory means that you can

delete and write files to the directory regardless of the permissions of the file and execute on a directory means that you can traverse the directory and that you can also access the file contents in that directory if you don't have this right you can't access any files in the in the directory or any subdirectories now this set of permission can create some corner cases which you would think that you will never face but in reality there are so let's say we if we have a directory with read access only uh that means that you can't access any files in that directory because you don't have any execute permission it will also involve that auto read access would mean that you can

list or enumerate entries in the directory because you don't have execute rights you can't enumerate them really if you have only execute permissions uh on a directory you can't list files because you don't have read permissions but if you know the name of the file you can still access it now imagine the following experiment make a any directory create a file inside it in this example i create aaa and putting aaa into the file called a i change the permissions of aaa to 777 which means that i will grant read write execute to the user to the group and to everyone else and of course i can list the contents of aaa now if i change the permissions of

the restricted directory to 666 which means read write to everyone to the user to the group and everyone but no execute for anyone else i can't get the contents anymore of the file now interestingly if you try to list the contents of restricted you will not see anything although you have read access but again you don't have execute now you can try to directly read the file or the file attributes it will be denied and now you can change back the permissions of restricted granting execute to to the user to the group and to everyone and again the file is still there you can still see it so if in case you as a user

don't have execute permissions on a directory but maybe you have permissions on the file maybe you can find a way to leak that file through an exploit and we will see a case for this because normally because of the directory permissions you wouldn't be able to see or access that file but in case you can leak out that file somehow to an external location you can read it contents if you have read write executable directory it means that you can delete and create files regardless of the files permissions or file owner especially regarding the delete one so if you have right access to a directory and there is a file owned by root it means that you can delete it

which we will abuse in in many cases now there are so called flag modifiers for each files there are many of those i will not detail all of them uh here from an exploitation point of view there are two important ones there is the you change unchanged or you immutable uh flag these are really all the same it means that no one can change the file until the flag is removed so if the file is owned by root and it has this unchanged flag even if you have right access to the directory you cannot delete this file so it can prevent exploitation restricted this is a macos specific flag it means that the file or the directory

is protected by sip sip stands for system integrity protection it's basically enforced by the sandbox and it protects system core files and system core directories and not even jute has right access to those location you need to have special entitlement which obviously is only handed out to apple binaries that can actually write to these locations you can use the ls-l to show these flags if you do it on the root folder you will see a bunch of these you will see a bunch of restricted locations which are the typically the system being uh usr var uh ford directories are osc protected and the hidden here refers to being hidden from finder so if you just

list these in in terminal you will see these locations but if you go to finder by default you you will not see these locations you need to unhide them there is another interesting bit that can affect our exploitation capabilities it's the sticky bit on directories it will mean that the file system will treat these files in a special way so basically if you have a file in the directory where the sticky bit is set only the file owner the directory owner or root user can rename or delete the file now this is typically applied on the temp directory and it's for preventing users from deleting uh each other file now you have right access to the temp

directory and if we go back to the regular posix model it would mean that you can delete anyone else file there but because of the sticky bit you cannot do that there is another important thing one on mac os it's the access control list it's basically a more granular access control than the traditional posix model it will work with creating access control entries to various files or directories and it can be really applied to multiple users multiple groups and you have more rights than the basic three in the in the posix model for directories it means that you will have list search at file add subdirectory delete child for file it's read write execute and

append uh which is a fourth one so you can be really more granular with controlling access in my experience i haven't really seen this overly used but you might run into it now there is an another thing which i think is much more limiting than the uh acs on file and that's the sandbox now sip which i mentioned before the system integrity integrity protection is also enforced by the sandbox and uh sandbox can further restrict your file access so there are many sandbox profiles uh on the system in these locations that you can see on the screen and those can really limit you to certain locations regardless of your user so there might be a daemon

process running as root which would mean that you can really access almost any any place on the system but maybe if you have a sandbox profile limiting you to only access certain directories this will take effect and and it will be more restrictive this is an example for sandbox profile these are written in svpl language uh i will not detail that here it's not a sandbox talk but if you open these sb files um i would say even without knowing the sbpl language you can read through and it will be mostly self-explanatory uh for example here we have hello five five right and the literal means that those specific files basically

so this was for the basic permission model and then let's see how we can find uh box so there are two methods the static and dynamic way for identifying uh box i mostly use the static option now here we can basically look for various file system permission combinations which [Music] if found could mean that there is an excludable scenario

so the first one is when the file owner is root but the directory owner is different and this usually goes together with the third one where the file owner is sued but through one of your group memberships you have right access to that directory this means that you can delete that file which is on my own by root and maybe mess around with that this is what we mostly abuse in the in the following cases there is also another case when the file owner is not true so it's owned by the user and by the directory only suit now this could happen maybe because others have right access to that directory uh not just suit but also because of

there is a root process touching that file but then later change changes the ownership of that file and the last one is when the file owner is not root but the group ownership is real which is really unique to the root user and the parent folder or directory isn't is not root owned so you can again mess that with that file and maybe gain some real group ownership through a bug so it's kind of similar to the first or third one but not targeting the the user but the group ownership now there is a dynamic method basically you can monitor for very similar relationship dynamically you can use tools like fs usage or objective c's file monitor

tool i think you can find the same scenarios then we come with the with the static method but the main benefit is that you can find cases uh for example when there is a root process touching the file in a in a location that you can control but then later it changes the ownership of the file to your user maybe an installer this means that you cannot find it with the static method because the ownership of the file is already modified but you can find it through through dynamic monitoring so let's see the box again the general idea here uh what i will mostly abuse uh the goal is to redirect the file operation to a location we want

and the typical process of the exploitation is we delete the file place a sim link or a hard link and and wait and see what happens with that sim link or hard link that we placed there can be a couple of problems with our symlink or hard link so the first is although the process is running as root because of its sandbox profile it cannot write to a location we want so i i redirect the network the next one is maybe there is a sim link or hard link but instead of following that it will simply overwrite the file so we can cannot do anything about this the third one is let's say we successfully redirected the

file operation and the problem is that the file is most likely still owned by root which means that we cannot modify its contents so we need to find a way to to control the file contents if we cannot do that it means that we will only have like a an arbitrary override vulnerability but not a full-blown privilege escalation unfortunately we can't control the contents of the file in most cases but we will see a few interesting scenarios there where we can do that and again if we have case one or two where it's either limited by the sandbox uh or it's not following links then it's not really a bug although the permissions are not ideal

so how we can control the file uh or by it's important we need to find a way again to inject some data into the files on by root or let's say there is a file maybe a some configuration file for uh for an av or some security products or or or anything else uh which is controlling the product itself if the file is in a changeable location you can delete that file create a new one with your custom content and you potentially you can bypass something or do something interesting uh with the product itself okay so the first one will be the install history please file uh vulnerability this was a macos vulnerability so whenever

anyone is installing an application on mac os the either from app store or from a package the system will log into call file install history plist which can be found in the library receipts directory now add menu admin users have write access to this location which means you can delete the file place the sim link and because the sim link will be followed you will get arbitrary overwrite unfortunately we can't really control the contents uh or only in a very limited way uh on the screen you can see the the plist file how the uh how this install history pls file looks like you can see that there is a date you can affect it but again it's pretty

limited there is display name of the application application version package id and so on so you can play around with these names but you cannot really do much beyond these to trigger this uh once you place the same link you can just install something maybe from the app store the next one is an adobe reader installer vulnerability so when you install at adobe robot reader on mac os there is a file in the temp directory uh with that long name and basically preorder installation you can create a sim link which will be followed by the installer which means you can overwrite an arbitrary file unfortunately the content of this plist is fixed so there is nothing really you can do

about it uh the next mug is kind of interesting because you could grant permissions to please files so with this bug you can grant read write read write read permissions to any plist file on the system by abusing this diagnostic message history plist file which can be found in the library application support crash deporter directory again this directory allows admin users to to write so you can delete the file place a sim link and and it will be followed to some extent so it will not be overwritten so sorry the file that you are playing it pointing to is will not be overwritten but if that file is a plist file the process will change its permission

to read write read write read because that's the expected uh permission on this diagnostic messages history plist file which means that you can grant word read access to any playlist file on the system and you can also grant group write access to any plist file on the system and you can trigger it by going to the privacy pane and changing the analytics and the improvements configuration uh the next bug the mac os phone hoover vulnerability and this was a an information leak so the library fonts uh directory has a group right permission set so admin users can write to these locations location and can drop any file here i think this permission is not needed and i will talk about it

uh a few minutes later why and this is the the directory that contains the system byte fonts and because i have already have bright access to these locations i started to look on to look into it now what happens when you install a font on mac os so you double click the font and this is the the screen you you will get you can set the install location to either computer or user the user location will be on your in your home folder in the library fonts directory and the computer location will be the library fonts directory that i just spoke about you press install font uh you select the font on the validation screen install ticked

and if you choose to install a system-wide font then you will get an authentication prompt this is why i said that i think having admin write access to the to the library fonts location is not needed because you will be prompted for authentication anyway so if you are authenticated then there is really no reason to have write access and then the file will be copied now i started to experiment with this and what i noticed that siblings hardlings don't work they will be removed and you can't win the race condition also phone hoover is pretty much restricted by the sandbox so even if it was followed i wouldn't really gain anything the file disclosure is happening

regarding of the source file or on on the installation installation process and not the the target so between the steps when you select install font and then install ticked the file is not locked by the application which means that you can replace the font with a sim link and that will be followed during the copy now what do we really gain with this because if we think about it at first there is a root process because we want to install uh a system font it will move a file from its original location with its original permissions to a place where we have already write access and again the file permissions are remain the same now at first it doesn't look interesting

at all but if we remember the the posix permissions it could actually mean an information leak so imagine the scenario that when you don't have execute permission on a specific directory but there is a file inside that place where you have read permissions on that on that file so that means that that we can leak that file through this process which is running as root to a location library fonts in this case where we have execute permissions so we will be able to read the contents of the file

so yeah this is how the the exploitation work uh if we check the private bar on mdsu uuid token idp list this is a file where we have uh read permissions on it but because we don't have execute permissions on the directory we cannot read it now we can use this phone mover bug to move this file out to the library fonts and then we can uh read it contents so the fix by upper was that they will actually verify the the replacement and the symlink or hard link cannot be followed the next one is again a simple arbitrary file override vulnerability in diagnostic messages and the reason this is more interesting because i could achieve

partial uh control of the of the content so again it's the usual story we have write access to this directory there are a bunch of asl log files all of them on own by root we can delete it and use hard links instead of sim links and what i found that you might need to reboot for the hard link to to take effect but we can still uh overwrite an arbitrary file now this is the log file so hopefully we can control its content and unfortunately only partially so asl logs are the apple system locks it's a very old api it's i think it's all deprecated or becoming deprecated there are very few documentations uh on that and my problem was that

there are multiple asl files on the under the log directory and i didn't know how to end up my asl log in these private bar log diagnostic messages so what will make an asl look to show up in this log and not another one and when i started to look to look into these uh diagnostic messages asl looks it it didn't at first it didn't seem to contain any arbitrary text field it seemed to be like having predefined uh fields with some uh values it can take like a dictionary now after looking uh through the logs i finally found one which contained an arbitrary text and that was the card of account refresh completed now i started to search for this string

and it led me to the calendar persistent framework now when i open the that framework and look for this string it made a call out to the car message tracer class with a with this log message and call message tracer was found in the calendar foundation framework now when i started to look through this car message tracer class it became obvious that okay this is the one that is using the the asl api and i started to trace the the functions if if i want to do like a custom message uh into the diagnostic messages it started to become a bit complicated and much time to to reverse the entire functionality so i decided to stop and because i

already have a class uh this car message tracer that can place a log me look for me in a in this asl with a custom message i can just use this class and don't care about the actual underlining method so what we can do is use the yellow pen on this calendar foundation framework to load it use the objective c runtime to locate the class with the ns class from string and once we have that we can basically call its methods and place our custom lock message in this asl log and this worked i could place an arbitrary content in the log file but unfortunately i couldn't do more so even if i deleted this log file

and i made my first log i i made my log entry the first in the log file it still had some headers and some other contents which would break any any useful stuff so it wasn't enough for good execution but i think it's still a useful tricar to inject uh content now the next one is finally like a full-blown privilege escalation not just arbitrary override it was in the adobe reader uh installer again uh the adobe reader used the acrobat update helper app um it's it was placed in the temp directory during the installation and there were two p list files inside this directory structure that later on voice were moved to the library launch

daemons directory and it was in a fixed locations but before the installing happened the installer delete any existing files in from the temp directory with these names so what we can do is basically this is a race condition because adobe deleted the directory that it wanted to use and then recreated it now between these two we can create our directory again before it's being created by adobe which means that we will be the owner of the uh of the directory and i found that it's very easy to win this race condition so we can pre-create a directory structure and once the installer placed the original plist file uh in this location we can delete it

because we own the directory and put there our own plist file and at the very end the installer will move the plist file into the launch daemon directory and basically it means that if we can move any plist file uh which we control to the launch demons we basically win because upon the next reboot uh the launch dv will start uh any process defined in this plist file as root

so the last bug i want to talk about is the posing mac os concerning the periodic scripts mac os has a bunch of periodic maintenance scripts under the edc periodic directory and it used to have a script that repeated the the main pages basically or the not the main pages sorry the the main database and it was running as root now the problem was that it got all the main page parts parsed through all the main pages and created a database now if we have like blue package manager being used on the system uh the usr local share man directory is a user writable location and it was parsed by a process running as root and this is

what we could uh abuse so what the make what is does it will create what is temp file for the database and we can redirect this uh temp five with a sim link and our target was again launch demons folder where we where i wanted to place a plist file but the problem was that the plist file in order to be loaded by launch d it has to be a properly formatted xml now if we look on the data on the what is database which is on the screen it's clearly nothing to do with xml it's basically a list that the first column is deleted by the from the file name of the man page

and the second part after the dash is basically the name of the main file from the name section which comes from the main section of the of the main file now how do we convert this file to an xml file the first step created my plist file which i wanted to be run or loaded and i basically replaced the the name section or the actual name on the man page to this xml and i run the make what is tool and it was nice because this xml showed up in the database the pro the problem was still that there were a bunch of content after that and before that now to solve anything comes after we can

just start an xml comment and basically that we comment out all the rest of the of the file uh i still needed to solve the the beginning of the file uh you can skip this so the file name

is the is really the first string that will be shown in the in the men page database and it has to make sense in xml now interestingly the the file name that you can see on the screen with thread red is a valid file name which is really nice because that's a start of the command in xml so it makes sense in xml and that's a valid file name i had to go back to the name section because if the file name is starting as a comment i need to close that comment before my uh plist file or before my content that i want to be loaded by launch d starts which was just pretty easy adding a

close comment of the file and finally this is how the man database started so we can see that there is the file name at the very beginning which is a comment basically starting and then there is a second part which is coming from the name section so we have a comment at the very beginning of the file then we have our properly formatted plist and then we have another command starting so this was a perfect xml and it was heavily loaded by launch d so let's see this in action oh this worked so it is the i'm in the main page for the usl local chairman and this is where the sim link will be

loaded let's go to my desktop and do run the exploit there are two options to run this i will choose the click one which will place a plist file with starting terminal so it created the file which is here it plays the steam link we can check that we have the sim link pointing to launch demons and we can simulate running the the maintenance street now the maintenance scripts run on a weekly basis obviously i don't want to wait a week now so we can just simulate its run

and now if we check this file

we can see that we have the xml command at the beginning we have our pvs file after it and then we comment out the rest of it and basically we can the attibute oops

and yeah we have a terminal popping up as root but unfortunately it's not always coming up properly to the screen but let's go to

terminal and you can see that there is a terminal running as root sometimes it doesn't show up properly but

you can see that if i load this p list terminal is coming up obviously because this is a live demo it doesn't work right but anyway this is how it works so lastly how we can avoid these attacks with installer regarding installers basically if you need to use the temp directory just use a random name that cannot be predicted or if you really don't want to use a random name but the predefined name then do these steps create a directory set the permissions to be owned by root only and no one else has any right access to it clean up the directory and then you can start using it because then no one else can place

any content inside it a move operation is also safe so if you move a file one file to a specific location if that place is a sim link where you move that file it will be overwritten by the move operation and in objective c if you use the write to file method of values classes like an s string it will not follow symlinks it will just overwrite what is there so it's like a safe function or method to use so that was all from me thank you very much for for listening