[Battlemesh] Extremely odd wireless network in the air causing problems
Musti
musti at wlan-si.net
Mon Dec 2 21:59:23 CET 2013
Hi,
a longer investigation that took a few days last week to triangulate the sources of this odd wireless traffic (riding around with a jeep with several 5GHz antennas mounted and monitoring the signal strength for a number of sources simultaneously). I was able to locate them on some towers and find out they are from a trustworthy commercial entity. Meaning that why such traffic is observer is extremely likely due to a hack or a worm, that is unclear as of now. Device manufacturer is unknown, but is not UBNT or Mikrotik from what I could tell from the shape. The good question now is what equipment is vulnerable to whatever this was. If there is a way for such wireless DoS behaviour to infect a number of nodes, the spectrum will be useless very fast. Please find the traffic analysis below, any ideas what is used to generate this behaviour would be useful.
In normal behaviour these locations have a working wireless link, now only DeAuth packets are present.
Location X
Main source MAC: 28:00:00:00:00:00
Packet Type: DeAutehntication
Bitrate: 6Mbps
Sequence number: 2145
Destination: xx:xx:xx:24:7d:98 - where xx values are incremented with each packet and wrap around
Same device transmits less often as well with these MACs.
e8:00:00:00:00:00 to 11:00:xx:xx:xx:xx, incrementally in to streams offset for probably fixed number., Bitrate: 6Mbps,
10:0e:00:00:00:00 to 01:00:ff:ff:00:00, destination fixed, Bitrate follows this repeating sequence 6Mbps, 6Mbps, 24Mbps, 32Mbps
62:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets
3e:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets
68:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets
64:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets
93:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets
5c:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets
86:00:00:00:00:00 - just one packet observed
Example of a packet:
> No. Time Source Destination Protocol Length Info RSSi TX rate
> 1 0.000000000 28:00:00:00:00:00 Computer_24:7d:98 802.11 102 Deauthentication, SN=2529, FN=1, Flags=........C[Malformed Packet] -69 dBm 6.0
>
> Frame 1: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface 0
> Radiotap Header v0, Length 34
> IEEE 802.11 Deauthentication, Flags: ........C
> Type/Subtype: Deauthentication (0x0c)
> Frame Control Field: 0xc100
> .000 0000 0000 0001 = Duration: 1 microseconds
> Receiver address: Computer_24:7d:98 (01:00:6a:24:7d:98)
> Destination address: Computer_24:7d:98 (01:00:6a:24:7d:98)
> Transmitter address: 28:00:00:00:00:00 (28:00:00:00:00:00)
> Source address: 28:00:00:00:00:00 (28:00:00:00:00:00)
> BSS Id: de:6c:11:86:de:6c (de:6c:11:86:de:6c)
> Fragment number: 1
> Sequence number: 2529
> Frame check sequence: 0x4739df1e [correct]
> IEEE 802.11 wireless LAN management frame
> Fixed parameters (2 bytes)
> Reason code: Unknown (0x7474)
> Tagged parameters (42 bytes)
> Tag: Congestion Notification
> Tag Number: Congestion Notification (116)
> Tag length: 116
> [Malformed Packet: IEEE 802.11]
Location Y
Main source MAC: 28:00:de:6c:11:9e
Packet type: DeAutehntication
Sequence number: 2529
Destination: 49:00:fa:xx:xx:xx - where xx values are incremented with each packet and wrap around
Source MACs used by this device, but less often.
10:0E:DE:6C:11:9E
E8:00:DE:6C:11:9E
28:00:DE:6C:11:9E
3E:00:DE:6C:11:9E
64:00:DE:6C:11:9E
30:00:DE:6C:11:9E
Example of a packet:
> No. Time Source Destination Protocol Length Info RSSi TX rate
> 3638871 1266.857808000 28:00:de:6c:11:9e 49:00:fa:6a:3b:20 802.11 102 Deauthentication, SN=2145, FN=1, Flags=........C[Malformed Packet] -82 dBm 6.0
>
> Frame 3638871: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface 0
> Radiotap Header v0, Length 34
> IEEE 802.11 Deauthentication, Flags: ........C
> Type/Subtype: Deauthentication (0x0c)
> Frame Control Field: 0xc100
> .000 0000 0000 0001 = Duration: 1 microseconds
> Receiver address: 49:00:fa:6a:3b:20 (49:00:fa:6a:3b:20)
> Destination address: 49:00:fa:6a:3b:20 (49:00:fa:6a:3b:20)
> Transmitter address: 28:00:de:6c:11:9e (28:00:de:6c:11:9e)
> Source address: 28:00:de:6c:11:9e (28:00:de:6c:11:9e)
> BSS Id: de:6c:11:9e:de:6c (de:6c:11:9e:de:6c)
> Fragment number: 1
> Sequence number: 2145
> Frame check sequence: 0xf18aa30f [correct]
> IEEE 802.11 wireless LAN management frame
> Fixed parameters (2 bytes)
> Reason code: Unknown (0x7474)
> Tagged parameters (42 bytes)
> Tag: Congestion Notification
> Tag Number: Congestion Notification (116)
> Tag length: 116
> [Malformed Packet: IEEE 802.11]
Regards,
Musti
On 27 Nov 2013, at 23:48, Ben West <ben at gowasabi.net> wrote:
> Sometimes weather radar units are put up for sale at Hamfests.
>
> http://ads22.imgur.com/all
>
> Trigger DFS for all your friends, uncooperative spectrum neighbors included. ;)
>
>
> On Wed, Nov 27, 2013 at 4:00 PM, Michel de Geofroy <micheldegeofroy at gmail.com> wrote:
> Maybe this is exactly what it is ... RF jamming ... I know of a ibiza WISP that jammed the competition to prepare his entry in the market.
>
>
>
> Michel
>
>
> Proudly Accepting Bitcoins 178QhTbSins1EnBqyL62k2uUrigh1Xc56Z you too start exchanging in bitcoins and join the revolution :)
>
> If you want to donate money or more to a good cause check out http://www.amigosolidarios.com/es/que_hacer.asp
>
> +34 606 88 22 79
> Skype micheldegeofroy
>
>
> On Wed, Nov 27, 2013 at 8:11 PM, Musti <musti at wlan-si.net> wrote:
> Hi,
>
> thanks for the reply. Meanwhile I have figured this may be a non-targeted deauthentication jamming. http://hackaday.com/2011/10/04/wifi-jamming-via-deauthentication-packets/
>
> However what I am seeing now with tcpdump analysis is that these deauth packets from a single source have an incremental destination address in a rather peculiar form. First two sections remain constant, the others start incrementing from left to right, rolling over back to 49:00:00…. in a period of hours. Now that attack does not make sense, because it is not targeting any specific manufacturer of type of the network, performing pretty much just an RF jam and succeeding in it.
>
> 1029548 2450.247257000 28:00:de:6c:11:9e 49:00:1f:86:b5:6f 802.11 102 Deauthentication, SN=2145, FN=1, Flags=........C[Malformed Packet] -89 dBm 6.0
> 1029549 2450.252103000 28:00:de:6c:11:9e 49:00:2c:86:b5:6f 802.11 102 Deauthentication, SN=2145, FN=1, Flags=........C[Malformed Packet] -90 dBm 6.0
> 1029550 2450.260856000 28:00:de:6c:11:9e 49:00:43:86:b5:6f 802.11 102 Deauthentication, SN=2145, FN=1, Flags=........C[Malformed Packet] -89 dBm 6.0
>
> Ideas welcome.
>
> Regards,
> Musti
>
>
>
> On 27 Nov 2013, at 18:37, Ben West <ben at gowasabi.net> wrote:
>
>> If there is any remote chance the party operating these radios is using atheros chipsets with the ath9k_htc driver, then it may be possible to spoof them into revealing their actual MAC addresses.
>>
>> http://www.mathyvanhoef.com/2013/11/unmasking-spoofed-mac-address.html
>>
>>
>> On Wed, Nov 27, 2013 at 3:19 AM, Musti <musti at wlan-si.net> wrote:
>> Hi folks,
>>
>> I am writing to you all with a description of a problem I am facing at the moment here in Slovenia, where a very odd wireless network is causing problems in existing networks. Any thoughts and ideas would be welcome.
>>
>> Location: Maribor, Slovenia
>>
>> A few days ago a network appeared in the air, that uses 802.11 but is not a conventional AP or mesh, transmitting at a rather high power in several directions, possibly omni at 5680MHz (ch 136). Triangulation of the signal thus-far has been a failure, not being able to find any consistent direction of the origin and perform triangulation. But looking at the traffic generated by this “thing” is where it gets weird.
>>
>> All the packets transmitted have a common BSSID: DE:6C:11:9E:DE:6C and originate from the following devices:
>>
>> 10:0E:DE:6C:11:9E
>> E8:00:DE:6C:11:9E
>> 28:00:DE:6C:11:9E
>> 3E:00:DE:6C:11:9E
>> 64:00:DE:6C:11:9E
>> 30:00:DE:6C:11:9E
>>
>> As well as
>> 10:0E:00:00:00:00
>> E8:00:00:00:00:00
>> 28:00:00:00:00:00
>> 3E:00:00:00:00:00
>> 64:00:00:00:00:00
>> 30:00:00:00:00:00
>>
>> The MAC addresses do not appear to be from a valid vendor, first to sections changing make no sense really.
>>
>> Now things get even more strange, the traffic is of 6M bitrate, consisting only of DeAutehntication packets, utilising the maximum throughput of the channel, mostly originating from 28:00:DE:6C:11:9E. Example from tcpdump verbose output:
>>
>> 01:54:32.120993 30290112us tsft 6.0 Mb/s 5680 MHz 11a -87dB signal antenna 1 DeAuthentication (28:00:de:6c:11:9e (oui Unknown)): Reserved
>>
>> Some other packets of type ACK and RTS have been seen, but absolutely no data of any form.
>>
>> The measurements and observations were made using Ubiquiti Nanostation Loco M5, Nanobridge M5 25dB running openwrt AA, using Horst and tcpdump. Btw, on these devices the only way how to make horst listen on a specific channel appears to be by creating an ap on that channel and then adding a mon0 interface. Any ideas how to use it more conveniently or use automatic channel hopping. Manual setting of the channel allows only the first two digits to be entered.
>>
>>
>> Any ideas on what other experiments to do and how to go about finding the source of this “noise” would be appreciated.
>>
>> Kind regards,
>> Musti
>> wlan slovenija
>>
>>
>>
>> _______________________________________________
>> Battlemesh mailing list
>> Battlemesh at ml.ninux.org
>> http://ml.ninux.org/mailman/listinfo/battlemesh
>>
>>
>>
>> --
>> Ben West
>> http://gowasabi.net
>> ben at gowasabi.net
>> 314-246-9434
>> _______________________________________________
>> Battlemesh mailing list
>> Battlemesh at ml.ninux.org
>> http://ml.ninux.org/mailman/listinfo/battlemesh
>
>
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
>
>
>
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
>
>
>
>
> --
> Ben West
> http://gowasabi.net
> ben at gowasabi.net
> 314-246-9434
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20131202/ce90b5bc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20131202/ce90b5bc/attachment-0001.sig>
More information about the Battlemesh
mailing list