vidkun

Johnnie: Yes, as far as I understand WPA2, it is technically possible if the attacker knowns the PSK (which was a stated condition of the OP's question). Condor: After watching your signature in utter amazement for a good 5-10 minutes, I'm missing the point of your post. Or maybe it's the early hour and lack of both coffee and sleep. What were you getting at?

The AP does not "authenticate" that it is a legitimate AP to the client. It "authenticates" itself by confirming that it knows the correct pre-shared key which is verified by successfully completing the 4-way handshake. So if I sit in your parking lot and setup an AP advertising your SSID and I configure it to use the same PSK that your legit APs are using, then your clients will still successfully associate to my rogue AP. That is a misleading use of the term authenticate in that article.

True, the PSK is never sent during the 4 way handshake. But it is used along with the SSID (both known values at this point) to derive the PMK. So if we have the PSK and the SSID, why isn't it possible (at least theoretically) for Karma to derive the PMK, generate and send an ANonce, receive the client's SNonce, then verify the PTK of the SNonce, and complete the authentication/association process?

digininja's explanation makes sense for why $ doesn't work, but what about spaces? Changing your password through the GUI with a space in your password truncates your new password at the first space as well.

stealkit: My skills aren't anywhere good enough to code what you are talking about, though it would be a cool idea. I had also wondered how hard it would be, and why it hasn't be done yet, to serve as a proxy for 802.1x authentication. Using two wireless radios, one running karma. Client connects to karma on one radio requesting an AP that the other radio sees there already. Then the second radio initiates a connection to the legit AP, proxying/relaying the challenge response between the legit AP and the client. Anyway, as for my project here I have a quick question. I was planning to use DNSSpoof to redirect a client's request for any web page to the captive portal page on the pineapple. The portal then checks if there is a valid session, and if so, passes the client's requested URL along. At least that was the plan until I actually vocalized that to someone today and realized that DNSspoof would just end up catching the redirection at the end and result in a loop. Is there a way to only spoof the request if it is from the clients and have the pineapple use a real DNS server (8.8.8.8) to handle the PHP redirect after logging into the portal? Any thoughts/suggestions on that would be helpful. Thanks. Also, I'll be pushing some code changes to github soon for some fixes to the session handling.

WM, looking for any beta testers?

Nice. Looking forward to playing with this.

I fixed the process.php and it now properly writes the credentials to file and builds the session. Does anyone have any ideas on handling the issue of passing along the originally requested URL and then redirecting to it from success.html?

First off, my web dev skills are greatly rusty these days. It's been a while since I've had the chance to work on anything. Anyway, I was thinking about a way to use the MKIV for a targeted phishing attack. The Idea: A captive portal for harvesting domain credentials of a targeted company (for legitimate pen testing engagements). Using Karma (and possibly a deauth flood), clients connect to the MKIV. DNSSpoof forwards all requests to the local index.php which checks if the client has a valid session. If session is valid, it redirects the client to their requested URL. If session is NOT valid, it redirects the client to captiveportal.html where they are prompted to login with their domain credentials. Submitting the form POSTs to process.php which opens creds.txt, writes the entered credentials, builds the session, and redirects to success.html. Success page makes the client feel good and then redirects to the originally requested page. Implementation: I have attached* what I have done so far for anyone that wants to help out. I currently have a few of the pages done up. Index.php is properly redirecting to captiveportal.html, but when I submit the form I just get a blank white page for process.php. It doesn't look like it ever writes out the credentials or builds any session info. Drawing blanks on that for now. Any thoughts, feedback, code is appreciated. I'd like to eventually get this to the point that it can be wrapped up into a module/infusion for quick and easy implementation. This way, attacking companies with better wireless implementations becomes easier. You no longer have to use freeradius-wpe to capture the challenge/response and then crack. Why waste that time when you can just ask them nicely for their credentials? *It won't let me upload any of the files, so I threw it up in on github here: https://github.com/vidkun/captivePhish

Sadly, it looks like I've run into the same issue with my brand new pineapple. It came with 2.4.1 firmware. I just powered it up, changed the password via the UI utility, poked around in the UI a bit, then used the UI button to reboot for the password change to take effect. When it came back up, neither the new/old password worked. I used the reset button to get back to the default password. Booted it up, logged in to UI just fine, used the UI to change password again making sure to carefully type it correctly, rebooted immediately, and now I'm locked out. As with others, neither the new/old passwords work and the reset button appears to be useless now. Holding for various amounts of time between 5-10 seconds does nothing. Neither does holding it any longer. This sucks. Has anyone found a way to fix this yet (aside from serial cables and clean flashing)? I'm in the middle of trying to brute force the SSH connection on it while I wait to see what else can be done. Sounds like the only options are buy more stuff to fix it myself or try to exchange it. Is that correct? And on another note, has the root cause of this been discovered yet? Thanks. EDIT: Well that was pretty damn quick. I found the correct password (thanks hydra). It seems that changing the password via the web UI does not properly handle spaces in the password. So my password actually got truncated to the first part before the first space. Using that, I was able to SSH in and manually run passwd from there to change it to the correct one. Then I used the UI reboot button to bounce the pineapple and it took the full password with spaces correctly. I just upgraded to 2.7.0 successfully. I haven't tested the UI password change utility and don't feel to interested in doing so. Hopefully the issue has been resolved as of the 2.6.4 release as zettaquark mentioned. And the reset button is working again as well. Hopefully that helps anyone else that runs into this issue.