Introducing knownbeacons extension #825
Conversation
|
@sophron why do we need to create a new extension module? This attack is related to the Lure10 attack why don't we just add those beacons to the lure10 beacon file? |
sophron
changed the title
|
@anakin1028 This is a new attack :) I just updated my first post. |
|
Would love to see this merged. Great contribution @sophron |
|
@kinduff Thank you. @anakin1028 @blackHatMonkey Can you have a look at the PR and let me know if you have any comments? We need this merged in the next few days. |
|
@sophron Looks like an interesting approach but the effectiveness of it is to be seen. |
|
functional test looks fine for me. From the sniffer I can see the spoofed beacons. After the commits are squashed I can help merge this :) |
sophron
force-pushed
the
famous-beacons
branch
3 times, most recently
from
eb56383 to
684ca00
Compare
|
I made a few improvements, including:
I believe it's ready. @anakin1028 or @blackHatMonkey you can merge this! |
| @@ -25,7 +25,7 @@ def __init__(self, shared_data): | |||
|
|
|||
| :param self: A Lure10 object | |||
| :param data: Shared data from main engine | |||
| :type self: Deauthentication | |||
| :type self: Lure10 | |||
There was a problem hiding this comment.
Is there a specific reason you made these changes here. For sake of clarity this should be removed from this PR.
There was a problem hiding this comment.
The main problem is whenever we make functional changes that are not described in a commit. If one of these irrelevant changes breaks the software we will have a hard trouble finding it. But this is only a typo change and I doubt it will introduce any issues.
| self._full_pkt_list = self._get_known_beacons() | ||
|
|
||
|
|
||
| def _get_known_beacons(self): |
There was a problem hiding this comment.
The docstring for this function is missing. We should probably add it.
| addr1=constants.WIFI_BROADCAST, | ||
| addr2=bssid, | ||
| addr3=bssid) | ||
| frame_part_2 = dot11.Dot11Beacon(cap=0x2105) |
There was a problem hiding this comment.
Maybe we can add the 0x2105 in the constants for clarity.
| # If INTERVAL seconds have passed... | ||
| if (time.time() - self._starttime > constants.KB_INTERVAL): | ||
| # Do a list shift | ||
| self._full_pkt_list = self._full_pkt_list[constants.KB_BUCKET_SIZE:] + \ |
There was a problem hiding this comment.
Maybe we can use a round parenthesis instead of the backslash.
There was a problem hiding this comment.
I think it's okay as long as the line wraps properly and the code looks good.
| first_essid = self._full_pkt_list[0][dot11.Dot11Elt].info.decode("utf8") | ||
| last_essid = self._full_pkt_list[constants.KB_BUCKET_SIZE-1][dot11.Dot11Elt].info.decode("utf8") | ||
|
|
||
| self._msg.append("Sending " + str(constants.KB_BUCKET_SIZE) + \ |
There was a problem hiding this comment.
I believe using a formatted string is much cleaner here.
| """ | ||
|
|
||
| # If INTERVAL seconds have passed... | ||
| if (time.time() - self._starttime > constants.KB_INTERVAL): |
There was a problem hiding this comment.
can you explain why this is needed?
There was a problem hiding this comment.
This is because of the (2) addition that I mentioned above. We want to broadcast a specific number of beacons every number of seconds.
There was a problem hiding this comment.
No, sleep() is forbidden within extensions. We run all extensions under a single thread. If we sleep() in one thread, it will pause the execution for all extensions.
sophron
force-pushed
the
famous-beacons
branch
from
684ca00 to
affbc3d
Compare
|
Thanks for the review @blackHatMonkey. I pushed updates for most of your comments. Let me know if there's anything else. |
|
And yes, feel free to open an issue that we ask the users to add known ESSIDs. |
|
I can create the issue once this is merged. |
sophron
changed the title
|
Thanks @sophron~! |
This PR introduces the "Known Beacons" attack. You can try it yourself with
--knownbeaconsor-kB. It is important to run this withroguehostapdinstalled.In this attack we send a number of beacon frames of known (popular) WLANs with no encryption type (Open WLANs). By "popular", we mean WLANs with an ESSID that is either usual for multiple different setups or can be found in many places across the world.
Examples:
Users that visited one of the above WLANs in the past using the default settings are most likely vulnerable to the "Known Beacons" attack. In my experience, all network managers are vulnerable except the one of Windows that, by default, won't automatically connect to Open WLANs.
This looks similar to the KARMA attack but it isn't. In KARMA attack, we exploit two different things: i) active scanning for networks the stations have associated with in the past and ii) the AUTO-CONNECT flag. The "Known Beacons" attack exploits only the AUTO-CONNECT flag.
Having said that, KARMA is getting less successful nowadays as network managers associate with an AP using the "passive scanning" method only. These network managers remain vulnerable to "Known Beacons" if the AUTO-CONNECT is enabled by default.
Of'course this attack will get better and better as we are increasing the size of the dictionary with the known ESSIDs. I believe the Wifiphisher community can help us with that :)
In the future, and when we fully migrate to
roguehostapd, we may want to have this extension enabled by default. In my opinion, it significantly raises the chances of automatic association.The implementation details are pretty straightforward. If you have any questions, feel free to ask me.