(Interesting updates bellow!)
Disclaimer
Before writing this blog, I reported my concerns directly to SAP following their disclosure guidelines. For approximately three weeks, we exchanged messages and as an outcome, SAP updated their CPI documentation. The post title is accurate and not just a clickbait.
In this blog I will not expose the details of the proof of concept that I presented to SAP, but I will describe the issue and will quote SAP's suggestions to prevent your passwords from being easily revealed. I am writing this post with good intentions as the ultimate goal is to help the community to take security measures in their systems as soon as possible. I've been careful to follow the community rules of engagement, the terms of use and the disclosure guidelines as I've already mentioned.
In one of the most interesting blogs I read last year, vadim.klimov wrote a disclaimer that I would like to reference at this time. It may not apply one hundred percent to this situation, but it perfectly reflects the mindset behind writing this post. Textually:
"Material in this blog is provided for information and technical features demonstration purposes only. Described techniques and published code snippets, even in case they make sense from technical perspective, shall be a subject for assessment and evaluation from legal perspective to avoid violation of software license agreements, should the one attempt making use of them and embed them or their variations into the application deployed on SAP Cloud Platform or any other development that utilises services provided by SAP Cloud Platform. Ultimately, we are good citizens and our aim is not to break the platform or rules of its usage, but to explore it and build smart applications on top of it.
When using approaches such as those described in the blog, please be cautious regarding how techniques are utilised and applied – they can be of great help, but equally to this, inaccurate usage of some of these techniques may cause severe stability and performance issues at runtime. Hence, before using this kind of techniques in real life applications and especially in production environments, ensure their usage is well considered, designed, implemented and well tested."
The issue
The following question will clue you in: for those with some background in ABAP or PI/PO:
Q: What happens with the password when you change the target URL in a RFC or a Communication Channel?
A: The password is deleted and you are forced to rewrite it.
The reason behind this behaviour is simple, if the password remains registered, nothing prevents you from redirecting the request to a service that captures your data. Even then, it is possible to redirect the call or act as a reverse proxy, leaving little trace of the change, not even affecting the functionality of an iFlow.
In CPI, unfortunately, the design of the manager of security materials does not tie or restrict the use of passwords for an specific service/host/url, regardless of the type of material, including certificates and passwords. This is the issue. In other words: If you are able to deploy an iFlow, you can reveal -all- the stored passwords. Period.
Consider the following reduced example: 1.- Create a credential, 2.- Use that credential to perform a request to a "bespoke" server, 3.- Reveal the data.
Mitigating measures
As I started this post, SAP has updated the CPI documentation with some recommendations and you should definitely follow them. Quoting:
- Don't give the integration developer access to productive systems.
- Consider applying a four-eyes principle and implement a review process before deploying integration flows to production.
- If read-only access is required to analyze issues in the productive system, use the authorization group AuthGroup.ReadOnly.
I would include:
- Severely restrict the access to the security manager. Not even with -read only- rights.
- Use artefact´s names that do not refers to the system that they are intended. If possible, treat their names as passwords themselves.
However, as a personal opinion I strongly believe that these measures are not enough. This is not to be paranoid, but in the vast majority of customer's accounts I have reviewed, the adopted "policies" of user registration and control are very "flexible", which means that it is very common to find users with major authorisations in productive environments and a general chaos in this regard. Logically, it takes a bad intentional will to reveal passwords, but I don't think you should just rely on good intentions when it comes to security.
When I contacted SAP, I had the expectation for them to introduce some mechanisms to relate security materials with urls/hosts/services. I understand that these changes would require to reshape the security material manager and it will possible affect a large number of iFlows. As this did not happen, it is up to you to act now and take some security measures with your own accounts.
Updates
02/08/2018: I just realized two interesting things.
- If you have rights to create an iflow, you don't need a bespoke server. The reason? CPI provides you with an API that allows you to do it without much effort using a groovy script.
- It is also possible to capture the user and password of the individual/system that is calling at your endpoint. This might be more dangerous.
13/08/2018: ch.becker from SAP, provided extra information about handling security in CPI and it feels like an official response to this post. The blog post can be found in this link.
- SAP Managed Tags:
4 Comments
