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?

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

Hacking the pacemaker

A team of University of Amherst (Massasuchets, USA) studied the security and privacy of commercial pacemaker. They discovered that it was weak. Current pacemakers and implantable cardiac defibrillators have some means to wirelessly communicate with external programmer device. The programmer device can collect patient data and adapt the therapy of the patient. Furthermore, it can generate fibrillations in test mode.

The communication is not protected. Of course, through eavesdropping, the team was able to reverse engineer the protocol. Then, they were able, through simple replay attacks to get patient data, change the therapies of the patient, and even to induce fibrillations. Another attack was a denial power attack where continuous communication diminished the lifetime of the implanted battery.

The hack itself is not extremely interesting (from the technical point of view). Hacking an unprotected wireless link is not a big deal. Is it really dangerous? In any case, any person who would be ready to play with an implanted pacemaker is necessarily murder minded (and then he has other means perhaps more efficient at his disposal)

The problem is more interesting when looking how to secure it. Due to the specific characteristics of the target, there are some important constraints:
– The power consumption is important. Replacing the battery require surgery! Cryptography requires power. Strong cryptography requires even more power. Furthermore, this type of devices is very sensitive to power denial attacks.
– The access to the pacemaker must be easy and fast for every practitioner. He must not have to look through many credentials, and secure database to find the right key in case of emergency.
– It must be reliable.
In this case, there is a tradeoff to find between security and practicability.

With the advent of the wireless interconnected area, this type of challenge will become extremely common. There will be more and more power supplied constrained devices to protect. Low power consumption cryptography: A new field of exploration?

Last issue of security newsletter is available

Security newsletter 9 is available. Our guest is Antoine JOUX (well known cryptographer). Together with the latest news, you will learn about about how to crack WEP in less than 6 minutes, that NOSTRADAMUS predicted next US president, and everything about Security of MPLS. The last article explains in detail the attack on disc encryption through freezing the memory. A great exploit from Princeton university.

The previous issues are available here.

6 May: Oups! Bad links. Thank you MK  :Wink:

Book: The Big Switch

Nicholas CARR was the author of Does IT Matter? In this first book, he questioned the future role of IT. He was forecasting the end of IT. In this new book, he continues his prediction with the advent of cloud computing.

He forecasts that computing power will become an utility as power supply. He makes the parallel with the transition to electricity power. Big companies such as Amazon (Elastic Compute Cloud EC2) or Google are offering grid computers to external companies. The interesting part of the book is the analysis of the impact it will have in conjunction with the advent of Web2.0 It has already allowed small companies to succeed without having huge IT infrastructure.

The book also highlights the current trends of Web2.0. Chapter 7: From the Many to the Few is extremely interesting. It describes how companies such as YouTube, or PlentyOfFish are using, for quite nothing, mobs of good willing “content creators”. Chapter 8: The Great Unbundling is about the transformation of content consumption. He predicts that the future of Internet will not be as bright as expected.
“But it’s clear that two of the hopes most dear to the Internet optimists-that the Web will create a more bountiful culture and that it will promote greater harmony and understanding-should be treated with skepticism. Cultural impoverishment and social fragmentation seem equally likely outcomes.”(extract)

The security threats highlighted in the book are the typical malware and privacy issues.

A book to read because it sheds a provocative light on the future of Internet.

Establishing end to end trust

Microsoft issued an extremely interesting white paper: Establishing end to end trust. It has been presented at RSA2008. The paper is worth reading. The main idea is that a trusted stack (encompassing hardware trust, OS trust, application trust, data trust and persona trust) and the ability to audit for accountability should make a more secure Internet.

It is interesting to note the extreme caution Microsoft takes on the topic of privacy and identity. Section IV is a fully dedicated cautionary note. Clearly, Microsoft fears that this initiative is considered as a Big Brother initiative. This is probably a sequel of the backlash on palladium.

I will focus on the notion of trusted stack. This is an addition to previous post on XBOX hack. The trusted stack is based on signature. According to the paper, there will be three categories.
“Even if code is signed, however, it will still fall into one of three buckets. There will be code that is signed by a known entity (e.g., Microsoft, Oracle, Adobe) that is trusted due to past experience, brand reputation or some other factor; there will be code that is signed but known to be malware (e.g., spyware, which can then be blocked); and there will be code signed by entities that are not known to the user.”
The paper clearly highlights the importance of the criteria to obtain the signature. If they are weak, then the trust is weak. The concept of signature relies on the fact that an authority, often called trusted third party, provides signature keys and associated certificates only to compliant and trusted principals. We expect the trusted third party do correctly its job. One of the strength of PC is the wealth of available shareware and freeware. There are thousands of small software publishers in the world. Thus, thte authority will never be possible to know if they are trust worthy. Will these publishers be allowed to sign?

To compensate, Microsoft proposes a reputation platform. Unfortunately, like in all reputation system, it has limitations. Reputation will increase only with the number of users recommending the software, i.e., the number of people taking the risk. Furthermore, many people will not check ( the same people that do not use an antivirus or do not update their software).

Furthermore, as explained in previous post, signature does not mean that the software is secure. Only peer auditing of the software before signing the application may give this assurance.

In other words, trusted stack as described will end up with the following situations:

  • Signed software that we trust because they are open source or from a publisher we trust.
  • Signed software that we do not know if we can trust.

It is still up to the user to decide if he takes the risk. In other words, we are not far from the existing situation. The only difference is that with a trusted stack based on TPM, application may trust and use secure elements of lower layers and interact with other trusted principals.

There are also many things to be said about audit. This is for another post.