Apple’s security vulnerability

On February 21, Apple announced that all its most recent versions of operating systems (indeed since 2012), had a critical vulnerability in the SSL implementation. The vulnerability was due to a coding bug in the SSL certificate verification routine. Following is the problematic piece of software.

static OSStatus

SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,uint8_t *signature, UInt16 signatureLen)

{

OSStatus err;

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)

goto fail;

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)

goto fail;

goto fail;

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)

goto fail;

fail:

SSLFreeBuffer(&signedHashes);

SSLFreeBuffer(&hashCtx);

return err;

}

The highlighted “goto fail” should not be in the source code. It is equivalent to “if conditions then goto fail else goto fail”.  In all cases, it will goto fail!  It bypasses all subsequent tests of the SSL certificate. Thus, an attacker could easily use a forged certificate that would be accepted as valid. She could mount a man in the middle attack.

This code is part of Apple public source code. This is due to non-adequate programming practices. Usually, we accept at least two things in software coding:

  1. Unitary tests; they should have covered all the branches of the if conditions and should have detected this error.
  2. Non-regression test; if the error was introduced later (as SSL is available for a long time), they should have spotted it.

These practices seem not be in place. This is a major issue for a code that handles security. Security requires the best coding practice. Bugs can easily turn into security vulnerabilities.

 

In the fuzz, I have even seen conspiracy theory that the bug was introduced by NSA. I would expect NSA to use stealthier techniques than such obvious back door. furthermore, if I am a bad guy who wants to introduce a backdoor, I will design one that I am the only one to be able to exploit. This one is available for every body.

Lesson: Secure software requires best software practice. And a derivative of law 6: Programmer is the weakest link.

Ten laws: a little help?

I am writing my second book.  It will explore the ten laws of security.  It will be published by Springer in 2015.   The book will describe many examples of real situations illustrating the laws.  Some examples will comply with the law, others will violate the laws.

I have already many examples. Nevertheless, the larger the stock of potential examples, the better.   Thus, I am looking for examples.   If you have examples illustrating one law, and are ready to share it with me, you are welcome.  Would it be a new unknown example that I would use in the book, then, of course, you will be cited in the book.   Winking smile

I am also looking for examples:

  1. Not related to IT
  2. Historical examples

A votre bon coeur…

Has NSA broken the crypto?

With the continuous flow of revelations by Snowden, there is not one day without somebody asking me if crypto is dead.  Indeed, if you read some simplifying headlines, it looks like the Internet is completely unsecure.

 

Last Friday, Bruce Schneier published an excellent paper in the guardian : “NSA surveillance: a guide to staying secure.”  For two weeks, he has analyzed documents provided by Snowden.   From this analysis, he drives some conclusions and provides some recommendations.  In view of the security profile of Bruce, we may trust the outcome.  I recommend the readers to read the article.

My personal highlights from this article.

  • The documents did not present any outstanding mathematical breakthrough.   Thus, algorithms such as AES are still secure.
  • To “crack” encrypted communications, NSA uses the same tools than hackers but at a level of sophistication far higher.   They have a lot of money.  The tricks used:
    • Look for used weak algorithms
    • Look for weak passwords with dictionary attacks
    • Powerful brute force attacks
  • The two most important means are:
    • Implementing back doors and weakening commercial implementations (poor random generator, poor factors in Elliptic Curve Cryptosystems (ECC), leaking keys…).   The same is true for hardware.

As was revealed today, the NSA also works with security product vendors to ensure that commercial encryption products are broken in secret ways that only it knows about.

    • Compromising the computer that will encrypt or decrypt.  If you have access to the data before it is secured, then you do not care about the strength of the encryption.

These are hacker tools designed by hackers with an essentially unlimited budget. What I took away from reading the Snowden documents was that if the NSA wants in to your computer, it’s in. Period.

His recommendations are common sense.   The most interesting one is to avoid using ECC as NSA seems to influence the choice of weak curves and constants in the curve.

 

His final statement

Trust the math.

is OK, but I would add “Do not trust the implementation.”  Always remember law 4: Trust No One.

Top threats for cloud computing

The Cloud Security Alliance released a document listing the nine top threats of cloud computing: “The Notorious Nine”.  The top nine threats are:

  1. Data breaches; an attacker may access your data
  2. Data loss; the loss may result either from an attack, a technical problem or a catastrophe.   The document wisely highlights the issue raised by encryption (to protect against threat 1)
  3. Account hijacking
  4. Insecure APIs;  this one is extremely important, especially for system designers.  It is not necessarily unique to the cloud, but it is clearly exacerbated with a cloud infrastructure.
  5. Denial of service
  6. Malicious insiders
  7. Abuse of cloud services;  using the cloud for nefarious actions such as password cracking. Well, every coin has two sides.
  8. Insufficient due diligence; jumping in the cloud wagon without enough preparation may be an issue.  This is not proper to the cloud. It is true for any new paradigm.  BYOD (Bring your own device) is a perfect illustration of such problem.
  9. Shared technology vulnerability; As you share components, pieces of software with not necessarily enough isolation, a single vulnerability may impact many players.

Each threat is described and illustrated by a real world example of an attack.  A risk matrix allows to compare them.

This list has been established by conducting a survey of industry experts.  Unfortunately, the document does not give details about the number of surveyed experts, their locations, and their qualifications.

Good document to read.

Ten security concerns on cloud

Cloud computing becomes the hot buzz topic. We will all migrate to cloud computing, sooner or later. Although it is extremely attractive from the financial point of view, it raises extremely serious concerns about security.

Global knowledge has issues a white paper that provides a kind of check list for selecting your provider, or to decide if it is wise to switch to the cloud.

  1. Where’s the data?
  2. Who has access?
  3. What are your regulatory requirements?
  4. Do you have the right to audit?
  5. What type of training does the provider offer their employees?
  6. What type of data classification system does the provider use?
  7. What are the service level agreement (SLA) terms?
  8. What is the long-term viability of the provider?
  9. What happens if there is a security breach?
  10. What is the disaster recovery/business continuity plan (DR/BCP)?

By the way, many of these questions are equally valid with an internal/outsourced IT traditional service. For instance, 1 or 2. have you asked yourself these questions for your current system. What is the answer for 5 in your company?

The document is here.

Ten ways the IT department enables cybercrime

This is the provocative title of latest Kapersky lab’s white paper. This document lists some of the usual mistakes that are encountered in the today protection. It is mainly focused on the mandatory adaptation due to mobile devices. The paper is not mind-breaking. Nevertheless, it gives some true statements, such as

  • Enabler #1: assuming the data is in the data center.
    Of course today, data is redundantly stored in the laptops and even smart phones. They need protection
  • Enabler #3: Treating laptops and mobile devices as company assets that are never used for personal use…
    Awfully true.
  • Enabler #5: Adoption of Social Media without protection
    Social media and Web 2.0 are here to stay. furthermore, they are becoming part of the business tools. They create a new kind of risks.
  • Enabler #10: Assuming everything is OK.
    Remember our law 1: Attackers will always find their way.

As usual in this type of document, the first items are extremely relevant, whereas the last ones are less. it is always difficult to end up with 10 valid items. Nevertheless, 10 is the golden number in communication.

As a good citizen, I put the link to Kapersky lab. You’ll need to register to download the white paper. Nevertheless, you may easily find pdf versions on the Net without having to register :)

Ten ways hackers breach security

I have decided to launch a new category: “the ten …” In this category, I will put the classifications and lists that we find around the net about security, such as the top 10 vulnerabilities in software.

Of course, the first one of the category is the Technicolor Ten Security Laws of my team.

I found this Ten ways hackers breach security as a white paper from global knowledge. The paper is clearly not revolutionary. Nevertheless, it is another ten laws…

Here are the ten ways:

  • 1- Stealing Passwords
  • 2- Trojan Horses
  • 3- Exploiting Defaults (a cruel one but awfully true. How many people do change the default password of their admin in the gateway?)
  • 4- Man In The Middle Attacks (more sophisticated, but at the heart of some recent wireless attacks)
  • 5- Wireless Attacks
  • 6- Doing their homework; what was meant here was to collect information about the target. This of course is one of the first stages for social engineering.
  • 7- Monitor Vulnerability Research (!!!)
  • 8- Being patient and Persistent
  • 9- Confidence Games; this is where they present social engineering
  • 10- Already Being on the Inside; the usual insider

Nice introduction paper, but not interesting if you’re already security aware.