Wow, so it’s been two years or so since I found these two vulnerabilities in an Industrial Control System (ICS) while doing an external penetration test. Before we continue, if you’re unsure what an ICS is, here is a link with a definition.
With that out of the way, here we go!
I fixed up the python script I wrote to test for this vulnerability and decided to make another post about on here. Link to the script is at the bottom of this post or you can visit my github here
Let me go over some important information though:
- Vendor Homepage: https://www.tridium.com/
- Version: Affects Tridium Niagara AX Versions: 3.8 and prior as well as Niagara 4 Versions: 4.4 and prior
So let’s get into it!
So there was a few ways you can authenticate to the web application however the one that had the vulnerability (as far as I know) was authenticating to a local machine rather than to a Forest. This local box happened to be running Windows 7. This means that their is a by default disabled Administrator account on the box with a username of “Administrator” and a blank password. I found that even when this account is disabled on the box you can still use it to authenticate to the web application. This is the first vulnerability.
Here is the response you can see if the application accepts Administrator with no password:
In the python script notice the Authorization Basic Header which you can change the value of if the credentials are different. All you have to do is put the username:password in that format and base64 encode it. For example if the credentials are admin:admin then the value of the Authorization Basic Header should be YWRtaW46YWRtaW4K
The other vulnerability that I found is if you add URL encoded character \ to the /niagara/ URI, then the server would respond some XML error that contained a directory listing of \ . Using this, I could traverse directories, there was just one problem…
It cut off some of the output
Here is an example of that:
Lets look in the source code of this page for the actual directory listing
You can see though the complete directory listing is cut off by a 500 error. But fear not there is a way around this!
By adding a URL encoded space to the end of the URL in the request, the output was not cut off however all of the files information, like size, creation date, etc. were invalid
Here’s an Example of that:
Here’s an example of a traversal: http://target.com/niagara/%5C..%5C..%5C..%5C..%5CUsers%5CAdministrator%5CAppData%5CLocal%5C%20
Would respond with a XML error page that has the directory listing of ‘C:\Users\Administrator\AppData\Local\’
Here is a link to my github with the script you can use to test to see if it’s vulnerable.
If it’s vulnerable this is what it will look like:
(Make sure you add %5C%20) to the URL!
Until Next Time!
One thought on “PoC for CVE-2017-16744 and CVE-2017-16748”
Wow~ That’s really amazing.