Jump to content

cmw

Active Members
  • Posts

    30
  • Joined

  • Last visited

  • Days Won

    3

Profile Information

  • Gender
    Male
  • Location
    Virginia

Recent Profile Visitors

1,599 profile views

cmw's Achievements

Newbie

Newbie (1/14)

  1. If you have installed the Site Survey module by Whistle Master (currently version 1.3) on the Tetra running version 2.02 you may notice that running a capture does not work. Examining the contents of the capture.sh script in /pineapple/modules/SiteSurvey/scripts/ I noticed on line #58 of the script that the capture files are supposed to be stored in: /pineapple/modules/SiteSurvey/capture/ Unfortunately, there is no folder named 'capture' so things go poorly. Simple fix; create the capture folder and you should be good to go! mkdir /pineapple/modules/SiteSurvey/capture I have several Pineapples so I'll check to make sure this isn't an isolated issue.
  2. The web interface for the DNSMasq Spoof module is pretty limited compared to what dnsmasq can actually do for you. As if often the case, graphical interfaces are nice but the real power is on the command line. The dnsmasq service is initialized from the script located at /etc/init.d/dnsmasq. This script points to a config file located at /var/etc/dnsmasq.conf. That file (dnsmasq.conf) is autogenerated each time dnsmasq starts by the configuration file located at /etc/config/dhcp (so modifying it is a no-no). The script at /etc/init.d/dnsmasq also appends an entry to the /var/etc/dnsmasq.conf file that points to /etc/dnsmasq.conf as an additional configuration file. This file (/etc/dnsmasq.conf) is one of two that you can safely modify. The dnsmasq.conf file is located in /etc/ on the Pineapple. The last entry in the configuration file is: addn-hosts=/pineapple/modules/DNSMasqSpoof/hosts/dnsmasq.hosts This points to the configuration file that contains the entries you see in the Hosts section on the DNSMasq web interface. This file is the 2nd one you can safely modify. The syntax for this file, which you can modify from the DNSMasq Spoof web interface (or from the CLI), is: <ip_address> <name> <name> <name> where <ip_address> is the IP address you wish the name(s) to resolve to and where <name> is the exact hostname/FQDN that will be entered by the user. For example: 172.16.42.1 starwars.com www.starwars.com ftp.starwars.com Important note: This file, which you can configure via the DNSMasq Spoof web interface does NOT support wildcards (but there is an alternative ...keep reading) and requires you to enter the exact name(s) you expect the user/system to enter. Hint: If you are not sure of all the names a user may enter for a certain website, try visiting the real site and see if there is an SSL/TLS certificate. If there is one, examine the Subject Alt Name section in the certificate Extensions area for a list of other DNS Names The DNSMasq Spoof web interface on the Pineapple does not allow you to spoof ANY query for a domain name (i.e. no wildcard support). In order to have wildcard support, complete the following steps: Stop DNSMasq SSH into the Pineapple Open /etc/dnsmasq.conf using your preferred editor. If desired, additional host entries (that will NOT be visible or configurable from the web interface can be added to this dnsmasq.conf file) To add a single entry in the dnsmasq.conf file (IPv6 & ttl are optional): host-record=<name>,<name>,<name>,<name><ipv4><ipv6><ttl> Example (with no ttl specified): host-record=appleinsider,www.appleinsider.com,appleinsider.com,172.16.42.1,2002:46a8:d6a3:1::100 You can also create a wildcard entry for any specific domain name by adding the following syntax to the /etc/dnsmasq.conf file: address=/.<domain.tld>/<ip_address> Example: address=/.startrek.com/172.16.42.1 This will resolve ANYTHING that is .startrek.com to 172.16.42.1. For example: www.startrek.com --> 172.16.42.1 ftp.startrek.com --> 172.16.42.1 asdf.startrek.com --> 172.16.42.1 beep.boop.boop.beep.startrek.com --> 172.16.42.1 server1.europe.startrek.com --> 172.16.42.1 The ultimate wildcard value: You can also configure dnsmasq to resolve EVERTHING (literally) to an address by adding the following to /etc/dnsmasq.conf: address=/#/172.16.42.1 When making changes to the Hosts section on the DNSMasq Spoof Pineapple page, remember the following: Each line is an entry Wildcards (*) are not supported Seperate each value with a space, NOT a comma Click Save after modifying the Hosts section The interface offers no validation of the input. Put your entries in carefully. You must stop and restart the service after changing the Hosts section. Other considerations: The /etc/dnsmasq.conf file supports many other entries such as email MX records. Check out the dnsmasq documentation (Google it) for more options. Sample MX record: mx-host=<domain.tld>,<server_fqdn>,<priority> mx-host=example.com,mail.example.com,10 If your target node already has locally cached entries for the Host entries you create they will not be resolved to what you desire until that entry ages out on the local host. If the target node has entries in its local hosts file they will be used over the entries in DNSMasq. If you are testing this in a lab environment you can clear resolver caches on different sytstems as follows: Windows ipconfig /flushdns Linux - A lot of Linux systems don't cache DNS entries. But if they do, you have a couple of options depending on the system. Here are some possibilities: sudo /etc/init.d/nscd restart systemctl restart nscd systemctl restart dnsmasq systemctl restart rndc MacOS - For all newer versions of MacOS sudo dscacheutil -flushcache If HSTS is enabled for a web site and the IP address to which you send the host is not HTTPS, they will not connect (Google, for example). Wanna try things out? A simple captive portal page that I very badly modified from a wifiphisher (or was it fluxion?) sample page can be downloaded here (I'm was shooting for proof-of-concept rather than convincing and fancy ...don't hate.): wget http://s3.amazonaws.com/ITdojoClassroomData/landing.tar.gz Extract these files and place them directly in /www on the Pineapple (NOT in the 'landing' folder). If desired, you can paste the contents of the index.html file in the Landing Page section of the DNSMasq Spoof page. This allows you to make modifications to the file from the web interface. When you save the page in the Landing Page section of the DNSMasq Spoof web page the contents are saved as /www/index.php (which the web server prefers over index.html). In the fake firmware upgrade page the SSID and PSK values entered are written to a file called wpakeys.txt in the /www/ directory. The data entered into the index.html file are posted to the firmware.php page which writes them to a text file and then displays a (not very) convincing firmware upgrade progress button. Hope this helps. Play nice. CMW
  3. I have several Tetras. Unfortunately, they crash/reboot very often. It fills me with nostalgia for my days as a Windows user. I have a Nano, too, but don't use it often enough to say if it crashes with the same frequency.
  4. In the top right hand-corner change it from "Suggesting" to "Viewing". That should help make it readable.
  5. Nobody else has looked at this since January? That's a bit disappointing. If I can get the default script to run I can turn my attention to extending the functionality of this feature. There are two scripts located in /etc/pineapple/. They are: tracking_script tracking_script_user tracking_script_user is the script you see in the web interface on the Tracking page. By default it is: #!/bin/bash echo $MAC echo $TYPE # 0 PROBE; 1 ASSOCIATION echo $SSID The contents of tracking_script are: #!/bin/bash export $MAC export $TYPE export $SSID [[ "$(uci get reporting.settings.tracking)" == "1" ]] && { [[ "$TYPE" == "0" ]] && { echo "$(date): Probe request from $MAC for SSID '$SSID'" >> /tmp/tracking.report } || { echo "$(date): Association from $MAC to SSID '$SSID'" >> /tmp/tracking.report } } /etc/pineapple/tracking_script_user This latter script reads the value of "option tracking" in the file at /etc/config/reporting. root@Pineapple:~# cat /etc/config/reporting config reporting 'settings' option interval '1' option log '0' option clear_log '0' option survey '0' option duration '15' option client '0' option tracking '0' option save_report '1' config reporting 'ssmtp' Using the command in the script from a terminal yields a value of '0' (as seen in the file above) root@Pineapple:~# uci get reporting.settings.tracking 0 The script tracking_script exports the values $MAC, $TYPE and $SSID but they aren't defined. The script is configured to echo strings of text into the file /tmp/tracking.report using the variables $MAC, $SSID when the value $TYPE is 0. My Tracking tab is seen in the attached image. My PineAP tab is seen in the attached image. When I connect the client listed in the Tracking tab nothing is updated. The script runs but because the values $MAC, $SSID and $TYPE are not defined they don't get written. But, because the value of uci get reporting.settings.tracking is 0 the script doesn't even try. This is evidenced by the fact that the tracking.report file is not created in the /tmp/ directory when the node associates to one of the Pineapple's SSIDs. If I change the tracking_script value uci get reporting.settings.tracking to a "0" and re-connect the node the Pineapple the tracking.report file is created but its contents are: root@Pineapple:/tmp# tail -f /tmp/tracking.report Fri Sep 15 13:52:45 GMT 2017: Association from to SSID '' Fri Sep 15 13:52:45 GMT 2017: Association from to SSID '' Fri Sep 15 13:52:45 GMT 2017: Association from to SSID '' Fri Sep 15 13:53:15 GMT 2017: Association from to SSID '' Fri Sep 15 13:53:45 GMT 2017: Association from to SSID '' This is the text echoed by the tracking_script file but, because the $MAC, $TYPE and $SSID values remain undefined they are not show in the file. Questions: Where are these MAC, TYPE and SSID variables supposed to be coming from? Is the value of uci get reporting.settings.tracking supposed to be changing when a node connects to the AP or when a Probe Request frame is sent? I'm a little confused on what that value means. Can someone from the Pineapple team tell us if there is a bug in this or if we are just doing something wrong? Thanks. Colin
  6. Me: "Have you tried just a regular shell script?" OP: "Yes, I have." Me: "Oh wait, I'm talking to myself... "
  7. 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.
  8. 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:
  9. 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!
  10. 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.
  11. 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?
  12. 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.
  13. 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.
  14. 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...