Hyland OnBase Log Injection ≈ Packet Storm – Digitalmunition




Exploit/Advisories no-image-featured-image.png

Published on September 9th, 2020 📆 | 5643 Views ⚑

0

Hyland OnBase Log Injection ≈ Packet Storm

CVSSv3.1 Score
————————————————-
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

Vendor
————————————————-
Hyland Software – (https://www.hyland.com/en/ and https://www.onbase.com/en/)

Product
————————————————-
Hyland OnBase
All derivatives based on OnBase

Versions Affected
————————————————-
All versions up to and prior to OnBase Foundation EP1 (tested: 19.8.9.1000) and OnBase 18 (tested: 18.0.0.32). OnBase Foundation EP2 and OnBase Foundation EP3 were not available to test, but Hyland’s response indicates that they are not likely to have fixed the vulnerabilities, especially given how numerous the instances of log injection are.

Credit
————————————————-
Adaptive Security Consulting

Vulnerability Summary
————————————————-
Hyland OnBase fails to properly sanitize data before writing it to the logs. OnBase also directly exposes logging methods to attackers, allowing attackers to create arbitrary log entries on behalf of any user, with or without authenticating. Attackers can also use these vulnerabilities to cause a denial of service.

Technical Details
————————————————-
OnBase contains two separate types of log injection vulnerabilities. First, because the OnBase architecture relies on the client-side performing data and privilege validation the OnBase server directly exposes logging methods that allow attackers to query those actions and write arbitrary log entries. These queries aren’t properly validated, allowing attackers to submit entries on behalf of other users or even write to the logs without authenticating. Attackers can leverage this functionality to create ficticious log entries and ruin the integrity of the logs.

The second way that the OnBase server writes logs is through exception handling, directly concatenating user input into the exception. This method allows attackers to inject arbitrary data into the logs through the exception handling, creating ficticious log entries and ruining the integrity of the logs.

We found that a failure to rate-limit or size-constrain the user-supplied logs and logged information also meant that we could cause denial of service attacks by either writing frequently to the logs or writing large log entries. For example, if we try to send non-numeric characters as user id an exception will occur. Many OnBase methods will then print the user supplied information to the logs as part of the exception handling and logging method. If the user id is especially large (thousands of characters), the server will stop responding to connection requests after just a few instances. On the other hand, if the attacker uses a smaller user id they simply have to send many requests in a small amount of time to cause the server to stop responding. These same denial of service conditions can be met by using the OnBase server logging methods, instead of attacking the exception logging, by either making many small logging requests or by making a few very large logging requests.

Solution
————————————————-
Unfortunately, attempts to notify Hyland of the vulnerabilities have been rebuffed as not being something that they have to fix since fixing vulnerabilities, according to the Director of Application Security, is “creating custom code” and no known fix is in place. It is recommended that users try to mitigate the vulnerability by ensuring that the OnBase server is inaccessible to anyone other than trusted users and that a WAF be used (note that OnBase can use “optimized” communication that is pure binary — if this is used, it will be much harder to configure the WAF to protect against these vulnerabilities).

Timeline
————————————————-
07 May 2019 – Adaptive Security Consulting discovered a series of vulnerabilities in medical records management and
search applications being considered by our client
15 May 2019 – The client was provided with the results of the assessment, including POCs for a number of high and
critical vulnerabilities
12 July 2019 – Client asked for more information and demonstrations
01 October 2019 – Client asked to test latest version of Hyland software
15 October 2019 – Client was informed that EP1 contained many of the same vulnerabilities
March 2020 – Client contacted Hyland and spoke with the Director of Application Security who said that fixing vulnerabilities was “writing custom code” and that Hyland “doesn’t write custom code”
21 April 2020 – Adaptive Security Consulting attempted to contact Hyland’s Application Security Team via email on behalf of client, but attempts were ignored

Source link

Tagged with:



Leave a Reply

Your email address will not be published. Required fields are marked *


loading...