Blog

Blacklisting or Whitelisting in the Right Way, (Thu, Sep 19th)

It’s Friday today, I’d like to talk about something else. Black (or white) lists are everywhere today. Many security tools implement a way to allow/deny accesses or actions on resources based on “lists” bsides the automated processing of data. The approach to implement them is quite different:

  Methodology Pro Con
White list Deny everything by default and allow exceptions Full control of all resources Harder to manage
Frequent updates
Can be frustrating for the user.
Black list Allow everything by default and deny exceptions Easy to manage
Less impact on users

Only “known” resources are blocked
Risks of missing blocked resources.
Never-ending process

A classic example is applications allowed to users on endpoints in a corporate environment (Microsoft AppLocker[1] works like this): You can allow all applications but block some or you can deny all applications but allow only approved ones.

When you have a security product that implements both types, how are they processed? In which order? Let’s take an example that I faced yesterday at a customer. The security product is a mail protection system which scans incoming SMTP traffic, extracts emails, attachments and tests them (in a sandbox if needed). Two types of lists are available and may contain the following indicators:

  • A sender email address
  • A sender domain
  • A sender IP address
  • An URL
  • A MD5 hash
  • A recipient email address

Lists are:

  • Allowed list
  • Blocking list

This looks very efficient: you can white list IP addresses of internal SMTP relays, domains from partners, or block domains used by spammers. But it can also have nasty effects. The question to think about is: In which order are the lists processed? They are multiple scenarios possible:

  • Process the blocking list first and, if a match is found, stop processing the other list
  • Process the allowed list first and, if a match is found, stop processing the other list
  • Process the blocking list and, if a match is found, check in the allowed list if there isn’t an exception
  • Process the allowed list and, if a match is found, check in the blocking list if there isn’t an exception

Let’s take the practical example that I faced yesterday as an example:

In the blocking list, there is a rule to prevent people to receive emails from the following domain: “efax.com”. This rule is in place for months. Suddenly, a user complained that he can’t receive emails from the domain “telefax.com.uy”. So, we added a rule in the allowed list to always allow emails sent from this domain. But it did not work… After some investigations, we found the issue!

The blocking list is processed in the first place and still rejected emails from telefax.com.uy (because the ‘efax.com’ rule matched). But why does it match a sub-string of the domain? By reading the documentation, we found that regular exceptions are allowed in rules.

To fix this issue, we changed the blocking rule to ‘^efax.com$’ to really match this domain and nothing else. With this configuration, the blocking list did not match any rule and the allowed list matched on ‘telefax.com.uy”. Happy user!

Conclusion: The implementation of white or black-list is not easy and must be carefully tested and… RTFM[2] to be sure to fully understand their priority!

[1] https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview
[2] https://en.wikipedia.org/wiki/RTFM

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) ↓