arrow-left arrow-right brightness-2 chevron-left chevron-right circle-half-full dots-horizontal facebook-box facebook loader magnify menu-down rss-box star twitter-box twitter white-balance-sunny window-close
StaySafe.ph Fixes Sensitive Personal Information Exposure
5 min read

StaySafe.ph Fixes Sensitive Personal Information Exposure

StaySafe.ph Fixes Sensitive Personal Information Exposure


Update as of December 21, 2020 2:25 PM, MultiSys acted and fixed the vulnerability in their API. I also updated the title of this blog.

TL;DR: StaySafe's API was vulnerable to Sensitive Personal Information exposure and data of users might be exposed if they share their QR code online. So I'm highly recommending users to not share their QR codes to anyone or publicly, if not necessary, to avoid information exposure.

StaySafe.PH is the Philippines official health condition reporting, contact tracing, and social distancing system to assist the government on our fight against COVID-19.

The Inter-Agency Task Force for the Management of Emerging Infectious Diseases (IATF) has made use of the staysafe.ph contact tracing application mandatory for the national government agencies and local government units. (Source: IATF Resolution No.85)

The staysafe.ph application already went through the assessment of the DICT's Cyber Security Bureau. (Source: BusinessMirror) So I was confident that the application has already been tested and secured.

So for this blog, I will write about the security issue I discovered in the StaySafe's API.

After signing up and inputting my information, the application will provide a QR code that you may show to establishments for health check. Aside from that, I also found out that I can also scan someone else's QR code.

In that feature, I discovered a vulnerability that upon scanning someone else's QR code it will return or show you the whole Sensitive Personal Information (SPI) of the QR code owner.

To demonstrate and show you the impact of this vulnerability, I searched on Facebook for publicly posted StaySafe QR using this search query staysafe.ph QR code and I found at least 5 QR codes in just a few seconds.

Figure 1. Publicly posted StaySafe QR Codes

Screenshot below is one of many publicly posted StaySafe QR in social media sites.

Figure 2. StaySafe QR code downloaded from https://www.facebook.com/photo/?fbid=119499919973101&set=a.119499943306432

Scanning it with StaySafe's 'SCAN QR' feature, will return the page shown below.

Figure 3. Scan Result

Normally, when you scan a StaySafe QR it will just show you the health status and the first name (Code Name).

But on my end as an infosec enthusiast, I monitored the HTTP requests and responses from and to the StaySafe application. (P.S. No testing performed against the application.)

I then noticed that when I scan someone else's QR code, it will send an API request to https://ws.staysafe.ph/api/v1/me/profile/scan_qr containing the UUID of the QR code. The API endpoint will then display its response containing the Sensitive Personal Information of the QR code owner.

Figure 4. API's Response upon scanning

The following fields are included in the response of the API endpoint. (The field will return 'null' if the data was not provided.)

  • Full Name
  • Photo URL (Selfie)
  • Age
  • Gender
  • Full Address
  • Symptoms
  • Health Checklist
  • Company Name
  • Company Address
  • ID URL (Government ID)
  • Email Address
  • Family Member's Info

This vulnerability is actually similar to the LTO's Vulnerable API endpoint that could allow the malicious actor to authenticate to the app to get the necessary cookie/token/session, send the request to the API with the initial details from the victim, and store a copy of the response on its own server.

In StaySafe application, a malicious actor can create its own website that will ask the victim to scan their QR code to get the UUID and send the request to StaySafe's API. (But only few users will fall for that if they are aware about data privacy). After that, the response from the API endpoint will be sent back to the malicious actor's server to store a copy and display the result to their victim.

To properly show you the similarity of LTO and StaySafe's API, I created a simple flow chart below. (Read my blog about LTO here)

That is actually possible because both LTO's API and StaySafe's API has a permissive Access-Control-Allow-Origin header which is currently set to * (wildcard). It only means that anyone can use their API to send requests from external websites.

Figure 6. Permissive CORS header

I calculated the severity of this vulnerability and the result is High (7.5).

Figure 7. Severity of the vulnerability

Below is the explanation of my severity calculation.

Figure 8. Metric explanation

Fortunately, no signs of data breaches or leakage, and kudos to the parties involved for being responsive and fixing the vulnerability.

Recommendations to other contact tracing application

  • Properly configure the Access-Control-Allow-Origin header if it is currently set to * (wildcard). This is to avoid external parties from requesting to your API.
  • Limit the information in the API response. In staysafe's case, health status and code name only.
  • Include a note to users to not share/post their QR publicly.
  • If someone reported a potential vulnerability, make sure to investigate it properly and fix it as soon as possible if it affects the information of users.

Recommendations to StaySafe users

There might be other vulnerabilities on the application so I highly recommend everyone the following:

  • DO NOT share your QR code to anyone
  • DO NOT post it on social media sites
  • DO NOT give your full personal information because it's not required as per StaySafe

For the responsible disclosure, please see the timeline below:

Figure 9. Timeline of events

NOTES:

  • No exploitation is performed on the app. The vulnerability was found by simply using the Scan QR functionality.
  • Responsible Disclosure was followed properly. It started with responsibly disclosing it to the NCERT and communicating with them about updates and other stuff. I also gave enough time for them to fix the issue.
  • I'm just following the principle of Full Disclosure and the intent of this blog is to inform users about the issue. Read Full disclosure (computer security). Additionally, I initially informed them last Dec. 10 about the disclosure of this issue and did not received any extension request. 10 days after the informing them, I finally disclosed it.
  • With this kind of issue, affecting the sensitive info of millions of users, remediation of vulnerability must be applied ASAP but the issue is still there 15 days after reporting it.

UPDATE:

They fixed the vulnerability more than 2 hours after I disclosed this blog.

Figure 10. Updated API Response