Microsoft Windows and IIS have long been a whipping boy for security issues. If you hadn’t noticed, they’re back in the spotlight, only not quite as loudly because of the technical nature of recent issues. But this year is different. Instead of Microsoft standing alone, web developers are strapped to the stocks as well.

Microsoft has a new security advisory up (April 23rd) giving vague details of a vulnerability that matches details provided by Cesar Cerrudo at HITBSecConf2008. It sounds like this is less an issue with external hackers and more an issue with trusting your developers, the ones who provide code that could possibly exploit this issue. The workarounds are a bit annoying as posted currently. I think every Windows admin has experienced angst when changing accounts that services or pools run under, and we all do so only if necessary (and cross our fingers that nothing breaks too badly). And disabling MSDTC (COM+) when your apps that run your business use COM+ is not an option. (Microsoft may as well tell us to turn off the web server and unplug the machine!) I think I would be more concerned if I were a larger hosting provider running on Windows…

The above issue does not affect Vista or Windows Server 2008, it appears.

This is paired up with a recent large scale of SQL injection attacks. Microsoft (and many others) rightly point the blame to developers and coding practices. The OS and even the coding environment can only go so far to protect against incompetent, ignorant, or rushed developers. The rest is up to the developers and those leading the developers.

Attackers continue to move up the layers.

How do you know your laptop users aren’t using their cell phone connection to access the Internet around your firewall while at work?

Thomas Ptacek continues some talk about the merits of (or lack thereof) “defense in depth” (DiD). He is not sold on DiD as a core principle for security design. Which I think is perfectly fine! Even though I believe in the value of DiD, it might not always apply in every situation.

Three things to start any DiD discussion:

1) Thomas quotes Eric about my first point: “But Eric also associates ‘depth’ with network security, not application security…” I think Eric is somewhat correct. Any discussion on DiD should start with where we’re framing the discussion, application, network, other…

2) I’ve mentioned before about security religions. There is a group who does not accept anything but truly secure “stuff.” Incremental or DiD principles need not apply. There is no use in arguing about DiD to someone who believes heavily in the absoluteness of security measures. These would be black and white people: either it is secure or not. Don’t argue DiD with someone who fanatically believes in absolute security; DiD is absolutely worthless to them.

3) How do you define DiD? I know of two different definitions. First, DiD refers to layers of defense overlapping to cover deficiencies in other layers; complementary DiD. One blanket can cover half your car when it is raining, but a second, different blanket overlapping the first one can cover the rest of your car. Second, DiD refers to layers that sit like concentric rings. If you break through one, you still have to break through several more; additive DiD. Without defining our view of DiD, none of our analogies will be appropriate to compare.

I sympathize with the points raised about causing an attacker to take more time/effort to achieve an asset (attrition) and also cause them to trip more alarms in trying to evade everything you’ve thrown in their way (delay). Notice these don’t *stop* an attacker, but they give defenders a chance to react better or avoid a compromise. Does an adhoc military base erect walls such to withstand missiles, tanks, and planes? No, they rely on detection of incoming threats and react to them. Kudos on the point of reaction, though, since many of these attacks are so quick to execute in the cyberverse. But in counter, I’d rather known after the fact than not at all.

Some comments paint what I think is a realistic vision of DiD.

One comment mentions that DiD is all about economics. This is more increasingly being called risk management. If you have layered defense where an attacker uses his known parlor tricks to get into the outer crust, but has to spend a lot of time and energy to get any farther because he’s not as knowledgable about other techniques, the risk of him bullishly continuing to try may be small.

Another comment mentions DiD should not be “an alternative to rooting out and fixing vulnerabilities.” Very true, but again this comes down to economics. It also seems to be the driving point behind WAFs. Rather than fix the code (which can be costly), just throw up a WAF and not bother fixing something that can be bandaged.

Complexity vs Security vs Economics…

(IN)SECURE Magazine Issue 16 is now available. Reminded about this by the ServerGuys!

So I’ve spent several days on Twitter, alternating between not watching to being interested in the goings-on.

My impression of Twitter is: IRC+IM+Web.

It is like IRC in meeting new people and hearing new voices, and having your voice heard to others you normally don’t interface with directly; like sitting in an IRC channel with 50 others, you can just pipe up with something and get involved. I could have use forum instead of IRC, but forums are threaded and usually slower, while IRC feedback is far quicker and linear.

It is like IM in tracking the people you like to talk to, direct messages, and so on. Unlike IRC where people come and go as they wish (minus your friend lists), IM is far more dependent on you having added them as a friend and vice versa.

And combine that with web accessibility. Companies have long fought against the time-wasters of IM and even chat (ok, fine, IRC is largely blocked because of its prevalence in bot control mechanisms), but people still want IM and chat. Hence, they now use a port 80 web interface to do essentially the same thing. If that is blocked, there are numerous other portals, site plugins, and clients to use to get the access. We’re destined to lose battles against cultural trends unless we’re an organization that absolutely requires high security.

Also, Twitter is easy to use and enjoy. There aren’t a ton of features, which I think is a key to anything “2.0” these days. I know, all sec pros should know how to use IRC and various chat clients (you’re old/middle school, right?), but the reality is not everyone has ever fired up non-web-based IRC before. So, this makes the IRC chat part of the equation much more accessible.

It is definitely not bad, and I do enjoy it, especially since I don’t get to use IM or IRC at work. Now, I can only join one public group of people in my Twitter club, but I can register other names for my other circles of buddies if I had any. 🙂 I could even have a work name and a group with just coworkers about what we’re doing or where we are.

Questions/tickets posted to me today remind me how much of a stressor it is to support developers. Typically speaking, developers have very few boundaries in which to solve their problems. Their lack of boundaries turns into my headache when they start finding creative (special ed) solutions to problems. Kinda like kids who want to do something but can’t, and they find some unexpected, completely terrible way to do it that causes a hole in the wall.

And sometimes, it’s not their solutions that suck, it’s the bad initial requirements that suck and really aren’t possible in a given architecture without a lot of unnecessary pain, cost, and compromise of security posture. And of course it’s my team that gets to be the mean parent…

An article on CNET about a LendingTree data leak made me pause for a moment.

Several former employees of LendingTree are believed to have taken company passwords and given them to a handful of lenders who then accessed LendingTree customer data files, the company said.

LendingTree could also face lawsuits from its customers, as well as sanctions from the U.S. Federal Trade Commission, particularly given the potential for identity theft…

I hope that those employees were already “former” when these incidents occurred. That makes life a lot easier. But what if they were still valid employees who gave away their valid passwords to a presumably remotely accessible system (web portal, most likely)? That just sucks. We go from corporate negligence to malicious insider, and that’s a world of difference.

This should bring up questions of how to make authentication non-transferable. Or about the need and scope of remote access. Or that we simply can’t be perfect and sometimes, especially with malicious insiders, ultimately our only recourse is rigid auditing and alerting.

Slashdot ran an email from a senior security engineer lamenting his company’s ethics in security auditing. Dan Morrill posted about it, which was my first exposure to it. I posted a comment on his blog, and he sort of lightly guilted me into posting it on my own blog here. Honestly, I had some points in it that I kinda didn’t want to just lose to the ether, and instead save them here for myself.

So read Slashdot first, then Dan, then my post will make more sense. I will concede points that say audits really are a bit about negotiating your security value, but I think it needs to be documented. Risk A, mitigating factors B, accepting C…

I know it’s a cop out, but I would look for work elsewhere. It’s not only a cop out, but also a bit of a cynical approach. But once you drop down this road of fudging the risks/numbers, where do you stop? Where do you re-find that enthusiasm for an industry you’re helping to game? What if your name gets attached to the next big incident? What if the exec that got you to bend throws your name out to others looking for the same leeway? Integrity is maybe our most important attribute in security.

I know strong-arming (or outright lying!) happens, it always happens. I think the only way this won’t happen is to have a very mature, regulated industry much like insurance or the SEC/accounting/financial space.

Of course, this also means we need to remove or greatly reduce subjective measures and focus on objective ones. Those are the ones we hate: checkboxes and linear values. Those suck to figure out, especially when every single org’s IT systems are different. I just don’t think that will happen for decades, if that. Unlike the car industry or even the accounting disciplines, “IT” is just too big and broad and has too many solutions to control it.

This leads to one of my biggest fears with PCI. Eventually it will be something negotiated, and the ASVs will be the ones taking the gambles. Lowest price on a rubber stamp PCI compliancy. Roll the dice that while we roll in the money, our clients don’t get pwned in the goat…good old economics and greed at work.

This also penalizes the many people who are honest, up front, and deal with the risk ratings in a positive fashion. Sure they may get bad scores, but that means there is room for measurable improvement. There are honest officers and people in this space. But there are also those who readily lie and deceive and roll the dice on security, and those are the ones who will drive deeper regulation and scrutiny.

—

I’m confused by the post itself. I’m not sure if his company is being strong-armed or if his company is doing the strong-arming.

If his company is being strong-armed, then any risk negotiation should be documented. “We rated item #45 as highly important. Client (name here) documented that other circumstances (listed here) mitigate this rating down to a Medium.”

If his company is doing the strong-arming, you might want to just let the senior mgmt do their thing. Ideally, if shit hits the fan, it is the seniors that should be taking the accountability, not others, especially if they’ve been involved in the decision making processes.

With this line of thinking, there is another thing: the geek factor. As a geek, I tend to know about and inflate the value of very geeky issues. It is often up to senior mgmt or the business side to make decisions on the risks. Sometimes, the decision is made to accept the risk. This means possibly not fixing a hole because the cost is too great, even if there is a movie-plot potential for a big issue. It might be an approach to sit back, take some time and reflect on the big picture a little more. Are these strong-arm tactics covering up truly important things? Or are they simply offending our geek ethic?

One could also weigh in on what would be your proper measure of security? It is always a scale between usability and security, and in the words of the poster, there will always be some scale that involves accepting some risk in order to keep one’s job. The alternative is to be so strict about security that you could only get away with that in a three letter agency or contractor thereof!

—

Ok, after all of that, if the guy wants to keep his job (or not I guess) but yet blow the whistle on such bad practices, I’ll have to put on my less white hat and give some tips.

It sucks to do, but sometimes you do have to skip the chain of command and disclose information to someone up above the problem source. I’d only do this after carefully considering the situation and making sure I have an out. Even an anonymous report to a board of directors is better than silently drowning with the rest of the ship.

If there is a bug or vulnerability in an app or web app, get it reported through your reporting mechanisms internally, like a bug system or ticket system. Get it documented. The worst they can do is delete it, at which point you might want to weigh disclosing it publicly somehow… (of course, by that time, they’ll likely know it was you no matter how anonymous you make it).

If the company is big enough and the issues simple enough, you might get away with publishing anonymous in something like 2600, the consumerist, or a general blog from a third-party. Sadly, when trying to get people to understand technical risk, it can be difficult to be precise, understandable, and concise. If the guy belongs to some industry organizations (Infragard, ISACA, etc) perhaps leaning on some trusted (or NDA-backed) peers can be helpful.

I just signed up for Twitter. I also embedded a tracker for just my posts over on my right menu bar up near the top.

I’ve been online a relatively long time now, nearing 15 years, which has included a lot of social stuff (IM, IRC, forums…). Because of this, I’m not terribly quick on utilizing various newfangled social networks. It’s a lot of work to maintain a presence, and most of my old stuff still works just fine for me. But Twitter looks interesting and mildly useful, basically a web-based IM system when used with others and a more streamlined, eye-blink, steam-of-consciousness blog/journal type of thing when used alone.

I don’t really have ambitions for Twitter beyond logging my own goings-ons that aren’t quite blog-worthy, so feel free to invite/abuse/include me in whatever. Never know, I may instead decide half my posts to Twitter are useless to even me, and the rest I could just roll into blog posts… I certainly have that freedom since I have no ambitions with my blog itself (hence no ads or viewer tallies!).

I’ve previously mentioned a web-based SSH tool as a way to access your SSH server through a web browser (and port 80/443).

Another such tool is up: consoleFISH. I tried it out really quick (I didn’t complete the login process), and seems to work nicely. Of course, when using such a tool, assume that everything you type is being read by the web server, including the password. Would I use this? Maybe in an emergency or when accessing an SSH I care nothing about (someone else’s!), but not likely for any of mine unless it was through my own web server. I may as well just port forward locally with Putty or use AjaxTerm on my own server here…

Snagged this from a0002.

The SANS Diary has posted a recovered tool that has been used to do mass defacements of websites. I’m sure this is being posted all over, so I won’t wax on it too much. The tool uses a search to find potentially vulnerable sites, then just mass attempts to SQL inject it. It’s a sweet, simple little tool and I’m sure there are many, many others out in the wild just like it that simply haven’t been recovered or distributed by the author.

Bojan closes the piece with the necessary suggestion for everyone: fix your shit. Run your own scans against your web apps because attackers are already doing it. Kinda reminds me of port scanning your firewall…attackers do it, so should you! You’ve already lost the battle if attackers have more information than you do, or find that open port (vulnerable input) before you do.

Still haven’t purchased some identity theft protection? Perhaps IdentityLoveSock is for you!

I was organizing some old files and came across one of my favorite 22c3 recordings. Tim Pritlove gave a “talk” called The Realtime Podcast, and I’m amazed I never posted about it. Tim’s talk was a realtime podcast on the topic of podcasting. If you can get your hands on the mp4 recording you’ll much appreciate it over the low res, reduced audio of the linked Google Video version.

One thing I’ve noticed on most (all?) podcasts I’ve listened is they have no background music playing. I find it interesting and somewhat more “focusable” to have the background music that Tim uses. I’d be curious if that would work well for any security podcasters, especially when the levels are controlled.

Tim pimps out DJ L’Embrouille [translated] in his podcast, a DJ who freely releases his electronic mixes. His sound ranges from ambient, minimal electronic to more house types of beats; basically stuff I totally dig. The mix Tim sounds like he is using is 2005 Week 38 (MPIIIRadiomix220905), although the levels are futzed a bit to reduce the heaviness and drop out much of the bass, I’m sure for podcasting purposes.

Drifting off on a tangent, many mixers put their little tags or snippets in the first few minutes of their mixes, and DJ L’Embrouille often does as well. He uses an almost whispered monologue. I have no idea if he came up with it, spoke it, or where it comes from, but it’s an amazing little piece*:

turn on,
tune in and drop out;
you can’t say that;
what I am saying,
happens to be,
the oldest method,
of human wisdom;
look within,
find your own divinity,
detach yourself,
from social and material struggle;
turn on,
tune in and drop out

* In doing just a bit more research, I think this piece is a reference if not an audio sample from somewhere of Timothy Leary who coined the phrase “turn on, tune in, drop out.”

A couple interesting papers posted up on SANS reading room.

First, “Malware Analysis: An Introduction.” I don’t particularly care so much for the introduction part, but I do like the walk-through later in the paper. I like to save paper, so I only printed out what I found interesting: pages 40-63. I should save even more paper and invest in a Kindle or e-book reader… One thing I notice the author didn’t use but I would recommend is a snapshot tool run before and after execution of the malware to capture changes in processes, files, and registry entries (Inctrl5 is still a great choice). I know he watches Process Explorer and TCPView, but it can be difficult to read everything in realtime if the malware does a lot. I was surprised there was no mention of Filemon or Regmon either.

Second, “Espionage – Utilizing Web 2.0, SSH Tunneling and a Trusted Insider.” I didn’t think this would be something I’d print out and read, but in quickly scrolling through it, it seems to pack a lot of very technical stuff into a web-borne client-side exploit. I appreciate that! Later in the paper, Ahmed discusses the incident reponse actions of the victim.

I swear I picked these up from McGrew’s blog, but can’t find them now. I could be wrong and got them elsewhere…

This looks like a fun little project that might run near $100 assuming one needs to get all the parts. The Predator from I-Hacked essentially extends the range of an open wireless network, rebroadcasting it in a secure mode that you can hop onto. It does this with an external antenna and DD-WRT.

Does this have any uses? Well, I doubt anyone wants to cart this around on a trip, and it certainly looks suspicious in a parking lot. But it might make a decent addition to a wardriving car/truck/van setup. A few years ago this might have been a fun idea to get wireless access while around town, but these days cell phone-to-laptop Internet services and gear seem to be solving this problem. This could obviously be used to surreptitiously connect from a distance to closed wireless networks that you have cracked. Although it might be more useful to just plop the antenna on the laptop and crack/access that way as well.