Comments

Zombie JohnMarch 19, 2013 7:36 AM

If you were Iran, wouldn't you disconnect your centrifuge controllers from everything but a closed network with no Internet connection? And then wouldn't you disable USB ports?

PetterMarch 19, 2013 9:18 AM

How many developers would be needed to create these state driven operations?
Are we talking 30 top notch coders, system specialists and encryption wizards or are they closer to 3000?

wumpusMarch 19, 2013 11:29 AM

@Petter

Depends on what you mean by "create", with people standing on each others shoulders and all. Since this is tippy-top -secret, I suspect that they have carved it up as much as possible with likely zero communication between the groups. One group finds zero day exploits, another creates the payload, another creates the "virus", another (probably more standard group of spooks) handles getting it on the target computers.

This cranks up the cost and helps remove any accountability, thus making it wildly popular in Washington DC.

Stephan BrunMarch 19, 2013 5:12 PM

Petter: Fred Brooks's Mythical Man Month and Eric Raymonds The Cathedral and the Bazaar are pertinent reading material here. In short, programming time isn't fungible, necessitating small teams. Testing, though, is, which means the testers can be as many as secrecy allows.

Dirk PraetMarch 19, 2013 7:54 PM

If my understanding of the article is correct, Gauss targets machines running a specific application and the encrypted payload is unlocked when its directory is located in the machines PATH/Windows Program Files Folder. All attempts at brute forcing the key(s) to unlock the payload(s) sofar have failed.

Which makes me assume no single machine has yet been found actively running one of the hidden Goedel module payloads. Now instead of trying to crack the key, why not develop a small program that totally sandboxes Gauss, monitors and records its every move and get antivirus/malware companies to distribute it with their next application update ? Just a matter of time before one or more of the Goedel payloads is unlocked, isolated and reverse engineered.

Ping-Che ChenMarch 19, 2013 8:04 PM

@Dirk Praet:

It's not even necessary to sandbox the module, as the decryption and verification process are both known. So it's only necessary to perform both, but not run the decrypted codes. However, I believe that for various reasons this should only be done for users who volunteered.

Another problem is that, although it's assumed that the process for finding a specific directory in PATH is to detect a certain installed software, it might also be just a "activation" key. For example, if you have a mole inside the organization you want to attack, you can easily tell him (or her) to add a specific string to PATH (which may not even be a directory at all). This way, you conceal the payload, and you control the timing of your attack with a simple command. PATH is also special in the way which anyone (without administrator privilege) can edit.

Peter KnoppersMarch 20, 2013 7:39 AM

Following up on the suggestion to employ virus scanners to look for machines on which the decryption and verification works.

It is possible that no such machine exists, yet. The Gauss malware might be triggered by releasing some update of a popular software product. This update would create the directory with the magic name that enables Gauss to unlock it's payload.

RHMarch 20, 2013 7:22 PM

@Zombie John: Security is always balanced against usability. If the Iranians really wanted to make sure no one infected their enrichment facilities, the sure fire way to do so is to buldoze the facilities, set fire to the remains, and guard the ashes. Ranks poorly in usability.

Its rare that an air gap can be held up perfectly, in this day and age. At some point data will need to be moved one way or the other, and that data may be too large to print and re-type back in by hand. A cost-benefit tradeoff is made, and the data is either transferred or it isn't.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..