While everyone is preparing writeups for the cool challenges I think a lot of people would also be interested in the funny things that went on during CSAW.

Poor Kevin

One of the recon assignments was to find a hidden flag for “Kevin Chung”, the challenge simply starts like this:

What could possibly go wrong right?

Spoiler alert! Where you were supposed to end up was here: https://github.com/historypeats/putscan/commit/a31512af6e8f2ae76bce11c0bd363f899e3488d1

Which I didn’t exactly find out about right away – I did however find his website http://coderkevin.com/. This site initially taunted users about the key (via a Youtube video and some text) which brings us to the next point…

Being a judge and having public whois info for recon challenges is a REALLY bad idea.

Why?

People like me might get desperate enough for a key were I might actually just look you up and call you for the key. (http://www.networksolutions.com/whois/results.jsp?domain=coderkevin.com)

Which I did and the call went something like this (sorry Kevin, I can’t imagine your pain):

Me: “Hello?”

Kevin: “Is this about the whois info?!”

Me: “Oh…no…but if it was about that and if you did know a key…would the first letter be A?”

Kevin: *laughs* Oh god people have been calling me all day *hangs up*

So naturally, as satisfying as this was I am clearly not aware of social bounds so I decided to text him.

 

As if this wasn’t bad _enough _Kevin also forgot (or was not aware of) EXIF data.

 

So that’s horrifying, considering that search EXIF data is the exact thing _that you’d have to do to find a key.

_

TL;DR – Kevin is probably changing his number and address relatively soon. Also internet points are serious business!

Funny False Flag-ery

So I personally enjoyed the effort that people would put into having false flags. I encountered a few (and placed a few), it’s really all part of the game with CTFs though.

Exibit A – Wikipedia getting bombarded:**

It would appear that for a brief time someone managed to add a false flag to the Wikipedia article “Odin”, which was removed shortly afterwords. This one made it through and I have no idea if many more were being done to other Wikipedia articles (if you know of some please post it!) I find it hilarious that people would suddenly be bombarded will crap additions to pages because of some random CTF competition.

Here’s an image of this:

Exibit B – Widget False Flagging

Initially while doing the “widget” challenge for CSAW I thought the idea was to get the key by viewing someone else’s widget. This seemed reasonable enough unti I actually did it.

Just no so much crap and derping in those widget fields – people running Acunetix and false flags to throw you off were everywhere.

Luckily enough if you _did _want to see those entries I have some of them saved in a very screwed up format here: http://thehackerblog.com/downloads/internet_culture_gone_wild.txt

Please notice fabulous entries such as:

• key{grep this bitch} (hehe, might've been me)

• "Please something" (I can taste the desperateness)

• howlongcanyouhandleinsideofyouhowlongcanyouhandleinsideofyouhowlongcanyouhandleinsideofyouhowlongcanyouhandleinsideofyouhowlongcanyouhandleinsideofyouhowlongcanyouhandleinsideofyouhowlongcanyouhandleinsideofyouhowlongcanyouhandleinsideofyouhowlongcanyouha (Apparently about that long)
  

• <script>alert("key{0ecb449efc3}")</script> (more false flagging)

• Widget: fuck Value: mygucciasswhole (HUNDREDS OF THESE, what the hell man?)

• Change this to the value you want tested (Some time of automated software?)

Their are plenty more but those were some of the funnier values I found.

CSAW Actively Scanning our Browsers for Vulnerabilities

How many of you noticed that? Seriously it’s like right in the source and it does it pretty often.

Basically in every CSAW CTF page they had the following:

<script src=”http://browserscan.rapid7.com/EM-209038687/1/0/1/0/collect.js”></script>

The browserscan.rapid7.com homepage looks like this:

Nothing to sketchy right? Here’s an example scan of my browser.

I really hope that this whole thing was just a way to hack a ton of CTF players but it really was probably more to gain lulzy statistics about players.

So that’s all I have for now but if I think of anything else funny I’ll add it – if you have anything funny to add please post it in the comments below!

This concludes the CSAW lulz writeup, I hope you learned something!

-mandatory

The “WidgetCorp” challenge for the 2013 CSAW CTF was a really neat web exploitation problem. It was a challenge where I was super excited to work through the whole thing (not always the case for sure!)

It’s a light blue because I solved it but you get the gist. No information/comments are provided about what to expect so you’re going in blind here.

Here is a picture of the homepage for this site:

Interesting, looks like a very well put together site eh?

On our main page once we’ve logged in we have options to:

• Check our widgets
• Make a new widget
• Check out the new feature (a link to the logout page, also an attempt at humor)

Great, so let’s make a widget!

 

Alright, looks good. Once we submit this page we get:

So we made a new widget with ID 7574 – let’s check it out now.

Great, so we have options to view/edit our newly created widget. Let’s view it:

As expected we have a page were we can view our widget details. The URL for this page looks like:

Obviously the id=7574 is showing that we are viewing a widget with the ID of 7574 (as we saw the website tell us earlier).

Now any good hacker would try to go to this URL next:

Which sadly yields us a:

Well, what were you expecting?

So they are checking if we own the widget before displaying the information. But how do they do that?

 

Cookies should always be checked during any sort of web auditing, they are often forgotten about or not coded securely.

Great so we have the following cookies:

• PHPSESSID, which is PHP’s way of doing cookies.
• widget_tracker, an interesting field which I immediately recognized as being a base64 encoded value
• widget_validate, some seemingly long string of characters (128 characters in length – nudge nudge)

Let’s checkout that widget_tracker value first shall we?

YToxOntpOjA7aTo3NTc0O30%3D

**So we decode the url encoded string:

YToxOntpOjA7aTo3NTc0O30==

Oh my, that double equal sign makes me smile every time! (Almost always means base64 encoding!)

Base64 decoding that value gives us:

a:1:{i:0;i:7574;}

What is that?! Did someone screw up JSON? Nope, actually it’s the PHP serialize function. I got it right away because I do far to much programming in PHP. Basically it’s like JSON encoding where you take an array and turn it into a string.

So let’s script this:

This will allow us to better understand what is going on.

Interesting, so we see it’s an array of the widgets we’ve created! So we can simply reverse this function to create a valid cookie value, bypassing the authentication.

Not done yet! What about that other value widget_validate?

Now this one I knew right away from experience that it was a SHA-1 hash (based off it’s length/character set, if you ever need to figure out a hash type see https://code.google.com/p/hash-identifier/)

But what is being hashed? My username? Our PHP session ID?

So I figured this out by simply monitoring the cookies being used. Hacking is really just like being a scientist…

So all I did was watch when the widget_validate cookie value changed, in this way I could see patterns and hopefully determine how they do their authorization.

So I had multiple theories of how they did it but I noticed basically that anytime I added a widget the cookie value would change (after I viewed the new widget).

In this way I knew that the widget_validate cookie was changing based on the widgets that I had created.

After a bit of testing I found that the value was simple a SHA-1 hash of the serialized widget array (a:1:{i:0;i:7574;}).

Great, now lets translate that into some code:

So this code will generate a valid cookie to view any widget that we want. Basically you call it with the wanted widget ID and a valid PHP session ID and it will auto-build the cookie for you.

So here is a simple function that gets any page I give it, this function also has the “generate_legit_cookies” function in it so it will auto make the appropriate cookies, etc.

 

I ended up make a script that views everyone’s widgets and outputs their values and that was a BIG mistake. So much script kiddy input values (people running Acunetix, automated tools).

Here’s a funny screenshot of that output:

So big mistake, luckily I screwed up my code at some point when I put in a null value for the ID and got an SQL error from the website.

So I got that as an output and it immediately clicked for me, we’re doing SQL injection via cookies. This is something I’ve always wanted to do (security nerds have different dreams I suppose).

Now, I did this manually step-by-step but I’m going to show a better method in this blog post. The better idea I had after I won is what I’ll continue with here because it’ll convey a good idea for future problems like this.

The idea I had was to simply make my script this:

 

So basically I made a PHP script that acts as a psuedo proxy for any SQL injection tool I want. I just tell my tool that the site I’m injection is http://127.0.0.1/widget_wut.php?id=1. That PHP script just returns the output from the http://128.238.66.224/widget_list.php I guess you would call this being a “hybrid script kiddy” because the PHP script simply does all the cookie crazyness for the SQL tool you’re using.

So here is the PHP script in action:

So hopefully this makes it more clear what I’m doing here but I’ll continue regardless (my brain is fried from constant CTF playing, maybe I’ll come back later and clean this up).

So after this I pointed sqlmap towards this local page:

My output:

So it’s working alright, let’s get the databases to ensure it’s all good:

Great everything works well, the next steps are pretty straightforward.

So hopefully this conveys everything that I’ve done correctly 😉 I’m pretty burned out so I’ll come back later and edit things that I screwed up.

-mandatory

So recently I was attempting to hack a friend’s server (with permission!) via a local file inclusion vulnerability and I discovered that nobody had any tutorials on hacking XAMPP servers via LFI.

Basically it’s pretty straightforward if they have FileZilla FTP Server enabled and working! In fact it should be trivial to exploit this in any currently running XAMPP server with an LFI vulnerability!

So before we start I’d like to point out that I found this out by simply copying the remote host’s installed programs on a VM of my own. This way I can get a good picture of what their server setup is and can more effectively exploit them. If you’re completely new to LFI exploitation in general here are some nifty tutorials/guides for you to read:

[http://www.blackhatlibrary.net/File_Inclusion

](http://www.blackhatlibrary.net/File_Inclusion) http://hakipedia.com/index.php/Local_File_Inclusion

It’s also worth mention that this type of LFI vector is not in the stock https://code.google.com/p/fimap/ tool’s libraries, so I don’t think this has been done much and that surprises me quite a bit! (Seems so simple!)

On too the meat of this post…

In order to demonstrate this attack I’ve prepared a Windows VM with XAMPP installed on it and configured FileZilla to have a usable Administrator account.

For the vulnerable application I simply search for “local file inclusion” on Exploit-DB. What’s nice about their website is that they host the actual vulnerable applications along with the exploits so that you can practice/verify an exploit for yourself!

I chose this result to be our target: http://www.exploit-db.com/exploits/21418/

Here’s a mirror from Google’s cache as Exploit-DB’s servers are often really slow: http://webcache.googleusercontent.com/search?q=cache:Z1tANS9wxQAJ:www.exploit-db.com/exploits/21418/+&cd=1&hl=en&ct=clnk&gl=us

Semi-ironically this software called “Manhali” is educational software for teaching, I suppose we’ll all learn something from this then!

As a reminder: The software that we’re using doesn’t matter here, the only thing that matters is that it has an exploitable LFI vulnerability that we can use.

 

Here is what the main website looks like once installed:

 

Now what’s nice about XAMPP is it comes stocked with your favorite programs for web server management, how convenient! Even cute icons for your control panel, who wouldn’t love this?

Moving on, if you have XAMPP installed you can see that the default directory that it’s installed in is “C:\xampp“. This is what the installer will put by default on all XAMPP installs.

You’ll also notice that FileZilla is located at “C:\xampp\FileZillaFTP“, and if you look in that directory you’ll notice that there is a configuration file for FileZilla called “FileZilla Server.xml“.

At this point I hope you know where I’m going with this but either way our next step is simply exploiting this LFI to read this configuration file for FileZilla!

It’ll look something like this:

Now let’s do this! (A reminder that you may need to append a null byte (%00) to get things working) Also this software simply forces you to download the file so it won’t be embedded in the webpage like most inclusion vulnerabilities.

What’s in this neat file you ask?

Settings, configurations, and more important MD5 hashed passwords for all the FTP accounts!

As you can see, near the <User Name=”Administrator”> we have a hash value. This is just a simple MD5 hash of the password for the Administrator’s FTP account! So you’ll have file system access in no time! You should also note that the options for “FileRead”, “FileWrite”, and “FileDelete” are all set to “1” (meaning true) so this user can do these actions.

One final step before we finish up here though, we need to crack the MD5 hash to get the plaintext password for logging in to the FTP server.

Before loading up any cracking programs – I find it’s easier to check a few online websites that offer MD5 “decrypting” for you. This basically means they have a large database of cleartext -> hash lists and they check if your hash is in their database. This worked in our test case but if you find a strong password is being used then you should use something like Rainbow Tables to crack them. (Check out this site if you’re going that route: https://www.freerainbowtables.com/tables/)

A simple submission to an MD5 “decrypting” website yielded us the password that we needed!

Somewhat ironically the password was “secure” the whole time! Use this along with the username “Administrator” to log in via FTP and start editing files as you wish! Keep in mind this might not always be the web root and you may have to mess around in order to find the URL path to the FTP directory. Perhaps some accounts aren’t for web editing etc, but simply look for any account that you can upload a web viewable file too. If done successfully you should be able to upload a shell/payload/etc to the server!

While their are some requirements to this method I’d imagine that this would be a very common setup for XAMPP users. You should also note that their are many other useful files in the XAMPP folder that you could read and use to your advantage. I would always recommend setting up a test environment on an offline system before preforming the actually attack so you’re prepared and don’t cause unnecessary noise on your target system!

As always thanks for reading and happy hacking!

-mandat0ry

So I had an interesting idea when a friend of mine asked what a hacker could use a botnet for.

I gave the casual responses like using bots for DDOS attacks, Bitcoin mining, and perhaps ad impressions. Basically anything that a computer can do without human interaction a botnet can do on a larger scale.

But then I thought what if a hacker used the human part of the botnet to complete his work? What if the hacker needed humans to complete his diabolical plan? Could you really use humans to power your botnet?

I’d say you could, and what is one thing humans beat computers at?

Of course the answer would be CAPTCHAs, a system designed purely to stop spam bots from abusing services across the internet. 

 

Obligatory XKCD Comic

Image from http://xkcd.com/632/

 

It’s really a genius system when you think about it, but if you’re not aware this is how it works in simplistic terms:

reCAPTCHA is a free CAPTCHA service that helps to digitize books, newspapers and old time radio shows.

Source: http://www.google.com/recaptcha/learnmore

So basically Google has scanned images of book pages that need to be turned into plain text. The best OCR out their cannot do it so they need humans to do it for them. But that’s expensive, and in a very innovative solution they now use sections of these book pages to use as an anti bot system. So in return for blocking automated bots from abusing people’s services, Google gets endless free human OCR.

Sweet deal huh?

So sweet that services have emerged to solve these CAPTCHAs cheaply for people who run spam/bot services that need to bypass these CAPTCHAs.

This is a CAPTCHA solving service that charges low rates to get these roadblocks solved for anyone with Paypal, Credit/Debit Cards, or many other payment gateways.

How do they do it? Cheap labor, and lots of it! They even force you to pay more at certain hours when their workers will be normally asleep so that they can attract more people to the night shift.

We rely on a workforce that is mostly located in South Asia and South-East Asia. The Nighshift Worker Compensation is intended to increase the amount of workers online during their nighttime, thus, increasing the overall capacity of the service. Please read here for more information.

Source: http://deathbycaptcha.com/user/faq

Not only that but they offer the service pretty cheaply, just take a look at their rates! Have 5,000 CAPTCHAs solved for only $6.95!

But I’m getting a little off topic here, the point is, humans are a much needed commodity in today’s shifty digital market. CAPTCHAs need to be solved and their are many people willing to pay money to have them solved.

So, the idea came to me that it shouldn’t be to hard to build a botnet that forces people to solve CAPTCHAs for you. Some malware convinces people to buy MoneyPak cards in order to get their computer working again so perhaps that sort of strategy could be used? But what would be a _believable _scenario where somebody would be forced to solve a CAPTCHA image?

I remember back to a crazy incident where Comcast (an ISP) started injecting Javascript into pages over HTTP. This is horrific for so many reasons but it’s completely true.

Not only were they injecting Javascript but they were doing it with poorly made Javascript which would no doubt break many pages that it was injected into. So we know that an ISP or two is willing to do dirty things such as this so why wouldn’t they also force people to verify that they’re human and not abusing Comcast’s precious internet service?

Meet the Comcast Anti Abuse Service:

After some (very bad) coding in Visual Basic I made a slick proof of concept on what a CAPTCHA botnet would look like (or what I imagined it to be). This malware is not very advanced and you could easily kill it if you wanted to, the real thing I’d imagine could detect your ISP and serve up logos/messages accordingly. It’d be even better if it could detect if you were using a web browser and only popup then – or better yet disable your browser until you enter in a CAPTCHA image.

Disclaimers:

• This was not made to be ACTUAL malware, DO NOT message me and tell me it’s poorly made. I am aware, it was NOT designed to be actually used – the control panel is actually vulnerable to tons of exploitation. I am OK with this because if someone actually decides to use this software I hope that they do get hacked (no offense, but I hate removing this type of malware off of my relatives computers!)
  
• The use of the Comcast Logo is protected under the Fair Use clause stating “the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;”. The ideas represented fictionally here are not those of the Comcast company as a whole. If their are any issues feel free to contact me at mandatory (at) gmail dot com. Thank you.

Even though I’ll probably regret it, I’m making the full source downloadable in case anyone wants to see more of how it works.

Click Here to Download the Full Source

To close, I’m sure there are many other ways hackers could utilize humans for their “humanity” via botnets and I think it’s an exciting area to explore.

What other problems could be solved by mass use of human labor? Not necessarily unethically with an illegal botnet but with legal ones as well?

-mandat0ry

 

 

Something that I’ve been really interested in is sub domain brute forcing, but what is it any why does it matter?

So, where to start? Let’s tell the story of a company system administrator and his journey.

So Bob (the sysadmin for a very important tech company) is put in charge of managing the DNS servers for H.U.E Inc among other things.

(For this story we’ll be using a 127.x.x.x format but we’ll pretend that these aren’t all loopback IP addresses)

Bob starts off by registering the domain name www.hueinc.com and points it to a server that hosts the company’s main website. So now whenever people go to www.hueinc.com it directs them to their web-server that serves up some static website detailing what the company is all about. We’ll say the IP address of this server is 127.0.2.1 just for example’s sake.

So, for those keeping track at home:

Great, but soon Bob is contacted by the developer department for H.U.E and they want a sub domain for their FTP server they setup. Easy enough, we’ll just set it to something easy to remember – after all this is what domains are for right? Bob decides that “ftp.hueinc.com” and “files.hueinc.com” seems like pretty easy-to-remember domains and set’s them to point twords the FTP server at the IP “127.0.2.8”.</p>

Cool, so now the company’s domain map looks like this:

Bob is now very confident with his ability to assign sub domains to things and starts assigning every department their own sub domains to make everything easier to use. He even sets up personal sub domains so he doesn’t have to remember all the annoying IP addresses of the server’s that he sometimes manages. The cPanel page that he uses to manage everything? Why that’s “cpanel.hueinc.com” of course! The company’s employee login page? “employees.hueinc.com”. The IP cameras for the building? “surveillance.hueinc.com”. The toaster in the lounge that tweets when bread is full toasted? “toasted.hueinc.com”!

Bob is very excited about how much easier he has made things!

So lets see, what’s the map look like now?

Etc, etc.

Wow, Bob certainly has been busy, what could possible go wrong here?

Meet Mike, he’s a Red Bull powered, not-so-ethical, insomniac. To top it all off he’s quite the computer security enthusiast and spends his time hacking at networks that he’s found an interest in. Sadly that system today turns out to be H.U.E. Inc.’s network.

Mike does a quick Whois on the domain name “hueinc.com” to start with and finds Bob’s contact details and the company’s phone number. Neat, so his opponent today is named Bob – let the games begin!

Mike now wants to know if they have any other systems than this static web server that shows the company’s details. After all, he is doubtful that he will have any luck hacking this server as most of the pages are just HTML files.

Perhaps this admin is new and has global DNS zone transfers enabled?

__A quick visit to https://tools.digitalpoint.com/zone-transfer and he discovers that they do not have global zone transfers allowed. (Mike prefers using this website as it won’t show his IP address for the query) A quick Google search reveals that only the company’s main website is indexed.

Oh well, I guess we’re doing this the fun way then!

Mike loads up one of his favorite tools for this type of thing called “DNS Discovery“. He loves this tool because it’s multi-threaded and can be installed on many embed devices because of it being written completely in C.

He has a word list for sub domains that he’s been building up overtime and is quite happy with it, the game of profiling administrators is something he enjoys very much.

The interface for this tool looks something like this:

He lets the tool run it’s course, he finds that Bob is quite the sub domain wizard and has assigned quite a few sub domains to systems that should not be touched by people who aren’t employees!

Mike’s map of H.U.E. Inc. now looks something like this:

His picture isn’t a very complete one but it reveals quite a few domains that he’s interested in.

Ah, sweet! Jackpot!

Mike isn’t quite done yet with his assessment yet however.

fire.hueinc.com? Does that mean the other “elements” are included as well?

Mike checks for “water.hueinc.com” and finds nothing, he then tries “earth.hueinc.com” and finds Bob’s other server as well!

Mike finds that many other sub domains all follow this sort of scheme, he discovers the “hercules.hueinc.com” sub domain as well and quickly scrapes a list of all of the greek gods for his word list. Sure enough, he enumerates ten more sub domains this way! He also now has an idea of some IP ranges the company might own and checks neighboring IPs for more systems. He finds a few more this way as well!

Mike has gone from having one static web server to attack to having tons of machines that he can mess with. Some of these systems were thought to be private and they probably haven’t been patched against the latest exploits.

What do _you _think Mike’s chances of success are now?

Is Bob and Mike’s story a unique one? This is probably not a common thing…right?

Sadly this isn’t a unique scenario at all, many (if not the majority) of system administrators will act exactly like Bob did. It isn’t that Bob didn’t know about the possibility of sub domain brute forcing but more that he never considered that anyone who do this. Heck, Bob even found the task of coming up with new sub domain names a fun job!

To close, here is a screenshot of this tool running against Cisco’s main domain name Cisco.com for five seconds (if this doesn’t get you a little freaked out I don’t know what would):

 

That’s a LOT of sub domains, I don’t even want to know what a full “scan” would yield…

EDIT: Just to clarify I’m not saying that companies shouldn’t use sub domains. My point was that this would be an effective way to enumerate systems that are scattered across different hosts (which is very possible, maybe you outsource you FTP etc.) A better point would be to just be cautious of how sub domains are assigned and not to depend on the obscurity of a system for security. This is well pointed out with the Cisco sub domains as many of those domains are _not _supposed to be globally accessible. I was hoping this post would get a few people to think about just what kinds of systems they consider “secret” that could be enumerated and attacked like this. Thanks for all the constructive comments so far – I believe I’ve fixed any errors in the post as pointed out by readers!

JUST FOR THE RECORD: I’m not endorsing the hacking of any of Cisco’s systems, I am merely pointing out the fact that this type of a thing happens all the time in real world networks. Cisco sadly has had a bad record when it comes to naming domains (they were vulnerable to zone-transfers for quite a while!). Please don’t attack any systems that do not belong to you! Jail time is not worth the adrenaline boost. Nuff said?