Earlier today I read an article about Monzo leaking PINs of their customers into operational logs. Bad. What’s worse – this is the second Monzo’s technical problem I came across within last 12 months.
A Year Ago
I have been doing a lot of work with smart cards, including banking cards. One summer day, I needed a card to run some tests and just plugged a Monzo card in. To mu surprise, the tests stopped working. I checked everything only to find out that the Monzo card was “dead”. What was going on??
It turned out that Monzo hadn’t LOCKed their cards. That would prevent the selection of the “system app”. The system app allows the card content management – listing, deleting, and installation of new applications to chip cards. It is something you should do in development, but not in production – it should have been LOCKED!
Note (7 August): just to clarify – the card behavior I observed is expected and correct. The problem here is the bank’s personalization process that turns “a card” into “Monzo card”.
Not locking cards, banking cards in this case, is a symptom of broken security policies, production life-cycle, poor understanding of security management, etc., as:
If someone compromises Monzo programming keys, they can re-program existing cards and make them do nasty things – like allowing export of PINs using “hidden commands”, changing behavior, diverge from the VISA/Mastercard standard and mandated behavior.
Rogue payment terminals can “kill” Monzo cards – disabling Chip&PIN as well as contactless payment functionality and force fallback to less secure magnetic stripe payments.
Potentially, attackers can disable Monzo cards over-the-air and put Monzo users into unexpected situations and exploit that for attacks.
This happened in the last week of July / beginning of August 2018. I believed that Monzo personalized their cards in-house so it was a strong indication of something rotten within this challenger bank. I’m not sure whether it was raised within the bank, but they had the opportunity.
This Is Getting Bad
Fast-forward to 5th August – 480,000 (currently quoted) customer PINs stored in logs. The logs were encrypted, but accessible to “unauthorized engineers”.
I would translate it as “it was in the AWS Amazon cloud on encrypted disks without any application-level encryption”, which basically protects the data when someone tries to steal storage disks from Amazon’s data center.
If the first incident was an indication, two of such security incidents mean that Monzo deserves a pretty thorough external audit to get their house in order. Quickly.
Is There A Lesson?
I have been of an opinion that all the hype around fintech and challenger banks and revolution in banking is all good … till these companies hit regulation barriers.
When that happens, fintech is quite happy to use traditional banks to provide the regulatory backbone. The new companies are driven by venture capital and the return on investment is the key priority. Corners must be cut to get a new business off the ground and while the business proposition evolves. But that must change once a company is up and running and profitable.
I know how difficult it is to build a secure system – it is not easy and challenger banks have to catch up with decades of technology evolution. Having said that, I don’t think we should give them some slack for being new.
A Note About Programming Chip Cards
After some research a year ago, it turned out that I tried to open a secure encrypted channel with the card with wrong (i.e., default) encryption keys. And the card deleted all its content and stopped working. Now – you would expect this not being possible. One should NOT be able to start the secure channel (reasons given above).
When we talk about chip cards (Chip&PIN bank cards used across Europe are such cards), they need an application – just like any computer. It can either be loaded during personalization – which is faster and cheaper but less flexible. This works for large volume use-cases like passports, ID cards, T1 banks, etc.
Another approach is to allow developers to program chip cards with own applications. One of the most popular type of such cards is Java card, where you can write Java programs and make them work on cards. More expensive, slower, but very flexible. Once in production (i.e., sent to users), they should be LOCKed for:
security – it’s not possible to re-program the cards with malicious apps; and
reliability / denial of service – prevent “killing” of chip cards.
As chip cards have very strong cyber security protection, any programming requires encryption and authorization before a chip card can be programmed (or freed of old applications). Each card will only give you a few tries to get the encryption right. If you fail, the card “dies” – it will stop working completely and delete all its memory.