COMMAND
Wingate
SYSTEMS AFFECTED
Wingate 4.0.1
PROBLEM
Gregory Duchemin found following. Wingate 4.1.1 is once again
vulnerable cause (once again!) of a too permissive redirector
engine (tested with version pro eval on NT server 4.0).
It's usual to say redirector services like telnet and ftp at
least, should be granted to only few people (authentication) and
binded only on private interface (binding configuration) while
accepting connections from some specific network/ip (wrapping).
Nevertheless, most of the time, http proxies, even binded only on
a private segment, are granted for all employees, for a public
usage. There is a way to abuse wingate services
authentication/wrapper/binding schemes simply by using the http
proxy. Any user allowed to connect the proxy should be able to
use any of UP wingate services.
For instance, if You create an admin account, allowed to use your
telnet and ftp services, while discarding all other users, You'll
be ask for username/password authentication next time You connect
to these ports (NT scheme or wingate one depending what You
choosed). Weather is clear.
Now, if You connect to the web proxy port and craft a special
request for the local telnet service while using ctrl-H chars, u
will be able to bypass twice policy (authentication) and IP
wrapper (binding conf) leading in remotely forcing wingate to
open a telnet, ftp, whatever... connection to any other host,
potentialy even from outside to inside the corporate network if
http proxy is reachable from outside (However, it was already a
bad idea before this bug).
If You don't use telnet, ftp, whatever services but have let them
binded on loopback (default configuration), You are vulnerable.
Take a look at that:
#telnet 10.0.0.1
Trying 10.0.0.1...
Connected to 10.0.0.1.
Escaped character is ^]
Login:
Telnet redirector asks for a credential. Till now, everything
looks quiet. And now....
#telnet 10.0.0.1 80
Trying 10.0.0.1...
Connected to 10.0.0.1.
Escaped character is ^]
GET http://127.0.0.1:23/H3ll
WinGate> GET /H3ll
Connecting to host GET.....Host name lookup 'GET' Failed
HTTP/1.0
Connecting to host....Socket error blahblahblah........
Great! we catch a wingate telnet prompt : WinGate > Telnet even
tried to connect to "GET /H3ll"! May be we could forge a good
request (a valid hostname/ip). Let's try something with ^H (this
old friend):
#telnet 10.0.0.1 80
Trying 10.0.0.1...
Connected to 10.0.0.1.
Escaped character is ^]
GET^H^H^H http://127.0.0.1:23/^H^H127.0.0.1
3 ^H for GET, 2 more for / and ' '
WInGate>127.0.0.1
Connecting to host 127.0.0.1...Connected
Connection terminated by remote host
Connection closed by foreign host
It's OK !...connection was established between telnet and pop3
services. It's possible to jump from service to service inside
wingate bypassing every authentication systems. Each connection
is present in the logging window but if You look more carrefully
in the telnet session properties u will see that we were telnet
authenticated as administrator (the mere user allowed in the
conf) without any password and from 127.0.0.1. Really funny !
When you configure a proxy service in the properties window, You
have to choose, among others, your binding/Interfaces/Policy
settings. These three are very important for your safety. The
first determine which interface connections are allowed to come
from. Second, to wich one, they should be sent. Third one
determine your per user policy. By default, bindings settings
come with "Allow connections coming in on any interface" checked
wich include loopback 127.0.0.1.
THE FLAW IS HERE !!
When connecting to telnet redirector (port 23 with only one user
"admin" allowed), You are prompted for login/password but when
connecting directly from loopback (on the proxy host), no
authentication at all! Alles klar, if users can use the http
proxy they can use loopback and redirecor too to bypass
authentication/IP wrapper for others services. Like described
above. For example:
#telnet wingate_ip 80
GET http://127.0.0.1:23/
Change TELNET PROXY bindings settings with "Connections will be
accepted from the following interface only xxx.xxx.xxx.xxx" and
You will be unable to do a bounce attack anymore even trying GET
http://xxx.xxx.xxx.xxx:23
It seems to be a BUG in the security scheme used by wingate that
trust that anything coming from 127.0.0.1 is already
authenticated.
If You look at "advanced options" in the Options menu, we will
find that default configuration trust any interface, You can't
disable trusting of 127.0.0.1 (at least not with an eval version).
May be disable this would make the job.
SOLUTION
ALWAYS Remove your services default binding to 127.0.0.1 (Never
use loopback), just use the IP address your really need!.