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.)

 

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.

 

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/security/cybercrime/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/article/9227736/Researchers_reveal_how_Flame_fakes_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.

 

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

 

http://blog.fireeye.com/research/2012/06/flame-skywiper-cnc-update.html

 

http://www.theregister.co.uk/2012/07/30/flame_wins_pwnie/

 

Flamer Analysis: Framework Reconstruction

 

Stuxnet And Flame Scare Critical Iranian Infrastructure Offline

 

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

Ars article.

 

From Ars:

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.

 

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

Article

 

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.

 

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

 

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.

 

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.

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.

 

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

 

I'll watch/ look into that. Thanks.

 

Flame Has a Cousin

"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/2012/10/miniflame-espionage-tool/


And the cyberwar keeps rolling along.

 

Kaspersky discovers miniFlame cyberespionage malware directly linked to Flame and Gauss

Article.

 

Also see, from Computer World: http://www.computerworld.com/s/arti...ge_malware_directly_linked_to_Flame_and_Gauss • Venture Beat : http://venturebeat.com/2012/10/15/miniflame-malware/ • Beta Beat : http://betabeat.com/2012/10/meet-miniflame-the-ninja-assassin-of-cyber-warfare-tools/

 

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.

 

Also see: http://www.h-online.com/security/news/item/miniFlame-the-Flame-trojan-s-little-brother-1731705.html • http://www.technewsworld.com/story/76414.html