A new malware variant by the name Gpcode.ak has been raising eyebrows in the security community. Upon infecting a computer, the trojan will encrypt the user’s documents, leaving a text file which demands money in exchange for a decryption key.
There are no new ideas here: encryption malware has been around for the better part of a decade, Adam Young and Moti Yung wrote a book about cryptovirology in 2004, and even Gpcode itself has been around since 2005, albeit with a far more primitive approach to encryption that the current incarnation.
The latest instance gets the crypto mostly right: it creates a unique 128-bit RC4 (Arcfour) key on each machine and uses a random initialization vector for each file it targets. The IV is written to the beginning of the file, encrypted by the per-machine key, run through MD5, and the output constitutes the per-file key, used to encrypt each file with RC4. At the end, the main per-machine RC4 key is encrypted with a 1024-bit RSA public key which the malware carries within its payload. The malware author can then send a tailored, per-machine decryptor to folks who pay up.
If you keep backups, you can obviously treat this attack as a simple data loss scenario. And if you don’t have backups and badly need the files back, you have no option but to pay: when used correctly, cryptography works. In their encrypted form and without the RSA private key, the files are as good as garbage. Anti-virus companies have no technological defense against this, can’t make any, and are being appropriately forthcoming:
A security company on Friday asked for help cracking an encryption key central to an extortion scheme that demands money from users whose PCs have been infected by malware. … “Along with antivirus companies around the world, we’re faced with the task of cracking the RSA 1024-bit key,” said Aleks Gostev, a senior virus analyst [at Kaspersky Lab].
See? Completely reasonab… wait, what? Factor the key? Seriously?
Arjen Lenstra and Eric Verheul estimate that, in 2009, a machine that can factor a RSA-1024 key in a day would cost $250 million. With a massive cluster of regular computers, such a computation would take years. And it gets better: 2048-bit RSA keys are considered impractical to factor before the year 2030, while 3072-bit keys are likely to provide protection beyond then. Do you see where this is going?
Even if the present key is factored, it’ll take the malware author mere minutes to generate a stronger one, insert it into the malware payload, and send it on its merry way. And we won’t be able to factor that one.
In fact, focusing on the cryptography in the malware misses the point entirely. What the malware is exposing is the far simpler fact that our desktop security systems are fundamentally broken, as there is no reason that a piece of malware executing silently in the background should have access to a user’s files without interaction or approval. If file access was securely brokered, we wouldn’t have to care about the crypto.
We know how to build desktop systems that are both drastically more secure and more usable than the ones in use today. Prototypes like CapDesk and Polaris demonstrate this on mainstream systems, while my own Bitfrost does so on the OLPC laptops. You won’t see ransomware on the XO-1.
When it comes to Gpcode, factoring the RSA key is the dumbest possible course of action. I know it, the security community knows it, and Kaspersky Lab knows it. It’s a press gambit, and one that I found distasteful at first. But I’ve come around: it grabs headlines, and maybe a proliferation of headline-grabbing, panic-sowing, fear-inducing threats like cryptoviral ransomware is exactly what’s needed to overcome inertia from operating system vendors and finally move us towards a more secure desktop.
Much love, Kaspersky Lab. Let’s go factor some keys.


Anonymous Coward said,
June 15, 2008 @ 1:43 am
Eh, at least the virus does a better job than the Debian developers.
Marty K. said,
June 15, 2008 @ 1:50 am
Quite possibly the most sensible approach to the Gpcode problem.
The only other way to counteract these types of programs is to enact much stronger legislation in the places from which they originate, which is easier said than done. Perhaps Kaspersky Lab’s intentional publicity stunt will help in this respect?
Jenny Nelson said,
June 15, 2008 @ 7:06 am
Catch the guy, and execute him if he doesn’t release the key.
Alexander said,
June 15, 2008 @ 8:15 am
The Debian developers does a great job, what do they have to do with this?
Ivan Krstić said,
June 15, 2008 @ 8:22 am
Alexander — the Anonymous Coward is presumably making fun of the recent Debian OpenSSL mess.
Sam Kuper said,
June 15, 2008 @ 9:18 am
After reading this, I was surprised to see that Symantec describes W32/Gpcode.AK as being easy to contain and remove. Is that a different trojan to Gpcode.ak, or is Symantec underestimating the threat?
Ralph said,
June 15, 2008 @ 9:58 am
Of course you’re absolutely right about factoring being a dumb idea…
except that one could justify factoring a key which has already been imposed on some victims, while simultaneously taking entirely different and stronger measures to prevent this happening to anyone in the future.
The first and most logical method of rendering harmless future exploits of this type would be to make backups… something the victims should have been doing every day, ever hour or every minute, depending on how much currency they can afford to lose.
Ivan Krstić said,
June 15, 2008 @ 11:18 am
Sam — I think Symantec’s classification speaks to a different kind of containment and removal ease. When the malware finishes its encryption run, it’ll destroy itself leaving nothing but the ransom instructions behind, meaning it’s both self-contained and self-removed. This fails to capture the severity of losing all your documents, however.
Ralph — I considered the “we’ll help people already affected while we develop better countermeasures” argument, but the point is that there are no better countermeasures for anti-virus companies to develop. Unless they want to get into the full-disk backup business.
Ralph said,
June 15, 2008 @ 12:05 pm
Ivan — I do think the antivirus companies should get into the full-disk backup business — or whatever kind of backup is required at this point. That’s only sensible.
With respect to “there are no better countermeasures,” didn’t you just write that you are working on such a system for OLPC?
Personally I just cannot believe that an OS is impossible tod secure. I mean, suppose all the code runs from ROM, and it is (physically) impossible to execute anything from data space. I don’t see how that arrangement could fail.
Ivan Krstić said,
June 15, 2008 @ 12:10 pm
Ralph — there are no better countermeasures from the anti-virus software point of view. The improvement has to come from the people who make operating systems; Bitfrost, the OLPC security architecture I designed, is one such effort. You might find my AusCERT 2007 slide deck useful to clarify things.
martin langhoff said,
June 15, 2008 @ 4:26 pm
I agree that it is lame (but useful to some extent) to attempt to factor the key. Customers affected by the current run may be able to get their files out. In some cases a completely lost file, recovered in a few months, is better than no file.
However… if Kaspersky’s PR had said “ah, we will take a few years to write a new OS, based on safe paradigms; users who migrate to it will be safe from this threat”, now that would be elegant useless crystal tower talk. They aren’t a OS outfit, like MS, RH, Debian/Ubuntu, Novell or OLPC. And they can’t turn their backs on their customers like that.
Frankly, I am not sure if there is something practical that can be done in the current situation to help people _now_. Those users are in the sh*t, and will continue to be in there for a while — yes, hopefully the industry will move faster towards a better paradigm… but however fast it happens, it won’t be fast enough :-/
Ivan Krstić said,
June 15, 2008 @ 4:31 pm
Martin — clearly it’s not the place of an anti-virus company to claim they’ll develop a better OS. But their PR is just disingenuous, and I fault them for it — for not saying “Look, we got lucky this time because the key length is such that we can conceivably factor it, but next time, we won’t get lucky. And we don’t have a solution to that problem. The OS vendors need to start thinking very hard about this, because the current defenses just won’t cut it.”
Ralph said,
June 15, 2008 @ 4:41 pm
Ivan, I read your slides. Very good!
I really don’t think security has to be quite so difficult as it seems right now. The problem, as I see it, is not about figuring out what to lock and how to lock it. It’s about figuring out where to install a few carefully-placed doors into otherwise solid walls.
I used to write a lot of code destined for ROM. I believe ROM code can be made intrinsically safe against any attacker who does not have physical access to our hardware. (One exception is for content-free denial of service attacks, which cannot be prevented by any locally-deployed method.)
Of course no system can ever be completely secure. As users, we will always be able to act carelessly and take imprudent risks. Nevertheless, we can do better than to leave all our money and possessions out on the front porch every night, with fireflies assigned to guard them — which is essentially what we’re doing now.
martin langhoff said,
June 15, 2008 @ 6:46 pm
And we hope they don’t, because then we are out of a job ;-)
Mike Hearn said,
June 23, 2008 @ 11:55 am
How much research has been done into retrofitting BitFrost like security models onto Windows? I know that CoreForce has done a decent job of bolting a kind of MAC security onto it, but what about a more complete solution?
Ivan Krstić said,
June 26, 2008 @ 11:07 am
Mike — I’ve talked to some of the top Windows security people about it, although not at great length. The consensus seemed to be that large parts could be ported with fairly low compatibility impact.
An RSS feed for comments on this post is available.
Leave a Comment