Wifi based heuristics

[jacklund]

First pass at a solution for issue #1000.

Some notes:

• I've managed to shoehorn my code into the analysis flow, although whether it's in the best place I'll leave up to y'all. I've added a WifiOUIAnalyzer type, which implements Analyzer, and which gets added to the analyzer harness by default (and is configurable). I've also added the configured OUIs to the AnalyzerConfig which felt weird, since everything else on that are booleans, but there didn't seem to be a better place to put that and still have it available in the Harness code.

• I've added a config line to specify the target OUIs as a comma-separated list of strings. I don't currently validate the OUIs (which should be done), because I'm not certain that's the best way to specify them. At some point there should probably be lists of well-known OUIs for specific types of target devices (similar to what Colonel Panic does in his OUI-spy apps), but until we have those lists, this might have to do.

• I've also marked a OUI match as a HIGH event type, which might not be what is wanted here, it just seemed like a good place to start.

• There's some code duplicated from DiagTask::process_container where I send the information to the notification channel and the display, which is not great, but I figured that some refactoring of the analysis flow to make this code fit better might make that go away anyway.

• Also, I'm using my fork of wifi-station for this PR - I have a PR pending on that repo which will add the BSSID to the list of items returned when scanning. Hopefully when/if that PR is merged, we can put that back.

Pull Request Checklist

• The Rayhunter team has recently expressed interest in reviewing a PR for this.
  • If not, this PR may be closed due our limited resources and need to prioritize how we spend them.
• Added or updated any documentation as needed to support the changes in this PR.
• Code has been linted and run through cargo fmt.
• If any new functionality has been added, unit tests were also added.
• CONTRIBUTING.md has been read.
• Your pull request is fewer than ~400 lines of code.

You must check one of:

• [ x No generative AI (including LLMs) tools were used to create this PR.
• Generative AI was used to create this PR. I certify that I have read and understand the code, and that all comments and descriptions were authored by myself and are not the product of generative AI.

[jacklund]

Rebased against upstream main

[cooperq]

@jacklund sorry for the delay on reviewing this I'm having a look at it now

[cooperq]

I like the direction of your approach here. A few issues:

1. alerts are reflected in the screen UI and the notifications but not in the web UI. We probably want to preserve the alerts and the OUI that triggered them. but we also want to update the web UI when we alert on an OUI. One way to do this would be to write it to the ndjson file but I think those currently get erased when we do a rescan. Another way would be to write it to its own separate wifi log which might be a better idea. It would be cool if we could write something to the pcap somehow from this but I will consider that a stretch goal for now.

2. the list of mac addresses the wifi client sees is very limited right now, I'm not really sure whats up with this but I supsect its stuck on one channel and perhaps not channel hopping? I will have to look into this.

3. Obviously this needs more documentation :) also the alert level for this should probably be low or informational for now as this is only useful in conjunction with other alerts.

[cooperq]

One of the main imsi catcher manufacturers is keyw corporation who has an unusual OUI of https://maclookup.app/macaddress/70b3d57cb 70:b3:d5:7c:b

It would be cool to be able to match against an oui like this that is >3 bytes but also the half byte at the end (crazy stuff I know)

Also we should have a sane default list of OUIs. I can provide this.

[cooperq]

please address the changes in my above comments.

[jacklund]

@jacklund sorry for the delay on reviewing this I'm having a look at it now

No worries, I know y'all are slammed.

[jacklund]

One of the main imsi catcher manufacturers is keyw corporation who has an unusual OUI of https://maclookup.app/macaddress/70b3d57cb 70:b3:d5:7c:b

Wow, that's crazy.

It would be cool to be able to match against an oui like this that is >3 bytes but also the half byte at the end (crazy stuff I know)

Well, right now I do a startswith() (IIRC) for the OUI matching. I was considering doing some more stuff to restrict it to 3 bytes, but I guess leaving it for now makes sense for stuff like that.

Also we should have a sane default list of OUIs. I can provide this.

👍

[jacklund]

I like the direction of your approach here. A few issues:

1. alerts are reflected in the screen UI and the notifications but not in the web UI. We probably want to preserve the alerts and the OUI that triggered them. but we also want to update the web UI when we alert on an OUI. One way to do this would be to write it to the ndjson file but I think those currently get erased when we do a rescan. Another way would be to write it to its own separate wifi log which might be a better idea. It would be cool if we could write something to the pcap somehow from this but I will consider that a stretch goal for now.

Sounds good. I'm going to have to use a separate logger in that case, not a big deal, since y'all redirect the default logging from stdout to the rayhunter logs. I'll probably use whatever's simplest for now, although if you have a preference for a particular logger, I can use that. I'll also add something to be able to look at the wifi logs similar to what's done in the web UI for the rayhunter logs.

I think to be really useful, we'd need to include both the OUI and the manufacturer in the alert, which means we'd need to configure it with both (i.e. my simple config of a list of OUIs probably won't cut it). I'll probably change that to a list of manufacturer => list of OUIs, unless you think that's overkill.

2. the list of mac addresses the wifi client sees is very limited right now, I'm not really sure whats up with this but I supsect its stuck on one channel and perhaps not channel hopping? I will have to look into this.

Hadn't noticed that. I can look at that as well.

3. Obviously this needs more documentation :) also the alert level for this should probably be low or informational for now as this is only useful in conjunction with other alerts.

Yep, I figured I'd wait until we settled on a set of stable features before tackling documenting it, but I can probably start with some of what we've got now. I'll also change the alert level.

Thanks for the feedback!