24 August 2017
Steven Murdoch

Steven Murdoch

Steven Murdoch - University College London

9Posts 59,372Views 35Comments
Information Security

Information Security

The risks from Cyber cime - Hacking - Loss of Data Privacy - Identity Theft and other topical threats - can be greatly reduced by implementation of robust IT Security controls ...

Demonstration of CAP vulnerability on BBC One today

26 October 2009  |  4689 views  |  4

This evening (Monday 26th October 2009, at 19:30 UTC), BBC Inside Out will show Saar Drimer and I demonstrating how the use of smart card readers, being issued in the UK to authenticate online banking transactions, can be circumvented. The programme will be broadcast on BBC One, but only in the East of England and Cambridgeshire, however it should also be available on iPlayer.

In this programme, we demonstrate how a tampered Chip & PIN terminal could collect an authentication code for Barclays online banking, while a customer thinks they are buying a sandwich. The criminal could then, at their leisure, use this code and the customer’s membership number to fraudulently transfer up to £10,000.

Read more at Light Blue Touchpaper...

BBC Inside Out, 26 October 2009, 19:30, BBC One East TagsSecurity

Comments: (9)

Steven Murdoch
Steven Murdoch - University College London - London | 26 October, 2009, 14:37

The BBC have released a video clip, and online article, covering the upcoming TV programme.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Steven Murdoch
Steven Murdoch - University College London - London | 27 October, 2009, 02:28

The full programme is now on BBC iPlayer for the next 7 days, and a clip is also on YouTube.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Stephen Wilson
Stephen Wilson - Lockstep Group - Sydney | 27 October, 2009, 20:32

I actually don't understand the attack (perhaps some technical details were left by the BBC on the cutting room floor). 

The reporter in the video clip says that a 'one time code' is retrieved by the attacker from the compromised retail terminal, and then used together with the name and account number to log on to the victim's net banking facility.

What sort of one time code exactly?  Also, it's not clear if this attack is designed to bypass the unconnected Chip-and-PIN Card reader that might be used at home to authenticate Internet banking logon, or whether it is used against a single factor logon protocol.

Perhaps the attack involves a measure of social engineering as well, where the tampered terminal is prompting the customer to enter Internet related secrets as well as regular card-present transaction details (PIN)?

Thanks in advance for any amplification. 

Stephen Wilson, Lockstep.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Steven Murdoch
Steven Murdoch - University College London - London | 28 October, 2009, 00:33

Hi Stephen,

Thanks for your interest; I'd be happy to clarify.

The "one-time code" is intended to bypass the two-factor CAP authentication. In fact, the tampered terminal implements the disconnected card reader protocol and requests two authentication codes: an "identify" code for login, and a "sign" code to initiate a transfer.

These codes were then used on the Barclays online banking system, which requires the use of the card-reader for both logging in, and performing transfers to new accounts. Notably, Barclays (unlike NatWest/RBS), do not include a nonce in the challenge, so the one-time authentication codes remain valid indefinitely (at least until the customer logs in again).

There is also a social engineering step, where the customer ID must be solicited, either before or after the customer uses the tampered terminal. The customer ID is not a secret, and customers are encouraged to keep it with their bank card, so will be much easier to obtain than the PIN, for example. Alternatively, it could be picked up by a keylogger. In principle the tampered Chip & PIN terminal could ask for it, but I suspect that would raise the suspicions of the customer.

Does this help clarify? We have more details in the academic paper.

Steven.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
A Finextra member
A Finextra member | 28 October, 2009, 04:49

Love your work.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Stephen Wilson
Stephen Wilson - Lockstep Group - Sydney | 28 October, 2009, 17:26

Thanks Steven.

You explained that:

The tampered terminal implements the disconnected card reader protocol and requests two authentication codes: an "identify" code for login, and a "sign" code to initiate a transfer.

Isn't this highly unusual behaviour for a POS Terminal?  Surely a  terminal only ever prompts for the PIN.  This is what I meant by Social Engineering: Not only must you tamper with the terminal, but you must also suck the customer into entering Internet-related data at the terminal at the store.

So I don't see this attack as being especially momentous.  Isn't it easily overcome by having the Internet authentication protocol involve a nonce to make the OTP non-replayable?  And obviously educating customers to not enter superfluous details at a retail terminal. 

For these terribly weak CAP implementations where the OTP lasts indefintely and is replayable, I would have thought that a Man-in-the-Middle attack, or good old phishing attack to garner codes online would be more fruitful than opening up terminals and re-programming the firmware (but not as much fun).

 

 

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Steven Murdoch
Steven Murdoch - University College London - London | 29 October, 2009, 18:16

Hi Stephen,

Isn't this highly unusual behaviour for a POS Terminal?  Surely a  terminal only ever prompts for the PIN.

The tampered POS terminal behaves exactly like a normal POS terminal. It only prompts for the PIN from the customer. It also requests the two one-time authentication codes (login and sign) from the card, but of course the customer can't see that because the card has no display.

The crook also needs the customer's membership number, and that could be obtained either by compromising the customer's PC, or by a separate targeted social engineering attack.

The best I can think of is if the crook calls up the customer and says "Did you recently make a purchase at X? That's fine; can I please get your membership number to confirm your identity." Banks already do this, so customers shouldn't be worried.

I would have thought that a Man-in-the-Middle attack, or good old phishing attack to garner codes online would be more fruitful

CAP was designed to prevent MitM, because the Barclays card readers show the destination account number and amount for the transaction. Had Barclays not used the same card for both point of sale and online banking, this would have probably worked. However, the purpose of this demonstration was to show that it doesn't.

For the RBS/NatWest system, MitM does work fine, because when customers generate a one-time authentication code, they can't tell what it is for. Criminals are actively exploiting this, so there doesn't seem much point in doing a demonstration.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Stephen Wilson
Stephen Wilson - Lockstep Group - Sydney | 29 October, 2009, 19:16

Thanks again Steven.  I see now -- the compromised terminal itself asks the card for the CAP code, under the covers, and sends it back to base. Duh! Pardon my error.

Another mitigating design feature might have been for the EMV card to enforce PIN re-entry for every fresh cryptographic event (the POS transaction, then the CAP code).  I guess you're showing that once the PIN is entered, the card will sit there and accept multiple cryptographic requests until it's taken out of the reader?  Nuts.

 

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Steven Murdoch
Steven Murdoch - University College London - London | 30 October, 2009, 13:48

Hi Stephen

Another mitigating design feature might have been for the EMV card to enforce PIN re-entry for every fresh cryptographic event (the POS transaction, then the CAP code).

Cards I have tested do implement this restriction – they will only respond to the GENERATE AC command twice, during each run. However that doesn't help, because the tampered terminal just stores the PIN, resets the card, and initiates a new transaction without interacting with the customer.

I guess you're showing that once the PIN is entered, the card will sit there and accept multiple cryptographic requests until it's taken out of the reader?  Nuts.

Provided you do a software reset, yes. There's not much the card can do about it though, because the tampered terminal can always disconnect power to the card and reconnect it. This is a standard feature of off-the-shelf smartcard readers which implement the CCID protocol.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Comment on this story (membership required)

Latest posts from Steven

Chip and Skim: cloning EMV cards with the pre-play attack

11 September 2012  |  8086 views  |  3 comments | recomends Recommends 1 TagsSecurityPaymentsGroupInformation Security

UK Cards Association attempt to supress Cambridge research

25 December 2010  |  8026 views  |  4 comments | recomends Recommends 1 TagsCardsSecurityGroupInformation Security

Reliability of Chip and PIN evidence in banking disputes

26 February 2010  |  6102 views  |  0 comments | recomends Recommends 0 TagsSecurityRisk & regulationGroupInformation Security

Chip and PIN is broken

12 February 2010  |  10510 views  |  13 comments | recomends Recommends 0 TagsCardsSecurityGroupInformation Security

Verified by Visa and MasterCard SecureCode

27 January 2010  |  8799 views  |  3 comments | recomends Recommends 1 TagsSecurityPaymentsGroupInformation Security

Steven's profile

job title Royal Society University Research Fellow
location London
member since 2009
Summary profile See full profile »
Dr Steven J. Murdoch is a Royal Society University Research Fellow in the Information Security Research Group of University College London, working on developing metrics for security and privacy.

Steven's expertise

Member since 2009
9 posts35 comments
What Steven reads
Steven's blog archive
2012 (1)2010 (5)2009 (3)

Who's commenting on Steven's posts