160K COVID-19 Records: Vulnerability in Avicena Medical Laboratory

Electronic health records (EHR) and personally identifiable information (PII) are highly sought by cybercriminals to conduct fraudulent schemes. With the mass-influx of online health platforms created and pushed to production to track COVID-19 testing and allow wide-spread home healthcare, these often improperly secured solutions have been ripe for the picking.

Back in September, Tim Starks and Aaron Schaffer of The Washington Post revealed that the Department of Health and Human Services failed to implement basic protections against hackers when it developed a system called HHS Protect to track COVID-19 data in 2020. The inspector general report concluded that failing to implement security controls before deployment of HHS Protect left it “susceptible to an unknown and possibly unacceptably high risk of failure or compromise from unintentional disruptions (e.g., man-made or natural disasters) or cyberattacks.”

Similarly, we found that Avicena Medical Laboratory, based in Kosovo, was affected by an insufficient authorization controls issue which allowed unauthenticated users on the internet to query a specific COVID-19 Sample Number, in the form of a seven-digit number. This number was provided by Avicena Medical Laboratory on each COVID-19 test (regardless of its type). No authentication was required to exploit this vulnerability. Furthermore, given that the sample number was incremental, it would have been possible to enumerate all COVID-19 tests performed by Avicena Medical Laboratory, since the debut of Avicena-ks.org.

According to what we were able to evaluate, the first sample was registered on the platform on August 2, 2021, and it had the sample number 1100000. Sample number 1265690 was the most recent sample at the time of the writeup of this report (July 9, 2022, 2:57 p.m.). A simple subtraction shows us that the platform has almost 166,000 records, containing personal and medical data of its patients.

Vulnerability Details

Vulnerability Type: Incorrect Access Control

Access Vector: ​☒​ Remote, ​☐​ Local, ​☐​ Physical, ​☐​ Context dependent, ​☐​ Other (if other, please specify)

Impact: ​☐​ Code execution, ​☐​ Denial of service, ​☐​ Escalation of privileges, ​☒​ Information disclosure, ​☐​ Other (if other, please specify)

Security Risk: ​☒​ Critical, ​☐​ High, ​☐​ Medium, ​☐​ Low

Avicena results were printed or sent via email to their patients, and in this results sheet, there was a QR code, disclosing the avicena-ks.org application. In addition to the QR code, there was also a URL in the same sheet.

Below is the results sheet that was emailed or provided to patients as a printed piece of paper:

On the main page, the Avicena-ks.org application was configured in a way that allowed any user with a sample number to verify COVID-19 test results. No additional verification information was required. As a result, unauthenticated users could query any sample number, and thus, reveal and retrieve thousands of COVID-19 tests and patients records.

Avicena-ks.org returning COVID-19 test results:

To do so, the application was sending a POST request to the verify.php page with the sample number as shown below:

POST /verify.php HTTP/1.1
Host: avicena-ks.org
Cookie: PHPSESSID=6306764535e34c816e9af1c2fe1a1425
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:101.0) Gecko/20100101 Firefox/101.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 24
Origin: <a href="https://avicena-ks.org">https://avicena-ks.org</a>
Dnt: 1
Referer: <a href="https://avicena-ks.org/">https://avicena-ks.org/</a>
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
shipping=[SAMPLE_ID]&button=

And as expected, the response would provide detailed information about the test results, but it also included personal identification, such as the national ID number (the equivalent of social security numbers in the U.S.), first and last name, and the city listed by the patient:

HTTP/1.1 200 OK
Date: Sat, 09 Jul 2022 13:11:28 GMT
…omitted for brevity…
				 <h3><font  color="Black" face="arial,verdana"><strong>Rezultati?/Result?/Rezultat?</strong></font>: <span style="background: #E61925;"  class="label label-large" ><font size=4 color="White" face="arial,verdana">Pozitiv</font></span>   
				  </span>
		            
				</h3>
			</div>
		</div>
		<hr />
		<div class="row">
		  <div class="col-md-12">
			<h2>Informatat e Pacientit / Patient Informations</h2>
		  </div>
		  <br/>
		    <table class="table table-bordered table-striped table-hover" >
		      <tr><td><strong>Pacienti/Patient/Pacijent</strong></td><td>Dardan Prebreza</td></tr>
		      <tr><td><strong>Nr. personal/Personal No./Lični br. </strong></td><td>117[REDACTED]</td></tr>
		      <tr><td><strong>Data e lindjes/Date of birth/Datum rođenja </strong></td><td>[REDACTED]</td></tr>
		      <tr><td><strong>Gjinia/Gender/Pol </strong></td><td>M</td></tr>
		      <tr><td><strong>Adresa/Address/Adresa </strong></td><td>Prishtine</td></tr>
		      <tr><td><strong>Qyteti/City/Grad </strong></td><td>Prishtine</td></tr>
		      <tr><td><strong>Shteti/Country/Država </strong></td><td>Kosove</td></tr>
		  </table>		
		</div>
		<hr />
		<div class="row">
		  <div class="col-md-12">
			<h2>Informatat e Testit / Test Informations</h2>
		  </div>
		  <br/>
		 <table class="table table-bordered table-striped table-hover" >
		      <tr><td><strong>Nr. i mostres/Sample No./Uzorak br.</strong></td><td>[REDACTED]</td></tr>
		       <tr><td><strong>Tipi i mostres/Specimen Type/Tip uzorka</strong></td><td>PCR</td></tr> 		      <tr><td><strong>Data e marrjes se mostres/Date of sample</strong></td><td>2022-01-17 19:44:15</td></tr>
		      <tr><td><strong>Data e rezultatit/Date result</strong></td><td>2022-01-17 23:02:26</td></tr>
		      <tr><td><strong>Rezultati?/Result?/Rezultat?</strong></td><td>Pozitiv</td></tr>
		      <tr><td><strong>Testi/Test/Test</strong></td><td>RT-PCR</td></tr>
		       <tr><td><strong>Pershkrimi/Description/Opis/Rezultat</strong></td><td>SARS­CoV­2 (2019­nCoV)</td></tr>
…omitted for brevity…

To confirm the magnitude of the issue and prove that a malicious attacker could automate the process of sequentially retrieving almost 166,000 COVID-19 test results, we also automated a small set of this work by using Burp Intruder to check the results of the last 90 tests (as of July, 2022). Based on our results, it appeared, that out of these last 90 tests, 30 of them have tested positive, and as shown previously, it disclosed an important amount of PII data for each test, regardless of positive or negative.

Original Application Potentially Vulnerable

While reviewing the Avicena-ks.org homepage, it revealed that the software development company that built this application for Avicena, in fact used an existing PHP application meant for delivery and tracking. Thus, they used an existing tool and adapted it to Avicena’s needs. However, what is worth noting is that the version in use was outdated and potentially vulnerable. In addition to this, based on the MySQL errors that were returned to the end-user, there is a high probability that the same application is vulnerable to SQL injection attacks. However, due to its sensitivity, no attempts towards SQLi exploitation were performed. A successful SQLi exploitation could lead to a malicious user being able to update test results, delete test results and so on.

Vulnerability Details

Vulnerability Type: Vulnerable Software

Access Vector: ☒ Remote, ☐ Local, ☐ Physical, ☐ Context dependent, ☐ Other (if other, please specify)

Impact: ☐ Code execution, ☐ Denial of service, ☒ Escalation of privileges, ☒ Information disclosure, ☐ Other (if other, please specify)

Security Risk: ☐ Critical, ☐ High, ☐ Medium, ☒ Low

On the main Avicena-ks.org home page, the source code would reveal the application in use and its version, as shown below:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
     <title>Verify Results</title>
    <meta name="description" content="Courier Deprixa V3.2.2 "/>
    <meta name="keywords" content="" />
    <meta name="author" content="Jaomweb">

After looking for this application name on Google, it appeared that this version was from April 2017, and since then newer versions of the application were released by the vendor. In addition, it appeared that at some point the vendor moved to a newer platform and did not further update or maintain their original application. Given how old this PHP application was and its potential end-of-life (EOL), there is a high likelihood of this application being vulnerable to different kind of vulnerabilities, including SQL injections, as further explained.

While poking around with the application, a simple quote sent as shown in the following POST request, would trigger an interesting MySQL error:

POST /verify.php HTTP/1.1
Host: avicena-ks.org
Cookie: PHPSESSID=6306764535e34c816e9af1c2fe1a1425
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:101.0) Gecko/20100101 Firefox/101.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 19
Origin: https://avicena-ks.org
Dnt: 1
Referer: https://avicena-ks.org/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close

shipping=1'&button=

HTTP/1.1 200 OK
Date: Sat, 09 Jul 2022 18:48:51 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Length: 150
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''1''' at line 2

As previously explained, no attempts to exploit this issue were performed. However, this kind of message is usually an indication of a SQL injection vulnerability and given how old the PHP application in use was, the likelihood of having this issue resulting in a SQL injection is high.

Indicators of Compromise

After the initial report was shared with the Kosovo CERT (KOS-CERT), our team presented and reviewed the findings to KOS-CERT via a screenshare. During this time, Bishop Fox found that a server misconfiguration on mail.avicena-ks.org had directory listing enabled, which indicates that avicena-ks.org’s host had been compromised since November 2021. A PHP web shell was found on Avicena’s host server as shown below:

Despite letting Avicena know about the web shell via KOS-CERT around mid-July 2022, the web shell remained active and was not taken down until early October 2022 – almost three months later – and nearly a full year since the initial compromise in November 2021.

The web shell could have allowed anyone to upload a malicious PHP file and gain a remote shell on their host and eventually perform privilege escalation to the host provider. In Avicena’s case, this was IPKO, one of the largest telephony, internet, and cable providers in Kosovo. IPKO hosts a number of other local companies’ data, which could have resulted in a more widespread compromise situation. We don’t know if attackers were able to directly attack IPKO’s infrastructure or gain further access into their systems; however, given the longevity of web shell presence on Avicena’s host or server, an investigation could be useful to better understand what the attackers were able to do via the web shell and their eventual remote access to the server.

Below are the mailboxes of the Avicena employees, which were all accessible in cleartext using the web shell upload by the attackers:

Below is an example of an email from the [email protected] mailbox which contained a sales report from May 2022:

Finally, after reaching out to additional people via unofficial routes, Avicena took down their avicena-ks.org host/server, as shown in the screenshot below from October 24, 2022:

A Quick Summary

The use of illegal software by software developing companies remains an issue, as it puts at risk all data served by a given application. In Avicena’s situation, an outdated and vulnerable PHP application was most likely adapted/customized to Avicena’s needs, resulting in the exposure of more than 166,000 COVID-19 test results and PII data of patients. Additionally, the compromised host exposed all Avicena’s employees’ email addresses and their correspondence with others.

Finally, a successful privilege escalation from their host could have eventually led to the compromise of the host server and could have been used to pivot to other IPKO systems, putting at risk even more data from other companies and organizations. It is important for IPKO to perform a full cyber investigation to fully understand what the attackers were able to do on the compromised Avicena’s host and ensure that the data integrity of other IPKO customers hasn’t been affected.

While we understand that KOS-CERT has no executive power, it should have played a more pro-active role by reaching out to the Information and Privacy Agency (IPA – AIP in Albanian) and other instances, including the hosting provider, as the affected party (Avicena) refused to take down their application. We hope that cases like this will help to increase the awareness of companies and organizations to handle PII data more seriously and help governmental agencies to take quicker actions when serious violations are reported.

Timeline of events

• July 7, 2022: Confirmation of the Insufficient Authorization Controls vulnerability, which exposed all COVID-19 tests performed by Avicena since they started using the online application.
• July 9, 2022: While digging into the PHP application that was being used, it appeared that they were using an outdated and vulnerable version of it, which was customized to their needs. There was a strong likelihood that the version they used was a nulled PHP application, potentially backdoored.
• July 12, 2022: The initial responsible disclosure report was shared with KOS-CERT, and they acknowledged having received it on the same day.
• July 12, 2022: Using unofficial channels, a Zoom call and a screenshare of the report was organized with the head of KOS-CERT, where the initial responsible disclosure report was shared with them. During this same call, it was discovered that avicena-ks.org had in fact been compromised since November 2021.
• July 12, 2022: During that same Zoom call, KOS-CERT had been advised to contact both Avicena and IPKO, the provider to take down their host down as soon as possible, in case Avicena was delayed in doing so.
• July 26, 2022: Unofficially, KOS-CERT confirmed that they have been in touch with Avicena’s IT person, but they did not take any actions to take the application down.
• October 4, 2022: KOS-CERT was officially contacted once more time via email to gain situational awareness and determine why the Avicena-ks.org host and application was still up and running.
• October 7, 2022: KOS-CERT responded telling us that they cannot force Avicena to take down their application.
• October 13, 2022: Using unofficial channels, we have reached out to the Ministry of Internal Affairs (responsible for KOS-CERT). And they suggested reaching out to the Information and Privacy Agency (IPA – AIP in Albanian – Agjencia për Informim dhe Privatësi).
• Sometime between October 14 and October 24, 2022: The application and/or the host were taken down.
• October 23, 2022: The initial report that was shared with KOS-CERT was also shared with the AIP.
• October 24, 2022: A call and screenshare with AIP was organized, where the details and the impact of the findings were shared and explained to them. AIP ensured us that they would take the proper actions and handle the incident.
• November 14, 2022: A physical meeting between our researcher and the AIP took place in Prishtina, Kosovo, where the details of the report and the breach were discussed. Additionally, our researcher offered his time pro-bono to expand the AIP’s technical capabilities while handling current and future cases related to privacy issues.