Hey everybody, welcome back to salted hash. I'm your host Steve Reagan
And today we're joined by the CEO and co-founder of T cell Michael fire tag
We're gonna talk about app SEC and we'll be right back stay tuned
Welcome back Michael. How are you? Thank you for joining me
Great. Thanks for having so
Application security. It's a thing you hear about all the time, but a lot of people seem to
Really?
Fail to grasp how significant these issues are in the world. We live in today, especially since
everything is an application one way or another and
Here recently, you put out a report talking about some web applications and attack highlights
And I wanted to go over that a little bit today
And the first thing that stood out to me in this report actually isn't like a type of attack or anything
It's it's the delay and getting said vulnerability it's fixed and it says here it was 38 days no matter the severity of the vulnerability
That seems really low compared to what it was a few years ago
It's that the case or is it is there improvement here? Am I reading this wrong? No, you're absolutely right
It's actually it's it sounds bad
Right. It's like eating
Hey, we found that your application is vulnerable to something horrible and it takes more than a month to fix that
but the reality is that
If we did the same when we did do the same report a year ago
It was more like two or three months
and so what we're finding is that
generally application security
meaning how to protect a web app API service when running in a production environment how to make sure that
You're not going to get back through the kind of biggest
Openings that you got which is that the application layer
It's getting a lot more focus from security teams, which is great and there we are making progress
I'll also caution that one thing, you know
We've talked about internally is that we the numbers that we've got
May be a bit skewed frankly in that
We collect it through our tool which also surfaces the information to our customers. And so one thing that we've often found
is that when we first show up in an environment that
List of open vulnerabilities that are on that application that is running in corruption out
That could be it tends to be quite long and things didn't you sit have set around for quite a time?
Once we're in place for a while, then there's kind of a more of a workflow for addressing them. Still taking much too long
But but but sped up so it'll be interesting to see how you know, how things
Progress as tools like this get more widely adopted. I think generally as the
team's focus on
These types of issues generally and start prior to us and getting them addressed
So bridging off that going into shared libraries and code resources where vulnerabilities were found and you're seeing them used in production environments
Has everybody any change on that in the last couple of years because I want to say it was like maybe 2012 somebody had
Brought up a report. I remember the vendor but the point was
using shared libraries that have vulnerabilities in your production stack
It's leading to all kinds of problems and nobody's patching on them or you're not updating your libraries
What are you seeing with that in regards to the field right now?
It's an improving or it's it's still just as bad as it was a few years ago
Well, it's not bad to be using third-party libraries have been a lot of ways. I mean vulnerable third-party libraries. Sure. Sure
well, I mean
so what will happen is I mean
The flow is you're gonna have to build your software on someone else's software and you should right
I mean like the worst thing you can ever find is someone built their own like SSL stack, right?
That's like roll your own encryption. Yeah
Exactly, like using third party stuff is is a good thing
The reality is every third party thing that you use
They'll be vulnerabilities in it whether you know about it today or they'll be discovered. So that's gonna happen
what's
it what's getting more and more awareness and
I think teams are getting better and better at but are nowhere near where they need to be is
actually
Having a defined process for tracking what vulnerabilities they actually have
Determining whether they're directly relevant to them and making sure that they're being addressed
quickly and addressing them can mean it could be as simple as I gotta patch that library and
That's easy for me to do because it's just some, you know dot release and Sakai changing a thing
to
Okay, I'm using this library and you know practical matter is sometimes it's a major project to upgrade it to the thing
That isn't vulnerable or the thing or there isn't a version that isn't vulnerable. So do I have other remediation?
paths
available to me to to be protected other than simply trying to obtain all my software which it you know, if you're built on
so as an example and it will say that most applications will have
Hundreds some will have thousands of third-party libraries that they're built on top of you
Saying that you're gonna that's great every one of them as soon as any one of them is released is not new
No, not a little it's just not. Yeah exactly. So security folks
We need to be practical in how we approach these things and particularly how we work with our peers and operations develop that to address
it so that's up and to and to have
procedures and tools in place so that
We know what to do if the answer and the legitimate answer from a development team is I can't patch this today
I need we need a whole project around that. Okay, what are you gonna do and that that's what people are getting more sophisticated with
So let's let's uh, keep going forward down this chain here and talk about the actual vulnerabilities themselves
I'm looking at the report and I noticed there's a
difference between what a wasp says their top
Vulnerabilities are and what you've discovered and I guess my first question is is why is there a difference are you looking at actual attacks?
In the wild where your customers were sampled or are you looking at something different on this? Yeah, I think there's
It's a good question
The the principle difference that we think that we're seeing is that we are watching an in a much more
controlled way attacks in the wild
versus
more
kind of survey
Responses from from large groups so you get a little less opinion with our data
You get a lot more, you know kind of controlled statistics
There's value in fold
right because
It's so you know for incident I would I we used a lot of top ten in our minds is how to how to start
something I think it's a great thing, but they think this is just another view into the world where if you say it cut across
several dozen
large-scale production applications and you simply measure
how are people being attacked and
Separately measure, where are the actual breaches coming from in other words? So it's a difference between how am I getting attacked?
and where is the actual breach, you know meaning vulnerabilities found or you know, or
Other form of breach if you're actually measuring those two things
What do you see in a more controlled environment that and that's what this is? It's a 60-day slice of time
All right, so it's kind of narrow
But it's a and it doesn't have the kind of qualitative
Aspect that OS reports can have because those are you know people reporting and saying this was horrible for me
Versus to simply measure, you know attack happen
But it is definitely useful. So I mean what we find is look like in the last, you know
Or at least in the you know
60 days in q2 that we measure like cross-site scripting was like all over the place and just generally browser targeted attacks
We're incredibly prevalent we found that
Almost all attacks. Well are
automated and
More than half the applications that we would look at are actually attacked
So this is just kind of interesting data points and you can see there. You know, we're also to kind of the drivers behind it
There that you know bad guys have figured out they can make money through crypto mining on your browser
If they can get your browser to run their code for you
So that's starting to take off and and they're hitting everyone's websites and doing browser extension all kind of terrible things
To to make this happen in the background. So there's a sort of drivers behind that whatever Sam
So the Verizon reports over the last couple years have talked about how web application attacks are the thing. That's what everybody's saying
Akamai recently said that web attacks have gone up ten percent over the last year and I look at
The findings you have it. They're here in the support and I see SQL injection
Something that is what twenty twenty-five years old now
I mean, it's it's like way older than my kids and I'm just why why is this still a problem? What is it?
What is it about SQL injection that we can't seem to get rid of it?
It's a that's a great question
There's two sides of this actually
With that Matt Kirk is is how many attack attempts happen?
It doesn't tell you how many sequel injections actually went through and actually we didn't see very many
Successful sequel injection attacks over that period that's worth trying it. Well, we all saw is that automation
So what we're what we're really seeing is
That if you're on the Internet
someone's gonna start hitting you and they're gonna start off with
Automated scans that will try everything and sequel will be the first thing that they'll they'll try doesn't mean it's gonna work
But it's gonna be the first thing that that they try
So a lot of ways, that's an indicator find someone who's attacking you
It doesn't necessarily tell you that they're actually breaching the application now, sometimes they will and when you know, you get a sequel injection
It's it's a disaster we see
successful breaches
much more commonly with
Command injection, which is utterly disastrous
cross-site scripting
Stolen credentials to kind of attack or session hijacking clickjacking. Those are the ones that seem to actually go through
but in terms of volume volume
We'll see things like sequel injection because it basically it's something where a bot
It's very easy to get a bot just slamming with lots of different attempts and that's what we're saying there
So for the old folk watching this like me and you mentioned command injection know you talked about command injection where I altered the URI
And and make the server do what I want very different type of command
no, he said it's that it's you know, it well could be I mean, they they've gone in quite sophisticated and how
But the what is somehow?
application to run some crazy shell command that it shouldn't and this company and those are real like
I mean the whenever always talk about is a course Equifax and like that. That is the
Entry point is you know a vulnerability in a third-party library stressed to that hadn't been patched
was you could send a
carefully crafted payload
Wasn't as simple as you know, doesn't you arrive and very carefully crafted payload that would trigger it to
execute
You know OS commands
Oh actually gel and so forth and from there you own the system and do anything you want and that that's basically it
the big danger and that's and
because of the impact of that that we think that's probably why we see so many attempts at that and
When we see breaches like man, it's you know, it's obviously disasters so later down in the report
And I know I keep hammering the port but it really is this was interesting reading for me
So I just wanted to talk about it
this is the first time I've ever actually seen Python listed as a
Type of a target platform and what's most commonly used against it? So I'm curious when you were looking at Python itself
What were the the SQL injections looking like when it came across the wire? Oh, the reason we break out the
report by
Platform type is because if we find that there are specific
vulnerabilities that
each platform may expose and hackers are aware of so the you know,
there's always gonna be this baseline of just like I'm gonna throw my tool at your stuff and it's gonna
Do like you know something called a drop table and you know, hope for the best
but what we also see is that
Hackers will probe a site and you can fairly quickly
Determine the basic architecture as a back-end of an application in most cases. So if it's a
Python based app you'll figure out that it's written, you know in Django for example
You can ever figure out if there's a node app if it's Java is it running spring?
Or is it running struts? For example, and once you figure something like that out, you can do that through
you know names of cookies your realm at urns there's lots of different techniques you can use just kind of guess at
language and platform
Once you have that you can be much more targeted in
The injection prickly injection attacks that you might try and that could that would apply to sequel injection
Knowing what oom they're using you can take you can then look for the book
You know the vulnerabilities that were known in that thing or just generally how does it translate?
And generate queries and see if you can find functionality that is likely to take on escape
You know content and dump it into a query or you know that or what?
Devised subsystem could actually shell out and can we try to get that going? So what we do find is that?
Bad guys are smarter about their attacks
after they do a little bit of reconnaissance and know your basic architecture and you can and if you think of this as a
Valium game right, which it is, right so that will find that
Roughly speaking
It'll take a hundred thousand
attack attempts meaning bad request into a system
to find
Any kind of vulnerability just you know, roughly speaking. So hundred thousand cross-site scripting attempts to find
The hole in dead where you can get a script to pop and the browser a hundred thousand or more
requests tuned to actually then get to a OS command that that or uh, you know
A local file include or any of those things. So if you think of that ratio
Be that's a lot. It means you have automation you have botnet and then that's giving you know
Protecting tools like a t-cell the ability to identify that attacker
before they actually
Breach the app right by amplifying if I'm looking for one bad request gonna have to be perfect. That's that's tough. But if I
Have to look for a hundred if I have to you have ninety thousand before you know
They were likely to find the hole then the advantage is on my side
and so what we're also finds and the attackers are trying to get smarter about it to say if I know your
Architecture. I know you're on you know, I know you're on Python. I know that
You're using you know, devise or something like that as an office or whatever it it
Whatever is the framework got figured out just through a little bit of telemetry
Then I can take my script which was going to shotgun a hundred thousand things
and I can try to snipe it down to twenty thousand then it's going to start a ship the
Probabilities in our favor and then the defending tools have to take that into account. So that's definitely what we're seeing makes sense
So the wrap things up
One of the high points of the report
It's the fact that companies need to have better visibility into their environment and what's going on with the applications
but if you had to give some basic
Here's where you start. This is where you can put your your best foot on the right path
What do you what do you want to say to business leaders looking to improve their app program and make it more secure?
yeah, so
the first step to
protecting an application is
getting metric based knowledge of the risks that you have and
What types of attacks are subject to so the problem is that?
Very often insecurity generally and definitely an application security. It's this
Incredibly broad very big thing that security teams then, you know say okay
Well, we need to protect the incent, you know for application security
So we're going to you know
Get tools and add processes and you get an enormous amount of resistance
From your peers and operations and develop in in it's difficult because you're asking for something huge
Often disruptive and you're not quantifying why?
If you can start off with a program to quantify
What risks might have the application what libraries am I loading in? Are they actually vulnerable what API is exposing the outside world?
Am I under - do people actually attack me and in what way?
if you can take that and
Then you can start to focus. What is the right?
what is the approach to reducing that rest of closing holes to identifying and
Blocking attackers to having in you can have a much more metric driven discussion about where to spend your resources
how to do this in a way that is not disruptive to your
Development and operations peers, that's the thing. So it's like so start with understanding
start with and think about tools and processes that are not disruptive to
The operations development teams that are going to work with
So that you can move forward with less
residual resistance and and everyone's confident that what you're doing is
Necessary and worth their time and money to back up
Excellent. Thanks a lot. Again Michael for talking to us. I appreciate it
If you'd like to learn more about application security or anything else like that online
Feel free to look us up at CSO online.com and we'll see you next week
This has been salta - and I'm Steve Reagan. Take care now. Bye