We work hard on the safety of our products. Of course, this also includes commissioning external specialists on our own behalf to independently and critically assess our products and review our safety measures.

Recently we contacted the Electronic Warfare Institute in Canada (EWI) and asked them to perform a complete security audit based on the firmware 2.12 according to UL 2900 Standard (US Cybersecurity Standard). In addition to the UL 2900-1 standard, the Electronic Warfare Institute also focuses on the potential or ability of malware to be be infiltrated into the CS141/BACS. More than 1 million attempts were made within 8 hours with various attack tools with the aim of crashing the web server of the CS141/BACS, or to make the system perform other functions than desired.

They did not succeed! And thus we are one of the few systems that EWI has tested wherein they were unable to find any security vulnerability which can be classified as "High". This goes for all interfaces; especially the operational stability of all hardware interfaces (RS232, RS485) were certified as robust, representing zero points of attack. The final report was surprisingly positive for such penetration tests, but we nonetheless intend to improve.

The bottom line:

If you activate a minimum level of security measures when setting up the CS141/BACS, the device can be considered safe based on the current state of technology!

The EMI report in detail describes some weaknesses classified as "Medium" and as "Minor" - we will evaluate these in the following analysis.

The category "Medium" describes vulnerabilities that can be exploited under certain conditions by untrusted persons if the necessary access authorizations are available.

First of all: in order to get such an access authorization to the CS141/BACS, the administrator password must be known. It should therefore be one of the minimum measures to assign a password to a new network device that is not broadly known to everyone.

It is exactly this prompt for a default password change that our firmware 2.12 prompts the user to do. If this is ignored, then this cannot be seen as a security vulnerability of the CS141/BACS, but falls into the category of "gross user error". Arbitrarily activating network services without using or monitoring them is also one of the grossly negligent errors of a user, and is certainly not the fault of the CS141/BACS.

With a minimum of common sense, every CS141/BACS is a secure device from initial installation - of course, we could set the hurdles even higher, but this would conflict with the fact that while we as GENEREX are the manufacturer, our customers are not the end users themselves, but a B2B - service provider who often sets up the device on behalf of the end user. Therefore, not all access restrictions can be activated in the delivery state - otherwise you could not install the CS141/BACS as a service provider at all.

Clearly visible: The CS141 warns its users about the serious security vulnerability "Default Password in Use".

The warning clearly indicates that a default password is currently being used and should be changed.

1. Vulnerability classified as "Medium":
The CS141/BACS uses a default password for the first user and there is no requirement to change this immediately on first login.

We asked ourselves this question much earlier, but finally decided that we only want to introduce this requirement to change the password at the first startup at the explicit request of our OEM customers. There are some OEM customers where we require this password change at the first login, but then it must be ensured that this password is not lost. Even we as a manufacturer cannot help to restore the access without losing all user-configured settings in doing so. Our products are sold exclusively through B2B partners, and they offer GENEREX products as part of other services, which often includes basic configuration. If now an elaborate configuration is "lost" because the customer forgot the password, then this is a problem for our partner - he cannot help and the end customer could ask for the setup work again - although he himself is responsible for the damage.

We think that in this phase of initial installation and handover to the end customer the loss of a password could be critical, much more critical and probable than a possible hacker attack at this point. For this reason, we "allow" ourselves this nuisance and continue to ship most devices with a default password, but prompt the user with a penetrating warning to change it.

We therefore do not allow this vulnerability, which is classified as "medium", and refer to our documentation including the Hardware Hardening Guide which makes every CS141/BACS the most secure device on the market.

2. Vulnerability classified as "Medium":
Using an older OpenSSH library  

This is not a security vulnerability in the sense that this access is not available to the user. The use of this Library is exclusivly reserved for the BACS VIEWER.

Why don't we just disable SSH if this is criticized as a security vulnerability?

The reason is that SSH is an integral part of the SFTP functionality of the BACS VIEWER that many users want to use to fetch data from the CS141/BACS. Without SSH unfortunately also no SFTP works - therefore SSH must be present - even if there is no access for it.

To prevent an attack, we use a specially adapted and hardened version of OpenSSH, so the known vulnerabilities of OpenSSH are not applicable to the CS141/BACS, at all.

Many penetration software vendors already consider older version numbers as a clear indication of potential security risks, even if, as in our case, it is not at all founded. In this case, too, we consider the classification as a "medium" security risk to be unfounded because it is based solely on the detection of the version number of the OpenSSH library.

In order not to offer a gap to the penetration software anymore, we have set the switch "BACS VIEWER" to OFF in the standard delivery with FW 2.12. This means that no BACS VIEWER can be used. So no BACS VIEWER data can be fetched anymore (unless the user switches the option back ON) - but the penetration software is "calmed down" now.

BACS VIEWER users should set the switch to ON if they want to fetch data, and after that the port can of course be closed again.

3. Vulnerability classified as Medium:
SNMP Service V2 with Default Community Strings is used

By default SNMP is disabled, so it does not pose a security risk. Should the user turn on SNMP and decide to use SNMP V2, but not use a different "password" than our default, then this is a conscious decision by the user and should also not be classified as a security vulnerability. Of course using SNMP V3 would be the safer way, but some customers want to use V2 and are aware of the risk and also our documentation points out this risk. Also, with SNMP V2 you can configure higher security and you don't have to switch to SNMP V3 right away; for some users this is enough.

Therefore, we do not accept this security gap, which is classified as "medium", and refer to the possibility of using SNMP V3.

The Security Audit of the Electronic Warfare Institute confirms:

Not only in terms of reliability, but also in the area of operational and cyber security, it’s clear: The CS141 / BACS one of the most secure devices currently available on the market!

All security gaps classified as "medium" in the report are almost completely debunkable through proper configuration. If security gaps occur in a network, they are due to the circumstance of the initial setup by service providers or they are unavoidable due to the existing network design.

Customers all over the world trust GENEREX products, and with this security audit we can once again prove that this trust is justified!