Loading...
 

MorphIT Security

Concepts and considerations regarding the security of the MorphIT application

1. system curing

The components used for MorphIT were put together additively. Thus, only those functionalities were used which are also necessary for the operation of MorphIT.

2. data and information protection

2.1 Passwords

Passwords are not stored directly in the database, but only their hash values. A limited validity can be linked to these. When creating passwords, the password strength can be checked.

When passwords are entered, they are displayed hidden by the browser.

2.2 Encryption

The web server used for MorphIT can be configured to only allow communication via TLS (≥1.2) with server authentication and with encryption.

The TLS version used depends on the installed NodeJS version and the browser used. All NodeJS versions supported by ClassiX support at least TLS version 1.2. NodeJS versions > 12 (and some older LTS versions) also support TSL version 1.3.

2.3 Client authentication using mTLS

Access to the web service interface of the MorphIT servers can be configured by activating mTLS so that only clients that can present a valid certificate can also establish a connection with the MorphIT server. This option applies to all HTTPS connections and can be activated as an additional security level in normal MorphIT operation.

2.4 Session security

For MorphIT it was decided to implement session management via WebSockets. There is a permanent connection between client and server, so that the server can assign the session to this message from the information about which WebSocket a message was sent.

This eliminates

  • meetings and associated takeovers of meetings
  • Possibilities for cross-site request forgery
  • URL parameters with potentially sensitive information (exception: direct links).

2.5 Caching

To avoid unnecessary caching the following headers are set:

Pragma: no-cache
Cache control: no-cache, no-store
Expires
Date

2.6 Other security-relevant headers

The following headers are set to further increase security and prevent unwanted browser behaviour.

Strict-Transport-Security:max-age=15552000; includeSubDomains
X-DNS prefetch control:off
X-Download-Options:noopen
X-Frame Options:SAMEORIGIN
X-XSS protection:1; mode=block

2.7 Security in static mode

The security aspects of MorphIT without a standing web socket connection are described in detail here .

2.8 Sensitive data in direct links

Direct links are used to jump directly to a certain position in ClassiX when opening the link or to perform a certain action. When using direct links the following guidelines are implemented in ClassiX:

  1. The URL parameter contains only a token and no user- or action-specific, sensitive data.
  2. The token is randomly generated and does not allow any conclusions to be drawn about the associated action.
  3. If the token executes an automated action, only this action is allowed and after executing the action the ClassiX instance is terminated and the client connection is disconnected.
  4. The token is only valid once.

2.9 Protection of sensitive assets

The release of sensitive assets can be configured so that:

  1. Access is only possible after login with the corresponding cookie
  2. The paths are encrypted, so that even as a logged-in user, valid paths cannot be guessed
  3. Access via the link is only possible as long as the instance that generated the link is active

The technical implementation of this concept is documented under "private assets".

3. integrity and injections

3.1 Specifying MIME types

For files output from the Web Server, the header specifies the MIME type and, where appropriate, the encoding. To support this, the header

X-Content-Type-Options:nosniff

set.

3.2 Cleaning of user inputs

To prevent injection, all HTML-relevant meta-characters are HTML-coded. Exclusively statically given elements are excluded from this. Furthermore, there is no direct possibility to manipulate DOM structures.

Even when compiling headers, the system does not rely on user input, but only on static content.

4. server integrity

4.1 Connection security

The MorphIT server communicates with all server-side processes via web socket connections, which can optionally be secured via SSL. Due to the standing connection, processes do not have to be authenticated for each request and the connection cannot be manipulated by third parties.

A separate port can be defined for communication with each of the following components, so that the connection establishment can additionally be monitored and restricted by a firewall for each component.

4.2 Launchers

The launcher is set up as a service independent of the server. This means that the launcher does not need to authenticate itself to the server. The server accepts incoming launcher connections that know the registration protocol. A check would mean that the server must have control over the launch of the launcher process to give it a shared secret. Since the launcher services can be distributed over several computers for scaling, this is not possible. This also allows the number of launcher processes to be adjusted to the load at runtime if necessary. An attacker who knows the protocol could potentially impersonate a launcher instance and start processes on request.

However, the server does not allow two launcher instances from the same IP address, as two launcher processes on one machine do not make sense. In addition, as already mentioned, the port for incoming Launcher connections can be closed by the firewall for external connections.

4.3 ClassiX

The server distinguishes between two types of ClassiX instances: interactive & background.

Interactive instances are mainly used in test & development and can log on to the server without further authentication. In the standard configuration (ws.morphit.interactive.connect_to_morphit), however, incoming MorphIT connections are never connected to interactive ClassiX instances, so that an attacker who logs on to the server as interactive ClassiX instance does not get access to the client connections.

Background instances are those which the server starts itself when required. It is not possible for an attacker to impersonate a background instance. This is ensured by the fact that the server generates a random nonce value together with each start command, which is associated with the start and given to the launcher. This nonce value is set by the launcher as environment variable in the started process and the started ClassiX process has to log on to the server with exactly this nonce value. The nonce value loses its validity after the login. If a ClassiX process logs on as background instance with a wrong nonce value, the connection to the server is disconnected and the process does not receive any client connections.

An attack scenario would have to look like the following:
condition: The attacker has access to the intranet, but not to the server.

  1. The attacker poses as a new launcher process
  2. The attacker waits until a new ClassiX instance must be started (start command). He cannot directly impersonate a ClassiX instance, because the connection is rejected without the nonce value from the start command.
  3. The attacker pretends to be a newly started ClassiX instance with the nonce value from the start command.
  4. The attacker waits until the ClassiX instance is connected to a MorphIT client.
  5. The attacker can now make the client believe that he is connected to a ClassiX instance and thus tap sensitive data.

In summary, the attack scenario is very cumbersome. The attacker must already have access to the intranet and must wait until an instance has to be started and it is assigned a client without being detected during this time. If he succeeds in doing so, he cannot take over a connection selectively, but receives a random connection assigned by the server. In order that the attack is not noticed and the client discloses the data to the attacker, he must fully implement the MorphIT protocol and respond to corresponding requests with the correct views.

4.4 Admin Console

The admin console, which provides access to the status of the server, can shut down the server and also control it to a certain extent, only connects to the local address by default for security reasons and the server rejects all admin connections from remote addresses. A whitelist of IP addresses for which incoming admin connections are allowed can be defined via ws.admin.allowed_ips, but it is never possible to access the admin interface from any address.
The admin console can also be completely deactivated via the option(ws.admin.enabled) if there are security concerns.

Since the admin console is necessary for a smooth MorphIT update, there is also the possibility to deactivate only the eval command of the admin console via the option ws.admin.allow_eval to prevent a possible privilege escalation by eval, if an attacker has already gained user access to the machine on which the MorphIT server is running and if it is running with higher privileges.

4.5 WebWidgets

MorphIT's web widgets (widgets implemented exclusively as web components) use the same communication channel in regular MorphIT operation as the rest of the MorphIT client. Therefore there are no security concerns.

If the user works on a native ClassiX, the web widgets can also be used, provided that the ClassiX has an existing connection to a configured MorphIT server. If the client opens a WebWidget, a browser will open and establish a connection to the server, which allows the client to communicate with exactly one widget. The WebWidge endpoint can be configured to run on a different port than the MorphIT endpoint. This prevents any client that has access to MorphIT from impersonating a WebWidget-client by blocking the port used.

If there are several open WebWidgets, there are several browsers, each of which connects to the server. So the server has to connect several web widget connections with one ClassiX connection. For this, the server needs the ClassiX ID (ascending number) and the widget ID. Both parameters are transferred via the URL when opening the browser. To prevent an attacker from connecting to the web widgets of a user by guessing the ID of his ClassiX instance, an additional session ID, randomly generated by the ClassiX instance when registering at the server, must be passed on during the connection establishment. This session ID is also transferred via the URL. Since there is no way to ensure that a URL is opened by a certain user (without explicitly authenticating him/her by login), this is the highest security level that can be achieved when establishing a connection. If somebody knows the link, he or she can access the WebWidget. However, there is a limitation that only one connection per widget-ID is accepted.

To prevent an attacker from connecting to the ClassiX instance of another MorphIT client as a WebWidget client, the server divides the ClassiX instances into two exclusive modes. A ClassiX connected to a MorphIT client cannot be connected to WebWidget clients and a ClassiX connected to WebWidget clients will not be connected to a MorphIT client.

With native web widgets the server only forwards messages of type web_widget to the connected ClassiX, all other messages are answered with an error message. In addition, the server prevents a web widget registered under a widget ID A from sending or receiving web widget messages to a widget with the ID B.