Contactless, Cardless or Cashless? (part 1)

Modern electronic cards are called smart cards. This name comes from the fact that these cards contain a tamper-resistent (althougth not tamper-proof) chip that is capable of performing computational operations (like signing or encrypting a block of data) and permanently storing information. The most common example of such cards are, the credit or debit cards that we use to interact with terminals like post of sales (POS) and ATM machines.

Most smart cards follow the EMV (Europay MasterCard Visa, http://tinyurl.com/3k8puz ) standard (also know as chip and pin on English speaking countries) which, currently, is being adopted by most of the countries( http://tinyurl.com/oz9pup9 ). This, was created to reduce the number of frauds that occurred when using the magnetic strip by, authenticating both the card (via a signed certificate stored on the chip) and its holder (via PIN request).

Another goal of the EMV standard is to allow multiple application to coexist on the same card. For example, we may have a card that works like a debit card or a Visa card depending on different factors (for example: country or POS type).

The EMV defines a protocol  that can be splitted into three different phases (http://tinyurl.com/p75wus7):

1. Card authentication: Ensures that the card information was not tampered with and which bank issued the card.

2. Cardholder verification: Executed via PIN insertion by the card holder, and assures to the terminal that the inserted PIN matches the one stored on the card.

3. Transaction authorization: Ensures that the transaction that is being performed is properly authorized by the bank that issued the card.

During the card authentication phase, different types of authentication can be performed. 

In the Static Data Authentication (SDA), the card presents a certificate signed by the issuing bank and its own information that is signed by the issuing bank private key.

Static Data Authentication (SDA)

On Dynamic Data Authentication (DDA), the card has a private key and is able to perform cryptographic operations like signing a challenge issued by the terminal. This signature is then verified by the terminal using the cards public key certificate that is signed by the issuing bank.

Dynamic Data Authentication (DDA)

If the terminal is able to confirm that the data sent to it is correct, it advances to next phase, the cardholder verification.

The cardholder verification phase is were the owner of the card has to provide proof of ownership by authenticating both to the card and the terminal. The type of authentication mechanism is negotiated between the terminal and the card using an ordered list called cardholder verification method (CVM). According to a study performed by researchers at Cambridge (http://tinyurl.com/p75wus7), this list, normally contains three options:

1. PIN verification: Where the cardholder is required to enter a PIN.

2. Signature verification: Where the cardholder is required to produce a signature that is visually (manually) confirmed by the comparing the provided signature with the one on the card.

3. None: Where no type of authentication is required.

If, for some reason, a terminal is not capable of one of these methods, it may be skipped. For example, in car tolls where we have a person requiring the toll fee, we aren’t required to enter a PIN or perform a signature.

In the PIN verification method, there are two different ways to confirm that the PIN is correct, online and offline. On offline verification, the PIN is sent to the card (encrypted or in clear text) that, compares it to the one that it has stored, updates the number of tries left and, replies according to the validity of the PIN. The reply also includes the number of tries left.

Simplified Offline PIN Verification

In online verification, the PIN is encrypted and sent through a network to the card issuer entity to be verified. Upon receiving it, the issuer will compare it to the one that it has stored and reply accordingly. When the pin is received on the terminal, the number of tries left is updated and a reply is returned to the cardholder. An example of such operations are the ones that are performed at ATM machines, where all PIN verifications are performed online.

Simplified Online PIN Verification

The transaction authorization initiates immediately after the cardholder is verified. During this phase, the terminal is assured that the requested transaction is authorized by the card issuer.

This phase starts with the terminal requesting to the card to generate a cryptographic message (Generate AC) of the transaction details (provided by the terminal). If the card accepts the transaction, it returns a cryptographic message (ARQC) to be sent to the card issuer, otherwise, the transaction is aborted. The returned message contains the description of the transactions plus a message authentication code (MAC) generated using a shared key between the card and the issuer.

When the issuer receives the message, it performs several operations like, verifying that the card is not stolen or there are funds on the account. If the issuing bank accepts the transaction, it will reply with a new cryptographic message (ARC) indicating that the transaction can be executed. This message also contais a MAC (ARPC) which, is generated using the initial message and an authorization response code.

The terminal, upon receiving the issuer message, forwards it to the card. The card will then validate the MAC and, if it checks out, updates its state indicating that the transaction was accepted.

The terminal will then request (Generate AC command) to the card to generate a transaction certificate that indicates that the transaction has been approved (TC). The certificate is then stored by the terminal and a copy is sent to the issuing entity. At this pois the transaction is completed and a receipt is printed.

An option for offline transaction authorization also exists. In this mode, the decision to approve or not a transaction falls on the card and the terminal. This decision is based on proprietary risk evaluation algorithm.

Simplified Online Transaction authorization

At a later time, the terminal sends a batch containing all the approved transactions to the acquiring bank (the entity that provides the terminal) to be processed (http://tinyurl.com/o3uh9lu). This process, depending on the amount of transactions, may occur once or more times a day.

Although there is a great visible effort to prevent attacks, several have been documented. For example, by exploring the fact that static data authentication always provides the same data and that is possible to perform offline PIN verifications, it is possible to clone a SDA smart card. This attack is know as the Yes card.

In the Yes card attack, the information provided by the SDA is copied into a new card. This new card will reply with YES to any PIN that is given. Although this attack is easily avoided by either performing online PIN validation or switching to a DDA card, due to economic reason (cheaper card, cheaper to perform offline PIN validation), there are card issuers and retailers that use these methods, thus are vulnerable to the attack.

Since most cards still come with a functional magnetic strip, it is possible to force the transaction to fallback to this method. Once on this “mode”, it is possible to both copy the information that is switched between the card and the terminal and the PIN.

Researchers at Cambridge University describe an attack where they perform a man-in-the-middle attack by exploiting a flaw in the EMV protocol (http://tinyurl.com/p75wus7). The discovered flaw allows for a stolen card to be used even without knowing the original PIN in offline PIN verification terminals. The attack is made possible due to the fact that the protocol does not authenticate the PIN validation correctly. So, it becomes possible to trick the card into thinking that the cardholder verification method was “None” or “Signature” while fooling the terminal into thinking that the correct PIN was inserted.

EMV protocol attack steps

As it is possible to see, these attacks at some point have to authenticate the cardholder in some manner. So, what is our degree of trust when we use cards that do not require the cardholder to authenticate?

In part2, we will explain the contactless payment systems and explore their many wonderful possibilities.

Read More

The year that was

Over the past year there has been a great focus on information and computer security and, as such, a great deal of new vulnerabilities have been found. In fact, finding security vulnerabilities has become so important, that companies like Google, Facebook, Microsoft and others have created programs that offer rewards to anyone who finds security vulnerabilities on their software (http://tinyurl.com/mq2meu6 , http://tinyurl.com/p95cpth ).

New vulnerabilities by year (1988 - 2014)

When a new vulnerability is found, it is reported under a common vulnerability exposure (CVE) tracking number to the NVD (http://nvd.nist.gov). Once reported, it will be analysed and receive a CVSS score (http://tinyurl.com/qzesna3). These scores, varie from 0.0 (low) to 10.0 (high) depending on factors like exploytability and impact.

During this past year, three critical vulnerabilities were found. Each one with a different attack vector but, all capable of compromising the security of systems exposed to the internet.

Heartbleed (CVE-2014-0160)

In April, a bug was found on the most widely used library to secure communications between peers on a network, the OpenSSL library (https://www.openssl.org/). Due to its origin, it has become known has the Heartbleed bug (http://heartbleed.com).

By exploiting this bug, an attacker is able to read arbitrary chunks of memory from the process on the server that is executing the OpenSSL library. By doing this, an attacker can obtain the private and secondary keys used to encrypt the traffic between the peers. With this information, it is then possible decrypt the traffic. Since this is a bug on a feature of OpenSSL, it leaves no trace of being exploited.

Its origin resides on a the implementation of the function used to keep the channel between the peers open, the heartbeat function. This function allows the peers to send at most 64KB (65536bytes) of information to the other peer. The information is then reflected back in order to access if the other peer is still there.

Heartbeat normal operation

The bug resides in the fact that this message contains a length field that is not compared with the actual message size to check if they match. Since the length is not checked, it is possible to send a very small message (ex: 1byte) but state in the length field that the message is of size 64KB. When the the message is reflected back, the attacker will receive the original message plus 65535bytes (64KB – 1byte) of random memory from the server. He can then execute this attack multiple times until he has gathered enough memory to get the desired content.

Heartbleed attack

OpenSSL is used by the most popular webservers on the Internet, Apache and nginx. These, combined, represent arround 66% (http://tinyurl.com/l4kvsjy) of the webservers. By this number, it is possible to grasp how serious this bug really was.

Currently, new releases of OpenSSL have been made available that correct this problem.

Shellshock (CVE-2014-6271)

In September, a 25 year old bug on the GNU Bourne-again shell (bash) was found. The bash is the most popular command line and, is present on all Linux and OS X operating systems. By exployting this bug, an attacker may execute arbitrary code on a server using specially crafted requests.

The bug resides on the way that the bash handles a special type of variables called environment variables (http://tinyurl.com/mtpe5m5). When the bash evaluates these vairables, if it is set with a function (small program) that starts with a special sequence of characters ( “() { :;};” ), it will not stop when the function ends but, in fact, will continue to evaluate the variable until all its content is parsed. This behaviour causes the execution of the code after the function ends which, in some cases, may be controlled by an attacker to, for example gain an iligit access to the server.

Following, we have an example on how to test if a bash is vulnerable to this bug.

Shellshock bug test example

In the above example, an environment variable x is crated with the value ‘() { :;}; echo vulnerable’, after, a new bash get’s called and executed (bash –c “echo this is a test”). Once it starts to execute, it parses the content of the environment variables defined in the system, which includes x, that contains the attack. So, if a vulnerable bash is being executed, the output would be the result of command echo “vulnerable” (the malicious code) followed by “this is a test”.

Although there are many ways to explore this vulnerability, the most common is by using an HTTP request (generated by the web browser and other similar tools). During a normal, non-malicious requests, a user sends an HTTP request to a webserver and expects a reply that contains some type of content.

Each HTTP request is composed of multiple fields that are read and interpreted by the webserver. To process these fields, the webserver will most likely call other small programs. To pass the fields to these programs, it will store them on environment variables.

HTTP request example

Since the HTTP requests are generated on the user side, he can craft special requests to execute arbitrary code on the webserver. On the following example, the User-Agent field has been replaced by content that can cause the server to try and contact another server (evilserver.com).

Malicious HTTP request

By broadcasting this message to a network, an attacker would be able to identify the webservers that are vulnerable to the Shellshcok bug.

Malicious HTTP effect

Due to simplicity and wide spread utilization of the bash on servers, security experts consider that this bug is even more dangerous than Heartbleed (http://tinyurl.com/o57dj8e).

Following the discovery of the shellshock bug, several other simillar bugs have been found (http://tinyurl.com/nngb368). In order to fix them, vendors have released patches that prevent their exploitation, so, if you haven’t updated your bash in since September, you should!

Poodle (CVE-2014-3566)

Less than a month after shellshock, researchers at Google release a paper called “This POODLE Bites: Exploiting The SSL 3.0 Fallback” (http://tinyurl.com/p9bxcdk). In it, they describe a flaw on SSLv3 protocol (in cipher-block-chain mode) and how to exploit it.

This flaw is know as POODLE, which stands for Padding Oracle On Downgraded Legacy Encryption and, by exploring it, an attacker will be able to obtain a session cookie of another user, and thus, impersonate the user to a service.

Since the discovered flaw resides on the protocol itself and not on the implemetations or the ciphers that are used, it actually invalidates its use.

Altough most secure communications use TLS (sucessor of SSL), many web servers and web browsers will downgrade to SSLv3 (or older) if they detect problems in the negotiation of the TLS session. This beaviour allows an attacker (assuming that he is able to perform man-in-the-middle attack) to interfere with the connection between both and, force them to downgrade to SSLv3. Once this is accomplished, he will then be able to decrypt the traffic between both by executing the POODLE attack.

SSLv3 Message format  1

SSLv3 in CBC (cipher-block-chain) starts by adding a message autentication code (MAC for short) in order for the receiver to check for the integrity (i.e if the content was modified or otherwise tampered with). Next, it has to split the message into 8 or 16 byte blocks (depending if the cipher is AES or DES) to be encrypted. However, since not all messages have a size that is multiple of these values, padding is added to the end of the message. Because the protocol does not specify the content of the padding, a set of random bytes is added as a pad. In order to know the size of the padding, one last byte that indicates its size is also added.

After being padded, the message is splited into blocks. Each block of clear text is then encrypted seperatly using a secret key and the previous block (an initialization vector is used to encrypt the first block). The process ends when the last block is encrypted.

CBC Encryption

Decrypting a message follows the reverse process. It starts by decrypting the last block using the previous block and the secret key. Then each encrypted block is used to decrypt the next block. Once the final block is decrypted, the last byte of the pad is read (size of the padding), the padding is striped of the message and the integrity of the message is verified. If for some reason the verification of the integrity fails, the message is rejected and the connection is closed.

CBC Decryption

Note that the padding is not verified in this process, and that if a message is rejected, the channel used to communicate is closed. The POODLE attack is based on these two facts.

To execute the POODLE attack, an attacker has to have the ability to perform a MITM (man-in-the-middle) attack and alter the traffic on the “wire”. Once the attacker is able to this, he will replace the padding block with another block (for example, the cookie block) and observe the response from the server. Since the padding itself is not checked, if the server accepts the message, he will have decrypted the last byte of message (he knows the size of the padding). He will then alter the message and repeat the process for the next byte and so on until the block is decrypted (http://tinyurl.com/kju8l2m).

The probability that a server will accept a modified message and decrypting one byte of information from the block is 1/256. Meaning that for a block of n bytes, we have at most 256*n to decrypt the block. This number may seem big, but with the current internet connection speeds, it is quite small.

SSLv3 is a protocol with 15 years that is still used for legacy reasons. Due to dificulty of performing this attack, the POODLE has a score of 4.6 in the CVSS, which rates it has a Medium risk vulnerability. However, this attack actually invalidates the use of the SSLv3 protocol and since the flaw resides on the protocol, the only solution is to disable to possibility to downgrade to it.

During the first ten months of 2014, three vulnerabilities with a great impact have been found. With little more than one month left until the end of the year, do you think that a new major vulnerability will be found? And what about 2015 and beyond? Are your systems and teams prepared to deal with this new reality?

Read More

Cryptocurrency, the coins of the future?

In 2009 an author going by the pseudonym of Satoshi Nakamoto published a paper called Bitcoin: A Peer-to-Peer Electronic Cash System (http://tinyurl.com/kkxbyss) that describes a decentralized electronic cash system based in cryptography that does not depended on financial institutions to validate transactions or to generate the cash. Since the system depends on a distributed network, it is very difficult to establish a relationship between the digital cash and its owner.  This paper has started the era of Cryptocurrency.

Although the Bitcoin is the most famous (and valuable) of cryptocurrencies, there are well over five hundred different types of digital coins in circulation (http://tinyurl.com/o94fhlw), each having different values and market capitalizations. Some of these coins actually reach very high values, being the most famous the case of the Bitcoin that reached the value of $1124.76 by the end of November of 2013. Although this value has decreased, it still has a high market quotation (at the time of writing: $427.20).

According to DELL, an estimated $2.6million worth in digital coins are generated every day (http://tinyurl.com/o6y4hrr) by users. Since these coins are traded digitally, are difficult to trace and have such a high value, they make a very attractive target for cyber criminals since they can use them to pay for illegal stuff or ask ransoms without worrying about being identified.

A study published by Kaspersky (http://tinyurl.com/m25vuma), shows that 8% of financial malware is already targeting cryptocurrency wallets, and 14% targets the mining process.

Also, the appearance of new malware that targets cryptocurrency varies according to the market quotation of the coins as another study from DELL (http://tinyurl.com/nqcu5h9) shows.

Although the cryptocurrency system equates into a rich, complex and distributed environment (please refer to https://bitcoin.org/ to learn the details) two core processes are systematically targeted by most attackers: the mining process and the transaction process.

To earn “coins” entities contribute to the validation of a set of the transactions by performing some complex computations (also known as mining). According to the amount of effort employed to perform the computations, entities are rewarded “coins”.

The proof of ownership of a set of “coins” is stored in the entity digital wallet. The “coins” are, like real money not tied to anyone’s identity, so what really matters is maintaining the ownership of the coins by protecting the one’s wallet.

Typically attacks to cryptocurrency environments aim to steal coins and sometimes to disturb the environment (or the network) and usually target:

• Wallets (represent a user personal wallet)
• Exchange Services (works like a bank or a store)
• Cryptocurrency network (similar to the economic system that regulates the market)
• Mining resources (where the coins are created)

User Wallets

The most obvious targets are the wallets. Since these are used to store the coins (or the coin address and private key that assures the network that the user is the owner of a set of coins), if an attacker can compromise the devices were wallets are stored, it will be possible to transfer the coins. Once the transfer is accepted, it becomes impossible to revert the operation (remember that the system works through “proof of ownership” and not by tying coins to anyone’s identity). Performing these attacks are equivalent to pickpocket a user wallet.

Currently there are over one hundred different families of wallet stealing malware (http://tinyurl.com/ovnddwz). These vary from phishing malwares that send emails that try to make the user reveal the content of his wallet, to more sophisticated ones like CoinThief.A (http://tinyurl.com/q88kxaz), which hides on the users device and waits for them to access their wallets to steal their credentials. These malwares can be seen as the pickpockets of digital wallets.

Exchange Services

Since digital coins are worthless if there isn’t a broker service that trades them for other things (like “physical” money or some kind of valuable service), exchange services have appeared and thrive worldwide. These services provide for the buying and selling of coins, and as such, they also have become a target due to the amount of digital coins that they store. Successfully attacking these services can be seen as robbing a bank or store.

Although there have been many attacks on the exchange services (http://tinyurl.com/q2ecy6t), the most famous one is the heist of MtGox (http://tinyurl.com/npnab5b). MtGox was a Tokyo based exchange service that at the time traded ¾ of the world Bitcoins.

With this heist, they lost 850.000 bitcoins (almost half a billion US dollars at the time) which, of course has lead to the bankruptcy of the service. How this heist was performed remains a mystery until now however and, if true, according to Campbell Harvey (professor at Duke University's Fuqua School of Business), it is the biggest bank heist in history.

Cryptocurrency Network

When a buyer (or sender) wants to acquire some goods (like “physical” money, service or any other product) from a seller (or receiver), a transaction of digital coins from one to another is performed. This transaction is initiated by the buyer that generates a signed block composed of his wallet address, the amount of coins and the seller wallet address. The block is then sent to the network in order to confirm the coins ownership transfer (mined). Once the seller receives the confirmation of the transaction he will accept it and handle the goods to the buyer.

But, by looking at this process, what stops the buyer from performing a double spending (spend the same coin twice) attack by creating two different block’s (one for each buyer) and sending them to the network to be confirmed? The distributed nature of the network stops this attack, because only one of those transactions will be accepted (added to the chain). This is due to the fact that one of those transactions will be accepted first (i.e. added first to the chain), and nodes only consider the first transaction (only accept the longest chain). If a transaction using the same coin arrives to be confirmed, they will detect the double spend and will not confirm it. So, to perform this attack, the sender must be able to forge a chain that is larger than the one that is currently accepted by the network.

In order to forge a larger chain, the sender must control a total amount of computing power greater than 50% of the network (i.e >=51%, which is very unlikely due to the size of the network). With it, he will be able perform a double spending attack by letting the first transaction be confirmed by the network, and then, introducing is own chain. Once introduced, it will become the main chain of the network since it is larger that the honest chain and nodes will start to work on it by adding new blocks to it.

Although this attack seems tempting because it can potentially encourage an attacker to always use the same coins to pay for something, it is less profitable than mining (http://tinyurl.com/kkxbyss). This is due to the fact, that by controlling that much computing power, the attacker will be able to collect very big rewards by staying honest and mine for coins. This means that an attacker will gain more by activity contributing to the “economy” well being than trying to control it.

Mining Resources

Earlier this year, researchers at Secure Works have discovered an attack where someone was able to redirected users (miners) to his own servers in order to “steal” their mining resources (http://tinyurl.com/o6y4hrr). Since users are rewarded according to their participation, the objective of the attacker was to have the users performing the heavy computations, and then collect their reward. This attack can be interpreted has stealing the salary of workers at a coin forging facility since it is effectively stealing their rewards for mining.

With this attack, it is estimated that the attacker was able to steal about $83.000 from the users, which isn’t much, but the interesting thing here is the way in which this attack was performed.

To execute this attack, the attacker changed the BGP routes (protocol that connects networks on the internet, for more details please read: http://tinyurl.com/o6y4hrr). After the initial advertisement, BGP ensures that the new routes are propagated through the network. When the attack was finally uncovered, it had already reached 51 different networks (http://tinyurl.com/mgo9zb6) and 19 Internet Service Providers (ISP).

The researchers have traced the origin of the attack to an ISP located in Canada. Since the BGP connected networks can only be changed manually (ensures that malicious networks can’t hijack traffic from legit ones), this means that the attacker was either an ex-employee of the ISP or was still working there.

With Cryptocurrencies current hype and exposure, researchers believe that these are just the first attacks, and that new and more complex ones will arise in the future (http://tinyurl.com/o6y4hrr).

Currently, the first Bitcoin ATM machine has been installed in Lisbon, and two more are planed for Porto and Algarve (http://tinyurl.com/lh8dwvx).

So are you prepared to start using Cryptocurrency on your day-to-day basis?

Read More