Tyler St. Onge|

Brief Update

It’s been awhile since I’ve written about the status of the honeypot, so I’ll just update quickly on where it stands and what needs to be done; mostly as a note for myself. I’ve mostly put this project on the backburner for now (I’ve started work on a new project that deals with gardening which makes more sense to work on during the few short months of warm weather we have in upstate New York). I plan on addressing these few concerns when I have time though.

As a side note, I didn’t include this in a blog post (though I should have) but I added a discord alert which puts a chat message into my discord channel every time there is some event with the honeypot (it gets pretty noisy). That code exists in the repository if you’d like to take a look.

Known Issues

Support Encryption

The biggest issue I saw was that while I was getting plenty of connections and authentication requests, the first command the hackers wanted to run was to switch out of cleartext and into some encrypted communication channel. I wrongly assumed a hacker wouldn’t care about having a secure channel to upload malware over, but in reality it’s such an quick thing to do and is baked into most FTP libraries that I should have worked on implementing this from the beginning.

Different modes for different goals

I guess this logic issue slipped by as I was too busy programming, but if the goal is to generate a password/username list I will need a mode which denies every authentication request so that a robot will continue trying other combinations. However, if I want to receive files the current mode of operation is fine, which is that it accepts the first authentication request. Another option would be to gather a certain number of attempts before allowing the hacker to connect; this way I will be able to compile my own lists but also gather some malware samples.

Intro

In my previous post, we investigated the inner workings of the File Transfer Protocol, at least the subset of commands that we deemed necessary for our purposes. Now we will take that information and implement it in Scala to create our rudimentary honeypot.

I will be leveraging the Akka and laying out most of the system through their Actor system. This approach will allow many different pieces to run concurrently and give us an excellent basis to extend this honeypot in the future to handle more protocols. To keep this post concise, I won’t go into depth about setting up the project or the Akka library’s specifics. The entire project exists on my local git repository.

Basic Architecture

At the core of this honeypot, implementation is the idea of having a root Supervisor, which will read a configuration file to create child actors responsible for handling server input for one mock protocol. I chose to use JSON for the configuration file since I’m not too fond of whitespace and curly braces spark joy in me, but if you aren’t so inclined, I’m sure switching to YML would be trivial.

Supervisor

Within the Supervisor we can see the looping over configuration file and instantiate of each components, for each component we send ourselves a MStartComponent message containing the information necessary to create it, using self ! MStartComponent(...). Most of this is straightforward with the interesting function being startComponent. This is where we will extend support for further protocols in the future, but right now only supports FTP.

1
2
3
4
5
6
7

private def startComponent(msg: MStartComponent) {
  log.info("starting component :: {}", msg.name)
  msg.ctype match {
    case "ftp" => context.actorOf(FtpListener.props(msg.port), name = msg.name)
    case _ => log.error("unknown component type: ", msg.ctype, msg.name);
  }
}

FTP Package

Within the FTP Package of our project lies all the real goodness that mimics an FTP server’s functionality enough to accept logins and files. The FtpListener is the entry file that is stood up by the Supervisor and is responsible for handling initial FTP connections into our system. Just a quick FYI also, this is configured to run on port 21, just like a real default FTP server, to make it easy for hackers to identify what the server is for, but this may require root privileges depending on your system.

Pre-post Drivel

This is the obligatory part of this post where I say, “wow, I haven’t posted for a while, I’m going to do better” but in reality, I program 8+ hours a day and a lot of times when I get home I’d much rather get some time away from the computer. However, I do feel that having a good project I can slowly work on in my free time with some technologies I don’t normally use could be fun and help expand my skillset.

I have always been interested in the security side of programming, and what better way to understand cutting edge security than to make something that’s very purpose is to see what people (mostly bots) are currently doing to exploit cloud applications. I am planning to implement most of this in Scala, which I do not use very often, so feel free to email me if you see some real rookie mistakes.

What is a Honeypot anyway?

hon·ey·pot
/ˈhənēˌpät/
noun

1. a container in which honey is kept.
   “an earthenware honeypot”

Well, not that kind of honeypot…

The one I am talking about is a server that mimics real applications in hopes of catching someone attempting to exploit it and logging the different methods that are used. There are plenty of open-source tools that accomplish this now and you can do something as simple as open Netcat on port 80 and see what files a hacker is requesting from your “webserver”.

That is, at its core, what a honeypot is. Obviously, things can get more complicated. You will want to make sure your system doesn’t get hacked and you want your fake application to have complex enough features so a hacker is tricked into thinking they’re exploiting a real system and that they’re getting the expected results back. If they are trying to leverage a command or query a file you do not have or support, they’ll probably just move onto another target and you’ll miss out on discovering what their technique was.

First Act - The Trap

I recently stumbled across a bunch of old Ezines from what I think is the 90s about virus development in assembly. It seemed like a pretty cool topic to look into and I figured it would be an excellent way to expand my knowledge of Assembly and coding in general. So let’s start with a hello world in Assembly. I am writing in 32bit assembly on Linux and I use YASM to assemble the code but NASM itself would work fine as well.

The Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

section .text
	global _start
_start:
	mov	eax, 0x04
	mov	ebx, 1
	mov	ecx, hello
	mov	edx, len
	int	0x80

	mov	eax, 0x01
	int	0x80

section .data
hello	db	"Hello, world!",0x0a
len	equ	$ - hello

Explanation

So at first glance Assembly looks like a load of jibberish, but it is actually pretty easy to understand. Let’s break it down section by section.

1
2

section .text
	global _start

All this section is doing is declaring that we are within the .text, which is the section that is going to contian all the code of the program, and that the entry to our program is the _start label.

1
2
3
4
5
6

start:
	mov	eax, 0x04
	mov	ebx, 1
	mov	ecx, hello
	mov	edx, len
	int	0x80

This is the meat of our program. First it defines the following code under _start, programs can divide their code into multiple labels but for a small program like this we can easily just leave it all under this one label. We continue by moving the hex value 0x04, which is what tells the computer we want to use the write command, into the register eax. How did I know that 0x04 was the call for write? It is stored on your computer in ‘/usr/include/asm/unistd.h’ or you can just google linux syscalls. The next command moves the value 1 into ebx. This is how we specify that we want to print to stdout so the text will be displayed in the terminal, we could have alternatively supplied a file descriptor to write to but I’ll talk about that in the next tutorial. After that, we move our string (which we will define in the .data section) into ecx, and we move the length of the string into edx. After we have set all the proper registers we use the interrupt 0x80 to tell the computer we have everything set for the function to run, which then causes the string to be printed.

It’s been quite awhile since I’ve made a blog post, not that I haven’t been up to tons of cool things, it’s just that I forget to find time to write about them. I am going to make an attempt to strengthen my writing skills and write posts about what I’m doing more often. With all the projects and learnign I do I feel that if I document them it will be a lot easier for me to keep tabs on how I’m progressing and at the same time maybe my ramblings may assist other people in their journeys. Anyway, as for the topic of this post I figured I’d pick up where I left off with the first and attempt the next IO Level from SmashTheStack.

Getting started

Now this level allows us to read the source code, which is as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

//a little fun brought to you by bla

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>

void catcher(int a)
{
        setresuid(geteuid(),geteuid(),geteuid());
        printf("WIN!\n");
        system("/bin/sh");
        exit(0);
}

int main(int argc, char **argv)
{
        puts("source code is available in level02.c\n");

        if (argc != 3 || !atoi(argv[2]))
                return 1;
        signal(SIGFPE, catcher);
        return abs(atoi(argv[1])) / atoi(argv[2]);
}

Looking at the code we see our target right away. We must get into the “catcher” method in order to set our uid to the next level and get the pass. Inside of the main method there is an if statement that when we do not supply 3 arguments OR if the second supplied argument is false (this means if argv[2] is 0) it will close the program.

So to get to the next lines of code we must supply 2 arguments with the program and the last argument must not be 0. Easy enough.

Continuing along, the next line sets the catcher method as the handler for a SIGFPE signal. So how exactly do we trigger a SIGFPE signal?

The SIGFPE

Recently I have been attempting to improve my programming knowledge by trying to grasp a deeper understanding of the memory allocations and getting deeper into the ways the computer handles it’s processes.
I figured a great way to do this would be to look more into exploitation, and so I picked up the book “The Art of Exploitation” which was an excellent read and I recomend it to any programmer looking to take the red
pill and see all the mess and loopholes that can be created when ignorantly hacking together programs in high level languages.

While reading this book and getting closer to the “hacker” community I found more about
wargames, which is how I wound up at SmashTheStack.org and writing these tutorials as I’ve conquered them one at a time.I would like to point out that this is definitely not the first tract of wargames I have done, but it is the first I will try to document and explain as I go through, both for myself and anyone who happens upon this.

The obvious first step would be to investigate the file and find out what needs to be done:

1
2
3
4

level1@io:/levels$ ./level01
Enter the 3 digit passcode to enter: 123
level1@io:/level$ ./level01
Enter the 3 digit passcode to enter: hello

The program does not offer any hints, but we can assume that if we enter the right code it will either print the password to level2 or drop us into a shell with permissions to read the password to the next level.
I also tried to break the program by enter bad data to see if it would return anything funky, though it didn’t help.

The next step I tried was to run a simple “strings” command on the file, though since we are looking for a number this was unlikely to help.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

level1@io:/levels$ strings -a level01
,0<     w
Enter the 3 digit passcode to enter: Congrats you found it, now read the password for level2 from /home/level2/.pass
/bin/sh
.symtab
.strtab
.shstrtab
.text
.lib
.data
level01.asm
fscanf
skipwhite
doit
exitscanf
YouWin
exit
puts
main
prompt1
prompt2
shell
_start
__bss_start
_edata
_end