Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

2/19/2020
02:00 PM
Nick Selby
Nick Selby
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
100%
0%

Zero-Factor Authentication: Owning Our Data

Are you asking the right questions to determine how well your vendors will protect your data? Probably not.

Let's say you own a small business, and you want to get a payroll service to help with withholding taxes and automatic deposits into your employees' accounts. That's a very useful, powerful service: You're giving a third party the right to withdraw funds from your bank account and send them to others. 

Being switched on to security, you'd look for a payroll company that supports multifactor authentication (MFA) based on a time-based one-time password (TOTP) application, knowing that SMS-based two-step login is effectively (in the words of Allison Nixon and Mark D. Rasch at Unit 221B Research) zero-factor authentication.

The trouble is, as of about three weeks ago, none of the major online payroll companies offered this feature. If you ask those companies, they'll say they offer SMS-based two-step login and then assure you they take security seriously. 

I found one firm that does support application-based MFA: I'll call it Payroll Company B. PCB isn't a payroll company as much as a professional employer organization, but still, it does payroll — for twice the price of the others I just mentioned. 

Anyway, you sign up. And after you go through the rigamarole to get the TOTP application working, if you're attentive, you may discover a seedy backdoor: If you were to forget the Web front end,call PCB's toll-free support number, and tell the company you need to make an account change, the entire authentication regime falls apart with these dreaded words:

"For security purposes, please tell me your full name and the last four digits of your Social Security number."

Yes, it verifies your identity by asking you for public information. Once provided, no further authentication is required, and you can request a password change, or the removal of TOTP-based MFA, or, presumably, to send Bob's paycheck to Alice. You're in.

And you're root because it has verified your identity. After all, who else could possibly know your full name and last four digits of your Social Security number?  

Who indeed?

Without installing, for example, a proper and secure multifactor, telephone-voice-based authenticator capability, these companies are left to improvise methods to hack together a security story to offer to security-conscious customers. After I discovered its glaring password reset vulnerability, I spoke with a helpful PCB supervisor and asked him to disable phone support. He cheerfully (and genuinely) promised to do so, saying he put a note in my account. I waited two weeks, phoned back, authenticated with a different rep using just my name and last four digits of my SSN, then asked the rep to close my account. In the company's failure to fix the problem, it made liars out of dedicated and creative support staff.

Forget Password Policy. What's Your Password Reset Policy? 
This vulnerability is so mind-thwackingly obvious that I cannot believe I need to say this, but it also raises an important issue that is relatively unaddressed by my colleagues in the financial services world: When we do vendor onboarding and qualify the vendor's security policies, are we asking the right questions? 

Or are we sending them a 120-question spreadsheet containing lots of questions about firewall rules and antivirus? As a friend who is a very high-ranking financial services security leader said to me the other day, "Oh, that doesn't happen. I've never sent a spreadsheet like that in the last week … "

This is not a theoretical issue. Recently, there was an attack that worked like this: The attackers had an in at a national mobile carrier and SIM-swapped the phones of some people in a targeted industry. They then used the pirated mobile numbers to call a firm that specializes in outsourced services to that industry, claimed to be the SIM-swapped employees, and requested — verbally —  password resets. That worked, as it would have worked at PCB.

This was an attack against a third party that for many firms would have bypassed entirely the security monitoring they have in place to defend their assets. The phone was swapped at the carrier, and the password reset was done at a third party, which also set up the fraudulent transactions when the crooks logged in to that service. The firms that didn't fall victim to this last phase were those that did transaction anomaly detection fast enough to understand the transaction was weird. 

Would your firm have caught it? More importantly, would your vendor procurement process and onboarding have asked the question, "Do you allow password resets via voice call?" 

Many companies don't ask the question. I spoke with colleagues at household names in the financial services space, and many firms are struggling to catch up.

What is clear is that we are all trusting cloud-based companies more often, if not exclusively, to handle those parts of the business we seek to outsource. Looking at the standard questionnaires, I see a lot of question-types missing. 

For example, rather than asking lots of questions about endpoint antivirus or whether the vendor's facility is in a location with little to no risk of natural disaster, terrorism, or civil unrest, it might be good to ask whether the vendor has separate production and nonproduction environments, or how their admins and developers access the environments, or how customer password resets are done.

In other words, we need to ask questions designed to understand the ways someone could subvert the vendor's authentication and access control regime. 

I'll be speaking about some of these things at the RSA Conference 2020 in San Francisco on February 26. I hope you will leave comments here and chat with me there. 

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's featured story: "8 Things Users Do That Make Security Pros Miserable."

Nick Selby is the Chief Security Officer for Paxos Trust Company, which creates contemporary infrastructure to support global institutional financial transaction settlement. Prior to Paxos, Nick served as Director of Cyber Intelligence and Investigations ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
ARossetti216
50%
50%
ARossetti216,
User Rank: Apprentice
2/20/2020 | 12:29:56 PM
Wow...
Amazing that even vendors who claim to offer "great" security have such weaknesses built in.  
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.