Nzyme is a new Open Source software, created in a spare time by CTO Graylog Lennart Koopmann. In March this year, version 1.0 of “Kyle Canyon” was released.
Nzyme is used to detect threats to wireless networks and belongs to the family of Wireless Intrusion Detection System (WIDS). This is probably the most interesting and polished open source WIDS project.
The most important functions of nzyme include:
- detection of malicious Access Points (AP);
- detection of known platforms used to attack wireless networks (WiFi Pineapple, Pwnagotchi, Wifiphisher);
- AP configuration error detection.
In this article I will try to explain why we need a WIDS system at all, how to install and configure nzyme and how to use it.
Malicious Access Points – Who benefits from it?
Attacks on wireless networks, especially on their clients, allow hackers to face different scenarios and are also often used in security audits. Devices and platforms for carrying out such attacks are very popular. An example of the use of WiFi Pineapple can be seen in a popular comedy series, Silicon Valley.
On the other hand, in the real world in 2018, the US Department of Justice accused seven hackers of working on behalf of the Russian GRU agency. They were supposed to carry out attacks targeting, among others, anti-doping agencies in Brazil and Canada, a company that produces devices that use nuclear energy, and a chemical laboratory in Switzerland. It was confirmed that the aforementioned Pineapple WiFi was used during the attacks.
* A photo posted by the US Department of Justice showing equipment found in a GRU agent-hired car
How are such attacks carried out? An attacker within the range of a Wi-Fi network must first force a victim, for example a company employee, to connect to a malicious access point issued by them.
How is connection forced?
In order for a victim to connect to the malicious AP, the attacker can use several techniques. Below I present a brief description of popular types of them.
Evil Twin
Creating an “evil twin” is all about cloning the traits of the real AP. Thus, the attacker copies:
- network name – Service Set Identifier (SSID),
- physical address of the AP – Basic Service Set Identifier (BSSID),
- an authentication method, for example WPA2-EAP-PEAP.
For optimal network connectivity, Wi-Fi devices use the 802.11k and 802.11r protocols, which allow switching between available APs in a way that is unnoticeable to the user. If the created Evil Twin offers a better signal, the device will automatically connect to it, going through the authentication process again.
Karma and MANA
To explain exactly what these attack techniques are, let’s first discuss a few things:
- Preferred Network List (PNL) – each Wi-Fi device has a list of networks it has connected to in the past. This list includes information about the SSID, BSSID, and network security. Based on this list, the device can automatically connect to available, known networks.
- Active Scanning – one of the network selection mechanisms defined by the 802.11 standard. The client is actively looking for available networks to connect to. It can do this in two ways:
- Direct Probing – the client is actively sending Probe Request frames. Based on the PNL, the frames contain the name of the network that the client is looking for. The AP receives the frame, verifies the network name and if it matches its name, it responds with a Probe Response frame. Connection is established.
- Broadcast Probing (Null Probing) – similar to above, the device is actively sending Probe Request frames. However, the network name is not sent in the frames. All APs that are in range respond to Probe Response with their own name. The client compares the returned netnames with the known networks in the PNL. In case of compliance, it connects to the AP.
- Passive Scanning – one of the network selection mechanisms defined by the 802.11 standard. The client listens on subsequent channels, looking for Beacon frames sent by the AP. If the frame contains a PNL-compliant network name, the client connects.
The KARMA attack takes advantage of a fairly obvious weakness in the Direct Probing mechanism. The client himself reveals his PNL, and the decision on the answer lies with the AP. In this attack, the malicious AP responds to every Probe Request.
The KARMA attack, however, is ineffective against current devices. For security and privacy reasons, newer devices behave differently and do not connect to an AP that has not previously responded to Broadcast Probing or only use Passive Scanning.
The MANA attack is a newer version of the KARMA attack. During the MANA attack, the malicious AP does not respond to the Direct Probe frame immediately, but saves the client’s BSSID and the expected network SSID in the memory. Knowing these values, it is able to correctly answer the Broadcast Probe. However, if the client uses Passive Scanning, the attacker needs to use a different technique.
Known Beacon
In this attack, the malicious AP has a list of potential SSIDs with which the attacked client may try to connect. Based on the dictionary, Beacon frames are sent with possible network names. If the attacker correctly guesses the expected network name, the client will try to connect to the malicious AP.
Free Wi-Fi!
Finally – the least demanding technique. By displaying an open network with an attractive name near an office where several hundred people work, you can count on the possibility that one of the employees will want to use it.
What happens when the connection is made?
Creating a properly configured malicious AP carries many possibilities. Some of them are presented below.
Taking over login details
A popular scenario for attacking WPA2-EAP-PEAP secured corporate networks is the exposure of Evil Twin. The user’s device, while connecting to the malicious AP, will try to authenticate with the RADIUS server. Windows devices use MS-CHAPv2 by default. As a result, the attacker is able to obtain the user’s login and password in the form of an NTLM hash.
It is worth mentioning that Android and iOS devices do not use the MS-CHAPv2 protocol by default, so an attacker can obtain the password in the form of plaintext.
An example of an attack in which an exposed WPA2-EAP-PEAP network was authenticated without the MS-CHAPv2 protocol
Social engineering attacks
Another popular scenario is the creation of a fake Captive Portal impersonating a real service of the targeted company. This way, it is possible to obtain login details or other valuable information.
Man-in-the-Middle (MITM) attacks
The scenario is quite obvious – the attacker controls the default gateway and DNS server. Most of the services use SSL/TLS and HTTP Strict Transport Security (HSTS), which makes it less popular nowadays, but such a scenario is still possible.
Client Access
The attacker, located in the same network, can scan and attack connected devices directly. Vulnerable, outdated network services such as SMB or RDP can be a quick way to gain access to a victim machine.
Building nzyme
What do we need?
Server
Raspberry Pi 3 or Raspberry Pi 4 are recommended to set up your own nzyme instance for locations with a greater number of frames in the air (for example in office buildings). We can also use any other Linux-based hardware. The recommended distribution is Ubuntu 20.04.
Network card
The software requires a network card that supports monitor mode, which allows you to capture all frames from the air. Proper support in the form of well-functioning drivers is also crucial.
Below is a sample list of standard recommended network cards used in wireless network security audits.
For 2,4 GHz network:
- TP-Link TL-WN722N* (AR9271),
- Alfa AWUS036NH,
- Alfa AWUS036NHA,
- Panda PAU05,
- Panda PAU06.
For 2,4 GHz and 5 GHz network:
- Alfa AWUS036ACH,
- Panda PAU09,
- Alfa AWUS1900.
*Worth noting: TP-Link TL-WN722N card is available on the market in several versions. The recommended option is v1 which uses the Atheros AR9271 chipset. Unfortunately, this version is no longer produced and we are only left with the aftermarket. The photo below shows how to identify the correct version.
Marking of v1 version of the TP-Link TL-WN722N network card
How does the installation go?
Below I present installation instructions performed on Ubuntu 20.04. The installation process on a Raspberry is very similar.
- Let’s install dependencies.
1 |
$ sudo apt update && sudo apt install -y libpcap0.8 openjdk-11-jre-headless postgresql-12 wireless-tools |
- Nextly, we download the appropriate file from the site https://www.nzyme.org/download.
1 |
$ wget https://assets.nzyme.org/releases/nzyme-1.1.0.deb |
- And install nzyme.
1 |
$ sudo dpkg -i nzyme-1.1.0.deb |
- Time to verify and note down the name of our network interface.
1 2 3 4 5 6 7 8 |
$ iwconfig lo no wireless extensions. eno1 no wireless extensions. wlx14cc20167022 IEEE 802.11 Mode:Monitor Frequency:2.457 GHz Tx-Power=20 dBm Retry short limit:7 RTS thr:off Fragment thr:off Power Management:off |
- Now, we create the file
1 2 3 4 5 6 7 |
/etc/netplan/01-nzyme.yaml network: version: 2 renderer: networkd ethernets: wlx00c0caac2a8f: {} |
- Configure the database.
1 2 3 4 5 6 7 8 |
$ sudo -u postgres psql postgres=# create database nzyme; CREATE DATABASE postgres=# create user nzyme with encrypted password 'your_password’; CREATE ROLE postgres=# grant all privileges on database nzyme to nzyme; GRANT postgres=# \q |
- In order to configure HTTPS self-signed we create the following file named openssl-nzyme.cnf. Edit entries under [req_distinguished_name] and [alt_names].
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 |
[req] distinguished_name = req_distinguished_name x509_extensions = v3_req prompt = no # Details about the issuer of the certificate [req_distinguished_name] C = US ST = Some-State L = Some-City O = My Company OU = My Division CN = nzyme.example.com [v3_req] #keyUsage = keyEncipherment, dataEncipherment keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names # IP addresses and DNS names the certificate should include # Use IP.### for IP addresses and DNS.### for DNS names, # with "###" being a consecutive number. [alt_names] IP.1 = 203.0.113.42 DNS.1 = nzyme.example.com |
- Followingly, we generate the keys based on the file.
1 |
$ openssl req -x509 -days 365 -nodes -newkey rsa:2048 -config openssl-nzyme.cnf -keyout pkcs5-plain.pem -out cert.pem |
- Nextly, we convert keys to PKCS # 8 format.
1 |
$ openssl pkcs8 -in pkcs5-plain.pem -topk8 -nocrypt -out key.pem |
- Now, we can delete the unnecessary file.
1 |
$ rm pkcs5-plain.pem |
- Subsequently, we create a password hash for the administrator account.
1 |
$ nzyme echo -n secretpassword | sha256sum |
- And we copy the sample configuration file.
1 |
$ sudo cp /etc/nzyme/nzyme.conf.example /etc/nzyme/nzyme.conf |
- Modify in /etc/nzyme/nzyme.conf the previously created administrator password hash and the database password.
1 2 3 4 5 6 |
# Admin password SHA256 hash. (64 characters) - generate with, for example, sha256sum on Linux: $ echo -n secretpassword | sha256sum # You will use this password to log in to the web interface. admin_password_hash: 95d30169a59c418b52013315fc81bc99fdf0a7b03a116f346ab628496f349ed5 # Path to postgreSQL database. Make suer to change username, password and database name. (This is described in the documentation) database_path: "postgresql://localhost:5432/nzyme?user=nzyme&password=<HASLO DO BAZY POSTGRESQL> |
- Further in the /etc/nzyme/nzyme.conf file, modify the URL from which we want to access the nzyme www panel, and indicate the generated SSL keys.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
interfaces: { # Make sure to set this to an IP address you can reach from your workstation. rest_listen_uri: "https://192.168.1.115:22900/" # This is usually the same as the `rest_listen_uri`. Take a look at the configuration documentation to learn about # other use-cases. It will be interesting if you run behind a load balancer or NAT. (basically, it is the address # that your web browser will use to try to connect to nzyme and it has to be reachable for it.) http_external_uri: "https://192.168.1.115:22900/" # Use TLS? (HTTPS) See https://go.nzyme.org/docs-https use_tls: true tls_certificate_path: /etc/nzyme/cert.pem tls_key_path: /etc/nzyme/key.pem } |
- Now we can restart the service.
1 |
systemctl restart nzyme |
- If everything works fine, we can go to the nzyme web panel. In the Networks view, we are able to see the currently available networks.
* Networks view in nzyme
- Followingly, let’s click on the network we want to monitor. In the further view we find the Fingerprint of our network that needs to be copied. At this stage, it is worth observing our network for some time. In most cases, our Access Point will have more than one fingerprint.
- Lastly, we go back to modifying the nzyme.conf file and configure our Access Point.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# A list of all your 802.11/WiFi networks. This will be used for automatic alerting. # It is recommended to leave this empty or on default at first start of nzyme and # then build it using the data nzyme shows in the web interface. For example, the # "security" and "fingerprints" strings can be copied from the web interface. 802_11_networks: [ { ssid: TEST-NET channels: [1,2,3,4,5,6,7,8,9,10,11,12,13] security: [WPA2-PSK-CCMP] beacon_rate: 40 bssids: [ { address: "ae:f8:cc:09:c5:23", fingerprints: [3d80bed50c879704430aafe7f1fda3337ff88c234cbf4755eda4dc64d6da4d1d] } ] } ] |
From now on, our network will be monitored by nzyme.
What nzyme can do?
Before we go over the detection capabilities of nzyme, let’s take a look at two terms used by the platform:
- Fingerprint,
- Bandit.
Fingerprint
An attacker can easily copy AP characteristics such as: SSID, BSSID, or working channel. For this reason, the Fingerprint mechanism, which is much more difficult to counterfeit, has been implemented in nzyme. Nzyme uses the information contained in the Beacon and Probe Response frames sent by the AP in the Tagged Parameters map to calculate the Fingerprint, which is in the form of a SHA-256 hash:
- Supported Rates (ID 1),
- Country Information (ID 7),
- HT Capabilities (ID 45),
- RSN (ID 48),
- Extended Supported Rates (ID 50),
- Extended Capabilities (ID 127),
- Vendor Specific Parameters (ID 221) 00:50:F2-4 (WPS) and 00:50:F2-1 (WPA).
* Tagged Parameters visible in Wireshark
Bandit
Defined AP, detection of which will be alerted. Nzyme has a predefined list with fingerprints from such platforms as: WiFi Pineapple, Wifiphisher or esp8266_deauther. We also have the ability to create our own Bandits definitions based on four parameters: Fingerprint, SSID, signal strength and Pwnagotchi identity.
Nzyme in its current version can detect nine events:
- UNEXPECTED_BSSID – detection of an AP with an incompatible BSSID;
- UNEXPECTED_SSID – detection of an AP with an incompatible SSID;
- CRYPTO_CHANGE – detection of changes in network security configuration, for example change from WPA2 to WEP. Below example code fragment showing what parameters are taken into account:
* Code snippet. The image shows an example value of the argument used in the CRYPTO_CHANGE alert
- UNEXPECTED_CHANNEL – detecting an AP on a channel other than expected;
- UNEXPECTED_FINGERPRINT – detection of AP with Fingerprint different than expected;
- BEACON_RATE_ANOMALY – detecting anomalies in the frequency of beacon frames sent by the AP;
- MULTIPLE_SIGNAL_TRACKS – nzyme monitors the signal strength of the configured APs; in case the signal strength differs from the historical values, it will be recorded as an incident;
- PWNAGOTCHI_ADVERTISEMENT – Pwnagotchi device detection;
- BANDIT_CONTACT – detection of defined Bandit.
Nzyme test
In a short video linked below, we can watch an example scenario where an attacker exposes a malicious Access Point using the eaphammer tool, copying the name of the attacked network but with an invalid BSSID. Nzyme soon detects the intruder and alerts the event. In other tested situations, such as: incorrect SSID, Fingerprint or network security changes, the threat was detected equally efficiently.
Additional Features
Other interesting features worth mentioning include:
- event sending via Syslog or Graylog (GELF);
- sending alerts by e-mail;
- the ability to build a tracker to physically locate malicious APs;
- creating traps, such as false APs.
Problems of technological infancy
During the tests in nzyme there were a few shortcomings, which is a rather expected situation for such a young Open Source project. One of the recurring errors was incorrect display of network names, as shown in the screenshot below.
*Unidentified signs in the Networks view in the Advertised Networks column
Another problem is the inaccurate operation of the Fingerprint mechanism. In the case of Mikrotik, OpenWRT devices or from suppliers of UPC and Vectra, nzyme sometimes assigned hundreds of fingerprints to one AP, which of course also generated the same number of false positive alerts. This problem can be temporarily resolved by disabling the unexpected_fingerprint alert. To do this, comment the appropriate line in the nzyme.conf file:
1 2 3 4 5 6 7 8 9 10 11 12 |
134 # List of enabled 802.11/WiFi alert types. Remove or comment out (#) an alert type to mute it. TODO ADD DOCS LINK 135 802_11_alerts: [ 136 unexpected_bssid 137 unexpected_ssid 138 crypto_change 139 unexpected_channel 140 #unexpected_fingerprint 141 beacon_rate_anomaly 142 multiple_signal_tracks 143 pwnagotchi_advertisement 144 bandit_contact 145 ] |
Summary
The nzyme software seems to be a promising system for detecting threats in wireless networks. The pluses are definitely its features, such as: open source, simplicity of installation, operation and configuration, and an eye-friendly interface.
If you are responsible for the security of your company’s Wi-Fi network, it is worth considering the aspects of the risks described in this article, as well as considering the implementation of nzyme or an alternative monitoring system.