Spectant Security analyzed the application during
installation as well as during its normal functioning window. The following
section details the activities and actions performed during the research.
During standard User Interface (UI) research the NASA's Eyes web site (eyes.nasa.gov) was
discovered and viewed. It was noted that a custom application was used along
with a custom "eyes://" URI linked off the various pages of the web site. The
eyes:// URI along with the underlying launcher and viewer application were
analyzed for potential weaknesses in their security.
Once installed, the NASA's Eyes application appears to be a QT GUI wrapper around
the unity player. The URI's to launch the application are structured like
(Textbox 1):
eyes:///?scene=$SERVERURL/content/scenes/default.xml&interface=$SERVERURL/content/interface/default/default.xml&document=$SERVERURL/content/documents/cassini/cassini.xml
Textbox 1: Raw URI string to launch the NASA's
Eyes Application from a web site
$SERVERURL
isn't set anywhere on the site and is pre-configured within the viewer. You
can see this from within the extremely verbose output_log.txt file in the
AppData path of the viewer (Textbox 2):
Replacements
$SERVERURL -> http://eyes.nasa.gov/server
$PROTOCOL -> eyesReplacements
Textbox 2: Raw output_log.txt output showing the
$SERVERURL parameter
Also in the output_log.txt file is a list of retrieved
files that the viewer uses for building the various models and animations for
the application (Textbox 3):
Successfully downloaded and parsed 'http://eyes.nasa.gov/server/content/interface/default/default.xml'
Successfully downloaded and parsed 'http://eyes.nasa.gov/server/content/documents/cassini/basic_camerawork.xml'
Successfully downloaded and parsed 'http://eyes.nasa.gov/server/content/documents/cassini/advanced_camerawork.xml'
Successfully downloaded and parsed 'http://eyes.nasa.gov/server/content/documents/cassini/control_scripts.xml'
Successfully downloaded and parsed 'http://eyes.nasa.gov/server/content/documents/cassini/timeline_hds_2.xml'
Successfully downloaded and parsed 'http://eyes.nasa.gov/server/content/documents/cassini/calendar_hds.xml'
Successfully downloaded and parsed 'http://eyes.nasa.gov/server/content/documents/cassini/gallery_hds_2.xml'
Successfully downloaded and parsed 'http://eyes.nasa.gov/server/content/documents/cassini/styles.xml'
Textbox 3: Raw output_log.txt output showing
resources downloaded over HTTP
One interesting thing to note is that during testing all
the resource files used within the application were accessed and downloaded
over HTTP instead of HTTPS.
The downloaded resource files were analyzed to determine
if there was anything that could be modified to gain access to the underlying
system running the browser/NASA's Eyes application.
During this analysis, it was discovered that the
application doesn't store the files in their default format. Instead, it
creates another directory in a different AppData path and stores them with
unpredictable names in a cache folder along with an index.csv to manage the
naming translations. Wireshark was used to verify that the downloaded files
were still being served via HTTP (Image 1):
Image 1: Wireshark Screenshot showing resources being downloaded over HTTP
This confirmed the use of unity player as well as files
being downloaded over HTTP. It also confirmed the use of QT GUI using the
QTWebKit.
The next step was to attempt to serve a custom XML
document within the eyes:// URI string to see if the player would perform any
validation on it and/or attempt to render it. The following code is a simple
HTML which attempts to cause the NASA's Eyes application to launch and render a
custom XML resource (Textbox 4):
<head>
</head>
<body>
<iframe style="width:0px; height:0px;" src="eyes:///?scene=$SERVERURL/content/scenes/default.xml&interface=$SERVERURL/content/interface/default/default.xml&document=http://127.0.0.1/eye_test.xml">
</body>
</html>
Textbox 4: Example HTML file that will launch
the NASA's Eyes application with 3rd party resource
By accessing this page in a browser, the launcher
automatically starts and all the xml files are rendered correctly including the
one served from the local host as evident by the output_log.txt file (Textbox
5):
Successfully downloaded and parsed 'http://127.0.0.1/eye_test.xml'
Textbox 5: Raw output_log.txt output showing the
download and render of 3rd party resource
The eye_test.xml file was modified to attempt to execute the Windows
CALC.EXE application (Image 2):
Image 2: Resource modification to execute CALC.EXE on target machine
When the viewer loaded, CALC.EXE was executed once the scene had been rendered (Image 3):
Image 3: Screenshot of CALC.EXE being executed on target machine
Using process monitor it was discovered that the OpenURL
call eventually landed on a rundll32.exe call which loaded url.dll with the
FileProtocolHandler function (Textbox 6):
PID: 756, Command line: "C:\Windows\System32\rundll32.exe" url.dll,FileProtocolHandler file:///C:/WINDOWS/System32/calc.exe
Parent PID: 9188, Command line: "C:\Windows\System32\rundll32.exe" url.dll,FileProtocolHandler file:///C:/WINDOWS/System32/calc.exe
Textbox 6: Process Monitor output showing the
rundll32 call from the NASA's Eyes application
Now that we know we can control the URI handler and full
path that gets passed to url.dll using rundll32.exe, we can execute code on the
machine running the launcher by using an executable on a remote windows/smb share
by modifying the custom resource to point to the remote windows/smb share
(Image 4):
Image 4: Resource modification to execute a remote TEST.EXE on target machine
Once that XML file is rendered, the launcher will
download and execute the test.exe application on the target machine (Image 5):
Image 5: Screenshot of TEST.EXE being execute on the target machine
Recommendations
It is recommended that all external resources be loaded over SSL with certificate validation from within the client application. It is also recommended to add a configuration file with approved external resource locations.
Disclosure Timeline
4/27/2017 - Contacted NASA Eye's Site Administrator - No Response
4/28/2017 - Called NASA SOC for Identified Security Issues - Was told to submit report to SOC
4/28/2017 - Sent Vulnerability Report to NASA SOC - No Response
5/02/2017 - Follow Up Requesting Response - No Response
7/27/2017 - Publish Findings
