http://isc.sans.org en-us Sat, 07 Nov 2009 14:55:01 +0000 Fri, 06 Nov 2009 22:43:05 GMT (C) SANS Institute 2009 isc rss feed maker 30 handlers@sans.org (ISC Handlers) http://isc.sans.org/images/status.gif http://isc.sans.org http://isc.sans.org/diary.html?storyid=7543&rss http://isc.sans.org/diary.html?storyid=7543&rss

Due to the recent publishing of information regarding a TLS/SSL protocol vulnerability (previous ISC diary entry can be found here http://isc.sans.org/diary.html?storyid=7534) OpenSSL has released a new version (OpenSSL 0.9.8l). It should be noted that this update does not fix the vulnerability in the protocol. It appears that they have made the choice to simply remove TLS/SSL renegotiation from their package by default. I would urge anyone who is running a SSL enabled site that uses OpenSSL to thoroughly test their application as well as any software clients that are in used with their application. There has been some discussion on the effects of simply removing renegotiation from these packages or disabling them by default (as OpenSSL has done). There will no doubt be instances where clients/servers will cease to function properly when renegotiation is disabled or removed. The nice thing about what OpenSSL has done is if you do run into issues, it appears to be an easy fix (set a flag and -hup!). So as always make sure to test vigorously before you deploy!
You can get this new version of OpenSSL at the link below.
http://www.openssl.org/source/


Release note from OpenSSL package:

Disable renegotiation completely - this fixes a severe security

problem (CVE-2009-3555) at the cost of breaking all

renegotiation. Renegotiation can be re-enabled by setting

SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in s3-flags at

run-time. This is really not recommended unless you know what

you're doing.

[Ben Laurie]

This event will no doubt develop over the next coming weeks and months, it should be interesting to see how far research goes into other protocols that ride on top of TLS/SSL channels. Let us not forget that not all traffic that is TLS/SSLencrypted is HTTP. Just off the top of my head I can think of LDAP, MSSQL, Email, and let us not forget SSLVPNS! Since this is a bug in a low lying protocol that higher level applications/protocols rely on there will no doubt be allot of interest issues raised. No doubt plenty of people including myself will have a busy weekend rereading the TLS specification. For those who are bored, feel free to read that specification at the URLbelow.
TLS 1.0: http://www.ietf.org/rfc/rfc2246.txt
SSL 3.0: http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00

Andre Ludwig]]> Fri, 06 Nov 2009 22:43:05 GMT http://isc.sans.org/diary.html?storyid=7540&rss http://isc.sans.org/diary.html?storyid=7540&rss Fri, 06 Nov 2009 04:35:51 GMT http://isc.sans.org/diary.html?storyid=7537&rss http://isc.sans.org/diary.html?storyid=7537&rss 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]]> Fri, 06 Nov 2009 02:06:38 GMT http://isc.sans.org/diary.html?storyid=7534&rss http://isc.sans.org/diary.html?storyid=7534&rss While the details had been offered in a meeting with the IETF, vendors and the open source implementers of SSL privately, it appears an IETFmailing 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 TLSworkgroup, 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]]> Thu, 05 Nov 2009 19:03:13 GMT http://isc.sans.org/diary.html?storyid=7531&rss http://isc.sans.org/diary.html?storyid=7531&rss 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 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 worlds 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 : 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]]> Thu, 05 Nov 2009 15:32:05 GMT http://isc.sans.org/diary.html?storyid=7528&rss http://isc.sans.org/diary.html?storyid=7528&rss 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 newall 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 IEusing visitors still were on that legacy version (data from Google Analytics). Not work-related websites also report numbers of 12 to 15% of IEusers not having upgraded to IE7 (itself a legacy version) or IE8.
There is of course a general ITimpact 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 DCarea (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 BCPplan, 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 ITproperly, 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]]> Thu, 05 Nov 2009 09:54:20 GMT http://isc.sans.org/diary.html?storyid=7525&rss http://isc.sans.org/diary.html?storyid=7525&rss Tue, 03 Nov 2009 22:17:28 GMT http://isc.sans.org/diary.html?storyid=7522&rss http://isc.sans.org/diary.html?storyid=7522&rss Tue, 03 Nov 2009 19:57:00 GMT http://isc.sans.org/diary.html?storyid=7519&rss http://isc.sans.org/diary.html?storyid=7519&rss There are some very interesting things about Opachki so let me start at the beginning. The Trojan is distributed with a dropper which, when infecting the system, drops a DLL file. Both the dropper and the DLL file are packed with a packer called Mystic Compressor. Besides this, the trojan never actually decrypts all strings in memory but calls a function to decrypt only what it needs and immediately deletes the data after it is not needed. Finally, the packer destroys PE header data from memory to make dumping more difficult.
Besides dropping the DLL, the dropper also does one vary nasty action: it completely deletes the SafeBoot registry key by calling reg.exe, as shown below:

This prevents the system from booting in Safe Mode the attackers did this to make it more difficult to remove the trojan. This goes well with what I've been always saying do not try to clean an infected machine, always reimage it.
As Opachki's main goal is to hijack links, it hooks the send and recv API calls in the following programs: FIREFOX.EXE, IEXPLORE.EXE, OPERA.EXE and QIP.EXE. While the first three are well known, I had to investigate the last one. It turned out that QIP.EXE is an ICQ client that is very popular in Russia, so the trojan has a component that directly attacks Russian users.
The trojan will monitor web traffic (requests and responses) that above mentioned applications make and will inject a malicious script tag into every response. The injected script tag can be actually seen in the browser (by selecting the view source option) and can be seen in the image below:

This will cause the browser to go to the shown site (google-analystisks.us), which is still live at the time of writing this diary. The site serves back a JavaScript file which modifies all links in the currently shown web page so they are redirected to a third site (http://thefeedwater.com/?do=rphpsub=241b= when I posted the diary). The PHP script at the google-analystisk.us web site is interesting as well if you try to retrieve it directly you'll get an error back so you have to supply a referrer field. It also checks if you came from a search engine (i.e. Google) and returns back a different JavaScript file so it steals search queries as well.
Finally, Opachki performs another interesting action: it tries to see if the system is already infected with ZEUS and will remove ZEUS' files (rename them to C:ntldrs). It will check for all four ZEUS versions by verifying presence of the following files: C:WINDOWSsystem32ntos.exe, C:WINDOWSsystem32oembios.exe, C:WINDOWSsystem32twext.exe and C:WINDOWSsystem32sdra64.exe. I don't know why they do this, it could be that they are hijacking ZEUS or simply competing for same machines or using same attack vectors as the ZEUS crew.
The whole story about Opachki shows how that the bad guys are prepared to invest a lot of effort into building malware. Removing such a trojan is not simple and I would recommend reimaging the machine as the trojan puts a lot of effort into making removing difficult. As the Trojan is specifically attacking Russian users (among the others), it is probably safe to assume that it originates from Russia as well.
Finally, this shows that the bad guys are (probably) making good money by just hijacking links/clicking.
--

Bojan

INFIGO IS]]> Tue, 03 Nov 2009 15:36:36 GMT