Sunday, March 20, 2011

Spam tapping Japanese disasters goes through the roof

18 March 2011

Newswires are reporting that the volume of spam – leading to infected and scamware websites – has gone through the roof this week, but M86 Security says that it has seen a spam campaign that imitates a Twitter notification.

This approach to spamming internet users is one of the first times that a Tweet format has been used for a spamming email, Infosecurity notes. But Phil Hay, M86's lead security researcher, notes that, whilst the subject of the spam varies, sadly, most of them focus on the recent tragic events in Japan.

The links on one spam campaign, he said, lead to a page hosting obfuscated malicious JavaScript, which seeks to exploit a Java vulnerability.

Allowing the message to execute, said Hay, meant that the host computer was immediately compromised, added to a botnet, and some not-so-subtle fake anti-virus malware was installed.

"The spam is originating from one of the Cutwail spambot variants. We managed to get this template from Cutwail command and control traffic, which clearly shows the Twitter template being used", he wrote in his latest security blog.

"With the rise in social networking, we have been seeing increased use of fake 'notifications' being used by spammers", he added, advising that, as ever, internet users should remain on guard, especially when it comes to Twitter 'notifications'.


Source and credit : http://www.infosecurity-magazine.com/view/16715/spam-tapping-japanese-disasters-goes-through-the-roof/

Google to enforce SSL encryption on developer APIs

Google to enforce SSL encryption on developer APIs

September 15: HTTPS or nothing

Google will soon require the use of SSL encryption with three of its developer-facing APIs.

Beginning September 15, Google will require all developers to use SSL connections for all requests through its Google Documents List, Google Spreadsheet, and Google Sites APIs. In other words, these APIs will only accept requests via HTTPS. If you make a request to an old HTTP address, such as http://docs.google.com/feeds/default/private/full, it will no longer work. You must use https://docs.google.com/feeds/default/private/full.

If you're using the latest version of the Google Data Client libraries, Google says, you needn't change anything. Those libraries already use SSL across the board. If you're not using those libraries, you must change all HTTP URLs in your code to HTTPS.

Google is not requiring SSL on all its APIs, but it "strongly recommends" that you use such encryption with all your Google API clients. The company has started with the Document List, Spreadsheet, and Sites API because most traffic to these APIs is already encrypted with SSL.

Mountain View has led the web in the gradual migration to SSL encryption: Gmail now defaults to SSL, it's an option with Google web search, and Google Docs – the company's online word processor – requires SSL. But other big names, including Facebook, have followed suit.

With most Google APIs, SSL is used with technical documentation, client libraries, and code samples already use SSL. This week, the company also announced that the Google Maps API is now offering SSL to all developers. Previously, it only offered SSL to "Premier" customers. ®


Source and credit : http://www.theregister.co.uk/2011/03/18/google_apis_require_ssl/


RSA hacked, SecurID users possibly affected

Posted on 18 March 2011.

In an open letter, Art Coviello, the executive chairman of RSA (the security division of EMC), made public the fact that the company has suffered a breach and data loss following an "extremely sophisticated cyber attack."


Categorizing the attack as an Advanced Persistent Threat - a term that is often associated with corporate espionage and state sponsored attacks - he said that their investigation revealed that the information extracted from the company systems is related to its SecurID two-factor authentication products, which are widely used by government agencies, private companies and other large organizations to add an additional layer of security for when employees log into their companies' networks.

"While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack," said Coviello. "We have no evidence that customer security related to other RSA products has been similarly impacted. We are also confident that no other EMC products were impacted by this attack."

He made sure to point out that customer or employee personally identifiable information has not been compromised, and that they are working with their customers to strengthen the security of their IT systems.

No further details about the incident have been revealed at this time, since the investigation is also mounted by the authorities - very likely by government security agencies. The lack of definite information has resulted in widespread speculation on the Internet.

According to ZDNet, security expert Dan Kaminsky says that it is not impossible that the database that links SecurID serial numbers to seeds (card's factory-encoded random key) has been compromised, which would mean that the attackers would be able to know all generated tokens at any given time and even know which organizations are using them.

Until more details are known, he advises administrators to be on the lookout for unusual use of SecurID on external-facing interfaces.

RSA also issued a set of rather broad recommendations for its customers, but offered no specific details about the compromise.

EMC says it doesn't expect the company to suffer any financial repercussions following the breach, but it seems a little too optimistic since SecurID currently commands around 70% of the two-factor authentication market, and is a major source of revenue for RSA.


Source and credit : http://www.net-security.org/secworld.php?id=10763

Rustock botnet downed by Microsoft

Posted on 18 March 2011.

As many security companies and experts noted in the last few days, the activities of the Rustock botnet came to a standstill.

They speculated about the reason behind this sudden drop, but it was revealed only yesterday: after receiving permission from the US District Court for the Western District of Washington, Microsoft has mounted a coordinated action with the US Marshals Service and executed a number of online and offline actions that resulted in Rustock's takedown.


"Like the Waledac takedown, this action relied on legal and technical measures to sever the connection between the command and control structure of the botnet and the malware-infected computers operating under its control to stop the ongoing harm caused by the Rustock botnet," explained Richard Boscovich, Senior Attorney with the Microsoft Digital Crimes Unit.

What allowed Microsoft to file a suit against the anonymous operators of the Rustock botnet is the fact that its trademarks were abused in the spam sent by the botnet. "However, Rustock’s infrastructure was much more complicated than Waledac’s, relying on hard-coded Internet Protocol addresses rather than domain names and peer-to peer command and control servers to control the botnet," said Boscovich.

In order to prevent a quick shift of infrastructure, the court allowed them to receive help from the US Marshals Service and physically capture evidence onsite and confiscate the affected servers from hosting providers for analysis.

"Specifically, servers were seized from five hosting providers operating in seven cities in the U.S., including Kansas City, Scranton, Denver, Dallas, Chicago, Seattle, Columbus and, with help from the upstream providers, we successfully severed the IP addresses that controlled the botnet, cutting off communication and disabling it," reveals Boscovich. "Microsoft also worked with the Dutch High Tech Crime Unit within the Netherlands Police Agency to help dismantle part of the command structure for the botnet operating outside of the United States. Additionally, Microsoft worked with CN-CERT in blocking the registration of domains in China that Rustock could have used for future command and control servers."

Bots - the infected computers - are still there, but they are now cut of from their herder(s). According to Microsoft's investigation, the number of computers infected with Rustock malware reaches 1 million, and now is the time to start working with ISPs and CERTs around the world and coordinate efforts for notifying the owners of the infected machines and share knowledge about how to clean them up.

"We will continue to invest similar operations in the future as well in our mission to annihilate botnets and make the Internet a safer place for everyone," states Boscovich. "However, no single company or group can accomplish this lofty goal alone. It requires collaboration between industry, academic researchers, law enforcement agencies and governments worldwide."


Source and credit : http://www.net-security.org/secworld.php?id=10764

Monday, March 14, 2011

Pwn2Own: IE8, Safari, iPhone4, BlackBerry Torch hacked

Pwn2Own: IE8, Safari, iPhone4, BlackBerry Torch hacked

11 March 2011

The first two days of the Pwn2Own cracking contest, held at CanSecWest in Vancouver, were a success with Google's Chrome and Mozilla's Firefox surviving the best efforts of the cracking contestests.

Crackers successfully `pwned' (hacked) Internet Explorer 8 and Apple Safari browsers, however, with vulnerabilities also being exploited on various smartphones, including Apple's iPhone 4 and RIM's BlackBerry Torch 9800.

According to newswire reports, Apple's Safari was the first to be cracked, with a weakness in the open-source browser rendering engine, Webkit. This was followed by Microsoft's IE8 which was found to have three security vulnerabilities.

The Heisse Online newswire says that IE8 was cracked by Irish developer Stephen Fewer, "though he had to connect three different security holes to get around the browser's protected mode and other security mechanisms."

The attacks, says the newswire, were anything but easy.

"The 64-bit operating system had all of the current patches and security mechanisms, such as DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomisation), were enabled and all of which had to be overcome to launch the calculator application", the newswire adds.

Heisse Online went on to say that the processes of Internet Explorer under Windows 7 all ran at low integrity levels, meaning that the executions could not write into normal directories - which was needed to qualify for a complete `Pwn' in the competition.

"No-one had a go at Chrome; although two parties registered, one did not show up at the competition, and the other told the organisers that they did not have a working exploit", the newswire noted.



This article is featured in:
Application Security • Malware and Hardware Security

source & credit : http://www.infosecurity-magazine.com/view/16574/pwn2own-ie8-safari-iphone4-blackberry-torch-hacked/

Google Android security tool found repackaged with malware

In a what should actually not be a wholly unexpected turn of events, the Android Market security update - pushed to Android users whose devices where affected by one or more "trojanized" applications found on the official Android marketplace - has itself been repackaged with a Trojan and is being offered on some third-party Chinese marketplaces.

The application, called “Android Market Security Tool”, has been repackaged with suspicious code, and according to the analysis by Trend Micro's researchers, this malicious version opens a backdoor through which device information such as IMEI, its phone number and routine logs is uploaded to a remote URL.

But it doesn't stop there. It can also modify call logs, intercept or monitor messages, download videos, and more, which could also lead to a very high phone bill for the user. One must only take a look at the permissions the application asks for to see that they can be misused in a myriad of ways:





Permissions asked from the legitimate application do not include receiving and sending text messages, pinpointing the location of the device and preventing the phone from sleeping.

Also, the legitimate Android Market Security Tool shows its version to be 2.5, while the malicious application says its version is 1.5. So far, this trojanized tool seems to be aimed exclusively at Chinese Android users.

It bears repeating that checking out any application's permissions before installing it is a good idea, and if you spot something that strikes you odd or with a great potential for misuse, consider not installing it.

I would say that keeping to the official Android Marketplace is also a smart move - despite what happened last week. The odds for avoiding malicious application are better, at least.

Source : http://www.net-security.org/malware_news.php?id=1665