Mind the protocol
SAP responded and put the service is in maintenance mode. Therefore it is not any longer possible to access data on the CMIS server.
Welcome to the next post in my unofficial series “Are you sure you want to expose that on the internet?”. After a data leakage at SAP, a missing security check at DSAG, another widely exposed OData service (post scheduled), and some more, today I have exciting news regarding SAP. If you have some time, you’ll learn how CMIS works, how to browse a CMIS repository and how to get access to fascinating documents. No hacking skills, exploits, special payloads to trick a system. All that is necessary to get access to the data is to use the intended – aka default – client to connect to a service made publicly available by SAP on the internet.
Recently I was exploring the SAP Discovery Center. In case you read some of my posts on learning and SAP, you might have noticed that I like the discovery center and that SAP should invest more into the content provided there. It is even recommended by SAP’s CTO. It should not wonder anyone that I accessed the SAP Discovery Center and explored some of its content. I started with services and of course, neither did the map of data center locations explains what the color of each bubble means, nor did the map load correctly and worked. Seems that my browser cannot access the file LicenseModelAndProvider.json as the server returns HTTP 500. I guess some broken routing is causing this.
All it takes is internet access and a browser
Yes, very sad, anyway, in the mission catalog I decided to open the featured mission “Getting started with SAP BTP Enterprise Account”.
The overview page of that mission displays two nice images I opted to explore in more detail.
There is an open in new tab button that opens the picture in a new tab. Two things draw my attention. The title of the tab is root:
Next the URL got my attention (I guess it is safe to say: that was the mistake no one thought about when making the image load from that location):
Looks cryptic, but let me assure you, it is not. To be more precise: some parts of the URL got my attention: documents, cmis, root. That reminded me of Mobile Documents, later renamed to Document Center and currently I do not even know if it is still a product. What I do know is that once I worked with Mobile Documents and I still remember the base architecture and that you can run queries against it to find documents or to load them. SAP Discovery Center is publicly recommended by SAP’s top management, SAP is a technology leader, some of the best people in IT work there, what could go wrong?
Starting from the URL of the image, I remembered that I could take parts away and get to the root.
This is the general information about the repository.
The data reveals that this is the repository for the SAP Cloud Platform Document Service from the Platform X project. And that someone wasn’t informed of the name change of SAP Cloud Platform/SCP to BTP. I also remembered that the ID must be the repository ID (or you just look that information up in the official documentation at SAP Help) and root is a selector. Putting this knowledge into action (or simply restore part of the URL I deleted earlier) gives:
This reveals more data about the repository.
Formatting the data to make it human readable reveals additional information. For instance, that the data contains folders and the folder name. It is also obvious now that CMIS is used as protocol. Therefore, what gets exposed here by the documents service is CMIS information: folder structure, names, sub folders, files, metadata. Any special SAP knowledge is not needed to understand the service, only CMIS knowledge.
Searching for files
CMIS isn’t the best protocol, but also not the worst. And it allows to run queries. From the above it is clear that a folder named Capgemini exists and has the ID _E3910AqYnRCvdkgm-LPp4gnUcqcCLj1bJy9S49hlS0. This information can be used to run a query against the CMIS service using the browser. For instance, take the URL of the picture from the discovery center and replace the last part of the URL, everything that comes after objectdID= with the above ID for the folder
The query is successful and shows even more information. Converting this data into a readable JSON string reveals: another folder named “Building an analytical reporting solution on top of your IoT sensor data” with ID: Cc4qbQ9lVeATS5-qTL7JDCCfMsXEO4dC_hfTB6mYEzA.
This query shows the content of the folder.
What is in the folder?
- Document type: application\/vnd.openxmlformats-officedocument.wordprocessingml.document
- Document name: SDC Checklist – Building an analytical reporting solution on top of your IoT sensor data.docx
- ID: 5ZL4a15fbPlt7lj_wagdWXphEqYq6evrPiZb9OjnvLI
This seems to be a downloadable document that is exposed publicly by the documents service. To download the document just add the ID to the query:
The Word document does not contain any (visible) watermarks or internal only marks, so I guess this is a public document. Albeit the content seems to be internal, as it appears to be the checklist that a mission needs to pass to make it on the discovery center site.
As you can see, the service is exposing folders and documents via CMIS to the general public, aka the internet. Accessing the information is rather difficult as JSON needs to be read and for each folder/file a request must be made. There is an UI5 client available, but only when you are a Document Center user. Developing your own CMIS client would be too much effort. But CMIS once was hyped. And as stated in the beginning of the post, no special skills needed. Solution: Apache Chemistry project! It even provides a CMIS workbench to make browsing a CMIS repository easy. That allows every person with a computer and internet access to run the workbench, connect to a CMIS repository and explore the files stored there. The project moved to the Apache attic, but the files are still available. The Apache Chemistry workbench code can be found here. The file to download is chemistry-opencmis-dist-1.1.0-server-webapps.zip. Unzip the file and run the workbench file that matches your operating system.
Start the workbench and provide the connection information to SAP document service.
- URL: https://discovery-center.cloud.sap/documents/cmis/json
- Binding: Browser
- Credentials: no user and password needed (PUBLIC SERVICE / ANONYMOUS)
Click Load Repositories and Login (no user or password needed. All public).
The Workbench will connect via CMIS to the service and list all top-level folders it finds.
In case you remember one of the queries made earlier to get the repository information, this is the same, only that this time the Workbench displays the folder information nicely. It seems that the repository is used to allow partners and SAP to store documents related (hopefully only) to Discovery Center content, like images or documentation to products. An SAP folder is also there. With the workbench, these folders and their content can be explored.
And now I stop. I assume that the people at SAP know what they do, so all this information is placed there intentionally for everyone to access. While everything is made available on the internet publicly, some exposed information seems not to be intended for everyone. Maybe the repository configuration is either misconfigured, lacks governance or was abused by contributors. Documents available in the repository that I did not expect to be able to access:
- There are many documents with the SDC checklist for mission evaluation. This seems to be an internal process. Besides the companies that tried to be included, you can see if a mission was rejected and the comments, also the name of the reviewers.
- There are documents from SAP user groups I think were intended only for registered participants or user group members. Is the DSAG ABAP Dev Days 2021 material available to everyone?
- Some documents are marked as internal or confidential yet are stored on a public accessible site. Is the north star architecture intended to be known by everyone? The classification says no, maybe some people need to refresh their training about document classification?
- User IDs. The user ID of the owner of the document (create, update) are accessible. With the data exposed from the customer influence, an attacker might be able to combine that information (name, company, customer influence idea, declined discovery center mission proposal).
- SAP Education training material (PDFs) is accessible. It is not even a time-consuming search necessary; the course PDFs are super easy to find.
- Trainings, workshop plans, material and meeting notes from customers normally should not be made available to everyone. Not to forget: if some people were not OK with having their e-mail address made available on the internet after providing them for an (internal) workshop, I guess SAP needs to send out a data privacy breach message to some people.
Several things failed here. Each one is already problematic, but the combination is makes it dangerous.
CMIS usage for hosting static resources
Someone at SAP thinks that hosting files for a public website on a CMIS repository is a good idea. Considering that CMIS offers – because of the protocol – so much additional information to each file, like author, date, type, modify date and so on, it is not a good idea to use it to host static assets for a public web page. At least I’d not do it. You can use it in the authoring process, but the final version of the site should be gone through some CI process and store all files in a separate location, without the additional meta data.
I would be surprised if the actual configuration of the CMIS repository is as intended. It looks like an internal repository was used and maybe enhanced for SAP DC related information and then also to store workshop material? Is there an additional location (SharePoint?) connected that was never intended in the first place to be? New data was added because it was possible? I doubt the users know where their data ended up.
That an anonymous user can access the repository is bad. That folders are listed and can be browsed, and the files stored in them, is beyond imagination. Who exposes a file service on the internet? And then does not enforce authentication?
Document classified as internal or confidential, customer & partner data, folders that are not used any longer, and so on. I do not think that a governance process is in place.
Safe place to store data
If you store confidential data somewhere, it is your task to ensure that access to the resource is protected. People thought that using the documents service that is also used to hosts files for the discovery center is a safe place and that confidential data can be stored there securely. Who gave the users the impression that this repository is a safe place? I guess everyone needs to go through some mandatory security training at your employer. Now you know why this is important and why you should follow the rules. Here SAP needs to invest either in the training and make it mandatory or check that the employees are not ignoring it.
Storing SAP Education course material in a publicly accessible place: I thought this is not allowed. I thought that if you share the PDF so that people you might not even know access it, SAP Education can even ban you from taking any further trainings with them? Seems I was wrong. Same for customer workshop material. Rarely this is intended for everyone to access.
If you think: Why not use CMIS to store images or documents for the SAP Discovery Center website? As long as the file can be loaded, what’s the problem? Let me show you the additional data you get via CMIS for a single file:
Believe me, most of that information is not needed for displaying a file in a web site.
From the above points – and there are many more – it can be deduced that the combination is what makes this dangerous. A public repository that only contains resources of a static site is not a big problem (besides architecture). The data that is made available makes it a problem. Therefore: if people think that the SAP DC documents repository is a safe place, why do they think so? Is this internally sold to users as a secure place? Are the people responsible for the configuration and validation of the service not aware that they gave anonymous users general read access? If so, how many more repositories from SAP are accessible from the internet and expose (confidential) information, from SAP, customers, and partners? Why not encrypt sensitive files? Without password or key it would not be possible to read the files. It’s 2022 and customers rely on SAP that they know what security means.
A problem is to know for how long the data was made available to everyone on the internet. The oldest directories are from Jan 2018. Worst case is that possible sensitive information from SAP, partners and customers was published for over 4 years. Not all directories contain data, I hope that some people cleaned up what was not needed any longer. My recommendation for partners and customers that did a workshop with SAP with SAP DC related content: ask where the workshop material was stored. For partners that worked with SAP DC missions: you should ask too.
Every information is there because someone put it there and someone configured the document service to expose the information to everyone. It looks like the service is (ab)used as a SharePoint replacement, but with so many people checking and approving anything at SAP, that cannot be the case. I have the feeling that the information should not be there, so let’s see how long it will need for SAP to take actions. Honestly, I do not understand why documents like images for the SAP Discovery Center are accessed through a CMIS service and are not stored on a static web server storage. I also do not understand why so many folders are accessible for everyone and why documents that seem not to be intended for externals are saved there. Not even to mention the missing authentication. Or encryption. Security in 2022 and SAP. Another example that stating that you are a cloud company does not imply understanding how the internet works.
For those wondering if I reported this to SAP. No, I didn’t. Over the last months I reported issues regarding GDPR or security to several companies and EVERY SINGLE ONE RESPONDED IN LESS THAN 48 HOURS. With one exception: SAP. So yes SAP, I received your message. I am not going to bother your staff with information regarding security, data integrity or anything else that relates to how the internet works.
Down the rabbit hole
What strikes me most is that absolutely no hacking or any special skills are needed to get access to the data. SAP puts a CMIS server with no authentication on the internet. The service provides assets to an important web site that gets recommended to be used by partners and customers by top level management. All you need to exploit (???) the service is to use the intended default client. This part is what makes me absolutely speechless. Default client! The SAP DC site uses HTTP to load assets. But the default and intended client for a CMIS server is a CMIS client. The web app in the architecture for Document Center e.g., the UI5 app which uses the CMIS protocol is a client.
Source: SAP Help
The current usage of accessing assets for SAP Discovery Center via HTTP calls is more the alternative, or workaround of the CMIS server. SAP uses the service “wrongly” and in returns allows everyone else to use the server as intended via CMIS client. And if people use the service as intended, with the correct client, not even basic security checks are in place. If you know how a file explorer works, congratulations, you can access the documents. This is so easy, its like an invitation. Honestly, I was not searching for this. I was checking some missions in the SAP Discovery Center, I noticed something strange and not even 2 minutes later I had access to documents I guess I should not have. I can only imagine how many people with basic skills came already across this.
Marc · May 23, 2022 at 12:30
Small correction: The required download for the Chemistry workbench is chemistry-opencmis-workbench-1.1.0-full.zip
Nice find… unfortunately these seem common traps, not just specific to SAP. Too few fully understand what it means when you put “things on the internet” or “cloudify” apps, databases, management systems, etc. So this is a great case study of how to NOT do it.
PS: Further troubling is that the CMIS reports “can_delete_object” and “can_delete_tree” as allowable actions…
Tobias Hofmann · May 23, 2022 at 14:10
let’s not make it too easy for everyone to download the workbench 🙂
The repo itself is marked as read only, it should not be possible to delete, upload or alter anything as an anonymous user. At least my test failed.
Merbin · September 4, 2022 at 07:24
> Someone at SAP thinks that hosting files for a public website on a CMIS repository is a good idea. Considering that CMIS offers – because of the protocol – so much additional information to each file, like author, date, type, modify date and so on, it is not a good idea to use it to host static assets for a public web page. At least I’d not do it. You can use it in the authoring process, but the final version of the site should be gone through some CI process and store all files in a separate location, without the additional meta data.
I agree on this point. People at SAP should avoid using Document Center (now called ‘SAP Document Management Service’) for hosting files but only for authoring files. While publishing the content, the files should be copied to a public repository like ‘Object Store on SAP BTP’ or ‘HTML5 Application Repository’ for very simple & small files.
Legal requirements | It's full of stars! · February 22, 2023 at 17:00
[…] and develop SAP based solutions. Although I really miss the Enterprise Architecture Explorer. I already covered the SAP Discovery Center (or as it is called by SAP: Disco). I posted some of my finding already and don’t assume I posted […]