Protecting yourself against the BlueGate RDP Gateway vulnerability

Schadenfreude is a wonderful feeling, but when it comes to information security, we must always remember that we live in glass houses. Over the past few months, as vulnerabilities have been rampantly exploited in SSL VPN products like those from Pulse, Fortinet and Citrix; I found myself deriving some enjoyment. Karma of course, was on its way.

Microsoft patched two vulnerabilities, dubbed BlueGate, as part of the January Patch cycle. These vulnerabilities are pre-authentication Remote Code Execution (RCE) rated. The vulnerabilities could allow remote code execution when an unauthenticated attacker connects to a target system using RDP and sends specially crafted requests. MFA will not protect you from this vulnerability. These vulnerabilities can be found in Windows Server 2012, 2012R2, 2016 and 2019.

Considering that RDP Gateway servers typically exist to provide a mechanism for users outside of to access trusted internal systems, exploiting this vulnerability could potentially provide network wide access to an attacker.

Security researcher Ollypwn has released proof-of-concept (PoC) that results in a denial of service (DoS). Luca Marcelli has also released a video showing a working RCE exploit.

Thankfully there is a small glimpse of hope. The vulnerability only affects the UDP transport (port 3391) option of the RDP Gateway components. Depending upon the configuration, administrators may have only exposed the HTTPS transport to the Internet. One potential mitigation, if patching is not an option, is to disable or block the UDP transport.

If you run RDP Gateways, please work to ensure that you patch or disable the UDP transport as quickly as possible. As with the Shitrix or SSL VPN vulnerabilities, once RCE exploit code is released, I expect attackers to include this in their ransomware toolkit much as they have.

Mitigating IE Zero-Day (CVE-2020-0674/ADV200001) with PowerShell and Intune

Microsoft published a security advisory (ADV200001) containing mitigations against an actively exploited zero-day remote code execution (RCE) vulnerability in Internet Explorer. At time of writing, there is no patch for the vulnerability. Microsoft is expecting to release a patch as part of the usual Patch Tuesday (Wednesday for some of us) cycle.

Microsoft has provided some mitigation steps that can be applied; however, they only recommend taking these steps if there is an indication you are under elevated risk. One of the problems with the mitigation steps is that you MUST revert the changes before you can install any future updated.

The mitigations also come with some side-effects; their impact might be too much for some organisations. Side-effects include:

• Printing to HP printers and other USB printers mail fail.
• Windows Media Player is reported to break on playing MP4 files.
• Sfc.exe will break.
• Printing to "Microsoft Print to PDF" is reported to break.
• Proxy automatic configuration scripts (PAC scripts) may not work. For me, I couldn’t imagine managing some enterprise environments without PAC scripts. That alone would be a good reason to not deploy these fixes.

If after all of this, you want to still apply these mitigations. I put together some quick guidance for their implementation with Intune.

Enabling the mitigations

1. Get a copy of the Enable-ADV200001.ps1 script from my GitHub repository.
2. Sign-in to the Microsoft Endpoint Manager Admin Center.
3. Select Devices > PowerShell scripts > Add.
4. In Basics, enter the Name: Enable IE Mitigations for ADV200001, and select Next:
5. In Script settings, browse to where you downloaded the Enable-ADV200001.ps1 script, leave everything else at their default settings, and select Next:
6. Select Scope tags. Scope tags are optional, if you don’t use this feature, select Next.
7. Select Assignments > Select groups to include. Select with groups this script should be applied to, select Next.
8. In Review + add, a summary is shown of the settings you configured. Select Add to save the script. When you select Add, the policy is deployed to the groups you chose.

Disabling the mitigations

1. Get a copy of the Disable-ADV200001.ps1 script from my GitHub repository.
2. Sign-in to the Microsoft Endpoint Manager Admin Center.
3. Select Devices > PowerShell scripts > Add.
4. In Basics, enter the Name: Disable IE Mitigations for ADV200001, and select Next:
5. In Script settings, browse to where you downloaded the Disable-ADV200001.ps1 script, leave everything else at their default settings, and select Next:
6. Select Scope tags. Scope tags are optional, if you don’t use this feature, select Next.
7. Select Assignments > Select groups to include. Select with groups this script should be applied to, select Next.
8. In Review + add, a summary is shown of the settings you configured. Select Add to save the script. When you select Add, the policy is deployed to the groups you chose.

More guidance can be found here Use PowerShell scripts on Windows 10 devices in Intune

Just remember that before your next patch cycle, you need to disable the mitigations, otherwise the updates will fail.

Ensuring your Windows 10 Clients are protected from CryptoAPI bug

Two weeks ago, Microsoft patched a vulnerability in its cryptographic library (CryptoAPI) that was reported by the NSA. At the time, there were no reports that this vulnerability had being exploited in the wild, however both Microsoft and the NSA where keen for organisations to install patches as quickly as possible. In its second-ever emergency directive, DHS' CISA recommended organisations perform the required endpoint patching by the 29th of January. I wrote about the first CISA emergency directive in my Advice on Mitigating DNS Infrastructure Tampering.

Proof-of-concept exploit code was quickly made available, but there are still no reported attacks. With the potential of attackers exploiting the vulnerability to sign malicious executables, that is, making malicious executables appear as if they are from a trusted, legitimate source; there are plenty of reasons to make installing this patch a priority.

As administrators, we already have the tools at our disposal to ensure that our Windows 10 clients are protected. Intune and Azure AD Conditional Access can once again be used to protect clients, as we did with Spectre and Meltdown.

How does it work? Read my post Using Intune and AAD to protect against Spectre and Meltdown, to understand the basics of how we can implement checks to validate the version of Windows 10 installed for Intune enrolled devices.

You will need to specify either of these two values for the Minimum OS version in your Windows 10 complaince policy:

• For Windows 10 version 1903 (May 2019 Update): 10.0.18362.592
• For Windows 10 version 1909 (November 2019 Update): 10.0.18363.592

I recommend the later, 10.0.18363.592, as it will allow you to ensure that all your clients are running the very latest Windows 10 features.

Need help with Windows 10 version numbering? Check out Wikipedia’s Windows 10 Version History) page. It is an exceptionally detailed guide on what versions you need to be aware of.

Bank Grade Security at Microsoft Ignite The Tour Sydney

I am extremely excited to announce that I am presenting my talk, Bank Grade Security at Microsoft Ignite The Tour in Sydney next month. I have received such wonderful feedback from this talk when I presented it at DDD Melbourne, DDD Sydney and NDC Sydney. Speaking at a Microsoft event like this has been a dream for a long time and I am excited to share it with an even wider audience.

If you are attending The Tour in Sydney, please register for the session (session code BRK30215). In the session I will be talking about how Australian Banks rate in terms of the use of security practices like SSL/TLS configuration hardening, the use of HTTP security headers and their support for security.txt files. The results will probably surprise you.

This talk will be updated with the latest results of my analysis, if you have seen the session, please come and see how the banks have hopefully improved. The session will be of interest to everyone including developers, security and operations teams.

Mitigating the risks of IMAP credential stuffing attacks in Office 365

A recent Bleeping Computer article, Multi-Factor Auth Bypassed in Office 365 and G Suite IMAP Attacks, reported that email security company Proofpoint, had observed a massive increase in credential spraying attacks that target Office 365 and G Suite. These attacks leverage legacy email protocols (IMAP) and credential dumps to bypass the multifactor controls provided by these platforms.

Now I am a bit sceptical of some of the numbers in the Proofpoint report, however I have seen other similar reports. I personally believe it is a safe assumption that most Office 365 and G Suite tenants have been targeted and that these attacks have successfully breached some of these tenants.

These attacks have been successful because:

• IMAP bypasses MFA (and some conditional access controls) on these platforms. This is due to the lack of support for MFA in the base IMAP protocol.
• The attackers have taken care to avoid potential account-lockouts. As a result, the attacks look like isolated failed logins and go unnoticed.
• MAP is an easy protocol to develop automated attacks against.

How can we protect our Office 365 tenants from these types of attacks?

There are three steps you can take:

1. Disable IMAP and POP access to mailboxes, and,
2. Disabling legacy authentication using an Exchange Online Authentication Policy, and,
3. Disable legacy authentication using a Conditional Access Policy.

Each of these steps targets different behaviours, and as such, I believe you should put all of these controls in place.

Disabling IMAP and POP client access

The first step is to disable users access to their mailboxes using IMAP and POP. Why do this? To be honest, why would any of your users be using these protocols? With Outlook applications on Windows, MacOS, iOS and Android and third party applications that support modern authentication, I don’t see any need for users to be sticking to these legacy protocols.

Unfortunately, you need to disable IMAP and POP at a mailbox level, you cannot disable it at a tenant level. To disable these protocols, we can connect to Exchange online and then use the set-CASMailbox CMDLet. Remember you need to do this for all mailboxes!

Set-CASMailbox -Identity $EmailAddress -PopEnabled $false -ImapEnabled $false

This could be included as part of your user automation processes.

Disabling legacy authentication using an Authentication Policy

You can find a great guide on doing this at Microsoft Docs, Disable Basic Authentication in Exchange Online.

Disabling legacy authentication protocols using a Conditional Access Policy

There is also a guide on Microsoft Docs, How to: Block legacy authentication to Azure AD with conditional access, that will help you set up a Conditional Access Policy that blocks legacy authentication protocols from use.

Slides and Content from The Boring Security Talk at CrikeyCon VI

Droopy the CrikeyCon Mascot

Last weekend I spoke at CrikeyCon VI. I am always excited to attend and present at CrikeyCon, the attendees are fantastic and overall the organisers have created an amazing conference ❤.

This year I presented The Boring Security Talk. This session covers a variety of issues, DNS, Email, CI/CD and dependency management.

You can view the slides here. I will update this past when the video becomes available.

CrikeyCon VI - The Boring Security Talk from kieranjacobsen

I have put together a list of links and reference materials:

• Hackers exploit Jenkins servers, make $3 million by mining Monero
• DHS: Multiple US gov domains hit in serious DNS hijacking wave
• Advice on Mitigating DNS Infrastructure Tampering
• A Deep Dive on the Recent Widespread DNS Hijacking Attacks
• DNS Squatting with Azure App Services
• DNSControl
• Managing DNS with DNSControl, CloudFlare, DNSimple, GitHub, VSTS, Key Vault and Docker
• MX Toolbox
• PostMark
• Phishing Scorecard
• UK ICO, USCourts.gov... Thousands of websites hijacked by hidden crypto-mining code after popular plugin pwned
• Malicious Docker Containers Earn Cryptomining Criminals $90K
• Postmortem for Malicious Packages Published on July 12th, 2018
• Malicious remote code execution backdoor discovered in the popular bootstrap-sass Ruby gem
• Pipdig Update: Dishonest Denials, Erased Evidence and Ongoing Offences

@kjacobsen / https://t.co/i7v4e9vNdr - Back again - another #CrikeyConVI legend supporter! He’s telnet’d here from 2014 to spread good security advices!! pic.twitter.com/YnlauRlIvk

— Doc Dave (@forensicdave) April 7, 2019

Kieran @kjacobsen Jacobsen from Readify is giving “The Boring Security Talk” now at #CrikeyConVI. Try to stay awake! High risk but low cool-factor IT systems need protection too! pic.twitter.com/JtyzxgmA0a

— Christopher Biggs (@unixbigot) April 7, 2019

If you want to catch this presentation in person, you will be able to see it at the Azure Global Bootcamp in Melbourne.

Update - You can now watch the https://www.youtube.com/watch?v=5OlMEi_vcgY!

Videos from NDC Sydney 2018

I forgot to post in December that the video from my NDC Sydney session, The Boring Security Talk, is available on YouTube and Vimeo.

Advice on Mitigating DNS Infrastructure Tampering

In January, the Department of Homeland Security (DHS) Cybersecurity and Infrastructure Agency (CISA) took the unusual step of issuing an emergency directive (EN 19-01) about Mitigating DNS Infrastructure Tampering. Several days, the National Cyber Security Centre (NCSC) which is part of the UK Government Communications Headquarters (GCHQ) also issued an alert on DNS Hijacking activity.

As I said, both agencies warnings unusual. This is CISA’s first ever emergency directive, and it is one of only 8 guidance posts released. NCSC has only issued 2 other alerts, for the TalkTalk breach and when the NHS was impacted by WannaCry.

If you haven’t read the read these alerts or any of the associated news coverage, let me provide a summary. Attackers have been directing attacks to DNS infrastructure, with organisations and government agencies falling victim. The goal of the attackers, thought to be of Iranian origin, is to redirect and intercept web and email traffic (and other network services).

The attacks have typically followed the pattern:

1. Compromising user credentials or an attacker that can make changes to DNS
2. Next, altering DNS records replacing legitimate records with addresses the attacker controls. This allows them to redirect user traffic to infrastructure they own. They can them manipulate and inspect all the traffic.
3. Attackers can obtain SSL certificates as they have control over DNS. This allows encrypted traffic to be decrypted, exposing private data and credentials.

The CISA guidelines are just as applicable for enterprise environments as they are for government agencies. Let’s look at how your organisation could perform the recommended steps.

Action One: Audit DNS Records

The first action item will be the most difficult for most organisations, auditing all your DNS records. For some organisations, even if they prioritise records that are associated with key services offered to their users and customers, MX records and NS records, that could consist of hundreds of entries.

Thankfully, there are some processes and tools that can help us in this task.

I recommend aiming to setup a tool to manage your DNS records, for example, DNSControl. I have a detailed write up on the why and how of DNSControl in my post, Managing DNS with DNSControl, CloudFlare, DNSimple, GitHub, VSTS, Key Vault, and Docker!.

To get your audit underway, I recommend these steps:

1. Get a copy of each DNS zone, most providers will provide one in BIND format.
2. Follow the Migration and Getting Started guidance for DNSControl.
3. Place your DNSControl file into a Git repository.
4. Break the zones and files up into smaller chunks so that multiple members of your team can review each entry.

The goal is to end up with a comment for each DNS entry (or almost every entry), explaining the purpose and who requested the entry. Any suspicious entries should be immediately handled as a potential security issue.

You should keep your eye out for dangling DNS records. These are cases where a DNS entry has been defined in a zone that points to an IP address or another record that is no longer in use. I wrote about these as a potential attack vector in 2017, DNS Squatting with Azure App Services. These attacks have become even more prevalent, with government agencies and businesses falling victim.

Side note: This is also a great time to review the SPF records for each of your domains.

Action Two: Change DNS Account Passwords

The second action is simple. Change the passwords for all accounts that can manage your DNS. If you have a higher risk profile, consider changing passwords on a regular basis.

Don’t just think about DNS hosting, depending upon your environment, your domains might be purchased via a different provider than who hosts your DNS zones. These accounts must also be protected.

I recommend, as does the CISA, that you make use of a password manager. This isn’t a post about the value of password managers, however their benefits are clear and well know. If you are unsure about what tools to use in your organisation, I recommend you look at LastPass Enterprise and 1Password for Business. My personal preference is LastPass due to its ability to use a Yubikey for MFA.

Action Three: Add Multi-Factor Authentication to DNS Accounts

I feel like this should be obvious to everyone by know. You need to use MFA for all accounts involved in the administration of your network.

If your domain registrar or DNS provider doesn’t provide MFA, then you must change to a provider that does. You might think I am being overly dramatic, but this is the only appropriate response. While the CISA directive doesn’t go this far, they are clear that you should ensure that you use a provider that does.

It should also be clear that providers that use SMS-based MFA are not recommended. It is just becoming to easy for attackers to perform sim-swap attacks.

Action Four: Monitor Certificate Transparency Logs

The last action point might sound a bit too difficult for small organisations and small IT teams.

Google’s Certificate Transparency project aims to address some of the structural flaws in SSL certificates. It provides an open framework for monitoring and auditing the issuance of certificates in real-time. It allows us to detect SSL certificates that have been issued by a certificate authority either legitimately, mistakenly issued or maliciously acquired. CT logs really do provide a way for the industry to monitor the CAs to ensure they don’t go rogue.

There are free and commercial tools available to monitor the CT logs. My preferred tool comes from a surprising source, Facebook. Facebook’s Certificate Transparency Monitoring tool allows anyone to search for certificates issued to a domain and to subscribe to notifications for a domain. This tool is rather simple to setup, but you will need a Facebook account and have alerts enabled on your account (and in your mobile apps if you want alerts going there).

Summary

To summarise, here is your DNS security checklist:

1. Switch to DNSControl and audit your DNS entries.
2. Use a password manager to manage the credentials for accounts. Change the passwords if you suspect a breach.
3. Use MFA for all DNS management accounts. If your provider doesn’t support MFA, change providers.
4. Use Facebook's Certificate Transparency Monitoring tool to identify all certificates being issued for domains you a responsible for.