This month, Microsoft issued 5 security bulletins covering 15 vulnerabilities in Excel and Windows. These updates are considered important rather than critical, as by the time of the patch there was no malicious code exploiting the vulnerabilities in the wild. Adobe also released a security bulletin patching 13 vulnerabilities in Acrobat Reader. Websense® Security Labs highly recommends applying the updates in order to avoid cyber criminals who may use these security holes for their malicious activities.

Arguably the most important bulletin is MS11-072, which targets five different vulnerabilities in Microsoft Office. An attacker could use any of these to execute arbitrary code on the computer with the same access rights as the user. This is a focus for any security researcher as hackers are constantly looking for newer ways to distribute their badware. Such issues are probably getting more and more headlines as Adobe's sandboxing system and regular security patches seem to be paying off, meaning an up-to-date system is much less prone to successful exploits by vulnerabilities in PDFs.

This does not mean, of course, that we will see no more vulnerabilities in Acrobat Reader. This Tuesday Adobe Issued a security bulletin too, fixing 13 vulnerability issues in their product. Each of the vulnerabilities could allow an attacker to execute a code on the host computer allowing them to take full control of it. This patch is rated as critical, therefore it is strongly recommended to apply it.

Also worth mentioning is that many companies have updated their DigiNotar certificates - Microsoft, Adobe, and even Mozilla Firefox issued the updates. Firefox even released an additional security patch targeting this issue. Please check that you have applied the latest updates so you are fully protected.

Is your organization using the latest Firefox 6 or Internet Explorer 9? Which one did you find more secure? Give us your thoughts in the comments.

Vulnerabilities patched by Microsoft on 13 September 2011:

MS11-070 WINS Local Elevation of Privilege Vulnerability (CVE-2011-1984)

MS11-071 Windows Components Insecure Library Loading Vulnerability (CVE-2011-1991)

MS11-072 Excel Use after Free WriteAV Vulnerability (CVE-2011-1986)

MS11-072 Excel Out of Bounds Array Indexing Vulnerability (CVE-2011-1987)

MS11-072 Excel Heap Corruption Vulnerability (CVE-2011-1988)

MS11-072 Excel Conditional Expression Parsing Vulnerability (CVE-2011-1989)

MS11-072 Excel Out of Bounds Array Indexing Vulnerability (CVE-2011-1990)

MS11-073 Office Component Insecure Library Loading Vulnerability (CVE-2011-1980)

MS11-073 Office Uninitialized Object Pointer Vulnerability (CVE-2011-1982)

MS11-074 XSS in SharePoint Calendar Vulnerability (CVE-2011-0653)

MS11-074 HTML Sanitization Vulnerability (CVE-2011-1252)

MS11-074 Editform Script Injection Vulnerability (CVE-2011-1890)

MS11-074 Contact Details Reflected XSS Vulnerability (CVE-2011-1891)

MS11-074 SharePoint Remote File Disclosure Vulnerability (CVE-2011-1892)

MS11-074 SharePoint XSS Vulnerability (CVE-2011-1893)

Vulnerabilities patched by Adobe on 13 September 2011:

Local privilege-escalation vulnerability (Adobe Reader X (10.x) on Windows only) (CVE-2011-1353).

Security bypass vulnerability that could lead to code execution (CVE-2011-2431).

Buffer overflow vulnerability in the U3D TIFF Resource that could lead to code execution (CVE-2011-2432).

Heap overflow vulnerability that could lead to code execution (CVE-2011-2433).

Heap overflow vulnerability that could lead to code execution (CVE-2011-2434).

Buffer overflow vulnerability that could lead to code execution (CVE-2011-2435).

Heap overflow vulnerability in the Adobe image parsing library that could lead to code execution (CVE-2011-2436).

Heap overflow vulnerability that could lead to code execution (CVE-2011-2437).

Stack overflow vulnerabilities in the Adobe image parsing library that could lead to code execution (CVE-2011-2438).

Memory leakage condition vulnerability that could lead to code execution (CVE-2011-2439).

Use-after-free vulnerability that could lead to code execution (CVE-2011-2440).

Stack overflow vulnerabilities in the CoolType.dll library that could lead to code execution (CVE-2011-2441).

Logic error vulnerability that could lead to code execution (CVE-2011-2442).

Websense Security Labs and our ThreatSeeker Network are constantly monitoring for these threats occurring in the wild.

A few days ago I received a spam email from my friend Jack on my personal Gmail account. The email came from his Yahoo! Mail account and looked in every way legitimate, except that it had no subject and contained only a link. The recipient list, unlike many spam bulk emails, wasn't even in alphabetical order.  

About an hour later I received another email from the same friend, this time sending a legitimate bulk email to multiple recipients apologizing for spamming them.

Email spam coming from your account is embarrassing, and in all cases the first thing you should do is change your password because the most likely cause of spam email being sent from your account is that your email password credentials were stolen.

Was His Email Account Hacked?

Jack, who I contacted for more details, at first refused to believe that his password was compromised, until I laid out two possible reasons why spam had been sent out from his account and let him decide which was more likely:

1. Yahoo!'s private key had been stolen and used to sign spam emails.
2. His Yahoo! email password, which he most likely uses on multiple Web sites, was somehow phished or stolen.

Being the smart friend that he is, Jack went with option number 2.

DKIM Signatures

Let me share how I came to my conclusion and how DomainKeys Identified Mail (DKIM) verification can be used in analysis to verify that the email sent came from Yahoo!, was not forged, and that his credentials were used to send the email.

Figure 1: Spam Email - click this link to view the original email with headers removed for privacy reasons.

For the purposes of this blog post, I'm going to focus less on what happens to the user when they click on the URL, and more on how we can determine whether the email was sent from Yahoo! using the credentials of the user in question ( I will state that Websense had the URL above categorized into Web and Email Spam as it's a Fake Canadian Pharmaceutical website).

When you look at an email, much like a Web page, there is more than meets the eye on the details behind that email. Gmail allows you to view the email as we see it above or in its original form, which has more details than the average person would ever want to see. Here is a snippet:

Figure2 : Spam Email snippet in original form with personal details removed

One interesting header in the email is the header called the DKIM signature:

The DKIM signature is a signature used by the SMTP receiver of an email to verify that it came from the sender it claims to come from and that the message hasn't been tampered with.

DKIM Algorithm 

In this case Gmail received a message from Yahoo!, looked at the DKIM signature, and applied the following algorithm:

1. Took a SHA-256 as the cryptographic hash of the message.
2. Signed SHA-256 hash using RSA as the public key encryption scheme.
3. Encoded the encrypted hash using Base64.

So, for someone to send an email claiming to originate from Yahoo! and pass through a server that checks the DKIM signature, they would have to obtain the private key that Yahoo! uses for signing email messages from Yahoo! mail servers.

Verifying DKIM Signatures 

Let's manually verify the DKIM signature to make sure it came from Yahoo!.

To do this we have to retrieve Yahoo!'s public key. To retrieve DKIM public keys the SMTP receiver uses DNS and looks at the TXT resource record type.

Using the s and d fields in the DKIM signature, which stands for the selector, we're going to make a manual DNS query for the TEXT resource record type for a host in the form: s._domainkey.d

s1024._domainkey.yahoo.com is the host we'll want to do the DNS look up the public key.

We can programmatically do this with a PERL using a set of scripts I co-wrote with my colleague David Saunders. The first script will pull the public key from the DNS request:

./get_dkim_key.pl s1024._domainkey.yahoo.com

host: s1024._domainkey.yahoo.com key: k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrEee0Ri4Juz+QfiWYui/E9UGSXau/2P8LjnTD8V4Unn+2FAZVGE3kL23bzeoULYv4PeleB3gfm JiDJOKU3Ns5L4KJAUUHjFwDebt0NP+sBK0VKeTATL2Yr/S3bT/xhy+1xtj4RkdV7fVxTn56Lb4udUnwuxK4V5b5PdOKj/+XcwIDAQAB; n=A 1024 bit key;

Figure 3: Script to fetch Yahoo! DKIM public key - full script source code can be found here

As you can see, the script above fetches the DKIM public key which allows us to verify the message. To accomplish this we could use PERL's Crypt::OpenSSL::DSA or various other libraries and languages, but instead we're going to use a CPAN module Mail::DKIM::Verifier against the initial message that includes the DKIM signature and all lines below to verify whether the message is valid and hasn't been tampered with. Mail::DKIM::Verifier will even download the public key so you don't have to fetch it explicitly. Here is a script you can use for verification of an email message that includes a DKIM signature:

./dkim_verify.pl message.txt

file: message.txt

pass

message.txt passed DKIM validation

Figure 4: DKIM verification script - full script source code can be found here

Conclusion

OK, so let's tie this all together. We received a SPAM email and wanted to verify that it came from Yahoo! as opposed to an open relay or a server claiming to be Yahoo!. The email message contained a DKIM signature, which we used to verify the DNS domain, the email sender, and the message integrity. Using the provided scripts, we verified this information, which led us to conclude that:

1. The email message was sent from Yahoo!.
2. The headers, including who it was sent from, were not forged.

All of this leads us to the conclusion that the person's email account that the spam email was sent from was most likely compromised by stolen password credentials. This isn't to say that digital certificates can't be stolen or replaced, this can happen, e.g. DigiNotar CA, but these types of occurrences are rare.

Back to my friend Jack, a smart technical guy who probably still doesn't understand how his credentials were stolen. Upon questioning Jack, he disclosed his password to me, which wasn't one I'd consider easy to brute force, but added that he uses that password on multiple Web sites and had recently signed up for about 4 different sites using that password where he used his email address as his username.

My advice to everyone is never use your email address password anywhere else but for your email account, and especially not on sites where your user name is your email address and your password is the password you use for that email address. You should realize that Web site databases get compromised all the time, so whether Jack's credentials were stolen because he was unknowingly phished, his computer had a keylogger on it, or one of the sites he registered for using his email address and email address password stole it, we'll never know. The important thing is that after such an incident to change the password to your email account.

DKIM signatures are used by all major Web-based email providers, including Yahoo!, Gmail, Microsoft Live, etc. If you see a DKIM signature, you can verify the DNS domain of an email sender and the message integrity by using the PERL scripts linked in this blog.

For More Information on DKIM:

• RFC 4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)
• RFC 4871 DomainKeys Identified Mail (DKIM) Signatures

Please leave feedback or comments, so we can make sure to fully address any questions or concerns you have.

Thanks!

Stephan Chenette - Principal Security Researcher

Websense® ThreatSeeker® Network has been tracking a large number of messages masquerading as legitimate messages from the Electronic Payment Association NACHA.

The messages bear legitimate traits, as the display name and routing details seem to confirm.  Further analysis of the message and attachments prove these to be malicious in intent.  The examples below show what these messages look like, and an unsuspecting member or patron of the service might just fall for this.

The example below is a variant that we have been aware of, and have been tracking for a while now.  The use of a double extension on a file name as well as the exact format of the message, including the Subject, attests to the reuse of the campaign.

Example of a variant noticed earlier:

 Digging a little deeper for the header Information, we find this:

Although this might seem to have come from NACHA, the routing details suggest otherwise as they do not originate from the publicly-known MX records for the organization.

At the time of analysis, VirusTotal results still had not hit 50%, and a mixed bag of detection shows that not all the major AV engines have detected this either.  Websense Email Security and Websense Web Security protect against these kinds of blended threats with ACE, our Advanced Classification Engine.

Websense® ThreatSeeker® Network has detected that the Web Directories site (http://www.web-directories.ws) was compromised on 4th September, 2011. This lead users to the Incognito exploit kit.

Web Directories is a site designed to help Webmasters and site owners find relevant directories. They intend to offer one of the largest Web directories listing on the Internet. This site has heavy global Alexa traffic, especially from Asia. It is estimated that over 60% of visitors to this site are from India, which has an Alexa traffic ranking of 885.

 The Web Directories homepage:

This site had the following malicious codes inserted:

The link hxxp://dire-straits.co.uk/stat.php redirects you to another malicious site hxxp://hertscycle.cu.cc/showthread.php?t=67640185 that contains the exploit codes.

 
From our analysis this code belongs to a notorious exploit kit - Incognito exploit kit. When redirected, a Trojan is silently downloaded to unsuspected clients, and infects them in the process.

 We also detected many other Web sites injected with similar codes:

Websense customers are protected from Web-based threats by ACE, our Advanced Classification Engine.

In this week’s Websense Security Labs video, researchers Armin Buescher, Stephan Chenette and Gregory Newman introduce us to “Morto,” a very unusual worm spreading across networks. Unlike your typical PC malware, Trojan or Rogue AV, Morto is unique because of the curious and unusual ways in which it propagates. In this video, find out how Morto takes advantage of weak passwords to infiltrate and the atypical approach it takes to compromise additional hosts.

Websense Security Labs™ and the Websense ThreatSeeker® Network have detected malicious emails posing as a consumer complaint notice from the Federal Trade Commission.   

Using names of government agencies as a ploy in this kind of malicious attack is anything but new.  We have reported that both the National Security Agency and the Federal Reserve were used in malicious campaigns.  The Philippine Bureau of Immigration's Web site got compromised early last month, and was even hosting a malicious file. 

The FTC campaign was first reported a few years back. It's interesting that in this case, as in other campaigns Websense Security Labs has seen, the content of the messages is almost always the same.  The exact email format seen in this case (shown above) was also used a few years back.  One sure thing that's different is the binary involved.  Malware authors constantly change the malicious file involved in their campaigns. The malware is poorly detected by AV engines.

Websense Email Security and Websense Web Security protect against these kinds of blended threats with ACE, our Advanced Classification Engine.