How can the recent Windows DLL hijacking issue affect me? Or rather, can it be used to specifically target vulnerable applications?

A disclosure this afternoon involving KeePass certainly does show you can target specific applications. For instance, if you can get someone with KeePass to attempt to open a KeePass file and load your malicious DLL, you can execute code…such as installing a keylogger/filemon to track what your victim uses to open that super-secret KeePass database.

Note an important issue here: While this vulnerability was announced by Microsoft, Microsoft may not be able to fix this underlying issue. Which really breaks many vulnerability management practices in enterprises that don’t do a good job keeping inventory of installed applications and their own updates/patches/vuln announcements.

As if there isn’t already enough uncertainty about browsing the web in general, take a read on recent posts from Armorize about some (to put it lightly) malware being served via widgets…with a large exposure base on Network Solutions’ parked domains. Part 1: the infection delivery; part 2: more on the malware; part 3: follow-up.

As the years go by, I have become less interested in the workings of malware on the desktop (call me jaded, but I consider it a total loss once it starts) and more interested in the delivery mechanisms and how malware gets injected into servers; or how servers get popped either directly or as unwitting facilitators (I work more with servers than desktops, so maybe this interest is natural). These reports by Armorize are a bit confusing to read in this regard, but from the sounds of it, either a widget server is being subverted or Network Solutions still has problems with someone owning (to some degree) their systems (or both). NetSol has been beleaguered this year with attacks.

Hosting someone else’s code. Including widgets from other people that consume content from other sites. Reduced budgets and increased cost-cutting. These are the sorts of things that demonstrate our unintended expansion of the trust we need to have in others and other code for our own security. Complexity doesn’t make things easier!

I can’t remember if I’d mentioned it before, but I will now since I’m snarfing many of the links to add to my own list. Wasim over at Security Thoughts has a nice list of vulnerable web apps you can learn from.

As much to remind myself as point out to anyone else, Google’s hackable website, Jarlsberg, has been renamed to Gruyere. Yes, there is a pronunciation note on the front page (btw, it’s a cheese).

It’s impossible to ignore shrdlu’s posts; they’re entertaining and truthful. For instance:

They assume that security staff actually have CONTROL over their systems.

Most products are predicated on this assumption—here, just install this agent and you’re done. Put this on the single choke point in your network and you’re done. Just whitelist what users can install and you’re done.

I’ve always been unable to explain how larger organizations can implement some of these things (I’ve worked in SMBs). You have one choke point? Hell, even I have at least 4, let alone other networks I have to eat up span ports for. That’s either costly or a gigantic mess. You have the ability to install and/or configure things? I do, but I know if one mistake digs into Availability then I get reamed. When you work in both operations and security roles, you learn quickly which one is more important! My guess is enterprises don’t do it very well at all like I expect; they just have the budgets to throw money at the issues and enough mgmt layers to spread the pain and BS.

As shrdlu mentions, it’s not at all surprising that the more “successful” security products are the ones that watch the network or require the least pain (read: involvement by anyone else) overall. This is why I’m a very, very, very strong believer in Network Security Monitoring and perimeter control as always being a very important thing for security.

Oh, the title of this post alludes to the thought of what role should security have. Should it just be a SOC where they have no control or administration rights? Or should they be veritable corporate gods? In my opinion, it should be far towards the latter. They may not always get their way, but they should be able to be empowered to straighten crooked paths.

(Look out, the cynical bus is driving by!)

The big elephant in the PCI room is simply how fucking expensive truly meeting the requirements is (for SMBs and others). Between capital costs and process changes and slowing down business and staff knowledge/training and manhours…it’s not nearly as small a pill to swallow as ya might think. And even if you get it done, the people behind it have a few more grey hairs, have burned plenty of political credit, and have new drinking problems! (Or you work in a large enterprise so it’s slightly easier to swallow.) More than likely they also now have dire staffing issues.

Mike Richardson has a great blog post about implementing PCI DSS standards in a web hosting environment. The end result? It’s dishearteningly expensive and not in demand.

What really sucks about admitting PCI is expensive? I’m also saying *security* is expensive. And it is! Then again, pressing 150lbs is tough, too, but you’ll get there if you start at 75lbs and work at it. (Don’t mock me in regards to my analogy!)

Compliance is still just part of what I call the big gamble in security (and enterprises). You know you should do more, you know you should look at that log today, you know your staff should be properly checking their controls, you know you’re not allowing your QSA to see the whole picture…but you gamble that things will be fine and continue on as you otherwise do, following the path of least resistance that you can get away with. Entire organizations operate that way, let alone executives, managers, and employees.

Need some password lists? Have a look at Ron Bowes’ wiki over at SkullSecurity for some lists. You may have heard of some of them (RockYou, MySpace, Facebook users…).

Strange naming choice aside, Giorgio Maone (of NoScript fame) posted about some Classic ASP ASCII conversion oddities, namely the tendency to replace unknown characters with homoglyph or homophone characters. This is an interesting little piece that has value for client browsers trying to prevent XSS attacks, or those attacking Classic ASP sites.

Quick note about a new Windows DLL vulnerability whose details have been announced. The best place to start investigating this is from HD Moore’s Metasploit blog post. It is worthwhile to note that most organizations block outbound SMB ports at the firewall. Internal attack is still quite possible, and so is being redirected to an external WebDAV instance. Thankfully WebDAV is not common out in the wild, so that scenario is slightly less of a risk, but still it might be useful to block unnecessary http methods like PROPFIND on your web filters. Unlike my shop which is a heavy Windows .NET dev shop, it might be useful to include all .dll files in your network share content scans. You should prefer to know what’s out there and what’s new if that isn’t too much of a burden (it is when my devs have innumerable dll files out on my network).

While we don’t have a huge plethora of worms and remote attacks these days, the number of attacks available, e.g. to pen testers, attacking users directly and actively is crazy high. Convince a user to do/go/open x and you’re in.