red profiles are optional and the application will run
without them. However, as expected this will generate
much less accurate results in the detection process,
since some heuristics will not be used.
3.2 Modules
The main application is connected to all the modules.
Scanners are passive modules with methods imple-
mented to monitor the network in order to find nearby
AP
s. After being started, the application will always be
scanning. The information provided will feed the De-
tectors, where a set of detection heuristics will sweep
the scanned
AP
s and when a specific
AP
reaches some
suspicion level it will interact with the Actuators to
perform active techniques.
For
Scanners
to scan the Wi-Fi channels we have
configured two different modules: one that uses the
iwlist
Linux command and another that uses the
scapy packet manipulation program.
On the
Detector
modules, one type of heuristic
present is the classic approach of whitelisting, where
we use the information from the configuration profile
regarding
SSID
s and their expected
BSSID
s. Since
this is likely to be bypassed (
BSSID
spoofing), we
also compare the Encryption type used by the AP.
Another heuristic is the variation of the signal
strength. As already described, this tool is designed
to be stationary, and normal
AP
s are also fixed. With
this in mind, we can estimate a baseline for the sig-
nal strength and use this information to improve the
detection process.
In particular the algorithm uses an
auth_rssi
de-
fined by the user for the authorized
AP
’s
RSSI
, and
to avoid fluctuations a delta accounts for variations.
As such, the read RSSI value must fall in the allowed
range of
[auth_rssi − delta;auth_rssi + delta]
. If this
is triggered, the user is prompted to associate to the
AP and continue to the active tests (Actuators).
The described heuristics assume that a configura-
tion profile is loaded when the application runs, ot-
herwise they will not be applied. In such case, a no
knowledge method is always run by the application,
where it conducts simple analyses on the scanned
AP
s.
A simple case is looking for
AP
s with the same
SSID
and different security being used.
Another heuristic used by the application is a free
Wi-Fi’s authenticity validation. This takes advantage
of the
BSSID
pattern of the studied free Wi-Fis. As
an example, the free Wi-Fi provided by the
ISP
NOS
(Portuguese media company), is generated from the
router of a personal network and the
BSSID
generated
for the free network follows a specific pattern. It is the
increment by one unit of the last byte of the personal
network’s
BSSID
. We use this information to analyse
the BSSIDs of the scanned free Wi-Fis.
This tool also has a blacklist passive heuristic for
RAP
s generated from known Wi-Fi attacking tools.
We configured two methods to detect Pineapple AP
RAP
s and
AP
s where the
BSSID
manufacturer is Alfa.
In the case of PineAP, the default
BSSID
contains
13:37
(leet speech), hence this heuristic can iden-
tify some
RAP
s configured by inexperienced attackers.
The Alfa condition is supported by the fact that these
Wi-Fi cards are mainly used for Wi-Fi attacks.
The passive detectors also have a heuristic to look
for de-authentication frames and alert the user. For
this we use the scapy packet manipulation tool.
The
Actuators
are composed by a set of active
detectors, a defensive mechanism and a honeypot.
The active detectors are performed when we have
knowledge about the scanned
AP
, i.e., the scanned
AP
matches an
AP
from our list of authorized
AP
s or for
open networks that fail the authenticity validation and
need further confirmation. The detectors under the
Actuators type of modules perform active operations
over the target
AP
, specifically, they associate to the
AP and then run the heuristics:
- Associate:
tries to associate to the AP and gather
information on the network addresses, comparing to
the values on the profile;
- Traceroute:
compares network paths to configured
destinations with the paths defined in the profile;
- Fingerprint:
verifies if the OS fingerprint and ser-
vices of the tested
AP
corresponds to the ones of an
authorized AP.
The Actuators set of modules is also composed
of an hybrid mechanism to detect Karma attacks. In
passive mode, we wait for probe responses from the
same
AP
to different probe requests. In the active
mode, we send probe requests for generated fictitious
SSID
s. If an
AP
sends responses for the fabricated
SSID
s, a Karma attack is spotted. In cases like this,
where it is obvious that
RAP
s are being created, a de-
fensive approach can be used by sending IEEE 802.11
de-authentication packets to the clients associated with
the detected RAP.
Last we have the honeypot module, which is a
RAP
created and controlled by the application. If an
attacker targets this
AP
, i.e., spoofing it, we have the
same confirmation as for the generated SSIDs.
4 RESULTS
This section describes the results obtained from the
RAP
detections performed on two different scenarios.
In the first, the
RAP
s were deployed by an information
A Flexible Framework for Rogue Access Point Detection
469