WEBVTT 00:08.450 --> 00:09.830 Hi, everyone. 00:10.070 --> 00:12.670 Thank you very much for attending to our talk. 00:12.750 --> 00:22.090 We're going to present the new concept of shadow vulnerabilities and how we apply that in order to attack the most famous projects in the world. 00:22.090 --> 00:32.850 So, just before we begin, we're very happy to say that we are very proud to be part of this amazing community, the DEF CON community and the AppSec community for itself. 00:32.850 --> 00:36.470 And before we begin, just a really quick intro about ourselves. 00:36.470 --> 00:39.930 I'm the co-founder and CTO of Oligo Security. 00:39.930 --> 00:45.970 Like any other Israeli that you probably met, I'm ex-IDF technological unit. 00:45.970 --> 00:52.150 And in the last eight years, I've been hacking and breaking software at Checkpoint Research. 00:52.150 --> 00:56.910 And I'm super famous for being handsome, or at least I think. 00:57.650 --> 01:00.070 And along with me is an awesome guy. 01:00.070 --> 01:04.610 He's one of our most talented researchers at Oligo Research Team. 01:04.610 --> 01:09.210 He's, again, like any other Israeli, ex-IDF technological unit. 01:09.210 --> 01:12.370 And he's been breaking and building software for all of his life. 01:12.370 --> 01:15.650 And he's very famous for being the best scuba instructor. 01:15.650 --> 01:20.710 He likes to deep dive into coral reefs and into complex bugs and code. 01:21.170 --> 01:29.610 So, just as a really quick agenda, what we're going to talk about today is the new concept of shadow vulnerabilities, what actually it means. 01:29.610 --> 01:37.390 And then we're going to give an example of a shadow vulnerability that we discovered in the famous Snake.yml Java parser. 01:37.610 --> 01:49.410 Then we're going to explain the process that we did in order to scale it and find vulnerable projects that are vulnerable to this shadow vulnerability. 01:49.610 --> 01:57.990 And in the end, like any good DEF CON talk, we're going to exploit some stuff and talk about the impact and then sum it up with conclusion and key takeaways. 01:57.990 --> 02:13.370 So, just as you might be familiar from this concept from other industries, the shadow IT, that stands for the IT, the infrastructure that we don't monitor. 02:13.370 --> 02:16.050 And hence, we don't really know what's going on there. 02:16.050 --> 02:20.230 And hence, there's a bigger risk of the stuff that we aren't aware of them. 02:20.230 --> 02:28.150 And you can see that this analogy goes in different world, the API world, the API that we don't monitor. 02:28.150 --> 02:33.770 And hence, we don't know what's going on in there, the sensitive data, and of course, so on. 02:33.770 --> 02:42.830 And that's why we dubbed this concept of shadow vulnerability for exactly the same analogy, for risks that we aren't aware of them. 02:42.830 --> 02:46.470 And hence, they're even bigger to deal with and more riskier. 02:46.470 --> 02:55.530 And basically, shadow vulnerability stands for those type of vulnerabilities that actually doesn't get a CVE assigned to the issue. 02:55.530 --> 02:57.630 And why do these things happen? 02:57.630 --> 03:00.830 It can happen for several different reasons. 03:00.830 --> 03:11.720 Of course, the most obvious one is that it just takes a lot of time in order to classify or there's a dispute between the maintainer and the reporter. 03:11.720 --> 03:19.580 And it might take a lot of time or even result in a no-fix to get this issue a CVE. 03:19.860 --> 03:29.970 Again, there are a lot of examples in libraries and projects that just by not following the best security practices, you're actually opening a door for attacks. 03:30.240 --> 03:41.000 And of course, in the end, the maintainers that are responsible for the project are the ones that are deciding whether this issue is a real CVE or not. 03:41.000 --> 03:44.660 And they are the ones that will flag it as a fix or not. 03:44.660 --> 03:49.880 And of course, what we're going to show is that there are just libraries that are insecure by design. 03:49.880 --> 03:55.400 Meaning that just by misusing this library, you're prone to a vulnerability. 03:55.420 --> 04:13.480 And again, the fact that we don't have a CVE associated is what keeps us blind because all of the other tools or other approaches that we know, and how can we deal with it. 04:13.660 --> 04:26.520 So now, I'm going to pass it on to Awesome Guy, that will deep dive and explain about how we found this vulnerable code pattern inside Snake.yml and Guy can take it from here. 04:27.300 --> 04:28.760 Thank you, Guy. 04:31.420 --> 04:37.920 Okay, so as Guy said, we're here to show you the new concept of shadow vulnerabilities. 04:37.920 --> 04:45.060 And to do that, we will dive into a specific example of a shadow vulnerability that we have found in a library called Snake.yml. 04:45.340 --> 04:50.800 So Snake.yml is a famous open source library for parsing YAML files in Java. 04:50.960 --> 05:01.800 It is ranked the number one YAML parser in the Maven repository and it is itself a dependency for more than 4,000 other open source packages. 05:04.890 --> 05:07.450 And just to recap, this is a YAML file. 05:07.450 --> 05:12.310 It is pretty similar to a JSON file, but it is meant to be more readable to humans. 05:12.310 --> 05:15.750 So if you are a human and you find this readable, so good for you. 05:17.450 --> 05:22.410 So let's say you are a Java developer and you want to deserialize a YAML file. 05:22.530 --> 05:25.730 I am a Java developer myself sometimes. 05:26.350 --> 05:28.690 Not proud of it, but yes, I am. 05:29.690 --> 05:36.470 So what most developers will do, they will just try to find the first code snippet on the internet that works. 05:36.470 --> 05:41.190 So what they will do then, they will just find this snippet from the docs. 05:41.190 --> 05:43.570 They will copy and paste it to their code. 05:43.630 --> 05:47.190 They will try to run it and it works. 05:47.370 --> 05:53.350 At this point, what most developers will do is they will just close the docs and continue with their job. 05:53.570 --> 05:58.770 After all, there is no alert that you have done something bad. 06:00.310 --> 06:05.490 But if one digs a bit further into documentation, he will see this. 06:05.490 --> 06:10.870 Snake YAML allows you to construct a Java object of any type. 06:11.210 --> 06:13.310 So what is any type? 06:13.430 --> 06:25.610 Any type can be a string, an array, a hash map or a dictionary, and it can even be a custom Java object like this person class here. 06:25.610 --> 06:34.470 So trying to parse this payload will result in calling the constructor method for the person class. 06:35.270 --> 06:37.430 But wait, any type? 06:37.450 --> 06:41.450 Something like this should really make your hacker Spidey sense tingle. 06:42.110 --> 06:44.870 Can it even be a URL class loader? 06:45.050 --> 06:53.770 So just to recap, a URL class loader is a Java class that allows you to load the Java classes from remote servers. 06:53.770 --> 06:57.710 And basically it loads them into memory and it can also execute them. 06:58.590 --> 07:01.830 So apparently yes, this also works. 07:01.910 --> 07:05.430 I'm sorry for the lame emojis from Windows. 07:05.430 --> 07:06.910 They used to be better. 07:07.430 --> 07:09.950 But yes, this actually works. 07:09.950 --> 07:19.090 If you will try to parse this YAML using Snake YAML, it will result in code execution from a remote server. 07:19.090 --> 07:21.750 As you can see here, the attacker control server. 07:22.730 --> 07:34.530 And I guess you wouldn't expect that just by parsing a YAML file you will result in code execution which can lead to complete takeover of the running host. 07:35.530 --> 07:39.850 So we were not the only ones who thought this was unexpected. 07:39.950 --> 07:45.110 This issue was reported a long time ago to the Snake YAML maintainers. 07:45.930 --> 07:51.590 And as a reply, the maintainers said that, well, he doesn't see that as a problem. 07:51.590 --> 07:54.010 This is the intended behavior. 07:54.490 --> 07:58.770 Users who want to be safe can just use SafeConstructor. 07:59.990 --> 08:03.350 So let's pause for a second and explain what SafeConstructor is. 08:03.630 --> 08:14.010 So Snake YAML allows you to provide custom constructor types to configure the way that you control the YAML parsing. 08:14.010 --> 08:24.260 So for example, the SafeConstructor will only allow you to parse Java primitive types such as a bool, string, int, and so on. 08:24.550 --> 08:30.450 And if it sees an unfamiliar type, it will just throw an exception and crash. 08:32.070 --> 08:39.390 There is also the constructor type which will do exactly the same thing as the SafeConstructor. 08:39.390 --> 08:49.210 But instead of throwing an exception when it sees an unknown type, it will just try to parse it and to create any Java object that it can find in the class loader. 08:50.890 --> 09:03.570 And it's important to note that a part of the issue here is that the unsafe constructor, not the default constructor, is the default type for Snake YAML. 09:03.570 --> 09:11.350 So if you will just try to initialize a new YAML parser, you will automatically receive the constructor type. 09:11.430 --> 09:17.330 You need to opt-in if you want to use the SafeConstructor. 09:18.350 --> 09:29.710 And in order to make things even worse, constructor type inherits SafeConstructor, giving developers a false sense of safety when they're using the constructor type. 09:29.710 --> 09:43.830 I think this is the really root issue here, because developers who are using the unsafe constructor get a false sense of safety that they are using the SafeConstructor just because it inherits the SafeConstructor. 09:43.830 --> 09:48.430 But it actually overrides the safe behavior of the SafeConstructor. 09:50.470 --> 09:52.410 So is this a vulnerability? 09:52.690 --> 09:56.830 Well, you might as well say, yeah, this is not a vulnerability. 09:56.830 --> 10:00.570 It's up to the users to know how to use Snake YAML. 10:00.570 --> 10:07.890 The users need to read all the docs, and that's exactly the maintainer's point. 10:09.190 --> 10:18.890 But what we say is that this vulnerability is a source for so many other vulnerabilities that we have found that you might as well call this a vulnerability instead. 10:18.890 --> 10:30.910 It's important to note that the reason that we issue CVEs for open source libraries is to tell the users who are using these libraries that they have potential security issues. 10:30.910 --> 10:35.790 You need to notify the users that something that they are using can be dangerous. 10:36.650 --> 10:51.590 But because this did not get any CVE, we call this shadow vulnerability, since users who are using Snake YAML will not know that they are using a possible vulnerable function. 10:53.830 --> 11:05.290 But anyway, all of this doesn't matter, since, as the maintainer says, 100% of the applications who use Snake YAML don't use it to parse untrusted input. 11:06.310 --> 11:08.630 We decided to test this claim. 11:09.750 --> 11:14.410 To do that, we introduced a concept we call reverse fuzzing. 11:15.110 --> 11:23.090 Traditional fuzzing involves taking one target and shooting as many inputs at it, seeing when it breaks. 11:23.090 --> 11:35.210 Reverse fuzzing is the process when you take one vulnerable input and throw it at as many targets as you can, trying to find the one that breaks. 11:36.790 --> 11:45.030 The simplest way to start searching for targets in this process is to just search for the code pattern in GitHub. 11:46.110 --> 11:49.830 So we did do that, and we ended up with many results. 11:50.370 --> 11:55.030 And there were too many for us to just go through each and every one. 11:55.550 --> 11:59.070 So we had to lower the amount of false positives. 11:59.110 --> 12:04.710 We wanted to filter the targets by amount of stars to find only the prime targets. 12:04.710 --> 12:09.170 But sadly, the GitHub code search does not let you do that. 12:09.170 --> 12:18.070 So we had to write our own scripts to do this, and we had to run them for a couple of hours because of the rate limiting that the API has. 12:18.770 --> 12:24.250 But we did end up with a much lower number of results. 12:24.650 --> 12:34.470 But still, out of all these results, we still had a few false positives, because some of the projects that use Snake YAML only use it to create YAML files and not to parse them. 12:34.470 --> 12:38.070 And also some of them are using the safe constructor. 12:39.330 --> 12:43.050 To eliminate the noise here, we just used CodeQL. 12:43.050 --> 12:52.850 For those of you who are not familiar, CodeQL is a powerful code querying tool that can help you find patterns exactly such as this. 12:55.270 --> 13:00.030 We ended up filtering the results, and we found a few prime targets. 13:00.030 --> 13:02.670 I will focus on a few of them now. 13:02.670 --> 13:07.510 One project that we found vulnerable was Apache Cassandra. 13:09.750 --> 13:19.170 Apache Cassandra uses the Cassandra YAML file to configure the server. 13:19.730 --> 13:31.250 Using the vulnerability that we have found, we've discovered that if a malicious attacker can control the contents of this configuration file, he can actually execute code on the running machine. 13:34.290 --> 13:41.750 Since this is a configuration file, we wanted to test if we can find an interesting attack vector for this. 13:42.970 --> 13:49.030 Usually attackers don't get the access to just edit configuration files on the servers. 13:49.230 --> 14:06.470 But during our research, we did find that on the default container image for Cassandra and the default installation, the Cassandra YAML file will usually have write permissions from any user on the running host. 14:06.470 --> 14:15.310 So this can be leveraged to gain local privilege escalation on the machine running Apache Cassandra. 14:15.310 --> 14:26.510 In addition to this, during our research, we have found another vulnerability in Apache Cassandra that did allow us to modify files on the Cassandra server. 14:26.510 --> 14:36.350 And then we just chained these two vulnerabilities together to obtain persistent RCE capabilities on Apache Cassandra. 14:37.210 --> 14:50.230 Another research that we started doing was also to search for more targets that are using Cassandra as a service, such as Amazon that is providing Cassandra as a service. 14:50.550 --> 14:57.590 Most of them really did sanitize the inputs, but the attack vector can still be valid for more services. 14:59.390 --> 15:08.010 So we did try to report this vulnerability to the Apache team that maintained Cassandra. 15:08.010 --> 15:15.510 And they were super responsive and they immediately said that they do see the issue and they will issue a fix. 15:16.450 --> 15:33.930 But they did say that they don't consider this a vulnerability because of the attack vector, which actually created another set of vulnerability because there is an issue, but it is not being notified to the users that it exists. 15:35.130 --> 15:45.370 And sadly, after deploying the fix, we see that they fell into the same pitfall that we mentioned earlier. 15:45.370 --> 15:58.510 They thought because the constructor inherits a safe constructor, they thought that just by using the constructor they are safe because it inherits a safe constructor. 15:58.610 --> 16:03.270 But as we mentioned earlier, it overrides the safe behavior of the safe constructor. 16:04.430 --> 16:10.550 This is still left unfixed since it broke some tests and stuff. 16:11.550 --> 16:12.750 Yeah. 16:15.090 --> 16:26.890 So while we did found a local privilege escalation, and local privilege escalation is really cool, what we really wanted to find is remote code execution, which is way cooler. 16:27.530 --> 16:33.530 And to do that, we had to expand our research to find even more targets. 16:35.230 --> 16:48.610 We did had some issues with the old method since not all the targets are open source, so searching GitHub limited the amount of results that we can get. 16:48.950 --> 16:58.410 And in addition to that, running CodeQL is pretty difficult in scale because you need to have the CodeQL database for each and every project. 16:59.710 --> 17:06.570 And as the maintainer already said, most of the projects do use Snake.YAML only for configurations. 17:06.910 --> 17:20.410 And we wanted to find a method how we can filter out those projects who use Snake.YAML only for configuration and find the ones who are using Snake.YAML to parse YAML files during their actual runtime. 17:22.690 --> 17:28.790 To do that, we decided to move from searching GitHub to searching for images in Docker Hub. 17:28.970 --> 17:45.570 We wanted to trace them in a runtime, and we wanted to plot the amount of calls that they do to parsing YAML files in order to find the ones who are not only using it in the beginning. 17:45.570 --> 17:58.730 Because what we understand is that when you use it for configuration, you usually only use it once when you start a container, and then you don't have to parse any YAML file. 18:00.570 --> 18:03.370 So there are a couple of ways of doing that. 18:03.370 --> 18:05.150 We wanted to do that in scale. 18:05.150 --> 18:08.410 And luckily, this is exactly what we at Oligo do. 18:08.410 --> 18:17.190 We use eBPF technology to observe the runtime behaviors of open source libraries down to the function level, and we do do that at scale. 18:17.190 --> 18:26.250 So using the data that we had, we were able to plot these graphs on many popular projects. 18:26.810 --> 18:33.630 So this is an example for a project that was using Snake.YAML actually for configuration only. 18:33.630 --> 18:41.850 So you can see that over time, you only see one peak at the beginning, and then there are no more usages. 18:43.550 --> 18:50.690 And contrary to this, this is a project that actually used it to parse YAML files on the fly. 18:51.150 --> 18:54.970 So these were actually interesting targets. 18:55.830 --> 18:59.710 So using this method, we were able to find more targets. 18:59.710 --> 19:04.630 Some of them are still under responsible disclosure, so we can't explain the bugs we found there. 19:04.890 --> 19:11.570 But one of the targets that we did find, and we can show you here since it already got fixed, is Confluence. 19:11.570 --> 19:30.670 So just in short, Confluence is using another open source library which is called Liquibase that had this HTTP client code, which was communicating with an API that was able to communicate and get YAML back from the API. 19:31.850 --> 19:38.050 So you can see here that it is not using the safe constructor, it is using the default and unsafe constructor. 19:39.430 --> 19:53.150 So you can see here that once you issue a GET request, the output from the connection is being moved straight into the loaded function. 19:54.510 --> 20:05.670 So this issue was fixed in Confluence server on the latest version, but it was not fixed as a security update, it was just pushed as a regular update. 20:08.050 --> 20:12.010 And there were many more projects that we found vulnerable to this. 20:12.150 --> 20:16.550 This vulnerability was kind of like a goldmine for us. 20:16.550 --> 20:20.930 Everywhere we looked, we found flawed usages of this library. 20:22.930 --> 20:30.370 And to continue and sum up and give the conclusions, I will give the talk back to Gal. 20:30.750 --> 20:34.050 Thank you, Guy, for being that awesome. 20:34.050 --> 20:35.410 Okay, cool. 20:35.410 --> 20:36.830 So let's sum it up. 20:36.830 --> 20:44.810 We actually were able to prove that vulnerability is not a vulnerability, but we were able to hack one of the most famous projects in the world. 20:44.810 --> 21:01.690 We started with an LPE, then we did a post-auth RCE, and actually we did find a no-auth RCE, meaning that we have a huge list of IPs that are using this vulnerable code pattern that we can now take down. 21:01.690 --> 21:07.790 This is still under responsible disclosure, but please stay tuned as we're going to publish it as soon as we can. 21:08.530 --> 21:11.030 But now, let's see what happened. 21:11.070 --> 21:29.690 While we did our research, actually Google stepped in, and in one of the most famous tools, OSS Fuzz, which continuously fuzzes the most famous open source projects in the world for security vulnerabilities, and Snake YAML is one of them, they did see that this issue occurs. 21:29.690 --> 21:31.910 So they opened an issue. 21:32.150 --> 21:38.730 And of course, we already know our maintainer that just changed the status to won't fix. 21:39.250 --> 21:43.710 But then Google said, look, this is an RCE. 21:43.710 --> 21:45.370 We can actually run code. 21:45.370 --> 21:46.930 This is very severe. 21:46.930 --> 21:48.750 We don't agree with you. 21:48.750 --> 21:51.750 There was a dispute, and Google said, look, we are Google. 21:51.750 --> 21:53.090 We are a CNA. 21:53.410 --> 21:54.610 We're not going to ask you. 21:54.610 --> 21:56.090 We're going to issue a CVE. 21:56.630 --> 22:04.090 So in a return to that, the maintainer said, good, if you're Google and you can issue a CVE, you can come up with a fix to this problem. 22:04.090 --> 22:05.410 I'm not going to do it. 22:05.410 --> 22:12.330 And this is how we ended up getting Snake YAML 2.0, which actually introduced breaking changes. 22:12.330 --> 22:21.070 It actually breaks the concept of deserializing structs and only lets you deserialize the primitive types. 22:21.070 --> 22:38.890 And by that, we still think that the world will remain vulnerable because all of the other applications that are leveraging Snake YAML for much more complex and extended usages besides the default types will have to use the vulnerable part. 22:39.790 --> 22:50.630 And now when you actually get to the official documentation of Snake YAML, you can see right away the maintainer added, if you are here because of a CVE, it's probably a false positive. 22:50.630 --> 22:59.650 And again, as Guy mentioned, we usually trust the documentation that we read, and this is exactly the root cause of those shared vulnerabilities. 22:59.850 --> 23:08.870 Because without knowing all of that, I would just get into the documentation and see that there's a false positive or say, okay, there isn't a risk. 23:09.150 --> 23:13.890 And of course, other projects saw this and followed. 23:13.890 --> 23:19.270 And for example, Apache Cassandra, we did see they tried to fix it but couldn't fix it. 23:19.270 --> 23:23.430 After the CVE applied, they just suppressed it and ignored it. 23:23.430 --> 23:23.730 Why? 23:23.730 --> 23:27.510 Because it would break in the builds of people and people ignored it. 23:27.510 --> 23:32.590 And again, they followed the maintainer's suggestion and just suppressed the vulnerability. 23:32.650 --> 23:34.210 So it's still out there. 23:34.750 --> 23:39.030 So this actually raises an interesting ethical question. 23:39.030 --> 23:41.670 Who owns the responsibility? 23:41.670 --> 23:55.090 Is it the library maintainer that has been thankfully giving the world an amazing open source that let us build amazing tools, but now he needs to change the way that his code works just for others to use it safely? 23:55.150 --> 23:57.470 Or is it the project maintainer? 23:57.470 --> 23:59.630 They have thousands of open sources. 23:59.630 --> 24:03.330 They have to be responsible for each and every one's security? 24:03.330 --> 24:18.810 Or is it just the innocent users that just want to code and use a DB or use an open source and don't know or think about the consequences or the problems they inherit when they use it? 24:18.810 --> 24:26.710 Or just the fact that they now have to be a Java security expert in order to just use a YAML parser? 24:28.410 --> 24:32.370 And as you can see, this is just the tip of the iceberg. 24:32.370 --> 24:36.510 This example of Snake YAML is just one example of a shadow vulnerability. 24:36.550 --> 24:39.090 But there are many more out there. 24:39.090 --> 24:46.950 You can see the same documentation that are repeating itself from each and every example, whether it's like Lodash or Jackson. 24:46.950 --> 24:51.330 And you can see how the maintainers on one hand say, OK, this is not a problem. 24:51.330 --> 24:58.210 But on the other hand, you should be aware and be following the guidelines in order to use it safely. 24:58.210 --> 25:07.430 And we do see those stuff coming over and over in different use cases and different libraries that everyone is using. 25:07.770 --> 25:09.970 And there are many more out there. 25:09.970 --> 25:12.050 And that's why we urge you guys. 25:12.050 --> 25:27.270 We're going to publish a list of all of the shadow vulnerabilities, but we urge you to also participate and add more and more examples because we think that it should be a security effort of all of the community in order to fix it. 25:27.270 --> 25:31.610 And again, like any good DEF CON talk, we have to exploit something. 25:31.610 --> 25:42.110 So I'm going to pass it on to Awesome Guy, that will show you an exploitation on Apache Cassandra with this shadow vulnerability. 25:44.830 --> 25:50.830 So we don't trust the demo gods, so we had a video. 25:51.510 --> 25:56.570 So you can see on the lower terminal, this is the Apache Cassandra server. 25:56.570 --> 25:59.250 On the top one, it's the attacker. 26:01.370 --> 26:06.170 We have used two vulnerabilities that were chained together. 26:06.430 --> 26:10.470 And once we reset the server, we can see that the malicious payload is being loaded. 26:11.070 --> 26:12.790 And we will get a connection. 26:13.410 --> 26:16.250 And we're now running as the Cassandra user. 26:20.550 --> 26:22.270 Great, so... 26:22.270 --> 26:24.330 You can applaud now. 26:32.800 --> 26:34.000 Great. 26:34.160 --> 26:37.000 Thank you, Guy, again, for being so awesome. 26:38.040 --> 26:42.980 So now, let's conclude what we have been seeing up until now. 26:43.120 --> 26:46.740 Open source, just like Guy, is awesome. 26:47.040 --> 26:52.800 And this is what enables us to build amazing applications and do it. 26:52.800 --> 27:00.300 And on the contrary, because it's everywhere, that's why it's very important to secure those open source packages. 27:00.300 --> 27:09.380 And I think people even talk about Lock4Shell, or Spring4Shell, or everything with Shell, just keep recurring and showing us how important it is. 27:09.380 --> 27:21.460 And that's why we think, by showing here the concept of shadow vulnerabilities, that the industry has to realize that fixing by a CVE cannot be the only focus. 27:21.460 --> 27:32.440 There are other problems out there, and that's why shadow vulnerabilities and these libraries that have this type of being insecure by design, it's just, again, the tip of the iceberg. 27:32.440 --> 27:36.520 And that's why this shadow concept should be called out. 27:36.520 --> 27:44.060 Because you saw that even if we have a fix, or even if we have a CVE, a lot of the time it doesn't really solve the real issue. 27:44.060 --> 27:48.260 And that's why we don't think it's someone's responsibility. 27:48.260 --> 28:02.940 We think it's everyone's responsibility, because we are all using, knowingly or unknowingly, in these applications that are built upon this amazing open source project, and that's why we think it should be a community effort. 28:02.940 --> 28:06.340 And that's why we need your help in order to do it. 28:06.420 --> 28:10.300 So, again, thank you very much for attending this talk. 28:10.300 --> 28:19.780 Please stay tuned as we're going to publish more and more examples of shadow vulnerabilities, and we're going to publish the new project that we hacked. 28:19.780 --> 28:27.320 And, of course, if you have any questions, you can reach out via LinkedIn, or Twitter, or X, or whatever. 28:27.320 --> 28:29.880 Elon will decide to call it tomorrow morning. 28:29.960 --> 28:33.480 We will be there and be happy to answer any questions that you guys have. 28:33.480 --> 28:34.480 Thank you. 28:40.860 --> 28:42.280 Any questions? 28:45.080 --> 28:47.020 Where do I like to dive? 28:47.560 --> 28:50.420 I'm from Israel, so I mainly dive in Eilat. 28:50.480 --> 28:57.160 But I've been all over the world, like wherever I get to and there's water, so I try to dive there. 28:57.660 --> 28:59.600 And to memory corruptions. 29:02.100 --> 29:05.020 Did Cassandra fix the other bug that you found? 29:05.360 --> 29:08.100 Yeah, we found several bugs in Cassandra. 29:08.100 --> 29:12.420 One of them was fixed and issued a CVE by itself, you can see. 29:12.420 --> 29:26.220 It was a command injection, so it actually lets you run code, but we used it in this research in order to create an arbitrary file primitive in order to actually exploit the shadow vulnerability of Snake.YAML. 29:26.220 --> 29:29.380 But the shadow vulnerability of Snake.YAML is still unfixed. 29:30.900 --> 29:31.660 Yes. 29:35.300 --> 29:36.260 It's a good question. 29:36.260 --> 29:39.040 You can find our blog in the Oligo official website. 29:39.040 --> 29:42.020 We're going to publish everything, like the research and how we did it. 29:42.020 --> 29:46.480 We're going to publish some tools and the way we did and scaled the research. 29:46.480 --> 29:51.540 And of course, we're going to publish more and more examples of shadow vulnerabilities, so you can see it over there. 29:52.380 --> 29:53.160 Yes. 30:03.300 --> 30:06.380 Yeah, so that is a good question. 30:06.380 --> 30:09.600 How do you find more shadow vulnerabilities in more libraries? 30:09.860 --> 30:17.080 So what we wanted to do to do that is just focus on libraries that are actually doing dangerous stuff. 30:17.080 --> 30:21.180 This serialization is something that is known to be really dangerous. 30:22.360 --> 30:41.840 We didn't come up with a smart way to do this at scale, but it's basically focusing on the libraries that you know that can be dangerous and trying to find these patterns of documentation that says, it's your responsibility to do that and that in order to be secure. 30:43.120 --> 30:44.760 Here comes the payload. 30:46.200 --> 30:47.140 What, what? 30:47.580 --> 30:50.260 The payload? 30:50.260 --> 30:52.140 What payload we used? 30:52.240 --> 30:54.940 It was on the previous slide. 30:55.240 --> 31:05.060 It's basically the URL class loader that will initiate a connection to our controlled server that will serve the malicious jar that will be executed. 31:06.000 --> 31:07.800 This one, yeah. 31:10.640 --> 31:12.120 More questions? 31:12.900 --> 31:13.700 Yeah. 31:21.500 --> 31:26.920 So yes, if we are planning to release an open source tool to find this. 31:26.980 --> 31:28.280 So currently not. 31:28.280 --> 31:31.240 It is based on the data that we have collected. 31:31.600 --> 31:40.520 But we can suggest that there is another way to search for this kind of issues using a dynamic instrumentation. 31:40.620 --> 31:45.060 Like you can do the same thing with Frida, just in a lesser scale. 31:46.480 --> 31:47.140 Yeah. 31:49.060 --> 31:50.240 You only have what? 31:53.700 --> 31:55.480 Yeah, yeah. 31:58.510 --> 31:59.250 Cool. 31:59.250 --> 32:00.450 Thank you very much guys. 32:00.450 --> 32:01.590 Thank you for attending. 32:01.590 --> 32:07.110 It was a pleasure to be here and again, hit us up and we'd love to answer anything. 32:07.110 --> 32:07.950 Thank you very much.