[HN Gopher] Not a drill: VMware vuln with 9.8 severity rating is...
___________________________________________________________________
Not a drill: VMware vuln with 9.8 severity rating is under attack
Author : jbonniwell
Score : 321 points
Date : 2021-06-04 20:34 UTC (1 days ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| colonelxc wrote:
| Not even the first preauth VSphere RCE this year:
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2197...
| terminalserver wrote:
| 9.8 out of 10?
|
| What's the .2 represent?
| formerly_proven wrote:
| No access to nuke launch codes
| tyingq wrote:
| There's a calculator like thingy here:
| https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CV...
|
| Down at the "Scope" section there's "changed" and "unchanged".
| If you click on "changed", it goes from 9.8 to 10.0.
| merb wrote:
| why do people putting their vmware vcenter onto the internet?
| Jedd wrote:
| If you're an organisation with vCenter, even if you don't have
| it 'onto the internet' you're far from safe. Your exposure then
| is _merely_ every user and every (other) device on your
| internal network that has routable access to your vCenter.
|
| But yes, exposing highly sensitive tools to a wide,
| untrackable, and frequently hostile audience is not good
| practice.
| croutonwagon wrote:
| This patch was pretty easy to apply too. Didnt even need a
| reboot IIRC
| sp332 wrote:
| And all the remote devices connected by VPN. With everyone
| working from home, that's a pretty high number too.
| 0xbadcafebee wrote:
| Why do people put hospital equipment on the internet? Why do
| people order steak well done? People are stupid.
| taneq wrote:
| Don't steakshame.
| cj wrote:
| Or to put it m0re sanely, people have many priorities.
| Cybersecurity does not rank very highly for many people
| (rightly or wrongly).
| touisteur wrote:
| Some people rightly don't trust their 'butcher' or the meat
| chain of custody _that much_. We eat shredded raw beef meat
| here and even I sometimes wince at the idea...
| tyingq wrote:
| Sadly, it's probably happening more with all the "work from
| home". I imagine lots of Shodan queries for vcenter right now.
| Apparently "intitle:id_vc_welcome" returns vcenter servers on
| Google.
| mschuster91 wrote:
| Even for WFH: just set up a damn openvpn in front of the
| vcenter server, if you don't have the money for a Cisco
| Anyconnect appliance.
|
| It's not _that_ hard, and anyone ignorant enough to expose a
| vCenter to the Internet deserves being shut down. This is
| unacceptably incompetent.
| oarsinsync wrote:
| > Even for WFH: just set up a damn openvpn in front of the
| vcenter server, if you don't have the money for a Cisco
| Anyconnect appliance. It's not that hard
|
| If your business depends on employees that are working
| remotely, and you have critical services behind a VPN, your
| VPN solution is now a critical service too, and should be
| built and managed accordingly.
|
| Just throwing an OpenVPN host up isn't enough. If you're
| going down that road, you need multiple OpenVPN hosts, each
| one "hardened" (since they're internet facing), and a
| mechanism to deploy the VPN clients (and certificates) to
| the users. You then need to do this a second time too for
| an entirely different VPN solution (OpenConnect? WireGuard?
| StrongSWAN?), in case the first one suffers a vulnerability
| that you can't immediately mitigate and instead just needs
| to be shutdown.
|
| Like most technology solutions, this is only trivial to
| resolve if you're operating at a really small scale, all
| your users are tech savvy, and you don't treat it as a
| business critical service.
|
| The moment your business depends on it, it either ceases to
| be trivial, or becomes a large source of operational risk.
| mschuster91 wrote:
| Agreed, but anyone running vCenter on their own is
| _already_ running complex and expensive infrastructure.
|
| There is simply no excuse _at all_ for having it directly
| wired to the Internet. _None_.
| ocdtrekkie wrote:
| FWIW, attackers are also constantly trying to exploit
| vulnerabilities in your AnyConnect appliance...
| perlgeek wrote:
| Lots of hosting companies use vcenter for managing their VMs,
| and if you expose vcenter to your customers, you have a very
| convenient way to have the powercycle VMs, open consoles and
| stuff like that.
|
| And if you expose it to your customers, you either have to
| force them to use a VPN (and support it for even their dumbest
| users), or you expose it on the Internet.
|
| Not great security wise, but the economics do push you into
| that direction.
| fulafel wrote:
| Also, if you look at the vulnerability track record of
| commercial VPN products recently (some mentioned in this
| article even), they aren't necessarily any safer to keep
| publically accessible.
| 2OEH8eoCRo0 wrote:
| I think that if it's possible then people will do it. There are
| so many humans and businesses that it's a certainty.
| nick__m wrote:
| A poc appears to be available there :
| https://github.com/xnianq/cve-2021-21985_exp !
|
| P.s. I use yandex to find CVE POC, google is almost useless for
| that kind of search and yandex almost always deliver working code
| !
| zwp wrote:
| Nice find.
|
| I'm hopefully preaching to the choir here but please beware
| that high-visibility flaws often attract fake PoCs. Malicious
| in the sense "might [also] attack the user" (you!).
|
| Often these will surf on work done by valid PoCs to look
| credible. GitHub was stuffed with them for the Hafnium Exchange
| bug, before Microsoft brought down the ban hammer. (At the time
| there was lots of mewing about "Microsoft protecting their own"
| and "Microsoft killing free speech" but I wonder if they
| weren't also interested in stopping the pwnage from these fake
| exploits, too).
|
| I'm not saying this repo is malicious. This github user looks
| legitimate and doesn't look like the obviously-created-by-a-bot
| profiles I've previously seen. Even so I wouldn't necessarily
| trust ~5000 vendored class files. Play carefully.
| faeyanpiraat wrote:
| This is the reason why I have to stay away from hackintosh
| with their modified kexts.
|
| And have to stay away from pirated games.
|
| A compiled executable from a trustworthy vendor gets a score
| of 1/65 on virustotal? Well, I guess you are running in a
| sandbox..
|
| A legit library has enormous number of lines? Well I'm
| rolling my own (except for crypto, noone should roll their
| own)
|
| I just cannot take the risk anymore.
| alanfranz wrote:
| Vanilla hackintosh with opencore and the right hardware is
| possible.
| gjs278 wrote:
| you're a liar, you don't do that.
| rootsudo wrote:
| Nice on the Yandex info. Thank you :)
| nick__m wrote:
| My pleasure if you use that knowledge for good!
|
| I use those POC to help the infosec team at work when the
| bosses postpone patching. There is nothing like a demo to
| persuade them we must patch now.
| scoopertrooper wrote:
| Github search also often does the trick.
|
| https://github.com/search?q=cve-2021-21985
| gwbas1c wrote:
| I worked briefly at VMware. An exploit like this doesn't surprise
| me one bit.
|
| We had a company mailing list that people used to email jokes
| back and forth all the time.
|
| One rather ignorant programmer put a rule on his email where he
| would get an alert whenever anybody emailed him with a particular
| word in the subject line. That word happened to get into a rather
| popular email thread, and in the middle of the thread we started
| getting complaints from him asking us to change the subject line
| because his pager was beeping off the hook.
|
| Career limiting move! He took a lot of heat for making poor
| assumptions.
| remram wrote:
| I fail see what that anecdote says about the company, even if
| the person you described happened to work there?
| gwbas1c wrote:
| Because vulnerabilites arise from programmers making poor
| assumptions.
| yokaze wrote:
| Yes, but you wrote a story about a single programmer, and
| that he took a lot of heat for that. The doesn't sound
| systemic to me.
| ostenning wrote:
| Nice assumption
| gjs278 wrote:
| this is the stupidest story ive ever read. maybe HN was right
| to make the text fucking impossible to read.
| justusthane wrote:
| If you don't use the vCenter plugins in which the vulnerabilities
| exist (vSAN Health Check, vROPS Manager), it's incredibly easy to
| mitigate this vulnerability by manually marking these plugins as
| incompatible: https://kb.vmware.com/s/article/83829
| [deleted]
| anonymousiam wrote:
| It's safe to say that anybody who exposes VCenter directly to the
| web is practicing poor security. I cannot imagine any scenario
| where this would be required. I manage a few VxRail/vSphere
| clusters and everything is behind firewalls and VPNs.
|
| That said, I understand that this vulnerability basically gives
| root to anyone with VPN access. In our case, pretty much anyone
| who has VPN access to the cluster already has root on it anyway.
| ssakamoto wrote:
| Website in tweet appears to be filled with suspicious malware
| like contents, beware
| hgo wrote:
| Dear arstechnica, please don't write articles like this, where
| you make it seem like curl is somehow related or even the cause:
| "It can be reproduced using five requests from cURL, a command-
| line tool that transfers data using HTTP, HTTPS, IMAP, and other
| common Internet protocols." I find it quite untasteful to somehow
| sneak an plug for curl in here at all.
|
| Thinking of: "I will slaughter you", where Daniel explains how he
| gets death threats from clueless sysadmins that see that they
| have been hacked by someone that used curl.
|
| https://daniel.haxx.se/blog/2021/02/19/i-will-slaughter-you/
|
| Edit: I have e-mailed the author, but someone that use Twitter
| may want to try and reach the author on @dangoodin001. Thank you.
| lallysingh wrote:
| They should've at least mentioned that cURL is reputable. Like
| a "standard" tool. They can cut "common" out of that
| description with no loss.
| tinus_hn wrote:
| I don't think it is proper to try to mobilize people to harass
| a Twitter account.
| SyzygistSix wrote:
| I feel like referring to the person who sent Daniel those
| emails a sysadmin is rather generous.
| ComodoHacker wrote:
| I can't see how it's a "sneak an plug" here. It's just a
| constatation of how easily exploitable the flaw is, using
| common tools like cURL.
|
| If an insecure website can be hacked using only dev tools in
| the browser, does anyone blame browser vendor?
| hgo wrote:
| I guess you're right, but in this context it's clear by
| curl's author's blog post mentioned in my original post, that
| cause can be easily confused by less technically savy
| readers.
| bigyikes wrote:
| I am interested in knowing which readers are technical
| enough to know or care what cURL is, but not technical
| enough to understand that the vulnerability isn't in cURL
| itself.
| ldarby wrote:
| Are you aware of this story:
| https://www.theregister.com/2006/03/24/tuttle_centos/ ?
| lallysingh wrote:
| You can know that cURL is some app, she then give it's
| web pages on the internet.
| [deleted]
| xwolfi wrote:
| You mean absolute morons ? I'm sorry but your little war
| against ars technica will have to wait for an actual
| problem: saying you can exploit a vulnerability with cURL
| has really nothing to do with cURL... I mean who in the
| world woud think "oh then I need to delete cURL"?
|
| Sorry but your disdain for "less technical readers" is
| frankly insulting.
| detaro wrote:
| You consider people sending death threats to developers
| because they think curl is some evil hacking tool not an
| "actual problem", despite it already having happened? We
| sadly share the world with "absolute morons", yes.
|
| (also, how is asking for a change a "war" against the
| publication?)
| TheAdamAndChe wrote:
| Nothing about the article implies cURL is responsible for the
| exploit, only that it can be used to leverage the exploit. It's
| relevant and good to know, and shouldn't be removed IMO.
| vgaldikas wrote:
| I understand that it's nothing to do with curl specifically,
| you understand it, good chunk of HN users do understand it.
| But general public doesn't really
| nkrisc wrote:
| It's strange to mention cURL specifically in this context. If
| the exploit only takes 5 HTTP requests, why not just say "5
| HTTP requests"? Why does the article need to mention cURL at
| all if it's not relevant how those requests are sent? Unless
| cURL is relevant, but that's now how the article is written.
|
| If they're trying to get across to a non-technical audience
| how easy it is, then why mention cURL? They're not going to
| know what cURL is, as evidenced by the explainer following
| immediately. Why not just say, "5 HTTP requests sent by the
| command line"?
| TheAdamAndChe wrote:
| HTTP exploit requests can be pretty complicated, and the
| use of cURL hints that it's a dirt simple exploit to
| leverage.
|
| This is an arstechnica article, their target demographic is
| more technically literate than the lowest common
| denominator.
| oasisbob wrote:
| > HTTP exploit requests can be pretty complicated, and
| the use of cURL hints that it's a dirt simple exploit to
| leverage.
|
| Why would that be? Curl can perform incredibly
| complicated requests to the point where they're barely
| legible on the command line.
| nkrisc wrote:
| Right, I understand. My point is that if they're going to
| mention cURL, but then describe it as "a command-line
| tool that transfers data using HTTP, HTTPS, IMAP, and
| other common Internet protocols." why not just say the
| attack can be executed directly from the command line?
| Any techincally literate audience will understand that
| implies cURL (or any other tool!) and an non-technical
| audience will understand its simplicity, if that is in
| fact the case.
|
| I still think it's strange to mention cURL specifically
| in the way they did and agree with the GP. Here's another
| terrible analogy for the HN archives, but it's kind of
| like saying, "the smash-and-grab on the jewel store can
| committed with a Stanley(tm) 16 oz Curved Claw Fiberglass
| Hammer" when of course any heavy, handheld object will
| do.
| thaumasiotes wrote:
| > why not just say the attack can be executed directly
| from the command line? Any techincally literate audience
| will understand that implies cURL (or any other tool!)
| and an non-technical audience will understand its
| simplicity, if that is in fact the case.
|
| I mean, the normal way to use curl for this kind of thing
| is to define the request you want to send in a file and
| tell curl to read the file. There's no requirement -- or
| implication -- of simplicity in an attack that "you can
| execute from the command line"; that description refers
| to every possible attack. It's meaningless. There's
| nothing you can do that you can't do from the command
| line.
| TheAdamAndChe wrote:
| cURL has above-average name recognition. It's like
| mentioning a Dremel tool instead of a handheld rotary
| tool.
| ldarby wrote:
| > cURL has above-average name recognition.
|
| It might to you and people in your circle, but that's not
| the entire audience of the article. I wouldn't assume
| everyone knows what a Dremel is either.
| codyb wrote:
| It might just be a common journalistic practice to briefly
| profile any name introduced into an article.
| reshlo wrote:
| But why did they need to introduce cURL into the article?
| ad404b8a372f2b9 wrote:
| cURL is used for this purpose all the time, it's perfectly
| legitimate to mention it in this context, it's only factual.
|
| If you have to censor your content to account for the stupid
| and the mentally ill (slaughter guy sounds schizophrenic
| complete with delusions of grandeur and persecution syndrome),
| you will have to stop posting completely.
|
| What I find very distasteful is your attempt to incite people
| to harass the author over social media.
| tptacek wrote:
| Just a reminder that these severity ratings, while often
| directionally useful (a 9.x probably is something you should care
| about if you run the target software; a 2.x is _probably_ not),
| the ratings themselves are total horseshit and are running
| industry joke; literally a Ouija board, starting from a
| hopelessly ambiguous "calculator" that you run and then apply
| subtle inputs to to get the score where you want it to be.
| cj wrote:
| (Just curious) is there something about this that lacks
| substance? Sure, a CVE rated 8.6 vs a CVE 9.8 may or may not be
| worse than the other, but is there a better mechanism to
| communicate severity other than this, or something like
| "Medium", "High", "Critical", struggling to see your point.
| tptacek wrote:
| I'm exclusively back on my bullshit about CVSS being a
| debacle, and hoping that if I whine about it enough, people
| will stop putting CVSS scores in headlines, because they're
| meaningless. "Critical" does a fine job.
| Buttons840 wrote:
| "Critical" reminds me of the urgency every new feature
| request receives in the backlog.
| arcticbull wrote:
| Or a Windows Update that requires a reboot.
| laurent92 wrote:
| Ah yes, the ACEI scale: ASAP, Critical, Emergency, and In
| progress. In Progress being the only thing that actually
| gets done. The rest is conjecture. ASAP will never get
| done.
| rswail wrote:
| Any earlier than "possible" is obviously "impossible".
| OJFord wrote:
| But you don't have to do things 'as soon as' they're
| 'possible'. It does have meaning.
| magicalhippo wrote:
| My dad used to joke he kept three piles of papers on his
| desk at work: "urgent", "very urgent" and "no longer
| urgent".
| jolux wrote:
| Sounds like you have a dysfunctional organization.
| KMag wrote:
| With apologies to Cardinal Richelieu, give me 6 items
| from the policies of the most functional large
| organization, and I will find something in them which
| will hang it.
|
| If you don't see dysfunction, you're not looking closely
| enough. That's not to say all organizations are
| equivalently dysfunctional or that we shouldn't strive
| for better. I'm just saying that "dysfunctional" isn't a
| damning accusation.
| jolux wrote:
| Absolutely, but that doesn't mean we shouldn't be trying
| to resolve problems all the same. Teams not having
| control over their work is inefficient.
| whoknowswhat11 wrote:
| I have users forward me critical security alerts all the
| time - most are not even close to critical.
|
| I like the scores - just ask them - what's the score.
| pts_ wrote:
| Getting a web shell speaks for itself.
| bawolff wrote:
| Context matters a bit. From what i understand its a plugin
| that's only sometimes used and would typically (but clearly
| not always) be not exposed to the internet.
|
| So its a serious vuln, but not as serious as say if it was in
| a component that was always exposed to the internet in the
| core part of vmware. I guess vulns can always be worse.
|
| How bad it is depends on how you use vmware. I mean
| regardless, clearly everyone affected should patch.
| vosper wrote:
| > the ratings themselves are total horseshit and are running
| industry joke
|
| Any further references to this? I'd love to have something I
| can send around internally. The people running Tenable tend to
| treat these numbers as gospel.
| ramimac wrote:
| Honestly, I'm sure there are better sources - but this might
| be worthwhile just for the irony:
| https://www.tenable.com/blog/why-you-need-to-stop-using-
| cvss...
| formerly_proven wrote:
| This isn't specific to CVSS, it's the same for literally any
| kind of security-related rating or classification system.
| bitexploder wrote:
| Well, just pull up a CVSS calculator and start asking
| yourself questions and playing with it. As a fun game we
| would have people independently rate bugs on our Slack, mind
| you these are seasoned information security consultants that
| have broken a lot of software, and the ratings were
| hilariously far apart. Ask everyone to rate it
| low/medium/high/critical and consensus was pretty easy to
| achieve. Anyway the point is the criteria are quite
| subjectively. What comes out seems very quantitative, but
| it's basically a pile of Jello in terms of how solid it is.
| beermonster wrote:
| You really should be performing your own risk assessment so
| you can convert this notional context-free severity rating to
| your own context-related impact and likelihood to give you
| your own company risk rating. Ratings over a certain number
| (to be agree with at board level - in effect your risk
| appetite) should be treated (risk remediated, removed,
| transferred to a third party etc etc).
|
| We also do this with pen test reports which suffer the same
| kinds of issues.
|
| Usually find that sometimes a medium is a critical for us and
| some times a high is a low for us - based on performing this
| kind of assessment.
| vosper wrote:
| > You really should be performing your own risk assessment
| so you can convert this notional context-free severity
| rating to your own context-related impact and likelihood to
| give you your own company risk rating.
|
| Totally agree, and I do that - check the vulnerability
| description, see if we're using that part of the library,
| etc... it usually works out that we're not actually
| affected by whatever the alert is.
| [deleted]
| bottled_poe wrote:
| In my mind there are only two factors that matter: the
| accessibility of the attack vector and the extent of the blast
| area if the target is compromised.
| rorykoehler wrote:
| I always use them as a guide for what we should talk about
| first to then give them our own internal rating. Typically vuln
| criticality is very system specific.
| jcims wrote:
| I got out of vulnerability management ~10 years ago and moved
| into other domains where I didn't really work around CVEs and
| vulnerability reporting. I dipped my toes back in late last
| year and couldn't believe that basically nothing had changed.
| gogopuppygogo wrote:
| The attacks are getting more funding and are exponentially
| more sophisticated. The investment in prevention is meh
| comparably.
| kjs3 wrote:
| I hear this argument all the time. It's always followed by some
| variation of "and that's why we're not going to address this in
| a timely manner".
| px43 wrote:
| The funny thing about infosec taxonomies is that actual attacks
| actively resist classifications like CVSS.
|
| CVSS is generally used on the sysadmin side to figure out what
| to patch first. Successful attackers generally go after shit
| that's unpatched. This often means that the most exploited bugs
| are the ones with the lowest CVSS scores, so new tools and
| techniques tend to grow around issues that sysadmins consider
| to not be a big deal.
|
| People eventually catch on that the "no big deal" bugs are
| getting exploited en-masse, and try to tweak the scoring
| process, which is why we're on CVSSv3 now with CVSSv4 in the
| works, and it's just as useless as it's always been.
| na85 wrote:
| It can't be _that_ bad, since I haven 't seen a flashy website
| for this vuln, complete with a logo, making the rounds on social
| media.
| KirillPanov wrote:
| All that means is that the first person to find the vuln wasn't
| a grad student hoping for a faculty job.
| yarg wrote:
| It needs a cool name too; the VisorShatter breach.
| franciscop wrote:
| VMBeware.com is available and a nice catchy name for a VMWare
| bug IMHO. Please cite me if you use it :)
| kzrdude wrote:
| It's close to slander to use such a name, I'm afraid.
___________________________________________________________________
(page generated 2021-06-05 23:02 UTC)