Unlocking the secrets of wireless networks with wifi_db for fun and profit. Link to heading
Table Of Contents
wifi_db is a Python3 program which allows importing files generated with airodump-ng, using the -w flag, and adding them to a SQLite database and extract useful information. To run queries and use the built-in views, the resulting database can be opened with a database client like SQLitebrowser. In the upcoming sections, detailed information will be presented about the complete range of features offered by the program, instructions on how to use it, and additional details regarding the database. One of the most notable features of wifi_db is its ability to quickly identify relationships between APs and clients. It also streamlines the process of cracking PSK networks, obtaining identities in enterprise networks, and detecting networks stored on devices connected to corporate networks that could be vulnerable to attacks.
The project is available at:
Features Link to heading
- Shows a detailed table of connected clients and their respective APs.
- Identifies client probes connected to APs, providing insight into potential security risks usin Rogue APs.
- Extracts handshakes for use with hashcat, facilitating password cracking.
- Displays Identity information (usernames) from enterprise networks, including the EAP method used for authentication.
- Displays if a network is cloaked (hidden) even if you have the ESSID.
- Generates a summary of each AP group by ESSID and encryption, giving an overview of the security status of nearby networks.
- Provides a WPS info table for each AP, detailing information about the Wi-Fi Protected Setup configuration of the network.
- Logs all instances when a client or AP has been seen with the GPS data and timestamp, enabling location-based analysis.
- Upload files with capture folder or file. This option supports the use of wildcards (*) to select multiple files or folders.
- Docker version in Docker Hub to avoid dependencies.
- Obfuscated mode for demonstrations and conferences.
- Possibility to add static GPS data.
Usage Link to heading
The program can be used as follows:
Firstly, airodump-ng needs to be executed to capture the necessary data. This can be achieved by running the following command:
sudo airodump-ng wlan0mon -w ~/wifi/scan --gpsd
In the above command,
wlan0mon specifies the interface to be monitored,
-w specifies the path and filename where the capture files are to be saved, and
--gpsd enables the capture of GPS data if a GPS antenna is present.
The files saved in the wifi folder can be imported into the application to build the database after the captures have been made:
python3 wifi_db.py -d database.sqlite ~/wifi/
In the above command, the
-d option specifies the name of the database file to be created, and
database.sqlite specifies the filename to be used. Finally,
~/wifi/ specifies the path where the capture files are located. In this parameter the program accepts the folder path, a specific file, a plain file adding all files with that name and wildcards (*) to select multiple files according to a pattern.
wifi_db can also be used with docker:
docker pull r4ulcl/wifi_db CAPTURESFOLDER=/home/user/wifi/ touch db.SQLITE docker run -t -v $PWD/db.SQLITE:/db.SQLITE -v $CAPTURESFOLDER:/captures/ r4ulcl/wifi_db
The first command
docker pull r4ulcl/wifi_db downloads the Docker image
r4ulcl/wifi_db from Docker Hub to your local machine. This image contains the necessary software and dependencies to run the wifi_db application.
The second command
CAPTURESFOLDER=/home/user/wifi/ sets an environment variable named
/home/user/wifi/. This variable will be used later to specify the folder where the captured Wi-Fi data is stored.
The third command
touch db.SQLITE creates an empty file named
db.SQLITE in the current directory. This file will be used as the SQLite database file where the captured Wi-Fi data will be stored.
The fourth command
docker run -t -v $PWD/db.SQLITE:/db.SQLITE -v $CAPTURESFOLDER:/captures/ r4ulcl/wifi_db runs the Docker container from the previously downloaded image
r4ulcl/wifi_db. The first
-v flag mounts the
db.SQLITE file in the current directory to the
/db.SQLITE path inside the container. The second
-v flag mounts the
CAPTURESFOLDER directory on the host machine to the
/captures/ directory inside the container. This allows the host captures to be process by wifi_db and wifi_db output database to be stored on the host machine.
Once the database is generated, it can be accessed using a database client such as SQLitebrowser or wifi_data, allowing the user to explore the many tables and views provided by the program and run custom queries against the database.
Below is an example of a ProbeClientsConnected table.
In this example we can see the probes of the clients connected to different networks. For example, we can see that a wifi-global client has probes to “WiFi-Restaurant”, “home-wifi” and “open-wifi”.
Database information Link to heading
The database consists of tables with the following information:
- AP: stores information about access points including BSSID, SSID, channel, frequency, encryption, and geographic location.
- Client: stores information about clients including MAC address, SSID, manufacturer, and device type.
- SeenClient: stores information about clients that have been observed on the network including MAC address, time stamp, signal strength, and geographic location.
- Connected: stores information about clients that are currently connected to access points including the BSSID and MAC address.
- WPS: stores information about Wi-Fi Protected Setup (WPS) configuration for access points including the BSSID, SSID, WPS version, and device information.
- SeenAP: stores information about access points that have been observed on the network including the BSSID, time stamp, signal strength, and geographic location.
- Probe: stores information about Wi-Fi probe requests made by clients including MAC address, SSID, and time stamp.
- Handshake: stores information about successful key establishment between a client and an access point including BSSID, MAC address, file name, and hashcat value.
- Identity: stores information about EAP identities used in authentication between a client and an access point including the BSSID, MAC address, identity, and method.
Additionally, the database includes the following views:
- ProbeClients: This view combines data about clients that have sent probe requests to access points, including the manufacturer of the client device, the number of packets sent, and the SSID (network name) of the access point that was probed.
- ConnectedAP: This view combines data about clients that are currently connected to an access point, including the SSID of the access point, the MAC address of the client device, and the manufacturer of the client device.
- ProbeClientsConnected: This view combines data about clients that have sent probe requests and are also currently connected to an access point, including the SSID of the access point, the MAC address of the client device, and the manufacturer of the client device.
- HandshakeAP: This view combines data about successful handshakes between clients and access points, including the SSID of the access point, the MAC address of the client device, the manufacturer of the client device, and information about the captured handshake file.
- HandshakeAPUnique: This view combines data about unique handshakes that have been captured, based on their SSID. This view excludes any handshake of an AP more than once.
- IdentityAP: This view combines data about client identities (i.e. usernames) that have been associated with specific access points, including the SSID of the access point, the MAC address of the client device, the manufacturer of the client device, and the method used to authenticate the client.
- SummaryAP: This view provides a summary of all access points in the database, including the number of times each SSID has been observed, the encryption type used by the access point, the manufacturer of the access point, and whether the access point is “cloaked” (hidden from view).
Each time the program is executed, new information is added to the database, joining it to the existing ones. Furthermore, complete folders can be imported without going file by file.