Apple is rolling out an iOS security usability feature called Security code AutoFill. The basic idea is that the OS scans incoming SMS messages for security codes and suggests them in AutoFill, so that people can use them without having to memorize or type them.
Sounds like a really good idea, but Andreas Gutmann points out an application where this could become a vulnerability: when authenticating transactions:
Transaction authentication, as opposed to user authentication, is used to attest the correctness of the intention of an action rather than just the identity of a user. It is most widely known from online banking, where it is an essential tool to defend against sophisticated attacks. For example, an adversary can try to trick a victim into transferring money to a different account than the one intended. To achieve this the adversary might use social engineering techniques such as phishing and vishing and/or tools such as Man-in-the-Browser malware.
Transaction authentication is used to defend against these adversaries. Different methods exist but in the one of relevance here -- which is among the most common methods currently used -- the bank will summarise the salient information of any transaction request, augment this summary with a TAN tailored to that information, and send this data to the registered phone number via SMS. The user, or bank customer in this case, should verify the summary and, if this summary matches with his or her intentions, copy the TAN from the SMS message into the webpage.
This new iOS feature creates problems for the use of SMS in transaction authentication. Applied to 2FA, the user would no longer need to open and read the SMS from which the code has already been conveniently extracted and presented. Unless this feature can reliably distinguish between OTPs in 2FA and TANs in transaction authentication, we can expect that users will also have their TANs extracted and presented without context of the salient information, e.g. amount and destination of the transaction. Yet, precisely the verification of this salient information is essential for security. Examples of where this scenario could apply include a Man-in-the-Middle attack on the user accessing online banking from their mobile browser, or where a malicious website or app on the user's phone accesses the bank's legitimate online banking service.
This is an interesting interaction between two security systems. Security code AutoFill eliminates the need for the user to view the SMS or memorize the one-time code. Transaction authentication assumes the user read and approved the additional information in the SMS message before using the one-time code.
Ross Anderson has a new paper on cryptocurrency exchanges. From his blog:
Bitcoin Redux explains what's going wrong in the world of cryptocurrencies. The bitcoin exchanges are developing into a shadow banking system, which do not give their customers actual bitcoin but rather display a "balance" and allow them to transact with others. However if Alice sends Bob a bitcoin, and they're both customers of the same exchange, it just adjusts their balances rather than doing anything on the blockchain. This is an e-money service, according to European law, but is the law enforced? Not where it matters. We've been looking at the details.
The very short version is that a UK bank, TSB, which had been merged into and then many years later was spun out of Lloyds Bank, was bought by the Spanish bank Banco Sabadell in 2015. Lloyds had continued to run the TSB systems and was to transfer them over to Sabadell over the weekend. It's turned out to be an epic failure, and it's not clear if and when this can be straightened out.
The more serious issue is the fact that customers still can't access online accounts and even more disconcerting, are sometimes being allowed into other people's accounts, says there are massive problems with data integrity. That's a nightmare to sort out.
Even worse, the fact that this situation has persisted strongly suggests that Lloyds went ahead with the migration without allowing for a rollback.
This video purports to be a bank robbery in Kiev. He first threatens a teller, who basically ignores him because she's behind bullet-proof glass. But then the robber threatens one of her co-workers, who is on his side of the glass. Interesting example of a security system failing for an unexpected reason.
The video is weird, though. The robber seems very unsure of himself, and never really points the gun at anyone or even holds it properly.
The Economist has an article on the potential hacking of the global financial system, either for profit or to cause mayhem. It's reasonably balanced.
So how might such an attack unfold? Step one, several months before mayhem is unleashed, is to get into the system. Financial institutions have endless virtual doors that could be used to trespass, but one of the easiest to force is still the front door. By getting someone who works at an FMI or a partner company to click on a corrupt link through a "phishing" attack (an attempt to get hold of sensitive information by masquerading as someone trustworthy), or stealing their credentials when they use public Wi-Fi, hackers can impersonate them and install malware to watch over employees' shoulders and see how the institution's system functions. This happened in the Carbanak case: hackers installed a "RAT" (remote-access tool) to make videos of employees' computers.
Step two is to study the system and set up booby traps. Once in, the gang quietly observes the quirks and defences of the system in order to plan the perfect attack from within; hackers have been known to sit like this for years. Provided they are not detected, they pick their places to plant spyware or malware that can be activated at the click of a button.
Step three is the launch. One day, preferably when there is already distracting market turmoil, they unleash a series of attacks on, say, multiple clearing houses.
The attackers might start with small changes, tweaking numbers in transactions as they are processed (Bank A gets credited $1,000, for example, but on the other side of the transaction Bank B is debited $0, or $900 or $100,000). As lots of erroneous payments travel the globe, and as it becomes clear that these are not just "glitches", eventually the entire system would be deemed unreliable. Unsure how much money they have, banks could not settle their books when markets close. Settlement is a legally defined, binding moment. Regulators and central banks would become agitated if they could not see how solvent the nation's banks were at the end of the financial day.
In many aspects of our society, as attackers become more powerful the potential for catastrophe increases. We need to ensure that the likelihood of catastrophe remains low.
The New York Times is reporting that some women in China are being forced to supply nude photos of themselves as collateral for getting a loan. Aside from the awfulness of this practice, it's really bad collateral because it's impossible to ever get it back.
This interesting essay argues that financial risks are generally not systemic risks, and instead are generally much smaller. That's certainly been our experience to date:
While systemic risk is frequently invoked as a key reason to be on guard for cyber risk, such a connection is quite tenuous. A cyber event might in extreme cases result in a systemic crisis, but to do so needs highly fortuitous timing.
From the point of view of policymaking, rather than simply asserting systemic consequences for cyber risks, it would be better if the cyber discussion were better integrated into the existing macroprudential dialogue. To us, the overall discussion of cyber and systemic risk seems to be too focused on IT considerations and not enough on economic consequences.
After all, if there are systemic consequences from cyber risk, the chain of causality will be found in the macroprudential domain.