Malware Through A Charger

Malware Through A Charger

Who would’ve thought you can get cyber attacked this way…

Forbes is reporting that Georgia Tech researchers have discovered an exploit where malware could be introduced to your computer through the plug in AC power charger.

Based on their proof of concept, when you connect your computer and electrical plug, you could get more than an electrical charge to your Apple iOS computer–you could get hacked!

The malicious charger has been named Mactans and in the future could be put together by inserting a miniature computer board (e.g. a BeagleBoard) right into the base of a charger plug (larger than the one shown above).

The hack attack is enabled by the USB port which is used for charging and doubles as a data port so that the malicious code would be surreptitiously inserted into your computer.

So be careful what you plug into, because when you think you’re just powering up your battery, you may end up powering down your whole computer device.

This sort of reminds me of the shoe bomber that forever changed how we view seemingly innocuous shoes at the airport.

A shoe may not just be for walking, and a AC charger may not be just a power source anymore. 😉

(Source Photo: here with attribution to Lee Bennett)

IT Security, The Frankenstein Way

Frankenstein

Here’s a riddle: When is a computer virus not a dangerous piece of malware? Answer: when it is hidden as Frankenstein code.

The Economist(25 August 2012) describes how computer viruses are now being secretly passed into computers, by simply sending a blueprint for the virus rather than the harmful code itself into your computer–then the code is harvested from innocuous programs and assembled to form the virus itself.

Like the fictional character, Frankenstein, that is stitched together out of scavenged body parts, the semantic blueprint pulls together code from host programs to form the viruses.

This results is a polymorphic viruses, where based on the actual code being drawn from other programs, each virus ends up appearing a little different and can potentially mask itself–bypassing antivirus, firewall, and other security barriers.

Flipping this strategy around, in a sense, Bloomberg Businessweek (20 June 2012) reports on a new IT security product by Bromiumthat prevents software downloads from entering the entire computer, and instead sets aside a virtual compartment to contain the code and ensure it is not malicious, and if the code is deemed dangerous, the cordoned-off compartment will dissolve preventing damage to the overall system.

So while on the offensive side, Frankenstein viruses stitch together parts of code to make a dangerous whole–here on the defensive side, we separate out dangerous code from potentially infecting the whole computer.

Computer attacks are getting more sinister as they attempt to do an end-run around standardized security mechanisms, leading to continually evolving computer defenses to keep the Frankensteins out there, harmless, at bay.

(Source Photo: herewith attribution to Dougal McGuire)

>The Foreign Software Threat and Enterprise Architecture

>


Enterprise architecture is the developer and keeper of the organization’s systems inventory, and it is the champion for system interoperability, integration, standardization, and modernization. Of course, all this within the framework of a secure information infrastructure.

What happens though when the security of systems is threatened from the inside—that is through malicious code itself?

Imagine a terrorist sleeper cell embedded in our country that can be activated at any time to cause destruction and havoc. So too, hidden malicious software code can be embedded in applications developed overseas or even by homegrown adversaries. And this code can be launched or used as a back door to disable our vital military systems for communications, weapons, navigation, and so on.

Military Information Technology, April 2008, reports that “DoD combats risks of a ‘mole’ in software written in other nations.”

According to a March 2007 report by the Center for Strategic and International Studies (CSIS), “malicious code, cyber-attacks, and espionage [are cited] as top threats facing the DoD and defense industry today, resulting primarily from software developed overseas, and to a lesser extent, from the global use of commercial software.”

Further, “the CSIS report noted that the number of U.S. companies outsourcing software development overseas had grown 25% from 2003 to 2006.”

“In September [2007], the Defense Science Board Task Force…came to similar conclusions” about foreign software exploitation. It states: “’while COTS development environments are more porous to attack than those of DoD custom development environments,’ subversion of the latter is more like to achieve adversarial objectives.”

Custom code does not get the same scrutiny as commercial code (especially open source) and so it is more vulnerable to exploitation via back doors or malicious code written into the software.

Dan Geer, the chief scientist and vice president of Verdasys, a security software firm, states: “Instead of trying to put a mole in the CIA, they try to put a mole in software.”

While “the technology industry has made progress at finding which writing patterns leave software vulnerable to inadvertent bugs…we don’t have as good a handle on what malicious programmers introduce.”

So how can we architect safer software?

  1. Scan—conduct vulnerability scans of software to identify known vulnerabilities.
  2. Patch—when vulnerabilities are detected, patch them quickly.
  3. Inform—have developers disclose what tools they are using and how they developed the code.
  4. Test—embed security testing and analysis in all phases of the systems development life cycle.
  5. Measure—develop metrics for software assurance so it can be rated and improved on.

Of course, we also need to ensure that developers are security-cleared to work on the software being developed or customized and that we layer our defenses and create redundant systems so that we mitigate risk from any single particular entry point.