Sign in to follow this  
Followers 0
Aghaster

Protocol Problem

9 posts in this topic

Hi,

I have problem concerning the limits of commonly used protocols. Some of you may know that I am working on a keylogger called KLog (see the link, it is the thread about it). So far, I've been happy using the FTP protocol. My program uses the following client/server model: the keylogger is the client, and it automatically connects to a server which I also coded. It uses the FTP protocol to send its information. It complies to the FTP protocol to bypass protocol filters, but it cannot be used with a 'real' FTP server, because it is more of a covert channel. I send the info in a non-standard way that still won't be blocked by a filter.

This is fine if the program just stays a keylogger, but I'm being asked to add new features that would make it more a trojan horse. I need to make the server (the program which the infecter controls) browse files on the infected computer (client) and download them. This is what FTP was obviously not designed to do, it was designed to do that the other way (client browses server, not server browses client). Because this is a big problem, I've at least made an "update" feature for the moment, so that <unknown guy> can infect the computers and update them at a later time. The update feature works this way:

Client connects to server, and sends data.

Before disconnecting, client asks for a file, update.exe

Server responds if the file exist, and its size, data socket is opened.

Client downloads the file if it does not already have a file of the same name and size, and then runs it.

This is fine for the moment, but trying to do FTP the other way it was designed to do is quite errr, unwanted. For file browsing and downloading, I thought I could make the server place a list of commands in a file, which the client would request at each time it connects. The client would then download the file and and run the commands (list files, send files, etc) and send it back to the server.

You see this is becoming quite hell of a problem. Would anybody know of a common protocol that would pass through a protocol filter, and in which I could make the server ask for things, instead of the client? The reason why I cannot make the keylogger a server is that most of the time people cannot access the router to forward the ports to the right computer. The only way I can work this out is to make the keylogger a client, because it is far easier to make an outgoing connection (no port forwarding).

0

Share this post


Link to post
Share on other sites

You may have considered this already... I believe a couple of 'push email' systems fake a 'reverse' direction by using long TCP/IP timeouts.

You could get the client machine to request 'instructions' but with a really long TCP/IP timeout, the server would only reply when it had an action (or just before the timeout was about to occur). If there was no instruction the client would just ask again. With your FTP-like system it could be as simple as the client doing 'GET COMMANDS'

Since you control both the client and server, once you have a two way dialogue going you can wrap anything up in the files/packets.

Cheers,

Mungewell.

0

Share this post


Link to post
Share on other sites
You may have considered this already... I believe a couple of 'push email' systems fake a 'reverse' direction by using long TCP/IP timeouts.

You could get the client machine to request 'instructions' but with a really long TCP/IP timeout, the server would only reply when it had an action (or just before the timeout was about to occur). If there was no instruction the client would just ask again. With your FTP-like system it could be as simple as the client doing 'GET COMMANDS'

Since you control both the client and server, once you have a two way dialogue going you can wrap anything up in the files/packets.

Cheers,

Mungewell.

Yeah, good idea. I've had an idea on how I could make FTP "reverse". When sending replies, the FTP server would place a dot '.' at the end of the reply explanation. This would mean that there are commands waiting. The client would then ask for a commands.txt, or something less obvious. This file would contain the commands. For file browsing, the client would use the DIR command and output to a file. This file would be 'uploaded' to the server. For file sending, it would simply 'upload' the file. I'd also make the client stay connected when we need to remotely access the machine. This means a lot of work, but yeah, it can be done.

0

Share this post


Link to post
Share on other sites

You could use ICMP or DNS -- most of the time, those protocols would be allowed through even a very restrictive firewall; also, you can tunnel more or less arbitrary data in the protocol, so you can have it do whatever you like (in other words, you don't have to make it "look like" valid requests/responses). You could set up your own application-level protocol, and piggyback it on one of those.

Some more info and some tools:

http://dnstunnel.de/

http://www.cs.uit.no/~daniels/PingTunnel/

I've recently gotten the idea to design something similar using HTTP (as near as I can figure, the "User-Agent" and "Server" headers should be able to contain arbitrary data, and I didn't see anything in the spec that provides a size limit). Of course, I'll probably never get around to actually building it, but it's a fun idea.

0

Share this post


Link to post
Share on other sites

What if you used TCP/IP but you disguised it as web browser traffic. mirrorshades gave me an idea. :D Let me explain:

You have the server appear to be a HTTP server. The client (on the infected machine) connects to the server and sends a user agent and server headers such as a regular web browser would. The HTTP server replies and then serves up the content. In this case it would reply with a connection to the client and the client can stream the data. Now the idea I had was you make the client use ONLY a specific web browser agent that the server will reply to. This way you avoid sending login credentials and any other packet headers. It then disguises your trojan horse as common web browser traffic. You could make the Browser agent be something like Internet Explorer, but a version that is no longer in use. Anti viruses may not notice this and in any logs the traffic will appear to be regular traffic.

This idea may be completely crazy though. Ignore it if it seems silly. :)

0

Share this post


Link to post
Share on other sites
What if you used TCP/IP but you disguised it as web browser traffic. mirrorshades gave me an idea. :D Let me explain:

You have the server appear to be a HTTP server. The client (on the infected machine) connects to the server and sends a user agent and server headers such as a regular web browser would. The HTTP server replies and then serves up the content. In this case it would reply with a connection to the client and the client can stream the data. Now the idea I had was you make the client use ONLY a specific web browser agent that the server will reply to. This way you avoid sending login credentials and any other packet headers. It then disguises your trojan horse as common web browser traffic. You could make the Browser agent be something like Internet Explorer, but a version that is no longer in use. Anti viruses may not notice this and in any logs the traffic will appear to be regular traffic.

This idea may be completely crazy though. Ignore it if it seems silly. :)

I've done something similar before, it seemed to work fairly well.

0

Share this post


Link to post
Share on other sites
You could use ICMP or DNS -- most of the time, those protocols would be allowed through even a very restrictive firewall; also, you can tunnel more or less arbitrary data in the protocol, so you can have it do whatever you like (in other words, you don't have to make it "look like" valid requests/responses). You could set up your own application-level protocol, and piggyback it on one of those.

Some more info and some tools:

http://dnstunnel.de/

http://www.cs.uit.no/~daniels/PingTunnel/

I've recently gotten the idea to design something similar using HTTP (as near as I can figure, the "User-Agent" and "Server" headers should be able to contain arbitrary data, and I didn't see anything in the spec that provides a size limit). Of course, I'll probably never get around to actually building it, but it's a fun idea.

Maybe you should take a look at the FTP protocol instead. I thought of using HTTP in the first place but then found out FTP would be just easier to use as a covert channel. Here is what I do to send keys "live":

CWD /txt/00480045004C004C004F

which is then decoded by the server as "HELLO".

I might take a look at DNS, but this would mean recoding all the network code, which is most of my code. FTP is also a very commonly allowed protocol.

As for arbitrary data, it still has to comply to the protocol. You have to put it somewhere the filter cannot know it is arbitrary. There is always the risk that the admin uses wireshark and looks at packets... to see this kind of weird stuff. He would certainly notice this is not a 'normal' FTP connection.

Anyway, I think doing a "reverse FTP" is still the most viable solution, considering I don't want to rewrite most of my app. Also, FTP was designed for file transfer, so I wouldn't have to do that much that it wasn't designed to do. I'd make my own custom protocol that I'd call RFTP, and write some simple doc about it. It would still comply to FTP, but add more features that would pass through a filter. Great for a trojan horse.

0

Share this post


Link to post
Share on other sites

The idea of a "polling mode" in which the keylogger client "polls" the server for commands, is better than you give it credit. The majority of boxen out there are behind firewalls and NAT, which makes initiating a connection from the server to the client tricky.

The problem with polling, is that if the client polls the server for commands too slowly, it breaks away from the "real-time" feel you're shooting for. Poll too often, and you create more traffic, maybe a noticeable level.

What if you have the server put out a command for the client to download (a la your update.exe), that has it enter a polling mode in which it temporarily checks in with a higher frequency. For as long as the server has commands waiting for the client, the client continues to check in sooner. When the client checks in and doesn't find a command once (or better... after a couple of times), it goes back into normal operation.

0

Share this post


Link to post
Share on other sites
The idea of a "polling mode" in which the keylogger client "polls" the server for commands, is better than you give it credit. The majority of boxen out there are behind firewalls and NAT, which makes initiating a connection from the server to the client tricky.

The problem with polling, is that if the client polls the server for commands too slowly, it breaks away from the "real-time" feel you're shooting for. Poll too often, and you create more traffic, maybe a noticeable level.

What if you have the server put out a command for the client to download (a la your update.exe), that has it enter a polling mode in which it temporarily checks in with a higher frequency. For as long as the server has commands waiting for the client, the client continues to check in sooner. When the client checks in and doesn't find a command once (or better... after a couple of times), it goes back into normal operation.

I thought of this. I'd make the server be able to decide to keep the client connected, in order to receive commands. In normal time, the client would only connect to send its data, but when I'd tell it, it would stay connected and wait for my commands.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0