So I tried to implement the caffe-latte attack in python with the help of scapy.

Fot those who are not familiar with the attack: it is a client side Wi-Fi attack and it is meant to recover WEP keys from clients.

I know WEP is not really used that much anymore but it would be nice to have a clear and readable python implementation of the attack.
In summary the attack goes like this:

1. An attacker sets up a WEP access point with the same SSID as the network he wants to crack.
2. Lets all client associate regardless of the wep key (since we dont know the real one)
3. Once the client is associated it will try to assign itself an IP (after dhcp times out)
   4.The client sends out a gratuitous ARP packet, we catch it.
4. We flip some of the encrypted bits corresponding to the last byte of the sender MAC and sender IP
5. Apply crc32 to the bitmask used to flip the last bits
6. Append that crc32 to the bitmask and XOR it with the contents of the actual packet. A new valid WEP encrypted ARP request packet should have been created.

For more details visit these links:
https://vimeo.com/23207363
https://vimeo.com/23214950

Now I'm finally going to guide you through how I tried implementing this and compare it to how aircrack-ng has this implemented in C.
The identification of the encrypted ARP packet is done correctly, since I know the key I can decrypt the packet and actually check.

First I get the encrypted wepdata and the ICV (which technically is also encrypted) like this:

wepdata = list(packet[Dot11WEP].wepdata)
original_icv = packet[Dot11WEP].icv

Then I create the bitmask and flip the bits at the index of the last byte of the sender MAC and IP.
The position is correct because I can decrypt the packet and check.
The way the crc32 is done could be wrong..

bitmask = list('\x00' * len(wepdata))
Flip bits of the bitmask corresponding to the last byte of sender MAC and IP respectively
bitmask[len(wepdata) - 11] = chr(randint(0, 255))
bitmask[len(wepdata) - 15] = chr(randint(0, 255))
Create crc32 checksum for the bitmask, the logical AND with only Fs turns it into a unsigned crc32
icv_patch = crc32("".join(bitmask)) & 0xffffffff

Then I XOR the results with the original content and put those value in the packet and send it.

flipped_result = [ chr( ord(wepdata[i]) ^ ord(bitmask[i]) ) for i in range(len(wepdata)) ]
patched_icv = icv_patch ^ original_icv
Put the results back in the packet
flipped_packet[Dot11WEP].wepdata = "".join(flipped_result)
flipped_packet[Dot11WEP].icv = patched_icv

What is wrong about this?

I attached 3 .pcap files. The captures encrypted_real_vs_replayed_arp and decrypted_real_vs_replayed_arp contain 2 packets each, one original and another modified packet (in encrypted form and decrypted form). These were from a wireshark capture and performing the caffe-latte attack with airbase-ng (it works and this is how packets should look).
The other capture called valid_vs_invalid shows two packets, one is the original ARP and the other is the modified ARP by the caffe-latte.py plugin. These packets were captured with scapy.
The WEP key is 12345 for simplicity if you want to analyze encrypted packets or so.

It seems that Wireshark can decrypt the modified packets from airbase-ng correctly but "refuses" to decrypt the modified packets from the caffe-latte plugin. Scapy however can decrypt those packets correctly. Clearly something is wrong about the way the packet is sent.
Here is the part of the wireshark code that decides if it is going to decrypt the packet or not:

/*
* Well, this packet should, in theory, have an ICV.
* Do we have the entire packet, and does it have enough data for
* the ICV?
/
if (reported_len < 4) {
/
* The packet is claimed not to even have enough data for a
* 4-byte ICV.
* Pretend it doesn't have an ICV.
/
;
} else if (len < reported_len) {
/
* The packet is claimed to have enough data for a 4-byte ICV,
* but we didn't capture all of the packet.
* Slice off the 4-byte ICV from the reported length, and trim
* the captured length so it's no more than the reported length;
* that will slice off what of the ICV, if any, is in the
* captured length.
/
reported_len -= 4;
if (len > reported_len)
len = reported_len;
} else {
/
* We have the entire packet, and it includes a 4-byte ICV.
* Slice it off, and put it into the tree.
*
* We only support decrypting if we have the the ICV.
*
* XXX - the ICV is encrypted; we're putting the encrypted
* value, not the decrypted value, into the tree.
*/
len -= 4;
reported_len -= 4;
can_decrypt = TRUE;
}

It looks like something is wrong with the size of the packet. But wireshark and scapy both tell me the total size is 86bytes which is the same as the packets from airbase-ng...

So here I reached the dead end.
What is wrong with my implementation of the caffe-latte attack?
captures.zip

Ok evil twin jams specific wifis and create a rogue access point with that name so victims can connect to it , and then prompt a credential webpage for user to insert their wifi password .
This concept does not have much success because victim will find suspicious , at least the young generation .

A better concept would be hacking the wpa source code to accept any password inserted on wifi with some exclusions , witch is if password is less than 6 characters , doing this then when victim connects to the rogue wifi access point their device is already sending the correct password , all that is needed is to tell wpa drivers to accept connection and parse that password to a file .

Hi! Here is my BTC Wallet address on LATOKEN:
1NdnMupY7s1UTeK3EtNH3LyjKJWDqAM29B

Hi,

I see that you're using MITMf project as dependency, and it's no longer being updated for long time, and bettercap is good replacement, any plans to replace mitmf with bettercap?

Thanks

I am trying to run ETF on kali it shows below error

Traceback (most recent call last):
File "./etfconsole.py,line 3, in
from termcolor import colored
ImportantError: No module named termcolor

I have already installed termcolor /use/lib/python3/dist-packages

I have tried to copy termcolor.py in "/use/lib/python2.7" but no luck.

Any solution to fix this issue.

Does this framework support MITM on WPA APs where you know the shared key, allowing eavesdropping on encrypted 802.11 packets? It is not explicitly stated in the feature description.

./setup.py
/usr/bin/env: ‘python’: No such file or directory

OS: ubuntu 22.04

hi i'm getting this error:

[+] Found previous session from today. Loading it.
[+] Loading last session from 14/01/2018
[+] Loading session 'et'!
Traceback (most recent call last):
File "./etfconsole.py", line 645, in
console = ETFConsole(session_manager.get_command_history())
File "./etfconsole.py", line 35, in init
self.aircommunicator = AirCommunicator(self.configs["etf"]["aircommunicator"])
File "./core/AirCommunicator/aircommunicator.py", line 31, in init
self.air_host = AirHost(config["airhost"])
File "./core/AirCommunicator/airhost.py", line 28, in init
either by argument in the command line or in the etf.conf file")
etfexceptions.MissingConfigurationFileException: [-] Missing Configuration File:
dnsmasq and hostapd configuration files must be specified
either by argument in the command line or in the etf.conf file

updated*

noticed mitm was not installing due to phython3 hyperframe not installing. after installing all dependencies and mitm i'm facing the same issue as running wifi-pumpkin.

└──╼ $sudo ./etfconsole.py
Gtk-Message: Failed to load module "atk-bridge"
Traceback (most recent call last):
File "./etfconsole.py", line 17, in
from MITMCore.etfitm import EvilInTheMiddle
File "./core/MITMCore/etfitm.py", line 6, in
from MITMPlugins.beefinjector import BeEFInjector
File "./core/MITMCore/MITMPlugins/beefinjector.py", line 6, in
from mitmproxy.models import decoded
ImportError: No module named mitmproxy.models

Hi, using Latest Kali 2 fresh install
in the end of the installation, I'm getting some like :

[+] Running scapy-com setup installation
running install
running build
running build_py
error: package directory 'scapy' does not exist
[+] Cleaning up the cloned folder after installation

is there anything particular I shall do to fix this ?

Regards

There are a lot of calls to os.system that only work on Debian based distros. And a lot of calls to NetworkManager.

Calls to NetworkManager are just there to ignore Wi-Fi interfaces but this does not work for all distros and does not work in a VM or Docker.

The framework uses old versions of some libraries because it is written in Python2. This used to be necessary since Scapy did not support Python3 yet, but it does now so it should be possible to update the frameworks base code.

I have my DHCP set up as follows:
gateway: 192.168.2.1
ip_range: 192.168.2.5 - 192.168.2.254
server: 8.8.8.8 8.8.4.4

but whenever I have a device connect to my AP it's not leased an IP
[+] New connected client on 'test'-> ip: None, mac: fc:a6:67:da:32:79 (None)

I'm using an ALPHA adapter as my wlan1 AP and my internal wireless card as connection to the internet