security Archives » Page 2 of 3 » Musings of an IT Implementor

Secure ReadyNAS Duo (v1) ADMIN Share

If you have a ReadyNAS Duo and you’re happy with your setup and are now sharing your shares out through your router over the internet, you need to be aware that any old hacker can try and access your ADMIN share (e.g. https://<your-readynas>/admin).

I use mine in exactly that way but don’t want Mr A.Hacker trying out a myriad of passwords on my ADMIN share just because my public shares have “Netgear ReadyNAS” plastered all over the front page (a tip for another day I feel).

Instead, if you’re comfortable using SSH, (there is a way to do this by using the FrontView config backup, edit the file and put back in place) then you can edit your Apache httpd.conf configuration file so that access to the ADMIN share is restricted to a host or hosts on your local home network only.

Steps:

1, Log into your readynas via SSH as root.
2, Backup your old config file:

# cp -p /etc/frontview/apache/httpd.conf  /etc/frontview/apache/httpd.conf.bak

3, Use ‘vi’ to edit the httpd.conf:

# vi /etc/frontview/apache/httpd.conf

4, Change the sections as follows:

<Location /admin> 
DirectoryIndex index.html
Options ExecCGI
AuthType Basic
AuthName “Control Panel”
require user admin
# block external admin.
Order Deny,Allow
Deny from all
Allow from 192.168 <<< INSERT YOUR LOCAL NETWORK IP ADDRESS SUBNET HERE
</Location>

and

<Location /get_handler> 
SetHandler perl-script 
PerlHandler get_handler 
PerlSendHeader On 
Options ExecCGI 
# Order allow,deny 
# Allow from all 
AuthType Basic 
AuthName “Control Panel”
require user admin 
# block external admin.
Order Deny,Allow 
Deny from all 
Allow from 192.168 <<< INSERT YOUR LOCAL NETWORK IP ADDRESS SUBNET HERE
</Location>

plus

<Location /dir_list>
AuthType Basic
AuthName “Control Panel”
require user admin
Options ExecCGI
#Allow from all
Order Deny,Allow
Deny from all
Allow from 192.168 <<<– Insert your subnet here.
</Location>

5, Save the changes with:

6, Restart your readynas:

# shutdown -r now

7, Test from your local network that you can access the ADMIN share:

https://<readynas IP>/admin

8, Test from the internet that you can’t access the ADMIN share:

https://<ISP IP>/admin

You should see a HTTP 403 FORBIDDEN error.

That’s it.
If you made an error, you can restore your config from the backup file you took:

# cp -p /etc/frontview/apache/httpd.conf.bak /etc/frontview/apache/httpd.conf

and then restart your readynas.
Don’t forget to check the config after you make any changes to shares / firmware etc.

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.

Why You Should Never Use J2EE_ADMIN for SLD Access

If you have a SAP Java stack (either pure or part of a dual stack), you should never ever use the J2EE_ADMIN account (or any other high privileged account) to access the SLD.
This is because on most SAP systems, the standard out-of-the-box installation and configuration for the SLD does not use SSL for communications to/from the SLD.

If you use the J2EE_ADMIN account to access the SLD, then each authentication request that the SLD issues to the client system (the SAP system querying or updating the SLD) will be sent unencrypted.
If the client system responds with the J2EE_ADMIN account username and password (if you put this in the NWA or RZ70) then the username and password are simply combined into a standard HTTP BASIC authentication response (https://www.w3.org/Protocols/HTTP/1.0/spec.html#BasicAA).

Essentially the username (J2EE_ADMIN) and password are combined into a string like this: <user>:<password> and then encoded (not encrypted) with BASE64.
This will then be sent in the clear (unencrypted) across the network to the SLD.
If you have Java stack full HTTP tracing turned on, you can see the authentication requests and responses and therefore see the password.
If you have a network packet sniffer installed, then you can see the authentication requests and responses and therefore see the password.

If you have a SAP PI system, you should really consider using SSL (HTTPS) for the SLD traffic. Since it is possible to completely bring down a SAP PI system by causing mayhem in the SLD.

HowTo: Restrict and remove DEBUG from SAP Roles

Scenario: Having access to the debugger (“/H”) in SAP, could provide the user the capability of circumventing authorisation checks and allowing access to data or modification of data.
You need to restrict or remove access to the debugger in the SAP roles.

The S_DEVELOP authrisation object controls access to the debugger.
You can locate the roles that contain the S_DEVELOP authorisation object using the SUIM report “Roles by Authorisation Values”.

You should edit all user assigned roles that contain S_DEVELOP and ensure that it is set to include a range of values for field “Object Type”, that excludes the DEBUG value:

S_DEVELOP
ObjectType:
4 to DE
DEVC to Z
Z to $TM

i.e. missing out DEBUG.

NOTE: The above is based on SAP R/3 4.7.

This will prevent access to the debugger.

HowTo: Secure ABAP Reports with an Authorization Group

Securing reports in SAP is different to securing transaction codes.
Reports don’t necessarily have to have any authorisation checks inside them.
Instead, you have to assign the reports a authorisation groups to control access.

This is a one-to-one assignment only. So does’t give that much flexibility.
From transaction SE38 in your DEV SAP system, enter the report you wish to secure, then select “Attributes” from the radio options, and click “Change”:

You can maintain in the original language if you wish.

Simply insert the authorisation group you wish to secure the report against, into the “Authorization Group” field and click “Save”:

If you have not created this auth group before, then you will be prompted to create a “New Entry”.
You will be prompted for a transport request.

You should now activate your report:

You can now secure the report by removing this specific auth group from the auth object S_DEVELOP in your roles: