Network News

X My Profile
View More Activity

Internet Explorer and Your Web Site's Privacy

Several months ago, Security Fix looked at a feature of Microsoft's Internet Explorer 6 Web browser that was difficult to fathom (see: Clipboard Data Theft Optional in IE7). While interviewing a source at the DEF CON hacker conference last week, I encountered another such "what-were-they-thinking" feature in Windows, which can occur when someone uses IE to initiate an FTP (File Transfer Protocol) connection to a Web site.

Web site administrators typically use FTP to move files from their computer up to their Web site, and vice versa. Most people probably use more full-featured, third-party FTP software to do this, but Microsoft Windows also includes its own built-in FTP functionality.

The problem is that if you FTP to your target site, open a Web page file (one that ends in ".html" for example) in IE6 and then save that file onto your computer, the browser will embed your FTP user name and password into the saved file. If you are unaware of this feature, and happen to later e-mail or otherwise share that saved file with anyone else, you will also give them the credentials they would need to add, modify or remove content on your Web site.

Don't take my word for it. If you're still using IE6 and administer a Web site, fire up FTP on Windows. To do this, open IE and type ftp:// in place of http://. After that, provide the user name for an FTP account that you have permission to modify (e.g., ftp://myusername@mywebsite.com). IE will then prompt you to enter your password, and after a successful login it will drop you into your Web site's main directory. Open a file in the FTP directory that ends in HTM, HTML or MHT, and then save it to your computer. Now, open the saved file in any Web browser and select "View," and then "View Source." Your credentials should be listed at the top of the source file.

The DEF CON attendee who showed me this bug -- a guy named Alex who runs security for a Midwestern brokerage firm -- said he first alerted Microsoft to this rather obvious problem in 2004. Microsoft's response, sent to Alex via e-mail, was that fixing it would require a "rearchitecture" of the feature, something Redmond typically would not attempt in one of its monthly security bulletins.

"Essentially, IE is designed to support FTP for convenience, but not to be a full-featured FTP client, which is why we include a separate FTP client in the operating system," wrote Christopher, a researcher with the Microsoft Security Response Center. "The reason IE includes the user name and password in saved files is because they are part of the URL. IE saves the URL in downloaded files so it can run them in an appropriate security zone at a later time, even though they are now located on the local system."

So, if Microsoft wouldn't fix this feature in a security bulletin, surely it would remedy it in a full rewrite of the browser, with the release of IE7, right?

Not quite. Trying to use the FTP functionality in IE7 was something of an annoying experience, as the browser kept refusing to serve certain pages after I connected to my FTP site. At first, it appeared Microsoft had indeed nixed this feature in IE7. However, if you select "View" from the menu tab (if you don't see the View menu in IE7, hit the "Alt" key), you should see the option "Open FTP Site in Windows Explorer." Web page files opened and saved from an FTP site using this method also contain the user's FTP login credentials.

What makes this a big deal? Consider the following. Let's say you use IE to pull down a few HTML files off of your Web site. After viewing the file in IE and making a couple of changes, you save the document and FTP it back to your site. Congratulations. If anyone viewing that page or document happens to check the source, they will then have the user name and password needed to control your Web server.

Update, Aug. 13, 3:32 p.m.
: Vulnerability watcher Secunia has posted an advisory about this issue, which credits Security Fix as the source.

By Brian Krebs  |  August 7, 2007; 1:30 PM ET
Categories:  From the Bunker , Latest Warnings , Safety Tips  
Save & Share:  Send E-mail   Facebook   Twitter   Digg   Yahoo Buzz   Del.icio.us   StumbleUpon   Technorati   Google Buzz   Previous: Citing Security Concerns, California Limits E-Voting
Next: Watch Out for Fake Tax 'Rebate' Sites

Comments

Despite the MS Rep's offering up of an alternate 'built-in' FTP solution, the blatant lack of concern in his response is absurd and tantamount to a shrugging of the shoulders. I guess that one person's convenient feature will be the nightmare of many a casual/inexperienced web page editor. Vista and IE7 are MS's answer to a more secure online life? Bah!

As always, review your site's code. And if you don't have the technical expertise, hire somebody to audit your site for such easy-to-exploit holes. Now, if only we could get site coders to remove hard-coded database access scripting lines from live pages....

Posted by: C.B. | August 7, 2007 2:07 PM | Report abuse

There are serious security implications which arise from using FTP to communicate with your server, since the FTP protocol sends the name and password across the net in plain text, ready for anyone with a subverted router to steal simply by capturing packets. Much better to disable FTP at the server end, and insist on uploads over something like SSH, or over a CMS which authenticates over SSL so the eavesdroppers can't hijack your password.

Posted by: Douglas Spencer | August 7, 2007 5:27 PM | Report abuse

Unfortunately, the Adobe morons behind Dreamweaver didn't support SSL for WebDAV shares for a long time. (I think they finally started supporting SSL in recent versions, though I'm not certain.) This stupidity impaired migration of site management to stronger protocols.

Posted by: antibozo | August 7, 2007 6:28 PM | Report abuse

In 2004, most people probably saw this as a usability feature. Now it is seen as a security design flaw. It's interesting what a few years does to perceptions.

Posted by: Beau | August 7, 2007 7:18 PM | Report abuse

Beau> In 2004, most people probably saw this as a usability feature.

I don't see how putting a username and password in a downloaded file improves usability. Please explain...?

Posted by: antibozo | August 7, 2007 7:49 PM | Report abuse

Keep looking, you'll find many "what were they thinking" issues from Microsoft.

You probably don't remember the issue from a few years ago whereby when you used MS-IE to connect to a password protected website the first password that MS-IE automatically sent (without user knowledge or consent) was your local PC user+pass.

Microsoft still does not really "get" the Internet. Check out the current discussions at Webmaster World on how to take over the URLs on someone else's MS-IIS web server.

Posted by: Anonymous | August 8, 2007 11:07 AM | Report abuse

One way to get around this is to make an Explorer shortcut to create an FTP shortcut. Right-click on desktop, New, shortcut, type in:

explorer.exe ftp://ftp.whatzis.com

then finish. Doubleclick shortcut, File -> Login As, enter name/password.

As for Windows having an FTP client, not a lot of people are cool with command line programs, Microsoft.

Posted by: Snorty | August 8, 2007 1:34 PM | Report abuse

owned

Posted by: f1re | August 10, 2007 12:41 PM | Report abuse

Firefox is also affected by this flaw

Posted by: fgf | August 10, 2007 1:31 PM | Report abuse

*sigh* I guess stuff like WinSFTP still is not in the main stream... Hell it makes it so a brain dead monkey can use SSH to transfer files but still have a GUI to baby their way through... Its just point, then click... pint... then click... *sigh* C'est la vie....

Posted by: logic | August 10, 2007 1:36 PM | Report abuse

My bad, its WinSCP, not WinSFTP.

Posted by: logic | August 10, 2007 1:37 PM | Report abuse

Their command line FTP client is full featured? Really, did they really mean to say that? Is it actually their position that they would expect users who are using FTP to use their command line version?

Are there other network related applications that Microsoft ships where they have the stance that the GUI version is not the preferred version and has known 'security limitations'?

Sorry, their excuses sound rather lame.

I do believe when they say that the issue was a design decision (as opposed to a surprise bug), unfortunately it has security implications, and that poor decision was never revisited.

DA

Posted by: DA | August 10, 2007 2:29 PM | Report abuse

fgf> Firefox is also affected by this flaw

Uh, no it isn't.

Unless, by "affected" you mean "Smart people will stop using IE and use Firefox more, thus affecting its market share."

Posted by: antibozo | August 10, 2007 2:29 PM | Report abuse

to fgf -- antibozo is correct. Firefox is absolutely NOT affected by this. this is MS Windows specific, by-design behavior.

Posted by: Bk | August 10, 2007 4:41 PM | Report abuse

easy fixed

use scp over ssh

enuf sed

Posted by: nikon | August 12, 2007 9:50 AM | Report abuse

@Douglas Spencer: that's why we have SFTP.
@Beau: No, they saw it as a blooper. If M$ saw it as usability they're toast.
@Snorty: Another way would be to not use IE or Windows. That's another 'what were they thinking'.
@fgf: so this is in the FTP layer itself? How terrible.

Posted by: Rick | August 12, 2007 2:37 PM | Report abuse

(Disclosure: I did consult for Microsoft on Vista, but I'm also one of the Black Hat speakers, which is partially why I got called in to do so.)

So. Not too many people are crueler to protocols than I am, but FTP deserves a bit of slack here.

If you download a random file from a FTP share, this doesn't happen.

You have to specifically acquire a web page over FTP, and have to log into the site using FTP credentials, in order to save the page...to your very own hard drive. Now, if you were to take this saved file, and send it to someone else, credentials would leak.

But hang on. FTP, by design, is already taking your plaintext password and dumping it on the wire. Any FTP server that requests a password is thus, by extension, disallowed from containing secure resources (since we presume the presence of an attacker sniffing traffic). So any content that is leakable has to be low security at best. Furthermore, for the special case where the user has done two more transactions -- saved the file, and sent it off -- the content has already been lost in the general case of an attacker sniffing the wire.

So what you have is an exceedingly special case in which credentials could leak, long after they've already leaked in the general case, and the content has to be low security anyway because its being accessed from a plaintext-authenticated resource. I wouldn't call it ideal behavior, but it's not exactly apocalyptic.

Posted by: Dan Kaminsky | August 12, 2007 9:57 PM | Report abuse

Dan Kaminsky> So what you have is an exceedingly special case in which credentials could leak, long after they've already leaked in the general case, and the content has to be low security anyway because its being accessed from a plaintext-authenticated resource.

Actually, in the general case, the original FTP transaction need not have been in the clear--it may well have been encrypted via IPsec or some other VPN. Yet the credentials still leak when the file is disclosed secondarily. And I think you're glossing over the fact that the disclosure scenario presented here doesn't involve any sniffing.

So I think this is somewhat worse than your characterization. I think you're misusing "apocalyptic" here--technically, it means "revelatory", but no, Armageddon will not necessarily result, if that's what you mean. :^)

Posted by: antibozo | August 13, 2007 1:37 AM | Report abuse

Antibozo,

OK, yes. In the scenario where:

1) A web page is saved...
2) ...when accessed from a FTP site...
3) ...that requires a password...
4) ...over a VPN link...
5) ...and then shared back out publicly...

...then, yes, there's a problem. But, seriously, that's a wildly rare sequence of events. You say I'm glossing over not requiring sniffing; the argument I make is that we presume an attacker is sniffing long before we assume the user will elect to redistribute a file. Automatic failure is always worse than user driven error.

There is interesting work being done with FTP though. See: http://bindshell.net/papers/ftppasv/ftp-client-pasv-manipulation.pdf

--Dan

Posted by: Dan Kaminsky | August 13, 2007 10:50 AM | Report abuse

Dan Kaminsky> But, seriously, that's a wildly rare sequence of events.

I guess I disagree, with respect, on how wild it is--a competent network admin who has users that require authenticated FTP (all too common) will set up a VPN if he can. And there are a lot of corporate users out there doing telework using VPN links; those users and their admins need to be aware of this vector.

Thanks for the link. Sort of a natural extension of the abuse of server-to-server FTP transactions orchestrated by clients.

FTP really does need to die. :^)

Posted by: antibozo | August 13, 2007 12:09 PM | Report abuse

Presuming M$ use a magic to mark the username and password fields this is probably accessible with Google.

Posted by: Rick | August 13, 2007 12:42 PM | Report abuse

Back in 2004, when the vulnerability was discovered and disclosed to Microsoft, a Google search yielded around 25,000 FTP credentials. Some of them came from very interesting sources like Microsoft, .gov, and .mil

An internal e-mail search (7 years worth of data) came up with over 700 matches of files with hidden passwords leaving my firm.

This is a real problem and a real exposure, though over the years it got slightly better (or Google became more selective in their filtering).

Yes, FTP is not a secure protocol by design. But if you use it for internal purposes, it will work. And on internal network you may event integrate your login into FTP site into your AD or other LDAP solution. And now there is a chance of your network credentials walking out of the door.

In 2004, I guess it was not a big deal. But this is 2007, and IE 7 on Vista is vulnerable.

I am not even going to mention disclosure of original source for HTTP saves. But you can locate some interesting information in those headers.

Posted by: Alex | August 13, 2007 2:36 PM | Report abuse

I am a web designer and reading the heading made me feel very frightened.
After reading the article and making the experiment I would like to remark some important things:
- The sequence of events that produce this vulnerability (which obviously exists) is absurd from any webdesigner, webmaster or even non-expert user (how many non-expert users would access FTP through the browser to maintain directly their files?).

I say it is absurd or uncommon because the usual thing is to copy (not save the page when viewing it) the file to your hard-drive, edit, save and paste in the remote site.
One last comment about the "After viewing the file in IE and making a couple of changes, you save the document and FTP it back to your site": The order is illogical: you change something, you upload it and finally, you view the file. In case of additional changes, you would edit the file you have just uploaded and still have locally.

Posted by: jotaele | August 17, 2007 4:44 AM | Report abuse

i was really shocked while reading this article, hope its really a very useful one in the web industry.

Posted by: webmaster | August 21, 2007 4:42 AM | Report abuse

The comments to this entry are closed.

 
 
RSS Feed
Subscribe to The Post

© 2010 The Washington Post Company