[Updated Module] AzurePublicIPAddresses v1.0.14 has been released

A new version of the AzurePublicIPAddresses module has been released. This includes support for 8 new regions: UAE, South African, Chile, and Brazil. For more information see the Change Log.

Getting the Module

If you have never used the module before, the easiest way to get AzurePublicIPAddresses is through the PowerShell Gallery:

PS> Install-Module -Name AzurePublicIPAddresses

If you already have the module installed, you can update the module from the PowerShell Gallery with:

PS> Update-Module -Name AzurePublicIPAddresses

You can also download the release from the module’s GitHub Releases page.

Found an issue? Then raise any bugs or feature requests via GitHub Issues.

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!

Tickets now available: 2019 Global Azure Bootcamp Melbourne

Global Azure Bootcamp Logo

I am excited to announce that tickets are now avavailable for the Global Azure Bootcamp - Melbourne! This year the bootcamp will be on Saturday 27th of April 2019.

The Global Azure Bootcamp is a free one-day global event organised entirely by users in the community for Azure users around the world who gathered to share essential Azure and Cloud Computing skills and ideas at the seventh annual Global Azure Bootcamp in 2019. We are hosting this event in Melbourne, Australia, but there are many locations, in fact more than 100 other locations worldwide, where the Global Azure Bootcamp will be hosted on the same day.

This is an educational event, and we want it to be an opportunity for everyone to gain new skills. The focus of the event is to teach essential Azure skills to anyone in the technology community who wants to advance their cloud knowledge and the goal of the event is to show people the benefits of Azure while strengthening the Azure community.

Tickets are available via EventBrite, and typically sell out very quickly. We will be maintaining a waiting list once we run out of tickets.

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.

Call for Speakers: 2019 Global Azure Bootcamp Melbourne

Global Azure Bootcamp Logo

The 7th Edition of the Global Azure Bootcamp - Melbourne, Australia. This year the bootcamp will be on Saturday 27th of April 2019. The location will be announced once is it confirmed.

The Global Azure Bootcamp is a free one-day global event organised entirely by users in the community for Azure users around the world who gathered to share essential Azure and Cloud Computing skills and ideas at the seventh annual Global Azure Bootcamp in 2019. We are hosting this event in Melbourne, Australia, but there are many locations, in fact more than 100 other locations worldwide, where the Global Azure Bootcamp will be hosted on the same day.

This is an educational event, and we want it to be an opportunity for everyone to gain new skills. The focus of the event is to teach essential Azure skills to anyone in the technology community who wants to advance their cloud knowledge and the goal of the event is to show people the benefits of Azure while strengthening the Azure community.

Please consider followings when you submit your session:

• We welcome all submissions that talk about Azure and its services. From AI and DevOps to Infrastructure and Security and everything in between.
• Breakout Sessions are 45 minutes; Lightning talk are 15 minutes.
• We will not be able to cover travel or accommodations expenses.

The Call for Speakers will close on the 10th of March, with those successful being notified shortly after.

Tickets for attendees will become available on the 6th of Marth 2019.

Using the OpenSSH client included in Windows 10 (1809) as your Git’s SSH client

Microsoft has included an OpenSSH client with Windows 10 since the Fall Creators Release (1709). This client has been installed by default since the April 2018 Update (1803). The biggest benefit for the average user is that they can now use a supported OpenSSH client, without downloading and installing any other software.

I was setting up my new Surface Pro 6 and wanted to ensure that I was using the built in SSH client and particularly, the SSH Agent. If you are not familiar with the SSH Agent, it caches your private key, so you are not prompted to enter your password for your private key every single time you use it.

I spent some time getting everything to work and wanted to help anyone else who might be having issues.

Side: Why not just use the Credential Provider?

This is a good question! For most users, I recommend that they use the built-in Git Credential Provider. Personally, I prefer using SSH as it is the tool that I am more familiar and comfortable with it. It is just a personal preference.

Step 1 – Install Git

Download Git and install it as you normally would.

Step 2 – Ensure OpenSSH client for Windows is installed

Hit Start > Type “Optional Feature” > go to the Setting App. Check the “OpenSSH Client” is in the list of installed optional features, otherwise install it using the “Add a Feature” button.

Step 3 – Put your private SSH keys in the right directory, and specify the correct permissions

Get your existing private key (or generate a new SSH keypair) and place the private key into the .ssh folder in your user profile. By default, you can/should call the private key id_rsa and the public key should be id_rsa.pub.

The SSH key agent will check the permissions of your private key to ensure it is correctly secured. By default, it isn’t, so we will need to update the security permissions on this file by:

1. Removing inheritance (select copy when prompted).
2. Remove all users and groups except for SYSTEM and your user account.

Step 4 – Update your global Git configuration to use the OpenSSH for Windows

Next, we need to tell Git you use the OpenSSH client provided by Windows and not the one bundled with it. There are two ways you can do this, using the git config command, or directly editing the global configuration file directly.

Via the Git config command:

git config --global core.sshcommand "C:/Windows/System32/OpenSSH/ssh.exe"

Via the Git global configuration file:

[core]
    sshcommand = C:/Windows/System32/OpenSSH/ssh.exe

Step 5 – Change the start-up properties of the SSH Agent Service.

We will need to change the settings for the SSH Agent’s Windows Service. Using your favourite tool (PowerShell or Services.msc), change the start-up type of the service “OpenSSH Authentication Agent” from Disabled to Manual.

Optional – Start the SSH Agent when PowerShell loads

For the most seamless experience, we should automatically start the SSH Agent just prior to our first need of it.

To do this, I have added the following to my PowerShell profiles:

$sshAgentStopped = 'Stopped' -eq (Get-Service -Name 'ssh-agent' -ErrorAction SilentlyContinue).status
Write-Verbose -Message ('SSH Agent Status is stopped: {0}' -f $sshAgentStopped)

if ($sshAgentStopped) {
    Write-Verbose -Message 'Stating SSh Agent'
    Start-Service -Name 'ssh-agent'
}

If you don’t perform this step, you will need to manually start the agent, or will need to enter the password for your SSH private key every time you wish to use it.