[standards-jig] JEP:0015 Account Transfer
iainshigeoka at yahoo.com
Thu Jan 24 20:13:38 UTC 2002
On 1/24/02 10:00 AM, "Casey Crabb" <debug at nafai.dyndns.org> wrote:
> On Thu, 2002-01-24 at 11:55, Iain Shigeoka wrote:
>> :) I seem to be playing old curmudgeon/devil's advocate a lot lately...
>> You may want to crosspost this to the security-jig list to have the security
>> team look at this issue (if you want a security breakdown). (However, in
>> the last Foundation meeting we tentatively decided to try and rework the JIG
>> system to avoid this sort of problem of not having the right people see
>> issues... Sorry I digress.)
>> OK. Here's one I thought of as I read your description.
>> Scenario (rogue server): I (rogue spammer) set up a script that slams your
>> server that supports account transfer. The script simply floods your server
>> with account transfer requests acting like a server. Since you allow
>> account transfers, and must expect that a single server may legitimately
>> make many of these requests, your server accepts them. The script then
>> proceeds to spam the world through your server using all of these accounts.
>> A normal server could limit the number of registrations from a single IP to
>> prevent spammer account creation, prevent "open" registrations, etc...
> Devil's advocate is an important role.
> I don't see the above compromise working though because the
> AccountTransfer request has to be initiated by the server currently
> holding the account. The AccountTransfer request has to be honored by
> the Account your are transfering to (ie you have to already have created
> the account and logged into it). This means that random rouge can't ask
> to have an account transferred to him.
> Asking the tertserver to modify a roster may have the hole you are
> describing, but dialback can verify identity. So if olduser is on
> tertuser's roster there is already an established relationship; if
> oldserver says that olduser is moving account to newuser at newserver
> they can dialback oldserver to verify this.
> What the attacker would need to do is hijack the oldserver.
> Am I missing it?
Sort of. I'm probably not being clear. :)
The tertserver and old server are completely virtual. A hoax played by the
rogue spammer's script. So there is no need to verify the ability to
transfer accounts because there are no accounts to verify. It's all a
figment of the scripts imagination...
Hmm. I think I see the disconnect. The spammer is CREATING fake accounts
on a legitimate server. Say I wanted to create 10,000 jabber.org accounts
to spam from. I could have my script act like "fakeserver.com" and transfer
10,000 non-existant accounts from fakeserver.com to jabber.org. I'm sort of
hijacking jabber.org's server (or at least its resources and reputation).
Alternatively, I could use this as a DOS (denial of service) attack by
chewing up all of jabber.org's resources trying to deal with the mass
account transfer (and all the data storage that it implies).
Once again, you can do this through the register protocol as a client but
account transfer makes it easier to do, and harder to block while still
supporting the protocol...
Am I making sense or am I missing it?
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
More information about the Standards