fringes

Seb, what is it with your fixation on that? I remember you putting that up in the studio windows in one of the first shows in the new warehouse.

So DataHead, was this an April Fools resurection of a 5 year old puzzle? What ever happened to those coins, ZWP '/QWAOE/MCYKB'/C, eef5204d6a.hak5.org, etc.? I'd forgotten all about it.

And if you're working from a Windows box, you might like to use putty and WinSCP, very nice SSH and SCP clients.

Thanks, Seb! Now it works with just the root and I restored the original trust store.

Ok, I got my pineapple bar to work again. They got the cert from a new source, and none of the interediate issuers were in the trust chain: /etc/ssl/certs/cacert.pem I simply exported the three issuers (root and CAs) and concatenated them into a new cacert.pem. Seb, please issue a new /etc/ssl/certs/cacert.pem, as I don't think everyone will be up for this.

Well, there is a new cert and it expires: 5/1/2017 And https://www.wifipineapple.com/?downloads&list_infusions&mk5 seems to return the correct JSON data. I rebooted my MkV, and still no infusions on the pineapple bar. Since the above link is returning the data to my browser and the certs now look good, I'm wondering if there were any kind of caches on the pineapple that could be causing this. Or could the new certificate have a trust chain that isn't accepted by the pineapple? I didn't save the old cert, so I can't compare them.

In case it wasn't clear, this expired certificate is almost certainly breaking the Pineapple Bar infusion.

Yeah, sorry. The URL is: https://www.wifipineapple.com/?infusions, but there are no links. Might have to search the code in the pineapple bar infusion. Edit: Have a look at: /pineapple/components/system/bar/files/downloader The wget command (no SSL) is: wget "http://wifipineapple.com/mk5_infusions?infusion=$name-$version" -O /sd/tmp/infusions/$name-$version.tar.gz So for example: http://www.wifipineapple.com/mk5/infusions.php?infusion=sslstrip-2.1 will download the sslstrip-2.1 bundle.

I just noticed that, I think the URL is actually: https://www.wifipineapple.com/?infusions But there are no Download links there either. Still looking. Edit: I believe I answered your question in your post under the infusions support (https://forums.hak5.org/index.php?/topic/34961-infusions-site-offline/?p=259493 ) Still holding this topic for the expired certificate.

Did you go to the site in your browser? You can just click through the SSL warning.

I've tethered the pineapple to my laptop and used OpenVPN from there, but that wasn't a great solution. You could also try using proxychains with SSH SOCKS, but I haven't tried that. The real solution will be the OpenVPN infusion that doesn't exist yet; I hope we see it soon.

I saw over i the Infusions section that someone reported the infusions site as down. When I checked https://www.wifipineapple.com/?downloads, I observed that the certificate expired today. I suspect that's why the Pineapple Bar iswn't working this morning. I tried to reach Seb in the chat room, but it's probably sleepy time over there, and there is probably someone else (Darren) that would handle the certificate anyway.

Confirmed. Whe I look at the "Available Infusions" tab in the Pineapple Bar, there are none. I believe the URL you're looking for is https://www.wifipineapple.com/?downloads It's the same used by the pieapple, but the certificate expired today. Sooo I'm guessing that's probably the problem.

I comented in another topic recently, but those scripts are not friendly in identifying the correct processes (or interfaces) on the pineapple. I think it's the stripped down OS (or dropbear); some of the tools are missing functionality.

Sorry Lord_Snake, I actually referred you back to this topic. (It's the medication.) But look through this topic because I believe something like this script has been discussed here.

I've had two micro-SD cards roll over and die (stop working). If you are not already comfortable making symbolic links, I would spend some time getting to know Linux (or other *nix) before you start reorganizing your file systems.

But... This creates a hard dependency on your SD card which could be a pain if it rolls over as they are want to do.

Linset is interesting, but it's still in Spanish. Does it create a WPA/WPA2 AP, or is it just doing a deauth (capture handshake) attack and putting up an unprotected twin?

For your client/victim to be challenged, you would have to provide an WPA2 AP. If you do that, the password they enter will be hashed before being returned to AP. A deauth attack would be easier. For the user to receive your fake challenge, you already would have your own malware on the victim's machine. If you can do that, you don't need to capture just an AP password; you'd already own their box. The WPA2 handshake is network, not web related. A practical and effective way to capture the AP password is with the SE attacks described above by J5x86.

Have you looked through the WPS infusion support thread? https://forums.hak5.org/index.php?/topic/31454-support-wps/ It's huge I know, but you might find some similar discussions there. (I think that's where I saw it.)

I think you missed my point. The pineapple does create a real acccess point. And if it's WPA or WPA2, the user will be challenged (by his own software) when he attempts to connect. I think WPA2 is pretty solid for now. The known attacks are well documented. Edit: Are you asking if PineAP can throw up WPA2 APs?

My Mk5 ran out of internal space too, with nothing installed. I ended up performing a factory reset (from the Configuration infusion) to get back some space. I think my file system layout is wacked, but it's always been that way: root@Pineapple:~# ls -l / drwxrwxr-x 2 root root 731 Jan 12 22:39 bin drwxr-xr-x 7 root root 900 Jan 1 1970 dev drwxr-xr-x 1 root root 0 Jan 30 14:53 etc drwxrwxr-x 13 root root 740 Jan 12 22:39 lib drwxr-xr-x 2 root root 3 Oct 9 23:02 mnt drwxr-xr-x 9 root root 0 Jan 1 1970 overlay drwxrwxr-x 1 root root 0 Jan 9 15:32 pineapple dr-xr-xr-x 69 root root 0 Jan 1 1970 proc drwxrwxr-x 17 root root 252 Jan 12 22:39 rom drwxr-xr-x 1 root root 0 Mar 15 13:31 root drwxrwxr-x 2 root root 744 Jan 12 22:39 sbin drwxr-xr-x 10 root root 4096 Jan 1 2014 sd drwxr-xr-x 11 root root 0 Jan 1 1970 sys drwxrwxrwt 14 root root 420 Jan 1 2014 tmp drwxr-xr-x 1 root root 0 Mar 23 2013 usr lrwxrwxrwx 1 root root 4 Jan 12 22:39 var -> /tmp drwxrwxr-x 1 root root 0 Mar 8 18:32 www root@Pineapple:~# df -h Filesystem Size Used Available Use% Mounted on rootfs 3.2M 1.3M 1.9M 40% / /dev/root 11.8M 11.8M 0 100% /rom tmpfs 30.2M 120.0K 30.1M 0% /tmp tmpfs 512.0K 0 512.0K 0% /dev /dev/mtdblock3 3.2M 1.3M 1.9M 40% /overlay overlayfs:/overlay 3.2M 1.3M 1.9M 40% / /dev/sdcard/sd1 28.7G 566.6M 26.7G 2% /sd Note that my /var is sybolically linked to /tmp. How does that happen?

I re-read your post and I think I understand. I believe you want to mimic a WPA2 AP such that a user that connects is challenged by their own OS software for the key. But you want to capture that key at the AP. No, for the user to get that challenge, it must be a real WPA/WPA2 AP. I suppose there might be some way to capture the key they entered, although the handshake would fail. This would take some research though. I would never say there's no way to do it because breaking security is what we do. However, I believe this would be a hard nut to crack. So I believe a simpler question would be: Is there any facility for the WiFi pineapple (or any AP) to capture invalid keys? Almost certainly not, and if you capture the hash, you still have to crack it. (A deauth attack is easier.) The above video and WiFiphisher both use social engineering attacks to capture the WPA2 key, because that's the easy (perhaps only) way other than capturing the handshake and performing a brute-force password attack.

No, they're identical to each other. I was just saying that if you try to use an RP-SMA connector antenna (such as from your ALFA), you'll need one of these: https://hakshop.myshopify.com/collections/antennas/products/sma-male-jack-to-rp-sma-female-adapter?variant=504035017

Stealing is bad. But I wonder about the implications if that is used during a penetration test. I think it becomes one of authority and scope. I think this Xfinity WiFi hot-spot madness is a security disaster waiting to happen.