1 00:00:01,920 --> 00:00:04,560 - This is Jacob Baines 2 00:00:04,560 --> 00:00:09,560 and he's gonna talk to you about ASAs 3 00:00:09,930 --> 00:00:12,183 and whether you should trust them or not. 4 00:00:13,350 --> 00:00:14,183 - Nailed it. 5 00:00:18,360 --> 00:00:20,010 All right, hello, everyone. 6 00:00:20,010 --> 00:00:23,670 Welcome to my talk, "Do Not Trust the ASA Trojans." 7 00:00:23,670 --> 00:00:24,993 Ooh, that's fast. 8 00:00:27,150 --> 00:00:30,153 Now you might immediately be asking yourself what is an ASA? 9 00:00:31,020 --> 00:00:31,950 And these are ASA. 10 00:00:31,950 --> 00:00:35,100 These are Cisco Adaptive Security Appliance. 11 00:00:35,100 --> 00:00:37,050 At the top, you see the original ASA released 12 00:00:37,050 --> 00:00:39,960 some 15 years ago and that was followed by the release 13 00:00:39,960 --> 00:00:42,540 of the ASA-X, which was followed more recently 14 00:00:42,540 --> 00:00:45,813 by the release of the ASA-X with FirePOWER Services. 15 00:00:47,490 --> 00:00:50,190 Now the ASA actually comes in a few other form factors, 16 00:00:50,190 --> 00:00:53,193 including a virtual appliance known as ASAv. 17 00:00:54,690 --> 00:00:58,920 And these are sort of ASA, as well, despite their names 18 00:00:58,920 --> 00:01:00,990 because they can run the operating system known 19 00:01:00,990 --> 00:01:03,000 as ASA software. 20 00:01:03,000 --> 00:01:05,970 That is, of course, the same operating system used 21 00:01:05,970 --> 00:01:08,133 by the previously mentioned ASA models. 22 00:01:10,110 --> 00:01:11,790 Now an ASA typically sits at the edge 23 00:01:11,790 --> 00:01:14,610 of your corporate network where it can be a firewall, 24 00:01:14,610 --> 00:01:18,240 a VPN, an IPS, and, or a router 25 00:01:18,240 --> 00:01:20,310 possibly all wrapped into one. 26 00:01:20,310 --> 00:01:23,040 The ASA is a critical asset because it acts as the gateway 27 00:01:23,040 --> 00:01:25,770 between the internet and your corporate network 28 00:01:25,770 --> 00:01:28,560 and it also implements a variety of access controls 29 00:01:28,560 --> 00:01:29,613 and protections. 30 00:01:31,110 --> 00:01:34,080 This talk is called, "Do Not Trust the ASA," 31 00:01:34,080 --> 00:01:35,850 'cause we're gonna use features 32 00:01:35,850 --> 00:01:38,820 and vulnerabilities affecting the ASA in order to get 33 00:01:38,820 --> 00:01:42,930 root shells on the ASA itself, as well as shells 34 00:01:42,930 --> 00:01:45,543 on the administrative systems that connect to it. 35 00:01:48,090 --> 00:01:51,720 Now all the ASA models we discussed earlier can be managed 36 00:01:51,720 --> 00:01:53,460 by this thick client known 37 00:01:53,460 --> 00:01:57,600 as Adaptive Security Device Manager or ASDM. 38 00:01:57,600 --> 00:02:01,020 ASDM is installed on an administrator's Windows system 39 00:02:01,020 --> 00:02:05,310 so that they can remotely connect to their ASA or ASAs 40 00:02:05,310 --> 00:02:07,050 and perform administrative tasks 41 00:02:07,050 --> 00:02:10,830 like updating firewall rules, adding VPN users, 42 00:02:10,830 --> 00:02:13,293 or simply monitoring the router's status. 43 00:02:16,170 --> 00:02:19,650 So for the next 20 slides or so it is important 44 00:02:19,650 --> 00:02:23,730 to understand how the ASDM client and the ASA communicate. 45 00:02:23,730 --> 00:02:25,527 One of the first things that happens is 46 00:02:25,527 --> 00:02:30,527 the ASDM client makes an HTTP request for a PDM.SGZ file. 47 00:02:31,470 --> 00:02:34,770 Now this file is hosted on the Cisco ASA's web server 48 00:02:34,770 --> 00:02:39,390 and the PDM.SGZ is downloaded by the client and unpacked. 49 00:02:39,390 --> 00:02:44,390 The SGZ format is nonstandard one, but regardless, 50 00:02:44,460 --> 00:02:46,020 what the client finds inside is 51 00:02:46,020 --> 00:02:48,180 a whole bunch of Java classes. 52 00:02:48,180 --> 00:02:51,810 The client will load those into memory, execute them, 53 00:02:51,810 --> 00:02:55,350 and that establishes the full administrative session 54 00:02:55,350 --> 00:02:56,820 with the ASA. 55 00:02:56,820 --> 00:02:59,880 Now the fact that the SGZ file contains a whole lot 56 00:02:59,880 --> 00:03:01,950 of the client's functionality will be 57 00:03:01,950 --> 00:03:03,333 really important in a bit. 58 00:03:07,410 --> 00:03:09,660 So what's interesting about this is 59 00:03:09,660 --> 00:03:12,900 while the communication happens over SSL, 60 00:03:12,900 --> 00:03:16,683 the ASDM client never verifies the ASA server certificate. 61 00:03:20,790 --> 00:03:24,540 Which means that a Man in the Middle, like Hacker Cat here, 62 00:03:24,540 --> 00:03:26,940 can monitor or even modify the communication 63 00:03:26,940 --> 00:03:30,390 between the ASDM client and the ASA itself. 64 00:03:30,390 --> 00:03:32,520 Essentially, this should allow Hacker Cat to take 65 00:03:32,520 --> 00:03:36,390 full control of the ASA as long as they're able to establish 66 00:03:36,390 --> 00:03:37,990 this Man in the Middle position. 67 00:03:39,900 --> 00:03:41,520 Now this isn't theoretical. 68 00:03:41,520 --> 00:03:44,250 Pictured here is a screenshot of me using the popular tool, 69 00:03:44,250 --> 00:03:47,100 Man in the Middle proxy, on the ASDM client. 70 00:03:47,100 --> 00:03:49,680 I used a default Man in the Middle proxy certificate 71 00:03:49,680 --> 00:03:51,900 and the ASDM client gave no indication 72 00:03:51,900 --> 00:03:53,490 that it was under attack. 73 00:03:53,490 --> 00:03:57,120 Like I said, this should give me, the attacker, full control 74 00:03:57,120 --> 00:04:00,240 over the ASA, but I might be able to gain access 75 00:04:00,240 --> 00:04:02,550 to the administrator's system, as well. 76 00:04:02,550 --> 00:04:07,350 Recall that this PDM.SGZ file is full of Java classes. 77 00:04:07,350 --> 00:04:09,930 If the Man in the Middle can introduce Melissa's Java 78 00:04:09,930 --> 00:04:14,100 to the SGZ, then maybe the SDM client will execute 79 00:04:14,100 --> 00:04:15,303 the malicious code. 80 00:04:17,700 --> 00:04:22,410 To explore that, I wrote this SGZ parser called Getchoo. 81 00:04:22,410 --> 00:04:25,230 It can extract all the files from an SGZ file 82 00:04:25,230 --> 00:04:27,030 and drop them a disk. 83 00:04:27,030 --> 00:04:28,800 On the right here, you can see a recent release 84 00:04:28,800 --> 00:04:33,270 of the SGZ file containing more than 13,000 Java classes. 85 00:04:33,270 --> 00:04:37,260 Importantly, it also contains a signature file. 86 00:04:37,260 --> 00:04:40,770 Now this file contains valid cryptographic signatures 87 00:04:40,770 --> 00:04:43,590 for all of the files in the SGZ. 88 00:04:43,590 --> 00:04:47,760 So if the ASDM client verifies the files in the SGZ 89 00:04:47,760 --> 00:04:49,470 against the signature file, 90 00:04:49,470 --> 00:04:51,960 then an attacker shouldn't be able to introduce 91 00:04:51,960 --> 00:04:53,103 malicious Java. 92 00:04:57,510 --> 00:05:01,560 So here's some of the decompiled logic from the ASDM client. 93 00:05:01,560 --> 00:05:03,210 Highlighted here, we can see 94 00:05:03,210 --> 00:05:06,510 that the client does actually check the validity 95 00:05:06,510 --> 00:05:10,500 of each file and when it encounters an invalid entry, 96 00:05:10,500 --> 00:05:13,143 it will log that failure to a log file. 97 00:05:14,160 --> 00:05:16,980 But as we can see here, 98 00:05:16,980 --> 00:05:21,030 the client will still load the unsigned class files. 99 00:05:21,030 --> 00:05:23,790 The client knows it's loading in unsigned class, 100 00:05:23,790 --> 00:05:25,620 so it attempts to use what they're calling 101 00:05:25,620 --> 00:05:27,783 the unsigned protection domain. 102 00:05:29,100 --> 00:05:30,600 The unsigned protection domain is 103 00:05:30,600 --> 00:05:33,030 just like the signed protection domain 104 00:05:33,030 --> 00:05:35,700 except the all permission has been removed. 105 00:05:35,700 --> 00:05:39,120 It just so happens that in this piece of software, 106 00:05:39,120 --> 00:05:43,560 that doesn't have any significant effect for the attacker. 107 00:05:43,560 --> 00:05:46,860 A malicious Java class can more or less do anything 108 00:05:46,860 --> 00:05:47,733 to the system. 109 00:05:48,810 --> 00:05:49,643 Thank you. 110 00:05:52,830 --> 00:05:57,210 So this actually has been an ongoing issue with the ASDM. 111 00:05:57,210 --> 00:05:59,370 Last summer, Cisco issued this advisory 112 00:05:59,370 --> 00:06:03,510 and assigns CVE 2021, 1585. 113 00:06:03,510 --> 00:06:05,400 Essentially, this advisory says 114 00:06:05,400 --> 00:06:08,220 a Man in the Middle can inject arbitrary Java 115 00:06:08,220 --> 00:06:11,580 into an SGZ file and gain execution 116 00:06:11,580 --> 00:06:13,410 on an administrator's system. 117 00:06:13,410 --> 00:06:16,590 Now, Cisco didn't release a patch with this advisory. 118 00:06:16,590 --> 00:06:20,070 In fact, they didn't try to patch it until June 2022. 119 00:06:20,070 --> 00:06:23,670 And unfortunately, that patch wasn't effective. 120 00:06:23,670 --> 00:06:27,300 I'm told Cisco released a new patch for this vulnerability 121 00:06:27,300 --> 00:06:29,760 a couple of days ago, I was at Black Hat. 122 00:06:29,760 --> 00:06:31,890 So this issue might be cleaned up now, 123 00:06:31,890 --> 00:06:34,500 although I haven't had a chance to verify that. 124 00:06:34,500 --> 00:06:37,830 But it did take more than a year after initial disclosure 125 00:06:37,830 --> 00:06:39,363 for Cisco to address this. 126 00:06:41,580 --> 00:06:43,950 Now a Man in the Middle attack is difficult. 127 00:06:43,950 --> 00:06:47,160 It's a difficult position for an attacker to achieve 128 00:06:47,160 --> 00:06:49,920 so it's useful to note that 1585 is actually useful 129 00:06:49,920 --> 00:06:52,260 for evil endpoints as well. 130 00:06:52,260 --> 00:06:54,630 And what I mean by evil endpoint is that 131 00:06:54,630 --> 00:06:58,917 if Hacker Cat can trick an administrator to connect 132 00:07:01,920 --> 00:07:05,190 to a endpoint in their control, 133 00:07:05,190 --> 00:07:08,940 then the Hacker Cat can return an SGZ file 134 00:07:08,940 --> 00:07:12,810 with malicious content and the ASDM client will load that 135 00:07:12,810 --> 00:07:16,230 into memory, execute it, and then Hacker Cat will have 136 00:07:16,230 --> 00:07:18,480 code execution on the administrator's system. 137 00:07:20,550 --> 00:07:22,410 Again, that's not theoretical. 138 00:07:22,410 --> 00:07:25,380 I've actually written two exploits for 1585, 139 00:07:25,380 --> 00:07:27,507 one of which is a Metasploit module. 140 00:07:27,507 --> 00:07:30,330 And now this talk emphasizes real exploits, 141 00:07:30,330 --> 00:07:33,930 particularly using Metasploit to hammer home that these are 142 00:07:33,930 --> 00:07:35,880 viable attacks that could be pulled off 143 00:07:35,880 --> 00:07:37,270 by low-skilled attackers 144 00:07:39,398 --> 00:07:41,848 and these attacks should be taken very seriously. 145 00:07:44,250 --> 00:07:45,523 Now obviously, this Man in the Middle, 146 00:07:45,523 --> 00:07:49,110 the Man in the Middle aspect of this attack is 147 00:07:49,110 --> 00:07:50,880 much more difficult 148 00:07:50,880 --> 00:07:53,580 when the administrator doesn't connect 149 00:07:53,580 --> 00:07:55,740 to the ASA over the internet. 150 00:07:55,740 --> 00:07:57,930 Hacker Cat is gonna have a hard time establishing 151 00:07:57,930 --> 00:08:00,930 a Man in the Middle position within Corpnet. 152 00:08:00,930 --> 00:08:04,113 So the administrator is probably safe in this configuration. 153 00:08:06,450 --> 00:08:09,030 Now as a researcher, I want to find a way to attack 154 00:08:09,030 --> 00:08:11,190 the administrator on Corpnet, as well. 155 00:08:11,190 --> 00:08:14,190 And I figured I'd try to just modify the SGZ file 156 00:08:14,190 --> 00:08:15,870 on the ASA itself. 157 00:08:15,870 --> 00:08:18,990 Now remember the SGZ is hosted on the router's web server, 158 00:08:18,990 --> 00:08:22,023 so I figured I might have some type of write access there. 159 00:08:24,300 --> 00:08:27,060 But I needed to find how the SDZ file got on the ASA 160 00:08:27,060 --> 00:08:28,440 in the first place. 161 00:08:28,440 --> 00:08:30,930 And the answer is that it gets added to the ASA 162 00:08:30,930 --> 00:08:34,980 when the ASDM binary package is loaded on the system. 163 00:08:34,980 --> 00:08:38,160 Now the package is available on Cisco's website 164 00:08:38,160 --> 00:08:41,820 as pictured here, but it's also loaded by default 165 00:08:41,820 --> 00:08:46,820 onto some of their ASA, such as ASAv and the test 5506X 166 00:08:47,580 --> 00:08:50,430 that we purchased also had it preloaded. 167 00:08:50,430 --> 00:08:53,910 But regardless, this SGZ file is first introduced 168 00:08:53,910 --> 00:08:57,810 to the ASA's web server when the ASDM binary blob is loaded 169 00:08:57,810 --> 00:08:58,683 on the ASA. 170 00:09:00,287 --> 00:09:02,670 And so I went hunting for the SGZ file 171 00:09:02,670 --> 00:09:05,160 in the ASDM binary package. 172 00:09:05,160 --> 00:09:07,320 Again, this is a nonstandard format, 173 00:09:07,320 --> 00:09:09,030 so I had to do a little bit of work, 174 00:09:09,030 --> 00:09:11,820 but it turned out to be pretty simple. 175 00:09:11,820 --> 00:09:14,490 The binary package breaks down into three parts: 176 00:09:14,490 --> 00:09:17,670 a general header, a manifest area, 177 00:09:17,670 --> 00:09:20,370 and then all the files are catted together at the end. 178 00:09:21,480 --> 00:09:23,310 I was also looking for security features 179 00:09:23,310 --> 00:09:24,780 in the binary package. 180 00:09:24,780 --> 00:09:27,390 And basically, I was looking for evidence 181 00:09:27,390 --> 00:09:29,670 that Cisco was signing the package. 182 00:09:29,670 --> 00:09:32,160 So I did find this hash field in the header. 183 00:09:32,160 --> 00:09:35,340 So my question was, is this a security feature 184 00:09:35,340 --> 00:09:38,140 or is it just a checksum to ensure the file's integrity? 185 00:09:39,300 --> 00:09:42,120 And it turned out to just be a checksum, 186 00:09:42,120 --> 00:09:44,640 which might not sound like a big deal to a lay person, 187 00:09:44,640 --> 00:09:46,200 but it really is. 188 00:09:46,200 --> 00:09:49,410 Because there's no Cisco signature on this binary package, 189 00:09:49,410 --> 00:09:54,060 anyone is able to craft their own arbitrary ASDM package, 190 00:09:54,060 --> 00:09:57,540 which is a big deal because it means we can upload 191 00:09:57,540 --> 00:10:02,130 arbitrary SGZ files amongst other files to the ASA, 192 00:10:02,130 --> 00:10:03,930 which in theory should allow us to attack 193 00:10:03,930 --> 00:10:05,793 the administrator on Corpnet. 194 00:10:09,210 --> 00:10:12,210 We reported this to Cisco in February of this year 195 00:10:12,210 --> 00:10:15,780 and Cisco released this advisory without a patch in June. 196 00:10:15,780 --> 00:10:19,530 Again, I believe a patch was released a couple days ago, 197 00:10:19,530 --> 00:10:22,830 but I haven't gotten a chance to verify that. 198 00:10:22,830 --> 00:10:25,890 But either way, this advisory says exactly 199 00:10:25,890 --> 00:10:27,840 what we just discussed. 200 00:10:27,840 --> 00:10:32,010 Attackers can upload malicious ASDM packages to the ASA, 201 00:10:32,010 --> 00:10:35,130 which can result in code execution on hosts connecting 202 00:10:35,130 --> 00:10:36,063 to the router. 203 00:10:38,190 --> 00:10:40,770 So we're able to achieve what we set out to do. 204 00:10:40,770 --> 00:10:45,180 Hacker Cat has a malicious ASDM package hosted on the ASA. 205 00:10:45,180 --> 00:10:48,840 The only question that remains is how exactly does 206 00:10:48,840 --> 00:10:51,363 Hacker Cat craft this malicious package? 207 00:10:53,490 --> 00:10:55,080 Now there are actually a bunch of files 208 00:10:55,080 --> 00:10:57,690 in this binary package and there are a variety 209 00:10:57,690 --> 00:11:01,560 of attack vectors Hacker Cat can pursue with these files 210 00:11:01,560 --> 00:11:04,530 that all result in code execution. 211 00:11:04,530 --> 00:11:07,140 So I'm gonna highlight some of the files in the package 212 00:11:07,140 --> 00:11:07,990 and what they do. 213 00:11:11,250 --> 00:11:14,640 The package contains HTML and JavaScripts that make up 214 00:11:14,640 --> 00:11:17,430 the ASDM web portal on the ASA. 215 00:11:17,430 --> 00:11:19,890 Now these are obviously good vectors for phishing 216 00:11:19,890 --> 00:11:23,013 or browser exploitation, but they're not the best. 217 00:11:24,450 --> 00:11:28,770 The ASDM binary package contains ASDM client installers. 218 00:11:28,770 --> 00:11:32,250 There's an MSI for Windows and a DMG for Mac. 219 00:11:32,250 --> 00:11:35,520 And these MSI used to be unsigned until I told Cisco 220 00:11:35,520 --> 00:11:37,440 that probably wasn't great 221 00:11:37,440 --> 00:11:40,710 and they started signing the MSI in June of this year. 222 00:11:40,710 --> 00:11:43,770 But implanting your own installers is obviously 223 00:11:43,770 --> 00:11:45,423 a very good attack vector. 224 00:11:47,790 --> 00:11:50,370 The package contains all the files for launching ASDM 225 00:11:50,370 --> 00:11:52,110 via web start. 226 00:11:52,110 --> 00:11:54,840 Cisco just deprecated that functionality in June, 227 00:11:54,840 --> 00:11:57,870 so it's not that great of an attack vector anymore, 228 00:11:57,870 --> 00:12:00,090 but it's obviously a place that could lead 229 00:12:00,090 --> 00:12:01,353 to code execution. 230 00:12:03,570 --> 00:12:07,440 But as we've seen, the SGZ file is a really good vector 231 00:12:07,440 --> 00:12:10,050 and it originates in the ASDM binary package, 232 00:12:10,050 --> 00:12:11,490 so we might as well use it. 233 00:12:11,490 --> 00:12:15,240 So let's discuss a tool that will help Hacker Cat build 234 00:12:15,240 --> 00:12:17,673 malicious ASDM binary packages. 235 00:12:19,290 --> 00:12:22,140 And this is a tool I wrote to do this and it's called 236 00:12:22,140 --> 00:12:25,230 The Way and The Way has three major functions. 237 00:12:25,230 --> 00:12:28,650 It can partially extract ASDM packages to disk, 238 00:12:28,650 --> 00:12:31,110 which is really useful for examining and modifying 239 00:12:31,110 --> 00:12:32,583 the contents of a package. 240 00:12:34,320 --> 00:12:37,530 It can also rebuild extracted ASDM packages. 241 00:12:37,530 --> 00:12:41,700 So for example, in this slide, I modify the ASDM web portals 242 00:12:41,700 --> 00:12:45,030 indexed .HTML to say, "Hello DEF CON." 243 00:12:45,030 --> 00:12:48,510 Then I use The Way to rebuild a valid ASDM package. 244 00:12:48,510 --> 00:12:51,177 And when the new package is loaded on the ASA 245 00:12:51,177 --> 00:12:55,050 and we browse to the ASDM web portal that's hosted 246 00:12:55,050 --> 00:12:58,470 on the router, then we'll see, "Hello DEF CON", 247 00:12:58,470 --> 00:13:00,033 when we hit that landing page. 248 00:13:02,850 --> 00:13:05,700 And finally, The Way can generate straight-up 249 00:13:05,700 --> 00:13:08,100 malicious ASDM packages. 250 00:13:08,100 --> 00:13:11,430 These packages contain an SGZ file that will generate 251 00:13:11,430 --> 00:13:15,360 a reverse shell to an IPM port of the attacker's choosing 252 00:13:15,360 --> 00:13:18,450 whenever an ASDM client connects to the ASA. 253 00:13:18,450 --> 00:13:20,670 So pictured here, you can see both the command line 254 00:13:20,670 --> 00:13:22,680 for The Way and I diagram 255 00:13:22,680 --> 00:13:24,933 how that exploitation actually works. 256 00:13:26,850 --> 00:13:29,190 And this is how the attack looks in reality. 257 00:13:29,190 --> 00:13:31,560 You can see the ASDM launcher is up and running 258 00:13:31,560 --> 00:13:34,533 and a reverse shell has been sent to my (indistinct) box. 259 00:13:36,030 --> 00:13:38,400 So by crafting a malicious ASDM package, 260 00:13:38,400 --> 00:13:41,490 we can exploit ASDM clients not only connecting 261 00:13:41,490 --> 00:13:43,983 from the internet, but from Corpnet, as well. 262 00:13:45,450 --> 00:13:49,290 The only challenge is installing our malicious ASDM package. 263 00:13:49,290 --> 00:13:53,190 It does require elevated privileges to install this package 264 00:13:53,190 --> 00:13:57,060 on the ASA, so that's certainly a limiting factor. 265 00:13:57,060 --> 00:13:59,910 But, of course, attackers can find ways to get 266 00:13:59,910 --> 00:14:03,270 required credentials or they can use an inside attacker 267 00:14:03,270 --> 00:14:05,160 or trick an administrator into installing 268 00:14:05,160 --> 00:14:06,870 a malicious package. 269 00:14:06,870 --> 00:14:08,943 Those are all plausible vectors, 270 00:14:10,290 --> 00:14:13,290 but my favorite vector is a supply chain attack. 271 00:14:13,290 --> 00:14:17,580 When I bought our test 5506X with FirePOWER Services, 272 00:14:17,580 --> 00:14:20,400 it arrived with an ASDM package already loaded. 273 00:14:20,400 --> 00:14:21,540 I had no way of knowing if that was 274 00:14:21,540 --> 00:14:24,180 a valid Cisco ASDM package or not. 275 00:14:24,180 --> 00:14:26,250 The reseller could have planted a malicious package 276 00:14:26,250 --> 00:14:29,280 on my device and they could have gained code execution 277 00:14:29,280 --> 00:14:33,900 in my home network when I started using ASDM on the ASA. 278 00:14:33,900 --> 00:14:36,990 As we've seen, this isn't a theoretical threat, 279 00:14:36,990 --> 00:14:40,110 it's a viable and demonstratable attack 280 00:14:40,110 --> 00:14:42,480 that if done correctly, would actually leave the victim 281 00:14:42,480 --> 00:14:43,443 none the wiser. 282 00:14:45,600 --> 00:14:48,510 What's sort of interesting about a supply chain attack is 283 00:14:48,510 --> 00:14:51,690 that the ASDM software is actually updated separately 284 00:14:51,690 --> 00:14:53,580 from the ASA software, 285 00:14:53,580 --> 00:14:57,963 meaning updating the operating system won't update ASDM. 286 00:14:59,550 --> 00:15:00,900 And I got to wondering how often 287 00:15:00,900 --> 00:15:03,240 people actually update ASDM. 288 00:15:03,240 --> 00:15:05,700 Basically if no one is updating the software, 289 00:15:05,700 --> 00:15:09,540 our implant lasts forever and any bugs that we find 290 00:15:09,540 --> 00:15:11,910 in this software last forever. 291 00:15:11,910 --> 00:15:13,920 So I wrote a little tool to do some scanning 292 00:15:13,920 --> 00:15:16,563 of the ASA using ASDM on the internet. 293 00:15:17,970 --> 00:15:19,470 And here are the results. 294 00:15:19,470 --> 00:15:22,290 Basically no one updates the ASDM package, 295 00:15:22,290 --> 00:15:26,070 which is great for attackers and less good for defenders. 296 00:15:26,070 --> 00:15:29,790 At the time of scanning, 7.18.1 was the most recent version 297 00:15:29,790 --> 00:15:32,910 of ASDM and fewer than half of a percent 298 00:15:32,910 --> 00:15:35,130 of hosts were using that version. 299 00:15:35,130 --> 00:15:36,960 And we can see here the most popular version 300 00:15:36,960 --> 00:15:39,963 on the internet was released in 2017. 301 00:15:42,930 --> 00:15:45,060 So that's it for ASDM hackery. 302 00:15:45,060 --> 00:15:47,700 The rest of this talk will focus on a particular model 303 00:15:47,700 --> 00:15:51,840 of ASA called ASA-X with FirePOWER Services. 304 00:15:51,840 --> 00:15:55,110 And in this first section, we'll get a root shell 305 00:15:55,110 --> 00:15:57,123 on the system over HTTP. 306 00:15:58,650 --> 00:16:01,980 Now, as a reminder, these are the ASA-X 307 00:16:01,980 --> 00:16:03,870 with FirePOWER Services. 308 00:16:03,870 --> 00:16:06,930 They're the latest hardware model to use the ASA name 309 00:16:06,930 --> 00:16:09,540 and they're admittedly getting a bit long in the tooth, 310 00:16:09,540 --> 00:16:11,890 but they're still in support and used globally. 311 00:16:13,890 --> 00:16:16,350 Now the name FirePOWER Services actually describes 312 00:16:16,350 --> 00:16:18,750 a special feature on that ASA model. 313 00:16:18,750 --> 00:16:22,710 In particular, it describes this oval at the bottom labeled 314 00:16:22,710 --> 00:16:25,773 ASA FirePOWER module deep packet inspection. 315 00:16:27,030 --> 00:16:29,700 And what that FirePOWER module actually is 316 00:16:29,700 --> 00:16:31,920 is a virtual machine running Snort. 317 00:16:31,920 --> 00:16:35,460 Essentially, FirePOWER services is an IPS that's installed 318 00:16:35,460 --> 00:16:37,770 directly on the ASA itself. 319 00:16:37,770 --> 00:16:39,390 It's a pretty nifty feature. 320 00:16:39,390 --> 00:16:40,380 And from this diagram, 321 00:16:40,380 --> 00:16:42,900 we see that incoming traffic is diverted 322 00:16:42,900 --> 00:16:45,453 through this virtual machine for analysis. 323 00:16:46,680 --> 00:16:49,020 Now you can access the FirePOWER virtual machine 324 00:16:49,020 --> 00:16:50,820 via the Cisco CLI. 325 00:16:50,820 --> 00:16:54,390 The command session SFR console will drop you 326 00:16:54,390 --> 00:16:57,450 into a Telnet session, which prompts for creds. 327 00:16:57,450 --> 00:17:01,350 And once authenticated, you'll have this apparently limited 328 00:17:01,350 --> 00:17:03,033 FirePOWER module shell, 329 00:17:04,440 --> 00:17:06,360 except it isn't all that limited. 330 00:17:06,360 --> 00:17:08,970 By executing the expert command, you'll drop 331 00:17:08,970 --> 00:17:11,550 into a bash shell on the VM. 332 00:17:11,550 --> 00:17:13,620 And from there, you can actually pseudo to root using 333 00:17:13,620 --> 00:17:16,023 the previously used Telnet credentials. 334 00:17:17,400 --> 00:17:19,740 And this root shell, as a feature, isn't limited 335 00:17:19,740 --> 00:17:23,040 to terminal connections, you can also use it via SSH. 336 00:17:23,040 --> 00:17:26,130 So anyone with an SSH access to the ASA can grab 337 00:17:26,130 --> 00:17:28,503 a root shell in this virtual machine. 338 00:17:30,120 --> 00:17:32,070 Now that's particularly noteworthy because 339 00:17:32,070 --> 00:17:36,360 as a virtual machine when configured has network access, 340 00:17:36,360 --> 00:17:39,390 meaning it can communicate with the inside network 341 00:17:39,390 --> 00:17:41,820 that the ASA is supposed to be protecting 342 00:17:41,820 --> 00:17:44,040 and it can communicate with the outside network 343 00:17:44,040 --> 00:17:45,480 or the internet. 344 00:17:45,480 --> 00:17:48,720 An attacker that grabs a root shell on this VM can install 345 00:17:48,720 --> 00:17:53,100 arbitrary software, persist through reboots and upgrades, 346 00:17:53,100 --> 00:17:56,820 pivot attacks inwards, exfiltrate data out, and perhaps 347 00:17:56,820 --> 00:17:59,370 most interestingly to me, just chill out 348 00:17:59,370 --> 00:18:02,580 and sniff the traffic flowing through the virtual machine. 349 00:18:02,580 --> 00:18:04,800 And it's unlikely that anyone is actually monitoring 350 00:18:04,800 --> 00:18:07,143 this virtual machine for a malicious behavior. 351 00:18:08,760 --> 00:18:10,350 It's a really attractive place 352 00:18:10,350 --> 00:18:12,243 for an attacker to land and hide. 353 00:18:13,140 --> 00:18:16,050 And this type of root shell is actually something 354 00:18:16,050 --> 00:18:19,350 most vendors attempt to prevent, 355 00:18:19,350 --> 00:18:23,013 but it just so happens to be a feature of this model of ASA. 356 00:18:24,960 --> 00:18:27,720 Now Cisco obviously knows that this is dangerous 357 00:18:27,720 --> 00:18:30,030 because they have this lockdown sensor command 358 00:18:30,030 --> 00:18:33,030 that can disable the expert command and thus access 359 00:18:33,030 --> 00:18:33,993 to the root shell. 360 00:18:34,980 --> 00:18:37,650 But I'm not sure if this is actually used 361 00:18:37,650 --> 00:18:40,773 and our next exploit will bypass it anyways, so. 362 00:18:43,470 --> 00:18:46,440 So I was investigating how I can land in the root shell 363 00:18:46,440 --> 00:18:49,830 via HTTP, and it turned out ASDM can talk 364 00:18:49,830 --> 00:18:52,983 to the FirePOWER module and generate these pretty graphs. 365 00:18:54,450 --> 00:18:57,600 But ASDM can't access the root shell. 366 00:18:57,600 --> 00:19:01,440 If I use ASDM to issue the session SFR console command, 367 00:19:01,440 --> 00:19:04,200 then the ASA basically replies, you can't do 368 00:19:04,200 --> 00:19:06,933 interactive shells over HTTPs, so get outta here. 369 00:19:09,420 --> 00:19:10,560 So I started messing around 370 00:19:10,560 --> 00:19:13,230 with some command injection vectors and here's one 371 00:19:13,230 --> 00:19:15,180 that was actually successful. 372 00:19:15,180 --> 00:19:19,050 I issued the command session, SFR do backtick ID backtick 373 00:19:19,050 --> 00:19:21,003 where ID is a Linux command. 374 00:19:22,522 --> 00:19:24,930 And the Linux command will tell us 375 00:19:24,930 --> 00:19:27,720 who we executed the command as. 376 00:19:27,720 --> 00:19:30,510 So we can see that the ASA responded to the request 377 00:19:30,510 --> 00:19:32,490 with "invalid do command". 378 00:19:32,490 --> 00:19:34,140 Do would equal zero or root, 379 00:19:34,140 --> 00:19:37,230 meaning we successfully executed the command as root 380 00:19:37,230 --> 00:19:41,880 within this virtual machine which results in this scenario: 381 00:19:41,880 --> 00:19:44,610 an attacker over the internet can achieve a root shell 382 00:19:44,610 --> 00:19:46,470 on the FirePOWER module, 383 00:19:46,470 --> 00:19:49,800 on the FirePOWER module virtual machine by sending 384 00:19:49,800 --> 00:19:52,800 a rather simple command injection exploit. 385 00:19:52,800 --> 00:19:55,410 And the exploit is really simple. 386 00:19:55,410 --> 00:19:58,050 It's so simple you can put it in a tweet. 387 00:19:58,050 --> 00:20:00,000 So pictured here, you can see a tweetable version 388 00:20:00,000 --> 00:20:01,350 of the exploit. 389 00:20:01,350 --> 00:20:05,940 You see I used the curl utility bash dev TZP 390 00:20:05,940 --> 00:20:08,820 and net cat to throw the exploit and catch a reverse shell 391 00:20:08,820 --> 00:20:09,873 from the ASA. 392 00:20:11,430 --> 00:20:12,990 Again, this is great for an attacker. 393 00:20:12,990 --> 00:20:15,773 They now have their own malicious VM on the ASA to pivot 394 00:20:15,773 --> 00:20:18,423 inwards with and exfiltrate from. 395 00:20:19,740 --> 00:20:21,840 Now Cisco did release an advisory for this, 396 00:20:21,840 --> 00:20:24,780 but only after it was determined that it was a bypass 397 00:20:24,780 --> 00:20:27,030 for the lockdown sensor command. 398 00:20:27,030 --> 00:20:29,370 Cisco has released patches for most, but not all 399 00:20:29,370 --> 00:20:33,120 ASA exit FirePOWER Services and their advisory makes 400 00:20:33,120 --> 00:20:37,620 sort of big deal that the attack requires ASDM credentials, 401 00:20:37,620 --> 00:20:40,290 which is true, but those credentials might be 402 00:20:40,290 --> 00:20:42,810 easier to come by than you'd think. 403 00:20:42,810 --> 00:20:44,730 So I'm gonna list a few ways you might come 404 00:20:44,730 --> 00:20:46,323 by ASDM credentials. 405 00:20:47,640 --> 00:20:50,370 First recall that the ASDM client is vulnerable 406 00:20:50,370 --> 00:20:51,630 to Man in the Middle attacks. 407 00:20:51,630 --> 00:20:55,890 So additionally, by default, ASDM client authenticates 408 00:20:55,890 --> 00:20:59,580 the ASA using HTTP basic auth, which means 409 00:20:59,580 --> 00:21:02,970 a Man in the Middle can (indistinct) extract 410 00:21:02,970 --> 00:21:07,290 valid ASDM credentials from any HTTP request originating 411 00:21:07,290 --> 00:21:09,270 from the ASDM client. 412 00:21:09,270 --> 00:21:10,263 So there's one way. 413 00:21:12,030 --> 00:21:14,190 It's also worth noting that the default credentials 414 00:21:14,190 --> 00:21:17,400 for the ASDM interface are blank, blank. 415 00:21:17,400 --> 00:21:19,560 You don't have to take my word from that. 416 00:21:19,560 --> 00:21:23,310 This slide is taken directly from Cisco's "ASDM Book 1". 417 00:21:23,310 --> 00:21:27,213 And of course we confirm this is true on our own 5506X. 418 00:21:29,460 --> 00:21:31,740 And it also turns out the ASDM client was logging 419 00:21:31,740 --> 00:21:35,010 credentials to the client log for a long time. 420 00:21:35,010 --> 00:21:37,200 So I wrote this Metasploit module that will scan 421 00:21:37,200 --> 00:21:41,040 through ASDM log files and pull out valid credentials. 422 00:21:41,040 --> 00:21:42,340 So that's yet another way. 423 00:21:43,440 --> 00:21:45,810 And finally, the ASDM web interface doesn't have 424 00:21:45,810 --> 00:21:48,270 brute-force protection enabled by default. 425 00:21:48,270 --> 00:21:52,023 You have to go in and enable this account lockout feature. 426 00:21:54,240 --> 00:21:58,380 So the only thing that protects that interface by default is 427 00:21:58,380 --> 00:22:02,310 an ASDM-specific user agent, one version of which 428 00:22:02,310 --> 00:22:04,170 I've highlighted here. 429 00:22:04,170 --> 00:22:06,690 Without this user agent, the ASA ignores 430 00:22:06,690 --> 00:22:08,580 the inbound ASDM requests. 431 00:22:08,580 --> 00:22:10,830 So that is at least some type of protection, 432 00:22:10,830 --> 00:22:13,530 but I ended up writing a Metasploit module 433 00:22:13,530 --> 00:22:17,460 that will brute force this ASDM interface anyways. 434 00:22:17,460 --> 00:22:20,340 So that's another way to get credentials. 435 00:22:20,340 --> 00:22:23,520 And I know a lot of people don't like brute-force attacks 436 00:22:23,520 --> 00:22:25,350 because they aren't very cool, they certainly aren't 437 00:22:25,350 --> 00:22:29,100 elegant, but we've seen a number of APT, like GRU use 438 00:22:29,100 --> 00:22:32,010 brute-force attacks at scale with great success. 439 00:22:32,010 --> 00:22:34,050 And I'd suggest if it's good enough for GRU, 440 00:22:34,050 --> 00:22:35,650 it's good enough for me and you. 441 00:22:37,352 --> 00:22:39,600 (audience members laughing) 442 00:22:39,600 --> 00:22:41,970 So with credentials in hand, I also wrote 443 00:22:41,970 --> 00:22:43,620 a Metasploit module 444 00:22:43,620 --> 00:22:46,950 for the command injection issue over HTTP. 445 00:22:46,950 --> 00:22:49,470 Here, you can see we provide IPs and credentials, 446 00:22:49,470 --> 00:22:52,683 throw the exploit, and catch a reverse shell yet again. 447 00:22:54,030 --> 00:22:58,440 And this is sort of only semi-related, but I was messing 448 00:22:58,440 --> 00:23:01,380 around with this ASDM interface and figured out how to dump 449 00:23:01,380 --> 00:23:03,777 the running configuration over HTTP. 450 00:23:03,777 --> 00:23:06,660 And I actually think this shouldn't be possible, 451 00:23:06,660 --> 00:23:08,580 I don't think ASDM can do this. 452 00:23:08,580 --> 00:23:12,420 It did involve some Cisco CLI hackery, but anyways, 453 00:23:12,420 --> 00:23:14,610 if you do come along ASDM credentials, 454 00:23:14,610 --> 00:23:17,553 that's just another way to dump more creds. 455 00:23:20,250 --> 00:23:22,680 So we're going to switch our focus to abusing 456 00:23:22,680 --> 00:23:25,320 the installation of the FirePOWER module. 457 00:23:25,320 --> 00:23:27,420 Now, nothing in the remainder of this talk is 458 00:23:27,420 --> 00:23:30,540 actually considered a vulnerability by Cisco, 459 00:23:30,540 --> 00:23:33,093 but I'll let you be your own judge on that matter. 460 00:23:34,980 --> 00:23:36,870 Now interestingly, the FirePOWER module is 461 00:23:36,870 --> 00:23:40,080 an add-on package, kind of like the ASDM package, 462 00:23:40,080 --> 00:23:42,870 and it also has to be installed. 463 00:23:42,870 --> 00:23:46,110 The ASA-X works totally fine without it 464 00:23:46,110 --> 00:23:49,530 and if the user doesn't use the IPS feature, then likely 465 00:23:49,530 --> 00:23:51,690 they'll not want it installed in the first place. 466 00:23:51,690 --> 00:23:55,110 So a scenario where Hacker Cat has SSH access 467 00:23:55,110 --> 00:23:58,140 from the internet, but the FirePOWER module isn't installed 468 00:23:58,140 --> 00:23:59,970 isn't that farfetched. 469 00:23:59,970 --> 00:24:02,160 But without the FirePOWER module installed, 470 00:24:02,160 --> 00:24:04,870 Hacker Cat can't access that special root shell 471 00:24:06,780 --> 00:24:07,980 or can he? 472 00:24:07,980 --> 00:24:10,140 So let's see how Hacker Cat can get that shell 473 00:24:10,140 --> 00:24:12,093 by using the FirePOWER boot image. 474 00:24:13,020 --> 00:24:16,170 Now the FirePOWER boot image, the FirePOWER module 475 00:24:16,170 --> 00:24:18,780 installation process is really involved. 476 00:24:18,780 --> 00:24:21,360 It takes three different steps. 477 00:24:21,360 --> 00:24:23,940 But first you have to install a boot image, 478 00:24:23,940 --> 00:24:25,950 which is labeled number one here. 479 00:24:25,950 --> 00:24:29,430 Then you have to install an install package, 480 00:24:29,430 --> 00:24:31,170 which is labeled number two. 481 00:24:31,170 --> 00:24:33,900 And finally, you have to install an upgrade package, 482 00:24:33,900 --> 00:24:36,990 which is not even on this page and not numbered. 483 00:24:36,990 --> 00:24:38,670 But we are talking about phase one here, 484 00:24:38,670 --> 00:24:40,743 installing and using the boot image. 485 00:24:41,760 --> 00:24:44,460 The boot image needs to be downloaded from Cisco and copied 486 00:24:44,460 --> 00:24:48,030 onto the ASA or an image might already be present 487 00:24:48,030 --> 00:24:51,240 on your system, as was the case with our test device 488 00:24:51,240 --> 00:24:53,010 when we purchased it. 489 00:24:53,010 --> 00:24:55,290 Either way, once the image is on the ASA, 490 00:24:55,290 --> 00:24:57,450 you issue two commands to boot it. 491 00:24:57,450 --> 00:25:00,570 The first command lets the ASA know this is the boot image 492 00:25:00,570 --> 00:25:01,557 that you want to use 493 00:25:01,557 --> 00:25:03,873 and the second command actually boots it. 494 00:25:05,190 --> 00:25:08,160 You can then issue the session SFR console command to open 495 00:25:08,160 --> 00:25:10,680 up a Telnet connection to the boot image 496 00:25:10,680 --> 00:25:12,660 and you'll be prompted for creds. 497 00:25:12,660 --> 00:25:14,280 Pictured here is the default credentials 498 00:25:14,280 --> 00:25:16,710 for the various versions of the boot image. 499 00:25:16,710 --> 00:25:19,413 But note the default user is always admin. 500 00:25:20,970 --> 00:25:24,270 So once authenticated, you'll drop down into this shell 501 00:25:24,270 --> 00:25:25,560 on the boot image. 502 00:25:25,560 --> 00:25:28,380 Now this is actually an extremely limited gel. 503 00:25:28,380 --> 00:25:31,140 It's really only useful for installing stage two, 504 00:25:31,140 --> 00:25:33,000 the install package. 505 00:25:33,000 --> 00:25:35,220 It doesn't have anything like the expert command 506 00:25:35,220 --> 00:25:37,140 we saw previously. 507 00:25:37,140 --> 00:25:39,610 So let's actually take one step backwards 508 00:25:40,800 --> 00:25:44,490 and instead log in as this undocumented user root 509 00:25:44,490 --> 00:25:47,220 with a password Cisco123. 510 00:25:47,220 --> 00:25:49,113 And bam, you got root shell. 511 00:25:50,940 --> 00:25:53,700 And what's great about that is the boot image is 512 00:25:53,700 --> 00:25:54,810 networks too. 513 00:25:54,810 --> 00:25:59,640 So using hardcoded creds on the boot image gives Hacker Cat 514 00:25:59,640 --> 00:26:01,860 that special root shell once again. 515 00:26:01,860 --> 00:26:03,990 Now Cisco said this is not a vulnerability 516 00:26:03,990 --> 00:26:06,210 because there are no security expectations 517 00:26:06,210 --> 00:26:08,823 during the FirePOWER installation process. 518 00:26:10,740 --> 00:26:12,480 They had the same response when we reported 519 00:26:12,480 --> 00:26:15,660 that command injection issue in the boot image. 520 00:26:15,660 --> 00:26:18,690 This pictured injection is in the logic for installing 521 00:26:18,690 --> 00:26:21,300 part two of the FirePOWER module. 522 00:26:21,300 --> 00:26:23,250 But I just want to emphasize 523 00:26:23,250 --> 00:26:26,193 the boot image contains no vulnerabilities. 524 00:26:28,260 --> 00:26:29,430 But vulnerability or not, 525 00:26:29,430 --> 00:26:31,680 the hardcoded credits are dead useful. 526 00:26:31,680 --> 00:26:34,080 And I've written a couple of exploits that automate 527 00:26:34,080 --> 00:26:36,690 the uploading and configuration needed to take advantage 528 00:26:36,690 --> 00:26:40,080 of this non-vulnerability and both exploits end 529 00:26:40,080 --> 00:26:41,763 by catching a reverse shell. 530 00:26:42,780 --> 00:26:45,900 The Metasploit version is a bit better because it catches 531 00:26:45,900 --> 00:26:47,400 a reverse interpreter shell. 532 00:26:47,400 --> 00:26:50,010 Now Cisco did remove the hardcoded credentials 533 00:26:50,010 --> 00:26:52,710 from a recent version of the boot image. 534 00:26:52,710 --> 00:26:55,500 But since the ASA doesn't prevent you from using 535 00:26:55,500 --> 00:26:57,420 older boot images, I can't say it's 536 00:26:57,420 --> 00:27:00,060 a particularly useful mitigation. 537 00:27:00,060 --> 00:27:02,133 In my mind, it's kind of a forever day. 538 00:27:04,530 --> 00:27:07,170 Now the problem with the previous attack is it assumed 539 00:27:07,170 --> 00:27:11,280 SSH access, which is obviously not going to typically 540 00:27:11,280 --> 00:27:13,323 be available for an attacker. 541 00:27:16,526 --> 00:27:18,300 I want to figure out some attacks that assumed 542 00:27:18,300 --> 00:27:20,280 no access to the device. 543 00:27:20,280 --> 00:27:23,520 I want to modify FirePOWER install packages to include 544 00:27:23,520 --> 00:27:26,640 malicious code and then get unwitting victims to install 545 00:27:26,640 --> 00:27:28,650 those malicious packages. 546 00:27:28,650 --> 00:27:30,813 So again, let's visit the boot image. 547 00:27:32,610 --> 00:27:35,250 So this is the scenario I'm visiting. 548 00:27:35,250 --> 00:27:37,620 Hacker Cat is totally on the outside, 549 00:27:37,620 --> 00:27:39,093 has no access to the ASA. 550 00:27:40,099 --> 00:27:42,593 He's just sitting out there in the cold all alone. 551 00:27:44,070 --> 00:27:47,070 So to help Hacker Cat get back to his root shell, 552 00:27:47,070 --> 00:27:49,980 I started looking at the format, the boot image, 553 00:27:49,980 --> 00:27:52,380 and it turns out it's just a totally generic 554 00:27:52,380 --> 00:27:55,890 bootable Linux ISO, like it's just a live CD. 555 00:27:55,890 --> 00:27:58,710 You can actually execute it with VMware Fusion 556 00:27:58,710 --> 00:28:02,670 or whatever virtual machine system you like. 557 00:28:02,670 --> 00:28:04,440 There's really nothing Cisco-specific 558 00:28:04,440 --> 00:28:06,213 about the boot image's format. 559 00:28:08,070 --> 00:28:12,270 So I figured, well, why don't I just create my own live CD, 560 00:28:12,270 --> 00:28:17,270 my own bootable Linux ISO, give that to an administrator, 561 00:28:17,460 --> 00:28:19,530 get them to install it? 562 00:28:19,530 --> 00:28:21,930 Then the ASA should boot the malicious ISO. 563 00:28:21,930 --> 00:28:25,440 Because my operating theory was that the Cisco-provided 564 00:28:25,440 --> 00:28:29,433 FirePOWER boot image was just a normal live CD or whatever. 565 00:28:31,656 --> 00:28:34,890 And usually stories like this have a lot more to them, 566 00:28:34,890 --> 00:28:37,140 what you tried, what failed. 567 00:28:37,140 --> 00:28:40,080 But the funny thing is, this just works. 568 00:28:40,080 --> 00:28:43,680 I grabbed an existing script for creating tiny core 569 00:28:43,680 --> 00:28:45,450 Linux bootable ISOs. 570 00:28:45,450 --> 00:28:48,840 I added in a few features: the ability to play Doom, 571 00:28:48,840 --> 00:28:53,160 a reverse shell, the essentials, and this script 572 00:28:53,160 --> 00:28:56,700 which I rebranded as Pinch Me generates a malicious ISO 573 00:28:56,700 --> 00:29:00,750 that the ASA will happily boot and assign IP addresses to. 574 00:29:00,750 --> 00:29:01,800 There's no trial and error 575 00:29:01,800 --> 00:29:05,250 because the ASA doesn't attempt to block this behavior. 576 00:29:05,250 --> 00:29:07,770 I guess booting arbitrary virtual machines 577 00:29:07,770 --> 00:29:10,650 on the ASA-X is just a feature. 578 00:29:10,650 --> 00:29:13,260 But again, this isn't a vulnerability 579 00:29:13,260 --> 00:29:16,233 because there's no security expectations on the boot image. 580 00:29:18,300 --> 00:29:20,520 So we can craft our own booted images, 581 00:29:20,520 --> 00:29:24,240 distribute them as we'd like, and once installed, have 582 00:29:24,240 --> 00:29:26,523 special access to this root shell once again. 583 00:29:27,750 --> 00:29:29,850 And we can play Doom-ASCII. 584 00:29:29,850 --> 00:29:31,620 Now this is sort of cheating because it's running 585 00:29:31,620 --> 00:29:34,800 on the virtual machine, but I'm forever going to say 586 00:29:34,800 --> 00:29:38,103 that I ran Doom on the ASA-X with FirePOWER Services. 587 00:29:39,420 --> 00:29:42,300 One downside is that I didn't find a way to drop 588 00:29:42,300 --> 00:29:44,970 into the Doom via the session SFR console 589 00:29:44,970 --> 00:29:47,760 'cause there's some type of kernel module involved. 590 00:29:47,760 --> 00:29:50,280 So you have to use this SSH session that I set up, 591 00:29:50,280 --> 00:29:52,593 but it's good enough for a hack. 592 00:29:54,720 --> 00:29:57,870 But the problem with just attacking the system 593 00:29:57,870 --> 00:30:00,360 with a boot image is that it doesn't persist 594 00:30:00,360 --> 00:30:01,680 through reboots. 595 00:30:01,680 --> 00:30:03,567 So I started looking at the install package 596 00:30:03,567 --> 00:30:05,523 for a more sustained attack. 597 00:30:06,840 --> 00:30:09,210 Now remember the install package is part two 598 00:30:09,210 --> 00:30:11,670 of the FirePOWER module installation. 599 00:30:11,670 --> 00:30:15,300 The install package is installed by and overwrites 600 00:30:15,300 --> 00:30:16,263 the boot image. 601 00:30:17,340 --> 00:30:20,190 So I was trying to figure out the format of the boot image, 602 00:30:20,190 --> 00:30:22,350 the format the boot image expects 603 00:30:22,350 --> 00:30:24,390 the install package to be in. 604 00:30:24,390 --> 00:30:27,150 So pictured here is Python tech taken directly 605 00:30:27,150 --> 00:30:30,300 from the boot image and you can see that expects 606 00:30:30,300 --> 00:30:33,930 the install package to be written in the encrypted content 607 00:30:33,930 --> 00:30:36,723 signed checksum package wrapper format. 608 00:30:38,280 --> 00:30:40,740 It's a pretty secure format as far as I can tell. 609 00:30:40,740 --> 00:30:44,820 And somewhat importantly, it's the only format that I think 610 00:30:44,820 --> 00:30:48,390 Cisco has ever published the install package in, 611 00:30:48,390 --> 00:30:50,703 at least dating back to 2016. 612 00:30:52,801 --> 00:30:54,300 And it looks like this. 613 00:30:54,300 --> 00:30:56,880 This isn't super important to know, just note that it starts 614 00:30:56,880 --> 00:31:00,363 with this keyword "key" very early on into the file. 615 00:31:02,010 --> 00:31:04,710 But it also turns out that the boot image has this if clause 616 00:31:04,710 --> 00:31:09,300 for the FirePOWER module and that if clause allows 617 00:31:09,300 --> 00:31:11,610 for a second install package format. 618 00:31:11,610 --> 00:31:14,940 And this format is called checksum package wrapper 619 00:31:14,940 --> 00:31:18,030 and is actually an utterly insecure format. 620 00:31:18,030 --> 00:31:20,460 There's no Cisco signature on this one and it only has 621 00:31:20,460 --> 00:31:24,420 checksums like we saw with the ASDM package, 622 00:31:24,420 --> 00:31:26,490 which means in theory, we should be able to craft 623 00:31:26,490 --> 00:31:28,497 one of these checksum install packages 624 00:31:28,497 --> 00:31:31,350 and the administrator should be able to install it, 625 00:31:31,350 --> 00:31:33,843 resulting in route shell access once again. 626 00:31:35,160 --> 00:31:36,960 And after some tedious reverse engineering, 627 00:31:36,960 --> 00:31:38,790 I did figure out that format. 628 00:31:38,790 --> 00:31:41,490 Again, it's not important, just note that the file 629 00:31:41,490 --> 00:31:43,140 no longer starts with a "key" keyword, 630 00:31:43,140 --> 00:31:44,613 it goes straight in the data. 631 00:31:46,800 --> 00:31:50,430 Now the problem is that we actually need 632 00:31:50,430 --> 00:31:53,850 the install package to do its job, namely install 633 00:31:53,850 --> 00:31:55,620 a whole bunch of Cisco stuff 634 00:31:55,620 --> 00:31:57,690 and then overwrite the boot image. 635 00:31:57,690 --> 00:32:00,210 Otherwise the install process will fail. 636 00:32:00,210 --> 00:32:03,660 So it isn't enough to know this insecure format, 637 00:32:03,660 --> 00:32:07,350 we need the insecure checksum package to also contain 638 00:32:07,350 --> 00:32:09,420 all the Cisco stuff as well 639 00:32:09,420 --> 00:32:11,733 so that installation will actually succeed. 640 00:32:14,100 --> 00:32:15,888 So I wrote a tool that does that. 641 00:32:15,888 --> 00:32:17,220 This tool called What's Up. 642 00:32:17,220 --> 00:32:20,340 It takes in a valid and signed installation package, 643 00:32:20,340 --> 00:32:23,670 unpackages it, inserts malicious code, 644 00:32:23,670 --> 00:32:28,140 and then repackages it into this insecure format, 645 00:32:28,140 --> 00:32:31,113 ready to be installed by an unwitting victim. 646 00:32:32,580 --> 00:32:35,400 Now the malicious code is just this init script. 647 00:32:35,400 --> 00:32:37,410 Basically it tries to connect to an IPM port 648 00:32:37,410 --> 00:32:39,900 of the attackers choosing every five minutes. 649 00:32:39,900 --> 00:32:42,780 And this init script will survive reboots and even upgrades, 650 00:32:42,780 --> 00:32:45,360 so it's a pretty useful little attack. 651 00:32:45,360 --> 00:32:47,820 All you need is to get someone to install it. 652 00:32:47,820 --> 00:32:50,553 But remember this is still not a vulnerability. 653 00:32:53,190 --> 00:32:56,760 But the result, again, if installed is Hacker Cat is back 654 00:32:56,760 --> 00:32:59,793 in the root shell and this time with persistence. 655 00:33:01,448 --> 00:33:03,960 Now I actually described this to Cisco as a potential 656 00:33:03,960 --> 00:33:07,260 supply chain attack as well, but they disagreed. 657 00:33:07,260 --> 00:33:09,450 They pointed out that the FirePOWER module has 658 00:33:09,450 --> 00:33:13,590 a root shell feature and a vendor could simply insert 659 00:33:13,590 --> 00:33:16,200 arbitrary code into the virtual machine using 660 00:33:16,200 --> 00:33:17,550 that root shell. 661 00:33:17,550 --> 00:33:21,060 So no malicious installation package required. 662 00:33:21,060 --> 00:33:25,650 Which I agree is 100% true, but to me that's a separate 663 00:33:25,650 --> 00:33:28,740 and also concerning supply chain attack. 664 00:33:28,740 --> 00:33:31,490 But I wasn't able to win them over to my point of view. 665 00:33:33,750 --> 00:33:36,030 So that's all the hacks I have for you. 666 00:33:36,030 --> 00:33:38,700 In this talk, we discussed Man in the Middle problems, 667 00:33:38,700 --> 00:33:41,010 credential leaks, code signing issues, 668 00:33:41,010 --> 00:33:43,770 package signing issues, root shell as a feature, 669 00:33:43,770 --> 00:33:46,260 hard-coded credentials for a root shell, 670 00:33:46,260 --> 00:33:47,850 command injection for root access, 671 00:33:47,850 --> 00:33:50,820 and executing arbitrary bootable ISO. 672 00:33:50,820 --> 00:33:54,333 Many of these make the ASA a perfect little Trojan horse. 673 00:33:56,051 --> 00:33:58,050 Now having said all that, let's take a quick look 674 00:33:58,050 --> 00:34:00,543 at some indicators and possible mitigations. 675 00:34:02,340 --> 00:34:05,280 The number one thing I hope is taken away from this talk is 676 00:34:05,280 --> 00:34:06,720 that this can never be done. 677 00:34:06,720 --> 00:34:08,700 Never can you use ASDM over the internet 678 00:34:08,700 --> 00:34:11,460 without potentially risking your ASA. 679 00:34:11,460 --> 00:34:13,470 The Man in the Middle issue that we talked about, 680 00:34:13,470 --> 00:34:16,920 to my knowledge is actually not slated to be fixed. 681 00:34:16,920 --> 00:34:20,430 I would actually encourage you to stop using ASDM altogether 682 00:34:20,430 --> 00:34:22,593 and disable that feature on your ASA. 683 00:34:24,360 --> 00:34:27,150 I've written a few YARA rules to help identify 684 00:34:27,150 --> 00:34:29,460 some of these attacks we've talked about. 685 00:34:29,460 --> 00:34:32,790 One rule will detect malicious ASDM packages 686 00:34:32,790 --> 00:34:36,360 and another detects unsigned install packages. 687 00:34:36,360 --> 00:34:38,550 The other two will look through the ASDM log files 688 00:34:38,550 --> 00:34:42,483 for credentials or signs of malicious SGZ usage. 689 00:34:45,540 --> 00:34:48,420 Now ideally, I'd love to give patching guidance, 690 00:34:48,420 --> 00:34:51,150 however, there are a slew of issues in this talk 691 00:34:51,150 --> 00:34:54,540 that are not considered vulnerabilities or unpatched 692 00:34:54,540 --> 00:34:57,870 or their patch status isn't clear as of today. 693 00:34:57,870 --> 00:35:00,690 When patching isn't an option, we usually apply 694 00:35:00,690 --> 00:35:04,440 mitigating controls which is isolate and limit access. 695 00:35:04,440 --> 00:35:08,400 And that's not easy because the ASA is a critical system 696 00:35:08,400 --> 00:35:10,200 in a given network. 697 00:35:10,200 --> 00:35:14,100 At very least, like I said, I'd suggest disabling ASDM 698 00:35:14,100 --> 00:35:15,330 and ensure that you're auditing 699 00:35:15,330 --> 00:35:17,550 who's logging into your system. 700 00:35:17,550 --> 00:35:19,860 Now we saw a number of password issues in this talk, 701 00:35:19,860 --> 00:35:22,650 so rotating passwords might be a good idea. 702 00:35:22,650 --> 00:35:24,570 But finally, when it comes to the ASA-X 703 00:35:24,570 --> 00:35:27,300 with FirePOWER Services, I actually think 704 00:35:27,300 --> 00:35:30,210 this root shell feature is far too dangerous, 705 00:35:30,210 --> 00:35:34,080 even without all the packaging issues that we discussed. 706 00:35:34,080 --> 00:35:37,350 So I'd suggest retiring and replacing those devices. 707 00:35:37,350 --> 00:35:40,410 And until you do that, you should spend some time looking 708 00:35:40,410 --> 00:35:42,960 at the root shell on the device to ensure you know 709 00:35:42,960 --> 00:35:44,210 what's going on in there. 710 00:35:46,170 --> 00:35:47,850 So that's actually it. 711 00:35:47,850 --> 00:35:49,500 All the code I mentioned 712 00:35:49,500 --> 00:35:52,230 and a lot more, actually, is up on GitHub. 713 00:35:52,230 --> 00:35:55,410 If you liked this talk, you can find me on social media 714 00:35:55,410 --> 00:35:57,990 at the normal places. 715 00:35:57,990 --> 00:35:58,860 That's it. 716 00:35:58,860 --> 00:35:59,843 Thank you. 717 00:35:59,843 --> 00:36:02,926 (audience clapping)