Blockchain: a “supply chain” attack

A hacker, by the handle Right9ctrl, has injected malicious code that steals Bitcoin and Bitcoin Cash funds stored inside BitPay’s Copay wallet apps. The hacker injected the malicious code in the JavaScript library Event_Stream. This malicious code lays dormant until used inside the source code of Copay, a Bitcoin wallet. There, it steals much information such as the private key.

Right9ctrl inherited the access to the Event_Stream library because the initial author passed him/her the control. The initial author did not want to maintain anymore the open source library.

In other words, this is an example of a software supply chain attack. One element in the supply chain (here a library) has been compromised. Such an attack is not a surprise. Nevertheless, it raises a question about the security of open source components.

Many years ago, the motto was “Open source is more secure than proprietary solutions.” The primary rationale was that many eyes reviewed the code and we all know that code review is key for secure software. In the early days of open source, this motto may have been mostly true, under some specific trust models ( see https://eric-diehl.com/is-open-source-more-secure/, Chapter 12 of Securing Digital Video…). Is it still true in our days?

Currently, there are a plethora of available open source libraries. With the advent of many new programming languages, the number of libraries is exploding. Many projects have a few contributors, sometimes even only one individual. How many users of these libraries review the code before using it? I would guess very very few. Thus, the motto is becoming weaker. It is probably true for large, well-established projects, such as OpenSSL, but what for projects with one contributor? The success of the library is most probably not a valid indicator of trustfulness.

In this case, a warning signal would have been that the malicious code was heavily obfuscated. There is no legitimate reason why a JavaScript open source should be obfuscated. Open source is about transparency. Obfuscation is about obscurity.

Conclusion: be very careful when selecting an open source library, you may not necessarily trust it.

Conclusion2: if you are using a copy wallet, Sophos provides some advices.

 

Password complexity

Password complexity is one of the top conflictual topics of security. According to NIST, many companies may over-complicate their password policies.

In 2003, Bill BURR (NIST) established a set of guidelines for passwords asking for long passwords. Since then, many policies requested these complex, lengthy passwords mixing characters, digits and special characters. Recently, he confessed that he regretted to have written these guidelines. In June 2017, NIST published a more recent version of the NIST 800-63B document. These guidelines are user-friendly.

In a nutshell, if the user defines the password, then it should be at least eight characters long. If the service provider generates the password, it should be at least six characters long and can even be numerical. The service provider must use a NIST-approved random number generator. The chosen or generated password must be checked against a blacklist of compromised values. There are no other constraints on the selection.

On the user-friendly side, NIST recommends:

  • The password should not be requested to be changed unless there is evidence that it may be compromised.
  • The user should be allowed to use the “paste” command to favor the use of password managers
  • The user should be able to request the temporary display of the typed password.

Additional constraints are on the implementation of the verifier. The verifier shall not propose any hint. The verifier must implement a rate-limiting mechanism to thwart online brute-force attacks. The password shall be stored as a salted hash using an approved key derivation function such as PBDKDF2 or Balloon with enough iterations (at least 10,000 for PBKDF2).

Appendix A of the NIST document provides rationales for this simplification. For instance,

Many attacks associated with the use of passwords are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy, complex passwords as simple ones.

Or

Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.

A few cautionary notes; the addressed threat model is an online attack. It does not adequately cover offline attacks where the attacker gained access to the hashed password. The quality of the implementation of the salted hash mechanism is paramount for resisting offline attacks. Furthermore, it should be hoped that a theft of salted hash database should be identified and would trigger the immediate modification of all passwords, thus, mitigating the impact of the leak. NIST recommends using memorized secrets only for Assurance Level 1, i.e.,

AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. 

Higher assurance levels require multi-factor authentication methods. The guidelines explore them in depth. It may be the topic of a future post.

NIST is a reference in security. We may trust their judgment. As we will not get rid soon of the password login mechanism, we may perhaps revisit our password policy to make it user-friendlier and implement the proper background safeguard mechanisms.

I wish you a happy, secure new year.

Judgment under uncertainty

We often have to make decisions without having all the information we expected. We make this decision on the belief of perceived likelihood of events. Obviously, evaluating uncertain events is an incredibly difficult task. Unfortunately, it is mandatory for risk management or data analysis. This judgment is subjective although we may believe it is rationale.

In 1974, Amos Tversky and Daniel Kahneman published a paper “Judgment under uncertainty: heuristics and biases.” They explored the different biases that will taint our decision and that we are most probably not aware of.

For instance,

  • Insensitivity to sample sizes. The size of the sample impacts its representativeness
  • Misconception of chance; many people believe that the probability of dice sequence 111111 is far lower than the sequence 163125
  • Biases of imaginability;

The paper lists ten such biases. Being aware of them is worthwhile. The article remains me a lot of the book “Predictably irrational.”

Nice to read for security guys and data analysts.

Reference

Tversky, Amos, and Daniel Kahneman. “Judgment under Uncertainty: Heuristics and Biases.” In Utility, Probability, and Human Decision Making, edited by Dirk Wendt and Charles Vlek, 141–62. Theory and Decision Library 11. Springer Netherlands, 1975. http://www.cob.unt.edu/itds/faculty/evangelopoulos/busi6220/Kahneman1974_Science_JudgementUnderUncertainty.pdf

 

 

 

Law 2: Know the Assets to Protect

This is the second post of a series of ten posts. The first one analyzed Law 1: attackers will always find their way.

The primary goal of security is to protect. However, to protect what? “What are the assets to protect?” is the first question that every security analyst should answer before starting any design. Without a proper response, the resulting security mechanism may be inefficient. Unfortunately, answering it is tough.

The identification of the valuable assets will enable defining the ideal and most efficient security systems. The identification should specify the attributes of the asset that needs protection (confidentiality, integrity, anti-theft, availability, and so on). Assets are coming in many forms: human, physical goods, information goods, resources and intangible goods. The four first categories are often well treated. Unfortunately, it is not the case for the last one. Intangible goods are the intangible concepts that define the value of a company. They encompass notions such as brand, reputation, trust, fame, reliability, intellectual property and knowledge. For instance, a tarnished reputation may have serious business impacts.

Once the assets identified, the second step is to valuate them. All assets should not have the same value. For instance, all documents of your company are not to be classified as confidential. If you classify too many documents as confidential, users will become lax, and the mere notion of confidential will become diluted.

Once all the assets identified, it is time to make a threat analysis for the most valuable assets. It is not sufficient to know what to protect to design proper defense. For that purpose, it is key to identify the potential attackers. According to general Sun Tzu in his “Art of War”, it is paramount to know your opponents.

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”

The knowledge of the enemies and their abilities is paramount to any successful security system. This knowledge can be collected by surveying the Darknet continuously, hacking forums and attending security conferences (Black Hat, Defcon, CCC, …). There are many available classifications for attackers. For instance,

  • IBM proposed three categories: clever outsiders who are often brilliant people, knowledgeable insiders who have specialized education and Funded organizations that can recruit teams of complementary world-class experts.
  • The Merdan Group defines an interesting five-scale classification: Simple manipulation, Casual hacking, Sophisticated hacking, University challenge and Criminal enterprise.
  • At CloudSec 2015, the FBI disclosed a motivation driven gradation: Hacktivism, Insider, Espionage, Terrorism and Warfare

The practitioner selects the classification that fits best the problem to analyze.

Once the threat analysis is completed, then starts the design of the countermeasures. An important heuristic to keep in mind: “in most cases, the cost of protection should not exceed the potential loss.” Usually, defense is sufficient if the cost of a successful attack is equivalent to or higher than the potential gain for the attacker. Similarly, defense is adequate if its expense is equal to or greater than the possible loss in the case of a successful attack.

Remember: know what you must ultimately protect and against who.

BYOLC: Bring Your Own Loss of Control

In a recent post, I highlighted my belief that one of the most worrying new threats of the cloud was the Bring Your Own Cloud.   A recent study from LogMeIn and Edge Strategies confirms this risk by focusing on the use of cloud-based services.  They coined it as Bring Your Own App (BYOA)

Following is their infographics that summarizes the major outcomes.

’The

In a nutshell, the problem is more worrying than expected.   Currently, a huge amount of applications (> 85%), and thus data, are under the radar of the IT team!    One of the answers that we proposed is that IT should provide company blessed solutions.   I am a strong proponent of this solution.   This study seems to show that it is not sufficient: 64% bring their own apps when a similar solution is already in place.  I must confess that during the era before cloud, I was doing the same, for instance, using Firefox when IE was blessed, or my preferred software editor…

Even if you ban BYOD, BYOA will be here.   This unavoidable BYOA means that we are losing more and more control on sensitive data.  What is the proper answer: DLP (dubito ergo sum), more control of what is executing on the user’s computer (not compatible with BYOD)…

BYOD + BYOC + BYOA = BRYLC 

Unfortunately, cloud is here and we cannot escape it.   THus ranting is useless.  We have to find new solutions and methods to protect our assets.  What answer do you suggest?

 

Thanks to Gomor for the pointer

CataCrypt 2014

In the tsunami of the catastrophic HeartBleed bug, this new IEEE workshop will be interesting.   cataCRYPT stands for “catastrophic events related to cryptography and security with their possible solutions.”

The main point is: many cryptographic protocols are only based on the security of one cryptographic algorithm (e.g. RSA) and  we don’t know the exact RSA security (including Ron Rivest). What if somebody finds a  clever and fast factoring algorithm? Well, it is indeed an hypothesis but we know several  instances of possible progress. A new fast algorithm is a possible catastroph if not handled  properly. And there are other problems with hash functions, elliptic curves, aso. Think also about the recent Heartbleed bug (April 2014, see http://en.wikipedia.org/wiki/Heartbleed): the discovery was very late and we were close to a catastrophic situation.

So we are thinking about a regular workshop, the name is CATACRYPT, about these possible problems and their solutions. It includes problems with cryptographic algorithms, protocols, PKI, DRM, TLS-SSL, smart cards, RSA dongles, MIFARE, aso. Quantum computing, resilience and agility are also on the program.

The birth of cataCRYPT is not opportunistic.  His founder, Jean Jacques Quisquater, had launched the idea last year.  Its announcement following HeartBleed is a pure coincidence.

The paper submission deadline is 2 June 2014.   Hurry up…

The conference’s site is http://catacrypt.net/

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.