The Flame: Questions and Answers

Perhaps. Some of the more, umm, "fringe" elements in politics here (and elsewhere) do seem to have a hankering for Armageddon. I don't think they have enough influence (yet) to actually make anything of it though.

Then again, starting wars for economic reasons is old stuff...

For now I would ascribe things like this to shortsightedness and stupidity, of which there are plenty in any government. "Never ascribe to malice what is attributable to stupidity or ignorance," etc. Not to say that my opinion won't change with new data, but I'd rather not immediately assume the worst.

(And I'd better shut up before I trip the mods' politics detectors.)

Edit: Mrkvonic: what would be most worrisome to my mind is the possibility of electrical power being cut off across a large area. That could be an economic disaster, and possibly lead to loss of life (depending on the exact situation and the duration of the outage). I'm not sure how much within the realm of possibility that is though..

(I do recall a Chinese research paper about generating cascading power failures in an electrical grid, without any physical tampering with the infrastructure. Not sure if it was ever proven realistic.)

[noone_particular]

For now I would ascribe things like this to shortsightedness and stupidity, of which there are plenty in any government. "Never ascribe to malice what is attributable to stupidity or ignorance," etc. Not to say that my opinion won't change with new data, but I'd rather not immediately assume the worst.

Flame was designed to be a weapon and was deliberately used in a targeted attack? How can you not ascribe malice? The stupidity applies with losing control over it and some of the coding, but it was specifically designed to be a weapon. I'm all for leaving specific politics and stated vs real motives for such a weapon out of the discussion (but would be glad to debate them elsewhere), but one fact is clear. This was created to be a weapon and used as such, the exact thing our government said it would consider an act of war if we were targeted in this manner. By our own definition, we've committed an act of war. How can we not expect a response? It's hard enough for real people to differentiate between civilian and military targets. Can we honestly expect better from man made code, which has no conscience or sense of right and wrong? I fear we've opened a real Pandoras box here. No matter whose code it (or the ones to follow) is/are, in the end we know who pays for it, financially, physically, in all ways.

Okay, "not malicious" was badly worded. I'll give you that. But I think our nation-states would have to be even more messed up than they are (which is pretty messed up already) to contemplate the deliberate arrangement of a world war.

(Yet.)

As I said though, my opinion is subject to change with changing data.

[RJK3]

Originally Posted by m00nbl00d

Yes, it matters. It's the patient zero that matters, actually. If there's no patient zero, Flame is nothing but a hype. Just because there are stupid people everywhere, including certain organizations, that doesn't necessarily give any credit to the malware/attacker in question.

You often seem to miss the point people make - instead doggedly re-stating the original point that you already made and that everyone had already understood

No one doubts that it would be handy if no 'patient zero' existed. HungryMan is simply pointing out that one of the infection vectors of the Flame malware (Gadget MITM module / fake Windows update), meant that it could infect the computers of more security conscious people on the same local area network. This is if the following was true:

1. Their system proxy settings were set to auto (http://www.informationweek.com/news/...rime/240001490)
2. Their timezone was set to GMT+2 or higher (https://twitter.com/craiu/status/209628249024770048)
3. They attempted a Windows Update (http://www.computerworld.com/s/artic...Windows_Update)

This is unfortunate, since there is always going to be someone who will be infected by something like Flame through the other infection vectors it ostensibly used -whether or not they were 'zero-day' exploits like Stuxnet employed.

There are all kinds of reasons for being on a LAN with other computers you don't control. The risk of Flame to the average person is minimal, but the general use of MITM attacks by malware is a real threat.

Since you can't always rely on the network administrator to prevent MITM attacks originating from the LAN, then as I suggested in the Trusteer Rapport thread, one should be careful what they do while on a LAN they don't control. This includes Windows Updates apparently.

[PaulyDefran]

Originally Posted by noone_particular

Against this sort of attack, about the only thing that would help is filling the USB plugs with epoxy.

The double standard behind this makes me want to vomit.

I've recently been investigating (for other reasons), software like My USB Only and USB Block. I wonder how easily they are bypassed? USB Block seems pretty stout from my layman's research.

http://www.newsoftwares.net/usb-block/

Under "Benefits".

PD

[Dermot7]

FireEye has since made another discovery regarding Flame’s command and control (CNC) behavior: it appears that the Flamer/sKyWIper malware’s callback has recently changed.

http://blog.fireeye.com/research/201...nc-update.html

[Dermot7]

Black Hat Hackers and other delegates to Black Hat celebrated the best and worst of information security with the latest edition of the Pwnie Awards, the security geek equivalent of the Oscars.

The award in the top "Epic 0wnage" category went to whoever's behind the Flame cyber-espionage spyware. It was their use of an MD5 collision attack to create counterfeit Microsoft certificates – and thereby push bogus updates via the Windows Update – that earned the respect of hackers. Recent reports by the Washington Post suggest that a team from the CIA, the National Security Agency and the Israeli Defence Force developed the attack.

http://www.theregister.co.uk/2012/07...me_wins_pwnie/

[siljaline]

Flamer Analysis: Framework Reconstruction

From the very beginning of our analysis of Win32/Flamer it was clear that this was an extremely sophisticated piece of malware which we had never seen before. It implements extremely elaborate programming logic and has an intricate internal structure. At the heart of Flame’s modularity lies a carefully designed architecture allowing all its components interoperability without causing any incompatibilities. In this blog post we will concentrate mainly on the internal architecture of the mssecmgr.ocx module (Flame, Duqu and Stuxnet: in-depth code analysis of mssecmgr.ocx). In the course of our research we analysed several different versions of mssecmgr.ocx and found specific architectural similarities that allow us to reconstruct Flame’s framework.

[siljaline]

Stuxnet And Flame Scare Critical Iranian Infrastructure Offline

Iran is set to take critical infrastructure offline next month, following highly sophisticated cyber attacks such as those carried out with the Stuxnet and Flame malware.

Reza Taghipour, the country’s telecommunications minister, said “one or two” countries who were hostile to Iran were controlling the Internet, making it untrustworthy, according to the Daily Telegraph.

It is believed the US and Israel have been cooperating on cyber attacks against Iranian infrastructure. Reports they created Stuxnet, which was thought to have set Iran’s nuclear programme back two years, and Flame, which attempted to collect vast amounts of information from those working on the nation’s critical operations.

[JRViejo]

W32.Flamer is a sophisticated cyber espionage tool which targeted the Middle East. News of its existence hit the headlines earlier in 2012. Symantec, has performed a detailed forensic analysis of two of the command-and-control (C&C) servers used in the W32.Flamer attacks earlier this year.

Have I Got Newsforyou: Analysis of Flamer C&C Servers by Symantec Security Response.

[siljaline]

New in-the-wild malware linked to state-sponsored Flame targeting Iran

The operators behind Flame, the highly advanced espionage malware that targeted Iran, began their campaign no later than 2006 and supported three other pieces of malicious software, one of which is still circulating on the Internet, researchers said.

The revelations are the result of a forensic investigation of control servers used to help execute the flame operation.
They show the state-sponsored campaign was even more far-reaching than previously believed. The servers were disguised as publishing platforms running a fictitious content management application called Newsforyou and were programmed to destroy hard-drive data to prevent the espionage from ever coming to light. They also used strong cryptography to prevent lower-level operators from controlling infected computers or viewing the contents of data that was extracted from them.

Ars article.

[chronomatic]

From Ars:

"More interestingly, the results have shown that not our published chosen-prefix collision attack was used, but an entirely new and unknown variant," Stevens wrote in a statement distributed on Thursday. "This has led to our conclusion that the design of Flame is partly based on world-class cryptanalysis. Further research will be conducted to reconstruct the entire chosen-prefix collision attack devised for Flame."

"It's not a garden-variety collision attack, or just an implementation of previous MD5 collisions papers—which would be difficult enough," Matthew Green, a professor specializing in cryptography in the computer science department at Johns Hopkins University, told Ars. "There were mathematicians doing new science to make Flame work."

I had assumed the Flame authors used previously published MD5 attacks. But, according to these cryptographers, the attack was brand new. It makes you wonder what else NSA can do where crypto is concerned. According to some, they have broken public-key crypto as well.

[siljaline]

Cyberwar on Iran more widespread than first thought, say researchers.

The covert cyberwar being waged in the Middle East and north Africa – particularly against Iran and its allies – is even more sophisticated and widespread than had previously been understood, according to new research.

Two leading computer security laboratories – Kaspersky Lab and Symantec – have been studying a series of powerful cyberweapons used against targets including the Iranian nuclear programme and Lebanese banks accused of laundering money for Iran and its ally Hezbollah. They are now convinced they were all probably created by a national government or governments working together.

Article

[chronomatic]

Originally Posted by Rmus

While the analysis of what this malware does once installed may be fodder for good headlines, it's rather inconsequential from a preventative point of view, since it first has to install to do anything, as did Stuxnet, Conficker, and other sensational malware, all easily preventable with proper security measures in place.

It depends. If the attacker can get a code path to the kernel (ring 0), it doesn't matter what protections you have in place. You are going down. And this can sometimes be done from user-space (i.e. a limited user account) depending on how/if the process shares memory with the kernel.

This is the problem with monolithic kernels. Own the kernel, you own everything. There is no stopping it if the attacker has a path to the kernel and has a 0-day exploit. It depends on the exploit, but it can be done. You can bypass anything -- Applocker, Windows Integrity Controls, AV, anti-executables, etc.

[Rmus]

Originally Posted by chronomatic

It depends. If the attacker can get a code path to the kernel (ring 0), it doesn't matter what protections you have in place.

...


There is no stopping it if the attacker has a path to the kernel and has a 0-day exploit... You can bypass anything -- Applocker, Windows Integrity Controls, AV, anti-executables, etc.

Well, in previous posts, I've stressed (speaking for myself) that protections in place, security measures. etc. begin with policies and procedures.

The protections you list omit these.

The principal entry points for malware code on my system are

1. through a port
   
   
2. via the web through a browser
   
   
3. via external media, eg, USB drive

A properly configured firewall and browser take care of the first 2. Secure policies about USB take care of the 3rd.

I've mentioned before that even though I have an anti-execution product, it has never alerted to anything in my normal, daily use of the web, since no malware code has ever been able to execute.

Regarding 0-day exploits: having an exploit is one thing. Getting it to trigger on a system is another.

Using the latest Java exploits as an example -- with a properly configured browser, they just don't get a chance to do anything on my system. I've demonstrated this in other posts.

So, until something changes in the delivery mechanisms used by cybercriminals, I'll hold to this position. If something does change, I'll certainly reassess the situation.

Speaking just for myself...


regards,

-rich

[chronomatic]

Originally Posted by Rmus

The protections you list omit these.

The principal entry points for malware code on my system are

1. through a port
   
   
2. via the web through a browser
   
   
3. via external media, eg, USB drive

That's all true. An attacker has to enter somehow. Either through a listening port or via an application that calls out (browser).

Closing ports is easy (in fact most OS's don't have open ports by default -- Windows is an exception I guess). The harder part is securing applications that call out. NoScript can help in a browser, but it breaks functionality so much that I don't use it. Better, imo, is locking the browser down with a MAC policy using the principle of least privilege. You give the browser access to the files and libraries it needs to run and then stop it from accessing anything else. So if an attacker pops your app (whether its a browser or whatever) with an exploit, he will be confined by the policy which will usually make his attack futile.

Another good mitigation is DEP/ASLR and other memory hardening techniques. While it wont stop all exploits, it will stop a good percentage of them.

Basically I am agreeing with you. My only point was that nothing is 100% fool-proof when an application is sharing memory with kernelspace and hooking into the kernel via all kinds of API calls. This is an inherent problem with monolithic kernels -- it's impossible to confine userspace from kernelspace with perfect efficacy.

[Hungry Man]

Doesn't have to be a listening port. It can be closed if they have a vulnerability like that one not long ago. But yes, a closed port is generally secure.

I'm just saying there's always a way into a machine if it has the ability to connect out to the internet.

Basically I am agreeing with you. My only point was that nothing is 100% fool-proof when an application is sharing memory with kernelspace and hooking into the kernel via all kinds of API calls. This is an inherent problem with monolithic kernels -- it's impossible to confine userspace from kernelspace with perfect efficacy.

This is a problem witih any system that uses address spaces. Any kernel, monolithic or not, is going to have exported areas in other address spaces.

Otherwise I agree with your post entirely. Least privilege and application/user separation are the best ways to go.

[chronomatic]

Originally Posted by Hungry Man

This is a problem witih any system that uses address spaces. Any kernel, monolithic or not, is going to have exported areas in other address spaces.

Some microkernels are designed to avoid this behavior and can be hardware enforced. The idea is you run a few thousand lines of code at kernel level and everything else (drivers included) at userspace level. You can enforce separation via IOMMU hardware (which is common on modern CPU's). If a driver goes bad, it cannot affect Ring 0. Indeed it can't even crash the system. Such is the case with MINIX, for example, as well as others. But the problem is the performance will drop by 10% or more.

Andy Tannenbaum gave a talk at FOSDEM describing Minix in detail. It is worth a watch if you have an hour. -https://www.youtube.com/watch?v=bx3KuE7UjGA-

[Hungry Man]

I'll watch/ look into that. Thanks.

[Mman79]

"Researchers have uncovered new nation-state espionage malware that has ties to two previous espionage tools known as Flame and Gauss, and that appears to be a “high-precision, surgical attack tool” targeting victims in Lebanon, Iran and elsewhere.

Researchers at Kaspersky Lab, who discovered the malware, are calling the new malware miniFlame, although the attackers who designed it called it by two other names – “SPE” and “John.” MiniFlame seems to be used to gain control of and obtain increased spying capability over select computers originally infected by the Flame and Gauss spyware."

http://www.wired.com/threatlevel/201...spionage-tool/


And the cyberwar keeps rolling along.

[siljaline]

Kaspersky discovers miniFlame cyberespionage malware directly linked to Flame and Gauss

Security researchers from Kaspersky Lab have identified another piece of malware targeting the Middle East that is likely part of the interrelated cyberespionage efforts behind Stuxnet, Duqu, Flame and Gauss. The malware was dubbed miniFlame because its code suggests that it was built on the same platform as the highly sophisticated Flame threat discovered in May. However, the functionality of miniFlame -- called SPE by its authors -- is different.

Article.

[JRViejo]

Merged Threads to Continue Related Topic.

[siljaline]

Also see, from Computer World: http://www.computerworld.com/s/artic...lame_and_Gauss • Venture Beat : http://venturebeat.com/2012/10/15/miniflame-malware/ • Beta Beat : http://betabeat.com/2012/10/meet-min...warfare-tools/

[siljaline]

Meet miniFlame – the Latest CyberWarfare Discovery • MiniFlame Sabotage Tool Spotted Supporting State-Funded Malware • miniFlame aka SPE: "Elvis and his friends" • After Flame and Gauss strike, MiniFlame takes aim.

[siljaline]

Also see: http://www.h-online.com/security/new...r-1731705.html • http://www.technewsworld.com/story/76414.html