Security treat: the ftp address, username and password of your website’s server broadcasted over the Internet

Frederick Giasson

That post talks about another security problem resulting of the bad interaction between two different applications. The current problem is that the ftp address with the login name and password of your web site can be viewable by anybody on the Internet in a specific situation.

How it happened?

I am using the AceFTP software to connect to the ftp of my website’s server. It is a really nice ftp software. One of the useful features is that you have the possibility to view a file (text, image or webpage) in an embedded web browser. Then if you click on your index.htm file, you will see it instantly into the browser; it is really useful when you do not remember what a specific file was.

I am also using StatCounter as my web site statistic application. I already talked about that beautiful service before. You only have to put a little JavaScript code on one of you webpage, and it will record the entry and exit pages of your visitors.

Now you wander what is the problem?

The problem exists when one of the feature of AceFTP and another one of StatCounter interact together:

  • The preview feature of AceFTP
  • And the possibility to put your statistics public with StatCounter

Note: you need to have in mind that this security problem can be possible with other ftp client softwares that have the same feature and any other web site statistics services that broadcast the stats publicly. I get AceFTP and StatCounter in my example because it is with them that I discovered the problem.

You see the problem coming? When I check a file that contains the JavaScript code of StatCounter in the “embedded browser”, the code on that page is then executed by the ftp client software. Then the visit will be recorded by StatCounter. The problem is that the entry page that StatCounter will show will be something like that:

username:\[email protected]/thefilepath.htm

Then if the public statistics of your StatCounter account is at “on”, then anybody can have access to the ftp server of your web site.

Demonstration

  1. I check one of my file containing the StatCounter’s JavaScript code with my ftp client software
  2. Then I check my stats

How can we fix the problem?

  1. Web services like StatCounter could check for the patterns: “* : * @ *”, then hiding them. It is exactly what Bloglines had done when I discovered a problem like this one with their web application.
  2. You could use another option of StatCounter that enable you to ignore the visits that come from your IP address. Then if StatCounter ignore your visits, such activities will not be the recorded.
  3. You could simply stop using the preview feature of AceFTP.

Conclusion

My conclusion is that same as the one I wrote for the Bloglines’ problem with the RSS feed: This experience is a good example of the potential security treats that can appears when more than one system start to interact together.

Technorati: | | | | | |

The software architecture to use for faster security hole patching: Web Applications

Frederick Giasson

Security holes can be found everywhere in software. It can be a problem by the way a programming language is used; it can be a problem with the conception or the use of an un-secure protocol; it can also be a problem of interaction with other software or libraries; it can be a problem with his interaction with the operating system, or it can be a problem with the way users use it.

These problems are real, and many people and billion dollars are spent to try to cope with them. However nothing is perfect and the result is currently seen as marvel by someone and terrible by others.

If a security problem is found, you can bet that an advisory will follow; a patch of the software in cause will be distributed. Software developers thought about developing systems to ease the burden of software updating imposed to users. Some systems are good, others are more debatable. In a case or another, the problem is the same: users need to perform some type of task to patch their software to secure their systems. With the number of software they daily used, they can hardly keep them up-to-date, with or without having the will to do it.

What if they do not own, on their computer, the software they are using? It is sure that not owning them on their computer does not make the code surer, but will the updates be faster? You bet. Think about it. You are using certain functionalities given by a certain web services, web application, API, etc. Someone find a security hole in the thing, and then wrote and publish an advisory about the found security hole. Normally, thousands or millions of people would need to download and install a patch to get rid of the bug and re-secure their systems. But if the same code is use by all these users, you only have to change that code to automatically patch all users. It is probably the greatest security advantage we have by using such online software.

I recently unintentionally tested the concept with Bloglines. I found a bug in their system (in fact it was the relation between a bug in their system and the use of another web service), published an advisory, then the system was patched 1 or 2 days later by the Bloglines developers. Then all the users were patched and secured at the same time.

Technorati: | | | | | | | | | | |

Come back on the Bloglines’ security flaw with secure feeds

Frederick Giasson

Give to Cesar what belong to Cesar. Bloglines has reviewed the previous security flaw I found in their system in interaction with secure web feeds and fixed it.

I was reviewing the posts that bloggers make on the subject and read all the comments on them. It leads me to check if the problem I found on Bloglines was always there. They fixed it.

How have they fixed it? No they did not delete the HTTPS and HTTP Authentication handling feature of Bloglines. They simply make the URL feeds with HTTP Authentication private.



We can’t change the status of such feeds; the system does not give us the possibility anymore. They are private and will remain private. It’s good news. As far as I know, there are no other problems with this feature in Bloglines.

I would like to thank the Bloglines team for their positive answer to my security flaw discovery and for their fast service fix.

Technoratie: [] [] [] [] []

Do not use the Atom Gmail service with online aggregators like Bloglines

Frederick Giasson

I study the problem of the secure web feeds since some weeks. I read a surprising post that talks about the Gmail Atom feed service used with Bloglines this morning. An idea came up in my mind while reading the post: it is not possible… can I really have access to login and password of people that subscribe to “secure” web feeds that use SSL and HTTP Authenticate with Bloglines? The answer is sadly: Yes I can.

The problem is that to use the Gmail Atom service in Bloglines, you need to build your feed’s URL like this: https://USERNAME: [email protected]/ gmail/feed/atom, to provide the user and password to the feed’s server.

All the problem is there: you have the username and the password in plaintext directly in the URL.

The first thing I then checked is if I was able to find such strings in online aggregators such as Bloglines. There is the answer:



Why do I have access to these URL? Probably because the Bloglines profile of these users are public and not private.

Then I tested if I was able to have access to these users and passwords by subscribing to the SSL and HTTP Authentication test feed on the silverorange project with Bloglines. I created two Bloglines profiles: one that the profile (Jim) and his blogroll are public and another (Todd) that will check the blogroll of the first account. The scenario goes like this:

1. Jim subscribes to a new SSL and HTTP Authentication protected feed with Bloglines. His profile is public and he does not know the consequences of what he is doing. The address he subscribe to is:

https://testuser:[email protected]/rsstest/
httpauth/rss_with_ssl_and_auth.xml

2. Todd discovers the public profile of Jim and checks his blogroll. He is lured by an entry called “Test Feed (HTTP Auth, SSL)” he checks it, likes it and subscribes to it. Then Todd see this Bloglines page:



3. Todd check more closely to this Bloglines page and remark:



Todd just discovered the user and password of a “secure” web feed. Basically he was not able to see the complete URL of the feed because it is viewable in the Bloglines system as: http://www.bloglines.com/preview?siteid=1830560. However, by subscribing to it, Bloglines shows the complete URL of the feed to the subscribed users.

This is just a test I performed with a SSL and HTTP Authentication RSS test feed available on silverorange.

Now, think about the consequences of this situation when users subscribe to Gmail or any other “secure” web feed using SSL and HTTP Authentication? The problem is real and could have many undesired consequences.

The best thing to do is not using such feeds in online services like Bloglines. Even in stand alone software it could be unsafe. I pointed out a week ago why I do not like this strategy to handle the problem of secure web feeds. This is a beautiful example of the potential problems it can lead to. You can read my article on the problem and the proposal of a solution here: Secure Web Feed Protocol.

This experience is a good example of the potential security treats that can appears when more than one system start to interact together.

Technoratie: [] [] [] [] []

New applications of the Secure Web Feed Protocol – In Gmail and RSS Calendar

Frederick Giasson

Five days ago I proposed my article: Secure Web Feed Protocol, to the PST05 conference. Two days after I came around 15 things you can do with RSS. Two of these applications got my attention:

  1. Collect your email from all your email accounts in your RSS reader
    Stay updated on someone’s schedule
  2. I thought: these ideas are wonderful! What about the security of these services? Could they use SWFP? There is what I found.

1. Google is supposed to have tested a RSS feed service for Gmail in their GoogleLabs in 2004. I can not confirm if the service is always available because I do not have any Gmail accounts and I can not sing-in for one. This service put new incoming messages of a Gmail account into a RSS feed. Then if you subscribe to that feed you will see your new Gmail messages directly into your web feed reader. What an excellent idea! However, I was surprised to found that they used SSL to create a secure channel between the feed and the feed reader.

In the section 5 of the SWFP article I explained why I think that using SSL to secure a web feed is not the good strategy to adopt. It is for this reason that I was surprised to discover that they tried to use SSL to secure the inbox web feeds. JC suspected that they did not create it for this purpose but for another application called Google Notifier. I think he is right.

I do not know what was the real purpose of this test but the result is the same: the idea of using RSS feeds to check your mail is interesting. However, using SSL does not seem to be the good strategy to adopt. Not all stand alone feed readers support SSL. If you do not wish to enter the login and password of the private feed each time you want to check for new messages, you will need to do something like that:

https://USERNAME:[email protected]/gmail/feed/atom

This solution is even worse than not encrypting the web feed at all. With this string an intruder could sing-in into your account then check, delete or send messages with your Gmail account. It is far worse than only having access to the unencrypted inbox content.

This is a beautiful idea that could be handled by the Secure Web Feed Protocol. Now check out the second application of RSS feed that could use SWFP.

2. This time we are sharing our calendar with our friends and family using a service called RSS Calendar. When you add something to it all your friends and family will have access to your calendar’s changes. Is that not beautiful? Yeah it is. What about the security of this other service?

You could wish that the planet know that you are going to Mont Washington the 20 Mai 2005. But what if you only wish that your friends and family know it? There is no privacy feature in the service for the moment.

I think that the implementation of the Secure Web Feed Protocol could be really interesting in this case too. Only the people you choose would be able to read your calendar. I like the idea.

You are now thinking: how could the implementation of SWFP could be done in such services? The only thing that will change with what I discussed in the article is the way you will distribute the asymmetric keys

Technoratie: [] [] [] [] [] [] []