On Mon, Apr 22, 2024 at 10:46:50AM +0200, Peter J. Philipp wrote: > Hi, > > I have a shortage of RJ45 adapters so I had to expose one host on wifi, for > this I set up an access point of type "AVM Fritz!Box 7390" with latest > firmware > from last year. > > Soon I started facing deauth attacks from someone within my wifi cell region. > Since the deauthers were spoofing my OpenBSD host to the AVM it wasn't > resistant to this. So what I did was crontab (with ~) setting up a random > lladdr on my OpenBSD boxes bwfm0 and resetting the interface. Worked well > for a day, then the bad guy changed his attack, and made my OpenBSD SBC > inoperable. > > I have traced some of the things he/she did and I'll try to reconstruct it. > > 1. I set up a wifi connection on 2.4 GHz which seemingly made the attacker > annoyed. It could have been the SSID of "SUGARHILL" that really annoyed them. > > 2. Attacker sets up deauther on AP cuasing us to crontab random MAC's, this > worked for a while. The attack was temporarily stopped. > > 3. Attacker sets up an IBSS node with the same SSID of "SUGARHILL". Now here > is where it gets weird. I don't know if my SBC had a bssid with mac address > for association set. Let's pretend this is a grey area. Attacker then > proceeds to disassociate OpenBSD. > > 4. I reassociate because we are in the process of changing MAC address per > crontab. > > 5. For whatever reason we join the IBSS instead of the AP. Please see A for > the code analysis I did. > > 6. The OpenBSD is inoperable. Since I don't have UART console on it I can't > reach it anymore. A powercycle may bring it back. Eventually I'll have to > set up a UART for it. > > Code Analysis: > > This is the first real search in the IEEE 802.11 on OpenBSD code for me. Does > a state diagram exist for this? > > A. ieee80211_node.c - in _node_join_bss() > > IBSS has higher preference on line 1333. new_state() beomes S_RUN. Important > is that mgt is set to -1. > > B. I can't understand currently where else it would go but in state S_RUN > it can parse a lot of frames and drops a lot of frames as well. I > personally saw that at this point my SBC was inoperable to the wifi. > > > > Conclusions? I don't have any. I'm hoping to start some dialogue among the > powers that be. It would be nice to flag off joining IBSS's when only wanting > to join BSS's. But while I'm unsure it's best not to send patches. > > Here is the dmesg of the SBC in question: > > https://blog.centroid.eu/c?article=1712648412 > > PS: A USB-C RJ45 dongle costs 15 EUR. I may just include it in a batch when > I buy from my computer and electronics supplier next. > > Best regards, > -pjp
The bwfm(4) driver is not set up to use IBSS. If this driver joins an IBSS network then that is a bug. It shouldn't be doing that. Regardless, the best way to avoid deauth attacks is to use management frame protection aka. MFP aka IEEE 802.11w-2009. The Fritzbox probably supports this, but our net80211 stack doesn't quite support this yet. There is some code which is disabled, none of the drivers make use of it. I myself don't have enough spare cycles to work on it. Another solution is to use an OpenBSD AP *and* client and set the stayauth nwflag on both of them, e.g. ifconfig athn0 nwflag stayauth This currently only helps against deauth frames, see ieee80211_recv_deauth(). It won't help against disassoc frames. But it should be easy to copy the stayauth code to other input frame handlers if needed.
