At leas it wasn't Pasw0rd.
We're not saying this is how SolarWinds was backdoored, but its FTP password 'leaked on GitHub in plaintext'
SolarWinds, the maker of the Orion network management software that was subverted to distribute backdoored updates that led to the compromise of multiple US government bodies, was apparently told last year that credentials for its software update server had been exposed in a public GitHub repo. Vinoth Kumar, a security …
COMMENTS
-
-
-
Thursday 17th December 2020 17:30 GMT bombastic bob
Re: Pasw0rd?? Who would use that, that's foolish!
yeah, using l33t5p34k to encode your favorite word makes it SO much more secure... </snark>
(although I admit doing that when certain password verifiers won't let me do something more secure and easier to remember like an equivalent of 'correcthorsebatterystaple' and then confuse you when you have to use 3 of 4 different things, and if you use all 4, it rejects it...)
-
-
-
Wednesday 16th December 2020 08:42 GMT Hubert Cumberdale
Re: Hmmmm
I thought we already knew his password.
-
-
Thursday 17th December 2020 17:33 GMT Snake
Re: if true...
It's more absolutely, gross-level stupidity.
Why was a server of outbound software granting write access to FTP clients? Why??!!
Basic security protocols would tell you that public access = read only. If World+dog needs write access then you do so in a separate directory, from which submissions can be vetted prior to integration to distribution. You don't go making a server read/write on the same resource.
...
I seriously wonder about the "skill", "knowledge" and "intelligence" of IT people who thought of, and especially OK'ed, this setup. Really. I *thought* you went through higher education...but apparently I was very, very wrong.
-
Friday 18th December 2020 08:28 GMT Jonathan Richards 1
Re: if true...
Violent agreement. Apparently nobody looks at these complex systems in the round. The fact that this is a penetration testing organization makes me think that they don't eat their own dog-food, as they say.
I'd go further than a separate directory. In the situation where a design review has decided that there has to be weak authentication on uploads, the inbound server should be a physically separate machine on a physically separate network.
-
-
-
Wednesday 16th December 2020 11:39 GMT Pascal Monett
That article does not make clear how the data was accessed. Of course, obtaining personal, intimate data on up to 14 million government workers is very much a bad thing, but there is nothing that says that an FTP password was at fault.
Solarwinds can explain all it wants, the fact that it has rubbish password security is now established and that is a stain that is not going to go away quickly for a company that is supposed to deal in Internet security and network monitoring.
-
-
-
-
-
Wednesday 16th December 2020 18:04 GMT Michael Wojcik
Re: It's OK...
Exactly. Typical software product supply chains have a lot of potential points of vulnerability. Developer machines, source-code repositories, CI, staging, build machines, artifact repositories, signing servers, private-key backups... Good separation of concerns can plug some of the holes (don't keep production signing keys on developer machines!), but the links between them can introduce new ones.
Even if you follow the sorts of practices that the CA/BF's Code Signing Research Group was trying to push a few years back - requiring a FIPS 1040-2 Level 2 HSM to do the actual signing, for example - and follow reasonable practices like requiring mutual authentication and data integrity between production build machines and signing servers, it's really hard to lock attackers out of that process flow once they get access to the internal network. That's one reason why zero-trust corporate systems are a hot topic these days.
Against that, though, you have to ensure developers can do their jobs and automated integration-build-test systems can do theirs. It's not an easy problem.
-
-
Thursday 17th December 2020 19:52 GMT jtaylor
Re: It's OK...
all you have to do is download and verify your own software to spot a hack like this. Stopping might be hard(ish) but detecting it is not.
Detect what? If you look for anomalous behavior, you can detect active malware. You won't detect a backdoor that's waiting passively to receive a trigger. You won't detect malware that deactivates if it detects it's running in a VM.
Of course, you could just compare cryptographic hashes against those from your parallel build environment that pulls known-good source code and builds it in a trusted environment. But then, if you have that known good trusted toolchain, why didn't you use that to build the release in the first place?
-
-
Friday 18th December 2020 08:43 GMT Jonathan Richards 1
Re: It's OK...
> you have to ensure developers can do their jobs and automated integration-build-test systems can do theirs. It's not an easy problem.
Once again, Einstein's maxim has it. A solution should be as simple as possible, but no simpler. [1] If the enablement of development, integration, etc. to make a sleek supply chain results in a weakened chain, then the simplification has gone too far, and the IS architecture simply has to sacrifice some efficiency for increased effectiveness.
[1] Apparently, Einstein never used these exact words, but wrote something very like it when talking about principles of theoretical physics.
-
-
Thursday 17th December 2020 11:43 GMT Anonymous Coward
Re: It's OK...
But...my assumption is that this isn't the build server and is part of the hack (i.e. the ability to write anything you want to a "trusted" software update server likely evades firewall rules and simple content inspection) but doesn't allow you to produce a signed executable with your embedded payload. That would take additional access.
It's an update server with a questionable configuration (i.e. allowing a general purpose user to upload content into software dstribution folders) and it reinforces many of my concerns about Internet accessible FTP servers (they are largely abandonware from an operational perspective and any configuration errors are either ignored or not well understood).
It's not clear the Github repository is a Solarwinds employee or from someone who had compromised Solarwinds and shared example code for other reasons.
-
-
-
-
Wednesday 16th December 2020 08:21 GMT Phil O'Sophical
Re: That's the sort of password
I'd guess it was one of those situations where one developer puts a simple password into some internal test code, assuming that no-one would be daft enough to want to share it, and then some other developer decides to share the test code, assuming that no-one would be daft enough to hard-code a password in it.
-
Thursday 17th December 2020 11:50 GMT Anonymous Coward
Re: That's the sort of password
It's likely to have been an account that allowed existing Soalrwinds deployments to check for updates.
Not great, but a common solution in the mid-00's to keep the world+dog out of your FTP servers but not any real security. Post-2010 it should have been replaced by a more robust system.
Unless you're suggesting Solarwinds was having developers build and upload code directly to the FTP servers with code repositories/build processes/code signing left to individual developers to do as they want? I'm not saying its not possible BUT....
-
-
This post has been deleted by its author
-
-
Wednesday 16th December 2020 06:59 GMT sanmigueelbeer
GE puts default password in radiology devices
GE puts default password in radiology devices
The update and maintenance software authenticates connections by using credentials that are publicly exposed (can be found online) and does so periodically with GE’s online maintenance servers.
The credentials can only be updated by the GE Healthcare Support team. If not updated through a customer request - credentials are left default.
Makes me laugh
sometimeshow large corporations simply do not take this seriously.-
Wednesday 16th December 2020 22:17 GMT DevOpsTimothyC
Re: GE puts default password in radiology devices
Well this one has hit a number of gov agencies so hopefully it makes a country introduce a law that makes the CEO personally accountable (with jail time for computer hacking type offences).
I imaging that many of these problems would go away very quickly with many CEO's taking a paranoid level of care around security.
-
-
Wednesday 16th December 2020 08:40 GMT chivo243
I had to assist a user who would be taking a computer home with the vpn connection. I used my phone for a temporary hotspot to test. I thought i made an easy password 12345678 I kept trying to connect the computer to my hotspot and it failed. I checked the hotspot password again, I fat fingered 12345679 SolarWinds maybe the password should have been SolarWinds124
-
Wednesday 16th December 2020 14:31 GMT c1ue
Yet another example of the utter bollocks of "sophisticated, patient nation-state spies" - as opposed to the reality of semi- and in-competent IT setups.
What is abundantly clear is not that the "bad guys" are skilled, it is that their targets are not.
This is pure "security by obscurity" gone bad...
-
Wednesday 16th December 2020 20:54 GMT tcmonkey
NaTiOn sTaTe AtAcKeRs!1!1!!one!!!
I’m not sure where companies are getting the idea that their products are so secure that only a government assisted outfit can break into them, but as this post shows it’s clearly absolute horseshit in some/most cases. How about the next time they think about drumming up fear and loathing of an entire country they actually provide some evidence of that claim?
‘Allegedly’ is not worth the paper it’s written on.
-
Thursday 17th December 2020 19:49 GMT Anonymous Coward
At 13 characters length, with a mix of alphabetic and numeric characters, the password was actually a fairly strong one. According to the "How Big Is Your Haysstack?" calculator at the Gibson Research site, it could take decades to centuries to guess a password of this length. Posting it as plaintext in a public place was, well — stupid.