fail

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.

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.)