Using ncat as a Telnet Client

Next up on the tools I am trying to lean is netcat. They call it the Swiss army knife of networking tools. It is described as being like UNIX cat. But of course it runs over the network. Specifically it allows you to read and write to network connections. You can use any ports. You can use either the TCP or UDP protocols.

There are apparently multiple applications for netcat. It can do a rudimentary port scan. It can do file transfer. It can also act as a backdoor. Originally it was developed by "Hobbit" in 1995 for UNIX. There is a more modern implementation called ncat. Ncat adds things like support for IPv6 and SSL.

I downloaded ncat. Initially I could not figure out how to use it. Then I figured I would test it out as a client for telnet. Had to install a telnet server on my machine first. Ended up installing the free KpyM Telnet Server. Here is a hint for KpyM: they give you a registration key for free to remove the nag screen.

Initially I got ncat to connect to my telnet server. But it was displaying a bunch of strange characters. Was not sure if this was an ncat issue or a telnet server issue. So I got another dedicated telnet client installed. That client worked fine with my telnet server. Damn. I guess ncat will take some getting used to. Maybe a bunch of configuration to do.

So far I have not found much use for this ncat. Maybe as I get into network programming some more, I will find the need.

Sockets for Network Programming

I am finishing up my initial work on writing my own version of the Loki program. Have learned a bit about network programming, specifically dealing with sockets. Thought I would record some of that knowledge here for future reference.

Start out with the network protocols. There is UDP and there is TCP.

UDP is simple. It has less overhead. There is no guarantee that the data gets delivered. Also the order of data sent may not be kept. If your data is not delivered, it does not get automatically retransmitted by UDP. There is no concept of a connection with UDP. You just blast data to its destination. The recipient of the data has to take all of the data at once. Popular other protocols that employ UDP are DNS and SNMP.

TCP is a reliable transport protocol. If some data does not make it to the destination, TCP will handle retransmission. It will also make sure that the order of the data you send is preserved on the other end. You can think of TCP as a byte stream. The destination at the other end can read the bytes in any chunks they want. They don't have to read the message all at once.

When doing UDP and TCP network programming, you will be using sockets. Socket programming is old. It has been around since before the times of the World Wide Web. One popular old library is Berkeley Sockets, which have been around since 1982. There is also Windows sockets (AKA WinSock), that have been around since 1993. These sockets are point to point and are bidirectional.

With sockets, there is a client and a server side. The calls are somewhat similar for UDP and TCP. Generally you have to do less with UDP as it is connectionless. From the client, with UDP you call socket(), sendto() and/or recvfrom(), and finally close. On the server, with UDP you call socket(), optionally setsockopt(), bind(), sendto() and/or recvfrom(), and close().

For TCP, the client calls socket(), connect(), send() and/or recv(), and close(). On the server, TCP calls include socket(), optionally setsockopt(), bind(), listen(), accept(), send() and/or recv(), and close().

The socket() call returns a file descriptor. The bind call associates the socket with an IP address and port number. The listen() call will cause the server to wait for connections from clients. Then accept() gets the first connection, creating a new socket that is connected on both ends. You should have a multithreaded server to deal with multiple connections at the same time.

For data types larger than 8 bits, you need to worry about the order in which those bytes are stored and transmitted. There is a Big Endian and Little Endian convention for this byte order. Big Endian means higher order bytes are at the start. You got to worry about the order on the machines at both ends, as well as the order of the bytes in transit.

OSI Layer Headers in Network Programming

I am getting down to the details in my implementation of the Loki program. To review, Loki sends messages through firewalls using the ICMP protocol. I built a Loki client and a server (that I call Logan). Initially I just sent some test data through. Now it was time to start putting meaningful messages in the data.

For debugging purposes, I just created user interfaces so I could type in the messages on the Loki client. I also added the user interface to Logan, so you could view the messages coming through. At first my server program received the messages. But it could not extract out the text I was passing through. What gives?

Well I am just using old C strings. I it character data buried in the datagram. I even put a unique string of characters to help me easily locate the beginning of my message. The only problem was that I was using C strings to parse the contents of the message. Wouldn't you know it? There were a bunch of zeros buried in the headers.

Fine. So I skip over the ICMP header. The thing still does not work. Wait a minute. By the time the transmission gets to the server, it also has an IP header as well. Duh. Once I skip over all layers of the header, I am in business. I can transfer messages to and from my programs at will.

I might run one more test so see how far apart these programs can be and still operate. Same LAN? Anywhere on the Internet? I guess it all depends on if the middlemen pass the ICMP messages through. At this point, it should be a trivial exercise to replace my "hello" messages with commands to do stuff on the server computer.

ICMP Server Called Logan

I had previously struggled to code up a client program similar to Loki. It sends out data using the ICMP protocol. The idea is to sneak past firewalls that do not block ICMP. Now I needed a server to listen for ICMP messages from my client. I will call this server program Logan.

Started off with some lessons learned from coding up Loki. Must run this program as Windows administrator to prevent the raw socket usage from being blocked. I was a bit confused about needing a call to bind() before I recvfrom(). However when I skipped the bind() call, I got error code 10022, also known as WSAEINVAL.

Okay. So I need to do a bind(). I want to get ICMP packets from anywhere. Therefore I specify an address of INADDR_ANY. But I need to set the port parameter too. The only problem is that, unlike TCP and UDP, ICMP does not use ports. It does not make sense. For now I am using port 7, also known by IPPORT_ECHO. Who knows? Maybe the port number is a don't care.

All I do know is that I can detect and capture packets sent by my Loki program. So the next step is to put intelligent messages in my ICMP packets to "do things" on the target computer. Let's maybe start with some cool but harmless actions and see where it leads. Eventually I will need to figure out how to distribute my server program and run it as Windows administrator.

Baby steps. One thing at a time first.




 

Rolling my own ICMP client

I searched around on the Internet for a program named Loki. It was supposed to send traffic using ICMP. The idea is to hide stuff in there that firewalls would not detect/block. I did find rumors of this program. But could not find the program or even the code for it. Damn.

What is a programmer to do? Write my own version I say. I broke out Microsoft Visual Studio and wrote some C++ code. There were surprisingly few lines of code in my program. Essentially I am making a socket() call to set up the communications, and a sendto() call to push out the data.

Unfortunately the socket() call kept failing with an error of 10013, which is also called WSAEACCES. This is some kind of permission denial on Windows. I tried overriding this by setting a value in the Windows registry. No luck. I am logged on as an administrator on my machine. So I should be able to open up a raw socket.

A couple web site gave me some other ideas. In the end, I had to start my Visual Studio IDE, running it as an administrator. So to begin I just was sending myself some ICMP packets. At least I thought I was. Downloaded Wireshark to record the output and prove the thing was working.

Initially Wireshark did not pick anything up. I broke out the Windows ping program to test Wireshark. It captured that data, but not my own program's messages. Then I modified my program to send some ICMP packet to Google instead of myself. Bam. We are rocking and rolling.

Right now I just send a bunch of garbage in my ICMP packets (sorry Google). And this is just the client end that sends messages. I need to write a server end that runs on another machine. And instead of sending garbage data, I might just have to send some commands over ICMP that "take control" so to say.

This has been an exciting start to researching programs of interest that bypass firewalls. There were some rough patches. But I am learning to power through adversity, like not being able to find my programs. Also broke out an old but good book "UNIX Network Programming" by Richard Stevens. Good stuff.

Covert ICMP using Loki

I have recently been made aware of lots of software. This is in the context of things that might compromise or help you punch through a firewall. So I have decided to go find said software and play with it. I figure the experience will be good.

First up on the list is Loki. This is a server on UNIX that lets you covertly communicate by hiding messages in ICMP packets. It is an old trick. Phrack magazine issue 49 from way back in 1996 introduced the idea. But it did not release the code or program.

Strangely enough, I was never able to locate the Loki program. Damn. How is a brother supposed to learn about this stuff? I know. I can roll my own version. I can write code. How hard could it be? Just got to study up a bit on ICMP, which I hope is fully documented. Then I am off to the races.

I think I am going to have to spin up a Linux instance somewhere to play with the software I find. Loki was for UNIX. And next I want to investigate netcat, which I presume is also a UNIX program. For now I can write my own Loki for Windows. But I can't write all the software. Who has time for that?