 My name is Michael Brooks, and I'm really glad to speak here at DefCon. This is my first time speaking here, and so far I've had a blast. What we're talking about today is attack chaining within web applications, and particularly how CSRF can be used in attack chains. We'll be talking about high-impact exploits, as you will see. Also, at the end of this talk, there will be an oh-day of vulnerability being released with exploit code, as well as some other goodies. Okay, let's... oh. Okay, first of all, as a show of hands, who thinks CSRF is lame? Who thinks it is the lamest fly out there? People even take it seriously. Okay, we got one. Wow, I'm surprised. Honestly, I thought CSRF, even a year ago, I thought CSRF was the lamest vulnerability. I mocked the OWASP for putting it as number five on our top ten vulnerabilities. I laughed at CVE numbers relating to CSRF, until I started doing my own research. Right here, this is a piece of HTML code, and it is sending a Git request to cPanel web host manager, and it changes your root password. That is right, remote root with CSRF. CSRF is the member is remotely exploitable flaw with the highest impact possible, and we will see more high-impact flaws with CSRF. This is also... it also affects embedded devices. In this case, I am C-surfing on a Motorola surfboard cable modem, and I'm able to knock you offline just by you visiting my website. Anyway. Now, what is the surface area problem in software? In code quality control, you can use software to detect how much of your code has been executed during a test. And this is a way of gauging a surface area, how much surface has been tested. Now, humans are bound to make mistakes, and eventually they're going to make a mistake, a bug that a hacker can take advantage of. This is bugs per line of code. So now I'm talking about a tax surface. I'm talking about places in the application where I could gain access. I could gain access to other flaws. Now, okay. Now, using many parts of the application are off-limits to common users. For instance, administrative areas. However, these administrative areas can suffer from the exact same type of flaws. We're talking excess, cross-sql injection, and even worse, remote code execution flaws. But these flaws are exploitable using CSRF. In fact, there might be more of these flaws available in the open world due to some common misconceptions. For instance, thoughts of a developer. Why spend time validating input of someone I trust? He's the administrator. Why would he try and hack me? A password is acquired. That's enough to keep out an attacker. Thoughts of a hacker. Why should I look for a flaw I can't exploit? I mean, traditionally, when I went on a bug hunt, I would completely avoid the administrative area. There's no point in looking for a flaw there because I can't reach it. Thoughts of users. Bah, bah, bah, bah, bah. Users don't matter, so... Okay. Now, how would we go about finding one of these flaws? And what we're using is a web application scanner called Wapiti, otherwise known as an attack spider. Wapiti is an open-source scanner. However, there's a talk after this in Track 4 for a Grendel scan. I highly recommend everyone check out this scanner. It is very good. Unfortunately, when I was doing this research, Wapiti is what I used. Okay. We'll go through some of the steps for setting up this scan. The type of software that we're attacking is TBDev. This is a software that's used in private BitTorrent communities, such as Oink, Rest in Peace, or Demonoid. These communities are secretive because they're breaking the law, which means they get hacked, they can't go to the FBI. The FBI's looking for them. Okay. I do all of my auditing within a virtual machine. This way, I don't expose my workstation to attack. I can damage the machine, and I can easily restore with a copy. I have multiple VMs at the same time. I also can finally tune configuration specifically for a test. We'll talk more about that. Now, the first steps is to install TBDev. It installs fairly normally if you've ever installed a PHP MySQL application. You shouldn't have any trouble with TBDev. We need to create an administrative account as standard. In terms of the PHP... Go back. In terms of the PHP settings, make sure that display errors is on. This is very important in all web application scanning. Many vulnerabilities are detected by the application reporting than the error has occurred. For instance, a MySQL error. This is crucial for the detection of some flaws. However, it doesn't matter for XSS. XSS is not looking for errors to take place. Also, for this case, I'm leaving my magic quotes GPC on, although I recommend also scanning your applications with magic quotes GPC off. You'd have to know a bit more about how this works, but it's a security feature that can prevent many types of SQL injection. It's a good thing. This is being removed in PHP 6, and this is a very good thing. The reason why is because programmers will become overly reliant on the security of magic quotes, and magic quotes is not bulletproof, so more flaws are becoming popular. We're just scanning with both at this time. Yeah, scan it once with it on, and then once again with it off. Anyway, yes. WPT. WPT is a great tool. It is a command line-only application. It can be difficult to use. It's fairly solid. One advantage it has over a Grendel scan is that it contains less bugs. However, Grendel blows it out of the water in terms of features. Okay, the first part of WPT is that because we're scanning an authenticated area, we need the session ID of the administrator. This is a command line application here called gitcookie.py, and we're accessing... I'm giving it the location to the login form, in this case, slashlogin.php. It's going to grab the HTML and tell me what's on the form. It's going to say there's a username and a password, and I gave it the username, admin, and the password, password. This is... If you might notice something, the cookie's name is called pass, and it looks like an MD5 hash. In my mind, this is a red flag, but we'll get more to that later. This is the first indication that there may be a problem with the session handler. Now, if we use gitcookie.py again, we'll actually get the exact same session value again. This 32 character of hex. Called pass. Again, this is not good. This is a lot of evidence supporting that they're using an immortal session identifier, which we'll talk about more in a bit. It turns out that it's true. They're using the... Your session ID is the MD5 hash of your password. Okay, now, first of all, why are people still using MD5? It has been broken for four years, and yet people are still introducing it to another code. This is a violation of OWASP's Secure Cryptographic Storage, I believe it's number eight, but people are still doing it. Perhaps you don't know better. The SHA-2 family is secure, so SHA-256, SHA-384, and SHA-512. Any of those. Very secure functions, and you won't have to worry about attack. Furthermore, we actually only have to attack the MD5 hash. It is a password. It is an effect that their username and password is in clear text. We don't have to break the MD5 hash. It, in itself, is the session ID. So if we're able to steal this identifier, we'll be able to log on to the application indefinitely, or at least until they change their password. Okay, this is a broken session handler. Again, an OWASP violation. Okay. Now, this we're going to save for later. We know we've already detected one vulnerability, and we haven't even started the scan. So now we're going to start the scan, and we're doing it with... Oh. Now, there's some considerations with this type of scanning. You have to worry about certain requests that may break the scan, or make the application no longer available. In many cases, you would want to avoid, such as a logout function, logout.php, which would destroy the session. In this case, logout.php is purely cosmetic. The session ID stays the same regardless. However, we have to avoid changing the password. So this dash x at the very bottom is excluding the my.php, which allows you to change your password. Anyway, it scans fairly quickly, and here are the results. We find a reflective XSS hole in reader.php. This is accessible by everyone. So now this is actually very good news. Using this hole alone, we could potentially steal a user account of someone on the system. We could steal their session ID, and we could use that, again, indefinitely. We could hijack a user's account on this BitTorrent community indefinitely. However, it gets worse. There are more flaws that are found. The next flaw. Now, this is far more interesting. This is a stored XSS, otherwise known as persistent, and it is in the best place possible. It is an index.php. What this means is that you're able to change the very landing page. The very landing page of the application can be whatever you want it to be, including the ability to steal other people's session IDs or to face the page altogether. I'll show you an example. Now, there's a trick with this. This flaw is only accessible in the administrative area. You're thinking, well, damn, I mean, I'm not able to hit this flaw unless I'm able to use an administrative account. Well, that's where CSRF comes in. Another word for CSRF is session writing. When we look at the output of this scan, we know that it is already vulnerable. It is also vulnerable to CSRF. The reason why is because you can see it says news.php and they're sending a git action. Git action here. That is one parameter. And then it's sending a post of body and that's it. In CSRF, you're looking for another value to accompany it, called a cryptographic no-once. In essence, this is a randomly generated number that the attacker is unable to guess. So not only is this a stored XSS hole, but it's also across CSRF. Now, if they were sanitizing for cross-site scripting, it would still be a CSRF flaw. And that would be, it would take the manifestation of the ability to post a news article to the front page. The news would say like, oh, I don't know. Administrators eat babies. I mean, you could put whatever you want. In this case, it is more powerful due to the stored XSS. Yeah, stored XSS, an index.php. Anyway. Analyzing the results. Now, there's a way to verify that it is, in fact, CSRF. In this case, I built a very simple form, HTML form, that is recreating the request. It's sending the body value of owned. And I'm using JavaScript at the bottom to automatically submit the news article. This is the first step I had in exploit development, just to have some very simple proof of concept. If you're still unsure about XSS security, if you're a bit of a novice, I suggest the OWASP has some great information on it, including testing for OWASP as well as a CSRF tester project. I'm not sure about that, but all the power to them. I think it's interesting. It's interesting. Okay. Now. This is where we start. We start building chains. Good for the head. All right. Now, in order to... The request is bouncing between the system. It is bouncing between your web browser, and it is bouncing off of a reflective XSS flaw. I mean, a reflective surface, reflective like a mirror even. Well, it's also able to... You can bounce a request off of it. However, there's a problem. When your request is sending from your web browser to the server, it's going to be hit by an ad slash, or magic quotes. In essence, what this means is you can have problems having JavaScript with quote marks. Luckily, JavaScript has a tool called string from Charcode. But they don't have the inverse. So I had to write a function to encode all of my JavaScript before sending it through. And I'll show you the exploit code shortly. Okay. Now, this may seem a bit redundant. However, there's a method to my madness. We're using a mix of reflective XSS and social engineering in order to pull off this flaw. We have to get the administrator to click on a link in order for us to hit it. So the best way... At least that's the way I thought of doing this is making the link appear as though it is coming from his own website. All right? That's where the reflective XSS comes into play. We're sending... We send the administrator a private message on the system saying, hey, I think there might be a problem with your TV dev installation. This link just doesn't look quite right. You click on the link, and then the exploit code fires. This exploit code is entirely self-contained URL. It is a fire and forget. It does not require an external server and is rather small. In fact, I'll show you the code right now. All right. I made this easy to use. I tried to. I mean, this is entirely an HTML and JavaScript. You don't need a web server to run it. You just have to run on your local system. I figured even if you've never used exploit code before, you might be able to use this. I give some explanation of how it is used, but all it requires is the target, the location of the TV dev install that you're looking for, the script that you would want to execute on index.php. In this case, we're changing the inner HTML to an image. You'll see shortly. And then click Generate Attack. A URL is generated for us down here. This is what TV dev looks like. Simple. You could browse for... browse for torrents, search torrents, as well as a community. Now, to simulate as if the administrator were to click on that link, I'm just going to paste it. If you look at the link, it actually... it does look suspicious. You can see there are a lot of numbers and it's commented or quoted out. It looks similar to shellcode. However, this is to evade the add-slashes filtering. Now, enter. Redirecting you. It's a face. Simple. It is still the face. This is index.php. The page has been changed. The only way to reverse it is you'd have to log into the SQL database and actually delete the news article. Which I'll do now. Okay. Let's talk a bit more about how would you want to gain access to the community in the first place? Many of these communities do require invites and it would be nice to gain access to these. So, I'll show you a simple cookie stealing code. The PHP is very simple. In fact, it's only two function calls and a single variable. The first line here is saying get the file contents of a file we call cookie.txt. So, whatever is in that file, we're going to pull it out. Then, we're going to open that file for writing and we're going to take whatever parameter we receive as cookie and we're going to write it. So, in essence, this is going to give you a... If you were to put this script on the index.php, everyone who is logged in, their cookie value would be entered into this file separated by new lines and you could immediately log in as any one of those people. So, this is a very serious combination of having a broken session handler and being able to literally steal everyone's authentication on the system using this combination. Okay. We'll talk a bit more about defense. Yeah, one moment. All right. Okay. Limiting the access of the administrator account is a good idea. I mean, you shouldn't have cross-site scripting flaws in this area or other vulnerabilities. I mean, it's common in the Linux world to use CHruth to limit the ability of super users. And it is also absolutely important to apply CSRF protection to administrative areas. CSRF is a popular attack against Google because since you don't have access to the source code, it is able to identify this flaw and write exploit code by merely looking at the requests and looking at the traffic. Many CSRF protection mechanisms can be bypassed using XSS. Using XSS, you're able to read the page itself, which breaks the save origin policy. Using XML HTTP requests, you're able to read the CRS-RF cryptographic no-ones in order to bypass it. This is the same technique that the SAMI worm used. And I wrote similar exploit code actually utilizing some of its functions. What it did was, what it does is... It affects an open source... Okay. It affects... There's an open source clone of the site, dig.com. It's called Plig. Plig is the open source copy. And if you're familiar with dig, people post a link, and you vote up if you like it or vote down if you don't like it. What my exploit code does is, upon viewing the link, it forces you to vote on. It forces you to vote up on a Plig link. Now, this same attack could work against dig if you had a cross-site scripting flaw against dig. In fact, my exploit code could be modified to attack dig. This has implications for mostly spammers to wish to redirect people to their spam site. Not very good. Let's continue. This attack was recently... I recently put it on my blog, rooksecurity.com, as well as other attacks that I posted on there. There's another flaw I found in Plig. It turns out their CAPTCHA implementation was broken, and I was able to find the CAPTCHA code. I wasn't attacking the image. I was attacking more of an issue of how the code was generated. I was able to predict what the code was able to be, which is another bad combination, the ability to create accounts and then also vote on links. Now, even with... Oh, yeah, that's a lot of it. No. Okay, say you have problems with cross-site scripting and you have problems with CSRF, and you need a solution now. You need a more difficult solution, or a solution that is difficult to bypass. The OWASP suggests even protecting it with a CAPTCHA. This value cannot be read by means of XSS, and it would be a reasonable defense. Another method would be to use a side channel, such as emailing you a password via SMS text message or even email, and out of bad and signal. Okay, now there's another problem with CSRF that really keeps it from being a series of very widespread. One, when you're building a request, you have to know where that request is going. You have to know the path, and you have to know the server. However, Spy Dynamics released a very cool tool, a JavaScript port scanner. Now, the port scanner uses two different methods for detecting services. One of them is onload and onerror, and it's looking at the response times from requests. This method, I can't get to work reliably for a real-world exploit. However, there's another method used. What you're able to do is you're able to read a remote image on a system. If you know the path to the image, you can read the file dimensions. Using this method, you are able to identify embedded network hardware. In fact, this is a SNOM phone, VoIP phone. It's a supply. It's running an embedded Linux 2.4 system. Using this method, I'm able to detect this phone on the network and then hack it. Unfortunately, the exploit code is I can't show you it right now. It's a pretty cool system. What's actually made worse about this is that you're able to attack an internal network over someone's browser. This particular CSRF law, literally every request on the system is vulnerable to CSRF, including the feature to update the firmware. Because SNOM is obeying the GNU public license, and all of their source code is available for the device, you're able to build your own custom firmware, including a root-kitted firmware, and have your own root-kitted Linux system on an internal corporate network. In all honesty, I'm not very familiar with the building of hacked embedded systems, but if you are, please come talk to me. I'd like to build some back-to-road firmware. I think it would be fun, particularly. Also, SNOM wasn't the only one. In fact, I bought two other VoIP phones, and they were also vulnerable. The D-Link phone, as well as a Zoom phone. Another attack scenario that worked against all three phones was the ability to change what SIP server was using. You could force the phone into using a malicious SIP server, perhaps even intercepting calls. There's also proxy servers supported on many of them. The ability to listen in on telephone conversations. Okay. In all honesty, I'm done with CSRF. I think it's interesting. I think that a lot of people have passed it off as being lame, and it's a lot of bad flak. I mean, GNU Citizen was nominated for a Pony Award, even though I thought their attack against the BT hub was cool. But in all reality, that's not the problems that we face on the internet today. The problems are botnets, large controlled systems of computers that are even waging wars. Wars of spam. And that is actually my ode. My ode, this is DEF CON, and it is a unique place where you have people on both sides of the war. You have the blackest of the black hat sitting next to systems administrators and software quality control. You're literally sitting next to your enemy in a brutal war. And I'm very proud to drop this. This is a very good exploit. As an example, it affects none other than the copper mine photo gallery, which if you don't know, there should be around... I don't have the Google hack on hand, but it's around 5 million sites are running this. And the exploit is the ability to copy any remote file to the system and execute it. You could copy PHP files. This is prime from worms. Okay, I'm not done. I'm not done. Okay, even worse. Over the past few years, I've been collecting worm code. I'm very happy with my worm code collection. And if you go to RookSecurity.com Goodybag.zip Okay, in Goodybag.zip, there are source code for over 50 viruses and worms with visual studio build files. We have malware such as M-Pack, two versions of M-Pack. MyDOOM that builds and spreads. You name it. This is everything you need to build your botnet of your own. We're talking great outbreaks such as Blaster, MyTob. They're there. Custom modules for your GoBot and FatBot. They're also on this file. Goodybag.zip. Honestly, I hope someone downloads it. Also, this is a particularly devastating combination. It is www.rooksecurity.com slash g-o-o-d-i-e-b-a-g dot com. Please share it with your friends. That's it. That's it. Please share it with your friends. This is years of copulation. Now... Okay. Actually, I have a... I'm going to do a bit of a return to CSRF because this actually relates to this flaw. Turns out this flaw is also exploitable by CSRF, although it doesn't have to be. It is simply sending... By sending a single git and post request, you're able to... You're able to incur the flaw, or the vulnerability. Okay. It's actually rather advanced. I'm using something called Global Variable Manipulation, which is advanced PHP hacking. They are containing... I don't know... What? The URL again? It is www.rooksecurity.com slash... Make sure I get it right. Goodybag.zip. I'll be posting it to my main page, www.rooksecurity.com, if you visit it. I'll be posting it after this talk. Again, I encourage you to visit my blog. I do post O-days regularly. Very... I understand. This is not good disclosure. Not wise disclosure. Ethical? Ethics? Okay. The ability... The ability for this flaw to work is actually a bit complex, and it's certainly more complex than CSRF. What I'm able to do, or what the code you are looking at here does, is it's attempting to clean up the global namespace of a PHP application. However, it contains a fundamental flaw. This array that is selected right here contains what variables that it does not want to unset or destroy. However, by unsetting this array, I'm then able to actually do something that sounds a bit counterintuitive. I'm unsetting the other request methods. I'm unsetting, in fact, any variable sent as good as a git or a cookie is being unset. I'm also unsetting the request supraglobal. The reason why is because when they're unset, it's not checking them if a global variable has been sent via that supraglobal. I know I missed a lot of you, but what this allows me to do is basically it turns the entire variable namespace into a taint. It's really trying to do it and it's trying to take an amount of control over the application and really make it vomit up on itself. In this case, the next step is literally to go through and look for sinks. In this case, the sink I'm hacking is a call to copy. Now copy is much better than other sinks that you've heard of, The reason why is because it has to do with copy by down a default PHP. You can pass it a parameter of a URL and it will download that URL to your local system. Whereas include, can include remote code, however by default it does not allow this. In order for this vulnerability to work, you do have to have registered globals enabled. However, and this is not default in the latest version of PHP. In short, if any of you are curious about this exploit code, I encourage you to come to the question and answers afterwards. The code will be posted to my blog shortly if you wish to see it at that time. Or at a later date. One of the major points of this, the ability to use the resources around you without, that aren't necessarily a clear vulnerability. Such as the spy dynamics law has been known about for years, that it's been unpatched. And it allows you to identify, allows you to identify local embedded systems. There are other issues though. The ability to send, get and post requests anywhere on the internet allows you to use web browsers as a means of, as a proxy server even, to break into other systems. In fact, because this particular flaw can be exploited by a crass browser, or cross site request. You can, in garrison, any web browser visiting your site, even if it's a fully patched web browser, it can still be made of use. You can force them into hacking other servers that's multiplying your bandwidth. In fact, in the URL that you choose to download, there could be anything online. For instance, a good example is SourceForge.net has a CVE common versioning system, CBS. And in this CBS, you can host raw text files. So in essence, you could take, for instance, M-Pack or Backdoor and host it as a SourceForge project and then being able to use that to get to exploit other systems. You're using SourceForge's bandwidth to transfer your backdoor and you're using common clients to visit your site to attack them. All your server is doing, the server that you actually own, all it is doing is having a list of other sites to attack. So you're giving it a list, hey, start attacking this site and it will continue about its normal business. It's key that the site that you own, that you have remote code execution on, you don't want this to be detected. You want this under your control as long as possible. And so it would not be wise to use this system in a denial of service attack or others. Anyway, I suppose that concludes my talk. I hope you enjoyed it. I hope you downloaded my ROM code and used my exploit code. It makes me happy.