Critical SAP ASE Flaws Allow Complete Control of Databases Researchers warn of critical flaws in SAP’s Sybase Adaptive Server Enterprise software. Researchers are urging users to apply patches for several critical vulnerabilities in SAP’s Adaptive Server Enterprise (ASE). If exploited, the most severe flaws could give unprivileged users complete control of databases and – in some cases – even underlying operating systems. ASE (previously known as Sybase SQL server) is SAP’s popular database management software, targeted for transactional-based applications. ASE is used by more than 30,000 organizations globally – including 90 percent of the top banks and security firms worldwide, according to SAP. Researchers disclosed six vulnerabilities that they discovered while conducting security tests for the latest version of the software, ASE 16 (SP03 PL08). While SAP has released patches for both ASE 15.7 and 16.0 in its May 2020 update, researchers disclosed technical details of the flaws on Wednesday, saying “there is no question” that the patches should be applied immediately if they haven’t been already. “For the last several years there have been relatively few security patches for SAP Adaptive Server Enterprise (ASE),” said Trustwave researchers in a Wednesday analysis. “New security research conducted by Trustwave revealed a bunch of vulnerabilities in the current version of SAP’s flagship relational database product. Historically, SAP ASE is widely used by the financial sector in the US and other countries.” The most severe vulnerability, CVE-2020-6248, has a CVSS score of 9.1 out of 10. The flaw stems from a lack of security checks for overwriting critical configuration files during database backup operations. That means any unprivileged user who can run a DUMP command (used by database owners to back up the file system to storage devices) can send a corrupted configuration file, resulting in potential takeover of the database. This file will then be detected by the server and replaced with a default configuration – which allows anyone to connect to the Backup Server using the login and an empty password. “The next step would be to change the sybmultbuf_binary Backup Server setting to point to an executable of the attacker’s choice,” said researchers. “Subsequent DUMP commands will now trigger the execution of the attacker’s executable. If SAP ASE is running on Windows, the code will run as LocalSystem by default.” Another critical flaw (CVE-2020-6252) was discovered affecting Windows installations of the SAP ASE 16. That bug exists in a small helper database (SQL Anywhere) used by the SAP ASE installation to manage database creation and version management. Specifically, the issue is in the Cockpit component of ASE, which is a web-based tool for monitoring the status and availability of SAP ASE servers. The issues stems from the password, used to login in to the helper database, being in a configuration file that is readable by any Windows user. “This means any valid Windows user can grab the file and recover the password to login to the helper SQL Anywhere database as the special user utility_db and then issue commands like CREATE ENCRYPTED FILE to overwrite operating system files (remember, the helper database runs as LocalSystem by default!) and possibly cause code execution with LocalSystem privileges,” said researchers. In another issue, researchers found clear text passwords in the ASE server installation logs: “The logs are only readable to the SAP account, but will completely compromise the SAP ASE when joined with some other issue that allows filesystem access,” they said. Researchers also found two SQL injection flaws that could be abused to allow privilege escalation. One (CVE-2020-6241) exists in global temporary tables in ASE 16, while the other (CVE-2020-6253) stems from the WebServices handling code of ASE. The final bug discovered was an XP Server flaw (CVE-2020-6243) that could allow authenticated Windows users to gain arbitrary code execution (as LocalSystem) if they can connect to the SAP ASE. “Organizations often store their most critical data in databases, which, in turn, are often necessarily exposed in untrusted or publicly exposed environments,” said researchers. “This makes vulnerabilities like these essential to address and test quickly since they not only threaten the data in the database but potentially the full host that it is running on.”