Tuesday, March 12, 2013

Azure Management, PowerShell deployment, and a Forefront monkey wrench

How “Man-in-the-Middle” (MITM) interferes with Azure Management API authentication

A client needed an automated deployment of a PaaS web role into Azure using PowerShell.  I followed all appropriate steps up to the point of calling Publish-AzureServiceProject.  As the cmdlet progresses, it blows up at the point of verifying a storage account with an error “CData elements not valid at top level of an XML document. line 1 position 3”. Odd... 

I started researching: there seemed to be no relationship to PowerShell, Azure, or using Azure Management API.  Because some posts on troubleshooting this error indicated that it could be caused by a corrupt installation or configuration, we uninstalled and reinstalled anything Azure, and then even the .NET frameworks.  No difference whatsoever.  Some post mentioned that the content of the response that they could examine contained an authentication error that WCF/REST failed to properly parse.  I would have liked to pursue this lead: the only problem is PowerShell cmdlet is communicating over HTTPS, and it uses client side certificate to authenticate itself to the Azure Management API services.

Next, I made a copy of the project, put it on my (as opposed to the client’s) machine, and deployed it: typical “it works on my machine”.  While this sanity check was personally comforting, it did not get me any closer to the root cause of the error, and that little thing of client being able to deploy from THEIRS and NOT from my machine.

Providentially, a couple weeks back I was researching “Man-in-the-Middle” vulnerabilities of TLS and SSL and stumbled across MSDN articles about Forefront Endpoint Protection (like this).  This is similar to how Fiddler allows decryption of HTTPS traffic.

Since I wanted to examine the HTTPS requests and responses that caused the error message, I naturally tried to configure Fiddler.  When I had finished using Fiddler last time, I removed DO_NOT_TRUST Fiddler certificates from Trusted CAs.  That broke Fiddler’s configuration for HTTPS decryption.  I had to clean up certificates and the RSA work folder in C:\Users\\[username]\AppData\Roaming\Microsoft\Crypto\RSA\\[folder-with-big-name]\ to bring HTTPS decryption in Fiddler back from the dead.  After all this excitement on my machine was over, I was ready to see the request/response HTTPS traffic, on my machine first.  Then I got an HTTP 403 error at the same step of Publish-AzureServiceProject cmdlet.  image

I asked the client: “Do you happen to use Forefront HTTPS inspection in your organization?”  And what do you know!

We had their IT guys turn off Forefront HTTPS inspection on one machine.  We put the project there, ran Publish-AzureServiceProject, and we were in business!  It appeared that the error caused by Fiddler certificate based HTTPS “Man-in-the-Middle” was related to the original error caused by Forefront trying to inject itself between the PowerShell process with client certificate and the Azure Management services.

Thank God for drawing those lines in my head, one dot to the other, from “CData elements not valid at top level of an XML document. line 1 position 3” all the way to “Forefront is trying to read my encrypted traffic.”  I am thinking about contacting guys at Microsoft about defining Forefront configuration guidelines for these scenarios.

Thursday, January 10, 2013

Practical applications from “New Guidance to Mitigate Determined Adversaries’ Favorite Attack: Pass-the-Hash”

 

The scenarios described in the “New Guidance to Mitigate Determined Adversaries’ Favorite Attack: Pass-the-Hash” white paper could result in great, even catastrophic, impact on a compromised organization.  Countless organizations, large and small, are vulnerable, when their policies and practices are stacked up against the recommendations in the paper.  Here are several practical points (not silver bullets or solutions) that come to my mind as I was digesting the recommendations:

  1. Use “trusted” workstations to administer
  2. Administrators should have at least 2 accounts:
    • a standard unprivileged user account for regular work and login to their less secure, untrusted PC/workstation.  Writing Emails, browsing internet, writing documentation, research, etc.
    • an administrative account to login to trusted infrastructure from trusted workstation(s) to perform administrative tasks.
    • DO NOT MIX the usage of these two.
  3. Use AD group policy and internet proxy configuration to deny/disable communication via internet, email, IM, etc. and respective apps for the administrative domain and local administrator user groups and accounts.
  4. Disable NTLM protocol and use Kerberos, if possible.

In general, stay reasonably paranoid regarding your data and infrastructure .  “They ARE out to get you.”

Microsoft recommends these items among “Security Development Lifecycle” reading materials:

· Secure design, including the following topics:

· Attack surface reduction

· Defense in depth

· Principle of least privilege

· Threat modeling

· Secure coding, including the following topics:

· Cross-site scripting

· SQL injection

· Managed code security (transparency, code access security, assembly strong naming, etc.)

Saturday, October 6, 2012

Improving Security on Your Windows Box

Several years ago, I was reviewing my home router log out of curiosity.  I was surprised to see how many machines from every region of China and the rest of the world were attempting to break into my home network.  The number of malicious attempts can give you pause. Being of the mindset “you cannot be paranoid enough”, I have already been applying Microsoft’s and additional recommendations for secure computing practices since WinNT4 times. 

Here are a number of steps (most of them will cost you nothing, except time) that you can apply to your network firewall and Windows 7 PC or a Win2003/2008/2012 server to make them more secure. 

  • If you have not done so yet, educate yourself.  You can start here at Microsoft Safety & Security Center.
  • Run a good anti-virus service and keep it up to date!  I like Norton.  You can read AV reviews and decide for yourself.
  • Download and run Microsoft Baseline Security Analyzer.   Consider and apply recommendations, as long as they do not interfere with the way you intend to use your system.  Even if you do not apply all the recommendations, at least you will have a better idea what risks you are incurring by maintaining a larger profile for possible attacks.
  • Configure your extranet facing firewall to explicitly reject all inbound network traffic from IP ranges that should never have access to your LAN.  Here are some of my reasons:
      • I do not know and do not do business with anybody in China, or Brazil, or Egypt, etc.  Hence, I construe as malicious any attempts to access my LAN from systems in those parts.
      • You can use free MaxMind geo-IP databases to figure out IP ranges of different parts of the world to from which to reject traffic.  For individual lookups, I also use magic-net.
      • Here is a sample of some rejected Chinese IP ranges: 58.0.0.0-62.255.255.255,218.0.0.0-223.255.255.255,66.171.0.0-66.171.255.255,69.4.0.0-69.4.255.255,77.0.0.0-95.255.255.255,85.0.0.0-85.255.255.255,89.0.0.0-89.255.255.255,156.63.0.0-156.63.255.255
      • If you need to use Skype or some VoIP products to talk with people overseas, your can add Skype and other IPs to your firewall white list.
  • If your AV does not have its own firewall, configure Windows Firewall.  If it does, and it can be configured, add the same rejection rules as on the extranet firewall (see above).  Here you can also exclude specific systems or subnets that should not try to communicate with your box.
  • Here are examples of my Windows Firewall “deny” rules:

image

image

  • Tighten down other inbound application ports.  For example, if you want to allow Samsung AllShare to only accept traffic when on your home network, then make sure that only rules for “private” network are present, and you can define ports and an IP range from your home network in the “scope”.  The same principle applies if you are hosting an enterprise WCF service that should only be called by some webMethods services from specific hosts or from a certain subnet.
  • You can use some free network scanning apps to make sure you do not have services listening on ports that you do not intend.  For home use, I have found Android Fing to be quite helpful.
  • Install Microsoft EMET.  If you get tricked into clicking on a link that leads to a malware site, or you visit a legitimate site that is compromised, it may prevent some exploits.  Just read http://m.computerworld.com/s/article/9231367/Update_Hackers_exploit_new_IE_zero_day_vulnerability to understand the background.

These steps will make your system “more secure”, but they will not help you against DDOS style of attacks, or prevent you from clicking on a link referencing a malware site.  Nevertheless, taking simple steps to make your systems more secure can save you or your customers good money or extra work dealing with consequences.