Back in February I found an Android application which is used by the emergency services, that had exposed Azure API keys within the application leading to potential compromise of sensitive incident reports, attachments, and infrastructure server “.vhd” files with the access level to spin up new instances or delete them. I immediately reported this to the application developer and it’s respective organisation under responsible disclosure, which resulted in an instant and prompt response, which I give huge kudos for.

OWASP Defines this class of vulnerability as “Insecure Data Storage”:

Insecure data storage vulnerabilities occur when development teams assume that users or malware will not have access to a mobile device’s filesystem and subsequent sensitive information in data-stores on the device. Filesystems are easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores. Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data [1].

Vulnerability Details:

Firstly, when I saw the keys I went straight to Azure documentation to see what level of access such keys could give and Azure states that the account storage key is akin to the “root password” and that it should NOT be hard-coded or stored as plain text, where in this case it was embedded into an application “.apk” [2].

So you may be wondering, how did I obtain such keys from the APK? Well I used an online service named “http://www.javadecompilers.com/apk”, which decompiles APK files using JADX into zip format.

Next, I then used “grep -R ‘key’ .” to search for strings within the APK such as “password” “api” and “key” which resulted in the discovery of “Accountkey=XXX” and “AccountName=XXX” on further inspection. As you can see below within the “AzureConnection.java” file, both account name and account key was discovered along with the container name of “attachments”.

Next, I downloaded the Linux Azure CLI toolkit from Microsoft and connected to the instance issuing the “container list” function. This retreived some VERY Interesting containers such as ‘attachments’, ‘uploads’ and ‘vhds’. I was most intrigued of the fact, ‘vhds’ existed and after viewing the file names, it confirmed my suspicion that I had access to their server virtual machine files and could compromise their infrastructure with such access.

I then retrieved the contents of the ‘vhd’ container by issuing the command ‘storage blob list’ for the container ‘vhds’, which highlighted multiple server VHD files that I could download and/or modify.

Feedback/Suggestions:

I would suggest that the organisation reviews the application against the OWASP Mobile Testing Top 10 [1], to discover further vulnerabilities that could put the organisation at further risk.

An attacker with access to the vulnerability discovered, would be able to severely compromise the organisation due to the incident reports present on Azure, along with other sensitive files and information like Azure Cloud VHD files, which Microsoft recommends against storing in plain-text or hard-coded format [2], to prevent against this attack an API should be used between the application and Azure cloud server.

Finally, despite not being able to disclose the organisation name or application I would like to say thank you to them for handling this issue in a prompt and respective manner, which resulted in a good result for both parties involved, as now the application is secure.

References:

[1] https://www.owasp.org/index.php/Mobile_Top_10_2016-M2-Insecure_Data_Storage [2] https://docs.microsoft.com/en-us/azure/storage/storage-configure-connection-string [3] http://www.javadecompilers.com/apk

Disclosure Timeline:

17th February, 2017 at 01:32 GMT. Email sent requesting security contact information.
17th February, 2017 at 15:36 GMT. Response from vendor/org requesting full details.
17th February, 2017 at 16:00 GMT. Full technical details sent to company director.
17th February, 2017 at 16:13 GMT. Response from vendor/org stating they will look into it/resolve urgently.
16th July, 2017 at 22:50 GMT. Email sent asking for update on vulnerability resolution.
22nd July, 2017 at 13:21 GMT. No response, further email sent asking for permission if I can disclose with organisation name/details via Blog.
22nd July, 2017 at 23:35 GMT. Response received from company director. Company does not wish app or name to be included in disclosure.
23rd July, 2017 at 10:00 GMT. Full Disclosure via Blog.