During a recent penetration test we stumbled upon a couple of issues which independently might not have warranted any attention, but when combined allowed to compromise other users by injecting arbitrary JavaScript into their browsers. It goes to show that even certain issues which might not always seem particularly interesting (such as self-XSS) can sometimes be exploited in meaningful ways. I’ll keep this mostly theoretical so as not to divulge any information on the actual targeted system.

The first interesting behaviour we noticed during the assessment was related to the authentication mechanism. When logging in with a valid user account, the application would generate a base64-encoded session cookie which always started with the same values but had differing endings. This often happens when the cookie contains some kind of encrypted information related to the account and a timestamp to define how long the cookie is valid. Given the fact that the start of the cookie was always the same, it pointed to the fact that the encryption mode was either ECB or CBC with a static IV.

The web application actually decrypts the content of the cookie to display the username on the main page. The latter was discovered by attempting a CBC byte-flipping attack which allowed us to see certain blocks of scrambled text in the resulting page.

In this particular case, we weren’t able to generate arbitrary accounts to force the creation of arbitrary cookies, but we did notice a particularly strange behaviour in the authentication mechanism which allowed us to generate semi-arbitrary cookies anyways, which would in turn allow us to generate encrypted blocks for values we could use to inject JavaScript into the page.

It turns out that if we could login with an account named test, it was also possible to login with an account named ./toto/titi/../../test. This username was accepted with the same password as the original one. There is most certainly some other vulnerability here (path traversal or XPath injection maybe?), but given the limited time of the assessment, we weren’t able to exploit it in any other way than the one detailed below.

Given the “name traversal” issue, we could essentially generate encrypted cookies with arbitrary blocks. Since some of these blocks are then decrypted and shown in the web page, we were then able to force the generation of blocks which would result in a self-XSS. Obviously when we first noticed that the username was reflected in the page we attempted to inject JavaScript code directly into the username, but this was actually rejected by the application, so the only way of exploiting the issue was through the manipulation of the encrypted cookie, as its decrypted value was not sanitized. Unfortunately, this would only impact ourselves, unless we found a way to set another browser’s cookie to our malicious value.

This is where Burp’s request smuggler plugin came in handy, as while we were busy encrypting cookies, it also revealed that the web application was vulnerable to a request smuggling vulnerability. This type of vulnerability gives an attacker the ability to prepend another user’s HTTP request to the web application. This is where our previous discoveries related to the cookie parsing came in handy, as the request smuggling issue allowed us to specify the URL and headers of a subsequent request from another browser. In essence, this allows us to specify the cookie used by another browser for one request (although it could be repeated multiple times).

So, by exploiting this issue, we can send our malicious cookie to another user’s browser and therefore have our decrypted malicious javaScript code executed in his browser. That particular page would be rendered with our own cookie and privileges, but any further request would keep the browser’s original cookie and privileges (as long as we don’t perform another smuggling attack…). This would therefore allow our script to interact with the affected domain in any way the legitimate user could. Our Self-XSS was therefore transformed into a stored-XSS! A very restrictive CSP could have made our life harder, but in this case there was none.

I hope this quick post can give you other ideas to exploit weird and seemingly unrelated issues such as these in your own assessments!

Last year, Orange Tsai did some awesome research and discovered several vulnerabilities in SSL VPN providers which can allow an attacker to break into a network through the very device which is supposed to protect it. The vulnerable constructors were:

• Palo Alto
• Fortinet
• Pulse Secure

I’ll admit I’ve always found it particularly ironic to discover vulnerabilities in security-related devices and we’ve had a surprising amount of success at discovering these at SCRT throughout the years.

While reading through Orange’s blog posts, I noticed one comment asking whether any other vendors were affected. Although I can’t find the comment any more (it was several months ago), at the time I figured I might as well have a go at finding vulnerabilities in one of the other VPN vendors. I pretty randomly chose to start looking at SonicWall who recently wrote a post indicating that their products were not vulnerable to the Palo Alto vulnerability. ¯\_(ツ)_/¯

Not knowing much about SonicWall’s products, I searched for what could be an SSL-VPN device and ended up finding the Secure Remote Access (SRA). Thankfully, it is possible to download a trial virtual machine of the device which I recovered and started to analyse. All analysis was done on version 8.1.0.7-22sv of the device, which seemed rather dated, but I couldn’t find a newer version anywhere. I think this particular device has actually been replaced or is in the process of being replaced by the SMA devices which are at least also partially vulnerable to the issues reported below.

I started off by looking at the web interface exposed for the SSL-VPN. This interface contains a number of CGI files in the cgi-bin folder. These can be called remotely and are just 32-bit ELF binaries that are run on Linux. I went through them to understand how authentication was handled to either find a vulnerability in the authentication system itself, but also just to figure out which files can be called without being authenticated.

One of these CGI files is supportLogin which is used to handle certain types of authentication. I discovered a couple of vulnerabilities in here which can be exploited without requiring an account though they need the “Virtual Assist” module to be enabled on the device. To be honest, I do not know whether this is a commonly used module or not.

The first issue I discovered is a SQL injection in a parameter called customerTID. The web application uses a SQLite database and constructs several queries with user-supplied input through the sqlite3 printf functions. In most cases, it uses the %q formatter to appropriately escape quotes. However, as can be seen below, in some instances, a %s is used instead. As this doesn’t perform any escaping, a trivial SQL injection is present.

This leads to a blind SQL injection vulnerability which can be exploited remotely. The most interesting data that is stored in this particular SQLite database seems to be session identifiers for authenticated users in a table named Sessions. If exploited at the right time, this would grant access to the SSL-VPN with various levels of privileges.

This first vulnerability was attributed the following CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7481

In the same CGI file, a second vulnerability which leads to arbitrary code execution was also discovered. This one is a buffer overflow present in the parsing of the browser’s user-agent. The overflow can occur if the user-agent pretends to be Safari, as this results in calling the getSafariVersion function in the libSys.so library.

The getSafariVersion function looks something like what is below.

The memcpy function can be used here to overflow the local buffer. In the SRA, there is no stack canary, so overwriting EIP and using a rop chain to execute commands is simple. In the SMA, there are exploit mitigations in place and exploiting the issue would probably require a leak somewhere else or deeper investigations.

Nevertheless, crashing the CGI can be done with the following request:

GET /cgi-bin/supportLogin HTTP/1.1 
Host: 10.1.0.100 
User-Agent: plop Mac OS X Safari Version/12345678901234567890123456789012345678901234AAAABBBBCCCC lol Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 
Accept-Encoding: gzip, deflate 

The handler will restart automatically so it is possible to re-exploit the issue multiple times for example to brute-force libc’s base address. In practice after less than a 100 attempts, it is usually possible to get arbitrary commands to be run with nobody privileges on the device.

This vulnerability was given the following CVE : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7482

A third pre-authentication vulnerability is a pretty useless directory traversal, as it only allows to test for the existence of a file. In theory, if the file matches a certain structure, it would be possible to read parts of it. It was attributed the following CVE : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7483

In practice, I think this last issue can easily be used to figure out if a device is vulnerable to the two other vulnerabilities as they will likely all be patched together. Essentially, a device is vulnerable if the following requests takes a bit of time to complete:

/cgi-bin/handleWAFRedirect?repeated=1&hdl=../etc/doesntexist

It should take more time to complete than requesting an actual file such as:

 /cgi-bin/handleWAFRedirect?repeated=1&hdl=../etc/passwd

Three other vulnerabilities were discovered during the analysis, but they all require an account to be exploited:

• CVE-2019-7484 – Authenticated SQL injection
• CVE-2019-7485 – Authenticated Buffer Overflow
• CVE-2019-7486 – Authenticated Code injection

The two first ones are very similar to what was described above, while the last is a straightforward command injection, but I believe it requires an admin account, so you can be the judge of the criticity. It can be exploited like this:

POST /cgi-bin/viewcacert HTTP/1.1
Host: 192.168.200.1
[...]
Content-Length: 67

buttontype=delete&CERT=newcert-3'--'
ping -c 4 192.168.200.123
ls

Regarding the timeline, I reported these issues on the 5th of June 2019 to Sonicwall’s team and the advisories were then published on the 17th of December 2019.

I had a quick look recently (so 2 months after the critical update was released) to see whether there are still unpatched devices out there. I only tested the directory traversal issue and obviously there are still numerous vulnerable devices exploitable from the Internet. This is why I didn’t go ahead and post the exploit code itself in here.