Anecdotes
From Secure ABAP
We continue the series of Anecdotes (war stories) that we have started in the book (see the overview on page 342 ff). We presenting selected technical security defects and their relevance for business on this site. All examples have a real background and are - of course - anonymized in order to avoid any conclusion regarding customers or projects.
Contents |
Directory Traversal Backdoor in ABAP Code: Read and Write Access to confidential Data
In a development project, a Web interface for a supplier portal was created with Business Server Pages (BSP). The external developer thereby created functions to up- and download files. This was a required function for the suppliers in order to place their bids. This naturally included confidential data just like strictly confidential construction drawings.
The data storage for up- and downloads was to be determined by form fields. For security reasons the access to the application was secured by an authorization check. But the directories and files were created dynamically. That way no authorization check happened at file level. The developers implicitly assumed that a user could not access the files of another because these files were stored into another directory. Actually, it was possible to traverse the data system because the path was entered with the file name (that's why such a vulnerability is called Directory Traversal).
This allowed possible attacks like entering ../../othersupplier/offer.pdf. This hack allowed access confidential data of other bidders. Furthermore, the data integrity was violated because it was to write data by using the upload function. This also leads to legal issues since the customer had a contract with the suppliers that guaranteed protection of his intellectual property against unauthorized access.
This case case shows that a backdoor in your ABAP code might have severe consequences. It doesn't matter whether this backdoor was built in on purpose or not. However, intentional backdoors are of course the worst case, because have to assume a very targeted and quiet attack.
See also Chapter Directory Traversal in the book on page 185 ff.
Hard-Coded Usernames and Dynamic Coding: Database deleted and arbitrary ABAP Commands executed
Recently, one of our customers made a very interesting discovery. The security team conducted a couple of CodeProfiler scans on 3rd party code that was developed about three years ago. This custom code was an add-on for the company's HR system. Besides some typical security defects, our customer also discovered two disturbing facts:
- If a user with a specific name (which was hard-coded) had ever started one of their ESS modules, the entire data of this module would have been erased and filled with test data. A 3rd party developer had forgotten to remove parts of his test code from the productive application. Our customer was shocked to learn that they actually had a user with the exact same name as the 3rd party developer on the affected system.
- The custom code contained a report that dynamically built ABAP code based on input from the user interface (SAP GUI). The developers probably used such dynamic coding to avoid complex IF and CASE constructs in their code. However, dynamically created ABAP code leads to unforeseen side-effects. In this case, it was possible to change the generated ABAP code in a way that any ABAP command(s) could be executed. It took the security team less than 10 minutes to inject ABAP code that allowed downloads of all user names from the SAP system. For example, they could have downloaded all salary data with the same effort.
These findings made it clear to our customer that they needed to rethink the way they contracted external developers – security must be part of the specification.
See also Chapters Backdoors - hard-coded authorizations (page 143 ff) and Chapter ABAP Command Injection (page 169 ff).
