A cloud service consists of one or more web roles and/or worker roles, each with its own application files and configuration. You can also script more advanced IIS and machine configuration changes that run at role startup, including tasks that require administrator control.

Threats and countermeasures for securing cloud services are listed below.

	Threats	Countermeasures
1	Remote desktop is enabled and the remote desktop password is compromised to login to the web or worker role instance. This may happen if an attacker guesses or brute forces the remote desktop password. Remote desktop password is shared across operations personnel. One of them leaves the organization and can still RDP into a web or worker role instance from anywhere on the internet. When logging into a role using remote desktop client, you get a certificate error since the RDP authentication certificate is self-signed. You may not be able to validate if you are under a man-in-the-middle attack. Such an attack can steal the RDP username and password. Articles related to this threat:- Hacked Via RDP: Really Dumb Passwords Virtual Machine hacking Worm spreads via RDP SSL man-in-the-middle attacks on RDP	Disable RDP on cloud services by default. Since web or worker roles can restart at any time, no planned installations or OS level configuration changes should be done by remote login. Use Start Up tasks instead. Similarly if you need to pull diagnostic information, use Windows Azure Diagnostics. There should ideally be no reason to RDP into role instances other than to troubleshoot issues.   If you must RDP into a cloud service instance, use a password generation tool to set a strong random password. Do not share the password with others. Disable remote desktop immediately after troubleshooting.   Enabling RDP on a cloud service is an auditable event. The change in configuration gets logged in the subscription operation logs. This should tell who enabled RDP and when. If password is not shared, correlating with security event logs from role instances will tell who logged in remotely to a role at a particular time.   When logging into a role using remote desktop client, you will get a certificate error since the RDP authentication certificate is self-signed. You cannot be sure if your RDP connection is under a man-in-the-middle attack, which is another reason to not use RDP on a production role instance.
2	End users may not be sure if they are connecting to the right web site/ web service hosted on a cloud service. Data transferred from an end user to a cloud service may be sniffed while in transit. Articles related to this threat:- Data-sniffing attack costs Heartland $12.6m	Configure a custom domain name for your cloud service. Use CNAME to map .cloudapp.net to your own domain name e.g. www.contoso.com.   Enable SSL or use WCF's message layer security on roles that accept incoming connections on input endpoints. The server authentication certificate should be valid and should chain up to a trust root authority. This certificate should be procured for your own domain name.   Use the "secure" attribute for all authentication cookies or cookies that have sensitive data in your web site, so that these cookies are sent only on SSL.
3	An attacker can access your cloud service from anywhere on the internet. If the application hosted on the cloud service is not built by following security best practices, it may be compromised. Articles related to this threat:- SQL Injection Leads To BigMoneyJobs.com Leak Confirmed: Snapchat Hack Not A Hoax, 4.6M Usernames And Numbers Published FTC and TrendNet settle claim over hacked security cameras	Limit the input endpoints on your cloud service to only those that really need to be exposed to the internet. Use internal endpoints or queues for inter-role communication.   If you are expecting traffic from a set of specific IP addresses only, use IP based filtering at the firewall, IIS or the application level. Your callers using cloud services can reserve an IP address to ensure their service's IP address doesn't change.   Implement authentication and authorization at the application level so that only authorized callers/ applications are allowed to call your web site or service.   Follow Security Development Lifecycle (SDL) and security best practices when developing applications deployed on cloud services, e.g. all end user input must be validated for a set of allowed characters.   To limit the damage if a cloud service is compromised, do not run the role instances with elevated permissions. If you need to run command or code as elevated, try to run it as an elevated startup task.
4	Cloud service role instances may not be patched. An attacker may exploit a known vulnerability to compromise the system. Articles related to this threat:- JBoss Worm Spreading via Unpatched or Unsecured JBoss Application Server	Guest OS has two update settings. 1) Automatic: Azure automatically patches Cloud services periodically. 2) Manual: You can manually set the Guest OS version. If you do this and do not update the Guest OS version, it may stay unpatched. It is recommended to use automatic patching.   If you install non-Microsoft software on your cloud service using a startup task, you must consider the patching mechanism for it.
5	End users may be allowed to upload files through your application hosted on a cloud service. An attacker may upload malware to try and compromise a role instance. Cloud service instances may be subjected to malware through other avenues. Article related to this threat:- Worm spreads via RDP	Enable anti malware on the cloud service role instances. End user uploaded files should be scanned for malware.   Monitor logs for malware related events.
6	If a role instance is compromised or is under attack, the operations personnel may not get to know about it. Since roles can recycle at any time and will do so when the Guest OS is patched, previous role logs will be lost.	Use Windows Azure Diagnostics to transfer logs from role instances to Azure storage.   Ensure all event logs, including security event logs are transferred. Transfer Azure diagnostic logs and IIS logs for web roles.   Monitor logs for signs of suspicious activity.   To limit access to logs, use a separate storage account for storing diagnostic data than the one used to store application data.   To know if logs are deleted, enable logging on the storage account to log delete requests.
7	Secret keys may be stored in your configuration files (Web.Config or .cscfg). The keys/ passwords may be used to connect to other Azure components. These application configuration files may be compromised. This could happen if the configuration files are stored without proper ACLs on the deployment server, or in the code repository or a backup location. Incidents related to this threat:- Old AWS API key led to search provider's cloud security breach Developers, Check Your Amazon Bills For Bitcoin Miners	Use separate subscriptions/ resources for production and test environments. Even if secret keys for test environments are compromised, real data will not be compromised.   Secure configuration files on deployment server or code repository using ACLs.   Encrypt secrets in configuration files. Even if production configuration files are compromised, the secret keys will not be compromised.   Rotate or change secret keys in configuration files periodically. This will limit the probability that a compromised secret key is still valid. To allow changing of secret keys, store them in the service configuration file and not in the Web.Config file. You can change service configuration files without re-deploying the cloud service.
8	Your cloud service is unavailable due to unforeseen circumstances. This may happen if there is an issue in the datacenter or a natural disaster that has caused a datacenter to go down. Article related to this threat:- Windows Azure Hit by Cloud Outage in Europe	Create a disaster recovery plan   Host your cloud service in multiple regions and use Azure traffic manager to failover to a secondary cloud service if the primary is down.
9	Attackers mount a denial of service attack on your cloud service in an attempt to bring it down. Articles related to this threat:- The Mighty Azure DDoS attack stymies vote in Miss Hong Kong beauty contest On our extended downtime, Amazon and what's coming	Windows Azure has a distributed denial-of-service (DDoS) defense system that helps prevent attacks against Windows Azure platform services. It uses standard detection and mitigation techniques such as SYN cookies, rate limiting, and connection limits. However, it is still possible for applications to be targeted individually   Monitor your cloud service's uptime and responsiveness. Monitor the cloud service metrics.   If you notice that your application is under attack, contact Windows Azure Customer Support to receive assistance.   Use Dynamic IP restrictions   Use CAPTCHA for scenarios where attackers might want to automate specific HTTP requests to consume resources.

Subscriptions help you organize access to cloud service resources. Compromise of a subscription can compromise all data and applications hosted in it. Threats and countermeasures for securing a subscription are listed below.

	Threats	Countermeasures
1	Spoofing of an account administrator, service administrator or co-administrator account to access the subscription. This could happen if the administrator's password is compromised may be by social engineering or brute-forcing or by compromising the administrator's local machine that is used to login to the Azure management portal. An employee who had access to a subscription using a Microsoft Account (Windows Live ID) leaves the organization, but can still access the subscription. Article related to this threat:- AWS console breach leads to demise of service with "proven" backup plan	Use organizational accounts or on-premise corporate identities instead of Microsoft accounts (Windows Live ID) to provision access to subscriptions. Set a strong password policy and require passwords to be changed periodically. Use Multi Factor Authentication to access the Azure Management portal. You can add Multi Factor Authentication to Azure Active Directory or enable Multi Factor Authentication on your on-premise STS (e.g. ADFS server). Limit the number of co-administrators to a minimum. To do so, use separate subscriptions for test and production environments, so that developers and testers do not need to be given access to production subscription and/ or use Role Based Access Control on the Azure preview portal to grant (owner/ contributor/ reader) access to subscription or to specific resources or resource groups. Periodically review the list of people who have access to a subscription, resource groups or resources. Administrators should ensure that the machines they are using to connect to the Azure portal have a secure configuration, e.g. should be patched and have anti-virus running. Monitor the subscription operation logs
2	A management certificate or a publishsettings file is compromised and is used to access the subscription. Or an administrator who had access to a management certificate leaves the company and may still have the certificate and be able to access the subscription. Articles related to this threat:- Old AWS API key led to search provider's cloud security breach Developers, Check Your Amazon Bills For Bitcoin Miners	Limit the number of management certificates being used in the subscription. When using PowerShell, prefer to use Add-AzureAccount to login using individual administrator organizational accounts instead of using management certificates. Periodically review the list of management certificates in the subscription. Ensure there is a valid reason for each. Change management certificates periodically and whenever someone who had access to the management certificate leaves the company. Do not store .publishsettings files, even for test subscriptions in your code repository or folder shares.
3	Someone takes an action on the subscription and it is not possible to tell who took the action and when.	Ensure that administrators are not using shared accounts to login to the Management Portal. They must use their individual organizational accounts or accounts that can be tied back to an individual. Limit use of management certificates to background jobs or scripts that need to run automatically. All other access should be done using organizational accounts either through the portal or using Power Shell. Subscription operation logs are available for the last 90 days. If you may need to know about actions taken earlier than that, archive the subscription operation logs.

The blog posts will outline threats to data and applications hosted on Azure and countermeasures appropriate to address each threat. This is work in progress and posts will be added and updated over time. For a good overview of Azure components, refer Introducing Azure.

Securing the Microsoft Azure subscription

Securing Cloud Services

Securing Azure Storage (to be added)

Securing Azure SQL Database (to be added)

The topics covered in the Webcast are:-

1. Configuring SQL Server service accounts with least privilege. Service isolation is also explained.

2. Configuring accounts connecting to SQL Server from a Web application (Principals) with least privilege.

3. Running xp_cmdshell with a proxy so that the account invoking xp_cmdshell need not be a sysadmin.

4. Running SQL Server jobs with least privilege.

The Webcast can be viewed here:-

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032415807&CountryCode=US

This is the scenario:-

1. There is a Web site that allows end users to upload their pictures.

2. On the Web server, the Web site is physically located at C:\Inetpub\wwwroot\sampleapp, which is obviously a virtual directory.

3. The uploaded pictures are stored on the file system in the following directory C:\Uploads\{username}. This is not a virtual directory. {username} is the logged in user’s username and can contain only alphabets and numbers.

This is what the page looks like to the end user.

This is the code that gets executed. The code for the UploadPicture.aspx.cs file is this.

   1: public partial class UploadPicture : System.Web.UI.Page

   2: {

   3:     protected void Page_Load(object sender, EventArgs e)

   4:     {

   5:         lblUserName.Text = "Welcome " + User.Identity.Name;

   6:     }

   7:     protected void btnSubmit_Click(object sender, EventArgs e)

   8:     {

   9:         new UploadHelper().UploadFile(fileUploadControl, User.Identity.Name);

  10:     }

  11: }

The code for the UploadHelper.cs file is this:-

   1: public class UploadHelper

   2: {

   3:     private string uploadFolder;

   4:     public UploadHelper()

   5:     {

   6:         uploadFolder = @"C:\Uploads\";

   7:     }

   8:     

   9:     private void SetUpUploadFolder(string userName)

  10:     {

  11:         uploadFolder += userName + @"\";

  12:         if (!System.IO.Directory.Exists(uploadFolder))

  13:             System.IO.Directory.CreateDirectory(uploadFolder);

  14:     }

  15:     

  16:     public string UploadFile(FileUpload fp, string userName)

  17:     {

  18:         string extension = fp.PostedFile.FileName.Substring(fp.PostedFile.FileName.LastIndexOf("."));

  19:         if (extension.ToLower() == ".jpg" || extension.ToLower() == ".gif")

  20:         {

  21:             string strFileName = fp.PostedFile.FileName.Substring(fp.PostedFile.FileName.LastIndexOf("\\") + 1);

  22:             SetUpUploadFolder(userName);

  23:             string strFullPath = uploadFolder + strFileName;

  24:             fp.SaveAs(strFullPath);

  25:             return strFileName;

  26:         }

  27:         return null;

  28:     }

  29: }

If I login to the Web site as “varun” and upload a picture with name mypic.gif, it gets uploaded to this folder on the Web server:-

C:\Uploads\varun\mypic.gif

Happy Hunting!

1. “validateRequest” is set to false.

   1: <%@ Page Language="C#" ValidateRequest="false" 

   2: AutoEventWireup="true" CodeFile="Default2.aspx.cs" Inherits="Default2" %>   

2. User supplied input is, without encoding, rendered back to the browser.

   1: protected void btnSubmit_Click(object sender, EventArgs e)   

   2: {            

   3:     Response.Write("Welcome " + Request["txtName"]);  

   4: }   

3. The Request object has been used ambiguously.

   1: Response.Write("Welcome " + Request["txtName"]);

What I mean by ambiguously is, that, a specific collection like Request.Forms or Request.QueryString has not been used to get the input parameter. If, Request[“txtName”] is used directly, the Web server searches the collections in the following order:

QueryString
Form
Cookies
ClientCertificate
ServerVariables

If “txtName” exists in more than one collection, the Request object returns the first instance that the object encounters [1]. As a result, if “txtName” is entered in the query string as well, it will be picked up from there and not from the form variable.

Therefore, an attacker can lure a victim into clicking a link like

http://server_name/firstwebsite/Default2.aspx?txtname=%3cscript%3ealert('xss')%3b%3c%2fscript%3e

If the victim clicks on this link, enters any name in the text box and clicks the submit button, script payload in the query string will execute in the victim’s browser, leading to cross-site scripting.

A much more secure way of writing the same code would be:-

   1: <%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default2.aspx.cs" Inherits="Default2" %>

   2:      <html xmlns="http://www.w3.org/1999/xhtml" >

   3:      <body>

   4:         <form id="form1" runat="server">

   5:          <asp:TextBox ID="txtName" runat="server"></asp:TextBox>

   6:         <asp:Button ID="btnSubmit" runat="server" Text="Submit" OnClick="btnSubmit_Click" />

   7:         <asp:RegularExpressionValidator ID="regexpName" runat="server"     

   8:                                         ErrorMessage="This expression does not validate." 

   9:                                         ControlToValidate="txtName"     

  10:                                         ValidationExpression="^[a-zA-Z'.\s]{1,40}$" />

  11:         </form></body></html>

   1: public partial class Default2 : System.Web.UI.Page

   2: {

   3:     protected void Page_Load(object sender, EventArgs e)

   4:     {

   5:     }

   6:     protected void btnSubmit_Click(object sender, EventArgs e)

   7:     {

   8:         if (Page.IsValid)

   9:         {

  10:             Response.Write("Welcome " +

  11:                 HttpUtility.HtmlEncode(txtName.Text));

  12:         }

  13:     }

  14: }    

References:-
[1] Request Object
http://msdn.microsoft.com/en-us/library/ms524948.aspx

Code for Default.aspx:-

   1: <%@ Page Language="C#" ValidateRequest="false" AutoEventWireup="true" CodeFile="Default2.aspx.cs" Inherits="Default2" %>

   2:  <html xmlns="http://www.w3.org/1999/xhtml" >

   3: <body>

   4:     <form id="form1" runat="server">

   5:  

   6:     <asp:TextBox ID="txtName" runat="server"></asp:TextBox>

   7:     <asp:Button ID="btnSubmit" runat="server" Text="Submit" OnClick="btnSubmit_Click" />

   8:     <asp:RegularExpressionValidator ID="regexpName" runat="server"     

   9:                                     ErrorMessage="This expression does not validate." 

  10:                                     ControlToValidate="txtName"     

  11:                                     ValidationExpression="^[a-zA-Z'.\s]{1,40}$" />

  12:  

  13:     </form>

  14: </body>

  15: </html>

Code behind Default.aspx.cs file:-

   1: public partial class Default2 : System.Web.UI.Page

   2: {

   3:     protected void Page_Load(object sender, EventArgs e)

   4:     {

   5:  

   6:     }

   7:     protected void btnSubmit_Click(object sender, EventArgs e)

   8:     {

   9:         Response.Write("Welcome " + Request["txtName"]);

  10:     }

  11: }

Reference:-

[1] How To: Use Regular Expressions to Constrain Input in ASP.NET
http://msdn.microsoft.com/en-us/library/ms998267.aspx

   1:     [WebMethod] 

   2:     public string GetEmpName(string empid) 

   3:     { 

   4:         SqlConnection con = new SqlConnection("server=.;database=test;uid=sa;pwd=PassW2rd12"); 

   5:         SqlCommand cmd = new SqlCommand("select username from users where id = " + empid, con); 

   6:         con.Open(); 

   7:         string empname = (string)cmd.ExecuteScalar(); 

   8:         con.Close(); 

   9:         return empname; 

  10:     }

How many did you get? Lets go over them one by one:-

1. The SQL connection string uses SQL Authentication to connect to the server. If possible, you should use Windows authentication instead. This eliminates the need to store credentials in the application.

2. If Windows Authentication is not possible, store the connection string in the web.config file and encrypt it using the aspnet_regiis tool.

3. The account used to connect to the SQL server is “sa”, which is a member of the all powerful sysadmin server role. Instead, the account used to connect to the SQL Server must have the least amount of permissions on the server as needed to do the job.

3. There is no validation for the “empid” parameter. If only integers are expected, try to parse it into an integer, otherwise use a regular expression for white list validation.

4. The “empid” parameters is being concatenated to form a SQL statement, which is then executed. This means that the application is vulnerable to SQL Injection. Instead of concatenating user input to create a SQL statement, use parameterized SQL.

5. There is no structured exception handling in this code. As a result, verbose error messages containing managed exceptions will be sent to the end user. Implement structured exception handling and close the connection in a finally block.

This is how the code looks after restructuring:-

   1:  

   2:     [WebMethod]

   3:     public string GetEmpName(string empid)

   4:     {

   5:         int id;

   6:         if (int.TryParse(empid, out id))

   7:         {

   8:             SqlConnection con = new SqlConnection(System.Web.Configuration.WebConfigurationManager.ConnectionStrings["Conn"].ConnectionString);

   9:             SqlCommand cmd = new SqlCommand("select username from users where id = @id", con);

  10:             cmd.Parameters.Add(new SqlParameter("@id", id));

  11:             try

  12:             {

  13:                 con.Open();

  14:                 return (string)cmd.ExecuteScalar();

  15:             }

  16:             catch (Exception exp)

  17:             {

  18:                 LogException(exp);

  19:                 throw new ApplicationException("An unexpected error occured");

  20:             }

  21:             finally

  22:             {

  23:                 if (con != null && con.State == ConnectionState.Open)

  24:                     con.Close();

  25:             }

  26:         }

  27:  

  28:         return null;

  29:     }

My colleague Sagar and I will be conducting an application security workshop at the NASSCOM – DSCI Information Security Summit 2008 on the 1st December in IIIT, Hyderabad, India.

More information can be found here:-

http://www.nasscom.in/Nasscom/Templates/CustomEvents.aspx?id=55164 

The agenda is here:-

http://www.nasscom.in/upload/59314/Agenda_Tutorial.pdf