The Weekly Ink #18
THE WEEKLY INK
The Weekly Ink is the weekly newsletter brought to you by Duo Labs, the security research team at Duo Security, with curated links of interest in the security world to inform the community on security happenings and culture.
Attack of the Mobile "Super-Cookies"
In yet another blow to the world's online privacy advocates, it recently came out that Verizon has been injecting unique IDs into all HTTP requests sent over their mobile network. Notably, the tracking header gets sent along to any website you visit, meaning that sites with absolutely no affiliation with Verizon can still use the UIDH header to track Verizon users. As with other ISP schemes to inject content into web traffic, this sort of thing is very dangerous: it could violate core assumptions upon which application developers build their security models.
Unfortunately, it seems there's little most mobile users can do but complain - the only ways to avoid this tracking header are to run all of your web traffic through an encrypted tunnel (e.g. VPN), or to avoid using mobile data networks at all. Oh, and in case you were thinking about switching providers: AT&T is doing it too.
CurrentC: currently not looking so great
If you hadn't previously heard of CurrentC - the mobile-payments scheme backed by MCX, a consortium of some of the largest retailer chains - there's a good chance that changed this week. Even though the system is still only in a pilot phase, retailers have been stirring controversy by shutting off support for Apple Pay and Google Wallet (seen as competing systems) - and that was before CurrentC got hacked. They allege that attackers only got their hands on some email addresses of pilot participants (and other people who'd expressed interest), but surely this calls into question their assertion that storing personal data in their "secure cloud-hosted network" is preferable to keeping it on users' phones (say, in a Secure Element?)
Exploiting failures in EMV implementations
Meanwhile, KrebsOnSecurity reports that several banks have recently suffered a deluge of fraudulent card transactions with a surprise twist: they appear to be chip-card transactions! In the wake of an ongoing spate of major consumer data breaches, the US government and financial industry have been pushing to finally adopt the EMV, the more-secure smart-chip-based payment standard used in much of the rest of the world (Apple Pay is helping too; it is built on the 'contactless' variant of the EMV standard). However, it turns out that this rapid adoption might have had some unintended consequences, opening up new avenues of attack!
In theory, these sorts of fraudulent "replay" transactions shouldn't be possible under EMV, but it appears that some banks might have failed to properly implement some validation required by the protocol. This should serve as an important reminder: even if the design of a system like EMV is perfect (and there's plenty of reason to doubt that), it can be very hard to get the implementations right - and those that fail to do so might end up worse off than where they started.
One interesting nugget from Krebs' post is the mention that "banks are responsible for all of the fraud costs that occur from any fraudulent use of their customers chip-enabled credit/debit cards even fraudulent charges disguised as these pseudo-chip transactions." This seems to stand in stark contrast to previous deployments of EMV: security researcher Ross Anderson has often criticized the UK's roll-out of Chip-and-PIN in that it was used as a means to shift liability away from banks, and - in particular - onto individual consumers. If US-based banks actually have to bear the liability of EMV failures, then they will be more-strongly incentivized to get this right (or to lobby the government to change the rules).
Require-Recipient-Valid-Since
Last year, Yahoo announced that it was going to start reclaiming "long-dormant" email addresses and making them available to new users. Savvy observers (e.g. Wired's Mat Honan) quickly realized this could have some really terrible security results: email is one of the most commonly-used password-recovery methods, so if an attacker were to gain control of your primary email address, she could likely break into most of your other accounts across the internet.
Working with other stakeholders (notably Facebook), Yahoo developed a new SMTP extension called 'Require-Recipient-Valid-Since' to mitigate this concern, and the spec recently became an IETF proposed standard. Basically, RRVS is a way for email senders to indicate a message should not be delivered if the recipient address changed owners after a certain date. It's a fine idea in principle, but for it to work in practice, every site with email-based password recovery must implement it. I, for one, don't really see this happening any time soon.