<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi,<div><br></div><div>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.</div><div><div><br></div><div>In normal behaviour these locations have a working wireless link, now only DeAuth packets are present. </div><div><br></div><div><div><b>Location X</b></div><div><br></div><div>Main source MAC: 28:00:00:00:00:00</div><div>Packet Type: DeAutehntication</div><div>Bitrate: 6Mbps</div><div>Sequence number: 2145</div><div>Destination: xx:xx:xx:24:7d:98 - where xx values are incremented with each packet and wrap around</div><div><br></div><div>Same device transmits less often as well with these MACs.</div><div><br></div><div><div>e8:00:00:00:00:00 to 11:00:xx:xx:xx:xx, incrementally in to streams offset for probably fixed number., Bitrate: 6Mbps,</div><div>10:0e:00:00:00:00 to 01:00:ff:ff:00:00, destination fixed, Bitrate follows this repeating sequence 6Mbps, 6Mbps, 24Mbps, 32Mbps</div><div>62:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets</div><div>3e:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets</div><div>68:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets</div><div>64:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets</div><div>93:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets</div><div>5c:00:00:00:00:00 to 1c:00:xx:xx:xx:xx, incrementally, Bitrate: 18Mbps in 24Mbps, changing about every 20 packets</div><div>86:00:00:00:00:00 - just one packet observed</div></div><div><br></div><div>Example of a packet:</div><div><br></div><div><div></div><blockquote type="cite"><div>No. Time Source Destination Protocol Length Info RSSi TX rate</div><div> 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</div><div><br></div><div>Frame 1: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface 0</div><div>Radiotap Header v0, Length 34</div><div>IEEE 802.11 Deauthentication, Flags: ........C</div><div> Type/Subtype: Deauthentication (0x0c)</div><div> Frame Control Field: 0xc100</div><div> .000 0000 0000 0001 = Duration: 1 microseconds</div><div> Receiver address: Computer_24:7d:98 (01:00:6a:24:7d:98)</div><div> Destination address: Computer_24:7d:98 (01:00:6a:24:7d:98)</div><div> Transmitter address: 28:00:00:00:00:00 (28:00:00:00:00:00)</div><div> Source address: 28:00:00:00:00:00 (28:00:00:00:00:00)</div><div> BSS Id: de:6c:11:86:de:6c (de:6c:11:86:de:6c)</div><div> Fragment number: 1</div><div> Sequence number: 2529</div><div> Frame check sequence: 0x4739df1e [correct]</div><div>IEEE 802.11 wireless LAN management frame</div><div> Fixed parameters (2 bytes)</div><div> Reason code: Unknown (0x7474)</div><div> Tagged parameters (42 bytes)</div><div> Tag: Congestion Notification</div><div> Tag Number: Congestion Notification (116)</div><div> Tag length: 116</div><div>[Malformed Packet: IEEE 802.11]</div></blockquote><br></div><div><b>Location Y</b></div><div>Main source MAC: 28:00:de:6c:11:9e</div><div>Packet type: DeAutehntication</div><div>Sequence number: 2529</div><div>Destination: 49:00:fa:xx:xx:xx - where xx values are incremented with each packet and wrap around</div><div><br></div><div><div>Source MACs used by this device, but less often.</div><div><br></div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">10:0E:DE:6C:11:9E<br>E8:00:DE:6C:11:9E<br>28:00:DE:6C:11:9E<br>3E:00:DE:6C:11:9E<br>64:00:DE:6C:11:9E<br>30:00:DE:6C:11:9E</div></div></div><div><br></div><div>Example of a packet:</div><div><br></div><div><div></div><blockquote type="cite"><div>No. Time Source Destination Protocol Length Info RSSi TX rate</div><div>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</div><div><br></div><div>Frame 3638871: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface 0</div><div>Radiotap Header v0, Length 34</div><div>IEEE 802.11 Deauthentication, Flags: ........C</div><div> Type/Subtype: Deauthentication (0x0c)</div><div> Frame Control Field: 0xc100</div><div> .000 0000 0000 0001 = Duration: 1 microseconds</div><div> Receiver address: 49:00:fa:6a:3b:20 (49:00:fa:6a:3b:20)</div><div> Destination address: 49:00:fa:6a:3b:20 (49:00:fa:6a:3b:20)</div><div> Transmitter address: 28:00:de:6c:11:9e (28:00:de:6c:11:9e)</div><div> Source address: 28:00:de:6c:11:9e (28:00:de:6c:11:9e)</div><div> BSS Id: de:6c:11:9e:de:6c (de:6c:11:9e:de:6c)</div><div> Fragment number: 1</div><div> Sequence number: 2145</div><div> Frame check sequence: 0xf18aa30f [correct]</div><div>IEEE 802.11 wireless LAN management frame</div><div> Fixed parameters (2 bytes)</div><div> Reason code: Unknown (0x7474)</div><div> Tagged parameters (42 bytes)</div><div> Tag: Congestion Notification</div><div> Tag Number: Congestion Notification (116)</div><div> Tag length: 116</div><div>[Malformed Packet: IEEE 802.11]</div></blockquote></div></div><div><div><br></div></div><div><br></div><div>Regards,</div><div>Musti</div><div><br></div><div><br></div><div><br></div><div><br><div><div>On 27 Nov 2013, at 23:48, Ben West <<a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Sometimes weather radar units are put up for sale at Hamfests.<br><br><a href="http://ads22.imgur.com/all">http://ads22.imgur.com/all</a><br><br>Trigger DFS for all your friends, uncooperative spectrum neighbors included. ;)<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 4:00 PM, Michel de Geofroy <span dir="ltr"><<a href="mailto:micheldegeofroy@gmail.com" target="_blank">micheldegeofroy@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div dir="ltr">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.</div>
<div class="gmail_extra"><br clear="all"><div><br><br>Michel<br>
<br><br>Proudly Accepting Bitcoins 178QhTbSins1EnBqyL62k2uUrigh1Xc56Z you too start exchanging in bitcoins and join the revolution :)<br><br>If you want to donate money or more to a good cause check out <a href="http://www.amigosolidarios.com/es/que_hacer.asp" target="_blank">http://www.amigosolidarios.com/es/que_hacer.asp</a><br>
<br><a href="tel:%2B34%20606%2088%2022%2079" value="+34606882279" target="_blank">+34 606 88 22 79</a><br>Skype micheldegeofroy<br></div><div><div class="h5">
<br><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 8:11 PM, Musti <span dir="ltr"><<a href="mailto:musti@wlan-si.net" target="_blank">musti@wlan-si.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Hi,<div><br></div><div>thanks for the reply. Meanwhile I have figured this may be a non-targeted deauthentication jamming. <a href="http://hackaday.com/2011/10/04/wifi-jamming-via-deauthentication-packets/" target="_blank">http://hackaday.com/2011/10/04/wifi-jamming-via-deauthentication-packets/</a></div>
<div><br></div><div>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.</div>
<div><br></div><div>1029548<span style="white-space:pre-wrap"> </span>2450.247257000<span style="white-space:pre-wrap"> </span>28:00:de:6c:11:9e<span style="white-space:pre-wrap"> </span>49:00:1f:86:b5:6f<span style="white-space:pre-wrap"> </span>802.11<span style="white-space:pre-wrap"> </span>102<span style="white-space:pre-wrap"> </span>Deauthentication, SN=2145, FN=1, Flags=........C[Malformed Packet]<span style="white-space:pre-wrap"> </span>-89 dBm<span style="white-space:pre-wrap"> </span>6.0</div>
<div>1029549<span style="white-space:pre-wrap"> </span>2450.252103000<span style="white-space:pre-wrap"> </span>28:00:de:6c:11:9e<span style="white-space:pre-wrap"> </span>49:00:2c:86:b5:6f<span style="white-space:pre-wrap"> </span>802.11<span style="white-space:pre-wrap"> </span>102<span style="white-space:pre-wrap"> </span>Deauthentication, SN=2145, FN=1, Flags=........C[Malformed Packet]<span style="white-space:pre-wrap"> </span>-90 dBm<span style="white-space:pre-wrap"> </span>6.0</div>
<div>1029550<span style="white-space:pre-wrap"> </span>2450.260856000<span style="white-space:pre-wrap"> </span>28:00:de:6c:11:9e<span style="white-space:pre-wrap"> </span>49:00:43:86:b5:6f<span style="white-space:pre-wrap"> </span>802.11<span style="white-space:pre-wrap"> </span>102<span style="white-space:pre-wrap"> </span>Deauthentication, SN=2145, FN=1, Flags=........C[Malformed Packet]<span style="white-space:pre-wrap"> </span>-89 dBm<span style="white-space:pre-wrap"> </span>6.0</div>
<div><br></div><div>Ideas welcome.</div><div><br></div><div>Regards,</div><div>Musti</div><div><div><br></div><div><br></div><div><br><div><div>On 27 Nov 2013, at 18:37, Ben West <<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">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.<br>
<br><a href="http://www.mathyvanhoef.com/2013/11/unmasking-spoofed-mac-address.html" target="_blank">http://www.mathyvanhoef.com/2013/11/unmasking-spoofed-mac-address.html</a><br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 3:19 AM, Musti <span dir="ltr"><<a href="mailto:musti@wlan-si.net" target="_blank">musti@wlan-si.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi folks,<br>
<br>
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.<br>
<br>
Location: Maribor, Slovenia<br>
<br>
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.<br>
<br>
All the packets transmitted have a common BSSID: DE:6C:11:9E:DE:6C and originate from the following devices:<br>
<br>
10:0E:DE:6C:11:9E<br>
E8:00:DE:6C:11:9E<br>
28:00:DE:6C:11:9E<br>
3E:00:DE:6C:11:9E<br>
64:00:DE:6C:11:9E<br>
30:00:DE:6C:11:9E<br>
<br>
As well as<br>
10:0E:00:00:00:00<br>
E8:00:00:00:00:00<br>
28:00:00:00:00:00<br>
3E:00:00:00:00:00<br>
64:00:00:00:00:00<br>
30:00:00:00:00:00<br>
<br>
The MAC addresses do not appear to be from a valid vendor, first to sections changing make no sense really.<br>
<br>
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:<br>
<br>
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<br>
<br>
Some other packets of type ACK and RTS have been seen, but absolutely no data of any form.<br>
<br>
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.<br>
<br>
<br>
Any ideas on what other experiments to do and how to go about finding the source of this “noise” would be appreciated.<br>
<br>
Kind regards,<br>
Musti<br>
wlan slovenija<br>
<br>
<br>
<br>
_______________________________________________<br>
Battlemesh mailing list<br>
<a href="mailto:Battlemesh@ml.ninux.org" target="_blank">Battlemesh@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/battlemesh" target="_blank">http://ml.ninux.org/mailman/listinfo/battlemesh</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net/" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br><a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br>
</div>
</div>
_______________________________________________<br>Battlemesh mailing list<br><a href="mailto:Battlemesh@ml.ninux.org" target="_blank">Battlemesh@ml.ninux.org</a><br><a href="http://ml.ninux.org/mailman/listinfo/battlemesh" target="_blank">http://ml.ninux.org/mailman/listinfo/battlemesh</a><br>
</blockquote></div><br></div></div></div><br>_______________________________________________<br>
Battlemesh mailing list<br>
<a href="mailto:Battlemesh@ml.ninux.org" target="_blank">Battlemesh@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/battlemesh" target="_blank">http://ml.ninux.org/mailman/listinfo/battlemesh</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Battlemesh mailing list<br>
<a href="mailto:Battlemesh@ml.ninux.org">Battlemesh@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/battlemesh" target="_blank">http://ml.ninux.org/mailman/listinfo/battlemesh</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net/" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>314-246-9434<br>
</div>
</div>
_______________________________________________<br>Battlemesh mailing list<br><a href="mailto:Battlemesh@ml.ninux.org">Battlemesh@ml.ninux.org</a><br>http://ml.ninux.org/mailman/listinfo/battlemesh<br></blockquote></div><br></div></div></body></html>