git 协议可能被中间人攻击吗？

git

中间人

clone

攻击

27 条回复 • 2022-09-26 10:11:19 +08:00

1

kkeep

2022-09-24 20:24:10 +08:00 via Android

有意思，你这个是基于 ssh 的？

2

yankebupt

2022-09-24 20:24:37 +08:00

The downside of the Git protocol is the lack of authentication.
应该是有的

3

charlie21

2022-09-24 20:27:15 +08:00 via iPhone

commit 是可以在提交之前签名并在 origin 作 verified 的，用 gpg
https://stackoverflow.com/questions/10077996/sign-git-commits-with-gpg

4

x199ian

OP

2022-09-24 20:42:40 +08:00

@kkeep 应该不是
@yankebupt 我也觉得有，但是好像资料比较少，我没找到更具体的描述
@charlie21 但是协议本身是不是不保证安全呢

5

dem0ns

2022-09-24 20:46:30 +08:00

1

git:// 就是基于 ssh 协议的，中间人攻击 /防御和 ssh 是一致的，首次连接的时候会进行指纹确认，指纹信息会保存到 known_hosts 文件，下次连接的时候系统会对比指纹的，只有指纹一致才会进行数据传输

6

Trim21

2022-09-24 20:47:32 +08:00

会，git 协议是没加密的 tcp ，作为本地和服务器 git 命令之间的 pipe 进行远程代码同步。所以是有可能被中间人的。

7

moen

2022-09-24 20:52:20 +08:00

看 https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols 就知道，git 协议是为「公开的大型项目」而设计的，它不需要 HTTP 协议的各种限制，也不需要 SSH 的加密和认证机制，git 协议和 SSH 都是建立在同一层的。简单说 git 协议就是明文传输的，可以被中间人攻击

8

x199ian

OP

2022-09-24 20:53:43 +08:00 via Android

@dem0ns #5 但是我之前试过，应该没有确认指纹
@Trim21 #6 明白了，谢谢

9

dem0ns

2022-09-24 20:55:22 +08:00

@x199ian 你可以检查下你的 known_hosts 文件是否有 git.busybox.net

10

crab

2022-09-24 20:55:27 +08:00

@x199ian 免密码首次登陆有公钥指纹提示的啊。

11

x199ian

OP

2022-09-24 20:57:06 +08:00 via Android

@moen #7 谢谢，那么似乎目前应该避免使 git 协议

12

Trim21

2022-09-24 20:58:36 +08:00 via Android

2

@dem0ns 你把 git@和 git://弄混了吧，前者是 ssh 协议只不过省略了

13

dem0ns

2022-09-24 21:01:58 +08:00

@Trim21 确实 =.= 一直以为是做了个 alias

14

x199ian

OP

2022-09-24 21:08:32 +08:00 via Android

@dem0ns #9
@crab #10 确实没有确认指纹，known_hosts 里也没有

15

dem0ns

2022-09-24 21:11:59 +08:00

2

抓了个包，发现就是明文的，我在前面说的错了，误以为是 ssh

部分流量
003dgit-upload-pack /busybox.host=<请不要在每一个回复中都包括外链，这看起来像是在 spamming>.version=2.000eversion 2
0015agent=git/2.31.1
0013ls-refs=unborn
0012fetch=shallow
0012server-option
0017object-format=sha1
00000014command=ls-refs
0024agent=git/2.37.0.(Apple.Git-136)0016object-format=sha100010009peel
000csymrefs
000bunborn
0014ref-prefix HEAD
001bref-prefix refs/heads/
001aref-prefix refs/tags/
00000052c8c1fcdba163f264a503380bc63485aacd09214c HEAD symref-target:refs/heads/master
0044267b925bb46d53472d28e88edc7d837c5918612b refs/heads/0_60_stable
00442f8880d2333c0ff9229a2b386eb652952010d7e6 refs/heads/1_00_stable
004a1fb759908f0cc38fd0b763fb7908eef515f4af33 refs/heads/1_00_stable_10817
0044e9f8b2f830bf0273d0d51f56d24da84b955e0df5 refs/heads/1_10_stable
00444a81fe4173bf5029058253cf0be194c23a5ad369 refs/heads/1_11_stable
00449b8f810d38a720bca94af864e2960de91aae3a29 refs/heads/1_12_stable
00448f0c89e05a7b52f8c5ae7b451de6fd50732aeb45 refs/heads/1_13_stable
0044757e46252c004c9170dfc748a78f42abd416cf50 refs/heads/1_14_stable
004475919134e1fbd0c4dc60cab8fb5a7746c241123b refs/heads/1_15_stable
00446b5656e9bbc8c202dc323aecf54592185f9e129a refs/heads/1_16_stable
0044db4171d842e9bdc1c2903a9d5cfea053aceb35a2 refs/heads/1_17_stable
00442e79bc6c77560d4460847a459857039774de004a refs/heads/1_18_stable
0044f99811908419608e3ab81393d0177cc456101e4b refs/heads/1_19_stable
0043bdea7807b1f045a230a2efab8d85fa21a9aa3e48 refs/heads/1_1_stable
0044b1cec5003b73080a8aa7ea277621bf1c71c3e8d6 refs/heads/1_20_stable
0044e73f3c1d3d83699b723251f7e6a981021ce75475 refs/heads/1_21_stable
004428dd64a0e1a9cffcde7799f2849b66c0e16bb9cc refs/heads/1_22_stable
0044be947c4d97c0dacb703a6f24dd813ff6dd3a33b6 refs/heads/1_23_stable

16

dem0ns

2022-09-24 21:13:18 +08:00

002d.Compressing objects: 100% (28643/28643)
0034.Compressing objects: 100% (28643/28643), done.
[email protected]{h.x.'..b.
....qj.........Hl....1.O!"y.-.l..&.lFD..A28.y....m.:[email protected]".>Q...<.8;.....kEG......;|V....^.......m.Y*.T.9..
.s.Y...O.h.~.Zz..!..........J/.v.M.... DI..Jm.]...4N'.........L.l..-x..R.j.0...+tl .%...J.....k.Kc[D..$g..:IO=%..0.Yx.a&.D*.......]7..F..U......!AK.j.....RH).N.9.....U). ..e.....q$0...........n...A...7.........Q~z.|!.EU....`.,....."!........F38Hs.-.....)R<%[email protected]\.F...f{
.z.P..."...aQ^q.%...!..r8+..nX5?D......h.....[.2F...Y..q....0.3..nI..=......K.v......b...........7...h..x....n. .D{....Z...j.m.2J.)....d...I...6.Rmy..3.."0\.R;g..};z.........j..J"J....
.+C.w..F...T^89..G.v...h..m}...7..&x.j...x.&..Z.J..G.. :.uZ....3..%.+.x..Wx.X).........}.r."-.bs..%ZI#.? ..Z{....uE7CH...b..c.T...SNqg.5L........]._.......}S..x...Mj.0...:....lG.TJ..7(t.B.I#[T..-7..k.BW.....x..0e".. .dm......;a.kC.
o.ip..v..p.T..l.rBH-P........;......Q..2. ^(]gx.8Sz....p.CZ..}

PACK 开始是压缩信息

17

x199ian

OP

2022-09-24 21:30:53 +08:00 via Android

@dem0ns #15 谢谢看来应该避免使用 git 协议

18

agagega

2022-09-24 21:32:11 +08:00

Git 存数据的方式有点像区块链，一环套一环，所以即使被中间人攻击了，发现 hash 对不上很容易就发现了

19

keith1126

2022-09-24 21:38:36 +08:00

@agagega #18

区块链之所以防篡改并不是因为用了哈希，而是用了计算复杂度高的哈希。Git 用的哈希毫无密码学强度可言，完全可以在篡改后从第一个 commit 开始全部重算一遍哈希。

20

timpaik

2022-09-24 22:22:40 +08:00 via Android

@keith1126 所以 git 的 commit 一般会用 gpg 签名啊

21

lambdaq

2022-09-24 22:27:22 +08:00

@x199ian git 的「协议」只是一种格式，可以通过 ssh 传输，也可以通过 https 传输，当你用 http 协议传输肯定能被容易中间人的。

22

keith1126

2022-09-24 22:29:13 +08:00

@timpaik #20

并没有吧，反正据我观察，用 GPG 签名的人并不多。

而且另一方面，由于 GPG 签名不是强制的+普及度不高，当你遇到一个没有签名的 commit ，大概率只会觉得是对方没签名，而不是被篡改了。

23

Tobias747

2022-09-24 23:22:41 +08:00

GitHub 官方八月份已经支持显示 SSH commit verification, 建议开启[SSH commit verification now supported | GitHub Changelog]( https://github.blog/changelog/2022-08-23-ssh-commit-verification-now-supported/)

24

Greenm

2022-09-24 23:29:25 +08:00

git 不关注应用层的安全性，所以原则上是有风险的。

主流的 SaaS 服务商部署的 git 都是走的 SSH 或者 https ，这两个协议能够较好的防止中间人，如 github, gitlab 等。但你如果自建 git 服务器，那就无法避免被中间人。

25

zk8802

2022-09-25 03:54:27 +08:00 via iPhone

1

Git 被中间人攻击之后可能被用来直接攻击客户端，而不仅仅是修改 commit 历史。参见 CVE-2018-11233 和 CVE-2018-11235 。

不应该在不安全的网络环境下使用 Git （尤其很多人习惯性忽略 SSH host key 不匹配的提示）。

26

kkeep

2022-09-25 21:38:03 +08:00 via Android

@keith1126 防篡改不是高强度的 hash 区块链也可以从第一个开始伪造，但是别人不认。

我记得是这样？

27

forcecharlie

2022-09-26 10:11:19 +08:00

1

git 协议与 Git Over SSH/ Git Over HTTP 不一样，git 协议是非安全协议，传输流没有加密环节，公网传输可能是不安全的，Git Over SSH (ssh:// or [email protected]:some/some.git) 走的是 SSH 安全通道，Git Over HTTP 可以走 https 。

很多代码托管平台并不开放 git 协议，但可以使用 git 协议作为内部存储节点之间的传输协议。

利益相关：从事 git 代码托管开发多年。