Posts Tagged ‘Flame’

The Sportsmanship of Cyber-warfare

Wednesday, June 27th, 2012

As a bit of a history buff I can’t avoid a slight tingling of déjà vu every time I read some new story commenting upon the ethics, morality and legality of cyber-warfare/cyber-espionage/cyberwar/cyber-attack/cyber-whatever. All this rhetoric about Stuxnet, Flame, and other nation-state cyber-attack tools, combined with the parade of newly acknowledged cyber-warfare capabilities and units within the armed services of countries around the globe, brings to the fore so many parallels with the discussions about the (then) new-fangled use of flying-machines within the military in the run-up to WWI.

Call me a cynic if you will, but when the parallels in history are so evident, we’d be crazy to ignore them.

The media light that has been cast upon the (successful) deployment of cyber-weapons recently has many people in a tail-spin – reflecting incredulity and disbelief that such weapons exist, let alone have already been employed by military forces. Now, as people begin to understand that such tools and tactics have been fielded by nation-states for many years prior to these most recent public exposures, reactions run from calls for regulation through to global moratoriums on their use. Roll the clock back 100 years and you’ll have encountered pretty much the same reaction to the unsporting use of flying-machines as weapons of war.

That said, military minds have always sought new technologies to gain the upper-hand on and off the battlefield. Take for example Captain Bertram Dickenson’s statement to the 1911 Technical Sub-Committee for Imperial Defence (TSID) who were charged with considering the role of aeroplanes in future military operations:

“In case of a European war, between two countries, both sides would be equipped with large corps of aeroplanes, each trying to obtain information on the other… the efforts which each would exert in order to hinder or prevent the enemy from obtaining information… would lead to the inevitable result of a war in the air, for the supremacy of the air, by armed aeroplanes against each other. This fight for the supremacy of the air in future wars will be of the greatest importance…”

A century later, substitute “cyber-warriors” for aeroplanes and “Internet” for air, and you’d be hard-pressed to tell the difference from what you’re seeing in the news today.

Just as the prospect of a bomb falling from the hands of an aviator hanging out the cockpit of a zeppelin or biplane fundamentally changed the design of walled fortifications and led to the development of anti-aircraft weaponry, new approaches to securing the cyber-frontier are needed and underway. Then, as now, it wasn’t until civilians were alerted to (or encountered first-hand) the reality of the new machines of war, did an appreciation of these fundamental changes become apparent.

But there are a number of other parallels to WWI (and the birth of aerial warfare) and where cyber-warfare is today that I think are interesting too.

Take for example how the aviators of the day thought of themselves as being different and completely apart from the other war-fighters around them. The camaraderie of the pilots who, after spending their day trying to shoot-down their counterparts, were only too happy to have breakfast, and exchange stories over a few stiff drinks with the downed pilots of the other side is legendary. I’m not sure if it was mutual respect, or a sharing of a common heritage that others around them couldn’t understand, but the net result was that that first-breed of military aviator found more in common with their counterparts than with their own side.

Today, I think you’ll likely encounter the equivalent social scene as introverted computer geeks who, by way of day-job, develop the tools that target and infiltrate foreign installations for their country, yet attend the same security conferences and reveal their latest evasion tactic or privilege escalation technique over a cold beer with one-another. Whether it’s because the skill-sets are so specialized, or that the path each cyber-warrior had to take in order to acquire those skills was so influential upon their world outlook, many of the people I’ve encountered that I would identify as being capable of truly conducting warfare within the cyber-realm share more in common with their counterparts than they do with those tasking them.

When it comes to protecting a nation, cries of “that’s unfair” or “un-sporting” should be relegated to the “whatever” bucket. Any nation’s military, counter-intelligence organization, or other agency tasked with protecting its citizens would be catastrophically failing in their obligations if they’re not already actively pursuing new tools and tactics for the cyber-realm. Granted, just like the military use of aircraft in WW1 opened a Pandora’s box of armed conflict that changed the world forever, ever since the first byte’s traversed the first network we’ve been building towards the state we’re in.

The fact that a small handful of clandestine, weaponized cyber-arms have materialized within the public realm doesn’t necessarily represent a newly opened Pandora’s box – instead it reflects merely one of the evils from a box that was opened at the time the Internet was born.

– Gunter Ollmann, VP Research



The Flame/Flamer/sKyWIper Malware

Tuesday, May 29th, 2012

The world is abuzz this week with some flaming malware – well “Flame” is the family name if you want to be precise. The malware package itself is considerably larger than what you’ll typically bump into on average, but the interest it is garnering with the media and antivirus vendors has more to do with the kinds of victims that have sprung up – victims mostly in the Middle East, including Iran – and a couple of vendors claiming the malware as being related to Stuxnet and Duku.

A technical report on sKyWIper was released by the Laboratory of Cryptography and Systems Security (CrySys Lab) over at the Budapest University of Technology and Economics yesterday covering their analysis of the malware – discovered earlier in May 2012 – and they also drew the conclusion that this threat is related (if not identical) to the malware described by the Iran National CERT (MAHER) – referred to as Flamer. Meanwhile, Kaspersky released some of their own analysis of “Flame” on Monday and created a FAQ based upon their interpretation of the malware’s functionality and motivations.

There is of course some debate starting about the first detection of Flamer. Given the malware’s size and number of constituent components it shouldn’t be surprising to hear that some pieces of it may have been detected as far back as March 1st 2010 – such as the file “~ZFF042.TMP” (also seen as MSSECMGR.OCX and 07568402.TMP) – analyzed by Webroot and attributed to a system in Iran.

While it’s practically a certainty that the malware was created and infected a number of victims before it was “detected” in May, I’d caution against some of the jumps people are making related to the attribution of the threat.

Firstly, this behemoth of a malware pack is constructed of a lot of different files – many of which are not malicious; with the package including common library files (such as those necessary for handling compression and video capture) as well as the Lua virtual machine. Secondly, when you’re limited to an 8.3 file naming convention, even malicious files are likely to have name collisions – resulting in many spurious associations with past, unrelated, threats if you’re googling for relationships. And finally, why build everything from scratch? – it’s not like malware authors feel honor bound to adhere to copyright restrictions or steal code from other malware authors – nowadays we see an awful lot of code recycling and simple theft as criminals hijack the best features from one another.

As you’d expect from a bloated malware package developed by even a marginally capable hacker, there are a lot of useful features included within. It’s rare to see so many features inside a single malware sample (or family), but not exceptional. As Vitaly Kamluk of Kaspersky stated – “Once a system is infected, Flame begins a complex set of operations, including sniffing the network traffic, taking screenshots, recording audio conversations, intercepting the keyboard, and so on,” – which is more typical of an attack kit rather than a piece of malware. What do I mean by “attack kit”? Basically a collection of favorite tools and scripts used by hackers to navigate a compromised host or network. In the commercial pentesting game, the consultant will normally have a compressed file (i.e. the “attack kit”) that he can shuttle across the network and drop on any hosts he gains access to. That file contains all of the tools they’re going to need to unravel the security of the (newly) compromised host and harvest the additional information they’ll need to navigate onto the next targeted device. It’s not rocket science, but it works just fine.

I’m sure some people will be asking whether the malware does anything unique. From what I can tell (without having performed an exhaustive blow-by-blow analysis of the 20Mb malware file), the collection of files doesn’t point to anything not already seen in most common banking Trojans or everyday hacking tools. That doesn’t make it less dangerous – it merely reflects the state of malware development, where “advanced” features are standard components and can be incorporated through check-box-like selection options at compile time.

For malware of this ilk, automated propagation of infections (and infectious material) is important. Flame includes a number of them – including the commonly encountered USB-based autorun and .lnk vulnerabilities observed in malware families like Stuxnet (and just about every other piece of malware since the disclosure of the successful .lnk infection vector), and that odd print spooler vulnerability – which helps date the malware packaged. By that I mean it helps date the samples that have been recovered – as there is currently no evidence of what the malware package employed prior to these recent disclosures, or what other variants that are circulating in the wild (and not been detected by antivirus products today).

Are these exploits being used for propagation evidence that Stuxnet, Duku and Flame were created and operated by the same organization? Honestly, there’s nothing particularly tangible here to reach that conclusion. Like I said before, criminals are only too happy to steal and recycle others code – and this is incredibly common when it comes to the use of exploits. More importantly, these kinds of exploits are incorporated as updates into distributable libraries, which are then consumed by malware and penetration tool kits alike. Attack kits similar to Flame are constantly being updated with new and better tool components – which is why it will be difficult to draw out a timeline for the specific phases of the threat.

That all said, if the malware isn’t so special – and it’s a hodgepodge of various public (known) malicious components – why has it eluded antivirus products in the victim regions for so long? It would be simple to argue that these regions aren’t known for employing cutting-edge antimalware defenses and aren’t well served with local-language versions of the most capable desktop antivirus suites, but I think the answer is a little simpler than that – the actors behind this threat have successfully managed their targets and victims – keeping a low profile and not going for the masses or complex setups.

This management aspect is clearly reflected in the kill module of the malware package. For example, there seems to be a module named “browse32″ that’s designed to search for all evidence of compromise (e.g. malware components, screenshots, stolen data, breadcrumbs, etc.) and carefully remove them. While many malware families employ a cleanup capability to hide the initial infection, few include the capability of removing all evidence on the host (beyond trashing the entire computer). This, to my mind, is more reflective of a tool set designed for human interactive control – i.e. for targeted attacks.

Here at Damballa Labs we’re looking at the C&C infrastructure and relationships with other criminal campaigns and targeted attacks. I’m hoping to get some of the analysis out this week – assuming that there’s anything interesting there…

– Gunter Ollmann, VP Research