1 00:00:01,280 --> 00:00:12,559 [Music] 2 00:00:15,360 --> 00:00:17,760 what is an industrial control system it 3 00:00:17,760 --> 00:00:20,000 is a system which controls industrial 4 00:00:20,000 --> 00:00:22,080 processes you may have also heard them 5 00:00:22,080 --> 00:00:24,640 referred to as scada systems um and you 6 00:00:24,640 --> 00:00:26,720 can find them in power plants water 7 00:00:26,720 --> 00:00:28,800 treatment centers all sorts of critical 8 00:00:28,800 --> 00:00:30,640 infrastructure um 9 00:00:30,640 --> 00:00:32,558 you would think that these would be 10 00:00:32,558 --> 00:00:36,480 super secure locked down um are they 11 00:00:36,480 --> 00:00:38,160 are they there's so many 12 00:00:38,160 --> 00:00:39,600 vulnerabilities there's so many hacks 13 00:00:39,600 --> 00:00:40,559 you've probably heard about them in the 14 00:00:40,559 --> 00:00:41,840 news 15 00:00:41,840 --> 00:00:43,520 these two folks here are two people who 16 00:00:43,520 --> 00:00:45,280 are well aware of the insecurities of 17 00:00:45,280 --> 00:00:47,680 ics um they both come to us from 18 00:00:47,680 --> 00:00:49,520 compotest 19 00:00:49,520 --> 00:00:51,360 they in fact 20 00:00:51,360 --> 00:00:55,280 compete in competitions to hack ics 21 00:00:55,280 --> 00:00:57,600 systems and they in fact won this year 22 00:00:57,600 --> 00:01:00,640 in miami i believe so i think we can all 23 00:01:00,640 --> 00:01:03,039 be impressed by that um please give a 24 00:01:03,039 --> 00:01:07,430 good warm mch welcome to dais and don 25 00:01:07,430 --> 00:01:09,650 [Music] 26 00:01:09,650 --> 00:01:14,000 [Applause] 27 00:01:14,000 --> 00:01:16,240 thank you thank you 28 00:01:16,240 --> 00:01:18,880 so ics security is becoming more and 29 00:01:18,880 --> 00:01:21,200 more important now that factories are 30 00:01:21,200 --> 00:01:24,159 connecting more ics devices to either 31 00:01:24,159 --> 00:01:26,960 the internal i.t network or in some 32 00:01:26,960 --> 00:01:30,159 situations even directly to the internet 33 00:01:30,159 --> 00:01:33,280 so this talk is the result of some 34 00:01:33,280 --> 00:01:35,520 research we did in software that's 35 00:01:35,520 --> 00:01:38,799 commonly used in ics networks 36 00:01:38,799 --> 00:01:40,400 and at the front and the vulnerabilities 37 00:01:40,400 --> 00:01:42,799 we found 38 00:01:42,799 --> 00:01:43,600 so 39 00:01:43,600 --> 00:01:45,600 my name is dan cooper i'm here together 40 00:01:45,600 --> 00:01:48,479 with my colleague tyson kamada 41 00:01:48,479 --> 00:01:50,720 we work for computest a full-service 42 00:01:50,720 --> 00:01:52,880 security provider in the netherlands we 43 00:01:52,880 --> 00:01:55,360 do everything from plantation testing to 44 00:01:55,360 --> 00:01:56,880 incident response 45 00:01:56,880 --> 00:01:58,079 but we too 46 00:01:58,079 --> 00:01:58,960 are 47 00:01:58,960 --> 00:02:01,520 the research facility meaning we get to 48 00:02:01,520 --> 00:02:03,759 research cool stuff and talk at 49 00:02:03,759 --> 00:02:05,280 conferences about it 50 00:02:05,280 --> 00:02:07,280 so if you have any follow-up questions 51 00:02:07,280 --> 00:02:09,119 after this presentation we have a big 52 00:02:09,119 --> 00:02:11,280 tent full of arcade games on the retro 53 00:02:11,280 --> 00:02:14,319 square so feel free to drop by and 54 00:02:14,319 --> 00:02:17,599 we can have a talk and a beer 55 00:02:18,160 --> 00:02:19,200 so 56 00:02:19,200 --> 00:02:22,640 last april we won pontoon miami which 57 00:02:22,640 --> 00:02:25,040 was upon to own addition specifically 58 00:02:25,040 --> 00:02:28,319 about ics security 59 00:02:28,319 --> 00:02:30,959 so this was the result of a couple of 60 00:02:30,959 --> 00:02:32,879 weeks of research we did prior to the 61 00:02:32,879 --> 00:02:35,599 competition and during this talk we 62 00:02:35,599 --> 00:02:37,840 would like to share as much as we are 63 00:02:37,840 --> 00:02:40,160 allowed to about the vulnerabilities we 64 00:02:40,160 --> 00:02:42,160 we found during this competition and we 65 00:02:42,160 --> 00:02:46,480 demonstrated successfully during pontoon 66 00:02:46,640 --> 00:02:50,080 however before we go into the details 67 00:02:50,080 --> 00:02:53,440 we noticed that when the news was uh 68 00:02:53,440 --> 00:02:56,160 published about our victory in ponzuo 69 00:02:56,160 --> 00:02:58,720 that not everybody is familiar with the 70 00:02:58,720 --> 00:03:01,200 competition and how it works because the 71 00:03:01,200 --> 00:03:03,440 main comments were about the fact if we 72 00:03:03,440 --> 00:03:05,280 indeed use this mac os as our main 73 00:03:05,280 --> 00:03:08,159 operating system or if we run kali linux 74 00:03:08,159 --> 00:03:10,720 on it for our security research 75 00:03:10,720 --> 00:03:11,519 so 76 00:03:11,519 --> 00:03:14,400 before we dive into all the details 77 00:03:14,400 --> 00:03:16,080 i'm going to head over to tais and he's 78 00:03:16,080 --> 00:03:17,360 going to tell you a little bit more 79 00:03:17,360 --> 00:03:19,200 about the pawn to own competition and 80 00:03:19,200 --> 00:03:20,640 what the rules are and how you can 81 00:03:20,640 --> 00:03:22,159 compete 82 00:03:22,159 --> 00:03:23,120 yes 83 00:03:23,120 --> 00:03:24,319 so 84 00:03:24,319 --> 00:03:26,159 pawn to own was started 85 00:03:26,159 --> 00:03:28,480 15 years ago 86 00:03:28,480 --> 00:03:29,840 and the idea is that you need to 87 00:03:29,840 --> 00:03:32,400 demonstrate new zero-day vulnerabilities 88 00:03:32,400 --> 00:03:36,319 against a target in a live environment 89 00:03:36,319 --> 00:03:37,360 to win a 90 00:03:37,360 --> 00:03:39,519 money price and to also win the the 91 00:03:39,519 --> 00:03:41,200 laptop that you hack 92 00:03:41,200 --> 00:03:43,120 now there currently are three different 93 00:03:43,120 --> 00:03:45,120 editions for this there's the vancouver 94 00:03:45,120 --> 00:03:47,360 edition there's the miami edition which 95 00:03:47,360 --> 00:03:49,840 we participated in for ics 96 00:03:49,840 --> 00:03:50,959 and there's the 97 00:03:50,959 --> 00:03:53,599 tokyo edition or it moves around a bit 98 00:03:53,599 --> 00:03:55,760 for 99 00:03:55,840 --> 00:03:58,720 iot devices like phones 100 00:03:58,720 --> 00:04:01,120 tvs stuff like that 101 00:04:01,120 --> 00:04:03,680 so the idea behind ponzone is that 102 00:04:03,680 --> 00:04:06,080 around three months before the actual 103 00:04:06,080 --> 00:04:08,799 on-site demonstration they announced the 104 00:04:08,799 --> 00:04:10,159 targets 105 00:04:10,159 --> 00:04:12,080 and then for each target there's a cash 106 00:04:12,080 --> 00:04:13,280 prize 107 00:04:13,280 --> 00:04:15,040 and they select these targets based on 108 00:04:15,040 --> 00:04:16,880 what they think are interesting 109 00:04:16,880 --> 00:04:18,560 applications in 110 00:04:18,560 --> 00:04:20,238 that environment 111 00:04:20,238 --> 00:04:22,160 so in this case there's a control server 112 00:04:22,160 --> 00:04:24,720 category with two applications and you 113 00:04:24,720 --> 00:04:26,400 need to demonstrate a remote code 114 00:04:26,400 --> 00:04:28,960 execution vulnerability here 115 00:04:28,960 --> 00:04:31,680 either over the network or you need to 116 00:04:31,680 --> 00:04:34,080 let somebody open a file on that machine 117 00:04:34,080 --> 00:04:37,039 for that application 118 00:04:37,199 --> 00:04:38,800 and that can also be different kind of 119 00:04:38,800 --> 00:04:40,840 targets so 120 00:04:40,840 --> 00:04:43,759 in ponzo miami this time 121 00:04:43,759 --> 00:04:45,759 there were 122 00:04:45,759 --> 00:04:49,199 there was the opc ua server category 123 00:04:49,199 --> 00:04:51,919 there were three different levels of 124 00:04:51,919 --> 00:04:53,360 payload 125 00:04:53,360 --> 00:04:54,800 if you have a 126 00:04:54,800 --> 00:04:56,800 denial of service payload 127 00:04:56,800 --> 00:04:58,880 then you get five points and five 128 00:04:58,880 --> 00:05:00,160 thousand dollars 129 00:05:00,160 --> 00:05:02,639 because even just being able to crash a 130 00:05:02,639 --> 00:05:05,840 ics application can be very serious if 131 00:05:05,840 --> 00:05:07,600 it's something that for example controls 132 00:05:07,600 --> 00:05:09,600 the electrical grid 133 00:05:09,600 --> 00:05:11,759 and then the next level was 134 00:05:11,759 --> 00:05:14,000 remote code execution so taking over the 135 00:05:14,000 --> 00:05:15,120 machine 136 00:05:15,120 --> 00:05:17,280 but there was even a higher level here 137 00:05:17,280 --> 00:05:19,280 which was the bypassing the trusted 138 00:05:19,280 --> 00:05:21,120 application check 139 00:05:21,120 --> 00:05:23,280 and the reason this is higher is because 140 00:05:23,280 --> 00:05:25,600 remote code execution can be after 141 00:05:25,600 --> 00:05:27,120 authentication 142 00:05:27,120 --> 00:05:28,720 so they really wanted to make sure that 143 00:05:28,720 --> 00:05:30,960 the authentication was working correctly 144 00:05:30,960 --> 00:05:34,160 which is why this got more points 145 00:05:34,160 --> 00:05:35,840 and a bigger reward if you could 146 00:05:35,840 --> 00:05:37,199 demonstrate that 147 00:05:37,199 --> 00:05:40,240 i'll talk more about that later 148 00:05:40,240 --> 00:05:42,240 so the idea behind this competition is 149 00:05:42,240 --> 00:05:44,560 that they announce the targets and 150 00:05:44,560 --> 00:05:46,479 everybody who wants can just start 151 00:05:46,479 --> 00:05:49,120 researching it finding stuff and writing 152 00:05:49,120 --> 00:05:50,720 exploits for it 153 00:05:50,720 --> 00:05:51,759 and then 154 00:05:51,759 --> 00:05:52,960 you need to 155 00:05:52,960 --> 00:05:55,680 enter into the competition you need to 156 00:05:55,680 --> 00:05:58,080 submit your application 157 00:05:58,080 --> 00:05:59,600 and then nowadays you can also 158 00:05:59,600 --> 00:06:01,600 participate online but you can also go 159 00:06:01,600 --> 00:06:02,400 there 160 00:06:02,400 --> 00:06:03,840 and then you need to demonstrate your 161 00:06:03,840 --> 00:06:04,960 exploit 162 00:06:04,960 --> 00:06:07,120 against a live target 163 00:06:07,120 --> 00:06:08,800 and to do that you get 164 00:06:08,800 --> 00:06:10,319 20 minutes 165 00:06:10,319 --> 00:06:12,319 and three attempts and each attempt can 166 00:06:12,319 --> 00:06:15,039 only take at most five minutes so you 167 00:06:15,039 --> 00:06:16,960 really need to have an efficient exploit 168 00:06:16,960 --> 00:06:19,199 that runs well 169 00:06:19,199 --> 00:06:20,960 and yeah you need to make sure that you 170 00:06:20,960 --> 00:06:23,280 don't need to update it in between but 171 00:06:23,280 --> 00:06:24,720 you can prepare 172 00:06:24,720 --> 00:06:26,720 quite a long time in advance 173 00:06:26,720 --> 00:06:28,720 so normally it's three months but in 174 00:06:28,720 --> 00:06:30,400 this case because of covert they had to 175 00:06:30,400 --> 00:06:32,160 move the conference so also the 176 00:06:32,160 --> 00:06:34,240 competition moved so we actually had 177 00:06:34,240 --> 00:06:36,720 about six months of preparation in this 178 00:06:36,720 --> 00:06:38,639 case 179 00:06:38,639 --> 00:06:40,400 and the vulnerabilities need to be zero 180 00:06:40,400 --> 00:06:43,039 days which means that 181 00:06:43,039 --> 00:06:45,520 no the vendor must not know about them 182 00:06:45,520 --> 00:06:47,680 so how they do that is immediately after 183 00:06:47,680 --> 00:06:50,160 you demonstrate it and it succeeds you 184 00:06:50,160 --> 00:06:53,199 go into this disclosure room where they 185 00:06:53,199 --> 00:06:56,080 either there might be somebody on site 186 00:06:56,080 --> 00:06:57,840 from the vendor or they call somebody 187 00:06:57,840 --> 00:06:59,120 from the vendor 188 00:06:59,120 --> 00:07:01,120 and then they you fully disclose all of 189 00:07:01,120 --> 00:07:02,960 the details of the vulnerability so they 190 00:07:02,960 --> 00:07:05,520 can go and fix it 191 00:07:05,520 --> 00:07:06,880 but they also look into their buck 192 00:07:06,880 --> 00:07:08,560 tracker to see did they already know 193 00:07:08,560 --> 00:07:10,000 about this did they already have a 194 00:07:10,000 --> 00:07:11,440 record of this bug 195 00:07:11,440 --> 00:07:13,360 and if they did you get a reduced price 196 00:07:13,360 --> 00:07:15,039 because then it's a collision so it's no 197 00:07:15,039 --> 00:07:17,039 longer a zero day 198 00:07:17,039 --> 00:07:18,080 so it's 199 00:07:18,080 --> 00:07:18,880 also 200 00:07:18,880 --> 00:07:20,560 a goal of this competition to make sure 201 00:07:20,560 --> 00:07:22,639 that these vulnerabilities get fixed 202 00:07:22,639 --> 00:07:24,240 but also yeah you really need to work 203 00:07:24,240 --> 00:07:25,680 out the complete exploits you cannot 204 00:07:25,680 --> 00:07:27,919 just point to a vulnerability you have 205 00:07:27,919 --> 00:07:30,720 to actually demonstrate it live on stage 206 00:07:30,720 --> 00:07:33,039 there 207 00:07:33,440 --> 00:07:35,280 for this competition we had 208 00:07:35,280 --> 00:07:37,360 five different entries 209 00:07:37,360 --> 00:07:39,280 there was a denial service 210 00:07:39,280 --> 00:07:41,680 three remote code execution and one of 211 00:07:41,680 --> 00:07:44,960 the trusted application bypass in the 212 00:07:44,960 --> 00:07:48,879 opc foundation opcua.net standard 213 00:07:48,879 --> 00:07:50,240 they're really bad at naming these 214 00:07:50,240 --> 00:07:52,319 things 215 00:07:52,319 --> 00:07:53,680 and we're going to talk about the last 216 00:07:53,680 --> 00:07:55,599 two because for those we have permission 217 00:07:55,599 --> 00:07:57,599 to talk about them because the other 218 00:07:57,599 --> 00:07:58,400 three 219 00:07:58,400 --> 00:08:00,240 are not yet completely fixed and the 220 00:08:00,240 --> 00:08:02,560 vendors are still working on fixes but 221 00:08:02,560 --> 00:08:05,199 luckily these two were quick enough to 222 00:08:05,199 --> 00:08:07,280 update as we can now talk about it which 223 00:08:07,280 --> 00:08:09,759 is great otherwise we would have 50 224 00:08:09,759 --> 00:08:13,440 minutes to talk about very little here 225 00:08:13,440 --> 00:08:14,800 now 226 00:08:14,800 --> 00:08:16,960 as mentioned we also 227 00:08:16,960 --> 00:08:20,000 participated before in pontoon this was 228 00:08:20,000 --> 00:08:23,759 a year ago we participated in zoom 229 00:08:23,759 --> 00:08:25,360 and that exploit was a memory corruption 230 00:08:25,360 --> 00:08:26,400 vulnerability 231 00:08:26,400 --> 00:08:28,319 which was quite a lot harder than 232 00:08:28,319 --> 00:08:30,160 anything we did here 233 00:08:30,160 --> 00:08:31,520 and memory corruption means that you 234 00:08:31,520 --> 00:08:33,120 have to spend a lot of time getting the 235 00:08:33,120 --> 00:08:35,519 memory in the right shape 236 00:08:35,519 --> 00:08:36,719 so 237 00:08:36,719 --> 00:08:38,559 it was very tricky getting this to work 238 00:08:38,559 --> 00:08:40,159 and as you can see it succeeded with 239 00:08:40,159 --> 00:08:42,479 only 20 seconds left on the 5 minute 240 00:08:42,479 --> 00:08:43,679 timer 241 00:08:43,679 --> 00:08:45,680 so what we decided this year because it 242 00:08:45,680 --> 00:08:48,000 wasn't really a main focus project for 243 00:08:48,000 --> 00:08:50,560 us like zoom was we wanted no memory 244 00:08:50,560 --> 00:08:52,640 corruption at all everything we wanted 245 00:08:52,640 --> 00:08:55,360 was had to be logic bugs or something 246 00:08:55,360 --> 00:08:57,200 simple that we can just if you find 247 00:08:57,200 --> 00:08:59,200 availability then we take another day 248 00:08:59,200 --> 00:09:01,120 and we have to exploit for it 249 00:09:01,120 --> 00:09:03,360 so we wanted simple stuff low hanging 250 00:09:03,360 --> 00:09:05,360 fruit no memory corruption or stuff like 251 00:09:05,360 --> 00:09:06,240 that 252 00:09:06,240 --> 00:09:07,600 if you want to know more about this one 253 00:09:07,600 --> 00:09:08,800 we're going to talk about this one 254 00:09:08,800 --> 00:09:12,800 tomorrow at five at this stage 255 00:09:12,800 --> 00:09:14,880 so here we have an example of one of 256 00:09:14,880 --> 00:09:16,959 those exploits 257 00:09:16,959 --> 00:09:19,120 this one was 258 00:09:19,120 --> 00:09:20,720 streamed live 259 00:09:20,720 --> 00:09:23,440 and now i press enter and then about 260 00:09:23,440 --> 00:09:25,200 seven seconds later 261 00:09:25,200 --> 00:09:26,959 it executed and we had already 262 00:09:26,959 --> 00:09:28,560 demonstrated it 263 00:09:28,560 --> 00:09:31,360 so this this is much better for your for 264 00:09:31,360 --> 00:09:33,200 your heart than having to wait this five 265 00:09:33,200 --> 00:09:34,640 minutes and then 266 00:09:34,640 --> 00:09:36,399 getting really stressed about those last 267 00:09:36,399 --> 00:09:39,680 20 seconds if it's going to work 268 00:09:39,680 --> 00:09:41,279 so the first one we're going to talk 269 00:09:41,279 --> 00:09:42,160 about 270 00:09:42,160 --> 00:09:43,839 is the ignition one and i'm going to 271 00:09:43,839 --> 00:09:46,640 hand over to down for that now 272 00:09:46,640 --> 00:09:47,360 so 273 00:09:47,360 --> 00:09:49,200 the first vulnerability we're allowed to 274 00:09:49,200 --> 00:09:51,440 talk about is a remote code execution 275 00:09:51,440 --> 00:09:54,640 vulnerability in ignore ignition 276 00:09:54,640 --> 00:09:58,399 ignition is a scada software solution it 277 00:09:58,399 --> 00:09:59,760 means that 278 00:09:59,760 --> 00:10:03,040 with ignition you can 279 00:10:03,040 --> 00:10:06,320 intercept multiple channels of data from 280 00:10:06,320 --> 00:10:08,399 your ics network and you can write 281 00:10:08,399 --> 00:10:09,839 certain control 282 00:10:09,839 --> 00:10:12,000 statuses for them so basically it's like 283 00:10:12,000 --> 00:10:14,800 a central component in your ics network 284 00:10:14,800 --> 00:10:16,640 to monitor and 285 00:10:16,640 --> 00:10:19,920 control everything on the uh 286 00:10:19,920 --> 00:10:23,120 every appliance on your rcs network 287 00:10:23,120 --> 00:10:23,839 so 288 00:10:23,839 --> 00:10:26,640 before we start big kudos for how the 289 00:10:26,640 --> 00:10:28,720 vendor inductive automation handled this 290 00:10:28,720 --> 00:10:30,640 year edition of pawn to own because they 291 00:10:30,640 --> 00:10:32,399 were very quick with releasing their 292 00:10:32,399 --> 00:10:34,320 patches but they also gave full 293 00:10:34,320 --> 00:10:36,079 disclosure about every vulnerability 294 00:10:36,079 --> 00:10:37,279 that was mentioned during this 295 00:10:37,279 --> 00:10:38,560 competition 296 00:10:38,560 --> 00:10:40,800 which is really something that uh well 297 00:10:40,800 --> 00:10:42,880 not every vendor handles vulnerability 298 00:10:42,880 --> 00:10:45,440 disclosures in this way 299 00:10:45,440 --> 00:10:48,000 so i just described 300 00:10:48,000 --> 00:10:48,800 what 301 00:10:48,800 --> 00:10:51,519 ignition actually is and 302 00:10:51,519 --> 00:10:54,399 with certain confidence but this was no 303 00:10:54,399 --> 00:10:56,480 way the case when we actually entered 304 00:10:56,480 --> 00:10:58,399 the plane to go to miami because 305 00:10:58,399 --> 00:11:01,200 ignition was one of the software uh 306 00:11:01,200 --> 00:11:03,279 packages that we had a working exploit 307 00:11:03,279 --> 00:11:04,000 for 308 00:11:04,000 --> 00:11:06,079 long before we have even knew what the 309 00:11:06,079 --> 00:11:08,480 application was supposed to be doing 310 00:11:08,480 --> 00:11:09,440 but uh 311 00:11:09,440 --> 00:11:11,200 well it's software so we can hack it 312 00:11:11,200 --> 00:11:12,720 that we don't actually need to know 313 00:11:12,720 --> 00:11:15,760 where it's what it's used for 314 00:11:15,760 --> 00:11:17,200 so but we learned a lot during the 315 00:11:17,200 --> 00:11:19,040 conferences even where ignition was 316 00:11:19,040 --> 00:11:21,760 supposedly to be used for 317 00:11:21,760 --> 00:11:22,640 so 318 00:11:22,640 --> 00:11:24,320 the target for ignition was getting 319 00:11:24,320 --> 00:11:26,399 remote code execution 320 00:11:26,399 --> 00:11:29,040 so the first step was we looked for 321 00:11:29,040 --> 00:11:30,320 vulnerabilities that would actually 322 00:11:30,320 --> 00:11:32,959 allow us to run code 323 00:11:32,959 --> 00:11:34,480 and in the case for ignition this was 324 00:11:34,480 --> 00:11:37,040 rather easy because ignition has a 325 00:11:37,040 --> 00:11:40,160 script editor you as an operator you're 326 00:11:40,160 --> 00:11:42,480 allowed to write some script 327 00:11:42,480 --> 00:11:43,519 to 328 00:11:43,519 --> 00:11:46,560 based on certain data inputs you can 329 00:11:46,560 --> 00:11:49,040 write scripts that well 330 00:11:49,040 --> 00:11:51,519 change the the machine operating status 331 00:11:51,519 --> 00:11:53,200 or etc etc 332 00:11:53,200 --> 00:11:55,440 so it has a full python interpreter 333 00:11:55,440 --> 00:11:57,440 built in the application so that was 334 00:11:57,440 --> 00:11:59,519 quite quite a neat feature this means 335 00:11:59,519 --> 00:12:01,200 that if we could get access to the 336 00:12:01,200 --> 00:12:02,399 application 337 00:12:02,399 --> 00:12:04,000 it would be game over we could just use 338 00:12:04,000 --> 00:12:06,639 the game the internal script editor to 339 00:12:06,639 --> 00:12:09,040 upload a reverse shell and then we would 340 00:12:09,040 --> 00:12:11,200 have code execution 341 00:12:11,200 --> 00:12:14,720 so getting code execution was easy 342 00:12:14,720 --> 00:12:17,200 but the only trouble was that this 343 00:12:17,200 --> 00:12:19,600 editor was only available for logged in 344 00:12:19,600 --> 00:12:21,200 users of course you needed to be 345 00:12:21,200 --> 00:12:22,880 authenticated 346 00:12:22,880 --> 00:12:24,399 so that meant that we 347 00:12:24,399 --> 00:12:26,880 could shift our 348 00:12:26,880 --> 00:12:29,360 focus rather than finding a remote code 349 00:12:29,360 --> 00:12:31,839 execution vulnerability we could find an 350 00:12:31,839 --> 00:12:34,639 authentication bypass 351 00:12:34,639 --> 00:12:35,360 so 352 00:12:35,360 --> 00:12:36,880 since this 353 00:12:36,880 --> 00:12:39,040 was a java application 354 00:12:39,040 --> 00:12:41,440 doing code auditing is relatively easy 355 00:12:41,440 --> 00:12:43,920 you can just take the jar file re 356 00:12:43,920 --> 00:12:45,680 decompile it to 357 00:12:45,680 --> 00:12:47,920 readable source code and then you start 358 00:12:47,920 --> 00:12:51,120 auditing all the authentication classes 359 00:12:51,120 --> 00:12:53,440 so ignition has a couple of 360 00:12:53,440 --> 00:12:55,680 authentication methods you can just 361 00:12:55,680 --> 00:12:57,279 authenticate with the username and 362 00:12:57,279 --> 00:12:59,760 password and we'll verify this 363 00:12:59,760 --> 00:13:02,079 against an internal database 364 00:13:02,079 --> 00:13:05,279 but of course we all love single sign-on 365 00:13:05,279 --> 00:13:06,880 because yeah then you only need one 366 00:13:06,880 --> 00:13:09,040 account which you can use to log into 367 00:13:09,040 --> 00:13:11,360 all your application so ignition also 368 00:13:11,360 --> 00:13:13,600 has a single sign on implementation and 369 00:13:13,600 --> 00:13:16,240 it can authenticate to active directory 370 00:13:16,240 --> 00:13:18,720 for example because if you're on an it 371 00:13:18,720 --> 00:13:20,320 network that's what you want you already 372 00:13:20,320 --> 00:13:22,480 have an item active directory that is 373 00:13:22,480 --> 00:13:24,800 where all your user information lives so 374 00:13:24,800 --> 00:13:27,760 why don't you want to have ignition to 375 00:13:27,760 --> 00:13:30,639 authenticate against active directory 376 00:13:30,639 --> 00:13:32,399 well seemed like an excellent idea at 377 00:13:32,399 --> 00:13:34,720 the time but then we looked at how they 378 00:13:34,720 --> 00:13:36,639 actually implemented this sso 379 00:13:36,639 --> 00:13:38,399 implementation 380 00:13:38,399 --> 00:13:41,120 so this is the whole function 381 00:13:41,120 --> 00:13:42,959 it's not quite a lot of code 382 00:13:42,959 --> 00:13:46,079 but i'm going to shift the focus to only 383 00:13:46,079 --> 00:13:48,959 these four lines this is the whole 384 00:13:48,959 --> 00:13:51,440 authentication method 385 00:13:51,440 --> 00:13:53,600 so basically what you need is you need 386 00:13:53,600 --> 00:13:54,800 to have an 387 00:13:54,800 --> 00:13:56,560 active directory name 388 00:13:56,560 --> 00:13:58,480 and you need to find a user that is 389 00:13:58,480 --> 00:14:00,480 active within the domain 390 00:14:00,480 --> 00:14:02,079 but there's an important step missing 391 00:14:02,079 --> 00:14:05,279 here like verifying some tickets or 392 00:14:05,279 --> 00:14:08,800 passwords or anything that is a secret 393 00:14:08,800 --> 00:14:10,480 as long as you have a username you have 394 00:14:10,480 --> 00:14:13,040 an authenticated session 395 00:14:13,040 --> 00:14:15,600 so that was quite nifty quite handy for 396 00:14:15,600 --> 00:14:17,040 us 397 00:14:17,040 --> 00:14:19,120 finding a username in active directory 398 00:14:19,120 --> 00:14:21,199 is not particularly hard you can just 399 00:14:21,199 --> 00:14:22,800 ask the 400 00:14:22,800 --> 00:14:25,279 directory service or you can just take 401 00:14:25,279 --> 00:14:26,959 administrator for example because that 402 00:14:26,959 --> 00:14:28,560 one will always exist in an active 403 00:14:28,560 --> 00:14:31,279 directory system 404 00:14:31,279 --> 00:14:32,000 so 405 00:14:32,000 --> 00:14:33,920 combining those two using this 406 00:14:33,920 --> 00:14:35,760 authentication bypass to get a valid 407 00:14:35,760 --> 00:14:37,760 session and then using the script editor 408 00:14:37,760 --> 00:14:40,639 to spawn a remote shell we got remote 409 00:14:40,639 --> 00:14:43,120 code execution 410 00:14:43,120 --> 00:14:45,519 we are going to demonstrate it here on 411 00:14:45,519 --> 00:14:47,279 the left side you have a windows vm 412 00:14:47,279 --> 00:14:49,760 running the then latest version of 413 00:14:49,760 --> 00:14:51,199 ignition 414 00:14:51,199 --> 00:14:53,600 with the process explorer so you can see 415 00:14:53,600 --> 00:14:55,360 the 416 00:14:55,360 --> 00:14:57,519 reverse shell spawning and on the right 417 00:14:57,519 --> 00:15:00,639 hand side you have our exploit 418 00:15:00,639 --> 00:15:04,240 so we're just going to start the exploit 419 00:15:04,240 --> 00:15:07,199 it's going to try to log in get an user 420 00:15:07,199 --> 00:15:09,199 cookie 421 00:15:09,199 --> 00:15:11,680 that works and we got a remote shell so 422 00:15:11,680 --> 00:15:14,000 the cool thing about this is 423 00:15:14,000 --> 00:15:15,440 the whole 424 00:15:15,440 --> 00:15:17,360 gateway the ignition gateway runs as 425 00:15:17,360 --> 00:15:19,120 system because of course you want to 426 00:15:19,120 --> 00:15:21,199 have python code execution as a system 427 00:15:21,199 --> 00:15:23,360 user so we automatically have the 428 00:15:23,360 --> 00:15:26,720 highest privileges as well 429 00:15:26,720 --> 00:15:28,880 so that was the first vulnerability 430 00:15:28,880 --> 00:15:30,639 tais is going to talk about the second 431 00:15:30,639 --> 00:15:32,079 vulnerability which was a little bit 432 00:15:32,079 --> 00:15:34,639 more complex 433 00:15:34,639 --> 00:15:36,240 hi 434 00:15:36,240 --> 00:15:37,040 yes 435 00:15:37,040 --> 00:15:39,040 i'm going to talk about the 436 00:15:39,040 --> 00:15:42,160 trusted application bypass in opc 437 00:15:42,160 --> 00:15:43,240 foundation 438 00:15:43,240 --> 00:15:46,160 opcua.net standard 439 00:15:46,160 --> 00:15:47,120 opc 440 00:15:47,120 --> 00:15:48,079 ua 441 00:15:48,079 --> 00:15:49,680 you probably never heard of it but it is 442 00:15:49,680 --> 00:15:52,720 a very important protocol within ics 443 00:15:52,720 --> 00:15:55,279 it's created by the opc foundation 444 00:15:55,279 --> 00:15:56,320 which means that it's not a 445 00:15:56,320 --> 00:15:58,320 vendor-specific protocol 446 00:15:58,320 --> 00:16:00,880 so in an ics network you often have a 447 00:16:00,880 --> 00:16:03,440 device connecting to software that are 448 00:16:03,440 --> 00:16:05,920 is written by the same vendor and you 449 00:16:05,920 --> 00:16:08,720 speak a vendor-specific language 450 00:16:08,720 --> 00:16:10,399 a protocol that nobody else has 451 00:16:10,399 --> 00:16:13,120 implemented to communicate so there's 452 00:16:13,120 --> 00:16:15,199 all of these bubbles of systems within 453 00:16:15,199 --> 00:16:18,320 ics networks that can communicate over 454 00:16:18,320 --> 00:16:20,639 one vendor specific protocol 455 00:16:20,639 --> 00:16:22,480 but that's often not enough you have 456 00:16:22,480 --> 00:16:24,399 multiple of these things and you want to 457 00:16:24,399 --> 00:16:25,759 combine them 458 00:16:25,759 --> 00:16:26,639 um 459 00:16:26,639 --> 00:16:29,120 into some larger network 460 00:16:29,120 --> 00:16:32,160 so opc ua is often used as the glue 461 00:16:32,160 --> 00:16:33,360 between 462 00:16:33,360 --> 00:16:35,759 different fenders so if you if one 463 00:16:35,759 --> 00:16:38,639 vendor that has some stack of 464 00:16:38,639 --> 00:16:41,120 devices and software and another vendor 465 00:16:41,120 --> 00:16:43,199 then you can just choose opc ua which is 466 00:16:43,199 --> 00:16:45,440 often implemented by everything 467 00:16:45,440 --> 00:16:48,079 um to communicate between them it's also 468 00:16:48,079 --> 00:16:49,680 why it's created by foundation because 469 00:16:49,680 --> 00:16:52,240 that's a yeah there's multiple members 470 00:16:52,240 --> 00:16:53,759 multiple vendors are member of that 471 00:16:53,759 --> 00:16:56,160 foundation 472 00:16:56,160 --> 00:16:58,399 and part of the opc foundation's work is 473 00:16:58,399 --> 00:16:59,519 also to create a reference 474 00:16:59,519 --> 00:17:01,600 implementation 475 00:17:01,600 --> 00:17:02,880 they have a reference implementation 476 00:17:02,880 --> 00:17:06,400 in.net which is what this is about but 477 00:17:06,400 --> 00:17:07,839 it's more than just a reference 478 00:17:07,839 --> 00:17:09,199 implementation it's also used as a 479 00:17:09,199 --> 00:17:11,439 library in many products 480 00:17:11,439 --> 00:17:13,039 so many people don't actually write 481 00:17:13,039 --> 00:17:15,119 their own upc ua 482 00:17:15,119 --> 00:17:17,439 stack from scratch but they just grabbed 483 00:17:17,439 --> 00:17:19,679 the reference implementation 484 00:17:19,679 --> 00:17:20,640 so 485 00:17:20,640 --> 00:17:22,079 we looked at a lot of these applications 486 00:17:22,079 --> 00:17:24,559 and often they have either this 487 00:17:24,559 --> 00:17:26,319 implementation or they have a c version 488 00:17:26,319 --> 00:17:28,319 of the reference implementation there's 489 00:17:28,319 --> 00:17:31,120 just only a couple of opc ua 490 00:17:31,120 --> 00:17:34,559 implementations out there 491 00:17:34,799 --> 00:17:37,679 we have a demonstration of the opcoa 492 00:17:37,679 --> 00:17:40,640 reference client so that's part of the 493 00:17:40,640 --> 00:17:41,520 yeah 494 00:17:41,520 --> 00:17:43,200 the same code that opc foundation 495 00:17:43,200 --> 00:17:45,919 develops and we can demonstrate it on 496 00:17:45,919 --> 00:17:47,600 the left is the server on the right is 497 00:17:47,600 --> 00:17:51,199 the client that connects to the 498 00:17:53,760 --> 00:17:56,160 connects to that server 499 00:17:56,160 --> 00:17:57,919 and as part of the reference server 500 00:17:57,919 --> 00:17:58,840 there's 501 00:17:58,840 --> 00:18:02,240 some randomly generated data there 502 00:18:02,240 --> 00:18:04,160 there's a boiler with a temperature or 503 00:18:04,160 --> 00:18:06,480 something that we can read from 504 00:18:06,480 --> 00:18:08,160 it's just fake data that you can now 505 00:18:08,160 --> 00:18:11,120 read from the server 506 00:18:11,600 --> 00:18:13,840 now because we didn't want any memory 507 00:18:13,840 --> 00:18:15,919 corruption we thought those just 508 00:18:15,919 --> 00:18:17,760 application bypasses were quite 509 00:18:17,760 --> 00:18:20,320 interesting because that means that you 510 00:18:20,320 --> 00:18:22,160 essentially only have to all that one 511 00:18:22,160 --> 00:18:23,200 function 512 00:18:23,200 --> 00:18:25,200 you have to audit it completely and make 513 00:18:25,200 --> 00:18:27,039 sure that you understand every part of 514 00:18:27,039 --> 00:18:29,919 it but because it's such a 515 00:18:29,919 --> 00:18:32,160 constrained target it's just in one 516 00:18:32,160 --> 00:18:34,640 single place means you have very little 517 00:18:34,640 --> 00:18:37,120 other code to look at 518 00:18:37,120 --> 00:18:38,960 so we spent quite a bit of time looking 519 00:18:38,960 --> 00:18:42,320 at the different certificate validation 520 00:18:42,320 --> 00:18:44,240 functions in the the four applications 521 00:18:44,240 --> 00:18:46,240 that were in this category 522 00:18:46,240 --> 00:18:47,679 and eventually we found one 523 00:18:47,679 --> 00:18:49,520 vulnerability 524 00:18:49,520 --> 00:18:51,120 what's actually quite interesting is 525 00:18:51,120 --> 00:18:52,559 that this vulnerability was quite 526 00:18:52,559 --> 00:18:54,400 similar to something else we found last 527 00:18:54,400 --> 00:18:56,080 year 528 00:18:56,080 --> 00:18:58,320 there were some vulnerabilities we found 529 00:18:58,320 --> 00:18:59,919 in the coroner check app used here in 530 00:18:59,919 --> 00:19:01,120 the netherlands 531 00:19:01,120 --> 00:19:03,120 that basically in the ios version of the 532 00:19:03,120 --> 00:19:07,120 app completely disabled tls validation 533 00:19:07,120 --> 00:19:09,919 except for one single check implicit 534 00:19:09,919 --> 00:19:12,240 check at the end that still worked so 535 00:19:12,240 --> 00:19:13,840 they wanted to add certificate pinning 536 00:19:13,840 --> 00:19:15,440 but they completely messed it up so 537 00:19:15,440 --> 00:19:17,440 there was no certificate validation at 538 00:19:17,440 --> 00:19:19,600 all 539 00:19:19,600 --> 00:19:20,960 and this was actually quite similar to 540 00:19:20,960 --> 00:19:22,400 what we found here 541 00:19:22,400 --> 00:19:24,080 if you want to read more about this you 542 00:19:24,080 --> 00:19:27,280 can find it on our website 543 00:19:27,360 --> 00:19:28,640 so 544 00:19:28,640 --> 00:19:30,480 the process of how they want to validate 545 00:19:30,480 --> 00:19:31,840 the certificate 546 00:19:31,840 --> 00:19:33,440 in order to validate the certificate 547 00:19:33,440 --> 00:19:36,480 first you need to build certificate j 548 00:19:36,480 --> 00:19:39,760 quite often the other party only sends 549 00:19:39,760 --> 00:19:42,080 one certificate 550 00:19:42,080 --> 00:19:43,520 and then you need to make sure that you 551 00:19:43,520 --> 00:19:45,280 know the full chain to 552 00:19:45,280 --> 00:19:47,760 verify the cryptographic signatures on 553 00:19:47,760 --> 00:19:50,879 each step of that chain 554 00:19:51,039 --> 00:19:53,520 but for some reason 555 00:19:53,520 --> 00:19:55,120 the developers of this reference 556 00:19:55,120 --> 00:19:57,360 implementation decided that they don't 557 00:19:57,360 --> 00:19:58,320 like 558 00:19:58,320 --> 00:19:59,600 the 559 00:19:59,600 --> 00:20:02,400 trusts or for certificates in windows 560 00:20:02,400 --> 00:20:04,400 they don't want to use it because it's 561 00:20:04,400 --> 00:20:07,120 tricky to configure 562 00:20:07,120 --> 00:20:08,960 so what they do is that they 563 00:20:08,960 --> 00:20:11,280 they use their own logic 564 00:20:11,280 --> 00:20:12,480 to 565 00:20:12,480 --> 00:20:14,799 construct a potential certificate chain 566 00:20:14,799 --> 00:20:17,360 a candidate 567 00:20:17,360 --> 00:20:18,960 they construct this based on just the 568 00:20:18,960 --> 00:20:21,039 names in the certificate so it's not yet 569 00:20:21,039 --> 00:20:24,480 cryptographically validated 570 00:20:24,880 --> 00:20:28,480 and then they pass this chain to the 571 00:20:28,480 --> 00:20:31,280 x509 chain api to get it to validate it 572 00:20:31,280 --> 00:20:34,000 to check the signatures 573 00:20:34,000 --> 00:20:35,760 but because they don't really use it in 574 00:20:35,760 --> 00:20:39,919 the way that api was designed to be used 575 00:20:40,080 --> 00:20:42,000 they may encounter errors like an 576 00:20:42,000 --> 00:20:43,440 interested root because they don't 577 00:20:43,440 --> 00:20:45,760 configure the trust store because they 578 00:20:45,760 --> 00:20:47,120 don't want to use the windows build 579 00:20:47,120 --> 00:20:49,120 interests or 580 00:20:49,120 --> 00:20:50,960 so then they have some code to ignore 581 00:20:50,960 --> 00:20:54,080 these errors that they expect like the 582 00:20:54,080 --> 00:20:56,400 certificate root is the the root is 583 00:20:56,400 --> 00:20:59,039 entrusted 584 00:20:59,280 --> 00:21:01,280 so this was the idea behind this this 585 00:21:01,280 --> 00:21:02,640 function 586 00:21:02,640 --> 00:21:04,559 but it's not actually how the code that 587 00:21:04,559 --> 00:21:06,960 they have written works 588 00:21:06,960 --> 00:21:08,880 because why they wanted to verify that 589 00:21:08,880 --> 00:21:10,080 chain 590 00:21:10,080 --> 00:21:13,120 what this api was actually doing 591 00:21:13,120 --> 00:21:15,520 is it was building a new chain 592 00:21:15,520 --> 00:21:17,679 using whatever methods it had for 593 00:21:17,679 --> 00:21:19,520 finding those certificates 594 00:21:19,520 --> 00:21:23,120 and then verifying that new chain 595 00:21:23,120 --> 00:21:25,440 so if you could find some way to make 596 00:21:25,440 --> 00:21:28,240 those chains be different 597 00:21:28,240 --> 00:21:29,919 then you could make those errors 598 00:21:29,919 --> 00:21:31,600 disappear by 599 00:21:31,600 --> 00:21:33,600 making them 600 00:21:33,600 --> 00:21:35,280 coincide with the types of errors that 601 00:21:35,280 --> 00:21:38,080 would be ignored 602 00:21:40,960 --> 00:21:43,440 so i'm going to try to show this to you 603 00:21:43,440 --> 00:21:45,039 within the code 604 00:21:45,039 --> 00:21:46,640 instead of actually 605 00:21:46,640 --> 00:21:49,919 trying to do it on slides 606 00:21:51,200 --> 00:21:53,440 so 607 00:21:54,080 --> 00:21:55,919 this is readable could make it a bit 608 00:21:55,919 --> 00:21:57,679 larger i think 609 00:21:57,679 --> 00:21:59,520 the main logic for verifying those 610 00:21:59,520 --> 00:22:01,679 certificates is in the internal validate 611 00:22:01,679 --> 00:22:04,080 function 612 00:22:04,240 --> 00:22:05,679 this function gets that list of 613 00:22:05,679 --> 00:22:09,120 certificates that the other party sent 614 00:22:09,120 --> 00:22:11,600 and then it wants to check if it is 615 00:22:11,600 --> 00:22:13,440 trusted 616 00:22:13,440 --> 00:22:15,840 so the first important function here to 617 00:22:15,840 --> 00:22:18,159 look at 618 00:22:18,159 --> 00:22:21,720 is the 619 00:22:26,400 --> 00:22:28,880 okay i'm 620 00:22:28,880 --> 00:22:30,320 this function that i accidentally 621 00:22:30,320 --> 00:22:31,360 deleted 622 00:22:31,360 --> 00:22:35,760 we get issues no exception on get issuer 623 00:22:36,640 --> 00:22:38,480 and what this function does is that it 624 00:22:38,480 --> 00:22:40,880 tries to construct that chain 625 00:22:40,880 --> 00:22:42,559 and it has a 626 00:22:42,559 --> 00:22:44,960 this list it will at the return of this 627 00:22:44,960 --> 00:22:47,440 function contain that candidate chain 628 00:22:47,440 --> 00:22:49,679 that's not yet validated but that 629 00:22:49,679 --> 00:22:51,360 probably is going to be the chain of 630 00:22:51,360 --> 00:22:53,360 certificates 631 00:22:53,360 --> 00:22:55,679 an instruction works in a loop 632 00:22:55,679 --> 00:22:57,600 in every loop it tries to find the 633 00:22:57,600 --> 00:22:59,840 issuer of the current certificate so it 634 00:22:59,840 --> 00:23:02,000 has one certificate and now it wants to 635 00:23:02,000 --> 00:23:02,799 find 636 00:23:02,799 --> 00:23:04,640 what is the issue of this certificate so 637 00:23:04,640 --> 00:23:06,840 it wants to go one step up into the 638 00:23:06,840 --> 00:23:09,520 chain to do that it calls the function 639 00:23:09,520 --> 00:23:12,400 get issue or no exception 640 00:23:12,400 --> 00:23:14,799 and it has a couple of different 641 00:23:14,799 --> 00:23:16,960 certificate places it can look for that 642 00:23:16,960 --> 00:23:19,520 certificate 643 00:23:19,679 --> 00:23:23,840 and this function calls into match 644 00:23:24,640 --> 00:23:26,559 this function loops through the list of 645 00:23:26,559 --> 00:23:28,960 trusted certificates or the 646 00:23:28,960 --> 00:23:30,559 interested certificates that are still 647 00:23:30,559 --> 00:23:32,480 installed or the list of certificates 648 00:23:32,480 --> 00:23:34,000 that the client send 649 00:23:34,000 --> 00:23:37,840 and tries to find a match between those 650 00:23:38,240 --> 00:23:40,080 and then that function calls compare 651 00:23:40,080 --> 00:23:43,679 distinguished name which is the 652 00:23:43,679 --> 00:23:45,200 place where really this vulnerability 653 00:23:45,200 --> 00:23:47,360 originated 654 00:23:47,360 --> 00:23:48,480 so 655 00:23:48,480 --> 00:23:51,279 a certificate has a name 656 00:23:51,279 --> 00:23:53,120 but name means a bit more than what you 657 00:23:53,120 --> 00:23:54,960 might think of as a name 658 00:23:54,960 --> 00:23:56,720 so a name has components like for 659 00:23:56,720 --> 00:23:58,799 example you can have a country 660 00:23:58,799 --> 00:24:00,320 and you can have a 661 00:24:00,320 --> 00:24:02,799 state you can have a common name and 662 00:24:02,799 --> 00:24:05,760 that entire thing is considered the name 663 00:24:05,760 --> 00:24:07,520 and it has distinguished names 664 00:24:07,520 --> 00:24:09,520 components 665 00:24:09,520 --> 00:24:10,480 and 666 00:24:10,480 --> 00:24:11,679 normally 667 00:24:11,679 --> 00:24:14,320 in openssl or many other 668 00:24:14,320 --> 00:24:17,120 tls implementations to compare two names 669 00:24:17,120 --> 00:24:19,760 you just compare them bit by bit if it's 670 00:24:19,760 --> 00:24:23,279 just binary equal then they are equal 671 00:24:23,279 --> 00:24:24,559 but this function is way more 672 00:24:24,559 --> 00:24:26,880 complicated than that it actually takes 673 00:24:26,880 --> 00:24:28,480 the name apart into the different 674 00:24:28,480 --> 00:24:30,799 components and then sorts them and then 675 00:24:30,799 --> 00:24:34,080 compares them ignoring the case 676 00:24:34,080 --> 00:24:36,240 so uppercase lowercase are considered 677 00:24:36,240 --> 00:24:38,080 equal 678 00:24:38,080 --> 00:24:40,080 and that's this is not how any other 679 00:24:40,080 --> 00:24:42,400 x509 implementation works as far as i 680 00:24:42,400 --> 00:24:44,400 know 681 00:24:44,400 --> 00:24:46,159 so this is something we can use to 682 00:24:46,159 --> 00:24:49,279 create two diverging chains 683 00:24:49,279 --> 00:24:51,679 so if we now go backwards to 684 00:24:51,679 --> 00:24:56,039 that internal validate function 685 00:25:02,240 --> 00:25:05,279 here it starts that x 509 chain so here 686 00:25:05,279 --> 00:25:08,080 it goes into the actual api 687 00:25:08,080 --> 00:25:12,158 that it hands it the certificate 688 00:25:12,799 --> 00:25:16,159 and then try to build a chain with that 689 00:25:16,159 --> 00:25:17,600 and here we have the function which is 690 00:25:17,600 --> 00:25:19,520 going to ignore the errors that they 691 00:25:19,520 --> 00:25:22,559 expect to get here 692 00:25:22,559 --> 00:25:24,799 so one of the errors that they 693 00:25:24,799 --> 00:25:27,200 expect is an interested route 694 00:25:27,200 --> 00:25:28,960 and what this check here basically means 695 00:25:28,960 --> 00:25:30,080 this check 696 00:25:30,080 --> 00:25:32,320 if if it's the last one in the change or 697 00:25:32,320 --> 00:25:33,840 if it's in the place where they think 698 00:25:33,840 --> 00:25:37,120 their trusted root is then it is okay 699 00:25:37,120 --> 00:25:38,880 so that's that's the part that we can 700 00:25:38,880 --> 00:25:40,000 then 701 00:25:40,000 --> 00:25:43,840 use to hide the errors 702 00:25:48,240 --> 00:25:49,520 so 703 00:25:49,520 --> 00:25:51,200 to make this a bit more 704 00:25:51,200 --> 00:25:53,200 visual 705 00:25:53,200 --> 00:25:55,440 suppose the server has two trusted 706 00:25:55,440 --> 00:25:58,320 certificates let's encrypt and one named 707 00:25:58,320 --> 00:26:00,480 root 708 00:26:00,480 --> 00:26:02,000 and then it needs to validate the 709 00:26:02,000 --> 00:26:03,679 certificate and that's the certificate 710 00:26:03,679 --> 00:26:05,360 at the top 711 00:26:05,360 --> 00:26:07,360 the certificate says that it's issuers 712 00:26:07,360 --> 00:26:09,279 roots but with the cases swapped so 713 00:26:09,279 --> 00:26:12,400 lowercase r uppercase oot 714 00:26:12,400 --> 00:26:14,159 but the root is actually named root with 715 00:26:14,159 --> 00:26:16,640 uppercase r 716 00:26:16,640 --> 00:26:19,440 so then opcua this code consider this a 717 00:26:19,440 --> 00:26:21,919 potential candidate 718 00:26:21,919 --> 00:26:26,480 for um yeah the trusted root certificate 719 00:26:26,480 --> 00:26:28,960 and then it goes into that x509 chain to 720 00:26:28,960 --> 00:26:30,240 make this 721 00:26:30,240 --> 00:26:34,159 to do the cryptographic checking of that 722 00:26:34,240 --> 00:26:36,880 now the x509 chain 723 00:26:36,880 --> 00:26:39,360 api it doesn't really consider this one 724 00:26:39,360 --> 00:26:42,640 even a potential issuer because the name 725 00:26:42,640 --> 00:26:44,880 doesn't match so it's not going to say 726 00:26:44,880 --> 00:26:46,799 this cryptographic signature is wrong 727 00:26:46,799 --> 00:26:48,880 because it's not it's not even an option 728 00:26:48,880 --> 00:26:51,200 to check it 729 00:26:51,200 --> 00:26:53,279 so it doesn't really have a root 730 00:26:53,279 --> 00:26:54,640 certificate 731 00:26:54,640 --> 00:26:57,200 but very helpfully there's this 732 00:26:57,200 --> 00:26:58,720 extension 733 00:26:58,720 --> 00:27:00,080 it's called 734 00:27:00,080 --> 00:27:03,600 authority information access 735 00:27:03,600 --> 00:27:06,640 ca issuers url something like that 736 00:27:06,640 --> 00:27:08,559 basically what you can do is you can put 737 00:27:08,559 --> 00:27:12,240 a url into a certificate which says 738 00:27:12,240 --> 00:27:14,159 the issuer of this certificate can be 739 00:27:14,159 --> 00:27:16,480 downloaded from this link 740 00:27:16,480 --> 00:27:18,799 so even though the server didn't have 741 00:27:18,799 --> 00:27:20,640 this certificate the 742 00:27:20,640 --> 00:27:22,320 malicious certificate 743 00:27:22,320 --> 00:27:24,320 we can tell the server to download it 744 00:27:24,320 --> 00:27:26,240 from us 745 00:27:26,240 --> 00:27:28,720 so at this point this api will download 746 00:27:28,720 --> 00:27:31,039 that certificate from us 747 00:27:31,039 --> 00:27:33,360 and then because we have generated this 748 00:27:33,360 --> 00:27:35,919 one and that one the signature is just 749 00:27:35,919 --> 00:27:37,279 correct 750 00:27:37,279 --> 00:27:39,360 but the certificate is interested on the 751 00:27:39,360 --> 00:27:41,440 server 752 00:27:41,440 --> 00:27:43,520 now concept function that ignores those 753 00:27:43,520 --> 00:27:45,120 expected errors 754 00:27:45,120 --> 00:27:47,200 so it sees well there's one interested 755 00:27:47,200 --> 00:27:49,919 certificate at the root 756 00:27:49,919 --> 00:27:52,880 well that was expected so we just accept 757 00:27:52,880 --> 00:27:55,279 this certificate 758 00:27:55,279 --> 00:27:57,200 so in this way 759 00:27:57,200 --> 00:28:00,000 we can by only knowing about the root 760 00:28:00,000 --> 00:28:02,559 certificate on the server we can forge a 761 00:28:02,559 --> 00:28:04,720 new road certificate and then create a 762 00:28:04,720 --> 00:28:07,279 new end certificate that is accepted by 763 00:28:07,279 --> 00:28:08,399 the server 764 00:28:08,399 --> 00:28:10,159 even though it was not signed by one of 765 00:28:10,159 --> 00:28:14,000 the actual trusted routes on the server 766 00:28:14,000 --> 00:28:16,159 and therefore we have then bypassed 767 00:28:16,159 --> 00:28:19,200 what's known as the application check 768 00:28:19,200 --> 00:28:19,919 so 769 00:28:19,919 --> 00:28:23,360 some more background on opc 770 00:28:23,600 --> 00:28:24,640 it has 771 00:28:24,640 --> 00:28:26,720 an option for encryption 772 00:28:26,720 --> 00:28:29,200 it can also be used without encryption 773 00:28:29,200 --> 00:28:30,559 and that encryption uses those 774 00:28:30,559 --> 00:28:33,679 certificates and both parties need to 775 00:28:33,679 --> 00:28:36,799 show a certificate to the other party 776 00:28:36,799 --> 00:28:39,039 so in this case you could bypass both 777 00:28:39,039 --> 00:28:41,200 those authentications if both use the 778 00:28:41,200 --> 00:28:43,520 same implementation 779 00:28:43,520 --> 00:28:45,520 and then intercept the connection 780 00:28:45,520 --> 00:28:47,679 and then we could manipulate whatever 781 00:28:47,679 --> 00:28:49,919 systems are trying to communicate here 782 00:28:49,919 --> 00:28:50,880 which is 783 00:28:50,880 --> 00:28:52,559 really hard to say in general but yeah 784 00:28:52,559 --> 00:28:54,799 it might be some ics systems at both end 785 00:28:54,799 --> 00:28:57,960 of the connection 786 00:28:58,480 --> 00:29:00,240 now we have also a demonstration of this 787 00:29:00,240 --> 00:29:02,080 one 788 00:29:02,080 --> 00:29:03,360 again on the left that reference 789 00:29:03,360 --> 00:29:04,880 implementation and on the right are 790 00:29:04,880 --> 00:29:07,360 exploit 791 00:29:10,880 --> 00:29:12,720 connect to the server we 792 00:29:12,720 --> 00:29:14,960 see that it has a certificate issued by 793 00:29:14,960 --> 00:29:17,039 some root certificate 794 00:29:17,039 --> 00:29:19,360 we copy that root certificate 795 00:29:19,360 --> 00:29:21,919 and then generate a new certificate 796 00:29:21,919 --> 00:29:24,159 and connect to the server 797 00:29:24,159 --> 00:29:26,159 and yes you can see we have a incoming 798 00:29:26,159 --> 00:29:28,159 connection there and also here we can 799 00:29:28,159 --> 00:29:30,000 read that random boiler temperature 800 00:29:30,000 --> 00:29:33,120 values from the server 801 00:29:34,399 --> 00:29:36,399 now i'm going to hand over to down again 802 00:29:36,399 --> 00:29:38,840 to talk a little bit more about ics in 803 00:29:38,840 --> 00:29:43,200 general and our thoughts about it yeah 804 00:29:43,200 --> 00:29:45,279 so there were two vulnerabilities we are 805 00:29:45,279 --> 00:29:47,840 allowed to talk about at this this event 806 00:29:47,840 --> 00:29:51,760 the last three are still to be fixed 807 00:29:51,760 --> 00:29:53,600 so 808 00:29:53,600 --> 00:29:55,600 what we learned about the ics world is 809 00:29:55,600 --> 00:29:58,080 that in the ics world everything is 810 00:29:58,080 --> 00:29:59,840 about availability 811 00:29:59,840 --> 00:30:02,080 and we already noticed this when we 812 00:30:02,080 --> 00:30:03,440 discussed 813 00:30:03,440 --> 00:30:06,960 uh ics pen testing with our clients 814 00:30:06,960 --> 00:30:09,200 yeah they all think that's a good idea 815 00:30:09,200 --> 00:30:10,799 and they all want to do pen testing on 816 00:30:10,799 --> 00:30:13,440 their ics network 817 00:30:13,440 --> 00:30:15,039 however at some point we need to say 818 00:30:15,039 --> 00:30:16,159 okay but we 819 00:30:16,159 --> 00:30:18,320 cannot guarantee that 820 00:30:18,320 --> 00:30:20,320 all systems will stay online because we 821 00:30:20,320 --> 00:30:23,200 are going to send well malicious data to 822 00:30:23,200 --> 00:30:26,720 every device and they might well go 823 00:30:26,720 --> 00:30:29,520 offline or or crash or whatever 824 00:30:29,520 --> 00:30:31,679 so as soon as we mention this 825 00:30:31,679 --> 00:30:34,080 the pen test is off the table and you're 826 00:30:34,080 --> 00:30:36,640 back to tabletop exercises which are 827 00:30:36,640 --> 00:30:40,240 also useful but they're all theoretical 828 00:30:40,240 --> 00:30:41,600 so 829 00:30:41,600 --> 00:30:44,240 yeah nothing you do in the ics world 830 00:30:44,240 --> 00:30:46,159 should jeopardize the availability of 831 00:30:46,159 --> 00:30:49,279 components having downtime means that 832 00:30:49,279 --> 00:30:51,279 the whole facility grinds to a halt 833 00:30:51,279 --> 00:30:53,120 because for most component most 834 00:30:53,120 --> 00:30:56,559 important machinery there is no backup 835 00:30:56,559 --> 00:30:58,720 so that can of course raise all kinds of 836 00:30:58,720 --> 00:31:01,039 issues can either be liability issues 837 00:31:01,039 --> 00:31:03,120 but it can also loss of revenue you can 838 00:31:03,120 --> 00:31:05,039 imagine if a factory grinds to a halt 839 00:31:05,039 --> 00:31:07,440 you cannot produce any more 840 00:31:07,440 --> 00:31:09,760 or in some situations maybe even safety 841 00:31:09,760 --> 00:31:11,679 issues if the 842 00:31:11,679 --> 00:31:12,559 if it's 843 00:31:12,559 --> 00:31:13,360 the 844 00:31:13,360 --> 00:31:15,440 component is used to control bridges or 845 00:31:15,440 --> 00:31:17,200 whatever 846 00:31:17,200 --> 00:31:20,240 so that also means that things we 847 00:31:20,240 --> 00:31:23,600 consider common practice in it networks 848 00:31:23,600 --> 00:31:26,000 are not that common in ics 849 00:31:26,000 --> 00:31:27,679 systems 850 00:31:27,679 --> 00:31:29,360 one meaningful example is the 851 00:31:29,360 --> 00:31:31,760 installation of security updates that is 852 00:31:31,760 --> 00:31:34,559 not done in the ics world because well 853 00:31:34,559 --> 00:31:36,799 you have to take the devices offline 854 00:31:36,799 --> 00:31:39,279 because they need to reboot but even if 855 00:31:39,279 --> 00:31:41,600 that only takes 30 seconds 856 00:31:41,600 --> 00:31:43,679 there is still a chance and it might be 857 00:31:43,679 --> 00:31:46,000 a minor chance but nonetheless there is 858 00:31:46,000 --> 00:31:48,320 a chance that the security update also 859 00:31:48,320 --> 00:31:50,720 changes something else which makes the 860 00:31:50,720 --> 00:31:52,880 device unavailable 861 00:31:52,880 --> 00:31:54,240 so typically 862 00:31:54,240 --> 00:31:56,480 security updates are not installed 863 00:31:56,480 --> 00:31:58,840 because that could jeopardize the 864 00:31:58,840 --> 00:32:00,640 availability 865 00:32:00,640 --> 00:32:03,600 secondly is that the devices in the ics 866 00:32:03,600 --> 00:32:05,840 world have a considerable longer life 867 00:32:05,840 --> 00:32:09,519 span than in it world now you have 868 00:32:09,519 --> 00:32:12,399 components that might have been online 869 00:32:12,399 --> 00:32:14,559 for the last 30 years 870 00:32:14,559 --> 00:32:17,200 which also means you need to 871 00:32:17,200 --> 00:32:19,919 defend or protect devices 872 00:32:19,919 --> 00:32:23,039 that use 30 year old technology 873 00:32:23,039 --> 00:32:25,279 and they are not built to withstand 874 00:32:25,279 --> 00:32:27,039 attacks from 875 00:32:27,039 --> 00:32:29,679 adversaries via the internet 876 00:32:29,679 --> 00:32:31,519 for example we spoke with multiple 877 00:32:31,519 --> 00:32:34,399 operators at the conference with with 878 00:32:34,399 --> 00:32:36,080 pontoon miami was 879 00:32:36,080 --> 00:32:39,279 and they all had windows 95 or windows 880 00:32:39,279 --> 00:32:42,640 98 devices still in service and they 881 00:32:42,640 --> 00:32:44,480 needed to be connected to the internal 882 00:32:44,480 --> 00:32:46,159 network because they needed to be 883 00:32:46,159 --> 00:32:48,720 remotely managed or they needed to share 884 00:32:48,720 --> 00:32:50,960 data to other components about for 885 00:32:50,960 --> 00:32:53,039 example the pressure in the boiler or 886 00:32:53,039 --> 00:32:56,080 whatever data they needed to share 887 00:32:56,080 --> 00:32:56,799 so 888 00:32:56,799 --> 00:32:58,880 thinking about security in the ics world 889 00:32:58,880 --> 00:33:00,799 really differs from 890 00:33:00,799 --> 00:33:04,559 security in the it world 891 00:33:04,559 --> 00:33:07,200 so in the it world we're getting to a 892 00:33:07,200 --> 00:33:09,840 point where the network no longer 893 00:33:09,840 --> 00:33:10,880 matters 894 00:33:10,880 --> 00:33:13,840 so even if the network is compromised 895 00:33:13,840 --> 00:33:16,720 devices are able to protect themselves 896 00:33:16,720 --> 00:33:18,159 this comes 897 00:33:18,159 --> 00:33:20,559 for example due to secure defaults that 898 00:33:20,559 --> 00:33:22,960 devices nowaday use and things like 899 00:33:22,960 --> 00:33:24,960 transport security 900 00:33:24,960 --> 00:33:26,960 that the network no longer matters that 901 00:33:26,960 --> 00:33:28,000 much 902 00:33:28,000 --> 00:33:29,840 this is also the reason why we can build 903 00:33:29,840 --> 00:33:32,320 zero trust networks where devices 904 00:33:32,320 --> 00:33:34,320 authenticate each other rather than 905 00:33:34,320 --> 00:33:37,519 trusting on the network 906 00:33:37,519 --> 00:33:40,720 ideally we also want the ics world to 907 00:33:40,720 --> 00:33:42,559 move in this direction 908 00:33:42,559 --> 00:33:43,600 however 909 00:33:43,600 --> 00:33:45,679 we see with the vulnerabilities we found 910 00:33:45,679 --> 00:33:47,840 in only a couple of weeks of research 911 00:33:47,840 --> 00:33:50,399 that most components in the ics 912 00:33:50,399 --> 00:33:53,200 network are unable to defend themselves 913 00:33:53,200 --> 00:33:55,200 all the vulnerabilities we found were 914 00:33:55,200 --> 00:33:57,679 what we consider a low-hanging fruit 915 00:33:57,679 --> 00:33:59,440 there are no complex vulnerabilities 916 00:33:59,440 --> 00:34:01,760 there are no complex exploits 917 00:34:01,760 --> 00:34:04,640 i think the shortest time we went from 918 00:34:04,640 --> 00:34:06,399 installing the application into a 919 00:34:06,399 --> 00:34:10,159 running exploit was 15 minutes 920 00:34:10,320 --> 00:34:12,239 so 921 00:34:12,239 --> 00:34:14,159 we're still a long way from having a 922 00:34:14,159 --> 00:34:17,599 server trust network in the ics world 923 00:34:17,599 --> 00:34:19,199 and if you speak with people that 924 00:34:19,199 --> 00:34:22,239 operate or are responsible for securing 925 00:34:22,239 --> 00:34:23,918 ics networks 926 00:34:23,918 --> 00:34:26,800 they have one defense strategy and that 927 00:34:26,800 --> 00:34:29,520 is network segmentation making sure that 928 00:34:29,520 --> 00:34:32,719 the attacker can never reach the ics 929 00:34:32,719 --> 00:34:34,320 network 930 00:34:34,320 --> 00:34:35,199 which 931 00:34:35,199 --> 00:34:36,879 if you have only 932 00:34:36,879 --> 00:34:39,199 two or three bridges to either the 933 00:34:39,199 --> 00:34:42,560 internet or the internal it network 934 00:34:42,560 --> 00:34:44,560 looks like a solar plan 935 00:34:44,560 --> 00:34:46,399 only three bridges to the internal 936 00:34:46,399 --> 00:34:47,839 network that is something you can 937 00:34:47,839 --> 00:34:49,599 monitor and defend 938 00:34:49,599 --> 00:34:52,000 and you can reason about all the 939 00:34:52,000 --> 00:34:53,359 different vulnerabilities that could 940 00:34:53,359 --> 00:34:55,918 arise in that small setup 941 00:34:55,918 --> 00:34:57,119 however 942 00:34:57,119 --> 00:34:59,200 speaking to that same 943 00:34:59,200 --> 00:35:00,640 same people 944 00:35:00,640 --> 00:35:03,839 most ics networks no longer have three 945 00:35:03,839 --> 00:35:06,000 bridges to the internet or the internal 946 00:35:06,000 --> 00:35:09,200 network they have a tenfold of that 947 00:35:09,200 --> 00:35:12,079 because every component wants to do 948 00:35:12,079 --> 00:35:15,359 remote management and most likely the 949 00:35:15,359 --> 00:35:18,560 management is done by different parties 950 00:35:18,560 --> 00:35:20,400 you have people responsible for 951 00:35:20,400 --> 00:35:24,000 machinery at site a or maybe a specific 952 00:35:24,000 --> 00:35:27,119 device at site b 953 00:35:27,599 --> 00:35:29,440 and not only for remote management but 954 00:35:29,440 --> 00:35:32,320 also for monitoring and sharing data 955 00:35:32,320 --> 00:35:34,880 there were whole talks about having 956 00:35:34,880 --> 00:35:37,280 doing big data analysis by sending all 957 00:35:37,280 --> 00:35:39,280 your ics information up to the cloud 958 00:35:39,280 --> 00:35:41,520 where you could do big data analysis and 959 00:35:41,520 --> 00:35:42,960 you could send that 960 00:35:42,960 --> 00:35:45,440 data back to the network so you could 961 00:35:45,440 --> 00:35:47,680 make monitoring decisions 962 00:35:47,680 --> 00:35:50,160 or operating decisions 963 00:35:50,160 --> 00:35:52,319 so 964 00:35:52,480 --> 00:35:54,960 network segmentation is a good strategy 965 00:35:54,960 --> 00:35:56,880 maybe if you have only a couple of 966 00:35:56,880 --> 00:35:59,359 bridges but in the 967 00:35:59,359 --> 00:36:01,920 current ics world we don't see this as a 968 00:36:01,920 --> 00:36:04,400 winning strategy 969 00:36:04,400 --> 00:36:05,280 so 970 00:36:05,280 --> 00:36:07,599 we think if we want to prevent the 971 00:36:07,599 --> 00:36:09,680 critical infrastructure from becoming 972 00:36:09,680 --> 00:36:12,400 hit we need to start making secure 973 00:36:12,400 --> 00:36:13,599 devices 974 00:36:13,599 --> 00:36:15,040 and of course 975 00:36:15,040 --> 00:36:17,040 this is not something that is going to 976 00:36:17,040 --> 00:36:19,200 solve this problem immediately but this 977 00:36:19,200 --> 00:36:21,440 is of course also a hard problem to 978 00:36:21,440 --> 00:36:23,599 solve this is not something we're going 979 00:36:23,599 --> 00:36:27,040 to solve in the next year or so but i 980 00:36:27,040 --> 00:36:29,119 think that is the way forward 981 00:36:29,119 --> 00:36:31,680 secondly we don't think that 982 00:36:31,680 --> 00:36:33,920 having somebody responsible for ics 983 00:36:33,920 --> 00:36:36,000 security and somebody responsible for it 984 00:36:36,000 --> 00:36:40,320 security is a long-term strategy 985 00:36:40,320 --> 00:36:42,560 we think if you want to really make your 986 00:36:42,560 --> 00:36:44,720 ics network more secure you should 987 00:36:44,720 --> 00:36:46,720 consider it a single network with all 988 00:36:46,720 --> 00:36:48,480 kinds of devices if that either are 989 00:36:48,480 --> 00:36:51,200 laptops phones etc and you need to make 990 00:36:51,200 --> 00:36:53,680 sure that every device is secure 991 00:36:53,680 --> 00:36:56,160 and not making the distinction so hard 992 00:36:56,160 --> 00:36:57,119 about 993 00:36:57,119 --> 00:37:00,079 the type of device 994 00:37:00,320 --> 00:37:02,400 so 995 00:37:02,400 --> 00:37:04,880 if you want to read the full write-ups 996 00:37:04,880 --> 00:37:07,040 you can find them at our blogs 997 00:37:07,040 --> 00:37:09,920 we will also publish the three write-ups 998 00:37:09,920 --> 00:37:12,160 we haven't been able to talk about today 999 00:37:12,160 --> 00:37:15,520 as soon as the vendor has fixed them 1000 00:37:15,520 --> 00:37:17,280 those vulnerabilities are 1001 00:37:17,280 --> 00:37:19,599 much more like the first one in ignition 1002 00:37:19,599 --> 00:37:22,000 we showed you like really simple 1003 00:37:22,000 --> 00:37:25,119 vulnerability to exploit um 1004 00:37:25,119 --> 00:37:26,320 the 1005 00:37:26,320 --> 00:37:28,160 trusted application bypass where ty's 1006 00:37:28,160 --> 00:37:30,240 talked about that was by far the most 1007 00:37:30,240 --> 00:37:32,079 difficult vulnerability we demonstrated 1008 00:37:32,079 --> 00:37:34,800 during this year of pawn to one 1009 00:37:34,800 --> 00:37:37,280 so if you are responsible for ics 1010 00:37:37,280 --> 00:37:39,760 security we would love to have a talk 1011 00:37:39,760 --> 00:37:42,880 with you so please come to our tent 1012 00:37:42,880 --> 00:37:45,680 and we can discuss this further 1013 00:37:45,680 --> 00:37:46,960 and if you like memory crops 1014 00:37:46,960 --> 00:37:50,000 informabilities we will talk about zoom 1015 00:37:50,000 --> 00:37:54,079 tomorrow at this place at 5 which 1016 00:37:54,079 --> 00:37:56,800 should also be a fun presentation 1017 00:37:56,800 --> 00:37:58,960 thank you all for your attention and if 1018 00:37:58,960 --> 00:38:00,480 you have any questions we'll be happy to 1019 00:38:00,480 --> 00:38:03,720 answer them 1020 00:38:05,040 --> 00:38:07,760 cool and slightly scary thank you very 1021 00:38:07,760 --> 00:38:10,000 much folks um we have plenty of time for 1022 00:38:10,000 --> 00:38:12,079 questions so if you have a question for 1023 00:38:12,079 --> 00:38:14,160 tayson dan uh there are microphones in 1024 00:38:14,160 --> 00:38:15,520 the center i want the back one at the 1025 00:38:15,520 --> 00:38:18,000 front please line up talk nice and 1026 00:38:18,000 --> 00:38:19,760 closely to the microphone but this is 1027 00:38:19,760 --> 00:38:22,480 probably too close thank you 1028 00:38:22,480 --> 00:38:24,720 thank you for a very interesting talk 1029 00:38:24,720 --> 00:38:25,839 um 1030 00:38:25,839 --> 00:38:28,240 can you give us a little 1031 00:38:28,240 --> 00:38:31,040 insight for you into how you research in 1032 00:38:31,040 --> 00:38:32,560 the 1033 00:38:32,560 --> 00:38:35,040 applications to find those 1034 00:38:35,040 --> 00:38:37,839 vulnerabilities 1035 00:38:38,000 --> 00:38:38,880 sure 1036 00:38:38,880 --> 00:38:39,680 so 1037 00:38:39,680 --> 00:38:41,200 one of the first things you do if you 1038 00:38:41,200 --> 00:38:44,000 want to look for vulnerability 1039 00:38:44,000 --> 00:38:45,599 is that you look at what everybody else 1040 00:38:45,599 --> 00:38:46,960 has already done 1041 00:38:46,960 --> 00:38:48,800 so one of the things we did is there was 1042 00:38:48,800 --> 00:38:51,599 another early edition of ponzo 1043 00:38:51,599 --> 00:38:53,839 miami where also there were some 1044 00:38:53,839 --> 00:38:56,400 vulnerabilities in inductive automation 1045 00:38:56,400 --> 00:38:58,000 ignition 1046 00:38:58,000 --> 00:38:59,440 and we read those white write-ups we 1047 00:38:59,440 --> 00:39:01,839 tried to understand what was wrong 1048 00:39:01,839 --> 00:39:03,200 there was some 1049 00:39:03,200 --> 00:39:05,440 java de-serialization vulnerability in 1050 00:39:05,440 --> 00:39:07,920 the same api that we used so our 1051 00:39:07,920 --> 00:39:10,079 starting point was to look at that same 1052 00:39:10,079 --> 00:39:12,800 api can we still do the same thing 1053 00:39:12,800 --> 00:39:15,200 but the conclusion was no 1054 00:39:15,200 --> 00:39:17,440 they check for those deserialization 1055 00:39:17,440 --> 00:39:19,440 vulnerabilities 1056 00:39:19,440 --> 00:39:22,320 for an authenticated api calls 1057 00:39:22,320 --> 00:39:24,320 if you are authenticated then the checks 1058 00:39:24,320 --> 00:39:25,760 were much 1059 00:39:25,760 --> 00:39:27,599 more lenient 1060 00:39:27,599 --> 00:39:30,000 so that really led us to 1061 00:39:30,000 --> 00:39:33,040 um yeah this idea of can we somehow 1062 00:39:33,040 --> 00:39:35,119 bypass that authentication 1063 00:39:35,119 --> 00:39:36,640 and that's how we got to looking for 1064 00:39:36,640 --> 00:39:39,040 that active directory 1065 00:39:39,040 --> 00:39:40,960 bypass 1066 00:39:40,960 --> 00:39:44,000 so it's often just trying to find what 1067 00:39:44,000 --> 00:39:46,160 everybody else has already done or 1068 00:39:46,160 --> 00:39:48,800 trying to find easy places to start 1069 00:39:48,800 --> 00:39:50,320 especially in these applications where 1070 00:39:50,320 --> 00:39:52,560 you have no idea what they are doing 1071 00:39:52,560 --> 00:39:53,520 it's 1072 00:39:53,520 --> 00:39:55,440 very helpful to help have somebody who 1073 00:39:55,440 --> 00:39:57,599 points to a specific place in the code 1074 00:39:57,599 --> 00:39:59,760 or specific feature that can be useful 1075 00:39:59,760 --> 00:40:02,160 to exploit yeah 1076 00:40:02,160 --> 00:40:03,680 typically you would you want to have a 1077 00:40:03,680 --> 00:40:06,480 focus point because otherwise the attack 1078 00:40:06,480 --> 00:40:09,119 surface is too broad 1079 00:40:09,119 --> 00:40:10,480 so 1080 00:40:10,480 --> 00:40:14,720 we typically focus on things we consider 1081 00:40:14,720 --> 00:40:16,960 difficult to implement correctly 1082 00:40:16,960 --> 00:40:18,079 or 1083 00:40:18,079 --> 00:40:21,119 easy to miss certain security checks 1084 00:40:21,119 --> 00:40:24,160 and we really focus on those areas and 1085 00:40:24,160 --> 00:40:26,240 we just do a deep dive and we try to 1086 00:40:26,240 --> 00:40:28,160 find a runability and if not we try to 1087 00:40:28,160 --> 00:40:30,400 find a different focus point but you 1088 00:40:30,400 --> 00:40:32,240 need to have a very specific focus point 1089 00:40:32,240 --> 00:40:33,839 which for the trusted application bypass 1090 00:40:33,839 --> 00:40:36,079 was easy because yeah 1091 00:40:36,079 --> 00:40:38,640 the only attitude audit one function the 1092 00:40:38,640 --> 00:40:40,560 certificate check function and all the 1093 00:40:40,560 --> 00:40:42,240 other stuff because we didn't care about 1094 00:40:42,240 --> 00:40:44,000 the remote code execution vulnerability 1095 00:40:44,000 --> 00:40:46,640 etc we just ignored them so that made it 1096 00:40:46,640 --> 00:40:48,720 easier 1097 00:40:48,720 --> 00:40:50,640 about the 1098 00:40:50,640 --> 00:40:51,599 sorry 1099 00:40:51,599 --> 00:40:53,280 about the 1100 00:40:53,280 --> 00:40:55,680 certification uh bypass 1101 00:40:55,680 --> 00:40:57,119 what was the reason that the vendor 1102 00:40:57,119 --> 00:40:58,640 decided to 1103 00:40:58,640 --> 00:41:02,960 ignore an invalid root certificate 1104 00:41:02,960 --> 00:41:04,160 so 1105 00:41:04,160 --> 00:41:06,240 that's because as they described it to 1106 00:41:06,240 --> 00:41:08,079 us they don't know to use the window 1107 00:41:08,079 --> 00:41:10,000 certificate store because it's difficult 1108 00:41:10,000 --> 00:41:13,440 to manage for people in practice 1109 00:41:13,440 --> 00:41:14,960 according to them 1110 00:41:14,960 --> 00:41:17,520 so what they wanted was to just 1111 00:41:17,520 --> 00:41:19,440 have one directory where you can play 1112 00:41:19,440 --> 00:41:21,839 some dot pam files 1113 00:41:21,839 --> 00:41:24,720 and that's your trusted certificate root 1114 00:41:24,720 --> 00:41:25,839 um 1115 00:41:25,839 --> 00:41:28,560 so that's why they didn't configure the 1116 00:41:28,560 --> 00:41:31,680 the trusted root certificates of the 1117 00:41:31,680 --> 00:41:35,040 the that api that they were using 1118 00:41:35,040 --> 00:41:37,760 um so yeah that leads to certain errors 1119 00:41:37,760 --> 00:41:39,200 that may happen because they didn't 1120 00:41:39,200 --> 00:41:41,119 configure it in a way that is intended 1121 00:41:41,119 --> 00:41:41,920 to 1122 00:41:41,920 --> 00:41:44,319 which can yeah they then have to ignore 1123 00:41:44,319 --> 00:41:46,960 because yeah it's actually trusted 1124 00:41:46,960 --> 00:41:49,599 because they checked that 1125 00:41:49,599 --> 00:41:51,599 i think that 1126 00:41:51,599 --> 00:41:52,880 it should be but we haven't looked at 1127 00:41:52,880 --> 00:41:54,800 the api ourselves but i think it should 1128 00:41:54,800 --> 00:41:56,960 be possible to just use that api and 1129 00:41:56,960 --> 00:41:59,119 give it some trusted root certificates 1130 00:41:59,119 --> 00:42:00,880 say okay check this 1131 00:42:00,880 --> 00:42:02,960 jane these are the rest root 1132 00:42:02,960 --> 00:42:04,480 certificates we trust don't use the 1133 00:42:04,480 --> 00:42:07,280 windows thrust store use this one but 1134 00:42:07,280 --> 00:42:08,720 they didn't do that 1135 00:42:08,720 --> 00:42:10,960 so they built their own implementation 1136 00:42:10,960 --> 00:42:13,520 and then verified that with the api yeah 1137 00:42:13,520 --> 00:42:15,040 and then you get two different chains 1138 00:42:15,040 --> 00:42:17,520 and all kinds of uh complexity yeah we 1139 00:42:17,520 --> 00:42:19,520 are not net developers we are not sure 1140 00:42:19,520 --> 00:42:21,680 if it's really not possible to do this 1141 00:42:21,680 --> 00:42:23,119 and we also need to keep in mind that 1142 00:42:23,119 --> 00:42:25,119 they need to it needs to run on windows 1143 00:42:25,119 --> 00:42:26,880 mac os and linux 1144 00:42:26,880 --> 00:42:27,760 so they 1145 00:42:27,760 --> 00:42:29,280 there are some differences between the 1146 00:42:29,280 --> 00:42:31,359 implementations there as well 1147 00:42:31,359 --> 00:42:35,200 i see thank you very much of course 1148 00:42:36,319 --> 00:42:38,319 hey so you call these vulnerabilities 1149 00:42:38,319 --> 00:42:40,000 long hanging fruit 1150 00:42:40,000 --> 00:42:41,599 do you know how many others looked at 1151 00:42:41,599 --> 00:42:44,079 the same software and if the how many 1152 00:42:44,079 --> 00:42:46,319 collisions there were 1153 00:42:46,319 --> 00:42:48,640 so there were quite a few collisions we 1154 00:42:48,640 --> 00:42:50,640 even had one collision one of the remote 1155 00:42:50,640 --> 00:42:52,960 code execution vulnerabilities was a 1156 00:42:52,960 --> 00:42:54,000 collision there was also the 1157 00:42:54,000 --> 00:42:56,560 vulnerability we found in 15 minutes 1158 00:42:56,560 --> 00:42:57,359 so 1159 00:42:57,359 --> 00:42:59,119 we already figured that 1160 00:42:59,119 --> 00:43:01,119 there is quite a reasonable assumption 1161 00:43:01,119 --> 00:43:02,560 that somebody else has found the same 1162 00:43:02,560 --> 00:43:03,839 vulnerability 1163 00:43:03,839 --> 00:43:06,880 yeah so the war zone collisions um 1164 00:43:06,880 --> 00:43:09,680 but yeah most applications have 1165 00:43:09,680 --> 00:43:12,240 very wide attack surface so there is 1166 00:43:12,240 --> 00:43:13,040 still 1167 00:43:13,040 --> 00:43:15,440 more vulnerabilities to be found 1168 00:43:15,440 --> 00:43:19,200 in more obscure places 1169 00:43:21,680 --> 00:43:24,319 okay if there's no more questions i 1170 00:43:24,319 --> 00:43:26,480 think all that remains is to once again 1171 00:43:26,480 --> 00:43:28,480 give tess and dan a very big round of 1172 00:43:28,480 --> 00:43:30,560 applause thank you 1173 00:43:30,560 --> 00:43:32,340 thank you very much 1174 00:43:32,340 --> 00:43:33,300 [Music] 1175 00:43:33,300 --> 00:43:36,439 [Applause]