This issue was a bit of a brain cracker but I’m happy with the outcomes. A few weeks ago, one of my freelance customers from Argentina called saying they noticed their users could connect to their corporate email infrastructure using unmanaged email clients, which, in traditional French is what they call a big information security ka-ka, that could potentially lead to data leaks or even worse.
To tell you a bit about the infra:
It is a WS1 UEM On-Prem deployment
The email server is Exchange on-prem and the customer is using WS1 SEG for email integration
It’s a BYOD deployment having iOS and Android.
All users should be using a hardened deployment of Boxer to connect to the environment
Upon checking we found out there were no email compliance policies set up, so if users tried to connect to the SEG and it had a proper set of credentials they would’ve been authenticated and able to sync email.
Please note: the settings described below will only apply for a BYOD approach where you are using WS1 boxer, if you want to allow your users to use native mail clients for corporate-owned devices this might not be the right solution for you.
How to solve this situation:
In Workspace One UEM console we browse to Email -> Compliance policies and we should see something like this:
Under EAS (Exchange Active Sync) Device Type we should configure the compliance policy like this:
This setting will allow only Boxer clients and block all unmanaged clients.
Your mail client should look like this:
This way we will allow only boxer clients and block all other unmanaged clients.
Under Sync Settings compliance:
This setting will remove the email, calendar, contacts and other email objects sync from non-compliant devices.
Other settings to enable: Device Compromised: Set to Block Compromised Devices Managed Devices: Set to Block Unmanaged Devices
For an additional layer of security, the exchange team has decided to block unmanaged email clients on Exchange.
Here are the steps:
1. Log in to Exchange Console 2. Click Mobile -> Mobile Device Access 3. Under Exchange Active Sync Device Access Rules create 4 rules:
I’m not a cybersecurity expert, but I’ve been working for a CyberSec company for quite some time and after so many discussions with the Information Security folk a few things start sticking to you. This is the first post I will do focusing on security, but hopefully not the last.
Ransomware is not recent news, it’s been laying around for a couple of years. Particularly WannaCry kept many colleagues up all night in 2017. If anyone doesn’t know what Ransomware is yet, let’s explain it with this simple analogy:
You leave your bike on the street and some thug comes in and instead of taking it home puts a lock and demands a payment (ransom) for the key. Now, the bike is your data and the lock is an advanced encryption algorithm.
Now, as I mentioned in previous posts this blog primarily focuses on VMware products, and for many years the primary target for ransomware attacks was Windows and VMware was, fortunately, kept to a side. With the evolution of the Ransomware industry, yes Cybercrime is an industry, Ransomware started affecting not only windows but other operating systems. And that’s where ESXiArgs comes into the picture. Disclaimer: it’s not the first nor the last ransomware to affect ESXi, it’s just the latest one.
What is ESXiArgs? ESXiArgs is a Ransomware campaign targeting publicly available ESXi hosts. It is believed that it’s leveraging one of the following vulnerabilities CVE-2022-31699, CVE-2021-21995, CVE-2021-21974, CVE-2020-3992, and CVE-2019-5544. But still, the final vulnerability is not yet confirmed.
What is OpenSLP? OpenSLP is an open-source framework for networking applications to discover the existence, location, and configuration of services in enterprise networks, which ESXi client applications use to resolve network addresses and hosts.
What ESXi versions are affected? According to the official documentation:
It’s important to note that most of the affected hosts were reported to be outdated versions of ESXi 6.5 and 6.7.
Is there any workaround available? Yes, you can disable the SLP service as shown in this KB Please note, disabling SLP service doesn’t require a reboot but may affect how CIM interacts with your VMs and third-party monitoring solutions might be impacted.
Is there any way to recover? The US Cybersecurity and Infrastructure Security Agency (CISA) has published this github script with detailed instructions on how to recover. Remember: Paying for Ransomware is never an option.
Can I block the SLP port on the firewall? Yes, you can, as a compensatory control. That’s not a full mitigation.
Is there any official comment from VMware? VMware Official ESXiArgs FAQ page VMware Security Response Center has also made its official statement.
Closing comments: While researching for this blog post I came across a few interesting factors:
1. A cloud provider in France reported having 2000 ESXi hosts affected by this vulnerability. All the hosts were publicly available on the internet.
2. All of the affected hosts are unpatched. And most of them are end-of-life.
How can this be improved? Don’t expose your servers to the internet if it’s not required. vCenter and ESXi hosts are never required to be exposed to the internet. But Nacho I need them to… No, you don’t.
Keep the servers up to date: This doesn’t only apply to VMware, ESXi or vCenter. This is the most basic part of running IT operations to keep your organization secure.
I think of the usual patching as going to the doctor: • Some people go to the doctor often and get checked. Even if they are feeling perfectly fine. These are the more mature organizations that have reached a level of proactiveness and automation that allows them to. • Some people go to the doctor when they have some pain, they get some medications and forget about their doctor. This is probably the vast major group of organizations, both big and small that for a variety of reasons don’t want, don’t know, or can’t afford the operational cost of patching. • There is also a third group of people that never go to the doctor, and when they visit the doctor is too late. These people are just wrong.
Patching vSphere has never been easier, I’m patching my hosts as I write this, to be honest, vSphere Lifecycle Manager (a tool included in your vCenter license) makes it super easy to patch and upgrade your ESXi hosts.
Scan your environment for vulnerabilities: Organizations that are mature in the cybersecurity field usually have a Vulnerability Scanning tool running regularly. These tools often give a report of the vulnerabilities in the system and even tell you what is the suggested version and how to mitigate them. There are many options both open-source and paid. Based on my experience I would recommend Tenable or Nessus. Another option would be to hire a company or consultant that provides Red Team services.
Subscribe to VMware Security Advisories It’s a newsletter that sends you updates on new vulnerabilities, it’s usually a 2 minute read and from there you can notify your team and your organization to properly patch and update.