Apr 14 2014

Snowcrash, Snowden, Snow on trust

This prezi presentation describes how the perceived trust on Internet has eroded over time, with a clear acceleration last year.   This is a personal (provocative) vision.  The companies cited are just (non-exhaustive) examples and are more representing a category (type of flagship).

Apr 07 2014

Social engineering and catastrophes

Recently, I visited a security company. They presented their new impressive Security Operational Centers. The security analysts had a continuous update of the sanity of their networks, the most prominent threats and the a wealth of other useful security indicators on three huge displays. In the bottom right corner, info channels, as well as selected tweets were continuously updated. They explained that it was key to be aware of breaking news as they may impact the threat environment.

They are right. A good social engineer may use the current breaking news and the morbid curiosity of users. With the advent of social networks and its vector to disseminate latest news, news have been common tools of attacks. For a few years, every major catastrophe has seen mushrooming spams and fake sites pretending to collect charities for the victims of the catastrophe. In 2014, it even started to become a vector for Advanced Persistent Threat (APT).

On 2014 March 8, Malaysian authorities announced that they had no news of the flight MH370 to Beijing. It took several weeks before having confirmation that this flight crashed in the sea. Meanwhile, this topic was used for spying political instances. Two days later, members of a government of the Asian Pacific region received a spear phished mail with an attachment titled “Malaysian Airlines MH370.doc”. Of course, this document was empty but contained a Poison Ivy malware]. It was sent by Admin@338″: a Chinese hacking group. The same attacking group sent on 2014 March 14, a different spear-phished email to a US think tank with an attachment titled “Malaysian Airlines MH370 5m Video.exe”. Once more, the attachment was a malware.

Many other malwares used the same catastrophe without being part of an APT, but rather generic random attacks. Some phishing sites, mimicking Facebook look, were used to collect data from spoiled users. The sites supposedly presented a video of the supposed discovery of the missed plan. Before viewing the video, the site proposed the users to share the video with their friends. After the site asked the users to answer some questions such as age. In other words, the phishing sites scammed the curious tricked users.

This trend exists since a few year and uses every widely covered catastrophe. Thus be aware, charity may be a threat vector.

Mar 20 2014

Target and FireEye

Beginning of December 2013, US retail Target suffered a huge leak of data: 40 million valid credit card information were sent to Russian servers. This leak will have serious financial impact for Target as there are already more than 90 lawsuits filed against Target.

Target is undergoing deep investigation to understand why this data breach occurred. Recently, an interesting fact popped up. On the 30th November, a sophisticated, commercial, anti-malware system FireEye detected the spreading of an unknown malware within Target’s IT system . It spotted the customized malware that was installing on the point of sales to collect the credit card number before sending them to three compromised Target servers. Target’s security experts based at Bangalore (India) reported it to the US Security Operation Center in Minneapolis. The alert level was the highest from FireEye. The center did not react to this notification. On 2nd December, a new notification was sent without generating any reaction.

The exfiltration of the stolen data started after the 2nd December. Thus, if the Security Operation Center would have reacted to this alert, although it may not have stopped the collection but at least it would have stopped the exfiltration to Russian servers.

As we do not have the details on the daily volume of alerts reported from Bangalore to the Security Operation Center, it is difficult to blame anybody. Nevertheless, this is a good lesson with the conclusions:

  • Law 10: Security is not a product but a process. You may have the best tools (and Fire Eye is an extremely sophisticated one. It mirrors the system and runs the input data within the mirror and analysis the reactions in order to detect malicious activities). If you do not manage the feedback and alerts of these tools, and take the proper decision, then these tools are useless. Unfortunately, the rate of false error is too high to let current tools take such decisions
  • Law 6: You are the weakest link; The Security Operation Center decided not to react. As FireEye was not yet fully deployed, we may suppose that the operators may not fully trust it. The human decision was wrong this time.

Mar 11 2014

The war between Digital Rights Locker starts

The Walt Disney Studios Announces Disney Movies AnywhereIn 2010, two initiatives around Digital Rights Locker (DRL) were bubbling.  On one hand, DECE was a large consortium of companies that created UltraViolet (UV).  On the other hand, Disney was designing its own solution KeyChest.

During these four last years, UV has started to have mild adoption and deployment.  The latest news is that UV is available in more European countries. For instance, in France, we start to see on TV advertisement the presence of the UV logo for new titles.  Nevertheless, UV did not make an awareness campaign (at least in France).  Most French customer have no clue of what UV is.

Meanwhile, Disney did not join UV, neither promote KeyChest.   Some people thought KeyChest to be dead.  Since February 2014, the situation has changed.   Disney launched a new service: Disney Movie Anywhere.  User can open a KeyChest account to access the DRL and also use her iTunes account (Remember that Disney and Apple have very close connection).  The service is currently only available in the US.  It is said that other content owners may join.

Of course, currently UV and KeyChest are not interoperable, meaning that users should have both a UV account and a KeyChest account to access a large catalog.  Is a new war of standard starting?   DIsney, with its interesting catalog (cartoons, movies, Marvel, Star Wars…) and Apple are serious opponents.

A little bit of auto-congratulation:my book describes in details both UV and KeyChest.   Not a bad decision.

Mar 03 2014

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.

Feb 24 2014

Bring Your Own Cloud

In 2013, the cloud security alliance released “The Notorious Nine” threats for cloud. A few months later, I have the feeling that the most important threat is missing: “Bring Your Own Cloud (BYOC)”.

BYOC is when an employee uses a cloud based service without the blessing of his company for business purpose. The employee clearly puts the company at risk. The employee may bypass all the security policies of the company, as well as the fences the company put to protect its IP or infrastructure.

BYOC is so easy to do and unfortunately it is awfully convenient.

  • You just need to enroll on a free SaaS service to launch it immediately. It is sometimes faster than asking the same service from the IT team. How many of your employees have opened an account at DropBox, Box, GitHub, or whatever other cloud sharing service. How many of your sensitive information are already widely in the cloud? The employee will most probably not check whether the system is secure. The default settings are not necessarily the ones that you would use. Of course, the employee will not have read the SLA.
  • You just need to use the company credit card to open an account at IaaS or PaaS providers. This is clearly faster than asking the IT team to install a bunch of servers in the DMZ. But how secure will they be?

The fast and free/cheap enrollment of cloud services make it extremely attractive for employees. And they do not make it maliciously. They will always have strong rationales for their action.

But, it can become easily a nightmare for the company when the things are going wrong. Especially, if the employee used his/her personal mail to register rather than the company’s email. In that case, the company will have hard time to handle these accounts.

What can we do? Cloud is inevitable, thus we must anticipate the movement. A few actions:

  • Provide a company blessed solution in the cloud for the type of services will need. This solution can be fine tuned to have the security requirements you expect. The account will be in the name of the company, thus manageable. Premium services offer often better security services such as authentication using your Active Directory, logging, metering…
  • Update your security policy to make it mandatory to use only the company blessed solution
  • Educate your employees so that they are aware of the risks of BYOC
  • Listen to their needs and offer an attractive list of company blessed services
  • Make it convenient to enroll the company blessed services.

 

Do you share this concern? What would you recommend?

Jan 14 2014

A graphical password solution: PixelPin

Graphical passwords are an alternative to usual textual passwords. They use an image as main support and image handling such as pointing position in the picture as entry mode. They can be convenient on tactile screens, more difficult for robots to mimic human behavior, and claimed to offer better memory resilience.

Since early 1990s, the literature has been rather extensive in the field. Technicolor published several papers in the field (search for Maetz and Eluard). But we rarely see a product that implements such a solution.

UK-based company, PixelPin offers such a solution. It is based on Bonder’s seminal patent (5559961). When registering, you select one image as a support and four points in the image in a given order. When answering the challenge, you have to select the four points in the initial order. To limit risks of shoulder surfing, the precision of positioning is rather fine (at least on a computer). After 5 attempts, the account is locked for 15 minutes. Reset sends a reset token via the email used to register.

To increase memory resilience, and to ease the positioning you should select a picture with clear identified salient points else you will be quickly locked out. Of course, using too obvious salient points reduces the space of “keys” to explore.

The main issue is the network effect needed for such solution. It will be efficient if the sites are common and often visited, else your memory will fade. Unfortunately, I did not find many sites using PixelPin. The startup was launched beginning last year.

Older posts «