在本系列文章的第二部分中，我们描述了无线客户端安全性的改进如何削弱了我们对现代设备使用 Karma 攻击的能力(参见: https://posts.specterops.io/modern-wireless-attacks-pt-II-mana-and-known-beacon-attacks-97a359d385f9)。 然后我们讨论了 MANA，Loud 模式 MANA 攻击和已知信标攻击，它们可以用来克服这些改进。

在文本中，我们将讨论如何在 EAPHammer 中使用管理帧 ACL (MFACL)来对前面章节中描述的攻击技术进行粒度探测级控制(参见: https://github.com/s0lst1c3/EAPHammer )。 我们还将讨论这些攻击如何在算法级别工作，并深入了解使用 MFACL 如何影响 EAPHammer 的运行时效率。

管理帧ACL (MFACL)

Karma，MANA和已知信标攻击本质上是混乱的技术，可以很容易地导致你周围的所有设备连接到你的伪基站，无论设备是否在你当前的操作范围内。 即使是邪恶的伪基站克隆攻击在某些情况下也会遇到这个问题，例如当伪基站被赋予一个常用的 ESSID 时。

这带来了两个问题: 不仅是针对任意附近的设备本质上是非法的，它也不利于你的工作能力。 从攻击员的角度来看，伪基站攻击是有用的，我们需要能够精确地执行它们。 这意味着要限制它们的影响力和可见度，使它们仅限于我们预期的目标。

MFACL 算法

管理帧访问控制列表(MFACL)是解决这一问题的方案。 MFACL 是访问控制列表(ACL) ，在处理传入的探测请求帧之前由访问点进行检查。 它们既可以是基于 SSID 的，也可以是基于 MAC 的，可以在白名单模式或黑名单模式下使用。

下表列出了不同类型的 MFACL，以及它们使用时的效果:

需要注意的是，MFACL 不能用来限制信标帧，所以如果你正在执行以下任何技术，它们不能阻止客户端设备看到或尝试连接到你的伪基站:

· 伪基站克隆攻击

· loud MANA 攻击

· 已知信标攻击

基于 MAC 的 MFACL 在 EAPHammer 中的应用

Hostapd 从2019年4月发布的版本2.8开始就为基于 MAC 的 MFACL 提供了本地支持。 在将它们整合到 EAPHammer 中时，这为我节省了大量的工作，因为我必须对 hostapd 进行的唯一修改是与添加通配符支持。 有趣的是，Sensepost 的 hostapd-mana 从2016年开始支持基于 MAC 的 MFACL，从2017年开始支持基于 SSID 的 MFACL，这远早于 MFACL 在 vanilla hostapd 中的应用(这绝对不是他们第一次领先于潮流)。

基于 MAC 的 MFACL 可以以文本文件的形式传递给 EAPHammer，每行包含一个 MAC 地址:

# example EAPHammer MFACL file
78:f0:97:fc:b5:36
9a:35:e1:01:4f:cf
69:19:14:60:20:45
ce:52:b8:*:*:*
1f:5d:6b:c8:96:d2
c6:c8:64:79:e8:3b
32:99:49:e8:50:23
f5:e2:fe:d1:e2:78

注意上面示例中通配符的使用。 你可以用一个通配符替换任何八位元组，这样你就可以做一些简单的事情，比如用一个特定的 OUI 忽略来自任何设备的探测请求。 这在处理使用 MAC 地址随机化的设备时非常有用(尽管 EAPHammer 的实现不是一个完整的解决方案，因为不够健壮的 MAC 模式匹配和无法使用指纹设备)。 需要指出的是，这并不是 EAPHammer 的一个完全独特的功能，因为 hostapd-mana 和 airodump-ng 已经使用 bitmask 做了类似的事情很多年了。 实际上，EAPHammer 最终在运行时将通配符转换为位掩码，因此底层的实现非常相似。

一旦你创建了 MFACL 文件，你可以使用‘–mac-whitelist’标志或者‘–mac-blacklist’标志将其传递给 EAPHammer:

# use MFACL whitelisting
./eaphammer -i wlan0 --essid exampleCorp --cloaking full --karma --mac-whitelist /path/to/mac/whitelist/file.txt
# use MFACL blacklisting
./eaphammer -i wlan0 --essid exampleCorp --cloaking full --karma --mac-blacklist /path/to/mac/blacklist/file.txt

基于 MAC 的 MFACL 对运行时效率的影响

由于基于 MAC 的 MFACL 是 vanilla hostapd 的内置特性，因此它们进行了大量优化。 Vanilla hostapd 接受一个 MAC 地址列表作为配置参数，将单个 MAC 地址转换为字节数组，并在初始化基站之前将字节数组存储在排序的链表中。

基站启动并运行后，将使用二进制搜索执行 ACL 查找。 这种情况下产生最坏的情况的运行时效率是 O(log n)，其中 n 是 ACL 中的条目数。 比较是使用 os_memcmp 完成的，这是 Linux 必须提供的比较功能中最优化的一个。 尽管如此，使用 MFACL 可能仍然会降低 AP 的速度，特别是在频谱拥挤的密集城市环境中。 具有讽刺意味的是，在这样的环境中使用 MFACL 特别重要，因此我个人的建议是尽量缩短 MFACL，以避免处理时间过长。

实际的二进制搜索代码位于 hostapd 的源代码的‘src/ap/ap_config.c'文件中的‘hostapd_maclist_found()'函数中。 从程序员的角度来看，这绝对是一个绝佳的机会来见证计算机科学的基本概念在实际环境中的使用 :

912 int hostapd_maclist_found(struct mac_acl_entry *list, int num_entries,
913               const u8 *addr, struct vlan_description *vlan_id)
914 {
915     int start, end, middle, res;
916
917     start = 0;
918     end = num_entries - 1;
919
920     while (start <= end) {
921         middle = (start + end) / 2;
922         res = os_memcmp(list[middle].addr, addr, ETH_ALEN);
923         if (res == 0) {
924             if (vlan_id)
925                 *vlan_id = list[middle].vlan_id;
926             return 1;
927         }
928         if (res < 0)
929             start = middle + 1;
930         else
931             end = middle - 1;
932     }
933
934     return 0;
935 }

不幸的是，在混合使用通配符时，实际上不能执行简单的二分查找。 为了处理通配符问题，EAPHammer 更新的‘hostapd_maclist_found()'函数首先检查是否存在表示是否设置了通配符的标志。 如果将标志设置为 true，则该函数返回线性搜索。 否则，将使用二进制搜索。 我试图让线性搜索尽可能简单，并确保尽可能利用“os_memcpy()”和“os_memcmp()”。

851     if ( eaphammer_global_conf.acl_has_wildcards ) {
852
853         // fall back to linear search if list contains wildcards
854         for (i = 0; i < num_entries; i++) {
855
856
857             // we need to use os_memcpy to copy addr into addr_cpy, since
858             // addr is a constant pointer
859             os_memcpy(addr_cpy, addr, ETH_ALEN);
860
861             // apply current entry's bitmask to addr_cpy
862             for (j = 0; j < ETH_ALEN; addr_cpy[j] &= list[i].mask[j++]);
863
864             res = os_memcmp(list[i].addr, addr_cpy, ETH_ALEN);
865             if (res == 0) {
866                 if (vlan_id) {
867                     *vlan_id = list[i].vlan_id;
868                 }
869                 return 1;
870             }
871         }
872     }
873     else {
874
875         // no wildcards? awesome - do the binary search
876         start = 0;
877         end = num_entries - 1;
878
879         while (start <= end) {
880             middle = (start + end) / 2;
881             res = os_memcmp(list[middle].addr, addr, ETH_ALEN);
882             if (res == 0) {
883                 if (vlan_id) {
884                     *vlan_id = list[middle].vlan_id;
885                 }
886                 return 1;
887             }
888             if (res < 0) {
889                 start = middle + 1;
890             }
891             else {
892                 end = middle - 1;
893             }
894         }
895     }
896
897     return 0;
898 }

local/hostapd-eaphammer/src/ap/ap_config.c (source: eaphammer )[9]

在使用 EAPHammer 的基于 MAC 的 MFACL 功能时，需要记住这一点，因为它直接影响工具的运行时效率。 当使用通配符时，EAPHammer 的 MAC 地址 ACL 查找的最坏情况下的运行时效率从 O(log n)下降到O(n)，后者要慢得多。 再次强调，这应该不会造成太大的差别，除非你在一个人口密集的环境中，并且过度使用 ACL。

也许可以使用不同的容器结构和算法来执行更有效的通配符搜索(我们想到的是有向无环词图)。 但正如他们所说，过早的优化是一切罪恶的根源。 直到我开始在Github上收到问题，抱怨探测响应时间过长，而且很明显搜索算法不是问题所在，否则我可能不会自己找麻烦，除非我真的很无聊。

基于 ESSID 的 MFACL 在 EAPHammer 中的应用

基于 ESSID 的 MFACL 目前并不存在于 vanilla hostapd 中，但自2017年以来就存在于 hostapd-mana 中，自2019年10月以来存在于 EAPHammer 中。 与基于 MAC 的 MFACL 一样，基于 ESSID 的 MFACL 可以以文本文件的形式传递给 EAPHammer，每行只有一个条目:

# example ESSID-based MFACL file
apples
oranges
grapes
pears

EAPHammer 目前不支持其基于 ESSID 的 MFACL 的通配符，尽管将来可能会根据可行性和用户需求而改变。

需要注意的是，EAPHammer 将允许你在文件的每一行的开头和结尾处放置空格字符，并将此空格解释为 ESSID 的一部分。 换句话说，在生产使用 ACL 之前，一定要校对基于 SSID 的 ACL (我是否需要告诉你这一点?) .

一旦你创建了你的 MFACL 文件，你可以使用’–ssid-whitelist’标志或者’–ssid-blacklist’标志把它传递给 EAPHammer:

# use MFACL whitelisting
./eaphammer -i wlan0 --essid hackresponsibly --cloaking full --karma --ssid-whitelist /path/to/mac/whitelist/file.txt
# use MFACL blacklisting
./eaphammer -i wlan0 --essid hackresponsibly --cloaking full --karma --ssid-blacklist /path/to/mac/blacklist/file.txt

基于 SSID 的 MFACL 对运行时效率的影响

当使用基于 SSID 的 MFACL 时，访问点可能会受到性能影响，这种性能影响可能比使用基于 MAC 的 MFACL 时更明显(是由于字符串比较的原因)。 与基于 MAC 的 ACL 一样，只要 ACL 不是不合理的长度，这不应该是一个大问题。 然而，这仍然是需要注意的事情。

总结

本系列博文的第三部分到此结束。 我们将以第四部分结束本系列博文，在第四部分中，我们将向无线攻击实践人员介绍一些基本的谍报技术建议，以及一些用于侦测伪基站攻击的高级防御建议。

参考资料

[1] https://w1.fi/cgit/hostap/tree/src/ap/ap_config.c?h=hostap_2_8
[2] https://w1.fi/cgit/hostap/tree/src/ap/beacon.c?h=hostap_2_8
[3] https://github.com/sensepost/hostapd-mana/commit/6f07621e40e4c0272215c5502352974c7ce8d2f0
[4] https://github.com/sensepost/hostapd-mana/commit/5420e7843cdfbccc083f598f9418291baff3dc6d
[5] http://aircrack-ng.org/doku.php?id=airodump-ng
[6] https://sensepost.com/blog/2016/handling-randomised-mac-addresses-in-mana/
[7] https://github.com/s0lst1c3/eaphammer/blob/master/local/hostapd-eaphammer/hostapd/config_file.c
[8] https://w1.fi/cgit/hostap/tree/hostapd/config_file.c?h=hostap_2_8
[9] https://github.com/s0lst1c3/eaphammer/blob/master/local/hostapd-eaphammer/src/ap/ap_config.c
[10] https://github.com/s0lst1c3/eaphammer/commit/6a421a0edf637fd4f336b7a5dadeb4c17e0a313b

本文翻译自：https://posts.specterops.io/modern-wireless-tradecraft-pt-iii-management-frame-access-control-lists-mfacls-22ca7f314a38如若转载，请注明原文地址： https://www.4hou.com/system/21737.html