← All talks

What the DLL? Finding and Exploiting DLL Preloading Vulnerabilities

BSides Cape Town · 201639:341.6K viewsPublished 2016-12Watch on YouTube ↗
Speakers
Tags
About this talk
DLL preloading attacks have persisted as a Windows vulnerability since 2010, yet most application developers remain unaware of the risk. This talk introduces Rattler, a tool that automates the discovery of vulnerable DLLs in Windows applications, reducing analysis time from hours to minutes. Through live demonstrations and bug-bounty case studies, the speaker shows how attackers exploit these vulnerabilities to achieve code execution, persistence, and privilege escalation.
Show original YouTube description
In this talk we will discuss the history of DLL preloading attacks, the current limitations in finding and exploiting these vulnerabilities, release a tool to do this better, and discuss the results of reporting several vulnerabilities. Dynamic-link libraries or DLL’s are a common component used by Windows applications and have been a target of attacks since at least 2010. A tool to exploit DLL preloading attacks was released in 2010 by HD Moore. Preloading attacks are a common attack vector used by attackers to get their payloads executed via legitimate executables that do not reference DLL’s correctly. HD Moore’s tool assiststs in the discovery of application DLL’s which are susceptible to DLL attacks. Six years later, do we know how our Windows applications are behaving in terms of making use of DLL’s? Currently, the process to analyze applications DLL usage is time consuming and exhausting as it is not uncommon for an application to make use of 100 DLL’s or more. If we use existing tools and techniques to analyze an application for preloading vulnerabilities, assuming it takes ~2 minutes to test a single DLL for an application, it may take ~2 hours perform a complete analysis on all DLLs utilized by an application. In this research, we release Rattler, a single executable which automates the process of identifying vulnerable and exploitable DLL’s. Furthermore, in this research we will present our findings, which indicate that a significant number of Windows applications are still vulnerable to DLL attacks. We will also discuss the responses received from multiple BugBounty programs and how applications which have been identified as vulnerable by Rattler, can be exploited to achieve remote access or privilege escalation on Windows.
Show transcript [en]

It's my talk, what the DRL, and I had you add in a fancy title there. Um, Dom told me to do it. Um, if you see Dom, um, he's trying to grow a beard, just let him know that he's getting there and everything will be okay. Um, so, hashtag couldn't resist. So, that's the title. Yeah, this is actually working. Um, who am I? Yes, cannot have a slide about this. Um, so, I'm an analyst at SensePost. Uh, they let me wear my cowboy boots and grow a beard, so that's pretty awesome. So, um, I hack stuff there. Um, I try to most of the times, um, but a lot of the times it's just bashing away furiously at a terminal

with green text. Um, so, if any of you have any pointers, please let me know. Um, I like to build stuff to hack stuff. Yes, I'm being really lame. I'm quoting my Twitter handle. Um, but that really is one of the most favorite things that I find myself doing uh, on a Friday night is building tools. Um, cuz like I said, I'm pretty lazy and if I can automate something or make things a little bit quicker, I do it. So, I like to build stuff to hack stuff. Um, and then in my spare time, I like to try and grow a beard. On that note, there are some fantastic beards here, so well done. I'll be more than happy to discuss

beard oils at a later stage, but not right now. Um, and that's supposed to be flannel. I like flannel, cowboy boots, and moonshine. Um, I think I just I was born in the wrong continent. Um, uh, so, yeah, that's a little bit about me. Um, you can find me there. If you don't know what those are, you might be in the wrong venue. Um, but I think everyone's figured that one out. Cool. Awesome. So, I was once told by a very, very awesome speaker, um, who's in this room today, that a lot of talks should cover a story. And uh, mine doesn't really have a story, um, but I just really like that photo because, um,

when I tried to take it, um, and actually my colleague this morning asked me, "Chris, do you like to take photos?" And I was like, "Well, I try to take photos." Um, and if you know Daniel Cuthbert, our CEO, he has fantastic hair and makes uh, takes fantastic photos. So, I tried to uh, take a photo. And when I took that photo, I was with an American, an Australian, and a South African. And no, this isn't a bad bar joke. Legit, uh, we were having a beer in the bush. And um, with a uh, game ranger, and this is in a game reserve. And uh, I'm not going to try to do an Australian accent.

Um, I've been told I sound Australian when I go overseas, so I'll just speak normally for now. And he asked me, uh, "The sun's going down, and when sun goes down, that generally means that animals come out, like lions or, you know, you're in the African bushveld." So, he asked me, "Do you think we're safe outside here?" I'm like, "Dude, I grew up on the east end of Johannesburg. My survival skills are that of fending off overgrown pigeons. So, don't ask me, I'm not the right person. Um, but I think there might be a snake or two out in the bush." Um, and then he said, "You know, why don't you ask the game ranger? Um, this is his

threat area. That's his attack surface." So, he said, "You know, what's what's the biggest threat?" And he said, "Well, besides you guys over here and a cooler box full of beer, um, I'll probably say the Mozambican spitting cobras." So, the point of that and that picture was that, um, if in doubt, ask the experts. And a long time ago, I was looking how to tear apart Windows applications, and uh, one of the things that I stumbled across was DLLs. Uh, once upon a time, I used to develop applications, very terrible applications. Um, that's why I break them now. I'm not good at building them. Um, that's why I stick to hacking tools. Um, and I stumbled this thing called DLLs.

And uh, essentially, it's a bag of bits. And what really got me interested in them was that they can be invoked or used at runtime. Now, from someone who's built a couple of applications along the years, you know that you don't want to reinvent the wheel. And of course, use a library of sorts, you know, whether it's a Maven import or a header file, you want to reuse someone else's code. You want to use their wheel. You don't want to make your own. That stuff's hard. So, if it's all it's a if it's a solved problem, awesome, reuse it. But what's even better is that if you can do it at runtime. You don't have to compile, you

just make application, you say, "You know what, use that thing. Use that piece of code at runtime." And when I was just trying to break a lot of thick apps, especially on the Windows platform, I realized, "Well, hold on now. So, if I tell another application to use this bag of bits, I don't have to recompile the application. It just uses it at runtime." And that's when I would say the spidey senses started tingling. I was like, "Hold on now, this seems really cool." So, then I researched a little bit. I Googled frantically until I was on page four of results and every result was in purple. So, then I know my research was done.

So, what was the vulnerability? And the vulnerability that really got my interest was preloading hijacking. There's a couple other names for it. I found this description, which is probably violating every uh, rule for a good presentation cuz there's probably too much text, so I do apologize for the presentation gurus, but um, I just couldn't resist. So, that describes it better than how I would probably say it right now, so I'll give you 5 seconds to to read it, then you can get awkwardly silent. Cuz it's quite important. Are you going to say something or are you Um, I was just hoping for the awkward silence, but you broke it, Shell. Like watching a movie with subtitles.

Watching a movie. And then it's that. So, the vulnerability preloading is that essentially, we can trick applications into loading our DLLs. Which is really cool because if an application wants to use library X, and library X um, calculates pi to 40 digits, we can say, "You know what, don't use that library. Nobody wants to use that. Just load my library, which will give which will give me a shell on your machine." So, that's what got me interested. And this was the vulnerability that I started to look at. And of course, yes, a bit of history. Um, like I said, I think the memes took me more time than the presentation itself. I mean, you know, um, if I'm going to make you

guys read text, at least give you guys a good meme here and there. So, I tried. So, DLL preloading has been around since at least 2010. It's not new. Um, DLL preloading or hijacking attacks, it's been around for ages. Um, before I even had a beard or probably most of you even had a beard, they've been around. Notably, if you Google that advisory, that's one of the earliest ones that I could find from Microsoft. Um, they were aware that this was being used in the wild for a whole bunch of their products. So, it's been around for quite some time. Um, and there's multiple attack vectors to abuse this vulnerability. So, either via directories, so you can abuse certain

directories if you have access to certain directories, you can get applications to load your DLL, which can result in shells, anything malicious that you want. Um, certain registry entries that can be manipulated in order to trick applications into looking or loading DLLs from certain uh, directories. And then of course, you can literally just replace a DLL and rename it, and the application will load that at runtime. So, there's quite a few places. In my case, I'm looking at directories. Um, why? Well, I think I'm probably not the only one who sees the Windows registry and just kind of Um, and then of course, just replacing DLLs, well, I don't know, that just kind of seemed like taking a hammer to a

wall, which is cool for the first 5 minutes. Um, but yeah, it gets a bit boring. So, there are a lot of fixes for this along the way, and I just put arrows, so look above. Um, in terms of fixing what directories can be read, so the search order, which we'll look at in a bit. Um, registry entries that can be locked down. So, there have been some fixes in order to try and prevent this problem from happening. And I say problem problem because you'll see by the end of this, some people think it's a problem, some people don't. Um, personally, I think it is a bit of a problem. So, what? So, we have DLLs, we have a

vulnerability of sorts, which is relatively simple to exploit in terms of executables. Um, I would say it's probably one of the hollow world um, vulnerabilities that if you want to start tearing apart thick applications, this is very fun to get started with. And of course, why I like it is that it can give you persistence on a box. It can allow you to escalate privileges. And of course, if you have a host that's executing your code, it can allow you to have remote code execution on that host, which a lot of the times I find quite useful in terms of post exploitation. You want persistence, and of course, you want to, you know, escalate your privs,

which is quite useful at times. And we have the Windows operating system, which I'm sure a lot of us over here love to pick on. Um, and we've been testing this through 7 to 10. I left out Vista well, because Vista is just the ugly child that everyone likes to ignore, so I'm just ignoring Vista there. But 7 to 10, DLLs are used probably before at some point. Um, but that's what we have. And now, what do we do? Couldn't resist, sorry. There was actually a WarGames reference there, but I figured, you know what, after watching WarGames last night, it was really awesome. Cannot have a hackers um, reference. So, of course, we've got this vulnerability,

it's pretty easy to exploit, it's all over Windows. Let's go ahead and hack everything. I mean, I don't know if anybody here first time they figured out SQL injection, what did they do? Yeah, O'Neal became a very popular surname in Southern Africa. So, let's just go ahead and hack everything. So, how do we exploit this? So, first of all, you have to identify the DLLs utilized by an application. To do this, there are multiple ways to skin this cat. Um, everybody familiar with that saying, "Skin the cat?" Just checking. I once spoke to some people, and I mentioned that, and I got a very serious look, and I think they thought that I meant that they must go and skin

a cat. Uh, it was probably a cultural mishap. I'm like, "No, it's just a saying where I come from. You know, on the east end, we're a bit weird." Um, but basically, I mean, there's a lot of ways to do this. So, Windows debugger, process explorer, procmon, uh the imports address table, PE executables, what is it? Static analysis. So, there's multiple ways to do this. First thing after this step, so the second thing, you want to identify DLLs that do not make use of fully qualified paths. So, basically, you want to find DLLs that are being referenced and they don't have the path C: backslash Windows backslash system 32 backslash blah blah blah blah blah. You want to find the DLLs that

just say directory backslash moo.dll. Why? Because when DLLs are not referenced with a fully qualified path, it tells Windows to go look for the DLL, which is the search order, and that is what we abuse. Because the first thing Windows does is it looks in the current working directory of the executable and a few other directories along the way, where I mentioned registries, so on and so forth. So, as an example, yeah, skipped ahead, you know, multitasking, pressing buttons, reading slides. I'm still trying to get there. But, this is not what you want to see. You want to leave that DLL alone. This is the one that you want to target. Cuz those are the DLLs that will trigger the

search order. Then once you have that, you want to enumerate the target DLLs. Um, I used to say the word fuzz, but then my um Egyptian colleague um schooled me on the art of fuzzing, so I then called it enumerating, which I think is a more adequate term. So, thank you, Safe, for that. So, after that, you want to place your malicious DLL in the current working directory of the executable. There are other ways to exploit this, but that's the directory that I was focusing at. So, if you know that this is the DLL, you rename your malicious DLL, which you can create multiple ways, place it in the directory of the executable, and it would look like this, pretty much.

This is your target executable. You would put your DLL in that directory. Once you have that, you run target.exe, and then you wait for calc. So um I think it's quite simple. Um, I think it may be relative, but I saw this and I was like, this is quite lekker. I think I can do a few things with this. And of course, you can wash, rinse, repeat that process. I was like, I can't quite make that facial expression. Um, maybe after some uh Tears of the Hipster, um which is a great beer, by the way. Um, thank you, Cape Town, for that. But, we can repeat this. And when I wanted to repeat this, I

first looked and I said, "Okay, well, what's out there already?" So, I don't want to reinvent the wheel. I'll just see what that wheel's like and maybe polish it a bit and be like, "Okay, that's cool. I can I can use that." So, HD Moore, quite prevalent in the security field. Everybody heard of HD Moore? So, he did quite a bit of research on DLL preloading hijacking. Uh if you look at the online research, he was pretty much one of the first guys to uh speak about this, and he created a DLL hijack audit kit. So, that five times faster. I can't. So, basically, this kit allows you to identify DLLs that may be preloadable. It's a whole bunch of

scripts. You use procmon. Um and I looked at it and I was like, "Yeah, this seems like a little bit too much work that I'm willing to um put into to identify um DLLs that I can hijack." So, collection of scripts, like I said, and of course, there's that manual process that I mentioned before. Um after, you know, scanning the intertubes and trying to find out that approach came out, and of course, HD Moore's collection of scripts. So, yeah, the manual process. So, it's it's not uncommon for applications to have a lot of DLLs. Um so, for example, if an application has about 100, takes about 2 minutes to do each DLL, um you're looking at maybe about 2 hours.

Um and I don't know, that just seems a lot like why can't we just automate it? Get something else to do it, and let's make it a bit quicker. So, I was like, "No, this manual process doesn't make sense." Um and even what's out there is isn't just it's not satisfying um my craving for efficiency. Um so basically came up with Rattler. So, uh rattle something and you see what comes out. Um that was that was the hoping for it. Um like I was speaking to someone earlier, uh good hacking tool has to have an awesome name and really good ASCII art. Um I was just betting on the name. So, yeah. So, it's a Windows executable, supports

32 and 64 bits. Thank you, Visual Studio, for that. Written in delicious C++. I'm just going to add a little bit of sarcasm there because, yeah. Um pointers, uh pointer arithmetic, C++. Reminds me why I'm not a dev. Two inputs at this moment in time, the path to the executable that you want to target. So, if you have wordpad.exe or uh you know, organizationx.exe and you want to see if you can DLL hijack this uh executable, you give the fully quali- uh fully qualified path. And then of course, the mode. Um in this case, Rattler has one mode, um which will I'll talk about a bit later. So, it's two inputs. Keep it nice and minimal, no

ASCII art. It automates the manual process that I mentioned earlier. So, I see processes and I'm like, let's automate it, and then a little twist afterwards. It will identify exploitable DLLs, such that if an application is vulnerable, Rattler will give you the name of the DLL, and that is the name that you will give your malicious DLL that you'll need to place in the current working directory for the executable. That's what Rattler will tell you. Give you the name and the path as well of the vulnerable DLL. And what you'll see is that a lot of DLLs come from system32. Um it's quite rare that we find actually custom DLLs for the actual for the

actual application itself, um which is quite interesting. And there you go. There's the path for GitHub. Um I hit the big red button just before the talk to make it public. Um if there any um C++ gurus, I really appreciate your help to clean it up. Um so, yeah, that's where it is. It's on GitHub. And uh that's what it looks like when you start it. Um two inputs. Sorry, the one got cut off. I blame reveal.js. Um the border cut it out. You know, really, you know, reveal.js, really, you had one job. I'm joking. Um anybody else using reveal.js for presentations? Okay, so I went full hipster then. Okay. I was trying to avoid that for today.

And then of course, these are the results. I'm sorry if you are colorblind. I didn't not think about that, but if anybody is good at creating color output, I'd be more than happy to address that GitHub issue. So, example here, Rattler will tell you, "Cool, this application that we've tested, the results. If you were to place a malicious DLL called cryptsp.dll, ironically cryptsp, in the working directory of that executable, your payload will be executed." So, why I use it? Um so, you might be asking why there's a picture of an inbred kitten. Um same reason why I use Rattler. So, for any of you who are laughing now, the internet's been around for a while.

So, why I use it? Because I can and because someone could do that, so I can use Rattler as well. So automation. Automation. It's been fun. You give it the target executable, you hit enter, go watch some Netflix, make a cup of coffee, come back, "Oh, cool. Okay, those DLLs are I can use to exploit that application." Persistence. So, you're on a host, uh and you want persistence. There are multiple ways. Um what I like to do is identify the applications installed on the host, and if any of them are vulnerable to DLL preloading, I will then drop a payload and exploit a vulnerable DLL, and whenever that application is run, my payload will then be executed as

well, which is quite nice. Sometimes DLL preloading attacks will crash application, depending on the usage of the DLL. Sometimes it doesn't. So, you got to check that beforehand. So, I drop a DLL, and basically, whenever that executable is run, whether it's a service or by the user, my payload is executed as well. It's been quite handy. Privilege escalation. Why? Well, what do we know about hacking? Generally, if you exploit um something, you will generally inherit the permissions of that entity. So, if you uh hijack an application that runs as admin, what do you think permissions you're going to get? Admin. Bug bounties. Yes, the bug did bite. Yes, I must apologize for the bad joke.

I should have actually apologized earlier, but um yeah, too late for that. Um for fun, of course. I mean, who doesn't like hacking stuff and getting a shell? Um I still get excited about that. And of course, curiosity. Um one of the biggest questions that I asked myself from this re- research was, "Well, if this is from 2010, well, why is it still happening?" Um we know that vulnerabilities are still happening from years ago, but I was curious. I was like, "Okay, well, you know, it doesn't seem that hard to exploit or fix so my curi- I was very curious about this. And of course, Gautrain journeys. Those of you up in uh Gautrain know that um it

can get a little bit boring, and of course, you know, nothing better than sitting next to a fellow hacker on the Gautrain. I was actually made a reference to a hacker that unfortunately couldn't be here today, but we had a lot of fun on the hack train, you know, nice 40 minutes, like uh yeah, you want to see some shells? Oh, cool. So, we had a lot of fun with that. Um and yeah, if he watches this presentation, he'll know that that reference is for him. Yes. Yeah. #couldn't resist. Could not resist. Um I've had some screenshots, I've had some bad jokes. Um Obviously, you want to see Rattler in action. So, I resisted the urge to

sacrifice a hipster last night, so the demo gods might or might not be on my side, um but I think all of you seem quite cool. No one's thrown something at me yet. Um so, hopefully the good vibes will keep on going. So, in terms of the demo, we're going to identify some vulnerable DLLs. We're going to get some code execution, we're going to get a shell back. Um fun times. We're going to elevate some privs. And then, of course, I've tested this up until a patched Windows 10. Users on Windows 7, 8 .1, please go ahead and run this in on as many different kinds of machines as you can. What you'll see, what's quite interesting, is that

depending on the operating system, some DLLs appear to be vulnerable, some don't. So, if you are going to use this in the wild, run your test cases on the operating system that you are targeting. And then yeah, we're going to use a vanilla MSF Venom DLL payload. Vanilla out of the box, nothing fancy there. And cool, so that was my um slide to remind me to go do the demo. So, now it's the demo time, and there's probably going to be a couple minutes of awkwardness, of silence. I don't know, I find silence a little bit awkward at conferences. Um maybe that's just me. So, we've got a Windows machine over here. Um now, I don't want that to expand. Oh,

why am I looking there? I've got split screens. Um Conference pressure, what can I say? So, I have Rattler over here. Um let me see if I can make that font a little bit bigger. Uh properties, yes. Font. 28. Is that all right? Everyone see that? Cool, I got a thumbs up from the back, so that's good news. So, Rattler has two binaries, and then of course, there's a payload.dll. In this case, this payload just pops up calc. And as Rattler is running, I'll explain to you exactly what it's doing. So, you've just got to run one of these uh one of the two binaries, and just make sure that payload.dll is in the directory of Rattler.

And in this case, so I made a little cheat sheet. Um Yeah. So, we are going to target wordpad.exe. We want to see if this is vulnerable to anything. So, you can say Rattler 32. Going to paste. I'd say the Windows 10 command line is slightly better, control V actually works now. I've said right click and just hoping something happens. Um and then the mode. So, in this case, I'm running Rattler as admin, depending on the application, because we will run we will want to uh place files in the CWD, the current working directory for wordpad.exe. Um I know some of you might be saying, okay, you need admin to do this and whatever, but hopefully the point will

be made later. So, I'm going to run it. So, what Rattler does in the beginning, fires up the application. So, beforehand, you need to make sure that the application that you're targeting is not running, please, otherwise you'll get some weird errors like that. Um That is not correct, and it's probably because I'm running the 32-bit, but that's all right, I have a backup. So, what I'm going to do here is target a installer, and we'll come back to that. Like I said, conference pressure, it's probably because I didn't run the 64-bit. But we have in two installers over here. And what's interesting about the downloads directory is that it's untrusted. So, I can go ahead and basically

create a file, and I don't have to be admin or anything. If you were to try to drop a file in program files or somewhere under C, you'd get UAC saying, you know, you need permissions to do to do this. In the downloads folder, no, you don't. And these are the two latest uh .NET SDK installers. One is the web installer, and one is the offline installer. And I'm going to want to enumerate this one over here. So, I'm going to say properties, and I'm going to copy that. So, we'll say Rattler 32. Ah, it got me there. Windows got me there. Paste that. Say one. Close that. K, holding thumbs. Maybe I should have sacrificed a hipster, I

don't know. It's not too late. K, anybody wearing skinny jeans? Yeah, everyone keeps their hands down. Cool. So, what Rattler is doing now, it'll run the application just to get a handle on all the DLLs, and what it'll do, it'll just go through and enumerate every single one that's in there. Um not the most efficient, which we'll see. And this is going to happen a lot for a couple minutes, so it's going to go through every DLL. And what's interesting is that there's currently a bug such that Rattler will tell you that ntdll is vulnerable. It's not. Um Um it's it's on my to-do list to figure that one out. Um but it'll run it'll go through and

hopefully we'll see calc pop. So, if anybody's wearing skinny jeans now, I suggest you leave the room. Might have to get that sacrifice going. And what Rattler will do is that the payload triggers calc to be executed. And what Rattler will do, it'll place the DLL, whatever we're trying to enumerate, we'll run the application, and it will then look for the existence of calc. So, please don't have calc running also when you uh run Rattler. Um cuz then everything's going to come up. It'll look for the presence of that process. If calc exists, and that's another interesting area that I'll discuss now, if it runs the target executable, and if calc appears, Rattler then knows that that

DLL that it placed can then be used for DLL preloading. So, it's quite a rudimentary way of checking, and I found it quite um useful. So, there we go, cryptsp.dll is um vulnerable for this app. And what's very cool about this and lots of other installers, and I challenge you to go run these on installers, is that you'll notice that there are a lot of common DLLs vulnerable according to the technologies used. So, this is a Microsoft product, and this vulnerable this DLL is vulnerable. So, does anybody think that it's only this installer that is vulnerable to cryptsp.dll? You can you can shake your head, it's fine. I won't do mine too hard cuz I'm

scared this cool thing over here is going to fall off. Um So, now we have that. Rattler has now told us, okay, that's the DLL that is vulnerable. This is a very cool error. Um can anybody tell me what this error might be from? So, the payload that it uses, it hooks into the DLL main entry point. Remember I said DLLs are runtime, so there has to be some form of API. The application has to have some predefined way to know how to communicate to the DLL, and vice versa, there has to be some predefined established conditions. One of the entry points for DLLs is the DLL main. You can add custom ones. So, this is actually

part of future work, and if you see this error, it means that the DLL was preloaded, but the DLL provided did not have the entry points that the application was looking for. So, that's also on my to-do list. Some people say to-do, but I think to-do just sounds, you know, I don't know. I think it sounds slightly better. K, so now we have a vulnerable DLL. So, what do we do now? We want a shell. So, in this case, I have a DLL aptly named beard.dll. Um it's a MSF Venom vanilla DLL. Um So, all that it is. So, just to make sure that this application is vulnerable, I'm going to copy this into downloads.

I'm going to put it over here. You see, no UAC, no nothing. I can just copy paste to this directory. Cuz no one ever has a million and one installers in their downloads folder ever. No, not at all. So, I'm going to rename it to c r y p t s p .dll. I'm going to run the installer. Yes, I would like to run this installer. K, boom, there you go, we've got calc. K, so it's some manual verification. That's just OCD Chris saying, just manually verify. Thank you, that's very kind of you. Um That that was very nice, thank you. It's nice when people are nice. K, so now we have that. So, let's put a payload in.

So, before we do that, also, just for demonstrative purposes, using old Kali one, still my favorite Kali. Very little RAM to use. I have a multi handler. Um so, we can just show options here. K, so multi handler, payload, Windows Meterpreter reverse tp uh TCP. Standard, running as a job, waiting for a connection back. Let me put this over here. Great stuff. So, we now know that cryptsp.dll is the one we want to target. I have my payload on desktop. So, I'm going to go there. I'm going to paste that. I'm going to rename that back. I'm sure there's a much more efficient way of doing this. I apologize. Okay, so I'm just going to say

Cuz cuz you only listen once. Okay, great stuff. So, we now have our payload called cryptsp.dll. I'm now going to run the installer. Yes, I would like to give you admin permissions. Okay, interpreter session and we got Windows just happily dying somewhere on the inside that I'm sure of. So, we say sessions {dash} r 1. Cool. So, now we've got a meterpreter. Woohoo! Yay! Fun times. There was a webcam. We're going to do an LS and blah blah blah. Cool. Awesome. We're in the downloads folder. Um and now we have a shell. But um you know, what if I maybe wanted to, you know, do some other stuff? For example, maybe invoke Mimikatz or something.

Um Can anyone tell me what I might need to take that further?

So, I'm that I'm that person now. But you know, when we hack, you know, we want to be overlord. Yes, we want to be the alpha user. So, let's just use vanilla get system. And I should probably make that a bit bigger. Get system and now we can just say get UID. And there we go. Um elevated some privs. Um what I've done in the wild here is um I have dropped DLLs in download folders. And I know that cryptsp.dll will mostly slightly affect most Microsoft installers. Not all, but some. Um and you can go ahead and drop it in the download folder and if other the user does run that installer, you're going to get that.

Um or if you have some other way of executing the installer, you're going to inherit the permissions of that installer. Now, previously when I ran wordpad.exe in that um first little failure there, you wouldn't be able to get system my because wordpad.exe is not given those permissions. But, what is quite interesting and that I found with another useful way is that I have the EXEs. I have So, these are from Windows Windows So, program files Windows NT accessories. So, wordpad.exe and wabmig.exe. These are some accessories. So, if I know that this application is vulnerable to msftedit. So, I ran Rattler against wordpad.exe. And I copied the executable to my desktop here. And I know that beard.dll

is my payload. So, I'm first going to check calc. Rename that. Going to run wordpad. Oh, dot DLL dot DLL. Thank you, peer review. What would I do without it? Um Okay, there we go. So, sometimes with applications, they don't have to reside in their original directory in order them to be vulnerable. Here, I've taken out wordpad.exe, dropped in the desktop, and it seems that wherever you put wordpad or wabmig, wherever you put it, and if you drop a DLL called ms- microsoftedit.dll, your payload will be executed. Um it might be useful at some point. So, that I found to be quite fun. And um that then finishes the demo part. So, how are we doing on time there,

Yiannis? 7 minutes. Perfect. So, I can show you guys some more really bad memes. Um which I do have. Awesome. So, thank you for your patience. Observations. What is the point of this all? So, I did some bug bounties to draw some statistics about this cuz you know, I had this tool that just automated this task. I was like, cool. Well, let's go find which, you know, vendors have bug bounties and have thick apps. So, 11 submissions. Eight kudos. So, that's the term line bug bounties. People said, yes, that is a problem. We will try and fix that. And I emphasize try because what a lot of organizations have realized is that the tools that they are using to create

the applications are susceptible. For example, installers. I mean, who here has created their own installer? You guys are way better developer than I ever will be. But um some of us who are not capable of creating our own, we use other technologies to create installers for us. And a lot of vendors have realized that the installers that these technologies create are susceptible to DLL preloading. Um there was a payout um at this point, couple hundred dollars. Um other testing. So, I looked for apps outside of bug bounties cuz I knew bug bounties cool. So, there's, you know, mandate to attack these apps and let's see what these organizations say. Like, do they think it's a problem?

Tested around 50 Windows apps. Um I went absolutely crazy with it. Um submitted eight um disclosures. Um one said, yeah, no, that's a problem. Um yeah, we don't want that. A cool company out of Silicon Valley. Reason why I remember that, last night we were chatting uh to some dudes yesterday. And it was really cool. It actually quite surprised me. It was this little startup. Not so little. In San Francisco. And I said, hey guys, your your your application is vulnerable to this. And they fixed it within 24 hours. Um some of the other larger organizations just said um we are willing to accept this risk. And I'm like, cool, man. Um yeah, you do that.

Um common runnable DLLs. So, dot net installers. I urge you to go run this against and you will see a lot of products, a lot of family of products often have a common vulnerable DLL, which I found quite interesting. And of course, what's the solution? So, fully qualified paths. And maybe some verification and validation of the DLLs that your application is using. Um and then someone suggested just not use DLLs. And then I kind of looked at them with that dev look. Like, you know, when someone, you know, criticizes your code, you look at them, you're like, no. Um I got that look and I don't know why. I guess removing DLLs out of the picture just

doesn't make sense. Maybe a better implementation, I don't know. Um but the dev in me just loves runtime invocation of methods. Like, that just sounds really awesome. So conclusion. Um is this a problem? I'll leave this up to you guys to decide for yourselves. Why is this still a problem? So, from 2010, this was common knowledge. Why is it still a problem now? Is it a symptom from a bigger problem? Is there some other big problem, some amorphous idea that we haven't quite grasped yet for that? And of course, what I often ask some people is like, do you want your code to be used for payload execution? So, if there's a mega breach and in the breach

report, it says, "Product X was used by the hackers to do X, Y, and Z." Do you want that? I don't know. I wouldn't personally um want that to happen. Future work. So, I'm sure everyone saw that error. That's due to the um non-generic DLL entry point, the main entry point. Um so, why? I want to allow Rattler to adapt and to inject to those custom entry points. So, we can get even more. So, in this case, you know that that DLL is runnable. You just have to craft your payload to use the entry point that application is using for that DLL. So, slightly more work is on the to-do list. Faster enumeration times. Um for big

applications, it takes around 10 minutes, which isn't bad, but you know, let's make things quicker and faster. Um So, maybe parallel enumeration um might help. And then uh also, once again, thanks to Safe for this great idea, the import address table analysis, which could be quite interesting. So, only target the DLLs from that address table that are not using fully qualified paths. And then yes, that's my last point there. And this is actually my my my favorite part of the talk. And I'm sure we've got a minute or two later. Um but at the end of this, I was causing quite a lot of havoc with applications. And um you know, I I suggested to I

suggested to SensePost like, hey, you know, we're participating in bug bounties and um why don't you just why don't you make the policy that let's donate to charity? Why? Well, just a personal motto is that, you know, if you can make the world a little bit of a better place, why not? And um at SensePost, we are doing this. So, I think bug bounties and charities, awesome idea. The proceeds, cuz you know, go to charity. And yeah, let's just try and make the world a little bit of a better place in any way we can, besides just dropping O'Neil all over the planet. And that concludes my talk. That is the GitHub repo over there at the bottom.

There is a blog post with slightly more information. Um it should be on uh Rattler is public. It's all there. So, if you want a little bit more info or if you want some uh more in-text sarcasm, you know where to find it. And then of course, here's some useful stuff that helped me along my way. That concludes my talk. Thank you so much for your attention and time.