I made that script to detect evil twin basestations. I think that the logic would be a good supplement to OpenWRT since OpenWRT users are security conscious and baking in evil twin detection may be useful and wanted.
Michael
I made that script to detect evil twin basestations. I think that the logic would be a good supplement to OpenWRT since OpenWRT users are security conscious and baking in evil twin detection may be useful and wanted.
Michael
To be clear, is this intended to run on an OpenWrt, or a client (non-OpenWrt)?
This statement didn't offer clarity. If this runs on any client, I don't understand the attempt to relate it to OpenWrt.
I think implementing similar logic as a package in the package manager itself would be a boon to openwrt users who are in hostile environments. I wrote it on Linux but I think similar logic would be useful on openwrt.
OpenWrt is generally used an AP - and even when used as a STA, you can specify the BSSID to prevent the issue. How would Evli Twin detection help an access point?
What about sending an E-Mail warning to admin / users to raise awareness?
That is a good thing. So perhaps I misunderstand the purpose of the software. I thought that it detects against rogue APs. That means the software would run on clients, not the OpenWrt. Unless of course as I noted:
Perhaps I'm mistaken. But in the case you connect as a STA, you can still specify the BSSID, hence not being vulnerable to an Evil Twin attack.
Not sure if I get you right…hhmmm…I thought it should best run on an openwrt AP / router itself and detect evil APs with same SSIDs so you don’t have to touch every client.
Specify fixed BSSIDs? Is the evil within… ;- ) mine are all set to random, changing every day.
Aaah! That would be a cool and interesting feature!
I guess the OP can expound on the nature of the software in that use case.
Why would you do that?
I like to increase entropy
Unifi has a feature called "Rouge AP detection" which will alert the administrator if a device begins to advertise the same SSID as is configured within the Unifi environment. I'm not entirely certain how they implement the logic, but fundamentally the devices periodically scan for nearby SSIDs and throw an alert when an unexpected match (likely against the BSSIDs, but possibly other markers) occurs. Notably, it only works for Unifi APs and will treat any non-Unifi AP that is broadcasting the same SSID as rouge even if it exists on the same L2 network as the Unifi APs. To that end, you can also allow-list APs/BSSIDs that are legit to avoid false alarms.
This type of alerting is really useful for network admins/operators, but does not (and cannot) do anything to warn and/or protect individual users from Evil Twin attacks.
It isn't exactly clear to me if this is the same as what @Microlaser is proposing, but this type of system could be a nice addition to OpenWrt (although maybe it would be more fitting in a higher level system like OpenWISP or similar).
I have working code that detects evil twins. I want to give to the open source community. I think it would be a boon to security conscious OpenWRT users to have evil twin detection baked in and installable as a package perhaps. What I am suggesting is a lot like Unify but if you look at my code it does not depend on things like the klunky network manager on Linux. It is light and can be used to notify an OpenWRT user of an attack. This is exactly what I have in mind. I am not trying to force this idea, I am suggesting it to the community to see if there is interest.
I think there is one thing that about your description that not entirely clear -- hopefully you can clarify/confirm:
I think this is the confusion that solicited my interest. It wasn't clear [to me] whom the software is monitoring and defending in the [general] use case of an OpenWrt where it's an access point, not a STA (client).
It seems this software would be ran on a client, otherwise how would OpenWrt protect a user after an Evil Twin (and MitM) attack has already occurred for a client to connect to a rogue AP. Doppel-D suggested email.
My read of this -- pending clarification from the OP -- is that this an AP side approach, not applicable to STA operations. IIUC, it would notify the network admin that an Evil Twin attack is happening -- a rebroadcast of an SSID that is nominally being broadcast (legitimately) by one or more OpenWrt routers under the admin's control.
This would have relatively little applicability to a home user (although it can still be a good thing to have running just in case), but would be very useful for an admin/operator who uses OpenWrt to run a business network (especially hotels, cafes, etc.) that may be targets of such Evil Twin attacks.
This is all assuming I understand the intent, and I may be wrong here.
I don't know of a method by which the client side can easily identify an Evil Twin on the upstream network, but maybe I'm missing something . That is to say that in STA mode operation, OpenWrt has no knowledge of the upstream network details such as which APs are legit and which are the attack twins, so I don't think there is a mechanism by which it could protect users of a public wifi.
If I'm missing something about how a STA can detect and avoid/alert about an Evil Twin, hopefully the OP will explain the logic in more detail.
While a client usually trusts whatever BSSID matches the SSID, Wifi-Guardian adds a layer of 'Physical Fingerprinting.' Even in STA mode, the tool looks for the Locally Administered Bit. A legitimate ISP-provided router or an enterprise AP will almost never have this bit set. If a client sees its 'Home_Wifi' being broadcast by a BSSID with that bit enabled, it’s a 99% certainty that it's a software-defined rogue AP. This logic can be adapted to run as an OpenWRT package perhaps. I believe it has wider appeal than just business owners. It’s a privacy protector and many OpenWRT users are interested in security and radical privacy which most people are apathetic about these days.
So this is actually intended as a client side protection method? Protect the user, not the network?
It would seem that transmitting a warning to the user may be tricky... a few people have suggested email and there may be other methods. However, this may not work as expected if the twin is impersonating a captive portal... you may need to enter your credentials/payment in order to get through the portal before internet access is available. (depending on the attack method, the Evil Twin could be standalone, skimming credentials but not actually connecting the user to the internet, or it could be a MITM that grabs the credentials and also passes them to the upstream so that the user is none-the-wiser). That said, if the Evil Twin requires any kind of action before granting internet access, it will be difficult to warn the user via any non-local method.
Maybe the approach could be to integrate this detection into a LuCI connection manager page where a warning could be surfaced... could this ideam/method be integrated into TravelMate (@dibdot)?
That is an excellent idea!
You cannot depend on python and genuinely say “it’s light”.
Python dependency is huge for most devices that OpenWrt is targeted at.
Not sure if this would suffice, package python3-base require approx. 1.48 MiB size for 2 package(s) to install.
In my case libpython3-3.13 (~1.26 MiB) not installed, the rest was already installed: libatomic1 (~5.49 KiB) , libgcc1 (~21.67 KiB) , libpthread (~655 B)
On the other hand…my Netgear R7800 dinosaur is about ~10 years old and offers ~80MB flash and 512 MB RAM. What a good buy ;- )