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):
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):
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):
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):
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):
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):
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
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.