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

[Thijs Alkemade]

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

> Am 01.02.2014 12:46, schrieb Thijs Alkemade:
>> 
>> 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:
> 
> Hmm, How you do replace a packet in a TLS stream?
> 
> I don't consider the id (or even the resource name as mentioned in another mail) as part of the security concept of XMPP.
> 
> If you are able to inject or replace packets in a stream, almost everything can be done.
> 
> Maybe I miss something important here.

I don’t replace the packet, try to read what I write.

I only *delay* one TLS packet to give me enough time to send a reply before
the query arrives at the server.

Thijs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20140201/c14d3537/attachment.html>
-------------- 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: <https://www.jabber.org/jdev/attachments/20140201/c14d3537/attachment.pgp>