Xavier's Security Post

Developers and Disclosure -UPDATE

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?

¶ 10/02/2006 12:51:00 PM 0 comments

Deception within Obfuscation

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

¶ 9/12/2006 08:45:00 AM 0 comments

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

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.

¶ 7/29/2006 07:33:00 AM 0 comments

Rocks Clusters <=4.1 local root

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

¶ 7/14/2006 12:40:00 PM 1 comments

Your Space, My Flash, His Cookies

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

¶ 6/05/2006 06:11:00 PM 0 comments

Security through Compression...?

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?

¶ 5/14/2006 12:15:00 AM 0 comments

Google/Sony promotional game source code

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.

¶ 5/10/2006 02:04:00 PM 2 comments