“Embiggen your app" Serge Borso – JAN 2015 Empowering your web application to defend itself

“Embiggen your app"

Serge Borso – JAN 2015

Empowering your web application to defend itself

Intro: Who am I? Background: Jurassic park (1993)

SANS Mentor Penetration testing – vulnerability research

Talking Points

Current architecture – the way it is today Example Scenario Addressing the gap The “code” Demo time Risk Management

Keep it breezy

Let’s have fun! Ask questions Looking for interactivity, not a lecture

There are lots of things I don’t know…Just throwing that out there

Today’s world

Typical setup

ISP – Internet connection Router Firewall ↓ IPS/IDS maybe a WAF ↑ Load balancer Web farm Your application

What happens when the application is targeted*?

Will your ISP block malicious requests? Will the firewall block that? What about your IPS or WAF? How about the application?

*The target of an attack like SQLi, harvesting, spambots, XSS, etc…

“Security is everyone's responsibility”

Lots of products exist to stop X But what, if any, security is the

application responsible for?

Problem is… When it’s everyone's responsibility, it

quickly becomes no ones responsibility

To that end:

Separation of duties so to speak Utilize the best tool for the job

Seems logical right?Hard to do with all-in-one solutions

A WAF does fill a need, however…We don’t all have a WAFNot a panaceaBad practice to address an application

vulnerability with upstream device

What's the purpose of this then? I’m an advocate for application security Let the application defends itself Caveats

Has to look good, no really (transparent) Has to work wellHas to be convenientHas to be secureNeeds to be an appropriate solution for the

given problemAnd maintainable

Example scenario:Enter the iCloud celebrity hack

Apple was NOT breached There was a bug though So what happened?

How are accounts compromised? Myriad ways, but essentially two groups

Because of you and things in your control○ Password = Qwerty1!○ Infected machine/ already pwned

Because of the app and things outside of your control○ App allows for unlimited guessing○ Poor corporate/security practices

Apple didn’t stop it…

And that’s a $billion companyWhat chance then do we have to secure our

app?

Let’s learn from their mistakes

A very good chance

Everybody’s got a thing webapp How we handle security varies Lots of homegrown solutions

What to do then?

Inconvenience users with a captcha? Profile the user, or at least the behavior Back in my online banking days that’s

what we did… Deviations from norm hit threshold, then

take this action

But what action?

In band or out of band I.E. an alert goes out and someone

looks at it Let’s have the application take action If deviation is > x then …

The premise

Lots of information to work with when trying to identify malicious behavior

Anonymous (no authentication required) website leaves less options

Essentially build a profile

What to look for… some ideas

Time35 requests in one second?Time to submit form less than 5 seconds?

Agent, referer (typo) Cookies enabled, js enabled Previous status codes: 403, 401, 503 Post vs Get, Post without previous GET Use whitelist and blacklist approach

Introducing the code It’s a “scoring” model Nefarious activity = higher score Higher score = tighter security

Disable functionality○ No wire transfers○ No PII visibility○ No account editing○ Kick user out/ block

Throw a CAPTCHA if you think it’s a bot The APPLICATION makes the decision

Progressively more challenging

If score > x then.. Force a page refresh and then:

Check if cookie was setCheck if js is enabled

Lots of criteria can be checkedNeed to know your application And your users

If it’s not a human you have options

Disable functionality Feel free to use a CAPTCHA at this point Throttle connection Honeypot!

Learn if you are being targetedOr just “a” target (not “the” target)

Block at the IPS layer

So what's happening? HTTP requests are being scrutinized We’re trying to determine what’s behind

the requestsA valid userA malicious userA robot

Then an action is taken May be prudent to communicate with

upstream device

Backup for a minute

Major problem with this whole concept It’s mostly all client-side variables Client-side means I can spoof it This is called…

Security through obscurity

Poor practice Once a bad actor knows the secret… The protection mechanism becomes

useless Easily bypassed

Live example

Going to use tamper data and a browser Make some requests See how the application responds

Actions

Write to Apache or IIS log then parse Integrate with fail2ban Integrate with OSSEC Integrate with IPS

Implications…

The benefit of this is boundary protection at the IPS layer

I.E. If the IP is bad and attacking this one app, then we should leverage this knowledge and block it from touching anything on our network

Managing the risk What is the criticality and sensitivity of

what you are trying to protect? (assess the risk)

User accounts connected to PCI? Or an email contact form? Often requires commensurate security

Opposed to a general solution I.E. the WAF will work for the contact

form, the PCI environment needs a closer look

Cromulent Questions?

Thanks for your time!

serge@sergeborso.com @sergeborso