A Shock to the System: Static Analysis for Real AppSec

um anyways so um we have oshan marshall here for session number four um he's a developer and security consultant for secure ideas um oshan is an application uh security consultant and as his result in his roles at secure ends he works on ongoing development projects utilizing amazon web services and breaks other people's web applications when he is not swallowing gallons of the devops kool-aid he can be found blasting j cool cole while hacking blogging and coding he covers everything he does with the signature phrase i code i teach ihack so without further ado oh sean marshall

thank you thank you for that lovely introduction all right a shocks of the system stack analysis for real apsec so um this is the part of the talk where i am supposed to spend like an hour on this slide after the speaker already introduced me but no um what i talk about in this talk is actually comes from a place of trying to eat my own dog food and what i mean is is that whatever whatever madness that i prescribe as an application security consultant to the client is things that i actually have to implement next week when i'm actually on a sprint cycle so between doing each of those things i hope by spreading the message

adds that teaching element as well we're going to cover three things tools techniques people this is not the traditional use of ttp and that is on purpose because the human element at least deserves 33 percent of the talk and is where the security starts it's where the security happens and where the security ends so you ignore the people element to do your peril however i do realize that this is my this is a support group for security nerds like myself so i have to do to i have to do tools and techniques i have to do two demos with that all right static analysis this is the definition for those who are uninitiated the whole point here is that we're

trying to examine the source code without any execution we're out running it this is not a full-on pen test however tools and insights that we get from sac analysis can feed into a pen test and in fact cv you can pop cves by doing a full white box assessment with the stack one analyst going through sac analysis and then another consultant working on the actual pen test portion but there are many things that can lie to you that remember this whole recurring theme of trust but verify but the code can not also this is new because although some of you are like we've been at this oh sean we've been at this it's a whole bunch of alerts we've got

to sift through them and all of that here's the difference now we've got infrastructure as code you know all that inventory that we as security professionals have been trying to get people to do for ages they have it now you don't want like mind blown this is awesome and it's parcelable it's not in a spreadsheet screw your spreadsheet okay it's json yaml it's machine readable you've got an inventory of all the infrastructure along with the configurations listed in there and so with all of these pieces you can sort of rewrite the story of what a traditional static analysis engagement is and so the traditional story is you know we come in our support group um

we commiserate with uh internal security team and the cso we gotta uh we got plot against the devs right um we don't do that but that's the culture on the other side and so we do our best work we dive in we make some recommendations we make some recommendations however that produces a pdf that then has to be transliterated from the security people into actual way that the development team can understand there is a better way and i'm hoping by the end of the talk that you have the breadcrumbs to lead to how we can change that story now we're going on to tools tool talk tool talk to talk pick a scanner and a

scanner the first instinct may be all right stack analysis we're going to grab every tool on the market let's see what our budget blow it up i don't know about you but some people's security budget have been slashed because of covet right i can't raise my hand because i work for a security company but some of you who work in internal teams kovit has done a number of the security budget so when we're trying to return to normalcy it would be really nice if we could spin up things that are free right that don't and free as in free but don't cost me like weeks and weeks to configure and provision and get it actually working so

here we need to build tooling around need but first before we even reach at the tools you got to ask some basic questions do you know what language some of these applications you're trying to protect are written in are you aware of the tech stack that surrounds it also it's essential to keep the tooling at a minimum reduce it minimalism is wonderful wonderful thing it's a noise reduction so that when the alarms go off they're focused on the things that are actual real issues if you've got devs having to go through dozens upon dozens upon dozens of false alarms then they sort of numb out and if they're a whole bunch of alarms someone could be wrong it could be the dev team

it could be the way that the tool is configured so the stack analysis is not the cure-all of course but it is a good conversation starter now i'm going to say something manual dependency checking is an absolute waste of your time and money let me put the numbers behind that as the security consultant if i'm doing a pen test for you that's 300 an hour that that price is on our website it's public we think we're competitive in this market but that's the price and we normally take a week for a full on test for a web app if that pen test is the first time you figure out you're running things like jquery 1.0

or 2.x and those libraries that have been deprecated for months if not years then it's a waste of your time and money because you could have detected that for free we will write it on the report don't get me wrong we will because it depending on how far you're behind the whole patcher systems patcher system statue system depending on how far you're behind that does increase risk it harms your security posture as it will but it should not be the first time we have that conversation and so if you're especially since i'm a node developer i'll give you a no developer solution especially if you're a node developer if you're not using yarn audit or npm audit

what are you doing now we go into the demo brief demo is to cover the workflow um from a security practitioner's point of view so if you're a consultant on the job or you're maybe an appsec engineer or internal on the offensive side and you're or even an architect or hopefully an architect or a dev running a static analysis you would want the t you don't want to waste time like provisioning the tools so you'll stand up a vm and this time we use in internally we use vagrant um kudos to my co-worker alex rodriguez who helps who definitely push this project along and showed me how to work some things and ansible so here is

and of course it's going to be pre-recorded don't be disappointed don't be disappointed because if it i've timed it it may take seven minutes for me to do that's really fast however seven minutes behind the podium is agony so we're just gonna jump back and we're going to fast forward the bits where i can't type

of course it's on the other screen and just because it's recorded does not mean the demo gods will not screw me over

[Music]

are you kidding me all right

behold the man behind the curtain all right and let's make this as big as humanly possible and skip my notes so it's available publicly at saginaw static analysis ttp repo um just clone the repository and we're going to start in with a simple cd into the directory now this is again parts where i'm trying to forget the type we're going to vim into the we're going to just vim uh an over complicated text editor just to hop into the vague top into the vagrant file and make some modifications one thing that you will have to do for your machine is point it to which folder you want to share between the vagrant box and the host

so zoom past fast forward fast forward and right here i've got a folder demo where i've cloned some vulnerable code from github a very hard very time consuming and difficult thing to do prob most likely um and just we're going to be running sonar cube is just one of the tools that comes proof that can come provisioned with this vagrant box so vagrant up and we spit and we spin and we fast forward a bit just to spin up through the provisioning and all this is is automating a c uh setup with a vm so instead of downloading the iso with getting it in virtualbox trying to trying to provision through the settings trying to get your networking stack to

work this stuff is automated all of that stuff is automated because you shouldn't be wasting time with your setup now there are multiple tools that are pre-provisioned here it will be s i dash like bandit mob sf all of those other tools that were in the previous slide [Music] this case we're doing a provision with sonarcube and to catch up on time password a bit and with the provisioning we're done so we're going to create and here we're going to just run the script to create uh ansible playbook to create that instance where we're going to we'll be running sonar cube ah this i'm trying those last two lines are going to be critical those last two lines i'm trying to get

i'm trying to get at anyway click and drag sign in of course whatever password this is running locally but sure

and then we just walk through our traditional setting up a sonarqube project so get the token this case we're in this case we're running it on a python app that we just found copy paste that copy paste that back into the terminal and this actually all the networking is already set up so i think for this first sonar cube in general these are the port 8000 or port 9000 it's open to the local host so from your host machine or whatever web browser you can access these so access these tools and the wonderful beautiful thing about having a vm is that after the engagement after the exercise you can actually export you can actually keep the vm as evidence

so here we've discovered high level finding in this case this was a plain text password already already thrown in i know it's absolutely tiny but there is there it is so right off the bat in what seems like minutes we can spin up and run at the and we could spin up run a vm and just do some analysis and of course there are other tools like bandit for for python we also do shell i'll check why well you're not going to find any security findings out of a tool like shell tech but how many of you are familiar with a project that all right there's a whole bunch of code but at the end of the day

like 20 percent of it is scripted together bash is just bash scripts to do things that the developers should have been doing in the first place i know i have so let me push it back [Music]

fast forward so that's the demo now we go to detecting with technique this is here this is really important for continually integrating sac analysis in the software development life cycle as we call it um you really need to have engineers look at the code for your organization is functionally blind without it now if you're dealing with security people with consultants we have a list of things in our head when we're doing a web app test i know i can tell when my networking colleagues are on the test because it's just like all right we gotta go back into the checklist check for this that and the other with an engineer with someone who's writing code and

working in software that's that if you train them appropriately that flaw is something that pops out it's a design flaw that's what it is it's not a security problem it is a design flaw so if you're internal if you have an internal security team or if you're a consultancy please please only assign the static analysis job to someone who has written production code within the past decade so their knowledge stays relevant on there find someone if you don't have someone like that on staff find someone people who write software are going to find the flaws that general security practitioners can miss and the devs have to be the ones to do the remediation anyway if it's a

any vulnerabilities found is a bug and should go through the pipe and should go through the pipeline in order to be pushed out next is automation so there's this wonderful xkcd that i love and describes how i'm probably going to be spending next saturday night do not put waste time automating to ask unless you know the steps of what you're doing you bring the tool in to automate the task once you know rough idea what you're trying to do cloud formation for example we're using some you use something like cloud formation when you already know what infrastructure you need to set for for what infrastructure you're going to set for a project and the configurations for that the

different settings that you would manually go on the console or waste hours of waste weeks and months of time trying to script around

so the best way to do automation for he for scariest part is to incorporate some of the static analysis some of the dependency checking bit into the pipeline and we also got to think and this is four-step methodology but think of static analysis engagements like a pen test there is some recon that can be done hey you have the source code in front of you is it public when it shouldn't be are there github are there keys that are that have been committed to a public github repo are there aws keys that have been dropped simple things for reconnaissance most of your time is going to be spent in application mapping for sac analysis engagement because

finding out how this works is about fifty percent of the job vulnerability discovery is instant once you scan it you once you scan it awesome the exploitation phase if you're in white in your white box engagement that will take more time but for static analysis that fourth step is then verifying all right is this something because i guarantee you if you get the tool and you see a concatenated string sql string and you're like all right it's equal i sqli sqli however if you waste hours of time on harping that horn thinking because you of what you think and what you've seen the tool you will miss the fact that in the context of this application all of the

parameters were hard coded in the code base so it wasn't like a request so what seemed like sqli what seems like sql injection concatenated strings wasn't because hey every one of those parameters were hard coded from the configuration files so it's not like incoming requests from the user can mess with that but if you don't have that context and you just go if you just go with the alert on the tool you're you would be wasting time and energy so this demo is shorter and if this doesn't work that's fine

because it's only about 18 seconds

so this is from and we're i'm developers so internal dev i'm doing this pipeline from for an internal app and the pipeline is stopped why well let's dive in and hop into the logs this is aws pipeline and so we're going through we're going through the logs we're digging through the reason why the pipeline stopped and execution ended is because i don't know about you but um my boss does not let me ship code with high vulnerabilities in the dependents in the dependency chain so some of the some of these packages were vulnerable to cross-site scripting and maybe things are different for your environment maybe you have to set up a soft alert and configure it that way

but where i'm from and some of my client and some of the clients that i work with are under the same impression if it's high vulnerabilities in a node package you would just stop you would just stop the build on that and that's something where that needs to be fixed now patching that can be simpler patching that can be simple it can be easy with npm audit fix and it could also be simple as just upping the version number upping the version number so long as they're not breaking changes and i say that knowing that there are plenty of instances and plenty of instances within javascript or landscape especially the node landscape in which breaking changes

occur

so but this is important this is probably the most important slide more important than the demo is because i have to show you some success message from this pipeline because that i need to actually show that you that works um it's not enough to just ha not enough to have the guardrail of all right blocking it make sure that it stays functional and it it's easy to turn in and fix for patching updates so when things are doing well of course the pipelines work smoothly and we can configure the audit so you saw a bunch of high vol you saw high mediums and lows in that output demo that i did but you can also just set

yarn audit to only stop on high vulnerabilities in short that way so you're not just raising the alarm flags or throwing an error message in every pipeline but you also now that we're bringing it back to cloud formation templates now that you now that uh you've got infrastructure as code as part of the pipeline part of your pipeline may be standing up in additional infrastructure in aws so cflint is your friend not only does it alert you to some vulnerabilities but it's also the friend of the as a devops person because cflint actually gives me some syntax checking on this mile long configuration file and if i don't check it at least twice before i push

imagine back in the days when this is the best thing i can imagine is back in the days where you had to wait hours upon hours for compiling it feels like ages of every minute change pushing if you push it to aws all right it'll take a it'll take a minute it'll take a minute then it'll crash on whatever issue that you have and then it will take the next five to six minutes either rolling back all of the infrastructure or deleting all the resources that that change was supposed to make and so tools like cf lint serves two purposes it helps us as security practitioner find issues with the infrastructure in addition with the infrastructure and

for the devs it makes their life easier when they have to manually work with cloud formation templates there's also another tool called cfnag and some of these and that tool is also another cli tool these are some of the alerts things that uh pop up often are logging and monitoring logging and monitoring is your infrastructure tied into a cloud watch trail cloud watch or a cloud trail this is especially useful for serverless applications where you've got dozens of endpoints using more and those endpoints have different i am roles that reach even dozens more services so if there is no logging done for like for some simple request made to the back end then you have no visibility in there and you

cannot tell if you're being attacked or if it's just common usage and finally we're bringing it to a vision for you and this is the [Music] in the people portion of the talk so when you're starting these engagements you need to ask some basic questions what is this app supposed to do what are the standard use cases what are the standard use cases what needs to be protected if you ask these questions and you're willingly genuinely curious about the answers you can better inform how you're going to protect it because if this is an admin tool and only admin and the only role is admin and only admins log into it of course the base user case is going to be a

little more privileged than an e-commerce site next thing is to focus on collaboration with or over compliance so you will get compliant you will get compliance if you're genuinely collaborative it's better it's even better that way because i don't bring up static analysis to raise some holy war into your organization i bring static analysis and we bring stack analysis back into it to begin as a starting point to say okay how best can we protect this how best can we protect this app and that's another question that's really important what needs to be protected and i don't care what kind of shop you have if it's a devops shop or a place where dev and ops are in in

different teams that spirit of collaboration can be found both for some of you may not understand what's on the screen that's two equal signs in javascript they're both truthy values so there are more than one ways to be successful and you don't have to have devs doing all of the infrastructure at the same time but um even if those are distinct camps as long as they're collaborating together uh you get the function and you me some of you who are brand new to can i get the hand count for this is your first b size okay you did not catch my last talk um i hate the term devsecops it is a buzzword and it is only a word that people and

our support group use okay um but that is a whole different talk that is last year we'll keep moving on we'll keep moving on so security of course is in the middle is is in this but it doesn't need its own special highlight spot in the middle in the center of things because function creating functional code and maintaining availability which is what ops is that is that security is if you don't detect how security is interwoven in that uh you just gtfo at this point because that is the essential those are essential parts of it and now we and i'm pretty sure steve with the security champions talk at the end we'll go more into this

but we need a new type of security champion as we're bringing back into this new theme of you know returning to normal returning into post plague you know um and what you what we need we need to define what that hero is and one i guarantee you one of the definitions is not marvel universe dc comics saving the blockbuster every summer where we're saving the world that is not a security champion syria champions are more like static shock sat as saturday morning wb a cartoon i loved it loved it growing up um it's not because it's let's be honest it's a cosplay option for me right now um and it's not because it's not because just because of

uh the background of the young man um who's just trying to do the best he's trying to produce good in the world um who's also lost out lost his mother even though that i didn't know that how i didn't know at the time when i was kid how painfully uh important that element would resonate with me could not have predicted that the reason why security champions should be more like static shock is because the first thing that this pro this pro for young professional as we will call him the first thing he does when he comes to power and gets the skill sets is he goes to make his local community better and i think that sort of resonates with

besides rdu do you agree do you agree so that's where we need to start in that returning to normal um and some of you will look at the slides and it is seriously it says when we get my dude so now that we're using the tools to actually remove waste remove clutter now that we're changing up our technique and how we work with static analysis not blindly accepting the scanner in order to actually and actually analyze what we have to hear in applications and associating them with existing with existing security practices like pen tests and we're also in the spirit of collaboration what does that look like when it's all pieced together as the application security program

matures and it looks like this it's it looks like not only in the kickoff call do we have the usual oh we have the cso or we have offensive security engineers we've got analysts we also have people from the dev team in early stages there's a project manager an architect that doesn't write code anymore all is all his time spent is in meetings but soon it becomes actual technical decision makers come to the table and then in the end and as we go through the engagement it goes smoothly because we can point out some things and at the end of the engagement after here's the critical part you go through all of the findings and verify that there are

indeed findings then instead of just a pdf report that ages like milk why not just create the github issues or jira tickets or actually be part actually have that ingrained into the process to the point where okay just like your qa team found this for this quarterly this major big quarterly or or weekly release all right these are some issues these are some security issues that are also added to the backlog that need to be prioritized into the sprint planning phase and so it's not just one report at the end of it but it is a actual collaborative journey

and that's the story i want to that's the story that's a return to normal story that i'm looking for and i hope that sort of resonates with you as well stack analysis shock to your system [Applause] you