[jdev] XMPPloit

Peter Saint-Andre stpeter at stpeter.im
Thu Aug 16 12:32:11 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/16/12 6:07 AM, Kevin Smith wrote:
> On Thu, Aug 16, 2012 at 1:04 PM, Peter Saint-Andre
> <stpeter at stpeter.im> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 8/16/12 5:48 AM, Kevin Smith wrote:
>>> On Thu, Aug 16, 2012 at 12:36 PM, Pedro Melo 
>>> <melo at simplicidade.org> wrote:
>>>> Hi,
>>>> 
>>>> On Thu, Aug 16, 2012 at 11:12 AM, Kevin Smith 
>>>> <kevin at kismith.co.uk> wrote:
>>>>> On Thu, Aug 16, 2012 at 10:50 AM, Pedro Melo 
>>>>> <melo at simplicidade.org> wrote:
>>>>>> came across this today and I haven't seen it mentioned
>>>>>> here:
>>>>>> 
>>>>>> http://www.pentestit.com/xmpploit-tool-attack-xmpp-connections/
>>>>>>
>>>>>>
>>>>>>
>>
>>>>>> 
I haven't tested it yet, and the article is strong on claims and light
>>>>>> on explanations on how it works, so take it with a grain
>>>>>> of salt.
>>>>> 
>>>>> The claims they make seem sensible - everyone's known
>>>>> about the possibility of such downgrade attacks since
>>>>> forever - which is why clients generally won't allow both
>>>>> PLAIN and non-TLS at the same time. What clients really
>>>>> need to do is cert pinning and mech pinning to prevent
>>>>> these exploits in all but the first-login case.
>>>> 
>>>> Yes. The author as a small demo video screencast of the tool
>>>> in action here:
>>>> 
>>>> http://www.ldelgado.es/index.php?dir=aplicaciones/xmpploit
>>>> 
>>>> The initial plain-text part of the XMPP handshake will allow
>>>> a MITM attack to downgrade the security. Only cert and mech
>>>> pinning would work here.
>>> 
>>> It'll allow it to downgrade to no-TLS, but not to PLAIN, as 
>>> clients shouldn't be allowing PLAIN over connections without
>>> TLS.
>> 
>> Sure, that's the proper policy for all clients. (I don't see it
>> as "mechanism pinning" so much as client policy.)
> 
> This isn't mechanism pinning - mechanism pinning would be
> remembering the previously used mechs and warning when they become
> unavailable.
> 
> I was suggesting that all clients should have a policy as above,
> but that mech pinning would be better.

Seems sensible, yes.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAs6EsACgkQNL8k5A2w/vzsFgCePi1rU/I8vaKj2f6cEjamNixJ
7DcAoJqfemlrgoMk5W0Qxm4w0XK9qaL2
=clIe
-----END PGP SIGNATURE-----


More information about the JDev mailing list