The weakest link

Companies tend to spend a great deal of time, money and resources securing their network and systems implementing a layered model of security. This form of security is based on the premise that, the deeper a layer is, the more secure it should be. Each layer has a different purpose and as such, is composed by different stacks of hardware and software.

Since breaching these layers is hard, attackers target the users via phishing techniques to make them install malware or reveal their corporate credentials. After, they are able to use the disclosed information to breach the layers and gain privileged access to the internal network. To prevent these situations, there are a lot of tools (ex: Trusteer Apex, Confer) that use different techniques to detect anomalous behaviour and try to block the information disclosure.

Security layers example

What if we told you that it may be possible to obtain the corporate credentials via a third party that are totally outside your control? To understand this, we have to look at the rules of corporate credentials, more precisely, the password policy.

Most companies correctly enforce a set of rules on the password in order to make it stronger and thus, preventing the success of brute force attacks. The rules are normally composed of:

1. Minimum length;
2. At least one uppercase letter;
3. At least one lowercase letter;
4. One "special" character;
5. One number;
6. Time limited passwords;

By enforcing these rules, users end up with a strong password that is very hard to guess. However, this also has a downside.

Since users get a strong password that is not easy to memorize, the probability of reusing it on other places outside the corporate environment once it is memorized is non-neglectable. The password may end being used on the social networks, email services, online stores, travel agencies websites and so on. This behaviour, may pose a serious problem.

Due to the fact that, not all sites properly secure the user information and passwords, if an attacker is able to steal this information, there may be a chance that he can obtain the corporate password. Some examples of such hacks are the ones that have occurred on Sony, eBay, Home Depot. These, are just some of the "great ones", now think about the small business stores that have websites that require users to authenticate but offer little or no security. One may argue that companies enforce password rotation at predefined time intervals, however, most people tend to rotate between two or three passwords.

From here, all the attacker needs to do is associate the users to their companies. Well, if only people would share everything about their lives somewhere… Oh that's right; we live in the social networks era. Once identified, the attacker may now try to break into the company network via internet facing services using the collected passwords. Guessing the usernames should be an easy task via social engineering.

The point that we want to make with this post is: although companies spend a lot of money creating a "bulletproof" perimeter defence, if users are not "educated" to clearly separate corporate "life" from the "personal" life, breaches will continue to occur. These, and other such situations, make users the weakest link of your corporate security policy.

Since security is not only about technology but, also involves people and the processes that they use, companies should start educating their employees about the importance of separating personal and corporate life. To do this, companies should rely on their Human Resources department to, raise awareness about the problems of mixing both, promote training courses, or even educating people on this subject.

Read More

Email - From, To Who?

One of the most (if not the most) popular means of communication over the Internet is the email messages. According to a study made by Redicati (http://bit.ly/1l2gJ2z), the number of email accounts will hit little over 4.3 billion in 2015 generating 194 billions of emails per day.

Typically, to access the content of an email account, a user makes use of a mail client. These, allow users to compose, send, receive and read emails. They can either be local clients like Outlook Express or Thunderbird or via cloud based clients like gmail.com. But how does it all work?

The email service is built upon two different phases, the send and receive phases. To send an email, the Simple Mail Transfer Protocol (SMTP) is used while, to receive, depending on the email client, it is possible to use the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP).

Send

To send an email, the SMTP protocol is used. This protocol delivers the message between the sender and the receiver email server. This protocol may in fact be used more than once during the email transfer.

When an user sends an email, the client or mail-user-agent (MUA) connects to the SMTP server on port 587 (port 25 or 465 should no longer be used for this purpose) where a mail transfer agent (MTA) listening for new outgoing email messages. Once connected, a series of messages are exchanged between the client (sends 4byte commands) and the server (replies with a number and a description) in order to establish the email transfer parameters and transfer the email message from the MUA to the MTA.

Once the message is on the MTA, the receiver address is splitted into the user and the domain. After, the MTA consults a DNS in order to convert the domain into a mx record (mail exchanger record) that, is nothing more than the ip address of the SMTP server of the receiver of the email.

With the mx record, the MTA connects to the receiver SMTP server on port 25 and transfer the email message. This process of transferring an email message from one server to another is known as relay.

Once on the receiver server, two things may happen:

1. This SMTP server aggregates more than one email domain and executes the protocol again to deliver the email message to another SMTP server;
2. This is the final email server and in which case, the email message is delivered to the POP/IMAP server where it awaits for the MUA to connect and download the email for reading.

Simplified SMTP flow

Receive

When an email is delivered to the receiver MTA, it goes to a processing queue (that are composed by flat files) where, it awaits for the receiver to retrieve it.

As stated before, there are two different protocol to retrieve email. Each, runs on a separate server from the SMTP server (may be on the same physical machine) and are intended to be used on different situations.

Simplified Receiver Email Server Architecture

POP3

The first protocol is the Post Office Protocol which, currently is on version 3 (POP3). This protocol is intended to be used by remote clients and works on a download-and-delete basis.

When a client wants to read is email, the MUA connects to the POP3 server either on port 110 (clear text connection) or port 995 (encrypted connection). Once the connection is established, the server enters the Authorization phase where the MUA authenticates to the server.

If the MUA has provided valid credentials, the server enters the Transaction phase where it acquires an exclusive lock to the maildrop (where the mail of the client is stored). On this phase, the MUA will download the new emails and mark them to be deleted.

After the connection is closed, the server enters the Update phase where it will delete all marked messages.

Although it is possible to maintain the download messages, the protocol was designed to save server space and, thus, it deletes the messages by omission. The clients may change this behaviour on the MUA by indicating that it wishes to save a copy on the server.

The POP3 is a very simple protocol and as such, it has several limitations like for example:

1. Doesn't know the concept of folders or flags;
2. Only allows for one MUA to be connected to a specific account at any given time;
3. It can't read the different parts of a MIME envelope, enforcing the download of the full email message and not just part of it (example: the header).

IMAP

As POP3, IMAP is also designed to be used by remote clients. However, when compared with POP3 it:

1. Doesn't follow the download-and-delete philosophy, maintaining the messages on the server after retrieving them;
2. Offers a more complete set of functionalities, allowing it to, for example, manipulate folders and flags;
3. Allows for more than one MUA to be connected at the same time, thus creating the possibility for a client to connect more than one device to the mail server at the same time;
4. Can read the different parts of a MIME envelope and download each one as needed

Aside these differences, the protocol works pretty much the same as POP3. The client MUA connects to the server on port 143 (clear text) or 993 (encrypted), authenticates, manipulates the mailbox and logs out.

We have spent the better part of this post giving a brief overview of the send and receive phases, but we haven't explained what an email message is.

So, what exactly is an email message? In simple words its plaintext. In an in more depth analyses, an email message is divided into two different parts, the header and the body.

The header contains structured information in the form of fields. These, are composed by the pair name: value and in them, we find the To, From, CC, BCC, Subject and so on.

The body contains the email content. The initial specification (RFC 822) indicated that it could only contain ASCII characters which, meant that only simple text could be sent. However, and since this imposes a lot of limitations, the Multi-Purpose Internet Mail Extension (MIME for short) was developed.

MIME among other things, has enabled email messages to carry for example multimedia, images, styled text, documents and other types of content. It manages this by adding a multi-part support where, a message is divided into several parts. Each, can have a different format that is specified in a "part" header (remember, more than ASCII).

MIME part example

The above picture displays an example of a raw MIME email part. It starts with a boundary that indicates where the previous part ends. After, we have a part header that describes the content of the MIME part followed by the content and at the end, we will have another boundary.

The interesting thing is the "Content-Transfer-Encoding: base64" which indicates how the attachment is sent with the email message. Remember, that an email can only contain simple text and, as such, an attachment needs to be converted to simple text, and this is the way to do it. The file is converted to base64, written on the email and sent as text. Once it arrives, it is reconverted to a file.

On this post we have described the basic functionality of the email service. Our next post address the security issues related to the email and present a few solutions to enhance it.

Read More

Contactless, Cardless or Cashless? (part 3)

Cardless

Here we are for third and final part of this post. In it, we will address the cardless payment systems. Although there are many, like, for example, the wristbands used in the festival Lollapalooza 2014 (http://tinyurl.com/l362zdn) we, will focus on the ones that are design to be used with smartphones. From these, the most famous ones are Google Wallet and more recent Apple Pay.

Google Wallet

In 2011, Google has lunched the Google Wallet (http://tinyurl.com/kxgvmtx) service for the Android users. This service was designed to enable users to buy goods using their NFC enabled Android devices, by emulating the credit card behaviour.

In order for the service to work, Google required users to introduce on the device their credit card information. This information, was then stored in the secure element of the device. This element, is practically isolated from the rest of the system and, each time the device is used to buy something, it requires the user to introduce a four-digit PIN before transmitting its information to the terminal.

In order for third-party app developers to take advantage of the capabilities of NFC enabled devices, in 2014, Google introduced the Host Card Emulation. This new feature emulates the behaviour of the secure element and makes it easier for the developers to use the NFC capabilities.

Currently, Google doesn’t store the users credit card information on the device. Each time a user wants to associate a credit card to the Google Wallet service, a Google Wallet Virtual Card is emitted by Bancorp Bank (associated with Google). The information related to this new virtual card is then stored on the device using the Host Card Emulation feature. The users credit card information is stored on Google servers as is the users virtual card information.

Google Wallet registration sequence

When a user makes a payment using the device, it procedes as a normal credit card payment, meaning that it follows the EMV protocol (check part 1 of this article for the EMV protocol). The difference is that the money that is transferred from the acquirer to the merchant is provided by Google banking entity. At a latter time, the funds are discounted by Google from the user credit card.

Google Wallet payment sequence

If we take into account that each payment that goes through the EMV network has a fee that is charged to the merchant, we can see that Google may be losing money with Google Wallet. This is due to the fact that Google acts as both the Acquirers Bank to the Merchants Bank, but at a latter time, acts as a Merchants Bank to the Acquirers Bank.

So, one has to ask, how is Google profiting from Google Wallet because, no one enters a business to lose money?

Apple Pay

With the launch of iPhone 6, Apple has introduced Apple Pay (http://tinyurl.com/pjkatel). This is a new functionality that, allows users to pay for goods using some of Apple devices. Apple Pay relies on a tweaked tokenization technique that doesn’t store any information about credit cards on the device or on Apple servers.

When a user wants to configure Apple Pay, he introduces its credit card information (either by typing the card information or, taking a picture). The information is encrypted and sent over to Apple. Once received, it is decrypted and the card issuer identified. Apple will then generate a new encrypted packet containing the credit card information, the device information and iTunes history and send it to the card issuer.

When the packet is received by the issuer, it will evaluate the information and generate a DAN (Device Account Number) that is specific for the user’s device. The DAN is then encrypted using a key that only the card issuer can decrypt (leaving Apple incapable of decrypting it) and sent back to Apple along with a key used to generate dynamic codes unique to each transaction that is going to be performed. The encrypted packet is then forwarded to the user’s device where, it is stored in the secure element.

Apple Pay tokenization sequence

From this point on, each time that a user wants to make a purchase, the secure element will request the user to authenticate by using the touch id. After, a one-time-number is generated and sent to the the merchants terminal. The rest of the payment operation procedes has a normal EMV transaction.

By employing tokenization, Apple was able to convince the card issuer entities that it actually deserves a fee for each payment that is made using Apple Pay. This is due to the argument that  by employing this technique, Apple is actually reducing the probability of fraud (thus reducing the costs of the issuing entities) and, that users will spend more by using Apple Pay (http://tinyurl.com/lh67hyl).

But how secure is Apple Pay? Well, until now, direct attacks haven’t been reported (http://tinyurl.com/k28s7g5). However, the way that users authenticate to the devices may be vulnerable to attacks.

In late 2014, a member of CCC (Chaos Computer Club) has demonstrated how to clone a fingerprint from pictures (http://tinyurl.com/q5rdnfp). This allows another user to clone a fingerprint and personificate the owner to the device.

So Apple has based Apple Pay security on two distinct things, tokenization (that until the time of writing remains “safe”), and biometric information that, has demonstrated, can be hacked. Actually the same member of CCC in March 2015 has demonstrated how to clone an iris pattern from high resolution pictures (http://tinyurl.com/q3qlmg4).

Although Google Wallet and Apple Pay are the major players on the market, there are several new ones arising.

For example, SEQR (http://tinyurl.com/pvjvl9e) connects the users phone to the bank and relies on QR codes to read payment information from the terminal. As we stated in a previous post (http://tinyurl.com/o7lgj3c), depending on how these QR codes are generated, they may pose a security risk.

Another mobile payment system is Meo Wallet (www.wallet.pt). Apart from the “traditional” credit card association, it brings an interesting feature, it allows users to charge the wallet as needed. This way, a user is able to clearly separate their bank account from the device running the digital wallet.

SIBS has also announced MB Way (http://tinyurl.com/o9xttvs), but unfortunately is not yet available and little or no information is available of how it works.

From a curiosity point of view, we questioned one of these companies about how they are abe to guarantee the security of their system and the clients information and, we were very surprised with the answer. Citing from the reply email: “ We can assure that the use of * is secure, however, and how you should comprehend, for security reasons, we cannot answer your questions”. This answer actually makes one wonder if they are trying to do security by obscurity and, how secure is my information?

In this three part post we have covered the “state of the art” payment systems. We have showed that all have flaws an can be exploited in a malicious way. So how do you feel about the security of your money?

Read More

Contactless, Cardless or Cashless? (part 2)

Currently, many smart cards are being shipped with a contactless feature. This feature is built upon the RFID (radio frequency identification) technology and enables communication between the chip on the card and terminals without physical contact (http://tinyurl.com/n23f46h).

To be able to communicate with these cards, terminals make use of NFC (near field communication) which, is capable of transmitting and receiving information from the card (http://tinyurl.com/pkgug5m). NFC technology is designed to work in close proximity (just a few centimeters), and due to this restriction is considered fairly secure.

In order to speed up low value transactions, contactless payments don’t require the cardholder to authenticate. Cardholder authentication will only be required depending on factors like value of the transaction (individual or cumulative) or number of contactless payments per day. However and, despite the fact that the cardholder does not need to authenticate himself, contactless cards are still compliant with the EMV standard (thus, follow all the phases of the protocol) since the CVM (cardholder verification method) list contains the option “NONE” that indicates that no verification is required.

So, in short, the contactless feature introduces cards that for some operations don’t require any type of physical contact or authentication to execute a payments. Another important fact to notice is that, these cards are passive in the sense that they do not produce any perceptible sign that they are being used. This not only increases the attack surface of such cards, but also introduces a new attack vector, the contactless feature.

Since the introduction of NFC capabilities on smartphones, reading contactless cards has become quite simple (and cheap). Several researches have shown that is possible to exploit this feature to abuse such cards.

A paper by researches from the Royal Holloway University (http://tinyurl.com/o2o5puo) shows that is possible transform a smartphone with NFC into a terminal or a card. They do this by installing custom made software on a smartphone that enables them to read the information provided by a smart card. Once they get the information, they then use the smartphone has a contactless card. A practical demonstration of a similar attack is performed by a journalist of  Komo 4 News.

Digital pickpockets using technology to steal credit cards

The same researches have also published another paper where they describe a relay attack (http://tinyurl.com/pjeazbp). In relay attacks (also know as wormhole attacks), an attacker personificate the terminal to the card, and the card to the terminal in “real time”. He does this by using two distinct NFC devices, one near the card and another at the terminal. He, then transmits the messages that he is receiving from the card to the terminal and vice versa.

Relay attack

An attack of different nature is described by a group of Newcastle University (http://tinyurl.com/k8v3m99). In this attack, they make use of the contactless feature of the cards to try and guess their PIN. To carry out the attack, they take advantage of a few features of the smart cards:

1. It is still possible to require a PIN verification in the contactless “mode”.

2. Although there is a limit on the number of incorrect PIN tries, the counter that keeps tracks of the incorrect PIN entries is reseted when a correct PIN is inserted.

3. From all the possible PIN combinations, there is a subset of PINs that is more used.

4. People tend to store their cards in the same place.

5. PIN verification can be made in offline mode.

This attack is based on a very specific scenario that over time, can give the attacker unlimited PIN tries. Imagine that you frequently have to use an RFID card (for example to enter an leave your work place), that you store this card with all your other cards on your wallet and, that to use the card, you just approach your wallet to the reader instead of, taking the card out of your wallet. An attacker can make use of the reader to try and guess your PIN during this moment. All that he has to do is read the number of PIN tries that are left on the card, and if this number is bigger than one (not to arouse suspicious) he selects one PIN and gives it to the card. He then waits for the reply that is either success or failure. When the number of tries left is one, he stops so that, the cardholder does not suspect that incorrect PINs where feed to the card and he executes the reset on the number of tries when he uses the card. Once the PIN is discovered, the attacker can identify the cardholder by making the examining the the ID card information.

PIN validation attack algorithm

Although this attack may seem a bit farfetched, when you combine it with a location with many possible victims, the success rate may be considerable.

Currently, Caixa Geral de Depositos allows a max of 60€ per day (20€ max per transaction) before asking for cardholder verification (http://tinyurl.com/ncaw7tl). Now imagine that an attacker can perform any these attacks in places where you have many people and physical proximity is not suspicious (for example, public transportation during rush hour), can you guess how many money will he be able to divert before being discovered?

This article will continue in a third part that, will talk about cardless payment systems, how they work and conclude about all the three parts.

Read More