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

Alexander Holler holler at ahsoftware.de
Sat Feb 1 14:21:26 UTC 2014


Am 01.02.2014 13:59, schrieb 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.

I'm able to read. How do you send that reply?

Alexander Holler



More information about the Security mailing list