You are trying to infiltrate a specific computer inside a large corporation. You have a wireless USB key that you sneak in and plug it into a target computer.
The problem is issuing commands to that USB dongle (which I assume is running some sort of OS).
If the dongle sets up a new wireless network it will be detected by rogue AP scanners (common feature in many enterprise access points). So instead you stick your data in a covert channel. You then sit in the parking lot and communicate with your device without it tripping any IDS systems. At least for now until the IDS systems start looking for weird packets with data stuffed in all the wrong places.
Can you elaborate on the OS on a USB thing? You mean you'd reboot the machine to the OS on the USB? Wouldn't that trigger things? Or that machine merely a conduit?
Why not just be honest, and let everyone know that the fate of (2.4Ghz)802.11a/b/g/n/ac residential/commercial/enterprise/carrier grade rests on an unencrypted management packet framework(that some may argue is defective-by-design).
Until 802.11ad implements alternative methods of handling client/station management, it only takes one deauthentication packet to cause client(s)/AP interference, and possible interception/eavesdropping.
> To detect a bunny specific packet, each outbound packet is resized to match pre determined pack_len % mod = remainder values. Then when looking for packet bunny just tests each packets length against the modulus and remainder values.
The crypto is super simple currently. I have spent a long time trying to figure out a better solution but currently there is a single round of AES-256 in CBC mode, each message gets a random IV.
To answer the first questions from this, 1) yes I know there is no MAC I am working on that and could use some ideas 2) forward security is not built in, but if you can find a quicker way to renegotiable mpOTR we might be in business.
Any feedback would be great, I would really like to improve Bunny to be more solid in its use of crypto.
You're sending the IV as part of the data, and the IV is not encrypted. The message being sent is time.time(), which is hugely predictable. The padding is easy to attack, and the inclusion of the IV means you'll get the first data block too.
"Bunny is intended to act as a layer 1/2 technology that attempts to hide its wireless mesh communication traffic."
I think there's a lot of interest in this article but also a lot of uncertainty.
There are some interesting comments on the theoretical basis of Bunny and Bunny packets, but as someone without a lot of technical knowledge of this area, I don't know:
How effective Bunny is in practice?
How visible is it...?
If I were a network security professional, would I notice Bunny on my wireless network?
Perhaps the author or a knowledgable person could speak to these questions?
Cool, this is using pylorcon. I forked it to have fun with it. Let's see where can I manage to put this, and what kind of fun can be had. Hmm..., I can even send commands through this. Fun. Thanks for open sourcing this.
No problem man, if you get it working on your hardware that is not listed in the README, please tell me. I would love to keep a easy to find list of supported chips.
To answer you directly - no, you technically don't chat "over someone's WiFi network". If you're thinking TCP/UDP, the ability to see other computers on a LAN segment, access to encrypted data over a WPA2 connection, etc. - that's too many layers up in the OSI model.
Bunny lives down at the layer 1 / layer 2 model - hardware to hardware communication. Negotiation of connections that eventually lead to joining a subnet, etc.
Since it's at this lower level, it still hasn't "signed on" to a WiFi network - it's just chattering like it would like to sign onto one. No traffic from a bunny client makes it any farther than devices that can directly hear the broadcast. For bunny to work correctly, your device would have to be within range of another device using bunny such that you could pick up the packets as they were broadcast directly from the device.
TL;DR: Nothing is routed.
bunny monitors the WiFi traffic, regardless of network, that it can see in the area. It then builds up a model of what packets it can see (the packets have identifying fields, bunny builds up a list of the common values it sees in those fields) and builds similar looking packets (with values from those lists). Here's the code for the 'fake packets' that it can make:
The main difference between its fake packets and the real ones are that bunny repurposes part of the packets that normally don't contain any real data (vendor specific fields that are part of packets, but rarely used) and swaps them out with AES encrypted data that bunny understands (using an encryption key in config.py).
Any other bunny client with the same encryption key can see these broadcast fake packets, determine that they're fake (they're built in a very particular way), and then attempt to decrypt the data using the key it knows.
If it can decrypt the data into something meaningful, then data can be broadcast back and forth between the bunny clients.
The main packet types bunny clones are:
* Beacon: the packets that announce the presence of a WiFi network. These will be close clones of the existing beacons and are will contain the same core information the real beacons contain. A client looking for a WiFi network may end up using a bunny generated beacon to attempt signing in - but the actual connection negotiation won't be handled by bunny itself. bunny might be the source of the packet that causes WiFi network "Your Local Cafe" to appear in your available WiFi network menu, but it won't ever be involved in connecting you beyond that.
* Probe Response: This is the client counterpart to a beacon packet, basically. It's a client saying "Hey network <SSID name here> - are you there?" WiFi APs will likely respond to it with a "Yes, I'm here" but it won't go beyond that - bunny won't do anything with the responses.
* LLC QOS: This packet has the most potential to do something, in that it's a link level flow control quality of service packet. It's the kind of thing that one piece of the network would send to the other saying: 'Whoa, please slow down - too much data right now on <this stream>'. However, part of the data that's fudged in this packet is the sequence number. An invalid sequence number should cause any receiver of the packet to ignore it, making it safe for bunny to do this.
Yes-- that's what it does. Nodes need to agree on a pre-shared AES key, a modulus, and a remainder, and with that information they can monitor the wifi network to locate Bunny frames.
I glanced over the "proposal.txt" file and I think a reasonable summary is as follows: Bunny monitors a wifi network to build a model of the types of common packets it "sees". Once it has built the model it can transmit data covertly by sending packets with a crafted length (based on a couple of pre-shared values) that are similar to the "average" traffic on the network. Bits of AES-encrypted data are stored in some of the various header and payload fields that are "sloppily" defined in the 802.11 standards. Other Bunny nodes are able to recognize these frames because their length modulus the pre-shared modulus value will equal the pre-shared remainder value.
Bunny basically sends raw packets are that build around a model of 802.11 packets that it has seen. It spoofs all the fields and then injects little bits of data into certain 802.11 fields that are rarely used or have someone random data when they are. So this means that bunny is essentially a ad-hoc style network that hides is traffic to look like whatever wifi networks are around.
Basically with a bit of work you should be able to implement something approximating a tty type interface over this, which means that you could (theoretically) sit in the car park running a metasploit session on an evil box hooked into the target network in a very difficult to detect manner.
It also provides all kinds of interesting potential capabilities for anonymous communication across crowded networks. This could be great for co-ordinating drug deals or suchlike but is probably better still for co-ordinating protests and exporting information when GSM's down.
It's not for hacking into other people's network, it's for communicating wirelessly invisibly. It hides in other people's wireless signals so that an eavesdropper doesn't even see it's there
From my reading of the included proposal.txt, it uses steganography to have side-channel communications that look like other wifi communication near you.
I'm in the same boat, maybe I am just not familiar enough with this kind of software but I can't tell, do you have to have the SSID/Key to connect or does this piggy-back on it somehow?
I did something similar as in using the wifi chip for non-intended purposes (but not the same as you did with bunny) a few years ago.
Used same chipsets hehe.
I found that lorcon and aircrack's libs were both lacking tho. It appears not much has changed :/
Made it in C as i eventually forked off aircrack's lib to fix stuff (lorcon is nicer yes, but the code is so abstracted that it makes it painful to modify)
Note: These are by far the WORST chipsets on the market, the RX sensitivity makes them almost worless for any kind of application besides cracking WEP passwords.
I have this model. Can you explain a bit more what the issue is with the RX sensitivity. Are there any workarounds?
This would not work on a lot of large enterprise networks that use RSSI (Received signal strength indication) to detect malicious devices. Unless you are close to one sender and are sending data at the same time as this sender is sending its data.
[+] [-] jtchang|13 years ago|reply
You are trying to infiltrate a specific computer inside a large corporation. You have a wireless USB key that you sneak in and plug it into a target computer.
The problem is issuing commands to that USB dongle (which I assume is running some sort of OS).
If the dongle sets up a new wireless network it will be detected by rogue AP scanners (common feature in many enterprise access points). So instead you stick your data in a covert channel. You then sit in the parking lot and communicate with your device without it tripping any IDS systems. At least for now until the IDS systems start looking for weird packets with data stuffed in all the wrong places.
[+] [-] lifeisstillgood|13 years ago|reply
[+] [-] jvictor118|13 years ago|reply
[+] [-] skeletonjelly|13 years ago|reply
[+] [-] drippingwet|13 years ago|reply
Until 802.11ad implements alternative methods of handling client/station management, it only takes one deauthentication packet to cause client(s)/AP interference, and possible interception/eavesdropping.
:-\
[+] [-] euroclydon|13 years ago|reply
[+] [-] jdthomas|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] guelo|13 years ago|reply
[+] [-] Repeaterbird|13 years ago|reply
[+] [-] tptacek|13 years ago|reply
[+] [-] marshray|13 years ago|reply
https://github.com/mothran/bunny/blob/master/proposal.txt :
> To detect a bunny specific packet, each outbound packet is resized to match pre determined pack_len % mod = remainder values. Then when looking for packet bunny just tests each packets length against the modulus and remainder values.
https://github.com/mothran/bunny/blob/master/libbunny/SendRe... :
https://github.com/mothran/bunny/blob/master/libbunny/config... : What?![+] [-] mothran|13 years ago|reply
To answer the first questions from this, 1) yes I know there is no MAC I am working on that and could use some ideas 2) forward security is not built in, but if you can find a quicker way to renegotiable mpOTR we might be in business.
Any feedback would be great, I would really like to improve Bunny to be more solid in its use of crypto.
[+] [-] cabacon|13 years ago|reply
[+] [-] wulczer|13 years ago|reply
https://github.com/mothran/bunny/blob/master/libbunny/AEScry...
[+] [-] tlow|13 years ago|reply
I think there's a lot of interest in this article but also a lot of uncertainty.
There are some interesting comments on the theoretical basis of Bunny and Bunny packets, but as someone without a lot of technical knowledge of this area, I don't know: How effective Bunny is in practice? How visible is it...? If I were a network security professional, would I notice Bunny on my wireless network? Perhaps the author or a knowledgable person could speak to these questions?
[+] [-] orangethirty|13 years ago|reply
[+] [-] mothran|13 years ago|reply
[+] [-] danabramov|13 years ago|reply
Does it allow me to chat over someone's WiFi network with another client running this software?
Something else?
[+] [-] pudquick|13 years ago|reply
Bunny lives down at the layer 1 / layer 2 model - hardware to hardware communication. Negotiation of connections that eventually lead to joining a subnet, etc.
Since it's at this lower level, it still hasn't "signed on" to a WiFi network - it's just chattering like it would like to sign onto one. No traffic from a bunny client makes it any farther than devices that can directly hear the broadcast. For bunny to work correctly, your device would have to be within range of another device using bunny such that you could pick up the packets as they were broadcast directly from the device.
TL;DR: Nothing is routed.
bunny monitors the WiFi traffic, regardless of network, that it can see in the area. It then builds up a model of what packets it can see (the packets have identifying fields, bunny builds up a list of the common values it sees in those fields) and builds similar looking packets (with values from those lists). Here's the code for the 'fake packets' that it can make:
https://github.com/mothran/bunny/blob/master/libbunny/Templa...
The main difference between its fake packets and the real ones are that bunny repurposes part of the packets that normally don't contain any real data (vendor specific fields that are part of packets, but rarely used) and swaps them out with AES encrypted data that bunny understands (using an encryption key in config.py).
Any other bunny client with the same encryption key can see these broadcast fake packets, determine that they're fake (they're built in a very particular way), and then attempt to decrypt the data using the key it knows.
If it can decrypt the data into something meaningful, then data can be broadcast back and forth between the bunny clients.
The main packet types bunny clones are:
* Beacon: the packets that announce the presence of a WiFi network. These will be close clones of the existing beacons and are will contain the same core information the real beacons contain. A client looking for a WiFi network may end up using a bunny generated beacon to attempt signing in - but the actual connection negotiation won't be handled by bunny itself. bunny might be the source of the packet that causes WiFi network "Your Local Cafe" to appear in your available WiFi network menu, but it won't ever be involved in connecting you beyond that.
* Probe Response: This is the client counterpart to a beacon packet, basically. It's a client saying "Hey network <SSID name here> - are you there?" WiFi APs will likely respond to it with a "Yes, I'm here" but it won't go beyond that - bunny won't do anything with the responses.
* LLC QOS: This packet has the most potential to do something, in that it's a link level flow control quality of service packet. It's the kind of thing that one piece of the network would send to the other saying: 'Whoa, please slow down - too much data right now on <this stream>'. However, part of the data that's fudged in this packet is the sequence number. An invalid sequence number should cause any receiver of the packet to ignore it, making it safe for bunny to do this.
[+] [-] EvanAnderson|13 years ago|reply
I glanced over the "proposal.txt" file and I think a reasonable summary is as follows: Bunny monitors a wifi network to build a model of the types of common packets it "sees". Once it has built the model it can transmit data covertly by sending packets with a crafted length (based on a couple of pre-shared values) that are similar to the "average" traffic on the network. Bits of AES-encrypted data are stored in some of the various header and payload fields that are "sloppily" defined in the 802.11 standards. Other Bunny nodes are able to recognize these frames because their length modulus the pre-shared modulus value will equal the pre-shared remainder value.
[+] [-] mothran|13 years ago|reply
[+] [-] _b8r0|13 years ago|reply
It also provides all kinds of interesting potential capabilities for anonymous communication across crowded networks. This could be great for co-ordinating drug deals or suchlike but is probably better still for co-ordinating protests and exporting information when GSM's down.
[+] [-] shawabawa3|13 years ago|reply
[+] [-] friendcomputer|13 years ago|reply
[+] [-] joshstrange|13 years ago|reply
[+] [-] zobzu|13 years ago|reply
Used same chipsets hehe. I found that lorcon and aircrack's libs were both lacking tho. It appears not much has changed :/ Made it in C as i eventually forked off aircrack's lib to fix stuff (lorcon is nicer yes, but the code is so abstracted that it makes it painful to modify)
[+] [-] silasdavis|13 years ago|reply
[+] [-] alexkrycek|13 years ago|reply
rtl8187 - Alfa AWUS036NH
Note: These are by far the WORST chipsets on the market, the RX sensitivity makes them almost worless for any kind of application besides cracking WEP passwords.
I have this model. Can you explain a bit more what the issue is with the RX sensitivity. Are there any workarounds?
[+] [-] punnerud|13 years ago|reply
[+] [-] informatimago|13 years ago|reply
[+] [-] losethos|13 years ago|reply
[deleted]