This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

SAP HANA – SSL Security Essential

The HeartBleed hack exposed the consequences of security holes in software designed to provide encryption of network traffic.
However, this doesn’t mean that all encryption software has holes and it’s certainly better to have some form of encryption than none at all.

I’ve watched numerous online demos, official training videos and worked on real life HANA instances.  All of these systems so far, have not enabled SSL (now called TLS)  between the HANA Studio and the SAP Host Agent or the HANA Studio to the HANA database.
This means that specific communication between the HANA Studio, the SAP Host Agent and the HANA database indexserver, is not encrypted.

The HTTP protocol has been around for a long time now (thanks Tim).
It is inherently insecure when using HTTP BASIC authentication, since the username and password which is passed over HTTP to a server that has requested authentication, is sent in the clear (unencrypted) but encoded in BASE64.
The BASIC authentication is used to authenticate the HANA Studio with the SAP Host Agent.

What does this mean with regards to SAP HANA and the SAP HANA Studio?
Well, it means that any user with a network packet sniffer (such as Wireshark) could intercept one vital password, that of the <sid>adm SUSE Linux user.

In a SAP HANA system, the software is installed and owned by the <sid>adm Linux user.  Usually <sid> is a unique identifier for each HANA system in a SAP landscape.  As an example, H10 or HAN or any other 3 alphanumeric combination (within certain SAP restrictions) can be used.
When the HANA Studio is used to control the HANA database instance (start up and shutdown), the HANA Studio user is prompted to enter the username and password for the <sid>adm user.
This username and password is then sent via HTTP to the SAP Host Agent installed on the HANA server.  The SAP Host Agent uses the username and password to start or stop the HANA database instance.
If the password for the <sid>adm user is obtained, it is possible for a malicious user to establish an SSH connection directly to the SUSE Linux server where the HANA instance is installed, then control the instance, or access the database directly using a command line interface for executing SQL statements.

Here’s a 6-step example which took me 10 minutes to setup, trace, collect the data and then login to the Linux server as an authorised user.

Step 1, Install and open Wireshark (on your PC) and start tracing for TCP connections to the HANA server on the Host Agent TCP port 5<xx>13.
Step 2, Launch HANA Studio (on your PC) and in the navigator right click and choose “Log On”:

HANA  Logon without SSL

Step 3, If you haven’t elected to save the username and password during previous use of the HANA Studio, you will be prompted.  Otherwise, the system will auto-logon to the Host Agent.
Step 4, Analyse the Wireshark capture.  You’re looking for the text “Authorization: Basic” in the TCP packets:

HANA Logon Wireshark trace

The actual string will look something like: 
Authorization: Basic aDEwYWRtOmhhbmFoYW5h
I’ve copied an example HTTP POST out to a text editor for easy viewing:

HANA SAPControl HTTP POST

POST /SAPControl HTTP/1.1
Accept: text/xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Authorization: Basic aDEwYWRtOmhhbmFoYW5h
Content-Type: text/xml; charset=utf-8
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.7.0_45
Host: hana01.fqdn.corp:51013
Connection: keep-alive
Content-Length: 248

Step 5, Decode the username and password in the BASIC authentication string using a base64 decoder.  It’s possible to use an online one:

HANA SAPControl HTTP POST BASE64 decoder

The output includes the username and password in the following format:
USERNAME:PASSWORD

Step 6, With our new found details, log onto the HANA server using an SSH terminal:

HANA Server Logon

From this point onward it’s possible to access any data in the HANA database using command line tools.

SUMMARY:
You MUST enable SSL (TLS) encryption of the HTTP communications between the HANA Studio and the SAP Host Agent.  Without this, you might as well put the password on a post-it note on your screen.
See https://service.sap.com/sap/support/notes/1718944

Another option would be to segregate the HANA Studio users on their own vLAN, or to firewall the SAP HANA Host Agent and HANA database indexserver ports, tying them to specific user PCs only.
Incidentally, the password for the SYSTEM user of the HANA database, is encrypted with SHA256.  The encrypted string is then compared with the already encrypted password in the HANA database in order to authenticate a user.
However, if you have not enabled SSL between the HANA Studio and the HANA database indexserver, then all the of data retrieved from the database is sent in the clear.  You don’t need to authenticate to the database if you can just read the network packets.  This is true of most database connections.

HowTo: Use Oracle BBED to adjust DB Name in File Headers

HowTo: Use BBED to hack the database SID in the datafiles if you’ve gone and got them all mixed during a “CREATE CONTROLFILE” operation.

WARNING: Using BBED is not supoprted by Oracle unless you are asked to use it by Oracle Support themselves.

Use UNIX vi to create a text file that contains a line number, followed by the file name for the DB files that need changing:

# cat <<EOF > filelist.txt
1 /db/ora/system/system1.dbf
2 /db/ora/data1/data1.dbf
3 /db/ora/index1/index1.dbf
EOF

Save the file as “filelist.txt”.

Launch bbed (blockedit) as the Oracle DB UNIX owner.
Change the text “NEWID” for your new DB name in the “modify” line below.

$ bbed
BBED> set listfile 'filelist.txt'
BBED> set mode edit

# Dump the current block value for datafile #1 in your list file.
# exmaple: BBED> dump /v dba <file#>,<block> …

BBED> dump /v dba 1,1 offset 32 count 16

Make the swap:

BBED> modify /c NEWID file 1 block 1 offset 32

The checksum is now invalid:

BBED> sum file 1 block 1

Force save the new checksum:

BBED> sum file 1 block 1 apply

Verify the block:

BBED> verify file 1 block 1

Once you’ve done all your files:

BBED> quit;

Start the database with the CREATE CONTROLFILE SET DATABASE “NEWID”…

Controlling FUGR Access

If you have a super user role in your production system, it’s quite possible that use of the SUPRN_INS_OR_DEL_PROFILE or BAPI_USER_PROFILES_ASSIGN function modules could be used from SE37 to give SAP_ALL and then proceed to get around other restrictions.
Since SUIM relies upon S_DEVELOP and activity 16, you can’t just remove it unless you leave the admins to find their own way to the underlying transactions.
Instead, you could lock down the S_DEVELOP authorisation object by removing access to the specific function group (FUGR).
When editing the authorisations of a role, set one of the S_DEVELOP authorisation objects to exclude FUGR (and DEBUG):
Activity = 03 & 16 (Display & Execute)
Package = *
Object Type =
4              to DE
DEVC     to FU
FUGS     to Z
Z              to $TM
Then add another S_DEVELOP authorisation object “MANUALLY”.
Set this to exclude the SUPR, SUPRN and SU_USER function groups:
Activity = 03 & 16 (Display & Execute)
Package = *
Object Name =
0              to SUNI
SURI      to SURI-SU_UPGTOOLS
SU_USER_GRP_SURFACE to Z*
Z*           to $*
Object Type = FUGR