Abusing WCF Endpoint for RCE and Privilege Escalation

hello everybody welcome to b-sides this morning I hope you're having a great time we're gonna hear from Chris this morning on abusing WCF endpoint 4rce and privilege escalation take it away Chris alright guys thanks for coming to my talk yeah we are gonna be talking about WCF endpoint exploitation and just real quick want to thank the organizers and the volunteers for putting on the con like my first b-sides was last year and it's a lot of fun and an honor to be up here today so my name is Chris Anastasia I'm a pen tester at illumine co-founder of a little hacking group in Palo Alto called dark corner I have a couple certifications and I'm into stuff

outside of hacking but honestly this is like my main interest it's just what I love to do and you know if you ask me if when I was a kid what I wanted to do it was pen tester so I'm very happy but the agenda for today is gonna be a brief intro into WCF we'll look at target enumeration so finding software to try to exploit we'll look at an example vulnerable service and then some real-world examples and have a demo sorry I'm kind of nervous but uh my my motivation for this talk came after my friend presented his research around WCF after getting a bunch of CDs in VPN clients and some network monitoring

software and I I read his work and I wanted to go find my own bugs along the same lines the other thing is I want to get the word out about WCF as an attack vector because I haven't really seen many people talk about it and it seems like it's a pretty ripe vector a lot of the soft that I've looked at it's been really easy to find bugs and easy to exploit them so what is WCF it's short for windows communication foundation and it's a platform for developing service-oriented applications so any application with like a client-server model and the service you know receives a message from the client will take some action based on that message and the

communications can take place over a number of protocols the most prevalent that we've seen in real life or raw TCP HTTP and named pipes so WCF services are defined with an address binding and contract the address is just a URI looks pretty familiar and it'll have three or four parts depending on whether or not there's a port and so with the scheme host port and path and bindings just specify the transport protocol for the communications so again we'll have like TCP or HTTP and then the encoding scheme could be text or binary and you can optionally configure Transport Security and there are a ton of bindings but again those are the most common that we've seen and then the contract it

defines what functionality is actually going to be exposed by the service and so you can identify the contract by the service contract attribute in the code and then the operation contract attribute gets applied to whatever methods are going to be exposed through the service so the contracts where the bugs are gonna be the issue here is not with WCF itself but the fact that the applications are exposing powerful operations over WCF sometimes in my experience I've seen that there are attempts to lock down access to these operations but they can be bypassed and also when you're looking at these operations exploitability may not always be straightforward you know an example it was like you could modify the VPN

config for a VPN client so it's not direct code execution but you can stick a line in the config that when you connect using the VPN it's going to run a command as system so not always straightforward so target enumeration we're looking for dotnet binaries WCF was released with the.net framework 3.0 and for local targets we're gonna be focused on processes running as a privileged user like local system or local service now local system is a lot less privileged than our sorry local service is a lot less privileged than system but there are ways like rotten potato that will let us callate from service to system and then for remote targets the service has to be using a

network binding like net tcp binding i see these are more often using net name pipe binding so it's gonna be only locally exploitable so just for privacy but you can use process Explorer to identify the dotnet processes that are running on your system just to highlight them and then also in process explorer if you click on properties for a process you can look at all the loaded dotnet assemblies and you want to look for to see if system dot service model is referenced because that's got all the types and classes needed to build a WCF service so beyond process Explorer you can use the WMI command line and I have a little one-liner here that queries for

all the running services on a system and we'll just run fine stir in a loop against each service binary and look for the string ms quarry dll this is a key dependency for any dotnet binary and it can be prone to false positives and negatives but for the most part it's been reliable when I'm using it and it has the advantage of working using only native tools and so it's easy to run it against like if you're doing an internal pen test it's easy to just run that one-liner against every system on the land and so I did that the other day actually and you can see a got a huge list of dotnet services and if I wanted

to I could trim the results by instead of searching for MS quarry dll I could search for a service model or net TCP and the trade-off there is that I might miss stuff but the advantage is that not only if service model Doge does show up it's a really good chance that it's a WCF service and not just a dotnet service and if I find the net TCP string then it's mostly most likely got some kind of remote service so you know higher chance of finding RC so now we're gonna look at Vonda you see of service which is a forked version of one made by verse sprite which I just made to be remotely exploitable and it'll help us

understand the analysis and exploitation workflow so analysis begins with D compilation of the target application and dotnet binaries are really nice for static analysis because they decompile cleanly into source code with variable names and comments and everything intact and I used DN spy which is an open source net decompiler assembly editor and debugger when I'm doing this stuff so after D compiling it again we want to check for a reference to system service model if we don't find that reference either in the first level of references or it could be nested inside of another but if you don't find that anywhere then the app is not using WCF and you can move on so the next thing is to find the

contract so that you can see what kind of operations what kind of functionality is exposed by the service and involuntary see the service contract service contract attribute is applied to an interface called I've Volm service it can be applied to classes or interfaces but I've only ever seen it used with interfaces and then the operation contract is applied to the run me method and so then we have a class that implements the interface and actually defines the logic for the method and this one is just going to run a client supplied string as an operating system command and then we have the main class which inherits from service base which is used to create Windows services and

you'll always find the on start method is overridden and this is where you'll find usually the address and binding information so here we have the address it's net TCP binding listening on localhost port 81 and the path is volunteer as slash run me and because it's using net TCP binding it'll be exposed over the Internet and also binding security has been disabled so by default net TCP binding requires credentials of type Windows so you're gonna have to have valid creds to connect to the service but we'll look at a real life example later on if there's time where they they did exactly this and the security mode was set to none so then there's a call to add service

endpoint which consumes the address binding and contracts actually deploy the service and so if you find calls to add service endpoint that'll help you get the information that you need to actually connect to the service so to exploit the service we need to write a WCF client the first thing add a reference to system dot service model next to find the contract and we can just copy-paste this from the service and we don't actually have to implement the method like any logic in the method Visual Studio will actually automatically it automatically generated that implementation that just throws the not implemented exception so I'll do that for you automatically and so WCF clients communicate over channels and we can use

the channel factory class with the address binding in contract to create a client object that can then be used to actually invoke methods on the service and so here we're calling run me and passing at caltech C and so we'll take a look at a video of what that looks like so on the left hand side there's a windows 7 virtual machine the service has been started and i have process explorer highlighted on the service itself on the right hand side is the Windows 10 host machine where I'm gonna run the exploit and you'll see calc get spawned as a child of the service

and it's just gonna run a couple more times and you'll see more more calyx

okay so now we're gonna look at some real-world vulnerabilities and again we're looking for bugs in the application logic there's not a problem with WCF itself per se but whatever functionality has been exposed through it and the issue here seems to be that developers aren't considering the idea that rogue clients are going to you know connect and interact with these services or if they did they've made faulty attempts to lock down the service so a few months ago I found a privileged escalation bug in checkpoints zone alarm antivirus it has a service called checkpoint sandblast agent updater service that has a named pipe service that can be accessed by unprivileged local users and the service can be used

to trigger a call to a method called execute installer which will just run an arbitrary exe s system so it's not too far off from the run me method that we just looked at and the way I found this I googled for best antivirus and this was in the list so I know it's one of the best I ran the one-liner and it started a bunch of services actually started for unique services so far the only one that I found to be exploitable was this SBAC podía service host and then ID compiled each service and looked for a reference to system service model after that I started looking for exploitable functionality and Method names are

really helpful again it's it's so nice that these things compile into source code with the names and everything it just makes it a lot easier to understand what's going on and so I saw a method called execute installer that sounded very interesting again it'll run an arbitrary exe a system and it's based on client supplied argument so once I saw that there was you know some juicy behavior there we needed to figure out how to connect to the service and so the service endpoint definition is inside the on start method and there are two named pipe end points I get established and they're also calling this add secure WCF behavior on the endpoint which was a

clue to me that they had done something to try to secure the channel so this was one of the first ones I looked at so as I was doing this I started trying to build a client from scratch kind of like how we saw in bone WCF service but a lot of times that's not necessary usually there's existing client code sitting alongside the service binary in the install path and so I found this SP a stub DLL which had everything I needed to actually connect to the service so I created a new project added references to that DLL plus all its dependencies and I created this SP a stub object and I just use Visual Studio to tell me what

methods could be called on that object and so the first one I looked at was called register SP a stub and I liked this one because it just took a simple string as an argument so that I didn't have to create any complex structures to interact with it and also because I knew that if I successfully registered a stub whatever that means that it would end up in the logs of the AV so I would have evidence that I had successfully interacted with the service unfortunately none of my registrations were getting logged and it took me longer than I'd like to admit to figure out what the problem is but the the name pipe server it first it gets the pig of

the client that's connecting to the service and then from the pig it gets the actual file name of the client once it has the file name it creates this x5 nine certificate object from the client and it calls verify on it to see that it's actually a valid certificate so it validates the certificate then it reads the CN field of the cert into a variable called text and then finally it compares text to a string that says check Point Software Technologies Limited so it wants to know that it's a valid cert and that it's signed by checkpoint so that's why I couldn't talk to the service because my client wasn't signed by checkpoints so I considered two

possibilities to bypass a check the first was to inject code like DLL injection into a legitimate checkpoint binary the other was to sign the exploit code with a self-signed certificate after I posted this exploit on reddit James Forshaw pointed out a couple other possibilities including one that I really liked which was that the check uses processed main module to read the filename of the connecting process and that method reads the file name out of memory of the client which is under attacker control so you could start the client and then modify that structure in memory to point to a actual checkpoint binary and pass the check that way to so because I didn't know how easy it was to

do self-signed certificates I first went with the DLL injection which sort of worked but I had to disable a feature of the AV for the DLL injection too it would block DLL injection so at the end of the day I had to go with self-signed certificates and I read an article by Matt Graber that pointed out that nan admins on Windows can trust root CA certificates so that means with a few PowerShell commands I can create a self-signed cert trust it on Windows and then sign sign the code with it so I signed my exploit and then I tried to register stub and and you can see that the stub registration did get logged this time so

that's good so now I could actually interact with the service so once I was working I started playing with a method called send command it takes one argument which is a string of XML called command XML and this argument is received by the services on command receive method which through a chain of calls eventually passes the argument in to execute installer inside execute installer the XML gets deserialized into a couple different objects one of those objects has a field that's a string called installer package path and that's really the only thing I needed to pay attention to and whatever exe installer package path is pointing at that's what's going to get executed by this method so the only thing is whatever

program that's pointed to by installer package pet also has to be signed by checkpoint so again I considered two possibilities one was to DLL hijack a legitimate checkpoint binary and the other was to use self-signed certificates again because I was ignorant I used DLL and hijacking first and that's viable and that would have worked but signing the code was cleaner and easier so now I'm going to show you guys what that looks like and I did not start my VM so let me start my VM up here

I'll make this bigger

okay so first thing we're gonna create the certificate object with the CN set to checkpoint Software Technologies Limited and then going to export the cert to a file called fake cert sir and then we're gonna import it and this is the part that's kind of questionable about why can non admins do this on Windows so we get this nice warning that we can just click through and then we're gonna sign the exploit which is the WCF client and then we're going to sign the payload which is the code that's actually going to get run with high privileges and so we'll just take a look on the user test right now and if we list the local administrators you can

see that test is not in that list so we're not already in admin and I'm just going to do this so when I run this we should see a new local admin get created called zone alarm exploit

and so we got them right there so thank you [Applause]

how am i doing on time ten six minutes so okay I'm just gonna cover another vuln that I found just over the weekend which is in some no-name software called power plan by quest oka it doesn't matter that it's no name it's more just a point to see how this stuff works and so and it's a remote example so this service establishes a net TCP WCF endpoint which can be accessed by unauthenticated remote users and it exposes an operation called get processed data which you can access to get a connection string containing clear text database credentials so I found this on a pen test nessus had reported an unquoted service path which is a pretty boring finding

from necess but the the service was called WCF bla bla bla service which caught my attention so I was like let me go analyze this and so first thing I wanted to find out again we're in the on start method of the service and found out what the address was net TCP and then a public IP address public meaning not loopback so it was still it was on a LAN it was an Internet exposed and then the port is 8,000 and the path is my service we're using net TCP binding with security disabled I found client code in dll called powerplant client DLL and it defines a class called service interface client so the class implements the

methods defined in the I service interface interface and you can see get processed data is the one that that we exploited so I added references to the service DLLs the constructor for the service interface client wanted the address and binding part of the arguments so I had to define those myself and I I had to set the security mode to none in order for it to work and this is the entire exploit right here so I defined the address to find the binding I created the service client object and then I I just called get processed data on it and inside that is the connection string so part also part of the constructor for the service

interface client was a service interface callback class which you'll see sometimes they want these callbacks and the callback is only defined as an interface so again I just had to do stub implementations for all the the interfaces methods which Visual Studio will do for you automatically and and this is what it looked like heavily redacted but but I got the the name of the database server that it was connecting to as well as the user name and password I was able to then go log into the database I didn't get any XP command shell though unfortunately so in conclusion dotnet D compilation makes static analysis easy because we get source code we're exploiting the application logic versus WCF itself

developers don't seem to be considering that we're going to interact with their services or if they do they they don't secure it properly and WCF like I said I haven't heard a lot of people talking about it so I hope that this talk you've kind of learned how to do it and can go out and find your own bugs and that's all I got [Applause] so we have a couple minutes for questions does anybody have any or either here or online if anybody's listening it yes do you know it is WCF have like encryption support I think you touched on it but I was distracted it does and it's it's default actually to use TLS to transport the messages yeah

yes sir I believe there is I haven't I've only like I scanned one with nmap the other day and I forget exactly what it says but I think I think the answer is yes so any other questions cool thank you very much Chris [Applause]