Version mismatch with vmx86 driver

Well, it happened again. I upgraded VMware Workstation from 16.1.0 to 16.1.1. After rebooting I started a VM & got an error that said, “Version mismatch with vmx86 driver: expecting 401.0, got 308.0. You have an incorrect version of driver ‘vmx86.sys’. Try reinstalling VMware Workstation. Failed to initialize monitor device.”

I clicked OK & got another error that said, “Transport (VMDB) error -14: Pipe connection has been broken.”

The vmx86.sys file sounded familiar. Sure enough, I had a very similar problem last year & wrote a blog post about it.

https://patrickhoban.wordpress.com/2020/04/05/failed-to-start-the-vmware-authorization-service

Long story short, there’s an old version of the vmx86.sys file again. Do a repair on VMware Workstation, reboot, & try again.

Get-RDPCertificate PowerShell Function

I’ve been on a PowerShell function writing kick lately. Finally have one somewhat polished. As the name implies, it gets information for the certificate being used by the RDP service.

https://github.com/ThePatrickHoban/Scripts/blob/main/PowerShell/Certificates/Get-RDPCertificate.ps1

Quick Post: Find Group with ManagedBy Set

I recently ran into an issue where the description of an AD group said “Can manage membership of groups listed in notes”. Unfortunately, the notes field was blank. To find what, if any group(s) could be managed by this group just takes a few simple lines of PowerShell.

The code is posted on my GitHub page.

https://github.com/PonchoHobono/Scripts/blob/master/PowerShell/ActiveDirectory/FindGroupManagedBy.ps1

AZ-900 Exam

I passed the Microsoft Azure Fundamentals (AZ-900) exam!

Quick Post: MSVCR120.dll not found

Description – When running an OpenSSL command on Windows, you receive an error that says, “The code execution cannot proceed because MSVCR120.dll was not found. Reinstalling the program may fix this problem.”

Solution – Download & install “Visual C++ Redistributable Packages for Visual Studio 2013”. MSVCR120.dll is included in that package.

https://www.microsoft.com/en-ph/download/details.aspx?id=40784

Failed to start the VMware Authorization Service

When starting a VM I received an error that said, “VMware Workstation failed to start the VMware Authorization Service. You can try manually starting the VMware Authorization Service. If this problem persists, Contact VMware support.”

Looks like both the VMware Authorization Service & VMware Workstation Server service aren’t running.

I try to start VMware Authorization Service but get an error that says, “Windows could not start the VMware Authorization Service on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 6000009.”

Checking the Event Log I find one System event & three Application related events.

Event ID: 7024
Log Name: System
Source: Service Control Manager
Message: The VMware Authorization Service service terminated with the following service-specific error:
%%6000009

Event ID: 1000
Log Name: Application
Source: vmauthd
Message: Version mismatch with vmmon driver: expecting 385.0, got 308.0.

Event ID: 1000
Log Name: Application
Source: vmauthd
Message: Try reinstalling VMware Workstation.

Event ID: 1000
Log Name: Application
Source: vmauthd
Message:

Yes, the third application event really did have a blank message.

I don’t see any references in the registry or file system for anything named “vmmon”. I notice that the VMware Authorization Service depends on VMware vmx86 & it was running.

Get-Service -Name “VMware vmx86”

Below are the details for the VMware vmx86 service from the registry. Note that the ImagePath is “\SystemRoot\system32\DRIVERS\vmx86.sys”.

The properties of vmx86.sys show a File Version of 12.5.1.3 & build date of 6/19/2017. That seems pretty old for VMware Workstation 15.5 from 2020.

Let’s try a repair.

Using the PendMoves utility from SysInternals, it would appear the vmx86.sys file is going to be updated on reboot.

After the reboot, everything looks much better. Services are running.

vmx86.sys now has a file version of 15.0.0.84 dated 3/7/2020.

But most importantly, all VMs powered on properly.

What’s interesting about this issue is that about 5 months ago I upgraded from VMware Workstation version 12.5.7 to 15.5.1 & everything has been working. Which means that VMware Workstation version 15.5.1 works with vmx86.sys version 12.5.1.3. The issue started after upgrading from VMware Workstation 15.5.1 to 15.5.2.

If the repair doesn’t work for you, I also found a VMware KB article that walks you through manually removing the vmx86 service. In the end, you still have to reinstall.

https://kb.vmware.com/s/article/56954

Network Issue with Kioptrix: Level 1 VM

Playing with the Kioptrix: Level 1 vulnerable Linux VM I kept having an issue where even though I set the Network Adapter to use my custom LAN segment it would change back to Bridged during boot up.

Before:

After:

What I ended up doing to fix the issue is the following:

1. Power off the VM & remove the Network Adapter.
2. Remove the VM from VMware workstation.
3. Browse to the location of the VM’s VMX file & open it in your favorite text editor.
4. Remove all entries that start with “ethernet0” & save your changes.

Note – In my case I still had quite a few even though I had removed the NIC from within VMware workstation. Here are the settings I removed. Also note that they may not all be right next to each other in the VMX file.

ethernet0.allowGuestConnectionControl = “FALSE”

ethernet0.features = “1”

ethernet0.wakeOnPcktRcv = “FALSE”

ethernet0.networkName = “Bridged”

ethernet0.addressType = “generated”

ethernet0.pciSlotNumber = “32”

ethernet0.generatedAddressOffset = “0”

ethernet0.connectionType = “bridged”

ethernet0.pvnID = “52 2d e6 a1 6b d2 75 7c-36 41 8a 52 fc c8 48 5c”

5. After saving the file, import the VM back into VMware workstation & power it on.

Replace Tenable Nessus Essentials Self-Signed Certificate

After installing Tenable Nessus Essentials & browsing to the web interface, you get warning about the certificate. The message can vary depending on the name used in the browser to connect (localhost, hostname, etc.)

This is due to it using the built-in self-signed certificate that is generated when Tenable Nessus Essentials is installed.

Once logged into the web interface, there isn’t anywhere to replace the certificate being used. I found the link below on how to use a certificate from a certificate authority, but the details are…lacking.
https://docs.tenable.com/nessus/Content/CustomSSLCertificates.htm

So below is what I did to replace the self-signed certificate with one from an internal certificate authority. It’s no one-stop script or function to run but it does the trick. Form follow function people. All the code can be found on my GitHub page. Some code is based off other sources & is credited on the GitHub page.
https://github.com/ThePatrickHoban/Scripts/blob/master/PowerShell/Certificates/GenerateNessusCertificate.ps1

All the standard disclaimers apply, if you break something that’s on you. Use at your own risk.

1. 1. Create a DNS entry as needed for the FQDN you are going to use. In my case, I use nessus.laptoplab.net.
   2. Some environment specific variables you will need to change. $CN is the FQDN that will be used to access the web interface. $TemplateName is the name of the template in your CA. $Password is a temporary password used for exporting the certificates.

# Variables to update as needed
[string]$CN = "nessus.laptoplab.net"
[string]$TemplateName = "LabSSLWebCertificateCustom"
[string]$Password = "P@ssw0rd"




Set some more variables. These you can modify if needed.



# Other Variables
[string[]]$SAN = "DNS=$CN"
[string]$Date = Get-Date -Format yyyyMMddhhmmss
[string]$FriendlyName = """Nessus $Date"""
[int]$keyLength = 2048
[string]$NessusCAPath = "C:\ProgramData\Tenable\Nessus\nessus\CA"
$SecurePassword = ConvertTo-SecureString $Password -AsPlainText -Force

# CA
$rootDSE = [System.DirectoryServices.DirectoryEntry]'LDAP://RootDSE'
$searchBase = [System.DirectoryServices.DirectoryEntry]"LDAP://$($rootDSE.configurationNamingContext)"
$CAs = [System.DirectoryServices.DirectorySearcher]::new($searchBase,'objectClass=pKIEnrollmentService').FindAll()
If ($CAs.Count -eq 1){
$CAName = "$($CAs[0].Properties.dnshostname)\$($CAs[0].Properties.cn)"
} Else {
$CAName = ""
}
If (!$CAName -eq "") {
$CAName = "$CAName"
}




Stop the Tenable Nessus service



Stop-Service -Name 'Tenable'




Create a variable of the contents for the INF file to be used by certutil.



# INF Template
$file = @"
[NewRequest]
FriendlyName = $FriendlyName
Subject = "CN=$CN,c=$Country,s=$State,l=$City,o=$Organisation,ou=$Department"
MachineKeySet = TRUE
KeyLength = $KeyLength
KeySpec=1
Exportable = TRUE
RequestType = PKCS10
ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"
[RequestAttributes]
CertificateTemplate = "$TemplateName"
"@

# SAN Certificate
If (($SAN).count -eq 1) {
$SAN = @($SAN -split ',')
}
$file +=
@'

[Extensions]
; If your client operating system is Windows Server 2008, Windows Server 2008 R2, Windows Vista, or Windows 7
; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.

2.5.29.17 = "{text}"

'@
ForEach ($an in $SAN) {
$file += "_continue_ = `"$($an)&`"`n"
}




Prepare a few files.



$inf = Join-Path -Path $env:TEMP -ChildPath "$CN.inf"
$req = Join-Path -Path $env:TEMP -ChildPath "$CN.req"
$cer = Join-Path -Path $env:TEMP -ChildPath "$CN.cer"




Populate the INF file.



Set-Content -Path $inf -Value $file




Create a CSR.



Invoke-Expression -Command "certreq -new `"$inf`" `"$req`""




Get the private key info for the CSR.



# Private Key
$CertificateRequest = Get-ChildItem -Path Cert:\LocalMachine\REQUEST | Where-Object {$_.Subject -like "CN=$CN*"} | sort NotBefore | Select-Object -Last 1
Export-PfxCertificate -Cert $CertificateRequest -Password $SecurePassword -FilePath "$env:TEMP\$CN.pfx"

# Convert PFX to PEM
Set OPENSSL_CONF=C:\Program Files\OpenSSL-Win64\bin\openssl.cfg
Set-Location -Path 'C:\Program Files\OpenSSL-Win64\bin'
Invoke-Expression -Command ".\openssl.exe pkcs12 -in $env:TEMP\$CN.pfx -nocerts -out $env:TEMP\$CN.pem -passin pass:$Password -passout pass:$Password"
Invoke-Expression -Command ".\openssl.exe rsa -in $env:TEMP\$CN.pem -out $env:TEMP\$CN.key -passin pass:$Password -passout pass:$Password" 2>&1
Set-Location -Path C:\Temp




Submit the CSR to the CA.



Invoke-Expression -Command "certreq -submit -config `"$CAName`" `"$req`" `"$cer`""




Retrieve the certificate.



Invoke-Expression -Command "certreq -accept `"$cer`""




Export the certificate.



# Export certificate
$IssuedCertificate = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -like "CN=$CN*"} | sort NotBefore | Select-Object -Last 1
Export-Certificate -Cert $IssuedCertificate -FilePath "$env:TEMP\$CN`_Issued.cer"
# Convert to Base64
certutil -encode "$env:TEMP\$CN`_Issued.cer" "$env:TEMP\$CN`_Issued_Base64.cer"




Get the CA’s certificate. This step can vary depending on the PKI infrastructure.



# Get CA Certificate
# https://www.powershellgallery.com/packages/CertificatePS/1.2/Content/Copy-CertificateToRemote.ps1
[int]$iteration = 1
$Chain.Build($IssuedCertificate) | Out-Null
$ChainElements = $Chain.ChainElements | Select-Object -ExpandProperty Certificate -Skip 1
ForEach ($ChainElement in $ChainElements) {
$Iteration++
$CertificatePath = Join-Path $env:TEMP "$("{0:00}" -f $Iteration).$($ChainElement.Thumbprint).cer"
$ChainElement | Export-Certificate -FilePath $CertificatePath | Out-Null
# Convert to Base64
$Output = certutil -encode "$CertificatePath" "$env:TEMP\$("{0:00}" -f $Iteration).$($ChainElement.Thumbprint)`_Base64.cer"
}




Copy some of the certificate files to the Nessus Tenable directory. This one can vary as well to get the CA cert copied over. But if you’re reading this, you’re probably able to deduce how to get it copied & named correctly based on this example.



# Update Nessus certificate files
$Date = Get-Date -Format yyyyMMddhhmmss
Rename-Item -Path $NessusCAPath\cacert.pem -NewName $NessusCAPath\cacert`_$Date.pem
Copy-Item -Path $CertificatePath.Replace('.cer','_Base64.cer') -Destination $NessusCAPath\cacert.pem
Rename-Item -Path $NessusCAPath\servercert.pem -NewName $NessusCAPath\servercert`_$Date.pem
Copy-Item -Path $env:TEMP\$CN`_Issued_Base64.cer -Destination $NessusCAPath\servercert.pem -Force
Rename-Item -Path $NessusCAPath\serverkey.pem -NewName $NessusCAPath\serverkey`_$Date.pem
Copy-Item -Path $env:TEMP\$CN`.key -Destination $NessusCAPath\serverkey.pem -Force




Start the Tenable Nessus service.



Start-Service -Name 'Tenable Nessus'




Do a little cleanup. You can of course skip this step if you like & just move all the files generated to a secure location for backup.



$Cleanup = Get-ChildItem -Path $env:TEMP | Where-Object {$_.Name -like "$CN*"}
Remove-Item -Path $Cleanup.FullName

Now the moment of truth. Browse to the FQDN you configured for the Nessus Tenable web interface. You should not get any certificate warning.

								

			

My GitHub Site

I’m going to try & start using my GitHub site more.

https://github.com/ThePatrickHoban

Reset a Linux password from a live CD

Usually any Linux live CD will work. In my case since the installed version of Linux is Mint, I’m just booting to the Mint installation DVD which will by default launch a live session.

1. Boot to live CD.
2. Open terminal.
3. Find the drive with OS installed. (It’s usually /dev/sda1)

sudo fdisk –l

4. Create a temporary directory. It’s only virtual since the live CD runs in memory.

sudo mkdir /mnt/sda1

5. Mount the OS drive to the virtual directory.

sudo mount /dev/sda1 /mnt/sda1

6. Change the terminal root to the mounted drive.

sudo chroot /mnt/sda1

7. Change the password.

passwd john

8. Type the new password twice.
9. Exit chroot.

exit

9. Unmount the drive.

sudo umount /mnt/sda1

10. Remove Live CD & reboot.