Nyetya Announcement

As a result of Nyetya (also previously reported as Pyetya or NotPetya), we are sharing our thoughts on the potential impact to your Cisco Unified Communications environment.

The following overview was developed to provide clients and readers with a general understanding of the various potential points of impact should their Windows platforms/systems become unavailable, and may not be applicable in all environments.

Fidelus Managed Services is monitoring the situation and will provide additional details as appropriate and as they become available. Please reply back to FTAC Service Advisories if you have any questions or concerns regarding your services vulnerability or your support and we will try to answer any questions you may have.

Collaboration System Dependencies:

  • Active Directory Federation Services (ADFS)
  • Domain Name Servers (DNS)
  • Dynamic Host Configuration Protocol (DHCP)
  • Active Directory
  • Exchange
  • Secure File Transport Protocol (SFTP) Backup & Storage
In addition Cisco has provided several online resources that can be referenced:
Talos Blog: Cisco’s Threat Intelligence Team is actively investigating the attack. Visit the Talos blog, for the latest information on Nyetya and how Cisco Security protects customers.

Finally, you can review Microsoft’s KB article covering the technical details behind the SMB exploit and recommendations on how to reinforce and protect your Microsoft systems here: Microsoft Security Bulletin MS17-010

I. AFFECTED WINDOWS SERVICE :: ADFS

CISCO SERVICE :: Jabber/Finesse/User Login Failure
Login failure into UC applications can be the first symptom reported when ADFS is unavailable and the Single Sign-On functionality of Cisco UC platforms is enabled. Two possible workarounds exist in the situation where ADFS becomes offline.

Suggested Workaround #1
Our first suggestion would be to temporarily disable Single Sign-On across your Cisco UC platforms. Disabling this feature would require end users provide their Windows domain credentials to log into their UC applications such as Jabber, Finesse, CUCM Administration etc. Disabling this feature is our first suggestion as it’s the quickest way to restore login capabilities, while still allowing us to re-enable/re-configure Single Sign-On at any time.

Suggested Workaround #2
Our second suggestion, exchanging new meta-data, requires an additional, working ADFS server. This workaround retains SSO functionality but requires that meta-data is exchanged between UC platforms and ADFS. Suggestion #1 above can be followed if the meta-data exchange is unsuccessful. Note that new custom claims and Relying Party trusts must be created on ADFS for this workaround to succeed.

II. AFFECTED WINDOWS SERVICE :: DNS

CISCO SERVICE :: IP Phone Registration
DNS can be a requirement for IP phone registration in a UC environment. While this is not true for all situations, IP phones may attempt to resolve the hostname of a CUCM server before attempting and maintaining registration.

Note: DNS design can vary greatly between environments. Suggestions below may not be applicable.

Suggested Workaround | DHCP Available
If your DHCP servers are online, and your IP phones have a dedicated scope, our first suggestion would be to configure the DNS Servers scope option with any DNS servers that are still available. Fidelus Managed Services can reset your IP phones, in a staggered manner, to ensure they receive an updated DHCP lease reflecting a working DNS server.

If you have no available DNS servers, two options include to either enable DNS on a single IOS platform in your environment or deploy a temporary DNS server via OpenDNS. Regardless of which temporary solution is chosen, updating the DHCP scope for IP phones will still be required followed by resetting your IP phones in a staggered and control manner.

CISCO SERVICE :: Jabber/Finesse/User Login Failure
In most environments, CUCM proxies authentication requests to Active Directory, with many of these login attempts sourcing from Jabber and Finesse. If CUCM’s LDAP authentication target is configured for an FQDN instead of IP address, and its DNS servers are offline, then login failure will be an inevitable symptom.

Suggested Workaround
Our workaround for this situation would be to configure your LDAP authentication and synchronization servers with IPv4 addresses instead of FQDNs. Doing so will remove the requirement for DNS on login/authentication attempts from CUCM. Please contact Fidelus Managed Services for more information. This change can be done within minutes and requires no additional impact to UC services.

Leave a Comment

Professional Services Managed Services Procurement Services