Skip navigation

WinGate Proxy Server Again

WinGate Proxy Server

Discovered by Tom Hardy ([email protected])

Systems Affected

Networks Employing the WinGate Proxy 2

The Problem

Aim: To infiltrate internal "protected" network using the Wingate Proxy Server via file sharing.

Conditions:

(a) A default installation of Wingate 2
(b) Dialup connection with Wingate running on the "gateway" machine
(c) Local area network with default Wingate ip numbers, eg. the 192.168.0.0 network
(d) File sharing or even any daemon on any machines including the gateway. (I believe that MS introduced a "no file sharing" standard via dialup adapters. This method is able to bypass this by seeming as though the connection is via the localhost)
(d) At this stage an internal machine name is      required, if using a file sharing attack, but this is also being looked into.  (The Brain is ticking :))

Method: Using the Web Proxy one is able to use the CONNECT method (SSL) to make a clean link to an internal machine port. For this example, I shall use the netbios-ssn 139. For example send

CONNECT 192.168.0.2:139 HTTP/1.0

the wingate proxy will return

HTTP/1.0 200 Connected OK

and a clean link is open for the infiltration.

Notes: In my tests I have used the most excellent SAMBA package and the very nice Winsock control mixed with amazingly enough Visual Basic (quick and easy). Neat code/program will be supplied at a further date, but
this can no doubt be done with any TCP capable programming language. In earlier releases of Wingate
this was also possible through the telnet proxy.

Demonstration Code:

Due to the nature of the system, one is only capable of getting the machine name of the gateway computer using such commands as nbtstat and nmblookup (samba). The method i was trying was to set up a udp relay in order to utilise the internal machine"s udp netbios port (137) to use such problems, but fortunately I spent a while studying up on the netbios RFC and wrote my own code to do so. As this is now not an option via the socks 5 proxy, there only leaves a glimmer of hope, namely the dns server, which in the past i have used a number of times to find out some names, but this was on the whole a fairly unsuccessful method. Another point is that if the gateway machine is an NT box prior to sp3 then one is able to see other machine names.

But the essence of my initial claim is that file sharing is capable through the Wingate Server.

Attached is a very large and crude vb binary, but alas it demonstrates the problem well.

Notes on use:

======

(a) install
(b) start it up
(c) put in the ip of the wingate server in the first textbox
(d) get on a unix box with samba on it
(e) to view shares of a wingate internal host type in:

smbclient -L -I

-p 1000

(f) to use one of the shares:

smbclient \\\\\\ -I

of wingate host> -p 1000

 

In this example one requires the use of samba, but if I had the time I'd write a pure windows version in a real language, but this should suffice.

Countermeasures

=========

(a) a secure wingate server
(b) passworded internal shares

That"s about it, commonsense.

Stopping the Problem:

Load the new beta version of WinGate 2.1 located here.

To learn more about new NT security concerns, subscribe to NTSD.

Credit:
Reported by

Tom Hardy
Posted here at NTSecurity.Net
February 15, 1998

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish