Since 2019, Huawei has been facing in the United States, but Huawei devices are still being used by millions of people elsewhere. Among the various effects that the ban has on Huawei, one of them is the lack of Google Play Services on their devices. Because of that, all devices released after May 2019 include a set of various Huawei apps named Huawei Mobile Services (or HMS) which includes their own app store, the Huawei AppGallery.

Note: A simple timeline can be found at the bottom of this post.

Update 05/19: After publication, Huawei reached out with a timeline to fix the AppGallery and apologized for the miscommunication and the late reply. Because the AppGallery works differently depending on the regions and due to various other factors, it's taking Huawei a few weeks to fix it. The vulnerability should be fixed for everyone by May 25th.

How it started

Back in Feburary 2022, a developer I know released an app on the AppGallery. While looking at the listing of the app, I started wondering how Huawei's API worked. After a few minutes, I finally figured out one API that took a package name as a parameter and returned a JSON object with the details of the app. At that point I didn't know what I would find later on, so I just tried the API with the package name of a known free app: Huawei's AppGallery itself.

Below is a partial example of a typical response

{
  "app": {
    ...
    "name": "AppGallery",
    "openCount": 0,
    "openCountDesc": "",
    "openurl": "",
    "permissions": [],
    "pkgName": "com.huawei.appmarket",
    "price": "0",
    "productId": "",
    "rateNum": "0",
    "recommImg": "",
    "releaseDate": "2022-04-20 17:03:53",
    "sha256": "2e1a1ce4e86cbfc87f05411a2585e557af78b893f6be85f8f6cb93f889faee05",
    "size": "50347219",
    "tagName": "",
    "updateDesc": "",
    "url": "https://appdlc-dre.hispace.dbankcloud.com/dl/appdl/application/apk/40/4037feaa91cf453ca2dd1ebf444aedaa/com.huawei.appmarket.2204201539.apk?sign=mw@mw1651866832368&maple=0&distOpEntity=HWSW",
    "version": "12.1.1.302",
    "versionCode": 120101302
  },
  ...
}

Among the details returned by the API, various fields were expected: various IDs, app version, logo & images, description, permissions, release date, price, etc. However, one of the fields returned was not expected: URL. The download link was working, but that didn't come as a surprise as I was testing a free app.

I remember thinking to myself that it would be wild if the field was also available for paid apps. And so, my next move was to try using the package name of a paid app. Surprisingly, this response included a similar download link to the paid app, with the same type of sign parameter at the end.

At this point I'm starting to think of what comes next. Which security Huawei must have put in place to secure the apps.

1. The url may need an additional parameter of some sort to be able to download the app? This was quite easy to verify. I tried the url in my browser, and it downloaded the right file, with the right SHA-256 hash.

2. Huawei may have some sort of API built into the apps available on their AppGallery? So I decided to try installing the app I had downloaded earlier and opening it. I was able to use the app sucessfully.

3. Maybe the app I tried had an issue and its license verification was mistakenly disabled by the developer? This time I tried 3 different apps. Or rather, 2 other apps, and 1 game. I was able to use the apps successfully. However, the game had a license verification on its own which failed to pass as I did not buy that game.

So now I had one thing to do: contact Huawei directly to report the vulnerability.

The consequences

When publishing an app on the AppGallery, developers expect a certain level of security. It shouldn't be possible to download paid apps for free without any verification or whatsoever. While I currently don't know if the vulnerability has been actively used, if it has, both developers and Huawei may be losing some of their revenue.

Additionally, the fact that apps are easily downloadable by anyone means that they can easily be the target of pirates. In other words, attackers could use the API to download a large amount of paid apps in a relatively short amount of time without having to pay for them and without even needing to go through the AppGallery.

Contacting Huawei

After searching for "Huawei vulnerability contact," I ended up on a page which advises you to use a PGP key to contact them. So, on February 17, using the PGP key I sent an email to Huawei explaining how I found the API, and what it returned, and why it was a vulnerability. They replied to my email just 5 hours later (in an unencrypted email, which also contains a copy of my original email) by saying they would investigate the issue, and by asking me not to disclose the issue before the analysis is complete. They also asked me to provide a disclosure plan in case I had any. I decided to give them 5 weeks, and also asked them to keep me up to date on the issue, to which they agreed.

After 5 weeks, the issue was still not fixed. I sent them 2 emails: one a few days before the final day, and one a few days after. They didn't reply to either of them. At this point I could have posted the issue publicly, but I decided to keep it private and wait a few more weeks as I realized that 5 weeks may not have been enough.

13 weeks later

It's been 13 weeks (90 days) since I sent my first email to Huawei. I never received any update on the vulnerability during those 13 weeks. The vulnerability itself isn't fixed, and paid apps can still be freely downloaded. Developers using Huawei's services were also not made aware of this vulnerability nor if/how they may have been affected. Huawei has been informed about the disclosure of this vulnerability, and finally, developers of apps I have tested have been notified as soon as this post was published.

After my last email — sent a day before this post was published — Huawei acknowledged the vulnerability and gave it an ID. They also offered a bounty, which I declined for personal reasons.

Timeline

Thanks Damien Wilde for the header