Jump to content

cmw

Active Members
  • Posts

    30
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by cmw

  1. Me: "Have you tried just a regular shell script?" OP: "Yes, I have." Me: "Oh wait, I'm talking to myself... "
  2. I have manually added a client MAC to the Client Tracking Client Management list in the format FC:FC:48:12:34:56. This client's WLAN radio is in the physical environment. For basic testing purposes I have set the tracking script to be: #!/usr/bin/python names = ["fred", "barney", "wilma", "betty", "gazoo", "dino"] datafile = open("/tracking/test.txt", "a") for each in names: datafile.write(str(each) + "\n") datafile.close() Per the help pop-up, python is supported. I have created the /tracking folder and set permissions to 777. I can run this python script manually via an SSH connection to the MKV and it runs fine. The test.txt file is created and the names are added to it. However, the script does not run when saved in the Tracking Script section under the Tracking tab of PineAP. I currently have Karma, PineAP (Beacon Response, Harvester) running. Dogma is not running. But I have tried different combinations of running/not running without success. I have tried reboots and factory resets, all to no avail. The help bubble for Client Management reads: I don't know what is meant by the Pineapple seeing the MAC address in the list; does it just see the MAC no matter what (source, destination, BSSID) or does it have to see the MAC in a specific type of frame (Probe Request, Probe Response, Beacon). Is this really meant to just 'track clients' or is it as the help is worded (i.e. a script will run when the MAC is seen)? Does it run the script EVERY time is sees the MAC or does it just run it once? The Tracking Script help bubble reads: This seems to imply that only Probe Request and Association frames will initiate the execution of the script. Is that true? Does the probing node have to be probing an SSID on the SSID Management List or does it just have to be a Probe Request frame in general (Broadcast SSID, non-PineAP involved SSID)? Is there even a relationship between the SSID Management List and the Client Tracking stuff? The help bubble says the MAC of the tracked client, the event type and the SSID the client probed for are passed to the script. Does that imply that they must somehow be used by the script? Is there any reason my script can't just do its own thing, independent of the information? Finally, are only event type 0 (probe request) and event type 1 (association) passed? Are there other events types that will be passed by the script? If so, is there a legend? Those values (0 & 1) don't really map to Frame Subtype values. If this works they way I think it is supposed to work I can conjure up some pretty amazing things to do. But, as of right now, I can't get it to do anything and documentation seems to be non-existent. Anyone have any insight on this? Please share.
  3. I have seen this mentioned in a few posts but have never seen any resolution. This issue is at least partially display size dependent (i.e. not an issue for folks using large displays). In several infusion detail windows (deauth & Site Survey for example) you cannot see all of the options on the Configuration tab. The Site Survey Infusion can't scroll when there are a lot of SSIDs in the environment (you can scroll on the main menu tile but not in the details page). There is no ability to scroll town to see the truncated sections. In the Deauth Infusion this prevents you from using the web interface to configure the Infusions behavior. Besides the "buy a bigger display" peanut gallery response is there a way to enable scrolling within the configuration details window of an opened Infusion? Sample screenshot:
  4. I can't quite get this to work. Carrier is Verizon. I use Google Authentication and have generated an app specific password for the MKV My [redacted] config is: Gmail Account: <myemail>@gmail.com Gmail Password*: <app_specific_password> Phone Number: <10-digit-phone> SMS Gateway: vtext.com * I tried using my 'regular' Gmail password but didn't receive any messages at all. Sending a test message from Pineapple: Success, message arrives on phone Sending a test email (from Gmail) to <phonenumber>@vtext.com: Success, message arrives on phone Responding to the message from phone: Failure - I get the message back to my phone (and iMessage) but it does not get back to my gmail inbox and it is not received by the MKV The help file suggests that I need to use a different gateway. Verizon has two other possibilities that could be used: vzwpix.com mypixmessages.com When trying either of these I don't receive the test message from the MKV. I'm out of gateway's to try for Verizon. Does this still sound like a gateway issue or is it possible that the app-specific password is an issue? Is sending a keyword message to <phone>@smsgateway.com (7575551212@vtext.com, for example) supposed to arrive at MKV or am I supposed to be sending to a different address? Thank you!
  5. Update: When I run Deauth using aircrack-ng I can see deauthention frames on channel 1, 4, 9 and 11. However, no deauth frames are sent on channel 6, which is where I happen to have been doing most of my work. That is unexpected.
  6. Newer Windows OS' don't respond to broadcast deauth packets; you have to target them individually. (reminds me of their unwillingness to respond to broadcast ping). Could that explain what you were seeing?
  7. It seems random. I have had it work just fine and then come back and use it the next day and all it does is send what Wireshark sees as malformed packets that have no impact on the associated clients. As of now I don't really trust it. I need to explore more and see if I'm doing something weird that I'm not picking up on. Something done this common should be seen by more people if wasn't something on my side.
  8. I am running Deauth 1.7 (which I believe used to be called Jammer) on firmware 1.4.1. I am using wlan1 with a mon0 interface. Simple deauthentication attacks do not work. Screen shots are attached. When I run a deauth using aircrack-ng on Backtrack (or Kali) and capture the packets the deauthentication attack is plain to see (screenshot attached). Moreso, the client is wrecked. When I run deauth using the Deauth infusion the client is unaffected by the attack. Capturing the packets shows a flurry of Probe Response packets being sent whenever the attack is active. There are no deauthentication frames sent by the Pineapple. I saw the same behavior when using the deauth option in the Site Survey infusion. I also ran aireplay-ng from an SSH connection to the Pineapple with the same bizarre result (screen shot attached). I re-flashed the firmware and formatted the SD card (before and after re-flashing) in order to start fresh but results are the same. The forum has random complaints about Jammer/Deauth not working but the lack of mass complaints has kept from thinking that there is something being done incorrectly on my side. Is anyone else seeing the specific behavior or do anyone have a solution? Thanks.
  9. To summarize: In Karma, Client Blacklisting ---------------------------------- - Karma will not respond to or exploit blacklisted MAC addresses (clients) - Your own devices should be blacklisted - Client blacklisting is your ability to tell Karma to leave certain client MAC addresses alone (no matter how much they beg) SSID Blacklist ---------------------------------- - Blacklisted SSID’s will not be impersonated by Karma - Blacklist SSID’s you want Karma to leave alone SSID Whitelist ---------------------------------- - ONLY Whitelisted SSID’s will be impersonated by Karma - Whitelisted SSID are the only SSID’s attacked by Karma - Use a whitlist to attack specific SSID's, leaving all others alone SSID Whitelist/Blacklist is an either/or option (Cannot use both simultaneously) The whitelist/blacklist terminology may make more sense if you think of it as Karma. When something is blacklisted, Karma won't interact with it. Blacklisting bans MAC addresses and SSIDs from Karma, not from the network. When something is whitelisted, Karma can only do something to it. Whitelisting severely constrains Karma, allowing it to only interact with things specified on the whitelist.
×
×
  • Create New...