LASCON 2013 Report – First Afternoon

We move into the afternoon of LASCON. The vendor room was all abuzz, complete with lockpicking village.

IMG_1477IMG_1478

Stupid Webappsec Tricks

Zane Lackey, Security Engineer Manager from Etsy (@zanelackey)

XSS

Data driven security – look at your data instead of using your presuppositions about how attacks work.

Overwrite common methods but only phone home on interesting payloads.

8477 XSS attempts with mostly alert(), prompt(), confirm() (or multiples thereof). The payloads are mostly what you’d expect, “XSS,” document.cookie, integers (from scanners). Note you can’t match on “document.cookie” because it’ll already be expanded, so look for your domains, unique cookies, etc.

What else detects XSS well?  Chrome’s XSS Auditor. Works great.  But it can defend the user but doesn’t fix the XSS.

Server side attempt –

  1. Scan input for HTML esscapes/tag creation.
  2. If found, set flag to true and create array of hostile input.
  3. At output time, check flag, see if any hostile input is being output as valid HTML.
  4. If hostile input is being output, alert!

Need to fail open, stripping will break your app… And it should take you 20 minutes to push to production so detect to fix is a short path!

SQL Injection

These are attack chains that can be instrumented. Detection step then exploit step.

Alert on SQL syntax errors showing up in your application today. It’s a bug even if it’s not an exploit.

Watch logs for unique sensitive db table names in requests.  Occasional false positives are OK.

A SQL injection exploit response will be huge sized, often larger than is normal, detect that. Whitelist stuff that is supposed to give huge responses.

The more alerts you have in an attack chain the more visibility you have, but false positives happen. But if it’s happening in order down the chain, it’s probably not false.

“Temporary” debug stuff is permanent. How do you find this automatically? Access logs.

Map access logs to code paths. Endpoints that don’t get requests are anomalous. Alert off it then go take it out.

Attacker Trix

Cheapest way to find webapp vulns – Automation. Your best attackers are doing it manually anyway, but may as well beat out the kiddies. Break off-the-shelf scanners. They give off strong detection signals. User agents, request patterns, requests for stuff that doesn’t exist (*.asp or php on a Java site, for example).

Blocking IPs is easy but dangerous. You’ll break lots of legit things. IPs are not a strong correlation to identity.

  1. Classify a request as being from a scanner
  2. If yes, weight based on confidence
  3. Feed request into rate limiter (see Nick G’s rate limiting at scale talk) and drop if above threshold. They return a 439 “Request Not Handmade”🙂

This doesn’t impact browsing but does scripting. Set your thresholds high; allows for false positives but a scanner will definitely peg it.

Be ready for the weirdness that is the Internet! Tried auto-banning accounts that do scanning. They saw 437 scanners over the last week and only 10 were authenticated and 5 were false positives. Browser plugins is our guess. So don’t auto-ban.

Attacks don’t always happen like you’d expect.  Look at the data before you make decisions. Get the instrumentation you need to make those decisions.

“Run a bug bounty program and the Internet shows up!”

And of course you can then insert false data sets to screw with people and increase the cost of attack.

We don’t run scanners of our own because it’s a time sink and requires manual babysitting. We have taken WAF concepts and build them into the apps; since we deploy 30x/day we don’t need the “coverage in the meanwhile” functionality they provide.

Stalking a City for Fun and Frivolity

By Brendon O’Connor, CTO of Malice Afterthought and law student. About CreepyDOL wifi surveillance. He was wearing a kilt and started out by telling us we’d “lost the mandate of heaven.” Why is this? Well…

Everything leaks too much data. Privacy has been disregarded. Fundamental changes are needed to fix this. We need to democratize security – the government is the worst way to do this.

Especially the case of the US persecuting legitimate security researches like Weev for doing things like accessing public information on Web sites.

Wireless.  Your devices advertise networks they know for all our convenience. His little doodads find your probe list of wifi locations and gps location. Now we need a distributed way of doing this on a large scale with no centralized control. Academic sensor networks are kinda like this, but expensive. Hence, the F-BOMB hardware gizmo.

Raspberry Pi based, 5W, $57.08. Uses connection to municipal wifi to phone home, with automatic portal-clickthrough. Reticle, leaderless command and control software. Uses TOR to go out.

CreepyDOL is distribute computation for distributed systems. Want to digest on the nodes to minimize net traffic. Centralized querying for centralized questions only.  Filters include Nosiness, Observation, and Mining. Visualization using Unity (the game engine). Oh look, you can see a map mashup of people wandering around and click on them and find their name and other useful info.

Bottom line is that all these technologies leak info about you like it’s going out of style and it’s pretty simple to get Orwellian levels of visibility on you for one low price.

Gauntlt

I missed this in favor of the next talk; I’ve seen about a dozen gauntlt presentations over time since I know James, but here’s the slides! Integrate security into your CI pipeline you freaks!

Penetration Testing: The Other Stuff

David Hughes, OWASP Austin president and Red Team analyst for GM.

This started as being about organizational skills… It’s general tips on making your life as a pen tester easier.

  • Clients aren’t always right about their environment and scope creep can happen.
  • Don’t assume you’ll have Internet, there’ll be proxies…
  • Prep your tools and do updates and test it ahead of time.
  • Rehearse your toolchain
  • Title your terminals
  • Use mind maps (Freemind), outline tools (NoteCase Pro) to organize tools, systems
  • HTTP-Screenshot module does screenshots as nmap scans
  • Use output options or pipe to a file
  • Reporting – keep organized, do it as you go, use ASCIIdoc to take text to pdf
  • Do things the easy way – look for low hanging fruit. DEfault credentials, bad passwords, cleartext, social engineering, dumpster diving, open wireless. Easy stuff is higher risk and the client cares more than esoteric crap.
  • Don’t rush recon, look for clues, broken windows
  • Have a plan (PTS framework) but range off as needed
  • Protect your customer’s data
  • Encrypt your stuff
  • Have backups
  • Learn and use a scripting language
  • Don’t rub it in with the client
  • Get involved with the community!

And that’s everything but the drinking… Time for happy hour and the mechanical bull!

Here’s some pictures of the volunteers hard at work, the speakers’ green room (there were chair massages there in the afternoon!), and organizer Josh Sokol with Robert “RSnake” Hansen!

IMG_1479 IMG_1480 IMG_1476

Leave a comment

Filed under Conferences, Security

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s