Unveiling Critical Security Updates: SAP BTP Security Note 3411067

[JürgenAdolf]

In our ongoing commitment to maintaining a robust and secure SAP Business Technology Platform (BTP) environment, we want to bring your attention to an important security note that has recently been released. While we understand the significance of transparency, we'll refrain from explicitly detailing the nature of the issue to prevent any potential exploitation. Instead, we encourage all BTP users to carefully review this security note and take necessary actions promptly.

Security Note 3411067

This security note addresses a critical privilege escalation issue within SAP BTP Security Services Integration Libraries. The note outlines the symptoms, prerequisites, and reasons behind the identified concern, providing a comprehensive understanding of the potential risks involved.

Action Steps: To safeguard your SAP BTP environment, we strongly urge all users to:

1. Check the Security Note: Navigate to SAP's official support portal and review Security Note 3411067 for detailed information.

1. Validate Prerequisites: Ensure your system aligns with the noted prerequisites to accurately assess the relevance of this security update to your setup.

1. Implement the Solution: Follow the provided solution outlined in the security note to address the identified issue and fortify your system against potential threats.

Additional Details: For those seeking a deeper understanding, Security Note 3411067 includes further details that shed light on the intricacies of the issue, allowing users to enhance their comprehension and implementation of the provided solution.

Update: We provide our customers with a  seamless and efficient way to assess their systems. To empower you to take control of your security, we have published a bash script that allows you to execute the scan on your own, eliminating the need to request scan results from SAP.

How to Execute the Scan: To access the bash script and run the scan independently, please refer to SAP Note 3411661. The script is conveniently attached to this note, providing a straightforward solution to help you determine whether your system is affected.

Conclusion: Security is a shared responsibility, and proactive measures are crucial to maintaining the integrity of our SAP BTP environments. By staying informed and promptly addressing security notes such as 3411067, we collectively contribute to a safer and more secure digital landscape.

We appreciate your diligence in reviewing and addressing this security note promptly. As always, your commitment to maintaining a secure SAP BTP environment is paramount. Stay secure, stay informed!

[dyaryura]

Hi Juergen

What should be the normal channel for customers to get notified about these kind of notes? Since this is BTP specific I'm wondering if it'll show up in Solman SysRec or if it'd be included as part of the monthly webinars led by Frank (https://support.sap.com/en/offerings-programs/support-services/security-optimization-services-portfolio.html).

Just wondering if you're planning a separate process to notify about these specific BTP notes.

Thanks!

[JürgenAdolf]

Hi Yaryura,,

Thank you for your inquiry and your interest in staying informed about critical updates in our SAP Business Technology Platform (BTP). You may register for SAP HotNews in SAP for Me via the Trust Center: https://me.sap.com/app/hotnews.

Your commitment to staying informed aligns with our shared goal of ensuring the security and integrity of SAP BTP. We value your feedback and collaboration in creating a secure and robust BTP environment.

Thank you for your understanding and ongoing partnership.

Best regards,

Juergen

[LutzR]

Hi juergen.adolf ,

please be more specific in how to configuring this correctly. I am receiving HotNews alerts regularly for lots of components. But yesterday it was only for the IS-OIL note  - not for BTP. Are there some prerequisites like matching customer numbers for S-User and Global Account or something?

<edit> I created case 128992/2023 on XX-SER-FORME for this </edit>

I would very much recommend SAP to make use of other communication channels too, e.g. the channels that are commonly used to alert administrators about necessary maintenance activity (DB-Update, Java runtime update) etc.)

BR, Lutz

[Frank_Buchholz]

Hi Diego,

yes, I'll talk about this note in the monthly Security Notes Webinar (13.12.2023 ASUG / 14.12.2023 Enterprise Support and DSAG) and will tell something like this:

If you just use BTP services (as in SAAS scenarios) but not develop own applications based on these Open Source libraries (especially about the XSUAA) then you are not affected -  Any required update on standard BTP services is already done by SAP.

Now, let's assume that some own applications are developed on BTP by your organization.

I believe, the normal channel for security reports on Open Source libraries (like these ones) for custom development are the corresponding CVEs - you should have some processes to find and update Open Source libraries based on CVE reports in any case. For this type of software, the SAP note comes on top of it.

Neither application System Recommendations in the SAP Solution Manager (which is strong for ABAP, Kernel, Java and HANA), the similar function in SAP Focused Run or the new Recommended Notes in the Maintenance Planner on the SAP Support Portal can support you about this note: The note is classified as "This document is not restricted to any software component" which means that there is no data to check anything using these tools. I'm not aware of any plans to extend these tools.

Thus said, you have to figure out by yourself if some custom development might use the affected libraries: Ask the developers in your team who maintain the code. They can check the library usages and version in dependency files like (pom.xmls, package.jsons, build.gradle, ...).

Greetings,
Frank Buchholz
CoE Security Services

[Cocquerel]

Is there a way (example using CF command line tool) to check which "@sap/xssec" version is using a  deployed Node.js App ?

[vobu]

Hi, first of all thanks for the detailed info on the potential privilege escalation vulnerability.

But if I'm not mistaken, only one of the three affected Node.js libraries is Open Source* - all others are Source Open, as in available on npm, but neither with a public source code repo, nor with an associated Open Source license.

In fact it stands to argue that if they were Open Source, the vulnerabilities might have been discovered sooner (b/c more eyes to the cause) and fixed quicker (b/c more hands to the rescue).

Just my .02€, Volker

*
- https://www.npmjs.com/package/@sap/xssec (not OS)
- https://www.npmjs.com/package/@sap/approuter (not OS)
- https://github.com/SAP/cloud-sdk-js (OS)

[MultivacTest123]

Hello Frank,

thanks for your inside and Information about this Note. What do we understand as own developed Application? We use the integration Suite solely so far, and the only "own" Applications there are, are the iFlows. Those iFlows are mainly build with the SAP given Adapters, i guess those iFlows i can ignore? Some of them have own written groovy scripts with libraries, do i need to check every iFlow with a groovy script then?

Thanks in advance for an answer and have a good day.

Best Regards,
Randy

[juan_jose_cruz]

Hi juergen.adolf,

¿Is sap_java_buildpack_1_81 already released for cflinuxfs4?

Thanks in advance.

[JürgenAdolf]

Hello Randy,

on SAP side all libraries are upated and fine. In a SaaS Scenario you are save.

Best,

Jürgen

[nothafts]

Hello, would it be possible, that such vulnerabilities coud be discovered with npm audit? Thank you.

[sgonzmot]

Hi mickael.cocquerel

Ideally, security should be implemented in the git repositories and added to the deployment pipelines themselves (DevSecOps). However, if you want to see something directly in the deployed container (unless there is another method), I would advise enabling SSH in the space/app. This approach allows you to extract the direct value from the module by executing cat + jq.

For example, you can use the following command:

cf ssh <app-name> -c 'cat app/package.json' | jq '.dependencies["@sap/xssec"]'

After extracting the information, don't forget to disable remote access.

I hope I have helped you!

Greetings!

[LutzR]

Hi juergen.adolf and others @ SAP:

please publish the FAQ-note 3411661. We are waiting for it since the update of the main note (more than 24 hours now.) We permanently get "SAP Note/KBA 3411661 is being updated".

We are waisting time with checking that note's status.

Thank you!

[Cocquerel]

My understanding is that the package.json is only considered at mtar build time. I mean, even if it says to take the last "^3" version  of  "@sap/xssec", if the build was done before the 25th of November when the version 3.6.0 containing the fix was available, it's not good. Is there a way using ssh to check which version is really deployed?

[sgonzmot]

Hi mickael.cocquerel

Unless I'm very much mistaken, the package.json file is the metadata of the application and it's vital within the deployment cycle and startup of the application in Cloud Foundry.

This file is responsible for providing a startup script (by default it's 'start') and installing direct and indirect dependencies (this last point is important, as packages that contain @sap/xssec as an indirect dependency are also affected, this can be seen in the package-lock.json).

Through SSH, we can check the package.json that was used to 'boot' the application and therefore the dependencies that have been installed.

I hope I have helped you!

[JoeGoerlich]

Hello Michael,

before running in the same situation as we had with Log4Shell, I recommend to better start right up building an SBOM. At best, this should be considered when they start developing the first custom applications in SAP BTP. This will help to identify which apps use which libraries and increase the speed when CVEs are issued for those.

For sure, a manual scan for the versions will help to identify progress and left-overs, but its time consuming.

BR,

Joe

[JürgenAdolf]

Hello,

there was technical problem with the note. It should be available again.

We are sorry for the inconvenience.

 

 

 

[KimmoD]

Another option that can be used is to check the installed version directly from installed packages:

cf ssh APP_NAME -c "cat /home/vcap/app/node_modules/@sap/xssec/package.json | grep '\"version\":'"

  "version": "3.2.12",

Kudos to showkath.naseem :

https://blogs.sap.com/2023/12/14/sap-btp-security-alert-%F0%9F%9A%A8-protecting-your-custom-applicat...

And if you have the code locally and need to find out where the old version of the package originates (and you have a more complex app with more than just the approuter, there are 61 dependent packages listed on npm)

npm ls @sap/xssec

This should print the npm dependency tree like this:

└─┬ ui5-middleware-cfdestination@0.6.0
└─┬ @sap/approuter@10.15.4
├─┬ @sap/audit-logging@5.8.2
│ └── @sap/xssec@3.6.0
└── @sap/xssec@3.6.0

[JürgenAdolf]

Yes

[JürgenAdolf]

No, it is currently not possible. CVE import in npm audit is yet  missing.

[showkath_naseem]

Thank you so much for your kind words! I am pleased to hear that my blog post helped you and others.

[gregorw]

Hi Jürgen,

is there a roadmap for CVE import in npm audit?

Best Regards
Gregor

[Cocquerel]

Thanks kdragon . that is exactly what I was looking for.

santiago_gonzalez_mota5 I have tried to just restart the app and as you can see in screenshot, it remains 3.3.5
So, my understanding is that the build of the mtar has to be done again to get the 3.6.0 version and then, the new mtar should be deployed.

[JürgenAdolf]

Hi Gregor,

we have no influence on it, as npm audit is not from SAP.

https://docs.npmjs.com/about-npm

 

Best,

Jürgen

[gregorw]

Hi Jürgen,

I think the colleagues from SAP Cloud SDK as for their package some entries exist in GitHub Advisory Database: ecosystem:npm sap that seems to be the basis for npm audit.

Best Regards
Gregor

[Bodriki]

This post here was done on December the 12th.
The hotnews was

3411067 - [Mehrere CVEs] Rechteausweitung in SAP Business Technology Platform (BTP) Security Services Integration Libraries

SAP-Sicherheitshinweis, Version: 6, Freigegeben am: 13.12.2023

[LutzR]

Hi. Nope. The note was first released on December 12. On 13th it was just updated.
I did not receive notifications for both releases (others did). There is some bug.

BR, Lutz

[LutzR]

Hi juergen.adolf ,

<EDIT> The error was on our side. The Security Contacts did receive the e-mail. Sorry. </EDIT>

some people received e-mails from SAP, inviting them to get their BTP environments scanned. I was one of the lucky ones to receive this e-mail. Thank you!
But I was the only one in our organization to receive this and we would like to know how to get other people of our organization registered to that distribution list, just for redundancy e.g. during holiday season.

We know that the distribution list was not the "Security Contact". He did not receive this. I am not aware to be specifically registered for anything. Can you make transparent on how to get on this kind of distribution list for the future?

Thank you!

Lutz

[sucheno]

Hi juergen.adolf ,

SAP note 3411067 mentions to update the libraries to latest versions for only 3 affected libraries.

https://www.npmjs.com/package/@sap/xssec
https://www.npmjs.com/package/@sap/approuter
https://github.com/SAP/cloud-sdk-js

What about the libraries dependent on these affected libraries?

We use many other libraries which internally uses @sap/xssec and I assume we would have to update those libraries as well.

If we do not update these dependent libraries, those are still fetching the older versions of @sap/xssec library upon deployments.

Below are the examples which we widely use..

https://www.npmjs.com/package/@sap/async-xsjs

https://www.npmjs.com/package/@sap/html5-app-deployer

https://www.npmjs.com/package/@sap/audit-logging

Thanks,

Suchen

[gregorw]

As long as the dependency is defined as:

"@sap/xssec": "^3.6.0",

it will automatically use any version equal to 3.6.0 or higher in the same major version 3.

[sucheno]

Thanks Gregor for your response.

We don't have dependency in our package.json for @sap/xssec library.

But we have @sap/async-xsjs, @sap/audit-logging ... if we don't update the versions of these libraries, we noticed these are downloading the older versions of @sap/xssec as "npm install" downloads the whole tree of all dependent libraries..

My question was to know whether we need to update the libraries of @sap/async-xsjs, @sap/audit-logging .. ?  or can we ignore as the SAP note says only to update the affected.. @sap/xssec, approuter, cloud-sdk..

Thanks in advance.

[VitorBrevilieri]

Same doubt. Any updates? Thanks