Entries Tagged "espionage"

Page 12 of 20

The Failure of Anti-Virus Companies to Catch Military Malware

Mikko Hypponen of F-Secure attempts to explain why anti-virus companies didn’t catch Stuxnet, DuQu, and Flame:

When we went digging through our archive for related samples of malware, we were surprised to find that we already had samples of Flame, dating back to 2010 and 2011, that we were unaware we possessed. They had come through automated reporting mechanisms, but had never been flagged by the system as something we should examine closely. Researchers at other antivirus firms have found evidence that they received samples of the malware even earlier than this, indicating that the malware was older than 2010.

What this means is that all of us had missed detecting this malware for two years, or more. That’s a spectacular failure for our company, and for the antivirus industry in general.

It wasn’t the first time this has happened, either. Stuxnet went undetected for more than a year after it was unleashed in the wild, and was only discovered after an antivirus firm in Belarus was called in to look at machines in Iran that were having problems. When researchers dug back through their archives for anything similar to Stuxnet, they found that a zero-day exploit that was used in Stuxnet had been used before with another piece of malware, but had never been noticed at the time. A related malware called DuQu also went undetected by antivirus firms for over a year.

Stuxnet, Duqu and Flame are not normal, everyday malware, of course. All three of them were most likely developed by a Western intelligence agency as part of covert operations that weren’t meant to be discovered.

His conclusion is simply that the attackers—in this case, military intelligence agencies—are simply better than commercial-grade anti-virus programs.

The truth is, consumer-grade antivirus products can’t protect against targeted malware created by well-resourced nation-states with bulging budgets. They can protect you against run-of-the-mill malware: banking trojans, keystroke loggers and e-mail worms. But targeted attacks like these go to great lengths to avoid antivirus products on purpose. And the zero-day exploits used in these attacks are unknown to antivirus companies by definition. As far as we can tell, before releasing their malicious codes to attack victims, the attackers tested them against all of the relevant antivirus products on the market to make sure that the malware wouldn’t be detected. They have unlimited time to perfect their attacks. It’s not a fair war between the attackers and the defenders when the attackers have access to our weapons.

We really should have been able to do better. But we didn’t. We were out of our league, in our own game.

I don’t buy this. It isn’t just the military that tests its malware against commercial defense products; criminals do it, too. Virus and worm writers do it. Spam writers do it. This is the never-ending arms race between attacker and defender, and it’s been going on for decades. Probably the people who wrote Flame had a larger budget than a large-scale criminal organization, but their evasive techniques weren’t magically better. Note that F-Secure and others had samples of Flame; they just didn’t do anything about them.

I think the difference has more to do with the ways in which these military malware programs spread. That is, slowly and stealthily. It was never a priority to understand—and then write signatures to detect—the Flame samples because they were never considered a problem. Maybe they were classified as a one-off. Or as an anomaly. I don’t know, but it seems clear that conventional non-military malware writers who want to evade detection should adopt the propagation techniques of Flame, Stuxnet, and DuQu.

EDITED TO ADD (6/23): F-Secure responded. Unfortunately, it’s not a very substantive response. It’s a pity; I think there’s an interesting discussion to be had about why the anti-virus companies all missed Flame for so long.

Posted on June 19, 2012 at 7:11 AMView Comments

Flame

Flame seems to be another military-grade cyber-weapon, this one optimized for espionage. The worm is at least two years old, and is mainly confined to computers in the Middle East. (It does not replicate and spread automatically, which is certainly so that its controllers can target it better and evade detection longer.) And its espionage capabilities are pretty impressive. We’ll know more in the coming days and weeks as different groups start analyzing it and publishing their results.

EDITED TO ADD (6/11): Flame’s use of spoofed Microsoft security certificates. Flame’s use of a yet unknown MD5 chosen-prefix collision attack.

Microsoft has a detailed blog post on the attack. The attackers managed to to get a valid codesigning certificate using a signer which only accepts restricted client certificates.

EDITED TO ADD (6/12): MITM attack in the worm. There’s a connection to Stuxnet. A self-destruct command was apparently sent.

Posted on June 4, 2012 at 6:21 AMView Comments

Backdoor Found (Maybe) in Chinese-Made Military Silicon Chips

We all knew this was possible, but researchers have found the exploit in the wild:

Claims were made by the intelligence agencies around the world, from MI5, NSA and IARPA, that silicon chips could be infected. We developed breakthrough silicon chip scanning technology to investigate these claims. We chose an American military chip that is highly secure with sophisticated encryption standard, manufactured in China. Our aim was to perform advanced code breaking and to see if there were any unexpected features on the chip. We scanned the silicon chip in an affordable time and found a previously unknown backdoor inserted by the manufacturer. This backdoor has a key, which we were able to extract. If you use this key you can disable the chip or reprogram it at will, even if locked by the user with their own key. This particular chip is prevalent in many systems from weapons, nuclear power plants to public transport. In other words, this backdoor access could be turned into an advanced Stuxnet weapon to attack potentially millions of systems. The scale and range of possible attacks has huge implications for National Security and public infrastructure.

Here’s the draft paper:

Abstract. This paper is a short summary of the first real world detection of a backdoor in a military grade FPGA. Using an innovative patented technique we were able to detect and analyse in the first documented case of its kind, a backdoor inserted into the Actel/Microsemi ProASIC3 chips. The backdoor was found to exist on the silicon itself, it was not present in any firmware loaded onto the chip. Using Pipeline Emission Analysis (PEA), a technique pioneered by our sponsor, we were able to extract the secret key to activate the backdoor. This way an attacker can disable all the security on the chip, reprogram crypto and access keys, modify low-level silicon features, access unencrypted configuration bitstream or permanently damage the device. Clearly this means the device is wide open to intellectual property theft, fraud, re-programming as well as reverse engineering of the design which allows the introduction of a new backdoor or Trojan. Most concerning, it is not possible to patch the backdoor in chips already deployed, meaning those using this family of chips have to accept the fact it can be easily compromised or it will have to be physically replaced after a redesign of the silicon itself.

The chip in question was designed in the U.S. by a U.S. company, but manufactured in China. News stories. Comment threads.

One researcher maintains that this is not malicious:

Backdoors are a common problem in software. About 20% of home routers have a backdoor in them, and 50% of industrial control computers have a backdoor. The cause of these backdoors isn’t malicious, but a byproduct of software complexity. Systems need to be debugged before being shipped to customers. Therefore, the software contains debuggers. Often, programmers forget to disable the debugger backdoors before shipping. This problem is notoriously bad for all embedded operating systems (VxWorks, QNX, WinCE, etc.).

[…]

It could just be part of the original JTAG building-block. Actel didn’t design their own, but instead purchased the JTAG design and placed it on their chips. They are not aware of precisely all the functionality in that JTAG block, or how it might interact with the rest of the system.

But I’m betting that Microsemi/Actel know about the functionality, but thought of it as a debug feature, rather than a backdoor.

It’s remotely possible that the Chinese manufacturer added the functionality, but highly improbable. It’s prohibitively difficult to change a chip design to add functionality of this complexity. On the other hand, it’s easy for a manufacturer to flip bits. Consider that the functionality is part of the design, but that Actel intended to disable it by flipping a bit turning it off. A manufacturer could easily flip a bit and turn it back on again. In other words, it’s extraordinarily difficult to add complex new functionality, but they may get lucky and be able to make small tweaks to accomplish their goals.

EDITED TO ADD (5/29): Two more articles.

EDITED TO ADD (6/8): Three more articles.

EDITED TO ADD (6/10): A response from the chip manufacturer.

The researchers assertion is that with the discovery of a security key, a hacker can gain access to a privileged internal test facility typically reserved for initial factory testing and failure analysis. Microsemi verifies that the internal test facility is disabled for all shipped devices. The internal test mode can only be entered in a customer-programmed device when the customer supplies their passcode, thus preventing unauthorized access by Microsemi or anyone else. In addition, Microsemi’s customers who are concerned about the possibility of a hacker using DPA have the ability to program their FPGAs with its highest level of security settings. This security setting will disable the use of any type of passcode to gain access to all device configuration, including the internal test facility.

A response from the researchers.

In order to gain access to the backdoor and other features a special key is required. This key has very robust DPA protection, in fact, one of the best silicon-level protections we have ever encountered. With our breakthrough PEA technique we extracted the key in one day and we found that the key is the same in all ProASIC3, Igloo, Fusion and SmartFusion FPGAs. Customers have an option to program their chosen passcode to increase the security; however, Actel/Microsemi does not tell its customers that a special fuse must be programmed in order to get the backdoor protected with both the passcode and backdoor keys. At the same time, the passcode key can be extracted with our PEA technique which is public and covered in our patent so everyone can independently verify our claims. That means that given physical access to the device an attacker can extract all the embedded IP within hours.

There is an option for the highest level of security settings – Permanent Lock. However, if the AES reprogramming option is left it still exposes the device to IP stealing. If not, the Permanent Lock itself is vulnerable to fault attacks and can be disabled opening up the path to the backdoor access as before, but without the need for any passcode.

Posted on May 29, 2012 at 2:07 PMView Comments

Biometric Passports Make it Harder for Undercover CIA Officers

Last year, I wrote about how social media sites are making it harder than ever for undercover police officers. This story talks about how biometric passports are making it harder than ever for undercover CIA agents.

Busy spy crossroads such as Dubai, Jordan, India and many E.U. points of entry are employing iris scanners to link eyeballs irrevocably to a particular name. Likewise, the increasing use of biometric passports, which are embedded with microchips containing a person’s face, sex, fingerprints, date and place of birth, and other personal data, are increasingly replacing the old paper ones. For a clandestine field operative, flying under a false name could be a one-way ticket to a headquarters desk, since they’re irrevocably chained to whatever name and passport they used.

“If you go to one of those countries under an alias, you can’t go again under another name,” explains a career spook, who spoke on condition of anonymity because he remains an agency consultant. “So it’s a one-time thing—one and done. The biometric data on your passport, and maybe your iris, too, has been linked forever to whatever name was on your passport the first time. You can’t show up again under a different name with the same data.”

Posted on April 26, 2012 at 6:57 AMView Comments

Buying Exploits on the Grey Market

This article talks about legitimate companies buying zero-day exploits, including the fact that “an undisclosed U.S. government contractor recently paid $250,000 for an iOS exploit.”

The price goes up if the hack is exclusive, works on the latest version of the software, and is unknown to the developer of that particular software. Also, more popular software results in a higher payout. Sometimes, the money is paid in instalments, which keep coming as long as the hack does not get patched by the original software developer.

Yes, I know that vendors will pay bounties for exploits. And I’m sure there are a lot of government agencies around the world who want zero-day exploits for both espionage and cyber-weapons. But I just don’t see that much value in buying an exploit from random hackers around the world.

These things only have value until they’re patched, and a known exploit—even if it is just known by the seller—is much more likely to get patched. I can much more easily see a criminal organization deciding that the exploit has significant value before that happens. Government agencies are playing a much longer game.

And I would expect that most governments have their own hackers who are finding their own exploits. One, cheaper. And two, only known within that government.

Here’s another story, with a price list for different exploits. But I still don’t trust this story.

Posted on April 2, 2012 at 7:56 AMView Comments

Computer Security when Traveling to China

Interesting:

When Kenneth G. Lieberthal, a China expert at the Brookings Institution, travels to that country, he follows a routine that seems straight from a spy film.

He leaves his cellphone and laptop at home and instead brings “loaner” devices, which he erases before he leaves the United States and wipes clean the minute he returns. In China, he disables Bluetooth and Wi-Fi, never lets his phone out of his sight and, in meetings, not only turns off his phone but also removes the battery, for fear his microphone could be turned on remotely. He connects to the Internet only through an encrypted, password-protected channel, and copies and pastes his password from a USB thumb drive. He never types in a password directly, because, he said, “the Chinese are very good at installing key-logging software on your laptop.”

Posted on February 24, 2012 at 7:06 AMView Comments

Bad CIA Operational Security

I have no idea if this story about CIA spies in Lebanon is true, and it will almost certainly never be confirmed or denied:

But others inside the American intelligence community say sloppy “tradecraft”—the method of covert operations—by the CIA is also to blame for the disruption of the vital spy networks.

In Beirut, two Hezbollah double agents pretended to go to work for the CIA. Hezbollah then learned of the restaurant where multiple CIA officers were meeting with several agents, according to the four current and former officials briefed on the case. The CIA used the codeword “PIZZA” when discussing where to meet with the agents, according to U.S. officials. Two former officials describe the location as a Beirut Pizza Hut. A current US official denied that CIA officers met their agents at Pizza Hut.

Posted on November 30, 2011 at 6:57 AMView Comments

Fake Documents that Alarm if Opened

This sort of thing seems like a decent approach, but it has a lot of practical problems:

In the wake of Wikileaks, the Department of Defense has stepped up its game to stop leaked documents from making their way into the hands of undesirables—be they enemy forces or concerned citizens. A new piece of software has created a way to do this by generating realistic, fake documents that phone home when they’re accessed, serving the dual purpose of providing false intelligence and helping identify the culprit.

Details aside, this kind of thing falls into the general category of data tracking. It doesn’t even have to be fake documents; you could imagine some sort of macro embedded into Word or pdf documents that phones home when the document is opened. (I have no idea if you actually can do it with those formats, but the concept is plausible.) This allows the owner of a document to track when, and possibly by what computer, a document is opened.

But by far the biggest drawback from this tech is the possibility of false positives. If you seed a folder full of documents with a large number of fakes, how often do you think an authorized user will accidentally double click on the wrong file? And what if they act on the false information? Sure, this will prevent hackers from blindly trusting that every document on a server is correct, but we bet it won’t take much to look into the code of a document and spot the fake, either.

I’m less worried about false positives, and more concerned by how easy it is to get around this sort of thing. Detach your computer from the Internet, and the document no longer phones home. A fix is to combine the system with an encryption scheme that requires a remote key. Now the document has to phone home before it can be viewed. Of course, once someone is authorized to view the document, it would be easy to create an unprotected copy—screen captures, if nothing else—to forward along,

While potentially interesting, this sort of technology is not going to prevent large data leaks. But it’s good to see research.

Posted on November 7, 2011 at 6:26 AMView Comments

1 10 11 12 13 14 20

Sidebar photo of Bruce Schneier by Joe MacInnis.