Nimbusec KB

This book includes information about Nimbusec related topics.

API

Information to our Nimbusec API

API

API Documentaion

APIv3 docu:

https://openapi.nimbusec.com/?urls.primaryName=Nimbusec%20Website%20Security%20API%20v3#/

https://openapi.nimbusec.com/cyberrisk/#/

API

FQL Documentation

Server Agent

Additional information about the Nimbusec Server Agent

Server Agent

Installation on Linux

Installation

This guide describes the installation of the Nimbusec Server Agent. The Server Agent is optional for the function of the product, but improves the detection rate greatly. Therefore, it is strongly recommended to install the Server Agent. Installation on Linux and BSD Installation.

Requirements

Create a Cronjob

We recommend two different ways to run our Server Agent:

Method 1: cron.daily

The easiest method is to install a script under /etc/cron.daily. This script will get executed on a daily basis, but the exact time is system dependent. The script would look like the following (make sure it's executable):

/etc/cron.daily/nimbusec

#!/bin/bash
/opt/nimbusec/agent -config /opt/nimbusec/agent.conf

Note: This cron job will run the nimbus-agent as user root! It is not required, nor recommended, to run the Server Agent as user root! To run the Server Agent as a different user, see section Security.

Method 2: crontab

To get more control over the exact time when the agent is run, create a cron job. A cron job to start the Server Agent every day at 1am would look like this:

0 1 * * * /opt/nimbusec/agent -config /opt/nimbusec/agent.conf

Note: It is not required, nor recommended, to run the Server Agent as user root! Please add the cron job to an appropriate user, see section Security.

Security

We strongly recommend to run the Server Agent as different user than root.

It is neither required, nor recommended, to run the Server Agent as user root. This section will describe the steps necessary to run it as a different user.

Select a user for the Server Agent to run as who has the following permissions (Recommendation: Run the Server Agent as the same user, as the web server is running or with a different user that has the same permissions as the web servers user):

If you have to use the cron.daily method, change the script to something like this: /etc/cron.daily/nimbusec

#!/bin/bash
su -c "/opt/nimbusec/agent -config /opt/nimbusec/agent.conf" www-data

or

#!/bin/bash
sudo -u www-data /opt/nimbusec/agent -config /opt/nimbusec/agent.conf

If you use the traditional crontab method, simply add the cron job to the appropriate user instead of root:

crontab -u www-data -e

Run Server Agent in chroot environment

If you want to further restrict the Server Agent, you can also run it in a chroot environment. Our support will be glad to assist you.

Proxy Configuration for Server Agent

To enable use of a proxy for upload to the Nimbusec API, set the environmental variable "http_proxy" using following syntax: http_proxy=http://[user:pwd@]proxy-ip:port/
An example would be: 'export http_proxy=http://username:pwd@meinproxy:8080'

Logging

You may want to log error messages to a logfile instead std.out. Thats of course no problem. Just pipe the output of the agent to the desired file location like this:

/opt/nimbusec/agent -config /opt/nimbusec/agent.conf > /opt/nimbusec/logs/agent-out.log 2> /opt/nimbusec/logs/agent-err.log

 

Server Agent

Installation on Windows

This document describes the Install Process of the nimbusec Server Agent under Windows Server 2008 and 2012. The Server Agent adds extended functionality to the nimbsuec service.

Installation

  1. Download the appropriate version of the Server Agent for your Server from https://portal.nimbusec.com/einstellungen/serveragent 
  2. Copy the the downloaded file to your server and extract its contents. You can choose freely where you want to keep the files. The only requirement is that the user, that will run the Server Agent can access this location and execute the binary.

Task Scheduling

  1. Open the Task Scheduler

    image-1627288339822.png
  2. Select 'Create Basic Task'
  3. Enter a name of the new Task

    image-1627288452793.png

  4. On the next two screens you can select how often the Server Agent should be run

    image-1627288579610.png

  5. Select 'Start a Program' as Action for the Task

    image-1627288635921.png

  6. Click on Browse to select the Server Agent (agent.exe). In the Field 'Add arguments' add the string -config < C:\path\to\agent.conf > (replacing < C:\path\to\agent.conf > with the path to the config file)

    image-1627288732269.png

  7. On the next Screen please tick the checkbox 'Open the Properties dialog for thes task when I click finish' and confirm the screen by clicking 'Finish'
  8. A new windows will open where you can select which User should execute the Server Agent. Please make sure to select 'Run whether user is logged on or not'. Otherwise the Server Agent will not be run in the background.

    image-1627288861425.png

 

Proxy Configuration for Server Agent

To enable use of a proxy for upload to the Nimbusec API, set the environmental variable "http_proxy" using following syntax: http_proxy=http://[user:pwd@]proxy-ip:port/ For the Windows Command Prompt an example would be: 'set http_proxy=http://username:pwd@meinproxy:8080'

 

Server Agent

Agent Configuration

This how-to describes the manual configuration of the Server Agent

Known Limitation

Please note: The upload size of the analysis result is limited to 750MB. To ensure consistency of results, the data will not be analysed if the limit is exceeded.

All errors of the agent, including https communication with the Nimbusec API will be printed to the terminal.

Format

The format of the Server Agent configuration must be in valid JSON. Otherwise the SErver Agent will fail to start. This can be tested with JSON Lint

An example configuration looks like:

Single domain configuration

agent.conf (Linux)

{
  "key": "abc",
  "secret": "abc",
  "tmpfile": "hashes.txt",
  "domains": {
    "example.com": "/var/www/example.com"
  },
  "excludeDir": [ ],
  "excludeRegexp": [ ],
  "includeDir": [ ],
  "includeRegexp": [ ],
  "apiserver": "https://api.nimbusec.com"
}

agent.conf (Windows)

{
  "key": "abc",
  "secret": "abc",
  "tmpfile": "hashes.txt",
  "domains": {
    "example.com": "C:\\iis\\example.com"
  },
  "excludeDir": [ ],
  "excludeRegexp": [ ],
  "includeDir": [ ],
  "includeRegexp": [ ],
  "apiserver": "https://api.nimbusec.com"
}

Multi domain configuration

agent.conf (Linux)

{
  "key": "abc",
  "secret": "abc",
  "tmpfile": "hashes.txt",
  "domains": {
    "example.com": "/var/www/example.com",
    "demo.co.at": "/var/www/demo.co.at"
  },
  "excludeDir": [ ],
  "excludeRegexp": [ ],
  "includeDir": [ ],
  "includeRegexp": [ ],
  "apiserver": "https://api.nimbusec.com"
}

agent.conf (Windows)

{
  "key": "abc",
  "secret": "abc",
  "tmpfile": "hashes.txt",
  "domains": {
    "example.com": "C:\\iis\\example.com",
    "demo.co.at": "C:\\iis\\demo.co.at"
  },
  "excludeDir": [ ],
  "excludeRegexp": [ ],
  "includeDir": [ ],
  "includeRegexp": [ ],
  "apiserver": "https://api.nimbusec.com"
}
Field Description
key Your assigned customer key for the Server Agent. The key can be via https://portal.nimbusec.com/einstellungen/serveragent or by requesting a new from support@nimbusec.com. The key is unique per server and must not be used across multiple servers.
secret Your assigned customer secret for the Server Agent. The secret can be retrieved via https://portal.nimbusec.com/einstellungen/serveragent or by requesting a new from support@nimbusec.com . The secret is bound to a key.
tmpfile Path to a writable location where the Server Agent can store it's temporary file. This file contains the data that is sent to the nimbusec API to analysis and will not get deleted after, but overwritten with each run. Each domain counts as a separate run. This enables you to inspect the data we send to our API.
domains A key value map of domain names and corresponding document roots. The domain name must match the domain name in the portal, else the upload will fail with a access denied message. The document root is the root directory which should be scanned. On Windows the backslashes must be escaped. You can also use forward slashes on Windows.
excludeDir A list of directories which should be skipped. The directories must be absolute file paths. Neither baseline nor webshell analysis will be performed inside these directories!
excludeRegexp A list of regular expressions. If a regular expression matches a file path, the file will be ignored. Be very sure to make the regular expression as strict as possible. The syntax of the regular expressions accepted is the same general syntax used by Perl, Python, and other languages. More precisely, it is the syntax accepted by RE2 and described at http://code.google.com/p/re2/wiki/Syntax , except for \C. Neither baseline nor webshell analysis will be performed inside these files!
includeDir A list of directories which should be included. The directories must be absolute file paths. If this list contains entries, only directories, that begin with the specified values will be regarded for baseline and webshell analysis. All other directories will be disregarded. E.g. document root is /var/www, if /var/www/a is specified /var/www/a files and directories below will be analysed while everything else below /var/www will be ignored.
includeRegexp A list of regular expressions. If a regular expression matches a file path, the file will be anylsed. Be very sure to make the regular expression as strict as possible. The syntax of the regular expressions accepted is the same general syntax used by Perl, Python, and other languages. More precisely, it is the syntax accepted by RE2 and described at http://code.google.com/p/re2/wiki/Syntax , except for \C. Neither baseline nor webshell analysis will be performed inside these files!
apiserver The url of our API server. Only change this if told you by the nimbusec support!

Command Line Options

The agent can be run with the following parameters: (Not all options are available in all versions of the agent)

Parameter Version Description
-h * Displays help and exits.
-config string * Configuration file for nimbusec agent (default "agent.conf")
-follow-symlinks TRUE / FALSE * Toggle following symlinks (default true)
-maxprocs int * Maximum number of processes used (default 2)
-v 11 Displays the version and exits.
-yara 11 Enable YARA engine.
Server Agent

Docker Image

Nimbusec Server Agent Docker Image

This docker image is intended for use with the Website Security Monitor by KSV1870 Nimbusec (https://nimbusec.com). Use of this image requires an active subscription to Website Security Monitor.

This image is published under https://hub.docker.com/r/ksv1870nimbusec/server-agent

What is Nimbusec Server Agent Docker Image?

Let's answer this question step by step.

Nimbusec Website Security Monitor is a cloud-based monitoring solution to check for malicious malipulations on websites.

Nimbusec Server Agent is the server side component of Website Security Monitor. It checks PHP code that is interpreted on the server and therefore cannot be analysed through http requests (as it is interpreted before being sent to the client).

Nimbusec Server Agent Docker Image is a convenient method of distributing the Server Agent to Nimbusec Customers. Its sole purpose is to run the contained server agent.

Basic Assumptions

The server agent runs unprivileged. Per default it runs with the user id 1000. You can supply any user ID if you need to match the permissions of your scan target. While you can run the container privileged or as user root, this is strongly discouraged.

Configuration

Nimbusec Server Agent uses a config file to read instructions. This config file adheres to the following structure.

{
  "key": "$KEY",
  "secret": "$SECRET",
  "domains": {
    "$DOMAIN": "$TARGET_DIR"
  },
  "tmpfile": "/tmp/nimbusagent-hashes.txt",
  "excludeDir": [],
  "excludeRegexp": [],
  "includeDir": [],
  "includeRegexp": [],
  "apiserver": "$API_SERVER"
}

All $-Placeholders need to be provided except for $TARGET_DIR and $API_SERVER. For these two this docker image can fall back on the following default values:

In addition to the configuration options listed above there is one setting that can only be enabled via Environment Variable in this image. Adding the env YARA=true will enable the optional support for yara scan rules. The ruleset is downloaded from the API Server when the server agent is executed.

For additional Information please refer to the Knowledge Base.

Mount your own agent.conf

The most flexible way to provide a configuration is to mount to the container-path /app/agent.config (please note, this path and filename is mandatory). This mount can be read-only

You need to replace the $KEY an $SECRET placeholders from the above example with the corresponding values provided by KSV1870 Nimbusec. For $DOMAIN you can select any Domain that you have configured in your Nimbusec Website Security Monitor Account. Please note, you have to use the correct Style of the domain, i.e. example.com and www.example.com are treated as different domains.

docker run -v /local_path_to_config/agent.conf:/app/agent.conf:ro -v /var/www/html:/app/scan:ro <dockerimage>

This example mounts a local config file and the scan dir of /var/www/html into the container, both read-only.

Pass Environment Variables

If you don't want to provide a custom config file you can pass the Placeholder values (KEY, SECRET, DOMAIN and optionally TARGET_DIR) as environment variables (docker via -e, docker-compose via environment).

docker run -v /var/www/html:/app/scan:ro -e KEY=api-key -e SECRET=api-secret -e DOMAIN=example.com <dockerimage>

This example mounts the target /var/www/html into the container and provides key, secret and domain via enviroment variable.

What gets scanned?

The directory to scan needs to be mounted into the container, either into the default location /app/scan or in a custom directory which is specified via your agent.conf or the TARGET_DIR environement variable. This mount should be read-only. The server agent will not write into this directory.

docker run -v /local_path_to_config/agent.conf:/app/agent.conf:ro -v /var/www/html:/mnt/html:ro -e TARGET_DIR=/mnt/html -e YARA=true <dockerimage>

This example mounts the local config file and the target dir into the container. As the target dir in the container is different from /app/scan we have to specify the container directory to scan as /mnt/html. In addition the YARA env variable enables yara support and downloads the scan rules form the api server.

Recommendations

Advanced

If you want additional insight into the workings of the server agent you can mount the container tmp dir to a local directory. This mount has to be read/write and has to have these permissions for the User ID that runs the agent (either 1000 or a value that you can set via the -u/--user flag).

docker run -v /local_path_to_config/agent.conf:/app/agent.conf:ro -v /var/www/html:/app/scan:ro -u 1234 <dockerimage>

Assuming that the data in the local directory /var/www/html is only readable to user ID 1234, you can provide this ID to the docker container. The server agent in the container is executed with the user ID 1234.

FAQ

FAQ

Configuration

Outdated CMS Version

The use of an outdated version of a content management system (CMS) can lead to various security issues. A list of known security vulnerabilities sorted by version number can be found in the publicly accessible CVE Details database¹. In many cases the only countermeasure is to update to the latest version.

Solution

The best protection against security vulnerabilities due to outdated versions are regular updates. Always use the current version and check periodically for new updates. This also applies for plugins, themes and other third party products used in combination with your CMS.

Vulnerable CMS Version

Your Content Management System (CMS) has known security vulnerabilities which can be found in the publicly accessible CVE Details database¹. Depending on the severity of the vulnerability this may cause security incidents like confidential information disclosure, bypassing access control mechanisms,attacks against users as well as a take-over of your systems by an attacker.

Solution

Stay informed about known vulnerabilities of your CMS and follow instructions of the vendor to fix security issues. Furthermore, always use the latest version and check periodically for new updates. This also applies for plugins, themes and other third party products used in combination with your CMS.

Downloadable Source Code

Source code on your web site can be accessed and downloaded. While this is not considered as a security vulnerability per se, this may provide valuable information to an attacker for a successful attack, such as programming language specific security holes, version numbers located in the source code, programming errors and bugs that lead to possible attacks, etc.

Solution

Make sure your source code is securely stored and it can not be accessed by unauthorized persons.

FAQ

Reputation

Hatred or Violence

Browser plug-ins like WOT [1] allow to evaluate a website by the user, e.g.regarding questionable contents like hate speech, racism or discrimination. Your website has received poor ratings in this category. The result is that the plug-in warns users about a possible danger when visiting your website. This can lead to a damage of your reputation.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

Misleading

Browser plug-ins like WOT [1] allow to evaluate a website by the user, e.g. point out misleading, incorrect or unethical content or unproven product claims. Your website has received poor ratings in this category. The result is that the plug-in warns users about a possible danger when visiting your website. This can lead to a damage of your reputation.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

Adware

Browser plug-ins like WOT [1] allow to evaluate a website by the user, e.g.regarding unwanted advertisements like highly annoying ads and pop-ups. Your website has received poor ratings in this category. The result is that the plug-in warns users about a possible danger when visiting your website. This can lead to a damage of your reputation.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

Experience

Browser plug-ins like WOT [1] allow to evaluate a website by the user, e.g. user experience regarding unacceptable user experience, low quality products or unreliable deliveries. Your website has received poor ratings in this category. The result is that the plug-in warns users about a possible danger when visiting your website. This can lead to a damage of your reputation.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

Scam

Your website has been blacklisted as it has been identified as fraud. This might indicate that your website has been hacked and third parties may have access to your system. This means that your website may harm users by phishing attacks and scam which can have a negative impact on your reputation.

Solution

Carry out an anti virus scan immediately and contact your web hosting provider to inform him about you being hacked. Furthermore, please check the following information that may help you to resolve this issue [1]. If you suffer from hacking attacks frequently or if the problem persists even after the recovery we strongly recommend to consult an IT security expert to help you.

Illegal

Your website has been blacklisted as it has been identified to hosting malicious or illegal content. This might indicate that your website has been hacked and third parties may have access to your system. In Addition to a severe damage of your reputation, hosting illegal and malicious content may have legal consequences for you.

Solution

Carry out an anti virus scan immediately and contact your web hosting provider to inform him about you being hacked. Furthermore, please check the following information that may help you to resolve this issue [1]. If you suffer from hacking attacks frequently or if the problem persists even after the recovery we strongly recommend to consult an IT security expert to help you.

Potentially Unwanted Application (PUA)

Browser plug-ins like WOT [1] allow to evaluate a website by the user, e.g. if the site installs or is involved in the distribution of potentially unwanted programs or applications (PUA) like toolbars without notifying the user. Your website has received poor ratings in this category. The result is that the plug-in warns users about a possible danger when visiting your website. This can lead to a damage of your reputation.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

SPAM

Your website has been blacklisted as it has been identified to send spam. This might indicate that your website has been hacked and third parties may have access to your system. Furthermore, this can refer to insecure configuration of a mail server which is used as an open relay. Another reason for blacklisting can be poor user evaluation via browser plugins such as the WOT Add-on [1] which allows users to tag websites if they are used to sending spam or if they are referred to in spam mails.

The consequence is, additionally to a great loss of reputation, impairment of the e-mail traffic on the system as mails are marked as spam mails.

Solution

Try to figure out the reason why your website has been blacklisted. Check if your system can be used as an open relay and secure your system’s configuration [2]. Moreover, it is recommended to carry out an anti virus scan and to contact your web hosting provider to inform him about your problem. If the problem was due to malicious software, please check the following information that may help you to resolve this issue [3].

If you managed to solve the underlying problem follow the blacklist removal process of the specific blacklist provider.

If you suffer from being blacklisted frequently or if the problem persists even after fixing your configuration issues we strongly recommend to consult an IT security expert to help you.

Malware

Your website has been blacklisted as it has been identified to hosting malicious software. This might indicate that your website has been hacked and third parties may have access to your system. This means that your website may harm users which can have a negative impact on your reputation.

Solution

Carry out an anti virus scan immediately and contact your web hosting provider to inform him about you being hacked. Furthermore, please check the following information that may help you to resolve this issue [1]. If you suffer from hacking attacks frequently or if the problem persists even after the recovery we strongly recommend to consult an IT security expert to help you.

Reputation

Browser plug-ins like WOT [1] allow to evaluate a website by the user regarding several categories. Your website has received general poor ratings by them indicating a bad reputation. The result is that the plug-in warns users about a possible danger when visiting your website.

Solution

Monitor your users’ behaviour and try to find the reason for the poor evaluation. If you suspect that your website has been rated bad unjustified by the intention to harm your reputation, you have the possibility to contact the plug-in developers [2].

The domain of an outgoing link found on your website is on a blacklist. There are two possible causes. Either your website has been hacked, and someone placed malicious links on your website, or the legit website you are linking to has been hacked and was indentified by a blacklist. Both can cause an immediate reputation loss, because search engines use outgoing links in their ranking calculation.

Solution

Review the links. If they lead to legit websites, inform the owner of that website about the blacklist listing. If they lead to unknown/malicious websites delete them and take further actions to resecure your website. Please check the following information that may help you to resolve this issue [1]. If you suffer from hacking attacks frequently or if the problem persists even after the recovery we strongly recommend to consult an IT security expert to help you.

Phishing

Your website has been blacklisted as it has been identified as phishing site. This might indicate that your website has been hacked and third parties may have access to your system. Your website may be misused, by masquerading as a trustworthy entity to obtain sensitive information from your users.

Solution

Please check the following information that may help you to resolve this issue [1]. If you suffer from hacking attacks frequently or if the problem persists even after the recovery we strongly recommend to consult an IT security expert to help you.

 

FAQ

Transport Layer Security (TLS)

Certificate

Legacy Certificates

By legacy we mean distrusted certificates. An example from the past is the distrust of the Symantec PKI [1]. The best solution to date is, to replace the existing distrusted certificate with a new one from any Certificate Authority trusted by Google, Mozilla, Apple and Microsoft (and probably other browser vendors).

Misconfigured Chain

A correctly configured webserver should provide clients with the whole certificate chain up to the root certificate. If the server delivers a misconfigured certificate chain (e.g. incomplete or wrongly sorted) most browsers recover by verifying the certificate via AIA. [1]

This process, however, slows down page loading and browsers that do not support AIA may show the user a security warning.

Revoked Certificate

A Certificate may be revoked for various reasons (e.g. (possible) loss of the private key, domain closed, etc...). This means that the certificate is not valid anymore and users are shown a warning page in most browsers.

Protocol

TLS (Transport Layer Security) or SSL (Secure Socket Layer) is a protocol used to securely transmit encrypted data. Since SSL v3 the protocol is known as TLS, where TLS 1.0 corresponds to SSL v3.1. The currently recommended versions are TLS 1.2 and TLS 1.3. All the other versions are considered weak or contain vulnerabilities.

SSL v3/SSL v3.1/TLS 1.0

Those versions have also considerable security vulnerabilities. A well known attack is the Chained Initialization Vector CBC Mode MiTM Weakness (BEAST) attack. The attack is based on the usage of the CBC mode for encrypting the block ciphers and enables Man-in-The-Middle attacks which can be used to obtain plaintext HTTP header data. [1] Additionally, the key derivation function for the master key depends on a MD5 hash function. The possibility of collision based attacks let the protocol be considered as insecure in general. In October 2014 the POODLE attack has been published. This attack targets all implementations of SSL v3/TLS 1.0 which leads to the point that this protocol is not recommended to use any more. Using a Man-in-The-Middle attack, encrypted data can be decrypted and an attacker can gain access to plain text data. [2]

TLS 1.1 deprecation

The Internet Engineering Task Force (IETF) no longer recommends the use of TLS versions older than TLS 1.2. According to the following draft document (https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/) TLS 1.0 and TLS 1.1 are deprecated. Negotiation of TLS 1.0 or 1.1 from any version of TLS MUST NOT be permitted. All major browser vendors are deprecating support for these versions of TLS by March 2020.

Ciphers

DES

3DES

3DES or Triple-DES is a cryptographic block cipher algorithm which uses 64-bit blocks for data encryption between a client and server. Mostly used for establishing HTTPS connections, this cipher is known to be weak due to his short block size (in comparison, AES uses 128-bit blocks). With the emergence of the Sweet32 attack, there is a documented way of exploiting this trait. [1] The security measures of 3DES start to crumble whenever the birthday bound is reached. The point, at which a collision between the encrypted blocks is expected. Under certain circumstances, the attacker can then retrieve sensible data like session cookies.

Export

Export Cipher Suites are weak by design. They are encrypted but only with weak key material. This leads to the fact that the encryption can be broken very easily as there are used 40 bit or 56 bit algorithms.

IDEA

IDEA uses 64-bit blocks for encryption which is considered as weak. Per RFC5469 this cipher is deprecated. It has been completely removed in TLS 1.2.

LOW

LOW are low strength encryption cipher suites, using 64 or 56 bit encryption algorithms but excluding export cipher suites. As of OpenSSL 1.0.2g, this is disabled in default builds. Src: OpenSSL

Null

Using Null ciphers mean that no encryption for the data is used at all. They do not offer any privacy or security for the user of a web service. For this reason it is urgently recommended not to use Null ciphers.

RC2

It is advised not to use RC2 for encryption as it has an insufficient key size and is therefore seen as untrustworthy.

RC4

It has been known that RC4 has a weakness in its encryption and should therefore be avoided. On the other hand, there is no secure alternative as many clients still require RC4 support. However, since March 2013, RC4 is demonstrably broken and is classified as insecure in combination with TLS (Transport Layer Security). [1] The attack demonstrates that parts of the plain text can be recovered. For this reason, it is recommended that the support for this cipher should be removed in the near future.

SEED

SEED is an older South Korean cipher. OWASP recommends to not use this (and other older) cipher anymore.

Hash Functions

MD5

The use of the MD5 hash algorithm should be avoided in general as this algorithm is prone for collision attacks. [1]

SHA1

Known for its cryptographic and mathematical weaknesses, the SHA-1 hash algorithm was already replaced by the SHA-2 ciphers family as the recommended standard in 2002. As of begin of 2017, popular browser vendors like Microsoft, Mozilla or Google will stop accepting SHA-1 signed TLS certificates. Instead, the browsers will start displaying a warning sign if any certificate in the trust chain uses the outdated algorithm. Therefore, the upgrade of the web server's and of all intermediate certificates to the SHA-2 family should be considered as soon as possible.

Key Exchange Algorithms

Anonymous Diffie-Hellmann

Anonymous Diffie-Hellman Cipher Suites are used for anonymous Diffie-Hellman communications in which neither party is authenticated. Therefore this mode is vulnerable to Man-in-The-Middle attacks. [1]

 

FAQ

Verifying PDF Integrity

The Cyber Risk Rating Portal issues multiple documents at the end of the rating process for every supplier. The documents are among others the Cyber Risk Rating Certificate which contains the overall rating scores for the supplier along with the WebRisk score and the Cyber Risk Rating Assessment Report that lists the answers of the supplier along with the validation results.

To ensure the integrity of the documents and prevent potential compromises by others during the download process, a signature file for each document is added that contains the signed digest per document. By signing the digest, the document integrity is guaranteed as changing the document's content would consequently create a different digest, failing to match the provided signature. Additionally, the signature cannot be altered given that it was signed using our own secret RSA private key. The algorithms used for the process are SHA256 to create digest of the document and RSA PKCS#1 v1.5 for the signing.

Verifying the integrity on the command line

It is advised to verify the integrity of each document after downloading them as a zipped archive. For each document, the corresponding signature file .sig represents the signed digest in byte form. Furthermore, the public key that was used on our side is required. It can be downloaded here: Cyber Risk Rating Signature Public Key.

The verification can be done using OpenSSL v1.1.1f or above.

$ openssl dgst -sha256 -verify crr-signature-key.pub -signature Cyber-Risk-Rating-Report-Valid.pdf.sha256.sig Cyber-Risk-Rating-Report-Valid.pdf
Verified OK

If the documents are compromised, the verification will fail. In this case, contact `support@nimbusec.com` immediately for further help.

$ openssl dgst -sha256 -verify crr-signature-key.pub -signature Cyber-Risk-Rating-Report-Valid.pdf.sha256.sig Cyber-Risk-Rating-Report-Compromised.pdf
Verification Failure

CyberRisk Rating Signature Public Key

You can download the signature key as file here: Cyber Risk Rating Signature Public Key,

or use the plain text version printed below:

-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwGd+TC2FkOrz/CqU9lUk
xNi8uhQ73D9YVlQ93Jkl4plVRYcquGOK0hLqWSTDkHAfd9fKCqgmJWF1X6eF/fz7
B6a7HeCHAPlut3aclEneJef03JWsLZWoMD724v7vDXHolUcDNHuICWQpWMpZ/xaM
E1FzNlzqSH41tF3YPOaxGiQA39+POxaWItYk7hBKBWhU6F4PBzZfM2gE/3AOqcRi
4DRFYPh3ZwIVTGqDtfiYMWUYLDI5u0KzdFne6qvBHflBwB1Nd9l3ckEFiv91s2Sg
3AaiXEqgSvLIL02tbmVnbfImVXksE9VeNWpr0LKWnTApheX++DQ0itB7zbg9JIfv
rEG9JNuP/dXlFjYRsBlsaz950vulzwwWjeHs6LikqHUz+4xy8+GU6vs0QFbvkHlD
DRcJGeCWsCiijh9dtM+yDcZfr8WjEr9AQfskMSfoWuVqAMBqJ05C51fDnZdbNLGy
0ubtIoI4cSIf7Rrow1iq8l4WsPoIZDRq2S0jJc3gLnAS6erlQoox/9A2ZWeCQPw9
iHixIVpQR/h6TKT6M4VQn+Ilw+Nj5o6yTzYEhq5nY64yH9zn0brhycANLhO/PnA1
rYaCorVRMFbr9UeysulqKBEk4TkEAWdUXdqSzM/Wdm2P0pQM7Y0vhMbqMSeYoGkX
o2lNrkxDioheGnwTsaFejtMCAwEAAQ==
-----END PUBLIC KEY-----

 

FAQ

Compliance Monitoring Issues

General Information

In the world of website compliance, a lot of differnt compliance violotions can occour. Therefore we decided to make a clear separation of those violations and introduced different violation categories:

Each category includes different types of violations that will be described in the corresponding section. The main differences are that regulatory violatens based on GDPR context prescribed by law and business violations based on custom rules that can be individually defined to meet each customers individual requiremnts.

Regulatory Violations

This category includes all detected problems that relates to the acutal GDPR context prescribed by law. The following types can be detected by the Nimbusec compliance monitor in the context of regulatory violations:

Generally, the Nimbusec Complaince Scan simulates a standard website user that visits a website, but does not perform any kind of interaction with it (e.g. allowing cookies, ...). For this vioaltion type, we collect all cookie information that was set from the website (before any kind of user interaction). This results in a clear list of cookies that were initially set/provided by the website. In the default configuration, if our simulated website user gets any kind cookies, a 'Cookie Opt-In' violation will be triggerd and shown in the compliance monitor. With other words, cookies have been set without asking for consent in the cookie banner.

In the Nimbusec Compliance Monitor, this violation type can be seen in the compliance view of an asset:

image-1627892571901.png

By clicking on the "Details" button, all detected cookies can be seen.

image-1627892598969.png

In more detail, the Nimbusec compliance scan saves the following data:

example data:

Name Domain Secure HttpOnly LifeTime SameSite ThirdParty InServerResponse
cookie_name www.example.com false false -1 N/A true false

column description:

Column Description
Name Name of the detected Cookie
Domain Domain name where the described cookie was found
Secure The Secure flag is an option that can be set by the server when sending a new cookie to the user in an HTTP response. The purpose is to prevent cookies from being observed by unauthorized parties due to sending the cookie in clear text.
HttpOnly The HttpOnly flag is an additional security option for cookies. If this flag is set, the browser does not display the cookie through client-side scripts.
LifeTime This parameter shows the validity of a cookie.
SameSite The SameSite attribute shows if this cookie is restricted to a first-party or same-site context.
ThirdParty This attribute shows if this cookie was distributed from the own web ressource or from an external one. (domain name matching)
InServerResponse If the value of this attribute is true, this cookie was directly send from the server. If this value is false, the cookie was created and distributed via a JavaScript context.

The Nimbusec Compliance Scan checks websites for the presence of a standard cookie banner. For this case, we check for a default set of various cookie banner implementations. If a custom cookie banner is used, the scan configuration has to be adjusted to detect non default cookie banners.

Form: HTTP-Transmit

For this case, our scan checks all availabe input forms that handles sensitive data. If the content of the input form will be send unencrypted (via HTTP), the Nimbusec Compliance Scan throws a Form: HTTP-Transmit violation. Unencrypted data transmission may be intercepted and the data could be seen in plain text.

By clicking on the "Details" button in the compliance view, all detected cookies can be seen.

image-1627892770440.png

image-1627893146393.png

Form: Form-Sensitive

As mentioned above, the Nimbusec Complaince Scan checks all availabe input forms that handles sensitive data. If we detect such forms, a Form-Sensitive event will be triggered. This should help the users to identify those forms and may handle them in a different way.

image-1627893184908.png

Form: External-Transmit

This type of violation gets triggerd if form data will be send to an external processor (e.g. to an external company that may performs user analytics tasks)

image-1627893221406.png

Imprint Policy

The presence of an imprint is a mandaroty regulation in GDPR. Our imprint policy checks the presence of an imprint link on the corresponding website. To detect it, we use predefined search patterns and apply them on the websites source code.

By clicking on the "Details" button in the compliance view, all defined polices can be seen.

image-1627893270031.png