Hackers used SolarWinds' dominance against it in sprawling spy campaign
in.reuters.com
in.reuters.com
Titles are by far the biggest influence on threads. As a result of this title, this thread is a shallow, frothy rantfest.
The site guidelines say "Please use the original title, unless it is misleading or linkbait; don't editorialize." Cherry-picking a detail is editorializing, getting it wrong is misleading, and getting it wrong by making it more sensational is linkbait, for the trifecta.
Submitters: please don't do that. If you want to say what you think is important about an article, please do so in the comments. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
Or too long and needs shortening. In these cases, what, if there is one, is the preferred way to shorten titles? Truncate or attempt to rewrite to shorten without editorializing?
In cases where there isn't a natural way to truncate, a better option is to look at the HTML doc title, a subtitle, a heading, or sometimes even a photo caption, that say accurately and neutrally what the article is about. There's often also a sentence in the opening paragraph that can be used. Sometimes none of those exists, but you can find a representative phrase lurking in the article body. The key is that it be representative though, not cherry-picked. There's a bit of interpretation involved there, but you can nearly always pick out the general-overview phrase if one exists. They have a distinctive quality.
Rewriting should only be a last resort. When we edit titles, we always try to use representative language from the article and rather than to make up language ourselves.
And you're dense enough to give these guys a second chance
Then you should just fire your engineers and base your entire life out of the Gartner trade rag magic quadrants.
While these credentials let you push things to the download servers, the actual malware was inserted much earlier during the build process before the code was signed.
Seems to work pretty well for a lot of the CIO/CTO level people who I have worked with.
Unfortunately.
If the status quo were more justifiable their actual job responsibilities to other people within the organization ( conflict resolution, scheduling, resource allocation, and personnel management) are things that could be automated in a hot minute.
You just described the CIO of a billion dollar revenue NYSE traded company I was with briefly a few years back. The CIO had no degree and thought the Gartner organization could do no wrong, so they were his guide and trusted confidant. It was a nightmare, a total disaster. Everyone in IT there were so used to constant chaos no one seemed to notice or mind. Yikes.
For what it's worth.
Burglar 2: "Key's under the doormat"
These people are supposed to be security professionals.
A few years ago I complained to the DD-WRT developers that they need to serve up with firmware images on HTTPS (They were serving them up on HTTP). Their images are not cryptographically signed and they didn't publish hashes so at the very least they could try to secure the transport and use HTTPS. My request was rejected and they were confused as to why HTTPS was necessary as "it's not like we're doing online banking".
- Access Rights Manager: Manage and audit access rights across your IT infrastructure
- Security Event Manager - Improve your security posture and quickly demonstrate compliance with an easy-to-use, affordable SIEM tool
- Server Configuration Monitor - Gain visibility into systems changes and easily compare configurations over time with our new change monitoring tool
- Patch Manager - Patch management software designed to quickly address software vulnerabilities
- Serv-U Managed File Transfer Server - Enhance security and control over file transfers in and outside your organization
- Serv-U File Transfer Protocol Server - Simple, affordable, easy-to-use FTP server software
While I wouldn't call all of these security sensitive, but considering some of the other tools that they built:
- Dameware Remote Support: Remote control and systems management tools in one easy-to-use package
- Dameware Remote Everywhere: Deliver the tools IT professionals need in a cloud-based, remote support solution
- User Device Tracker: Network device tracking software designed to locate users and devices on your network
they definitely count as a security-sensitive vendor.
If this is the case, then why is Russia so definitively portrayed as the culprit in so many publications, currently?
Much easier to simply hide who you are by changing your compromise fingerprint than to try to impersonate someone else's compromise fingerprint.
If a technique is seen in this attack that has been seen in previous attacks which are now known to be by a russia-sponsored group, that is very strong evidence that the same group is responsible. It is not proof, but it is strong evidence.
Given the fact that attribution is so difficult that we haven't seen any lawsuits yet, I'd imagine that entirlely suppressing your own methods if you know what the investigator is expecting from someone else as well as what the methods of others are is feasible.
American media loves their heroes and villains narratives, and the characters change depending on what is convenient. Even if Russia was responsible, would you believe them after all the other times they cried wolf?
It's like getting a new, untrained puppy; it's one of those cases where, you walk into a dark room the puppy was in for a little while. You can smell it, and you're more than likely correct what it's coming from, you just can't see it so you can't really prove, yet, that there is shit somewhere... until you turn the lights on.
Attackers also leave breadcrumbs behind; fingerprints, in a way. Sometimes the actions taken are the fingerprint, sometimes the effort to cover up those actions is the fingerprint.
If I am an investigator and I see trademark actions or cleanup that I've seen before in a russia-sponsored attack, it is not a huge leap to strongly suspect I am investigating a russia-sponsored attack.
Like how North Korea is largely seen as responsible for hacking Sony. If you paint a big enough arrow, people will follow it.
Hackers used SolarWinds' dominance against it in sprawling spy campaign
Not to dismiss the point of the editorialised title here ("SolarWinds use the password 'solarwinds123' on their Update Servers") but note:
Neither the password nor the stolen access is considered the most likely source of the current intrusion, researchers said
I'd argue that it's very relevant; if they were making such terrible decisions a year ago, what else did they do wrong between then and the hack? I am reluctant to assume that they didn't make other mistakes, given how obvious this password flub was.
I heard it's not uncommon that multiple adversaries sometimes poke around the same systems, even fight each other to maintain access.
Does this mean the job listing was posted before this incident gone public?
He noticed whenever there is a spike in open security positions a breach is soon announced or was just announced recently.
Or maybe a few years ago some security genius mandated a weekly password change and they had just made it to week 123.
Not legally binding in the contiguous United States.
No qualified professional should think 'solarwinds123' is an acceptable password, especially in a production environment!
Not much left of them trying to lie their way out of this shambles.
2. The weak password wasn't how they were hacked
3. Solar winds was just the vector, the actual payloads were targeted and advanced.
Their insecure password may be disappointing but it's not relevant to the much more important story about who used them to compromise very sophisticated targets.
Wow.
grep -e '[a-zA-Z]\{4,\}$' /etc/dictionaries-common/words | shuf | head -n 4
I have yet to be in an organization that hasn’t defaulted to something quite unwise simply because trying to maintain the institutional knowledge of that password is otherwise difficult.
Mostly – don’t. Every user that has access to a system should have their own credentials. There’s no reason for an update server to be set up this way.
Or, you sign a key/certificate for each user, add MFA
Or, you create a complex password for each user, and add MFA
Or you create a complex password, shared in a keystore that handles checkout and rotation
Worst case, if you're lazy, you create a complex password for a handful of your teammates and reset it when a team member leaves
Or if you're solarwinds, you apparently choose gross negligence
[0] https://www.yubico.com/resources/glossary/static-password/
The answer is typically “never share accounts” and therefore never share passwords.
I wouldn’t the surprised if “do not share credentials” is explicitly stated in solarwinds internal security policies.
Beyond the challenge of sharing strong passwords, there’s also the (important from compliance perspective) issue of losing the ability to audit who took what action if multiple people use the same credentials.
- Using a password manager where there is audit logging that is reviewed and the access to the passwords is segregated to those who need it - Using a privileged access monitoring tool such as CyberArk - Simply creating separate named privileged accounts for each person to use is the best alternative
We've moved to identity + role based access control, but some older core pieces still used the shared password.
We simply have a portal that authenticated users can log into it, and see the current password which is rotated monthly, with a random selection from a series of dictionary words. (which can occasionally produce giggleworthy combinations)
But as the sibling comment says; the right way is to get rid of it entirely.
Never had a need for anything SolarWinds provides, and we have tons of stuff in PCI-DSS environments...
They're a networking company but they apparently build stuff like it's still 1996.
Never needed SolarWinds, and we'll definitely never entertain them now.
https://www.networkmanagementsoftware.com/wp-content/uploads...
These kinds of passwords are all over the place. Cisco uses a simple variation of c!sco123 for a lot of it’s managed gear which is a documented default that doesn’t get changed.