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 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>SARSCoV2 (2019nCoV)</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.
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 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.
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:
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.
Subscribe to Bishop Fox's Security Blog
Be first to learn about latest tools, advisories, and findings.