00:00:00.500-->00:00:05.917 [Applause] >>Hello guys. Hello and welcome. Super glad to be here this is my first time 00:00:05.917-->00:00:12.750 speaking at Def Con. Very humbled to see so many people. Thank you guys for coming. So I 00:00:12.750-->00:00:17.458 heard there might be some problems with the projector so I apologize for that uh in 00:00:17.458-->00:00:22.458 advance. So without further ado, let's jump into some practical Cisco Switch Exploitation. So I 00:00:25.042-->00:00:30.042 am a Penetration tester at Kaspersky Lab. Um I am also a skydiver, so if any of you guys 00:00:32.333-->00:00:37.333 skydive, raise your hand. No one? Yeah buddy! [Laughter] So uh long story short um I'll be 00:00:42.042-->00:00:48.875 talking about um critical vulnerability published by uh Cisco Systems on March 26th and 00:00:48.875-->00:00:55.625 it announced that uh around three hundred uh different models of uh Cisco Switches were 00:00:55.625-->00:01:00.417 vulnerable to an uh unauthenticated code execution vulnerability and uh but it also 00:01:00.417-->00:01:04.875 said that signs of uh exploitation in the wild. There's no public exploit 00:01:04.875-->00:01:11.000 available. So, um there was uh one quiet evening just writing one of those pentest reports 00:01:11.000-->00:01:16.000 when I decided to take a break and go to my Twitter feed and all the sudden I stumble upon a 00:01:19.542-->00:01:25.292 tweet about the vulnerability, about the Cisco Advisory. So here what- here's what I saw. 00:01:25.292-->00:01:30.292 Red. Critical. So it got a CVSS score of nine point eight. And uh in a nutshell, this uh was 00:01:33.375-->00:01:38.375 about um a remote code execution via a Telnet service and cisco switches and that happened uh 00:01:41.833-->00:01:46.833 because of two major uh problems. Uh there was a failure. um about plus- uh cisco 00:01:50.917-->00:01:55.917 systems um might be um joining clusters. And um surprisingly enough they are using Telnet for 00:02:00.917-->00:02:05.917 um communication between cluster members. And um that's not just plain Telnet. They're using some 00:02:08.042-->00:02:13.042 of their specific options plus their management protocol options and um- Also this 00:02:15.917-->00:02:22.000 options are not correctly parsed no the server side. So um this uh according to the advisory 00:02:22.000-->00:02:28.167 this leads to remote code execution. So the vendor advice is um disable Telnet. Which is a 00:02:28.167-->00:02:33.167 solid advise because you know that um Telnet is a old legacy protocol. Um is being superseded 00:02:37.125-->00:02:42.125 by SSH, um. >>We can't hear you. >>Speak into the microphone. >>Okay. Do you hear me now? 00:02:44.167-->00:02:48.750 Okay, that's better. >>[Inaudible comment from audience] >>So Telnet is a 00:02:48.750-->00:02:55.500 legacy protocol and which being superseded by SSH uh like twenty years ago. And now according to 00:02:55.500-->00:03:01.375 the advisory, you can now get access to a Cisco Switch to ride. Um is it really serious? 00:03:01.375-->00:03:07.333 Uh a known public exploit uh no knowledge of exploitation. Okay, so guys, challenge accepted. 00:03:07.333-->00:03:12.333 That's why security researchers are here. So I'll walk you through uh the process of 00:03:14.667-->00:03:19.667 creating a working exploit of uh this switches. And uh to start off um the first thing I did uh 00:03:22.625-->00:03:29.375 was research uh the information available public about this vulnerability. And basically 00:03:29.375-->00:03:35.375 there are two things up for grabs. Uh one is the Cisco advisory that uh I was just 00:03:35.375-->00:03:40.500 talking about, The other one is the original source of information, the Vault 7 Leak. 00:03:40.500-->00:03:45.500 Uh that happened in uh March of 2017 um and that is um actually the source for Cisco Systems 00:03:51.625-->00:03:56.625 them uh themselves. Thats where they got information about the vulnerability. So this um leak 00:04:00.125-->00:04:05.125 effected many vendors uh like uh Microsoft Apple and Cisco. I decided to swift through the 00:04:07.667-->00:04:12.667 pages of uh this leak to find something honestly I was hoping to find some kind of exploit 00:04:16.125-->00:04:21.250 there or at least a step by step explanation of what was going on. But no, it was even a 00:04:21.250-->00:04:26.250 challenge to um find the pages themselves. Because everything was code named and uh the code 00:04:28.375-->00:04:33.375 name for this exploit is ROCEM. I don't know what it means. Um, all I got were the testing notes 00:04:37.708-->00:04:42.708 for it so the tiny bits of information I got from the uh the Vault Seven is it works in 00:04:46.667-->00:04:51.667 three ways. It has um three ways of operating. Is set, unset and interactive mode. Uh which 00:04:55.125-->00:05:00.125 brings us to Set Mode. So they run a scri.a script that basically um turns off the 00:05:03.833-->00:05:08.417 authentication on Telnet Connection and after that all the subsequent connections to 00:05:08.417-->00:05:13.417 Telnet uh are credentialed less. So you just pop up level fifteen Cisco IOS. So the answer is 00:05:15.875-->00:05:22.417 completely opposite. You just um get the authentication page back and also sequent connection 00:05:22.417-->00:05:27.958 require password. And the most interesting one is interactive mode. SO you run the exploit. 00:05:27.958-->00:05:31.958 You immediately uh get a shell and notice some sequent connections are effected. So 00:05:31.958-->00:05:38.625 this is my guess from the Vault 7 pages. I don't know how it exactly work but I assume they 00:05:38.625-->00:05:43.625 work this way. So I decided why not do the same uh I had two Cisco switches available. Uh I 00:05:48.750-->00:05:55.750 just needed to cluster them up. Uh dump some traffic in cluster configuration and I hope to get 00:05:55.750-->00:06:01.750 a working exploit. So this is how I felt at the beginning. [Laughter] But you know um the 00:06:01.750-->00:06:06.750 life is harsh and I look like this actually. [Laughter] So you guys um. Uh a few words about um 00:06:10.167-->00:06:16.292 clustering those switches. So this is a way to actually uh a centralized way to administer 00:06:16.292-->00:06:21.250 several Cisco Switches. They have the master switch and they have several slave-switches. Uh 00:06:21.250-->00:06:26.250 and you just um log on to a master switch and uh you are able to pop up a shell from any 00:06:29.417-->00:06:34.083 of the slave switch from the shell of the master switch. So this is kind of what it looks 00:06:34.083-->00:06:40.500 like. If you log into the master switch with a level 15 privilege, you will get a level 00:06:40.500-->00:06:45.500 15 shell on a slave switch. And the switches uh are doing this by uh discovering themselves on 00:06:47.667-->00:06:54.458 the L, uh L Two Network. They're broadcasting CDP Packets uh and they're building up tables of 00:06:54.458-->00:07:00.208 possible candidates for clustering. So um you add a master on the salve switch and 00:07:00.208-->00:07:04.875 then you are able to run the r command command which pops the R Shell. So I was running 00:07:04.875-->00:07:09.875 Wireshark uh during running this command uh and testing all this. And the advisory if you remember 00:07:12.000-->00:07:18.583 said that there was a Telnet going between this mastery and slave switch, so I look up the 00:07:18.583-->00:07:24.792 Wireshark and what do I see? Where's Telnet. [Laughter] No Telnet. So some fancy unknown L2 00:07:24.792-->00:07:29.792 Protocol. Uh I wasn't expecting that. Telnet? No Telnet. So Um I was really unhappy and almost 00:07:33.542-->00:07:38.542 closed the Wireshark window but I decided to type some more commands into uh into the shall 00:07:40.875-->00:07:45.875 and I actually observed that there is Telnet in uh the traffic. Uh what was funny is 00:07:48.208-->00:07:54.542 this L2 protocol actually encapsulates IP protocol where the source and destination uh 00:07:54.542-->00:08:01.125 are not IP addresses but chopped mecca addresses of the Cisco switches. And of course an IP 00:08:01.125-->00:08:06.125 packet dot TCP Packet and Port 21 and we got Telnet inside. Okay. Okay then I said. Um next 00:08:10.625-->00:08:17.167 thing I was looking at the traffic for some uh anomalous uh traffic of Telnet but uh 00:08:17.167-->00:08:23.000 everything was the same as the. with the generic Telnet connection, except for.for the 00:08:23.000-->00:08:28.000 initial handshake um. You know Telnet before you are presented with the um credential prompt uh 00:08:31.000-->00:08:36.000 and the shell, the serving plant are negotiating the uh options. And um what's interesting is 00:08:38.250-->00:08:45.083 there is that, I found an interesting uh string flowing um between the server and client 00:08:45.083-->00:08:49.708 and it says Cisco Kits. So we have to remember the string as this proved to be an important 00:08:49.708-->00:08:54.708 string. Back to the Vault 7. Uh, one of the important bits of information that I got there was 00:08:58.250-->00:09:04.375 notes of some engineering- engineer uh testing the exploit. Uh of course no exploit was 00:09:04.375-->00:09:09.375 available for Vault 7 but uh this was um kind of um error log for is um Telnet debug from 00:09:13.083-->00:09:18.625 Cisco. And it says that this is some kind of anomalous up. And we see the same string that I 00:09:18.625-->00:09:25.042 observed in uh in the Wireshark Dump Cisco Kits. Um since this is Track 101 here's a Telnet 00:09:25.042-->00:09:31.500 Commands and Options One-oh-One. This Cisco Kit String was transferred as a part of 00:09:31.500-->00:09:36.500 sub-negotiation option of Telnet. Um it can be used to transfer custom parameters um 00:09:38.708-->00:09:45.250 before the Telnet session. Well I decided to go to the easy way and I was sure I would get a 00:09:45.250-->00:09:50.250 shell easily and I just replayed the traffic into a generic Telnet connection but no. It 00:09:52.500-->00:09:57.500 doesn't work. I'm still presented with a credential check and if you look thoroughly 00:10:01.167-->00:10:06.292 through them Cisco Advisory Page you can see them. They actually have an IPS rule for this 00:10:06.292-->00:10:11.292 vulnerability and it's called Cisco IOS Buffer overflow. What does this sound like guys? It's 00:10:15.292-->00:10:20.917 time for some reverse engineering. Alright so uh if you want to reverse engineer, 00:10:20.917-->00:10:27.042 you might want to get the firmware out of the switch easy. Uh you just log into the switch. 00:10:27.042-->00:10:32.042 You list the contents of uh flashed directory. There's always a firmware uh there. 00:10:35.000-->00:10:40.333 Cisco Switch has a copy command which is able to copy the firmware to an arbitrary FTP 00:10:40.333-->00:10:46.875 server so getting the firmware is pretty easy. What does a researcher do with the firmware. 00:10:46.875-->00:10:53.792 Of course binwalk. Um no problems here. Um uncompressed into a 30 megabyte binary uh 00:10:53.792-->00:10:58.792 well things are going good I thought. But- no. Every reverse engineer knows that when you 00:11:03.750-->00:11:08.750 open up IDA Pro, and it show this tiny thin column, you're doing something wrong. IDA did 00:11:11.208-->00:11:18.042 not recognize it, of course it didn't. But jokes aside, um this um firmware if PowerPC 32 bit. 00:11:18.042-->00:11:23.042 It's easily, you can look it up in Google uh that Cisco Switches are running PowerPC. It's no big 00:11:26.583-->00:11:33.000 secret and the entry point, the actual address of the firmware to be loaded is um uh thirty 00:11:33.000-->00:11:38.000 hundred in HEX and you can see that uh doing the switch startup. Since I didn't uh see 00:11:40.667-->00:11:45.667 any code whatsoever uh when I fired up my item. Um there's actually a very nice script by a 00:11:48.708-->00:11:54.625 guy names Frederico and he created a script for IDA that automatically recognizes all the 00:11:54.625-->00:12:01.208 functions um and it's actually cross platform. So if you have like one or two functions 00:12:01.208-->00:12:06.000 already recognized manually it just switches through all the code and recognizes the other 00:12:06.000-->00:12:11.417 one with the same prolog. So it looks something like that. You just specified the most common 00:12:11.417-->00:12:18.250 prolog for a function and we'll just loop and discover the function. So this help me to 00:12:18.250-->00:12:24.833 discover like 90 or 97 percent of all the function which was enough. Well of course, um 00:12:24.833-->00:12:29.833 firmware, there are no symbols whatsoever. Um and uh Cisco IOS Operating System is basically uh 00:12:34.458-->00:12:39.458 single binary uh even when you're looking through the code. It's kind of difficult, kind of 00:12:41.583-->00:12:45.958 difficult to follow because lots of the places where the functions are called 00:12:45.958-->00:12:50.958 indirectly.Uh the call tables are filled with run time doesn't make it easy to follow the 00:12:53.917-->00:12:58.917 control flow uh in static. So of course uh since we are have problems with static analysis we 00:13:01.708-->00:13:06.500 have to set up a debug environment uh and there are some problems with that. First 00:13:06.500-->00:13:11.500 of all, of course there is no um development kit for Cisco. Um although, although, the switch 00:13:14.625-->00:13:19.625 itself has a GDB kernel command, which is um actually a GDB Server with a slightly uh 00:13:22.750-->00:13:27.750 customized protocol so the problem is the new GDB client versions uh do not support this. 00:13:31.208-->00:13:36.917 There is an manual on the internet how to build an old version of GDB uh for it work 00:13:36.917-->00:13:41.917 with the uh Cisco, Router or Switch. Another option is to use the debugger created by NCC 00:13:44.792-->00:13:51.500 Group called IODIDE. Uh it's- it]s pretty good. And uh some people who actually build an uh 00:13:51.500-->00:13:56.500 IDA adapter for to debug IOS but I didn't find it in public so I started out with GDB. I opened 00:14:00.375-->00:14:05.375 the manual and patched it so what did I get? Well, [laughs] almost nothing. I was able to 00:14:08.083-->00:14:13.083 read uh and write um get memory on the switch but that's all. I wasn't able to run uh the 00:14:15.500-->00:14:22.208 firmware, I wasn't able to put a break point anywhere. So guys, I resorted to the less possible 00:14:22.208-->00:14:29.167 option. IODIDE. [Laughter] It was kind of in the smooth experience you know. Uh, 00:14:29.167-->00:14:34.000 [laughs] uh this uh, this uh debugger i think it was built for some um [inaudible] narrow 00:14:34.000-->00:14:39.000 uh models of routers. It had some user line code that uh requested information from the 00:14:41.042-->00:14:46.042 router like process list and um the router configuration the switches output different uh . 00:14:48.750-->00:14:53.750 um different formats. So the uh the debug- debugger was crushing all the time and I had to um 00:14:57.708-->00:15:03.583 really debug it and uh cut out lots of userland functionality to get it working but 00:15:03.583-->00:15:09.875 nonetheless it did work for uh debugging the kernel of IOS. Not to long a guy. uh not too long 00:15:09.875-->00:15:16.792 ago, like couple of weeks ago. I stumbled upon this pic comparing Windows Debugger and OllyDBG 00:15:16.792-->00:15:21.792 debugger well this how I felt when I was debugging using IODIDE. [Laughter] You know-but 00:15:24.625-->00:15:29.625 you know, hat's off to NTC Group, this is still the best tool available to debug IOS. So- 00:15:32.000-->00:15:37.000 So now to that actual meat of presentation. The actual vulnerability. Um that uh Cisco 00:15:39.292-->00:15:45.833 Systems encountered. And I started with uh looking for stings in the firmware. They 00:15:45.833-->00:15:50.833 were all recognized and was easy to get them. And um 'member that string in the dump and also in 00:15:54.250-->00:16:00.500 the failed output uh the Vault 7 leak. This is it, I started with it. So I got some 00:16:00.500-->00:16:05.500 cross-references um to the string and it lead me to one particular interesting uh 00:16:07.708-->00:16:14.417 function which is uh I call it called Cisco Kits. And it was uh actually uh a really um doing 00:16:14.417-->00:16:20.583 what it was doing is it was parsing this um custom um magic string and there was a 00:16:20.583-->00:16:25.583 vulnerability in it. And because the Telnet code is rather magical the code for uh parsing 00:16:28.208-->00:16:33.208 um uh for sending the string and the code for parsing the string was uh really near and uh held a 00:16:35.542-->00:16:40.542 lot so- Uh this might be a little bit difficult to process but this is the client portion 00:16:44.375-->00:16:50.250 that sends this magic Telnet option and we can. we can see that it is managed by a format 00:16:50.250-->00:16:55.250 string. Um which is some byte. The string than a byte then an integer then we get another 00:16:58.417-->00:17:05.250 string between the two columns and we get um integer. Matches perfectly, the string I was uh 00:17:05.250-->00:17:12.250 looking at uh in the Wireshark. So uh let's look at the code that actually receives this 00:17:12.250-->00:17:17.250 magic option and parse this. Um-I stumbled upon this code. So it basically reads the first 00:17:21.708-->00:17:26.708 byte, reads the integer, reads the Cisco Kit string, and then it reads the string that is 00:17:29.167-->00:17:33.750 between-between the columns. And funny enough that no bound. boundary check that no length 00:17:33.750-->00:17:38.750 change whatsoever, and its just read until the next column. Guys, what does this look like? 00:17:41.250-->00:17:46.250 To me it sounded like a classic overflow. So- [Laughter] So I had an overflow, it's uh an 00:17:50.875-->00:17:57.500 absolutely classic one. Um instead of sending an empty string between the two um 00:17:57.500-->00:18:02.500 columns. I you know, wrote some capitals A's because capitals A mean business. [Laughs] And we 00:18:05.250-->00:18:11.458 can see at the bottom of the slide, that the power countering pro. uh program counter is um 00:18:11.458-->00:18:17.542 actually like a EIP for intel platforms. It's um instruction parameters. We can see capital 00:18:17.542-->00:18:22.542 A's in that so uh we now are in control of program counter. This is how our flow looked in uh 00:18:26.250-->00:18:31.917 debugger. We see that uh stack is overflowing with uh the capital A's. The and um we see 00:18:31.917-->00:18:36.917 that um the current instruct uh instruction is BLR. Which is a Power PC for branch to link 00:18:39.667-->00:18:44.667 register and um what it does it is checks the link register, which is you can see is 41, 41, 00:18:47.250-->00:18:52.250 41, 41. And branches to it so it jumps right to um the data we had sent to the switch. The 00:18:56.333-->00:19:01.333 stack so the Power PC stack frame is kind of the same as intel in a way we have uh local 00:19:04.958-->00:19:09.958 variables um up above the return address. So if one of the local variables is a buffer, and uh 00:19:12.333-->00:19:19.292 the boundaries are not checked we of course we have uh we have a problem. Execution will be 00:19:19.292-->00:19:26.250 controlled by user supplied input so now what do we do after we you know send some capital 00:19:26.250-->00:19:32.833 A's. Of course we generate some cycle pattern. Cyclic pattern is a way to determine the exact 00:19:32.833-->00:19:37.833 location where we actually overflow the program counter um it works in a way that uh every 00:19:40.292-->00:19:45.958 four bytes in a buffer are unique so when you do uh overflow with Cyclic pattern you 00:19:45.958-->00:19:51.583 just read the uh contents of program counter. You fit it up to a special method that 00:19:51.583-->00:19:56.583 recognizes uh this tiny four byte portion of uh buffer. And uh this method gets to the 00:19:58.792-->00:20:03.792 offset of the buffer that overflows Power Count. I use pwn tools for this. This is a great 00:20:06.375-->00:20:11.500 framework for pwning stuff and also has the ability to generate cyclic patterns so it works kind 00:20:11.500-->00:20:18.333 of like this. You just generate the string for about two hundred symbols um you create a payload 00:20:18.333-->00:20:23.333 uh with a magic Telnet option. You send it and again with the switch crashed. I observed the 00:20:28.208-->00:20:33.208 value D 8 to AD and ask you which is uh you see how it is in hex. You just fit. fit this up 00:20:37.292-->00:20:43.500 to the cyclic uh find method and we get the actual program counter is overflown at offset 00:20:43.500-->00:20:48.500 at one- one hundred and fifty. Alright and guys this really looked um too easy because 00:20:50.833-->00:20:55.833 actually R9 so the Power PC has um thirty. thirty one uh general purpose registered and the R9 00:20:59.458-->00:21:05.833 register at the time of overflow was pointing at our buffers so it was it looked too easy. So we 00:21:05.833-->00:21:10.833 just have to put our shellcode and address pointing by R9 and uh no bad shells were in place 00:21:12.958-->00:21:17.958 whatsoever. Okay then. Uh here's a screenshot from uh IODIDE so you see the R9 um see the R9 00:21:22.875-->00:21:27.875 register be in uh pointing to our buffer. So we have to find uh gadget in memory that just 00:21:31.708-->00:21:36.708 jumps to R9 and it is here in the screen. So it's kind of easy. You just load the R9 00:21:40.042-->00:21:44.708 register to a special CTR uh register the second instruction is garbage we don't need it. And 00:21:44.708-->00:21:49.708 then we branch to CTR uh register so this way we just jump to uh R9. Um what could 00:21:51.875-->00:21:56.875 possibly go wrong? You know, jump into shellcode is always fun- but no. Um access exception 00:21:59.750-->00:22:04.750 again so I failed again. The device actually rebooted. Um I don't know why, I don't know 00:22:07.125-->00:22:13.417 why. So it seemed to me that heap and the stack were not executable. Why did that happen? 00:22:13.417-->00:22:18.417 Is this actually uh the data execution prevention? Honestly guys I still don't know but 00:22:20.708-->00:22:26.333 there's been uh talks on uh on this matter before and one of them was really good at Black 00:22:26.333-->00:22:31.333 Hat uh not so long ago by a Felix FX and he actually suggested that uh this might 00:22:34.792-->00:22:39.792 happen because uh of um instruction and data caching in Power PC. Uh here's a slide from 00:22:43.042-->00:22:49.708 his presentation. Power PC has a cache for data and instruction so what happens when we write 00:22:49.708-->00:22:55.875 some data to stack or heap actually and uh and then transfer execution control of 00:22:55.875-->00:23:00.875 this data. Um. When we transfer the execution control data to uh this data there's actually no 00:23:03.208-->00:23:08.208 data there, because the data we just wrote is in the cache so this uh might be the reason it 00:23:10.292-->00:23:15.292 is not working. So in the end, we are not be able to execute co.code so what do we do? Our 00:23:18.750-->00:23:25.208 last resort is return oriented programming of course. [Laughs] Uh what is it? It is. its a 00:23:25.208-->00:23:30.208 generic technique used in uh exploitation to uh bypass uh data execution privation. In our 00:23:32.208-->00:23:37.208 case its a way to bypass instruction and data caching and it works um this way. We. we 00:23:42.125-->00:23:47.125 don't write our own code um to stack or heap we are reusing the code in the binary or in my 00:23:49.667-->00:23:54.667 cache in the firmware. We use uh this stack as a source of data for those instructions and we um 00:23:58.625-->00:24:03.625 we chain this little snippets of code in uh in such a way so that we can uh perform uh our needed 00:24:06.958-->00:24:12.958 actions. And those might be either uh let's say arbitrary reads, arbitrary rights. and 00:24:12.958-->00:24:17.958 then when we're done we are transferring the con. uh execution control flow back uh 00:24:20.667-->00:24:25.667 to the to the original function. So um the each gadget, each candidate gadget has uh to me at 00:24:28.375-->00:24:34.958 least two conditions. So it must execute some payload, either read or write. Uh and also it 00:24:34.958-->00:24:39.958 has to have some code that is transferring IDA's execution flow to the next gadget. And uh 00:24:43.125-->00:24:48.833 there is some limitation to this approach. Uh only of course you are as good as the number of 00:24:48.833-->00:24:55.042 gadgets uh in firmware, and there's a limited set of them. And uh when you're actually 00:24:55.042-->00:25:00.042 chaining them up. Every gadget is a modifying stack in a way because mostly we use um 00:25:02.917-->00:25:09.042 function uh epilogues as gadgets and they all work with stack. So when they move uh stack around 00:25:09.042-->00:25:14.042 and this might corrupt uh stack frame that is um below your stack frame. Uh and this is 00:25:16.458-->00:25:21.458 tricky and creates problems. We can accomplish um basically two things with returned oriented. 00:25:23.750-->00:25:28.750 Uh either arbitrary rights and this might lead to arbitrary code execution. So my idea was 00:25:32.292-->00:25:37.292 uh- um to create an arbitrary memory right primitive. The idea is really quite simple. m we 00:25:41.208-->00:25:46.208 have a find. uh we find a code snippet uh in the firmware uh that takes value from, two 00:25:49.833-->00:25:54.833 values from this deck. One value is um is the memory address uh we want to write to. And the 00:25:57.958-->00:26:02.958 other uh value is the actual value that we're writing. Uh so for example um we load uh memory 00:26:08.875-->00:26:13.875 address at register R 30 and the value to register R 31 and then we uh we chain to the next 00:26:19.917-->00:26:24.917 gadget. Which actually preforms the right. So- yeah we've been talking about it already. So a 00:26:28.375-->00:26:33.375 typical gadget looks like this. It's uh function epilogue it does stuff with uh data on stack 00:26:36.333-->00:26:41.333 and then it uh jumps. So the LWZ uh opcodes are floating data and the last opcode BLR is actually 00:26:45.542-->00:26:50.542 to jump um out of the function. So I'm gonna be talking about the right primitives uh that I 00:26:54.125-->00:27:00.792 used to actually get uh this exploit working. This is actual gadget I'm using in the original 00:27:00.792-->00:27:07.333 proof of concept that I released not too long ago. Uh so first and foremost uh with the gadget 00:27:07.333-->00:27:12.333 we have to set up um our um address of the next gadget. So we do this by loading data from 00:27:15.625-->00:27:22.500 stacked reg to R zero then by loading the r zero register in to the link register. And you 00:27:22.500-->00:27:28.750 remember I told you that the link register is used for branching. Next thing we do is 00:27:28.750-->00:27:33.750 we load the address we want to write from uh from the stack and stack is pointed by a register 00:27:36.750-->00:27:41.750 R1 in Power PC. We load this into R30, we load the actual value to R31 uh side effect from 00:27:45.750-->00:27:52.667 gadget like this it moves a stack bit like uh ten in hex and then we range to the value we 00:27:52.667-->00:27:59.292 put in R zero. That's it we have two registers with an address valued right and we [inaudible] 00:27:59.292-->00:28:04.292 we chain to the second gadget. Which is uh uses up code stored value it it writes the value of 00:28:09.083-->00:28:14.083 R31 to R30. And this. this is our basic right primitive it consists of two gadgets, um the 00:28:19.167-->00:28:24.250 loading and the writing. And the result is we just wrote arbitrary data to arbitrary 00:28:24.250-->00:28:29.250 address. it is easier to do this with um automatic tools this uh ropper tool is really good uh it 00:28:32.333-->00:28:38.292 kind of semi-automates uh the process of building uh gadgets uh you can look up you can load 00:28:38.292-->00:28:43.292 uh binary of firmware in it. And uh look for gadgets uh with uh search and wildcards. Okay, so 00:28:48.417-->00:28:53.417 we have um, basically have the ability to write arbitrary data into the firmware. How do we get 00:28:55.500-->00:29:00.500 code execution from it. Uh the plan is to find some place in some uh critical place in uh the 00:29:04.500-->00:29:09.333 firmware uh which we can patch and will result in code execution. So you can patch the 00:29:09.333-->00:29:14.333 control flow and actually uh checks uh the credentials. You can um patch some uh Telnet uh 00:29:17.208-->00:29:23.375 inter-structs that are used for authentication or you might look for some function pointers that 00:29:23.375-->00:29:28.375 uh return uh critical data related to uh authenticating you on the switch. Well I thought 00:29:30.500-->00:29:35.500 why not patch the execution flow so looking further down the code, um, where the switch is um 00:29:39.958-->00:29:46.958 authenticating you I just decided to patch this "IF" branch. well uh instead of if 00:29:46.958-->00:29:53.583 and all those conditions, I uh just put it like uh if true, and guys it looks like it work but 00:29:53.583-->00:30:00.333 now again, this only worked on the debugger. [Laughs] The exception was triggered uh 00:30:00.333-->00:30:05.333 during the live set up and uh. you know. [Laughter] I was kind of desperate at that moment. Uh 00:30:09.500-->00:30:14.500 I kept on looking and a couple of I'd say days you know. Uh I was looking at this code and 00:30:18.833-->00:30:25.000 something you know uh cached. And uh lots of code on this slide what's interesting is the 00:30:25.000-->00:30:30.000 first the line which is a indirect call for function that I named uh is cluster mode. And 00:30:33.083-->00:30:38.083 uh It's indirect so it means it's not called directly it's being reference by a memory 00:30:40.708-->00:30:47.625 location and this memory location has the actual address of the function. So um the 00:30:47.625-->00:30:51.750 second interesting thing is that there was there was another function on the code that was 00:30:51.750-->00:30:56.750 called indirectly. And it was called get privilege level. Uh also was ref.reference by uh 00:31:00.625-->00:31:05.625 memory location. So uh long story short uh, both of this functions are referenced 00:31:10.250-->00:31:15.250 indirectly. And we can apply uh right primitives to them to change this memory location by. 00:31:17.375-->00:31:22.375 but the question is why are this functions uh important? And they are important because uh if uh 00:31:25.167-->00:31:30.167 the function uh is cluster mode returns something that uh is not uh zero, then we go down the 00:31:32.833-->00:31:38.542 branch which checks your privilege level. And that is the only check you need to get a 00:31:38.542-->00:31:43.542 privilege 15 shell in IOS. So if we patch this cluster mode with uh a nonzero and then we patch 00:31:48.750-->00:31:53.750 and uh the pointer to get to level with the function that always returns 15 we can see 00:31:57.250-->00:32:02.250 here as the Power PC snippet if our privilege level is uh not minus one we are just presented 00:32:05.500-->00:32:10.500 with a shell. Okay so, easy enough. Um, we will actually take uh this pointer uh pop up 00:32:19.958-->00:32:25.750 IDA Pro, look for a function that returns something that is a non zero, one, fifteen, doesn't 00:32:25.750-->00:32:32.542 matter. We will take uh get privilege level uh pointer of written with a function that 00:32:32.542-->00:32:37.542 always returns 15. Um the firmware actually had-had those functions. So it was pretty easy 00:32:40.375-->00:32:45.375 to find. And uh all we have to do now is to uh find suitable gadgets to make the necessary 00:32:50.458-->00:32:56.750 rights. So the first gadgets I was already talking about it. Uh it was just loading up 00:32:56.750-->00:33:01.750 information uh I mean uh data from stack. We take the pointer to it's cluster mode function. 00:33:06.625-->00:33:12.458 We take the value we want to override it with that is the address function that always 00:33:12.458-->00:33:17.458 returns one. Uh we add to stack pointer and we make a branch to the next gadget. Uh the address 00:33:22.250-->00:33:27.250 for this gadget we already set up uh during the first two op codes that you see. So loading 00:33:30.667-->00:33:35.667 the R zero register and loading to the R zero to link register. Second gadget does the right. Uh 00:33:38.292-->00:33:43.292 so the first op code uh gets to registers uh gets R30 and gets R31, and writes to the location 00:33:48.042-->00:33:54.792 reference by R30. Okay so now we have overwritten this cluster mode it always returns uh a non 00:33:54.792-->00:34:00.917 zero value so we go down the branch that uh checks the privilege. It's kind of more 00:34:00.917-->00:34:05.917 tricky with the second write because uh it actually needs to do the reference. But guys um- 00:34:10.292-->00:34:16.875 this did work and finally, finally. I was presented with the level 15 uh IOS shell on the 00:34:16.875-->00:34:21.875 switch. [Applause] Now, you know that it's demo time. I hope the. I'll check if the inter. 00:34:36.958-->00:34:41.958 internet works, if not I'll just uh show you the video. [Humming] I hope I can do. [Humming] 00:35:03.792-->00:35:09.958 That's actually. a SSH connection to my laptop, so that's uh not too fast but I 00:35:09.958-->00:35:14.958 can't really see what I'm doing but I can try. So- Eight, one ten. So yeah, we have a Cisco 00:35:25.167-->00:35:30.167 Switch on uh on this IP address. And uh we can actually see that um there's the password prompt 00:35:32.417-->00:35:37.417 right? We type in some basic stuff like Cisco, Cisco it doesn't work. Alright so to the 00:35:44.583-->00:35:49.583 exploit itself. [Typing] Can't really see what I'm typing. [Cough] Alright, it's good. So 00:35:58.667-->00:36:03.667 the option uh. [Laughter] Options are pretty easy so you just uh specify the host. And 00:36:11.250-->00:36:16.250 you set- I'm not sure if it worked because there's some problems with timings but we'll 00:36:18.750-->00:36:23.750 check. Alright, is there a shell? Yes, there is. [Applause] So you can actually see the 00:36:39.208-->00:36:44.208 version the firmware, you can also see that uh we have uh. [grunt] Shell proof right? Yeah, 00:36:49.208-->00:36:54.208 we have uh. [inaudible] privilege 15 shell. So what's great about this exploit is that 00:36:57.417-->00:37:02.417 we can easily unset this. So instead of set we just go with the let's see. uh two dashes, I 00:37:05.583-->00:37:10.583 don't see. >>Yes >>Okay. We go with unset and uh yes. It goes back to its original state. 00:37:26.000-->00:37:31.000 [Cheering] Alright back to the- well it's good demo Gods were happy with me so. [laughter] 00:37:33.625-->00:37:38.625 Yeah, so that's the video I made it. So side note,I do pentest a lot. So I’ve encountered uh many 00:37:43.708-->00:37:49.917 of those switches on Pentesting and successfully exploited uh several of them and what helps 00:37:49.917-->00:37:54.917 with this. This uh exploit is actually um very firmware specific because offsets are 00:37:57.000-->00:38:03.500 different from firmware to firmware and what helps is to determine the version is two is 00:38:03.500-->00:38:08.500 two protocols. SNMP and CDP. SNMP, if you guess if you guess Public, or uh private string. Uh 00:38:11.833-->00:38:17.875 you are able to dumb the firmware version. That helps you to develop or customize the 00:38:17.875-->00:38:22.875 exploit. Or if you are in the same L2 uh physical uh broadcast network as the switch uh you can 00:38:26.083-->00:38:32.833 listen for CDP requests. They also uh give information about the version of this uh switch. 00:38:32.833-->00:38:39.375 So this helps a lot. So in a manner of like one or two hours you can find uh you can 00:38:39.375-->00:38:46.292 customize the shell on the. on the switch. So about further research, of course uh I managed 00:38:46.292-->00:38:51.292 to do only arbitrary rights uh on this switch. It would be good to be able to run an arbitrary 00:38:54.417-->00:39:01.333 run code instead of- instead of just modifying memory. Um and also it would be really good to 00:39:01.333-->00:39:06.042 actually out made the process of building rob gadgets because it's kind of a tedious process 00:39:06.042-->00:39:11.042 and you know the first time it's fun but not so much when you do like tenth time. And again, um I 00:39:15.833-->00:39:22.458 just thought about like a week ago. What if uh we know like switches are clust-are using 00:39:22.458-->00:39:29.125 clustering, uh via the CDP protocol and uh I am almost sure but not 100 percent sure that 00:39:29.125-->00:39:34.000 there is no authentication in place when they're sending this Telnet to clustering between 00:39:34.000-->00:39:39.417 them and we also know the master switch can easily get um privilege 15 shell on the slave 00:39:39.417-->00:39:44.417 switch. But what if we are in the same broadcast uh uh segment and we just build a CDP packet 00:39:47.250-->00:39:51.500 that uh tells uh the other switches that we are a switch and then we craft a and layer 00:39:51.500-->00:39:58.375 two Telnet connection requesting a privilege 15 shell with R command. What would happen? Well 00:39:58.375-->00:40:03.375 this would remains to be- uh remains to be seen. Uh working on it, it's an ongoing research, 00:40:05.583-->00:40:10.583 and um you know, stuff to think for you guys. Thank you so much for your time. [Applause] You 00:40:27.792-->00:40:30.542 can check the proof of concept code uh on Github. Um contributions of course are 00:40:30.542-->00:40:31.667 welcome. Thank you so much. [Applause]