\n

We created a C# Azure function which loads a native DLL and calls the load function.

\n

\n

The load function brute forces the handles until it finds an open one whose name starts with “iisipm”. Then it constructs the malicious message and sends it immediately. As a result, DWASSVC crashes.

\n

Although we only demonstrated a crash, this vulnerability could be exploited to a privilege escalation.

\n

Impact

\n

Microsoft has various App Service plans:

\n\n

For more information, see: https://docs.microsoft.com/en-us/azure/app-service/overview-hosting-plans

\n

 

\n

Exploiting this vulnerability in all of the plans could allow us to compromise Microsoft’s App Service infrastructure. However, exploiting it specifically on a Free/Shared plan could also allow us to compromise other tenant apps, data, and accounts! Thus breaking the security model of App Service.

\n

Conclusion

\n

The cloud is not a magical place. Although it is considered safe, it is ultimately an infrastructure that consists of code that can have vulnerabilities – just as we demonstrated in this article.

\n

This vulnerability was disclosed and fixed by Microsoft and assigned as CVE-2019-1372.
\nMicrosoft acknowledged that this vulnerability worked on Azure Cloud and Azure Stack

\n","status":"PUBLISHED","fileName":null,"link":"https://research.checkpoint.com/2020/remote-cloud-execution-critical-vulnerabilities-in-azure-cloud-infrastructure-part-ii/","tags":[],"score":0.7926468849182129,"topStoryDate":null},{"id":"RS-23033","type":"Research_Publications","name":"Remote Cloud Execution – Critical Vulnerabilities in Azure Cloud Infrastructure (Part I)","author":null,"date":1580414446000,"description":"Ronen Shustin Cloud Attack Part I Motivation Cloud security is like voodoo. Clients blindly trust the cloud providers and the security they provide. If we look at popular cloud vulnerabilities, we see that most of them focus on the security of the client’s applications (aka misconfigurations or vulnerable applications), and not the cloud provider infrastructure… Click to Read More","content":"

Ronen Shustin

\n

Cloud Attack Part I

\n

Motivation

\n

Cloud security is like voodoo. Clients blindly trust the cloud providers and the security they provide. If we look at popular cloud vulnerabilities, we see that most of them focus on the security of the client’s applications (aka misconfigurations or vulnerable applications), and not the cloud provider infrastructure itself. We wanted to disprove the assumption that cloud infrastructures are secure. In this part, we demonstrate various attack vectors and vulnerabilities we found on Azure Stack.

\n

Check Point Research informed Microsoft Security Response Center about the vulnerabilities exposed in this research and
\n
a solution was responsibly deployed to ensure its users can safely continue using Azure Stack 

\n

Setting up a research environment

\n

Researching cloud components can be difficult, particularly as most of the time it’s “black box” research. Fortunately, Microsoft has an on-premise Azure environment called Azure Stack which is meant primarily for enterprise usage.  There is also a version called Azure Stack Development Kit (ASDK) which is free. All you have to do is get a single server that meets the installation hardware requirements and follow the detailed installation guides. Once the installation is finished, you will be greeted with the User/Admin Portal, which looks very similar to the Azure Portal:

\n

\"\"

\n

By default, ASDK comes with a small set of features (core components) which can be extended with features like SQL Providers, App Service and more. With that said, let’s see how ASDK compares to Azure.

\n

Main differences between Azure and ASDK

\n\n\n

Azure Stack Overview

\n

Note – Most of the data in this section is taken from this book

\n

\"\"

\n

Let’s break down the diagram by layers:

\n

First, we have the Azure Stack portal that provides a simple and accessible UI, along with Templates, PowerShell, etc. These components are used for deploying and managing resources and are the common interfaces in Azure Stack. They are built on top of and interact with the Azure Resource Manager (ARM). The ARM decides which requests it can handle and which need to be passed on to another layer.

\n

The partition request broker includes core resource providers in Azure Stack. Each resource provider has an API that works back and forth with the ARM layer. A resource provider is what allows you to communicate with the underlying layer, and includes a user/admin extensions that are accessible from the portal.

\n

The next layer underneath contains the infrastructure controllers which communicate with the infrastructure roles. This layer has a set of internal APIs which are not exposed to the user.

\n

The infrastructure roles are responsible for tasks such as computing, networking, storage and more.

\n

Finally, the infrastructure roles contain all the management components of Azure Stack, interacting with the underlying hardware layer to abstract hardware features into high-level software services that Azure Stack provides.

\n

ASDK is based on Hyper-V, meaning all of its roles run as separate virtual machines on the host server. The infrastructure has separate virtual networks that isolate them from the host network.

\n

 

\n

By default, there are several infrastructure roles that are deployed, including:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
NameDescription
AzS-ACS01Azure Stack storage services.
AzS-ADFS01Active Directory Federation Services (ADFS).
AzS-CA01Certificate authority services for Azure Stack role services.
AzS-DC01Active Directory, DNS, and DHCP services for Microsoft Azure Stack.
AzS-ERCS01Emergency Recovery Console VM.
AzS-GWY01Edge gateway services such as VPN site-to-site connections for tenant networks.
AzS-NC01Network Controller, which manages Azure Stack network services.
AzS-SLB01Load balancing multiplexer services in Azure Stack for both tenants and Azure Stack infrastructure services.
AzS-SQL01Internal data store for Azure Stack infrastructure roles.
AzS-WAS01Azure Stack administrative portal and Azure Resource Manager services.
AzS-WASP01Azure Stack user (tenant) portal and Azure Resource Manager services.
AzS-XRP01Infrastructure management controller for Microsoft Azure Stack, including the Compute, Network, and Storage resource providers.
\n

Source: https://docs.microsoft.com/en-us/azure-stack/asdk/asdk-architecture

\n

If we break down the main abstract layers in the diagram above into the main virtual machines:

\n\n

Let’s look at an example that demonstrates how all the abstract layers in the diagram work together:

\n

A tenant wants to stop a virtual machine in Azure Stack. How does this work?

\n
    \n
  1. The tenant can use the User Portal/CLI/Powershell to perform this action. All these interfaces eventually send an HTTP request which describes the desired action to the ARM (Azure Resource Manager), which runs on Azs-WASP01.
  2. \n
  3. The ARM performs its necessary checks (for example, check if the wanted resource exists, or if it belongs to the tenant),  and tries to perform the action. There are actions the ARM can’t handle by itself, like compute, storage and more. Therefore, it forwards the request with additional parameters to the correct resource providers which handles the virtual machine compute operations (which runs on Azs-XRP01).
  4. \n
  5. There is an internal chain of API requests until eventually the virtual machine located in the Hyper-V cluster is shut down. The result is forwarded back in the request chain to the tenant.
  6. \n
\n

In the following section, we describe in detail an issue we found in one of the internal services that allowed us to grab screenshots of the tenant and infrastructure machines.

\n

Screenshot grabbing and information disclosure

\n

Service Fabric Explorer is a web tool pre-installed in the machine that takes the role of the RP and Infrastructure Control Layer (AzS-XRP01). This enables us to view the internal services which are built as Service Fabric Applications (located in the RP Layer).

\n

\"\"

\n

When we tried to access the URLs of the services from the Service Fabric Explorer, we noticed that some of them don’t require authentication (usually there is a certificate authentication/HTTP Authentication).

\n

We had some questions:

\n\n

These services are written in C# and their source code is not public, so we had to use a decompiler to research them. This required us to understand the structure of the Service Fabric applications.

\n

One particular service that didn’t require authentication is called “DataService”. Our first task was to find where this service is located on the Azs-XRP01 machine. We found this easily by running a WMI query to list the running processes:

\n

\"\"

\n

The result revealed the location of all the service fabric services there are on the machine, including DataService. Performing a directory listing on the DataService code folder revealed a lot of DLLs. However, their names indicate their purpose:

\n

\"\"

\n

De-compiling the DLLs gave us the ability to explore the code and find the mapping for the API HTTP routes:

\n

\"\"

\n

We can see that if the HTTP URI matches to one of the route templates, the request is handled by a specific controller, which is a common REST API implementation. Most of the route templates require at least one parameter that we don’t necessarily know. Therefore, we first started looking at those that don’t require additional parameters:

\n\n

As Azure Stack runs locally on our machine, we can just locally browse these API to see how they respond.

\n

When accessing the virtualMachines/allocation API (QueryVirtualMachineInstanceView), it returns a large XML/JSON file (depending on the Accept header you send) which contains a lot of data about infrastructure/tenant machines located on the Hyper-V node in the cluster.

\n

\"\"

\n

This is a snippet from the information returned. We can see here interesting stuff like the virtual machine name and ID, hardware information like cores, total memory, etc.

\n

Now that we know there is an API that can provide information about the infrastructure/tenant machines, we can look at the API calls that require other parameters. For example, the VirtualMachineScreenshot looks interesting, so let’s see how it works.

\n

According to the template, several parameters must be supplied to route the request through the VirtualMachineScreenshot controller:

\n\n

When all of these parameters are provided, the GetVirtualMachineScreenshot function is invoked:

\n

\"\"

\n

If the virtual machine ID is valid and exists, the GetVmScreenshot function is called. This actually “proxies” the request into another internal service.

\n

\"\"

\n

We can see that it creates a new request with the specified parameters and passes it to the request executor. The internal service which will process this request is called “Compute Cluster Manager” (located in the Infrastructure Control Layer). From its name, we see that it manages the compute clusters, and can perform relevant actions. Let’s see how this service handles the screenshot request:

\n

\"\"

\n

First, we encounter this wrapper function, which calls another GetVmScreenshot on the vmScreenshotCollector instance. However, we can see that there is a new parameter,  a flag that determines if the compute cluster contains only a single host/node.

\n

\"\"

\n

After GetVirtualMachineOwnerNode figures out which node of the cluster the virtual machine is located on, it calls the GetVmThumbnail function:

\n

\"\"

\n

It seems like this function constructs a remote Powershell command which it executes on the compute node (this is how most of the compute operations work). Let’s look at the compute node and see how the Get-CpiVmThumbnail is implemented:

\n

\"\"

\n

This is the Powershell implementation of this function. It looks like it executes the GetVirtualSystemthumbnailImage which is a Hyper-V WMI call that grabs the thumbnail for the virtual machine. The thumbnail is the small window at the bottom left of the machine overview in Hyper-V:

\n

\"\"

\n

However, because of the option to specify dimensions, this is equivalent to a legit quality screenshot.

\n

Now that we have a good understanding of the primitives contained in “DataService”, let’s get back to our first question: Why doesn’t it require authentication? We actually don’t know the answer, but it should absolutely require authentication. We approached this by asking an additional question: In what scenario can we access this service from outside? The answer is SSRF, but where should we start looking? The obvious choice is the User Portal. It is accessible to the tenants and can access services such as ARM. On Azure Stack, it can even directly access the internal services.

\n

Azure Stack and Azure can deploy resources from a template. The template can be loaded from a local file, or a remote URL. It is a very simple feature and also interesting in terms of SSRF, because it sends a GET request to a URL to retrieve data. This is the implementation of the remote template loading (used as Ajax):

\n

\"\"

\n

 

\n

The GetStringAsync function sends an HTTP GET request to the templateUri and returns the data as JSON. There is no validation on whether the host is internal or external (and it supports IPv6). Therefore, this method is a perfect candidate for SSRF. Although this allows only GET requests, as we’ve seen above, it’s sufficient for accessing the DataService.

\n

So let’s use an example. We want to get a screenshot from a machine whose ID is f6789665-5e37-45b8-96d9-7d7d55b59be6  with the 800×600 dimensions:

\n

 

\n

\"\"

\n

The response we got is Base64 encoded raw image data.

\n

We can now take the data we got and transform it into an actual image. Here is an example using powershell:

\n

\"\"

\n

We will get this image:

\n

\"\"

\n

 

\n

Conclusion

\n

In this part, we showed how a small logical bug can sometimes be leveraged into a serious issue. In our case, because DataService didn’t require authentication, this eventually allowed us to get screenshots and information about tenants and infrastructure machines.

\n

In the second part, we will take a deep dive into Azure App Service internals and examine its architecture, attack vectors, and demonstrate how a critical vulnerability we found in one of its components affected Azure Cloud.

\n

The SSRF vulnerability (CVE-2019-1234) was disclosed and fixed by Microsoft, and was awarded $5,000 from Microsoft’s bug bounty program.

\n

The unauthenticated internal API issue had also been separately discovered by Microsoft, and had been addressed in late 2018 in Azure Stack 1811 update.

\n

In the next part, we disclose a critical vulnerability we found in the Azure App Service.

\n

 

\n","status":"PUBLISHED","fileName":null,"link":"https://research.checkpoint.com/2020/remote-cloud-execution-critical-vulnerabilities-in-azure-cloud-infrastructure-part-i/","tags":[],"score":0.5951376557350159,"topStoryDate":null},{"id":"RS-19424","type":"Research_Publications","name":"Man-in-the-Disk: Android Apps Exposed via External Storage","author":null,"date":1534129752000,"description":"Research By: Slava Makkaveev   Recently, our researchers came across a shortcoming in the design of Android’s use of storage resources. Careless use of External Storage by applications may open the door to an attack resulting in any number of undesired outcomes, such as silent installation of unrequested, potentially malicious, apps to the user’s phone,… Click to Read More","content":"

Research By: Slava Makkaveev

\n

 

\n

Recently, our researchers came across a shortcoming in the design of Android’s use of storage resources. Careless use of External Storage by applications may open the door to an attack resulting in any number of undesired outcomes, such as silent installation of unrequested, potentially malicious, apps to the user’s phone, denial of service for legitimate apps, and even cause applications to crash, opening the door to possible code injection that would then run in the privileged context of the attacked application.

\n

These Man-in-the-Disk attacks are made possible when applications are careless about their use of External Storage, a resource that is shared across all applications and does not enjoy Android’s built-in Sandbox protection. Failing to employ security precautions on their own leaves applications vulnerable to the risks of malicious data manipulation.

\n

In this post we will show how one WRITE_EXTERNAL_STORAGE permission can make it possible for an Android app to silently execute privileged code and install other apps.

\n

Overview

\n

There are two types of Android device storage:

\n\n

Before going any further, though, let’s take a deeper look at Android’s External Storage.

\n

Many high privileged systems and popular apps use Android’s External Storage as a temporary buffer when downloading data from the Internet. What’s more, many apps hold working data permanently in the External Storage since the device can often be limited by using the Internal space only.

\n

As all third-party apps installed on the device can observe data transferred by other apps via the External Storage, as well as overwrite a target file, various possibilities are available for a Man-in-the-Disk attack.

\n

Firstly, a malicious app can crash a target app’s native library which parses a storage located data file. This crash can lead to a code execution in the context of a privileged or popular app. Another attack is to hijack an app update flow, overwrite APK files and silently install a rogue app instead of a legitimate one. DoS and EoP vulnerabilities are also possible.

\n

The Fuzzing Tool

\n

Once we encountered an app that saves either data or configuration using the External Storage, we decided to use fuzzing techniques to try and search for vulnerabilities within the app. However, there are only Black Box Fuzzing available for Android, which would not be an efficient or sufficient, and therefore not really applicable, for our purposes. So in order to successfully test for vulnerabilities in the target apps our research team adapted an existing fuzzing tool (AFL) to run native Android libraries over the QEMU Emulator. This allowed us to run ‘Grey Box Fuzzing’.

\n

This tool consists of several parts including patched version of Android Runtime (libart.so), dalvikvm tool, GLib, QEMU and AFL. The assembly of these tools eventually allows to fuzz a user custom lib wrapped in a DEX file on an actual Android device or an ARM device emulator. The execution flow is as follows: AFL Fuzz Engine → QEMU ARM CPU emulator → dalvikvm tool → Android Runtime + adapter DEX.

\n

In the case of some of the apps below, for example Yandex or Google Translate, the ‘Grey Box’ fuzzing allowed us to mutate the translation package files in an efficient way until a lib crash was reached. In one case it took just 15 minutes to reach the crash, with the other it took half a day.

\n

Examples of a Man-in-the-Disk Attack

\n

Let’s take several examples of how a Man-in-the-Disk attack can be used. These vulnerabilities show that even the biggest Android vendors and developers make dangerous mistakes when working with the External Storage.

\n

Google Translate (com.google.android.apps.translate)

\n

Google Translate app downloads and holds off-line mode translation packages on external storage – /storage/emulated/0/Android/data/com.google.android.apps.translate/files/olpv3/v5/25/r11/ . These data files are processed by libtranslate.so app’s native lib upon entering the first letter for translation. The attacker can then generate a rogue binary, overwrite original files located in the external storage and crash the lib. This scenario does not require any file observation from the attacker side.

\n

\n

Video: A demonstration of a Man-in-the-Disk attack against Google Translate.

\n

Google Voice Assistance (com.google.android.googlequicksearchbox)

\n

The app downloads offline speech recognition languages to External Storage  (/storage/emulated/0/Android/data/com.google.android.googlequicksearchbox/files/download_cache/) as an archive and then decompresses machine learning related binaries in the app’s Internal Storage directory (app_g3_modes). The attacker can then overwrite downloaded files and crash libgoogle_speech_jni.so app’s native lib.

\n

\n

Video: A demonstration of a Man-in-the-Disk attack against Google Voice Assistant.

\n

Xiaomi Browser (com.android.browser package)

\n

The Xiaomi Browser downloads a self-updating APK file to External Storage /storage/emulated/0/Android/data/com.android.browser/files/update, verifies SHA1 and installs the APK. The attacker can then overwrite the updated file right after verification since verification and installation are two separated and manually invoked actions.

\n

\n

Video: A demonstration of a Man-in-the-Disk attack against Xioami Browser.

\n

Yandex Translate (ru.yandex.translate)

\n

The Yandex Translate app downloads and holds offline mode translation packages on External Storage – /storage/emulated/0/Android/data/ru.yandex.translate/files/offline/translation/ . The same process follows as was seen with Google Translate, but in this case a different libmobile-android.so native lib is under attack.

\n

\n

Video: A demonstration of a Man-in-the-Disk attack against Yandex Translate.

\n

Yandex Search (ru.yandex.searchplugin)

\n

Yandex Search downloads and holds offline mode search packages on External Storage – /storage/emulated/0/Android/data/ru.yandex.searchplugin/files/edge_search_dicts/. The attacker can then generate a rogue binary, overwrite the original file located in External Storage and crash liboffline_search-data_reader.so app’s native lib.

\n

\n

Video: A demonstration of a Man-in-the-Disk attack against Yandex Search.

\n","status":"PUBLISHED","fileName":"//research.checkpoint.com/wp-content/uploads/2018/11/august_android_exploit-300x170.jpg","link":"https://research.checkpoint.com/2018/androids-man-in-the-disk/","tags":[],"score":0.4416694939136505,"topStoryDate":null}],"mapData":null,"topMalwareFamilies":null};