文章来源：
http://www.isfocus.net
文章提交：legendz3 (antic01dmi1k_at_yahoo.com)
中文PDF版本：
http://www.isfocus.net/wendang/sshrp.pdf
利如刀割. SSHarp.
原著： stealth
stealth@segfault.net
翻译： 无用君
admin@root.com.cn
This translated document is an isfocus.net production. The
copyrights of the original articles belong to Stealth.
--[ 介绍
一般被认为非常强壮的Secure Shell (SSH)协议通常被不当的使用。特别是在大部分SSH
客户端中SSH1/SSH2互动性的实现通常会出现我们下面将提到的一些弱点。加之SSH2协议
本身也灵活得足以为攻击者提供一些有趣的部分。
对于否认声明，请查看本文的PDF版本(
http://segfault.net/~stealth/ssharp.pdf)。
文中提到的小程序将会在这篇文章发表一周后发布，这样可以给厂商一些时间检修自己的程
序（这相当琐细）来减少被攻击的可能性。
在这篇文章中，我将描述SSH客户端如何可认为它们丢了它们想连接的主机的主机密匙,就
算它们其实已经在已知主机列表中有了那台主机。其实这是因为一些在SSH设计中使SSH开
发者的工作变的更难但却可以提供特殊的保护或更多的灵活性的地方造成的。
在这篇文章中，我假设你们都有一些关于SSH是如何工作的基本知识。不过你并不需要完全
详细的理解理解它，因为攻击只是在握手过程中只有几个数据包被交换的时候成功。我同时
假设你熟悉一些普通的网络攻击例如Man in the Middle攻击，plaintext协议的挟持攻击
及重放攻击（replay attacks）等。
--[ 1 玩转标语
SSH的设计要求客户端和服务端在交流用来加密对话通道的密匙之前先交换标语。这个对于
双方都很重要，因为它决定了客户端和服务端将使用哪个协议来通讯。一个标语通常会像这
个样子：
SSH-1.99-OpenSSH_2.2.0p1
客户端得到一个标语并把它理解为“对我说SSH1或SSH2”。这是因为横杠后面有一个
“1”，也是所谓的远程主版本号。它允许客户端选择SSH1作为用于交流和以后解密的匙。
不过因为远程副版本号是“99”，所以客户端同样可能使用SSH2继续。（习惯上，一个远
程副版本号99和一个远程主版本号1表示该主机同时兼容两个协议。）
取决于客户端配置文件和命令行选项，他决定选择两个协议之一。假设这个用户没使用“-
1”或“-2”选项，大部分的客户端应该表现相同。这是因为各SSH厂商基本相同的配置文
件和它们里面所包含的语句：
Protocol 1,2
这使客户端选择SSH协议版本1。接下来发生的事情就很明显了。因为SSH客户端惯于使用
SSH1来与服务端对话，所以它很可能从来没有使用过SSH2。这点可能会被攻击者利用，攻
击者可以提示一个这样的标语给客户端：
SSH-2.00-TESO-SSH
客户端查询它的已知主机数据库并略过主机密匙，因为它只能找到服务端SSH1版本的密
匙。而从标语上来看，它将不允许继续使用SSH1来对话了（因为远程主版本号为2）。原
本SSH将会显示以下信息：
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA1 host key has just been changed.
The fingerprint for the RSA1 key sent by the remote host is
f3:cd:d9:fa:c4:c8:b2:3b:68:c5:38:4e:d4:b1:42:4f.
Please contact your system administrator.
中文意思：
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 警告: 远程主机鉴定已改变 @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
可能有人在做坏事
有人可以现在窃听你（man-in-the-middle攻击）！
也有可能RSA1主机密匙刚被改变。
远程主机送来的RSA1密匙指纹为
f3:cd:d9:fa:c4:c8:b2:3b:68:c5:38:4e:d4:b1:42:4f.
请联系你的系统管理员.
但在改变了标语后，它会让用户接受新的密匙：
Enabling compatibility mode for protocol 2.0
The authenticity of host 'lucifer (192.168.0.2)' can't be established.
DSA key fingerprint is ab:8a:18:15:67:04:18:34:ec:c9:ee:9b:89:b0:da:e6.
Are you sure you want to continue connecting (yes/no)?
中文意思：
为协议2.0启动兼容模式
无法确定主机'lucifer (192.168.0.2)'的真实性。
DSA密匙指纹为ab:8a:18:15:67:04:18:34:ec:c9:ee:9b:89:b0:da:e6。
你确定你想继续连接吗（是/不是）？
这时对于用户来说，输入"yes"要比修改已知主机文件并重启SSH客户端要简单的多。一但
用户接受新的密匙，攻击者的SSH服务端将记录登陆的用户名和密码，并将这个SSH连接转
移，这样以来用户就不会注意到他的帐户已经被别人拿到了。
我们描述的攻击并不只是个升级攻击，对于SSH2与SSH1对话的降级攻击它同样作效。如果
标语包含"2.0"，客户端只会使用SSH2与原来的服务端交谈，并且一般情况下它不知道服务
端的SSH1密匙因为它根本不会说SSH1。不过我们的MiM服务端会SSH1，并且提示一个客户
端不知道的密匙。
这个攻击对只支持一个协议的客户端（一般是SSH1）不起作用，因为它们只能实现第一个
部分。不过这种客户端非常少见。
如果客户端使用RSA鉴证，攻击者就不可能介入，因为他正对客户端交谈一个不同的协议。
换句话来说，攻击者从未对双方讲过相同版本的协议，因此不能发送或者拦截RSA 鉴定。
一个简单的MiM程序（ssharp）可以设置banner-hack并记录登陆信息。
--[ 2 -玩转密匙
如果有一个在不进行版本转换的情况下攻击SSH的办法就好了。因为版本转换使打破RSA鉴
证变的不可能实现。
再阅读SSH2的设计之后我们明白SSH2已经不再使用主机密匙来加密了（SSH1中，主机和
服务器密匙被送到客户端，然后客户端将用这些密匙加密过的链接密匙（session-key）送
回）。取代了客户端获得主机密匙通过将服务端送出的MAC（Message Authentication
Code消息身份验证代码：服务器计算的一组哈希数据包交换并用商议过的算法来对它进行
签名）与自己计算的哈希数字进行对比来检查是否有任何交换包被篡改。SSH2的设计已经
灵活到可以提供更多的静态算法来让MAC计算。尽管它指定在交换密匙的过程中，客户端和
服务器端交换一个用来保证数据包完整性的首选算法名单。通常DSA和RSA在使用：
stealth@liane:~> telnet 192.168.0.2 22
Trying 192.168.0.2...
Connected to 192.168.0.2.
Escape character is '^]'.
SSH-1.99-OpenSSH_2.2.0p1
SSH-2.0-client
`$es骡%9?愿4D=?拆ydiffie-hellman-group1-sha1ssh-dss...
我删除了一大堆字符并用"..."来代替了它们，因为真正有意思的部分是"ssh-dss"，这是服
务端用于MAC计算的最喜爱的算法。客户端连接到192.168.0.2，但无法得到一个用来计算
的RSA密匙因为服务器也没有。当然攻击者的MiM程序有一个RSA密匙，并只提供给RSA去
保证完整性：
stealth@liane:~> telnet 192.168.0.2 22
Trying 192.168.0.2...
Connected to 192.168.0.2.
Escape character is '^]'.
SSH-2.0-OpenSSH_2.9p1
SSH-2.0-client
at s縠u犊>vM矑E=diffie-hellman-group-exchange-sha1,
diffie-hellman-group1-sha1ssh-rsa...
一个连接到我们的MiM服务器上的SSH客户端会再一次的提示用户去接受新的密匙来代替解
决MiM发出的警告。
MiM服务器连接到原始的服务器上并了解到他在使用DSA。然后他便改变使用RSA密匙来与
用户交流。如果原始服务器同时提供DSA和RSA，MiM服务器将需要等待，直到客户端发送
它的首选算法并找一个算法作为它的第二选择。一个RFC规定必须由SSH2服务器来选择客
户端列表中他支持的第一算法，我们的MiM服务器将选择下一个并因此在客户端产生一个丢
失密匙的情况。这个将再一次产生yes/no提示，而不是警告信息。"ssharp"同时支持这个
key-hack模式。
--[ 3 – 对策
一个拥有RSA主机密匙的主机提供DSA主机密匙对现在的客户端来说根本没有什么。他们忽
略他们有一个那台主机的有效主机密匙，但却是另外一个密匙类型。SSH客户端同时应该解
决MiM警告如果他们了解到服务器的主机密匙有版本或者类型不匹配的情况。这很可能是有
些人在玩MiM游戏。在我的眼里这明显是一个SSH客户端软件的漏洞。
--[ 4 – 一个实现
网上已经流传了不少SSH1的MiM实现工具，例如dsniff或者ettercap。一般他们理解SSH
协议并把很多的精力放在了数据包集合和重集合或者转发的步骤中。其实这些东西都差不
多。Ssharp是建立在一个普通的OpenSSH守护进程上的，它被修改过来接受任何登陆/密码
组并为这些连接开始一个专用的shell：一个给了用户名，密码和一个真正的目的地IP的
SSH客户端。它在没有用户互动的情况下登陆到远程主机上，因为它是被绑定到MiM服务器
pty上的，所以它寻找那些进入他普通shell的用户。这样的话就不需要与SSH1或SSH2打
交道或更换密匙等。我们只需要与标语或者签名算法等打交道。
如果使用USE_MSS选项激活的模式来编译，ssharp将使用一个像会话的窗口来记录SSH客
户端，这样允许附带第三部分到已存在的SSH1或SSH2连接上。同样可能踢出合法用户并完
全控制整个会话。
--[ 5. 参考
[dsniff] 我所知道的第一个MiM实现工具。
http://www.monkey.org/~dugsong/dsniff
[ettercap] 一个不错的sniffer/mim工具。
http://ettercap.sourceforge.net
[ssharp] 本文中所提到的mim攻击工具。
http://stealth.7350.org/7350ssharp.tgz
[here] 本文的pdf版本。
http://stealth.7350.org/ssharp.pdf
--[ 6.译者心得
本来自己翻译东西从来是不写什么心得的，但Whitecell的大侠们都认为如果不写心得的话
就不是完全明白文章的意思，所以偶只好在这里乱凑几句了。
这篇文章是个德国的小伙写的，不知道文章自己的语法问题太多还是小弟我太菜，反正里面
有一大堆问题我看了3、4遍才搞明白，所以我修改并删除了一些段落，让它比较容易理解
一些。如果你跟我开始一样也很困惑的话就让我们先复习一下：
SSH一般的工作过程是这样的，一个客户端先记录服务器的公匙。如果一个新的密匙出现了
的话，客户端会报告给用户有可疑情况。不过如果服务器使用一个客户端从来没有使用过的
协议例如SSH1的话，出现的信息则只是要求用户接受新的密匙。所以攻击者可以通过提示
给客户端一个修改过的版本信息标语来进行对那些防范意识不够的用户的Man in the
Middle攻击。
同样的，如果如果攻击者在服务器边提供一个不同的MAC算法给客户端，会产生相同的效
果。
其实Man in the Middle出现在SSH中已经不是新鲜的事情了，SSH1中的缺陷使这种攻击
风靡了一段时间，有兴趣的朋友可以去看看以前那篇叫做《The End of SSL and SSH?》的
文章。这个漏洞和以前那个在第一次运行SSH时出现"warning, server's key has
changed, continue?"的漏洞类似，不过SSHarp和dsniff不同的地方在于由于SSHarp
是以一个守护进程的方式架设在服务器上的，所以它的嗅觉范围不会像dsniff一样只限制
于自己所在的子网内，不过缺点就是首先要在被嗅觉的主机上有一个合法帐户。不过只要漏
洞在，修改一下工具是算不了什么大问题的。
至于这个到底是漏洞还算是SSH中的一个功能的问题，我看还是由大家自己讨论吧。
