 Hello, everyone. Welcome to the annual phenolate speech at DEF CON. We got plenty of material to cover, so I might actually step over some stuff pretty quick. And if you've got questions, the idea is I will hang out on the first pool, and you're going to buy me beer, and I answer your questions. Okay, let's go. What we're going to do. First, if you catch Richard Thiem's talk, lots of people are concerned about what's the matrix, are we in the matrix, how to hack the matrix, so we thought we're going to look at it and tell you how to hack the matrix. Then we have some GSM stuff, you know, of the short fun excursors. We were actually covered GSM and GPRS basics. GSM is swapping over finally to the United States, so you finally got decent phones. And I thought it would be quite useful to actually give you an introduction on how the backbones work, so we will also discuss two things about the mobile phone networks, attacking mobile phones and attacking mobile phone backbones. And of course, this being a phenolate speech, we have the usual Cisco OD crap and shell codes and stuff. Hacking the matrix. There is a product from made by in terraces. They used to be cable char. It's called the matrix. So just because they gave it the wrong name, I started looking at it. This is basically a switch router, so you have a switch and you basically can say the use in that port is now going to be a router. And to sum it up, the vulnerability is a God. If you do anything for management, you better have TCP, IP working, right? So this being an embedded system, you do like ten connections or you complete ten TCP handshakes to any given service that you use for management. Let's say it's Talnet or SSH and that's about it. Nobody else is going to do that anymore. The same thing on the switch ports that are not assigned to a router. They use this very advanced technique for calculating initial sequence numbers for TCP that's known as the 64K rule. So NMAP will actually tell you it's a piece of crap and it's easy to hijack. So well, when you unpack the box, it is a switch, so as soon as someone Talnet's there, you can hijack the connection easily. And also, of course, it does OSPF. For those of you who catched a talk two years ago, you know that OSPF is quite useful and you can do lots of things with it. The bad thing is vendors tend to read RFCs incompletely, so they actually read the part that told them how to build the packets for OSPF but they didn't read the part that told them how to make OSPF work. So you just sit there and flutter with OSPF hello messages, which basically means here's the next new router, here's the next new router, here's the next new router. And instead of validating that first and then tell everyone else, it will tell everyone else in the network right away. Which translates to all you need is one of those boxes in your OSPF network and it will actually kill the whole network for you. And well, to make a long story short, last year I said if you got an embedded system and it got port 80 TCP open, you can bet your assets vulnerable, so same holds true for the matrix. Which answers the question how to hack the matrix, use HTTP. Okay, GSM basics, the global system for mobile communication, GSM, is actually used for quite a while and was standardized by the ETSI. In contrast to the mobile networks you got here, usually, there is a very specific difference between what they call the terminal equipment and everyone else calls a phone and the SIM card that is actually a smart chip handling all your information. You use the SIM card to authenticate the key material on the SIM card to authenticate and to use your caller ID and other IDs to authenticate. The phone does not matter. The GSM core networks actually rely on this information to find out who you are and actually bill you for the service they provide. So, lots of people have tried to do caller ID spoofing and other stuff with GSM. Some succeeded in very limited environments, but in general it's all fine and all good. Which actually changes. It changes with what's known as GPRS, the general packet radio service. Well, this service now is pretty much like the internet was compared to least line services. So, in the beginning of networking you had least line services and direct connections and then someone came up with the internet thingy and all the packet forwarding crap and all hell broke loose. Same here. So, this is actually packet services for mobile phones, so you can serve web faster and do all kinds of stuff with it and consequently the whole backbone infrastructure is running on IPv4. Now, authentication is a bit different here. If you want to find out which network you're talking to, you use the APN, the access point name. This is something you transmit to the GSM network and it will figure out on which side you will pop up. So, that does not have to be the internet or a VAP gateway. And then optionally, you got PPP running over that, giving you IP addresses and of course doing this chat, pat thingy, find out who you are if you got a right username and password. APNs. You should actually think of an APN as a URL. It is quite similar actually because you give it a name and it will tell you which network you're talking to in contrast to a real URL telling you which server you're talking to. So, the same thing in full color. What you got here is actually a very basic, well, yeah, very basic picture of a GSM network. You got the guy here being the mobile phone talking to the PLM and which is the public land mobile network. Everyone else just says the mobile network. You got the HLR, which is the home location register and you can actually think of it as a huge fucking database. Often it runs Oracle. If you're home, there's another thing that's called the visitor location register. And the HLR actually holds all the information about you and your credentials and what you're supposed to do and what you're not supposed to do. Then you got the SGSNs and the GGSNs. The SGSNs are the serving GPRS support node. Think of the GGSN as a backbone router and the SGSN as the one actually talking to the HLR and forwarding this stuff. So it's pretty much like a framework network. And of course you got more than one GGSN. So you got one facing the internet. You got others facing company dedicated networks. So big companies go there and say, okay, you're doing GPRS. That is quite useful. So you got, let's say you got any kind of logistics company like UPS or FedEx and they got what I call the oversized Gameboys where you're supposed to sign on. These devices have to talk back and actually make sure that, well, you signed and the package was delivered. And, well, it's quite easy for them to actually order GPRS services, request an APN and every time those devices have to talk to the network, they open the APN and say, this is where I want to talk to. And now they end up being in the UPS internal network instead of the internet. Of course nobody prevents you from doing the same. So GPRS attack points. First the GGSN as I said is just another IPv4 device at stake actually figured that out. They had an OQGPRS box hanging off the internet and they actually found a vulnerability there. Something totally simple like a special TCP option. So you can actually expect a lot of stuff going on with those especially on the networks that face not the internet but some company networks. And the scary thing here is Cisco also does GGSNs. Now APNs can actually be GGS. They're not considered a secret. It's like the URL. So most of the APNs are actually either the URL of the company's home page or the company name. So you can just go ahead and try it. I did that in Germany and it turned out that lots of major companies actually have their company name as APN and you get asked for a username and password via PPP. And of course this being a large user base you often find usernames and passwords called test and test and yeah you know how that works. So the thing here is you can actually do APN filtering in a HLR but no provider does it. For a simple design failure reason. You can only say that a user account is allowed to do all APNs you want or a limited list. Now that would be pretty bad for the database if they had to write that down into the database for 22 million customers. So they don't say that. They just say everyone can go to whatever APN he wants and yeah the GGSN were the authentication servers, radio service hanging off that during the authentication and with a large username and actually user account database you should also find weak passwords. But there is actually more to it. So if you happen to have for whatever reason, maybe for staying at DEF CON or talking to some guys, you happen to have one single computer in a mobile phone provider's network. It can be the secretary's Windows PC or whatever. You can actually do quite some interesting stuff. There is the GPRS tunneling protocol GTP. It's standardized here for everyone who loves to read boring documents. You can actually get that off the ETSI webpage. The protocol is actually designed to transport user data and control data via IPv4 and the GPRS backbones and is also used in UMTS backbones for the third generation that you didn't even hear of. The protocol can control pretty much everything in the network. This includes setting up modifying tunnels, connections, data transfer path. You can modify the VPN access for an active subscriber. You control how they roam and of course you control how the accounting works. Now both the control connections and the user data are ran over the same protocol. So we are talking about all the same thing. Now the most funny thing is actually already on like the fifth page of the standard because it says that every device SGSN and GGSN is supposed to support this protocol including version zero. So what they did was actually they standardized their inability to fix the protocol because even if they come up with a new version that isn't so screwed as the one we are now talking about, the devices are supposed to support the screwed version and this is in the standard. I would say that was not a good move. So what's it all about? What's it cool about it? This is in protocol running over IP so we are quite familiar with it, right? It runs on UDP which enables us to spoof. It has no authentication. You can create, update or delete user context to your lightning with one UDP packet. You can modify or remove billing information with one UDP packet. You can actually reroute traffic and redirect traffic over the backbone. Guess what? One UDP packet. You can actually invite people into VPNs. So you got one of those boxes and you got a friend who got a GPRS phone. You can actually invite him actively to one of the company VPNs, one UDP packet. And of course you can force people to roam. Roaming is handled by GDP between the SGSNs. So I was actually wondering why there isn't someone, maybe I do it, starting a company as a mobile phone provider and just having one SGSN and constantly sending out UDP packets and make all the users roam over you. Which I think is a good business concept but it wasn't declared as such in the standard. The fun thing is how they dealt with security is this. They say we're ETSR, we're doing GSM. So we don't care about IP. Someone else is going to make IP secure. Period. And a statement. Okay. Assumed you do not have a computer in a mobile phone network. And of course most of you are not supposed to have one. There is other stuff you can actually do with GPRS and VAP. This is anonymous HTTP. The good thing here is a lot of people especially at this conference have certain interest in doing HTTP without revealing their real IP address to the server they're talking to. Those reasons might include something like Unicode or web applications or other overflows that you might find in port 80 applications. So how do you do that? The VAP protocol is actually the vehicle to go for. You have the wireless transport protocol and the wireless session protocol. The wireless transport protocol is used to do basic transport stuff. The wireless session protocol is actually the one doing a session over the UDP stuff you talk on the air interface to your mobile network. Now this is used to actually talk to something that's called a VAP gateway. The VAP gateway is supposed to work as a proxy both in protocol terms and in HTTP terms. It will accept UDP on one side which is your phone and it will talk TCP to the other and it will grab down the web pages you asked for. Do something that they call compiling which basically means take an HTTP or in this case WML tags. Make them non-tax so compile them in one binary format so it's smaller and send it to your phone. So WSP in the default setting that your phones use is a connection over UDP so it got actually numbers to track the connection and the session which you compare for those of you who know DNS and the DNS IDs for packets for requests. This is pretty much the same idea here. Now an often overlooked fact is that actually the standard says there is a way to do connectionless WSP. Connectionless WSP means you're not setting up a connection. You just send the HTTP request to the VAP gateway. This has several advantages. First of all you can tell the VAP gateway you're not really interested in the answer which means it's not going to send one. The second thing is this being UDP of course we can easily spoof again. Which now means we're actually giving the company, the mobile phone company money by using GPRS but we're actually not using our own source IP address but someone else's. And this is quite okay. The VAP gateway does not filter that usually. I have not seen a VAP gateway or any other device in a mobile network that will actually detect spoofing but they might exist. Correct me if I'm wrong. So you actually got anonymous HTTP request capabilities and to make it nice and have a little drop of sugar on top of it, it's built to someone else. You just find out which IP addresses are used which of course you do with this ICMP sending utility called Ping and then you use their IP addresses. So not only is your HTTP based attack anonymous but someone else is going to pay for it. So this is the summary of how to do that in case you want to try that at home. The good thing is you don't actually need to have a phone. There are open VAP gateways in the internet. So you can actually look for UDP port 9200 and well then apply your responsible procedure in dealing with new waste of exploiting things. Yeah. I had a certain problem with an NDA here. So I just wanted to make sure that this is covered in the slides. Go make me drunk. Okay. From the backbone to the actual devices, this is the thing we're talking about. The Siemens S55. Now there are lots of smart people actually dealing with PDA sized phones and other, yeah, the new generation stuff that runs Symbian OS and I'm not really smart enough to compete with them. So we had a different reason looking at that one. Simple for the reason was we had it and those Semi smartphones as I call them are very widespread used. It's like the camera phones and MMS crap and Java applications and so we picked actually one to play with it. It got Bluetooth. So what's bad about the Bluetooth implementation here is every time you start a connection it will of course ask you if you want to pair with this device. This is fine. Well if you start the next connection it will ask you again. So you open about 100 connections and it will have 100 message boxes on the screen. That thing is there's not being Windows. You don't see that those are multiple message boxes lying on top of each other. So you acknowledge one or dismiss one and it still looks the same. You have no idea what's going on. And well the same problem actually holds true for the connection was that the connection resource is in the phone. So you do more connect to it. At some point in time it's so busy waiting for the user to acknowledge or dismiss this pairing that it doesn't have any connections left. So if this guy had a headset or anything else actually working with the phone this changed. It's no longer working. And all you need is something that's called an L2 ping. It's just a layer 2 kind of ping. So that's quite easy. The big inbox is something I really like to do in airport lounges. You got all the executives with their little nice phones and well everything they do is like they get the phone, they set a new background picture and turn on every possible feature. So the thing is the S55 accepts whatever files you send to it and puts it in a directory saying incoming data. Now it is quite easy and not really time consuming to send 2100 files. Unfortunately it is quite time consuming to delete 2100 files on your phone. Because they actually got a function that's called delete all. But this function seems to use a counter for what all actually means that is bite sized. So you can actually delete 255 files at the same time. But this is not going to win the race against the one sending the files. And it is by the way quite annoying when they're on the phone because it keeps peeping. Okay so the next big thing that the vendors of the phones actually advertise is the whole Java stuff. Well if you remember last year I hate Java. But Java is actually supposed to be a secure programming language. And this is done by having exceptional circumstances in your program code manifest themselves as exceptions. One of those exceptions is an out pointer. Well an out pointer exception shouldn't kill the Java virtual machine. Actually here it does. So everything that could possibly trigger an out pointer exception, which often is just leaving out data, will result in what we call the white screen of death. Because as you see on a picture this is how it looks like. All you have to do is trigger an out pointer exception and we're going to show you how. There is the thing called the Jot files. Jot files are actually text files that are comparable to like INI files on Windows. They're lying around on web servers. So you serve web and it says download Java application or it says click here. And you actually pull down a Jot file and it figures out what the name of the Java application is, what size, where it comes from, what classes it needs and stuff. And of course the name of the Java application is quite interesting because it wants to ask you if you want to install it or not. And that's stored in the mid-let name. Well, if the mid-let name is missing, you get what you see here, the white screen of death. So you can actually build web pages with evil Z mince links, which is quite funny. But the other thing is even more funny. I didn't find a way to exploit it, but that might be just as stupid me. You have an over long mid-let name. So in case the user actually is stupid enough to acknowledge the installation of the Java application AAAAAAA, what happens is it will create a directory to put the Java application in. So it passes the Java application name as a directory name to the core operating system. Now there seems to be a limit which means that if you have a normal name that works well, if you have an over long name, it will actually overwrite the name of the file and some structures that are supposed to run the file system. So you cannot delete this. You actually have to flash the phone and remove all the data by reformatting the whole phone, which is the reason this little fucker here doesn't know any other ringtones than the default one anymore. But even with the Java stuff, well, you can crash it, but you can actually do more. Spider Jar. The idea actually is here that you can have some limited information pulled off the phone by Java applications. Most phones will actually complain if a Java application tries to make a connection outgoing and like send data. Well, the Siemens doesn't. The Siemens just says, well, it does a tiny little beep, nobody really hears, and then lets you through. Questions, which information can you get? In a standard Java classes, Java X and all the Midlet stuff, there isn't any interesting. But we got the company class trees, and of course Siemens got one, and they're growing every time. This is the information from like today. It might change with the next firmware and they got new classes. But today you also can, you already can get the list of missed calls. Now the information, what calls you missed and from which number they came, can be quite interesting if it's sent to some external server. And of course you can also get the IMEI of the phone, so you can actually identify the phone correctly. So we try that and you can have a Java application. It could be a little game or whatever it is posing as, and every time you play the game, it's actually telling some web server in south of Russia which calls you missed. I don't think that's a good idea. Time.jar is very, very funny because it shows that Java does not necessarily prevent you from doing stupid things. Sending an SMS or placing a call can be a costy thing depending on where you call or where you send the SMS to. I don't actually know if you got so-called value edit services, SMS and MMS in the States already. So where an SMS costs you about three bucks. But we got quite a lot of them in Europe and guess what they're offering. So normally it is supposed to actually ask you when a Java application will trigger the phone to call someone or send an SMS. It is supposed to ask you and say, hey, look, do you want to do that? But we got a little problem here. This confirmation is done by a dialogue. Now Java not being the fastest programming language in the world has a timing issue here. If you before you try to send the SMS actually fill the screen and do something else on it. So to make that visual, this is what it is supposed to do. For those who cannot read it, it says allow sending SMS to whatever number. And well, you're supposed to press yes or no. Due to the timing problem, you can ask different questions like, would you like to play a game? I had the idea of actually using the two buttons that are supposed to say yes or no as a control in some jump and run game. So you would actually press yes approximately 50 times, 50% of the time and send about 1,000 SMS each three bucks. The next thing we got here is something that is actually related to the whole MMS picture phone thingy. Well, of course to send pictures and do MMSs, you need to have image formats. So the image format of choice here is GIF and JPEG. Now the GIF file format, as you all know, supports multiple frames for animated GIFs. For that to be flexible, you got something in the file format that is called the virtuous screen, which describes which area on the screen is actually covered by the sum of all frames in the GIF file. Now what you can do here is send a GIF file that actually has one of the frames offsetting in this virtuous screen. This is supported by the standard. The good thing about that is, well, the virtuous screen itself is not really supported by Siemens. So you're actually writing the GIF data into some memory that is not displayed, but holds something different. So if you actually open such a GIF file or you get an MMS with it, your phone will crash. It will crash and it will just go off. It is very interesting, but you can make this permanent by placing this picture as a background image on the phone, which is pretty much the last thing you did with the phone. Okay, enough of that crap. Actually go and do some of the Cisco stuff. This was not intended to be here, but since a lot of people were talking about the latest iOS bug where you could like deny a service or device and actually some brilliant people send very extensively explained IRC shadlocks to full disclosure claiming this might be exploitable. I thought I going to comment on it. So the recently discovered bug is for those of you who don't have email that there is a way with like Metform packets to fill the input queue. Now the question was, is this exploitable? Well, my question is, when you're stuck in a traffic jam, does that mean you control the traffic light? You can describe the bug as something like you have people checking in in Alexis Park and you've got like 75 people go into the front counter and then you kind of like kill the person behind the counter which still doesn't mean you get their money. So to answer the question, no, it's not exploitable. But the good question would really be, what is the problem? The problem here is that iOS is interrupt and message driven. So the processes themselves are responsible for draining the queues which obviously those four processes didn't do. And while most processes in iOS for what I know do their own protocol parsing. Means the IP header is actually parsed at a central place but everything else is parsed each and every time in each and every process whoever is responsible for it. That means if you got a hundred types processes 99 can do IP protocol parsing quite well and one is totally fucked up and all you have to do is find the one. So that obviously leads to the point, can we expect more of that? I guess the simple and short answer is yes. The bug is actually a design failure in my eyes. iOS 12.3 is already out and it's already deferred and there are some specific protocols that are handled differently and have higher priorities and stuff. So it's just a matter of time. The effects of the bug were not as bad as we thought because Cisco actually went to the background providers and told them upfront here is something major calming so please filter that. And the bug actually was found Cisco internally so they could do that but what if the next bug is not? Well at this point in time here is the one finding the bug. He's the only one from the Cisco staff team. I'm glad he is here. He didn't get credit in the advisory so I wanted to give him credit here. Okay back to bugs that we found. Cisco iOS 11 and X, 11 X and below there is the UDP Echo Service. Now Nessus is telling you since ages that the UDP Echo Service is bad because someone can do ping pong attacks on it. On Cisco the UDP Echo Service is actually worse because they got a bug here that is on first time very small. You look at it and you send the UDP Echo Request packet and in the UDP length you actually say it's longer than you actually include the data off. So you have one single character in the packet but you say the packet was 100 bytes long. You get 100 bytes answered. Now we tried and tried to look at how much data we actually can get back and it ended up being something about 19K with one packet. So that could be quite useful because that is IO memory. IO memory is used on Cisco for handling all the crap that has something to do with the packets themselves and some limited routing information. So we actually got comparable box in 12.x like the Cisco express forwarding. That's a certain way of getting packets from A to B that Cisco uses. I think it's now the standard setting. This one had a comparable bug where the IP length was the trigger. So there is more of it. But back to the UDP Echo Service what can we do with it? Oh no here's something because people started complaining about finding bugs in 11 is useless because nobody uses 11. This is a router actually alive in the internet. He found it. It runs iOS 9. Well this one is not even available on the Cisco FTP servers anymore. So people do update their routers once in a time. Okay the UDP Echo InfoLeak bug actually is quite useful because we can do reliable iOS fingerprinting. In the past we got the problem that you got like 22,000 different iOS images sitting on Cisco and well you don't know what the router you're targeting is running. Now you can because it contains block headers which contain addresses who allocated the block. You got addresses of the allocating image, allocating function which change per image so you know which image it is and you got address ranges for IO memory and heap memory and those change by platform. So you can fingerprint it. This is what you actually get back. You see you have the allocation stuff and the pointers we talked about last year. They're all platform specific but you also got the ring buffer information and the actual packets in the device. So question is can we and yes we can. There is of course the possibility of draining the router of memory leakage and actually get 19K per packet back and parse that correctly. So we came up with phenolate iOS sniff which is remote iOS sniffing. You don't need any account, you just need UDP echo. What it does is actually pulling down the information, parsing the memory block, identify them, identify the packet offset, do the packet decoding and present you with a nice TCP dump like output. So this being the receive buffers it's quite useful because well the router receives certain information especially when people log in. So what you see here are the first two lines or three lines of stuff that actually is sent to the router when someone is telenetting to it. Well the first lines he is probably sending are the passwords. So that's quite useful. But there is another bug. Cisco has an HTTP service and as I said earlier if you've got an embedded system and it got a TCP port 80 open it is vulnerable. Well Cisco is no exception. The HTTP server on 11.x and up to 12.2 has an integer overflow. It unfortunately requires you to send two gigabytes of data. But well I actually did a survey on people and said is this bullshit or should we actually go ahead and see if we can exploit it. And most said yeah I don't care if I wait a week and I got root on the device that's fine. And since that is a stack based overflow and it might be quite interesting to do because last year we did heap overflows we did it. So exploitation issues in the past for those who missed last year we need server image dependent information like previous pointers, size value and IO memory, stack location, location of the own code which probably means you should already have a console connection to the router you're trying to hack. And this isn't really practical. So things change. What we got now is the UDP echo memory leak. We see Attica provided data which is the UDP stuff you send there in the first place. We have live iOS memory addresses. The leak memory block headers if you remember. And we have the ability to fill multiple memory locations because it's a ring buffer. So we just send it multiple times. And we got the HTTP overflow which is a direct frame pointer overwrite and return address overwrite so it's straightforward to exploit. So what we can do is we actually send four binary shell code there via the UDP echo block. On the response we see where it ended up and we can calculate the exact address it is. We also have no limitations on byte because UDP echo doesn't care what it got in a payload. We need actually to select a good address from those in the ring buffers because if the router is not sitting in a phenolate lapse it has probably something else to do namely forwarding packets. So it's using the ring buffers actually to do the job and we need to find a way to actually have a stable address where the shell code survived and is not overwritten by other IP packets. But well if we figure that out we own the box. So combined we actually send the maximum URL length allowed by iOS. Then we send two gigabytes of additional URL elements which has a nice side effect because it keeps counting and counting the number of bytes received and compares it to the size of the buffer. Now after you send two gigabytes of data this being a signed integer the number of bytes received variable will be negative and this is smaller than the size of the buffer so they can still copy it which means they're overflowing the buffer. Then after sending all the crap over there we perform a UDP memory leak server times so we get all the code addresses like an intelligent decision on which address to use well and complete the overflow. For those of you who prefer like all in color here it is. HTTP connect legal size URL send lots of A's do the UDP echo get the info back repeat until happy send the overflow on the box end of slide. The problem we got here is of course the binary via HTTP. We're overriding the return address so HTTP doesn't really like characters like line feeds character turns, slashes zero bytes are obviously bad but we found out that the HTTP encoding you know the percent XYZ stuff that everyone like uses to screw up in their web servers is actually performed on the same buffer before the overflow function returns. So we can actually do overflow and use the HTTP encoding so we can use arbitrary addresses which made it even easier. I said we need an intelligent address selection so what we are doing is there is several strategies that are listed here I'm running out of time so I'll skip over and just tell you use the second smallest address or the third smallest address is the best way to do you will see it in the code. Now shell code we had shell code in the past that overwrote the complete configuration which unfortunately means you lose all the juicy info like the passwords they use and they're never never going to use on any other router in their network and the routing information access lists all the stuff you could be interested in so we figured we need new shell code and for that we actually did binary research on iOS. iOS, Cisco actually supports serial debugging via GDP but it sucks but they also got some debugging capability in the ROM monitor which is comparable to what you have in your PC as a BIOS and so you can set breakpoints and do this assembly the cool thing here is code identification of the critical part of the huge chunk of code you got is quite simple because the string that is shown in a function is actually stored right next to the function in the text segment and that's before the function so all you do is turn on every possible debugging you can give and do whatever you wanted to find out and then look for the strings find them in the code disassemble the function after that and you got the function using those strings so equipped with this knowledge we actually figured out we need new shell code call it next generation code whatever what we do is runtime iOS patching we actually teach the Cisco device to forget about certain functions it performed before namely password validation so with the new shell code you turn it to the device and it stops doing the annoying user authentication give me the password stuff it just drops you on the user shell and of course on the same is possible for the enable password so it will actually ask you for the enable password when you say enable but it will not validate the results of course you can do other stuff you could actually introduce something like forgetting about to check if the bgp neighbor I'm talking to is really the one I'm supposed to talk to use your imagination the problem here is we have to keep ios running the overflow actually destroys a lot of stuff on the heap because of the encoding we use we send twenty four bytes and they end up being eight bytes but we destroyed a lot but the Motorola call structure actually saves frame pointer and stack pointer pretty comparable to the Intel ones and so all you need to do is search the stack upwards for information that was set there by a function preamble and use this information and your clean return and better like clear the return on information so it will actually return faults and nobody cares this is the code I guess nobody can read it there it just finds the return and cleans yeah you can check it out on the slides later ios runtime patching advantage of course the router stays online it doesn't reboot anymore the configuration is preserved so if you're interested in stuff like the passwords there's a heavily encrypted with the password seven algorithm and of course uh... it proves that what people talked about for years and years back during ios runtime code is actually possible and quite easy disadvantages of course it's depending on the image so we got the image independent and image dependence again uh... you need therefore a large target list and well you actually got annoying messages on the console saying check some error because it does check some the tax segment and uh... figures out that there's a problem but of course uh... we patch that out as well so this is what the exploit is Cisco Cosmos reliable ios remote exploitation that's just a summary uh... and this is how it looks like quite easy she's bad okay here is something uh... lots of people for last year's were complaining that all the presentations held on blackhead or actually uh... held the same way on defconn and there is no well yet so here's our well yet to defconn what about image independent shellcode we can actually uh... instead of modifying the image we can actually modify the configuration now the configuration is portable over images and versions so all we need to do is have a shellcode that does string search uh... mem copy and check sums well we can do that config modification code uh... we start searching at the beginning of the nvram uh... we look for currencies of uh... like interesting data uh... let's say password and enable uh... we replace it with our information uh... and hereby replace authentication information for the listed services we then just need to recalculate the checksum uh... for the nvram and write it back and this is how that looks like you know ios also has the advantage of ignoring lines with bullshit so uh... we can actually replace the stuff and uh... introduce a line feed the rest of the encrypted strings ends up being butchered ios ignores it that's fine advantages here it's image independent the configuration is pretty much preserved except for the passwords but of course we can change the shellcode and copy the passwords elsewhere uh... and we have actually more choices of what to do we can have shellcodes just renaming every router to like piece of crap uh... disadvantage of course it's still uh... platform dependent but well we cannot change that except for uh... if one of the guys that sees a challenge comes up with a uh... cross-platform shellcode for Motorola and MIPS uh... and the router has to reboot so we got a little downtime so what what's the whole thing about well didn't we mention last year that you shouldn't run unneeded services like utp echo uh... that you actually should protect your infrastructure and um... that you actually should not copy data into the buffers that are not large enough to hold them so the problem here is ios moves forward uh... the new ios versions actually got legal interception building half a year ago i was talking to jaya who did the uh... legal interception talk and i said that that would be quite interesting because uh... then you can wear a t-shirt saying my other computer is your legal interception system this seems to become true slowly well and if your infrastructure is owned uh... you can't defend your systems of course okay and one thing i wanted to mention is that there are more people than we are researching ios exploitation as a birthday gift i got body of secrets james bampford it actually has a whole page on the fact that uh... the nsa is actively trying to find hacks for ios so they can take over sysco routers i just wanted to mention that here uh... you actually got some very excellent uh... experience on defcon we just have to identify the people so the defense part of course mobile phones that's easy turn the crap off do not do bluetooth or have no uh... uh... infrared enabled when you're sitting in the airport do not run any java code just because it says it's going to show you titties uh... when you receive files delete them right away uh... think of your mobile phone as a crappy version of outlook and well if you got a chance uh... keep your phone from where up to date some vendors actually uh... allow you to do that for others you have to arrest on the people at the shop and if you're anyone is with the company doing that uh... don't do gpr svp ends defense sysco um... in summary do not trust devices just because they're in the black box it doesn't mean they're more secure it mostly means they're less secure uh... keep your ios up to date if possible actually block every direct communication to your routers there is no legitimate use to someone else in the internet talk directly to your router so if you have done that in the first place even the uh... q filling back wouldn't even affect you and of course uh... to do that you should prefer out of an management uh... so the one talking to your others actually coming in on a different interface and well you should include your router in the ideas watch list but i was racing through it and i guess i made it on time uh... thanks a lot being here and well i will be at the pool for questions uh... i know that most people don't see the lower part of the screen but this is something they just got in germany out with the advertisements and i thought we're gonna change that a bit and thanks very much