Remove Services from Windows

Ever had a Windows services that either wasn't working correctly or for some reason didn't get removed correctly when uninstalling or changing an installed application? For cases like these, the sc command can help to get things cleaned up. sc is a command line utility for interfacing with the Service Control Manager. To remove the service, first you'll have to know its name. Launch services.msc and find the service you want to remove. Open up the properties dialog for it and note what is displayed next to "Service name." This is the value you'll need to put into the command line.

Run cmd.exe as administrator. This is the syntax for removing a service:

>sc delete <service name>

Downloading Files Using the Command Line

If you're used to using a GUI, you probably never think about how to download content from the Internet or a local server. Downloading content using the command line, however, takes a little more conscious effort. Luckily, its pretty easy to do once you get the hang of it. For me, there are two commands that I like to use most of the time and they are wget and curl.

wget
wget is a petty straight forward in how it works: it downloads things. It can be used to download files using HTTP, HTTPs, and FTP. I find wget useful for either downloading files to a server that might not have a GUI or if I want to script something. As an example, to download the latest version (as of this writing) of Firefox

$ wget https://ftp.mozilla.org/pub/firefox/releases/44.0.2/linux-x86_64/en-US/firefox-44.0.2.tar.bz2

curl
curl downloads and tries to process the target all in one action. curl also supports a lot more protocols than wget. This tool is great if you want read a file stored on a server (among other things). My favorite use for it is actually pretty simple: seeing my external IP address

$ curl icanhazip.com

Enable SSH Key Based Authentication

By default when you setup an SSH server, users will login using username/password authentication, just like if they were physically present at the box. SSH also supports using keys to authenticate. This can by useful for a number of reasons, such as:

• Make logging in faster
• Scripting and automation
• Part of mult-factor authentication

Before we go any further, log into your SSH server to make sure it is configured to allows key based authentication.

$ ssh myaccount@server
$ cat /etc/ssh/sshd_config | grep AuthenticationMethods

The default configuration for SSH servers is for that command to return nothing, which means key based authentication is enabled. If it returns publickey, it will also work. There may be other values included in the line. If they are separated by a comma, then they require multi-factor authentication. If they are separated by a space, they can be used for single-factor authentication.

In order to make things work, you need to generate a key-pair for your user account on the endpoint (client) you are going to connect from. Then, you need to put the public key from that key-pair onto the system where you are logging in using SSH (server). If you want to have multiple different users be able to log in using keys, you need to repeat this process for each of them. Let's walk through it.

Start by generating the key-pair using your account on the client system. You can adjust the options here depending on how strong of a key you want to use. I'm going to use the strongest possible key that is supported at this time.

$ ssh-keygen -b 521 -E sha256 -o -t ecdsa

Let's have a look at where the new keys are stored

$ ls -l ~/.ssh/
total 16
-rw------- 1 myaccount myaccount  736 Feb  6 15:33 id_ecdsa
-rw-r--r-- 1 myaccount myaccount  268 Feb  6 15:33 id_ecdsa.pub
-rw------- 1 myaccount myaccount 1386 Feb  8 20:46 known_hosts

In this case, id_ecdsa is my private key. Notice how only myaccount has access to them. The public key is id_ecdsa.pub and anyone can read it. Next, you'll have to get a copy of the public key over to the SSH server and store it in the home directory for the user account you'll be logging into. We can use scp to get the file copied over.

$ scp ~/.ssh/id_ecdsa.pub myaccount@server:~/

This will place the public key in the home directory of your account on the SSH server. For the next part, you'll have to connect to the SSH server.

$ ssh myaccount@server

Copy the public key to the end of the authorized_keys file for the account. Note the use of the double carrot (>>) here. A single carrot (>) will overwrite the file if it already exists. A double (>>) carrot will add text to the end of the file if it already exists. Either way will create the file if it does not already exist.

$ cat id_ecdsa.pub >> ~/.ssh/authorized_keys

Now you're all set. Log out of your SSH session and then log back in. When you reconnect, it should authenticate with your key-pair and not prompt for a password (unless the server is configured to use multi-factor authentication).

Solving Over The Wire Bandit Levels 0 - 5

The Over The Wire Bandit challenges are a cool way to learn your way around a Linux shell. Some of the levels are easier to figure out than others. I highly encourage working through these challenges on your own. If you get really stuck to the point of giving up, then read on. Also, some of the challenges can be solved multiple ways. This is how I solved them.

Level 0
This level is about getting logged into the system using ssh. Log in with the username bandit0 and password bandit0 as provided on the page

$ ssh -l bandit0 bandit.labs.overthewire.org

Level 0 -> 1
This level is about learning to read files. The password is stored in a file called readme stored in the home directory

$ cat readme 
boJ9jbbUNNfktd78OOpsqOltutMc3MY1

Level 1 -> 2
For the next and all subsequent levels, you'll probably want to exit out of the ssh connection and then reconnect using the next sequentially higher username (bandit1, bandit2, bandit3, etc.) along with the password unlocked in the previous challenge.

This challenge is figuring out how to read a file that starts with special character, in this case a hyphen (-). This can be solved by specifying the full path to the file

$ cat ./-
CV1DtqXWVFXTvM2F0k09SHz0YwRINYA9

Level 2 -> 3
This level is learning how to handle spaces in a file name. The answer is by using the backslash (\) character. Also, once you start typing the name, you can use the tab key to autocomplete the name of the file and the backslashes are put in automatically

$ cat spaces\ in\ this\ filename 
UmHadQclWmgdLOKQ3YNgjWxGoRMb5luK

Level 3 -> 4
This level is learning how to look around the directory structure and find hidden files. The password is stored in the inhere directory. Start by having a look around

$ ls
inhere
$ ls -a inhere/
.  ..  .hidden
$ cat inhere/.hidden 
pIwrPrtPN36QITSp3EQaw936yaFoFgAB

Level 4 -> 5
All of the files in the inhere directory are in binary format (not human unreadable), except one. Sure, you can just read all of them until you find the correct file, but there's a better way to do it using the file command to see what type of files they are

$ file inhere/*
./-file00: data
./-file01: data
./-file02: data
./-file03: data
./-file04: data
./-file05: data
./-file06: data
./-file07: ASCII text
./-file08: data
./-file09: data
$ cat inhere/-file07 
koReBOKuIDDepwhWk7jZC0RTdopnAYKh