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.

DNS Squatting with Azure App Services

TL DR

• SaifAllah benMassaoud from Vulnerability Lab discovered that resnet.microsoft.com was resolving to resnetportal-prod.azurewebsites.net, however there was no Azure App Service at this address.
• Anyone could have established an App Service with this DNS name, and thus squat on a microsoft.com subdomain.
• This vulnerability has the potential to affect any organisation that is using App Services (or similar PaaS services) and custom domain names where they do not have appropriate controls in place.

Like many involved in the InfoSec industry, I monitor a bunch of vulnerability disclosure feeds. They can be a valuable source of knowledge: new techniques, new bugs, new breaches or just interesting tools and technology.

Several days ago, a post titled: Microsoft Resnet - DNS Configuration Web Vulnerability grabbed my interest. It has an innocuous title, and I hadn’t recalled anyone else talking about a Microsoft DNS Vulnerability. The post wasn't that long, the description and the proof-of-concept are only a few paragraphs in length; however what I did discover was an interesting vulnerability, one that, I feel, is going to become more and more prevalent with the use of Platform As A Service (PaaS) technologies like Azure App Services.

Simply put, in this situation, someone had created a CNAME entry within Microsoft’s DNS to point resnet.microsoft.com to resnetportal-prod.azurewebsites.net, unfortunately, resnetportal-prod.azurewebsites.net didn’t exist. This doesn’t sound that bad? Right?

For those who are not familiar with the azurewebsites.net domain, this is the domain used by Azure App Services to host services. When you create an App Service, you specify a name, like myawesomewebapp.azurewebsites.net, you can then deploy your application to that App Service. You can pick whatever you want as the applications name, as long as no one else has taken it before you.

You can optionally specify a custom domain name for your App Service, like myawesomewebapp.com, and use a CNAME entry to map your custom domain to your azurewebsites.net domain (you can now also use an A record).

You should now be able to see the problem; resnetportal-prod.azurewebsites.net didn’t exist yet the name resnet.microsoft.com was pointed to this App service. What does exist is a great squatting/hijacking opportunity. Anyone could have signed up for an Azure Subscription, created an App Service with the name resnetportal-prod.azurewebsites.net and then hijacked resnet.microsoft.com. Vulnerability Lab maanged to discover a pretty significant issue.

What could one do with a subdomain of microsoft.com? Phishing, credential theft, and ransomware comes to mind pretty quickly. I am sure an APT crew would love to have a domain or subdomain like this. There are probably only a few domain names in the world where the average user and even the average system administrator are extremely trusting, and microsoft.com would have to be one.

It isn't just the big organisations like Microsoft at risk. Any company that makes use of PaaS services like Azure App Services and CNAME entries could potentially become the next victim. Attackers might use your domain name to attack others or perhaps create more effective attacks against your own users.

Let’s consider our friends Contoso Limited; they deployed an application for their users to contosoapp.azurewebsites.net, they also established a custom domain name, home.contoso.com. The app was used for some time, and eventually they decide to decommission it. A developer, maybe a sysadmin deletes the Azure App Service, but in their haste, they forget about the DNS entries. More time goes by, and now Bob from an APT group finds the entry for home.contoso.com pointing to contosoapp.azurewebsites.net, he then goes and sets up his own App Service and hijacks home.contoso.com.

Bob the sends out this email to some Contoso email addresses:

Subject: New Employee Experience
From: Contoso Marketing
Body:
    Hi Team,

    We have launched a new employee portal, it is great and has a bunch of awesome features. The site can be found at http://home.contoso.com. 

    From,

    The Contoso Marketing Team

Bob doesn’t even need to hide the links in the email, he doesn’t need any of the usual masking techniques, he can simply display the company’s domain name. If the email structure, text and links are well crafted, how would Fred from Accounting determine if this was a legitimate email?

When a user navigates to the page, perhaps it prompts for credentials, maybe it tries to run a browser exploit? I have no doubt that a campaign against an organisation like this would be extremely successful.

Now the details of how SaifAllah benMassaoud from Vulnerability Lab initially discovered the misconfiguration are not described in the release. I am going to guess that he probably used an automated DNS enumeration tool like DNSRecon and DNSNinja. These make the discovery of DNS records easy, and it would be easy to automate additional checks based upon their results to find vulnerable configurations.

In terms of defending against these issues, there are two methods, both of which need to be implemented by organisations:

1. Appropriate change control processes: If an App Service or similar PaaS solution is being decommissioned, processes should be in place to ensure that any associated DNS records are removed;
2. Monitor your DNS zones for configuration issues: Have automated scripts that check and send alerts if configuration issues are found.

If you haven’t looked at a DNS management tool like DNSControl, do so now! DNSControl was originally developed by Stack Overflow, and you don’t need to have hundreds of domain names and records to gain value from a tool that allows you to manage DNS as code.

DNSControl uses a Domain Specific Language for defining domains and their records, independently of your provider. You can use macros and variables to simplify your configuration. My favorite features is the ability to configure multiple DNS providers, this is great for migrations and for fault tolerance. The CloudFlare provider still allows for control over their proxy as well, ensuring that all of our configuration remains in source control.

Defending against this vulnerability is fairly simple, practice good change control processes and monitor your DNS zones. DNS enumeration tools like DNSRecon and DNSNinja can also assist in determining your organisations risk, whilst DNS as code tools like DNSControl will give us better control over our DNS change processes.

Kieran Jacobsen

Enabling Mobile Device Management with Office 365

Microsoft recently announced that they would be including a Mobile Device Management (MDM) platform as part of Office 365. What this means is that organisations, both small and large now have an extremely easy and powerful MDM available to them, without any additional charge to their Office 365 licencing. Administrators can manage Android, iOS and Windows Phone devices, and enforce various corporate policies and standards.

To support the new MDM functionality, you will need to create two new DNS records in each of your Office 365 domains. I have updated the Posh-Office365CloudFlare script to support the creation of these two additional records. You can create these records via the -MDMEnable parameter.

The process for creating the entries is as simple as:

Register-Office365.ps1 -CloudFlareApiToken <token> -CloudFlareEmailAddress <email> -Domain <domain> -MDMEnable

Just a quick note, I am yet to fully test out the new MDM functionality as none of my existing tenants have enabled for it yet. 

Kieran Jacobsen

Posh-CloudFlare managing CloudFlare using PowerShell

The aim of the Posh-CloudFlare module is to simply and automate the management of CloudFlare hosted DNS zones using PowerShell and the CloudFlare Client API. I have made the module available via the PoshSecurity GitHub, here Posh-CloudFlare.

I started looking at CloudFlares API several months ago, as part of another post which I am still working on. Back then I was simply looking at the creation and deletion or records.

Things changed when I found that I needed to spend quite a bit of time working with DNS. Provisioning new infrastructure within cloud environments is something I spend a significant amount of time doing, and am actively investigating the automation of it, and as such, become interested in other parts of the API.

This module now implements all of the Client API, with 22 CMDLets in total. To simplify things, I have documented what CMDLet maps to what API call below:

CMDLets	API Actions
get-CFDNSZoneStatistics	3.1 - "stats" - Retrieve domain statistics for a given time frame
get-CFDNSZone	3.2 - "zone_load_multi" - Retrieve the list of domains
get-CFDNSRecord	3.3 - "rec_load_all" - Retrieve DNS Records of a given domain
get-CFDNSZoneStatus	3.4 - "zone_check" - Checks for active zones and returns their corresponding zids
Get-CFIPThreatScore	3.6 - "ip_lkup" - Check threat score for a given IP
get-CFDNSZoneSettings	3.7 - "zone_settings" - List all current setting values
Set-CFDNSZoneSecurityLevel	4.1 - "sec_lvl" - Set the security level
Set-CFDNSZoneCacheLevel	4.2 - "cache_lvl" - Set the cache level
Set-CFDNSZoneDevMode	4.3 - "devmode" - Toggling Development Mode
Clear-CFDNSZoneCache	4.4 - "fpurge_ts" -- Clear CloudFlare's cache
Clear-CFDNSZoneFileCache	4.5 - "zone_file_purge" -- Purge a single file in CloudFlare's cache
Add-CFBlackListIP Add-CFWhiteListIP Remove-CFListIP	4.6 - "wl" / "ban" / "nul" -- Whitelist/Blacklist/Unlist IPs
Set-CFDNSZoneIPVersion	4.7 - "ipv46" -- Toggle IPv6 support
Set-CFDNSZoneRocketLoader	4.8 - "async" -- Set Rocket Loader
Set-CFDNSZoneMinification	4.9 - "minify" -- Set Minification
Set-CFDNSZoneMirage2	4.10 - "mirage2" -- Set Mirage2
New-CFDNSRecord	5.1 - "rec_new" -- Add a DNS record
Update-CFDNSRecord	5.2 - "rec_edit" -- Edit a DNS record
Remove-CFDNSRecord	5.3 - "rec_delete" -- Delete a DNS record

The Client API can be a little tricky at first, I have developed the CMDLets in a manner to simplify the learning curve. Typically any API call which modifies or removes a DNS record, would require a rec_id to be specified. This field can be found by querying all of the records in the zone. I have simplified things by performing the search and other API queries for you. You can still specify a rec_id if you like.

Switches and parameter validation sets have been used to simplify some of the other CMDLets, particularly those around minification, security and other zone wide settings.

Finally I have tried where possible to make good use of the Pipeline. There are still a number of areas that could be improved.

Getting Started

The first thing you will need to do, is obtain your API Token. This can be found on your Account page. You will need this, and the email address you use to sign into CloudFlare for the majority of the CMDLets. For CMDLets which modify DNS Zones or records, you will need to specify the zone as well.

To obtain the module, simply perform a git clone to your preferred module location as below:

I have included a demo script, Posh-CloudFlare-Demo.ps1 at the root level of the module, which you can run on the namespace of your choice. I recommend not using your corporate production domain. At the top of this script, simply update the API Token, Email and domain name fields as required.

You can then run the script, and see it manipulate the DNS zone. I am not responsible if this breaks production. This script shows you each CMDLet and it's output. I don't recommend simply running the script, I recommend stepping through each line so you gain more of an understanding.

Potential Uses

The automatic provisionment of cloud hosted environments is why this was developed as well as another project I will announce in the coming future. For now, I see myself working on at least one module to support the automation of Office 365 provisioning, including creating the TXT, MX and SRV required.

Warnings

Firstly, I haven’t finished up the PowerShell help – Naughty! I will work on this one as I go.

Secondly, there might be some bugs. Whilst I have tried to test the majority of the permutations of the code, I can’t be fully sure I haven’t missed something. If you find one, please feel free to contact me and I will make the required fixes, or even better, push your updates up to GitHub.

Kieran Jacobsen

Windows DNS and BIND Server together

Another one of my bulk DNS scripts.

This was a weird request however there were a number of requirements:

• Allow BIND servers running on Linux/Unix to take zone transfers of all production zones (forward and reverse), this should be limited to specific servers.
• BIND servers should only be allowed to request one transfers from specific servers
• Only authorised BIND servers should be permitted
• BIND servers SHOULD be listed in a name server query for a particular zone (that is, BIND servers should have an NS record)

The script is pretty simple:

Bulk import of DNS PTR Records

Due to a number of issues, I was once required to delete some reverse lookup zones in DNS and then recreate them. There were two reasons I had to do this, firstly there were some conflicting replications configurations, secondly I was merging some DNS servers and finally I was making the reverse look zones class B instead of 2 dozen class C zones.

Before I start, there is one limitation with this script. All of entries you are importing must belong to the same reverse lookup zone. For example, this script would handle importing entries of 10.0.0.23, 10.0.0.55 into a reverse lookup zone of 10.0.0.0/24 or even 10.0.0.0/16; however it will fail if you try to import those entries into a zone of 172.16.0.0/24.

This script I wrote for these sort of situations, and many others. Whenever doing this work, I have always had a resulting CSV file with my entries that I need to end up back in DNS. This file has had the following format:

host, ip

hostname1.domain.local, 10.0.0.1

hostname2.domain.local, 10.0.0.2

Once you have a CSV file of the above format, point the following code at it:

$filename = read-host "CSV filename"
$dnsserver = Read-Host "dnsserver"
$namespace = read-host "namespace - format 201.168.192.in-addr.arpa"
$entries = import-csv $filename
foreach ($entry in $entries) {
    dnscmd $dnsserver /recordadd $namespace $entry.ip "ptr" $entry.host
}

DNS Cleanup - Removing an old DNS Server

The script that is outlined below was written very quickly one night. The issue was we had several old decomissioned/dead DNS servers in the environment, and a lot of DNS namespaces to remove them from (aproximately 10 forward and 20 reverse lookup zones). It should be noted that this script assumes we can make a change on a single master server and replication (hopefully AD Integrated) will take care of the rest.

Enjoy.

$masterdns = "<Primary DNS FQDN>"

$olddnshost = read-host "Enter new host name (FQDN)"

$enumzones = get-WMIObject -Computer $masterdns -Namespace "root\MicrosoftDNS" `
    -Class "MicrosoftDNS_Zone"

foreach ($zone in $enumzones)
{
    if ($zone.zonetype -eq 1)
    {
        write-host ""
        $name = $zone.name

        dnscmd $masterdns /recorddelete $name "@" NS $olddnshost
       
        Write-Host "NS Record for "$olddnshost " deleted from "$name
    }

}