Easy LPEs and Common Software Vulnerabilities

we are very pleased to introduce you christopher bella who will be talking about easy lpes and common software vulnerabilities so let's all welcome christopher to the stage with a big round of applause thank you and um yeah so my name is christopher and i'm here to talk about a lot of the common vulnerabilities in software that i find today and how some of them are very trivial to do things like privilege escalation on modern windows as a day job i'm a security researcher at microsoft where i write fuzzers for the hyper-v hypervisor and i've got my twitter up there as well where you can shoot me questions about this even after the talk and i guess a bit of

background as to why i want to present this information during work and even in personal time like before even getting into vulnerability research a lot of the talks that i've seen revolve around things like complex memory corruption vulnerabilities um or things that require like maybe three months six months plus of deep reverse engineering effort things like writing dealing with custom hypervisors for housing emulators for fuzzing all these kind of complex environments as well and one of the common things i heard before knowing anything about vulnerability research starting out my career in security in general was kind of this complexity around vulnerability research and how finding zero days is getting harder and harder especially with the advent of

mitigations like aslr and dep and things like that and when you browse like zdi and and advisories like that you see heaps of software volumes coming out in common software like adobe and that day after day and you think that you know these sorts of things are being looked at or being fuzzed by large companies with resources of like 500 plus calls in the cloud and they're just fuzzing away and all these sorts of things that kind of leaves not much room for i guess vulnerabilities that are very simple and easy and can be potentially quick to find for people who are just getting into the space or aren't as experienced but from my experience there are

entire categories of vulnerabilities not just like a bug that's not exploitable that's useless and no one cares about but actual privilege escalation bugs in these prominent software that go unnoticed and you can find pretty easily even today so that kind of set out a set of goals for the types of bugs that i wanted to find and how i wanted to find them as part of this little i guess exercise and the goal was to find find them fast find zero days fast i don't want to spend of course i could spend months reversing something writing a fuzzing harness for it or just manually understanding its logic mapping it out things like that but i wanted to find bugs that i could

discover in hours or days maybe even minutes i mean one of the zero days that i'll be demoing later i found in maybe half an hour of looking on a system if that so some of these if you know what to look for are extremely easy to find and they're also easy to exploit you can go from bug to actual exploitation and get that privesque for example in a very short amount of time that kind of trials into the speed thing i don't want to well for this exercise i didn't want to find a bug that would then take me six months plus to actually have an exploit in so we're kind of focusing on speed here

and when i think of these bugs i think about like the bugs that i would have enjoyed uh knowing about if back when i was doing red teaming for example where you have like limited time on engagement and you want to prove ask on a box and you don't really have the luxury of spending weeks and months diving deep into research so these are the types of things where you could potentially find these bugs very quickly and use it even live on engagement and i'll be demoing these towards the end of the slides as well so that kind of leads naturally into focusing on logic vulnerabilities mostly because we're targeting like in my examples we're targeting modern

windows 10 so a lot of the if you go for memory corruptions you're likely going to have to deal with things like aslr and deb or if it's a heap exploit you're gonna have to focus on heat grooming and all those things just take too much time to turn a bug to an exploit for the most part so i kind of wanted to focus or believe that i had more luck focusing on logic bonds and this also ties in to how lots of people do von research especially companies like google project zero and that or oss fuzz and that would focus on fuzzing or finding bugs in adobe or finding bugs in you know anything else you do get the

logic vons there still definitely but a lot of the vons you'll see will be memory corruption volumes there will be things where they can write fuzzers for spin it up in the cloud and run that for like three months plus um which does make it a little bit more difficult to find uh memory corruption phones although i will say there are still plenty of memory corruption volumes in lots of software defined um so it's not so much the lack of them but more so for speed um that i decided to focus on logic vulnerabilities and when talking about logic vulnerabilities there's lots of types of logic vulnerabilities things from like read permission checks and things like that

one of my favorite ones is bad assumptions which is kind of a very broad category i guess but one example of it that is very very common is related to file io so an example here a little snippet right where we're opening a hard-coded file path and writing to it twice an assumption here may be that that file being open is the exact same file in both cases or even that that file actually does live in c drive program data my folder which i guess technically may be the case but due to the fact that windows and other modern operating systems have file redirections in the forms of sim links and junctions and hard links and things like that um c

drive program data my folder could potentially redirect to c drive windows system 32 and then suddenly your file1.txt that you're opening actually lives in system32 not in program data as expected that's just an example of like an assumption that a program may have that could be a security vulnerability if it's something that they haven't sufficiently accounted for or thought of and so in general when looking at what's in a zero day um there's a few components right we need to have a component to interact with so if we take this snippet for example like the principle or service we need some way of interacting with that component via some method maybe some sort of ipc shared memory file io

something like that and then some sort of internals knowledge as to how we can abuse some of those behaviors via you know a sim link redirection or some other logic issue and then how we can turn that into a bug and when we're looking at the interaction part there's lots of common attack surfaces in processes and this mainly relates to how processes interact with each other for example if i were to install an antivirus on my computer most of the time it's not going to be just one executable and that's it typically there may even be like five exes and a few drivers and various other components that get installed alongside that and they need some way to interact with

each other that can be via com rpc shared memory name pipes just file io in general device drivers and various other mechanisms and all these ways of communicating between processors can also be leveraged for say an unprivileged process that we create to interact with a more privileged process running a system for example this all obviously depends on things like what permissions are set on things like these name pipes or these shared memory sections that will determine if we can interact with them and how we can interact with them but they are definitely a lot of common attack services that i see in a lot of software and commonly you'll find that this software doesn't adequately adequately have

permission checks in place for these sorts of things and when it comes to windows we're kind of lucky that a lot of the tooling for finding this attack surface and enumerating it is public already we have like process hacker listed we have tools from google project zero in their sandbox attack surface analysis toolset we have the sysinternal suite as a whole which is a great set of resources as well and lots of other open source or public resources for enumerating these attack surfaces and i'll give an example of that a bit later as well now i kind of touched on the file system redirection stuff and i have a few demos later and they're not

all based on file system redirection but i feel like this kind of needs to be pointed out again simply because this is super common this is one of the most common things i find in software uh where they i guess don't have the understanding or there's oversight or some reason they do some sort of file i o in an insecure manner simply because we can have control over redirection of these paths so as an example c drive itself is a sim we link a user can change c drive to point to c drive temp or change c c drive to point to uh a different drive altogether every folder path could potentially be a junction that just

redirects to another folder and every file could potentially be a hard link to another file um james forshaw had a good talk on a lot of these file system redirection um components in his talk called a link to the past roughly around 2015 so it's definitely not even a new attack surface and um if we start thinking about this sort of thing we also see that it's not unique to windows so while i am talking about windows in this talk mac os and linux all have file system redirection capabilities i've had vulnerabilities in mac where they use certain apis to get the path of their application bundle and that typically is expected to live in like slash

applications where low privileged users do not have permissions to write to but by utilizing hard links and creating a hard link from a less pre i guess less hardened folder we can trick that api to returning a different path like slash temp or somewhere in the user's home directory where the user does have full control over that file and the application doesn't know any better and does something silly and insecure on the assumption that the only part that's going to return is like this slash application slash myapp.app bundle path that's really hardened but that may not be the case so it's definitely not a set of vulnerabilities unique to windows and when we start looking at junctions

we can see that these types of vons are actually really really common i have a little scrolling thing here it's not scrolling but anyway if you go on zdi and you just search the keyword junction in the past few months alone you'll find heaps of vulnerabilities reported in core windows itself and third-party products and when you see these types of vons affecting the core windows operating system on such a level um you kind of realize or maybe have an integration that these types of things are also going to affect third-party products a lot it's kind of a natural assumption when you see that how badly it's affected by renders and windows has kind of mitigated some

of these things if we go back to the whole potential hard links there was hard link mitigations released in the windows rs not too long ago and in the future i expect it to be also be mitigations against a lot of these junction attacks that we will see shortly but currently it kind of does plague a lot of software and one example of that i'm going to demo is related to zoom i'm sure everyone's familiar with what zoom is especially during kovid times so one of the bugs so this example for example is going to be a junction related logic bug in zoom that we can turn into a privilege escalation zero day for zoom

so let's see if i can get the demo showing okay just fyi the vm that i'm using to demo these is just the ms edge developer vm that you can grab off microsoft's website so i pulled that down and just ran that as is i installed a few extra software packages on them things like zoom as an example and some other products that i'll be demoing and just as a quick quick review of the attack service stuff i mentioned earlier if we open up something like process hacker and then we open up just some random process we can automatically see things like okay it's got rpc ports it's got events that we could potentially interact with

it's got handles to device drivers which are also a potential attack surface depending on if we as a low privileged user can interact with this device driver we have under files they'll be file io stuff but they'll also be things like named pipes if it has name pipes opened and there's also things like if i scroll down memory sections that we could potentially map into our own unprivileged process and modify and these are all potential attack surfaces to this process depending on how this process interacts with that and what the permissions are set for that that's kind of like a little example of just a very quick way to enumerate something relating to attack service on a random

process so with zoom for example i have zoom here should be updated a few days ago so still a zero day and this one we need some way to get zoom to do something insecure one of the things i like to check is when zoom is installed via like an msi package and things like that the installer lives in c drive windows installer and these are interesting attack surfaces um if anyone's seen sandbox escapers work on twitter she has done a lot in this space as well and previously james forshaw has also done a lot like i said relating to lots of these simulink related vulnerabilities and so one way to identify if msi belongs to

your target i like to just look at the digital signature right i see zoom there so i know it zooms that's simple enough and then if we hit right click and repair the nature of the windows installer is the zoom msi is going to run and it's going to do a certain set of operations to repair itself but the key point here is that when the msi runs it auto elevates itself to system even if we are just a regular user so what if it does in that msi package has to be careful in a way since it is operating as system and if i look at a procmon trace actually let me start another pokemon

session so if i start procmon to capture and i run repair on the msi then the msi file like i said zoom or auto elevate do stuff whatever it's coded to do usually just either checking file hashes moving files around general kind of repair operations like that let that go let me check my filter yep i need to remove this and now we can see all the various operations that it did and typically for von research you know if you see your target has zoom installed you'll install it locally and do these sorts of things on your local machine to identify and if i scroll down we'll see certain interesting behavior

let's see if i can spot this one it does a lot of things i think i need to adjust my filter again so what we should see is it trying to do something in our here we go okay found it so instantly we see here that this process which is running as system is trying to access something in our user's app data folder now since this is our user's app data folder we have full control over the contents of this directory well at least in normal cases we have full control over the contents that may not necessarily be the case but in most cases it is and it's trying to access these folders right bin bin001

whatever but it can't find it so the thing that pops in my mind is what if i create this folder what is it going to do next it might try to do something silly like load a dll from there if it does then that's probably an instead win for us so one thing i'll do now is we'll go to that folder we see that there's no bin i'll make that directory and just for now i'm going to include just that path actually that didn't work but that's fine we'll restart or rerun the repair operation which we can just do as many times as we want it will run through again and we'll be able to see what it tries to do with

this directory let's just exclude this still doing its thing and these types of things where it tries to access files or folders in in folders that we control are nice things to look out for okay so we see that it accesses it and then what it does afterwards is it just deletes the folder so if i go here we can see that bin no longer exists it just deleted the folder you might be like okay just deleted it so what but the thing is since we have the capability to do file system redirection we can actually leverage this to trick zoom to deleting any folder on the system we want which means we have an arbitrary folder

or even file deletion primitive here and that is something that we can leverage to turn into a privileged privilege escalation exploit there's ways to do it with the core windows operating system itself there used to be tricks with the windows error reporting folder now there's tricks with windows defender and i kind of encourage anyone who's interested in these types of things to find other methods as well but when i was running through these demos a couple days ago on this vm i found something else interesting that stood out to me that i figured would be more fun to demo as well and that's the fact that this vm on the microsoft website comes pre-installed with

chocolaty the software management package i guess i haven't really used it myself but it is installed on here and one thing i realized that's quite interesting that allows us to leverage this deletion for a priv-esque is the fact that if we look at the system environment variables for the system path we can see that c drive program data chocolaty bin is a path in the system path which means there's going to be a lot of system or applications that run a system that are going to look into this path to find a certain dll that it's missing and things like that and another key point about this path is that it lives in program data it's in

c drive program data chocolaty and why that is so interesting is the fact that regular users can create folders in program data i can do make the temp and temp is there as an example any regular user can create a folder in program data it's not a lockdown folder and in chocolaty we have the chocolatey bin which is in the path this folder is locked down i can't just create a dll here and hope that a system process loads it if i could that would be an easy proves again but the very fact that it lives in program data and we have this arbitrary folder deletion what if we just delete the chocolaty folder create our own chocolatey folder

with its own bin and since we created it we have control over its contents and we can put whatever dlls we want in there and that's exactly how this type of thing is exploited and i'll actually demo that so as an example so this shouldn't have been run before so i shouldn't be able to delete chocolatey access is denied obviously it's still there tried to delete everything didn't work because the acl is restricted so when i think about how to exploit this zoom vulnerability let's go back to our app data zoom let's delete the zoom folder make it as an empty one and the tools i'm using here are from google project xero's symbolic testing tools that are on

github and so if i go to my user's package for that and i go create mount point and i say let's turn zoom into a mount point that points to rpc control and then let's create a another sim link from rpc control slash bin and we point that to our directory that we want to delete which is program data slash i can make this bigger program data slash chocolatey so if i start that way so now if i do on zoom it's going to rpc control which is nothing but if i dir zoom slash bin it should go to our chocolaty folder as it showed there so now that we have that and we can see that zoom here

shows that it's a junction to rpc control and now all of this is done as a low privileged user so now if we go back to the msi rerun the repair operation if i go to c drive program data we see chocolate in here at some point thanks to the folder redirection chocolaty should disappear it shouldn't take too long to happen just give it a few steps bam chocolate is gone right and now thanks to that we can go into program data make the chocolaty bam go into chocolaty make the bin cd bin and suddenly now we can write here whatever we want and now since this is in the system path the next step to turn this to a

privilege escalation is to find a system process that's going to try to load something from this directory since it's in the system path and i have a process monitor trace from boot that will show us something that does that so if we capture a boot trace which you can do by just going options enable boot logging we'll see that the spools v process which runs the system tries to load or tries to create a handle to this tp gen lic.dll in this chocolaty path so if i copy over our own dll to hear chord uh what was it tp gen lick.dll right that dll is here this dll that i created will simply create a file

in c drive in c drive we can create folders but we can't create files right if i go test.txt and c drive access denied and the dll that i planted if it runs it'll create a text file in c drive called itworks.txt simple way for me to just verify that it executed code so now that we have this planted in program data well in chocolaty actually um all i need to do is get the spool sv process to reload there could be various ways to do this uh the easiest way i'm going to do is just restart the machine but you could potentially restart the service you could even there's bugs where there's been where you crash the service

and then it just auto runs again since it detected that it failed some things when you exploit these on call windows aren't even things that you need to get a service to do it's something you'll do periodically maybe like every five minutes it'll do this operation or every time you update windows update or some sort of signature database it will do this operation okay so we're logging back in and now based on our procmon trace that we had from the bootlogging we expect that spool sv would still try to load that dll that now suddenly exists and if i just go to c drive try to make it a bit easier to see oh what do you know airworks2.txt he's

suddenly there you know hello from system bam you got privacy in zoom [Applause] and that's just kind of one example right this is a zerodanes and uh actually one other thing i'll mention is that that zoom bin deletion is just one of the ways you can trick zoom into deleting things there's like three other ways that i found as well and for example this can be found by just opening up procmond knowing to how to set your filters right clicking in msi hitting repair and then finding it like i think i found this in about less than an hour of just downloading zoom and playing around with it and seeing what happens so these are definitely the types of

vons that once you're aware of you can start seeing them everywhere another example i have so this one isn't a zero day this one's an end day i found this one earlier last year and then someone else found it again earlier this year on twitter so it kind of was fresh in my mind and this one's an interesting one because it's not a file to a redirection one and anyone who knows fox at pdf reader or i guess pdf readers in general they're heavily fuzzed right if you search for uh foxit on zdi you'll find memory corruption vulnerabilities reported practically daily weekly over the past x amount of months or years it's something that's heavily fuzzed yet

they lived in there one of the most simplistic logic bugs that you could easily turn to an lp ever and i'm going to demo this one now as well so i have the older version it's not that old actually but the uh vulnerable version of fox reader i've got to close the presentation and go back to that

and one thing fox it reader does when it's installed is it has this foxit reader update service that runs as system and i believe i already have a procmond trace of it actually i don't need to i can just open a new one because it runs like crazy so this one as soon as you opt open pokemon it stands out like crazy

there we go we can see practically every second it's trying to open this file and if i scroll to the right you know i have to close this because it's just going to lag my machine right it doesn't find it so it's searching for this fox data.txt file in this path like 100 times a second it just keeps on searching for it keeps on trying to access it which you know probably not the best design but it is what it is and the first thing i want to check when i see something like this is can i create this file you know is it something that i could potentially create and then have the privileged

process try to interact with so echo test to voxer data.txt ah it worked it created so i can create this file you'll notice though that if i do a directory listing it's not there that's because once it tries to pass the file it just deletes it and you'll see that in procmod but it just happens very quickly and so the next step is thinking okay what is it actually expecting from this text file and so one of the things i did it was a bit small but i'll kind of explain it is open up foxit reader the update service in binary ninja i do a search for just foxet data and that'll take me to this screen where i

can see it's trying to open fox's data.txt here and then without even having to dive into reverse engineering too much i can just scroll down and just see if anything else nearby is interesting and when i scroll down i see things like session id okay that could be concerning if i need a valid session but then i see like stir temp updater path and cs command line when i say command line that stands out as potentially interesting because does that mean i can pass it a command line it will run it i don't know i continue scrolling down and then i see user shall execute success or use user shall execute failed okay that really stands out to me

that means that this has some some built-in behavior to execute something right and then when i backtrace that a little bit what you'll find is that the way this passes the text file is it searches for a two byte header i think it's like ff fe and then it'll take a path similar to this where you can have any random session id it really doesn't matter you can put the stair temp updater path to your exe like cmd.exe and then you pass it the command line like in this case you know i'm echoing system to c drive it works.txt this is my fake foxed data.txt file that i create so to test this i can

place this way it's trying to read foxet data now as a reminder in c drive since i didn't delete it we still have it works too dot txt but that's fine because my example is not it works too it is just edwards.txt right so we'll be able to see if this works or not so what happens if i just copy that file here if i just copy that here you know obviously that's disappeared because it got passed instantly and now if i go to c drive oh look it works.txt code execution again thank you foxset right and that's something that i spotted in fox's pdf reader by just opening procmond and then seeing like a

million plus requests through this file and wondering can i create this file and what is it expecting from this file what is it passing from it and this was a zero day from earlier last year so it's fairly new new enough right this one this one wasn't originally in my talk but this one i found in the dev uh vm that i showed that you can pull down from microsoft and this one is another zero day this one's actually very common in other software as well i've found this in very very prominent antivirus software that try to open paths like they go c drive device hard disk volume 2 and try to open up dlls from there

which is just a mistake in the way they're trying to open the path um they're not actually meant to be opening it from c drive device but because of a coding area they're opening it from c drive device and c drive device is a folder that typically doesn't exist and it's a folder that low privileged users can create so this is kind of a take on that by puppet labs or puppet i have no idea what this software is but it comes pre-installed in this dev machine and um here we go puppet labs and then it's come to puppet and it's got like its own ruby installed and various other things and literally i found this a couple days

ago after looking at it for about a second which kind of drives home my point again that lots of these vons they're they're not hard to find i download random software even avs and very prominent software and find these things very quickly okay let me just go back to my slide for a minute

okay i think if i open up the one captured at boot i should be able to find it we'll find something interesting that it tries to do when it boots let's get rid of fox reader okay keep going should be soon okay well there's a couple but i want to focus on one because this thing is just plagued with them okay so oh whoops i still have that there let's focus on a different one well anyway okay so i haven't cleaned up this vm properly but uh in c drive program data puppet labs puppet var lib it tries to load rb 3.0 if i go further down there's actually more so i don't even have to go with

that example there's here syslog dot so in c drive program data puppet labs puppet var lib syslog dot so right tries to create a handle to it if i scroll to the right you'll see that it's not found so first thing is do i have permissions to do stuff there and forgotten puppet puppet labs puppet var lib and this i mean you can pull down the vm and verify it yourself it's nothing i've modified but this folder typically doesn't have anything and oh okay this vm is cleaned up it's this proc mon log that shows the wrong one so here we actually have write permissions i can create folders i can create files i can create anything in this

folder so i can create syslog.so and things like that and that means that it's going to you know open a handle to it or do something interesting and i guess i already spoiled it but the thing is when it tries to open it it loads it as a dll so naturally if i put a dll here it's going to load it for the sake of a demo i'll demo that let me just get rid of these two oops

yeah yeah delete okay so that's fresh so now i can copy here the dll i had before uh rb3.0 i think was one of them that tries to load that's there and now to exploit this i think i can just restart the service i don't need to reboot again so we have c driver i don't was this one something just ran it again did it do it on its own you know what let's capture events there let me run this again sometimes you'll find that sometimes you won't have to restart anything you'll just find it on its own there i have another pokemon running let me modify the filter i think i need to remove foxed data again

okay go away okay restart puppet

and we see it does a whole bunch of things if we scroll down arbitrary. so so it loads it as an image we can see that this is a system process spawned by a ruby command line and if i go to you can probably find arbitrary.so which lives in you know the folder we put and the company's to do company names is just some dll i created in visual studio but that's loaded in a system process now and that means we also got code execution and there's you know our code execution right there [Applause] so that's another zero day in whatever puppet labs is um probably some dev thing it was installed on the vm so i found that

pretty funny um yeah and i guess a key point i'm trying to drive here a lot is that these are so easy to find like i recommend people just pulling down avs avs are a great one because they typically have like 10 executables and all these ipc mechanisms going on and all these shared memory and all these device drivers and there's just so much going on in them that there's a lot of these attack services for them but as seen even something like zoom whatever puppet labs is um chocolate well i guess chocolatey wasn't a vuln but it was a design decision that we could exploit another one this is my last one is vmware workstation

this one is a i gotta stop presentation again this one is another zero day in vmware workstation or at least the zero day as of a few days ago so i mean probably is still a zero day and with that one if we go add or remove programs after vmware workstation is installed and we find vmware workstation this one is pretty much like the zoom one but you would find it in a different manner so to speak so if we go vmware workstation and we hit modify this will also auto elevate the system so as a low privileged user we can get the application to do stuff as system which means we can be very

i guess scrutiness in what it does because everything it does is potentially dangerous if it's doing it as system if we hit repair now this takes like a minute because it does a lot of stuff so i've pre-prepared a procmond capture of this just so we don't have to sit through the entire thing but you could do this yourself in your own time if you wanted to verify it and what we'll notice is a quick point so there's one example here where it tries to load this dll from our app data path now the name is of the folder is kind of randomized but there's been vulnerabilities where they'll use a randomized path but we can race condition this by having

our own executable search for newly created folders and then in newly created folders we just drop a dll of this name such that most of the time we're going to win the race and when it tries to load this dll it will load ldl i've had that vulnerability in a lot of other software as well in this case vmware can kind of get away with it because the folder it creates it creates with a restrictive acl that we cannot write to so i haven't really looked into bypassing this much potentially there are bypasses obviously if you create the folder before vmware creates it that's potentially something how long is this one two three four five six seven it's seven

digits potentially you could create every single folder name seven character seven digits along especially if it conforms to like six you know eight to zero characters and then one number or something if you find a pattern like that you can kind of just brute force the folder creation and then run this msi and then hope that it uses a folder name that you already have existing and depending on how it handles that it may not delete it or do something secure it might just access the dll from there and you get a brief ask i haven't actually tested that on this so i have no idea if that's the case in this scenario but it's something to keep in mind when

you see something like this but something else interesting happens if we go down we see that it tries to access this c drive var run vmware host d ticket i mean i'm not sure if that's supposed to be like something it installs on linux i have no idea c drive var run isn't really something that's going to exist on windows and it's not something that it installs on windows so that's odd but spoiler alert when it finds this it'll do certain parsing i'm not sure if it's looking for anything else interesting but i know one thing it does is it'll delete the folder so one thing we can do to exploit this again is do the whole symlink thing

where run points to rpc control and vmware host d ticket points to any arbitrary folder and when it finds that you'll just delete it and that's another arbitrary folder deletion zero day in in vmware and like i said i gave an example before of exploiting this via chocolaty just because of the fun fact it was installed and i found that pretty funny in program data of all places but there are definitely core windows locations where you can leverage this as well so those could be fun to look at too for the sake of time i'm not going to demo that one i already demoed the zoom version so feel free to try that yourself if you

have vmware installed

if i go back to some of the key takeaways that i had in mind when doing this is i kind of want to i guess demystify the fact that vulnerability research especially on logic vulnerabilities which aren't things that are like heavily fuzzed in these applications especially in some third-party applications like zoom i don't know many people that are like logic von hunting prevests in zoom people will be fuzzing for rces and things like that but some of these other types just aren't heavily looked at and they are very easy to identify and exploit if you know these kind of mechanisms or these common weaknesses as to what to look at all the vons that i've presented

in here all the zero days and even the end days took me most of them less than a day to to go from downloading and installing the software and then finding and actually exploiting the bug and that is super quick and these also affect lots of software like we saw vmware we saw zoom which is probably installed in most people's machines these days we have lots of other third-party products that i can't really talk about but avs as a general is another big one um but really like anything kind of is affected by this it's very hard for me to pull down software and be like okay it has no logic bonds at all and as mentioned earlier this

isn't something unique to windows i've found similar things on mac as explored before and although i haven't looked at these much at all on linux and even on mac i suspect there are very common logic bonds like this there as well in terms of the future of these sort of bugs anyone interested in the hard link side of things there used to be lots of hard link bugs where you could create a hard link from a file to any other file even if you didn't have access to that file like write access to it and then processors would do things like set permissive acls on that file and that would apply to the file you had

linked to and things like that i didn't really touch on that much because those have been mitigated in windows by a patch i think towards the start of last year it might have been when that started to get squashed and i would actually expect more mitigations to follow simply because that these types of bug classes well at least the junctions like some of the logic things we saw where just loads of dll from some directory i don't think windows can do much about that um they are trying to do some things around to like the system 10 path but in regards to the junction stuff we saw the folder level redirection i know mitigations on that are being

actively looked at so i would kind of expect something around that to be mitigated in the future but currently it's something that kind of plagues a lot of software so yeah in the meantime there's still many popular many of those bugs in popular software like i said we saw that c drive var run example from vmware they also open c drive device or c drive other folders that just don't exist not realizing i guess that low privileged users can create folders in c drive and yeah i hope you enjoyed my talk that was all i had for today

such a great presentation really really enjoyable to see uh so many zero days drop in one presentation so that's really cool uh we have a few questions i believe you've already the first question that we've got i believe you've already answered this so but i'll just repeat it anyway and it talks about um this person uh risen i think is the name on on slack he's asked microsoft uh he believes doesn't consider some link abuse vulnerabilities anymore in the latest insider builds uh do you see this category of vulnerabilities disappearing in the near future if you believe the mitigation putting places out of it i think you've answered that but did you want to add any more comments

yeah um so i can't speak so this is my personal experience i can't speak on behalf of microsoft because i don't work a lot in that mitigation space i know that typically even with hard links and things like that typically when you see something like that in my mind where they're not accepting it it's because they're already looking into broader mitigations as a whole that mitigates the entire bug class which is why they won't accept individual bugs but that said if i look at zdi and type in junction i still see heaps of junction related bugs i'm not sure if that's just because it's a zdi thing i know microsoft also has some differences between

if it's a sandbox escape as well as a um just a proversk um in my mind obviously there's still all bugs that you can exploit so there's still valid lps today and that's my personal view um but i would definitely expect that that just because that mitigations are coming but that's just my personal view i don't actually have any work related insight into that couple more questions uh can you use make link instead of the project zero tools for making those links and junctions yep so in some cases yes in some cases no so the make link tool by renders i think james faulco touched on this as well in some of his blogs have certain checks in them that

restrict what you can do with them but those checks are in the tool itself they're not really enforced on like the kernel side of things so for some things for some junctions you can do like make links j and just point it anywhere you can create a junction like that that's true i typically just use the symbolic testing tools because i remember there being some scenarios where those tools by google project zero don't have certain checks in them that the windows toolset does um what those checks were from the top of my head i don't know but i recommend looking at james forshaw's blog blogs because i reckon i'm pretty sure he has those detailed in his blogs

a couple more questions uh by nathan riley for this one why are these considered drones in 30 third-party apps instead of the msi installer framework yep so all msi i guess the framework does in this case is allow the process to elevate the system now if that process decides to use paths in program data or in c drive device or in the user's app data my personal views that's the program's choice the program could easily have operated in c drive program files and its own folder which low privileged users shouldn't be able to modify anything in c drive program files so the fact that it's doing arbitrary deletions on c drive var run vmware host d ticket that's not

something that i see as a responsibility of microsoft to reinforce that's something that the programmer who coded up this msi code in the first place to the custom dll that lives in there has decided to do and they could easily decide not to operate on those i guess weak paths and i suppose that that brings us probably to the final question and i guess you'd answer this in part already by that answer that you just gave and the the question is by will i and he asks oh uh asks you said it's a mistake to do file i o with pre-written paths assuming the file there is what you expect it to be but what's the

alternative for developers yep so that all relies on the security of the path to begin with so when you're writing as a system user c drive is going to point to c drive um if you're writing as a in the context of a specific user account they can redirect c drive to point to something else so if you're concerned about that you can run a system and then in regards of turning the folders to directory junk directory junctions that can only happen depending on the acl so for example if a process as system tries to access c drive program files my folder me as a regular user shouldn't have any control over changing that c drive program files into

a junction because i'll need permissions to modify that folder in the first place and regular users do not have that permission if you're operating in c drive program data then or even in c drive program files but where the process has specifically applied a rig acl which i've seen before i've seen programs live in c drive program files and they've added their own weak acl to a specific folder path allowing regular users to modify that folder and that's kind of there and false for weakening the acl if they want to be sure that it's safe they should use paths that they either know are hardened by acls by windows like in c drive program files

or they apply their own acl on creation and kind of treat it securely like that if you're operating on directories that by default the user will likely have permissions on in like the user's own app data folder as we saw zoom operate on where it operates on a user's app data folder without any special acls on there that is a known path where users have read and write access to so that should be known to developer not to do anything sensitive in there when they're running a system so that's kind of just a uh something to keep in mind when you're doing those privileged operations yeah great presentation a great answer to all of those questions really like

the slack question so keep them coming but let's all thank christopher one more time for a great presentation