Two major flaws in Azure App Services were recently discovered involving Linux an open source and community-developed operating system.
Azure Insight
For the last decade, AWS, Microsoft and Google have been introducing new and innovative platforms to the Cloud. While AWS was first to the launch their IaaS platform in 2008, Microsoft and Google were not far behind. Windows Azure was released commercially in 2010 offering over 600 services and benefitting mostly from SaaS. Azure App Service is a cloud computing-based platform that is used as a hosting web service for building web apps and mobile backends. Taking business to the cloud is a way to facilitate storage, networking, and processing power through natural language processing and artificial intelligence as well as standard office applications. As the market continues to bring on new challengers for the top spot AWS, Microsoft and Google have held strong to their positions. Today each company offering multi-cloud platforms has reached the multi-billion dollar per year increase in market share. For a list of Top Grossing Cloud Earners, click here. Although these companies are introducing new products at an astonishing rate, infrastructure needs to be a top priority.
Open Source Vulnerabilities
Vulnerabilities are inevitable when using open source operating systems because public coalition can work for the greater good or compromise security. Azure App Service’s first vulnerability was discovered by way of docker environments. Running virtual machines or containers in the cloud is one of the most popular uses for Microsoft Azure. These containers can host multiple components such as domain name system servers, Windows Server services or third-party applications. Containers within the docker hold two separate nodes one for management and one for the application. Also, two domains are registered to the app’s HTTP web server and the application administrative page, leaving Kudu open for continuous deployment of applications. The vulnerabilities, Paul Litvak from Intezer Labs, found allows actors to takeover KuduLite which is considered an escalation flaw.
Azure deployments on Linux environments are managed by a service called KuduLite, which offers diagnostic information about the system and consists of a web interface to SSH into the application node (called “webssh.”)
Linux was originally developed for personal computers based on the Intel x86 architecture, but has since been ported to more platforms than any other operating system. By taking over hard-code credentials (root:Docker!) it is possible to SSH into the instance and log in as root, giving permission to the actor to take control over the SCM (Software Configuration Management). By gaining access to the SCM actors can manipulate the machine by screening a user’s HTTP requests to the web page, add various pages, and insert malware.
API Requests
The second vulnerability for Azure App Service’s still stems from the application node and involves a false request to the Kudulite API. This false request is referred to as SSRF (server-side request forgery) and this vulnerability can infiltrate the application node’s system and potentially steal source code and vital system information such as credentials and PII. In typical SSRF examples, the attacker might cause the server to make a connection back to itself, or to other web-based services within the organization’s infrastructure, or to external third-party systems. By forging a POST request these actors can remotely execute code from the application mode via the command API. By using these vulnerabilities in tandem actors can rewrite arbitrary codes and potentially takeover administrator system controls. Actors can change HTTP requests to navigate unsuspecting consumers to false web pages. Not only are consumers are affected but administrators are at risk of total system takeover that can jeopardize their entire business or application. An SSRF exploit that causes connections to external third-party systems might result in malicious onward attacks that appear to originate from the organization hosting the vulnerable application, leading to potential legal liabilities and reputation damage.
Third-Party Vendor Security Tips
Applications running third-party systems are advantageous for software integration and open to the public for collaboration. By having third party systems operating for applications administrators need to be aware of the security risks that can affect their applications and consumers in various ways. There are three main vulnerabilities when implementing third party systems that all business and applications should be observing.
- Data Breach and Ransomware – Businesses need to limit the scope of a vendor’s access to systems and data often referred to as least privileged access. Malware such as ransomware can quietly encrypt data for weeks, overwrite backups and compromise businesses by paying the ransom.
- Non-compliance – legal and industry regulations can occur when an outsourced provider has inadequate control systems and knowingly or accidentally causes a customer to violate that regulation. To mitigate mandatory non-compliance regulation violations involves implementing an effective vendor privileged access management program.
- Down times and Outages – down time and outages can occur both from damage done during the attack or from time to restore systems to an uninfected state.
Implementing a good vendor management system, including policies, procedures, and technology solutions does more than prevent and mitigate disaster. Having all vendor-related information in a single place can influence your decision-making process and protect the bottom line.
Source code security plugin flickr photo by Christiaan Colen shared under a Creative Commons (BY-SA) license
