FBI warning against counterfeited CISCO routers

Beginning May, FBI issued a warning about counterfeited CISCO routers. The US government, university, and companies were purchasing top notch routers from CISCO. In fact, their retailers were sourcing in China with counterfeited material. Thus, more than 3,500 gears were installed in critical places with counterfeited materials.

The problem is that nobody knows if there was no trapdoor installed in these routers. Backdoor in sensitive places would be very strong weapons for any attacker. Currently, we don’t know if is a part of warfare or just a traditional counterfeiting operation.

In order to limit the expenses, more and more governments and even armies use main street devices for their infrastructure. They do not anymore build their equipment. This means that they change their trust model. They are using the same trust assumption as we, common mortals, use: trust your supplier.

Of course in case of counterfeited material, this assumption is extremely weak. The risk is not only the presence of trapdoors, but simply the quality of the device or software itself. On critical equipment, the reliability may be lower than expected.

Nevertheless, is this assumption true for genuine equipment? This reminds me the accusation of NSA trapdoor in Microsoft cryptographic API. Researcher discovered the presence of key called NSA_key! (see cryptome.org). This ended up with some governments requiring to use exclusively Open Source in some parts of their IT infrastructure to avoid potential trapdoors.

To view the presentation of FBI, visit abovetopsecret.com

Ransoming virus (2)

The story continues.

Dving a little bit more in the available information. Gpcode is actually using RSA 1024. Kapersky labs have extracted the public keys. The virus uses two public keys depending on the version of the Operating System. The virus calls Microsoft cryptographic library.

Having the public key is useless. Kapersky labs is calling for the help of crypto community to help to crack the private key. In other words, they launch their own RSA-1024 challenge (See RSA number challenges that apply only to factorization). This is illusory. It would require too much power calculation (else it would have been decided that RSA 1024 is not anymore safe). And there are two keys to crack!!!

The only effective countermeasure against Gpcode is backup your data.

Thanks Alain for the link to the blog  :Wink:

Ransoming virus

Kapersky lab, the anti-virus editor, detected a variant of virus Gpcode. It encrypts some data files on the hard disk, renames them with extension ._CRYPT, and adds a file !_README_!.txt in the folder. Then, it displays a message announcing the encryption and giving a contact mail.

The virus claims to use RSA-1024. Thus, out of the possibility of brute force attack. Pirated person should contact the pirate, pay the ransom, and he will receive a decryption tool.

This type of attack is not new. Older virus used the same technique. More dangerously, attackers penetrated enterprise network and encrypted critical data. Later asking the ransom. This type of attack is not well advertised because enterprise look for discretion (bad reputation).

Should the victim of the virus pay?

  • First of all, normally if the data are carefully daily back-up, then this attack is just painful but not lethal. Would the attack notification appear several days or weeks after infection, it may be more problematic. There are many files that you do not access daily. Some people, or SOHO do their backup on rewritable storage overwriting previous backup.
  • What does guarantee that after payment, the pirate will provide the decryption tool? Would you trust your tormentor?

By teh way, does the virus really use RSA 1024? May be it just brags it and implements a lesser secure one. The advantage of using asymmetric crypto is that reverse engineering the virus will not leak the key (that may not be the case with symmetric crypto). It would be “funny” if the virus would just use a XOR with a long key, or even put random data (if the pirate does expect to extort money)

Lessons from Société Générale

In January 2008, the name of Jérome Kerviel became famous. This second-rate French trader generated 5 billions € of losses to his bank, Société Générale. Jeremy Epstein uses this story to illustrate 13 lessons for security. His lessons have many common points with our 10 laws. Some of them are more original. My preferred ones are:
Lesson 1: “Low tech attacks are easier” and according to me often neglected.
Lesson 7: “Don’t believe every thing you read”. This lesson is true even out of the field of security. Trusted information is a difficult quest.
Nonlesson 11: “Insider attacks (usually) have motivation”

It is perhaps in the motivation space that the failure of Société Générale finds its root. The latest report highlights that the controlling mechanism of the traders did not work properly. We may question if it was not on purpose. At end December 2007, Jerome Kerviel generated 1.5 billions € for his bank. For that, he violated many rules. What would be the behavior of a controller who detects such violation which produces such huge benefits? (Being a second rate trader, Kerviel was not authorized for such huge investments). Is it not tempting for the management to close its eyes? This is another illustration of our law 9: Quid custodient ipsos custodies?

The paper is in the latest issue of IEEE security & privacy, may-june 2008. A good reading.

And you, which is your favorite lesson?

Japan: iPod taxed?

Japanese government plans to tax iPods and other hard disk equipped portable players. The DVD recorders have already such a tax. The tax would probably be around 100yens (0.61€) A similar tentative failed in December 2005.

Many countries adopt similar strategy. Recently, French government planned to extend its copyright tax to iPhones (for about 7€). Obviously, each time, consumer electronics industry fight back.

This type of tax opens a gray area. For instance, is it legal then to rip DVD content for copy (even if it is not granted by studios)?

Discreet large scale attack on the net

In January 2008, tens of web servers have been hacked by the same exploit. These web servers were all using Apache. The infected web servers added a discreet call to to java script to the main page of the hosted sites. Once executed by the visiting browser, the java script checked vulnerabilities to load some malware onto the visiting hosts. The final goals of the installed malware was to load a binary to create botnets. The infected sites were very different ranging from hospitality promotion to sales of automotive replacement parts and even one security dedicated site.

The attack was extremely sophisticated. The attacker used ptrace to inject code in the memory of the Apache server. Thus, there was no modification of the files on the server! The name of the java script was changed randomly for each new visit. If the same IP address visited a second time the site, the java script was not appended to the downloaded page. The java script itself was obfuscated. The final binary that is loaded is extremely wise. It is highly visible with a reassuring name (regscan.exe). It modifies Internet Explorer to bypass potential firewalls.

The aim of this attack was clearly financial. Access to an infected computer for a botnet can be negotiated around 1$. These zombies are extremely useful to run spam or adwares. Interestingly, two weeks after the detection of the attacks, the attacker cleaned the servers he/she infected. The attacker was looking for discretion and not for the sunlights of the media.

This attack shows that hacking becomes an interesting business handled by extremely skilled attackers. We are far from the script kiddies or the geeks who were looking for fame. This story also highlights that you are always at risk, even if you do not visit “risky” sites. “Innocent” sites may infect your computer.

Law 4: Trust no one. Keep your computer up-to-date with all the patches. It is a tedious task, but mandatory. The java script was looking for known vulnerabilities that could have been patched.

For more information, read BUREAU M., Infection sur la toile, in MISC n°7, May/June 2008

Controlling fabless chips

More and more silicon manufacturers are becoming fabless. It means that they make their own design, but the actual manufacturing is done by another company. Unfortunately, they loose control on production. Thus, they face two types of piracy:

  1.   Manufacturers making more components than expected and selling them through illegal distribution channels.
  2. Pirating intellectual property through stealing some parts of the design.  Although not well-known from media, this piracy is serious.

At last USENIX workshop, Dr KOUSHANFAR from Rice University presented a system that may solve this problem. It is the result of more than 6 years of research.

The idea is rather simple. On a selected set of wires of the Integrated Circuit (IC), a basic circuitry is inserted. Thus, the path of an intercepted wire is driven by a bit. Depending on the value of the bit, the wire will go where it should to behave correctly, or go somewhere else generating a bogus chip. This set of bits form a long key, so called common key: CK. In addition every chip generates a public/private key pair using a hardware true random number generator. Then, using a typical secure link protocol, the IC designer can transmit for a given chip (identified by its public key) CK into the chip. The chip stores this key and can be then sold. Of course without the right value of CK, the chip does not work.

The paper discloses difficult attacks: either to reverse engineer the circuit to find the right value of key and create a new mask with the burnt key, either to get access to the private key of the IC designer. Another attack (not described) would be to cheat the true random number generator in order to have the same public/private key pair for batches of ICs.

Unfortunately, the paper did analyze the security only with piracy in mind. There is another important risk: denial of service. If during the life of an IC, an attacker may overwrite the CK of a good chip with a random value, then the attacker can stop any system using this type of chip.

The idea may also be used for controlling the distribution of secure chips. The secure chip should be fully functional only once personalized.

A concept to watch closely…

The corresponding paper is available at here