Slashdot Mirror
Hacking Web Services
siduri writes "Udi Manber, chief scientist at Yahoo!, gave a great talk on the kinds of hacks that Yahoo sees at the IEEE's Symposium on Security and Privacy. I wrote an overview of his talk for Dr. Dobb's Journal. While some of the message is well-known stuff (like that people will spend a lot of time hacking the most trivial things), the details of what Yahoo has to deal with are really pretty interesting."
I know that someone has been hacking google for the past few years about once a week. Always changing the google logo(jk). I guess google is just powerless to protect themselves
Yahoo's problems are massive, and I think it's good that at least SOME people at Yahoo realize it, even though I'm still not convinced they are aware of the full scale of the problem.
After all, if you chat with Yahoo's service, you're eventually going to be booted off by another user. Some of the methods users use to exploit the system and kick off other users are clever, some are not so clever.
One method involves running a program easily downloaded off of the internet and typing in the desired victims name. It's your basic "Punter". Some of the programs available are effective at removing users of Yahoo's Messenger, while a few of the more recent ones do a good job taking out users who use 3rd party Yahoo clients, or even Yahoo's web-based Java client.
These methods of exploitation are half-way understandable, though I don't see why Yahoo hasn't worked to block the attacks in the same way that AOL has with AIM.
The other method, plain old boot-text, is simply unacceptable.
If I were chatting with someone using Yahoo Messenger and they annoyed me, all I would have to do is send them a single URL with an unrealistically long domain name in it, and their Yahoo Messenger will crash. A URL such as www.xxxxx.com with about 400 to 500 X's in the name will work nicely.
It's a relatively simple matter for the end user to set up a personal word-filter on their messenger and block out all occurences of "www." which effectively makes them invulnerable to this attack, but that is not the issue. The issue is, that if Yahoo has such easily exploitable end-user software, I'm very worried about the quality of their security as a whole.
Think about it.
"Everything you know is wrong. (And stupid.)"
Moderation Totals: Wrong=2, Stupid=3, Total=5.
Often, it's not a matter of restricting access. The description of the E-Bay situation where other people would generate bad logins as a competitor to lock them out is a good example. You need to provide this functionality, to keep from having your client's accounts broken into. Yet, that very policy can be used effectively as a denial of service against your clients.
I run into sysadmins who assume that issues are binary--something is bad, cut it off; something is good, allow it. Usually more complex applications require much more of an understanding of a balance between business functionality and security. In the case of E-Bay and user lockout, there is no exact solution--you need to satisfy two opposing interests--so you make a compromise between the two and try to forge a workable solution.
I think the biggest challenge for the security community will be how to modify their practices (and others') to be able to quantify risk in applications so that businesses can make good functional decisions. Security teams have largely focused on perimeter security and things like web parameter checking, but they don't usually stray into the gray area of functional requirements--or if they do, usually only to, as some have put it, cut the wings off flies.
So, to get back to the original point of the post--it's not so easy to solve as just blocking traffic. Nope, sorry, it's a lot more work than that.
he talked about countermeasures instituted against hackers, but doesn't want them openly published (security through obscurity, anyone?)
I'm quite tired of hearing statements like 'company X won't reveal Y; this demonstrates security though obscurity which everyone knows is bad.' Well, it's not! Your statement demonstates that you can echo the slogans but don't understand what security really means. I strongly encourage you to read a recent Crypto-gram by Bruce Schneier. You cannot apply the principles used for analyzing a mathematical system to all real world security issues.
Given one hour to live, the student replied: "I'd spend it with professor FP who can make an hour seem like a lifetime."
Yahoo!'s problems are no different from those brick-and-mortar retailers have with loss leaders and promotions: if you give something away at a loss, there is a good chance that others will find it profitable to get lots of it and resell it. It's not a security problem, it's a problem with the business model. Welcome to the real world.
Yahoo! may want to continue to bask in the glory of having many millions of users, but if they want stop these problems, all they have to do is charge for all of their services. The choice is really theirs.
Don't get me wrong: I like Yahoo! services and I think it would be great if they continue to be free. But I really worry when Manber uses terms like "theft" and "security" for a problem that has very little to do with "theft" and "security". Fortunately, Manber himself isn't calling for a legal solution, but management and lawmakers may be less understanding of the issues involved.
During hotly contested auctions, some users will mount password attacks on other bidder's accounts an hour before the end of the auction -- not to actually gain access, but merely to trigger a security lockout, thereby ensuring that the legitimate user cannot place last-minute bids.
I realize how ridiculously easy it is to get a new IP address on a dialup system or in a facility where someone has access to many addresses but wouldn't a simple IP block after so many attempts help discourage the casual DoS but still allow the legitimate user access when they come to make their last minute bid?
If not this then what about using a login name which is different then the displayed account name? This way the login name is not available to people viewing a particular account's public details for their use in a DoS. I know this is an added step of complication but may be necessary to eliminate bad side effects.
The solution exists, it's just that the transition to the solution will be painful, so we're desperately trying to avoid it.
The solution is whitelists and "postage".
Put all your friends in a whitelist. Main from them is delivered instantly.
Anyone else who emails you gets an autoreponse, "I don't know you. To ensure that you're a real human being, you'll to need to run the postage program to get the result for the code ABAASDFFEFEF". The program needs to be open source and easily verifyable for security reasons. The program solves some problems that is hard to compute (say 60 seconds), but easy to verify. One example would be a brute for cypher break on a simple cypher. The senders email client can handle this autoreponse automatically, shielding the sender from needing to deal with it (Gee, my computer gets slow for a bit when I email someone new). Spammers, on the other hand, would need to either limit their spamming so they have time to generate valid responses, or would need to invest in expensive hardware to generate the responses fast enough. End result: It's no longer cheap and easy spam.
There are a few other details to make mailing lists feasible, but it's doable.
However, this effort would require everyone to upgrade their mail clients or to use external programs to manage this. Given that extremely slow adaptation of other email security features, I'm not optimistic.[B