Via LiquidMatrix, a demonstration on some vulnerabilties have been disclosed against RBS WorldPay over on the rather sobering unu1234567 blog. This brings up a couple comments:

1. If a breach occurs and no one notices it, is it a real breach? (I mean this sarcastically and rhetorically; of course it is a real breach, but it illustrates something that blows my mind: vulns that linger for weeks, months, *years!* and then get discovered. And how long have we had this hole in the ass of our pants and not known it?)

2. I hope RBS WorldPay is going over their logs to make sure their databases haven’t been siphoned off already. And good luck trying to find all the permutations…it would be fun to take such logs and start carving them up, kicking out obviously valid calls, and collating items of interest for manual review. And if they don’t have reasonable logs saved, fail.

3. I don’t care if RBS WorldPay will say this is a development box. It’s externally accessible. It contains valid logins. As Heartland will attest, even satellite, non-critical apps/servers can act as a launching pad for deeper attacks. Unless you purposely hang a box (honeypot) out there to be attacked, there is no such thing as a valueless target for an attacker.

4. Clearly, this system either has never had any security review of the app, or their external assessments are failing to detect that this was externally accessible, or their change control sucks to let this system get configured to be external in the first place. Lots of fail here, really. Lots of head in the sand issues no matter what the story.

4. Congrats on the free security lesson, RBS WorldPay.

This is still begging to be produced. Christopher Hoff recently posted lyrics for Security Rockstar (to the tune of Nickelback’s Rock Star). And a portion of it bookended the Network Security Podcast episode 161 (the version at the end does the first verse and chorus).

Strangely, the music is far more painful than Hoff’s singing. 🙂 And does contain some nice lines. I especially dig the rhyme of “…ubuntu” and “…can hack into.” It really should include something about being the target of kiddie hacks, once you get to be a security rock star (maybe kiddies want to be the rock star but then rage against them in the next breath).

Very quickly, ComputerWorld has an opinion piece on The Unspoken Truth About Managing Geeks. A nice read.

InformationWeek’s August 31, 2009 issue included a nice article from the folks at Neohapsis (Greg Shipley, Tyler Allison, Tom Wabiszczewicz) titled Breach Diaries: 5 lessons learned from the front lines of today’s major data thefts. I’d link to the article, but InformationWeek wants you to register first. Lame, because the article hits key points very well which I’ll very briefly list. Some of the thoughts are my own below, but many are yoinked from the article. I share this because, as the article states in the beginning, the business tendency to shut up about breaches is making it harder for security to improve.

1. Get serious about web security. Web apps are being widely used as attack vectors. WAFs buy time, but the root issue is code. Review apps and incorporate security into dev cycles.

2. Add secondary controls. This includes internal firewalls, network segmentation, encryption, database monitoring. Implementing them is not enough. Implement them with a purpose, audit the settings/policies/configs, and watch the logs. Arguably weighted in the reverse order!

3. Know your limits. Most (hell, all!) security technology has limitations. Know them and lean on those techs only as much as they should be leaned on. Fill in the gaps with other solutions (usually watching events, traffic, anomalies, etc) and diligence. I really think this is where staff will make or break you, not the technology.

4. Trust but verify. Wake up every morning and say this until you live this.

5. Plan for incidents. This is another “duh” item, but a tougher one when you get down to it. For instance, how often does a security breach happen compared to a simple system outage/issue/mistake? A vast majority of the time an admin attends to an issue, the response is to rebuild or do things that destroy data. I’d argue that once an incident is truly suspected, then IR policies come into play, but for day-to-day work, I would usually suspect that systems or evidence may get destroyed or at least tainted. Really, this might come down to being careful to keep logs and audit trails and events separate from day-to-day ops.

Bejtlich has been far more active on this than I, so I’ll defer to his updates here and here.

I’ve heard from a couple places now that reference a report last year in regards to the TCP/IP dos vuln CVE-2008-4609 that Microsoft, Cisco, and others coordinated patch releases for this week (one of the the dos parts to MS09-048). This is probably accurate since Outpost24 (Jack C. Louis who passed away earlier this year) is credited in the Microsoft bulletin.

Here are the key points:

1. Windows XP is vulnerable to the two dos issues in MS09-048 when it has a listening service open.

2. Windows 2000 is vulnerable to the two dos issues in MS09-048, and will not be patched.

3. Windows XP currently has no MS09-048 patch, and may not get one for the same reason Windows 2000 is not getting one: the change is too big/hard/impacting to the underlying TCP/IP (NDIS) implmentation.

4. So far this just deals with a vulnerability that leads to a low-cost DOS attack (i.e. you don’t need 10,000 distributed systems). There may still be a potential for r00t code to be developed, or malware payload that may be used to storm through a network and just repeatedly down every XP/2000 box. Better yet, if you need a box rebooted as part of your attack, this could be a sure way to do it, or to get an admin’s attention to then log into the box and snag some credentials while he investigates.

Quick pointer over to some nice postings. Rich Mogull pointed to and responded to an article by Bob Russo from the PCI Council. Bob also responded back in the comments. My feelings are also in comment form, there.

Bottom line: PCI is a great value, an excellent value, as long as you don’t think it is the only thing you need to do, or lash back at it in some odd hatred of “best practices” because, god forbid, they’re not perfect. It is the kind of guideline that so many companies need, and so many of us experts can use to make our cases. It doesn’t end with PCI, but for many it does start with PCI.

Thank you Bejtlich for posting about this and making me revisit this for what is probably the fifth time in 2 days. I fully blame Microsoft poor wording for the confusion.

Yesterday, my first reaction (heck I even Tweeted it) to MS09-048 was to call it a Big Deal. Truly, it should be: On affected systems, any listening service exposes the system to at least one of the vulnerabilities.

Microsoft played dumb with Windows XP, however, stating the default configuration for XP SP2 and SP3 has the Windows Firewall turned on and not allowing any listening services.

But I think anyone who has even a smidgen of tech-sense in them knows that once you network the box (or basically even just use it, it seems), listening services are started and maintained or the Windows Firewall is flatly turned off.

So, the question remains: Let’s stop playing dumb and just say XP SP2 and SP3 at least potentially should be considered vulnerable. Does that mean XP is vulnerable to just the DOS/reboot vulnerabilities or also the part that allows remote code execution?

A big fail on Microsoft’s part for basically omitting this information.

Update 1:00pm: I can also confirm that there are no patches at all for XP systems relating to ms09-048 in WSUS or Windows Update. This could mean a few things. Maybe XP is en total not affected (but why the asterisk?). Maybe no patch was ready (of course, this could mean Microsoft just indirectly released their own 0day once what was released is reversed). Or maybe something screwed up. But the bulletin certainly reads like XP is potentially vulnerable if you, god forbid, expose listening services.

Update 1:37pm: Fabs has released details on one of the dos vulns, CVE-2009-1926

Since Firefox has gone down the same path as IE (bloated, trying to do everything, untrusted, slow-loading, and being so big that it just can’t, alone, be the “more secure” option anymore which, along with speed and trust, catapulted it up into contention with IE in the first place!), my loyalty to Firefox is entirely hinged on add-ons like NoScript.* This means I’m open to new tools that may be simple and get back to what I really want: speed, trust, simple, and reasonably secure largely through that simplicity.

I just read about SeaMonkey’s new release. While it’s a new option, I don’t like the idea that it is trying to be an “Internet suite” of tools (really, HTML editor?) with a browser, email client, news client, IRC client, etc. In that regard, I’m not tripping over myself to try it, but though I’d share the link in case it does become a legit contender as the new upstart (just like Firefox and Google once were…oh how the popular forget what made them popular). Besides, in trying to do all that stuff, can it ever possibly satisfy my security desires enough in any one part to best dedicated individual clients? Yeah, if I get around to trying it out, I’ll try it out. If not, I’m probably not missing much.

* Strangely, IE7 loads faster, at least in perception, than any instance of Firefox that I run anymore, Windows or Linux. But, I like that I can really reduce the toolbar footprint of Firefox down to like one bar, and it sucks that IE’s bar has gone the way of being a pain in the ass to customize in the same way. Still… really it’s NoScript that keeps me locked to Firefox.

I’m not a fan of password managers in browsers; it makes me feel even worse about how OS-like the browsers are getting (and how far from Firefox’s “we’re secure because we’re simple” roots they’ve strayed), but I’ll have to remember this Firemaster tool (article by Lifehacker) if I ever find a need to break into a Firefox password manager store. (via h-i-r.net)

In-browser password management is something people looking for efficiency and shortcuts want to use. In my opinion, most of those people are probably the same people who re-use passwords and use simple passwords. I would suspect most people choose simpler passwords for their in-browser management tool, making Firemaster a risk. (Of course, you’ll never learn what your passwords are if something always puts them in for you!)

Then again, one should always expect some method of cracking or brute-forcing passwords, and thus always choose reasonably complex ones.

…because your personal acceptance level (or ignorance) of risk differs from that of the company you work for.

There are always posts about how draconian IT policies are for users, and responses on why it is that way. This well-written article is another example of the justification for IT restrictions.

It is often the job of IT security folks to do and enforce these things, usually as a blessing from upper management. Getting mad at them is rarely going to get you anywhere, just like getting mad a TSA agent. Sorry, they’re just doing their job; take it up with their superiors or the policy-makers. We’re not (always) trying to be sadists.

The end of this article is a key point: “As a user, are you ready to accept personal responsibility if something you want affects the security of the network?”

In the end, it is all just a balancing act between corporate culture (which includes productivity and happiness) and managing your risk. If we could forget all the endpoints and properly secure the important data while letting people all run as local admins, we’d probably do it. Logical decisions are usually easy for us…

The good folks at Offensive Security have posted a video (camtasia) of the Win2k IIS 5.0/6.0 FTPD exploit in action (found via Andrew Hay). The difference between this version and the kingcope expoit is this sets up a bindshell where the original set up a new Windows user account.

What isn’t mentioned is the exploit does require a valid connection to the FTP server, either through valid credentials, stolen credentials, or anonymous write access. So the old “best practices” of removing anon access, being careful who you let into your server, and enforcing strong passwords helps mitigate this risk. Though that’s really not enough assurance and I expect an MS patch for this soon, this at least should let you sleep at night if you have vulnerable servers. And don’t just think about remote attacks from China but also internally-accessible FTP servers.

Another “best practice” is to flatly not use the IIS FTP server. I think that suggestion has been around for 10 years now…

Over the years, the case whether Skype is appropriate for the enterprise has regularly been brought up. I just read a news article talking about a recently released trojan that intercepts Skype voice conversations and is based on code that was developed 3 years ago.

From this first article, it sounds like the malware gets installed onto a target computer, and then records all voice communication that Skype attempts to make. It is unclear if this includes call information routed through a system designated as a supernode.

Regardless whether it does or not, keep in mind there are governments in this world that would outlaw Skype if there was no way to intercept those calls (even in 2006!). And they typically “allow” Skype. That alone should be enough to give you some clues…

This morning a 0day for Microsoft Windows 2000 IIS 5.0/6.0 FTP server was announced on Full-disclosure (and milw0rm). From the sounds of it, this may require a valid set of credentials and thus be more of a priv escalation than a remote r00t, but close enough to be a bit worried. (Do you trust your FTP outsid…err…users?)

I have a friend who has an old Windows 2000 FTP server he can’t take down and it open to the Internet (with valid login information). One way to initially minimize the risk on this vulnerability is to limit those who can connect through your border/perimeter/firewall to the FTP service to only those people who have a legitimate need. If you don’t have such information available, perhaps the log files will give an accurate history of valid users? If nothing else, this is better than nothing to go on, especially until more information on this vulnerability comes out.

Thankfully my friend does have a lengthy store of FTP logs, and this quick script I banged out will pull out unique IP addresses, quick and dirty-like. I basically search for lines in the logs that contain “PASS – 230” which is the code for an accepted password.

$alllogs = Get-ChildItem “C:\somepath\ftplogs”
$whitelist = @()

foreach ($logfile in $alllogs){
$logcontents = get-content “C:\somepath\ftplogs\$logfile”

foreach ($logline in $logcontents){
if ($logline.Contains(“PASS – 230”))
{$whitelist += $logline.Split(” “)[1]}
}
}
$whitelist | Sort-Object | Get-Unique

Via Bejtlich, for future reference here is the link to log and packet captures from the 2009 Inter-Service Academy Cyber Defense Competition. Check the paper at the top [pdf] for some information on the attacks.

I have a special place in my heart for quotes and zen/koan type stuffs. So I’ve saved reading shrdlu’s recent related post until a laid-back Friday, and I’m happy I did. These security koans are excellent!