Xavier's Security Post
Saturday, July 29, 2006
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;
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.
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
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 withinNot 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
Friday, July 14, 2006
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
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