Please see below details of a newly discovered vulnerability in Zoom video conferencing software; we hope this is useful to you if your organisation is one of the many to have deployed Zoom to enable remote working during the current Covid-19 crisis.
Clients requiring additional assistance with the topics discussed below should contact their Threatscape support representative. For additional advice related to securing remote workers, please refer to tips for securing remote working on our web site.
Threat Advisory
This advisory details a recently discovered threat related to a widely adopted technology which may be applicable to your business, and contains our recommendations on how you can mitigate its effects.
Title: Critical Vulnerability in the Windows client software for Zoom Video Conferencing
Date: April 1st, 2020
Risk Category: Phishing, Zero Day
Background
Due to the current COVID-19 crisis, organisations around the world are now working remotely. This has required the rapid deployment and adoption of remote working technologies, including collaboration tools for audio and video conferences. In response, cyber criminals are particularly focused on identifying new ways to target and exploit these tools, to compromise user systems or to capture data or user credentials from their targets.
Summary
Details
During conversation in Zoom meetings, users can interact through the chat interface. URLs that are shared via chat are displayed as clickable hyperlinks. Links pointing to internet pages will open in the users default browser, but if a user clicks on a link in UNC format which points at a file on a remote server, Windows will attempt to connect to the remote server using the SMB file-sharing protocol to open the target (and potentially malicious) file.
During the connection process, Windows will by default transmit the user’s login name and NTLM password hash to the remote server. An attacker could share a maliciously crafted link via chat which points at a server under their control, and then capture the credentials of anyone who clicked on the link.
Widely available hacking tools such as Hashcat can “dehash” NTLM password hashes to reveal passwords, and the GPUs in modern graphic cards allow these tools to accelerate their maths operations and crack passwords at high speed.
Mitigating Factors
(1) An attacker must be able to post a malicious link
The first and most obvious mitigating factor is that an attacker must be able to post a malicious link to the chat box of a Zoom call if they are to get participants to click it. This means that this risk is greatest for ‘public’ Zoom calls where anyone can join in, and is significantly less for private corporate sessions.
It is still possible however that an attacker might use social engineering to trick someone into posting a malicious link to a private company chat.
(2) Port 445 must be open for the attack to succeed
Windows SMB communication uses IP port 445, and every properly configured corporate firewall should already be blocking that port to prevent any SMB communication from LAN to WAN (this has been an industry-standard firewall policy recommendation for many years). Therefore a user behind a well configured firewall is already protected from this attack. This protection should also apply to users working remotely whose internet traffic is being forced to transit through a corporate security gateway, or users working at home who have a well configured home firewall.
However, since the current crisis has led to an unprecedented number of people working remotely, there is at present an increased risk that some users might not have the full protection normally provided by their corporate IT infrastructure. This could particularly be the case if users find it necessary or preferable to disconnect from a corporate network or disable corporate security measures to make a Zoom call possible or to improve the speed.
(Users of Symantec Endpoint Protection can also use its “location awareness” feature to configure a security policy which blocks all port 445 connections when a user is “off net”).
Additional Mitigation
It is possible to configure Windows not to send user credentials automatically when attempting to connect to a remote server; this can be done manually or by means of registry edit. Note that on a corporate network, this can interfere with routine connection to domain resources.
(1) Manual configuration to prevent NTLM credentials being sent to remote servers
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers
If this policy is configured to ‘Deny All’, Windows will no longer automatically send your NTLM credentials.
(2) Configuration change via registry entry
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
Make a new entry named:
“RestrictSendingNTLMTraffic” = dword:00000002
Additional Recommendations
- Keep applications and O/S patched and anti-virus updated
- Run software with the least privileges, not as “local admin” or similar
- Avoid files from non-trusted sources, or clicking on suspicious links
Further References
(including some less serious Zoom security issues, two of which affect Mac users)
https://threatpost.com/two-zoom-zero-day-flaws-uncovered/154337/
