[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:15.06,Default,,0000,0000,0000,,{\i1}34c3 intro{\i0}
Dialogue: 0,0:00:15.06,0:00:30.13,Default,,0000,0000,0000,,Herald: All right, next lecture here is\Nfrom Artem. Next to the fact that these,
Dialogue: 0,0:00:30.13,0:00:38.82,Default,,0000,0000,0000,,how would I spell it, earning a nice\Namount of money probably at a lab that's
Dialogue: 0,0:00:38.82,0:00:46.59,Default,,0000,0000,0000,,quite renown in the world as Kaspersky and\Nfrom that point on he's not just looking
Dialogue: 0,0:00:46.59,0:00:52.54,Default,,0000,0000,0000,,in this lecture to exploit a development\Nfor Cisco stuff we all suffered from this
Dialogue: 0,0:00:52.54,0:00:57.61,Default,,0000,0000,0000,,last year or we all heard about it and\Ndon't know the impact maybe, but he's
Dialogue: 0,0:00:57.61,0:01:05.02,Default,,0000,0000,0000,,going to explain us the work he did on\Nthat field so please can I ask your warm
Dialogue: 0,0:01:05.02,0:01:14.30,Default,,0000,0000,0000,,welcoming applause for Artem Kondratenko,\Ndo you, okay good, please give him a warm
Dialogue: 0,0:01:14.30,0:01:21.96,Default,,0000,0000,0000,,applause and start.\N{\i1}applause{\i0}
Dialogue: 0,0:01:21.96,0:01:26.15,Default,,0000,0000,0000,,Artem Kondratenko: Hello everyone, so\Nexcited to finally be able to attend Chaos
Dialogue: 0,0:01:26.15,0:01:31.88,Default,,0000,0000,0000,,Communication Congress. Very happy to see\Ny'all. So without further ado let's jump
Dialogue: 0,0:01:31.88,0:01:38.23,Default,,0000,0000,0000,,into some practical IOS exploitation. So a\Nfew words about myself, my name is Artem,
Dialogue: 0,0:01:38.23,0:01:43.66,Default,,0000,0000,0000,,I do stuff, mostly security related stuff\Nbut mostly my areas of expertise are
Dialogue: 0,0:01:43.66,0:01:48.87,Default,,0000,0000,0000,,penetration tests, both internal external\Nand also do research in my free time and
Dialogue: 0,0:01:48.87,0:01:54.29,Default,,0000,0000,0000,,get a bug bounty here and there and this\Ntalk is actually kind of a continuation of
Dialogue: 0,0:01:54.29,0:01:59.73,Default,,0000,0000,0000,,my talk this summer at Def Con about Cisco\NCatalyst exploitation.
Dialogue: 0,0:01:59.73,0:02:04.60,Default,,0000,0000,0000,,So for those of you who are out of\Ncontext, let's recap what happened earlier
Dialogue: 0,0:02:04.60,0:02:14.45,Default,,0000,0000,0000,,this year. So year 2017 was reaching\Nvulnerabilities for Cisco IOS devices. So
Dialogue: 0,0:02:14.45,0:02:20.14,Default,,0000,0000,0000,,we had at least three major advisories for\NCisco IOS that represented three remote
Dialogue: 0,0:02:20.14,0:02:24.28,Default,,0000,0000,0000,,code execution vulnerabilities.\NSo the first one is vulnerability in
Dialogue: 0,0:02:24.28,0:02:30.60,Default,,0000,0000,0000,,cluster management protocol which resulted\Nin unauthenticated remote code
Dialogue: 0,0:02:30.60,0:02:36.56,Default,,0000,0000,0000,,execution via telnet, second one is SNMP\Noverflow and the DHCP remote code
Dialogue: 0,0:02:36.56,0:02:40.31,Default,,0000,0000,0000,,execution.\NIn this lecture I'm gonna be talking
Dialogue: 0,0:02:40.31,0:02:47.06,Default,,0000,0000,0000,,about two of those vulnerabilities because\NDHCP RCE is yet to be researched. So
Dialogue: 0,0:02:47.06,0:02:51.88,Default,,0000,0000,0000,,hopefully by the end of this talk I'm\Ngoing to be able to show you a live demo
Dialogue: 0,0:02:51.88,0:02:56.81,Default,,0000,0000,0000,,of exploiting the SNMP service in Cisco\NIOS.
Dialogue: 0,0:02:56.81,0:03:05.87,Default,,0000,0000,0000,,So but first what happened earlier: So on\NMarch 26, 2017 we had a major advisory from
Dialogue: 0,0:03:05.87,0:03:10.79,Default,,0000,0000,0000,,Cisco that announcing that hundreds of\Nmodels of different switches are
Dialogue: 0,0:03:10.79,0:03:15.23,Default,,0000,0000,0000,,vulnerable to remote code execution\Nvulnerability. No public code, no public
Dialogue: 0,0:03:15.23,0:03:21.07,Default,,0000,0000,0000,,exploit was available and no exploitation\Nin the wild. So it was critical and main
Dialogue: 0,0:03:21.07,0:03:24.38,Default,,0000,0000,0000,,points of the vulnerability were as\Nfollow:
Dialogue: 0,0:03:24.38,0:03:30.97,Default,,0000,0000,0000,,So Cisco switches can be clustered, and\Nthere's a cluster management protocol
Dialogue: 0,0:03:30.97,0:03:36.43,Default,,0000,0000,0000,,built on top of telnet, and this\Nvulnerability is a result of actually two
Dialogue: 0,0:03:36.43,0:03:43.88,Default,,0000,0000,0000,,errors, a logic error and a binary error.\NSo the telnet options get parsed
Dialogue: 0,0:03:43.88,0:03:49.94,Default,,0000,0000,0000,,regardless whether the switch is in\Ncluster mode or not and the incorrect
Dialogue: 0,0:03:49.94,0:03:56.56,Default,,0000,0000,0000,,processing of this cluster management\Nprotocol options result in overflow. So
Dialogue: 0,0:03:56.56,0:04:00.98,Default,,0000,0000,0000,,what is interesting about this\Nvulnerability that actually the source of
Dialogue: 0,0:04:00.98,0:04:06.01,Default,,0000,0000,0000,,research for Cisco guys was another\Ninternal research. But the "Vault 7" leak
Dialogue: 0,0:04:06.01,0:04:13.21,Default,,0000,0000,0000,,that happened in March this year so many\Nhacking techniques and tools were released
Dialogue: 0,0:04:13.21,0:04:20.44,Default,,0000,0000,0000,,to public by WikiLeaks, and among many\Nvendors that were affected was Cisco
Dialogue: 0,0:04:20.44,0:04:25.09,Default,,0000,0000,0000,,Systems.\NSo basically except for the advisory you
Dialogue: 0,0:04:25.09,0:04:30.24,Default,,0000,0000,0000,,could go to WikiLeaks and read about this\Npotential exploitation technique for Cisco
Dialogue: 0,0:04:30.24,0:04:35.49,Default,,0000,0000,0000,,Catalyst. So basically these were notes of\Nan engineer who was testing the actual
Dialogue: 0,0:04:35.49,0:04:43.75,Default,,0000,0000,0000,,exploit, there were no actual exploit in\Nthe leak. So basically this worked as
Dialogue: 0,0:04:43.75,0:04:49.21,Default,,0000,0000,0000,,follows: there was two modes of\Ninteraction, so for example an attacker
Dialogue: 0,0:04:49.21,0:04:55.33,Default,,0000,0000,0000,,could connect to the telnet, overflow the\Nservice and be presented with a privileged
Dialogue: 0,0:04:55.33,0:05:02.86,Default,,0000,0000,0000,,15 shell. The other mode of operation was\Nthe … is to set for all the subsequent
Dialogue: 0,0:05:02.86,0:05:08.79,Default,,0000,0000,0000,,… connections to the telnet, there\Nwill be … without credentials so I
Dialogue: 0,0:05:08.79,0:05:14.62,Default,,0000,0000,0000,,did. We discover this exploit, full\Nresearch was presented at DEFCON 25. I was
Dialogue: 0,0:05:14.62,0:05:20.62,Default,,0000,0000,0000,,targeting system catalyst 2960 as a target\Nswitch. I also described a PowerPC
Dialogue: 0,0:05:20.62,0:05:25.34,Default,,0000,0000,0000,,platform exploitation and the way you can\Ndebug it.
Dialogue: 0,0:05:25.34,0:05:31.43,Default,,0000,0000,0000,,You can look at my blog post about\Nexploiting this service, and also the
Dialogue: 0,0:05:31.43,0:05:37.53,Default,,0000,0000,0000,,proof accounts of exploit on my github\Npage. But today I want to talk about
Dialogue: 0,0:05:37.53,0:05:42.20,Default,,0000,0000,0000,,something else, about another\Nvulnerability that was announced this year
Dialogue: 0,0:05:42.20,0:05:49.49,Default,,0000,0000,0000,,about SNMP remote code execution.\NSo the actual motivation behind this
Dialogue: 0,0:05:49.49,0:05:55.84,Default,,0000,0000,0000,,research was that I was conducting an\Nexternal pentest, and it was revealed an
Dialogue: 0,0:05:55.84,0:06:00.51,Default,,0000,0000,0000,,nmap scan revealed that a Cisco router\Nwhere the default community string was
Dialogue: 0,0:06:00.51,0:06:07.09,Default,,0000,0000,0000,,available. So the goal was to get access\Nto the internal network.
Dialogue: 0,0:06:07.09,0:06:13.45,Default,,0000,0000,0000,,So the actual advisory said that the\Nattacker needs a read-only community
Dialogue: 0,0:06:13.45,0:06:19.70,Default,,0000,0000,0000,,string to gain remote code execution on\Nthe device. The target router was a 2800
Dialogue: 0,0:06:19.70,0:06:26.65,Default,,0000,0000,0000,,integrated services router, which is a\Nvery common device on the networks.
Dialogue: 0,0:06:26.65,0:06:34.39,Default,,0000,0000,0000,,So the technical specs for it is it's a\Nit has a MIPS big endian architecture, you
Dialogue: 0,0:06:34.39,0:06:39.99,Default,,0000,0000,0000,,don't have any client debugging tools for\Nit available, and it's interesting in that
Dialogue: 0,0:06:39.99,0:06:46.92,Default,,0000,0000,0000,,sense that the firmware is relatively new\Nfor this router, and it might be
Dialogue: 0,0:06:46.92,0:06:52.77,Default,,0000,0000,0000,,interesting to look at the defensive end\Nexploit prevention mechanisms employed by
Dialogue: 0,0:06:52.77,0:06:59.37,Default,,0000,0000,0000,,Cisco IOS. When I say relatively new is\Nthe interesting thing is that this device
Dialogue: 0,0:06:59.37,0:07:04.04,Default,,0000,0000,0000,,is actually end of support, it's not\Nsupported. So the last patch for it was
Dialogue: 0,0:07:04.04,0:07:12.36,Default,,0000,0000,0000,,came out at 2016, and to remind you the\Nadvisory for SNMP overflow appeared in
Dialogue: 0,0:07:12.36,0:07:19.04,Default,,0000,0000,0000,,2017, in June 2017, but nonetheless this\Nis still widely used device.
Dialogue: 0,0:07:19.04,0:07:27.76,Default,,0000,0000,0000,,If you search for SNMP banner on Shodan,\Nyou will find at least 3000 devices with
Dialogue: 0,0:07:27.76,0:07:37.55,Default,,0000,0000,0000,,SNMP service available with default public\Nstring. So this devices are all supposedly
Dialogue: 0,0:07:37.55,0:07:43.71,Default,,0000,0000,0000,,vulnerable to SNMP overflow. And the\Nquestion is whether we can build a mount
Dialogue: 0,0:07:43.71,0:07:49.14,Default,,0000,0000,0000,,code execution exploit for it. So since\Nwe're going to be exploiting SME protocol,
Dialogue: 0,0:07:49.14,0:07:54.46,Default,,0000,0000,0000,,let's make a quick quick recap of how it\Nworks, just light touch.
Dialogue: 0,0:07:54.46,0:08:01.93,Default,,0000,0000,0000,,So SNMP comes with several abbreviations\Nlike MIB, which stands for management
Dialogue: 0,0:08:01.93,0:08:07.92,Default,,0000,0000,0000,,information base, and is kind of a\Ncollection of objects that can be
Dialogue: 0,0:08:07.92,0:08:12.86,Default,,0000,0000,0000,,monitored from the SNMP manager. And so a\Nmanagement information base actually
Dialogue: 0,0:08:12.86,0:08:21.37,Default,,0000,0000,0000,,consists of object identifiers. And as an\Nexample: you all know that printers
Dialogue: 0,0:08:21.37,0:08:25.55,Default,,0000,0000,0000,,usually use SNMP, For example if there is\Na certain level of ink in the cartridge,
Dialogue: 0,0:08:25.55,0:08:31.73,Default,,0000,0000,0000,,you can query the SNMP service on this\Ndevice for the percentage of ink left. So
Dialogue: 0,0:08:31.73,0:08:39.18,Default,,0000,0000,0000,,that's a kind of example how it works.\NManagement information base looks like a
Dialogue: 0,0:08:39.18,0:08:42.22,Default,,0000,0000,0000,,tree.\NSo you have your base element at the top
Dialogue: 0,0:08:42.22,0:08:47.84,Default,,0000,0000,0000,,and your leaf elements, So all these\Nelements represent an object that could be
Dialogue: 0,0:08:47.84,0:08:53.51,Default,,0000,0000,0000,,queried. We're going to be looking at get\Nrequests. And that is why the advisory
Dialogue: 0,0:08:53.51,0:08:57.79,Default,,0000,0000,0000,,states that for their vulnerability to be\Ntriggered you only have to know the read-
Dialogue: 0,0:08:57.79,0:09:03.11,Default,,0000,0000,0000,,only community string. So it's a\Nrelatively simple protocol, you just
Dialogue: 0,0:09:03.11,0:09:08.20,Default,,0000,0000,0000,,supply the object identifier you're\Nquerying and you'll get back the result.
Dialogue: 0,0:09:08.20,0:09:14.100,Default,,0000,0000,0000,,So here for example we get the router\Nversion, the description field. And you
Dialogue: 0,0:09:14.100,0:09:24.17,Default,,0000,0000,0000,,can also do this with a readily available\NLinux tools like snmpget. So before we
Dialogue: 0,0:09:24.17,0:09:28.63,Default,,0000,0000,0000,,will build an exploit, we have a starting\Npoint. So how do we look for for the
Dialogue: 0,0:09:28.63,0:09:35.11,Default,,0000,0000,0000,,crash? So the advisory actually states\Nthat there are nine different vulnerable
Dialogue: 0,0:09:35.11,0:09:41.40,Default,,0000,0000,0000,,management information bases and you only\Nhave to know the read-only community string.
Dialogue: 0,0:09:41.40,0:09:50.09,Default,,0000,0000,0000,,So for the fuzzing to be done I'll be\Nusing Scapy as a tool to as a toolkit to
Dialogue: 0,0:09:50.09,0:09:54.31,Default,,0000,0000,0000,,work with network protocols, and here you\Ncan see that I'm building an object
Dialogue: 0,0:09:54.31,0:09:59.16,Default,,0000,0000,0000,,identifier, a valid object identifier that\Nreferences the description field, and then
Dialogue: 0,0:09:59.16,0:10:04.92,Default,,0000,0000,0000,,I'm appending some letters "a" which is 65\Nin ASCII table. Then I build an IP packet,
Dialogue: 0,0:10:04.92,0:10:12.15,Default,,0000,0000,0000,,I build a UDP packet and an SNMP packet\Ninside of it with community string public
Dialogue: 0,0:10:12.15,0:10:17.32,Default,,0000,0000,0000,,and object identifier.\NSo of course this will not trigger the
Dialogue: 0,0:10:17.32,0:10:23.59,Default,,0000,0000,0000,,overflow, because this object identifier\Nis completely fine. How do we get all the
Dialogue: 0,0:10:23.59,0:10:28.67,Default,,0000,0000,0000,,object identifiers that our router will\Nrespond to? So basically there are two
Dialogue: 0,0:10:28.67,0:10:36.23,Default,,0000,0000,0000,,ways: you can take the firmware and just\Nextract all the OIDs from it. It's easy to
Dialogue: 0,0:10:36.23,0:10:43.67,Default,,0000,0000,0000,,grab them, they're stored in plain text.\NAnother way is to actually look at the
Dialogue: 0,0:10:43.67,0:10:52.40,Default,,0000,0000,0000,,vulnerable MIBs and visit the website OID\Nviews and get all object identifiers from
Dialogue: 0,0:10:52.40,0:10:59.40,Default,,0000,0000,0000,,this website. So as a matter of fact the\Nfirst crash I had was in ciscoAlpsMIB,
Dialogue: 0,0:10:59.40,0:11:08.96,Default,,0000,0000,0000,,which is kind of related to airplane protocol,\Nwhich does not concern us because it's not
Dialogue: 0,0:11:08.96,0:11:16.76,Default,,0000,0000,0000,,a focus of our exploitation.\NSo the actual overflow was in one of its
Dialogue: 0,0:11:16.76,0:11:23.29,Default,,0000,0000,0000,,object identifiers. So this request this I\Nactually crashed the router when you
Dialogue: 0,0:11:23.29,0:11:30.48,Default,,0000,0000,0000,,connect to the Cisco router of via a\Nserial cable you will be and there's a
Dialogue: 0,0:11:30.48,0:11:36.48,Default,,0000,0000,0000,,crash you will be presented with a stack\Ntrace. So we see here that we got a
Dialogue: 0,0:11:36.48,0:11:45.89,Default,,0000,0000,0000,,corrupted program counter, and we also see\Nthe state of registers that we have at the
Dialogue: 0,0:11:45.89,0:11:55.27,Default,,0000,0000,0000,,moment of crash. So here you can see that\Nwe have control of a program counter, it's
Dialogue: 0,0:11:55.27,0:12:04.11,Default,,0000,0000,0000,,called EPC, and also we control the\Ncontents of registers s0, s1, s2, s3, s4,
Dialogue: 0,0:12:04.11,0:12:08.16,Default,,0000,0000,0000,,s5, s6.\NFurther inspection also provided me with
Dialogue: 0,0:12:08.16,0:12:14.96,Default,,0000,0000,0000,,knowledge that we have 60 spare bytes on\Nthe stack to work with. But before we
Dialogue: 0,0:12:14.96,0:12:20.37,Default,,0000,0000,0000,,build we exploit we have some problems,\Nissues to be solved.
Dialogue: 0,0:12:20.37,0:12:26.15,Default,,0000,0000,0000,,And that is: yes, we do control the\Nprogram counter, but where do we jump to?
Dialogue: 0,0:12:26.15,0:12:34.88,Default,,0000,0000,0000,,Is ASLR on? Can we execute shellcode\Ndirectly on the stack? Is stack
Dialogue: 0,0:12:34.88,0:12:42.66,Default,,0000,0000,0000,,executable? If we can place the shellcode\Non it, is data caching a problem for us?
Dialogue: 0,0:12:42.66,0:12:49.18,Default,,0000,0000,0000,,And if we launched our shellcode, can we\Njust bash the code? Is the code section
Dialogue: 0,0:12:49.18,0:12:54.06,Default,,0000,0000,0000,,writable? Is the code integrity check on?\NBut the most important question is: how
Dialogue: 0,0:12:54.06,0:12:59.12,Default,,0000,0000,0000,,can we return the code flow back to the\NSNMP service?
Dialogue: 0,0:12:59.12,0:13:07.93,Default,,0000,0000,0000,,Because IOS is a single binary running in\Nthe memory, and if you have an exception
Dialogue: 0,0:13:07.93,0:13:15.02,Default,,0000,0000,0000,,in any thread of this big binary, the Cisco\Ndevice will crash. And if we look at the
Dialogue: 0,0:13:15.02,0:13:16.83,Default,,0000,0000,0000,,advisory, one of the indicators of
Dialogue: 0,0:13:16.83,0:13:23.13,Default,,0000,0000,0000,,compromised Cisco states is device reload,\Nso exploitation of the vulnerabilities
Dialogue: 0,0:13:23.13,0:13:29.50,Default,,0000,0000,0000,,will cause an affected device to reload.\NWe will build an exploit we'll try to
Dialogue: 0,0:13:29.50,0:13:36.11,Default,,0000,0000,0000,,build an exploit that will not crash the\NSNMP service on it. Before we dive deeper
Dialogue: 0,0:13:36.11,0:13:45.15,Default,,0000,0000,0000,,into the firmware I want to reference\Nprevious researches on this matter. This
Dialogue: 0,0:13:45.15,0:13:53.67,Default,,0000,0000,0000,,is by no means a complete list but these\Nresearchers actually helped me a lot and
Dialogue: 0,0:13:53.67,0:14:00.90,Default,,0000,0000,0000,,seemed interesting and very insightful to\Nme. You should definitely check them out
Dialogue: 0,0:14:00.90,0:14:07.03,Default,,0000,0000,0000,,so for example "Router Exploitation" by\NFelix FX Lindener and "CISCO IOS
Dialogue: 0,0:14:07.03,0:14:12.08,Default,,0000,0000,0000,,SHELLCODE" by George Nosenko is a great\Nresource for IOS internals and great
Dialogue: 0,0:14:12.08,0:14:16.70,Default,,0000,0000,0000,,reference to how IOS works in terms of\Nexploitation
Dialogue: 0,0:14:16.70,0:14:22.50,Default,,0000,0000,0000,,and the third resource "How to cook\NCisco" is a great info on exploiting
Dialogue: 0,0:14:22.50,0:14:29.19,Default,,0000,0000,0000,,PowerPC-based Cisco switches and also\Ngreat info on bypassing common mechanisms
Dialogue: 0,0:14:29.19,0:14:38.13,Default,,0000,0000,0000,,and exploit prevention stuff in IOS. So\Nbasically if I were to tell you how IOS
Dialogue: 0,0:14:38.13,0:14:42.93,Default,,0000,0000,0000,,works in one slide it's basically a single\Nbinary running in memory. Everything is
Dialogue: 0,0:14:42.93,0:14:50.86,Default,,0000,0000,0000,,statically linked into a single ELF file\Nwhich gets loaded on startup, of course
Dialogue: 0,0:14:50.86,0:14:57.72,Default,,0000,0000,0000,,you have no API whatsoever. Everything has\Nno symbols whatsoever. Yes, there is a
Dialogue: 0,0:14:57.72,0:15:03.58,Default,,0000,0000,0000,,glibc library at the end of the firmware\Nbut it's also kind of hard to use it
Dialogue: 0,0:15:03.58,0:15:10.17,Default,,0000,0000,0000,,because you have so many different\Nversions of firmware and the offsets jump
Dialogue: 0,0:15:10.17,0:15:14.31,Default,,0000,0000,0000,,and you don't know the exact location of\Nthose functions. So to start with static
Dialogue: 0,0:15:14.31,0:15:19.21,Default,,0000,0000,0000,,analysis you should probably copy the\Nfirmaware from the flash memory of the
Dialogue: 0,0:15:19.21,0:15:27.59,Default,,0000,0000,0000,,router. Use the copy command, it supports\NTFTP and FTP protocols so you download
Dialogue: 0,0:15:27.59,0:15:32.44,Default,,0000,0000,0000,,this firmware, the next thing you do is\Nunpack the firmware. The firmware itself,
Dialogue: 0,0:15:32.44,0:15:38.95,Default,,0000,0000,0000,,when the router starts loading it, has an\Ninitial stop that does the unpacking but
Dialogue: 0,0:15:38.95,0:15:43.78,Default,,0000,0000,0000,,you don't have to reverse engineer that,\Nyou just use binwalk, that will do the
Dialogue: 0,0:15:43.78,0:15:53.26,Default,,0000,0000,0000,,unpacking for you. You load the result of\Nunpacking with binwalk to IDA Pro, you
Dialogue: 0,0:15:53.26,0:15:58.42,Default,,0000,0000,0000,,have to change the processor type to MIPS\N32 big-endian and we know that this is
Dialogue: 0,0:15:58.42,0:16:05.14,Default,,0000,0000,0000,,MIPS, because we saw the registers. These\Nregisters tell us that it was indeed MIPS
Dialogue: 0,0:16:05.14,0:16:13.04,Default,,0000,0000,0000,,architecture. So one thing I want to note,\Nthe actual firmware gets loaded into
Dialogue: 0,0:16:13.04,0:16:20.52,Default,,0000,0000,0000,,address 800F00 but the program counter is\Nlocated at address 4 and this is because
Dialogue: 0,0:16:20.52,0:16:29.09,Default,,0000,0000,0000,,IOS when it loaded the firmaware\Ntransfers, I mean maps to memory 2400F00
Dialogue: 0,0:16:29.09,0:16:35.12,Default,,0000,0000,0000,,and this is important because to have\Ncorrect cross references in IDA Pro you
Dialogue: 0,0:16:35.12,0:16:43.22,Default,,0000,0000,0000,,have to rebase your program to 4 and after\Nthat you will have all correct string
Dialogue: 0,0:16:43.22,0:16:48.93,Default,,0000,0000,0000,,cross-references. We will have all the\Nnecessary strings and your static analysis
Dialogue: 0,0:16:48.93,0:16:56.01,Default,,0000,0000,0000,,setup will be complete. But in order to\Nbuild an exploit it will not suffice to
Dialogue: 0,0:16:56.01,0:17:00.74,Default,,0000,0000,0000,,only have the, you know, IDA Pro loaded\Nwith the firmware with all the cross
Dialogue: 0,0:17:00.74,0:17:07.14,Default,,0000,0000,0000,,references, you probably want to, you\Nknow, set up a debug environment. It is
Dialogue: 0,0:17:07.14,0:17:14.69,Default,,0000,0000,0000,,well known that IOS can be debugged via a\Nserial port and actually there's a "gdb
Dialogue: 0,0:17:14.69,0:17:23.11,Default,,0000,0000,0000,,kernel" command that is used to start the\Ninternal gdb server, or it was because
Dialogue: 0,0:17:23.11,0:17:29.14,Default,,0000,0000,0000,,functionality was removed in the recent\Nversions of IOS and you can't really run
Dialogue: 0,0:17:29.14,0:17:38.95,Default,,0000,0000,0000,,the gdb. But nonetheless there's a way to\Nenable the gdb and this way is to reboot
Dialogue: 0,0:17:38.95,0:17:46.39,Default,,0000,0000,0000,,the device, send an escape sequence to the\Nserial line, this will bring up the rom
Dialogue: 0,0:17:46.39,0:17:52.50,Default,,0000,0000,0000,,monitor shell so rom monitor is a simple\Npiece of firmware that gets loaded and run
Dialogue: 0,0:17:52.50,0:17:59.72,Default,,0000,0000,0000,,just before your firmware starts running\Nand in this ROMMON you can manually boot
Dialogue: 0,0:17:59.72,0:18:08.95,Default,,0000,0000,0000,,your firmware with a flag and which will\Nlaunch the whole firmware under gdb. And
Dialogue: 0,0:18:08.95,0:18:17.98,Default,,0000,0000,0000,,after your firmware is loaded, the gdb\Nwill kick in. Now you can't just use your
Dialogue: 0,0:18:17.98,0:18:25.92,Default,,0000,0000,0000,,favorite gdb debugger and Linux and\Nconnect it to IOS via a serial port
Dialogue: 0,0:18:25.92,0:18:35.00,Default,,0000,0000,0000,,because IOS uses a slightly different\Nsubset of commands of gdb protocol. It has
Dialogue: 0,0:18:35.00,0:18:43.68,Default,,0000,0000,0000,,a server-side gdb but the client side\Nshould be accustomed to this gdb server.
Dialogue: 0,0:18:43.68,0:18:48.63,Default,,0000,0000,0000,,Basically there is no publicly and\Nofficially available client-side debugging
Dialogue: 0,0:18:48.63,0:18:56.30,Default,,0000,0000,0000,,tools for IOS and that is because this is\Nintended for Cisco engineers for to be
Dialogue: 0,0:18:56.30,0:19:02.24,Default,,0000,0000,0000,,done. Although there have been some\Nefforts from the community to build tools
Dialogue: 0,0:19:02.24,0:19:08.75,Default,,0000,0000,0000,,to debug several versions of routers and\Nswitches with IOS and if you look for ways
Dialogue: 0,0:19:08.75,0:19:15.93,Default,,0000,0000,0000,,to debug Cisco IOS you will find, you most\Ndefinitely will find a tutorial that says
Dialogue: 0,0:19:15.93,0:19:21.61,Default,,0000,0000,0000,,that you can actually patch an old version\Nof gdb that still supports IOS, but it
Dialogue: 0,0:19:21.61,0:19:26.12,Default,,0000,0000,0000,,actually never works because I tried it\Nand all I could do is read memory, the
Dialogue: 0,0:19:26.12,0:19:34.95,Default,,0000,0000,0000,,stepping, the tracing, it just doesn't\Nwork. So another way is to use a cool tool
Dialogue: 0,0:19:34.95,0:19:42.39,Default,,0000,0000,0000,,by NCC group, it's called IODIDE, it's a\Ngraphical debugger for IOS, it really
Dialogue: 0,0:19:42.39,0:19:48.77,Default,,0000,0000,0000,,works, it's a great tool, but the thing is\Nit is only, it targets PowerPC
Dialogue: 0,0:19:48.77,0:19:54.83,Default,,0000,0000,0000,,architecture and it has some some problems\Nyou probably have to patch the debugger to
Dialogue: 0,0:19:54.83,0:19:58.64,Default,,0000,0000,0000,,be able to work with it and the third\Noption, the last resort
Dialogue: 0,0:19:58.64,0:20:05.38,Default,,0000,0000,0000,,is to implement your own debugger for the\Nrouter. And to do that you have to know
Dialogue: 0,0:20:05.38,0:20:12.37,Default,,0000,0000,0000,,which commands actually Cisco supports,\Nand not a lot, so you can basically read
Dialogue: 0,0:20:12.37,0:20:18.52,Default,,0000,0000,0000,,memory and write memory and set and write\Nregisters and the only program counter
Dialogue: 0,0:20:18.52,0:20:25.23,Default,,0000,0000,0000,,control command is a step instruction. So\Nbasically it's kind of easy to implement
Dialogue: 0,0:20:25.23,0:20:31.87,Default,,0000,0000,0000,,such a debugger because all the\Ninformation is just sent as a plain text
Dialogue: 0,0:20:31.87,0:20:40.82,Default,,0000,0000,0000,,over a serial cable and appended with a\Nchecksum which is just a CRC. So this way
Dialogue: 0,0:20:40.82,0:20:48.18,Default,,0000,0000,0000,,I was able to, you know, make a quick\NPython script using Capstone to be able to
Dialogue: 0,0:20:48.18,0:20:55.45,Default,,0000,0000,0000,,debug IOS, you can inspect registers,\Nthere's a basic breakpoint management, you
Dialogue: 0,0:20:55.45,0:21:02.17,Default,,0000,0000,0000,,just write a special control double word\Nto be able to break. You can step over a
Dialogue: 0,0:21:02.17,0:21:06.79,Default,,0000,0000,0000,,step over step into and also a good feature is\Nto be able to dump memory, which we will
Dialogue: 0,0:21:06.79,0:21:15.17,Default,,0000,0000,0000,,use later. So to find the overflow, the\NSNMP overflowing the code, how do you do
Dialogue: 0,0:21:15.17,0:21:20.84,Default,,0000,0000,0000,,it? Basically you can follow, since we\Nhave all the string cross-references, you
Dialogue: 0,0:21:20.84,0:21:28.96,Default,,0000,0000,0000,,can follow the strings, that reference\NSNMP get requests and just step until the
Dialogue: 0,0:21:28.96,0:21:35.14,Default,,0000,0000,0000,,crash, but a more efficient method is just\Nto crash the device and start inspecting
Dialogue: 0,0:21:35.14,0:21:41.57,Default,,0000,0000,0000,,the stack after the device is already\Ncrashed. You just have to dump some memory
Dialogue: 0,0:21:41.57,0:21:47.18,Default,,0000,0000,0000,,on the stack and look into the values that\Nreference the code, some of them will be
Dialogue: 0,0:21:47.18,0:21:58.81,Default,,0000,0000,0000,,return addresses and this will give you a\Nhint where the crash actually is. So the
Dialogue: 0,0:21:58.81,0:22:03.50,Default,,0000,0000,0000,,actual program counter corruption happens\Nin the function epilog, I call this
Dialogue: 0,0:22:03.50,0:22:12.55,Default,,0000,0000,0000,,function snmp_stack_overflow, so you can\Nsee here that at the end of a function we
Dialogue: 0,0:22:12.55,0:22:18.72,Default,,0000,0000,0000,,load the values from the stack to\Nregisters $s0 to $s6 and also we load
Dialogue: 0,0:22:18.72,0:22:24.61,Default,,0000,0000,0000,,value into register $ra and this is an\Nimportant register, it's called a return
Dialogue: 0,0:22:24.61,0:22:31.05,Default,,0000,0000,0000,,address register and almost every function\Nin MIPS uses this register to jump back to
Dialogue: 0,0:22:31.05,0:22:39.78,Default,,0000,0000,0000,,its parent function. So basically we have\Nsome space on the stack, but the question
Dialogue: 0,0:22:39.78,0:22:47.79,Default,,0000,0000,0000,,is can we place our shellcode on this on\Nthe stack? And can we execute it? Because,
Dialogue: 0,0:22:47.79,0:22:51.79,Default,,0000,0000,0000,,you know, stack location is\Nunpredictable, every time you trigger this
Dialogue: 0,0:22:51.79,0:22:57.37,Default,,0000,0000,0000,,vulnerability a separate space on the\Nstack is allocated and you cannot really
Dialogue: 0,0:22:57.37,0:23:04.68,Default,,0000,0000,0000,,predict it. So, no valid jump to stack\Ninstructions in the firmware like we did
Dialogue: 0,0:23:04.68,0:23:11.98,Default,,0000,0000,0000,,on Intel x86 like jump ESP. No such\Ninstructions in the firmware, but even if
Dialogue: 0,0:23:11.98,0:23:19.13,Default,,0000,0000,0000,,we could find such an instruction, the\Naddress space layout randomization (ALSR)
Dialogue: 0,0:23:19.13,0:23:26.07,Default,,0000,0000,0000,,is on, which means the code section and\Ndata section is based on different offsets
Dialogue: 0,0:23:26.07,0:23:31.79,Default,,0000,0000,0000,,each time we reboot the device, which\Nmeans that we can't reliably jump to the
Dialogue: 0,0:23:31.79,0:23:39.95,Default,,0000,0000,0000,,instruction. And also an unfortunate thing\Nis that data caching is also in place. So,
Dialogue: 0,0:23:39.95,0:23:49.31,Default,,0000,0000,0000,,about ASLR, this is the first first time I\Nencountered the randomization in IOS.
Dialogue: 0,0:23:49.31,0:23:56.12,Default,,0000,0000,0000,,Previous researchers, that I've been doing\Nwith, they said a lot about diversity of
Dialogue: 0,0:23:56.12,0:24:01.92,Default,,0000,0000,0000,,the firmware. So, basically you had so\Nmany different versions of firmware when
Dialogue: 0,0:24:01.92,0:24:07.14,Default,,0000,0000,0000,,you exploited the Cisco device it couldn't\Nreally reliably jump to any code because
Dialogue: 0,0:24:07.14,0:24:11.94,Default,,0000,0000,0000,,there's so a vast diversity of different\Nfirmware that was built by different
Dialogue: 0,0:24:11.94,0:24:17.99,Default,,0000,0000,0000,,people but here we actually have the stack\Naddress based randomization and the text
Dialogue: 0,0:24:17.99,0:24:26.11,Default,,0000,0000,0000,,section and data section is loaded on\Ndifferent offsets after each reboot. So,
Dialogue: 0,0:24:26.11,0:24:32.93,Default,,0000,0000,0000,,another thing that really upsets us is\Ndata caching, so when we write our shell
Dialogue: 0,0:24:32.93,0:24:38.58,Default,,0000,0000,0000,,code to stack, we think that it will be on\Nthe stack but what actually happens,
Dialogue: 0,0:24:38.58,0:24:43.07,Default,,0000,0000,0000,,everything gets written into data cache\Nand when we place our program counter to
Dialogue: 0,0:24:43.07,0:24:51.14,Default,,0000,0000,0000,,the stack we get executing garbage\Ninstructions which results in a crash once
Dialogue: 0,0:24:51.14,0:24:58.54,Default,,0000,0000,0000,,again. So this problem this is basically a\Ndata execution prevention, well it's not
Dialogue: 0,0:24:58.54,0:25:06.15,Default,,0000,0000,0000,,it's a it's a cache but the solution to\Nthis problem is the same as for data
Dialogue: 0,0:25:06.15,0:25:12.42,Default,,0000,0000,0000,,execution prevention and it is return\Noriented programming, so but unfortunately
Dialogue: 0,0:25:12.42,0:25:21.14,Default,,0000,0000,0000,,we still have ASLR so we can't really jump\Nto anything because it's on a random
Dialogue: 0,0:25:21.14,0:25:28.58,Default,,0000,0000,0000,,offset but here the rom monitor, that I\Nwas talking about comes to our rescue. So
Dialogue: 0,0:25:28.58,0:25:34.62,Default,,0000,0000,0000,,this little piece of software that gets\Nloaded before the actual firmware might
Dialogue: 0,0:25:34.62,0:25:40.15,Default,,0000,0000,0000,,actually help us. So\Nthe first thing we want to find where
Dialogue: 0,0:25:40.15,0:25:45.55,Default,,0000,0000,0000,,this bare-bones firmware is\Nlocated and the interesting feature of
Dialogue: 0,0:25:45.55,0:25:52.74,Default,,0000,0000,0000,,this ROMMON shell, it's actually allowing\Nyou to disassemble arbitrary memory parts
Dialogue: 0,0:25:52.74,0:25:59.18,Default,,0000,0000,0000,,and if you target the disassembler at an\Ninvalid address you will get a stack trace
Dialogue: 0,0:25:59.18,0:26:06.04,Default,,0000,0000,0000,,revealing the actual address of the rom\Nmonitor. And what's the most interesting
Dialogue: 0,0:26:06.04,0:26:13.07,Default,,0000,0000,0000,,thing as the rom monitor is located at\Nbfc0000 and you can dump it using the
Dialogue: 0,0:26:13.07,0:26:19.07,Default,,0000,0000,0000,,debugger or you can just search the\Ninternet for the version and download it.
Dialogue: 0,0:26:19.07,0:26:28.62,Default,,0000,0000,0000,,The most interesting part about this piece\Nof firmware, is that rom monitor is
Dialogue: 0,0:26:28.62,0:26:34.47,Default,,0000,0000,0000,,located at the same address and it's\Npersistent across reboots and it's really
Dialogue: 0,0:26:34.47,0:26:41.61,Default,,0000,0000,0000,,great because we can use it for building\NROP chains inside of it. So now we have a
Dialogue: 0,0:26:41.61,0:26:49.61,Default,,0000,0000,0000,,theoretical possibility of circumventing\NASLR, defeating the cache problem. So how
Dialogue: 0,0:26:49.61,0:26:56.19,Default,,0000,0000,0000,,do we build an exploit, so the overview is\Nas follows: we jump to ROMMON, we initiate
Dialogue: 0,0:26:56.19,0:27:02.93,Default,,0000,0000,0000,,a ROP chain, which makes an arbitrary\Nwrite using the code reuse technique and
Dialogue: 0,0:27:02.93,0:27:10.67,Default,,0000,0000,0000,,after that we have to recover the stack\Nframe to allow the SNMP service to restore
Dialogue: 0,0:27:10.67,0:27:16.05,Default,,0000,0000,0000,,the legitimate code flow. This is really\Nimportant because we will be writing only
Dialogue: 0,0:27:16.05,0:27:22.47,Default,,0000,0000,0000,,four bytes and that is not enough for a\Nfull fledged shellcode and if we don't
Dialogue: 0,0:27:22.47,0:27:28.53,Default,,0000,0000,0000,,crash SNMP we can exploit this\Nvulnerability over and over again, thus
Dialogue: 0,0:27:28.53,0:27:33.09,Default,,0000,0000,0000,,building a shellcode in the memory. So\Nafter we build the shellcode we make a
Dialogue: 0,0:27:33.09,0:27:44.29,Default,,0000,0000,0000,,jump to it. So, here's how it works: we\Noverflow the stack, we overflow the return
Dialogue: 0,0:27:44.29,0:27:51.78,Default,,0000,0000,0000,,address so it points to rom monitor, we\Njump to the rom monitor, then what we do
Dialogue: 0,0:27:51.78,0:27:57.68,Default,,0000,0000,0000,,we actually find a gadget that reuses the\Ndata on our stack to make an arbitrary
Dialogue: 0,0:27:57.68,0:28:04.50,Default,,0000,0000,0000,,four byte write just before the text\Nsection. Then we have to find a gadget
Dialogue: 0,0:28:04.50,0:28:11.53,Default,,0000,0000,0000,,that will recover stack for us so we can\Nrestore the legitimate SNMP execution call
Dialogue: 0,0:28:11.53,0:28:19.73,Default,,0000,0000,0000,,flow. So this is basically an overview of\None cycle of how we write a four byte
Dialogue: 0,0:28:19.73,0:28:27.97,Default,,0000,0000,0000,,double word. Now, a little bit on building\NROP chains, so what is it? what is return
Dialogue: 0,0:28:27.97,0:28:38.18,Default,,0000,0000,0000,,oriented programming? So basically the\Nidea is to not execute the shellcode
Dialogue: 0,0:28:38.18,0:28:45.39,Default,,0000,0000,0000,,directly but is to use existing\Ncode in the binary to execute your
Dialogue: 0,0:28:45.39,0:28:52.20,Default,,0000,0000,0000,,payload. So you use stack not as a source\Nof instructions but you use stack as data
Dialogue: 0,0:28:52.20,0:28:59.72,Default,,0000,0000,0000,,for the code that you're reusing. So\Nbasically you change the snippets of code
Dialogue: 0,0:28:59.72,0:29:07.72,Default,,0000,0000,0000,,we call them gadgets and you chain them\Ntogether with jump or call instructions
Dialogue: 0,0:29:07.72,0:29:17.16,Default,,0000,0000,0000,,and candidate gadgets has to meet two\Nrequirements: It has to actually execute
Dialogue: 0,0:29:17.16,0:29:22.82,Default,,0000,0000,0000,,our payload and also it also has to\Ncontain instructions that will transfer
Dialogue: 0,0:29:22.82,0:29:28.34,Default,,0000,0000,0000,,execution flow to the next gadget or, if\Nit's the last gadget it should transfer
Dialogue: 0,0:29:28.34,0:29:37.78,Default,,0000,0000,0000,,execution back to the SNMP service. The\Nproblems with the return oriented approach
Dialogue: 0,0:29:37.78,0:29:42.42,Default,,0000,0000,0000,,is that there is a limited set of gadgets\Navailable, so if you're talking about the
Dialogue: 0,0:29:42.42,0:29:46.98,Default,,0000,0000,0000,,firmware it's around 200 megabytes of code\Nso there are plenty of different gadgets
Dialogue: 0,0:29:46.98,0:29:51.33,Default,,0000,0000,0000,,there, if we're talking about a rom\Nmonitor it's only 500 kilobytes of code,
Dialogue: 0,0:29:51.33,0:29:58.67,Default,,0000,0000,0000,,so not a lot of code available and the\Nsecond major problem is that gadgets,
Dialogue: 0,0:29:58.67,0:30:04.55,Default,,0000,0000,0000,,because most of them are function\Nepilogues, they modify the stack frame
Dialogue: 0,0:30:04.55,0:30:09.41,Default,,0000,0000,0000,,because they delete the local variables\Nafter they jump back to the parent
Dialogue: 0,0:30:09.41,0:30:15.79,Default,,0000,0000,0000,,function and you have to account for that\Nbecause this, my crash, the process you
Dialogue: 0,0:30:15.79,0:30:23.72,Default,,0000,0000,0000,,are exploiting. ROP chains can be\Nbasically forced to do anything but
Dialogue: 0,0:30:23.72,0:30:31.42,Default,,0000,0000,0000,,mostly, most of the times we do arbitrary\Nmemory writes and this actually might lead
Dialogue: 0,0:30:31.42,0:30:39.60,Default,,0000,0000,0000,,to arbitrary code execution. So the idea\Nfor for looking for gadgets is that you
Dialogue: 0,0:30:39.60,0:30:46.20,Default,,0000,0000,0000,,find a gadget that loads data from the\Nstack into the registers and then you find
Dialogue: 0,0:30:46.20,0:30:50.58,Default,,0000,0000,0000,,a second gadget that works with the data\Nin the, in those pages for example you
Dialogue: 0,0:30:50.58,0:30:58.40,Default,,0000,0000,0000,,have one register $v0 which contains the\Nvalue you want to write and the other
Dialogue: 0,0:30:58.40,0:31:09.93,Default,,0000,0000,0000,,gadget $s0 which has the address you want\Nto write to. So we actually want to find
Dialogue: 0,0:31:09.93,0:31:15.66,Default,,0000,0000,0000,,gadgets that also load data from stack to\Nreturn registers so we can jump to the
Dialogue: 0,0:31:15.66,0:31:24.16,Default,,0000,0000,0000,,next gadget. I don't have to look for\Nthese gadgets manually in IODIDE, in there
Dialogue: 0,0:31:24.16,0:31:29.86,Default,,0000,0000,0000,,are a lot of different tools for building\NROP chains, one of those tools is Ropper
Dialogue: 0,0:31:29.86,0:31:32.48,Default,,0000,0000,0000,,you can find it on GitHub it's a really\Nhandy tool.
Dialogue: 0,0:31:32.48,0:31:36.38,Default,,0000,0000,0000,,You just search for necessary\Ninstructions to build
Dialogue: 0,0:31:36.38,0:31:48.67,Default,,0000,0000,0000,,the necessary ROP chain. So now the last\Ntechnical part of how the ROP chains in
Dialogue: 0,0:31:48.67,0:31:54.94,Default,,0000,0000,0000,,this particular exploit work and then\Nwe'll get to the demo. So this is how a
Dialogue: 0,0:31:54.94,0:32:02.83,Default,,0000,0000,0000,,perfectly, you know, healthy stack frame\Nlooks like. So you basically have local
Dialogue: 0,0:32:02.83,0:32:07.50,Default,,0000,0000,0000,,variables on the stack, you have return\Nadress, you also have a stack frame of
Dialogue: 0,0:32:07.50,0:32:13.39,Default,,0000,0000,0000,,parent functions underneath the stack\Nframe of our vulnerable function. So when
Dialogue: 0,0:32:13.39,0:32:19.68,Default,,0000,0000,0000,,we overflow the local variables with our\Nlong object identifier here's what
Dialogue: 0,0:32:19.68,0:32:27.77,Default,,0000,0000,0000,,happens: We overflow the local variables\Nand these variables actually partly get
Dialogue: 0,0:32:27.77,0:32:34.21,Default,,0000,0000,0000,,written to $s0 and $s6 general purpose\Nregisters we also, of course overflow the
Dialogue: 0,0:32:34.21,0:32:41.30,Default,,0000,0000,0000,,return address, which will jump for us to\Nrom monitor and we also have some 60
Dialogue: 0,0:32:41.30,0:32:46.59,Default,,0000,0000,0000,,bytes, after that we overflow the stack\Nframe of the next function and we use that
Dialogue: 0,0:32:46.59,0:32:54.97,Default,,0000,0000,0000,,data also for our ROP chain. What we do\Nhere, we take the value of $a0, we control
Dialogue: 0,0:32:54.97,0:33:01.92,Default,,0000,0000,0000,,the value of $a0 as you remember and we\Nmove it to register $v0 and that's for
Dialogue: 0,0:33:01.92,0:33:10.04,Default,,0000,0000,0000,,only solely purpose because there are no\Nother gadgets in rom monitor that use $s0
Dialogue: 0,0:33:10.04,0:33:16.51,Default,,0000,0000,0000,,as a target register to write data so we\Nhave to use register $v0. After that the
Dialogue: 0,0:33:16.51,0:33:22.28,Default,,0000,0000,0000,,most important part is that we load the\Nreturn address from the ROP data too and
Dialogue: 0,0:33:22.28,0:33:31.29,Default,,0000,0000,0000,,also we load the address we will write to\Nfrom the ROP data too. So basically right
Dialogue: 0,0:33:31.29,0:33:40.54,Default,,0000,0000,0000,,now after this gadget stops executing we\Nhave $s0 points to a memory we want to
Dialogue: 0,0:33:40.54,0:33:49.70,Default,,0000,0000,0000,,write to and $v0 contains 4 bytes we will\Nbe writing just before the code section.
Dialogue: 0,0:33:49.70,0:33:57.65,Default,,0000,0000,0000,,So the final gadget that is performing the\Narbitrary write is the gadget that takes
Dialogue: 0,0:33:57.65,0:34:08.19,Default,,0000,0000,0000,,the value of register $v0 and writes it to\Na pointer reference that referenced by
Dialogue: 0,0:34:08.19,0:34:15.04,Default,,0000,0000,0000,,register $s0 and the last thing it does\Nactually transfers the control back to the
Dialogue: 0,0:34:15.04,0:34:22.15,Default,,0000,0000,0000,,gadget, which will recover the stack for\Nus. Most important gadgets it allows us to
Dialogue: 0,0:34:22.15,0:34:28.14,Default,,0000,0000,0000,,run the exploit several times, you might\Nhave noticed that the previous gadgets
Dialogue: 0,0:34:28.14,0:34:36.46,Default,,0000,0000,0000,,actually moved the stack pointer 30 bytes\Nand hacks down them down the
Dialogue: 0,0:34:36.46,0:34:38.36,Default,,0000,0000,0000,,stack and this actually means
Dialogue: 0,0:34:38.36,0:34:44.51,Default,,0000,0000,0000,,that the process that we will return\Nto will crash if we don't point the stack
Dialogue: 0,0:34:44.51,0:34:50.77,Default,,0000,0000,0000,,pointer just between two stack frames. We\Nfind a gadget that will move the stack
Dialogue: 0,0:34:50.77,0:35:00.34,Default,,0000,0000,0000,,pointer down to 228 bytes in hex, which\Nwill result in a perfectly healthy stack.
Dialogue: 0,0:35:00.34,0:35:08.69,Default,,0000,0000,0000,,Also we load the return address to\Nregister $ra and it points to the parent
Dialogue: 0,0:35:08.69,0:35:16.66,Default,,0000,0000,0000,,function that called our own vulnerable\Nfunction so this way we perform an
Dialogue: 0,0:35:16.66,0:35:22.85,Default,,0000,0000,0000,,arbitrary four byte write. We can do this\Nseveral times until our shellcode is
Dialogue: 0,0:35:22.85,0:35:28.35,Default,,0000,0000,0000,,actually built, just before the text\Nsection and the final thing we do, we
Dialogue: 0,0:35:28.35,0:35:34.85,Default,,0000,0000,0000,,overflow the stack again and jump to the\Nshellcode. A few words about the
Dialogue: 0,0:35:34.85,0:35:45.91,Default,,0000,0000,0000,,shellcode: The device I was working with had a\Ntelnet service and it had a password, so I
Dialogue: 0,0:35:45.91,0:35:52.15,Default,,0000,0000,0000,,designed a simple shell code that will\Njust patch the authentication call flow.
Dialogue: 0,0:35:52.15,0:35:58.61,Default,,0000,0000,0000,,So as you can see here we have a function\N"login password check" and a result which
Dialogue: 0,0:35:58.61,0:36:09.17,Default,,0000,0000,0000,,is in $v0 register is checked whether the\Nauthentication was successful or not. We
Dialogue: 0,0:36:09.17,0:36:13.70,Default,,0000,0000,0000,,can build a shell code which which will\Njust patch this instruction which checks
Dialogue: 0,0:36:13.70,0:36:19.90,Default,,0000,0000,0000,,"login password check" and it will allow\Nus to make a credential list
Dialogue: 0,0:36:19.90,0:36:29.78,Default,,0000,0000,0000,,authentication against telnet service. So\Nwhat it does: basically the shell code
Dialogue: 0,0:36:29.78,0:36:35.78,Default,,0000,0000,0000,,inspects the stack and the return address\Nin it to calculate the ASLR offset
Dialogue: 0,0:36:35.78,0:36:43.17,Default,,0000,0000,0000,,because, of course the ASLR is on for the\Ncode section and we want to patch
Dialogue: 0,0:36:43.17,0:36:52.47,Default,,0000,0000,0000,,something in it and after that it writes a\N0, which is a nop instruction in MIPS, to
Dialogue: 0,0:36:52.47,0:37:00.77,Default,,0000,0000,0000,,a call that checks for password for telnet\Nand also for enable password and then it
Dialogue: 0,0:37:00.77,0:37:10.61,Default,,0000,0000,0000,,just jumps back to SNMP service. So now\Nthe long-awaited demo. Let's see if I can
Dialogue: 0,0:37:10.61,0:37:42.48,Default,,0000,0000,0000,,make it a live demo. All righty, so here\Nwe have the serial connection to the
Dialogue: 0,0:37:42.48,0:37:52.82,Default,,0000,0000,0000,,device, you can see we have a shell. So\Nwhat we do now, we inspect the password on
Dialogue: 0,0:37:52.82,0:37:56.46,Default,,0000,0000,0000,,the telnet service to make sure it's\Nworking as intended. So we see that bad
Dialogue: 0,0:37:56.46,0:38:03.70,Default,,0000,0000,0000,,passwords. We don't know the valid\Npassword for the device, what we do now is
Dialogue: 0,0:38:03.70,0:38:16.05,Default,,0000,0000,0000,,we launch the actual exploit, as\Nparameters it takes the host, community
Dialogue: 0,0:38:16.05,0:38:26.20,Default,,0000,0000,0000,,and shell code in hex. So this is the shell
Dialogue: 0,0:38:26.20,0:38:41.30,Default,,0000,0000,0000,,code I was talking about that patches the\Ncode flow in authentication. So let's
Dialogue: 0,0:38:41.30,0:38:53.58,Default,,0000,0000,0000,,write sudo. So here you see that we\Ninitiate writing the four byte sequences
Dialogue: 0,0:38:53.58,0:39:02.49,Default,,0000,0000,0000,,into the text section. Basically this\Nwrites the shell code into the memory. So
Dialogue: 0,0:39:02.49,0:39:17.18,Default,,0000,0000,0000,,after the exploit finishes this, we just\Nhave to jump to the shell code. So let's
Dialogue: 0,0:39:17.18,0:39:57.53,Default,,0000,0000,0000,,see. Please do not crash. So, yes. So back\Nto the slides. And of course you can build
Dialogue: 0,0:39:57.53,0:40:02.50,Default,,0000,0000,0000,,a shell code that will unset this behavior\Nand patch the process back to enable the
Dialogue: 0,0:40:02.50,0:40:07.94,Default,,0000,0000,0000,,password and on the side notes how\Nreliably can you exploit this
Dialogue: 0,0:40:07.94,0:40:15.22,Default,,0000,0000,0000,,vulnerability? So, of course the SNMP\Npublic community will leak you the version
Dialogue: 0,0:40:15.22,0:40:20.56,Default,,0000,0000,0000,,of the particular router but it does not\Nleak you the version of ROMMON and we're
Dialogue: 0,0:40:20.56,0:40:29.38,Default,,0000,0000,0000,,basically constructing ROP chains in the\Nrom monitor. So actually you have not that
Dialogue: 0,0:40:29.38,0:40:34.08,Default,,0000,0000,0000,,many versions of rom monitor available.\NYou have only five if we're talking about
Dialogue: 0,0:40:34.08,0:40:41.50,Default,,0000,0000,0000,,2800 router. So the worst-case scenario is\Njust you crash it four times. It's not
Dialogue: 0,0:40:41.50,0:40:46.41,Default,,0000,0000,0000,,like you have to crash it four thousand\Ntimes to you know beat the ASLR but
Dialogue: 0,0:40:46.41,0:40:52.34,Default,,0000,0000,0000,,there's a second option which is\Ninteresting. ROMMON is designed to be
Dialogue: 0,0:40:52.34,0:40:57.59,Default,,0000,0000,0000,,upgraded, so basically a system\Nadministrator can download a new version
Dialogue: 0,0:40:57.59,0:41:02.80,Default,,0000,0000,0000,,and update it but the thing is that read-\Nonly region that contains the stock ROMMON
Dialogue: 0,0:41:02.80,0:41:10.30,Default,,0000,0000,0000,,is always in place and it is always at the\Nsame offset, so even if you updated the
Dialogue: 0,0:41:10.30,0:41:15.76,Default,,0000,0000,0000,,rom monitor, the read-only version of it,\Nthe old version that always been there,
Dialogue: 0,0:41:15.76,0:41:24.65,Default,,0000,0000,0000,,will always be at bfc00000. So basically\Nthe assumption is that all the devices
Dialogue: 0,0:41:24.65,0:41:29.03,Default,,0000,0000,0000,,manufactured at the same time and place,\Nthey will have the same read-only rom
Dialogue: 0,0:41:29.03,0:41:38.03,Default,,0000,0000,0000,,monitor, you can query your serial number\Nof your router using snmpget. So for
Dialogue: 0,0:41:38.03,0:41:44.76,Default,,0000,0000,0000,,example my lab router is manufactured in\Nthe year of 2008 and Czech Republic. So
Dialogue: 0,0:41:44.76,0:41:51.72,Default,,0000,0000,0000,,and it has the following version of rom\Nmonitor. So guys to, you know, to
Dialogue: 0,0:41:51.72,0:41:57.21,Default,,0000,0000,0000,,summarise about all this, do not leave\Ndefault credentials on external networks.
Dialogue: 0,0:41:57.21,0:42:02.73,Default,,0000,0000,0000,,So public communities are not designed to\Nbe placed on external networks
Dialogue: 0,0:42:02.73,0:42:09.99,Default,,0000,0000,0000,,for the Shodan to find it. Take care of\Nwhat you expose on the external networks.
Dialogue: 0,0:42:09.99,0:42:17.27,Default,,0000,0000,0000,,Of course patch your devices and watch\Nfor the end-of-life announcement by
Dialogue: 0,0:42:17.27,0:42:28.20,Default,,0000,0000,0000,,Cisco. Sorry? Sure why not? Alright guys\Nthank you so much for your attention
Dialogue: 0,0:42:28.20,0:42:40.51,Default,,0000,0000,0000,,{\i1}applause{\i0}\Nthanks for having me.
Dialogue: 0,0:42:40.51,0:42:42.60,Default,,0000,0000,0000,,Herald: I suppose there are some questions
Dialogue: 0,0:42:42.60,0:42:50.25,Default,,0000,0000,0000,,in this audience, please take a microphone\Nif you can. no one on the internet? They
Dialogue: 0,0:42:50.25,0:43:00.59,Default,,0000,0000,0000,,are flabbergasted there it seems. \NMicrophone number one.
Dialogue: 0,0:43:00.59,0:43:07.11,Default,,0000,0000,0000,,Mic 1: Yeah, I'm a random network admin\Nand I know that people tend to use the
Dialogue: 0,0:43:07.11,0:43:13.32,Default,,0000,0000,0000,,same SNMP community on many of their\Nrouters. My view is that basically if you
Dialogue: 0,0:43:13.32,0:43:19.17,Default,,0000,0000,0000,,can get access to read only on those\Nrouters you will be able to hijack that or
Dialogue: 0,0:43:19.17,0:43:25.14,Default,,0000,0000,0000,,like use the same principle. So basically\Ndon't use the same SNMP community on all
Dialogue: 0,0:43:25.14,0:43:29.91,Default,,0000,0000,0000,,your devices that would be also something.\NArtem Kondratenko: the main thing is to
Dialogue: 0,0:43:29.91,0:43:34.80,Default,,0000,0000,0000,,update your routers because it's a patched\Nvulnerability, the patch was released in
Dialogue: 0,0:43:34.80,0:43:42.86,Default,,0000,0000,0000,,September of 2017 but if you tend to use\Nthe end-of-life products like router 2800
Dialogue: 0,0:43:42.86,0:43:48.94,Default,,0000,0000,0000,,you probably should use a strong community\Nstrength for it.
Dialogue: 0,0:43:48.94,0:43:55.04,Default,,0000,0000,0000,,Herald: Thank you. Someone else having a\Nquestion there? Yes someone on the
Dialogue: 0,0:43:55.04,0:44:00.39,Default,,0000,0000,0000,,internet is alive. It's alive.\NSignal Angel: Let's try it. Yeah now I've
Dialogue: 0,0:44:00.39,0:44:05.05,Default,,0000,0000,0000,,actually got a microphone. The Internet is\Nasking how much time did you put into this
Dialogue: 0,0:44:05.05,0:44:08.83,Default,,0000,0000,0000,,whole project?\NArtem Kondratenko: While working on this
Dialogue: 0,0:44:08.83,0:44:19.07,Default,,0000,0000,0000,,exploit consumed around I'd say four\Nweeks. Four weeks from the discovering the
Dialogue: 0,0:44:19.07,0:44:26.32,Default,,0000,0000,0000,,device on the external network to the\Nfinal exploit. Yes. Thank you.
Dialogue: 0,0:44:26.32,0:44:31.46,Default,,0000,0000,0000,,Herald: I have a question maybe for you as\Nwell. Is that you you're as well a lot of
Dialogue: 0,0:44:31.46,0:44:36.07,Default,,0000,0000,0000,,you have lots of volunteers who are\Nworking with you as well in researching
Dialogue: 0,0:44:36.07,0:44:38.44,Default,,0000,0000,0000,,these exploits or?\NArtem Kondratenko: Volunteers?
Dialogue: 0,0:44:38.44,0:44:41.73,Default,,0000,0000,0000,,Herald: Yeah I don't know.\NArtem Kondratenko: No, actually we don't
Dialogue: 0,0:44:41.73,0:44:44.26,Default,,0000,0000,0000,,have any volunteers, this is all part of\Nmy work.
Dialogue: 0,0:44:44.26,0:44:52.30,Default,,0000,0000,0000,,Herald: Okay. Thank you very much for\Nthank you very much for this in its really
Dialogue: 0,0:44:52.30,0:44:56.42,Default,,0000,0000,0000,,revealing lecture, if someone wants to...\NArtem Kondratenko: Oh I just forgot to
Dialogue: 0,0:44:56.42,0:45:02.46,Default,,0000,0000,0000,,say, is my mic on? okay so the actual\Nproof of concept and the debugger will be
Dialogue: 0,0:45:02.46,0:45:07.57,Default,,0000,0000,0000,,released in a few days, so the Python\Nscript with the capstone and the actual
Dialogue: 0,0:45:07.57,0:45:12.07,Default,,0000,0000,0000,,proof of concept I'll publish it and in a\Nweek or so.
Dialogue: 0,0:45:12.07,0:45:16.04,Default,,0000,0000,0000,,Herald: okay thank you.
Dialogue: 0,0:45:16.04,0:45:20.55,Default,,0000,0000,0000,,{\i1}34c3 outro{\i0}
Dialogue: 0,0:45:20.55,0:45:36.74,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2018. Join, and help us!