Hello World!

Hi! My name is Elsaid Salem and this is my first blog. It is going to be a technical blog so it’s aptly named “Hello World!”. Needless to say, I’ll be improving as time goes on and as I get more experience and feedback about the blogs, so I welcome all kinds of feedback; please don’t be shy!

This blog and the ones that come after will tackle new and essential knowledge points about cyber security, how to get into it, and excel. I’ll also cover some common puzzles and learning modules such as hackthebox.eu and overthewire.org challenges to give my perspective and hopefully be helpful to someone out there who might have similar challenges. I’ll do my best to simplify things as we slowly build up vocabulary and concepts used in cyber security.

To kick things off, I’ll start with the Bandit challenges from overthewire.org. Without further ado, lets start with the first level: Bandit 0.

Bandit 0 and Bandit 1 are both extremely simple challenges but they require a good foundation for completing the challenges that come after. You’re going to want to get familiar with using the command-line (terminal on linux/Mac, powershell/cmd on windows). The first level, Bandit 0, simple wants us to log in to the device remotely. The machine is located at bandit.labs.overthewire.org. The first question is then how do we log in remotely to machines? Luckily, overthewire provides a hint at the bottom: “ssh”.

What is ssh? SSH is a remote access protocol and it stands for “Secure Shell”. SSH is a upgraded, secure version of telnet. So what does this mean and what does it do? In cyber security, the addition of word “secure” to a protocol usually indicates some level of encryption or at least authentication. SSH lets a user log into a machine remotely and operate it using its command line interface (CLI). So lets get start by exploring how to use SSH: mac and linux pretty much have SSH preinstalled and ready to go while windows machines might require you to install a program like putty. So how do we use it? If we look up the SSH protocol we see that it runs on pot 22 by default. We can also find information on its useage by googling “man ssh”. This will work on any OS and will search for the “manual page” of SSH. Reading through it, we can see that we need to specify a user, followed by the “@”, and finally the address of the remote machine. Luckily for us, SSH will also resolve domain names but if we wanted to find the IP of a machine on a public domain, we can always do reverse domain lookup, but we’ll get to that later. Overthewire provided us with the user ID of the level: bandit0 and the domain name as well as a port number. Since the port number give to us is not the default 22, we need to specify it in our SSH command. From the manual we find that to specify a port, we add the “-p” to the arguments followed by the desired port number, 2220 in our case. So let’s give it a shot:

ssh bandit0@bandit.labs.overthewire.org -p 2220

It connects! Nice. Now it says something about this being a new or unrecognized device and confirms whether or not you want to connect. For now, hit “y” and enter, it will ask us for the password for this user. This password was already provided to us: bandit0. In the future we will explore how to use keys to automatically log in without requiring the password.

Awesome! We’ve successfully logged into the machine remotely. Congratulations on completing level 0! Now how do we get to level 1?

Overthewire tells us that the password for the next level is in a file called “readme” that is present in the “home” folder. SSH by default, drops the user logging in into their home folder so the “readme” file should be available to us immediately. We can verify that we’re indeed in the “home” folder by using “pwd” (print working directory). We’ll get to traversing directories and viewing their contents as we progress through the levels. The next user ID is bandit1, that’s been given to us. So how do we read a file from CLI? There are many ways to read files but for the sake of simplicity we can use “cat” which simply prints the file’s contents on the screen for us.

Let’s pause here for a second to discuss the first security flaw that occurs more often than seems logical. This flaw is storing passwords for other users “in the clear” on user accounts. Many people think that since their initial account (or security layer) is already password protected, whatever else they store on this layer is safe. Unfortunately, as we can see from this example, this can be a serious data breach hazard since if this one password is discovered, everything else becomes available to malicious actors (bad hackers). This why a security standard called “defense in depth” is important. Defense in depth is the concept of putting multiple layers of security before a malicious actor can get their hands on sensitive data (like passwords). For example, in this case, adding another layer (and adding more “depth” to the security) would be to encrypt that password.

At this point, we now have both the user ID and the password for the account associated with level 1: bandit1 and the password that printed when we invoked “cat” on the readme file. So let’s clear this level by logging into bandit1 and looking at how to get to bandit2 (the next level). To do this we’re once again going to use SSH but we can do it in two ways and we’ll discuss the difference after we log in. The first way is to simply SSH into bandit1 from bandit0 without logging out. The second is to “exit” from bandit0 and log in to bandit1 directly from our own machine again through SSH. In either case the only step that’s different is the addition of “exit”-ing from bandit0. So let’s get to it:

ssh bandit1@bandit.labs.overthewire.org

This time, we won’t get the notification about it being an unrecognized device (because we’re likely on the same machine as bandit0 or this is commonly done and so therefore the machines are already acquainted with each other). It will ask for the password which we can provide thanks to the readme file from bandit0.

Amazing! We’ve just cleared 2 levels and learned about 3 new CLI commands.

So let’s revisit the login to bandit1 to start the discussion about logging and trust relationships. In the case that we’re secretly trying to traverse the network or moving laterally within a machine (logging in to different users), it’s more “secret” to log in to the machine from a local account (an account already existing on the machine or network). First let’s talk about logs and logging. Machines have been “taught” to log (record) every activity that happens (successful or failed) and generally any relevant information related to that activity. The level of detail (verbosity) of the logging is generally dependent on the setting by the administrator or the manufacturer. So in the case of SSH, it would record where the connection request is coming from (our IP address), if the attempt succeeded or failed, and which user that attempt was done against (in this case bandit0 and bandit1). So to minimize our tracks (if that’s important to the task at hand), it’s better to log in to the next user (bandit1) directly from bandit0. Since we already logged in, bandit0 will have a record of our connection attempt and the IP address we’re connecting from. And we’re in control of bandit0, so bandit1’s log will say that bandit0 tried to log in and it succeeded (without recording our IP address). This is not foolproof but it’s a general setting.

The second reason we should log in to bandit1 from bandit0 is the concept of trust relationships. It might be that only bandit0 is allowed to be accessed from outside the network and so trying to log into bandit1 will automatically reject our external connection if we try to do it directly from our device. This is because machines on an internal network can establish “trust relationships” (think back to the message when we first used SSH to log in to bandit0). As such, we are utilizing the trust relationship between the local machines and users to pivot (using one account or machine as a means to get access to another account or machine) to traverse a network or device.

I hope that this post has helped provide a ledge and stepping stone for those who are interested in the field of cybersecurity and if you have any feedback or corrections please, kindly, let me know!