Affected: BlackBerry Desktop Software version 5.0 and earlier (on all platforms) - IBM Lotus Notes Intellisync

Fixed in version 5.01

CVSS score: 9.3

CVE-2009-0306

More info: KB19701

The KB contains a workaround for those not eeding the Lotus Notes Intellisync functionality.

Thanks to Greg for sending this in.

--
Swa Frantzen -- Section 66

TLS 1.0+ and SSL 3.0+ (known from among others "https") is vulnerable to a protocol weakness where a man in the middle attack could be worked in during the renegotiation phase in modern versions of the protocol.

While the details had been offered in a meeting with the IETF, vendors and the open source implementers of SSL privately, it appears an IETF mailing list came to finding it again. That seems to have prompted the original finders (Marsh Ray and Steve Dispensa) to offer up their finding publicly.

The news media outlets are obviously all over this. Some links aside of the usual media outlets:

• The original description (site is suffering from a slashdot effect as I write this)
• The summary by the IETF TLS workgroup, and promisses for an amended protocol
• Marsh Ray's paper
• March Ray's protocol diagrams

There does not seem to be much you can do till the protocol is fixed. The main problem seems to be with clients using certificate authentication.

Exploiting this requires the attacker to be able to intercept the traffic.

Thanks to Martin, Edward, Ken and Chris for sending this in.

--
Swa Frantzen -- Section 66

Insider jobs are not often made public. So, when one does come around it's very interesting to try to learn from those we can talk about. Even inside a company often there is not much said about it to other employees, making learning from it extra difficult unless you were involved somehow.

Snapnames is the company fessing up. Snapnames is in the "domain name after market": they grab domains that are expired and sell it in auctions to people they have in their customer base. There are more such companies.

Like any auction driving up the price is supposed to be the interest in the domain. And unlike a regular auction, the seller is the auction house itself - they grabbed it expired, it costs them the absolute minimum to get it, if they sell it for thousands: that's thousands of profit for them.

A shill is "a person who poses as a customer in order to decoy others into participating, as at a gambling house, auction, confidence game, etc." according to the dictionary. It's used in this context as a person who drives up the price artificially.

So what happened ?

• A snapnames employee participated in 5% of auctions since March 2005.
• Snapnames has a fessed up in email to some affected customers about it and is offering financial restitution to those affected by it. They do have a FAQ entry on that available at http://www.snapnames.com/faq.html
• There are rumors that seem to get confirmations that the employee was a VP of engineering using the username of "halvares", and it seems to have been confirmed by the company.
  [I'm not going to republish his real name, there's plenty of places to find it for those interested]
• Forum threads dating back to 2006 have customers of snapnames find the user "halvares" suspicious: http://www.dnforum.com/f205/important-message-snapnames-thread-197282.html
• People who knew said person describe him as "the kind of guy that you wanted working on the other end of the phone; fast, courteous and intelligent.  To find out now that he was lying and betraying not only me, but everyone that he worked with leaves me speechless.  It left a fellow employee I spoke with at SnapNames speechless as well.  With such a small organization, I can only imagine the feeling of betrayal." [From http://www.domainnamenews.com/editorial/snapnames-insider-bidding-aftermath-editorial/6491]
• Namejet -a competitor of snapnames- sent out the following to their customers:

Dear Valued NameJet Customer,

As you may have already heard, another company in our same line of business, SnapNames, was the victim of an internal security breach. We wanted to address any concerns you may have and assure you that at NameJet we have the necessary security protocols in place to prevent this kind of incident.

What Happened at SnapNames:

According to SnapNames, an employee set up an account on SnapNames under a false name. Under this account, the employee bid in SnapNames auctions. In many instances the bidding by this employee caused the ultimate auction winner to pay more for a name than had the employee not participated in the auction. In addition, on certain occasions, when the employee won an auction, the employee secretly arranged for a refund from SnapNames. This was in violation of SnapNames internal policy, and once discovered the company immediately closed the account in question and the employee was dismissed.

We commend SnapNames for taking quick and decisive action once it discovered its security breach.

NameJet has Strict Security to Prevent Anything Similar:

You should have full confidence nothing similar has occurred on NameJet. We have security procedures and policies in place that monitor all activities to ensure that “shill” bidding does not occur. Further, employees are strictly barred from bidding on auctions and NameJet has both internal and external monitoring to ensure all security procedures are enforced. These procedures were developed and are maintained by two of the world’s largest and most trusted registrars.

Thank you for your business and for your ongoing trust in NameJet.

If you have any questions regarding this issue, please contact us at customers@namejet.com.

Sincerely,

Steve Brown
General Manager
NameJet.com  

•  Snapnames is said to have fired the employee and is working with an external party to settle it financially with those they think are affected.

What can we learn ?

• That insider threats can be extremey damaging to your reputation, as evidenced by your competitors jumping all over it.
• That the insider -in order to fly under the radar ?- is perceived as an excellent team member :"[the one] that you wanted working on the other end of the phone; fast, courteous and intelligent.
• Those directly involved will feel betrayed because they trusted too much.
• Polices alone might not be enough, we need to enforce them. And we need to actively detect breaches of our policies.
• Detecting it is difficult. This went on for 4.5 years.
• Suspicions had been raised by their customers after half a year, yet it seems to not have triggered whatever was needed for snapnames to catch him.

What can one implement in the form of controls to detect fraud ?

• A policy prohibiting unwanted behavior. Make sure it passes the "speed limit test":  If -out on the road- it says 50 max and there is no consequence to going faster, who'll bother with it ? Even if there is a fine or other consequence, as long as there is no police officer wielding a radar, who'll care about the fine ?
• Limit access to information using a role based model.
• Use a need to have model for granting access rights.
• Prevent accumulation of rights in any single employee.
• Monitor what people who have broad access permissions to dangerous data do in real life (within limits of the law and regulations regarding privacy etc.), even if you trust them.
• Rotate roles: don't let anybody get a position where they are the only ones doing the same thing every time it needs to be done. Hiding it becomes too easy if nobody else does that task for a long enough period.
• Monitor for indicators changing when you rotate peoples responsibility. Seek the explanation for those changes.
• Monitor for fraud: 5% of your transaction having the same account involved might be enough to dig a bit deeper
• Automatically seek for fraudulent patterns in your transactions. This is the needle int he haystack, but computer are good at searching, as long as we can define the needle good enough.So you need to figure out how fraud could happen and what is unwanted behavior etc. and then find that. E.g. a sales person in your company might have read/write access to the directory where you keep the offers your company creates. But if you find a sales person copying (even slowly) every single offer, you might have a big problem.
• As you learn more ways to commit fraud make sure you monitor for them.
• Monitor for customers expressing suspicions on your users/employees/company outside of your involvement on e.g. forums where the professionals among your customers hang out and feel free to talk. They might not always need to be the type wearing tin foil beanies, sometimes they might have a point that could take years to grow if you don't follow it up..

 Got more lessons to learn or controls to implement, we love to hear about them!

--
Swa Frantzen -- Section 66

IT in general is riddled with legacy system. They are inheritances of a past we 'd like to forget or we might even cherish them. But they have a tendency of harboring nasty surprises.

In an economic climate where investments are a bit less likely than they used to be, there is fear we'll end up with more legacy systems than ever before. Moreover people aren't buying the "shiny new" all that easy anymore regardless of the economic climate.

But there is more. Even free software that is as easy to upgrade to as a single click isn't being upgraded. In controlled corporate environments there might be reasons of compatibility, but even home users don't upgrade to in some striking cases. E.g. IE6 -a decade old browser, hated by anybody doing anything beyond basic CSS- has had 2 new versions people are automatically upgraded to, and yet it still has a population of users that is significant, even among the Storm Center's visitors -last month- more than 17% of our IE using visitors still were on that legacy version (data from Google Analytics). Not work-related websites also report numbers of 12 to 15% of IE users not having upgraded to IE7 (itself a legacy version) or IE8.

There is of course a general IT impact of supporting legacy systems, which can be a pain. Add in the lack of planning for problems with such systems and it all becomes a nightmare scenario. Look e.g. at what hit the news regarding the failing synchronization of traffic lights in the DC area (Thanks for sending this in Angela!). The failure as such is a problem one might argue, but statements like "Parts are not really available" are worrying to a great extend. BCP/DRP issues abound.

But there is also a huge security impact. Threats change. If you run things a decade old -even if the top security bugs do get fixed- you still have an architectural model for your defenses that's a decade old or more. A decade is a lot in IT and in security. A lot changes in that time.  Now you might argue using old technology puts you out of the hot-spot where the attackers focus on. While that is true to a point, attackers, security researchers and bug fixers all focus on the latest greatest version. If we all start to slack in upgrading, the attackers might not shift their focus to where the researchers and fixers of bugs are focusing anymore, changing cat and mouse game to one where the mice aren't being watched by the cats anymore. Moreover we know from dshield data that scans for old vulnerabilities never really stops anyway.

So what can each of us do in our corner do to make the world a better place - and have our customers/employers not end up in the news with 30 year old hardware running a mission critical system and failing impacting many thousands ?

An inventory comes to mind as a first control measure. If you don't even know you have a legacy system, there will be nothing that's going to be done until it fails and hits you.

If you can, figure out for all used hardware and software

• if there is still a way to support it somehow, and how difficult that is
• when the support will be stopped
• how critical it is, and if it's taken into consideration properly in BCP/DRP plans

Make a plan, at least for every legacy system out there. [this is really part of your BCP plan, but I'll assume many lack such detailed plans]

• How will you phase it out
• When is the deadline on having it gone
• How will you support it till then
• How will you ensure security for as long as you still have it

Add to it:

• How will you know when this status changes (vendor might go out of business, release new versions and silent forget the one you still have, stop supporting a version/variant, extend support, ...) ? With the risk of depending on external parties, these updates need to also be done by actively polling for this, passively waiting to be informed isn't going to be enough to prevent you from getting in trouble.

As evident, the BCP and security requirements should be enough to cause some pressure on companies and organizations that manage their IT properly, but that's not going to affect most home users or small businesses who have a motto of "don't fix if it isn't broken" and apply it liberally.

This doesn't mean I'm advocating to be always on the latest greatest version a vendor promotes. Far from it: I'm hesitant to recommend a feeding frenzy over new OSes -of any vendor or make-, but that doesn't mean we ought not to follow the vendors of our choice into upgrading before the vendor forgets all about their previous version.

So how can we convince those that their (unsupported) legacy systems are a bad deal for the rest of us, just as for themselves ?

--
Swa Frantzen -- Section 66