Kids, don't do that at home. We are only using tools and technics that are long known... |
We are starting with no knowledge about the system or the network (beside guessing that there is an R/3 system). Since most SAP customers are using an Oracle database chances for such a system are high. Our tool of choice is a Laptop with some network tools, an Oracle client, and the SAP kernel. We need network access, for example an unused port, a mini-hub, or we use a port connected to a printer. And now we start sniffing the network traffic.
SAP R/3 system communicate on possibly many ports. The application server listens on a port from 3200 to 3299, the message server on a port in the range 3600 to 3699. The last two numbers are called the system number. You can change the port numbers, but chances are very high, that the customer uses ports in these ranges. Have a look at the command line for tcpdump (Abbildung 1). There are other tools as well that you can use.
Abbildung 1. Packet sniffer
#!/bin/sh tcpdump -n -i eth0 'tcp[13] & 3 != 0 and \ (( tcp[2:2] >= 3200 tcp[2:2] < 3300) or \ 5 ( tcp[2:2] >= 3600 tcp[2:2] < 3700))' |
tcpdump will show all connects to the application servers. The expression tcp[13] & 3 != 0 matches these TCP packets. The option -n displays only IP addresses, no names. We note the output (Abbildung 2, the output has bee shortened.
We know one or more SAP application servers, and can now start looking at them in more detail. First defense against the sniffing attack is using a switch (most people do that by now). Nevertheless there are attacks against switches that degrade them to hubs. After that, the sniffing attack is again possible.
We now choose an unused IP address for our laptop (or use DHCP). Now we face the danger to get detected, since we are using an active network setup. It might be helpful to sniff DNS packets to get the IP address of the DNS server.
We use SAPGUI to connect to the SAP system. The last line in the window is the status line which tells us the System-ID. The System-ID is the same as the Oracle System-ID (if Oracle is used). If we have seen a connection to port 36nr we can use lgtst to get more information about the system.
We are now looking for the database server of the SAP system. A portscan on the SAP application server might reveal a message server and an Oracle port (Abbildung 4).
A wild guess: We are facing a SAP system with database and central instance on one machine. We can verify that with sapinfo (Abbildung 5). sapinfo is part of the RFC-SDK on the GUI CD.
Abbildung 5. Using sapinfo
cracker# sapinfo awhost=ip-address sysnr=nr SAP System Information ----------------------------------------------- 5 Destination hostname_SID_nr Host hostname System ID SID 10 Database SID DB host hostname DB system ORACLE SAP release 40B 15 SAP kernel release 40B RFC Protokoll 011 Characters 1100 Integers BIG 20 Floating P. IE3 SAP machine id 320 Timezone 3600 (Daylight saving time) |
If the SAP Host has only one NIC we are ready. Otherwise it might help to use lgtst or queries to the DNS server to guess the right IP address.
Starting from noting we gained the following knowledge:
The IP addresse(s) of the victim
The SAP systemnumber (last to numbers of the SAP port)
The System-ID of the SAP system and the oracle database
The name of the database server
This is all wee need to know about the database, so we now launch our attack.
We craft a SQL-NetV2 konfiguration which will give us access to the database. We need the file sqlnet.ora (default SAP file, see Abbildung 6) and a file called tnsnames.ora (Abbildung 7). The environment variable TNS_ADMIN contains the path to these files, but on our laptop we are free to use whatever we like anyway.
Abbildung 6. The file sqlnet.ora
################ # Filename......: template sqlnet.ora # Name..........: 5 # Date..........: ################ AUTOMATIC_IPC = ON TRACE_LEVEL_CLIENT = OFF SQLNET.EXPIRE_TIME = 0 10 NAMES.DEFAULT_DOMAIN = world NAME.DEFAULT_ZONE = world #SQLNET.AUTHENTICATION_SERVICES = (ALL) |
Abbildung 7. The file tnsnames.ora
SID.world = (DESCRIPTION = (ADDRESS_LIST = 5 (ADDRESS = (COMMUNITY = sap.world) (PROTOCOL = TCP) (Host = hostname) (Port = 1527) 10 ) ) (CONNECT_DATA = (SID = SID) (GLOBAL_NAME = SID.world) 15 ) ) |
If the default passwords have not been changed we can use the SQL command connect sapr3/sap@SID in svrmgrl to cennect to the database – thank you for playing. Otherwise we have to use the OPS$ access to get the SAPR3 password (Abbildung 8). So create a user sidadm and start playing...
Abbildung 8. Hacking Oracle
Current SAP R/3 releases store the SAPR3 password encrypted in the table SAPUSER. We have two ways out:
Attack the encryption.
Use SAP tools to access the database, for example R3trans.
Abbildung 9. R3trans for Oracle access
sidadm> export PATH="$PATH:/oracle/SID/817_32/bin:/usr/sap/SID/SYS/exe/run" sidadm> export dbms_type=oraexport DIR_LIBRARY=/usr/sap/SID/SYS/exe/run sidadm> export dbs_ora_tnsname=SID 5 sidadm> export TNS_ADMIN=/home/sidadm sidadm> cat control export compress=no client=000 # select table where name = T000 select * from t000 sidadm> R3trans control ... 10 sidadm> strings trans.dat ... q 000SAP AG Walldorf DEM [...] q 001Auslieferungsmandant R11 Kundstadt EUR [...] ... |
An attacker might do:
clientremove ;-)
export tables and analyze them offline
import a user with SAP_ALL rights
import other data
Hacking is fun. The only means against the attack is denying access to the database port, either with a packet filter or with a protocol.ora configuration (Abbildung 10).
Abbildung 10. The file protocol.ora
tcp.nodelay = true tcp.validnode_checking = yes tcp.invited_nodes = ( ip address, ip address ) 5 |
The only drawback is that a new application server must be added here too, as well as other systems of the transport landscape might be (for test imports).