AnalogX Proxy Vulnerabilities

 

CONTENT:

1) What is AnalogX proxy?

5) Other features.

2) Using the FTP gateway.

6) Port scanning an AnalogX Proxy.

3) The IRC bouncing bug.

7) Finding AnalogX Proxies.

4) The FTP bounce bug.

8) Credits and References.


1) What is AnalogX proxy?

This is a windows based freeware (www.analogx.com) proxy and is frequently used in small LANs as a gateway to internet. It offer up to 6 gateways, they are, http, ftp, nntp, smtp, pop3 and Socks proxy (see picture below). This proxy has been programmed just thinking on intranet access, so the most important feature on security, is IP filtering (there isn't user/pass level access, unlike other gateways). Then if any user install this proxy on his computer, and doesn't care about IP filtering, then this proxy can be accessed not just from intranet, also from the whole internet.

 
In my research for ftp proxies, I found that 8 of 10 proxies installed on network computers are AnalogX, most of them are versions 4.07 and 4.10 (I know there is a newer version 4.12 but I couldn't find a proxy server to test). Ports that are being listened to by this proxy are:
HTTP 6588
FTP 21
NNTP  119
SMTP  25
POP3 110
Socks 1080

2) Using the FTP gateway

You can access to an AnalogX ftp gateway, by doing telnet to the ip hosting the proxy, that I'll mention as AXproxy. Do a Telnet at port 21.

>Telnet AXproxy 21




The first BUG of this proxy you can notice quickly if you press any key:



It happens because it assumes that every chunk of data it receives, must contain a complete command on it. To avoid this, AnalogX proxy might be programmed so it would join each chunk of data received into a buffer, and then explore that buffer to extract valid commands (by searching for the CRLF char), if an invalid command is found, then it must return a 500 command not understood message, but always when a CRLF (standing for a command delimiter) is present, otherwise it can be a fragment of a valid command, in that case the server might wait for a new data incoming.

A little trick for bypassing this bug (as when we use telnet for windows this can be very annoying), is by using "copy/paste" instead of direct typeing. I'll use instead a telnet script for mirc as this may be more convenient for illustrating purposes.

The way that FTP gateways work is by relaying the connection to the destination server, but they parse the commands they need to proccess in order to support binding of incoming connections from the client if not in pasive mode. Then they parse commands like PORT or PASV. Almost every FTP gateway control the data flow by filtering unknown commands, and unknown replies from server, that ensures that gateway is going to be used just for FTP services. The big BUG of AnalogX, is that it doesn't filter unknown commands and responses, when the proxy logs succesfully into the target server, it doesn't care if the server doen't reply with a 220 code msg (a ftp welcome banner). In fact, every command that isn't understood by AnalogX can be passed to the target server.


But when used to connect with AnalogX:



If you just want to use the ftp gateway for connecting to a ftp site, i.e. ftp.netscape.com, there are some ways to do such thing, in some FTP gateways it can be done:



What the FTP gateway does, is connect to ftp.netscape.com on port 21, and wait for a 220 msg banner from the server, then it sends a USER anonymous command, and leave the rest of the login procedure to the client.

In fact, if there werent those control numbers at the replies, like 220, 221, 230, 331, 451, 500..., and it were another gateway rather than AnalogX, then the gateway wouldn't relay the replies to the client.As you see, its very dificult to cheat a FTP gateway others than AnalogX.

There is another tip that we can use to avoid the initial "USER user" command sent by the proxy to the server in the procedure of login. There is a method of connecting through a FTP firewall that doen't require login (that is, the procedure of logging is left to the target server instead participating the proxy on it). This method is obsolete, and not used for the most of compliant FTP gateways. But AnalogX implements it, i think this is because of compatibility purposes. This is the OPEN method. So we can do something like this:

 

3) The IRC bouncing bug:


If we've found an AnalogX FTP gateway, we can use those features explained above, to connect to IRC via FTP. As long as AnalogX gateway let us relay all data to the target server, don't mind if it's a FTP server or else.

Then we can proceed like we were connecting to a FTP server via proxy, but instead we'll try to connect to an IRC server:

 


This demonstrates that an AnalogX FTP proxy can be used as a gateway to IRC (in this case, the undernet network), But this procedure can be done by using an IRC client, i.e. mIRC. This can be done by passing the commands to the server with the /raw or /quote IRC commands at the status window.

 >/server AXProxy:21

FTP AnalogX Proxy 4.07 (Release) ready
not understood

>/quote OPEN eu.undernet.org:6667

 ***Looking up your hostname

 ***Checking identd

 ***Found your hostname

>/quote USER param1 param2 param3@host.com param4

>/quote NICK urnickhere

PING? PONG!

*Welcome to the Internet Relay Network urnickhere

...

When mirc performs a /server command, after connecting it sends a NICK mynick command to the server, then AnalogX proxy obviously don't understand, if it were another proxy, it just disconnect, but AnalogX stay waiting for a new command, that makes possible to connect to IRC via a FTP proxy.

You can use AnalogX FTP proxy to clean access to others gateways, for example, many scanners (i.e. Dalnet scanner) scans at port 23, and g-line if they find a wingate. They look for the string Wingate> and if this string is not found, it's assumes that server open at port 23 is a secure telnet server. But there is known that there are other telnet gateways rather than Wingates, that can be used for anonymity purposes. Most of those gateways disconnect if they receive an unknown command at the login procedure, but as we have an AnalogX FTP proxy we can filter this so can access to the irc network:  

>/server AXProxy:21

FTP AnalogX Proxy 4.07 (Release) ready
not understood

>/quote OPEN tngateway:23

Enter Remote address:port>

>quote irc.dalnet.org:6667

*** Checking for identd
...


If we wouldn't use the AnalogX proxy to access to the telnet gateway:

>/server tngateway:23

Enter Remote address:port>NICK mynick

***Disconnected

Think of it! We can chain as many FTP proxies as we want, and not just FTP proxies, we can use Telnet gateways, HTTP  gateways (if we use the HTTP_CONNECT feature), and socks gateways. żDo you see how useful can be used this for making crazy the people that try to track back the IP chain? more if we switch from diferent proxies, even creating loopbacks. For example, we can build this chain:

MyIP -> AXProxy1:21 -> AXProxy2:21 -> AXProxy1:1080 -> AXProxy2:6588 -> AXProxy3:1080 -> AXProxy2:1080 -> AXProxy1:6588 -> AXProxy3:21 -> AXProxy4:21 -> irc.undernet.org:6667

You can notice that the only requirement is that ASProxy4 has just port 21 open, while other known ports for http and socks must be closed.

Of course, if just one of the AXProxies is not logging (and it is really possible as the owner would think this is a waste of time for an intranet), then the traceback is broken, and they should recall the help of the ISPs, so think if you use AXProxies located at certain unfriendly countries...

You can use this bug of AXProxy FTP gateway for protocols other than IRC, in fact, the less in common with FTP protocol, the more success, as AXProxy will relay the requests unfiltered.

4) The FTP bounce bug:


It's well known (as explained by hobbit - 1996) that earlier FTP servers implemented a feature called "FTP proxy". This was intended to be a flexible handling of data connections, but indeed it was a security problem, because anybody could establish a really hard-traceable connection. The vulnerability relays on PORT command of FTP protocol. For example, you can connect to a server at IP 111.222.111.222, on port 21. After a log in procedure, you could perform a PORT operation. This prepares the server so it knows where to establish a connection for transfering data. The bug is that there is not needed that the IP receiving the data connection to be the same as the IP originating the control connection. The format of a PORT command is:

PORT cc,cc,cc,cc,pp,pp

Where cc (in octet format) is the IP of the computer that is going to receive the incoming data connection, and pp are the high order and low order bytes of the port that will be open for the transfer.

If that port is open, you can, first send a file to the FTP server, that file could have a list of commands for a particular server, for example, commands for another FTP server.

Nowadays, nearly all of the FTP daemons are fixed so it's really hard to find a FTP server with this vulnerability.

However, we can play with it, and our favourite FTP proxy.


What we've done is to send the default directory file listing, to donut.vuurwerk.nl:6666 ( PORT command at 62.250.14.6:6666) that is a server of the Undernet IRC network. This information is garbage for this server, but you could imagine what could do a directory listing (think on huge servers) of hundred FTP sites as it just need hundred of simultaneous connections and PORT commands. Instead of directory listing, we could send a file (with some commands on it) with the STOR command,  then you will be creating a connection to the target server, that is indirect (so it's hard to traceback) and this connection is still established even if you close all connection to the proxy server (only the connections are closed when the data transfer is finished).

The server at ftp.netscape.com, despite it was logging all the time, each PORT command it got the IP of the proxy, so it cannot know that the data has been relayed to the Undernet server. And the Undernet server will notice that incoming data is going from the proxy server. Then your IP is out of the path.

Although we've sent a bit of garbage to the Undernet server via AnalogX proxy, we can't say that AnalogX proxy isn't fixed for this bug. The fact is that ports below 1024 are blocked inside the proxy for addresses others than the originating control connection (maybe AnalogX programmers would think that ports greater than 1024 are relevant and not to be considered, you know, ports like 1080,4444,6660-9,7777,6699,8000,8080...), so even though the data transfer between ftp server and proxy succeed, the transfer to the target destination won't. In fact we cannot know if the data arrived to the destination, as no error messages are returned from the proxy. The only way you can check this works, is, by connecting using FTP chaining (as explained above), to hide your IP both to the final proxy and the FTP server, and then try to connect (via PORT command) to a dummy server that you run on your IP, if you receive the directory listing, then you can be sure the bug will work with the target server.

One consideration, as we know that FTP data transfers are unidirectional, we cannot see the answers the server is sending while performing the FTP bounce feature, then you may guess what the server is responding at every action that you planned.

5) Other features:

There are other features of those Protocol Gateways. For example, you can use the NNTP proxy to access to a private (and probably fast and huge) news server. You can access to a POP3 server (be imaginative), and even you can send anonymous email from the server relayed by the SMTP proxy, NOTE FOR SPAMMERS, 99.9% of the AXProxies, although is enabled the SMTP proxy server, user didn't set up for work with a valid SMTP server, then you cannot use them to send junk mail.

6) Port scanning an AnalogX Proxy:

If you do a portscan at an AXProxy, then you may find that all ports are closed, this is a "somehow antiscan feature", that is, AnalogX limits the max users connected at a time, but instead of limiting the successful connection, what it limits is the number of atempts at a time, then if you scan by opening 5 or more sockets, then AXProxy refuses the connections and you can't find any open ports, then when you scan for open ports, you must do it for known ports, (21, 23, 25, 80, 81, 110, 6588, 8000, 8080 ,8081...), and do it with just 1 attempt at a time to ensure response.

7) Finding AnalogX Proxies:

As you can see, AnalogX proxies have tipically open port 6588 for HTTP proxy. This doesn't mean that every computer that listen to at 6588 runs AnalogX software, but 95% are running it. The obvious way of finding is by using a network scanner. This is time-consuming and risky (you can be treated as a hacker, well, I know there is nothing wrong in being one, but not everybody think like me, hehe). Other way is to take old lists of known http and socks proxies, search addresses pointing to port 6588, and then test it. Get lists of socks proxies with port 1080 (socks), and change port to 6588, you will find http proxies, even ones that once were running a socks gateway but now are disabled god knows why.

Dont forget to check if proxies at 1080 and 6588, also open at port 21. Do the procedure explained above, with port 21, (optional with 25, 110 and 119), and you will get many ftp gateways (nearly all of them are AnalogX). The ones that don't open ports 1080, 6588, 80, 23, 8080, 8000, ... are good candidates to be used with IRC networks like undernet (by using the IRC Bouncing Bug), as their scanner can detect many of proxies at not standard ports.

HTTP proxies running at port 6588, when are being tested with a proxy checker, like the one that comes with AATools, then most of them report an anonymity level of 100 (highly anonymous), and most of them implement the HTTP_CONNECT feature, so they can be used for connecting to IRC and other protocols.

8) Credits and References:

This document has been written by DrK3055A, A.K.A. ProxyGrabber. I want to thank to the people of  Proxy Blind Site and its Forum for giving emotive support and Excelent information about proxies of any kind.

If you want to know more about these protocols, take a look at these RFCs:

 - RFC959, File Transfer Protocol.

 - RFC1459, Internet Relay Chat Protocol.

 - RFC1945,RFC2068,  Hypertext Transfer Protocol (1.0/1.1)

 - RFC1928, Socks v5 Protocol.