 My name is Icyk and this is my colleague Tomer and we're going to present to you here tonight about software update exploitation. This lecture will cover the what, the who, the why of this attack. And we will also give you some hands-on and demo about this sweet attack. Okay, so updates, I guess everybody heard about software updates. It ain't nothing new, your application, my application, everybody does updates these days. Over the time, different updates techniques you can see here below some of the favorites update methods. Nowadays, most of the people, most of the companies, vendors simply put their updates on the website and the application downloads the update and simply updates themselves. The reason we picked an update is because the scenario which an update takes place is very ideal and comfortable for exploitation. In addition, when exploiting an update technique, the result is in many of the times is that multiple application becomes vulnerable at once. Okay, the first requirement to exploit a software update technique is to be able to pull a man in the middle attack on the victim. Now you can see there's a variety of ways to pull this technique. The only relapsed calls that we will see, and later on we will see how we're going to dismiss this obstacle, is the usage of static or predefined URLs, which makes the application very strict. But as I said, it's no match. The second requirement to exploit a software update technique is to don't know the dialect between the update agent and the update server. Now this is a very specific information and it's been conducted and gathered per application. What you see over here is a very generic dialect that we've picked up from a server. The first one, as you can see, is composed from two interactions. The application goes online, checking with the site whatever it's currently being up to date. If it's not been up to date, it expects the server to supply a roadmap of versions and URLs to download them from. Now, as you can see, there are two failing points in this dialect. First, we can always reply with a negative answer. That means even if the client is really updated, you will think it's not. Second of all, when the update will proceed to download the update, we can then manipulate the URL and set it to be our own. The second dialect is much more simpler. The application is not the vendor site, pre-programmed, which simply goes straightforward and download executable. Well, in this case, what we will show later on is it is possible to redirect or reroute the request from reaching the vendor site and actually make it go to our own website. Okay, so let's start the attack. What you can see here is the Layer 4 and the Layer 3 of the attack. On the Layer 3 basis, we're not doing anything interesting, simply inverting the IP addresses. On the Layer 4, we do have something very interesting. As you can see, as usual, we compete the sequence, the check sums, the basics. But we're also going to pull what we call a one-shot, one-kill trick. The one-shot, one-kill trick is implemented in TCP. And the idea is that most of the update's dialects takes place within a single packet frame, which means for us, it only takes to transmit one packet to the victim, and we will push aside the real server. Now, as you can see, we are going to activate the push, act, and fin bits. The push and act is used to transfer the information to the application. But the fin is to state that the application has finished talking, no more information to be sent. What it will happen is when the real server will wake up and give the reply, I recall that it's in the middle and we're actually going to perform it on the Wi-Fi environment, we cannot actually mute the server for real. It will come back with an answer. But since we've signaled the fin bit, the retrassmission or the server actual reply will be disqualified as TCP out of state. So this is our idea for a one-shot, one-kill. On a much higher scale, what we saw is most of the application are actually using HTTP to conduct their business. This makes an update just a regular HTTP transaction. Here you can see a list of a very popular and common interactive in HTTP. For instance, the client accessing a document, perhaps an XML or an R&I, the result is this a client expects some kind of a roadmap with versions with URLs to download from. We can counter this or poison this by supplying our own document, which will of course be malicious with a malicious URL included. We can see that when the client proceeding to downloading the file directly, regardless for anything, we can do a nice trick and is to basically counter it with an HTTP 302 response. Now, HTTP protocol supports with direction on the fly. It supports load balancing and transparent operations. So when the application actually accessing a file trying to download it, we'll actually redirect the request saying that the file exists merely just on another different server. A demo of this attack will be presented later and you will see for yourself. Either way, the server will be muted, as explained in the layer 4 technique. We have nothing that we can add on this layer to basically overrun the server reply, of course. Okay, so our idea of attacks basically to spoof the update server reply. We're going to do it by pulling a men in the middle attack on the victim and in the right moment, we're going to inject a single packet, if possible, that will contain A, a document that says a newer version available. This is the URL for it. Or B, we will try to redirect or relocate download from taking place on the renderer side to take place on our malicious repository. So let's start seeing some real-life case studies. And we will begin with Notepad++, a very straightforward application, and a very straightforward update technique. The application begins by performing a very simple get query. You can see that the application actual version is being passed as a URI parameter for that 9.2. The application expects an XML from the server stating whatever there's a higher version to update, and if there is, which URL it should be take to download it. So when we know about this and we know how the XML look alike, it's very easy for us to generate on the fly such an XML with the response, with the proper formatting syntax, basically stating A, there's a higher version, and we can easily compete a higher version from the current performed URI pass parameter. Second of all, knowing that we can cause an update to take place, we can also set the URL to be anywhere in the world. In that case, we will of course take it home to our malicious server. So what's the result? The result is a very naive application doing a very naive approach, just trying to see what there is a new version available. It ended up downloading a malware on the updated computer, and it did so quite fast. The second application that we're going to review is Skypey. Skypey on the other hand does not use such an naive approach. It's actually accessing the same URL to download a file, skypeysetup.exe. Now the skypeysetup.exe file is basically determined in runtime, whatever an update is required or not. So we cannot stop skypey from making the download, and we cannot actually make skypey make the download from a different location. We have to actively work against download. So in this very specific case, and in the case where the application goes straight forward, heading the wall, don't care, don't ask to a website, what we're going to do is we're going to counter this action with HTTP 302 response code. The HTTP 302 response code allows us to basically define a new location where the resource is being located. So when skypey approach download.skypey.com, asking whatever skypeysetup.exe is available, we're going to respond with, hell yeah, it's available. Only it's just moved a little bit to the evil repository side. And skypey will just go there happily ever after, download the file and execute it. The question that people ask me many times is whatever fixed parameters or all sort of pre-shared knowledge about the server can be effective. So as you guys saw, there are any fixed parameters, any fixed host names or whatever you like to call it, it's really not match. And in the example of skypey, we have proven that even the application knows the location and knows what it's after, thanks to the HTTP protocol flexibility, it's made it easy for us to basically redirect it again and downloading a malware instead. Okay, the last example that we're going to review is a much complex one. The malware bytes application is an open source anti-malware application. And its update procedure is a little bit complex, but not that much. First, it begins by querying the server, whatever there's a higher version available. Notice here that the application never reports about its current version. No worry about it. We can always fake a much higher version or the highest possible version. If the server do contain a much higher version, it will simply go and download, again, a fixed file name from a fixed site. So that's how we're going to do it. In this specific update procedure, we can choose to do either one of the two. We can either try and always spin the download itself, which means we will make it reliable with the user. He will always try to download a real version, except he will receive a malware instead. And we can also choose another technique, which will be to fight on both fronts. In this example, we choose to fight on both fronts. For the first get, we're going to answer with a fake higher version. As you can see, the highest possible number of the application accept. So the application will proceed further to download the actual update. Okay, again, a fixed name, fixed location. No worry about it. We're going to spin it off with HTTP response 302. The result is, even if an application performs a much complexer dialect and has more than one query, it is still possible to hijack it. Successfully and exploited to run malware. We have collected a little bit over 100 different applications. We went to download.com, other major website, taking everything from image viewers, CD players, shitty applications, really. We just went to everything that we can, and we collected a pretty much pretty big database. You can see some examples below here for different type of application, which are vulnerable. I think it's a very good time to proceed to some real-life action. Tomer? Hey, everybody. So before the demo, we just want to take a minute and explain you what components builds our attack. So what we have here are two computers. One is the attacker computer. Our attack tool, E-Pon, is running on it. And the second one is the victim computer. This is the computer that will try to do the update. In addition, we also have here an access point. It's an open public Wi-Fi called MedWi-Fi. Also, the attacker and the victim computer are connected through it. Because we had to do some changes in the setup, we will demonstrate the demo on the VMware, because we do have two screens, but it's one feed, so we will not be able to see also the attacker and the victim. So let's begin. First, we need to run E-Pon. Okay, so what we see here is E-Pon. E-Pon has two modes, a CLI mode and a 3D mode. We are watching the 3D mode. We are watching, sorry, we are watching the 3D mode. The 3D mode is like a Wi-Fi radar. What we can see here is that we are the yellow vertex, the main vertex, and surrounding us all other blue vertexes. Right now, it's only MedWi-Fi, our all-available access point that E-Pon was able to detect. The GUI also supports zooming in, zooming out, and rotating. Okay, so let's start. Let's start the demo. We have chosen AutoEat for the demo. AutoEat is a scripting language for Windows automation tasks. It has a check for an update feature, so let's try updating it and see what happens. First, checking for an update. The reason available update. Downloading. Boom, game over. Okay, let's take a look at E-Pon and see what happened. As we can see, the MedWi-Fi vertex after an attack, thanks. After an attack, the MedWi-Fi vertex has changed from blue to red, indicating us a successful attack took place in MedWi-Fi access point, and also a green vertex was added with the attacked computer IP, and the trigger domain name. Okay, let's close E-Pon. Okay, after attacking AutoEat, let's build a new attack from scratch on a new target. Target is a Dreamsoft PDF-to-word converter application. The version is 2101, which is the latest version. Before that, I just have to show you some of the database. E-Pon has, in order to build some new attacks, we must use E-Pon database. E-Pon has a database. So, E-Pon has a database. It's actually an XML document that contains triggers and responses. Here we can see the 200k attack and the 302 redirection attack as we talked before. Here we can see the target name. We need to fill the target name. We need to fill the domain name, the path, the attack type, which is 200k, and the method is get. Because we are using 200k attack, we will also have to add the response. In 302 redirection attack, we do need to fill the domain name, the path, the attack type, which is 302, and the method is get. In 302 redirection attack, we do not need to supply a binary location. E-Pon gets it as a CLI parameter. Here we can see the script for running E-Pon. We have the minus W for the wireless, the minus I for the interface. The target's XML is the database. The minus U, sorry, is for the malicious location binary, which in this case, this is the Apache server running on my computer. Okay. So, let's run Wireshark. This is the new target. Let's analyze how it's doing the update. First, we need to run the application. Check in for an update. Okay. We can see that the application shows us that there is no unavailable. There is no unavailable update. We are using the latest version, not surprising. Let's take a look at Wireshark to get a better understanding. Let's filter it with HTTP request filter. Here we can see the entire session between the application and the update server. We can see that the application went to cbsadreamsoft.com to go PHP. We can see that it sent it version 2101, which is, as I said, the latest version, as a URI parameter. The server responded with 200 OK, and contains an XML document. Okay. We can see here some tags, a code tag, XURL tag, and some more information. So, let's build a new server response and try update it once again and see what happens. We will have to use, again, the templates. So, we will take the 200 OK template. Let's put, first, let's put a name. We will have to take the host. We will have to take the path to the binary, which is go PHP. The attack type is 200 OK. And because it's 200 OK, again, we will have to use the response. Just copy the server original response and put it here. Because the server responded with a document, which is an XML format, we will have to use the C letter. Let's change the code tag from one, code tag value, sorry, from one to two. And let's put in here, let's say, ipon says hi.com. Okay. Let's copy it to ipon database. Okay. So, what we have here? We have a target name, which is Defcon. The domain name is cbshvmsoft.com. Go PHP. The attack type is 200 OK. The method is get. And this is the server response. Okay. The code tag is two. And malicious location. Let's save it. Let's run ipon again. Okay. Let's close the application. Checking for an update. Okay. We can see that now the application thinks that it needs to do the update. There is an available update. And you need to download from ipon says hi.com. Do you want to do the update? I don't. So, let's close the application. We can see a new vertex was added. Let's close ipon once again. And instead of ipon says hi.com, let's change it to another location, which is the Apache server running on my computer. So, we will have to take this. Okay. In this case, this is the same target. Let's copy it to ipon database. Okay. So, the target name is ADM soft PDF world converter. The domain name, as I said, 200 OK. The method is get. Again, we change the code from one to two for newer version. And here there is a function, get malicious URL, that tells ipon to take the malicious binary from my Apache server. Let's save it. Let's run ipon once again. Let's run the application. Check in for an update. There is an available update. Form here. Downloading. Boom. Game over. Okay. If we will go to the CLI mode, again, as you can see, the new vertex, the green one was added with the attacked computer IP. If we will go to the CLI mode, here we can see the two packets that were sent as we talked about. The one shot, one kill concept. We can see here the 200 OK. Here you can see the L3 layer. We can see here the L4 layer. We have the fin, the push, and the act. This is the 200 OK response that we have supplied PDF to world converter application. And that's it. Let's go back to Isaac. Okay. So, what we saw here was a demo and we also saw a little bit of hands-on. As you can see, it's quite simple to take this application, this everyday application and examine how they're working. As you can see, a target can have multiple responses. Depends on how complex the dialect can be. Multiple 200 OK. Multiple 302 if required. One of the things that the one shot, one kill concept does by supplying the fin flag to the L4 is the ability to break down pipelines. Actually, most of the clients after receiving a packet with a fin will disconnect from the server and take the new request on a new socket and a new connection. This actually breaks down the entire session into server response type of thing which makes it quite easier for us to handle. So again, if there's a complex dialect it's nothing to worry about. That's a number, just a couple of words about Ipon itself. It's basically a Python script using Scipium, sorry, as a fundamental library for injecting. As Tomer said before, there is minus W for the Wi-Fi but it's also applicable to be performed on a LAN environment thanks to the R poisoning. So again, it's quite flexible application. The database itself in one upon second I'll just open up real quick. Yeah, sure. The database itself is a little template engine, template engine, sorry. As Tomer says, you can actually code and insert a new type of things in it. As you can see, the Python actually respects the macro between the percentage. It's actually invoking a real Python language. It's not a very complex template language, but it's enough for you to pass parameters and you can generate response on the fly from it. Wait, let's just... Tomer, can you show us the notepad++ one example? Yeah, so the Cdata is, of course, to escape the XML within the XML. But as you can see here, we actually compete, we actually accessing the hash table, which can actually perform as, let's say, the fundamental principle. The HTTP request just simply breaks down every parameter in the request. So you can see that the increased version is basically taking the actual value of the version, as to remind you that hold up a minute where the presentation went. The notepad++ actually has been kind enough for you to want to be actually precise and not just to throw some random figures. It's as possible, as you can see the 4.902, so except we're basically increasing it by one, making sure it always will trigger an update. And as you can see, the location in the XML is also a function in the E-Pon code. It's quite flexible. We try to tweak it as generic as possible so you can extend it to support new functions, new generation of content and even new protocols if you will encounter. Okay, so let's continue with the presentation and talk about the most obvious obstacle that most people think when they hear about HTTP is what about SSL? Well, yeah, SSL can update you better, because it's a couple of drawbacks when using SSL. First of all, it's quite expensive for a resource. You cannot use SSL to transfer geeks of geeks of downloads. Again, since most of the vendors presume, if you can try to remember, most of the update application don't actually give you the entire look. You don't see the golden lock. So the vendors allow themselves to fool around with SSL for the real security. Here you can see some interesting example that we came across of vendors using SSL to update, but only to say so. You can see some cheap solutions like update with self-signed certificate. Yeah, that's gonna help. We even saw one application which was quite interesting. It accepted third-party certificate and didn't actually give them the whole name. Just wanted to have some certificate. Again, very interesting solution. The result is basically, even though it's conducted through SSL and everything supposed to be kosher, it's not. We don't support it in IPON as it is, but it won't be so hard to implement to counter this cheap SSL solution. Another attack that me and I came up with, this is a bit on theoretical side here, is that we actually saw that there is no minimum for the cipher-suit strength in SSL. I mean, browsers do support some sort of a minimum set for SSL, but this application actually will agree for anything and they will also agree for a null cipher. Now, it is possible to raise condition the SSL handshake, basically give the server the idea that the client has only a null cipher and make the server believe the server offers to the client a null cipher, the result will be a legitimate SSL connection negotiated on null cipher, so it's actually doesn't do anything productive. So, is it the end of the world? Apparently not. There are some quite instance and applicable solution that software vendors can implement and some of them de-depliment. Actually, some of the major players such as Microsoft and Google did implement digital signatures in their updates. A very, very simple concept. They basically give away the public key in their application and when the application downloads a new binary, a new update, it simply verified itself to make sure it's signed properly. So, even if we can temper with the downloads, we cannot still push away a binary that's signed by a vendor. So, it's a very easy and very fast solution. Of course, there are other solutions that can be made SSL the right way which means there's a valid verification there's a valid certificate that's actually designed to be for that host name and now the SSL itself does not need to provide the entire binary application because SSL can be only used to transfer the MD5 or the SHA-1 of the actual download. The download can be take place on a clear HTTP. This way, even if we will hijack the session and we'll push away a different binary, the MD5 has already passed in a secure separate channel so the application can confirm the MD5 does not match the actual download. So, it's a resource in a safe way but it's also applicable. Okay, so what's the future for IPON? What's the future for update attack? Well, we actually think the future is quite pink for these guys. First, some ideas for the next version. Playing with proprietary update data, although we can always push an executable or a binary or a rootkit and make things interesting from there, we don't need to do that. But on this level, we can simply tamper with application specific information. Now, imagine an application such as a friendly firewall downloading a black list of IPs. If the black IPs file is not secured, I can tamper with it. I can actually give away IPs of an actual real site such as Google and make home firewalls block Google. I can actually give away IPs of an actual firewall is antivirus walls. People tend to trust antivirus box and they tend to believe that what they say is the truth. So we can actually make an antivirus attack application. We will just insert a bad signature and the antivirus will just tell you that this application is no longer legitimate. We can make the antivirus actually take over its own protection and end up having broken DLLs. And we can also make the most funniest things in the world basically make the antivirus protect the virus from others to be deleted. The hit and run mode is also very interesting. We've noticed that some of the application stores some sort of a history of successful updates. You can see there's a list of IPs and URLs. So I don't even actually want to walk you or stalk you all the way. It's good enough that we meet in the airport and I attack you. You just happen to check in for an update, your application and bang, it's recorded my malicious website as a potential download site. You must be familiar with the option of download now install later. This is exactly the case. You perform the download in an Instacure network and you're installed it later in the house but you're actually installing a malware. So it's the hit and run mode. But I think the most interesting thing that we came up with Hippon is that whatever Hippon does to you, to your application, to your laptop you can do it to your friends and etc. Because we're not actually lying on any exploit, we're not lying on anything specific. You only have to do is have a password in the airport. Each one goes to his own direction. I'm going to attack some of you. Some of you will be getting infected. When you're coming back to your friend, to your office, to your state the malware will do the same thing to your environment. It can actually manifest as an airborne virus. It doesn't need any network. It doesn't require any storage. It's simply propagate through searching updates in your area or your device or whatever the update is something Hippon knows how to attack. It will attack and spread forward. So how about that? Thank you. The Hippon project has been released on DEF CON. It's the official announcement. We are going to maintain a code repository at Google Code Projects. You're welcome to download it. I don't think we're going to upload it. We will supply some bug fixes and some of the ideas maybe improve the 3D graphics a little bit. I'm going to get the questions in a minute. So whatever the version you have right now in DEF CON, it's the first version. Just check it out for the newer version. Yes, questions. Yes, yes. We have over 100 different devices. Again, from the vendor perspective it's hard to tell them it makes sense from them to make the update available on the website. So they actually rely on the infrastructure to be secure. They say, hey, your bubble will be in your office, in your home network. But in a public Wi-Fi such as an airport, McDonald's coffee shop, they didn't find about it. Most of the vendors didn't pursue further to embedded PKI. Oh, fuck you. Any more relevant questions? Have we? No, don't think so. That's wonderful. That's... Thank you very much. That's a free tip for you guys. Yes. Yeah, I think. But as I said again, you guys have the real hard copy in your CDs, so no tempering with that. But yeah, it will work for more versions. Any more questions? Thank you very much.