Monday, October 25, 2010

Application Security Challenges

Assume that all your application security challenges are conquered. You've got smart people and you've trained them well. They catch all their exceptions, they bound their arrays, they else their if's and sanitize their inputs and outputs.

Congratulations. You've solved your biggest security problem.

Maybe.

How about your crufty old apps?
image
You’ve got de-provisioning down pat, right? No old apps laying around waiting to be exploited? Nobody would ever use the wayback machine to find out where your app used to be, would they?
Or
image
An associate of mine did the forensics on one like that. Yes, you can upload a Unix rootkit to a blob in a SQL server, execute it directly from the database process and target a nearby Unix server. Heck – you can even load a proxy on the SQL server, poison the Unix servers ARP cache, and proxy all it’s traffic. No need to root it. Just  proxy it. Network segmentation anyone?
Any old libraries laying around?
image
Yech. I have no clue how someone who downloads [insert module here] from [insert web site here] and builds it into [insert app here] can possibly keep track of the vulnerabilities in [insert module here], update the right modules, track the dependencies, test  for newly introduced bugs and keep the whole mess up to date.
How about those firewall rules?
image
Speaking of de-provisioning – Firewalls rules, load balancer rules… Are they routinely pulled as apps are shut down? Have you ever put a new app on the IP addresses of an old application?
Shared Credentials anyone?
image
That’s that whole single sign-on, single domain thing. It’s cool, but there are times and places where credentials should not be shared. Heresy to the SSO crowd, but valid none the less.
You Management Infrastructure is secure?
image
Of course you don’t manage your servers from your desktop, you’ve realized long ago that if it can surf the Internet, it can’t be secured, so you’ve got  shiny new servers dedicated to managing your servers and apps. Now that you have them, how about making them a conduit that bridges the gap between insecure and secure?
Speaking of System Management

image
Do you system managers surf the Internet? Hang out at coffee shops? Do you trust their desktops?

Same goes for DBA’s by the way. A trojan’d DBA desktop would be a bad day. I’m just too lazy to draw another picture.

Don’t forget Storage management
image
Can’t figure out how to hack the really important [secure] systems? How about cloning a LUN and presenting it to the really unimportant [insecure] system? Your really cool storage vendor gives you really cool tools that make that really easy, right?
Or your Backup Infrastructure
image
We aren’t too far removed from the day when Legato tech support insisted that backing up data through a firewall was unsupported. Even if you tried, you soon figured out that by the time you opened up enough firewall holes to get backups to work, you’ve pretty much lost the ability to segment your network. And after you’ve poked the required Swiss cheese holes, the firewalls role over and die when you stream backups through them anyway. We can’t afford to a dedicated backup server for every app, so we build shared backup networks, right? What do backup networks do - connect every network together?
How about remote access?
image
Capture credentials on the sysadmin’s home computer, try them against the corporate SSH gateway? Don’t worry about it. nobody would ever think to try that. You’ve got two-factor, obviously.
Your Build/Deploy Process?
image
I think it’d be so cool to have my parasite malware get deployed to prod using the enterprise change management/deployment process. Heck – it’d even inherit source control and versioning from the host. Neat!
Take a look around.

When you are buried deep in your code, believing that your design is perfect, your code is checked, tested and declared perfect, and you think you've solved your security problems, stop & take a look at the security challenges surrounding your app.

Thursday, October 21, 2010

Log Reliability & Automotive Data Recorders

When are logs reliable?

Toyota's official answer seems to be either It depends or "The data retrieved from the EDR is far from reliable", unless the data exonerates them, in which case "the EDR information obtained in those specific incidents is accurate".

There’s got to be a blog post somewhere in that.

Accuracy:

  • Did the log record what actually happened. Did the log record when something actually happened?
  • Do the logs represent the events in the order that they occurred?
  • Are the time stamps accurate?
Time syncing all you systems is fundamental, obvious and a best practice for the last fifteen years or so, but unless you log time sync failures, you don't necessarily know if the time stamp on a logs is accurate. I like syslog capable systems that time stamp the logs at the source and syslog servers that time stamp them again as they are caught and written. That helps verify the accuracy of time stamps.

Completeness:

  • Are there gaps in the logs? If so, can we determine where the gaps are?

Unless the logs are stamped with a serial number, odds are that you cannot verify completeness.

I've never testified in court.

I’m not sure what it is, but I’m sure it’s rootable

I have no clue why anyone would still run RealPlayer. I’ve pretty much forgot that it existed.  But I know that those who know what it is and still run it are screwed. If they even know they are running it. They probably don’t. That makes them extra screwed.

If you accidently configure RDS in your Linux kernel, you’ve got something to fix.  From what I can see, we can blamethank Oracle for RootableReliable Datagram Sockets. You’d think that be now we’d be able to introduce something new and interesting without making the old & stable rootable.

I guess not.

If obscure media players and Infiniband protocols are rootable, the most popular OS in the world must be rootable, right? Yep, it’s rootable. Again. Damn. It’s probably also running Java, which makes it double-extra rootable. Speaking of Java, Microsoft thinks that there is an unprecedented wave of Java exploitations. I wonder who wrote the operating system that allows itself to be exploited by such an unprecedented wave. Waves aren’t unprecedented. They are periodic.

I used to think that running a non-Microsoft browser would help keep my desktops clean. I’m not sure anymore though. The alternatives don’t appear to be any less rootable. Nor does the running the best alternative operating system make you immune. Safer maybe, but immune? Nope. Not even close.

Adobe, apparently feeling rather left out by all the recent attention that Java has received, decided that Flash Player, Reader, Acrobat and Shockwave must be vulnerable too. Can’t let the competition leave you behind, can you? I can imagine some VP reading about Java exploits and demanding that all Adobe products support exploits too.

And of course if you are bored, you can remotely root a Blackberry Enterprise Server. All you need to do is have one of your poor sales schmuks open up a PDF on their Blackberry. Sounds like fun, eh? The sales droid opens a PDF, the system manager of the BES server gets screwed.

If it can surf the Internet, it can’t be secured.