So I've been looking through the WPA and 4-way handshake mechanisms trying to brainstorm the possibilities for creating a fake AP with WPA encryption, an option which seems to be missing from airbase-ng.
Here are my thoughts so far:
I create a fake AP with WPA-PSK encryption flag and set its ESSID to the target AP's ESSID.
By de-authenticating the clients connected to the target AP, the normal reaction would be searching for their AP in the WiFi list.
They would attempt to connect to the fake AP using the password I'm trying to retrieve.
According to this Wikipedia demonstration of the 4-way handshake: https://en.wikipedia.org/wiki/IEEE_802.11i-2004#Protocol_operation
The PTK is never shared on the fly between the AP and the station (client); instead, MIC's are compared.
In packet 2/4, the station sends its SNonce signed with an MIC.
After receiving this packet, the fake AP would skip constructing a PTK and would just send packet 3/4 with a randomly assigned GTK and an MIC (I'm not sure whether this MIC is verified by the client).
So my questions are:
Does the client verify the MIC from the 3rd packet of the handshake?
If it doesn't, does that mean that the client has been successfully authenticated and connected to the AP?
Further thoughts:
In the absence of an AP-sided PTK, can I just send raw un-encrypted data packets to the client for the purpose of DNS spoofing?
In the case that raw data packets aren't accepted by the client, could the Hole196 vulnerability (documented here: http://www.airtightnetworks.com/WPA2-Hole196) be utilized for DNS spoofing, given that the GTK is known by the fake AP?
I hope you're caught up with my question; if you need any further clarification, I'll be glad to reply.
Okay so I've read through the IEEE Std 802.11-2012 documentation, and came to the conclusion that my concept is invalid and not feasible due to the following:
In section 11.6.2 of the IEEE Std, at the bottom of page 1249, the following statement appears:
If the GroupKey or SMK KDE is included in the Key Data field, but the Key Data field is not
encrypted, the EAPOL-Key frames shall be ignored.
This rules out the option of sending an unencrypted GTK to the supplicant (client), knowing that sending an encrypted GTK to the supplicant is not possible as well due to the fact that the fake AP can't generate the actual (client-sided) PTK required for the encryption of the Key Data (including the GTK) in the 3rd EAPOL message of the four-way handshake.
The encryption of the Key Data field in WPA2 CCMP is usually achieved through the NIST AES key wrap algorithm documented in IEFT RFC 3394.
My assumption that the GTK could be sent to the supplicant unencrypted (before I arrived to that section of the IEEE Std) also ended up with a complete failure; it's further explained in section 11.6.6.4 of the IEEE Std 802.11-2012 on page 1259:
On reception of Message 3, ..., the supplicant also:
...
b) Verifies the Message 3 MIC. If the calculated MIC does not match the MIC that the Authenticator
included in the EAPOL-Key frame, the Supplicant silently discards Message 3.
Again, since the fake AP can't generate a valid PTK, it can't calculate the valid MIC for Message 3, which results in a discarding of the message and failure of the operation.
Related
I am trying to analyze probe response .pcap files of a network to deduce the security protocol (as in wpa, wpa2, wep, open network).
I realized that in some beacon .pcaps, there is a tag with the wpa information and in the following image for example, it says that the WPA version is 1, meaning the security protocol is WPA. But in other beacon .pcaps that tag doesn't appear and I'm guessing it is not always there because that tag is vendor specific.
Either way, I couldn't find this tag in any probe response .pcaps and couldn't figure out the security protocol from the RSN Information tag. For example I tried checking if AES is in the Pairwise Cipher Suite List (since it isn't used in WPA, but is used in WPA2), but it appears in both WPA and WPA2 networks. Is there a reliable way to do this with any captured probe response packet?
When I use bep_0005 get_peers method to find an infohash like "1111111111111111111111111111111111111111", I can receive the response with "values' key, But when I use bep_0003 to send BitTorrent protocol handshake to each peer in "values", Peers always disconnect TCP connect, In fact, It seems Peers don't have ut_matadata.
Why node send me fake data?
There are several possible causes for this
Old utorrent versions returned values stored for the nearest target key if they did not have an exact match. this was fixed a while ago but many people are still running old clients
Various dubious implementations monitoring the DHT try to harvest data by responding to any and all get peers request with values and then recording connection attempts for whatever reasons
Malicious entities use bittorrent clients as dDoS amplifiers by inducing them to spam targets with TCP connnections
But there are various measures a node can implement to sanitize that data.
The packet identifier is required for certain MQTT control packets (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.html#_Toc385349761). It's defined by the standard as a 16bit integer, and is generated by each client. The identifiers are reusable by the client after the acknowledgement packet is received. So the standard allows up to 64k in-flight messages. In practice, the clients I've looked at seem to just increment a counter, and so allow a total of 64k messages to be sent by a client. Both of rust MQTT client libraries panic when that counter overflows. (UPDATED 2016-09-07: if the rust clients are compiled in release mode then they don't panic, the value of the Packet Identifier becomes 0 -- in normal circumstances this will work, but...)
Does anyone know of an MQTT client that allows more than 64k messages/client (i.e. re-uses packet identifiers)? I'm wondering if this is a limitation that I need to be aware of in general, or if it's just a few clients. I've taken a quick look at compliance tests and haven't yet seen much to indicate that this is checked -- I'll keep looking.
Edit: It could be that some clients achieve this as a side-effect of limiting the number of in-flight messages. UPDATE 2016-09-07 the rust clients do it by assuming they can wrap on overflow and never catch up to lagging messages (maybe a good bet, but not assured, and with an ugly outcome if it happens)
As you have pointed out, the packet identifier are intended as temporary value that must persist until the published packet is received and acknowledged.
Once acknowledged, you can reuse the identifier (or not).
Most client runs on embedded system and they don't track more than a single packet (so only a single identifier is being handled) since they wait for ACK or REC/COMP before making any other publishing.
So for these clients, even a single identifier would be enough.
Please notice that for QoS 1, remembering the identifier is futile since it's valid to resend the packet if the next packet is not an ACK (so you have the identifier to reply with in the packet you are receiving).
For the rare clients that do support interleaved publish packets, they only need to support 2 valid identifiers at any time (that is, in the case they have received a QoS 2 packet, answered with PUBREC and then receive another QoS 1 or 2 packet).
Once they receive a PUBREL packet they can reply with a PUBCOMP without needing to remember the identifier (it's in the PUBREL header), so the only time they do need to remember identifier is between the PUBLISH and the PUBREC packet. Provided they allow interleaved publish packets, the only case where a second identifier is required is when they are publishing while receiving a published packet at the same time.
Now, from the point of view of the broker, most implementation use a 16-bit counter per client so they could support, in theory, up to 65535 in-transit packets.
In reality, since the minimum size of a publish packet is 8 bytes (usually more), that means having to store at least 9 bytes per potential packet (the additional byte is for remembering the current state in case of QoS 2) so that's half a MB of memory in the minimal case, but likely much more in real life, since you never have an empty publish payload and topic name.
As you see, it's almost impossible for an embedded system to implement with such storage requirement so shortcut are taken.
In most scenario, either the server does not allow so many un-acknowledged packet (by simply replying to the client in order to release the identifier) or use the identifiers pool between different clients.
So typically, again, the worst case for the broker can only happen if the client does not acknowledge the published packets. If the broker does not get any answer from the client it can:
close the connection
refuse to send new published information or
ignore the answer and republish
All of these strategies needs to be implemented anyway since you could have the same issue with a slow client and a fast publisher and your 65535 identifiers.
Since you have these strategies, there is no need to waste a MB of memory per client and instead cut your leg much earlier (while keeping a reasonable working condition).
In the end, the packet identifiers are a tool to deal with identification of recent packets, not a tool to index all packet received. A counter is good enough for this case and a wrapping around should not pose any issue when you account for the memory and bandwidth requirement.
I need to analyze the wireless traffic occurring in Ch 1 of 802.11g. I have captured all the traffic logs using NETMON as test.cap file.
Q: How can extract the information using tshark to suitable format so that it can be used for further post processing?
I have captured all the activity in Ch11 but in wireshark it shows only 802.11 in protocol.
That usually means "the traffic is encrypted and Wireshark doesn't have enough information to decrypt it"; it does represent activity.
So if you're capturing on channel 11, an I/O graph in Wireshark, rather than anything extracted using TShark and further processed, should suffice to show the level of activity on that channel. You'd only have to dissect it if you want to see what type of traffic, at a higher level, that activity is, but it sounds as if you just care about activity, no matter what the packets are.
I have use SNMP v1 and 2c for network discovery of printers by sending broadcast message with community "public" and it works just fine, but when I send broadcast message with version 3 of the protocol I got timeout error.
Do somebody share example of SNMPv3 device discovery?
Thank you.
Two things:
1) Doing a broadcast SNMPv1/v2c is actually not defined to work in the protocol. Cheap implementations will simply respond, as you've found, to any packet it sees that the kernel accepts to the port and not check the address. However, you'll also find some implementations that will not respond to broadcast packets. So that's actually not a surefire discovery mechanism in the first place. (Let alone, many vendors finally got smart and don't have public be the default community name)
2) SNMPv3, on the other hand, is even less likely to work because of how engineID discovery happens within the SNMPv3 protocol. SNMPv3 won't respond with a normal response PDU anyway, as it should respond with a REPORT PDU saying "this is my engineID" and you'd have to respond back with that engineID and the proper USM credentials to access the device.
In short, SNMPv3 was designed for security and there isn't a "public" equivalent any longer. You'd need to know how to access the device and can't just "guess".