Monthly Archives: November 2019

Talk: Running #Azure Securely – Granite State Code Camp #GSCC – Are all these security features for me?

Yesterday I had the opportunity to speak at the Granite State Code Camp (#gscc) in Burlington, MA. As part of my series of talks on Running Azure Securely, my talk today was around defense in depth and was called Running Azure Securely – which of these Azure security features are for me?. The session was interactive, engaging a third-of-a-dozen folks in the audience in a discussion of how to defend various workloads using the (fictitious) page of photos app as a foil.

Slide deck attached.

Also perhaps of interest – a similar talk from the other Burlington – at the recent VT Code Camp – which has a few add’l resources listed: https://blog.codingoutloud.com/2019/09/28/talk-running-azure-securely-are-all-these-security-features-for-me/

Talk: Running Azure DNS Securely

On 22-Oct-2019 I spoke at Boston Azure about network security and focused on some of the edges of using Azure DNS, and included some DNS subdomain hijacking awareness.

The command

dig CNAME bostonazuredemo.azuresecurely.com +short

will check public DNS records for a CNAME, returning whatever it is mapped to, if anything.

digging-dns-hijacking

In the above screenshot:

  1. nothing returned from dig – this is before any DNS entry was created for the demo subdomain
  2. a cascade of CNAMES are returned from dig – this is after a DNS entry was created for the demo subdomain – and it pointed at an Azure Web App — the cascade here includes my subdomain => an azurewebsites.net subdomain (bostonazuredemo.azurewebsites.net) => a second azurewebsites.net subdomain (waws-prod-dm1-139.sip….) => a cloudapp.net domain => and finally an IP address
  3. a single CNAME is returned from dig – this is after the Azure Web App was deleted (), but the DNS subdomain entry (bostonazuredemo.azuresecurely.com) was left intact – creating a dangling subdomain at risk of being hijacked — anyone who registered bostonazuredemo.azurewebsites.net (and it was open for anyone) would automatically have bostonazuredemo.azuresecurely.com already wired up to it.
  4. a cascade of CNAMES are returned from dig – but different than the first – this is after bostonazuredemo.azurewebsites.net was registered again, by a hacker, and bostonazuredemo.azuresecurely.com was hijacked

 

Some other notes from the session:

Subdomain takeover examples: