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:

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: security | statcounter | aceftp | ftp | flaw | hack |

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: Security | hack | hacking | patching | Bloglines | api | software | architecture | web | services | applications |

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: [security] [Bloglines] [secure] [feed] [atom]

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: PASSWORD@gmail.google.com/ 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:testpass@secure3.silverorange.com/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: [gmail] [atom] [Bloglines] [security] [feed]

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:PASSWORD@gmail.google.com/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: [swfp] [secure] [web] [feed] [gmail] [rsscalendar] [rss]

This legitimate question has been asked by Daniel Lemire after his reading of the SWF protocol. There is my answer to his question. I added it as the section 7 of my SWFP paper.

The question is hard to answer because it depends on many factors. I’ll compare the two methods together and try to show you the differences between the two protocols.

Usually SSL is used to authenticate the server to the client and, optionally, the client to the server. With the cost of authentication certificates (about 100£ each), the normal clients can’t afford these authentication certificates. It’s why SSL is mainly used to authenticate servers.

Our goal is especially to authenticate the readers to the server. It’s a reason why using SSL as a secure channel and an authentication protocol is not so useful: because the implementation cost is too high; like the revised version of SWFP at section 5.

This is the big difference between SWFP and SSL: their goals.

A solution could be to use HTTP over SSL (HTTPS) with HTTP Authentication. HTTPS would provide the secure channel and HTTP Authentication would provide the authentication mechanism. The problem with this solution is that some feed readers only implement HTTPS, others HTTP Authentication and few implement both. Another problem with this solution is that who says HTTP Authentication also says login and password. In SWFP the authentication is inherent to the system. It’s made with the public key of the legitimate reader present in the secure database of the server. The authentication steps of the reader to the server are transparent to him. I think that this transparency feature is an important one because it simplify the process and brings non-expert users to use it. Only the simpler things, in appearance of, are widely used.

Two types of feed readers are available: the web applications like Bloglines or the standalone software like Omea Reader. Both principles, HTTPS with HTTP Authentication and SWFP, could be implemented in standalone software and the implementation time, cost and difficulty are probably comparables. However, I think that SWFP would be much more easer to implement in web applications. Why? To use HTTPS with HTTP, the web applications would need to create the secure channel themselves with the feed’s server. By example, Bloglines itself would need to create the secure channel with each private feed server. I don’t think that it’s imaginable. However, with SWFP nothing like that would be necessary because the encrypted feed is viewable by anyone who needs it, even web applications. If I check the FeedBurner stats of my blog: 30% of my readers use Bloglines. I think that it’s considerable and that we need to take this fact in count.

Another problem with the HTTP Authentication solution is that it’s not an optimal solution to our problem. If a user is subscribed to many private feeds then he’ll need to enter, each time, a login and password to check the feeds. Personally I don’t think that this is viable. Think about the pain such a situation would engender… nobody would subscribe to such feeds.

Finally one of the beauties of web feeds is that you can archive them for future readings. The problem with the HTTPS solution is that you didn’t really have the choice to archive the encrypted or the unencrypted content. But such a choice is possible with SWFP.

Technoratie: [swfp] [https] [authentication] [security] [feed]

The last weekend an idea passed through my mind: “It seems that more companies are using content syndication technologies to broadcast their news or information to their employees”. Then I started to write a protocol to take this fact in count. It’s called: SWFP, Secure Web Feed Protocol.

“SWF is a protocol to ensure the secure broadcasting of web feeds’ content over a local network or the Internet. The protocol ensures the encryption of the feeds and the distribution of their encryption symmetric keys.”

It was supposed to be the draft of an idea, something to post here. Finally it revealed to be an article of 12 pages. I worked on it this week and came with this first draft:

View: SWFP: Secure Web Feed Protocol [PDF file]

If you have any question about this paper, don’t hesitate to contact me. If you find flaws in the protocol or modifications to suggest send them to me, they’ll be warmly welcome. I also invite you to leave your comments about this paper here, on this post.

Technoratie: [feed] [security] [protocol] [encryption]

I was surprised to see, this morning, a sort of bookmark spam attack in one of my Del.icio.us feed (tag:writing). I had around 30 bookmark entries with user names like: rollofle500, rollofle502, rollofle503? etc. All the messages have been sent at a minute of interval with different tags, different topics and all linked to the same website: http://torrents.on.nimp.org/?u=rolloffle that redirect us to http://www.gnaa.us/. I think the attack have been performed with an automated script that worked like this:

1. He creates an account with a random name and a random email address.
2. He login to this newly created account.
3. He post a bookmark with this newly create account and put random tags that he get in a special word dictionary created for this effect.
4. Finally he restarts the whole process.

It seems that the administrator of Del.icio.us had deleted these users and entries. They probably have been alerted of the situation and deleted them on the spot.

The problem is that erasing all the entries hadn’t repaired the entire problem because their feeds have been infected and distributed to hundred of subscribed users.

We are in right two ask this question: Why this situation happened? The answer is ease: because their authentication is not working properly. You can post bookmarks without validating your account. This is the real problem and why the spammer had been able to perform this sort spam attack. Even if you see this message:

» A verification email has been sent. Please check your mail. If it does not arrive shortly, go to the settings page and ask for another verification email.

You can do what you wish with your account.

What’s the solution to prevent future bookmark spam attacks on Del.icio.us? They will need to upgrade their registration and validation system to prevent the new users to be able to post bookmarks without being validated by the system.

Technoratie: [spam] [delicious] [bookmark] [authentication] [security]

A week later, a journalist of TVA enters LG2 without being intercepted.

There are some updates on yesterday news. Mr. Caillé knew that Radio Canada would broadcast this report for more than a week. Yesterday a journalist of TVA, another French Canadian news network, had entered in LG2, without being seen. They explored the site for about 2 hours; they entered a repair shop, found blue print plans and Hydro-Quebec trucks with keys on the starter. It’s unbelievable. What do they need to do the make them react? Do they need to put bombs at LG2? If I’m going there tomorrow, will I be able to go anywhere I want without seeing any security agents and enter every door I see (because they are virtually all unlocked)? It’s not a game; it’s serious: they need to do something. These people, these administrators, don’t seem to understand what is going on, what?s the treat. We don’t live in wonderlands. Is 9/11 already forgotten? Did we learn anything from this event? …I can’t believe it.

Video report of TVA (french)

Technoratie: [security] [terrorism] [quebec] [dams]

First, read this piece of news about the security of Quebec’s dams: Quebec dams open to attack, probe suggests. Everybody is talking about this report done by a journalist of Radio Canada. I saw the report on the TV and it’s awesome. The authorities can’t say that the security is correct; it is not. The journalist had reached the core of two major dams in the north of Quebec without being seen. Was he hiding? No, he looked like a tourist with a huge camera on his shoulder and his big white truck. He was able to stop the electric production of about 500 000 homes; he reached the main controls of the power plants without anyone intercepting him? he was alone in the complex. He never meets any employee or security guards in about 1 hour of door opening and investigation on each site. There was no evident camera (the authorities say that they are hidden). The problem is that it seems that they are not monitored by permanent security guards. Sorry but tell you it, Mr. Caillé, but Hydro-Québec is not a chain of corner shops; the camera don’t have the same utility in a corner store and in power plant of billions of dollars. Cameras in the first one are there to know who the criminal was. In the second, they are there to prevent criminals to reach the dam.

Okay, you know what’s the problem? It’s probably easiest to enter in this critical infrastructure of Quebec than to enter in any home on the territory. This situation is definitely unacceptable after the 11 September 2001. Some ones will say that we have nothing to fear; that we don’t have any enemies and it would be an unnecessary spend of money. To them, I’ll say that: first, we get problems with French separatists for more than 40 years. Last years, an unknown group had put dynamite on a main transmission pole and they pull the trigger. What if they had reached the core of the Manic 5 central, or LG2? The result had would be catastrophic. What if they do this in a cold wave of 1 or 2 weeks with temperatures under 30 or 40 degree Celsius? We probably wouldn’t be able to buy electricity at the USA or Ontario because they just wouldn’t have enough. Then, we would be in great troubles.

After, think about it. Our greatest electric client is the USA. We sell megawatts of electricity on the east cost market. If two of our main dams are the target of international terrorism it’ll not just be a catastrophe for the village around the dams (who will probably be flooded) but also for the entire east cost of America. Think back, the major black out that occurs a year or two ago on the east cost. The electric switch in new New-York city was turned at off and they didn’t have electricity at all for some days; no air conditioning in the middle of a dog days. This total back out was the result of a problem in a switch complex somewhere in the north east of the USA. Think about what it would be like if 2 or 3 of the main dams of the north east of America would be shutdown or destroyed? I don’t want to think about it. If international terrorists need to hurt the USA, then one of their best bet would probably to destroy these dams. It’s easy, as demonstrated above, and effective.

Finally, if there is no security at all for these dams, what’s the security of our nuclear power plant? Is this the same situation? I hope no, otherwise it would be the problem of many more person than the millions habitants of the east coast of America. It’s my reaction to the situation. I hope the government of Quebec will get enough pressure to move and spent money to arrange the situation. The current situation is unacceptable; and for the stability of the Quebec, the Canada and the United-States, we need to act now.

What can we do? Talk about the situation. Are you Canadian or American? Talk about it, wrote about it in hope that these things put pressure on Hydro-Québec and the government of Quebec to obligated them to act and increase the security of these sites.

Update 17-02-2005: The video report(french)

Technoratie: [security] [terrorism] [quebec] [dams]