4 ms·
tl;dr: thegrugq argues that it's possible for SolarWinds' security to have been inadequate, yet that security posture to have made no difference in whether they
by troydavis 6y ago
tl;dr: thegrugq argues that it's possible for SolarWinds' security to have been inadequate, yet that security posture to have made no difference in whether they were hacked by the SVR.
thegrugq argues it's very likely:
> I’m perfectly willing to believe that their build servers were using “admin:admin” and that’s how the Russians gained access to inject their code… but, this was a clandestine intelligence operation. They did not succeed merely because SolarWind had poor password hygiene.
- dilyevsky 6y agoNonsense argument. What’s the point of securing anything if THE KGB can cast a hack spell and get root on my server?
- sydd 6y agoNo, read the article. What can they do if someone from KGB will apply to a junior dev position and get the job? They will hand them all their keys.
- tptacek 6y agoAnd there are teams, a very few of them large, where internal segmentation is strong enough to survive a compromised developer machine. But that's an extraordinarily high bar to clear and very few companies, even those with strong security teams, really manage to clear it.
- dilyevsky 6y agoI’ve been hearing this argument for over 10 years now about nsa, idf, china and now the kgb. The truth is internal audits are quite effective at catching these. If nsa could just place a plant why did they spend so much effort to tap into companies’ inter-dc fibers?
- ukj 6y agoIt's not an XOR.
- benlivengood 6y agoBecause mass surveillance is useful to identify targets and moles are useful to dig up the rest of the information on targets.
- blincoln 6y agoI have mixed feelings about this. I agree with him that if the SVR specifically targeted a particular organization with a specific goal in mind, it wouldn't really matter if they had weak passwords or not. OTOH, I think it's not out of the question that one or more organizations (intelligence agencies, criminals, etc.) found the password and took advantage of it more as a "let's see where this thread leads" type of opportunistic attack, and all of the downstream consequences only happened because of that. I've never worked for an intelligence agency, but I've been a professional penetration tester for about a decade, and when I go after an organization, that's typically my approach: find the weakest links and start following them to see where they go. In a complex environment, usually that leads to control over everything sooner or later. Edit: just to clarify that last paragraph, what I'm getting at is that if I imagine myself in the shoes of an intelligence agency, the "organizations" I'd be going after would be foreign countries. I'm sure in some cases it would make sense to go after specific businesses of interest, but in the absence of legal restrictions, I'd be looking for the weakest links in entire industries that supported those countries in some way, not necessarily picking a specific business and targeting them. There are quite a few companies out there that make systems monitoring and administration software that would provide similar levels of access to a wide range of organizations if their build chains were compromised. The one that was compromised was the one that also had a publicly-exposed update server with a password that could have been obtained in at least two different ways.[1] Coincidence? Perhaps, but I don't think it's fair to just take it off the table. [1] Accidentally exposed in a public GitHub repo for many months, as well as being easily guessed. Either alone would have been enough. Both being true seems to me to make it more likely.
- troydavis 6y agoI think that's a good summary. Also, it's easy to imagine the SVR poking at all companies which sell high-trust applications[1] to many government agencies, and running with the ones[2] that worked. Regarding whether the password thing was a coincidence, I wouldn't be surprised that, if other large enterprise software companies were severely hacked, similar stories surfaced. That doesn't mean it's a coincidence, of course, but may mean that this is average among enterprise software companies. One takeaway here is that software companies shipping trusted software to third-party networks have an exposure more like Google or the Federal Reserve, not like other software companies. That's not how (a lot of) the software industry has acted. [1]: NMS, systems management, facilities management, possibly CRM [2]: Where one was detected (because the attackers chose the wrong target in FireEye), others have probably occurred and/or are active now. While this was very sophisticated, it wasn't Stuxnet (https://blog.erratasec.com/2021/02/no-1000-engineers-were-not-needed-for.html https://blog.erratasec.com/2021/02/no-1000-engineers-were-no...).
- a1369209993 6y agoNot quite. Rather, they argue that it's theoretically possible (though not necessarily realistic) to have good enough security to resist targeted hacking by the KGB, but this requires vastly more than just better password hygiene.
- Sebb767 6y ago> it's theoretically possible (though not necessarily realistic) to have good enough security to resist targeted hacking by the KGB It is possible to have a security level where the cost outweighs the benefit. If the KGB really wants to go all out, they could buy employees, burn zero days or even hold sysadmin families hostage - but that would be extremely expensive and risky and they'd really need a big reason to go that far. If your password is "admin" or "solarwinds123", on the other hand, the biggest expense is probably the employee time spent laughing in the coffee room. I agree that it is vastly expensive to have a security level high enough that the KGB realistically can not take over your network, but it's far cheaper and more realistic to have a security level where it's not worth the expense.
- a1369209993 6y ago> I agree that it is vastly expensive to have a security level high enough that the KGB realistically can not take over your network, but it's far cheaper and more realistic to have a security level where it's not worth the expense. Yep. The former is possible in theory but not likely to happen. The latter is somewhat difficult, but ought to be table stakes for any company dealing with security-sensitive anything.