Dropbox reveals hack: What DevOps can learn from it

So what can we learn from others’ misfortune? One obvious lesson: Not all MFA schemes are created equal, so look to FIDO2/WebAuthn. Another is the importance of the curiously named SaaSBOM.

And it goes without saying that you shouldn’t store secrets in GitHub. In this week’s Secure Software Blogwatch, we say it anyway.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: LaMDA in the 1980s.

Get a free SBOM and supply chain risk analysis report

OTP FAIL: FIDO2 FTW

What’s the craic? Sergiu Gatlan reports — “Dropbox discloses breach”:

“Dropbox is working on securing its entire environment”
Threat actors stole 130 code repositories after gaining access to one of its GitHub accounts using employee credentials stolen in a phishing attack. … The company discovered the attackers breached the account on October 14 when GitHub notified it of suspicious activity that started one day before the alert was sent.
…
The successful … phishing attack … targeted multiple Dropbox employees using emails impersonating the CircleCI continuous integration and delivery platform. … On the same phishing page, the employees were also asked to "use their hardware authentication key to pass a One Time Password (OTP)."
…
In September, other GitHub users were also targeted in a similar attack impersonating the CircleCI platform and asking them to sign into their GitHub accounts. … In response to the incident, Dropbox is working on securing its entire environment using WebAuthn and hardware tokens or biometric factors.

MFA vulnerable to phishing? David Perera counts the ways — “Another Multifactor Fail”:

“Stealing credentials in real time”

Add DropBox to the list of tech companies experiencing a multifactor fail moment. … Employees fell for a well-crafted phishing campaign that gave hackers access to internal code repositories and some personally identifying information.

…

Acknowledgment of the hack comes after multiple Silicon Valley firms have recently found their internal security not as hacker-proof as once thought. Security experts have long recommended multifactor authentication as protection against hackers. [But] threat actors are adjusting up uptake of that advice by pivoting to stealing credentials in real time, along with one-time authentication codes. … So it was with Dropbox.

Ooops. The Dropbox Security Team puts a brave face on it — “How we handled a recent phishing incident”:

“Accelerating our adoption of WebAuthn”

In today's evolving threat landscape, people are inundated with messages and notifications, making phishing lures hard to detect. Threat actors have moved beyond simply harvesting usernames and passwords, to harvesting multi-factor authentication codes as well. … Even the most skeptical, vigilant professional can fall prey to a carefully crafted message delivered in the right way at the right time.

…

The code accessed [from GitHub] contained some credentials—primarily, API keys—used by Dropbox developers. … Our security teams took immediate action to coordinate the rotation of all exposed developer credentials.

…

While the information accessed by this threat actor was limited, we hold ourselves to a higher standard. We're sorry we fell short, and apologize for any inconvenience. One way we hope to prevent a similar incident from occurring is by accelerating our adoption of WebAuthn [which] is currently the gold standard. … Soon, our whole environment will be secured by WebAuthn with hardware tokens or biometric factors.

What lessons are there for DevOps? aborsy cuts to the chase:

Why do these large cloud companies with thousands of employees have a work environment that is susceptible to basic attack techniques, such as phishing? It doesn’t instill confidence in the rest of their infrastructure.

Great motivation, but some specifics would be nice. Training is always one suggestion, however u/richhaynes ain’t a fan:

A company I worked for had a breach because someone revealed their credentials. So after the mandatory training for all employees … I ran a phishing campaign to test that it had been effective.

…

The results were horrifying: About 20% gave valid credentials. Worse still was that about 70% of employees didn't even scroll down the page to see the text in an image that said, "This is a fake site and you are being phished."

…

When I presented the results to the C-suite, one admitted to giving credentials and everyone of them said they didn't see the image. I didn't stay much longer.

How well did Dropbox handle it? Steve Gibson poaches a curate’s egg — “Something for Everyone”:

“Downstream damage”
I think they handled it pretty well. But there are some lessons to be had. [It’s] yet another instance of a major security-savvy and network-savvy organization being successfully attacked and breached — even in the face of knowing that this is going on.

Their email filters … failed just enough to allow bogus phishing attacks to reach their employees. And notice that these were code developers — not, for example, less sophisticated clerical … workers.
…
The more complex an organization's setup is — which is to say that the greater the number of ancillary services an organization employs — the greater is their “phishing email attack surface.” The modern trend is products as managed services, where companies are increasingly contracting out for an increasing number of [SaaS] services rather than rolling their own in-house. … Sounds great, but recall all of the downstream damage that the breach at SolarWinds created. … And also remember all of those dental offices and hospital services that were hit with crippling ransomware when their [SaaS] was breached?

A great point. And one that John P. Mello Jr. expands upon — “SaaSBOM … SBOMs in the SaaS era”:

“Stiff headwinds”

Software bills of materials (SBOMs) have become a hot topic. [But] how can SBOMs be developed for vendor-managed deployment models, such as … SaaS? … Here are five reasons why your organization should consider a SaaSBOM:

…

SaaSBOMs provide fresh information about apps running in the cloud. … SaaSBOMs make service components more transparent to users. … SaaSBOMs help security teams understand all dependencies — not just libraries. … SaaSBOMs add another level of software security assurance for vendors. … SaaSBOMs will become a requirement in the software industry.

…

There are those, however, who believe SaaSBOM proliferation faces stiff headwinds. The frequency at which components change in a SaaSBOM is a challenge and might even change from customer to customer. … Some questions need to be answered before software publishers take on the massive engineering overhead needed to maintain SaaSBOMs.

Returning to the MFA question, u/Necessary_Roof_9475 feels like a broken record:

This is once again why I will keep saying that 2FA is not "hack" proof. I'm blown away … by how many people think because they have 2FA they can't be phished or "hacked." People need to stop thinking 2FA is some magic cure.

But sdfhbdf challenges the response: [You’re fired—Ed.]

Using a hardware key like Yubikey would prevent such attack since the challenge-response in the browser communication with the key contains the domain (which I assume was different) and hence would fail to generate proper OTP. … I assume they, or their vendor, CircleCI … had some older implementation … that maybe relied just on the string generated … without challenge-response.

…

WebAuthn [is] a good successor. This should definitely prevent such attack vector

Meanwhile, u/Goatlens eyerolls furiously:

Imagine that. Large company doesn’t proactively protect their network and instead reactively takes action once they’re ****ed.

And Finally:

Alternate AI history

Previously in And finally

You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or ssbw@richi.uk. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: Jun Ohwada (cc:by; leveled and cropped)