Showing posts with label Malware. Show all posts
Showing posts with label Malware. Show all posts

Saturday, January 16, 2010

Source code for Skype eavesdropping trojan in the wild

Earlier this week, Swiss programmer Ruben Unteregger who has been reportedly working for a Swiss company ERA IT Solutions responsible for coding government sponsored spyware, has released the source code of a trojan horse that injects code into the Skype process in order to convert the incoming and outgoing voice data into an encrypted MP3 available at the disposal of the attacker.

Here’s how the trojan, currently detected as Trojan.Peskyspy, works:


“When the Trojan is executed, it injects a thread into the Skype process and hooks a number of API calls, allowing it to intercept all PCM audio data going between the Skype process and underlying audio devices. Note: Since the Trojan listens to the data coming to and from the audio devices, it gathers the audio independently of any application-specific protocols or encryption applied by Skype when it passes voice data at the network level.

Note: The incoming and outgoing audio data are stored in separate .mp3 files. The Trojan also opens a back door on the compromised computer, allowing an attacker to perform the following actions:
- Send the .mp3 to a predetermined location
- Download an updated version
- Delete the Trojan from the compromised computer”

Skype is often dubbed a “national security threat” by governments all across the globe due to their — at least publicly acknowledged — inability to crack the 256-bit encryption VoIP calls.

And while some of these governments are reportedly spending surreal amounts of tax payer’s money (Rental of the Skype-Capture-Unit per month and instance EUR 3.500) in order to achieve their objectives, others are taking the cost-effectiveness path by attacking the weakest link in the process - the end user infected with a targeted DIY government sponsored spyware recording all ongoing and incoming Skype calls, thereby bypassing the need to attack the encryption algorithm.

Saturday, August 22, 2009

IE8 outperforms competing browsers in malware protection

A recently released study by NSS Labs is once again claiming that based on their internal tests, Microsoft’s Internet Explorer 8 outperforms competing browsers like Google’s Chrome, Mozilla’s Firefox, Opera and Apple’s Safari in terms of protecting their users against “socially engineered malware” and phishing attacks.


Not only did IE8 top the chart, but also, the rest of the browsers have in fact degraded their “socially engineered malware” and phishing block rate in comparison to the results released by the company in the March’s edition of the study.

How objective is the study? For starters, it’s Microsoft-sponsored one. Here’s how it ranks the browsers:

Socially engineered malware block rate:

Microsoft Internet Explorer v8 - 81% block rate
Mozilla Firefox v3 - 27% block rate
Apple Safari v4 - 21% block rate
Google Chrome 2 - 7% block rate
Google Chrome 2 - 7% block rate
Phishing attacks block rate:

Microsoft Internet Explorer v8 - 83% block rate
Mozilla Firefox v3 - 80% block rate
Opera 10 Beta - 54% block rate
Google Chrome 2 - 26% block rate
Apple Safari v4 - 2% block rate

What is “socially engineered malware” anyway?

Basically, it’s the direct download dialog box that appears on a, for instance, scareware or Koobface video page spoofing Facebook’s layout, like the one attached. using “socially engineered malware” as a benchmark for malware block rate isn’t exactly the most realistic choice in today’s threatscape.

And even if it is, some pretty realistic conclusions can be drawn by using some internal traffic statistics from Koobface worm’s ongoing malware campaigns. The Koobface worm, one of the most efficient social engineering driven malware, is a perfect example of how security measures become obsolete when they’re not implemented on a large scale.
The stats themselves:

- MSIE 7 - 255,891 visitors - 43.33%
- MSIE 8 - 189,380 visitors - 32.07%
- MSIE 6 - 76,797 visitors - 13.01%
- Javascript Enabled - 585,374 visitors - 99.13%
- Java Enabled - 576,782 visitors - 97.68%

What does this mean? It means that with or without the supposedly working “socially engineered malware” block filter using a modest sample of several hundred URLs, the Koobface botnet is largely driven by MSIE 7 users. The previous edition of the study dubbed IE7 a browser which “practically offers no protection against malware” with the lowest block rate achieved back than - 4%.

Just like the previous edition of the study, this one also excludes the notion that client-side vulnerabilities continue contributing to the “rise and rise” of web malware exploitation kits. By excluding client-side vulnerabilities, the study isn’t assessing IE8’s DEP/NX memory protection, as well as omitting ClickJacking defenses and IE8’s XSS filter, once pointed out as a less sophisticated alternative to the Firefox-friendly NoScript.

Socially engineered malware is not the benchmark for a comprehensive assessment of a browser’s malware block rate. It’s a realistic assessment of the current and emerging threatscape combined with comprehensive testing of all of the browser’s currently available security mechanisms, a testing methodology which I think is not present in the study.

Tuesday, February 3, 2009

The smallest threat to open source in 2009

How much of a problem is security updating for open source software going to be in 2009?
On Jan. 1, Dana Blankenhorn published the sensationally titled The biggest threat to open source in 2009.
His thesis is simple: that, because open source software usually lacks any mechanisms for easily updating to the latest security patched version, the growing popularity of open source software will render it more vulnerable to problems than its closed source counterparts.
As a lead-in to his main point, he said:
There is no longer any doubt that hackers and malware writers are going after open source projects as they once went after Windows. Vulnerabilities are being found, discovered, created, exchanged.
There seems to be a common malady amongst opinionated tech writers--that of never quite getting it when it comes to the fundamental principles of security. A particular favorite for being ignored is that of security through obscurity.
Many many moons ago, I wrote what I think is a decent treatment of the subject as it applies to open source software, Security through visibility. While it makes a pretty strong case for ignoring the bleatings of "popularity is insecurity" doomsayers, it's really only the first step toward full understanding of all the problems with the assumption that the only thing "secure" about open source software is obscurity.
Obviously, based on his start to the article, I was already expecting very little in the way of useful information. His next statement left me even more mystified at what appeared to be a towering edifice of ignorance, however. Specifically, he said:
The best protection against vulnerabilities is to keep software updated, but most open source lacks update services. That's one part of the Windows license that is worth paying for, and there does not seem to be an open source equivalent.
As a long-time user of open source operating systems, previously favoring Debian GNU/Linux, and subsequently moving on to FreeBSD, I was stunned to see this in writing, published for all the world to see. Was he serious? Could he really believe that?
One of the most visible wins for open source Unix-like OSes, once one has learned a fair bit about them, is the casual availability of superior software management systems. Ive written a brief primer for effective use of APT for TechRepublic, Efficient software management with the Advanced Package Tool in Debian. Ive also addressed the excellence of a security tool integrated with FreeBSDs ports system, How FreeBSD makes vulnerability auditing easy: portaudit. Both of these articles illustrate some of the significant benefits of better software management systems than offered by MS Windows.
Perhaps even more relevant to Danas point is the fact that, on open source Unix-like OSes (but not on MS Windows), the software management system typically manages security updates for far more than just the core OS and a couple of applications created by the same vendor. Such Unix-like OSes software management systems tend to provide security update management for literally thousands of software packages originating outside the core OS project itself--in some cases, tens of thousands.
Then, his next statement clarified his meaning:
An exception is Firefox...But how many take advantage of this? And how tied is Firefox to updating for security purposes? Remember were talking about pushing updates, not asking users to pull them.
Suddenly, it all became clear. In Dana Blankenhorns mind, "open source software" refers only to the handful of popular open source applications that are regularly used on MS Windows systems. I find it interesting that the only example of an open source application he offers is an exception to his rule, however.
Where are all the legions of open source applications that dont provide easy software updates? Whose fault is it that MS Windows doesn't have a software management system that can help ease the process of applying security patches for these applications the way open source OSes do? Where are the examples of closed source applications that provide such update management as he describes, where the MS Windows compatible open source alternative does not--thus justifying his singling out of open source software as somehow more notably vulnerable?
Perhaps the worst part of the inaccuracies of the article is the fact that its clear assumptions (that all software worth discussing is MS Windows-centric, for instance) for those of us who know better are opaque to those who do not.
A manager with little or no experience of OSes outside of MS Windows may read this article and come away with the assumption that open source OSes completely lack software management systems. As a result, he or she may scupper any potential plans to deploy open source Unix-like systems in the network. So much for "the best tool for the job"; such decisions are often difficult to make well even when you aren't hampered by wrong-headed ideas like those Dana's article might inspire.
He does make a good point about corporate culture, though:
But until this ramps up (hopefully in a competitive market), enterprise managers have an easy way to say "no" to open source.
Regardless of how dangerous this is, the fact that managers feel it's dangerous makes it so.
Too bad some of those managers might "feel" its dangerous specifically because of his own article.
I'd clarify that to say that managers feeling its dangerous doesn't actually make it so--but it does make it so for all intents and purposes in the corporate environment, when it comes to technology implementation decisions. When the higher-up says "I think the closed source software offering is better, because I have these concerns about the open source software alternative", his or her subordinate (and perhaps more technically inclined) IT worker will eventually reach a point where he or she must either make decisions limited by the managers fears or polish his resume. Take it from someone who knows from personal experience.
On one hand, I'm inclined to be dismayed by this common bureaucratic failure of corporate culture, and feel the urge to rail against it. After all, security is everybody's problem; it's not just a problem for "that guy over there". Your problem, to a significant extent, becomes my problem when you connect to the Internet.
On the other hand, knowing something about security that others don't provides something of a competitive advantage. Where competitors may stumble and fall, the organization with a knowledgeable IT department will remain stable and secure, and prosper where others have failed.

Wednesday, June 18, 2008

How to recover GPcode encrypted files?


Got backups? In response to the security community’s comments on the futile attempt to directly attack the 1024 bit RSA keys using distributed computing, Kaspersky Labs are now reasonably recommending that affected end users lacking backups of their encrypted data, take advantage of data recovery tools :

Currently, it’s not possible to decrypt files encrypted by Gpcode.ak without theprivate key. However, there is a way in which encrypted files can be restored to their original condition. When encrypting files, Gpcode.ak creates a new file next to the file that it intends to encrypt. Gpcode writes the encrypted data from the original file data to this new file, and then deletes the original file.

It’s known that it is possible to restore a deleted file as long as the data on disk has not been significantly modified. This is why, right from the beginning, we recommended users not to reboot their computers, but to contact us instead. We told users who contacted us to use a range of utilities to restore deleted files from disk. Unfortunately, nearly all the available utilties are shareware – we wanted to offer an effective, accessible utility that could help restore files that had been deleted by Gpcode. What did we settle on? An excellent free utility called PhotoRec, which was created by Christophe Grenier and which is distributed under General Public License (GPL).

Find out how to restore files encrypted by the GPcode ransomware by exploiting a weakness in the process in which the malware deletes the original files, why directly attacking the encryption algorithm was a futile attempt right from the very beginning, how would the malware authors adapt in the future and what can you do about it?

As I’ve already pointed out in a previous post “Who’s behind the GPcode ransomware?” even through they’ve successfullyimplemented the encryption algorithm this time, the only weakness in the process remains the fact that the malware authors are not securely deleting the original files, making them susceptible to recovery using data carving techniques, or through the use of plain simple point’n'click forensics software. If backups are not present, you would have to apply some marginal thinking given that not all of your affected files can be recoved, and therefore, recovering 500 out of 1000 is better than recovering none, isn’t it? Whatever approach you take try to adapt to the situation, and don’t pay. More info on the Stopgpcode utility released by Kaspersky :

To complete the recovery process, we’ve created a free utility called StopGpcode that will sort and rename your restored files. The utility will process the entire disk and compare the sizes of encrypted and recovered files. The program will use the file size as a basis for determining the original location and name of each recovered file. The utility will try to determine the correct name and location for each file, recreating your original folders and file names within a folder called “sorted”. If the utility cannot determine the original file name, the file will be saved to a folder called “conflicted”.

Next to the step-by-step tutorial on using PhotoRec, a data recovery utility, you can also watch a video of the process, or consider using third-party data recovery utilities next to their web based alternatives.

Why was the distributed cracking futile at the first place?

Mostly because the lack of easy to measure return on investment and applicability in a real-life situation - they could have simply started using GPcode variants with new and stronger keys on a per variant basis. The malware authors were also smart enough not to release a universal decryptor including the private key for all of their campaigns, instead, upon providing a custom built decryptor to the affected party, first they request the public key used in the encryption process to later one ship a customer tailored decryptor that works only for the encrypted files using the public key in question. Compared to the majority of malware variants attempting to infect as many hosts as possible, GPcode’s currently targeted approach is willing to sacrifice some efficiency and emphasize on quality.

How would the malware authors adapt in the future?

According to the author of Gpcode, or the person responsible for processing the decryptor requests, new versions with stronger encryption are already in the works, including commodity malware features such as anti-sandboxing, polymorphism and self-propagating abilities. This would result in a awkward situation, for instance, for the time being two out of the four emails used by the authors of GPcode aren’t even bothering to respond back to the infected party, so you can imagine the delays with responding given that GPcode starts self-propagating. They will basically end up with a situation where the number of affected people would outpace their capability to provide them with a custom built decryptor in a timely manner, even if someone’s willing to pay the ransom.

With the entire GPcode ransomware fiasco slowly becoming a tool in the marketing arsenal of a backup company that can now use GPcode as a fear mongering tactic, malware free backups are once again reminding us of their usefulness.

Sunday, June 15, 2008

Fake ImageShack site serving malware, links distributed over IM

In a combination of domain typosquatting next to spoofed image files, malware authors managed to successfullyimpersonate ImageShack, the 5th largest image hosting website on the Internet, the result of which is a malware campaign circulating over MSN, enticing users into infecting themselves by clicking on the spammed links to fake image files.  
This currently active IM malware campaign is yet another indication that the “don’t click on executable files” security tip is on the verge of irrelevance. Social engineering, however, isn’t, since impersonating ImageShack to serve fake images which are in fact trojans turning the infected hosts into zombies is a well coordinated social engineering campaign combining several difference tactics.

The real ImageShack site is imageshack.us, however, the malware authors are impersonating ImageShack and using imageshaack .org, in particular imageshaack.org /img/Picture275.jpg, which is where the malware is. Once the user gets infected with the malware, Backdoor.Win32.SdBot.eiu in this case, the host joins an IRC channel where the botnet masters continue issuing commands for the campaign to spread, like the following :

!msn.msg lool!! :D http ://imageshaack.org /img/Picture275.jpg |!trition.msg lool!! :D http ://imageshaack.org/img /Picture275.jpg topic set by Everglades on Wed Jun 11 15:41:57

“!msn.msg Haha is that you;)? http ://imageshaack.org /img/Picture275.jpg?|!trition.msg http: //imageshaack.org/img /Picture275.jpg

Until the site gets shut down, consider being extra vigilant on IM messages received, and while this is a bit more creative social engineering attack then the majority of average ones I’ve seen this month, non-executable files are apparently just as dangerous as executable ones.


Dancho Danchev is an independent security consultant and cyber threats analyst, with extensive experience in open source intelligence gathering, malware and E-crime incident response. Dancho is also involved in business development, marketing research and competitive intelligence as an independent contractor. He's been an active security blogger since 2007, and maintains a popular security blog sharing real-time threats intelligence data with the rest of the community on a daily basis.