security

A friend of mine, Colin Keigher, recently did some interesting research into how Scanlife's proprietary EZCode 2D barcode system functions. He did a presentation of it at BazCamp Vancouver about his findings, and has also written a detailed blog entry explaining his findings.

It's fascinating to see the breakdown of what he found, and it's enough to make me want to check the format of any 2D barcode i'm trying to scan. I'm not quite sure how prevalent these codes are in the United States yet, but I know they're starting to show up in Canadian newspapers.

This afternoon, I was reading my Twitter feed, and @n3tg33k retweeted a twitter.com address: twitter.com/server-status. Since I'm mentioning it on here, I'm sure you know it doesn't refer to a Twitter username @server-status, but rather is a link to a page that displays server status information for some of Twitter's servers. A few minutes after seeing that link on my feed, there was another retweet from @agent0x0, referencing twitter.com/balancer-manager--another page with server information that probably should not be publicly available.

Out of curiosity, I decided to poke around to see if I could find any more data leaks on there. My original tactic was rather haphazard: I found a list of standard Apache modules, and brute-forced some URLs based on them. However, I got a much better idea--since these were public-facing pages, maybe I should try a little Google hacking before I spent the rest of my day trying to read the minds of the webmasters at Twitter. Since both of the data leaked pages I had heard about so far were web server status pages, I Googled "Apache/2.2.11" site:twitter.com and looked through the results.

A link to server-status showed up on the first page in the initial list. The link to balancer-manager didn't show up in the initial result set, although when I asked Google to show similar results, balancer-manager showed up as well as server-status. However, these were the only two Twitter data leak pages that showed up under that search; the rest of the approximately fifty hits were from Twitter users who tweeted about installing that version of Apache, or tweeted lines from Apache status pages for whatever reason. I double-checked by searching Google for the entire Server Version line (Apache/2.2.11 (Unix) PHP/5.1.6 mod_ssl/2.2.11 OpenSSL/0.9.8e-fips-rhel5); this only returned the same two data leak hits as before. Of course, this is not to say these are the only two data leaks on Twitter.com. There may be more lurking, connected to things other than Apache/2.2.11, or not yet cached by Google. But, there are at least two that have been cached, as well as passed around the social media security geek corners of Twitter--and that's two too many.

What does this mean? It means that Twitter should change its settings so that these two pages are accessible by their server administrators, but not the public at large. It also means that if you are responsible for maintaining a website, you should make sure that all of the pages created by your web server that are meant for internal monitoring and maintenance are kept just that: internal. Otherwise, if someone malicious knew what they were looking for, they could find that information, scour it for any indication that your system had a known vulnerability, and exploit it. Defending against exploits is inevitable when running any computer system, of course, but there is no use in making it easier by keeping internal server monitoring and maintenance data exposed.

Epilogue: It appears that Twitter has blocked access to these two pages. For a few minutes, I was getting a page that told me that they liked my enthusiasm, but I was rate-limited to prevent abuse and should try again in 60 minutes. This happened when I tried to access either of the aforementioned URLs. This happened not only from my computer from which I was doing all of the poking around and reloading, but also from my smartphone, which I had not yet used to access either of the data leak URLs.

Within ten minutes after first seeing the rate limit pages, I was getting 403 Forbidden errors instead.

Tangential to the data leak weirdness, it's interesting to see a rate limit web page on Twitter. I've had plenty of experience and frustration dealing with rate limits on API calls, since I've written some rather API-call-intensive Twitter bots in the past. However, I've never seen any documentation about rate limits on Twitter's web interface--either a limit on the number of times a certain user or IP address can reload a Twitter web page, or on the number of times that users in general can access a page per hour.

Has anyone else who is reading this seen a web page that said they were rate-limited, or do you have any knowledge about any restrictions Twitter has on how many times a web page of theirs can be accessed? I would be interested to know.

It seems like the hottest thing on the internet right now is a Google Wave invite. The day that Google began to offer Wave invites, I felt like I was the only person on my Twitter feed who was not tweeting either about the fact that she had one, or the fact that she wanted one. Since then, I still see some tweets about it, but it has mainly calmed down on my feed.

However, Twitter is still abuzz with people passing links to supposedly free Wave invites around. It seems simple enough to the unintiated: give some website your Twitter name and your email address, retweet the link to their website, and get your hands on one of thousands of invites. Sounds simple, right?

But...anyone can put up a site claiming that they have Wave invites, or anything else. It has all the marks of a scam: someone you don't know has harvested your email address, and they can send whatever spam they want to you. They've also matched your email address to your Twitter account...which makes it easier to crack your accounts, especially if the passwords to them are the same.

I was having a conversation about this with Hellekin on Twitter earlier today, and he suggested putting up a site that culled the tweets that passed around the spam links, and call the people out on the fact that it's probably a scam. I am not all that adept at putting up websites--however, I really do enjoy making Twitter bots, and started becoming very good friends with the Twitter Search API last week, while writing an IRC bot that (among other things) searches for tweets that reference my hackerspace. Thus, I took a little code from that IRC bot, took a little other code from the Kanye Bot, tweaked it a little bit, and made a bot that digs up tweets that are likely to be from people who have fallen for the scams. It lightheartedly tells them that their email address has now been taken by a scammer, and advises them that it may be good to change their password.

The bot is posting at @WavePwned. Right now, the way it's coded, it hits a few false positives, since the search terms are google wave invite http: So, in addition to hitting people who are tweeting links to span sites about Google Wave invites, it also hits people who are linking to articles about Google Wave invites. However, it is almost impossible to craft something more specific and hit such a large amount of the people propagating these phishing links, since there are so many new links made with the same kind of spam, and the phrasing of the spam tweets changes so often.

Hopefully, this little bot will alert at least a few people to what a hoax all of these Google Wave invite sites are, and make them think a little more before giving some random website their information. The morals of the story: if it sounds too good to be true it probably is, and think before you give out your social networking or email address information.

(thanks, @hellekin, for the idea!)

Just because Twitter is ubiquitous doesn't mean that it should be applied to everything.

Case in point? Vantage Credit Union has introduced a new feature called tweetMyMoney. It is exactly what it sounds like: people can now send bank account management commands--and receive bank account information--through Twitter. People can check balances, transfer funds between accounts, check recent transactions, and check recent holds.

The first question on the tweetMyMoney FAQ supposedly touches on why the feature is secure. It reads:

Q. How is mobile banking using Twitter secure?
A. As always, your account security is our utmost priority. When you use tweetMyMoney to access your account information, keep in mind that the information provided DOES NOT include account numbers, passwords, PINs or any other secure information. Also, tweetMyMoney uses the application’s direct message feature so no one else sees the account information you request.

Really?

Sensitive information should simply not be transmitted via Twitter. There's always the risk of a DM fail: if you accidentally tweet @myvcu without using a direct message, you are in effect announcing to the entire internet that you are using tweetMyMoney, and that control of your Twitter account gives them at least some control over your bank account. Furthermore, your Twitter direct messages are not encrypted--so, if someone is watching the network, they can have your username, your login credentials, and the fact that you use this service, even if you sent a direct message. They can also see what the credit union is sending back to you--including your account balances, as well as the code that supposedly authenticates that the message is from Vantage and not from someone else. If they're sending the code to you unencrypted, you get no assurance that the code hasn't been stolen.

I'm sure I'm just scratching the surface here, and that there are even more security flaws in this that I have yet to think of. I hope other banks don't follow suit on this, and I hope Vantage jettisons this feature soon. Otherwise, there could be some serious issues on the horizon.

(hat tip to @nickhacks for telling me about tweetMyMoney.)

This morning, Farhad Manjoo's column in Slate Magazine argued that corporate computers should be "unchained": that workers should be allowed to run any chat programs they wanted on there, and be allowed to use any kind of software, because it will allow them to choose the suite that will make them most productive.

Manjoo's argument is naive, and it ignores the realities of corporate IT. He gives the average end user far too much credit. He assumes that people are only playing on the internet to clear their heads for a few minutes before getting back to work, and only using websites and tools that increase productivity and are not infected with malware. There are some end users who are diligent, and will follow this ideal. However, there are many who will not. And, there are some end users who think they are being diligent, but are sufficiently unfamiliar with internet threats that they think they are downloading legitimate software for work, but are instead introducing malware onto their computers. In the balance, allowing anything and everything to load or run on a corporate computer will be far more likely to burden the network with malicious software than cause the renaissance of productivity that Manjoo envisions.

However, even though Manjoo's proposed solution is overbroad, he does raise a good point that IT staffs should take to heart. Sometimes, there is more than one legitimate option for getting a job done. It does get frustrating, as an employee, to be unable to use battle-tested, job-relevant software because IT has not installed it on the company's systems. (Having previously worked as an attorney in a large law firm, I know this all too well.) Allowing employees to install whatever they want whenever they want is not the answer. Instead, this should be a call to IT departments everywhere to take the time to assess the software available to employees, stay in touch with employees relative to their software needs, and continue to explore options frequently cited by employees as ones that would improve their productivity at work. It is folly to allow untested software on a corporate network. On the other hand, if members of the IT department consistently tested and evaluated software frequently requested by employees, and implemented the options that proved themselves sufficiently secure, realistic to administer, and productivity-enhancing, then there is hope for enhanced employee productivity and strong network security to coexist.

(Hat tip to Ben Tomhave for turning my attention to this article.)