"Having a description of the vulnerability rather than the payload" Me too please! Really not comfortable that there is no information on the real issue.
It shouldn't come as a surprise to Kaseya users on this forum ask for a deeper knowledge of this vulnerability.
Let's see if Kaseya is willing to provide it... maybe only with a specific NDA...
I did speak with a support manager Monday night, and she said that they don't want to provide more details at this time, in order to give the customer base time to get patched, which makes sense. However, I think they need to be making a full-court press to notify their on-premises customer base, and then provide their partners with further details on how exactly this exploit worked, and what they've done to ensure it's patched.
I have a call with my account rep tomorrow to discuss a lack of notification, and he claims he called 2 people but didn't leave voicemails due to the "negative connotations and no explanation", which I can't say I'm happy with. At a minimum, a voicemail should have been left letting us know about the new security bulletin, given the severity of this issue.
Thank you for patching the security holes in Kaseya. that is good.
However it would be a really good thing if we could get more information.
For example, can we check the IIS-logs for suspicious beaviour, if so what?
Could our server be compromised (which means all our customers as well)?
We all have a bad feeling about this.
I can understand that you don't want to disclouse the exact exploit/payload.
Every other vendor, would release the patch and details of the vulnerability. Allowing the rest of us, to make an assessment on risk and impact, and allow us to investigate whether or not there has already been a compromise, and any further action needed to be taken, increased security measures being put in place for example.
They claim less than 0.1% of customers have been compromised, however sounds like 90% wouldn't even know.
So far the facts are:
There was a vulnerability, and we think its been patched!
They have worked with some of their "larger" customers, and found it being actively exploited
According to a post, made yesterday, the payload was altered to evade the checking procedure provided
It is the VSA servers that need to be checked, rather than the end-points, and knowing the nature of the vulnerability, would give clues on where to check.
I was very surprised to see the 0.1% estimate in their security bulletin, I would love to know how they arrived at such a low figure, before anyone even really knew about the vulnerability.
Just a heads up. It looks like Kaseya updated the detection script to 2.2 last night
I did not see any anoucements so though everyone might be interested
This is still burning a hole - anyone got any new news?
Here's what I'm using to stomp it down; there's a new flavor that is not what Kaseya or esentire has published... where it keeps the keys in hklm\software\microsoft\removaltools (irony anyone?)
1. a monitor set to watch for powershell.exe running for more than a minute on workstations (false positives being less troubling than missed positives)
2. a script (sorry, agent procedure) that creates xmrkill.bat on the endpoint and runs it as system, when that monitor set triggers.
3. the batch file, which does
taskkill /f /fi "imagename eq powershell.exe"
then a quick
reg delete hklm\software\microsoft\removaltools /va /f
So far it's at least "knocking down" hundreds of the little buggers that were running live on our managed endpoints.... but UGH I want some way to demonstrate that having patched (on friday night) with 188.8.131.52 that we are no longer actively pushing this crap out.
So, anyone have anything else to share about this? I fully expect to have to change which registry key I am "purging" on a regular basis since this has apparently migrated from hklm\software\microsoft\powershell to hklm\software\microsoft\policies, and now to hklm\software\microsoft\removaltools.
I see Kaseya has updated their detection script again last night, seemingly with your removaltools key, the silence from Kaseya is deafening though.
I wouldn't delete the whole contents of that key though, as per your batch script.
Just an update - I've gotten some attention from Kaseya support (thanks guys) and they're getting it done.
The new version (v3, updated as of earlier today 2/7/2018)) of the cleanup tool is good, as far as we can see it's cleaned up all the instances we got last friday night. Our stopgap kept the lid on the situation but now we're going ahead pretty confident that we and our customers are actually "clean". I can strongly recommend getting the new import from helpdesk.kaseya.com/.../360000346651-XMR-Detection-and-Removal-Procedures and implementing it.
Support was also helpful in checking over our VSA to confirm that the patch (184.108.40.206) had in fact closed the hole and stopped the VSA from pushing this out again, so we're moving ahead with a little more confidence. Another couple of days "clean" (knock on wood) and we'll be able to sleep again :)
Looks like they updated the script AGAIN to version 4 yesterday. Any one have further insight or experience? Yes Kaseya's silence on this is deafening and inexcusable.
Kaseya's silence on a couple of different topics right now is rather deafening...
Yesterday, when submitting a support case regarding Flash IE not being updated in the Ninite catalog (as well as Java 9 missing entirely), I also asked about the "Request Support" page now showing a blank page only stating "This page is not available please contact support for assistance".
I received the following answer from Kaseya's support:
"I would like to inform you that this page is been removed for security reasons. This is after the latest patch update."
As to the KSDU issue:
"Please know that your issue has been identified to be a possible defect and has been progressed to our engineering backlog for future prioritization. It will be prioritized by our engineering team and may be addressed in a future release cycle as part of the normal process."
Hardcoded backdoor credentials would certainly explain the silence coming from Kaseya.
ninite does not reflect a java version 9 yet. This is a 3rd party program from Kaseya.