Bunny.py: A WiFi darknet that hides its traffic in the noise of 802.11
github.com
This is a project I have been working on for a while now and I would love some feedback.
github.com
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.
(Not sure how well that works for windows, which freaks out at the slightest hardware change, but it seems to work great for linux - I'm doing that at work to get modern hardware and software support of ubuntu while the software we use is only for centos; if I ever want to go back I just remove my extra hard drive and boot from the original again :) )
[1] it had the nvidia proprietary driver hardcoded in xorg.conf -- with a blank config, Xorg correctly auto-configures the neuveuo(sp?) driver when it's running natively and the emulated card driver when running in a VM.
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.
:-\
new standards encrypt management frames, though.
https://github.com/mothran/bunny/blob/master/libbunny/AEScry...
I'm not nearly qualified to talk about that stuff, but instead of requiring PyCrypto maybe you should require Keyczar (http://code.google.com/p/keyczar/) and not have to worry about padding, IVs etc
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.
Maybe I am mis-understanding you. Where would you put the MAC data in a packet? would in be broken up or just stuffed in to a single location for each packet?
Do some benchmarking to prove that it's a serious problem first before rejecting "the right way" as too expensive.
> Where would you put the MAC data in a packet? would in be broken up or just stuffed in to a single location for each packet?
If you use a long enough MAC, say 160 bits, you can split it up and stuff the individual bits anywhere you like. You're the expert in hiding stuff in Wifi packets, not me!
But as it stands (MODULUS = N.NN, REMAINDER = 0.NN) only has 5 decimal digits = 16 bits of entropy. Bunny traffic could be identified after observing just a handful of packets (not even knowing the actual values for M and R).
> But as it stands (MODULUS = N.NN, REMAINDER = 0.NN) only has 5 decimal digits = 16 bits of entropy. Bunny traffic could be identified after observing just a handful of packets (not even knowing the actual values for M and R).
Very true, I will add this to my TODO list, thanks.
better: why not implement a lower level without crypto then layer a known good crypto on top? so just go for datagrams (udp), then add reliability (tcp), then add, say tls. I don't know much about this (sorry), but I bet once you have udp there are libraries to do almost all the rest.
https://pypi.python.org/pypi/simple-crypt
for python 2 it is still a good pycrypto example - the code is pretty simple.
There are peer-reviewed standard cipher modes that provide a cryptographic checksum with a low overhead per block plus one extra block cipher operation per message. These are generally known as single-pass authenticated encryption modes. GCM mode is probably your best option. If you're willing to rekey every 64 GB, are releasing your code under an OSI-approved Open Source license, and you're okay using a mode that's patented, OCB mode is another option.
Really, you don't want to use a static key. Ideally you'd either use the shared master key just to provide confidentiality (in case ECDH is broken) and authentication for ECDH session key agreement. Failing that, you'd use the shared master key and the current time to generate the session encryption keys in order to limit the amount of traffic under a given session key that an attacker can use.
session_counter = (AES256_enc(master_key, 0) + time()) | 0x0FFF; session_key = AES256_enc(master_key, session_counter); will generate for you a 128-bit key that changes every 1.13 hours (2^12 seconds). If an attacker can notice some traffic pattern that gives away when the rekey happens, this will give away the lower 12 bits of AES256_enc(master_key, 0), but this is very little plain text to work with. Note that due to the | 0x0FFF, it's impossible to accidentally use the leaked bits in a session key by using AES256_enc(master, 0) as a session key. If you want a 256-bit session key, it's best to use a second 256-bit shared key to encrypt session_counter to generate the second 128-bit half of your session key. Of course, in practice you'd pre-calculate when the session_counter rolls over rather than recomputing the session key for every packet. You either live with data being lost a few seconds every hour, synchronize clocks very well using GPS or NTP, or else calculate two sets of session keys and use the MACs to figure out which key the sender is using. When using two sets of session keys, you'd throw away the "expired" key and calculate the "upcoming" key 2^11 seconds after session_counter rolls over. (That is, you actually roll your pair of session keys half out of phase of when you'd roll a single session key.)
Edit: Changed to use C's xor operator for exponentiation since Python's double-asterisk notation doesn't display properly on HN.
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... :
if (round( (size - 4) % MODULUS, 2) == REMAINDER):
print "pack num: %d, " % n
MODULUS = 1.21
REMAINDER = 0.85
The mod/remainder values are agreed upon by the network operators, that is why they are in config.
The length % mod == remainder trick for detecting packets was inspired by the KIS rootkit in the later 90's. http://packetstormsecurity.com/files/25029/kis-0.9.tar.gz.ht...
(I think?)
(yes, I know about rounding, fractions, different bases - I was just trying to explain why it still worked. sigh.)
If you know enough about floating point to prove that the rounding will always give you the correct answer, then probably you would have just used the integer representation to begin with.
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?
Does it allow me to chat over someone's WiFi network with another client running this software?
Something else?
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.
The packets sent wont be routed ? So this is a peer to peer / adhoc network between two clients who not only will encrypt their messages but will write it in invisible ink too.
It's a really cool hack, and mothran probably knows more about wifi packets now than anyone is legally allowed.
But if I am in a situation where the enemy is so sophisticated they can infer useful information from my non hidden encrypted traffic I am going back to filling in the Times crossword on a bench in st James park
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.
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.
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)
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?