All right, everyone, welcome back.
If you're just joining us here in the AppSec Village,
I hope you are ready for a fantastic talk.
If you're still hanging around from the last talk,
glad to have you back. This is going to be awesome.
I wanted to take a few minutes to thank everybody
who helped to put on DEF CON this year.
I know this has been very challenging for people.
It's challenging for us at home.
It's doubly challenging to bring
a great conference experience to DEF CON.
And we really hope that comes through.
Also take a minute to thank the AppSec Village.
Some people have put in amazingly long hours
to make this stuff happen.
And we want to thank them as part of that.
Additionally, if you want to get a shirt,
head over to the AppSec Village website.
You can purchase your shirt there
for the second incarnation of the AppSec Village.
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.
Hi. Hello, everyone.
Thanks for joining our presentation,
which is going to be today about our journey
into turning offsec mindset to developer's toolset.
This presentation, we're going to be two of them doing it.
And it's going to be in what we can say three parts.
First one is going to be about a tool
that we created inside our company,
which is called ChopChop.
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.
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.
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.
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.
So hopefully, we hope that you're going to learn
something about it.
All right, let's start.
This graph, we actually took it from CVE details.
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.
So we took this graph last year,
and we can realize that between 2016 to 2017,
the number of CVEs just doubled.
And this is something that we can see.
Every day and every week, we get new vulnerabilities coming in.
We get Oracle built-in, which is just full,
and hundreds of vulnerabilities are inside.
We also get built-in of Microsoft,
which are just showing up hundreds of vulnerabilities,
or let's say dozens of vulnerabilities each month.
And this is something that's growing, obviously,
and we're hearing a lot about this.
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.
So this is something that we can feel,
and this is getting really, really big.
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.
And this is the number of new vulnerabilities that we get per week.
And this is huge, huge for a team to just realize
that we do have to process all this information.
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.
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.
And this is a huge thing to actually realize and to process,
especially depending on the size of your team.
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,
on specific magazines, on specific websites,
and they actually hear about like this,
and there's like a really big buzz around those vulnerabilities.
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?
And this is something that, well, we can understand it, obviously.
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.
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, and so on.
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.
So the context was based on this.
So the problematics we had was something circa 2016,
when we started having like this kind of philosophy and mindset.
And the idea was we had thousands of servers and domains that had to be scanned daily.
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.
So we wanted to have like fresh data all the time, and daily fresh data.
Second of all is we did not have direct access to the servers in some specific situations.
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.
So we didn't have like SSH access on all the machines all the time.
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.
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.
The tech landscape that we had was also unclear.
In 2016, 2017, there were a lot of vulnerabilities, especially with WebDAV, if you can remember.
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.
So these were the things where, okay, there's a huge vulnerability with struts.
Are we vulnerable to it? Yes, no.
And can we quantify the number of servers which might be potentially vulnerable to this?
And the last point, but not least, is interesting.
And speaking of which, it's like this lean security, all right?
And it's the idea of ability to perform checks every time, so again and again.
So basically, this kind of like loop, this lean loop that we can have,
where we would be able to like spot security regression.
And this remembers like a cool anecdote, if we can say it this way.
There's one company, quite big company, having a bug bounty program.
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.
They fixed it.
But unfortunately, a couple of weeks later, they redeployed the same vulnerable component.
And another bounty researcher found it.
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.
And this is what I'm going to call security regression.
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.
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.
We have everything automated right now. We do have like a lot of pipelines for our developers.
Everything is going faster and faster and faster.
And I think that we can improve our way into this.
And this is some of the reasons why we created our tools, and we wanted to tackle this issue.
Security regression was one of the big parts.
So this was our context.
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.
So yeah, 2017, we had Struts, we had RCE, so Remote Code Execution on Drupal.
We had WebDAV, we had like lots, a lot of things happening, obviously.
And we had to process this as fast as we could.
So this was one thing. The other one was, we had like a small team working on this.
When I'm speaking of small teams, it was three to four people.
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,
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.
But never mind, we will come back to this later on.
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.
The second one was having something reliable.
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.
So there would be nothing random in the processing.
So we would know exactly how the rules would be triggered.
And if we would run it twice, we should have the same output, obviously.
And the last point, but not least, would be no false positives.
So it's interesting because we need to find like a threshold, right?
We need to have like a tool super fast.
But on the other hand, we don't want any false positives, which is really hard to combine all together.
So it's two criteria, which unfortunately don't really work together.
But we think that we did quite a great job, and this is something that we managed to do.
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?
And not having like a lot and lot and lot information to process.
So really trying to like do some kind of like sniper thing,
and just making sure that we get to what's really valuable.
So those were our needs, and yeah, trust me, we had a lot of them.
So if we can take an image, an analogy, it would be like more or less like going to the jungle, right?
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.
But this was like more or less the case.
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.
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.
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.
This was like mostly like the whole soul of the application.
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.
So we were saying chop-chop, chop-chop, and what does it mean?
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.
So we thought the name was interesting, and exactly what was like the spirit of the tool.
So this is why we called it chop-chop.
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.
So it was the whole soul, and this is why we kept the name chop-chop,
and released the tool with this name.
The tool initially back in 2017 was written with Python.
We started with Python 2.7, then migrated to Python 3.
We got everything working, and following the upcoming month,
we started getting plugins that the security team mostly wrote.
And in the end, we came up with 80 plugins.
So 80 things processing, which were done.
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.
A couple of things like this, and we started like creating plugins,
which were specific to our environment.
Those ones were not released, but this gives you the idea of the flexibility of the tool.
So taking a domain name or an IP, and afterwards doing some processing.
And any kind of processing, basically.
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.
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.
So daily scans, basically every day, and allowed us to answer two questions.
The first one would be to answer to the management,
are we affected? Yes, no.
And then afterwards, being able to quantify the number of servers,
or number of IPs, which were actually affected with this specific vulnerability.
Is it going to be one? Is it going to be 100?
Is it going to be dozens, hundreds, thousands?
Is it going to be all the servers at once?
So it's actually quantifying the results, and we were able to do this.
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.
And this allowed us, and this saved us a lot of time.
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.
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.
Based on this, we're going to have a severity, which ranks from 0 to 10.
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.
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, this is something that was a bit useless.
But we will come back to this.
We had a description, ensuring that the git repository is not accessible from the web root,
and one fix, what we can call remediation.
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.
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.
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.
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.
And afterwards, you would just have to override a couple of things and you would be start to go.
Here are some things that we managed to find on production systems.
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.
So this was quite problematic.
We also had things like htpassword, which was not interpreted by the application server,
for some reasons, misconfiguration, things like this.
But this is something that we managed to show.
And the idea was having hypothesis and trying them across a larger scope,
depending on the scope that you have.
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.
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.
It's something quite similar to what we tried as well, and we got inspired.
So this is why it's going to be in the references.
And if you haven't seen the article, feel free to reach out and just check it out.
It's absolutely awesome research.
Even if it's 2017, absolutely awesome and just gold.
So feel free to get it afterwards, and you will get it in the slides.
So these were some things that we were trying.
All right, maybe it's not going to be interpreted.
Well, what do we lose?
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.
Fortunately for us, it tricked, and we managed to remediate it in a couple of hours.
But also, internal information disclosure.
So here we had the server status page, which gave us some information.
Nothing super critical, but still.
It could give URI, so basically endpoints, and maybe some kind of internal endpoints.
But it was also giving some ideas about the IP address range that we were using internally.
So those kind of things that we didn't want attackers to have on their hands.
We wanted to try this across all our servers again, and finding them.
So this is the kind of things that we managed to find.
Last but not least, here is, for example, with the wildcard.
So basically some cross-domain.xml files, which are way too permissive.
Way too permissive, allowing anyone to just craft some payloads
and being able to start discussing with our website.
Might be afterwards stealing some cookies, stealing some information.
And we wanted to just trigger it on all our parameters.
This is something that we managed to find.
One rule, doing it all.
It worked pretty well, and we were really happy with this.
So now, what we had was a hypothesis.
We had a tool written by a security team, used by security people, and it was working.
We were happy, everything was good.
But then afterwards, we wanted to try the extra mile.
And the extra mile was actually a couple of extra miles.
And by saying this is, okay, we had our internal tool, and we wanted to make it available to everyone.
And what we mean by everyone is mostly developers.
As soon as having a tool, that they could integrate into the pipeline, and in the CI-CD pipeline.
So this was our goal, and basically the polar star that we were trying to target.
And it turns out that the first issue that we found was actually based on communication.
Developers don't necessarily get security things.
It's one of the golden rules.
But same as the other way around.
Which means that we're coming with our needs, we're coming with our ideas, with our beliefs.
Developers come with theirs.
And it turns out that we need to find a way on how to get a line.
We found this interesting thread on Twitter, so we're not shaming anyone or doing any kind of finger pointing.
But we think that it's an interesting thing.
So we got someone on Twitter basically showing and giving some idea about past experience, and started using acronyms.
IR, especially if you're working in security, this is something which stands for incident response.
And this is perfectly understandable.
But it turns out that in the comments, we got some people where IR didn't mean anything.
So people started looking up and found that it was an acronym maybe for infrared cameras.
And it's something that if this person doesn't know the acronym, there's some issue with the communication.
And we need to find a way into achieving and finding a bridge between them.
And the last picture is just showing on the right that everyone is right.
Everyone is right based on what they're looking up.
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.
Security is not against developers. Developers are not against security.
I think both of them can work together.
But just trying to get the same beliefs, at least on some very specific topics.
So yeah, interesting things about the communication channel and speaking the same language.
And when it comes to security, it comes with a lot of details.
SSTI, XSS, XSE, SQLI.
But also when we're speaking about CVEs.
So we get thousands of CVEs as we saw earlier.
But also MS-Beltane, MS-08, MS-067.
But we also have a name of vulnerabilities.
Heartbleed, Eternalblue, Bluebone.
And this is a huge referential that we do have in security.
Absolutely crazy.
And the thing is, security people are actually losing track of all this.
It's so much information.
We have so much information to process.
So yeah, we have those named vulnerabilities.
They have websites.
They have videos.
They have almost like choreography and things.
But also like all the names of vulnerabilities and classes, vulnerability classes that we have.
So much information to digest.
It's already hard for security people and people working in this for day long, right?
And who have been doing their careers in this.
But what about developers?
How can developers keep up with this information?
When we just like giving them a report, some of them might just be, I'm just completely lost.
I'm just completely lost.
I have no idea what this means.
I can see this presentation, but I might look like a fool if I just ask the question, what is this acronym for?
So it's some information that we need to take care of and just making sure that we get the interesting bits to developers.
And there's actually another question, and we're not getting to the debate, maybe afterwards in the Discord.
But should developers keep up with all this information?
Should they?
And I don't know.
But I don't have the information so far.
I don't know.
I have my opinion, but I'm happy to discuss and to chat about this afterwards in the Discord with you all.
So a lot of information of process, a lot of vocabulary that we need to take care of.
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.
Now what?
Now what is going to do the developer?
I don't know.
It just is that there's a URL.
It's giving some information.
But what is he going to do about this?
What is the risk?
And what is the kind of remediation he can put in place to mitigate this?
But he needs to understand the risk and what can happen.
What are the bad things that can happen with this specific thing?
And in his environment and in his context, right?
So security vocabulary is one thing.
But remediation is another one.
And bringing remediation in the tool and giving this capability is actually like bringing assistance to the developers.
Which means that we're going one step forward to them, towards them.
And what's going to happen is developers are going to come to us as well afterwards.
And it's going to be a win-win discussion.
And everyone's going to be aligned against just having secure application, running production.
And everyone's going to be happy with this.
So bring anything valuable as soon as you have a hit.
And that you have something that's actually triggering in your environment.
So it could be a link to whatever, what kind of explanation.
It could be like a research document. It could be anything on Twitter.
It could be just a thread, whatever.
Or it could be also a pointer to internal resources.
Do you use the OWASP ASVS, for example?
So maybe that could be a link to the specific section.
And just referencing it so that developers could start getting information.
Developers are super curious as security peeps.
So I think it's a good opportunity to have this discussion and this conversation with them.
So yeah, just bringing assistance and helping them into achieving better security within their application
by giving them as much inputs as we can.
Another part is contextualization.
And contextualization is also key.
Again, I'm not going to go into debate.
And I think that this is something like a question that you might have to ask yourself.
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?
It might be some kind of trade-off that you need to find.
Maybe it's finding some balance.
Because if you start answering yes, this is exactly the same criticity,
the same exploitability, it might just start giving red flags to developers.
Because everything is going to be critical.
And based on this, developers have a lot to deal with.
Production errors. They have a lot of development.
They have deadlines. They have a lot of work that they have to do.
And if we start getting security tasks on top of it,
they're going to start getting overwhelmed.
And having too much information afterwards,
they're not going to be able to process any of it.
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.
So balance and trade-off are now part of the game.
Last but not least is about collaboration.
And we truly believe that collaboration will empower your organization.
And by saying this, it's like finding the best tools to do it.
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?
And we are users of Nikto, we find it absolutely an amazing tool, and it works greatly.
But it works greatly especially for security-oriented people.
Because it's going to give you usually a lot of output,
but afterwards you're going to start to have to dig in.
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.
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.
Are the developers going to be able to do it?
It might not be possible because they might not know anything about security.
So this is why we want to help them by doing some kind of triage in all those findings,
and providing them good inputs.
So finding the best tools to do this is extremely important,
and some of them might be tailor-made.
So something definitely to bear in mind.
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,
that's not going to be something too crazy.
Usually, when we speak to developers, they find the security quite mystic.
It's like some kind of black magic happening behind the scenes.
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,
and writing tools, and writing rules, and so on.
So something to bear in mind.
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.
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.
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.
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.
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.
And last point, but not least, change the posture from no, you can't,
to yeah, let's see how to make it.
For example, if some people want to use the tool,
because they also want to do some monitoring and things,
yeah, why not? Why not?
They should be able to do this, right?
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?
But you need to have this discussion,
and not having just really close answers.
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.
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.
Cheers!
All right.
Hello everyone, and thank you for watching this talk.
I'm Stanislas Malveaux, I'm working currently as an intern,
a security intern at Michelin.
So I present to you how we created GoChopChop,
which is the second version of ChopChop,
which Paul presented to you.
So, ChopChop, GoChopChop is a command line
for dynamic application security testing,
and it's written in Golang.
Its purpose is to scan several endpoints,
and expose services, files, folders, through the web root.
And we created the tool so it can be fully configurable by developers,
even by non-security people.
And I present to you how it works,
and how easy it is to modify and add a role, for example.
Alright.
So, here we are testing our own web application,
which is exposed on port 80.
Alright.
So, for the purpose of the demo,
we exposed a git config on the web application.
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.
So, now we're going to try the tool on our own web app.
Here.
Alright.
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.
So, now we're going to see how to configure ChopChop
to make new rules, and how you can configure it.
So... no.
Alright.
So, the rules are written in YAML,
and it's very easy to create a new one or modify.
So, here, for our example, we have the rule git config,
so it will scan the endpoint slash git slash config.
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.
So, in our case, we saw it was core.
There is other things like no match.
No match is a list of strings which needs to not be in the HTTP response.
And another one is headers, for example, content-type application-json.
And you have to give it a remuneration,
so here we say do not deploy .git folder on production servers.
A quick description so the developers understand what is going on
and why it has a severity level of high.
So, here, it verifies that the git repository is accessible from the site
and a severity level of high.
So, you can easily modify it, for example, high to a low level.
Or, for example, if the developers don't really know what to do, we can give FUBAR, for example.
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.
So, we can modify it again to, for example, low.
All right.
And if you relaunch it, it will take into account the modification and the severity level goes to low.
All right. So, now, we're going to do a new rule.
For the sake of the demo, we created a quick HTML page.
So, yeah, we see here we created an HTML which says DEFCON rocks.
So, I want the tool to flag it and to give us an output on this.
All right.
OK.
So, here, I'm going to scan the main endpoint of the web application.
So, what we check is we give a name to the rule, so DEFCON rule here.
We need a status code of 200 and we need to match the string DEFCON.
So, if the DEFCON is found in the HTTP response, it will flag.
And a remediation and description and the severity.
So, we can test it.
All right.
And here, you see the tool flagged it on the main endpoint, the severity level and the remediation.
All right. That's pretty much it.
Paul will finish this presentation and thanks for listening.
Welcome back.
Thank you, Stanislas, for the demo.
So, what we learned from this.
So, from going from an offensive mindset to creating a tool used by developers.
And what we learned was things that finding the same language, same vocabulary and speaking the same with the same concept is extremely important.
Second of all is make sure that they get your points and that you get theirs as well.
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.
Just make sure that you also understand what are their problematics in terms of development side.
Maybe it can be something based on the organizations.
But this is something that has to be done, definitely.
It has to be done and having you to be conversational in two channels, basically.
Third point is bringing assistance will lead to better collaboration.
So, as Stanislas showed you before, by giving some remediations.
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.
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.
Again, don't underestimate collaboration to broaden your audience based on your context.
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.
The opposite as well.
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.
So, try to bring something super valuable.
This is extremely important.
And last point, but not least, that we have on our checklist is the contextualization in the trade-off.
Having this balance.
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.
For this specific trigger, this specific hit, especially with the GitExpo, I would not recommend putting it in low.
But this is something that we can do and programmatically everyone can do this.
Even non-developers people, non-tech people.
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.
This is something that we can do.
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?
And okay, so it's got an enumeration and you can only choose from those specific values.
But anyway, so those are, I would say, the lesson learned from having an offensive tool and putting it into developers' hands.
We do have a couple of references and obviously we're just on the shoulder of giants.
And I think that those specific links are quite valuable, especially with what we try to build.
And I think that those talks and those blog posts are actually similar to the mindset that we have.
So first of all, and we talked about it with cracking the lens from James Cato.
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.
The second one is the keynote from the STIC. STIC is a French conference in France.
And we had the privilege to have Alex Ionescu in 2019 speaking about security with developers.
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.
And it's an interesting discussion. I think that might have some English subtitles because the talk is in French.
But definitely something that I would consider to watch afterwards.
The last two are actually from Harold Meir.
And two great conferences talks. The first one, learning the wrong lessons from offense.
And the second one from B-Sides Doha, which is make more stuff.
And this was oriented to security people.
So those four references are absolutely awesome.
And we recommend you to watch them. It's worth the watch, definitely.
So thanks a lot. Thanks a lot for your time. Thanks a lot for watching.
Feel free to check our GitHub if you want to follow the project and start collaborating with us.
And if we do have one advice, embrace hackiness, have fun and collaborate with your organization to make it more secure.
Cheers. Bye.