Am 01.02.2014 12:46, schrieb Thijs Alkemade:
On 1 feb. 2014, at 10:47, Alexander Holler <[email protected]> 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.
Regards,
Alexander Holler
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________
