Login  
Search All Forums
Dart Home | PowerTCP WebServer for ActiveX | Custom Development Reply | PowerTCP WebServer for ActiveX Topics | Forums   
AuthorForum: PowerTCP WebServer for ActiveX
Topic: Client is able to access windows files using ../../../../../windows/
lyve2ryde

From: USA
Posts: 25
Member Since: 02/25/15
posted November 12, 2020 3:18 PM

Can you please advise on this matter.
I believe they are using the latest WebServer control v1.9.5.0, but I'm still trying to confirm that.
Thanks,
Tim Snelling

The below info is copied from an email to us, from one of our customers.

Our system administrator performed a nessus scan on our network and found the following issue with the Managed Air Web server. Please review the issue below and let me know if you have a remedy.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Description
It appears possible to read arbitrary files on the remote host outside the web server's document directory using a specially crafted URL. An unauthenticated attacker may be able to exploit this issue to access sensitive information to aide in subsequent attacks.

Note that this plugin is not limited to testing for known vulnerabilities in a specific set of web servers. Instead, it attempts a variety of generic directory traversal attacks and considers a product to be vulnerable simply if it finds evidence of the contents of '/etc/passwd' or a Windows 'win.ini' file in the response. It may, in fact, uncover 'new' issues, that have yet to be reported to the product's vendor.

Solution
Contact the vendor for an update, use a different product, or disable the service altogether.

Output
Nessus was able to retrieve the remote host's 'win.ini' file using the
following URL :

 - http://dsho012867.acument.com:90/../../../../../../../../../../../../windows/win.ini

Here are the contents :

------------------------------ snip ------------------------------
; for 16-bit app support
[fonts]
[extensions]
[mci extensions]
[files]
------------------------------ snip ------------------------------

Note that Nessus stopped searching after one exploit was found. To
report all known exploits, enable the 'Perform thorough tests'
setting and re-scan.

Nick B (Admin)

From: Utica, NY USA
Posts: 614
Member Since: 05/25/10

Extra Support Options
Custom Application Development

posted November 13, 2020 1:01 PM

Hello,

Thank you for your report, this is entered as TTWeb5758 for review. To remove this vulnerability within your code, in the Get/etc event(s):

  If (InStr(Request.Filename, "/../") > 0) Then
    Response.Body.Write "your error message here."
    Response.Status = httpBadRequest
    Response.StatusText = "your status text here."
  End If

Or as desired for your requirements.
lyve2ryde

From: USA
Posts: 25
Member Since: 02/25/15
posted November 13, 2020 3:37 PM

Thank You.
I have added the InStr check for the "../" string.

however when I use a web browser and pass a URL like "127.0.0.1/../../../../../../../windows/win.ini"
The Request.FileName = /windows/win.ini"
and the RootDirectory also does not have any "../" in its pathname.
So I'm not sure the proposed InStr check will work. As it is not showing up in either string.

I have also added an InStr check for ".ini" and for ".dll", and when I pass the URL above, the logic does catch it, and returns an error page.

Please let me know your thoughts on the "../" check, and why I can't duplicate it.

Thanks,
Tim Snelling
lyve2ryde

From: USA
Posts: 25
Member Since: 02/25/15
posted November 13, 2020 3:49 PM

I should mention that the web browser changes as soon as I hit Go.
from; "127.0.0.1/../../../../../../../../../../../../../windows/win.ini"

to; "127.0.0.1/windows/win.ini"
Nick B (Admin)

From: Utica, NY USA
Posts: 614
Member Since: 05/25/10

Extra Support Options
Custom Application Development

posted November 13, 2020 4:45 PM

Hello,

In my testing, modern web browsers sanitize the URL, so any "/../" will be removed from the URL when attempted, while "/.../" won't be. Because of this, I've been using our PowerTCP Web for ActiveX (specifically the PageFetch sample) to test this issue (which does not actively sanitize the path) (this is also why I didn't use "../" as the InStr check in case that "/.../" could have been a valid path). I suspect that this web browser URL sanitization is the reason your statements in the previous post were the case (please let me know if you find this is not the case). If you are interested in our HTTP/S client products, they can be found here for 30-day trial testing or purchase:

https://www.dart.com/products/powertcp-web-for-activex
https://www.dart.com/products/powertcp-web-enterprise-for-activex
lyve2ryde

From: USA
Posts: 25
Member Since: 02/25/15
posted November 14, 2020 7:38 AM

Nick,
Thank You very much, we already have a licensed version of the Web for ActiveX control, that we are no longer using. So I didn't think to test with it.
I used your PageFetch sample and was able to catch the request in our Get routine.
Unless there is something I am not aware of, a "/.../" would never be a valid request in our application, but I will discuss with others changing to "/../" instead.
Thanks Again, I feel more comfortable with the code change, not that I have been able to duplicate this issue.
Tim Snelling
lyve2ryde

From: USA
Posts: 25
Member Since: 02/25/15
posted November 16, 2020 12:21 PM

Hi Nick,
Just thought I'd let you know that our customer was upgraded with the software logic change in the Get Event.
If (InStr(Request.Filename, "../") > 0) Then
  'Return an Error Page...
End If

And our customer just reported that the issue found with the Nessus Scan Tool is now resolved.

Thanks,
Tim Snelling
Nick B (Admin)

From: Utica, NY USA
Posts: 614
Member Since: 05/25/10

Extra Support Options
Custom Application Development

posted November 16, 2020 4:15 PM

Hi Tim,

Great! Glad to hear it.
Reply | PowerTCP WebServer for ActiveX Topics | Forums   
This site is powered by PowerTCP WebServer Tool PowerTCP WebServer for ActiveX