Jump to content

skimpniff

Active Members
  • Posts

    76
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by skimpniff

  1. @DangerAnt I agree, I think once they get the time and inclination the base OS will be much better. The real issue is the 3rd paryy modules no longer getting worked on. It sucks but I get it, life happens.
  2. Well, I don't feel like going through the many, many posts and comments relating to the issues related to 2.7. If you want to see what I am referring to, please do as I did and start with the 2.7 release thread and scroll through. Then, search 2.7 and see the remaining issues posted. I am not the first to have issues or complaints regarding this firmware update. I am not new to the Pineapple, it's use cases, or the modules. I have been utilizing the Pineapple since it's original incarnation when they first started implementing Jasager. I'm not mentioning this as a brag, only to demonstrate that my concerns are not those of a first time user. One of the issues I have had is Evil Portal freezing the system in 2.7. Newbi3 has already seen my post about that. My other issues are around the modules not really being maintained after 2.5.4. I understand that is a third party dev issue, but a lot of the draw to the Pineapple is some of the outstanding work done by these devs. I use my Pineapple for more than just PineAP and Recon. I have looked for solutions to the problems myself and many others have. There are none as development has not been consistent. I understand there are greater things going on in the world that is impacting dev, which is why I am not harping on the devs. I didn't ask for anyone to unhose 2.7, I asked if anyone knows of a firmware release that is stable will all options working at the same time. So I offer to you, re-read my post, notice the question as well as some of the examples I cited for my complaints, and investigate the other issues the community has for 2.7. If you have any actual insight, I welcome it. If you only have unhelpful commentary to the structure of my post/question, keep it to yourself.
  3. I have been banging my head against the wall over this for days now. 2.7 is hosed. 2.6.x has some issues, like Reporting Emails not working. 2.5.4 is where dev stopped for most of the modules, and supposedly has working Reporting email, but the sd card not mounting or randomly unmounting issue makes it unreliable as a drop box. Does anyone have any suggestions on a stable version that has everything working properly, or is this just a "pick your poison" situation?
  4. I am also dealing with this issue. I have had no luck on the 2.6.x versions and rolled back to 2.5.4 because another user said that fixed it for them. I have had no such luck. I know that 2.7 reports it has fixed this issue, but it is so broken in too many other respects for me to entertain it as an option. Does anyone have any ideas, suggestions, or fixes?
  5. Actually rolled back to 2.5.4 since the report email issue was never fixed in 2.6.x.
  6. No. I have basically given up on PortalAuth. I haven't had a working version since 2.4.x and the benefits of being on the upgraded firmware outweigh the usefulness of PortalAuth right now. I am running 2.6.1 as it has been the most stable. It would be nice if the module development would resume, but it seems like that ship has sailed as everyone has moved upward and onward. I miss the good ol' days when Darren and company were running shit out of the basement and still had the passion for the projects. I also ant to state for the record that 2.7 is basically unusable for anything worth doing and should be pulled if nobody is going to work out the kinks. EDIT: Realized the PortalAuth references were not related. Too many hours staring and consoles. Yes, rolling back to a version before 2.7 has fixed all EvilPortal related issues. My apologies @newbi3
  7. I had everything running fine and then made the mistake of upgrading to 2.7. Now whenever I fire up evil portal, it runs fine, I capture creds, and everything seems to be in order except...I no longer able to access the pineapple via hardwire or wireless to the management interface. No access to the webgui or ssh. Once I pull power and the nano reboots, I can get back in and see the captured creds (which are only found in the PortalAuth Captured Creds and not in the EvilPortal logs?). I have done my due diligence searching the interwebs/forums and haven't seen anything regarding this. If there is already a post, thread, and/or solution please point me to it. Has anyone else had this issue and have a solution? For now I am going to downgrade to 2.6.2 to see if things go back to working as desired.
  8. So I got openvpn successfully installed. Here is what I ended up doing for anyone else working this issue. The problem stems form th source repository. Sinc the OG cloud.wifipineapple.com repository is now defunct you need to edit the opkg.conf file to replace the old src/gz line with this: src/gz packages http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packages For me to get this working I did a full reset to purge any other source lists and associated info. Im sure there is a more manual way to do this, but I didn't feel like futzing with it. After the reset, I modified the file, performed the opkg install, and voila. For further understanding for those who care, the issue stems from having the wrong package source in previous attempts. The Alpha121U (aka PA MkV) can only use openwrt version 12.09 and any other versions packages will not work, causing the errors to throw due to incorrect installer details specific to the OS version. Many hours of Google and config file putzing around, but I have a working openvpn access point now. I hope this helps ohers in the same sitch. Cheers.
  9. I have not found an answer for this in all of the Internets. Does anyone have some help? Install returns the following: root@Pineapple:~# opkg install openvpn-openssl Package openvpn-openssl (2.3.11-1) installed in root is up to date. Configuring liblzo. //usr/lib/opkg/info/liblzo.postinst: line 4: default_postinst: not found Configuring openvpn-openssl. //usr/lib/opkg/info/openvpn-openssl.postinst: line 4: default_postinst: not found Collected errors: * pkg_run_script: package "liblzo" postinst script returned status 127. * opkg_configure: liblzo.postinst returned 127. * pkg_run_script: package "openvpn-openssl" postinst script returned status 127. * opkg_configure: openvpn-openssl.postinst returned 127. It appears there is an issue installing the dependencies. root@Pineapple:~# opkg info openvpn-openssl Package: openvpn-openssl Version: 2.3.11-1 Depends: libc, kmod-tun, liblzo, libopenssl Provides: Status: install user unpacked Architecture: ar71xx Conffiles: /etc/config/openvpn 5d0a69b4290e1896d683289069351dcd Installed-Time: 1511825392 root@Pineapple:~# opkg install libc Package libc (0.9.33.2-1) installed in root is up to date. Configuring liblzo. //usr/lib/opkg/info/liblzo.postinst: line 4: default_postinst: not found Configuring openvpn-openssl. //usr/lib/opkg/info/openvpn-openssl.postinst: line 4: default_postinst: not found Collected errors: * pkg_run_script: package "liblzo" postinst script returned status 127. * opkg_configure: liblzo.postinst returned 127. * pkg_run_script: package "openvpn-openssl" postinst script returned status 127. * opkg_configure: openvpn-openssl.postinst returned 127. Any ideas?
  10. A simple reboot makes them available. I am just trying to figure out the root issue so I can fix it if possible. In a test environment it is merely an inconvenience, but for a live audit I need to know that everything will be available on initialization.
  11. I install all of my modules to the SD card. Every time I power on the Nano, the modules do not load. Once I perform a reboot, the modules are present. I ensure I do a proper Shutdown command each before powering it down, and that has not seemed to make a difference. Is there anything that can be done to ensure SD card modules load on first boot?
  12. Ok. Basic question, I apologize. I have successfully gotten PA to clone sites and the inject sets are working properly. The issue I am now facing is that on submit, the user is being redirected to /captiveportal/index.php What is the recommended way to get a redirect to a real URL on the interwebs? Also, I am getting "You are not authorized." What could be causing that? @sud0nick @newbi3
  13. @sud0nick I am not sure what the final verdict ended up being but I am no longer experiencing the error I reported before. The only thing I did was to create a symlink for /root/portals to /sd/portals. Prior to the symlink I was getting the same error, created the symlink and tried again, no issues. Perhaps there was a storage issue on root that was contributing. Whatever the reason, I was able to successfully clone the page I provided for demo purposes. Thanks for taking the time to take a look at my issue, you and the rest of the team are pretty awesome and I appreciate all of your work. Been following Hak5 since the basement days in Va. --------------------------------- EDIT: So, now that I have a successful clone (all the files seem to be present), I am only getting a blank page displayed. I hosed up my regular Nano landing page script (Config page), so it is now blank. Is there something required in that page for EP to work? I thought it was only for basic landing page stuff, which is why I didn't think too much about it when I cleared the script. I tried adding: <?php header("Location: /sd/portals/wifi/index.php", true, 301); exit(); ?> to test the theory and got the same results. EDIT: Seems to be limited to that site. Our fav coffee site seems to be doing just fine.
  14. Thanks Nick. Also, I have done a factory reset and fresh install of the modules so there is no chance of misconfiguration due to user error.
  15. Hey guys. EP is not populating portal auth portals saved to sd. I poked around the EP files lookig for an obvious smoking gun, but was not able to find anything meanigful (to me). Any advice on how to correct? Nano 1.1.3 All modules installed to sd.
  16. Hey team. I have dusted off the Nano and am working through the various EP and PA scenarios. So far I have yet to get a site to clone properly with PA. I have gone through a series of sites and injection sets to see if there is a commonality, to no avail. Here are my findings so far, I'm hoping you can help me get back on my feet. Nano Firmware:1.1.3 All modules installed to sd. Test site: http://www.wi-fi.org (tried to find a http site figuring https may be part of the issue) Log out put: /sd/modules/PortalAuth/includes/scripts/libs/requests/packages/urllib3/connectionpool.py:747: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html InsecureRequestWarning) Traceback (most recent call last): File "/pineapple/modules/PortalAuth/includes/scripts/portalclone.py", line 24, in cloner.cloneResources() File "/sd/modules/PortalAuth/includes/scripts/PortalCloner.py", line 186, in cloneResources r = self.session.get(urlparse.urljoin(self.url, img.get(tag)), stream=True, verify=False) File "/sd/modules/PortalAuth/includes/scripts/libs/requests/sessions.py", line 473, in get return self.request('GET', url, **kwargs) File "/sd/modules/PortalAuth/includes/scripts/libs/requests/sessions.py", line 461, in request resp = self.send(prep, **send_kwargs) File "/sd/modules/PortalAuth/includes/scripts/libs/requests/sessions.py", line 573, in send r = adapter.send(request, **kwargs) File "/sd/modules/PortalAuth/includes/scripts/libs/requests/adapters.py", line 415, in send raise ConnectionError(err, request=request) requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine("''",))
  17. @sud0nick To address your redirect comment in the "Real Issues" post on page 1: the way I got around this was with a trick I learned from you in different post (about landing page images not showing up of all things). I just added the "require_once" code to the landing page, pointing to my evil portal page. This way, the auth page pops before they even get a chance to try to navigate. After auth, they can go where they please without the wonky redirect/caching issue. For those unfamiliar and wanting to know wtf I'm talking about enter the following syntax on your landing page php file: require_once('path/to/your/evil/portl/index.php'); You can find the path easy enough by navigating to the portal in question via Cabinet > www > captiveportal > Just copy and paste the already provided path under "location".
  18. Hey guys, I am running into an issue with getting openvpn-openssl installed on my old mk iv. I just got the nano and want to repurpose my mk iv to be an openvpn client (episode 2018). The old package path in the opkg.conf file is 404. So I rummaged around the internets for a while and found the openwrt path with openvpn in it (http://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/packages/base/) but when I install I get a 127 error: Configuring openssl-util. //usr/lib/opkg/info/openssl-util.postinst: line 4: default_postinst: not found Configuring liblzo. //usr/lib/opkg/info/liblzo.postinst: line 4: default_postinst: not found Configuring openvpn-openssl. //usr/lib/opkg/info/openvpn-openssl.postinst: line 4: default_postinst: not found Configuring openvpn-easy-rsa. //usr/lib/opkg/info/openvpn-easy-rsa.postinst: line 4: default_postinst: not found Collected errors: * pkg_run_script: package "openssl-util" postinst script returned status 127. * opkg_configure: openssl-util.postinst returned 127. * pkg_run_script: package "liblzo" postinst script returned status 127. * opkg_configure: liblzo.postinst returned 127. * pkg_run_script: package "openvpn-openssl" postinst script returned status 127. * opkg_configure: openvpn-openssl.postinst returned 127. * pkg_run_script: package "openvpn-easy-rsa" postinst script returned status 127. * opkg_configure: openvpn-easy-rsa.postinst returned 127. Do you have any advice or an old mirror or something so I can get this bad boy up and running? The old threads form 2012 have 404 pages as well. Thanks in advance.
  19. Just to add a little fun to this conversation, I recently discovered that if you have more than one instance of the option ssid "fun name here" in the /etc/config/wireless file the pineapple with broadcast multiple ssids and will allow connections from any selected. What better way to increase your chance of a bite than to have more than one lure on the line.
  20. So, deciding to take another approach, I want to bounce the idea off the forums to see what you guys have to say. Supposing the IP of the Pineapple was a non-issue because it is either associated to the customer/target (WAN/LAN for example) or the 3G dongle is non-attributable, and also supposing the server setup for SSH relay was also non-attributable, wouldn't simply using torsocks (http://code.google.com/p/torsocks/) be an acceptable solution for anonymous remote access to the Pineapple? ie. torsocks ssh login@host This seems easier than running Tor hidden services on the relay SSH server and everything that would go along with that setup. That being said, it has been my experience that if it seems easy there is probably a catch. Other than a potential username leak, this seems like a good answer. So I leave it here to QC the idea. EDIT: This is another option that seems to meet the same purpose. http://www.howtoforge.com/anonymous-ssh-sessions-with-tor
  21. So it has been almost a year since this post went up originally. I have played with this off and on since but still have not come up with a solution. Has anyone else found a way? This problem is not limited to when the Pineapple is connected via ethernet to the box running SET. I have had the Pineapple connected via WAN/LAN on my home network with my laptop connected wirelessly and gotten the same result. To recap the problem: DNSspoof on the pineapple config = 192.168.1.4 *.example.com SET running on 192.168.1.4 Client associates to pineapple, navigates to example.com (123.45.678.9) Pineapple redirects request to 192.168.1.4 SET runs exploit SET redirects client to example.com (123.45.678.9) Pineapple redirects to 192.168.1.4 Desired effect: Client associates to pineapple, navigates to example.com (123.45.678.9) Pineapple redirects request to 192.168.1.4 SET runs exploit SET redirects client to example.com (123.45.678.9) Client connects to example.com (123.45.678.9) Any ideas for a solution would be greatly appreciated.
  22. The cloned site is here : /pentest/exploits/set/src/program_junk/web_clone/index.html
×
×
  • Create New...