CounterMeasures - A Security Blog � exploit

The best form of defence?

Rik Ferguson — Tue, 03 Jan 2012 16:19:41 +0000

Mutation by woodleywonderworks

A report in the Daily Yomiuri suggests that the Japanese government have commissioned Fujitsu Ltd to create a “defensive virus” and that after 3 years of work and a budget of $2.3 million, the project is nearing completion.

Technical details in the article are necessarily thin on the ground but it appears that the “cyberweapon” is designed to “springboard” from one compromised computer to another, tracing back to the original source of the attack and shutting down malicious processes en route.

Whilst I can see the attractiveness of the principle and have some sympathy for the thinly veiled claims in the article that “everyone else is doing it”, the concept of the “good” computer virus has been the subject of debate for many years and it has never gained widespread support.

Even a “good” virus or worm must execute on a machine without the permission of the owner of that machine. If that “good” virus has the objective of terminating malicious processes and/or patching security holes then, by definition it must modify or delete critical processes, memory content or files. If its design is to spread autonomously then system owners will have no opportunity to test whether its supposedly altruistic activities will have any negative impact on a running system. It will also consume bandwidth, disk space, memory and processor cycles, all adding to the load, just as a malicious worm does effectively creating a Denial of Service condition.

The “good” virus may also be hindered by effective security software, many of the actions it will be carrying out, such as modifying system components and terminating process, will be precisely those which are designed to be recognised and stopped by security programs.

Finally it really wouldn’t take much effort for criminal groups to take these white-hat tools and modify them for more malicious use, blurring the line even more between the “good” and the bad and putting professional grade carrier mechanisms in the hands of criminals.

The Japanese government seem less than coordinated right now on the actual use such a technology would be put to, the article reports them as saying that they are “not considering outside applications for the program as it was developed for more defensive uses, such as identifying which terminal within the Self-Defense Forces was initially targeted in a cyber-attack“. This is hardly surprising, as the creation of malware is currently a violation of Japan’s criminal code.

You have to wonder though, even in that limited scenario, wouldn’t such an automated “sprinkler system” pose a huge risk of destroying valuable forensic evidence in the case of a breach? Wouldn’t effective real-time monitoring of computers and networks, reporting to a centralised SIEM console provide as much intelligence in a less inherently risky way?

Post Script:

In 2004 Cyrus Peikari made a seemingly good case for Fighting Fire with Fire, but I feel that the medical analogy breaks down completely under close examination. In the digital case we are talking about releasing a self-replicating virus into the wild, whereas in the medical case we talk about manual and controlled introduction of an attenuated virus on an individual (and voluntary) basis.

Conficker, Duqu, Stuxnet, Aliens, Confuxnet!

Rik Ferguson — Fri, 02 Dec 2011 14:37:21 +0000

I have just read a Reuters news story where respected “cyber warfare expert” John Bumgarner is reported to claim that Conficker was devised and released to act as a global smokescreen for the surgical attack, using Stuxnet on nuclear facilities in Iran.

Bumgarner claims that initial reconnaissance work was carried out using Duqu in 2007 to identify targets relevant to a later attack by Stuxnet. In November 2008 Conficker was released globally to infect as many machines as possible. When a Conficker infection phoned home, if the victim machine was found to be in a apposite location (Iran) it was flagged as a later target for Stuxnet. He further states that Conficker did no damage to machines outside Iran and that on the infamous April 1st “activation date” (of the third variant from March 2009) it was used to pull down Stuxnet to those machines located in interesting locations in Iran.

Here is the evidence, all of it unsubstantiated as far as I can ascertain, that Bumgarner presents to support his claim:

1- Both Stuxnet and Conficker show evidence of “unprecedented sophistication” leading him to believe that they are related.

2- Both Stuxnet and Conficker use the same vulnerability to infect machines (MS08-67)

3 – Unspecified “key dates” in timestamps of unspecified “different versions” of Conficker and Stuxnet overlap and also “helped him to identify April 1 2009 as the launch date for the attack“.

4 – April 1st 2009 was the 30th anniversary of the declaration of an Islamic Republic in Iran. Other unspecified dates also corresponded with days when “Iranian President Mahmoud Ahmadinejad said his nation would pursue its nuclear program despite international objections, and another with the day that he made a highly controversial appearance at Columbia University in New York“.

As regards the end-game, the eventual infection of machines physically located in the right place inside nuclear facilities, Bumgarner concedes that at this point the malware wasn’t yet “in the target“. So to make that final crucial leap, Stuxnet was designed to infect USB drives, in the hope that someone would later take the same USB drive from a Conficker/Stuxnet infected machine and plug it into a machine located in an air-gapped network in nuclear facility. At that point, Bumgarner states, “it was checkmate“.

Phew, what a ride! You’ll forgive me I hope if I say that this account stretches my credulity to breaking point. Let me list a few reasons why.

1 – If targets outside of Iran were surplus to requirements, why did the first iteration of Conficker only exclude computers based in the Ukraine? Why was that restriction later removed? Why not only infect machines in Iran in the first place? It is also not true to say that machines infected with Conficker were all unharmed, Conficker was used to deliver Fake AV and had a functional relationship with Waledac botnet C&C

2 – The levels of sophistication in Conficker and Stuxnet are in different leagues. The original version of Conficker used a single already patched Windows vulnerability to spread, the second variant added the capability to spread via removable drives and by brute forcing passwords against a list of common password variants, neither method sophisticated. There was a level of sophistication in the scale of pseudo-random domains that were generated by the malware as potential C&C locations, but nothing that wasn’t quickly reverse engineered and understood. In the third variant of Conficker the propagation methods were actually removed, only to reappear again in the fourth significant variant. Stuxnet was a far more sophisticated animal, taking advantage of zero-day vulnerabilities and requiring specialist knowledge of SCADA systems and nuclear facilities.

3 – I would theorise that the creators of Stuxnet chose to also use the MS08-67 vulnerability because its effectiveness is demonstrated by the fact that Conficker is still one of the most prevalent infections in enterprise networks, three years after its initial appearance. Why would you make two pieces of malware that propagate using the same vulnerability and yet rely on one to download the other?

4 – The “activation date” of April 1 was coded into the third variant of Conficker. You don’t need unspecified time-stamps on unspecified files to tell you that.

5 – April 1st is also April Fool’s day in many countries around the world, it’s also the anniversary of the founding of Apple Inc., the founding of the Serious Organised Crime Agency (SOCA) in the UK, the birth of the Republic of Ireland and the land blockade of West Berlin by the East German military. Get my point? As regards President Mahmoud Ahmadinejad saying that his country would continue to pursue it’s nuclear program, well surely, pick a day, pick any day…

Then of course there’s the difficult conclusion, relying on persons unknown to plug a USB device into a Confuxnet infected machine, then unknowingly taking that same USB drive and plugging it into a PLC in a nuclear facility. Given the “unprecedented sophistication” of everything that has gone before, it’s this one just a tiny bit of a shot in the dark? A little bit “hit and hope”?

Sorry Mr. Bumgarner, it could be true, of course it could, and it could be that you have been misreported, but on the evidence you present so far, I just don’t buy it.

If I were a government with this kind of resource at my disposal, wouldn’t it make sense for one of my operatives in the target facility to simply take the USB containing Stuxnet right there for me?

I know, there weren’t any aliens.

5 Security Questions for your SaaS provider

Rik Ferguson — Thu, 04 Aug 2011 12:49:51 +0000

used by permission from ky_olsen's Flickr stream

Software as a Service is seeing sustained growth and sustained adoption in both enterprise and in the home. According to a Gartner release in July 2011, Software as a Service revenue reached $10 billion in 2010 and is still growing. In fact Gartner estimate growth of over 20% 10 $12.1 billion on 2011.

The Gartner definition of Software as a Service is software that is “owned, delivered and managed remotely by one or more providers. The provider delivers an application based on a single set of common code and data definitions, which is consumed in a one-to-many model by all contracted customers anytime on a pay-for-use basis, or as a subscription based on use metrics”. The example that is cited in almost every article and presentation on the subject is Salesforce.com, and while they are a major provider in the SaaS arena it is important to recognise that SaaS comes in many different flavours. Customer Relationship Management, Human Resource Management, Cloud backup, Collaboration platforms, accounting platforms, helpdesk management, managed services and web or email filtering to name but a few.

The economic benefits, to providers and customers alike are relatively obvious to spot, the cost of user provisioning (the SaaS model) when compared to the cost of application acquisition, licensing and rollout (the on-premise model) is extremely attractive. The SaaS provider is able to more quickly and easily update and manage the software and service due to its centralised nature, application improvements are easier to make as a result of the visibility the provider has of customer usage patterns and the scalability and pay-per-use is attractive for both customer and provider. In addition the possibilities for integration and open interfaces are greater, with many SaaS providers already offering social media-like collaboration functions or open interfaces (APIs).

While SaaS may offer a flexible and cost-effective alternative to a traditional application environment, it is not without risk. By moving to a hosted platform, as opposed to in-house, enterprises must necessarily sacrifice a large element of control over parts of their operating environment. With SaaS in particular, almost the only choice you have is whether you upload certain data or not, the rest is largely out of your hands. You do of course retain the legal and regulatory accountability for the security of your data.

The risks in a SaaS environment are many, and largely related to the benefits offered. As I mentioned previously, your provider has access to your usage habits of the platform, normally through some kind of web analytics, they also have the capability of accessing all of your data and this in itself presents the risk of unauthorised access or monitoring by an insider.

The centralised nature of the system and the “one configuration fits many” model of the multi-tenanted environment means that, should a vulnerability affect one customer, there is a strong possibility that other customers will be equally affected. The Epsilon breach is one of the more recent examples and it affected many Fortune 500 companies using the same SaaS provider. The scope for exploits of vulnerabilities is wide. Common protocols and the software stack are used by most SaaS providers (HTTP, XML/SOAP, JSON, CSS and JavaScript) and these are readily and regularly exploited if not correctly engineered, implemented or configured. Additionally, the more scope a platform offers for customisation and external integration (a key selling point for SaaS vendors), the more chance there is that some other customer will introduce a vulnerability from which another may suffer the consequences. Such is the nature of a multi-tenanted environment.

5 Key security questions to ask your SaaS provider:

1 – Penetration testing – How is the environment pen tested, how often and do you have the ability to independently pen test your own part of the environment? Without regular, in-depth pen testing you have no visibility of your current security posture.

2 – Data Security – How is data encrypted in storage and in transit across the shared resources of the SaaS provider data centre? Who has access to the keys? Is separation of duties and separation of keys and data maintained? Can the provider offer you a SAS 70 report?

3 – Multi-tenancy – Is there an option that provides for single tenant hosting? Also explore whether this single tenancy comprises simply the application or also the data storage?

4 –Disaster Recovery – In the event of catastrophic failure, or external intrusion and data loss what backup and recovery procedures are in place? Where is backed up data stored (and encrypted again) and how is it effectively restored?

5 – User Authentication – What is the sign on procedure for the SaaS application? Are multiple factors in use? Is it possible to integrate sign-on with authentication structures already in use by the customer?

Malvertising, who’s responsible?

Rik Ferguson — Fri, 01 Apr 2011 12:18:05 +0000

Online advertisements are a part of our daily browsing experience as they are also an essential part of companies’ online marketing strategies. So how do we know, when visiting websites that carry these networked advertisements, whether we are opening ourselves up to criminal compromise through malicious ads?

Tweet from the New York Times after they fell victim to criminal ads

Web site owners use trusted content networks to provide advertisements for their websites, and criminals are actively targeting this trust relationship as it represents a weak link in the chain of content control. Criminals create shell companies to place advertisements that hide malicious content in ads that are subsequently placed with high profile advertising networks. These malvertisements are then syndicated across many hundreds of web sites silently infecting as many victims as possible, as these examples illustrate.

Malvertisments, as they are referred to, have become increasingly common over the past few years and continue to be a growing problem. The potential number of victims available to criminals through a syndicated ad will often far outstrips the potential return for compromising an individual website. Internet users are unknowingly putting themselves at risk when they visit legitimate websites, which happen to be carrying malvertisements, designed to invisibly and automatically infect them through drive-by downloads. A drive-by download usually involves a chain of events; the victim visits a website which in this case is carrying a malvertisement, the malvertisement will contain content (most often JavaScript or Adobe Flash) which will be automatically executed by the browser. The purpose of the JavaScript is to automatically and invisible redirect the browser to a server hosting exploits (commonly a criminal exploit kit such as Yes!, Eleonore or Phoenix for example) these exploits are then used to push out the final malicious payload of the criminal’s choosing. In some cases exploits for technologies such as Adobe Flash are embedded directly within the malvertisements and this has the same end result of delivering a malicious payload. Once infected, your PC is compromised or your virtual wallet lifted in a number of ways; from pushing fake security software which attempts to fool the you into believing that your PC is infected with any number of entirely bogus malware which only this (paid-for) application can remove, to criminals stealing your personal or financial details and/or obtaining remote access to your PC.

So where does the responsibility lie? Is it with the web site that is hosting the malicious adverts, the network distributing them, or the consumer who visits the website? Really the responsibility, as well as the potential for damage, is shared. Web site owners and ad-networks alike suffer embarrassing brand damage when their customers are infected and the victim of course suffers the pain of information or identity theft and financial loss.

It is certainly true to say that if the right checks and balances were in place the problem would largely cease to exist, at least on legitimate websites. Clients of ad-networks should be applying pressure to their provider of choice to ensure that the appropriate checks are made before the advert goes out. Ideally, automated systems need to be in place at the advertising content providers, to run the ads through a sandbox before they are released into the public domain, checking for any kind of active or malicious code. Third party providers should perform specific checks to verify URLs and detect any unexpected or unwanted behaviour such as automated redirections, even if not malicious no web user wants to be bounced off to a third party website simply as a result of rendering an ad in their browser and no website owner would want their visitors stolen in this way either!

In the meantime, Internauts should ensure that they have the appropriate anti-malware software installed on their PC to minimise the risk. Free options include tools such as Browser Guard, which blocks exploit attempts and detects malicious JavaScript, stopping it from executing. When choosing anti-malware software, it’s important not to focus purely on software that will scan for bad files, but also that will stop PCs (and not just browsers) from connecting to malicious destinations.

Google Android rooted, backdoored, infected.

Rik Ferguson — Wed, 02 Mar 2011 13:08:49 +0000

Image from MJ/TR Flickr under Creative Commons

The folks over at Android Police published details yesterday of what they describe as “the mother of all Android malware” that was initially spotted by reddit contributor lompolo.

Lompolo posted details of 21 Android apps which were repackaged version of legitimate apps, at current count now more than 50 malicious apps appear to be involved. The repackaged versions include the rageagainstthecage or the exploid exploit which is capable of gaining root access to the device. Not only do these trojanised apps steal device details such as IMEI and IMSI but they also install further hidden malware which siphons even more user information off the device and into the hands of criminals. Further research from Android Police reports that this second payload also contains a dropper capable of downloading further code.

In a response to the intial posting by lompolo one of the developers of the legitimate apps that have been hijacked commented:

“I’m the developer of the original Guitar Solo Lite. I noticed the rogue app a bit more than a week ago (I was receiving crash reports sent from the pirated version of the app). I notified Google about this through all the channels I could think of: DCMA notice, malicious app reporting, Android Market Help…they have yet to respond. Thankfully this was posted on Reddit, since after the post the rogue dev and all his apps have been removed from the market. There really should be a faster/easier way to get Google to act on it!”

Trend Micro detect this threat (popularly known as DroidDream) as ANDROIDOS_LOTOOR.A, further details in the link.

During the five days these apps were available an estimated 50,000 downloads have taken place. Google have now pulled the apps and blocked the rogue developer from Android marketplace, they have also remotely removed the apps from affected handsets. Of course this remote kill switch will not remove any other code that may have been dropped onto the device as a result of the initial infection. So if you are one of the estimated 50,000 people who have downloaded these malicious apps it could be worth your while investigating the possibility of getting a replacement handset or reinstalling the operating system on the one you have if possible.

The Android app ecosystem is by definition open, there is a wide array of app stores available and apps can be published to the user community in minutes. This greater openness of the developer environment has been argued to foster an atmosphere of creativity, but as Facebook have already discovered it is also a very attractive criminal playground.

It is worth remembering that full security suites are now available for Google Android, such as this one. The number of threats to mobile platforms is growing and growing at a steady rate. Of course the sheer volume of mobile malware is a long way from the epidemic proportions of Windows based malware, but criminal interest is clearly there and growing. We see multi-platform attacks distributed by the same criminal groups that traditionally have focused on Wintel systems, and the growth in complexity of threats, for example ZeuS malware now incorporating mobile elements aimed at intercepting SMS banking authentication codes is striking. Criminals are driven by consumer behaviour and as the money-making opportunities move to mobile platforms criminals will, in fact already are, following.

A full list of the trojanised apps, published by Myournet, is:

Falling Down
Super Guitar Solo
Super History Eraser
Photo Editor
Super Ringtone Maker
Super Sex Positions
Hot Sexy Videos
Chess
下坠滚球_Falldown
Hilton Sex Sound
Screaming Sexy Japanese Girls
Falling Ball Dodge
Scientific Calculator
Dice Roller
躲避弹球
Advanced Currency Converter
App Uninstaller
几何战机_PewPew
Funny Paint
Spider Man
蜘蛛侠

The Guardian have published an expanded list of apps believed to be trojanised in this way here.

Facebook open JavaScript hole

Rik Ferguson — Fri, 11 Feb 2011 16:41:18 +0000

Used under creative commons from Editor B Flickr photostream

Yesterday Facebook made some important changes to the way in Facebook Pages, the fan pages set up by brands, bands and even cucumbers could be created.

In the past the tabs which could be added to these pages have been set up in two ways; the first used the Facebook FBML app. This allowed page tabs to be created using static Facebook Markup Language (FBML) or HTML, it wasn’t particularly engaging but it was very simple to use. The second method for creating page tabs was by adding a custom Facebook app inside a standard FBML tab. This meant the custom app could request external data from a third party and display it inside the page tab. This content though was subject to many technical limitations, as it was all proxied through Facebook which broke many things including tracking pixels, JavaScript and Flash.

So what is the big change? Well Facebook now allow iframes to be included inside Facebook apps on page tabs, meaning that all that Facebook proxying can be avoided. While this is no doubt great news for legitimate developers it will undoubtedly make life for those with malicious intent much easier too.

It is now possible to set up a Facebook page, create a default landing tab (the one you first see when you visit the page) and include an app that contains an iframe. That iframe can for example contain JavaScript which immediately and without user interaction redirects you to any site it chooses. Say for example a page containing Fake AV or a page where an exploit kit is waiting to silently infect you with malware.

No more likejacking required, no more having to persuade users to install your app, if a criminal can make the bait sweet enough just to get you to visit the page, that is all they will require to start the chain that leads to your computer being compromised and used for criminal purposes.

Of course Facebook ask their developers to agree to a code of conduct that prohibits such activities, but when it comes to criminals, that’s a bit like taking a driving license away from a joyrider.

I have informed Facebook of this oversight in their new functionality and will update this blog posting if I hear back from them.

Thanks to Stig Edvartsen for his eagle-eyes and Heidi Obschil-Müller for the iframe

Merry Christmas and a Happy New 0-Day

Rik Ferguson — Thu, 23 Dec 2010 11:16:43 +0000

Well, work is winding down for the festive season and bellies are being prepared for several days of abuse. Maybe we should be preparing our computers for equal amounts of abuse if we use Internet Explorer right now…

My freshly built Snowlady, Frostenia

Firstly, I want to take this opportunity to wish all the Countermeasures readers all the best for this holiday period and wish that the very best thing that happened to you in the last year is the worst that hapens in the next! And to take one worry off your mind, in the absence of a patch for the new
Microsoft Internet Explorer 0-day vulnerability, keep yourselves safe this season by installing the free tool Browser Guard 2010 which already offered protection against this exploit before it was even known.

The vulnerability certainly looks serious, affecting all supported versions of Internet Explorer on all supported versions of Windows, including Windows 7, Vista and XP. As vulnerabilities go, this kind is of the most worrying as it allows remote execution of code, meaning the attacker can run programs (such as malware) directly on the victim computer. It also bypasses to key security mechanisms put in place to protect against this kind of exploit, namely Data Execution Prevention (DEP) and Address Space Layout Randomisation (ASLR).

The Microsoft advisory recommends that users set their Internet and Local Intranet security zones to “High” but have not yet said if they plan to release an out of band patch. The exploit code for this vulnerability has already been made public and already incorporated in the metasploit toolkit and we expect to see widespread criminal exploitation of this vulnerability.

This vulnerability is highly reminiscent of a vulnerability at the same time two years ago which prompted several national governments to warn against using IE and to switch to an alternative browser. For my point of view on that debate, have a gander at this blog posting.

Your secrets are (not) safe with mIE

Rik Ferguson — Mon, 06 Sep 2010 13:41:29 +0000

Tweet by Microsoft Security Response team

Microsoft Security Response team posted an interesting tweet at the tail end of Friday afternoon last week. The message itself was relatively low key, but pointed to something possibly more worrying. Enough to make me do some digging anyway…

“We’re aware of a publicly disclosed issue involving Internet Explorer. We’ll continue to investigate over the weekend.”

Hm, publicly disclosed where and by whom? What kind of issue and what kind of effect?

Well it looks like the tweet might be referring to an evolution of a vulnerability that was first made public by Google’s Chris Evans back in December of last year in a post on his Scary Beast Security blog.

Why have I jumped to that conclusion? Well, also on Friday last week, just a couple of hours before the Microsoft tweet, Chris Evans posted the following to the Full Disclosure mailing list

“Hi, In an attempt to get this bug fixed…

A nasty vulnerability exists in the latest Internet Explorer 8. I have been unsuccessful in persuading the vendor to issue a fix.

The bug permits — for example — an arbitrary web site to force the victim to make tweets.”

In the mailing list posting Chris goes on to state that there is evidence that Microsoft may have been aware of this bug since 2008 and that the same defect “probably” affects earlier versions of IE too.

The exploit acts by stealing the (supposedly secret) credentials for an already authenticated browser session, in his example Twitter. Those credentials are then abused to send arbitrary forged content.

Embarrassingly Opera, Chrome, Firefox & Safari have all already fixed this vulnerability. Let’s hope Microsoft had a good long investigate over the weekend then eh? With the ever increasing popularity of URL shortening services, vulnerabilities like this are all too easy to exploit.

Don’t take shortcuts

Rik Ferguson — Tue, 20 Jul 2010 08:40:58 +0000

picture from bradleygee's Flickr photostream under Creative Commons.

On the 16th of July Microsoft released Security Advisory 2286198 confirming an as yet unpatched vulnerability in Windows Shell that exposes all users of all current versions of Microsoft Windows to very real risk of attack and infection.

According to Microsoft “The vulnerability exists because Windows incorrectly parses shortcuts in such a way that malicious code may be executed when the icon of a specially crafted shortcut is displayed.” So what does that mean in plain language?

It means that if any user of Microsoft Windows opens a folder containing a shortcut which has been designed to exploit this vulnerability, they will be infected. No opening of files required, simple browsing is enough.

Although Microsoft have stated that “This vulnerability is most likely to be exploited through removable drives” users should be on their guard against all shortcut files whose authenticity they cannot guarantee. This same vulnerability could be exploited though contaminated file shares or something as simple as a malicious compressed archive such as a zip file.

Worryingly, the malware that was first exploiting this vulnerability appeared to be highly targeted, looking for Siemens WinCC SCADA systems, SCADA systems are routinely used in the control of utilities such as power and water and also in large-scale manufacturing. Siemens were warning their customers of this as early as July 14th.

The source code for this malware is now in open distribution, (and incorporated into the Metasploit framework) and we can expect to see widespread criminal adoption of this technique from this point.

For now the best defence against attacks is contained within the Microsoft Security Advisory; disable the displaying of icons for shortcuts and disable the WebClient service.

Further details on Trend Micro’s detection of the malware involved are available on the TrendLabs blog. Please be aware this is a breaking situation and further malware will take advantage of this same vulnerability.

New malicious Twitter spam

Rik Ferguson — Tue, 15 Jun 2010 14:36:25 +0000

Just a couple of hours ago I started getting some very shady looking tweets like the below.

Malicious Tweet

The link in the post is abbreviated, but leads on to a site hosting some obfuscated JavaScript.



If this JavaScript is executed by the browser an unpleasant payload is delivered to the victim. So far we have seen both malicious PDF documents and executable files. These Trojans attempt to connect to additional locations to download further malware. TrendLabs are currently investigating, watch the blog for updates.

This latest Twitter malspam follows hot on the heels of the Gaza and FIFA spam run earlier this month.

Be careful where you click and make sure your security software is blocking those evil links.