WEBVTT 00:13.280 --> 00:15.760 All right, everyone, welcome back. 00:16.080 --> 00:22.100 If you're just joining us here in the AppSec Village, I hope you are ready for a fantastic talk. 00:22.100 --> 00:25.740 If you're still hanging around from the last talk, glad to have you back. 00:25.740 --> 00:27.100 This is going to be awesome. 00:27.180 --> 00:35.380 I wanted to take a few minutes to thank everybody who helped to put on DEF CON this year. 00:35.440 --> 00:38.540 I know this has been very challenging for people. 00:38.540 --> 00:41.060 It's challenging for us at home. 00:41.060 --> 00:48.240 It's doubly challenging to bring a great conference experience to DEF CON. 00:48.240 --> 00:50.260 And we really hope that comes through. 00:50.260 --> 00:53.300 Also take a minute to thank the AppSec Village. 00:53.320 --> 00:58.860 Some people have put in amazingly long hours to make this stuff happen. 00:58.940 --> 01:02.020 And we want to thank them as part of that. 01:02.540 --> 01:07.440 Additionally, if you want to get a shirt, head over to the AppSec Village website. 01:07.440 --> 01:15.060 You can purchase your shirt there for the second incarnation of the AppSec Village. 01:16.280 --> 01:28.820 So for our next talk, we've got Paul Abar and Stanislas Malveaux talking to us about turning the offensive security mindset into a developer's toolbox. 01:29.960 --> 01:31.040 Hi. 01:31.040 --> 01:32.440 Hello, everyone. 01:32.440 --> 01:42.940 Thanks for joining our presentation, which is going to be today about our journey into turning offsec mindset to developer's toolset. 01:43.560 --> 01:47.360 This presentation, we're going to be two of them doing it. 01:47.680 --> 01:51.300 And it's going to be in what we can say three parts. 01:51.420 --> 01:58.580 First one is going to be about a tool that we created inside our company, which is called ChopChop. 01:58.580 --> 02:05.620 And we will come to what happened, what was the context, what was the need for it, and that we're going to explain what happened. 02:06.100 --> 02:15.920 The second one is how did we want to broaden our audience into having more and more and more people using it, and especially developers. 02:16.160 --> 02:23.200 And the last part is going to be the demo that we're going to do with Stanislas, who is here just next to me, and who's going to do it. 02:23.220 --> 02:33.000 So three parts in trying to explain our journey into how we tried at least to achieve it and some of the mistakes, drawbacks, and things that we learned on the way. 02:33.000 --> 02:37.560 So hopefully, we hope that you're going to learn something about it. 02:38.160 --> 02:40.020 All right, let's start. 02:40.520 --> 02:44.760 This graph, we actually took it from CVE details. 02:44.760 --> 02:54.840 And it just shows the number of vulnerabilities and numbers of CVEs that we got starting from a couple of years back to basically now. 02:54.840 --> 03:04.300 So we took this graph last year, and we can realize that between 2016 to 2017, the number of CVEs just doubled. 03:05.060 --> 03:07.220 And this is something that we can see. 03:07.220 --> 03:10.560 Every day and every week, we get new vulnerabilities coming in. 03:10.560 --> 03:16.140 We get Oracle built-in, which is just full, and hundreds of vulnerabilities are inside. 03:16.140 --> 03:24.440 We also get built-in of Microsoft, which are just showing up hundreds of vulnerabilities, or let's say dozens of vulnerabilities each month. 03:24.440 --> 03:29.020 And this is something that's growing, obviously, and we're hearing a lot about this. 03:29.060 --> 03:38.500 And in the last couple of days, last couple of weeks, we got a number of vulnerabilities during the lockdown, which was just massive, and especially critical vulnerabilities. 03:38.500 --> 03:44.020 So this is something that we can feel, and this is getting really, really big. 03:44.380 --> 03:58.480 And when we're taking those numbers, we realize that just by dividing it by 52, the number of weeks that we have per year, we realize we get something like 319 new vulnerabilities. 03:58.480 --> 04:02.660 And this is the number of new vulnerabilities that we get per week. 04:02.660 --> 04:09.560 And this is huge, huge for a team to just realize that we do have to process all this information. 04:09.560 --> 04:22.420 So bear in mind that we are not affected by all those vulnerabilities at the time, but it really depends on your context, on our context, on your customer's context, and so on. 04:22.420 --> 04:32.680 But this is something, some information that needs to be digested by your teams to just realize if you're affected or not, and if you're vulnerable to it or not. 04:32.680 --> 04:41.380 And this is a huge thing to actually realize and to process, especially depending on the size of your team. 04:42.000 --> 04:58.980 And usually when we get a new vulnerability, like the MS17010, or let's say the new vulnerability for the DNS remote card execution on Microsoft, which happened a couple of weeks ago, we usually get the management, because they hear a lot about this on Twitter, 04:58.980 --> 05:07.100 on specific magazines, on specific websites, and they actually hear about like this, and there's like a really big buzz around those vulnerabilities. 05:07.100 --> 05:15.620 And usually they're coming to the security team and just asking, all right, are we affected by this vulnerability or this other one that we heard about? 05:16.280 --> 05:20.160 And this is something that, well, we can understand it, obviously. 05:20.160 --> 05:29.740 And the problem with this is we get to the point where the security team is overwhelmed by the number of new findings that happen each day. 05:29.740 --> 05:42.660 And you get like a backlog, which is full of things that you need to process, and it turns out that the management is coming and coming and coming again to just like ask if we are vulnerable to this, to just answer to the management, to the executive, 05:42.660 --> 05:43.680 and so on. 05:43.680 --> 05:53.160 So something to bear in mind, and this is part of the context that we are in and why we actually had like this old tool ID, and we started like getting this. 05:53.160 --> 05:56.200 So the context was based on this. 05:56.820 --> 06:04.240 So the problematics we had was something circa 2016, when we started having like this kind of philosophy and mindset. 06:04.240 --> 06:10.560 And the idea was we had thousands of servers and domains that had to be scanned daily. 06:10.620 --> 06:28.620 We wanted to scan them to basically for statistics reason, KPI, and having some like fresh data, because obviously as soon as you do a penetration test or any kind of testing, we can consider the test outdated a couple of hours or let's say a couple of days afterwards. 06:28.620 --> 06:34.220 So we wanted to have like fresh data all the time, and daily fresh data. 06:34.440 --> 06:41.460 Second of all is we did not have direct access to the servers in some specific situations. 06:41.460 --> 06:50.120 And this was based because the servers were materialized, because it was managed by other entities, and a couple of other reasons that we had. 06:50.120 --> 06:54.480 So we didn't have like SSH access on all the machines all the time. 06:54.480 --> 07:08.420 So this is why we needed to have like another way into assessing the security of the applications that were exposed on the internet, inside as well in the network, and really we had like a really big context with this. 07:08.420 --> 07:26.900 And we can see that the situation is quite pretty similar to what we can call black box penetration testing, which means that we don't have like administration access to the server, and that we need to like find other ways to qualify and to have an ID if we are vulnerable to this specific value. 07:27.200 --> 07:30.500 The tech landscape that we had was also unclear. 07:30.720 --> 07:37.740 In 2016, 2017, there were a lot of vulnerabilities, especially with WebDAV, if you can remember. 07:37.740 --> 07:46.540 It was like quite a hot topic at the time, but also with struts, because there were a couple of critical vulnerabilities which happened in a couple of days. 07:47.220 --> 07:52.420 So these were the things where, okay, there's a huge vulnerability with struts. 07:52.440 --> 07:54.200 Are we vulnerable to it? 07:54.200 --> 07:55.100 Yes, no. 07:55.100 --> 08:01.200 And can we quantify the number of servers which might be potentially vulnerable to this? 08:01.200 --> 08:04.600 And the last point, but not least, is interesting. 08:04.600 --> 08:08.440 And speaking of which, it's like this lean security, all right? 08:08.440 --> 08:15.340 And it's the idea of ability to perform checks every time, so again and again. 08:15.340 --> 08:23.020 So basically, this kind of like loop, this lean loop that we can have, where we would be able to like spot security regression. 08:23.680 --> 08:28.620 And this remembers like a cool anecdote, if we can say it this way. 08:28.620 --> 08:34.520 There's one company, quite big company, having a bug bounty program. 08:34.940 --> 08:48.280 And after speaking with them, they actually told us that they paid some really good bounty for a specific researcher who found remote code execution on some of the production servers. 08:48.280 --> 08:49.620 They fixed it. 08:49.780 --> 08:55.980 But unfortunately, a couple of weeks later, they redeployed the same vulnerable component. 08:55.980 --> 08:58.920 And another bounty researcher found it. 08:58.940 --> 09:07.180 And they had to pay twice for the same vulnerability that they had, that they had already patched, and that they already paid one researcher for it. 09:07.180 --> 09:10.360 And this is what I'm going to call security regression. 09:11.340 --> 09:21.520 When we're taking the tech and like the developer landscape, unit testing is actually one of the foundations of any kind of like new development. 09:21.520 --> 09:37.620 And I think that like this specific mindset and security regression should definitely be something that we could put on our top priority, just to make sure that we get all those regressions as soon as possible. 09:37.920 --> 09:40.240 We have everything automated right now. 09:40.240 --> 09:43.020 We do have like a lot of pipelines for our developers. 09:43.020 --> 09:45.880 Everything is going faster and faster and faster. 09:45.880 --> 09:49.780 And I think that we can improve our way into this. 09:49.780 --> 09:55.060 And this is some of the reasons why we created our tools, and we wanted to tackle this issue. 09:55.060 --> 09:58.640 Security regression was one of the big parts. 09:59.000 --> 10:00.780 So this was our context. 10:01.560 --> 10:14.140 The needs that we have, so needs from the field, and this was again from like 2016, we had to assess new vulnerabilities, new risks coming in, and we had to do this quickly. 10:14.140 --> 10:21.180 So yeah, 2017, we had Struts, we had RCE, so Remote Code Execution on Drupal. 10:21.260 --> 10:25.960 We had WebDAV, we had like lots, a lot of things happening, obviously. 10:25.960 --> 10:30.200 And we had to process this as fast as we could. 10:30.360 --> 10:31.580 So this was one thing. 10:31.580 --> 10:36.280 The other one was, we had like a small team working on this. 10:36.400 --> 10:40.100 When I'm speaking of small teams, it was three to four people. 10:40.100 --> 11:00.980 All of them were all security-oriented, which is really important for the rest of the journey, because this started introducing some bias, which means that we were security people working with security tools that we wrote, and we were more or less like in our circle and in our comfort zone, 11:00.980 --> 11:19.200 which means that when we started and wanted to deploy to other population and other kind of people, developers, devops, it turns out that we had some interesting gap, I would say, and those bias that we introduced, we're going to try to give you the mistakes and how we tackle these issues. 11:19.200 --> 11:21.860 But never mind, we will come back to this later on. 11:22.420 --> 11:33.520 So we needed a tool which would be fast, so something where we could just say, okay, here is the new vulnerability, run it across all our parameters and see if we get a hit. 11:33.520 --> 11:36.840 The second one was having something reliable. 11:36.840 --> 11:49.800 And when we say reliable, it's mostly interesting for the deterministic return, which means that if we would run the tool twice, we would make sure that if it hits, it would hit again. 11:50.080 --> 11:55.600 So there would be nothing random in the processing. 11:55.600 --> 11:59.440 So we would know exactly how the rules would be triggered. 11:59.520 --> 12:04.000 And if we would run it twice, we should have the same output, obviously. 12:04.260 --> 12:08.280 And the last point, but not least, would be no false positives. 12:08.480 --> 12:12.600 So it's interesting because we need to find like a threshold, right? 12:12.600 --> 12:15.040 We need to have like a tool super fast. 12:15.040 --> 12:20.560 But on the other hand, we don't want any false positives, which is really hard to combine all together. 12:21.580 --> 12:27.540 So it's two criteria, which unfortunately don't really work together. 12:27.740 --> 12:32.520 But we think that we did quite a great job, and this is something that we managed to do. 12:32.620 --> 12:48.640 And considering that a hit, chop chop hit, would be a real hit, which means that if we get something in the output, in the console output, we would have to open an incident, call someone, or start doing like an immediate action, right? 12:48.640 --> 12:52.280 And not having like a lot and lot and lot information to process. 12:52.360 --> 13:00.120 So really trying to like do some kind of like sniper thing, and just making sure that we get to what's really valuable. 13:00.260 --> 13:04.640 So those were our needs, and yeah, trust me, we had a lot of them. 13:05.660 --> 13:12.760 So if we can take an image, an analogy, it would be like more or less like going to the jungle, right? 13:12.760 --> 13:25.000 And it would be like something where we would just have like a machete, and like start just like chopping trees to try to like create a path in like the jungle, so that we could reach our destination point. 13:25.020 --> 13:27.340 But this was like more or less the case. 13:27.360 --> 13:36.040 As you saw beforehand, it was more or less like an approach of like black box testing, where the tech landscape was a bit unclear. 13:36.140 --> 13:47.220 We didn't exactly know what we were doing, and what we wanted to do is like creating hypotheses, and trying to see if it would be valuable for our context. 13:47.220 --> 13:57.300 And making sure that the tool that we released, and that we get, would be something also valuable for other organizations, so that they could customize it for their own environments. 13:57.300 --> 14:02.140 This was like mostly like the whole soul of the application. 14:02.140 --> 14:13.380 So yeah, this analogy, really the analogy of jungle, and having something where we would have to like start chopping trees, and making sure that we're not in danger. 14:14.760 --> 14:17.860 So we were saying chop-chop, chop-chop, and what does it mean? 14:18.460 --> 14:26.920 It's actually a funny name, and it's something coming from Cantonese, which means hurry, and suggest to do something like without delay and right now. 14:26.920 --> 14:32.940 So we thought the name was interesting, and exactly what was like the spirit of the tool. 14:32.940 --> 14:34.840 So this is why we called it chop-chop. 14:34.840 --> 14:44.870 We wanted to have like a tool where if an emergency alert was coming in, we would be able to like respond right now, and having results in no time. 14:45.160 --> 14:51.420 So it was the whole soul, and this is why we kept the name chop-chop, and released the tool with this name. 14:51.960 --> 14:56.820 The tool initially back in 2017 was written with Python. 14:56.820 --> 15:00.720 We started with Python 2.7, then migrated to Python 3. 15:00.720 --> 15:08.720 We got everything working, and following the upcoming month, we started getting plugins that the security team mostly wrote. 15:08.720 --> 15:12.060 And in the end, we came up with 80 plugins. 15:12.060 --> 15:15.220 So 80 things processing, which were done. 15:15.440 --> 15:30.660 Going from trying to find if there was like a .git folder exposed on the internet, or let's say in the web root, accessible in the web root, to also like checking if the RDP port was also open, checking if the port was here, and was just responding. 15:30.720 --> 15:36.580 A couple of things like this, and we started like creating plugins, which were specific to our environment. 15:36.580 --> 15:41.420 Those ones were not released, but this gives you the idea of the flexibility of the tool. 15:41.420 --> 15:45.580 So taking a domain name or an IP, and afterwards doing some processing. 15:45.580 --> 15:48.020 And any kind of processing, basically. 15:48.440 --> 16:04.200 As I said, it was mostly doing things with HTTP, and this was like the whole soul of the application at first, but then afterwards, people started integrating new protocols and new modules to start interacting with other services. 16:05.500 --> 16:16.380 So we had everything running, the ability to run scans daily, with what we called deterministic wizards, which was one of the things we were really eager to have. 16:16.380 --> 16:21.940 So daily scans, basically every day, and allowed us to answer two questions. 16:21.940 --> 16:25.640 The first one would be to answer to the management, are we affected? 16:25.640 --> 16:26.700 Yes, no. 16:26.700 --> 16:35.820 And then afterwards, being able to quantify the number of servers, or number of IPs, which were actually affected with this specific vulnerability. 16:36.260 --> 16:37.540 Is it going to be one? 16:37.540 --> 16:38.880 Is it going to be 100? 16:38.880 --> 16:42.540 Is it going to be dozens, hundreds, thousands? 16:42.540 --> 16:45.480 Is it going to be all the servers at once? 16:45.500 --> 16:49.600 So it's actually quantifying the results, and we were able to do this. 16:49.600 --> 16:58.160 So we would count every console output, every line we would get, and we would have an idea of how many servers would be affected. 16:58.160 --> 17:03.480 And this allowed us, and this saved us a lot of time. 17:05.040 --> 17:21.320 As I said, ChopChop initially was written in Python, and this is an example of a plugin that we wrote, and this one is to try and check, ensure that the git.git repository, .git folder, is not exposed in the web route. 17:21.340 --> 17:38.580 So what it's going to do, it's quite simple, it's going to test on port 80 and on port 443, in HTTP and HTTPS, and it's going to check one specific path, which is going to be .git slash config, and it's going to check for one specific word to appear in the HTTP response. 17:38.720 --> 17:43.620 Based on this, we're going to have a severity, which ranks from 0 to 10. 17:43.620 --> 17:51.320 10 is going to be critical, 0 is going to be informational, quite similar to what we can find with the CVSS code, something similar. 17:51.320 --> 18:12.240 Again, this thing, we will talk about this later on, but we changed it in the new version of ChopChop for particular reasons, and because we thought that having this specific range would be way too far and way too lot of information to process, and based on the audience we wanted to reach, 18:12.240 --> 18:14.700 this is something that was a bit useless. 18:14.740 --> 18:16.600 But we will come back to this. 18:16.600 --> 18:28.020 We had a description, ensuring that the git repository is not accessible from the web root, and one fix, what we can call remediation. 18:28.400 --> 18:38.100 And it was really important for us because afterwards, after using it and using it, we started getting people and non-security people using the results of ChopChop. 18:38.100 --> 18:47.880 And it turns out that some of them were lost by just having an Excel file or anything like this, just an output, ChopChop output, just didn't know exactly what to do with this. 18:47.880 --> 19:01.220 So we started implementing remediations to give some insights and some inputs, so that people could work on their own by just giving them a bunch of pieces so that they could start working on the remediation and mitigation. 19:01.640 --> 19:12.480 So this is the kind of plugins that we had, written in Python, giving you some information, so you just had to inherit from the plugin class that we had. 19:12.480 --> 19:19.400 And afterwards, you would just have to override a couple of things and you would be start to go. 19:20.740 --> 19:25.720 Here are some things that we managed to find on production systems. 19:26.000 --> 19:40.080 So for example here, we managed to get repository access for SVN with some files, wc.db, which allowed us afterwards to basically fetch anything from the SVN repository, and afterwards getting the source code and so on. 19:40.080 --> 19:41.620 So this was quite problematic. 19:41.620 --> 19:52.080 We also had things like htpassword, which was not interpreted by the application server, for some reasons, misconfiguration, things like this. 19:52.080 --> 19:54.300 But this is something that we managed to show. 19:54.520 --> 20:02.980 And the idea was having hypothesis and trying them across a larger scope, depending on the scope that you have. 20:02.980 --> 20:16.720 But this was the idea, having a hypothesis, taking things maybe from the bug bounty, we were speaking about bug bounty beforehand, so just checking things that bug hunters are trying on large scopes. 20:16.720 --> 20:25.940 And you will see in the reference that there is a nice talk from James Kettle, Cracking the Lens, which is some research that he did in 2017. 20:25.940 --> 20:30.560 It's something quite similar to what we tried as well, and we got inspired. 20:30.560 --> 20:32.720 So this is why it's going to be in the references. 20:32.820 --> 20:37.580 And if you haven't seen the article, feel free to reach out and just check it out. 20:37.580 --> 20:39.060 It's absolutely awesome research. 20:39.060 --> 20:42.540 Even if it's 2017, absolutely awesome and just gold. 20:42.540 --> 20:46.400 So feel free to get it afterwards, and you will get it in the slides. 20:46.460 --> 20:48.280 So these were some things that we were trying. 20:48.280 --> 20:50.440 All right, maybe it's not going to be interpreted. 20:50.520 --> 20:51.720 Well, what do we lose? 20:51.720 --> 20:57.820 Just maybe writing a couple of lines of code and seeing if it's going to match and if it's going to trick somewhere. 20:58.420 --> 21:02.760 Fortunately for us, it tricked, and we managed to remediate it in a couple of hours. 21:03.280 --> 21:06.340 But also, internal information disclosure. 21:06.340 --> 21:10.540 So here we had the server status page, which gave us some information. 21:10.540 --> 21:12.640 Nothing super critical, but still. 21:12.640 --> 21:20.140 It could give URI, so basically endpoints, and maybe some kind of internal endpoints. 21:20.140 --> 21:25.380 But it was also giving some ideas about the IP address range that we were using internally. 21:25.380 --> 21:30.500 So those kind of things that we didn't want attackers to have on their hands. 21:30.500 --> 21:36.220 We wanted to try this across all our servers again, and finding them. 21:36.220 --> 21:39.300 So this is the kind of things that we managed to find. 21:40.820 --> 21:46.220 Last but not least, here is, for example, with the wildcard. 21:46.460 --> 21:51.760 So basically some cross-domain.xml files, which are way too permissive. 21:51.760 --> 22:00.400 Way too permissive, allowing anyone to just craft some payloads and being able to start discussing with our website. 22:00.400 --> 22:04.520 Might be afterwards stealing some cookies, stealing some information. 22:04.520 --> 22:08.060 And we wanted to just trigger it on all our parameters. 22:08.060 --> 22:10.740 This is something that we managed to find. 22:11.000 --> 22:13.280 One rule, doing it all. 22:14.340 --> 22:18.480 It worked pretty well, and we were really happy with this. 22:20.320 --> 22:23.760 So now, what we had was a hypothesis. 22:23.760 --> 22:31.240 We had a tool written by a security team, used by security people, and it was working. 22:31.240 --> 22:33.780 We were happy, everything was good. 22:33.900 --> 22:37.140 But then afterwards, we wanted to try the extra mile. 22:37.140 --> 22:40.380 And the extra mile was actually a couple of extra miles. 22:41.360 --> 22:47.700 And by saying this is, okay, we had our internal tool, and we wanted to make it available to everyone. 22:47.700 --> 22:50.900 And what we mean by everyone is mostly developers. 22:50.900 --> 22:58.160 As soon as having a tool, that they could integrate into the pipeline, and in the CI-CD pipeline. 22:58.160 --> 23:04.260 So this was our goal, and basically the polar star that we were trying to target. 23:04.960 --> 23:09.980 And it turns out that the first issue that we found was actually based on communication. 23:10.200 --> 23:13.240 Developers don't necessarily get security things. 23:13.240 --> 23:14.840 It's one of the golden rules. 23:14.840 --> 23:16.840 But same as the other way around. 23:16.840 --> 23:22.780 Which means that we're coming with our needs, we're coming with our ideas, with our beliefs. 23:23.120 --> 23:24.780 Developers come with theirs. 23:24.860 --> 23:29.020 And it turns out that we need to find a way on how to get a line. 23:29.440 --> 23:35.840 We found this interesting thread on Twitter, so we're not shaming anyone or doing any kind of finger pointing. 23:35.840 --> 23:38.560 But we think that it's an interesting thing. 23:39.300 --> 23:47.240 So we got someone on Twitter basically showing and giving some idea about past experience, and started using acronyms. 23:47.240 --> 23:53.080 IR, especially if you're working in security, this is something which stands for incident response. 23:53.080 --> 23:55.780 And this is perfectly understandable. 23:55.980 --> 24:02.280 But it turns out that in the comments, we got some people where IR didn't mean anything. 24:02.280 --> 24:08.760 So people started looking up and found that it was an acronym maybe for infrared cameras. 24:08.760 --> 24:16.900 And it's something that if this person doesn't know the acronym, there's some issue with the communication. 24:16.900 --> 24:21.180 And we need to find a way into achieving and finding a bridge between them. 24:21.180 --> 24:27.020 And the last picture is just showing on the right that everyone is right. 24:27.520 --> 24:31.160 Everyone is right based on what they're looking up. 24:31.160 --> 24:40.320 But it's just that we need to get those two people aligned to make sure that they can move forward and they can move together in the same direction. 24:40.540 --> 24:42.260 Security is not against developers. 24:42.260 --> 24:44.080 Developers are not against security. 24:44.080 --> 24:46.760 I think both of them can work together. 24:47.080 --> 24:53.380 But just trying to get the same beliefs, at least on some very specific topics. 24:55.040 --> 25:01.560 So yeah, interesting things about the communication channel and speaking the same language. 25:02.200 --> 25:06.340 And when it comes to security, it comes with a lot of details. 25:06.340 --> 25:10.040 SSTI, XSS, XSE, SQLI. 25:10.040 --> 25:12.680 But also when we're speaking about CVEs. 25:12.680 --> 25:16.860 So we get thousands of CVEs as we saw earlier. 25:16.860 --> 25:22.160 But also MS-Beltane, MS-08, MS-067. 25:22.160 --> 25:25.580 But we also have a name of vulnerabilities. 25:25.580 --> 25:28.440 Heartbleed, Eternalblue, Bluebone. 25:28.440 --> 25:33.080 And this is a huge referential that we do have in security. 25:33.080 --> 25:34.660 Absolutely crazy. 25:34.660 --> 25:40.640 And the thing is, security people are actually losing track of all this. 25:40.640 --> 25:42.500 It's so much information. 25:42.500 --> 25:44.800 We have so much information to process. 25:44.800 --> 25:48.280 So yeah, we have those named vulnerabilities. 25:48.280 --> 25:49.400 They have websites. 25:49.400 --> 25:50.180 They have videos. 25:50.180 --> 25:52.660 They have almost like choreography and things. 25:52.900 --> 25:57.880 But also like all the names of vulnerabilities and classes, vulnerability classes that we have. 25:57.880 --> 26:00.080 So much information to digest. 26:00.080 --> 26:05.280 It's already hard for security people and people working in this for day long, right? 26:05.280 --> 26:07.680 And who have been doing their careers in this. 26:07.680 --> 26:08.980 But what about developers? 26:08.980 --> 26:11.620 How can developers keep up with this information? 26:12.080 --> 26:17.420 When we just like giving them a report, some of them might just be, I'm just completely lost. 26:17.420 --> 26:18.380 I'm just completely lost. 26:18.380 --> 26:19.620 I have no idea what this means. 26:19.620 --> 26:26.820 I can see this presentation, but I might look like a fool if I just ask the question, what is this acronym for? 26:27.120 --> 26:34.600 So it's some information that we need to take care of and just making sure that we get the interesting bits to developers. 26:35.600 --> 26:40.620 And there's actually another question, and we're not getting to the debate, maybe afterwards in the Discord. 26:40.660 --> 26:44.120 But should developers keep up with all this information? 26:44.680 --> 26:45.540 Should they? 26:45.660 --> 26:46.700 And I don't know. 26:46.700 --> 26:49.320 But I don't have the information so far. 26:49.320 --> 26:50.140 I don't know. 26:50.140 --> 26:56.200 I have my opinion, but I'm happy to discuss and to chat about this afterwards in the Discord with you all. 26:56.760 --> 27:02.940 So a lot of information of process, a lot of vocabulary that we need to take care of. 27:04.760 --> 27:16.700 The second part was, all right, if we get a chop-chop hit and the application is flagged because of some reasons, maybe some plugins got in and so on. 27:16.700 --> 27:17.720 Now what? 27:17.720 --> 27:20.420 Now what is going to do the developer? 27:20.960 --> 27:22.200 I don't know. 27:22.400 --> 27:24.360 It just is that there's a URL. 27:24.360 --> 27:26.140 It's giving some information. 27:26.140 --> 27:27.680 But what is he going to do about this? 27:27.680 --> 27:28.860 What is the risk? 27:28.880 --> 27:32.740 And what is the kind of remediation he can put in place to mitigate this? 27:32.740 --> 27:35.720 But he needs to understand the risk and what can happen. 27:36.140 --> 27:39.880 What are the bad things that can happen with this specific thing? 27:39.880 --> 27:44.280 And in his environment and in his context, right? 27:44.500 --> 27:47.060 So security vocabulary is one thing. 27:47.060 --> 27:48.800 But remediation is another one. 27:48.800 --> 27:56.040 And bringing remediation in the tool and giving this capability is actually like bringing assistance to the developers. 27:56.040 --> 28:00.260 Which means that we're going one step forward to them, towards them. 28:00.260 --> 28:04.300 And what's going to happen is developers are going to come to us as well afterwards. 28:04.300 --> 28:06.840 And it's going to be a win-win discussion. 28:06.860 --> 28:12.020 And everyone's going to be aligned against just having secure application, running production. 28:12.020 --> 28:14.480 And everyone's going to be happy with this. 28:14.480 --> 28:18.180 So bring anything valuable as soon as you have a hit. 28:18.180 --> 28:21.340 And that you have something that's actually triggering in your environment. 28:21.340 --> 28:24.760 So it could be a link to whatever, what kind of explanation. 28:24.760 --> 28:26.340 It could be like a research document. 28:26.340 --> 28:27.920 It could be anything on Twitter. 28:27.920 --> 28:30.180 It could be just a thread, whatever. 28:30.180 --> 28:32.940 Or it could be also a pointer to internal resources. 28:33.060 --> 28:36.900 Do you use the OWASP ASVS, for example? 28:36.900 --> 28:39.760 So maybe that could be a link to the specific section. 28:39.760 --> 28:43.900 And just referencing it so that developers could start getting information. 28:43.900 --> 28:47.180 Developers are super curious as security peeps. 28:47.180 --> 28:52.100 So I think it's a good opportunity to have this discussion and this conversation with them. 28:52.100 --> 29:01.960 So yeah, just bringing assistance and helping them into achieving better security within their application by giving them as much inputs as we can. 29:02.920 --> 29:06.170 Another part is contextualization. 29:06.560 --> 29:09.900 And contextualization is also key. 29:10.160 --> 29:13.090 Again, I'm not going to go into debate. 29:13.090 --> 29:18.030 And I think that this is something like a question that you might have to ask yourself. 29:18.450 --> 29:36.610 Should we consider the same criticity if we get a chop-chop hit for one machine which is exposed on the Internet and one machine which is completely air-gapped in a segregated environment where only two people are reaching the application and this specific server? 29:37.230 --> 29:40.010 It might be some kind of trade-off that you need to find. 29:40.010 --> 29:41.650 Maybe it's finding some balance. 29:42.310 --> 29:52.110 Because if you start answering yes, this is exactly the same criticity, the same exploitability, it might just start giving red flags to developers. 29:52.110 --> 29:54.250 Because everything is going to be critical. 29:54.750 --> 29:57.490 And based on this, developers have a lot to deal with. 29:57.630 --> 29:59.010 Production errors. 29:59.010 --> 30:00.410 They have a lot of development. 30:00.410 --> 30:01.370 They have deadlines. 30:01.370 --> 30:03.950 They have a lot of work that they have to do. 30:03.950 --> 30:09.670 And if we start getting security tasks on top of it, they're going to start getting overwhelmed. 30:09.670 --> 30:14.970 And having too much information afterwards, they're not going to be able to process any of it. 30:14.970 --> 30:24.850 So this is why I think it's a trade-off about what we try to achieve with them and what's the image that we want them to perceive from us. 30:24.850 --> 30:28.310 So balance and trade-off are now part of the game. 30:30.650 --> 30:34.670 Last but not least is about collaboration. 30:34.750 --> 30:39.050 And we truly believe that collaboration will empower your organization. 30:39.050 --> 30:43.990 And by saying this, it's like finding the best tools to do it. 30:44.230 --> 30:52.770 So for example, a lot of people, when we released ChopChop in June, we had a lot of people asking us, what's the difference with Nikto? 30:52.930 --> 30:59.110 And we are users of Nikto, we find it absolutely an amazing tool, and it works greatly. 30:59.110 --> 31:03.210 But it works greatly especially for security-oriented people. 31:03.630 --> 31:09.970 Because it's going to give you usually a lot of output, but afterwards you're going to start to have to dig in. 31:09.970 --> 31:16.650 You might have between one line and the other, something which is going to be informational and another one which is going to be critical. 31:16.650 --> 31:24.790 But this is going to depend on your experience, on what you think about it, and you're going to have to do those choices on your own. 31:25.250 --> 31:27.370 Are the developers going to be able to do it? 31:27.370 --> 31:31.950 It might not be possible because they might not know anything about security. 31:31.950 --> 31:40.750 So this is why we want to help them by doing some kind of triage in all those findings, and providing them good inputs. 31:40.750 --> 31:47.010 So finding the best tools to do this is extremely important, and some of them might be tailor-made. 31:47.370 --> 31:50.270 So something definitely to bear in mind. 31:50.630 --> 32:11.530 Second of all is making sure that the learning curve that you're going to have, if you're looking for people to collaborate, which means writing new rules, helping, maybe doing a pull request on your project, and doing this kind of collaboration, make sure that the learning curve that people are going to have to start digging in the codebase, 32:11.530 --> 32:14.030 that's not going to be something too crazy. 32:14.650 --> 32:21.570 Usually, when we speak to developers, they find the security quite mystic. 32:21.570 --> 32:25.290 It's like some kind of black magic happening behind the scenes. 32:25.290 --> 32:43.050 They're using some weird commands and so on, and this is why if we start putting on the shelf a new application that we want people to start playing with, that they start collaborating with us, we need to make sure that this is mostly friendly to new people coming in security, 32:43.050 --> 32:45.850 and writing tools, and writing rules, and so on. 32:45.850 --> 32:47.530 So something to bear in mind. 32:47.910 --> 32:56.010 And again, this depends on the context where you're in, which means if your developers are using YAML, in this case, go for it. 32:56.010 --> 33:03.790 If your users stick with XML for some reasons, because in your context, this is what they use, stick with it and go for it. 33:03.790 --> 33:13.650 It's really going to depend on your context, and I think that the last point, discernment and clear thinking for your choices within your organization are key. 33:13.850 --> 33:23.790 This is one of the most important things that we learn, is just checking the context, and make sure that the security adapts perfectly to this context within your organization. 33:23.790 --> 33:40.610 Because if you're trying to get a bigger audience, and broaden the usage of your tools, you need to actually get them in, and by doing this, you need to look like them, so that they can start getting it without any issue. 33:41.150 --> 33:46.530 And last point, but not least, change the posture from no, you can't, to yeah, let's see how to make it. 33:46.530 --> 33:52.130 For example, if some people want to use the tool, because they also want to do some monitoring and things, yeah, why not? 33:52.130 --> 33:52.530 Why not? 33:52.530 --> 33:54.530 They should be able to do this, right? 33:54.530 --> 34:05.010 If they start asking questions about new technology, new frameworks that they want to put in, well, obviously there's going to be a balance into, is it something that's good for my company, for my organization? 34:05.010 --> 34:09.610 But you need to have this discussion, and not having just really close answers. 34:10.130 --> 34:23.170 So that's, we think, some of the keys that we got, and that we managed to see following this development, and trying to broaden the usage of our tools. 34:23.810 --> 34:36.690 So this is why we created GoChopChop, and what I'm going to do is give my seat to Stanislas, and he's going to present you the tool, and hopefully make an awesome testing session and demo video. 34:36.770 --> 34:37.530 Cheers! 34:40.630 --> 34:41.970 All right. 34:43.810 --> 34:47.050 Hello everyone, and thank you for watching this talk. 34:47.050 --> 34:53.910 I'm Stanislas Malveaux, I'm working currently as an intern, a security intern at Michelin. 34:54.670 --> 35:05.970 So I present to you how we created GoChopChop, which is the second version of ChopChop, which Paul presented to you. 35:06.670 --> 35:15.310 So, ChopChop, GoChopChop is a command line for dynamic application security testing, and it's written in Golang. 35:15.310 --> 35:25.350 Its purpose is to scan several endpoints, and expose services, files, folders, through the web root. 35:25.570 --> 35:36.050 And we created the tool so it can be fully configurable by developers, even by non-security people. 35:36.210 --> 35:43.670 And I present to you how it works, and how easy it is to modify and add a role, for example. 35:46.170 --> 35:47.430 Alright. 35:48.050 --> 35:56.490 So, here we are testing our own web application, which is exposed on port 80. 36:00.010 --> 36:01.690 Alright. 36:01.830 --> 36:10.090 So, for the purpose of the demo, we exposed a git config on the web application. 36:10.090 --> 36:23.350 So, we can see here, we did a curl on a web app, and it returns a status code of 200, and a core repository format version, and so on. 36:23.650 --> 36:29.930 So, now we're going to try the tool on our own web app. 36:32.970 --> 36:34.170 Here. 36:36.250 --> 36:37.130 Alright. 36:37.130 --> 37:01.330 So, we launched GoJarChat on our URL foobar.com, and it flagged the git config vulnerability, and it gives you a severity level, which is high in our case, a name for the plugin, and a remuneration we can use later to remunerate the vulnerability. 37:01.330 --> 37:10.590 So, now we're going to see how to configure ChopChop to make new rules, and how you can configure it. 37:11.070 --> 37:15.450 So... no. 37:15.610 --> 37:16.690 Alright. 37:18.210 --> 37:28.570 So, the rules are written in YAML, and it's very easy to create a new one or modify. 37:28.570 --> 37:37.170 So, here, for our example, we have the rule git config, so it will scan the endpoint slash git slash config. 37:37.430 --> 37:58.230 We give it a name, so git exposed, a status code of 200, which will scan the HTTP response to see if the HTTP response gives a 200 status code, a match, which is a list of strings the tool needs to find in the HTTP response. 37:58.230 --> 38:00.550 So, in our case, we saw it was core. 38:01.530 --> 38:06.130 There is other things like no match. 38:06.130 --> 38:13.670 No match is a list of strings which needs to not be in the HTTP response. 38:13.850 --> 38:19.490 And another one is headers, for example, content-type application-json. 38:19.830 --> 38:28.590 And you have to give it a remuneration, so here we say do not deploy .git folder on production servers. 38:28.590 --> 38:37.430 A quick description so the developers understand what is going on and why it has a severity level of high. 38:37.430 --> 38:45.830 So, here, it verifies that the git repository is accessible from the site and a severity level of high. 38:45.830 --> 38:52.190 So, you can easily modify it, for example, high to a low level. 38:52.190 --> 39:00.610 Or, for example, if the developers don't really know what to do, we can give FUBAR, for example. 39:05.070 --> 39:18.670 So, if we launch it now, it will say, OK, I don't understand FUBAR, you need to give a severity level of informational, low, medium, and high. 39:18.670 --> 39:23.150 So, we can modify it again to, for example, low. 39:23.710 --> 39:24.530 All right. 39:24.590 --> 39:32.650 And if you relaunch it, it will take into account the modification and the severity level goes to low. 39:32.870 --> 39:33.410 All right. 39:33.410 --> 39:37.370 So, now, we're going to do a new rule. 39:37.370 --> 39:48.370 For the sake of the demo, we created a quick HTML page. 39:51.530 --> 39:57.970 So, yeah, we see here we created an HTML which says DEFCON rocks. 39:57.970 --> 40:06.270 So, I want the tool to flag it and to give us an output on this. 40:07.070 --> 40:09.110 All right. 40:11.550 --> 40:12.910 OK. 40:13.410 --> 40:21.450 So, here, I'm going to scan the main endpoint of the web application. 40:21.790 --> 40:27.590 So, what we check is we give a name to the rule, so DEFCON rule here. 40:27.590 --> 40:32.890 We need a status code of 200 and we need to match the string DEFCON. 40:32.890 --> 40:37.290 So, if the DEFCON is found in the HTTP response, it will flag. 40:37.330 --> 40:40.470 And a remediation and description and the severity. 40:40.930 --> 40:42.670 So, we can test it. 40:45.530 --> 40:46.690 All right. 40:47.970 --> 40:54.650 And here, you see the tool flagged it on the main endpoint, the severity level and the remediation. 40:55.830 --> 40:56.530 All right. 40:56.730 --> 40:58.410 That's pretty much it. 40:59.390 --> 41:03.790 Paul will finish this presentation and thanks for listening. 41:06.690 --> 41:08.710 Welcome back. 41:09.430 --> 41:13.310 Thank you, Stanislas, for the demo. 41:14.110 --> 41:16.390 So, what we learned from this. 41:16.430 --> 41:23.570 So , from going from an offensive mindset to creating a tool used by developers. 41:23.570 --> 41:37.870 And what we learned was things that finding the same language, same vocabulary and speaking the same with the same concept is extremely important. 41:38.350 --> 41:44.830 Second of all is make sure that they get your points and that you get theirs as well. 41:44.830 --> 41:53.030 Which means that if you have some beliefs, if you have some things and reasons that you think that the application should be secured this way. 41:53.030 --> 41:58.830 Just make sure that you also understand what are their problematics in terms of development side. 41:58.830 --> 42:01.990 Maybe it can be something based on the organizations. 42:01.990 --> 42:05.050 But this is something that has to be done, definitely. 42:05.050 --> 42:13.390 It has to be done and having you to be conversational in two channels, basically. 42:13.890 --> 42:18.310 Third point is bringing assistance will lead to better collaboration. 42:18.310 --> 42:25.310 So, as Stanislas showed you before, by giving some remediations. 42:25.310 --> 42:39.610 This could be giving links, giving information to the ASVS OWASP, to a bunch of resources and trying to give more information to the people so that they could secure it in a timely manner. 42:39.610 --> 42:50.150 This is something that bringing this will actually help them and helping them will bring definitely more joy and they're going to be able to help you as well if you're looking for something. 42:51.310 --> 42:58.070 Again, don't underestimate collaboration to broaden your audience based on your context. 42:58.370 --> 43:06.370 If the developers that you have that you're trying to target are using XML and you're coming with something in YAML, this is not going to work. 43:06.370 --> 43:07.790 The opposite as well. 43:07.790 --> 43:15.850 Because everything which might be shiny or anything like this might not be the real solution and you're not going to bring anything to them. 43:15.850 --> 43:18.370 So, try to bring something super valuable. 43:18.970 --> 43:21.070 This is extremely important. 43:21.070 --> 43:27.910 And last point, but not least, that we have on our checklist is the contextualization in the trade-off. 43:28.010 --> 43:29.650 Having this balance. 43:29.650 --> 43:42.250 As I showed you before, Stanislas, during the presentation, you are able to change, for example, the severity of one specific finding if your organization has a specific context. 43:42.550 --> 43:50.970 For this specific trigger, this specific hit, especially with the GitExpo, I would not recommend putting it in low. 43:50.970 --> 43:56.130 But this is something that we can do and programmatically everyone can do this. 43:56.130 --> 43:58.830 Even non-developers people, non-tech people. 43:58.830 --> 44:06.710 You could definitely imagine a product owner or anyone just like, you have this file and you can actually start tweaking a couple of parameters. 44:06.730 --> 44:08.870 This is something that we can do. 44:08.870 --> 44:21.970 And even though you can tweak the parameters, if anyone is just going wrong, you can see that there are a couple of checks that Stanislas developed to make sure to give some insights about, okay, it failed, but why does it fail? 44:21.970 --> 44:29.150 And okay, so it's got an enumeration and you can only choose from those specific values. 44:29.250 --> 44:36.810 But anyway, so those are, I would say, the lesson learned from having an offensive tool and putting it into developers' hands. 44:37.790 --> 44:43.210 We do have a couple of references and obviously we're just on the shoulder of giants. 44:43.210 --> 44:51.070 And I think that those specific links are quite valuable, especially with what we try to build. 44:51.070 --> 44:57.830 And I think that those talks and those blog posts are actually similar to the mindset that we have. 44:57.830 --> 45:02.390 So first of all, and we talked about it with cracking the lens from James Cato. 45:02.390 --> 45:14.710 And I think it's interesting in terms of the scope he has, taking everything from the bug bounty platform and having hypotheses and running it and seeing if it triggers anything or not. 45:14.710 --> 45:17.370 The second one is the keynote from the STIC. 45:17.370 --> 45:19.630 STIC is a French conference in France. 45:19.630 --> 45:26.110 And we had the privilege to have Alex Ionescu in 2019 speaking about security with developers. 45:26.110 --> 45:43.570 He started dealing with Rust and a bunch of things like this where he was actually launching the debate about should developers keep up with the compilation flags to avoid having any kind of memory corruption errors, etc. 45:43.750 --> 45:45.810 And it's an interesting discussion. 45:45.810 --> 45:49.830 I think that might have some English subtitles because the talk is in French. 45:49.830 --> 45:54.990 But definitely something that I would consider to watch afterwards. 45:54.990 --> 45:58.310 The last two are actually from Harold Meir. 45:58.850 --> 46:01.050 And two great conferences talks. 46:01.050 --> 46:03.850 The first one, learning the wrong lessons from offense. 46:03.850 --> 46:08.490 And the second one from B-Sides Doha, which is make more stuff. 46:08.650 --> 46:11.610 And this was oriented to security people. 46:12.050 --> 46:16.650 So those four references are absolutely awesome. 46:16.650 --> 46:18.950 And we recommend you to watch them. 46:18.950 --> 46:21.770 It's worth the watch, definitely. 46:23.370 --> 46:24.830 So thanks a lot. 46:24.830 --> 46:26.150 Thanks a lot for your time. 46:26.150 --> 46:27.490 Thanks a lot for watching. 46:27.570 --> 46:33.390 Feel free to check our GitHub if you want to follow the project and start collaborating with us. 46:33.390 --> 46:41.510 And if we do have one advice, embrace hackiness, have fun and collaborate with your organization to make it more secure. 46:41.930 --> 46:42.710 Cheers. 46:42.970 --> 46:43.890 Bye.