Thoughts on the .wmf 0-day and uses for mischief 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.  ¶ 12/30/2005 12:11:00 AM 0 comments

  Last words on that MySpace worm (GodOfTheNoose) 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.  ¶ 12/19/2005 10:29:00 PM 0 comments

  Cross Data Domain crossdomain.xml misconfigurations 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

  ¶ 12/19/2005 12:56:00 PM 0 comments

  New MySpace XSS worm circulating. [UPDATED] 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.  ¶ 12/18/2005 12:10:00 AM 0 comments

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

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.  ¶ 12/15/2005 07:37:00 AM 0 comments

  errata of statistics 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.  ¶ 12/09/2005 07:33:00 PM 0 comments

  phpMyAdmin <=phpMyAdmin 2.7.0(-rc1) $GLOBALS overwrite 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 -____-  ¶ 12/07/2005 06:04:00 AM 0 comments

  serious vTiger <=4.2 flaws 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.  ¶ 12/06/2005 09:47:00 PM 0 comments

  .php.any file extention PHP execution 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!

  ¶ 12/06/2005 01:53:00 AM 0 comments