[Security] [jdev] Spoofing of iq ids and misbehaving servers

Thijs Alkemade me at thijsalkema.de
Sat Feb 1 11:46:40 UTC 2014


On 1 feb. 2014, at 10:47, Alexander Holler <holler at ahsoftware.de> wrote:

> Am 31.01.2014 22:51, schrieb Thijs Alkemade:
> 
>> These use an incrementing counter to generate ids, starting from 0. This means
>> that, for example, roster retrieval always gets the same id and could be
>> spoofed by a fast enough attacker:
> 
> Could you elaborate how that attacker does send those spoofed stanzas?

Okay, "fast enough" isn't really accurate, you need to cheat to be faster
than someone's own server.

Suppose I want to target someone and I know the server they use, the account
there, the fixed resource they have set and that I have control over the
network my target is using.

I can see there's an outgoing connection to an XMPP server, but it's using TLS
so I can't directly manipulate it. However, the initial packets on a stream
usually have a set ordering, depending on the client. If I know the roster
retrieval is always the 3rd iq packet, and always the 7th TLS packet, then I
can delay the 7th TLS packet while I send an new packet to the target's
server:

    <iq type='result' id='2' to='target at domain.lit/Resource'>
        (evil spoofed roster contents here)
    </iq>

If the client doesn't check 'from' adresses properly, it won't notice this
reply didn't come from their own server, but from me.


A less complicated attack:

Suppose I'm in a MUC, I see you join and your client starts requesting vcards
for everyone in the MUC sequentially. I get request with id x, but I reply
with a spoofed image for requests x+1, x+2, x+3, etc. It's not guaranteed to
work as I need to be faster than the other clients, but as long as it can
occasionally work it's a vulnerability.

Thijs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.jabber.org/pipermail/security/attachments/20140201/6159274a/attachment.pgp>


More information about the Security mailing list