Tempestโ€™s consulting team has found a vulnerability in the SecurMail module of the SecurEnvoy product. SecurMail promises to securely send and receive e-mails (including attachments) using SSL authentication, as well as encryption and multifactor authentication. However, the vulnerability was found in the functionality responsible for attaching files and makes it possible to send and execute a malicious file.

The following is a brief explanation of the vulnerability type. In addition, it certainly presents the methods adopted to detect and exploit the vulnerability; this has even enabled remote execution of commands.

The vulnerability to be addressed here is the directory traversal type. Attacks of this type consist of the possibility of traversing directories outside and/or inside the root of the application, thus allowing access to other files or folders in an arbitrary manner. For more in-depth study of the topic click here

This vulnerability is caused by an application failure that had not sanitized the malicious entries of a user, whose purpose is the manipulation of application files. What led to the investigation of this vulnerability was the observation that a user could manipulate fields where directories are loaded.

Thus, the desired file path gave space to change the user input; so that, through the use of traversal directory techniques, it was possible to recover files from the application and the server.

SecurMail installs a web application, using the Common Gateway Interface (CGI) of the IIS server. Thus, when accessing the IIS manager, it was possible to identify all existing directories. Among the directories listed, the SECUPLOAD folder stood out:

Figure 1. IIS Manager with application directories

When accessing the SECUPLOAD folder, an accessible upload form, not protected by authentication, was found. The vulnerabilities found in the upload form were possible only after decompiling the application binaries. Therefore, it was possible to identify the first fault: there was no authentication and session check during the upload process.

As the code obtained in the decompiler was checked, another traversal directory vulnerability was detected, which made it possible to send any file in an arbitrary directory.

This vulnerability can only be exploited due to the absence of a session cookie check. In addition, the value of the SecurEnvoyReply cookie was transformed into a string and concatenated to the directory where the sent file would be stored. The following images illustrate the pieces of vulnerable code:

Figure 2. Recovering the value of the cookie and converting it to string

In the previous image, you can see that the value of the SecurEnvoyReply cookie was stored in the str variable. You can also see this variable being manipulated through the text6 variable, which has as its final value a directory path.

In addition, the variable text6 was used as a parameter of the CreateDirectory() function; which, according to Microsoft documentation, can be used to create new directories. As an aggravating factor, it was also possible to observe that there was no user input check during all this operation.

Figure 3. Using CreateDirectory() with the value of the text6 variable.

Therefore, using this vulnerability, the proof of concept of sending a file was performed, inserting a payload in the cited cookie so that the file would be stored on the root unit C:\. The following request illustrates the sending of a file, together with the payload as the value of the cookie:

Figure 4. Sending the file with the payload in the cookie

However, it was possible to verify that the sent files are encrypted by the application:

Figure 5. Sent file

The original file was saved on the server, and only after being saved to disk, would it go through the encryption process. The next image illustrates this fact:

Figure 6. Code snippet of the file save

According to what was stated in the previous paragraph and illustrated in Figure 6, it is possible to verify that the variable text9 was created by concatenating the variable text6, of the string โ€˜\โ€™ and the variable fileName (which stores the name of the sent file). Right after the creation of the text9 variable, it was used as a parameter in the PostedFile.SaveAs() method, a function which is capable of saving the contents of a file in a specified directory.

After all these findings, a new proof of concept was performed which generated a race condition through multiple request submissions containing the file. In addition, the payload was also sent to arrange the file on an externally accessible path.

Through the race condition, it was possible to prevent the use of encryption. Figure 7 illustrates the successful opening of the file:

Figure 7. Sending the file successfully

Using the vulnerabilities already applied, it was possible to send a malicious file that could send and receive commands on the infected machine. The next image illustrates this:

Figure 8. Execution of commands successfully performed

RESPONSIBLE DISCLOSURE

Responsible disclosure with SecurEnvoy was performed, so that the necessary assistance was also given during testing to correct this vulnerability. Thus, during the sending procedure, checks were performed on the session cookie, as well as the comparison of the canonical path of the sent file. So that it is only released after this check.

Finally, a CVE was reserved.

TIMELINE

May 17 โ€” An e-mail was sent reporting the vulnerability;

May 18 โ€” SecurEnvoy responded to the email saying they were arranging for the correction;

May 19 โ€” SecurEnvoy sent a patch to re-test the vulnerability;

May 20 โ€” It was not possible to reproduce the vulnerability after the fixes;

May 27 โ€” SecurEnvoy announced that it had published the patch for its clients.