Sniffing traffic for replay attacks about chain33 HOT 31 CLOSED

实际上，这是一个打币接口，你修改了 过期时间相当于修改了 交易的内容，打两次币是正常的。一般来说，rpc 接口只允许有权限的人访问。

from chain33.

实际上你调用了两次rpc接口去发送币。

from chain33.

but if i don't know the -k arg and I just sniff traffic, I can send coin many times.
Suppose I implant a Trojan virus on your computer, the virus only to sniff traffic and then modify and send it, it will cause losses.

from chain33.

the -k should not appear in traffic

from chain33.

修改了交易内容之后的交易和原来的交易是不同的交易， 不算重播攻击。
签名在节点上进行是现在我们的节点是带钱包功能， 钱包的访问有两重限制

1. 需要钱包的密码
2. 在配置文件 chain33.toml 中 rpc 配置段中有 限制访问接口的 。 有个是IP的限制，一个接口的限制。 如下 whitelist=["127.0.0.1"]， jrpcFuncWhitelist=["*"]

from chain33.

目前我们如果在同一台机器上有木马的化，可以直接发送交易。这里 -k is not private key 是 address

from chain33.

所以不需要sniff，也可以调用接口发送币。

from chain33.

不过确实可以用更加安全一点的方法:

1. 开通 ssl

2. rpc 加上安全验证

后续可以支持这两个功能。

目前只是限制了IP address

from chain33.

@thereksfour 你有什么想法

from chain33.

目前 -k 这个选项有点 迷惑性，他可以填写 address 也可以填写 private key

from chain33.

@thereksfour Can you speak Chinese？

from chain33.

If you don't know Chinese, we will reply you in English.

from chain33.

当我调试类似的公链，像是 steemit 时，我发现他们是这样做的：他们在每个交易中放入一个随机数，在进行签名时，他们会计算这个交易的哈希值，如果已经被签名过，就不会在进行签名

from chain33.

所以我之前认为这是一个安全问题是因为，这里似乎没有对不同的交易进行区分，当调用 SignRawTx 时，如果 txhex 相同，依然会对交易进行签名

from chain33.

type Transaction struct {
	Execer    []byte     `protobuf:"bytes,1,opt,name=execer,proto3" json:"execer,omitempty"`
	Payload   []byte     `protobuf:"bytes,2,opt,name=payload,proto3" json:"payload,omitempty"`
	Signature *Signature `protobuf:"bytes,3,opt,name=signature,proto3" json:"signature,omitempty"`
	Fee       int64      `protobuf:"varint,4,opt,name=fee,proto3" json:"fee,omitempty"`
	Expire    int64      `protobuf:"varint,5,opt,name=expire,proto3" json:"expire,omitempty"`
	//随机ID，可以防止payload 相同的时候，交易重复
	Nonce int64 `protobuf:"varint,6,opt,name=nonce,proto3" json:"nonce,omitempty"`
	//对方地址，如果没有对方地址，可以为空
	To                   string   `protobuf:"bytes,7,opt,name=to,proto3" json:"to,omitempty"`
	GroupCount           int32    `protobuf:"varint,8,opt,name=groupCount,proto3" json:"groupCount,omitempty"`
	Header               []byte   `protobuf:"bytes,9,opt,name=header,proto3" json:"header,omitempty"`
	Next                 []byte   `protobuf:"bytes,10,opt,name=next,proto3" json:"next,omitempty"`
	XXX_NoUnkeyedLiteral struct{} `json:"-"`
	XXX_unrecognized     []byte   `json:"-"`
	XXX_sizecache        int32    `json:"-"`
}

from chain33.

你修改了 Expire 交易 hash 就会改变，Transaction 的字段有点多，不仅仅有 Payload 还有很多其他的字段，除了 Signature 其他的字段都会影响交易hash，你说的随机数可能就是我们这里的 Nonce

from chain33.

这个问题我们保持关注。后面开通 ssl 尽量保证没有办法 sniff。

from chain33.

{
	"method": "Chain33.SignRawTx",
	"params": [
		{
			"addr": "1CbEVT9RnM5oZhWMj4fxUrJX94VtRotzvs",
			"txHex": "0a05636f696e73124618010a421080d0dbc3f4021a157465737420666f72207472616e736665722062747922223147684d5a3776704545474c556d786366384b524e65646a704b5a5946757339644a20a08d0630e5da91e4fde19fd4013a223147684d5a3776704545474c556d786366384b524e65646a704b5a5946757339644a",
			"expire": "120s"
		}
	],
	"id": 0
}

这是调用 SignRawTx 时发送的一段数据，我只是修改了 expire 字段，改变了整个交易的哈希，并没有修改 txHex 这个字段的任何值，但是看上去并没有对这个字段进行校验，导致相同的 txHex 仍然可以被签名

from chain33.

是的，我们设计的: 交易应该快速失败，所以，默认每个交易加了120s 就过期。如果一个交易过期了，私钥的控制者，可以重新签名重新发送这个交易，当前前提是你需要有私钥。

from chain33.

SignRawTx 类似 bitcoin 的 signrawtransaction 接口，不会再校验 交易是否被签名过了。而是一个无状态的设计。

from chain33.

实际上能调用 Chain33.SignRawTx 也就意味着可以 dump private key 所以，我个人认为，没有必要在这个位置再做控制，而是要加强，对私钥的一个管理，rpc 权限安全的一个管理。

from chain33.

but if i don't know the -k arg and I just sniff traffic, I can send coin many times.
Suppose I implant a Trojan virus on your computer, the virus only to sniff traffic and then modify and send it, it will cause losses.

实际你提供的情况是修改原交易,这个是不是主要原因， 因为在其他环境下也是可以创建交易。 木马是获得了钱包的访问权限。

如果木马控制了在线钱包节点， 那么不只是可以发送转账。 避免这种情况， 可以用离线钱包。在离线钱包里对交易签名后， 再用U盘复制到在线环境发送。

from chain33.

but if i don't know the -k arg and I just sniff traffic, I can send coin many times.
Suppose I implant a Trojan virus on your computer, the virus only to sniff traffic and then modify and send it, it will cause losses.

实际你提供的情况是修改原交易,这个是不是主要原因， 因为在其他环境下也是可以创建交易。 木马是获得了钱包的访问权限。

如果木马控制了在线钱包节点， 那么不只是可以发送转账。 避免这种情况， 可以用离线钱包。在离线钱包里对交易签名后， 再用U盘复制到在线环境发送。

sorry，我之前认为 -k 是私钥，所以认为他会有一些问题

from chain33.

这个的确比较迷惑人的一个选项

from chain33.

其实我不太会调试 go 这种语言，只是凭之前调试的 c++ 的公链的经验，所以不太明白对于内部细节的处理。我可以开一个issue询问一下关于如何调试的问题吗？

from chain33.

but if i don't know the -k arg and I just sniff traffic, I can send coin many times.
Suppose I implant a Trojan virus on your computer, the virus only to sniff traffic and then modify and send it, it will cause losses.

It is not the main reason to modify transaction, because you can create transaction anywhere.
In your case, Trojan controls the online wallet node, Trojan can not only do some traffic. Chain33 support offline wallet. You can use offline wallet and not import private key to online node.

from chain33.

但是不可否认的是，这种设计在一些极端情况下可能会出现安全问题，比如不当的配置等等，所以我不认为这种设计是好的，我能想出的更好的办法是应该在 SignRawTx 中加入对 txHex 的校验。

from chain33.

@thereksfour 调试，你说的是单步调试吗？

from chain33.

是这样的，我用 goland 调试 chain33，调试 chain33-cli 时，发现执行到
33cn/chain33/system/dapp/commands/send.go 中第 69 行

err = cmdCreate.Run()

我没有办法跟进这句代码开启的子进程中去，即使我在这个子进程会执行到的地方下了断点，

func CreateRawTx(cmd *cobra.Command, to string, amount float64, note string, isWithdraw bool, tokenSymbol, execName string) (string, error) {
	if amount < 0 {   // breakpoint here
		return "", types.ErrAmount
	}
	if float64(types.MaxCoin/types.Coin) < amount {
		return "", types.ErrAmount
	}

这也是我在之前报告的溢出的 issue 中，没有定位到正确代码位置的原因，不过即使我在 patch 的地方下了断点，依旧无法断下

from chain33.

一般go语言的调试，我也不用，主要是通过看代码，总结模式，加日志的方式来分析代码。

from chain33.

谢谢，希望继续关注这个问题。

from chain33.