- July 13, 2020
2FA for SAP, and how to hack it
Ever since GDPR was introduced in 2018, personal data stored in SAP systems has needed to be better protected. To achieve this, most auditors suggest or even demand, the use of 2-Factor-authentication, and the use of password-based login is being discouraged. When authentication is not secured for all end-users, then the accounts with privileged access rights should be prioritized. However, unless its properly configured and continuously monitored, 2FA can be also be hacked, resulting in identity theft.
2-Factor Authentication for SAP
As the name suggests 2FA, typically demands two components to co-exist, in the same place, at the time of login. In practice, this typically means the end-user has a physical device such as a SmartCard, and a memorized PIN number.
When the end-user wants to login to SAP, the SmartCard is inserted into the reader device. A chip on the SmartCard has encrypted storage, which for example stores a X.509 certificate. A PIN can be used to unlock the storage, making the certificate accessible. Once unlocked the SAP Secure Login Client can read and match it with the information stored in the SAP User Master to process the login.
Better than passwords?
The principle is simple, as even if the physical device is stolen, the thief still requires the PIN, which is ideally only stored within the memory of its’ owner.
SecurityBridge is a modern SAP Security Platform, natively build in SAP. It uses an ABAP based Intrusion Detection System (IDS) to guard your SAP landscape 24/7. Its frontend is build with Fiori, which provides you an intelligent insight on the security posture of your ABAP, Java and HANA based systems.
Required components
Needless to say, you need an SAP NetWeaver instance which needs to be Secure Network Communications (SNC) enabled. In addition, the client (laptop or desktop) requires a software component, the so-called SAP Secure Login Client. The software can be found in the SAP Download Portal.
Under the assumption that the SAP Logon application is already available on the machine, connection entries need to be pushed to the saplogon.ini configuration file.
Additionally, when Public Key Infrastructure (PKI) is the desired mechanism, SmartCards containing certificates should also be available.
Activation of SNC/SSO
SAP NetWeaver
Start by setting the profile parameter snc/enable to 1 and the value for the parameter login/disablepasswordlogon to either 1 (to allow some users, e.g. emergency users to logon via password) or 2 (to generally disable password logons). Once done you’re pretty much good to go. Other relevant parameters that need to be considered are:
- snc/enable = 1
- snc/acceptinsecuregui = 1
- snc/acceptinsecurerfc = 1
- snc/acceptinsecurecpic = 1
- snc/acceptinsecurer3intrfc = 1
- snc/permitinsecurestart = 1
- snc/extidlogindiag = 1
- snc/extidloginrfc = 1
- snc/gssapilib = /usr/sap/<SID>/SYS/exe/run/libsapcrypto.so
- snc/identity/as = p:CN=<name>, OU=<organization>, O=<company>, C=<country>
( CN can be freely chosen but best practice is sap<instance no>.<hostname> ) - spnego/enable = 1
SAP User Master
Within the SAP User Master transaction SU01, the SNC tab needs to be maintained with the canonical name that also exists within the certificate.
SAP Certificate Store
In transaction STRUST, an entry for the node „SNC SAPCryptolib“ should be entered, to give the SAP NetWeaver a canonical name.
At the same level, the admin has to add trusted certificates in order to make the login process work. Making use of the root certificate is recommended, instead of adding each end-user certificate into the list.
Client adjustments
Great! You have configured SAP NetWeaver. This is the moment to run a test, before rolling out the required client software and SAP Logon connections.
Install the SAP Secure Login Client in addition to the SAP Logon software.
Create a new connection entry with the necessary SNC parameters. You will see that the newly added entries show a different symbol.
You are now good to go. Put the SmartCard into the Laptop’s reader and initiate the login by selecting the previously created connection from the SAP Logon. Unless the SmartCard storage was already unlocked, you will be prompted for the PIN. If all works well, you should see a slightly different logon screen (see screenshot below), or if you have access to a single client only, you will be logged in automatically.
Congratulations!
Security considerations
How secure is the approach described above? Let’s recap how it works. The certificate existing on the SmartCard is mapped against the SNC name in the SAP User Master. The SNC name, used for the login, is an attribute of the SAP account.
This means that there are two links an attacker could try to break. The first link exists between the end-user certificate and the SNC name stored in SAP. The second link exists between the SNC name and the SAP account.
Attack scenario
Remember – the weakest link, breaks the chain!
What are the scenario’s our „virtual“ attack would consider?
- Option: Stealing the SmartCard
Well that’s what a 2FA device is made for. Without the PIN, the attacker cannot use the card. Also, stealing the device will reveal that an attack is planned or ongoing. - Option: Imitate the certificate
Not a bad idea, but very hard to realize. Certificates are based on encryption processes. The attacker would require access to the certification authority and needs the root certificate, to sign their copy of the certificate, before the SAP instance would trust that the cloned certificate is legitimate. - Option: Alter the link between the SNC name and the SAP Account.
However, this attack vector would not result in success for an external attacker as access to the SAP application is required.
Wonderful ! You’ve established a bullet-proof login procedure. While focusing on the external attacker scenario, however, we’ve entirely forgotten about what an inside attacker could do.
Insider attack
Consider the following scenario: The insider has a working SmartCard and already gained access to maintain the SAP user administration.
However, the insider plans to steal the SAP identity of another user, which may instantly affect system integrity. Forensic investigations later on, will provide evidence of the actions performed, connecting us to the victim of the identity theft instead to the real attacker. If you don’t monitor the SNC string changes, attackers can use this circumstance to theft identities without knowing the passwords of their victims and without owning their 2FA device.
That’s only one scenario but compromising the entire system will require access to a privileged account. In this case the insider might target any of the well-known privileged accounts instead eg: (SAP*, DDIC, Firefighter).
Measures to prevent insider attacks
- Protect and restrict manual maintenance of SNC names
- Source the SNC name from an external user management system, instead of referring to a direct user master attribute
- Monitor the system (e.g. through change documents) for SNC name manipulation.
- When no manual user-maintenance is required, hide the SNC register from SU01
- Monitor direct table updates (USR – Tables)
Automate the process with a Threat Detection Platform such as SecurityBridge, that will continuously monitor all activity in real-time to cover security aspects that enables you to prevent an insider manipulating the SNC names within your system.
Looking into securing your SAP landscape? This white-paper tells you the “Top Mistakes to Avoid in SAP Security“. Download it now.
