Security of the SAProuter
On https://service.sap.com/securitynotes -> News you can find a new spotlight news from 12.11.2013 about Security Notes concerning the SAP Router:
Important security fixes for SAP Router; new malware variant
This news refers to security notes published back in May 2013 and older but which are still open in many customer intallations. The underlying security vulnerability is named in various publications, e.g. in this one on the RSA Conference in Singapore in June 2013: The State Of SAP Security 2013: Vulnerabilities, Threats and Trends from Alexander Polyakov.
You run at least one SAP Router installation within your DMZ which is connected to the internet:
Within this blog here I like to summarize the instructions how to secure the SAP Router. Please feel free to comment on this blog to support me in improving this documentation.
Most important activities:
- SAP recommends to upgrade any (active) SAP Router installation as soon as possible
- Activate SNC to encrypt the communication channel to SAP support
(or use hardware encryption using IPSEC)
- Use an access control list (saprouttab) to limit connectivity
As the SAP Router is an independent and compatible piece of software you can update it without touching other parts of the Kernel – in fact most of the active SAP Router installations are installed on other servers than the application servers of any ABAP system anyway. Therefore SAP recommends to use the latest release everywhere. Currently you can find the releases 7.20 and 7.21 on http://service.sap.com/patches using the search. However, I assume, that release 7.20 perfectly works fine.
Note 1921693 explains how to get and update the SAP Router.
Caution: In opposite to an update of the saprouttab which can be done without restarting the SAP Router (option -n) any active connection will be stopped while replacing the executables.
Neither the EWA / RSECNOTE nor the application System Recommendations in the SAP Solution Manager can tell you if your SAP Router installations are up to date as both tools have only access to the Kernel version (disp+work) of the ABAP system itself. Therefore you have to find any outdated SAP Router installation by yourself. If you have configured the SAP Solution Manager to manage SAP Router installations you can use transaction SOLMAN_SAPROUTER to find installations which are known by the SAP Solution Manager.
These security notes are part of the latest version of the SAP Router:
- Note 1820666 – Potential remote code execution in SAP Router
An attacker could possibly exploit SAP Router in order to take control of an SAP application, including viewing, changing, or deleting data.
- Note 1663732 – Potential information disclosure relating to SAP Router
An attacker could possibly discover information relating to SAP Router connections if SAP Router is used for Internet communication, and if it is started with the option “-n”. This information could be possibly abused to specialize attacks against the application server.
Architecture with IPSEC (hardware based)
Architecture with SNC (software based / certificate based)
- Note 1895350 gives some more recommendation on the secure configuration of SAP Router
- Note 1853140 describes the recommendation from SAP not to use the remote administration option of the SAP Router.
- Note 48243 explains how to integrate the SAP Router into a firewall.
- SAP Router Entry page
- Creating a Route Permission Table
- Option -S to change the default port
- Option -n to update the saprouttab without restarting the SAP Router
Documentation on SMP:
- Step by Step Procedure for SAP Router SNC Configuration
- SAProuter – SNC or VPN?
- Getting Started with SAProuter – Tutorials
These documents all together propose additional activities:
- Change the default port
- Use an SAP Router password for SAP Support
New, June 2014: Do you know about the new option to change the “SAP Router password for SAP Support” for all systems with a single step?
In the past you had to change the password for every system individually. If you run many systems this would be a nightmare, simply killing the option to do it.
Now you find a tiny checkbox in the Service Connection settings labelled with “Apply the changes to all the systems this SAP Router is assigned to“. Using this option you can efficiently set a new password. (If you are using an “Additional SAP Router” you still need to set the password individually for this additional SAP Router.)
If you are running SAP Solution Manager 7.1 you have additional options to monitor and manage the SAP Router.
Note 1886060, this wiki and this blog describe how to setup and configure System Monitoring in the SAP Solution Manager 7.1 for SAP Router.
Active Global Support
thanks for update. I am wondering how many customers are going to update their sap routers. Usually, a sap router gets installed and they nobody touches it for many years unless it breaks. We live in interesting time. It seems to be getting harder and harder to manage infrastructure and many customers are struggling. Cloud does not seem to be really helping with it. Someone may argue that it might even be making some things harder to manage.
Thank you Frank, your updates are much appreciated,
This post pretty much terrifies me. You're sending totally the wrong message and The Register picked up on it today.
Here are my opinions:
1) If you run a saprouter connected to the internet then you deserve to be fired. saprouter is NOT a secure solution to transferring data and in my opinion SAP should not even allow saprouter traffic across the internet. Instead, a secure IPSec VPN should be used, like any sane person.
2) Change the port number? Seriously, this is security by obscurity and that is not security at all.
3) SAP connects to all those customers that have saprouters. It can see exactly what versions and contact them automatically to ask them to update. Then, it can cut off access to customers who leave themselves at risk. This is the only responsible thing to do.
SAP, and particularly Active Global Support, must take a hard stance here and force customers to protect themselves, or you are complicit.
Sorry about such a rant, but I feel really strongly about this.
thank you for pointing me to that article which I've have now forwarded to other teams at SAP (but I guess they already got it).
1) The purpose of the SAProuter is indeed to offer a secure channel from and to SAP:
I agree if you would say that this requires only to accept SNC authenticated and encrypted communication requests from/to dedicated SAProuter servers at SAP which are listed in the local route table.
Therefore, maybe I should move the SNC option from section 'additional activities' to section 'most important activities'.
However, this requires some additional work for the IT team as referenced here on SMP /saprouter-sncadd and described in this document or in this wiki on SCN.
If a company want to raise the security level beyond this point it can apply for Advanced Secure Support which offer various enhanced packages which e.g. include hardware based security extension.
Nevertheless, we should ensure that the first steps is done first by all our customers. This blog tries to raise the awareness about such basic activities.
2) Changing default ports (or changing default url patterns using a virtual host or changing a default user name) are of course not the leading security measures. Usually I use the term 'security by obscurity' only to describe a single insufficient security measure but not to classify additional security activities like this one. Maybe I should move the recommendation to change ports from section 'most important activities' to 'additional activities'.
However, I don't see why anybody should pass information to potential attackers for free. Therefore I generally recommend to replace well-known default values, which easily can be used in a search, to some other values.
3) Some good points, even if mayby very strict, however, at least I, Frank Buchholz, as a technician cannot discuss related activities or plans of SAP here on SCN. Well, at least I've passed your comment to the decision-making team.
Thanks very much for the response. Sorry for maybe over-reacting a bit, I was frustrated by this 🙂
I don't much agree with the first point though - I have seen saprouters on the internet but only when restricted to a firewall to a specific IP. They shouldn't be open on the internet, that's just stupid.
Mostly though I think that SAP should take a proactive stance to protect the security of their customers and hopefully this forum discussion is a launchpad to that end. That would be a great outcome for customers.
Well, it is well documented that SAProuter is not a firewall and the most important patch is 6 months old. Now new vectors come into play and people do stupid things from network topology perspectives sometimes (and generally with available security solutions).
The patch was already alerted to all customers and their defined "Security Contacts" via the Patch Tuesday process in June 2013. Responsible security researchers adhere to the 3 month grace period before disclosing more details, and those are the responsible ones...
If anyone is still not patched, then it is most important that they patch their SAProuters now.
This blog by Frank certainly helped me to convince customers to patch their SAProuters, as mine are patched since May 2013 (onwards) and I did not experience any problems.
Luckily there are not many, but from time to time there are some corrections which must just go into the systems as prio 1 and the naughty folks are onto it already.
If you are 6 months late then you should be frustrated by that and not public awareness, but ideally realize that you just need to upgrade your router and keep a closer eye on the Patch Tuesday process. Not everything is in RSECNOTE.
I hear you Julius but I don't understand why SAP wouldn't take a much firmer view on customer's security. You can see the impact in the press, here:
So it should be simple:
- saprouters open to the internet get blocked (filtered by IP might be OK)
- saprouters that are on an insecure version get blocked
- saprouters not using SNC get blocked (not sure if this is possible any more anyhow, I maybe out of date)
Why should there be any middle ground here? Who does it benefit? SAP gets hurt badly by press like the article above.
You can be sure that SAP's own routers are patched...
But blocking unpatched routers and forcing SNC I cannot easily imagine because of backward compatibility.
But SAProuters are not only used for opening a connection to SAP OSS systems. There are also "hosters" which use it (some of them even park their SOLMANs and webdispatchers on the outside of the firewall..) and there are customers which use it correctly behind the firewalls for their own SAPGui -> Server connections via router strings.
6 months down the line, it is now important that the late patchers upgrade their SAProuters (at least that).I understand that to be Frank's main message and he provided more information additionally about how to fox the (new) Trojan vector looking for router and then their SAPgui ports.
Great new tutorial:
Getting Started with SAProuter - Tutorials in Software Support and Maintenance
I am very much impressed after reading this blog. Very well explained about SAP Router and the security involvement. Pictures that you have attached is awesome. Keep up the good work. Its very useful for our security members who are working in our projects. I will try to share your weblinks to them and this will help us to learn & upgrade themselves. All the best. Waiting to see more updates from you. 😎