Paid Advertising
web application security lab

Archive for July, 2006

Fake Google Toolbar

Monday, July 31st, 2006

Well, it was just a matter of time, but there are finally some reports of a fake google toolbar executable that hides a trojan horse.  Great!  Well, I always knew it would happen, and I’ve been warning people for ages,  “If you put executables on your webpage, it’s just a matter of time before the phishers do the same thing.”  Thankfully the barrier to entry in building executables is still fairly high, making this a fairly small attack vector, but used in combination with hacking a big DNS could be huge.  Think about what a fake Microsoft Windows Update could do in terms of numbers!

This probably falls into the Pharming category rather than Phishing, as it doesn’t actually intend to directly compromise you by asking you for information, but it does try to get you to download something based on a brand that you are supposed to trust.  To my knowledge this is the first time this has ever happened.  But getting someone to install this toolbar could lead to information loss, but also to more phishing, because the anti-phishing built into the Google Toolbar will obviously be turned off.  Pretty nasty.  Executables are pretty nasty.

I’m still waiting for a day when there will be a single signing authority for executables so you can know what is real and what isn’t.  Google Toolbars should be signed by a central authority, and your machine shouldn’t even let you download it unless you know where it comes from and can verify that.  That might be a pipe dream, and that would kill a lot of the little guys, but if it at least warned you that it wasn’t signed that might give people a clue that it wasn’t Google.  Either that or they’d just click through.  This is frustrating, because there isn’t really a good answer, other than better detection of fraudulent websites claiming to be big brands.

Expect Header Injection Via Flash

Monday, July 31st, 2006

I probably didn’t go into enough detail the last time I talked about Amit Klein’s header injection vulnerability he disclosed with Flash. Blad3 brought my attention to this tool over at secunia that allows you to test sites for JavaScript injection via Expect headers. (I had better luck with Internet Explorer using that tool than I did with Firefox). But what it shows is that a huge chunk of major websites are now vulnerable to this. Without naming all of them, just trust me, it’s a lot.

The ramifications for this are huge. Being able to run any JavaScript you want one just about any website has some very serious issues. Of course you still need to get the user to view your Flash movie, so this has no added security issues if you always know where you are clicking, and the website itself has no cross site scripting vulnerabilities. However, if the site has XSS holes, or you are directed off site, suddenly all of your information is now able to be leaked via XML over RPC. If you happened to be logged into a major website that has the Expect issue flaw, your cookies can be stolen, any page that you have access to can be scraped. You can be used as a tool to launch XSS proxy attacks. This definitely goes into the JavaScript Malware bucket.

This is huge folks. Not just big, but huge. There’s no way of knowing exactly how many sites are vulnerable, but I’m going to go out on a limb here, and say a huge chunk of them will be until patches are issued.

Special thanks to Blad3 for making me re-visit this.

Popup Blocking

Sunday, July 30th, 2006

I ran across an interesting link to a page that tests your browser for popups. It requires that you run Java. I was actually a little bummed that not a single popup went through on my browser. But then again, I run QuickJava (similar in principle to Noscript, but better for my needs) so it’s not that big of a surprise.

But it got me thinking.  This really only tests conventional popups.  It certainly doesn’t test for things like my Most Evil Popup Ever(TM). Frankly, I wouldn’t expect it to, because it isn’t a normal popup, but as technology evolves, I think less and less conventional means for delivery is going to take over.  I feel like there are probably other forms of these types of popups that could work better, but I haven’t put any time into thinking through it, so it’s probably best to leave it at this.  Anyway, cute link if you aren’t sure how vulnerable you are to popup annoyances.

Made it to the Front Page of Slashdot, and Survived

Sunday, July 30th, 2006

Today, Slashdot ran an article on the JavaScript Malware that Jeremiah Grossman will be discussing in his talk at Blackhat next week. The page links to a news.com.com article that talks through the cross site scripting ideas. A few days ago Billy Hoffman of SPI Dynamics published a link that has a very simple prototype of the JavaScript malwar port scanner. Although this is really only one part of the attack, it does give you a sneak peek at what will be discussed.

Well, it might be too early to say this, but we managed to survive the front page of Slashdot.org. Thankfully the slashdot effect was mitigated by the fact that it’s a Sunday morning, we weren’t the main link on the page, and it wasn’t linking to one of the PHP files, because I doubt we could have handled that kind of load.

Quite an honor though! My girlfriend asked me, “Did you ever think you’d be on the main page of Slashdot?” I had to honestly say, “Not unless I hacked it and put myself up there.”

New Hands-On Cross Site Scripting Training Podcast

Saturday, July 29th, 2006

Dan Kuykendall over at Mightyseek just put out his second cross site scripting (XSS) podcast.  Honestly, I think this time around he is doing a much better job explaining, not just how it works, but some of the details around filter evasion.  He actually sets up a hackme type server with a few examples that show how to evade them.

Additionally he plugs the cross site scripting cheat sheet (no, he wasn’t paid for the plug).  As dynamic website technology advances, and there are more unique forms of filters in the world, this is going to be more and more imperative over time.  Anyway, if you are new to XSS, Dan’s podcast is worth a listen.  It’s definitely not designed for the web application security professional, but rather, it’s a simple tutorial.  Hopefully this sort of thing will continue, because as the web grows, XSS, and all forms of web application security will become a bigger issue.

Yahoo Redirection Used in Phishing Email

Saturday, July 29th, 2006

Today, I got a phishing email using a Yahoo redirection. People who claim redirection isn’t a problem read on. Indeed, the URL also uses Dword encoding to further make the URL obfuscated. Here’s the URL:

Notice the Dword there? 1115019674 That translates to 66.117.217.154:

OrgName: Fuse Internet Access
OrgID: FIAI
Address: 209 W. Seventh St.
Address: MS 121-550
City: Cincinnati
StateProv: OH
PostalCode: 45202
Country: US

How someone could ever figure out what that URL was without clicking on it who wasn’t already familiar with phishing schemes, I’ll never know. Phishing is partly social engineering, and my trust in Yahoo is what makes me think, “Sure, I believe that Yahoo could theoretically have some arrangement with other companies to redirect traffic.” The fact that mega companies with known brands have these holes makes this a big problem.

Some Security Questions Answered

Saturday, July 29th, 2006

I got an email today with a few good security related questions so I decided to post the answers as other people may be interested:

Two questions:
1. If someone is hotlinking an image, is there a way to change the htacess to serve them a file that will embed links in their site?

2. How important is not having 777 CHMOD for security?

To the first, question, it depends completely on how they are linking to you. If they are using an iframe to show the image, absolutely. If they are simply using an IMG SRC tag, you are pretty out of luck. I’ve experimented with all sorts of redirection techniques but have come up dry. The best I’ve come up with is making it redirect to a mailto: tag, which will launch the user’s mail client, which can embed text (HTML, I’m afraid is not really an option there). You can do the same thing with the skype: directive if they have Skype installed, or scp: directive if they have WinSCP installed (there’s actually a known exploit in WinSCP if you wanted to install malware). Another option is to have it link to an RFC1918 (non routeable) address space to perform a function. Something like http://192.168.0.1/firewallsettings/makemeinsecure (this would only work if they were already logged in, the IP address was correct, and they had the correct type of router/firewall for whatever function we are talking about). Note that you can probably figure out the firewall/router that they are using since they are connecting to your machine and you’ll have their IP address by which to do recon. I don’t recommend doing any of this stuff, because they’ll know it’s you and you’ll probably end up in jail, but it can be done in theory.

To the second question, 777 really isn’t that important if you are pretty sure there are no other vulnerabilities in your system and you don’t have multiple (untrusted) users on your system. If your system creates files of a name based on arbitrary user input, 777 could cause a problem because they can name it .php and because it is 777 instead of 666 it will actually run. That’s partly how Apache.org got hacked. If you have untrusted users on your system and you have 777 they can write, run or erase the file. If the file is owned by the www user and they have www user access, that’s sorta a moot point, but it could be a problem where they don’t have www user or CGI access and you otherwise wouldn’t want them to access/edit/erase those files. Really 660 should be used for read/write access on multi-user systems, or 770 for executables, if you wanted to be super anal about it. I’ve only seen one system that was hacked because of this, ever. So it’s not really that big of a deal.

Lan-Aces Warning

Friday, July 28th, 2006

I almost laughed when I saw this vulnerability alert. The company who owns Lan-Aces Office Logic (which I’ve never even heard of, so I don’t think this is a wide spread security vulnerability) has 24 hours to make contact with Mike@chtechnology.com before he releases what appears to be some sort of script injection (sounds like XSS running on the machine, so it has access to the drive).

Of course this is a theory, and the details are vague, but as of tomorrow he’ll release his code to the world. Here’s his post:

Does anyone use this email client? I have to say It would be in your best intrest to turn off html messages until I speak with tech support at Lan-Aces. If they do not respond within 24 hours I will post a huge security bypass exploit that works for all html & scripting blocking mechanisim. With this said….

These types of vulnerabilies are really nasty, but given that I’ve never even heard of the mail client, I doubt it’s that bad. If you’re running Lan-Aces Office Logic, or know someone who is, let them know.

Cross Domain Leakage With Image Size

Friday, July 28th, 2006

A few days ago I posted about how to control cross site scripting remotely.  This is a pretty powerful tool in the web application security toolkit - specifically for attackers attempting to mount remote attacks.  I did fail to mention one thing about this.  But let me start from the beginning.  Once upon a time, I was trying to get Gerv to implement content restrictions and additionally dynamically resizing iframes based on the embedded content.  Both had their uses for isolating user information in another domain or at minimum restricting what they can do in the realm of the page they are residing on.  The bug had issues going through as it is deemed a security issue to know the state of a user on another site via cross site request forgeries.

Then I started thinking about how my own image controlled XSS worked.  Because I now know the size of an image hosted remotely, I could also potentially know the state of the user.  Picture a dynamic image that, based on user state, changed it’s actual size.  It’s a fairly tricky thing to do, and very rare, but I have seen it before, “Hello, user!” verses “Hello, RSnake!” which is dynamically generated to suit the user.

There is another application that I haven’t figured out a good use for, but via things like PHP easter eggs, Apache default icons, etc… you can actually fingerprint the machine remotely.  I don’t see what value this has, particularly, unless you are using the XSS proxy idea and you really never want to touch the machine in question at all.

Another alternative is that the image is either there or not there based on the user’s state (members area directing them to a login screen which will prompt a JavaScript error that you can trap).  Again, all of these conditions may be rare, but it points to the ability to use a remote image to not only control remote cross site scripting vectors, but to also know the state of users on remote websites via CSRF.  Scary!

Don’t Search Here

Friday, July 28th, 2006

Over the last few weeks I’ve found a number of different articles talking about how search engines are basically saying “Don’t search here, go elsewhere for better results.”  One of the best ones is the Yahoo embedded in Google thread at Threadwatch.  There’s another one that Phaithful sent me talking about Wikipedia being the new DMOZ. (In case you don’t know what DMOZ is, it’s basically the largest human indexed directory on earth, and all major search engines use it).  In the search engine optimization world, this is pretty critical to knowing where to place your content so it gets the highest listings possible.

This might be a bit of a rant, but, I’m really getting sick of all the Wikipedia talk.  I understand it’s purpose, but it really has a lot of flaws (namely, you have no idea who wrote it, it is biased, and it can change at any time with no obvious revision history).  Schools have begun to say “you cannot cite Wikipedia as a source”.  Lately, I have noticed more and more that searh engines are putting Wikipedia at the top of their SERPs (Search Engine Results Page).  Are they trying to say to me, as a consumer, “Don’t bother searching here.  Use Wikipedia instead.”  Effectively they are telling me that Wikipedia’s links are more reliable and interesting than the search engines themselves.

So the next question is how long will it be before Wikipedia is either bought by a search company, or devolves into a link farm controlled by blackhat SEO folks.  Oh well, maybe I’ll ask Wikipedia, next time I need to look something up.  At least it will save me a click.  Sorry for the rant.