DDoS Skype for Business User Enumeration

How is User Enumeration Threatening Skype for Business Users?

What is User Enumeration? Why is it a problem? How does this affect Skype for Business.
In this article we will explain all of them and how to get protected

5e315dc6ceeebbd8fe9341af 1 2Y66B1rrGJunV574QGPOlw nadafm

What is user enumeration?

User enumeration flaws provide attackers with a method to determine whether a specified username exists. An app signup error message saying “username already in use” would be one example. If the attack can be automated (by comparing the response to when a username is not in use), it allows an attacker to whittle down a large list of potential usernames to a smaller list of confirmed usernames.

Having a list of valid usernames for a system is extremely valuable to an attacker because it facilitates a range of other attacks which would otherwise take much more effort to pull off, including automated password guessing (brute-force) and denial of service attacks.

Why is this a problem?

Exploiting one of these user enumeration flaws is a fairly easy task. The first step is to identify the username format. This can be done by guessing common username formats (e.g. dan.andrew, d.andrew, etc) with employee names (for example obtained from LinkedIn or other public sources). If an organization uses an uncommon format, other techniques can be used, such as extracting a username from PDF or Microsoft Word file metadata.

With this information in hand, a long list of potential usernames in the correct format is generated using common forenames and surnames or a public list of employee names. Finally, the enumeration flaw is exploited to test the presence of each username in the list.

Now armed with a list of usernames that exist within the organization’s Active Directory (AD), the attacker can:

  • Launch a password spraying attack where a small number of common passwords, such as Password1, are tried against a large number of valid users. This technique is surprisingly effective, even against household-name companies. Intruder uses this technique on penetration tests and trust us, it works!
  • If the Windows domain is configured to lock out accounts after several failed logins, then a denial of service can be caused by submitting multiple bad logins against these known user accounts.
  • If an account lockout policy is not configured, the attacker has free rein to keep guessing passwords, increasing their chances of compromising accounts.
  • If credentials are successfully compromised, the attack can continue. The attacker can log into the affected product or another exposed remote access solution like remote desktop or a VPN, either of which could allow remote access to the internal network.
  • Exposed email services like Outlook Web Access or Outlook Office 365 could also allow access to sensitive information in emails, or the ability to mount further attacks by emailing malware appearing to come from inside the organization. The attacker is constrained only by what is exposed to the Internet.

Without a user enumeration flaw to first get a confirmed list of users, these attacks become an order of magnitude more difficult. What’s more, easy-to-use tools are publicly available to exploit three of the four examples above, so attacks against these commonly exposed technologies can be carried out even by unskilled attackers.

How does this affect Skype for Business?

Lync/Skype for Business’s vulnerability to user enumeration attacks was first reported to Microsoft in 2016.

Since then the vulnerability, which exists in a number of Microsoft’s on-premise products, hasn’t been fixed.

It remains one of the primary concerns for any company using Skype for Business on-prem.

This vulnerability not only makes it easier to penetrate users’ Skype for Business accounts, it also enables attackers to obtain lists of valid usernames, which can be used to penetrate other corporate resources which don’t have this weakness.

SphereShield’s Tarpit

SphereShield’s Tarpit feature for Skype for Business protects against enumeration attacks directed at exposed authentication services, such as the Webticket NTLM authentication interface as well as SOAP and OAuth interfaces that Skype for Business exposes externally.

Additionally, Skype for Business’s Lyncdiscover service, which is unauthenticated, is also protected.

SphereShield’s Tarpit delays failed authentication attempts and other relevant communication to prevent server response times from revealing whether the username sent exists or not.

The Tarpit can be fine-tuned by system admins to correspond with real-world delay times in the Skype for Business on-prem environment.

The user experience of users with correct credentials remains unaffected when activating this feature.

You can learn more about the Tarpit concept in this Wikipedia article

Additional Protection

SphereShield’s existing “SphereShield Credentials” feature continues to provide blanket protection against user enumeration attacks and many other potential vulnerabilities. Deployments using SphereShield Credentials don’t expose Windows Authentication interfaces to the internet.

Organizations using SphereShield Credentials have their users create a dedicated Skype for Business password which is different to their AD password and only used to connect externally to Skype for Business from Mobile and external Windows clients.

Customers already using SphereShield Credentials are already protected against user enumeration attacks and don’t need to activate this feature.

ADFS Skype for Business SkypeShield

New security vulnerabilities exposed in Microsoft ADFS

Tests carried out on a number of large organizations using Microsoft’s ADFS (Active Directory Federation Services) for SSO (single sign on) to cloud or third party services such as Office 365, Skype for Business (Lync) Online or Salesforce revealed that they expose their corporate networks to account lockout threats.

Testing conclusively demonstrated that companies using ADFS for authentication are vulnerable to threats caused by the external exposure of authentication services.

The tests by AGAT Software demonstrated the ability of hackers to lock Active Directory network user accounts, which were believed to be protected. Only knowledge of the username was required, which is typically easy to guess or to find out.

The tests revealed that attackers can lock accounts through ADFS even when the ADFS Extranet Lockout feature of Windows 2012 is deployed to protect ADFS.

A successful attack can cause significant business damage by preventing the user from logging into the network and from performing any type of work. Even resources not requiring ADFS are affected. This attack vector can be abused as part of a wider DDoS attack, halting all the company’s activities by locking all of the domain network users.

Beyond protecting ADFS, AGAT also offers a unified defense solution for protecting Skype for Business against account lockout. The Skype for Business topology creates challenges that are hard to address using generic solutions due to the multiple protocols, channels and methods used by a plethora of supported clients.

In order to raise awareness of the vulnerabilities that ADFS and Skype for Business deployments cause, AGAT Software is now offering a free test to companies wishing to validate that their network accounts are protected against account lockout for both ADFS deployments and Skype for Business on-premise deployments.

Mobile Security Skype for Business

How to verify DDoS/account lockout protection while deploying Skype for Business

While deploying Skype for Business (Lync) on mobile devices, laptops or any other external devices outside the corporate network, special attention should be given to the possible exposure of authentication services.

The exposure of these services increases the risk of Active Directory (AD) accounts becoming locked if someone who only knows a user name sends authentication attempts to the Active Directory. If an account is locked out, the user will be prevented from accessing any services, even internally, that require an organizational account. This will likely include their workstation.

Several authentication channels need to be addressed:

  • Mobile/desktop Skype for Business client logins
  • Web App logins
  • Dial-in page logins from a meeting invitation
  • Any NTLM/Basic or SOAP login sent via HTTP to a Skype for Business Front End server or director
  • NTLM authentication requests sent using the SIP protocol to an Edge server
  • Exchange Web Service (EWS)

Each of these channels should be monitored and the tally should be aggregated across all.

If you handle SIP and mobile HTTP protection separately, an attacker can send authentication attempts through separate channels without going over the specific channel threshold. In such a case, the attacker would be able to cause account lockout.

So, for example, if your network policy locks your account after five attempts, an attacker can send three attempts through a Lync mobile and another three to an SIP edge server. They could cause your network account to be locked out without reaching the limit in each channel.

Moreover, most generic proxy solutions offered currently fail to handle SOAP and certainly SIP authentication attempts because they are structured specifically for Lync.

The most effective solution for preventing such attacks is to have a unified solution that protects your distributed resources.

SkypeShield offers site and multi-site defense against DDoS attacks. All AD authentication attempts from the channels listed above are monitored via SkypeShield. Failed attempts are counted and stored in a central database table which is shared by all SkypeShield components.

SkypeShield monitors Active Directory authentication attempts for all Microsoft Skype for Business services published to the Internet. The solution counts failed attempts, and once an admin-set threshold has been reached, it blocks any further attempts from reaching AD servers. Such “soft locking” prevents AD accounts from being locked out.