This post documents a security mis-configuation I observed in VIPRE Endpoint Security with Endpoint Discovery.  A few years ago, I published a blog post titled The Dangers of Client Probing on Palo Alto Firewalls, which detailed how client probing feature on Palo Alto firewalls can leak service account password hashes.  This issue is very similar and is probably best described as a forced authentication attack.

VIPRE Endpoint Security is a typical Antivirus/Endpoint Protection software.  It protects computers from malware and performs other actions such as web filtering.  This issue is unrelated to it’s ability to detect malware, but rather how it can deploy agents.

One of the features of this software is that it can detect unmanaged systems and automatically deploy agents to them.   This is where the problem stems.  Below is an excerpt from the user guide, emphasis mine:

Additionally, here is an excerpt from the referenced “Automatically Installing Agents” portion of the doc:

When we view the settings in the UI, they look like this. First, under the “Unprotected Computer Discovery” page, we can see that we can check the “Enable endpoint discovery” checkbox.  By default, it will check every hour.  There is also the “Authenticate with unprotected computers using saved credentials” checkbox.
We do actually get some sort of “warning” at the bottom, but it does not reference the security risk and only that this may increase the amount of error logs.

The credentials used are found under the “Remote Credentials” area within the “Agent Installation” tab.  At least one set of credentials must be present here.  As this account must have local administrative privileges over the system, it is predictable that a Domain Admin account will be used here, however any account used must be highly privileged as it presumably must have local admin over all managed systems.

So here is the summary of what appears to be going on:

• VIPRE Automatically scans the network every hour via Active Directory and NETBIOS.
• VIPRE Automatically tries to log into rogue systems that are discovered.
• The login attempt is performed using highly privileged credentials.

From here, exploitation is easy.

1. Create a new device on the network.
2. Start an SMB server. You can use Responder or ntlmrelayx.py, or a legitimate server in tandem with a packet capture.
3. Wait ~1 hour.
4. Receive an inbound SMB authentication attempt, which you can then attempt to crack or relay.

I was able to test this using Responder, and it worked as expected:

$ sudo python Responder.py -I eth0
                                         __
  .----.-----.-----.-----.-----.-----.--|  |.-----.----.
  |   _|  -__|__ --|  _  |  _  |     |  _  ||  -__|   _|
  |__| |_____|_____|   __|_____|__|__|_____||_____|__|
                   |__|

           NBT-NS, LLMNR & MDNS Responder 3.0.2.0

  Author: Laurent Gaffie (laurent.gaffie@gmail.com)
  To kill this script hit CTRL-C


[SMB] NTLMv2-SSP Client   : 10.0.0.34
[SMB] NTLMv2-SSP Username : DOMAIN.LOCAL\vipre
[SMB] NTLMv2-SSP Hash     : vipre::DOMAIN.LOCAL:9004E002D008cb436097f2d43ab:5FD88B956E5E2EA5CB64964148CFD60B:0101000000000000C0653150DE09D201E291934C1C4AEF7E000000000200080053004D004200330001001E00570049004E002D00500052004800340039003200520051004100460056000400140053004D00420033002E006C006F00630061006C000300340057004500052004800340039003200520051004100460056002E0053004D00420033002E006C006F00630061006C000500140053004D00420033002E006C00329E6351F2C18F2292C1CEAB94E076ADF33DA0A001000000000000000000000000000000000000900240063006900660073002F00310039006F00630061006C0007000800C0653150DE09D20106000400020000000800300030000000000000000000000000400000F2C6D23520B969106525FA996CD32002E003100360038002E0031002E003100300033000000000000000000

It should also be noted that the exploitability of this attack relies upon two known issues with Microsoft protocols.  A vulnerability in the NTLM protocol what has been publicly known for 20+ years,  yet the default configuration of current Windows systems is to allow for NTLM authentication. While Kerberos was introduced in Windows 2000, Windows still supports NTLM.  In order for relay to work, the targeted system must not require SMB signing.  This is unfortunately still the default on modern Windows systems.

Unlike the issue with Palo Alto Firewalls, I found two differences that were significant:

1. The account used MUST be highly privileged, as this is a requirement to install an agent.  Palo Alto’s User-ID feature is designed simply to enumerate logged on users, so presumably less privilege is needed.
2. The VIPRE documentation makes no mention of this risk, as far as I can tell. Palo Alto does tell you to minimally scope the permissions as well as let you know that this can lead to exposure of username, domain, and password hash.  I would advise VIPRE to make note of this risk in their documentation and UI as well.

My advice for clients would be to disable endpoint discovery, as the risk outweighs the benefit.  Even without “Authenticate with unprotected computers using saved credentials” checked, an admin may mistakenly deploy to a malicious device.  I would also advise to not configure Automatic Agent Instillation for any polices.

As my testing was limited to testing in a production environment on a client network, I was not able to explore all possible configuration options and record their results. It is not completely clear which of these actions may cause an SMB authentication attempt to take place, but this is what I believe to be the case:

• Device scanning (no)
• Authenticate using saved credentials box checked (yes)
• Automatic Agent Installation checked (yes)

As this risk is not detailed in any VIPRE documentation, it is possible that VIPRE was not aware of this risk. I attempted to contact them. The disclosure timeline is detailed below:

December 31st 2020 – Attempted to reach out via security.txt and security@[DOMAIN] but neither were present. I then attempted to reach out via Twitter.

January 4th 2021 – Attempted to reach out again via Twitter.  I received a DM and was directed to their support page. I went on to create a support ticket.

January 5th 2021 – Received confirmation from technical support that the information was forwarded on to the appropriate team.

January 6th 2021 – VIPRE Product Management confirmed that they could reproduce the issue.

January 11th 2021 – VIPRE publishes an initial public blog post about the issue with limited details.

January 26th 2021 – I publish this blog post publicly based upon an agreed upon disclosure timeline.  VIPRE has indicated that they will post a more detailed write-up from there end at a later date with additional details.

January 29th 2021 – VIPRE updates their blog post to include additional information about the vulnerability.