“Embiggen your app"

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

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 WAF Not a panacea Bad 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 well Has to be convenient Has to be secure Needs to be an appropriate solution for the given problem And 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 company What 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 Time 35 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 set Check if js is enabled Lots of criteria can be checked Need to know your application And your users

If it’s not a humanyou have options Disable functionality Feel free to use a CAPTCHA at this point Throttle connection Honeypot! Learn if you are being targeted Or 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 requests A valid user A malicious user A 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

“Embiggen your app"