Tech Support
Documentation
Login
Contact Us
Increasing Security of MySQL Databases While Eliminating Downtime
January 18, 2021 - TuxCare PR Team
Open-source software (OSS) has quickly transformed how modern applications are built and their underlying code. Access to high-quality and robust open-source software projects has allowed developers to quickly integrate new capabilities into their applications without reinventing the wheel. As a result, it is now estimated that between 80% and 90% of the code in most modern applications is made up of open source components. Likewise, many of the tools that have enabled DevOps and CI/CD growth such as Jenkins, Kubernetes, and Docker are themselves open-source projects.
In 2019 the overall number of published open-source CVEs (968) more than doubled compared to any previous year. Vulnerabilities grew by 130% between 2018 and 2019 (421 CVEs to 968 CVEs) and were 127% higher than 2017 (435), which had the second most CVEs in the study. This increase does not appear to be a flash in the pan as the discovery of new CVEs also remains at historically high levels through the first three months of 2020. This volume increases the complexity of managing an organization’s attack surface for developers, IT, and security teams alike. The Jenkins automation server had the most CVEs overall with 646 and was closely followed by MySQL with 624. Likewise, these projects tied for the most weaponized vulnerabilities with 15 (vulnerabilities for which exploit code exists). This article investigates the reasons for these software vulnerabilities and shows how to protect MySQL databases from potential security incidents.
Contents:
A Brief Overview of MySQL and Its Prominence in the Relational Database Market
There are several databases on the market, but MySQL is one of the most prominently used in both backend internal operations and public-facing applications such as websites and customer portals. Although it’s an open-source database, MySQL was acquired by Sun Microsystems that was later bought by Oracle. It was first introduced in the 1990s, but quickly became a popular option to the previously at-the-time dominant Microsoft SQL Server database. The syntax for MySQL is similar to other SQL languages (e.g., Oracle and Microsoft), so it’s a convenient choice for developers and organizations that need a more affordable database.
Currently, MySQL is one of the most commonly used relational database management systems (DBMS) on the market. A 2019 study showed that MySQL was 38.9% of the market followed by MongoDB with 24.6% and PostgreSQL with 17.4%. Open-source database software dominates a majority of websites, backend systems, and other corporately run data storage servers.
Open-source software that runs infrastructure has many benefits including a community that contributes to updates, bug finding, and features, security researchers that can find vulnerabilities before hackers find and exploit them, and a shared repository that can be forked and customized by other developers. With these benefits, however, comes a downside. If an attacker finds a bug, they can exploit it rather than report it. The result could be exploitation of the software and a zero-day vulnerability unknown to the developer until the exploit or code vulnerability is found. It could take potentially years to identify a vulnerability currently being exploited, which makes it even more critical for organizations to patch MySQL software as soon as an update is released. These updates patch systems from vulnerabilities that could have existed for months, and possibly years. If the exploit affects a production MySQL database that stores sensitive information, it’s imperative that the organization patches the system as soon as possible.
Vulnerabilities in MySQL
Between the length of time MySQL has been available to the public and its open-source codebase, the database software has numerous CVEs (Common Vulnerabilities and Exposures) — 1308 total. Some of these CVEs are related to applications or software such as PHP application files that allow SQL injection to manipulate web content and execute persistent Cross-Site Scripting (XSS), but others target the core of the database engine. Some vulnerabilities as recently as 2020 allow privilege escalation, network access to compromise the MySQL client, and remote code execution (RCE).
A compromised database is a critical security event as several other issues can spawn from allowing attackers to access it. Depending on the exploit, attackers can exfiltrate data from a compromised server, give themselves administrative privileges on the server, or inject their own data into tables. In a persistent XSS attack, any application that does not encode database data could be vulnerable to data or cookie theft. If an attacker can perform privilege escalation on the server, they could manipulate data, exfiltrate data to an attacker-controlled server, or perform lateral moves across enterprise databases. Remote code execution is especially dangerous, because an attacker can run their own malware on the server, which could be anything from keyloggers to ransomware.
Dangers of Unpatched Database Servers
As an example, look at CVE-2020-2934. There are several other CVEs related to this vulnerability, all of which affect MySQL Connectors, clients and network sessions. Successful exploitation of this vulnerability could allow an attacker to perform CRUD (Create, Read, Update, or Delete) commands on the database server or launch a denial-of-service (DoS) attack. An attacker with the ability to execute CRUD commands can read your data or make changes to it.
Data breaches on a database are considered critical and have a long-lasting impact on customer loyalty, trust, revenue, and productivity. Most organizations do not have an internal incident response team, which means that outside consultants are necessary who charge hundreds of dollars an hour. In some cases, IT administrators choose to turn off critical systems to contain the breach and block hacker access to the database server. This temporary remediation stops the attacker from stealing more data, but it also interrupts applications that need access to the database to function.
Severe breaches where an attacker uses ransomware to encrypt data or corrupts files require backups and a data recovery plan. Even in large enterprises, recovery plans can fail and need support from outside consultants. While the database remains down, the organization loses revenue from downtime, which can be thousands of dollars an hour in large enterprises.
The cost of a data breach on a database server greatly depends on the type of compromise, the amount of data stolen, and the efficiency of the incident response. As an example, Canadian lender Desjardins Group spent $53 million after a data breach that disclosed personal information on 2.9 million of its members. British Airways and Marriott spent $100 million each after violating GDPR (General Data Protection Regulation) compliance regulations, following data breaches.
Vulnerable Database Software Must Be Patched Quickly
One commonality with every CVE listed in the MITRE database for MySQL is that any application listed with vulnerabilities must be patched. CVEs could be third-party software that allows SQL injection and other exploits or vulnerabilities could be found in the MySQL database engine itself. You may not use the third-party application, but any MySQL database vulnerabilities should be patched as soon as possible.
Because MySQL is such a critical infrastructure component, administrators and database administrators (DBAs) may often schedule patching for a further date. They may also wait several weeks to patch the system so that thorough testing can be done and to avoid downtime on a production database server. Every day that passes is a window of opportunity for an attacker to exploit the unpatched MySQL server software.
With over 1300 CVEs and counting, it may seem like a losing battle for administrators and DBAs to keep up with patching the server. Any downtime on a production server means loss of productivity, sales, and it’s usually difficult to schedule as administrators cannot interrupt services during busy business hours.
Conclusion
To keep servers patched and safeguarded from the latest vulnerabilities, the answer is to use live patching so that the server receives continual updates without a reboot. KernelCare+ will soon release a new feature that will allow administrators to patch their database servers without requiring a reboot. Using KernelCare+, administrators can avoid costly data breaches, downtime, and still safeguard critical data.
