Privacy and vulnerability issues: Could decentralized networks help save democracy?

Democratic movements can flourish online, but just as easily get censored. A group of researchers is developing solutions to the vulnerabilities and privacy problems with using big social media platforms like Facebook and Twitter.

Turkish President Recep Tayyip Erdogan disrupted communications between his opponents when he shut down Twitter during the run-up to the country's recent election. But in doing so, he provided yet more proof of how flawed social web activism can be. Whether the lessons in Turkey are heeded could have serious consequences for democracy.

Social networks such as Twitter and Facebook have enabled unprecedented levels of communication and have even received credit for at least one major democratic revolution. There's just one problem: because of their monolithic nature, these centralized networks expose users to snooping and interference of the kind Erdogan caused, says Sonja Buchegger, Associate Professor of Computer Science at KTH Royal Institute of Technology.

A single, large-scale platform provides an easier target for anyone who wants to interfere with online political activity, says Buchegger. "But, if Twitter were decentralized, and you had users cooperating and communicating directly, that wouldn't have been possible to disrupt.

"Decentralization allows for greater freedom of expression.

The good news is that there could be a computer science answer to the problem. Buchegger is leading a group of scientists at KTH who are creating building blocks that developers could use to launch decentralized, distributed networks, which would not only be difficult to interfere with, but would also protect people from government snooping.

"The internet itself is not centralized -- it would be hard to shut down," Buchegger says. "It was built as a robust, decentralized tool to communicate; and we can do the same for other services that are now centralized, like social networks."

Whether the demand for such networks would go mainstream any time soon is hard to tell. Buchegger notes that it is difficult for most people to wrap their head around the notion that their personal information is exposed on web-based email and social platforms.

"The whole privacy issue online is very young, and the population is not used to thinking in this way," she says. "Offline, we know how to protect our privacy; we know who can overhear us; we see who is in the room with us and we know whether we can trust those people; but online we haven't really grasped who the audience is and how that changes over time."

Buchegger's research is focused on the privacy issues of distributed peer-to-peer (P2P) networks, that is, the underlying infrastructure for a decentralized system in which people could store their data beyond the reach of data miners or government surveillance.

"We are developing these little building blocks: this is how you do passwords in a distributed environment; this is how you do search in a privacy-preserving decentralized environment; this is how you make news feeds; this is how you control access," she says. "Then you can put the building blocks together and build a new communications system -- that's the idea."

For example, encryption tools are being tested that could provide users with "fine grain" control over their privacy. One could use encryption keys to decide specifically who can access or view a given piece of content. "You wouldn't have to worry about all the people you don't want to access it because the default is that access is denied," she says.

The research into privacy tools cuts right to one of the major weaknesses of centralized networks -they rely on centralized data centers for storage, thus exposing millions of people's personal information to prying eyes.

Buchegger says that as far as promoting democracy goes, distributed networks could outshine so-called "Facebook revolutions," encouraging more widespread activism, particularly for those whose only connection to the web is with a phone.

"This is a way of developing the idea of a commons, in which more people get together and organize and share resources," she says. "A decentralized network would also be a sort of commons because you could imagine how people with large servers could store encrypted data for others. It could enable access to resources for those who cannot store so much on their phone."

While distributed networks offer potential for greater communication and more effective organizing, Buchegger is quick to point out that technology is not a quick fix for promoting democracy. Ultimately political action depends on people assembling in the non-virtual world. "There is a danger that you think that just because you repost something on Facebook or Twitter that you are doing activism, but it's not actually doing something.

"Networks can reach more people and be used to organize physical activism, but they're not a substitute for activism."

Cite This Page:

KTH The Royal Institute of Technology. "Privacy and vulnerability issues: Could decentralized networks help save democracy?." ScienceDaily. ScienceDaily, 12 May 2014. .KTH The Royal Institute of Technology. (2014, May 12). Privacy and vulnerability issues: Could decentralized networks help save democracy?. ScienceDaily. Retrieved May 30, 2014 from www.sciencedaily.com/releases/2014/05/140512101634.htmKTH The Royal Institute of Technology. "Privacy and vulnerability issues: Could decentralized networks help save democracy?." ScienceDaily. www.sciencedaily.com/releases/2014/05/140512101634.htm (accessed May 30, 2014).

View the original article here

Apple to fix iPhones' vulnerability to boobytrapped chargers

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Following a Black Hat demonstration on Wednesday in which researchers plugged an iPhone into a malicious charger programmed to attack iOS devices, an Apple spokesman told Reuters that the next software update will fix the bug that enables the hack.

Apple's iPhones and iPads will be vulnerable until they get the iOS 7 update, which is scheduled for release later this year.

A spokesman told Reuters that the issue has already been fixed in the latest beta of iOS 7, which has been released to software developers.

The attack employs a malicious USB charger dubbed "Mactans" that was first publicized in June.

Mactans is a simple device: a custom-built charger equipped with a tiny Linux computer that's programmed to compromise iOS devices.

It attacks devices within a minute of connecting, needing neither jailbreaking nor input from the phone's user to succeed.

Its creators say it cost about $45 to buy and took about a week to design.

The successful attack leads to a persistent infection of software that's invisible to a phone's user, relying as it does on the built-in concealment techniques that Apple itself has put in place to hide some of its own apps.

Mactans, which was created by researchers from the Georgia Institute of Technology, was demonstrated at Black Hat by research scientist Billy Lau, along with graduate students Yeongjin Jang and Chengyu Song.

During their presentation, the researchers succeeded in infecting an iPhone with malware designed to dial one of the researcher's phones - an assignment it carried out successfully.

The flaw that allows the hack could be exploited in the wild to enable attackers to remotely hijack a device and turn it into a spying tool, the researchers said.

With control of an iOS device, an attacker could, for example, get the phone to snap screenshots of banking logins and passwords and credit card numbers; could access email, texts and contact information; or could track a phone owner's geolocation, Lau said.

Lau said that Android devices don't suffer from the same vulnerability given that they warn users when they plug into a computer, even if it's a tiny computer pretending to be a charging station.

After Apple's iOS 7 update, a similar warning message will pop up to alert iOS users that they're connecting to a computer, as opposed to an ordinary charger, Lau said.

Until then, make sure you practice safe powering.

It's not that Mactans presents a grave risk of contracting malware, mind you.

As Peter Bright at Ars Technica describes it, this attack has some serious limitations (Mr. Bright, by the way, does a good job at describing the technical aspects of the USB idiosyncrasies that concern this attack, so do read his piece if that appeals).

A successful Mactans attack requires that the phone's screen be unlocked, for one thing.

It also requires the attacker to have a valid developer account, and each developer account is limited to generating the required provisioning profiles for 100 different phones.

That means that such an attack would have to be targeted, as opposed to being widespread and indiscriminate.

It could be done, but it sounds like it would be rather esoteric and James Bond-ish.

It's always been a good idea to avoid plugging gadgets into sketchy power-charging stations to avoid catching an electronic disease (there's even a name for it: juicejacking).

But, at least as far as an attack like Mactans goes, it's likely only going to happen in research situations or in Hollywood scripts at this point in time.

Follow @LisaVaas

Follow @NakedSecurity

View the original article here

NIST, US government's vulnerability database, brought down by ironic malware

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

The US's national vulnerability database has been offline for days thanks to a multi-server infection by severely ironic malware.

Kim Halavakoski, chief security officer at Crosskey Banking Solutions, broke the news Wednesday night on his Google+ page.

Halavakoski said that he was trying to research vulnerability information from the National Vulnerability Database (NVD) and other websites operated by the National Institute of Standards and Technology (NIST).

Instead of results, he got what was still showing up as of Friday morning: a "Page not available" message.

When he asked NIST what was up, a spokeswoman told him that the organization doesn't know when the database will be back up, but they're sweating bullets to get it back fast.

According to her statement, the public-facing NVD site and other NIST-hosted sites were taken offline when NIST discovered malware on two servers on Friday night.

NIST took the servers offline after a firewall picked up on suspicious activity and blocked "unusual" traffic from reaching the internet.

While investigating the malware, NIST discovered an unspecified software vulnerability.

So far, nothing vile has seeped out as a result. NIST says:

Currently there is no evidence that NVD or any other NIST public pages contained or were used to deliver malware to users of these NIST Web sites. NIST continually works to maintain the integrity of its IT infrastructure and acts to limit the impact of malware on its systems. We regret the impact this has had on our services.

An interesting note: in a subsequent post Thursday morning, Halavakoski noted that a site report shows that the day after NIST detected the malware, it switched its sites from IIS 7.5 to Linux and Apache.
At any rate, beyond the Microsoft vs. open-source debate, the hack of a database that catalogs vulnerabilities is little short of "pure evil", to borrow Halavakoski's summation.

Those hackers really know how to hurt a security guy/girl. Good luck wiping your servers clean, NIST.

Follow @LisaVaas
Follow @NakedSecurity

Images from Kim Halavakoski

View the original article here

BlackBerry warns of TIFF vulnerability that could allow malware to run on enterprise servers

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

If you are responsible for administering the BlackBerry phones used by staff at your company, there's some imporant security news.

According to a BlackBerry security advisory published last week, vulnerabilities exist that could allow remote hackers to run malicious code on the BlackBerry Enterprise Server (BES) software run by many firms.

The flaw, which has been rated as "high severity", involves how BlackBerry's enterprise software handles TIFF image files on webpages, in emails, and in instant messages.

According to BlackBerry's advisory:

Vulnerabilities exist in how the BlackBerry MDS Connection Service and the BlackBerry Messaging Agent process TIFF images for rendering on the BlackBerry smartphone.

Successful exploitation of any of these vulnerabilities might allow an attacker to gain access to and execute code on the BlackBerry Enterprise Server.

Depending on the privileges available to the configured BlackBerry Enterprise Server service account, the attacker might also be able to extend access to other non-segmented parts of the network.

In short, a malicious hacker could create a boobytrapped TIFF image file and either trick a BlackBerry smartphone user into visiting a webpage carrying the image, or embed the malicious image directly into an email or instant message.

According to BlackBerry, the BlackBerry Messaging Agent flaw does not even require a user to click on a link or view an email for the attack to succeed.

The risk is that by exploiting the flaw, hackers might be able to plant malicious code on your BlackBerry Enterprise Server that opens a backdoor for remote access.

Depending on how your network infrastructure is set up - intruders might be able to see into other parts of your network and steal information.

Alternatively, the hackers' code might cause your systems to crash - perhaps interrupting communications.

It's important to underline that these are not vulnerabilities in BlackBerry smartphones themselves. Like other BlackBerry-related vulnerabilities we've seen in the past, the potential attack is against the BlackBerry Enterprise Server used by businesses.

As more and more companies are waking up to the risk of targeted attacks with the apparent intention of stealing data and spying on activities, such a vulnerability is clearly a serious concern.

The good news is that BlackBerry has not received any reports of attacks targeting its enterprise customers, but obviously it is still a very good idea for affected customers to update their software as soon as possible. The company has published workarounds for those businesses who may not be able to quickly update their installation of Blackberry Enterprise Server.

Follow @gcluley

View the original article here

Anatomy of a vulnerability - cURL web download toolkit holed by authentication bug

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

You may not have heard of cURL, but you've probably used software that uses it.

It's an open-source programming toolkit that helps you deal with writing client-side code that deals with URLs.

In the words of the project itself, "cURL groks those URLs."

It's popular because it's a URL Swiss Army knife, making it easy to handle popular protocols like HTTP, SMTP, POP3 and many more. It also supports uploads, downloads, authentication, proxies, cookies and SSL/TLS.

It even supports Gopher, if you remember that far back.

One risk with an all-singing, all-dancing library, of course, is that there's more code to go wrong.

And sometimes, even obscure bits of code you thought you'd never use might get triggered. Worse still, they might be triggerable by external circumstances you never predicted.

That's the curly problem here.

The vulnerable code was introduced in the 7.26.0 release, when support for DIGEST_MD5 authentication was added to the cURL software.

DIGEST_MD5 is an rudimentary way of allowing you to login over an unencrypted connection, for example to an HTTP or POP3 server, without sending your actual password.

The server sends a random challenge string, or nonce, together with a bunch of other authentication-related data; you reply with a cryptographic hash of your password mixed up with that server-supplied data:

So a cracker who sniffs your reply can't directly recover your password from it, and since the challenge is random and varies every time you log in, the cracker can't re-use your reply later.

As an aside: avoid using DIGEST_MD5 authentication. Encrypt the entire session using TLS instead.

A cracker who sniffs a DIGEST_MD5 reply can't re-use it directly, but he can use it to try to recover your password offline using a dictionary attack.

TLS not only prevents this, but also keeps the entire transaction secret, including the contents of your web session or email. That's a much better security outcome.

Here's the buggy code from a vulnerable version of cURL:

Don't worry if you aren't familiar with C. I'll explain.

In C, the management and use of memory is left up to the programmer. You can use library code to help you deal safely with variable-length data, such as user-supplied text strings, or you can deal directly with memory yourself.

Above, the programmer has done the latter.

Firstly, he allocates a series of fixed-length memory blocks on the stack.

Then he copies text strings supplied by the caller of the function into those blocks, but be uses the system functions strcpy() and strcat(), which stand for "string copy" and "string concatentate" (tack one string on the end of another) respectively.

In modern code, you should never use those functions, because you can't limit how much data they copy.

They simply duplicate every byte from the input string into the output string, until a NUL (zero) byte has been found. A NUL is how the end of a text string is denoted in C.

So, if the server sends too much data in its authentication challenge, for example an overly-long realm string (the contents of which can be whatever the server chooses), this function will stuff too much data into the buffer it uses to compute the authentication response.

A buffer overflow will result, and in this case, since the destination data blocks were allocated automatically on the stack, the function will crash when it ends.

That's because the stack also stores the address in memory from which the function was called, so the cURL software can return there when it's finished. The return address is overwritten in the above code if the string response get over-filled.

The fix was a simple one.

The uncontrollable strcpy() and strcat() functions have been replaced with the function snprintf(), which stands for "formatted print of string into at most n bytes":

You can still make mistakes with snprintf, since it's up to you to specify n, and if you aren't careful, you may get it wrong.

But the point is that is is at least possible to restrict the output of snprintf to a known buffer size, which you simply can't do with the old-fashioned strcpy() and strcat().

? The updated cURL code above still isn't perfect. The programmer should really check the return value of snprintf(), which reports how many bytes it wanted to write. If your buffer wasn't big enough, then the output will be incomplete and therefore incorrect. You ought not to use it: increase the size of your buffer and try again, or report an error instead.

You're probably thinking, at this point, that exploiting this vulnerability would be hard because most programs that use cURL do so in the background. They aren't interactive.

Autoupdating software, which might use the cURL library (known as libcurl) typically comes pre-configured with a list of known-good URLs, or asks you to enter a URL at install time, and that's that.

An attacker who could talk you unto switching your known-good autoupdate URL for a dodgy one, or who could persuade you to change from the POP3 email server you've always used to one you've never heard of, would surely find it easier to infect you simply by getting you to run his malware directly.

That's true, but there's still a risk.

If an attacker can redirect the requests from your autoupdater or your POP3 client, for example by fiddling with your DNS settings, or by hacking a server at the edge of your service provider's network, he could send you off to an imposter site and attempt to exploit you from there.

? As @kyprizel points out in the comments below, cURL only actually calls the vulnerable function from its POP3 and SMTP protocol handlers, so an HTTP request cannot directly put you in harm's way. But cURL follows HTTP redirects, even unusual ones that send you off to a POP3 server, so a crook who can modify your HTTP replies may be able to attack you nevertheless.

Because of the buffer overflow, this could lead to a drive-by download, where cURL itself is tricked into misbehaving, cutting your informed consent out of the loop altogether.

The lessons?

Don't use strcpy() or strcat().Ever.Use snprintf (or strlcpy() and strlcat(), or similar) instead.Always check the return value of string-handling functions so you don't end up using incorrect results.

Your next problem is to find out which software you are using, if any, includes cURL code with these bugs. (Versions of cURL from 7.26.0 to 7.28.1 inclusive are affected.)

Best start asking around...

Follow @duckblog

NB. Although several Sophos products use libcurl, none of them use code from the vulnerable versions.

View the original article here

Vulnerability reported in Foxit PDF plugin for Firefox - how to mitigate it

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

When you think of PDF vulnerabilities and exploits, the first word that comes to mind is probably Adobe.

That's because Adobe's PDF reader has long been the most prevalent product in the marketplace, and the most heavily targeted by attackers and researchers.

But there are plenty of challengers in the PDF software market, and it's important to remember that just "being different" is not enough to deliver security on its own.

Also, since Adobe released Reader X, with its security-oriented sandbox, crooks and researchers alike have found Adobe's PDF nut much harder to crack.

You can therefore expect other vendors of PDF software to start feeling some of the heat that would probably have been aimed entirely at Adobe in years gone by.

Here's an example: Italian security researcher Andrea Micalizzi has recently sought, and found, a possibly-exploitable vulnerability in the latest Foxit PDF plugin for Firefox.

Micalizzi hasn't actually produced a proof-of-concept exploit, but I was able to reproduce his result at will.

(I used Firefox 18.0 with Foxit Plugin 2.2.1.530 on Windows XP3.)

The crash, which is a side-effect of a stack overflow, pretty much lets you write to a memory location of your choice. That's not good.

Foxit openly promotes its PDF reader as a secure platform that "insures worry free operation against malicious virus [sic]", which may sound like a bold statement in the face of Micalizzi's bug.

But there is still literal truth in Foxit's claim: the bug is not in the PDF reader itself, but in the npFoxitReaderPlugin.dll file that acts as the glue between the browser and the reader.

? The np at the start of the filename stands for "Netscape Plugin", a plugin architecture that originated in the heady days of Netscape Navigator. Ironically, the first example of such a plugin for Netscape was written at...Adobe Systems.

Intriguingly, you don't actually need to feed Foxit a PDF to provoke the crash. You just have to feed it a malformed link that, when clicked, serves up an HTTP reply that advertises itself as a PDF.

The buffer overflow happens in the code that processes the link, triggering a crash when the link includes an overly-long query string.

If a link contains a question mark [?], the query is the text that follows it. The query component is usually used to identify parameters submitted to a server-side script. Below, for example, the query part is the string download=true:

http://example.org/docs/file.pdf?download=true

Foxit has yet to comment on this issue on its security advisories, though I am sure it will soon do so.

I've seen stories online suggesting that, since there's no patch yet, you might consider switching to a different PDF reader.

But since the bug isn't in the reader itself (and there's no exploit yet, anyway), there's a quicker and simpler mitigation you can use that will let you stick with Foxit.

Just turn off the Firefox plugin.

Go to Tools|Add-ons at the Firefox menu, choose the Plugins tab and click the Disable button against the Foxit Reader Plugin for Mozilla.

PDF files will no longer open directly inside your browser. You'll get an intermediate dialog saying:

You have chosen to open: . . .

You will then need to click the OK button.

This loads the file into a separate Foxit reader process, avoiding the buggy code in the plugin DLL.

As Steve Jobs might have said, not that big of a deal.

Follow @duckblog

View the original article here

Zero day vulnerability in Internet Explorer being used in targeted attacks, FixIt now available

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Internet Explorer users beware, there is a new zero day (previously unknown, unpatched vulnerability) attack targeting your browser.

Microsoft has issued an advisory about the flaw and it is being referred to as CVE-2012-4792. Microsoft has also made a temporary FixIt available until it can deliver a formal patch.

The flaw affects users of Internet Explorer 6, 7 and 8, but not 9 or 10 and allows for remote code execution with the privileges of the logged in user.

Another poignant reminder that running your computer as a non-administrative user pays off when new flaws are uncovered.

Non-privileged users will severely limit the damage that can be done using a vulnerability like this one.

The vulnerability was initially
" href="http://blog.fireeye.com/research/2012/12/council-foreign-relations-water-hole-attack-details.html" rel="nofollow">discovered by FireEye on the Council on Foreign Relations website on December 27th, 2012.

SophosLabs has records showing the Council's website infected as far back as December 7th.

We have seen the exploit used on at least five additional websites suggesting the attack is more widespread than originally thought.

The attack appears to be closely related to attacks we reported on last June that were targeting visitors to a major hotel chain.

While the vulnerability being exploited is entirely different, the payload is nearly identical to the hotel attack and others we have associated with the Elderwood Project.

While the attacks appeared to be targeted to a small number of sites, there is no obvious link between the victims.

Some are referring to this as a "watering hole" attack, but the evidence we have doesn't necessarily support that conclusion.

If you use Internet Explorer, be sure you are using at least version 9 to avoid being a victim of these attacks. If you can't upgrade, consider using an alternative browser until an official fix is available.

Microsoft's FixIt is intended as a temporary workaround that could also be considered, but until an official fix is available I recommend avoiding IE 8 and lower.

If further information becomes available, we will publish the latest here on Naked Security.

Sophos Anti-Virus on all platforms blocks this malware as follows:

• Sus/20124792-B: Misc. files specifically associated with this attack
• Sus/Yoldep-A: Encoded payload also seen in other Elderwood Project attacks
• Troj/SWFExp-BF: Adobe Flash component
• Sus/DeplyJv-A: JavaScript components evolved from earlier Elderwood Project attacks

Follow @chetwisniewski

Watering hole photo courtesy of Shutterstock.

View the original article here

Zero-day XML Core Services vulnerability included in Blackhole exploit kit

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

A couple of weeks ago (12 June 2012) we published an advisory for a vulnerability in Microsoft XML Core Services, also known as CVE-2012-1889.

The vulnerability is a true zero-day, being exploited in the wild, with no patch yet available from Microsoft.

The main concern in such situations is the speed with which we see exploit kits updating to target new vulnerabilities.

This is hardly surprising: web drive-by download attacks are responsible for the majority of user infections nowadays, and it is exploit kits that are used to construct these attacks.

As soon as we see exploit kits targeting new vulnerabilities we can expect to see a lot more users getting infected - especially if the vulnerabilities are zero-days.

Unfortunately, as noted in the ISC Diary, only a few days after the initial advisory was posted, a metasploit module was created and published.

Expectations were duly set for rapid uptake by the popular exploit kits.

Sure enough, within a week, CVE-2012-1889 exploiting code very similar to that published to Metasploit was seen within the landing page of a Blackhole exploit kit site.

(Thanks and hat-tip to the eagle-eyed researcher who first spotted this - ChrisW, who works at a UK University.)

The code is bundled alongside the various other exploits that Blackhole currently targets. The landing page itself is obfuscated in the usual manner we expect for Blackhole, using the latest anti-emulation tricks in an attempt to thwart detection. (Sophos products detect and block this as Mal/ExpJS-N.)

When the code is deobfuscated, the usual functions used to target the vulnerabilities we associate with Blackhole are evident. However, within this particular page was a new function (spl7), that targeted CVE-2012-1889. The function used well-described heapspray techniques to deliver the shellcode, prior to exploiting the vulnerability in order that execution passes to that shellcode.

The shellcode is pretty straightforward, attempting to download the payload (a dll) from a remote server, writing it to the temp folder.

So, let's take a quick review of the timeline of these events:

30 May 2012: Vulnerability reported to Microsoft12 June 2012: Microsoft publishes advisory12 June 2012: Sophos publishes advisory14 June 2012: Sophos publishes Exp/20121889-A16 June 2012: Metasploit module published18 June 2012: Sophos raises threat level to critical21 June 2012: Updated Blackhole exploit kit spotted27 June 2012: Sophos lowers threat level to high

Curiously enough, at the time of writing, I have not seen other Blackhole sites targeting the vulnerability.

To be honest, after seeing that first site, I was expecting a significant proportion, if not all, of the Blackhole sites to be using it within a few days.

We can only speculate as to why this new exploit isn't widespread. Is the exploit code unreliable? Is it being reserved for specific, new (expensive!) variants of the kit?

For now, it is a case of watch this space...

Follow @SophosLabs

View the original article here

Gmail accounts targeted by 'state-sponsored attackers' using Internet Explorer zero-day vulnerability

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Both Google and Microsoft have put out alerts about an unpatched, zero-day hole in Internet Explorer that didn't get fixed on Patch Tuesday and is actively being exploited in the wild.

According to ZDNet, those attacks are apparently being launched by the "state-sponsored attackers" that Google warned Gmail users about last week.

Neither Google nor Microsoft referred to those state attackers in their respective security warnings. ZDNet attributed that particular detail to a source it said was "close to these investigations".

This source confirmed to ZDNet that the attacks motivated Google to warn Gmail users last week about the attackers.

As ZDNet pointed out, Gmail users have been reporting on Twitter that they've been hit by the Gmail warning.

Google security engineer Andrew Lyons wrote in the company's security blog that Google reported the vulnerability to Microsoft on May 30 and that the two companies have been working on the problem since.

He wrote on Tuesday:

Today Microsoft issued a Security Advisory describing a vulnerability in the Microsoft XML component. We discovered this vulnerability - which is leveraged via an uninitialized variable - being actively exploited in the wild for targeted attacks.

Lyons said that the attacks are spreading both from malicious web pages set up to snare Internet Explorer users and through Office documents.

Users running any flavor of supported Windows are vulnerable, from XP onwards up to and including Windows 7. All supported editions of Microsoft Office 2003 and Microsoft Office 2007 are also vulnerable.

The hole hasn't been stitched up yet, but Microsoft is suggesting a workaround that will help prevent it from being exploited.

Microsoft's security advisory recommends that IE and Office users immediately install a Fix it solution, downloadable with instructions from Microsoft Knowledge Base Article 2719615, until the company gets the final fix out.

The vulnerability crops up when Microsoft XML Core Services 3.0, 4.0, 5.0, and 6.0 try to access an object in memory that hasn't been initialized, which can corrupt memory such that an attacker could execute arbitrary code on a hijacked machine.

A victim would have to visit a maliciously crafted site using IE to suffer an attack. An attacker might lure users into visiting a boobytrapped site by enticing them to click on a link in an email or via messaging.

A successful attack grants the intruder the same user rights as the logged-on user. Therefore, a mitigating factor is to configure accounts with fewer rights, as opposed to operating with administrative user rights.

Microsoft noted that by default, IE on Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 runs in a restricted mode known as Enhanced Security Configuration. That also mitigates the vulnerability.

As far as bolting down Gmail goes, Sophos's Graham Cluley has a collection of tips on how to stop your Gmail account from getting hacked.

It's definitely worth a read. Here's a quick cheat-sheet; Graham gives you more detail on these items in his article:

OK, that last one's not a tip, per se, but it's food for thought if you are, in fact, important enough that a state would want to attack your Gmail account.

If you are, think twice about using a free web email provider for sensitive information. If you're working for the government or the military, like Graham said, put all that sensitive information on secure systems instead.

Follow @LisaVaas
Hairy spider image, courtesy of Shutterstock.

Tags: 2719615, gmail, Google, IE, Internet Explorer, Microsoft, Microsoft XML Core Services, Office, security advisory, state-sponsored attackers, Windows, XML Core Services, Zero Day

View the original article here