Technical Analysis of SAP Exploit Script Used in JLR, Harrods Hacks | Hacker News Reader

Technical Analysis of SAP Exploit Script Used in JLR, Harrods Hacks

detect.fyi

8 pointsincogitomode12 comments

This is just a really bad AI summary of the script.

You may as well just pop the script (mirrored here: https://gist.github.com/nneonneo/9caabf7c9d2f94711bce005e144...) into your own AI of choice and tweak the analysis to your liking.

(Note the giveaway "likely via argparse in Python" and similar constructs; the script obviously does use argparse so there's no need for hedging)

100%, this is definitely slop.

What's extremely saddening is that I had to examine three pages of search results for the CVE number before finding a non-slop explanation of the bug. In the race to "explain" vulnerabilities and bugs (and sell their security solution), a whole ecosystem of slop sites citing other slop sites has appeared, and accurate, careful (and often slow!) technical analysis is being lost in the noise.

As far as I can tell, the exploit works like this:

`metadataupload` takes a .zip file as POST input. This endpoint can be trivially reached on any SAP instance without authentication. The .zip file can contain a .properties file, which is deserialized into a java.util.Properties instance.

Since they're using Java deserialization, it is possible to deserialize arbitrary objects. The actual exploit uses a payload generated by ysoserial (https://github.com/frohoff/ysoserial) to either execute a command directly or drop a file on the filesystem. The basic idea behind a deserialization attack is to construct an object graph such that, when deserialized, functions that run normally as part of the deserialization process end up calling arbitrary code.

Deserialization attacks are well-known in the Java world, and are very common thanks to the fact that the serializer is both easy to use and baked into the language. With a large enough codebase (or the right dependencies) you're practically guaranteed to have enough serializable types to string together an RCE.

As an example, one of the classes used in this exploit is org.apache.xalan.xsltc.trax.TemplatesImpl (https://xalan.apache.org/xalan-j/apidocs/org/apache/xalan/xs...). This class contains a serializable array of Java .class bytecodes which will be dynamically loaded if the `newTransformer` method is called; note that merely loading a Java `.class` will be enough to run arbitrary code via static constructors. Other serializable classes are used to get the `newTransformer` method to be called on the object during deserialization.

The OP post is full of nonsensical and outright incorrect fluff. This is a straightforward deserialization-to-RCE bug; the RCE is what's being used to upload arbitrary files.

Who does even run Netweaver Java AS today? Apparently some do, but that was a bad idea from the start. It is an optional server component letting Java applications run in the SAP server. In my eyes it was always an unnecessary additional source of complexity, they added it to the portfolio back when Java was the hype. Now its been pwned by an unchecked upload.

But i know that HN does not have an appreciation for SAP anyhow.

Interesting, I worked on SAP for a few years and I expect this is just the tip of the iceberg on SAP systems :(

In recent years, we got patches (OSS Notes) almost daily.

To be honest, I've never heard anyone with SAP experience that has anything good to say about it. My N value is pretty low to be fair, but it definitely has the air of being widely disliked

In college, I worked for a small team in a large organization that used SAP. My team tracked everything in an Excel dashboard, and I was tasked with automating data ingestion from SAP into Excel. The only tool I had available was the SAP GUI input emulation API for VBA. It was extraordinarily painful to set up and would break every time the SAP team would change the GUI to add or remove a button. Lots of fun.

The only tool you knew about.

To be fair, it is almost impossible to get data out of SAP. Their "security" is all there to prevent users from doing anything useful. You have no access to the underlying database (like DB/2, oracle), you have to use their GUI or write a custom ABAP program.

But in most cases, the functions you need to call to write data to disk are usually closed off to developers due to "security". If you have access to the database (almost impossible to get), the data for the important tables are spread throughout multiple tables with names that look like names created from /dev/urandom.

I am familiar with SAP, all that you say is only true if you don't know how to do it. I see this a lot, people that are familiar with "normal" technology, try to invent ways to do things in SAP. What is wrong with writing an ABAP program, or using a provided communication/interfacing method to transfer data? If you are stuck on GUI/files/DB level, sure you wont be able to do anything. You can for example generate complete excel files on the server, no need for the GUI. There is a running joke on SAP forums about how many times excel file generation was invented.

Some of the cryptic table names date back to R/2, sure, but they are the de-facto standard data model for those business data. If you have business systems communicating, for example product, business partner or financial data, it will have a mark on it of how those data are handled by SAP.

But then there are CDS views (for some time now) that have long descriptive names, and metadata to help you make database queries. You are not meant to read or write database tables directly (as of some time).

Again, I will say, where I worked, due to "security" lots of items were disabled, even for developers. The only item that you could use to get data was SE17, some people (a few) were allowed to have SE16. But due to memory, getting data that way was very slow.

Also, SE16 did and may still have security issues. That was the reason for it being disabled for 99% of the users.

Reply on news.ycombinator.com