WEBVTT 1 00:00:00.120 --> 00:00:03.799 Welcome to the deep dive. Today, we're cracking open your 2 00:00:04.000 --> 00:00:07.200 provided excerpts from the Vulnerability Researcher's Handbook. 3 00:00:07.280 --> 00:00:07.799 Sounds good. 4 00:00:08.439 --> 00:00:10.880 Yeah, I think of this less like a dry technical 5 00:00:10.880 --> 00:00:13.519 manual and more like a backstage pass. You know. We're 6 00:00:13.519 --> 00:00:16.719 looking at solfware vulnerabilities, how they're found, what happens next, 7 00:00:17.079 --> 00:00:20.879 and why it all matters for keeping our digital stuff secure. Absolutely, 8 00:00:20.920 --> 00:00:23.559 we'll trace their life cycle, look at the common types, 9 00:00:23.600 --> 00:00:26.280 and even get into some of the wealthy ethics around 10 00:00:26.320 --> 00:00:26.920 finding them. 11 00:00:27.760 --> 00:00:31.480 Yeah. I mean, it's hard to really overstate how much 12 00:00:31.800 --> 00:00:36.000 software runs things now, everything pretty much your phone, apps, 13 00:00:36.479 --> 00:00:41.200 critical infrastructure. It's all code. And well, where there's code, 14 00:00:41.240 --> 00:00:43.799 there can be weaknesses, vulnerabilities. 15 00:00:43.079 --> 00:00:45.200 And those are the open doors for attackers. 16 00:00:44.799 --> 00:00:49.719 Exactly, cybercrime, privacy breaches, even disrupting major systems or national 17 00:00:49.759 --> 00:00:53.240 security risks. And the really tricky part is the unknown ones. 18 00:00:53.320 --> 00:00:54.719 They're just lurking. 19 00:00:54.320 --> 00:00:57.600 There, undisclosed stuff, hard to defend against what you don't 20 00:00:57.640 --> 00:01:01.520 know exists precisely. Okay, so finding and sounds tough. But 21 00:01:01.600 --> 00:01:04.280 once a researcher does find a vulnerability, how do they 22 00:01:04.359 --> 00:01:06.599 know how bad it is? Is it just a guess? 23 00:01:06.879 --> 00:01:08.840 Oh not at all. There's actually a system for this. 24 00:01:09.000 --> 00:01:12.719 It's quite structured. It's called the Common Vulnerability Scoring System 25 00:01:12.879 --> 00:01:17.799 CVSS for short. Think of it like a standardized ruler 26 00:01:17.959 --> 00:01:21.040 for measuring how severe a flaw is the common language 27 00:01:21.079 --> 00:01:24.120 exactly that. It helps security pros talk about the impact. 28 00:01:24.400 --> 00:01:29.200 It calculates a score based on well, how it affects confidentiality, integrity, 29 00:01:29.239 --> 00:01:31.680 and availability. The CIA triad. 30 00:01:31.799 --> 00:01:35.280 It's like a risk score, right, The CIA triad makes sense? 31 00:01:35.599 --> 00:01:39.079 So are there specific tools researchers used to hunt these 32 00:01:39.120 --> 00:01:41.000 down like digital bloodhounds. 33 00:01:41.120 --> 00:01:45.920 There definitely are vulnerability standing tools. They help automate finding, classifying, 34 00:01:45.959 --> 00:01:47.719 and you know, prioritizing risks. 35 00:01:47.959 --> 00:01:48.519 The example. 36 00:01:48.719 --> 00:01:51.120 Sure, you've got things like nikto that's an open source 37 00:01:51.120 --> 00:01:54.280 one command line mostly for web servers. Then there are 38 00:01:54.280 --> 00:01:58.719 commercial ones like rapids of an Expose or Qualless Vulnerability Management. 39 00:01:58.760 --> 00:02:02.159 They usually have more features. Dashboards link up with other tools, 40 00:02:02.400 --> 00:02:03.040 so you run. 41 00:02:02.920 --> 00:02:05.879 A scan and bam, all the problems pop up. Seems 42 00:02:05.879 --> 00:02:06.400 a bit too. 43 00:02:06.319 --> 00:02:09.680 Easy, ha, Well yeah, it's not quite magic. These tools 44 00:02:09.719 --> 00:02:12.000 are really valuable, but you have to understand their limits. 45 00:02:12.120 --> 00:02:12.439 Okay. 46 00:02:12.560 --> 00:02:16.199 They basically work off databases of known vulnerabilities. So if 47 00:02:16.199 --> 00:02:18.680 something is brand new a zero day. 48 00:02:18.639 --> 00:02:21.639 Ah, okay, so only known stuff right exactly? 49 00:02:22.120 --> 00:02:24.360 Or if the tool just isn't programmed to look for 50 00:02:24.400 --> 00:02:27.199 that specific type of flaw, it might miss it like 51 00:02:27.240 --> 00:02:28.400 an old virus scanner. 52 00:02:29.000 --> 00:02:31.400 Got it. So what are the usual suspects? Then? What 53 00:02:31.479 --> 00:02:34.400 kinds of flaws pop up most often? 54 00:02:34.520 --> 00:02:36.759 Well, if we look at web applications, a really common 55 00:02:36.759 --> 00:02:39.319 one is cross site scripting XSS. 56 00:02:39.000 --> 00:02:41.360 Right EXSS, I've heard of that. That's where they inject 57 00:02:41.439 --> 00:02:42.439 code into websites. 58 00:02:42.680 --> 00:02:46.080 Exactly. An attacker slips malicious code into a site and 59 00:02:46.120 --> 00:02:48.240 then it runs in the browser of anyone who visits, 60 00:02:48.639 --> 00:02:51.599 often exploits bad input handling sneaky. 61 00:02:51.919 --> 00:02:53.560 How does that work? Different types? 62 00:02:53.719 --> 00:02:56.759 Yeah, there are a few flavors. Persistent EXSS stores the 63 00:02:56.800 --> 00:02:59.960 bad code right on the site. Reflected EXSS usually come 64 00:03:00.120 --> 00:03:04.479 from clicking a bad link, and dom based XSS messes 65 00:03:04.520 --> 00:03:07.120 with how JavaScript on the page handles data. 66 00:03:07.159 --> 00:03:09.840 Okay, that sounds like a major headache. What else is common? 67 00:03:10.159 --> 00:03:14.400 Another big category is injection attacks SQL injection and no 68 00:03:14.560 --> 00:03:15.400 sequel injection. 69 00:03:15.560 --> 00:03:17.680 That's attacking the database directly. 70 00:03:17.319 --> 00:03:20.439 Pretty much imagine a log in form If the site 71 00:03:20.479 --> 00:03:23.240 isn't careful an attacker can type stuff into that form 72 00:03:23.280 --> 00:03:26.240 that actually sends commands straight to the database. They could 73 00:03:26.280 --> 00:03:28.719 grab data, maybe even take control. 74 00:03:28.919 --> 00:03:29.520 Wow. 75 00:03:29.759 --> 00:03:32.560 Then there's command injection. That's where they trick the server 76 00:03:32.599 --> 00:03:36.800 itself into running commands. Could lead to a total takeover kes. 77 00:03:37.439 --> 00:03:42.719 And let's not forget cross site request forgery CSRF. That's 78 00:03:42.719 --> 00:03:45.199 like tricking you into doing something malicious on a site 79 00:03:45.199 --> 00:03:48.000 you're logged into just by clicking a link or visiting 80 00:03:48.000 --> 00:03:49.039 a compromise page. 81 00:03:49.120 --> 00:03:51.960 So making my browser do bad things on my behalf exactly. 82 00:03:52.080 --> 00:03:54.280 And these are just common web app issues. Clients over 83 00:03:54.319 --> 00:03:56.919 apps have their own set of potential problems too, of course. 84 00:03:57.120 --> 00:04:01.039 Okay, so vulnerabilities get introduced somehow, they take different forms, 85 00:04:01.800 --> 00:04:04.840 but what's their lifespan? Is there like a typical journey. 86 00:04:05.280 --> 00:04:08.199 It's not always perfectly linear, but yeah, you can think 87 00:04:08.240 --> 00:04:11.439 of a general life cycle. First is inception, how it 88 00:04:11.479 --> 00:04:15.719 gets in there, coding error, bad configuration whatever. Then discovery 89 00:04:15.719 --> 00:04:19.560 someone finds it right after that often exploitation and remediation, 90 00:04:20.240 --> 00:04:22.439 so it gets used from MARM and then people try 91 00:04:22.480 --> 00:04:27.759 to fix it. Finally, finally maybe deprecation. The software gets updated, replaced, 92 00:04:28.079 --> 00:04:32.759 the vulnerability becomes less relevant, but stages can overlap, things 93 00:04:32.800 --> 00:04:33.800 can get rediscovered. 94 00:04:34.600 --> 00:04:36.920 It's messy sometimes, and right in the middle of that 95 00:04:36.959 --> 00:04:39.279 you have the really scary ones, the zero days. What 96 00:04:39.360 --> 00:04:40.879 makes them so much worse. 97 00:04:40.920 --> 00:04:44.279 Zero days are exploits for vulnerabilities that the developers don't 98 00:04:44.319 --> 00:04:45.000 know about yet. 99 00:04:45.040 --> 00:04:48.279 Ah, So no patch exists when it's first founder. 100 00:04:48.040 --> 00:04:51.360 Used exactly, That's the critical part. There's no immediate fix. 101 00:04:51.480 --> 00:04:54.199 It can take ages for developers to even realize there's 102 00:04:54.199 --> 00:04:57.000 a problem, let alone create, test and release a patch, 103 00:04:57.079 --> 00:04:57.600 and even. 104 00:04:57.439 --> 00:04:59.439 Then people might not install the patch right away. 105 00:04:59.519 --> 00:05:02.639 Precisely. Look at Eternal Blue. That exploit was used in 106 00:05:02.680 --> 00:05:06.319 the huge WannaCry ransomware attacks. Microsoft had released a patch, 107 00:05:06.360 --> 00:05:09.360 but tons of systems weren't updated. The damage was massive. 108 00:05:09.720 --> 00:05:12.240 That really drives home the danger you mentioned. We have 109 00:05:12.279 --> 00:05:14.680 some real world zero day examples. Can we dig into 110 00:05:14.680 --> 00:05:15.680 those see how it plays out? 111 00:05:15.839 --> 00:05:19.560 Absolutely, real cases make it much clearer. Let's take Pulse 112 00:05:19.560 --> 00:05:25.360 connect Secure CVE twenty nineteen eleven fifteen. Okay, researchers found it, 113 00:05:25.399 --> 00:05:29.160 reported it responsibly. The vendor, pulse Secure, put out a 114 00:05:29.199 --> 00:05:30.279 patch fairly quickly. 115 00:05:30.480 --> 00:05:31.680 Sounds like a success story. 116 00:05:31.800 --> 00:05:35.800 Well yes, and no. Here's the twist. Other researchers then 117 00:05:36.079 --> 00:05:38.319 took that patch, reverse engineered it. 118 00:05:38.279 --> 00:05:40.519 Figured out how the original bug works from the fix. 119 00:05:40.519 --> 00:05:44.800 Exactly, and then they released public exploit code. So the 120 00:05:44.839 --> 00:05:48.240 initial discovery was zero day, but the wave of attacks 121 00:05:48.240 --> 00:05:52.480 that followed wasn't technically because the flaw was then known. Fascinating, 122 00:05:52.800 --> 00:05:55.839 and what's also interesting, the original researchers later used their 123 00:05:55.879 --> 00:05:59.759 knowledge ethically. They found vulnerable systems, reported them through bug 124 00:05:59.759 --> 00:06:02.639 bound counties, even got a big payout from Twitter for 125 00:06:02.720 --> 00:06:04.560 finding it in their VPN setup. 126 00:06:04.720 --> 00:06:07.319 So the path isn't always straightforward, not at all. 127 00:06:07.399 --> 00:06:10.439 It shows how complex the weaponization can be. 128 00:06:10.560 --> 00:06:11.959 What's another example, how. 129 00:06:11.839 --> 00:06:15.600 About at Lassian Confluence CVE twenty twenty one two six 130 00:06:15.720 --> 00:06:19.800 zero eighty four. This was an OGNL injection flaw allowed 131 00:06:19.839 --> 00:06:23.600 remote code execution, no login needed ouch and the kicker 132 00:06:23.879 --> 00:06:26.759 it was discovered while it was already being actively exploited 133 00:06:26.800 --> 00:06:27.920 out in the wild. 134 00:06:27.639 --> 00:06:30.240 So the attackers found it first, or at least used 135 00:06:30.279 --> 00:06:30.720 it first. 136 00:06:30.800 --> 00:06:34.279 Teams that way. To Alastian's credit, they reacted fast, issued 137 00:06:34.319 --> 00:06:36.800 a patch used in Apple alerts. It was actually a 138 00:06:36.800 --> 00:06:39.240 better response than for a similar issue they had earlier. 139 00:06:39.480 --> 00:06:43.040 CVE twenty nineteen three three ninety six shows the improvement. 140 00:06:43.120 --> 00:06:45.399 So in that case, the vulnerability, the exploit, the attack 141 00:06:45.480 --> 00:06:46.360 all hit it once as. 142 00:06:46.319 --> 00:06:49.240 A zero day essentially, Yeah, a real scramble. 143 00:06:48.839 --> 00:06:51.800 That is sobering attackers finding things first it happens. 144 00:06:52.040 --> 00:06:55.360 Another one Microsoft dot Net CVE twenty seventeen eight seven 145 00:06:55.480 --> 00:06:58.560 five nine, also found after it's being exploited, clearly part 146 00:06:58.600 --> 00:07:00.920 of an active campaign. And then there was the Citrix 147 00:07:00.959 --> 00:07:05.040 ADC Gateway vulnerability CVE twenty nineteen nineteen seven eight one, 148 00:07:05.399 --> 00:07:09.240 nicknamed Shitrix by some Yeah, okay, serious issue though very 149 00:07:09.319 --> 00:07:12.240 unauthorized remote code execution. Again, it was disclosed to Citrix, 150 00:07:12.279 --> 00:07:14.839 but the patch took over a month. They suggested mitigations 151 00:07:14.839 --> 00:07:16.839 in the meantime. Hmm, the month is a long time, 152 00:07:17.160 --> 00:07:19.879 it is, and it raises a tough question right when 153 00:07:19.920 --> 00:07:23.560 disclosure happens but there's no immediate patch. Does that early 154 00:07:23.600 --> 00:07:26.959 warning help users more or does it just give attackers 155 00:07:26.959 --> 00:07:27.560 a heads up? 156 00:07:27.920 --> 00:07:31.439 Yeah, that's a tricky balance. These cases really show the 157 00:07:31.519 --> 00:07:35.079 different facets and the ethical typrope everyone's. 158 00:07:34.720 --> 00:07:39.959 Walking, absolutely, and that brings us to responsibilities. Vendors for instance, 159 00:07:40.279 --> 00:07:42.800 really need to work with research ever we got against 160 00:07:42.839 --> 00:07:47.000 them right. Hostile policies like sending cease and desist letters 161 00:07:47.000 --> 00:07:50.240 for good faith research that just pushes researchers to maybe 162 00:07:50.279 --> 00:07:54.600 sell the vulnerability or go public out of frustration. Clear, 163 00:07:54.759 --> 00:07:58.160 safe harbor and responsible disclosure policies are key and. 164 00:07:58.199 --> 00:08:00.600 The vendor's duty to us the users. 165 00:08:00.800 --> 00:08:04.360 Fundamentally, they have to protect their users, patching known flaws 166 00:08:04.360 --> 00:08:07.920 and supported products, giving mitigation advice. They should also nudge 167 00:08:07.920 --> 00:08:11.240 people using old versions to upgrade if user data gets 168 00:08:11.279 --> 00:08:14.279 compromised because of a software flaw. The vendor really bears 169 00:08:14.319 --> 00:08:15.480 a lot of the responsibility. 170 00:08:15.600 --> 00:08:17.360 Makes sense, and it's not just their own code they 171 00:08:17.360 --> 00:08:19.439 need to worry about. Is it software uses lots of 172 00:08:19.480 --> 00:08:20.480 other bits and pieces. 173 00:08:20.759 --> 00:08:24.319 That's a huge point. Modern software is built on layers, 174 00:08:24.560 --> 00:08:29.600 open source libraries underlying operating systems. Vendors can't just secure 175 00:08:29.639 --> 00:08:32.240 their little piece and ignore the foundation. 176 00:08:32.200 --> 00:08:35.240 Like the wantacray example hitting old Windows XP systems. 177 00:08:35.279 --> 00:08:38.759 Exactly, if a vendor sells you a whole package hardware 178 00:08:38.799 --> 00:08:41.440 and software, they need to think about the security of 179 00:08:41.440 --> 00:08:44.480 the entire thing, not just the parts they wrote from scratch. 180 00:08:44.600 --> 00:08:48.360 Okay, so shifting gears a bit. If someone listening is thinking, hey, 181 00:08:48.360 --> 00:08:51.919 I want to find these things. What's the typical starting point? 182 00:08:51.960 --> 00:08:54.399 How does that research process usually work? 183 00:08:54.679 --> 00:08:57.919 Well? The general path usually starts with identifying a target, 184 00:08:58.399 --> 00:09:00.919 What software hardware do you want to look at? Then 185 00:09:00.960 --> 00:09:04.200 you research it, how does it work? Where might weaknesses lie? 186 00:09:04.879 --> 00:09:08.120 Then comes the attempt to actually exploite those potential weaknesses, 187 00:09:08.519 --> 00:09:11.159 but in a safe, controlled way in a lab environment. 188 00:09:11.240 --> 00:09:15.279 Absolutely critical. If you find something, you document it thoroughly clear, 189 00:09:15.360 --> 00:09:18.720 report steps to reproduce it, and finally you submit that 190 00:09:18.759 --> 00:09:20.639 report to the right people the vendor. 191 00:09:20.879 --> 00:09:23.879 Usually it sounds a bit like lock picking. Study the lock, 192 00:09:24.120 --> 00:09:25.759 find flaws, try to open it. 193 00:09:25.840 --> 00:09:29.840 Document how that's a great analogy. Actually, yeah, studying the design, 194 00:09:30.039 --> 00:09:35.279 finding weaknesses, testing techniques, reporting back, maybe even suggesting improvements. 195 00:09:35.480 --> 00:09:37.480 Are there places to learn more? Get started? 196 00:09:37.600 --> 00:09:41.200 Oh? Definitely? The full disclosure mailing list is classic for 197 00:09:41.240 --> 00:09:44.919 seeing what others are finding. Defcon talk recordings are fantastic 198 00:09:45.000 --> 00:09:49.399 for deep dives. Vendor security bulletins Microsoft, Uboon, tou etc. 199 00:09:49.919 --> 00:09:53.399 Are essential if you're focused on their products, and oh 200 00:09:53.399 --> 00:09:57.240 wus The Open Web Application Security Project has tons of resources, 201 00:09:57.320 --> 00:10:01.480 especially for web stuff, But honestly, practice is everything. Set 202 00:10:01.519 --> 00:10:03.200 up a lab, start experimenting. 203 00:10:03.240 --> 00:10:06.440 Okay, choosing a target. There's so much software, how do 204 00:10:06.480 --> 00:10:09.159 you even pick where to look? Seems overwhelming? 205 00:10:09.240 --> 00:10:12.279 It can be. Choosing strategically helps. Start with something you're 206 00:10:12.320 --> 00:10:14.080 actually interested in that keeps you motivated. 207 00:10:14.200 --> 00:10:14.639 Makes sense. 208 00:10:14.840 --> 00:10:19.120 Also, think about likelihood. Is the software complex old? Does 209 00:10:19.120 --> 00:10:21.840 it have a huge user base but maybe hasn't been 210 00:10:21.840 --> 00:10:25.200 looked at closely for security? Those can sometimes be well 211 00:10:25.399 --> 00:10:29.519 fruitful areas well. Consider what you can realistically test. Do 212 00:10:29.600 --> 00:10:33.000 you have the means? And crucially do you have permission? 213 00:10:33.039 --> 00:10:35.000 If it's not your own system, that's non. 214 00:10:34.960 --> 00:10:36.840 Negotiable, right, Permission is key. 215 00:10:37.039 --> 00:10:42.120 Maybe focus on software handling valuable data and align it 216 00:10:42.159 --> 00:10:44.720 with your skills or what you want to learn, and 217 00:10:44.960 --> 00:10:48.799 always always in an isolated test environment. Cannot stress that enough. 218 00:10:49.320 --> 00:10:53.279 You mentioned an interesting example in the handbook Horse Management Software. 219 00:10:53.399 --> 00:10:54.440 Why that right? 220 00:10:54.840 --> 00:10:58.799 That was just an illustration of finding niches. Sometimes specialized 221 00:10:58.799 --> 00:11:01.440 software for an industry or or hobby hasn't had the 222 00:11:01.480 --> 00:11:04.559 same security scrutiny as say Windows itself. 223 00:11:04.679 --> 00:11:07.200 Ah, Okay, less common targets exactly. 224 00:11:07.480 --> 00:11:10.120 You might find something older on source forge, Maybe get 225 00:11:10.120 --> 00:11:13.159 a free demo, look at the features? Does it handle billing, 226 00:11:13.679 --> 00:11:16.720 personal info? The age itself can be a clue. Older 227 00:11:16.720 --> 00:11:20.120 code might use outdated, less secure practices. The point is 228 00:11:20.320 --> 00:11:23.279 finding something accessible you can test safely in your lab 229 00:11:23.360 --> 00:11:25.559 where there's a decent chance of finding something interesting, and. 230 00:11:25.480 --> 00:11:27.159 Once you have a target, you don't just poke at 231 00:11:27.159 --> 00:11:29.360 it randomly. Right you mentioned test cases. 232 00:11:29.639 --> 00:11:33.720 Definitely not random. Structure testing is way more effective and 233 00:11:33.759 --> 00:11:35.120 you don't have to start from scratch. 234 00:11:35.519 --> 00:11:37.399 Use existing resources absolutely. 235 00:11:38.200 --> 00:11:43.000 The OAS Web Security Testing Guide WSTG is amazing for 236 00:11:43.039 --> 00:11:46.960 wear apps. Frameworks like mitery, ATT and CK give you 237 00:11:47.039 --> 00:11:50.039 a way to think about different attacker techniques. 238 00:11:49.559 --> 00:11:51.120 So you use those to build your tests. 239 00:11:51.279 --> 00:11:55.080 Yeah, structure your test cases. What's the goal? Maybe link 240 00:11:55.080 --> 00:11:57.320 it to an att and CK tactic. What are the 241 00:11:57.360 --> 00:12:00.759 exact testing steps? Maybe you're trying dl high jacking techniques 242 00:12:00.759 --> 00:12:03.519 you found on hat tricks and think about potential fixes 243 00:12:03.559 --> 00:12:06.720 based on best practices. Clear goals make the whole process 244 00:12:06.840 --> 00:12:07.799 much more focused. 245 00:12:07.919 --> 00:12:12.039 Okay, leveraging existing knowledge, structured approach. Got it? What about 246 00:12:12.080 --> 00:12:15.559 the tools of the trade. What's in a vulnerability researcher's toolkit? 247 00:12:15.679 --> 00:12:19.679 Oh, there's quite a range basic stuff. First note, ticking screenshots, 248 00:12:19.759 --> 00:12:23.919 screen recording tools like cherry Tree, green shot obs are popular. 249 00:12:23.960 --> 00:12:25.240 For documentation exactly. 250 00:12:25.399 --> 00:12:29.480 Then the core testing environment hypervisors and VMS. VMware Workstation 251 00:12:29.559 --> 00:12:33.480 pro is great, commercial, has snapshots, virtual boxes, free, open source, 252 00:12:33.600 --> 00:12:36.600 very common. Hyper v is built into Windows, and you 253 00:12:36.639 --> 00:12:39.279 can save time with pre built dms designed for security. 254 00:12:39.480 --> 00:12:43.120 Collie Linux is the famous one, but also mobexler, Remnucks, 255 00:12:43.240 --> 00:12:46.360 the trace labs, ocent vm lots of options. 256 00:12:46.519 --> 00:12:49.840 What about specific testing tools for web apps? 257 00:12:49.919 --> 00:12:54.519 Proxies are essential. Burpsuite is the industry standard, powerful but commercial. 258 00:12:55.159 --> 00:12:59.320 Zap is a great free, open source alternative both let 259 00:12:59.320 --> 00:13:01.120 you intercept and mess with web. 260 00:13:00.960 --> 00:13:03.960 Traffic and for non web stuff looking inside applications. 261 00:13:04.039 --> 00:13:06.840 Yeah, then you need debuggers like alidbiger, wind big to 262 00:13:06.919 --> 00:13:10.720 step through code execution. Decompilers and disassemblers let you reverse 263 00:13:10.720 --> 00:13:15.519 engineer compiled code. Redard To and Guidra are amazing free options. 264 00:13:15.559 --> 00:13:19.000 IDPro is a commercial king but expensive, and the CIS 265 00:13:19.000 --> 00:13:22.360 Internal Suite has indispensable utilities for Windows research. 266 00:13:22.519 --> 00:13:24.799 That's a serious toolkit. Okay, So let's say you use 267 00:13:24.840 --> 00:13:27.039 these tools, you follow your test cases, and bingo, you 268 00:13:27.080 --> 00:13:29.440 find a vulnerability. Now, what how do you tell people? 269 00:13:29.519 --> 00:13:31.120 That's vulnerability disclosure. 270 00:13:30.759 --> 00:13:34.919 Right exactly, communicating your findings responsibly is critical. Think back 271 00:13:34.919 --> 00:13:37.399 to Dan Kaminski and the DNS flaw in two thousand 272 00:13:37.440 --> 00:13:39.039 and eight. That was a landmark case. 273 00:13:39.120 --> 00:13:39.799 What happened there. 274 00:13:40.039 --> 00:13:43.360 He found a really fundamental flaw in how DNS worked, 275 00:13:43.440 --> 00:13:46.960 but instead of just dropping it publicly, he worked quietly 276 00:13:47.000 --> 00:13:51.000 behind the scenes with Microsoft, Cisco, all the big players 277 00:13:51.679 --> 00:13:54.559 got patches developed before he announced it publicly at the 278 00:13:54.559 --> 00:13:59.320 black Hat conference. Coordinated approach, Yes, minimize the chaos, set 279 00:13:59.360 --> 00:14:01.879 a great press for handling critical stuff. 280 00:14:02.279 --> 00:14:05.320 So that's one model coordinated disclosure. Are there others? 281 00:14:05.639 --> 00:14:08.879 There are a few main types. Coordinated is generally preferred. 282 00:14:09.200 --> 00:14:11.759 Work with the vendor, give them time to patch before 283 00:14:11.759 --> 00:14:12.399 going public. 284 00:14:12.559 --> 00:14:12.879 Okay. 285 00:14:13.200 --> 00:14:16.200 Then there's private disclosure. You just tell the vendor and 286 00:14:16.279 --> 00:14:18.679 they decide how and when to fix it and announce 287 00:14:18.720 --> 00:14:21.600 it common if you're hired for a penetration test. 288 00:14:21.519 --> 00:14:22.679 Right part of the contract. 289 00:14:22.759 --> 00:14:25.440 And then there's full disclosure. That's just releasing all the 290 00:14:25.440 --> 00:14:28.879 details publicly, maybe with little or no warning to the vendor. 291 00:14:29.080 --> 00:14:31.960 It's controversial, arguments for and against it. In terms of 292 00:14:32.000 --> 00:14:33.679 protecting users, Where do. 293 00:14:33.720 --> 00:14:36.600 Big bounty programs fit in? They seem really common now. 294 00:14:36.679 --> 00:14:39.399 Yeah, they've become a big part of the landscape platforms 295 00:14:39.440 --> 00:14:42.679 like hacker own bug crowd, they act as go betweens. 296 00:14:42.720 --> 00:14:43.399 How do they work? 297 00:14:43.720 --> 00:14:46.320 The company sets the rules, what you can test, what 298 00:14:46.399 --> 00:14:49.559 kind of bugs they'll pay for. Researchers submit reports through 299 00:14:49.559 --> 00:14:52.639 the platform. It streamlines things, creates. 300 00:14:52.320 --> 00:14:55.480 A record, sounds good anty downsides. 301 00:14:54.919 --> 00:14:58.440 Well, the platforms themselves aren't always motivated to fight for 302 00:14:58.480 --> 00:15:01.480 the researcher's pay out if there's a dispute, and sometimes 303 00:15:01.480 --> 00:15:04.759 the scope can be limiting or findings get dismixed unfairly. 304 00:15:05.279 --> 00:15:09.120 They're useful, but not a replacement for a solid, overall 305 00:15:09.159 --> 00:15:11.879 responsible disclosure policy from the company itself. 306 00:15:12.120 --> 00:15:15.200 So if there's no bug bounty, how do you initiate contact? 307 00:15:15.240 --> 00:15:16.279 Just email them. 308 00:15:16.080 --> 00:15:19.759 Pretty much, gather your info about the vendor, about your findings. 309 00:15:19.919 --> 00:15:24.080 Your first email should be clear, state your intentions, reward 310 00:15:24.120 --> 00:15:26.840 dot credit, just want it fixed, Include a solid proof 311 00:15:26.879 --> 00:15:30.840 of concept evidence, and keep the tone professional. No threats, 312 00:15:30.919 --> 00:15:34.159 no demands, no vague you've been hacked stuff, be specific. 313 00:15:34.519 --> 00:15:37.519 Then maybe followup politely every thirty days or so, give 314 00:15:37.519 --> 00:15:39.480 them up to ninety days for a proper response. 315 00:15:39.600 --> 00:15:42.039 Generally, why don't they just ignore you? Where they get hostile? 316 00:15:42.320 --> 00:15:46.080 Yeah, that happens if they're unresponsive, you could try community forums, 317 00:15:46.440 --> 00:15:50.159 maybe find unofficial support folks. Full disclosure is a last 318 00:15:50.159 --> 00:15:53.080 resort and maybe even then hold back the working exploit 319 00:15:53.159 --> 00:15:55.440 if there's no fix to avoid immediate. 320 00:15:55.080 --> 00:15:57.600 Harm and hostile vendors unfortunately. 321 00:15:57.720 --> 00:16:01.480 Yeah, be prepared for legal threats, maybe even social engineering 322 00:16:01.480 --> 00:16:05.039 attempts against you. There have been nasty cases. Using an 323 00:16:05.080 --> 00:16:08.200 alias during research and initial contact can offer some protection. 324 00:16:08.399 --> 00:16:12.720 It's a tough spot, definitely sounds challenging. So assuming disclosure happens, 325 00:16:12.720 --> 00:16:16.000 maybe it gets fixed. How does the world learn about 326 00:16:16.039 --> 00:16:18.919 this vulnerability? Formally publishing it? 327 00:16:19.120 --> 00:16:22.279 Yes, publishing is really important for the broader community. Getting 328 00:16:22.320 --> 00:16:26.600 findings into recognized databases helps everyone. Think about Armis Labs 329 00:16:26.639 --> 00:16:30.399 and their Blueborn research on Bluetooth flaws. They published a 330 00:16:30.480 --> 00:16:34.960 huge white paper, got multiple cvees assigned. That raised massive awareness, 331 00:16:34.960 --> 00:16:40.039 pushed vendors to fix things, spurred more research. Publishing drives progress. 332 00:16:39.639 --> 00:16:43.159 And CVE common vulnerabilities and exposures. That's the main database, right. 333 00:16:43.080 --> 00:16:46.720 That's the big one. Yeah, publicly available catalog. To get 334 00:16:46.720 --> 00:16:49.240 a CVE, the software usually needs to be something the 335 00:16:49.360 --> 00:16:52.519 end user manages where they could disable a flawed. 336 00:16:52.159 --> 00:16:55.360 Component, so not usually basic web services where the user 337 00:16:55.399 --> 00:16:56.320 controls nothing. 338 00:16:56.639 --> 00:17:01.120 Generally no basic SAWS often doesn't qualify. Cvees are assigned 339 00:17:01.159 --> 00:17:06.880 by CEDEM CVE numbering Authorities. These are orgs partnered with MITERI, 340 00:17:07.240 --> 00:17:08.759 who runs the CVE list. 341 00:17:08.960 --> 00:17:11.680 What if the software doesn't have a specific CNA. 342 00:17:11.400 --> 00:17:14.359 Then you go to a CNA LR last resort that's 343 00:17:14.440 --> 00:17:19.160 usually IMERI itself or CISA for industrial control systems. Some 344 00:17:19.279 --> 00:17:22.880 other platforms like Hunter dot dev for GitHub open source, 345 00:17:23.279 --> 00:17:26.240 or ZDIS Zero Day Initiative also assigned cvees. 346 00:17:26.440 --> 00:17:29.720 What about those ineligible apps like SAWS anyway to publish 347 00:17:29.880 --> 00:17:30.599 those findings? 348 00:17:30.759 --> 00:17:33.960 Options are limited for say a standard sauce platform, where 349 00:17:33.960 --> 00:17:37.039 you can't get a CVE, your main responsible path is 350 00:17:37.039 --> 00:17:39.480 still direct disclosure to the vendor. There aren't really public 351 00:17:39.599 --> 00:17:42.119 databases for those specific types of flaws. But for other 352 00:17:42.160 --> 00:17:44.960 software that might not fit CVE criteria perfectly, you could 353 00:17:44.960 --> 00:17:47.960 look at vulnerability aggregators like vuln dB. They all have 354 00:17:48.000 --> 00:17:48.599 their own roles. 355 00:17:48.640 --> 00:17:52.720 Though this whole process research disclosure, it sounds like you 356 00:17:52.759 --> 00:17:57.039 can get complicated, even contentious, between researchers and vendors. Is 357 00:17:57.079 --> 00:18:01.559 there anyone who can help if things go wrong? A mediator. 358 00:18:01.680 --> 00:18:06.400 Yes, absolutely, that's called vulnerability mediation. It's like coordinated disclosure, 359 00:18:06.440 --> 00:18:08.519 but with a neutral third party stepping. 360 00:18:08.279 --> 00:18:10.160 In like a referee kind of Yeah. 361 00:18:10.440 --> 00:18:14.960 Helps resolve disputes, smooth things over, facilitate communication. Remember that 362 00:18:15.039 --> 00:18:18.319 case in Germany Lilith Whitman. Responsible disclosure led to a 363 00:18:18.359 --> 00:18:22.279 criminal investigation. Initially, mediation can help avoid that, provide structure, 364 00:18:22.279 --> 00:18:23.759 maybe anonymity, legal help. 365 00:18:23.799 --> 00:18:24.880 Who does this mediation? 366 00:18:25.160 --> 00:18:28.039 Several organizations can play this role. First the form of 367 00:18:28.079 --> 00:18:31.839 incident response and security teams, the cert Coordination Center sert 368 00:18:31.920 --> 00:18:36.640 DC vince ussert I see CERT for Industrial Systems. Acting 369 00:18:36.720 --> 00:18:39.519 fast and choosing the right mediator is key if communication 370 00:18:39.599 --> 00:18:40.119 breaks down. 371 00:18:40.279 --> 00:18:43.480 Okay, what about the other extreme, when a researcher feels 372 00:18:43.519 --> 00:18:47.319 totally ignored and decides, I'm just publishing this myself, independent 373 00:18:47.400 --> 00:18:48.720 publishing that should. 374 00:18:48.480 --> 00:18:51.960 Really be the last resort, only after responsible disclosure attempts 375 00:18:52.000 --> 00:18:52.839 have truly failed. 376 00:18:52.920 --> 00:18:53.559 How does it work? 377 00:18:53.720 --> 00:18:57.759 The researcher basically posts a report online, personal blog, medium, 378 00:18:57.920 --> 00:19:01.839 GitHub pages, maybe a security mailing list, sometimes includes proof 379 00:19:01.880 --> 00:19:04.680 of concept code. The goal is usually to put pressure 380 00:19:04.720 --> 00:19:06.440 on the company to finally fix the issue. 381 00:19:06.920 --> 00:19:11.000 Sounds risky free speech arguments aside, What are the dangers? 382 00:19:11.319 --> 00:19:15.440 Significant legal risks? Potentially violating the Computer Fraud and Abuse 383 00:19:15.480 --> 00:19:19.039 aced CFAA. Did your testing cross the line into unauthorized 384 00:19:19.079 --> 00:19:23.920 access copyright issues DMCA? If you publish code improperly using 385 00:19:23.960 --> 00:19:28.400 the vulnerability yourself before disclosure is obviously criminal and defamation. 386 00:19:29.160 --> 00:19:31.880 If you make false claims or state opinions as facts 387 00:19:31.960 --> 00:19:35.079 and it harms the company's reputation, they could sue, and 388 00:19:35.240 --> 00:19:37.920 simply failing to give any notice before going public can 389 00:19:37.960 --> 00:19:41.039 look bad. Legally, stick to the facts, avoid assumptions. 390 00:19:41.200 --> 00:19:44.240 So, if despite the risks, a researcher go this route, 391 00:19:44.640 --> 00:19:45.319 how should they do it? 392 00:19:45.400 --> 00:19:49.759 Carefully write a clear, factual report, redact sensitive info from 393 00:19:49.799 --> 00:19:53.759 vendor communications, suggest fixes, Maybe publish on a personal blog, 394 00:19:53.839 --> 00:19:56.519 get up pages as free, or try security lists like 395 00:19:56.599 --> 00:19:58.880 sekhlists dot org. Maybe even tip off. 396 00:19:58.880 --> 00:20:01.039 Tech media in a checklist before hitting publish. 397 00:20:01.319 --> 00:20:05.799 Definitely review any contracts, double check nobody else published at first, 398 00:20:06.079 --> 00:20:08.039 Tell the vendor you intend to publish, give them a 399 00:20:08.079 --> 00:20:13.480 final deadline, fact check everything, rigorously remove private licensed stuff, 400 00:20:14.039 --> 00:20:19.000 credit collaborators, proofread, then publish. Optionally, let the vendor know 401 00:20:19.079 --> 00:20:19.440