Abusing SAST tools
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 84 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54232 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 2915 / 84
1
2
3
4
6
7
13
15
20
37
39
43
44
47
48
49
55
00:00
Information securityScale (map)AutomationSoftware developerMathematical analysisSoftwareComputerComputer programCodeConsistencyAbstract syntax treeRule of inferenceConfiguration spaceData structureExtension (kinesiology)Process (computing)Game theoryPosition operatorStandard deviationMachine codeHacker (term)Cartesian coordinate systemBinary codeBitInsertion lossSelf-organizationType theoryMathematical analysisPhysical systemRule of inferenceDifferent (Kate Ryan album)Port scannerProcess (computing)CybersexForm (programming)Computer fileDisk read-and-write headData structureSoftware bugConsistencyComputer programmingComplex (psychology)Software testingFluid staticsScaling (geometry)MereologyCodeInformation securitySystem callExpressionLengthDataflowGame controllerFunctional (mathematics)Parameter (computer programming)Compilation albumNetwork topologyProgrammanalyseMultiplication signToken ringFormal languageSoftwareHeegaard splittingAbstract syntax treeLogicFile formatResultantDirected graphSocial classoutputFocus (optics)IdentifiabilityLoginNeuroinformatikScripting language
08:42
Complex (psychology)Source codeExplosionMathematical analysisSoftwareComputerComputer programCodePort scannerComputer configurationBinary codeLocal ringDefault (computer science)Internet service providerConfiguration spacePenetrationstestOpen sourceIntegrated development environmentInformation securitySoftware repositoryCloningFluid staticsCodeIntegrated development environmentInformation securityMultilaterationSoftware developerSoftware bugInternet service providerBitType theoryDifferent (Kate Ryan album)Computer fileMalwareNeuroinformatikPort scannerPlanningGraph (mathematics)Point cloudHypothesisAreaDirected graphRemote procedure callSource codeSoftware repositoryPointer (computer programming)Directory serviceComputer programmingConfiguration spaceCausalityMereologyCapability Maturity ModelLevel (video gaming)CloningOpen sourceInternet forumServer (computing)NumberVideo gameClient (computing)Hacker (term)MathematicsMultiplication signSoftware as a serviceReal numberTracing (software)Rule of inference
17:25
CodeFluid staticsMathematical analysisConfiguration spaceStructural loadPort scannerTable (information)SpywareRepetitionSource codeCommon Language InfrastructureDirectory serviceComputer fileSequenceCore dumpAliasingInertialsystemHardware-in-the-loop simulationFunctional (mathematics)Reading (process)Form (programming)Software developerSource codeCore dumpString (computer science)Computer fileIntegrated development environmentPort scannerBuildingSpywareCodeNumberConfiguration spaceDemo (music)Proper mapInformation securitySoftware repositoryDifferent (Kate Ryan album)SoftwareFormal languageEvent horizonMoment (mathematics)Directory serviceRule of inference3 (number)FehlererkennungscodeProxy serverVariable (mathematics)Wind tunnelCausalityForcing (mathematics)
26:07
String (computer science)Source codeCodeAliasingProcess (computing)Integrated development environmentConfiguration spaceProxy serverIntrusion detection systemInformation securityPort scannerFunction (mathematics)Computer fileLaptopWrapper (data mining)Group actionSoftware testingSoftware frameworkMathematical analysisInformation securityCodeLine (geometry)Configuration spacePhysical systemSoftware developerMathematical analysisVirtual machineFluid staticsNeuroinformatikIntegrated development environmentCloningSource codePort scannerComputer programmingRule of inferenceComputer fileDifferent (Kate Ryan album)Structural loadFerry CorstenContext awarenessTwitterBitLink (knot theory)Message passingElectric generatorOrder (biology)2 (number)Software as a serviceStandard deviationObservational studyAutomationoutputLetterpress printingTouchscreenLaptopSoftware frameworkSoftwareData miningElectronic mailing listProduct (business)NP-hardLatent heatBranch (computer science)Image resolutionSelf-organizationAreaLevel (video gaming)Variable (mathematics)CuboidKey (cryptography)LaserMappingSensitivity analysisType theoryComputer configurationMultiplication signGroup actionJava appletOperator (mathematics)Proxy serverNumberMoment (mathematics)Software repositoryFunctional (mathematics)Gastropod shellPoint cloudSoftware testingOpen sourceDefault (computer science)Side channel attackAnalytic continuationGoodness of fitSystem callFile formatFunction (mathematics)Instance (computer science)Wrapper (data mining)Library (computing)MereologyBoolean algebra
Transcript: English(auto-generated)
00:00
For the last couple of months, I've been playing with different SAS tools. I'm playing with SAS tools because part of my job and part of my actually interest is how to secure code in the best way. And doing so, we always start by playing with SAS.
00:22
After SAS, they're much more highest than dust, but this talk will focus about static tools and I tend to play with them and abuse them in different ways. And I will show you how. So who am I? I'm Rotem, nice to meet you.
00:41
I'm the head of marketplace at cybersecurity. It's a startup I joined a few months ago. But more important, I'm a bug bounty researcher. I play with lots of different programs over the years. And I am a cyber paladin for the last 20 years now.
01:01
So I started my InfoSec career 20 years ago and I'm just playing around with different form application testing to infrastructure testing to developing different SAS tools and now playing and abusing the SAS tools. And I will show you what I've done.
01:23
So first of all, who is my target audience? So I'm targeting different type of people and I think this will interest also security engineers who want to fix problems and to tell other people where they have gone wrong.
01:41
I'm targeting DevOps people because they are in charge of large scale deployments and every day we have more and more automation and more automated deployments going out every day. SAS to build those of course, it's a different, this talk is about SAS.
02:02
So I'm targeting you guys and a bit of bad guys, people who have decided to harm other people for a living. I hope none are in the audience here, but if you are, please go to the good side and start helping people. So a bit about what I will be talking about,
02:22
it's SAS, how it works. I'm going to give a brief intro about how everything works and why I started this research. I will show a bit the hacking and what I've done and I will wrap up with different conclusions and what is the impact of all of this.
02:41
So SAS 101, what is SAS? SAS is Static Application Security Testing. This means that we are testing applications in a static manner. So I went to Wikipedia and Wikipedia says it very, very easy
03:01
that static program analysis is the analysis of computer software that is performed without actually executing any programs. So, and this is very important because static analysis can happen on different targets
03:20
with different types of trust and we don't want to execute any programs. Let's say that we have different fuzzers that do execute programs in the sandbox environments, but SAS is supposed not to execute nothing. So why do we run the SAS?
03:42
The first thing is to stop bad security practices. We want to make sure that nobody inserts a bad code into our organization. We want to prevent infrastructure mistakes and now we have lots of infrastructure as code.
04:01
We want to assess code. So if we have like a big security test, sometimes I will run a bunch of SAS tools to check the code. And I want to create standardization and consistency across lots of codes. So let's say we want,
04:21
say there's no evil in our code. We can create a rule, no evil, and we run it and it would be standardized. So why SAS? And we have different pros and cons, but the pros, it's very fast.
04:43
It can run on code. Different SAS have different like times, but it's much faster than dust and much faster than other fuzzing and various solutions. It's safe. It doesn't execute any code. And it's easy. We can run on the code.
05:00
We usually don't need any other resources. Sometimes we have imports and stuff like that, but usually it's inside the same code base and we don't need external resources for it. About the cons, we have lots of false positives. Like SAS can do as much as looking at the code,
05:24
but it doesn't know what's the logic and it doesn't know how it is used. It's a very hard to track flow control. So if you have lots of complex flows, SAS will be a nightmare over here.
05:40
But not why SAS, but how do they work? How does the scanners work exactly? So first of all, the scanners take the code, they parse the code and they look for different, let's say JavaScript. So they look for JavaScript files and then they start converting these JavaScript text files into AST structures.
06:02
AST is a structure of how to template code in a way we can process it later. So after we create this AST, and I will show you later how it looks like, we start processing it. When we process the code, we just look for, in basic, we have different rules
06:23
and different findings we want to look for. And then the more complex AST, we have flow control analysis and we start looking for sources and sinks. But then we have all the results and we'll create a result-based AST. Usually today we have SARIF, it's a very fun format
06:44
that lots of tools are starting to adapt. And we are working with this and we are creating the results so other systems can consume them. Let's take an example. If we have a log one plus two times three,
07:01
it's a very simple function that does a arithmetic compilation. And how does it look like in AST? So first of all, if we look at the binary of the tree, so we see the program, it's calling the expression, the call expression is log. It has a plus expression and then there's a split, like one.
07:23
And because times is before plus, and this is a basic math, so we have a split over there and then there's the two and three. Sometimes these ASTs are by ANTLR, it's like a destructuring tokenizer language
07:42
or by other means, it doesn't matter how it created it, but then it creates this tree. From this tree, we can create a JSON or XML or however we want to represent it, but we are creating the data that we can start looking up on it.
08:01
So let's say we have here a call expression and then for again, we're for Kali and arguments, and you can see the binary expression. So now we can start walking the tree and start understanding what's happening over here. If we take a basic rule, let's say we want that if this is a call expression
08:21
and we have a log and the length is above zero, we have arguments, then we can say there's a log function with more than one argument. It can get complex. We can have more very flow control
08:41
and very complex architectures. So let's say we have this if and then, and all of this goes into a variable we call source or we tag it as a source. And then we create another argument, another lookup for sinks. If we're using Neo4j or some other graph database,
09:03
we can start connecting sinks and source and seeing the whole trace. And then if there's a trace, we can report a finding. So it can get very complex and very fast. And this is why, but still it's very functional.
09:20
It's very static. There's no, we never execute the code. So as Wikipedia said, it really doesn't execute the code. We don't have any execution over here and we are all good to go. And we can start using the SAS to assess even the most malicious programs
09:43
and malicious code areas. So my hypothesis and my question was, what if I could write code that will intentionally abuse a scanner when scanned,
10:01
when statically scanned? So this means can I create a method or a way with these areas to do something? To change the behavior of the scanner, to abuse it or change it though. So I looked up at different previous researchers
10:22
and we had, in the past, there was a check of remote code execution. It was fixed and a check of two, when they created it, someone could create a malicious telephone file. And with this telephone file, it could execute code inside checkup
10:41
and when executing the code, it had access to the whole environment of where it was executed. And there was a very simple workaround. Do not run checkup on telephone files from untrusted sources or pull request. But I want to run checkup on untrusted sources.
11:00
This is why I'm doing it. So it's a bit of a mix. So they fixed it and now I feel I'm okay and I can run again checkup. But I was playing with, it was a Lint tool, but you can use it also as a SAS.
11:22
It's a Clojure Lint tool that you can use also as a SAS tool and create different types of rules. And I will expand about it a bit later. But I opened a bug about it that it actually evaluates code. I will show you exactly what it does and how it does it.
11:41
But in the comment I talked with the guy over there and they said, okay, but this is how the scanner works. And we have nothing to do about it. Maybe add documentation. So I'm looking at telephone. And telephone is actually, it's not a SAS, I know,
12:02
but we do have different SAS scanners like Snyk or TeraScan that do rely on the telephone plan. So one of the recommendations inside CICD environments is before running like Snyk IAC is to create a TF plan.
12:24
And they show here in the documentation, run telephone plan and then telephone show. So we have telephone, telephone has a plan and then apply. And in the apply, it does actually do stuff
12:40
with the environment and executes code, but the plan shouldn't do anything malicious. But then we had Hiroki Soreza is someone I talked with in one of the cloud forums. And he pointed that actually telephone plan can run code.
13:00
It has a, you can create a telephone provider exec and you can run code with it. So if you're running any SAS that is relying on telephone plan and you're doing telephone plan before, as a step before the SAS, then you should know that someone can create a provider
13:22
and you can create even an unofficial provider that will download it from our HTTP server. And execute. So you can see also Alex Cascaso has created a very nice blog about it, but this is out there.
13:41
So a bit of hacking time. And now we are going to coming into the fun stuff. But first I want to have a small disclaimer. I believe in open source. And I think that it makes the world secure and it makes our life easier with open source.
14:01
But we need to use it responsibly because open source is not a full blown commercial tool. It didn't have the use of development and use of lots of clients.
14:21
Maybe it did have lots of clients, but it doesn't have enough resources to always to be on the best security maturity level. And we need to understand this because when we use open source and it's very, I believe in using it, but we need to make sure that we run it
14:41
and we treat it as something that is not fully baked or is not like some are more mature, some are less mature. And we have to know about these areas. And one of the parts of my mission and what I want to do is to make sure that it will be safer and safer
15:05
to use open source in companies and in real life. But for Star Wars, we have to make sure that we are running in a safe environment and that everything is configured and we know how to configure it properly.
15:24
So that's about that. But my experiment. So my experiment is very simple. I looked at different scanners and different scanners I collected through my experience.
15:42
And then I started looking at how they will execute or what can I do with them? And I created different kinds of evil files. What is evil files? I will show you in the experiments now. But I'm adding these evil files to the repo. I'm letting the environment clone the repo
16:04
and I'm assuming the scanner will work in the same working directory as the repo cloned. Now, this is a assumption based on different levels of knowledge in companies. And they saw in lots of places,
16:21
the scanners are running inside the same working directory as the repo and scanning themselves, scanning the repo itself. Then executing the scanner and they want to see what's the outcome, what can I do? So experiment number one, checkup. Before we had the RC on checkup
16:42
and this is why I started looking at it. And I started looking and in the documentation and they saw that checkup is actually running against, you can run it against the directory, against the working directory, the same working directory or the home directory.
17:00
And when you're running it against the directory, it looks for .checkup.yml file to load it as a config file. And this is interesting because it's actually how you need to work with checkup or with other SaaS tools. The SaaS tools assume there are different changes
17:22
and different types of levels of maturity inside the code. And developers are able to skip rules and optimize each repo according to what they want to do. But this means that also if I will take a repo,
17:46
I will scan it and I added the checkup.yml file into the repo, I can say check none. I can give it a check none file.
18:01
And what will happen is that the checkup will pick the configuration up if there's no default, if there's no forced configuration, and it's a big if, but most or lots of places I saw don't have a forced configuration. So it will actually not scan the code.
18:23
It will give you, everything is okay. And this is in a philosophical way, a question, if this is how we should run code, because we are giving the developer
18:41
lots of permission and lots of ability to configure properly what he wants to do. But at the same time, we are giving him the permission to do nothing, to say, just skip it, let's bypass security altogether and just leave me alone.
19:05
This is a good question about how, what as a security team I should do. But let's look at a demo. And here we took TeraGoat. The TeraGoat is a, let's see, we can see it here.
19:22
First thing doesn't work, but we took TeraGoat. TeraGoat is a repo that has lots of problems for checkup. And you can see we have lots of fail checks. And at the end, the echo, this is a very important thing, the return code is one.
19:41
One means there was a problem and if it was in a CI CD environment, it would fail the build. Now I'm echoing again the same thing, but I'm adding the bypass checks into dot checkup YML and running again checkup, nothing.
20:02
Everything is good. There are no errors, no nothing. The error code is zero. Everything is awesome. So this means with a very simple adding of the rule, adding of this file, we bypass the whole scanner configuration.
20:22
So after we saw what we can do with checkup, I looked into different other tools and they are, as I say, they are by definition or not all, but lots of them give you the same configuration, the same ability.
20:40
They have a different configuration file. You can create it and then bypass or create different rules. And we can see here PHP Stan and TFsec and KCS and Bandit and Brakeman and checkup and some group. And I'm sure there are more that I didn't check. We have the different configuration
21:01
and if you put this different configuration and tell them bypass our rules, they will bypass all the rules. And you can see there's so many stars on these scanners. I think it's about like 12, 15. We have 25. We have lots of GitHub stars. Over here, let's say GitHub stars that we are looking at.
21:25
But before we want more, I want to emphasize and talk about the scanner hijacking. So what have we done? We were able to alter the source code in a manner that we were able to manipulate
21:43
and abuse how the scanner works, the scanner behavior itself. So if someone adds a file inside a repo and I'm running it, I'm able to tell him, no, everything is okay, just skip security.
22:03
And sometimes it's good that we can do it. And sometimes we don't know about it and we don't have the proper visibility if someone really did it. I don't look at all the files out there in my 1,000 repos inside my organization and start looking, did someone manipulate and abuse
22:24
and bypass my scanners? Like this is not what I'm doing. And the scanners don't tell you, as someone bypassed me, please check this. So it's a good place to think about and understand what we want to do with this
22:41
for the future. But let's go, this is DefCon, so I'm going into experiment number two. It is much more interesting. So I continue to look inside checkoff and I saw those external checks there. Now there's a directory for custom checks to be loaded.
23:00
I like custom checks because custom checks means code. So looking at the different, what I can do, so again, I created a repo that I can clone it, scan it. It has checkoff YML inside. I load the configuration and inside, I tell it go to external checks
23:21
or inside the directory checks. Now I control the clone, I control the repo. So I created the directory with checks with my init py and then inside, I can create any Python file I want and it will load it. Like one checkoff will scan.
23:41
It will first load my files and execute them. So now not only I'm able to bypass the configuration, I'm actually able to execute code inside the environment that the scanner is running.
24:02
And let's see a demo about this, if we are in demos. So I created here, like I have my pipe dream. It's a, that is waiting for an event. I have a RC file over here and I created a .checkoff YML file with different runnels. Inside the runner, it just creates,
24:21
it calls the L-C-S-H with checkoff. L-C-S-H just sends something to my pipeline. So wget will call, I don't remember. And as you see, the moment I run checkoff, I see a post, I got something from checkoff. I even see it had the pycache, it compiled my files, I saw it did stuff.
24:43
So it's actually pretty cool. Now with this command execution, I can execute, I can access environment variables, I can access different networks. I can, I'm actually running as the scanners themselves. So what's important, experiment number three.
25:03
Now I talked about kibbit before, about Clojure. Clojure is a very interesting language. It's very, very dynamic and very fun. And this is a bit of from the source code of the kibbit. There was a read file and this is how it reads the files themselves,
25:23
the source code. It uses a function called read. Now we have a warning inside the Clojure source code that you should not use Clojure core read or read string, which is weird because every developer,
25:40
junior developer will try to read string and read data from untrusted sources. So this means that the question is why? Like you may be asking, why is this warning? What read actually does is reads Clojure code
26:01
and evaluates it. And then Clojure, we have something called like a self-evaluating form. And I will get to it in the later slide, but this is kibbit. Kibbit is a static code analyzer. We, it takes some code and when you run it, you run it with line usually.
26:23
It's line is like the NPM of Clojure and you want it with line and it tells you, okay, this is a problem. We'll consider using one instead of if. But then if you use a self-evaluating form,
26:40
that's hashtag equals something, this will actually run if you run it through a read the function. So I created again, I load different libraries because Clojure is very dynamic. I can load in everything I want. And I did a print line to a shell
27:00
to run again the same house C kibbit and then shut down agents just to exit nicely. So I run it line kibbit running code and then I see the exit code exit one and I run out success, I'm able to run my code. Experiment number four, we see we have pre-processing.
27:24
So Robocop for instance, has a configuration file that is very cool and very dynamic and so dynamic when it sees ERB templating, it executes it.
27:42
So, and I saw in the documentation, yeah, let's do get status. So I just did run RC Robocop exit, it worked. So the moment I load Robocop, it looks for .Robocop YML, executes my codes and exit.
28:04
Great success. Experiment number five. And this is a bit different than the others because I didn't find in PMD anyway to have a configuration file, but it looks for so much environment variables.
28:21
And one of the environment variables is the Java ops. So you can tell it what options to give Java when running PMD. So I told them use jar, use my jar instead of your jar. And I just, you can run an evil jar and twogs
28:41
and you can load another jar. But the question is, how can I tell it the environment variable? So in some CI environments or in some areas, I know like even in all my ZSH, you can create a plugin that if you see a .env file, load it automatically.
29:02
And so if I also submit a .env file, sometimes it will load the environment variables before running the scanner. So it's a good way to do stuff. I played with it, some did.
29:25
Some areas I was able to put a .env file and loaded the different environment variables and they executed my code. So if I'm concluding and I have much more scanners in the pipeline to check and I have different areas,
29:42
but this is a bit about the stuff that I talked about. We have Chekhov through the configuration file. Chekhov, create, restart and Robocop through the configuration file. We have Kibbit through code. I can create code that will execute. I have PMD and CDN and depth scan.
30:01
I didn't talk about them, but same thing with environment variables. And they have more every time someone shows me now a staticizer, I'm checking, can I, what's the configuration file? Does it have some kind of a loading of the rules and more and more, every day I'm finding more and more.
30:28
So what Wikipedia says is correct. It doesn't actually execute the program over the static program, but it does execute programs.
30:43
So I am able to execute programs through different, we can call it side channels from the configuration or from other methods of the scanners themselves to be dynamic, but except Kibbit that does execute programs.
31:00
So anomaly, but all the others are really through the ecosystem, the framework that we are using. So I'm saying like in your code will probably be able to execute other programs. And this is something that we need to understand
31:21
and know and live with. So the big question is what is the impact? If I'm looking at the impact and I'm trying to look at what it can do to my environment,
31:44
then I need to understand first where I'm running it. So I can run static analysis in developer machines usually except if someone will do a git clone from untrusted sources and just load it into his idea
32:01
or some other areas and the security team automatically analyzes it or he decides to analyze it. This is a risk. We have security researchers. If I want to scan untrusted code, how do I do it? Because SAST may execute code and I don't want to execute the code on my computer.
32:24
But my environment and what I am researching mainly in the last couple of months is the CI CD. So inside the CI CD, how does it work? First of all, developers commit
32:42
and push to development branches. When you commit and push, lots of systems do CI checks on every push and they do it in their internal cloud or in Jenkins or in other CI environments, but they run different types of testing
33:03
and security testing on the code so we make sure that no code will be inserted into production but maybe we can attack these systems themselves. The next place is the pull request. We have on every pull request and this is the request
33:24
I want to merge this code into production. We are doing lots of checks and lots of checks usually are also done against the production environment or against staging environments that have real credentials into areas.
33:41
And lastly, we have merge into production. So the merge into production, we can merge from people that by mistake or by intention push directly into the master branch and through the pull request. But the same, we have to have the CI checks and then we need CD deployments to deploy them.
34:03
Now this gets tricky because sometimes companies forget to separate between the checks and the deployments or give too much permissions to the checks. The implications over here. First of all, I can extract sensitive data.
34:20
We had different attacks in the last couple of months that running code inside our CI CD environment extracted sensitive data and like environment variables and different AWS keys and different even code and send them back home. If you have access to the internet, it's problematic.
34:43
You can bypass protections. Let's say we don't even have command execution but we do have the configuration bypass. We can create like a policy to bypass the code to say skip security.
35:05
I don't need them. I don't want them. They're just making it harder for me to deploy into production. We can infiltrate the network. We can go into use this as a stepping stone inside the network itself.
35:22
Lots of red teams I've done. I played with from one place inside the internal network. You can start end mapping. You can start going out as an MP. You can do lots of stuff into other areas. Maybe it's connected.
35:41
And the last but most important, maybe you can deploy assets to production. You can skip the CI checks. You can force deployment through the CI. And this is problematic.
36:02
Assume code will execute. This is my assumptions. And we need to put around this code as much guards and lasers and boxes and sandboxes and different areas we can. That eventually someone will find a way to execute code.
36:23
If it's from a very small open source SAS tool to a very large commercial SAS tool or some other things. Let's say code coverage tools.
36:41
I don't know. Someone can hack a code coverage tool. It can be awesome. We can, we assume the code will execute. And if the code executes, we need to be prepared to make sure that nobody, that it can't do nothing. And we know about it.
37:05
A bit about before I showed the workflow, the CI CD workflow, but in this attack flow, I can add code execution to a scanner configuration file. We can push new commits into the branch
37:21
and then create a PR request. This is every user inside the organization can do it. Sometimes we can do it from the outside, even let's say in GitHub from folk. Actually GitHub fixed this problem or I don't know,
37:40
fixed, but made it much harder because now today, new committers don't execute the workflow automatically. And this is, lots of attacks I've tried, got stopped in this area, but other areas are less mature and do execute code.
38:03
If you push it to a branch or to a PR. But then one repo will be scanned by a scanner and the PR it will execute. And this execution has access to our network. And sometimes also it's the same network
38:22
and same environment variables that the deployments and the CD deployments have. We can also just skip the whole check and tell the scanner all is good, continue on into production, and even that we introduce very bad code practices,
38:41
back doors or whatever you want. A bit about high level possible resolutions. I don't want to go into much here, so we'll just print screen this. But a bit, the network protect it, deny filters, deny access to the outside,
39:02
isolate only what you need inside the host, the same, create containers and pods and run everything in the least permissions. And then verify everything is deleted. Sometimes if you have a pod that is running for 10 hours, maybe it's a crypto mining.
39:22
Maybe it's just stealing all your data. Monitor everything, just monitor everything that you can do and then look for malicious activity. We need to understand the risks on running unverified code inside our laptop and then inside our CI CD environments. We need to educate ourselves, educate the organization,
39:44
educate our DevOps and what's the best and how to do it properly. Do red teams on the CI CD. We want to verify the tools we are running are good, but we don't have enough resources to do it. So we need to create a framework
40:02
to check that how we can ensure that the execution is running in the most secure way. Just ensure that your scanners aren't doing any malicious stuff.
40:20
Try to stick to SAST, to static and deny any execution possible. If you can make sure configuration is really picked up by your configuration, hard code the configuration. Lots of tools have option to hard code the configuration to something specific.
40:42
So it won't pick up the default configuration files. Also environment variables, unset them if you don't need them and the list goes on and on. I think that security needs are getting bigger and bigger every day. It's not only, I think I see it.
41:01
And we are going into massive automation. We're going into DevOps, deploying different production features every minutes, seconds even. And we have to be proactive and understand the next generation of attackers
41:22
and how they will abuse our infrastructure, our automations, how they will attack us from side channels, from internally, just abusing all our automation that we are doing
41:44
in order to make our lives easier and secure. It's also, I don't study code analysis tools. It's not only security, it's also linters. It's also code coverage, it's testing frameworks. We have much more automations coming on.
42:01
We need to deeper dive and understand the different SaaS scanners. We want to analyze wrappers. Let's say we have GitHub actions. I didn't talk about it over here, but different GitHub actions or wrapping all, or all wrapping all the scanners
42:21
and creating it more difficult to add configuration files, to add to, it's more difficult to check if there is a configuration file or to run it securely. We need to analyze them.
42:41
We need to create a standard for security working with code analysis tools of any kind. Like I would want a standard not only for the output, like Sarif did, also for the input of how am I running security code tools? Maybe do a SaaS for executing security tools.
43:05
I don't know, it's a bit meta, but we have much more to do. So first of all, I want to thank you guys for coming to my presentation. And I want to thank all the open source developers out there
43:20
for creating the awesome tools they are developing to tons of work. And we have millions, thousands of companies working with these tools and you're helping them in so much ways. I created a bit of a POC about what I talked about,
43:42
CI-CD lab. You can check it out over here. This POC is running is one scanned with different scan tools. It's trying to execute them. You can just pick it up, try to use it. Don't attack nobody. Just do it for research purposes
44:01
and start to understand how can you run it better? I started creating a community. I called it security tools Defcon. This link code goes to a Slack. And I want to start connecting between all the open source developers out there
44:22
and I don't know, anyone else that wants to join and start thinking about how can we standardize our tools? How can we create better documentation and better ways to make sure that when people are running our tools,
44:42
they are doing it in the most secure way. So I want to raise awareness about this and you can ping me up on the Twitter. You can ping me up in the Slack. I will be in Defcon.
45:00
I will be going around. Just send me a message. Hey, let's meet. I have an idea. I want to talk. I will be happy to talk with you and have a beer, go to a party. I don't know. Just hang around. So thanks again and we'll see you at Defcon.