 Okay, good afternoon everyone. I'd like to apologize for the quality of the audio. It's not actually the mic, it's me that's lost my voice. We don't have a lot of time, so we'll blitz through lots of this. Sense Post is a small security company based primarily out of South Africa. We've been speaking at DEF CON for about the last seven years, which kind of explains why my voice is gone. So, on my left is Marco, Senior Sense Post Associate. Hello. I'm Harun, for those guys down there, the scratchy voice, the tuft of hair you see over the podium is me. What the talk's about is, chiefly, some new tools that we've released, some new ways of getting in and out of your network. Once we've got a small foothold, how to effectively drive a bus through it. Okay, so we're going to be doing this chair-switching thing just because we're driving off one notebook, so give us three seconds in between that. What we're going to start off very quickly is with a brief history of how you've traditionally got network traffic into and out of target networks. And in the pre-firewall days, if anyone can still remember those, most machines had publicly addressable IPs, or at least they were routable, and we could send out traffic directly there. And that also gave us unfired access to the rest of the network. Happy days. Of course, people realized pretty quickly that that was a gaping flaw, and so we found firewalls were deployed, and that would have prevented inbound traffic. But for a long time, outbound traffic was still allowed. So we saw a plethora of tools being developed, mostly supporting command execution through websites, so the upload of some kind of web shell. And if you had an outbound channel, or if outbound traffic was allowed through the firewall, you could easily set up your netcat and once again get to a pretty comfortable place. That continued with the creation of binaries on the machine, so where you would need to upload netcats, there were a bunch of tricks to upload. One was to use debug.exe on the Windows platform, use that to write out binaries. Others were to upload specific upload pages. We also saw the notion of binding in front, excuse me, binding in front of open ports around 98. So these were all sort of traditional ways of passing your traffic in and out of networks, but none of these things really work today. At some point, this thing got classified as a Web 2.0 talk, and we figured, because we had the words Ajax somewhere in our slide deck. This is the one slide where you'll see Ajax, you won't see it again. What this slide introduces is just, again, it's another web shell. In this case, though, what we've got is a JSP that uses XML HTTP request object to actually execute the shell that you need. Same screen. So let's figure this. I'm going to WebKit. Okay. So this is our web shell. It's a JSP file that we've uploaded to a target web server. Harun's going to speak a little bit about how you can actually get the JSP on the web server, but in this case, we can run our regular commands as if it were, if I could type, we would see this is a regular UNIX shell. It just gives you that web interface. So again, nothing new, but in that case, it's got a bit of Ajax. So it's a Web 2.0 talk, apparently. So we saw those traditional ways of getting data into networks and out of networks. We also saw a while back sort of the notion of pivot machines, whereby you compromised a particular machine that you had access to and had a channel to and used that to pivot traffic around the networks. In other words, TCP port redirectors for the most part. And so this was possible in a number of ways. SensePost had an early tool called QuickKill. It was also possible through a bunch of Netcat instances for the really ghetto attempt. SensePost had another tool called TCPR. Foundstone had F-pipe. And Harun specifically asked me to mention the word Circa. So I say that the tools were Circa 2000, and I should still have a job when we get back. So how do these tools work? Well, pretty simple. You have a client on the left. That's the attacker. On the right hand side, you have a target. The client doesn't have a direct route to the target. The target's listening on a specific port, though, that the client wants to speak to. What the client does have is access to a pivot in the middle. So he uploads and runs his tool, TCPR. That tool listens on a given TCP port. The client makes a connection to that TCP port. And the pivot on the other side makes a socket connection to the target. And then in the middle, you have this pivot. It acts as basically a proxy, and it can pass traffic between client and target. Nothing new. One point to mention at this stage is that today, people are still looking for F-pipe, TCPR, and those kind of tools. If the machine you're attacking is XP1, 2K3, looking to NetSH and port proxy, when you install IPv6 on Windows, those particular versions, you get a TCP port redirector by default on the OS. So look into it. The next option for these pivot techniques is through the use of SSH, and we're mostly all familiar with SSH and its ability to tunnel traffic. So again, with the same situation, we have a client pivot and target. In this case, the pivot, which is the machine that the attacker has access to, it runs a secure shell demon, and it listens by default, of course, in port 22. The pivot has access to a target that's inside the network. And in this case, it's listening on port 25. So if the client has credentials for the SSH server, the client can log in with the minus L flag. He sets up a local listener on the client, and once the SSH connection is made through the pivot, the pivot makes a socket connection on the other side, and SSH will carry your traffic from the client all the way through to the target quite nicely. So it gives you an encrypted tunnel onto your target network, but it's not particularly useful. And the reason for that is it requires that the target runs, or the pivot machine runs a secure shell demon that you also have credentials for. So that can raise a number of barriers. So the second option is to flip that around, not use minus L, use minus R. Minus R creates a remote listener instead of a local listener. So in this case, what we do is we run the secure shell demon at the attacker side in the middle, which is the pivot machine. We simply upload an SSH client. So we don't actually have to install services or allow for inbound connections. In this case, we can make outbound connections. So Putty and Peelink are two easy ones for Windows-based attacks. So as I said, the SSH runs on the local machine. It listens on port 22. Pivot runs on the pivot, or SSH client runs on the pivot. And on the far side, we have the target, which is running, in this case, RDP. So through our command execution vulnerability, which is assumed at this point, we run SSH from the pivot. The pivot connects outbound to our SSHD. It sets up a remote listener on the attacker's machine, and it creates the socket on the other side to the target, and now the attacker can still connect locally to his machine and have traffic go all the way through. The benefit with this, just to recap that, is you don't need A and SSHD on your target, and B, you don't need inbound connectivity on port 22. One other option for carrying traffic is DNS to TCP, which, if you haven't looked at it, is really, really useful. So DNS proxy it over a bunch of protocols is fairly old, but it's still extremely useful. DNS is often one of the few protocols that is allowed out of a network from any point. So DNS to TCP allows you to carry TCP data over DNS. Check out the website. It's really good if you're in limited hot spots for getting Wi-Fi access for free. So what we have here is we're going to use a combination of DNS to TCP and the latter secure shell proxy technique. So in other words, we are going to upload to our target both the DNS to TCP client as well as the secure shell client. The reason for this is we're not going to remove the explicit requirement for outbound secure shell access. So where the only tunnel or the only traffic that's allowed out of your network is DNS, we can still proxy traffic over secure shell. So it's pretty simple. Set up your DNS to TCP tunnel outbound from the target to a DNS server that you control over that. You run that secure shell minus R attack that I spoke about. The attacker would connect to the listening end of that secure shell tunnel and still now he has a way to get his traffic into and out of the network. And in this case we're using a combination of as I said, secure shell and DNS to TCP. It's taking one more step lower in terms of the protocol stack. Some of you guys probably would have mentioned Layer 2 bridges if we hadn't, so we will. One option is when connecting to target networks, one option is to connect to specific ports and IPs, which is what secure shell allows you to do. So you set up a tunnel between yourself and a very specific service. But if you bridge the two networks at Layer 2, then you're in a much better place to explore the remote network without having to explicitly point your tunnel at particular hosts. So there's a couple of limitations, but it can be quite useful. It does require both inbound and outbound connection ability. So here's the quick schematic. You've got access through some network and a firewall onto a target machine. A victim, it sits in a LAN. You go in through a firewall at this point because you're allowed to. And what a Layer 2 bridge will turn that victim into is a gateway onto the remote network. So in that case you can still access all the machines on that network. There's a couple of pros here. As I said, it's protocol independent. It's carrying Layer 2 traffic, not Layer 3, which is pretty cool. It's simple to use and set up. But any decent firewall rule set will cancel this out. There's a couple of examples of Layer 2 bridges, Tratton, my network, are two of the more common ones. Okay. So just a quick recap. We used to be able to hit everything we wanted to way back in the old days. Firewalls were more forgiving, always good. Outbound access made us amazingly happy. So we could tunnel stuff as long as we could go outbound. But these days most networks you care to hit will be under slightly tighter lock and key. So what we're looking for is some way to do all of this cleanly over HTTP. So if we take a look at what started its life off as Glenn.JSP, effectively the scenario we're looking at is we can hit our target on port 80. We have the ability to upload files on the server. But all we can do is hit it on 80. Okay. There's tons of ways that you get upload access. These days, if you search for JMX console, you'll find still find a ton of them that allow file uploads. So network filtering is tight. We can't make outbound connections. We can't make other inbound connections. There's possible proxies in between. So we need to talk good HTTP to our target. We can't get Netcat to just bind in front and give us a shell. So all of these problems met one really smart internet sense post. And what we ended up with is something that's currently called Reader. So just to paint the picture, we're looking at a network that looks something like this. We've got our attacker sitting down there. We've got access to an Ubuntu machine. And inside of that network, there's a term serve box and an SSH box. Okay. So really quickly, what I'm going to be doing is I'm going to load up a piece of JSP on the victim server. I'm then going to load a little proxy on my end. And what we're hoping for is that we can then aim traffic at our local proxy. The local proxy will convert TCP to HTTP get requests, which will talk to the remote JSP. And the remote JSP then exits it as TCP traffic again. So essentially, we'll be talking clean HTTP. And we'll be pushing TCP clean through the network in a fairly independent way. Okay, so I'm going to quickly go through the demo. We've already uploaded the file to a directory called upload on the server. I'm going to kick that off. Okay, and what we've got there is the server saying, it's cool. Let's talk. And if I had control of my mouse, what this then does is allows us to connect to a local proxy to give it commands. Okay, so I'm going to connect to the local proxy, cut and paste a command just so my bad typing skills don't give stuff away. Okay, and essentially what we're going to tell it is create a tunnel on my machine port 1234, talking to a wind 2k 3 box inside that network on 3389. Essentially, I should now be able to aim at local host 1234. And what you're seeing back there is all of my traffic becoming HTTP posts, going off to the remote JSP page. And essentially, you putting TCP completely clean through. Okay, you will find it's a little slow. And you will find that I can't spell. But what you should notice is it's perfectly usable TCP. And at this point, if you know how terminal services works, every movement here is requiring traffic to go to the server. The proxy is going to happily push that stuff through. Because of the way the proxy works and because Glenn is actually much cleverer than us, you can actually create multiple tunnels through this interface. So you could just as easily go to our control point and tell it to create another tunnel that goes to another box for SSH access. Okay, then make your connection traffic going through. What you should notice is that RDP and SSH are talking binary protocols. So at this point, we're not just putting, pushing text through this. Essentially, you can put anything through it. The proxies handling TCP completely natively. Let me just kill it. So there's no more of this. Okay, so that's the very ugly way to kill it, which is kill your proxy while it actually wants to be running. Okay, so what it means is we have a clean, simple TCP over HTTP or HTTPS solution. And all it requires is the ability to create a JSP on the remote page. If we're going to create a JSP, surely it's not JSP specific. Ian at sensepost.com ported this to ASP. So we have reader.asp that will do the same thing. hat at sensepost.com gave us the same thing in PHP version. We'll release all of these tools on our blog as soon as we get back home. Shal and Nick drew the cool vizios that you saw. Essentially what it means is if we can create a file on your box, we can create a circuit through to internal hosts. Okay, we turn our attention to a slightly different topic, and that is one of the coolness that we can get out of SQL boxes specifically. So as you see, most of the stuff that we're doing here revolves around web slash databases. And that's because that's typically what we come in or bump into on our assessments. Last year at Black Hat, we released the tool squeezer, and it was just another advanced SQL injection tool aimed at MS SQL. And if you know the space, you know that pretty much every company, every guy who plays the stuff has written his own tool. So there's a lot of tools out there. We figured we'd pump out one more year. And we'll drop it after this. squeezer had won a slightly different approach to injection. And that was that it split the generation of data that it would extract from the way that the data was extracted. And that had a couple of quite nice benefits for us. I meant that you could do a bunch of stuff in order to grab data on the database, and then you could use a number of other techniques to extract it. And that gave you the ability to mix and match generation modes with return channels. So this is the simple flow. Generate your content. We could generate content in a bunch of ways. The standard one is command execution. We also supported the ability to pull out data from the database through quasi SQL queries. And we also supported the ability to copy files off the database to download files from the database machine. So you would create the content in one of these manners. That data was stored in a temporary table inside the database. And at that point, we could kick off one of our return channels to pull the data out. And we supported three different channels. The one was DNS. The second one was timing. And the third was error messages. DNS, you've already seen a bit of noise about yesterday. Robert Rick spoke about DNS extraction or exfiltration over or on Oracle. So the technique is fairly similar to that. The timing technique is nice because it requires no outbound channel or no explicit outbound channel. We could simply time HTTP requests and from that pull out all the data. Of course, the timing, as you can imagine, was pretty slow. We were timing out one bit at a time. And when you're looking at sort of two seconds for a one bit, it could take a while. But given enough time, it was usable. SQL error messages was, it's fairly well known at this point. So this process is nice. It's not fast enough, we think, for real time applications, but certainly batch type applications or command line interfaces. It's pretty nice. But don't expect to relay VNC or RDP traffic. So I'll do the demo shortly. In this case, the DNS channel was worked as follows. We had that temporary table in the database. There was a whole bunch of data in that table. We would pull out a line or a row from the temporary table, chop that up into a fixed chunk, convert that to hex, add a domain, and initiate a DNS query on the domain. On our side, that is, the attacker side would be monitoring our DNS traffic and pull that data out of it. The entire channel was handled in SQL. Elevated privs were used if found, but they weren't necessarily required. And the one nice thing with Squeezer is it did provide reliability guarantees. So it had the ability to re-request data and detective data had been lost. SQL Ninjas, another awesome injection tool that you'll find out there, and it's got a lot more features than Squeezer. It also supports DNS exfiltration. However, it uses a slightly different model. The DNS channel is handled by a standalone binary that you have to upload, so it gets a little awkward. But it's still a much cooler tool for other stuff. So SQL Ninja for the win. So to provide another schematic on how the DNS exfiltration worked, we had the attacker pumping through some kind of filtering device that only allowed our web traffic to go through and outbound DNS. A victim SQL server. The attacker issues some kind of command to create data. In this case, he issues a command that will be executed. The data that's created is stored in the temporary table. And he then sends a second injection string that, as I said, breaks up the data in the table row by row, chunk by chunk, converts it to hex, and performs a lookup on that hex encoded data. When that arrives back at us, we can convert it back, and we get the clear text. So to give you an idea, what I've got here is a Squeezer setup. On my next console, I'm going to show you TCP dump. It's just going to pump out the DNS queries so you can see I'm not completely faking this. I run a command. What is happening here is Squeezer packages the command in an injection string that's already configured, sends it off to the server. And what we'll see is the server starts to make all the requests. Coming out with the data, we decode that, print it out to the screen, and you've now got a really nice command interface running over DNS. But again, this is, this year, that's not super new, but we'll talk about something that we think is pretty cool. So in 2002, which is now going on for six years, Chris Anley wrote an awesome injection paper, and in it he discussed early objects and the use in injection strings. And what he found was it was possible to read and write files, execute commands, and all of that cool stuff that we used to do in injection, but without using the interface that most injection tools use. So to execute commands, most injection tools will run XPCMD shell. He figured out that actually you can use the early Windows shell scripting, I think it is, object. However, you don't see too much in terms of early integration into current injection tools. And we wanted to explore this a little bit to see how far we could push it. So what we got to was a SQL-based port scanner. And this runs entirely in T-SQL. It doesn't require the upload of any binaries or any of that. Once we kick it off, all of that stays in the same memory space as the SQL server. So its basis is the MSXML2 server XML HTTP object, which is a bit of a mouthful. But it's the same object that's used to make or to pull in XML data. And it's really, really useful. It's installed with, as I say, IE and IIS. And what we can do here is basically craft a URL made up of our target IP and the target port. We use OLE to make or attempt to pull XML data from that URI. And then we monitor the return codes from a bunch of methods. And based on that, we can determine if a port is open, closed, filtered, or running a web server, which is kind of nifty. So I've gone through, I think, most of this. So the one thing to point out is we differentiate between closed and filtered ports just through the use of timeouts, which is pretty much what everyone else does. So the technique behind the port scanner is pretty standard, but what we've done is shifted this into the SQL server itself. Of course, what it does require is either OLE objects, well, not either. It requires SA access in order to use the OLE methods. But given the number of web servers or web apps that we see that use SA, often this isn't the big problem. So this is the building block. This is a stored proc that we create on the server. It's called Probypy. You pass it an IP and a port. The stored proc creates the URL, creates the OLE object. It sets some timeouts. It opens the object, sends the request, monitors the status, and then based on all of the return values from those methods, we're able to fingerprint whether that port is open, closed, or so on. So using that as a building block, we can build further stored procs. In this case, we've got two. The one is scanned ports, and the other one is scanned hosts. So across a range of either ports or hosts, we can scan for a single host or a single port. You could also write a web server detector pretty easily with this. So let's give you the demo. Again, I've got another config file. All the setup is done. In this case, I can specify an IP address, give it a couple of ports. In the setup that goes through, it creates that building block Probypy. It creates the other two helper stored procs, and then it starts to scan. And we get the info art. It tells us that some of those ports are closed, some of them are open, and some of the open ones are actually running web servers. So it seems a little convoluted, but consider what it buys you. In this case, you don't have to upload Nmap, you don't have to upload any other tool. What it gives you is an AV-free or a detection-free way of conducting port scans. There's also, as I say, unless you're performing traffic analysis, you're not going to pick this up easily, specifically on the SQL server. It can scan almost all ports. What you'll find is because there's some protection built in for cross-protocol attacks, web server, or sorry, not even web server, the IE objects can't connect to all ports. But in truth, it's not so much of a limitation. It can only not connect to, I think I said, six ports. So out of the 65,536 ports, we can't scan six of them. And in fact, they're often not the ports that you're most interested in anyway. The other thing that'll buy two are proxies. So if the machine has a proxy set, then your traffic is going to be directed through there. But in truth, that's also not a limitation. There's an early object method to disable the proxy. So we figure that the early objects deserve more looking at. One of the things that buys you is platform independence. So SQL server version or SQL server across multiple versions supports this functionality. And we figure people should be playing with this stuff a little more. OK. So when we first wrote Squeezer, we weren't specifically aiming at SQL 2005. We then put up 2005 because we heard a lot about it and expected that most things would break by default. OK, because SQL 2005 has largely been Microsoft's flagship product for the STLC push. SQL poses interesting challenges. It's highly public. It's been highly exploited. And most of the exploits against it haven't been Microsoft's fault. So they get a bad rep for most SQL injection attacks. And actually it's not something they could do much about. So they took steps to try to reduce the attack surface. Essentially trying to stop people from hurting themselves. Pretty much like you force people to wear seat belts so they don't kill themselves. Lots of famous hacksaw celebrities have come out saying how they hate going up against O5 because of how secure O5 was. OK, we didn't find this to be the case. So fundamentally, probably the biggest problems that we pick up are neatly summed up. I thought by this picture, but it turns out that I'm the only one who makes any head or tail of it. What we're going forward with this picture is that on the one hand, you've got the surgeon general telling you that smoking is a bad idea. On the other hand, you're being told to come where the flavor is and come to where the flavor is about five times the size of the surgeon general's warning. OK, it's quite clear that this ad was not put up to tell you don't smoke. OK, if Microsoft were trying so hard to cut down on this functionality, adding tons more functionality into SQL Server was probably not the way to go. So you end up with very mixed messages. So the ultimate in scientific tests, you do a Google 2005 plus reduced attack surface, 106,000 hits, O5 and new features, you get about five million. OK, any software engineer will tell you that features will win because of the dancing pigs problem. Mr. White pointed out that actually Ed Felton said, given a trade-off, Gary McGraw and Ed Felton said, given a choice between security and dancing pigs, users will choose dancing pigs every time. And the problem that we bump into here is management by InFlight magazine. You could tell your boss that SQL endpoints in SQL are a bad idea, but if he read that this is a shiny new feature in SQL 2005, it's a safe bet you're going to build an app making use of both endpoints. OK, the second big problem that you bump into is that of in-band signaling. OK, in-band signaling has been biting us for such a long time that it's really painful to say it, not just because of my throat. When Captain Crunch started attacking phone systems in the old days, the reasons he was able to do what he did was because the same channel was being used to send commands and data. When we look at buffer overflows today, essentially the core of it is because data and instructions look the same, and if we can send it data and convince the computer that those are instructions, we're able to execute commands. And essentially, as long as you're using in-band signaling, you can't really claim to be secure by design. If we take a look at the way SQL Server was getting exploited across the net in the past, every tool was using XP command shell, so soon every doc came out with how to disable XP command shell. So in the normal arms race style, every tool now has a little click box that says re-enable XP command shell. In fact, all of the features that come locked down by default on SQL can be re-enabled through SQL queries if you've got the correct permissions. The in-band signaling helps administration, but is probably not the most secure way to do this stuff. So ad hoc queries are disabled, ad hoc distributed queries are disabled by default. Cesar Serudo's data thief used to use it to take data out of your network. XP command shell disabled, CLR integration is disabled, and literally as long as you've got SQL injection going, you can use the same channel to re-enable the stuff, which is part of the problem. So other than all of the old griping, we figured we'd have some new ones, and the two that we're going to look at is XML integration and CLR integration, or XML web services. So the marketing pitch for XML web services straight from Microsoft basically says, use this mechanism, you can create soap endpoints from within SQL server. Anything that can parse XML can now send requests and talk directly to SQL. So already this gives us two cool things. One is the ability to launch DOS attacks on the web server, the other is a good cross-platform query manager. So if we look at DOS, there's a very obvious example which we'll run through, but basically you create the SQL that says I'm creating an endpoint and my endpoint lives at slash SQL demo. You then, when you want to consume this web service, AMAT slash SQL demo, it gives you a whistel and you can build a little executable that then talks to this soap endpoint. Okay, now this starts to become interesting to us for multiple reasons. If we take a really quick look at a demo web server that we've set up, what you should see is on slash test, we have a very basic page that basically says welcome. Okay, what I'm going to do now is in SQL server run that create endpoint query, which we demoed. Okay, so we create it, it says command completed successfully, and surfing to this page you should see that effectively SQL server soap endpoint takes precedence over IIS. Okay, and the reason for this is at this point you should be able to aim your tool at it, get the whistel and start talking soap to it. Okay, so effectively all you're doing is very quickly killing IIS by telling SQL server to write to that path instead. Excuse me, hey, that works better. So something that's obvious is this had to come up during threat modeling. Okay, during threat modeling someone had to say, hey, this is a possibility, but what's interesting is as long as you've got SA or as long as you've got the proofs that you need, you're going to be able to do this creation. Also interesting and again straight from MSDN, you'll see that there's an option when defining the site to use asterisks, which basically says if you've got IIS serving multiple sites on this web server, overwrite all of them with your endpoint, not just one particular one. Okay, so this becomes interesting because even if file system writes prevent your SQL admin from doing bad stuff to your website, this new plan allows him to pretty much own it by binding in front of your web page. Essentially it's like the netcat portbind only 10 years later. What's interesting about this is I've shown you the demo via SQL query manager, but anything that we can do via query manager because there's in band signaling, we can actually also do via our SQL injection. So what we're going to take a really quick look at at this point is something like this. So if I quickly get to my scratchpad, we're up on screen, let's just turn on my brain. Okay, so what we're going to look at here is a very simple straightforward classic SQL injection page. So if we go back here, what you should see is pretty much the stuff that you used to single quote or one equals one stuff of a form that looks like this. Okay, and what we're going to do here is basically run this function and what you're seeing up here is I'm creating a function called get server version, a little stored proc called get server version and adding it to SQL server. You get an access denied which is cool. All it means is that we've entered a good SQL and then I'm going to run the second injection string which basically tells it that I want to create a web service on path slash SQL slash demo just because we couldn't think of a better name. But what that then means is that we can connect to that path, we can connect to that path, let's say that one more time. Essentially it means we should be able to surf to it and talk a good SQL. Okay, what you should be noticing again is the SOAP endpoints created and this time we created it completely remotely via our injection string. Okay, so what this should mean is that we now in the position to remotely create an endpoint and get this endpoint to run the function that we gave it, told it to run. In this case return at at version. So the obvious attack pattern that we were going for here was let's create a SOAP endpoint that accepts any request from us then evals that request and sends us the response back. But it turns out that Microsoft actually beat us to it. If you read any of the documentation on creating SOAP endpoints, you'll see that something that goes along for the ride is something called SQL batch, sorry SQL batch without the squeakiness. So if you take a look at the whistel that we just published, you'll notice it actually pushes down two functions. The one is get server version, the other one is SQL batch which is a built-in way of saying I'm going to send you SQL, please execute the SQL for me. Okay, and that's a built-in. So essentially we'll use our attack string, this time we filed it down so that there's not a lot to it and essentially all we're saying is create a new endpoint with absolutely no function behind it but please enable batches. Okay, so that should be familiar but what it does mean is we can now use any SOAP client and send completely arbitrary queries through to this and SQL server will execute them for us. Okay, so we can use the old technique, let's do ipconfig, pump it to a table, let's query the table and all is good. We're almost out of time so really quickly the next thing that was cool was CLR integration. When we wrote squeezer we did all that stuff inside of tsql and although tsql is Turing complete it was never intended to be building TCP replicas in it and so Marko lost a lot of hair in the process. Fortunately for us O5 now comes with the common language runtime built-in which means we don't have to inject tsql anymore we can start injecting CLR C sharp code. Okay it's turned off by default but again SP reconfigure will allow us to turn it back on. CLR integration does allow you to give assemblies really fine grain control but you can override this fairly easily. So the question is remotely how do I load a .NET assembly? The first thing we came up with was let's remotely create a C sharp file on the file system and so what you'll see is we use XP command shell create file create file create file it's really painstaking and then we hope that the remote box has a compiler to then compile that into an exe. Fortunately for us all versions of sql from O5 upwards now ship with the compiler built in so csc.exe will be sitting for you in the very predictable Winder DLL cache csc.exe so you can upload a file line by line call csc to build it and then execute it but that's a little bit ghetto. So instead we consider using an old Windows trick which is load the DLL via UNC path. Essentially we tell SQL server create this assembly from this UNC path SQL server then comes to our UNC path fetches the DLL and runs it in its memory space. Okay but even that it requires outbound UNC which still makes it a little ghetto. Fortunately there's one more technique which basically says you can pass me the hex for your assembly as part of your SQL query. Okay so it's in-band signaling plus plus give me the hex I'll build that executable for you when you need it you execute and all will be good. Okay so when you load an executable in SQL server it gives you different options by default executable loads as safe which means it can't touch anything it's sandboxed but if you told it I want this executable loaded and I want it to be unsafe then essentially your executable can do anything make outbound connections make arbitrary TCP connections and it's fine you might not have so even if you essay you might not be able to do that because SQL surface area configuration tool might have turned it off. Fortunately you can inject the string alter database set trustworthy to on and everything is trusted and you can then do what you want again. So really quickly basically all we did is convert we took a standard TCP socket program and we converted to hex it gives us this insanely long injection string and so essentially all I'm going to tell SQL server here is that I'm sending you a assembly please load this assembly you should see it taking a little bit longer because it's now building this binary for us inside of SQL server. While that's building really quickly if I go here we should be able to check and see so you should be able to see down here the ports that are listening on SQL server and what's more important is that you shouldn't see a listener on 8001 if we go back here our query is now run essentially now I'm going to tell the website that assembly that I just sent you please create a stored procedure that references that and that seems happy and essentially all that's left is for us to call this remotely so we call this remotely and what you should see on this side is if we now do a listen there's now something listening on 8001 what you should notice is that 3616 is essentially so if we did 3616 is actually SQL server so we broke down the exe sent it to SQL server SQL server is now running it inside of its own space okay so so really quickly what does this mean to us it means the funds just starting effectively it gives us a remote way to throw binaries into SQL server that stuff's not going to be touching disk as an executable itself it's going to be an expanded SQL table so forensics get more interesting we can launch the stuff with whatever privileges you able to master it should allow us to rewrite squeezer in CLR and make squeezer a lot more powerful but in the short term what it's allowed us to do is combine squeezer and the redirection that we showed you via jsp or asp so essentially what it allows us to do is make another picture in this case if you consider that squeezer basically abstracted this link so that it didn't matter how many hoops you went through you and the database seemed to have a clear connection we can now dump the jsp file equivalent inside a CLR program get SQL server to execute that then push our traffic through squeezer so even if there's no return channel squeezer will find one either via DNS or via timing and then talk aiming our RDP client at our own proxy would then go from proxy to squeezer squeezer would then talk to the database and traffic would go in or out however squeezer decided to find it for you and then tunnel through on the remote end perfectly clearly okay it's really small but what we do have for that is a quick video which I think Marco has loaded Marco has loaded here and essentially if you look at this okay cool so we out of time you're gonna have to believe the video we'll also put it up on the blog essentially what the video allows you to do is tunnel through SQL exactly as we tunnel through jsp except a lot slower the stuff that pushes through SQL is super super ghetto which means we only finished it during black at and I don't envision that we'll be releasing that for a while the ASP JSP PHP will be on our blog as soon as we get back to South Africa we'll be in 105 for questions thanks much