How do I bypass Cyberoam authentication

We are committed to working with a large number of security researchers to uncover serious vulnerabilities in key SSL VPNs and firewalls. Cyberoam, Fortigate, and Cisco VPN are all our research subjects. This article describes some basic instructions for remote command execution vulnerabilities affecting Cyberoam SSL VPN (also known as CyberoamOS).

This Cyberoam vulnerability is marked as It is a high risk vulnerability. Attackers can use it to control Cyberoam devices directly without authorization. The most important thing is the attacker's access rights, which means that the attacker can fully control the Cyberoam device.

Since Cyberoam devices are used as firewalls or SSL VPNs in most network environments, once the attacker has complete control of the device, they can launch large-scale attacks on the target intranet. Under normal circumstances, Cyberoam devices are usually on the security whitelist, which allows attackers to bypass other security measures better.

According to Shodan's data, there are more than 96,000 Cyberoam devices on the Internet worldwide. Most of these devices are on corporate, university, and some world-famous banks' networks. Once they fall, they can cause many economic losses.

Working with the Sophos security team is a very pleasant thing because after receiving the report, they quickly realized the seriousness and immediately released the patch.

Cyber ​​?? oamOS remote command execution

CyberoamOS is an improved version of the Linux based operating system that is mainly used in Cyberoam devices. The operating system has a web-based configuration interface and an SSL VPN entry.

The web interface mainly consists of two parts:

  • Frontend written in Java

  • Backend written in C and Perl

We will not go into the internal mechanism of the front-end or back-end code here, but rather briefly explain how this vulnerability can be triggered.

Both the configuration interface and the SSL VPN entry have a servlet that handles the main operations. These operations are carried out via ParameterDefined.

Most of these operations require authentication, but some operations can be performed without authentication (for example, logon operations).

The vulnerability we found is in the module. The request code for this module is 458.

It should be noted that the opcode corresponds to the data in the Cyberoam device database (with reference to the internal database Postgres). So if we search for 458 we can find the name of the corresponding opcode.

The following is a line in the database initialization SQL script that shows the operation name for 458:

And the function that performs the operation is stored in the directory. We're not going to disclose all of the code of the malfunctioning function, but we're going to provide some snippets of code to show where the vulnerability lies and how it is triggered.

Java front end code for opcode 458:

As the code above shows, it checks the validity of several parameters. If the confirmation is valid, the following happens:

At this point we have a new event code (363) that is sent to the backend. The vulnerability exists in the back-end code that handled this event.

The appropriate name of the opcode is In order to avoid direct exposure of the vulnerability, only part of the code is displayed.

Processing method.

As can be seen from the code above, the pseudo-Perl code shows us how the backend receives input ($ requestData) and how it tries to check some of the parameters it accepts.

If our parameters are valid after verification, then run the following code:

The above code sets the variable to Set the Accepted Value and Call Function. We will see what operations are involved and where RCE is triggered:

The code above performs an operation that all codes do when they are executed and initialize the variables (if some variables are not specified, they will be taken directly from the device).

After assigning the variables, the following code runs.

Yes, this is the command execution. The usage here is It will call. By controlling the "variables" that need to be executed, we can easily implement the execution of remote commands without authentication.

We will publish a full report and PoC within a few months and give a more detailed explanation.