Posts made by Tom

@GregAlexandre We have tried to fix this and added some more rules, however, we can't access Kobo dot com, and have been unable to do so for several days.

Can you inform us what the latest recommended version is?

@GregAlexandre This is curious, at least it is flagged as a "library" file, but in the Personal we show "orphaned" library files, not in the Corporate.

However, you are right, it should be bundled, not just treated as a library.

Do you have any idea when this started? It seems that the bundling properties on the product still should match, so this may be due to a code change (if it is recent). We made some small changes to the order of different stages of the processing and I start to suspect that it might have had some side effects in certain edge cases (and Geforce Experience is more complicated than most other products, in terms of bundling, so it could be an "edge" case).

@GregAlexandre This is fixed now. Though you may need to Inspect again.

The issue was not related to the Agent upgrade, it was a coincidence that we made another upgrade in the backend which had an unfortunate side effect for some Personal accounts.

And my apologies for the late response.

Do let me know if there is other issues and please don't hesitate to do an @ mention, to get my attention on urgent issues like this.

Hi,
I've found your Host and can see that there is an issue. I've forwarded it to the dev team and will come back with news very soon.

The driver file is present, so in that sense the software is there. But it appears that the driver also is bundled with other software from Intel.

I can also see that there is a new version, that will be added soon.

However, there are some issues with the accuracy of this, that is also why it is released as "Testing".

It should be clear in the UI of Personal edition with a black "Testing" pill. In the Personal we default to show these "Testing" apps, in order to get this kind of feedback.

However, in the Corporate, it isn't visible for ordinary accounts, except for Olli, and for our internal test accounts. The issue here, is that you can't see that it is "Testing" in the Corporate UI, so you may be led to believe that it is fully supported. Since Olli is the only external person who can see "Testing" in Corporate, we won't change that any time soon.

This detection will remain as "Testing", while we await a new backend feature, which should aid us in tracking this in a proper and reliable manner.

@OLLI_S Thank you, I've changed the file. Please report if that causes other issues.

@OLLI_S Looks like it is fixed.

@GregAlexandre Version 40278 is available now and I also confirmed it by downloading it.

@GregAlexandre
The advisory is still present:
https://security-advisory.acronis.com/updates/UPD-2302-3bd6-1ff4

Description
This update contains fixes for 2 high severity security vulnerabilities and is recommended for all users.

More details will be published soon.

Let's hope they release a new build asap.

@GregAlexandre If you look at this page, you'll see the latest build referenced:
https://www.acronis.com/en-us/support/updates/

However, if you click the link, then you get the older version, also the release notes has been pulled.

It is curious, as our robot found build 40252 on 21 February, and the update was detected on one or more customer PC's on 22nd, and the update was assigned to a curator who made the rule (on 22nd).

And there was even a new entry in their advisory database, indicating that build 40252 fixes security issues (albeit, no details were present).

We will set 40173 as Recommended for now and update as soon as a new build has been released.

@lammertsm Thank you. Detection has been added as "testing". We will soon release it properly.

@GregAlexandre

Removing chocolatey isn't trivial for all users, since a few already used it or started using after it was installed by VulnDetect.

We are assessing ways to determine this in a reliable way, so we don't remove it if the user has used it.

Alternatively, we will release a removal script at some point, so you and others easily can remove it.

Thank you. The product has been added as "testing". Once we have collected proper rule data, we will release it.

@GregAlexandre Interesting, I have no record of why it should have disappeared. Do let me know if it happens again.

And thank you.

@GregAlexandre

Thank you for highlighting this, we will consider how we can approach this, since some users had Chocolatey prior to installing VulnDetect.

@lammertsm

I'm happy you found a solution.

And thank you very much for the detailed explanation, I'm certain other customers can benefit from this.

@lammertsm

Hi,

It appears that we have some outdated documentation, it will be fixed within a day or two. The OCSP / CRT hosts should be:

• r3.o.lencr.org
• r3.i.lencr.org

However, this is most likely not the cause of the issue that you have.

I can see that the host got registered with the system. This means that the installer managed to contact the backend and get the authToken, that you see in the logfile.

Since the installer is invoked interactively by the logged in user, it uses the same network / proxy settings as the user that is logged in, when it invokes the Agent to register for a authToken.

While the Agent runs as the SYSTEM user, after it is installed.

In some environments, there is restrictions on what the SYSTEM user can do on the network and whether it has access to a proxy.

I suspect that is what you are seeing here.

Since I don't know anything about your system configuration, it is hard to advise on the proper cause of action to allow the Agent network access.

Updating your Microsoft 365 installations using Custom Software is very easy.

We have made the below simple sample code, which will update it in a safe manner.

You may want to alter this:
/update user displaylevel=false forceappshutdown=false

The displaylevel can be set to true, then the user will see a popup.

And you would be able to close the apps by changing forceappshutdown to true. Our tests shows that this is safe, as it doesn't close the apps, if people have unsaved documents open. However, please test this on a few hosts, before doing this across the entire company network.

$path64 = "C:\Program Files\Common Files\microsoft shared\ClickToRun"
$path32 = "C:\Program Files (x86)\Common Files\microsoft shared\ClickToRun"
$file = "OfficeC2RClient.exe"
$arguments = "/update user displaylevel=false forceappshutdown=false"
function updateOffice ($clicktorun, $arguments) {
    Start-Process -PassThru -FilePath $clicktorun -ArgumentList $arguments
}
if (Test-Path -LiteralPath "$path32\$file" -PathType Leaf -ErrorAction SilentlyContinue) {
    updateOffice -clicktorun $path32\$file -arguments $arguments
}
elseif (Test-Path -LiteralPath "$path64\$file" -PathType Leaf -ErrorAction SilentlyContinue) {
    updateOffice -clicktorun $path64\$file -arguments $arguments
}
else {
    Write-Host "Error: $file not found in default locations, aborting."
}

NOTE: A signed edition of the script can be found here:
https://stream.vulndetect.com/e/update-office.ps1

Remember to select All files: