Supply-side Vulnerabilities

In This Issue:

  • Supply chain compromises on the rise
  • ‘Known leaked’ passwords
  • Not Thor's hammer: administrative stupidity

Supply Chain Compromises on the Rise

There are two big infosec gotchas to look out for that rarely get talked about in the average IT department: supply chain attacks, and dependency management. These are interrelated concepts, and they're really, really hard to get a handle on.
Supply chain attacks are what they sound like: the compromise of an upstream supplier compromises your organization. Supply chain attacks can come in the form of someone compromising a supplier's data centers, and then crawling into yours via IT integration between your organizations, or it can come in the form of compromising software that you use.
Where supply chain attacks and dependency management overlap is also one of the easiest ways to compromise the software you use—the open source libraries, or other software bits that the software you use depends on. This latter approach is becoming something of a problem: The year-long rash of supply chain attacks against open source is getting worse.
In fact, dependency attacks are reaching out beyond compromising individual applications, and are heading toward compromising popular development frameworks. This was seen in the PHP world several times, but it's occurring more frequently with other popular languages as well: No REST for the wicked: Ruby gem hacked to siphon passwords, secrets from web devs.
The moral of the story is "don't trust anyone." Even signed software can be compromised if the source code, or one of its upstream dependencies, was compromised. Any software install, any update—even ones from the developer of an application you trust—can be compromised. And it's happening more and more frequently.


Assume compromise. We cannot stress this enough. Design your data center such that you assume that any application, any system, any device can be compromised at any time. Do automated baselining to determine what "normal" for your applications and devices looks like. Have a robot sit on the wire and freak out if things leave the error bars you've established for "normal." Automatically quarantine infected systems. Build everything to be composable, so that if anything behaves even a little bit wonky, you can nuke it from orbit and reinstantitate from a “known good” state.

Read More >

‘Known Leaked’ Passwords

If you've been spending any time at all on the Internet lately, you have may have noticed a trend among the larger, better-secured websites. This trend is to check any password you attempt to set—and, increasingly, any password you enter as it’s entered—against the list of "known leaked passwords."
Websites, and hopefully, one day, installable software, do this to help people avoid having their accounts compromised through some of the most common and easily-exploitable types of attack. One of the most important categories of vulnerability that this practice is meant to defend against is password reuse.
For some, the practice of checking your password against lists of known passwords might be concerning. Doesn't this mean that the site in question is seeing the password you're typing? Maybe even storing it in plain text? Not necessarily: Forced Password Reset? Check Your Assumptions. Done properly, it’s possible to run these kinds of checks without compromising your security.
The most important takeaway from the increased use of this practice, however, is that password reuse is becoming a very real, very tangible threat. It’s forcing the world's biggest companies to invest very real money in trying to mitigate the threat.
It should also be pointed out that password reuse, especially when combined with a lack of two-factor authentication (2FA), is the most common means by which developer accounts are compromised. This is often how the source code of upstream libraries is compromised, leading to cascade supply chain compromises.


The use of password managers, and the education to use them effectively, should be mandatory in your organization. Multi-factor authentication should be encouraged wherever possible, and be absolutely mandatory for all developer accounts, administrative accounts, and finance-related accounts. No ponies or plastic rockets required; this stuff is actually easy by now. So go forth and do it.

Read More >

Administrative Stupidity: Not Thor's Hammer

The domain administrator checkbox isn't Mjolnir. Administrative credentials can, in fact, be wielded by those who are completely unworthy. And the unworthy include people who infosec all the things. Consider, for a moment, this article: Top tip: Don't upload your confidential biz files to free malware-scanning websites – everything is public.
To be honest, we're kind of at a loss for words on that one.
Instead, we'd like to direct your attention to this: Who Gets Privileged Access & How to Enforce It. Administrative capabilities need not be binary. You don't need to give all six infinity stones to the fellow in the corner who's green as grass, or the individual at the back of the data center who doesn't quite "get" the Perpetual Paranoia that should be a way of life for anyone working in our field.
This is normally where we would go on a good tear about "insider threats" and so forth, but the bigger issue here is a bit more nuanced. In our experience, mistakes along the lines of "I uploaded that directory of super-tip-top-secret files to VirusTotal" happen because the individual in question doesn't really understand how that service works. They want to do the right thing, like checking the files for malware, but they're basically just following some steps they found on a forum somewhere, without actually understanding what they're doing.


Burning out your admins and/or not giving your admins enough time or incentives to become educated on the tools of their trade is a security risk. Like anything else in your data center, you need to monitor the health and load of your administrators. You need to add administrators when load gets too high. You need to be constantly training them, and refreshing their existing training. If you don't do this, you’re introducing vulnerabilities. Don't make the people with deity-level account access into vulnerabilities. Do not do.

Read More >

Facepalm of the Week

Repeat after us: if your data doesn't exist in at least two places, then it does not exist. Go verify your backups are working right now.

Video of the Week


Podcast of the Week

Smashing Security is back for another mention this week, as the podcast continues to be one of the most engaging in infosec this summer.

Thread of the Week

Time to remind folks what Coordinated Vulnerability Disclosure is all about, since both the affected vendor & the bug bounty platform in this disclosure debacle are incapable of doing so.
Buckle up, kids. The co-author of the vuln disclosure ISO standards has a thread for you. - Katie Moussouris - @k8em0

Quick Links


Get Your Copy.