Anonymous Claims Regarding The Security of The Onapsis Platform
Onapsis has been at the forefront of securing business-critical applications for over a decade. We take great pride in our dedicated research and development teams that not only uncover the threats to SAP and Oracle applications around the world but also augment and enhance our own cybersecurity platform. We consider the security and privacy of our platform to be paramount in earning and keeping the trust of our global customers, and so we hold our teams and our enterprise to the highest standards to ensure the resilience of our platform. As part of this commitment to the highest standards, Onapsis maintains a robust and mature security response process, informed by our extensive experiences in vulnerability research and ethical disclosure over the years with the largest software vendors in the world. Consequently, we take all claims of vulnerability reported to Onapsis very seriously.
On June 28th, a number of our customers contacted us sharing unsolicited emails they received claiming to have knowledge about the existence of “research” describing “zero-day vulnerabilities” in the on-premise software version of the Onapsis Platform. This was brought online on a webpage, not submitted to Onapsis or any security lists, and authored by an anonymous party.
We take any information about security threats affecting our customers with the utmost importance and therefore our internal teams immediately began executing according to our vulnerability response program to investigate the claims and, as appropriate, secure our products and customers.
There are five primary claims that were brought to the attention of Onapsis. Here are the resulting findings and our response from the research conducted by our product security teams.
Claim 0: Onapsis did not respond to or create a CVE for the reported vulnerabilities
Onapsis Response: Invalid Claim
There was no attempt made by the anonymous author to report this issue to Onapsis or to publish the report in standard security research disclosure channels (such as Full Disclosure). We have clear instructions on our website that are easily found on how to report vulnerabilities in Onapsis products to Onapsis.
Onapsis was made aware of these claims on 6/28 and immediately allocated a tiger team from our product security, security research, engineering, and product management to evaluate and address all claims made in the report. After thorough analysis, the team was able to determine that none of the claims made were actually vulnerabilities, as detailed below.
The author claimed we did not create CVEs. In this instance, there were no third party vulnerabilities identified and, as such, there is no grounds to create any CVEs.
Claim 1: Identification and Authentication Failure
Onapsis Response: Invalid Claim
The claim states that “[Onapsis] Consoles accepting SSH requests on the standard port 22 can be discovered using a Shodan or Censys search”.
Onapsis’ architectural guidance to all customers, as is standard practice for any form of security infrastructure, is to restrict access to all administrative interfaces allowing only restricted management segments or VPNs. Further the OP platform supports two-factor authentication (“2FA”), and our best practice guidance recommends all customers to enable 2FA.
We had external and internal teams conduct several searches, which found no Internet-accessible Onapsis Platform (“OP”) instances. Additionally, in the screenshot, the OP instances displayed indicated that they have self-signed certificates. This is neither the standard nor our recommendation for production installations of the Onapsis Platform.
Additionally, the anonymous author claims “You can SSH directly to the target servers using the generic onapsis or osp-admin users.”
This is patently false. The “onapsis” account is disabled by default, and manual enablement of this account is required. Our recommended practice to customers is to enable this account when needed, perform the required high permission activities and then disable the account when completed, in line with industry Privileged Account Management best practices.
Claim 2: Broken Access Control
Onapsis Response: Invalid Claim
The anonymous author claims that “PermitRootLogon is set to yes in the Onapsis appliance.”
This is another false claim. PermitRootLogin defaults to password-prohibit. Root access using password is not allowed by default.
This claim is for the ability to connect and authenticate to an Onapsis Platform appliance using SSH. This is a standard practice for appliances and allows for customers to connect and perform support operations when needed.
We have taken multiple steps to ensure we are following the principles of least access with regards to SSH access. The osp-admin referenced is the support account and is enabled by default. At the first login (during installation) customers are forced to create a unique password for this account. This account does not have bash access nor can it perform a sudo command.
The onapsis account is disabled by default, and manual enablement is required. Each customer is forced to change the passwords for the osp-admin and onapsis accounts at the time of installation. The passwords are required to be long and complex.
Claim 3: Sensitive Data Disclosure
Onapsis Response: Invalid Claim
At this point, the researcher has used multiple non-default enabled features to gain administrative access to the appliance. All claims in this section are expected behaviors. By definition, as for any system, administrative users have administrative access to certain sensitive information. After thorough review, our threat intelligence team determined there are no associated vulnerabilities.
They then claim “the generic admin user in the Web UI can also be brute forced.”
There are multiple controls built into the WebUI to make brute force attacks unreasonable for an attacker. There is an automatic timeout of two (2) minutes after every ten (10) failed authentication attempts and security notifications can be enabled that will send account security email messages to users when, for example, their password or permissions change or the platform detects multiple failed login attempts. Additionally, Onapsis best practice architectural guidance is to enable two-factor authentication for user authentication, eliminating the value of a bruteforce password attack.
Claim 4: Security Logging and Monitoring Failures
Onapsis Response: Invalid Claim
The final claim made is that none of the authentication attempts is logged or available within the platform.
This is also inaccurate. The author is confusing the absence of auditd (a program used for auditing logs) with the ability to generate security based logs. The Onapsis platform does log and retain details regarding login attempts in the auth.log log file.
Conclusion
Our current assessment indicates that all the claims presented in the anonymous “research” are untrue.
Our responsibility as a software vendor, security research team, and provider of security products is to thoroughly and rapidly respond to all reported vulnerabilities. Our commitment to our customers, partners, and community is to take all such claims seriously, regardless of source or validity. The Onapsis’ team rigorously analyzed these anonymous claims within one business day. We feel confident that this detailed report provides the required clarity our customers have learned to expect from us.
The Onapsis Product Security team continues to monitor and, as appropriate, will update this blog.
Please contact your account manager, technical account manager, or [email protected] if you have any questions, or would like to engage with our team.