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!)

Selection_002

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:

Very pretty, almost 10 minutes of CSS work in there

Very pretty, almost 10 minutes of CSS work in there

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

Selection_005

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!

Selection_006

 

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

Selection_007

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

Selection_008

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

Selection_009

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

Selection_010

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:

Selection_011

Which sadly yields us a:

Selection_012

Well, what were you expecting?

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

Selection_017

 

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:

Selection_019

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

Selection_020

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…

Looks like concentrated science!

Looks like concentrated science!

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.

Selection_022

Tedious but yields results!

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:

Selection_023

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.

Selection_024

 

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:

Selection_029

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.

Selection_026

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:

Selection_030

 

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:

Selection_032

Selection_031

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:

Selection_033

My output:

Selection_034

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

Selection_036

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

Selection_040

Selection_043

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.

exploitdb_exploit_picture

Note the “Vulnerable App” section where you can download this software to test for yourself!

 

Here is what the main website looks like once installed:

Something about this site just seems so...exploitable? Maybe it's the design, but that's besides the point!

Something about this site just seems so…exploitable…

 

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?

xamppcontrolpanel

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:

manhali_url_with_website

Yes I do have more addons than most sane people

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.

A download? For me?! You shouldn't have!

A download? For me?! You shouldn’t have!

What’s in this neat file you ask?

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

gedit_filezilla config

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!

md5_decryptor

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.

Indian Labor Zone

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:

Hard to believe I'm not a graphic designer huh?

Hard to believe I’m not a graphic designer huh?

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:

DOMAIN IP
www.hueinc.com 127.0.2.1
hueinc.com 127.0.2.1

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:

DOMAIN IP
www.hueinc.com 127.0.2.1
hueinc.com 127.0.2.1
ftp.hueinc.com 127.0.2.8
files.hueinc.com 127.0.2.8

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?

DOMAIN IP
www.hueinc.com 127.0.2.1
hueinc.com 127.0.2.1
ftp.hueinc.com 127.0.2.8
files.hueinc.com 127.0.2.8
cpanel.hueinc.com 127.0.3.1
employees.hueinc.com 127.0.3.2
surveillance.hueinc.com 127.0.3.3
toasted.hueinc.com 127.0.2.9
secret.hueinc.com 127.1.3.1
earth.hueinc.com 127.2.1.2
fire.hueinc.com 127.2.1.3
hercules.hueinc.com 127.3.2.1

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:

Obscurity is never the answer.

Obscurity is never the answer.

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:

DOMAIN IP
www.hueinc.com 127.0.2.1
hueinc.com 127.0.2.1
ftp.hueinc.com 127.0.2.8
files.hueinc.com 127.0.2.8
cpanel.hueinc.com 127.0.3.1
employees.hueinc.com 127.0.3.2
secret.hueinc.com 127.1.3.1
fire.hueinc.com 127.2.1.3
hercules.hueinc.com 127.8.2.2

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):

Cisco is the king of subdomains

Cisco is the king of subdomains

 

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?

After reading this news article by The Register:

http://www.theregister.co.uk/2013/02/02/twitter_breach_leaks_user_data/

I had a thought about how often this is starting to happen – often dumps are released to the public via torrents or other downloads.

See: http://www.huffingtonpost.com/2012/06/07/linkedin-password-hack-check_n_1577184.html

We’re not talking about a small number of passwords here either – that’s 6.5 million accounts, were you one of these users?

Now, to the hackers these accounts probably didn’t mean anything because they have no association with these people. But perhaps YOU know someone on this list?

More importantly maybe you know someone who was on this list perhaps?

Before I continue, if you’d like to check if your account has ever been dumped as part of a large hack – you can check here (or if you want to see if your victims/friends has had this fate): https://pwnedlist.com/

Hmm, I wonder if my friends have been hacked?

Pwned by Pwnedlist?

Moving on, it’s very possible that you or someone you know has had their password leaked in hash form (god forbid cleartext form!). If you’re like most human beings you reuse passwords all over the net and if someone took the time to crack your password hash on the dumped site then they may have a valid password for your other sites!

So this opens up a whole new level of cracking. Anyone could simple take your email and put it into Pwnedlist and check to see if it was leaked at some point. If it was it’d be just a simple derivation of what sites have had leaks compared against sites that the target uses. Chances are the password is reused in many other places across the web!

Even if your target/you haven’t been apart of a dump yet it would be trivial to write a script to check daily for this type of thing. (You can’t use their internal monitoring service because it asks you to verify emails in order to do that.)

Bam, easy (and not to technical) hacking!

Till next time,

-mandat0ry