 Okay, yeah, I'm FX. Thanks for the introduction. And we're gonna talk about router exploitation today. So I will give a short introduction to that topic, talking about what vulnerabilities we actually have in routers, what architectures, what is different, what makes it harder. Then I'm talking like half of the talk about return addresses. So this is gonna be really interesting and then a little bit of shell code. And if any one of you here actually has Cisco routers, I got you covered too. Whew. So, oh yeah, so there is, to classify yourself, to have to classify yourself, there is a blackhead meter. If you've ever been to pH neutral, you know the scheme. Essentially it means acid is like, you know, whiteheads and base is blackheads. And so it will essentially indicate on the slide where we are. So if you're wearing a suit, only watch the slides that are in the upper area. If you got a CISSP or something, then you can go as low as the middle area. And then everything down there is assembly and fun stuff. So, introductions. Essentially, we have seen router exploitation before. I have been involved in some of that. There was primary focus on iOS, of course. But interestingly enough, we're not seeing Cisco warms. And we are actually not seeing any large scale exploitation of a Cisco device in the field. We have written a tool to find those things. And I talked about it last year. And essentially, with a few exceptions, we actually drew a blank. And this actually motivated me to look into that issue and go like, hmm, so why? Like, why is actually nobody doing that? And I tried to figure out what do you need for a weaponized iOS exploit? Like, not for, you know, works in a lab and on stage, but for an actual weaponized exploit. What will it take to have meta-sploit modules, for example? Now I can already tell you that's not gonna be easy. The thing is, everything in Cisco is so fragile that, you know, when you attack it, it just blows and people notice. So it's not really easy to actually exploit them. And all incidents that we've seen have been insider attacks, configuration issues, trivial functionality bugs and stuff. So this is actually what we're seeing. And so I'm, yeah, here's the motivation. So the thing is this, everything that even remotely has anything to do with data that you can send other people is getting exploited. Why is it not that infrastructure gets exploited? I mean, it's obvious that control over the entire infrastructure of someone you don't like is good. Therefore, there must be something unique about, especially Cisco, that makes it really, really hard. Now if we figure out what that unique stuff is, then we can actually tell what needs to happen in this world so we actually see Cisco warms. And that actually allows us to react before it actually happens. So that is essentially where I came from. And now we're talking about vulnerabilities and routers. So there is actually very little public vulnerabilities. There is actually a shitload of them in Cisco IOS. Only 14 of them have been published last year by Cisco. Juniper actually never published anything of importance regarding their own products in routing environment. They have this kick ass like industry rock star security team, but apparently they're actually not testing their own boxes with it. So vulnerabilities in network world actually get fixed a lot of times with the customer from the networking department sending them a TCP dump. Well, after jumping through like 500 loops with the first and the second and the third level support people, right? He's sending them a TCP dump file and says, look, this packet crashes my router. And they go like, oops, functionality issue, gonna fix that. So it actually never makes it into security advisory and doesn't make it into any databases. So it's not accessible to any of their customers, even if they care. So they don't actually know, which is bad because those customers run our internet. You know the place where the porn comes from? So the vulnerabilities we have are service vulnerabilities, that is the most common thing because like everything that is a server likes to get attacked, same on Cisco. If you fire up a server on a Cisco router, it will be attacked. So that would be remote administration interfaces, SSH, something. That would be SNMP because everyone needs that to run their networks. That would be other stuff that shouldn't be on there like a TFTP server or an FTP server or an HTTP server. I mean the FTP server on Cisco iOS was so bad that when the first security vulnerabilities were identified Cisco decided to remove the entire server and to start over again sometimes in the future but like they essentially deleted the entire code tree and that was so right to do. So how can you have two buffer overflows and one format string vulnerability in the parsing of any command in FTP? So what is this actually saying? I'm actually just seeing half of the screen on my little fancy EEPC thingy. Yeah, so there is relatively little stuff that we have seen so far and the services that we have are actually not exposed to an attacker. Like the services you normally run if you have a clue as a network engineer are something like routing protocols but they require that you're within the same network. So you have to be within the same company for example to speak multicast with the routers. If you don't speak multicast, you're not speaking OSPF, you're not speaking in outside GRP. So essentially this is use left if you wanna like truly remotely attack someone. RIP is so simple that even Cisco didn't fuck it up. BGP, you have to explicitly say I wanna talk BGP with that guy and if that guy is actually sending you traffic you know who it is. That is really not useful for an attacker. The protocols where they put in the most stuff are layer two so you actually have to be on the same switch and some routing protocols like ISIS don't even speak IP. It's not IP, right? So you can't route it on the internet. If you are within the same multicast domain let's say within a large corporate network, good fun. But over the internet principle is don't trust routing updates from arbitrary people. There is a notable exception which is my favorite research bug. I haven't actually found it myself. So there is this vulnerability in iOS with IPv4 option parsing and it's only hitting in four different protocols. Things like the URL around the Vue directory, whatever, never hear of that or some multicasting routing and a rarely used protocol ICMP known as Ping. So this is really good because what they try to do is so you get a Ping packet in and it has a source route, IPv4 source route that everybody ignores because it's evil. So they think, okay, I'm getting this in and now I wanna Pong back to this machine so therefore I need to actually turn the source route around. And RFC says that there is only gonna be eight different IP addresses in the source route at max. So we allocate a static buffer on this deck that holds exactly those eight and then we parse it. And then we turn it around, which is a buffer overflow. Funnily enough, they also do that when you actually put a stop option in front of it. So it actually says end of options. So any sniffer, any IDS sees no options. And anything else is Cisco and sees a buffer overflow. The good thing is from an attacker point of view that people invent stuff and they don't do it right and then they put it on routers. So like nowadays we have IPv6 which is rarely tested at all because no end user actually uses it. And then people putting VoIP onto routers, like all those very simple to parse AS and one protocols. And they put web servers on routers so they can actually speak zip. And then governments come around and say, fuck, we need internet survey and so they're putting lawful interception functionality into the routers. People put SSL VPNs on them. There's brilliant new idea from Cisco which is called web service management agent. So it's actually opening a web server port on your router and you send it XML data to manage the router. So they can actually make it web 2.0. So who are we? Who's actually like to just to clear this up for everyone who are we is actually not running stolen Cisco code. They potentially did that in the past but they're not now. So their access routers actually come with age three, two, three enabled on like 10 TCP ports and it's not solid. The good thing about this is network engineers are real old style bunch because they like their blinking boxes to be simple because that way they don't have to learn new stuff which is good to totally understand. So they're really slow to adopt this stuff but like if you're rolling out voice over IP in your company, you can't do anything. I mean, the boss is telling you. Client side vulnerabilities actually play absolutely no role on Cisco because Cisco's are actually not used as a client. There are notable exceptions like if you type in a command that it doesn't know and you didn't explicitly tell it to not do NS lookups like name server lookups it will actually broadcast the DNS request to the local subnet like broadcast it. Whoever answers is correct. That is not smart. But the new services I was just talking about will change that as well because they will actually make the router a client because it's doing HTTP requests. And then there is the most powerful way of looking at Cisco vulnerabilities that is vulnerabilities that are triggered by traffic which actually flows through the router. That would be nice, wouldn't it? Like the router gets a packet, reads that packet, forwards that packet and then get owned. So with a far away target you actually score like 10 or 20 routers with one packet. But they're actually really rare. In fact, we haven't seen a single one yet. This only holds true for real Cisco iOS equipment like if you have a deep packet inspection firewall as whatever server bullet Cisco box, that is different. Yes, they get owned by traffic that goes through them. But routers are actually trying really, really hard to not look at traffic because if they would look at every packet that goes through, they would simply die. Like you will actually have like clusters of CPUs in them to forward the packets. And routing is all about speed because we want our porn to like not be Lego land. So it actually doesn't happen. Some traffic is notable exceptions. Some traffic actually get like source routed, for example, that must be inspected on every hop or you have an IPv6, you have the hop by hop header. And I'm going to watch that one closely because I'm sure that Cisco is gonna fuck it up. So what makes it so hard? If you compare the architectures of a couple of router vendors, Cisco iOS actually is a monolithic elf file. It's like the biggest Hello World program you've ever seen. Therefore, because it has no internal protections and we are going here into the details later, the default behavior if something goes wrong is device crash. Now people realize when the porn stops. So it's a really, really bad property of that platform. This actually makes it so hard. The service modules are actually running on Linux. So they're only process crashes. The router keeps forwarding exploitability a lot easier. Juniper running FreeBSD. I was told that they're actually upgraded to FreeBSD6. So thanks for letting me know I didn't know that. And they are standard Unix, right? You find a vulnerability exploited bomb. Huawei actually runs VRP in two different versions. There's a Linux VRP and there's a VxWorks VRP. VxWorks is a little bit more bitchy to exploit, but the Linux one is a Linux one, you know? So this is what I'm saying. The Unix-like operating systems and routers make it actually really easy to exploit those boxes. There is nothing fancy about it. So I don't actually know if we just fucked up completely and should have written a Rootkit detector for Juniper and not for Cisco, but yeah. So the hard one is iOS. This is why I love it. And as I said, it's a single large binary, shared memory architecture so everything can write anywhere in memory. There's virtual memory mapping according to the elf header so you only have a data section and a text section and stuff. And it's for PowerPC and MIPS. It has one single shared heap. So the whole thing shares one heap. What can possibly go wrong? Processes are a threat, so they actually memorize just the CPU context of that thing and then store it off. There's very little additional information to it. Oh yeah, and we have something that is really nice. We have a run to completion scheduling. Remember Windows 95 where you put in a CD and your PC didn't do anything for half an hour? This is how they schedule. So the consequences is it cannot recover from exceptions. If anything goes wrong, like if you have a divide by zero or something, your box literally does the equivalent of blue screening. It cannot recover from memory corruptions. If something in the heap is corrupted, it takes down the whole thing. Like you can't actually fix that anymore. The way you fix that on a Windows machine or similar is it's in a process and the process has virtual memory mapping. So if he fucks up his heap, here's fucking problem. In iOS, if he fucks up his heap, he fucked up your heap. Everything goes down. That is really bad. So you don't actually have a kernel that can kill stuff. So therefore they actually have an additional process that is called check heaps and walks the heap and tries to find corruption in the heap. And if he finds it, he reboots the box. And it cannot handle CPU Hawks. So Windows 95 tasks scheduling, right? One process, eating all the CPU powered, they actually have a watchdog. And the watchdog is then saying, it takes longer, it takes longer, I reboot. Is there anything else? So the memory layout is based on an image, right? It's a big fucking Hello World program. So it's also influenced, like IO memory and other memories are also influenced by what stuff you put into the router, like what interfaces. And so you have this base address here, which is stable over the platform. And then you, oops, sorry. And then you have a couple of other sizes that actually influence how big stuff is. So if I write one additional line of code into iOS and I recompile it, which happens a lot and we're gonna cover that, then all the sections that come after the text section, so the data section and BSS and all the other stuff is gonna be on a different address, which sucks because we need a return address. Every iOS image is apparently built from the scratch. Like every coder on Cisco land has its own make file. There's a very good reason that iOS actually says the corporate username of the guy who compiled it when you boot that thing up, because if they're getting a call into tag, stuff broke in this image, they're checking if the guy's still there and then either see if he can fix it or if he can actually not. And then, I don't know, hunt him down, right? Because he's the only guy having the make file that produced that image. Now, it really depends on platform version, minor version, release version. Then they have this concept of train. So a train essentially means the stable train, which is the slow train, you know? And then you have the real non-stable train, with like T is the technology train. There's new features in it. Imagine you have a Windows 2000 and you get the Windows XP version of like Solitaire. And so that decides then they have features, you pay by features, they get compiled in every time. And there are special builds as well. So we're ending up with like 270,000 different supported iOS images. That is a lot. So what is this doing here? So for exploitation, that essentially means you have a chance of 0.000366% of having the right return address if you're considering return into Libc. Great, that is not useful. And your assumptions about stack and heap are gonna be as useful as well because you're basing them off a address that you don't know. And stacks are actually blocks allocated in the heap. So your chance of guessing where the stack is of the stack that you just overflowed is actually even smaller than figuring out where the heap is. And that essentially means that the fucked up build process Cisco has is by far the best protection. It provides more entropy than any ASLR you've ever seen in a regular operating system. So at Blackhead, I actually happened to run into the guy who owns the build process now. And he told me, yeah, I know, it's really fucked up. We're making it better. I'm like, don't! Dude, if I can predict your code addresses your toast. So that is really fun. So this diversity is also a real problem for shellcode, right? But in shellcode, you usually need to get access to addresses somewhere. Like functions, you're calling functions of the operating system. That is the whole point of your shellcode. Well, the problem is the functions are always at different places, different addresses. And since it's compiled at once, they don't need something like a registry or something like exports from the DLs that tell you where functions are. And so essentially you don't find them. They're not there. And if you directly work on the data structures, for example, yeah, it's the same thing here because you would think that something like a struct that holds all the information about a process, something like the PEB and Windows, would actually be a really stable thing on Cisco. Well, heck no, because everyone can code anywhere and there is no segregation of duties whatsoever. People love to add an additional integer in the middle of their most central structure and the next version remove it again. This is really good. So using platform code is actually hard because we have this return address dilemma first. So where could we return to stack? We already discounted it somewhere on the heap. It's very unpredictable. iOS code is image dependent. We have a shitload of images, so we have no idea where that should be. You would need actually to have an exact version information for the image, which you don't, and you would also need to actually have that image because you need to disassemble it and find a function that you want to jump to. So you don't have that either. In the other sections, for this talk, I actually went ahead and compared 1,597 images for the 2,600 machine and compared the addresses of the sections because I thought, well, maybe, they actually align sections to aligned address. But they're trying really hard to keep this shit small because they're putting so much bullshit in it. So only 24 of them, so it's 1.5%, have a section on a common address, which is the data section, which doesn't mean that it contains the same things, right? Interestingly enough, in 12.4, they actually started to align things in their images. So they're actually, yeah, I'm seeing proof that they're working on a build process. Stop that. IOMM was my favorite idea. So IOMM memory and shared memory routers and the smaller ones is the memory where the actual packets are kept. So I sat down with a colleague of mine and we actually developed a valid IPv4 packet that's also executable PowerPC code. That was a nice thing to do for an afternoon until we figured out that now we have it and then IOMM memory is actually not executable. Could've checked that first. Heap spray is actually entirely not applicable because you have essentially no control over the heap. And you don't want to spray on that heap anyways. Now you actually have no control over the heap because there is a big difference between you providing a lot of JavaScript to a browser and controlling it completely and you talking to a router. Yeah, they're not gonna allocate much heap for you. Partial overwrites will be a good idea if you have a 32-bit address and you just overwrite like the least significant stuff then you can easily jump into buffers without knowing where they are. However, that only works on little endian platforms and we're speaking big endian here. So this is out of the picture. But Cisco has something like a loader, something like a BIOS called the boot ROM. And that's the ROM on. And that's actually right now the very best option we have in terms of return addresses. So the ROM on is mapped initially into memory to boot up the machine, right? And then stays there and it's mapped on fixed addresses. So let's get this right because many people after Blackhead asked me about this. So it's not deleted. We're not talking about like hacking the Cisco when it's booting up. It got other stuff to do at that point in time. It's loaded code like your BIOS code that is used for booting and then stays in memory so it stays there the whole time, okay? Just making this clear because people ask me that. So you see the addresses are relatively stable. Now the addresses are stable, what about the code? Diversion distribution is actually a lot smaller with ROM on and it's rarely updated. Who updates a router BIOS? There is only one reason to do it because if you get new line cards then you sometimes need to update it. But other than that, nobody does that. A feature of Cisco's large sales organization is that they love bulk sales. So they go into a network provider or service provider and say, hey, how is it like you buy a new network? Your equipment is already three years old. Throw it away, buy new stuff. And the service provider says, sure, blow me one and I buy it. And so, yep, they do it and then they buy all the boxes new, which means they're gonna have all the same BIOS version, right? Which is good. So I Googled around, you see a Pacman to the left side. So this is actually the version distribution according to what people write on the net. In 2600 routers, so you see there's a very big chunk of 70% running the same version. This is actually really cool. What you see on the right is a real world network, a larger real world network. And this is all the versions that there are, but it's over all the device classes, like from access switch up to big boxes. And no, I'm not gonna tell you where I have that from. So having Ramon in the same position all the time, we can use something called return oriented programming. So this is one of those techniques that everyone who needed it invented it for himself independently. I easily know about like 50 people that invented this technique for them because they needed it at that moment. There's a very good talk on this last year at Black Hat. I highly recommend if you can get your hands on it to actually read it, it's awesome. Or ask me about it later. So essentially what you do is you take, when a function returns, it actually restores the stack, right? And then it returns to whoever called them. Now this is common to pretty much all functions. Since you are controlling the stack, since you're writing there, if you have a stack-based buffer overflow, you don't provide just one return address, but you actually provide return addresses like many of them. And you keep jumping into function tails because if you jump into a function tail, then it's gonna pop stuff up the stack and so the stack pointer goes up and then you can actually control it again. So you use that and then you use the few instructions before that to actually cause shit to happen. And in this talk, they actually proved this method to be Turing complete on Intel and PowerPC. So we know that it's actually generalizable and now we do the same thing with the ROM on. So and this is how it looks like. So you have your buffer overflow up there, right? Buffer overflow happens, you overflow the stack. And by overflow in the stack, you're actually controlling a couple of things that are gonna be restored from the stack later on. Which is, first of all, very important. PowerPC returns not over the stack directly, but over a register called link register. So if you wanna return somewhere, you actually load the address of where you wanna return to into link register and then return. So it's actually restoring link register from the stack here, which means we keep control, right? Or we get control in this place. And then it's restoring two variables, our 32 registers are 30 and 31 through saved variables on the stack. And then it's adding the stack and then since you control the return, you now jump into a function tail like this function number two, which actually ends on an arbitrary memory right based on those two registers. So you're already controlling our 30 and 31. And now you get an arbitrary memory right, which is good. And then you can keep continuing doing that. So you fill the rest of the stack with the next stuff, which gets returned and restored into the registers. And then you return again to this function. This way you can actually write arbitrary values on two known addresses in address space. But you have a problem, another one, so to say. Essentially, we have too much cash, rare thing to have, but we have too much cash, we have two different caches. We have one cache that is a data cache and another one that's an instruction cache. Now what this means is if you actually have a buffer overflow like this mem copy here or anything else, any copy operation, it actually doesn't really write into memory, but it actually stays in cache. Now you don't actually have much time between you overflowing the buffer and you actually trying to jump into executable code. So this flash actually doesn't get flushed. So if you jump there, it's actually trying to execute what used to be on that position before you wrote, which sucks because you wanna run your own stuff. Luckily, in this bootstrap code, Cisco needs to do the same thing. Cisco needs to disable the caches when they actually load up iOS. So there's an entire function dedicated to that, which we can jump to, of course, and return-oriented programming used that one as well. So we're putting it all together. And so we're having the buffer overflow. We use return-oriented method to actually disable the cache by calling code in Roman. Then we write one four byte 32-bit set, which is an instruction into the exception handlers. The exception handler area has to be on the same position. It has to be executable. I have no fucking idea why it has to be writable, but it turns out it is. So I just write like a move stack pointer to counter register instruction there and then a branch to register instruction, to counter register, and then we can just jump there. The net effect being that this code, those two instructions, know exactly where the stack pointer is. So we can jump there. So we're jumping into the buffer, which we're just overflowing. So now we have regular code execution on the stack, but we actually don't wanna mess up the stack too much. So what we actually do is, we run a little second stage code that goes into IO memory and searches for magic value and then finds the packet that overflow came with, right? So it's finding his car and it's getting more stuff out, more shell code and putting it onto the stack where it belongs. And then you execute it and then you're pretty much done. I don't know if I mentioned that, but this is all one ICMP echo request and it drops you in an enable shell. So this actually works. So the thing is, because we have this fucked up scheduler, we actually need to be really careful how we get away with the exploit. Because if we just run our code, it's really bad because then the Windows 95 scheduler is gonna die and then the watchdog is gonna kill us. Other people have used terminate process as a method of getting away with it, like the terminated iOS process. The problem with that method is two-fold. One, you again need to know where it is. So it's image dependent, not good. The second is with the ICMP bug, for example, I'm exploiting a process called IP input. Now imagine what happens if I turn that off. The device only does IP output. Not very useful. So this is not usable. But we still have this stack layout going on, right? So you're still with me? You see the black headometer? It's fine if you sleep. So essentially we still have this stack laid out and there's still gonna be some stack pointer and link register saved on a stack higher up that is still valid and still intact. So we can actually parse upwards and find stuff of the stack that is not destroyed yet. And then we actually restore the registers based on that information and just return, entirely innocent. That works. The downside of Ramon is actually getting it. Like the problem is you're interested in the oldest version, the one that is most distributed outside. That is not available as an update obviously. And so you will actually need to get out and get the physical boxes and like get Ramon of them and disassemble them to know where stuff is. And because it's that code, you can't remotely fingerprint it. It would be like you try to remotely fingerprint the BIOS version of a PC, right? That's gonna be hard too. And you still need to know the hardware platform but that's a different issue. So what alternative method could there be to actually return without the Ramon? Return directly into the image because that you can actually fingerprint. What a problem here is that we just said they're all different and there are many of them. But the question is how different are they really? So I did this. First of all, I did what every good geek does with a new project, you buy new hardware. So I got a new machine and then I wrote a proud script that actually disassembled 1,597 iOS images and then runs a code similarity search on end. So it finds every return, every BLR instruction, parses upwards and validates that the linked register is actually restored from the stack because that is required and then it also validates that it's, that it has an arbitrary memory right and it validates that it's all in the same basic block so no shit can go wrong in between. What's up? I'm last dude, it doesn't matter. Yeah, same happened at Blackhead. I'm just speaking too slow. So here's four images, so you see it a little bit closer. So we're actually having an equal sequence in two different forms, so it's the same sequence but it's sometimes offset it by a couple bytes. The fun part is if you look at like 70 images, it happens to be only those two cases. That was really, really interesting. Now 70 images is still nothing. But if you take two images that are based on Cisco's feature navigator's output exactly equivalent, except for a very, very, very minor release fix, I don't know, they maybe changed the blinking rate of the prompt, change, they actually differ again. So this is really cool and then you look at larger bases and then you see that out of the 1,600, you actually have like 326, which is 20%, that share an arbitrary memory write on the same address. This is very promising. We find other stuff like fixed memory write and stuff, but I'm actually, this is work in progress, so I'm actually working on grouping those images together so I find which of the 30, of the 20% have what in common altogether. So you can actually know what you fingerprint, what you need to fingerprint to then know what return address to use. So when you compare the two, Ramon is actually still better. You get better chances, but you can't fingerprint it. On the other hand, for the method with the iOS images, I still have the caches you open. Like there is no cache disabling code in iOS that I can easily find. So I don't know, as I said, work in progress. Let's skip the summary. Go. So what about shell code? First of all, it tends to be big ass because the instruction set, our fixed size instruction set, so they're 32 and 64 bit. You often have that problem that your shell code is actually too large and overflows over the stack into the heap header block because the stacks are allocated on the heap and then the whole thing breaks down. I actually have shell code that in the middle of itself repairs the heap because it's sitting on the heap control header. That is really useless because then at the end, you actually don't have space for doing anything else with that and you need the stack to actually stay clean because you still need to return, remember. So you always need second stage code and there's some particular problems with finding IO memory addresses because they're not stable either but we're gonna solve that. What can you do? You can create VTYs, right? You can just create an enable shell but you always need to have addresses in the code that you can jump into. You could create a VTY or you can directly modify the data structures and I already mentioned that this is not really stable. You can also just modify the image. Now, what is this? You only need one single code point that you identify which is potentially the one that says password wrong. So what you do is you do exactly that. When you do it by hand, like when you open the iOS image and you wanna patch it, you find a string and then you cross-reference that string into memory where it is accessed. Well, you can do that in shell code too. So, shell code goes ahead and finds a unique string that you provided and then parses the entire code section and disassembles it and finds LIS and add instruction that you have two instructions that load the address of a string because it's a 32-bit fixed size instruction set. So it finds the two instructions and then knows in which function it is, right? And then it goes back upwards and actually disables the function entry point and just returns true. This is how it looks like. You have it on the slide. So this is how you code patch. Cisco has started to put tickle into the hands of system and network administrators. What if all places tickle? Couldn't they have loaded pearl on this, please? So they opted for tickle and you can automate a lot of shit with it. It's only in the newer boxes, like 12.4, but it's actually very useful for network administration and automating processes on their orders. Now I could imagine writing a shell code. I haven't done that yet. That actually downloads a tickle script from somewhere and then your remaining shell code is tickle. It would work. Many people have wet dreams about iOS sniffers. So essentially like post-exploitation, you're actually running a password sniffer on the router. What router would know, wouldn't he? The problem is that's a very naive idea because as I said, if the router would actually look at traffic, it would die due to the load. So this actually doesn't work straight out. However, very stupid ideas from governments in the first world that have to do with lawful interception are actually helping here because lawful interception by law requires that you build in targeted sniffing capability that the administrator will not see when it's turned on. This functionality is there no matter if it's turned on or not. So we can jump to it. So actually if you're running a service provider network supporting LI, which you have by law, then you're actually the only ones that are at risk of running an iOS sniffer that someone else controls. And the same holds true essentially for men in the middle. What I could imagine would be really cool is like compromising a core router and then getting it to the point where it's actually like leaking out sequence numbers from arbitrary TCP connections. So you can inject into any connection that is going through this network from anywhere in the world. It would be nice. So how do you protect? First of all, good luck. The easiest way to protect is prevent traffic designed to the router itself from getting there. Like nobody is supposed to talk to your router and don't forget like your fancy interfaces that you configured. You should use MD5 where you can and routing protocols. And you please stop running shit on iOS. Like it's not, it can barely handle itself. How should it handle a web server and an FTP server on top of it, right? So don't. Okay, and monitor your service modules. They're, yeah, special. Configuration checking is the easiest way to catch most of this actually. Because if someone owns a Cisco machine at some point the configuration is gonna change. There's a tool for that called Ransit which people running big networks actually use so it's actually halfway decent. And configure core dumping. Core dumping is the only fucking way you can ever find out if someone owned your router or not. If you didn't configure it beforehand, it didn't happen, you have no evidence whatsoever. So just place the FTP servers somewhere until all your Cisco's to dump core when they crash. This also helps harassing Cisco to fix the bug if it's not a security issue. So please do that. For really critical machines add enough flash so they can dump locally onto their flash and don't need the network for that because that is perfect evidence if someone is shooting with an exploit on your machines and they can do that, you have the exploit. Go ahead and complain to Cisco. The real problem is nobody updates iOS because then shit breaks like porn stops, you know? The cool people run 12.2 because that's the only thing they know is stable. The braver people run 12.3 and the void people run 12.4. And fail miserably with getting it to work, you know? Cisco should actually go ahead and like find out. They're the only ones that can find out how you can transition from one image to the other without breaking porn. Thank you, please do. And please complain to the other vendors because they're definitely not doing the right thing because the lack of advisories indicates that their stuff is perfectly secure. No, their stuff gets fixed silently. Maybe their stuff doesn't even get internal testing most likely. They're not looking at it at all. Like Lino Storwitz made fixing bugs and critical code stuff without telling anyone cool because he said security bugs don't need special treatment. Well, I'd back to disagree. And Cisco is actually doing a really, really good job here because the PSER team is actually this one bright spot of security in the whole Cisco blackness, you know? So, yeah, complain to them, tell your router vendor that they should actually test the shit and publish the results. And that was it for me. And I would like to point out that my best friend and DJ Moonby is playing tonight at one at Black and White Ball, right? So come by and see us there. Thank you very much.