Serious Vulnerabilities in Dualog Connection Suite

TL;DR

The flaws found in this maritime comms and connection suite were many, and not insignificant:

• Directory traversal
• 2FA challenge/response is performed in a client-side application
• Default install password
• SQL injection
• User data leakage
• Easily brute forcible password hashes

Introduction

During the test of a ship, we came across an installation of some software called Dualog Connection Suite. It offered a web service on port 3000, and immediately prompted you to use a Flash app. The use of Flash in 2020 is an immediate red-flag to a pen tester.

The software provides maritime email, security scanning and endpoint protection, file transfer, and allows crew to access the Internet. It was also running on a high-value host on the ship.

Within a few seconds we’d already noticed our first vulnerability, simply by watching the network traffic in the browser developer tools. There were enough signs to warrant deeper investigation.

With all application testing, we much prefer having access to the binaries, code and configuration that are on the server. Luckily, Dualog Connection Suite could be downloaded and inspected on our own machines, changing a black-box test to grey-box.

Over the course of the next 90 minutes, the following issues were found.

Since testing we have submitted six issues for CVEs.

Default Password on Undocumented Admin Account (aka “backdoor”)

The application uses an Oracle database, which is created and updated using scripts. In the file “CreateDatabase.sql”, an insert statement creates an account with the name “[email protected]”, and an associated 16 byte password hash.

Reverse engineering of the application showed this to be a plain MD5 hash. This was fed into our password cracking rig, and yielded the password in under 10 minutes. It is of poor quality.

No signs of this account could be found in documentation. No advice was given to change the password. The password has worked on both the implementations we have seen, giving superuser access to the system.

This should be considered a backdoor account that allows the application to be completely compromised.

SQL Injection

Multiple queries made to the backend clearly contained SQL in the form of “where” and “join” URL parameters. It became apparent that this allowed SQL injection.

It was trivial to alter the query to return all the details about all of the users, including the MD5 password hashes. This was for all users across all ships operated by the company, not just the ship we were on.

Cursory examination of the code driving the application indicated that this was a systemtic issue, with no sanitisation of URL parameters being performed before being inserted into SQL statements.

Directory Traversal

The system handles file transfer. One endpoint allowed the download of files, using a filename URL parameter. Examination of the code indicated this would be vulnerable to directory traversal, as the parameter was not sanitised in any way. Burp Suite picked this up via the automated scan.

This allowed access to configuration files across the system.

Plain MD5 Unsalted Password hashes

The passwords found stored in the database (and exposed by SQL injection) were plain MD5 without a salt. This makes them extremely fast to brute force, and allows the use of a look-up table.

Client-side 2FA

The web application made use of Adobe Flash. When logging into the application, the user was presented with a 2FA challenge (“Security code nr:”) and had to respond with a 6 digit number.

The numbers required for a response were stored in the Flash application itself, and could be easily extracted. A challenge of 23 meant the 23rd element of the array.

This made it trivial to work out the code and enter it.

Note that it was entirely possible to skip this aspect and just make direct API calls, but it was convenient to use the Flash application to understand how it worked.

2FA Bypass

2FA was only in place for administrator accounts. The Flash application decided to present the 2FA challenge only when the field usr_adminuser was set to 1. By forcing this value to 0, the 2FA check was bypassed entirely.

Again, as the 2FA was client side, this was not a requirement to work with the API.

Username Enumeration

When starting the Flash application, a full list of the users is downloaded, unauthenticated, from the server. These are in the form of email addresses. Here’s a small sample of what was available:

This is a significant leakage of information that would be useful for spammers and for phishing attacks.

The 6 CVEs in detail

Affected Product Code Base: Dualog Connection Suite – Impacted 2.39.

Attack Types: All remote

CVE-2020-26576
When downloading files using the web interface, the name of the file is provided. This is vulnerable to directory traversal using ../, allowing files to be downloaded from the system.

Directory Traversal is possible from the web interface allowing Escalation of Privileges, by providing ../ in the file download parameter.

CVE-2020-26577
It implements 2FA by using a numeric challenge/response. The challenge/response pairs are stored in the Flash application itself, making it easy for an attacker to look up the response. Also, the 2FA requirement can be completely skipped by altering a response from the server.

Incorrect Access Control in the Adobe Flash client allows Escalation of Privileges. The attacker must try to login with the Adobe Flash interface available on the network.

CVE-2020-26578
It contains an account, [email protected], with a default password that is created at install. The account is not documented or displayed, and hence, the password is not changed. The account allows complete control within the normal scope of operation. This can be exploited across the network.

By having Default User/Password at install the web interface allows Escalation of Privileges. An attacker can use default admin login to login to platform.

CVE-2020-26579
Multiple requests made to the web interface are vulnerable to SQL injection. This includes the user query, which allows the entire user table to be extracted from the system. This does require authentication, but a default password on an undocumented admin account
permits this.

SQL Injection can be used against the web interface for the Escalation of Privileges by an Authenticated attacker using the web interface.

CVE-2020-26580
When visiting the login page, it provides autocomplete of username. The entire list of users is downloaded using an API call in the background, leaking all the valid users.Information Leakage in the web interface allows Information Disclosure when the attacker visits the login page of the web interface.

CVE-2020-26581
Password hashes for users are stored as plain unsalted MD5. This makes them extremely fast to brute force, and allows the use of lookup tables.

Cryptographic weakness in the Connection Suite allows Escalation of Privileges. Attack
requires access to password hashes for users (which can be achieved using SQL injection).

Disclosure Timeline

22^nd January 2020 – contact Dualog support

27^th January 2020 – chase Dualog support

30^th January 2020 – chase Dualog support and get a response and email address to communicate with

3^rd February 2020 – send issues via email and request Dualog issue CVEs

4^th February 2020 – receive thanks and response indicating CVEs will be issued

5^th February 2020 – Dualog ask for more detail

10^th February 2020 – respond to previous request

30^th June 2020 – chase Dualog to see if issues have been fixed. No response.

21^st September 2020 – chase Dualog to see if issues have been fixed. No response.

4^th October 2020 – We escalate to CEO via LinkedIn. Dualog then reply to say they are releasing Connection Suite v3.0 in November which will fix everything except Passwords hashed with MD5. They also say that certain characteristics of the industry make updates problematic.

7^th October 2020 – Reply to Dualog to say that there are preventative measures that they should have advised their customers about, but they didn’t, and advising Dualog that we will disclose.

8^th October 2020 – Dualog email to ask for a delay until the 16^th due to local holidays, then silence again.

14^th October 2020 – we have a conference call with Dualog which was constructive. We advised them to seek a penetration test from a Norwegian supplier.

24^th November 2020 – Emailed Dualog to ask the November about the beta release, and the full release in December. Again silence.

8^th December 2020 – confirmed that new version was available. The release notes are incorrectly dated as 1^st December 2020.

Conclusion

We hoped that the severity of the reported issues would have spurred Dualog to more immediate action, we were wrong.

To quote a colleague:

Maritime security be like: We put VSAT on our ships to keep the crew happy and make ship-shore operations more efficient. Now we’re staring down the barrel of 10+ years of technical debt on board and IMO MSC.428 is going to fix that by Jan 1st 2021.