Firesheep, a week later: Idiot Shepherds
In only one week, Firesheep has captured the attention and interest of hundreds of thousands of people around the world, and has spurred a lot of great discussion. This is the second in a series of posts highlighting and responding to topics I found most interesting.
Previous post in series: Ethics and Legality
In addition to all the news articles, blog posts, comments, and tweets, Firesheep has inspired some people to respond with code.
One developer thought Firesheep, as a mostly passive tool, didn’t go far to warn people about the dangers of using insecure websites. He released a new tool called Idiocy which automatically hijacks any Twitter accounts it spots and posts a tweet as them, offering a much more blunt reminder to both the victim and their followers.
Idiocy, at less than 130 lines of code, is an important example of how easy eavesdropping can be.
While Idiocy might offer a useful message, Twitter users have no way to use the website securely without a third party tool like HTTPS Everywhere. Very few people have actually been affected by Idiocy, a search on twitter at this time shows less than a dozen tweets containing the message posted by Idiocy.
Another developer created FireShepherd, which has been widely reported as a way to stay “safe” while using insecure websites on public networks. To understand how this tool works, imagine your friend gets drunk at a bar and starts shouting his credit card number to everyone within earshot. Knowing he isn’t in his right mind and will likely regret his actions in the morning, you decide to intervene by shouting “LALALA” even louder with the hope that nobody will be able to hear what he is saying. While this may prevent some people from hearing the card number, it won’t stop everyone, and will most certainly upset everyone else at the bar even further.
This is essentially what FireShepherd does. FireShephed continuously sends random data over the network in an attempt to confuse session hijacking tools such as Firesheep. To an attacker, this is nothing more than a simple annoyance. FireShepherd does not change the fact that sensitive information is being sent insecurely.
Sending out lots of random data, especially over a wireless network, can disturb everyone else on the network and result in their connections becoming slow and/or unreliable. In addition, FireShepherd by default sends all this data out over the Internet to www.facebook.com, placing unnecessary load on their servers. This is usually referred to as a Distributed Denial of Service Attack, and is probably not something you want to participate in.
FireShepherd provides no real security and is harmful to Facebook’s servers and the local network which it is used on. Nobody should recommend using it for any reason.



Comments 8 Comments
Over 10 minutes, it averaged just over 2.5 kb/s.
For comparison, just randomly browsing facebook from Firefox used about 1 Mb/s on average, and often more. Your scaremongering of "ddos" and "jamming the wireless network" is laughable. I use more than 2.5 kb/s monitoring the bots in my IRC channel.
Furthermore, the tool causes firesheep to crash, halting it. Like, it crashes all. The. F***ing. Time. Continuously. Without stopping. Ever.
Thus, your analogy of it screaming "LALALA" in a bar is totally invalid. It would be valid, if screaming caused every human in earshot to spontaneously lose consciousness.
tl;dr: Fireshepherd is not a solution to the underlying problem, since it will not stop determined sniffers, but it is a viable bandaid for people who are only worried about stopping script kiddies.
IMHO, I don't think that expecting all WWW sites using SSL/TLS in a near future is realistic. Immediate attention should target public WiFi access point providers because they're giving access to Internet as a "dummy" bridge allowing everybody earring (not spying) all communications. Public WiFi access should be provided as a proxy and using SSL/TLS. Technologies are already available and free. For example, Apache's mod_proxy and mod_ssl would do the trick. Since, almost all routing devices are using an HTTP server for administration purposes (i.e. configuration, monitoring), implementing proxy and SSL/TLS should be trivial. This is not the ultimate solution, but still a huge step forward.
"There's no conspiracy: only ignorance. There's no ignorance: only consciousness persons systematically rejecting any plausible fact." - @illusion4dummy