Spammers exploit Steve Jobs death

October 7, 2011

By Dave Michmerhuizen – Security Researcher

Apple Chairman Steve Jobs passed away on October 5, 2011. We all share in the sadness of losing such a technology leader, visionary and innovator. Steve impacted our lives in a multitude of positive ways, through his spirit, his creativity and the word-class products he brought to market. Apple’s offerings are both mainstream tools and sources of joy – solving problems and brightening lives everyday, all over the world.  We wish for peace for Steve Jobs and his family.

Unfortunately while many are mourning, others are trying to take advantage of them. Only 24 hours after Jobs’ death spammers began sending insensitive emails claiming otherwise.

Steve Jobs spams

Spams like these capitalize on their shock value. The senders hope that you will be curious just long enough to let down your guard and click on the link.

By now we should all know that these links lead to no good.  Merely clicking on the link in one of these emails leads to a compromised website which redirects the browser multiple times, in some cases finally delivering it to a host serving up the BlackHole exploit kit.

Barracuda Labs is seeing more and more instances of spam linking to servers hosting these exploit kits.   They are increasingly popular with malware distributors because a link has been clicked no further user interaction is required to install their payload.

It saddens us to see these  emails in our honeypots.   Don’t let the amoral scum who send these things take advantage of you. If you see them, delete them right away.

 

Barracuda Networks customers using the Barracuda Spam & Virus Firewall are protected from these emails, while customers using Barracuda Web Filters or Barracuda Web Security Flex are protected from the payload.

Share

Posted in Current Events, Email Security, phishing, Spam, Web Security | No Comments »

Spammers exploit confusion over DigiNotar certificate forgeries

September 15, 2011

By Dave Michmerhuizen & Luis Chapetti – Security Researchers

 

Recently Dutch certificate authority DigiNotar suffered a compromise that resulted in the issuance of over 200 forged certificates for a variety of well known web domains including Google, Yahoo and Mozilla.

The certificates have been revoked and certificate users have been quick to update their products. Spammers and malware distributors have been just as quick to take advantage of the confusing stories about SSL certificates that have been appearing in the mainstream media.

Consider this spam that we recently started seeing at Barracuda Labs. The message, pitched directly to business customers of the Royal Bank of Canada tries to convince them that their SSL certificate has expired.

Spam impersonating Royal Bank

(Click for larger image)

While it may look like  garden variety phishing spam, this message is much more dangerous. The spammers try to create a sense of urgency with the hope that you will click one of the links to see what happens; which, in this case, is a particularly bad idea because the second link in the message directs the browser to a server hosting an exploit kit. Once the browser visits that site a series of attacks begin which can result in the download of Trojan.Buzus. This nasty payload steals login credentials and opens a backdoor allowing remote control of the now-infected computer.

Network traffic of exploit attacks

(Click for larger image)

 

Ever since the blackhole exploit kit became widely available earlier this year, the Barracuda Networks Real Time Protection System has been seeing more and more overtly malicious spam directing users to sites such as these which attempt to force malware onto users computers.  All it takes is one initial click on a link to set off a chain of exploits which require no further interaction to infect a computer. As always, we recommend you treat spam messages with great care.

Share

Posted in Email Security, ID Theft, Internet Security Tips, phishing, Security, Spam | No Comments »

Certificate Authority Hacked, Google Users Fall Victim to Man-in-the-Middle Attack

August 30, 2011

by Daniel Peck, Research Scientist

Yesterday reports began to trickle in that Google users in Iran were victim to a man-in-the-middle attack through the use of an illegitimate SSL certificate issued for “*.google.com”.  This is the latest in a series of events involving a hacked Certificate Authority, but this time there was clear evidence that the fake certificate was being actively used.  Details of the attack and consequences are being written about extensively elsewhere, so we will give a brief overview and link to those directly involved and others with particularly insightful analysis.

The certificate being used was issued by a Dutch certificate authority, DigiNotar. The consequence is that this CA has essentially been given the “death penalty”. Microsoft, Mozilla and Google have removed the DigiNotar root certificate from their chain of trust and certificates signed by them will have no more trust than one you generate yourself.  It is good to see that those who have the strongest position when choosing which certificate authorities to trust are doing the right thing here, with a technology that so many people rely on for security, privacy and economic reason a “one strike and you’re out” system is appropriate.  With each attack similar to this one, we see that the current system of Certificate Authorities is quite open to abuse with the combination of centralized and opaque trust.  Compromises of that trust can have severe consequences.  The system is clearly broken, and while some are working on replacement solutions, it is what we have to use in the mean time.

Users are advised to remove the DigiNotar root certificate.

Firefox:
http://support.mozilla.com/en-US/kb/deleting-diginotar-ca-cert

Chrome:
http://googlechrometutorial.com/google-chrome-advanced-settings/Google-chrome-ssl-settings.html

IE:
Some newer versions of Windows seem to be automatically checking a CRL and therefore are able to provide protection without a software update: “All supported editions of Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 use the Microsoft Certificate Trust List to validate the trust of a certificate authority. There is no action required for users of these operating systems because Microsoft has removed the DigiNotar root certificate from the Microsoft Certificate Trust List.”

However older versions of Windows do not provide automatic protection:” Microsoft will release a future update to address this issue for all supported editions of Windows XP and Windows Server 2003.”

http://www.microsoft.com/technet/security/advisory/2607712.mspx

The DigiNotar root will be being removed from relevant Barracuda Networks products.

 

Further reading:

Google Online Security Blog: An Update on Attemped Man-in-the-Middle Attacks

DigiNotar Response: Diginotar Reports Security Incident

EFF: Iranian Man-in-the-Middle Attack Against Google Demonstrates Dangerous Weakness of Certificate Authorities

 

Tools/Possible SSL Alternatives for advanced users:

Certificate Patrol for Firefox

Convergence

 

Share

Posted in Current Events, Security, Web Security | No Comments »

How a LinkedIn notice could empty your bank account

August 27, 2011

By Dave Michmerhuizen & Luis Chapetti – Security Researchers

Banks

We see a lot of spam at Barracuda Labs.  Sometimes they’re as simple and straightforward as a Viagra ad, but just as often they can be as serious and as devastating as an urban mugging.  We’ve been watching one of those muggings play out over the past few days, and it has reminded us that spam is nothing to take lightly.

Early on the morning of August 23 the spam monitors at Barracuda Labs started detecting a large number of emails claiming to be from LinkedIn.  The quantities were significant, tens of thousands an hour, and these were pretty convincing messages.

Linkedin spam

As convincing as they may be these emails have nothing to do with LinkedIn.  The from address is fake and the “Follow this link” hyperlink leads to one of a set of recently registered domains deliberately set up to serve malicious content

LinkedIn spam

 

Most of these sorts of spam attacks simply link to a malware file which the browser then downloads and offers to run. If an antivirus doesn’t intercept such a file then Windows will ask for permission to run it and it is easy enough to say no.

But this attack is different and much more serious. Each of the malicious domains such as linkedin-reports.com or linkedin-alert.com hosts an exploit kit, a set of malicious payloads that quietly attempt to take advantage of weaknesses in the Web browser and its helper applications.

Clicking on the “follow this link” hyperlink in the message doesn’t appear to have any effect. Nothing seems to happen; however there is a lot going on behind the scenes.

Below is what the behind-the-scenes network traffic looked like.

Network traffic of exploits

(Click for larger image)

This traffic capture shows a series of attacks against Internet Explorer (1), against the Adobe PDF reader plug-in (2) and finally against Windows Media Player (3).  Eventually these exploits result in the download of Trojan.Jorik (4).

Trojan.Jorik is a password stealer which gets right to work, periodically checking in with its command and control server (5).

After contacting the control server the Trojan contacts another server (6) for an interesting – and somewhat scary – configuration file.

Update with phishing HTML

(Click for larger image)

 

These password-stealing Trojans are programmed to insert themselves into the browser stack and can intercept login pages even before they are encrypted by HTTPS.  The list above shows the services that the Trojan is being configured to monitor.  There is more configuration that is not shown in this graphic – pages of HTML code snippets to be injected into login pages. When a login page for one of the monitored sites is displayed, the corresponding code snippet is added to the page. These code snippets ask for additional security questions or special passwords, information the password thieves want but questions that the legitimate login page does not ask.

Having your online banking credentials stolen is serious stuff, especially if the credentials belong to an organization or business with a hefty bank balance.  Consider the most recent story from Brian Krebs about the Cyber Theft of $217,000 from a nonprofit in Nebraska.

 

With so much spam circulating through email servers worldwide, it is easy to become insensitive to the very real danger that  truly malicious spam poses.  Never let down your guard, and never ever follow links in emails even if they appear to be official looking. As you can see from this example, one click can be all it takes.

 

Barracuda Networks customers using the Barracuda Spam & Virus Firewall are protected from these emails.

Share

Posted in Email Security, Internet Security Tips, phishing, Spam, Web Security | No Comments »

Do you ever worry about police impersonations?

August 18, 2011

by Shawn Anderson – Security Researcher

Have you ever driven down the road with a police vehicle right behind you? Do your nerves heighten and your stomach drop? This happens to a lot of people, and when the flashing lights turn on there is one thing to do. Pull over, right? The pure adrenaline rush from thinking, “What did I do wrong?” masks the paranoia of whether or not the person is really a police officer.

What would happen if you received an email from the police department stating that you were in violation of the law? Would your stomach drop and your nerves kick in as though the police vehicle just turned on its lights behind you? Would you stop to think whether the email is legit or not? Unfortunately, impersonating the police can be very effective for spammers who are trying to persuade recipients to click on a link or open an attachment. Forcing the recipients to consider their possible guilt can distract them from questioning the legitimacy of the email itself.

At Barracuda Networks, we are witnessing a large spam outbreak with malicious attachments that impersonates (spoofs) the New York State police. The email states that the recipient was in violation of the law, and contains a description of the traffic violation. It also claims to contain the actual ticket as an attachment with instructions to open it, print it and send it to ‘Town Court’ in some small town somewhere in New York state

The attachment is actually malware, a variant of Trojan.Downloader. If run, it downloads Trojan.Fakealert which further compromises the computer.

Emails like these teach a very important lesson. Many malicious spam messages go to great lengths to appear to be sent from some official government agency or other large organization. Unfortunately the contents of email messages are very easy to fake. The sad truth is that you should never assume that an email message is legitimate. Instead, if an email raises concerns you should verify the contents by phone or postal mail, and never run emailed attachments like the one in the message above.

Tips for configuring your spam firewall to block this attack:

Currently, the malicious spam is spoofing the “From” address domain of “nyc.gov”. Since “nyc.gov” has a Hardfail SPF record set up in its DNS txt record, most conventional filters will block these spoofed messages. Enabling SPF on your spam filter will help block these spoofed emails.

It is common, however, that these types of malicious outbreaks will rotate their sender domains, and it is likely that they’ll spoof other state domains. SPF records are not always set up or set up properly in DNS for domains that are commonly spoofed, so relying solely on the SPF filter is not recommended. Other content scanning techniques are required to block these attacks as they rotate sender domains. Customers using the Barracuda Spam & Virus Firewall should make sure their Energize Updates are up to date and that they are on the latest version to help block these types of malicious emails.

 

 

 

Share

Posted in Email Security, Security, Spam | No Comments »

Malformed DHCPv6 packets cause RPC to become unresponsive

August 16, 2011

by Thomas Unterleitner

There is a vulnerability in the part of RPC processing DHCPv6. The failure results because of incorrect handling of malformed messages. On July 28, 2011, this vulnerability was confirmed and reported by Microsoft.

To exploit this vulnerability, an attacker would need to intercept DHCPv6 traffic. Once a DHCPv6 Request has been intercepted, the corresponding Reply would have to be modified to contain the malformed Domain Search List option. On reception of this malformed packet, RPC on the remote machine would fail. Exploiting this vulnerability would cause the RPC service to fail, losing any RPC-based services, as well as the potential loss of some COM functions.

Failing RPC calls might interfere with the following:

- network connectivity (no IP address acquired, no IP address release/renew, …)

- applications using COM/DCOM interfaces

- machine’s sound system
The error has been found to occur on reception of DHCPv6 Reply (message type 7) packets, containing the option “Domain Search List” (option type 24) with an empty domain.

Affected Systems

Using the sample DHCPv6, it was possible to verify this issue on the following operating systems and configurations:

*       Microsoft Windows 7 Ultimate SP1 32 bit & 64 bit
It is very likely that other versions of Windows 7 (and maybe earlier) are affected by this issue.

Impact

1.      Reception of a “malformed” DHCPv6 Reply packet causes critical error 0xc0000374 within rpcrt4, leaving the RPC server to become unavailable.

a.) ipconfig /release <adapter_name> reporting: An error occurred while releasing interface <adapter_name>: The RPC server is unavailable.

This enables e.g. rouge DHCP servers to prevent other machines from connecting to a network.

Acknowledgments

This vulnerability was discovered by Michael Burgbacher and Thomas Unterleitner on behalf of Barracuda Networks AG. The complete advisory is available here.

Share

Tags: , ,
Posted in Research, Security | No Comments »

Validating validation

August 10, 2011

by Daniel Peck, research scientist

Coders get a bum rap about code quality with regard to security.  Some of the berating is deserved, like when they try to roll their own crypto algorithms (these people should get the 21st century equivalent of stocks in the public square and rotten fruit pelted at them), but other times it is much more subtle and things that an “end user” coder shouldn’t have to worry about at all.

Success in increasing code quality comes from making it very difficult for a developer to do the wrong thing, making sure that the path of least resistance is also the most correct path.  Unfortunately as some programming languages have come to be used as much by designers and artists than the more mathematically included coder of old, a mindset of working around the coder and giving them results that they expect rather than what they’ve asked for has become common.  This leads the developers to think they’re doing the right thing, while actually shooting themselves in the foot.  A friend of mine (hat tip to @suburbsec) pointed me to a very good example of this the other day on one of spotthevuln.com’s latest entries.

if ( (int) $_REQUEST['w'] && (int) $_REQUEST['h'] ) {
 $choice = array(
 'type'   => "Custom size ({$_REQUEST['w']}x{$_REQUEST['h']})",
 'width'  => $_REQUEST['w'],
 'height' => $_REQUEST['h']
 );
}
...
<iframe src="../../../wp-login.php"
        width="<?php echo $choice['width']; ?>"
        height="<?php echo $choice['height']; ?>"
>your browser does not support iframes.</iframe>

Anyone with a bit of programming knowledge can see that the developer is writing this bit of code with security in mind, testing to make sure that the parameters w and h are indeed string representations of integers before displaying them.  Otherwise they wouldn’t cast to an int, right?  Wrong.  Perfectly valid assumption, but it doesn’t hold true in the land of PHP (a place where black is white, cats and dogs live together, and notions of computational science have no place).

$_REQUEST['w'] and $_REQUEST['h'] still retain the same values as before the int cast, as they should, but if they contain values like “11<bad juju here>” the cast would still return an integer value, 11, and the script is now a funhouse for, admittedly lame, reflected xss.  Another interesting side effect of this function is that either of the variables is “0″ – which last time I checked is still an integer. The test fails as a side effect of the test being done in a boolean context and not a type context.  In this case, the result is a trivial xss bug but similar snippets can be pulled from many codebases that lead to all sorts of problems with the developers honestly believing they’ve performed all the reasonable steps to ensure input validation.  For this particular problem, a much better approach would be to use the is_numeric function for testing or to assign the value of the cast to the variable you’ll be using later, but you’d have a tough time figuring that out by searching for “php string to int”.

It needs to be difficult for the coder to deliver a working product while holding onto false assumptions, and it is up to the languages, frameworks, and development tools to make that more of a reality. Less “more than one way to do it” and more “this is the right way to do it” would go a long way to towards making web security less of a trainwreck than it currently is.

Share

Posted in Security, Web Security | No Comments »

Spam Legitimacy Through Url Redirection

August 9, 2011

by Daniel Peck, Research Scientist

Usually relegated to little more than page filler on vulnerability assessment reports, open URL redirection is a vulnerability that doesn’t usually affect the site owner, but can be leveraged to add a sense of false legitimacy to spam and phishing links going through it. This is nothing new in the world of spam, but we haven’t seen a lot of it in social network spam until recently. What usually is easy for moderately savvy users to detect becomes much more difficult when shared through a Facebook link, which as we’ve seen before is trivial for malicious types to create with “likejacking” when an unsuspecting user visits their page.

 

In this particular case the spammer is leveraging an open redirect on news.bbc.co.uk, a site that most users would see as trustworthy to redirects to a site that is far from legitimate.  It seems to only be being used to push users towards the typical affiliate spam that we often see with social network scams, but similar approaches could be very successful in a more malicious context.  While it does not solve the redirection issue, one way to avoid the viral spread of these scams is to log out of social media sites like Facebook when you aren’t using them, as then you will be prompted to login if the page tries to post to your account. For more savvier users browser add-ons such as ShareMeNot and NoScript can be used to block access to Facebook resources from sites other than Facebook. From a developer perspective, to make sure that your sites aren’t being used to add false trust to spam campaigns redirects should be validated, and limited as much as possible through a list of whitelisted urls that are allowed to be redirected to, or an intermediary page advising the user of the redirection. For more information the the type of vulnerability itself and mitigations check out this great post from Googles Webmaster Central Blog.

Share

Posted in Social Networking, Spam | No Comments »

Google+ Gets a “+1″ for Browser Security

July 21, 2011

by Ray Kelly, Manager of Client Side Technologies

 

+1Launching a new Web app today comes with a few certainties, and one of them is, “I will be a target for hackers” for sure.  So when an app as large and as high profile as Google+ launches, it will surely be one of the top targets for malicious activity.  This happened to Facebook the more popular it grew and it still is a favorite platform for malicious activity.  I did some analysis of the HTTP traffic between Google+ and the browser and found that Google is off to a good start in regards to browser security. Below are several take-aways:

Only SSL!
All Google+ traffic is sent over SSL and non SSL is not even an option.  This protects users’ traffic from getting sniffed and their sessions from being hijacked.  It is good to know that Google understands that sensitive information is being shared and SSL is really the only option for transmitting data.

Secure Headers
Here is what a typical response looks like from Google+:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 184942
Set-Cookie: ULS=somehash; Path=/; Secure; HttpOnly
Date: Fri, 15 Jul 2011 14:29:05 GMT
Expires: Fri, 15 Jul 2011 14:29:05 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE

There are a few headers in this response that are specific to browser security, for example:

Set-Cookie Secure – This tells the browser to only send cookies over a secure (SSL) connection.  So if the site happens to hit a page that is not SSL, then the cookie will not be sent.

Set-Cookie HttpOnly – This prevents the cookie from being accessed by client side script.

Both of these cookie attributes help to prevent  session hijacking by only sending cookies when appropriate.

X-Content-Type-Options: nosniff – This prevents “mime” based attacks. The header instructs the browser not to override the response content type.  For example, some browsers try to be smart by deciding for themselves if the content is really is text/html or an image.  So with the nosniff option, if the server says the content is text/html, then the browser needs to render it as text/html.

X-Frame-Options: SAMEORIGIN – This tells the browser to only render frame pages from the URL hosting the main page.  This prevents Clickjacking attacks against the user.  Clickjacking is a browser-based attack that tricks the user into clicking on one thing but then performs a different action, such as following a user on Twitter.

X-XSS-Protection: 1; mode=block – This allows the browser to detect a cross site reflection attack.  If the browser sees a potential reflection attack, it will prevent the page from rendering in the browser.  Instead, you will see something similar to this depending on the browser:

 

What about Facebook?
While these preventions are by no means ground breaking or new, the fact that Google is thinking about and using them is a good step.  In contrast, let’s look at a typical Facebook response:

HTTP/1.1 200 OK
Cache-Control: public, max-age=604800
Content-Type: application/x-javascript; charset=utf-8
Expires: Fri, 22 Jul 2011 14:46:37 GMT
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
X-Frame-Options: DENY
Set-Cookie: _e_syaN_0=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com; httponly
X-FB-Server: 10.52.238.45
X-Cnection: close
Date: Fri, 15 Jul 2011 14:46:37 GMT
Content-Length: 24032

It is surprising that Facebook has not taken the same simple precautions that Google+ has taken. Here, we can see the differences:

Secure Cookie Nosniff XSS Protection X-Frame HttpOnly Cookie SSL
Google+ Yes Yes Yes Sameorigin Yes Yes
Facebook No No No Deny Yes Optional and not default

In fact, just yesterday Microsoft’s Vulnerability Research team released advisory MSVR11-007: “Clickjacking Vulnerability in Facebook.com Could Allow Account Compromise”.   According to the advisory, Facebook has resolved the issue.  I did another check of the headers and still did not see any change to the response.  It is possible that Facebook closed the hole on the server side with input validation in order to prevent the malicious data from entering their database, but they still did not implement the simple browser precautions that Google+ has.   Here is the link to the official MSVR advisory:
http://www.microsoft.com/technet/security/advisory/msvr11-007.mspx

The folks from SecTheory/WhiteHat Security have an excellent write-up on Clickjacking.  For detailed information on this vulnerability visit:
http://www.sectheory.com/clickjacking.htm

 

Conclusion
Unfortunately, not all of these headers are supported in all browsers, meaning any of you still using IE6 won’t be able to take advantage of these headers.  What’s this mean for you? Make sure you are using an up-to-date browser to take full advantage of these protections.

Do these security measures make Google+ impervious to malicious activities?  Absolutely not.  Is it a good start?  Yes, it is. And further, it is good to see an app make its debut with security in mind.  It actually gives us Infosec folks a bit of hope that developers are listening and doing the right thing.

 

 

 

 

Share

Tags: , , , , ,
Posted in Internet Security Tips, Research, Security, Social Networking, Web Security | 9 Comments »

Fake Google+ invites used to harvest Facebook profiles

July 13, 2011

by David Michmerhuizen – Security Researcher

A common denominator of Facebook scams is that they offer you something you can’t resist.  Whether it be free Farmville coins, a ‘Dislike’ button, or just a girl in a short plaid skirt, if it’s desirable then you’ll eventually see it offered on Facebook as part of a scam.

And so it is with the latest must-have digital chotchka, an invitation to the new social networking offering from Google, Google+.  Since Google’s new project is aimed squarely at Facebook you would hardly expect to see such invitations offered on Facebook, but that’s where they’re showing up

Google Plus invite in Facebook news feed

Google Plus invite in Facebook news feed

Clicking on one of these news feed items brings up an actual Facebook application page.    These app pages are being taken down by Facebook and scammers are creating new ones, as seen here:

Facebook fake Google plus invite application

Facebook fake Google plus invite application

The reason for selecting an application for this scam is that applications can, if allowed, access otherwise private information from your Facebook profile.   That’s just what this app does.  Clicking on any of these links takes you to a page where the application requests permission to access your Facebook data, and it really does ask for quite a bit

Permissions request

Permissions request

This appears to be the entire point of this scam – email and account data harvesting.  The only other thing the application does is to spread to your friends.   First you are asked to ‘Like’ the app, which will cause it to appear in your friends’ news feeds.

"Like" step

"Like" step

Then, just in case items from you don’t appear in your friends’ news feeds, there is one more step: you are asked to explicitly send “invites” to your friends.

Fake "invite" step

Fake "invite" step

Instead of actually sending invites, you’re sending Facebook requests that will appear in the notification queue of each friend you select.

Once you are past this point you wind up on the Google+ home page, and when you try to log in – surprise – you haven’t been invited.

 

As always, we at Barracuda Networks recommend that you approach any wall post that appears in your news feed with great caution.   If they seem to be too good to be true, double-check with the person whose name appears on the post.  Additionally,  Barracuda Web Filters give IT departments the ability to selectively block Facebook within the organization.

 

 

 

 

 

 

Share

Posted in Internet Security Tips, Social Networking, Web Security | No Comments »

« Older Entries
Newer Entries »