SAP Security Notes Mar ‘18: The Risks of Open Source
Since it is the second Tuesday of the month, SAP has again published a new set of notes to patch vulnerabilities found in its software. SAP released a sum of 27 new security notes, taking into account the ones published after February’s Security Patch Day.
As far as 2018 goes, no notes tagged as Hot News, the highest category based on risk, were released; however, six notes were released with High Priority and need attention. We will give our insight into each of them in our last section.
Reported by Onapsis: Cross-Site Scripting (XSS) Vulnerability in Process Monitoring Infrastructure
When managing a large SAP landscape it is useful to gain insight into business processes in a centralized way. This is where SAP Process Monitoring Infrastructure (PMI) comes in. SAP PMI provides the technical means to monitor businesses processes. Those processes often involve multiple mechanisms. SAP PMI attempts to provide an overview of a business process by starting at a low level. It monitors technical process steps underlying the business processes, collects the technical data and sends it to a Central Monitoring System. In the Central Monitoring System the business processes are then reconstructed for analysis.
Administrators interact with PMI through web applications built on top of the Process Monitoring API. These components run in the Central Monitoring System.
By sending web requests, administrators can obtain status, error, statistical and process information which is then displayed graphically in a browser.
A Medium Priority security vulnerability in PMI (#2592807) was found by Onapsis security researcher Gaston Traberg. It concerns a Cross-Site Scripting (XSS) vulnerability, existing in one of the Java web applications for PMI. When the web application sends a POST-request to the PMI API to request data, the parameters are returned to the sender without ever having been sanitized on the backend. This means custom-script code can be embedded in the request, which will subsequently be executed client-side when the response is processed by the browser. An attacker can leverage this vulnerability by tricking an already authenticated user into clicking a trustworthy looking, but malicious, behaving link. After the malicious script is executed client side, the attacker may have free rein over the victim’s machine.
The Risks of Open Source
This month SAP published a High Priority Note (#2538829) titled, “Open Source Software Security Vulnerabilities in SAP Internet Graphics Server (IGS)”. In the note, SAP addresses vulnerabilities in libtiff, giflib and libpng, all of which are third-party open source libraries which handle images (TIFF, GIF and PNG, respectively). The vulnerabilities in these libraries have been around for over a decade.
Developing quality consumer grade software is an incredibly complex matter. It often involves bright minds with knowledge and experience in a multitude of fields to team up and construct a system with many moving parts. Cleverly designed software is modular and reusable, which facilitates the age old mantra in software development: “don’t reinvent the wheel”. By using software libraries, which are simply collections of reusable pieces of code, programmers use building blocks supplied by others, and add to those blocks to create something new of their own. In this way a crypto developer can easily implement imaging functionality in his application by using imaging libraries, while a web developer can secure his application by using cryptographic libraries.
The open source community is a great supplier of reusable software libraries. Some of these libraries have been tried and tested over decades, gained community trust and have become the defacto standard for their field of application in high-end software products. OpenSSL, for example, an open source library for securing communications, is used in hundreds of thousands of web servers and implemented in software released for millions to consume. Open source libraries are free, with lots of boxed-in brain power, tried and tested and open for anyone to check for backdoors or flaws. For many companies worldwide it has seemed to be a no-brainer.
However, in recent years it has become obvious that utilizing these open source libraries also has its disadvantages. In 2014 the critical OpenSSL Heartbleed security bug shook the IT community. The Heartbleed bug, “allow[ed] anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software.” It ignited the question, “how safe is open source software, really?” and how serious a flaw can be, because of its propagation through thousands of (commercial) products used worldwide. Doubt was cast on the generally held belief that open source is implicitly safer because it is open for inspection to anyone. Especially after it was found that a project like OpenSSL received a mere $2,000 per year in donations and had only one full-time worker approving over half of the 450,000 lines of code. How could it ever be able to compete with paid software?
Tech giants like Google, Facebook, Microsoft, Amazon and IBM have woken up to this question. They have bundled forces and together invested money in the Core Infrastructure Initiative, a project of the Linux Foundation to increase the security of underfunded open source projects.Their initiative is to explicitly answer the question with Linus’s Law, a statement in honor of Linux founder Linus Torvalds, which states that “given enough eyeballs, all bugs are shallow.” This means that if the team is large enough, all bugs can be easily found.
Apart from OpenSSL, other open source libraries have been found to contain serious security flaws. Apache, glibc and even the Linux Kernel are some examples that have not escaped in recent years. One could argue therefore, that it could be questionable for a commercial company to reuse free, open source libraries. Why not create their own? Apart from the costs involved, the answer could be quite simple: everybody should stick to what they’re good at. If every commercial software company had to program every moving part from scratch, it is highly likely a multifold of bugs would be introduced due to the sheer inexperience of the programmers. By having niche experts focus on their particular libraries, and reusing those libraries, in the end everybody benefits to the fullest. Relying on others comes with a cost. As a commercial company you are yielding control, and thereby the security of your customers, to others.
Like all the giants, SAP has similar considerations to make. Note (#2538829) shows how security flaws can be adopted by companies and go unnoticed for years under the cover of the commercial product.
The best way to counter these security issues is to keep your software patched and up-to-date at all times. This goes for companies like SAP as well as consumers. In the case of this note, it is therefore advised to download and install the IGS patch level indicated in the Support Packages and Patches section of this SAP Security Note.
Open source libraries used in commercial products are necessary to maintain quality; however, it should be clear that there is a gray area, in which trust is assumed but never received.
Remaining High Priority Notes
Apart from the note discussed in the previous section, the following High Priority notes were released this month:
(#2604541) – Denial of Service (DOS) in GWJPO. Here we see another example of a vulnerable third-party open source library ending up causing a security flaw in SAP. In this case, the vulnerable software is Apache CXF; an open source services framework helping developers build services using frontend programming APIs like JAX-WS and JAX-RS. GWJPO is using a particular vulnerable CXF servlet, which allows an attacker to prevent legitimate users from accessing a service, either by crashing or flooding the service.
(#2596535) – Information Disclosure in SAP BPA BY REDWOOD. SAP® BPA is an automation platform created by Redwood, sold, supported and validated by SAP. It allows customers to coordinate process automation across their SAP landscape. A vulnerability has been found in BPA that may allow an attacker to access information that should have been restricted. It goes to show that third-party software does not need to be open source to form a liability.
(#2331141) – SQL Injection Vulnerability in FI-LOC-FI-RU. User input was not sufficiently screened and sanitized by this component; therefore it was possible for users to submit improper data and inject dangerous SQL-statements, exposing the backend database and its sensitive content.
(#2595262) – Cross-Site Scripting (XSS) Vulnerability in SAP CRM WebClient UI. It’s not uncommon for an XSS vulnerability to be found in the SAP CRM WebClient UI. This note seems to acknowledge that fact by referencing previously released SAP notes concerning XSS in the CRM Webclient UI. The difference is that this one is of a more critical nature then others reported before. The referenced notes are required to be patched as a prerequisite.
(#2587369) – Potential Information Disclosure in SAP HANA Capture & Replay Trace File. This note addresses credentials that are stored in clear text in the indexserver trace files of a system using the optional capture & replay functionality of SAP HANA. An attacker would need to obtain TRACE_ADMIN or CATALOG READ authorization to display the indexserver trace files. Besides updating the software to later versions, two manual workarounds are provided to immediately eliminate the threat.
Conclusion
This month Gaston Traberg from our Research Labs has been acknowledged by SAP on their webpage for his collaboration efforts to keep improving SAP security. As always, we are working on updating the Onapsis Security Platform to incorporate these newly published vulnerabilities. This will allow our customers to check whether their systems are up to date with the latest SAP Security Notes and will ensure that those systems are configured with the appropriate level of security to meet their audit and compliance requirements.