December 1, 2020

Vulnerability reporting is dysfunctional

By Kevin Lee, Ben Kaiser, Jonathan Mayer, and Arvind Narayanan

In January, we released a study showing the ease of SIM swaps at five U.S. prepaid carriers.  These attacks—in which an adversary tricks telecoms into moving the victim’s phone number to a new SIM card under the attacker’s control—divert calls and SMS text messages away from the victim. This allows attackers to receive private information such as SMS-based authentication codes, which are often used in multi-factor login and password recovery procedures. 

We also uncovered 17 websites that use SMS-based multi-factor authentication (MFA) and SMS-based password recovery simultaneously, leaving accounts open to takeover from a SIM swap alone; an attacker can simply reset a victim’s account password and answer the security challenge when logging in. We responsibly disclosed the vulnerabilities to those websites in early January, urging them to make changes to disallow this configuration. Throughout the process, we encountered two wider issues: (1) lack of security reporting mechanisms, and (2) a general misunderstanding of authentication policies. As a result, 9 of these 17 websites, listed below, remain vulnerable by default.

Disclosure Process. On each website, we first looked for email addresses dedicated to vulnerability reporting; if none existed, we looked for the companies on bug bounty platforms such as HackerOne. If we were unable to reach a company through a dedicated security email or through bug bounty programs, as a last resort, we reached out through customer support channels. Sixty days after our reports, we re-tested the configurations at the companies, except for those that reported that they had fixed the vulnerabilities.

Outcomes. Three companies—Adobe, Snapchat, and eBay—acknowledged and promptly fixed the vulnerabilities we reported. In one additional case, the vulnerability was fixed, but only after we exhausted the three contact options and reached out to company personnel via a direct message on Twitter. In three cases—Blizzard, Microsoft, and Taxact—our vulnerability report did not produce the intended effect (Microsoft and Taxact did not understand the issue, Blizzard provided a generic acknowledgment email), but in our 60-day re-test, we found that the vulnerabilities had been fixed (without the companies notifying us). As such, we do not know whether the fixes were implemented in light of our research.

Among the responses we received, there were several failure modes, which were not mutually exclusive. 

  • In five cases, personnel did not understand our vulnerability report, despite our attempts to make it as clear as possible (see Appendix B of our paper). Three of them—Microsoft, Paypal, and Yahoo—demonstrated knowledge of SIM swap attacks, but did not realize that their SMS authentication policies were allowing for vulnerable accounts. Paypal, for instance, closed our report as out-of-scope, claiming that “the vulnerability is not in Paypal, as you mentioned this is an issue with the carriers and they need to fix it on their side.While phone number hijackings are the result of poor customer authentication procedures at the carriers, account hijackings resulting from SMS passcode interception are the result of poor authentication policies at websites. The remaining two websites—Taxact and Gaijin Entertainment—misinterpreted our disclosure as a feature request and feedback, respectively.
  • Three of the four reports we submitted to third-party bug bounty programs were disregarded due to the absence of a bug (our findings are not software errors, but rather, logically inconsistent customer authentication policies). Reports are screened by employees of the program, who are independent of the website, and passed on to the website’s security teams if determined to be in scope. These third-party platforms appear to be overly strict with their triage criteria, preventing qualified researchers from communicating with the companies. This issue is not unique to our study, either. A few weeks ago, security researchers also reported difficulties with submitting vulnerability reports to Paypal, which uses HackerOne as its sole security reporting mechanism. HackerOne employs mechanisms that restrict users from submitting future reports after too many closed reports, which could disincentivize users from reporting legitimate vulnerabilities.
  • In five cases, we received no response. 
  • All four attempts to report security vulnerabilities through customer support channels were fruitless: either we received no response or personnel did not understand the issue.   

We have listed all 17 responses in the table below. Unfortunately, nine of these websites use SMS-based MFA and SMS-based password recovery by default and remain so as of this writing. Among them are payment services PayPal and Venmo. The vulnerable websites cumulatively have billions of users. 

Recommendations

We recommend that companies make the following changes to their vulnerability response:

  1. Companies need to realize that policy-related vulnerabilities are very real, and should use threat modeling to detect these. There seems to be a general lack of knowledge about vulnerabilities arising from weak authentication policies.
  2. Companies should provide direct contact methods for security reporting procedures. A bug bounty program is not a substitute for a robust security reporting mechanism, yet some companies are using it as such. Furthermore, customer support channels—whose personnel are unlikely to be trained to respond to security vulnerability disclosures—add a level of indirection and can lead to vulnerability reports being forwarded to inappropriate teams.  

Our paper, along with our dataset, is located at issms2fasecure.com.

Thanks to Malte Möser for providing comments on a draft.

HOWTO: Protect your small organization against electronic adversaries

October is “cyber security awareness month“. Among other notable announcements, Google just rolled out “advanced protection” — free for any Google account. So, in the spirit of offering pragmatic advice to real users, I wrote a short document that’s meant not for the usual Tinker audience but rather for the sort of person running a small non-profit, a political campaign, or even a small company.

If there’s one thing we learned from the leaks of the DNC emails during the 2016 presidential campaign it’s this: cyber-security matters. Whether or not you believe that the release of private campaign emails cost Clinton the election, they certainly influenced the process to the extent that any political campaign, any small non-profit, and any advocacy group has to now consider the possible impacts of cyber-attacks against their organizations. These could involve espionage (i.e., internal secrets being leaked) or sabotage (i.e., internal data being corrupted or destroyed). And your adversaries might be criminal hackers or foreign nation-state governments.

If you were a large multinational corporation, you’d have a dedicated team of security specialists to manage your organization. Unfortunately, you’re not and you can’t afford such a team. To help out, I’ve written a short document summarizing low-cost tactics you can take to reduce your vulnerabilities using simple techniques like two-factor authentication, so a stolen password isn’t enough for an attacker to log into your account. This document also recommends particular software and hardware configurations that move your organization “into the cloud” where providers like Google or Microsoft have security professionals who do much of the hard work on your behalf.

Enjoy!

https://www.cs.rice.edu/~dwallach/howto-electronic-adversaries.pdf

No Facebook, No Service?

The Idaho Statesman, my sort-of-local newspaper, just announced that it will follow the lead of the Miami Herald and no longer allow readers to post anonymous comments to online stories. Starting September 15, readers who want to make comments will have to login through Facebook. This is the second time I’ve encountered a mandatory Facebook login for users trying to gain access to a third-party service. The first time was when I tried to sign up last year for the music streaming service Spotify. (Spotify now allows users to create an account using an email address, but it didn’t always.)  I’m not a Facebook fan for reasons related to Facebook’s privacy and information practices, but that’s really neither here nor there. The question is whether I should have to be a Facebook user to access services on the Internet that have no natural or necessary connection to Facebook. I’m not talking here about giving users the option to login through Facebook if they want to share their online activities with Facebook friends. I’m talking about conditioning access to a non-Facebook service, or to some aspect of that service, on a user’s having a Facebook account. Internet users are accustomed to dealing with lots of intermediaries, from broadband providers to search engines, to get access to services and information. The Internet is all about mediated transfers of information. I get that. But this strikes me as a troubling new layer of intermediation.

[Read more…]