All your CPI credentials and certificates are likely at risk
(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: Christian 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.
Hi Ariel,
I definitely see your point and concerns. But there is also a similar issue with PI and integration platforms in general. In regards to PI, the passwords are deleted when transporting or copying channels. But usually IDoc, RFC and XI channels are reused by multiple scenarios and for SOAP/http channels you can overwrite the target URLs dynamically. So once a person can configure or change Integration Flows, ICOs, etc. in a production environment, it's impossible to completely prevent misuse.
I also like your idea to link security materials with urls/hosts/services. It would be indeed a major change and will provide challenges when digging into all details. But if it's an optional - but recommended - security feature that can be activated on single artifact level, this functionality could be provided without disrupting existing scenarios.
Regards, Holger
Hi Holger,
I agree that misuse can not be completely prevented, as you well mention, you can dynamically change a communication channel behaviour leaving that channel particular channel exposed. The main difference I think, is that the exposure is of one specific object and all the scenarios that utilise that channel.
Linking the security materials in an optional way might be a reasonable solution, but I guess it wont be that easy to properly implement and test this. It would be nice to get some insights of the development team about the implications.
BR, Ariel
Hi Ariel
You definitely brought up a very interesting point in your blog!
However, on a wider note, this is not limited to just CPI as Holger mentioned above. Even for PI, there are other ways to "extract" such details without having to change the URL in the communication channel.
From my experience with various organisations, (even before all the rave about DevOps) the development team is also the same team that supports the productive system (in varying degrees). As such, having access to production systems' passwords are kind of the norm in order for them to complete the various tasks that the team is responsible for.
IMHO, this matter is not just technical in nature. At the end of the day, no matter what system/platform we are using, when we move into a productive environment, "someone" needs to know the passwords in order to either create a new entry or modify an existing one. The question is, how do you determine who this person is AND how do you ensure this person does not misuse it? Is it even possible?
All this reminds me of the following question that was raised by Ryan Crosby sometime back:-
https://archive.sap.com/discussions/thread/3718835
It would seem it all depends on how much an organisation "trusts" an integration developer (whether explicitly or implicitly).
I'm not sure if the mitigating measures/guidelines both by SAP and yourself would work in any organisation across the entire life cycle of a development, but I'm up to hearing any further thoughts from yourself.
Regards
Eng Swee
Hi Eng,
I wanted to bring this point some time ago, but I was waiting for SAP to provide me some inputs as I've presented my concerns informally first, and then opening a ticket.
That true, in one of my "lab" tests, I've created an adapter module, that uses a fail-over option to read all the "hidden" parameters. However, these approaches are often limited to a single scenario/channel. Also, certain amount of skills/knowledge are required. My biggest concern with the security materials (in their current state) is that can be freely use in any combination. I do not want to disclose too much, but imagine an standard iflow that is ready to configure and deploy, what stop you from doing a "carousel" with all the available credentials? In my laboratory, I've created a ridiculous simple iflow that allowed me to reveal all the available security materials in no time. I think that is a big difference to extract one password from a communication channel, rather than to easily disclose the whole list of security artefacts.
This is a good point. However, based on the design of the security materials, you can eventually have a persona that knows, writes and deploys the password and a completely different one that deploys and configure an iFlow, this last one not having the right to know the password.
I do believe the same, in my post I expressly mentioned that those measures are not enough and I would really like to have some mechanism to actively prevent these potential leaks. So far, you are just four roles away of being able to reveal all the passwords. This also means, that no password is secret in a development/test environment. Unfortunately, I've seen more than once colleagues deploying their gmail credentials for their own "hello world" scenarios.
Br, Ariel