Jump to content

fanbase

Active Members
  • Posts

    19
  • Joined

  • Last visited

Everything posted by fanbase

  1. It can be both, simultaneously. In fact, this is one of the configurations that the jasagerPwn script sets up for you, with impressive effects.
  2. thesugarat, if I recall correctly your solution entails mac address spoofing. Can you tell me the preferred method for mac spoofing on the pineapple? I vaguely recall in a prior posting that someone had offered one method, only to be told by sebkinne that perhaps their method wasn't the best. In any case, I remember neither method; though I know mac address spoofing is very basic, I would greatly appreciate a quick walk-through of the commands to be used.
  3. I'm very interested. I've tried setting up a OpenVPN connection between my pineapple and VPS but haven't succeeded. This has tremendous potential for an extended MITM attack through the VPS with, e.g., metasploit.
  4. It crashes and reboots when I use the SSLstrip infusion, and that alone (besides Karma). I'll let it run a few hours, check in later, and find that the sslstrip log has restarted with something like the name "log_70." The syslog confirms that an uncommanded reboot occurred at some point since I last checked in on the pineapple. (Incidentally, the sslstrip logs themselves show quite a few errors like "cannot concatenate 'str' and 'NoneType' objects" and "'twisted.internet.error.DNSLookupError'"— not sure if that is related.) It also seems to crash and reboot rather more promptly when I try to combine sslstrip with anything else: nmap, Trap Cookies, urlsnarf... I'll be in Hong Kong next week; I'll look into buying a serial TTL cable while I'm there. Sounds like a project. In the near term, any insight on what might be causing these uncommanded reboots — and how to avoid them?
  5. My pineapple crashes and reboots a lot. I'd like to figure out why. Common sense tells me to begin by sifting through something like a system log that might detail the events that led to each crash. The trouble is, when I look at the log available through the web interface after a crash, the first entry only begins 0:38 seconds after the reboot. No events are listed prior to it: Jan 1 01:00:38 Pineapple kern.info kernel: [ 30.720000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) This makes it difficult to determine what precipitated the uncommanded reboot. How and where do I find log files that would detail events that are occurring prior to the uncommanded reboots? If the answer involves the Log Check infusion or the "custom tail" option, perhaps someone could steer me toward resources that might help in understanding how to use it? I really don't know where to begin.
  6. As it happens, I had a chance to try the work-around this morning -- and remotely from another city, at that! I SSH'ed into the Pineapple through my VPS, then issued the following command: /etc/init.d/uhttpd restart The web interface, which had previously been hung up and was not loading, popped up instantly when I hit refresh in the browser. Does this solve anyone else's problem?
  7. I tested it again by pulling the plug. What was already in the log stayed saved in the log. A new log, titled "Log_70" -- because the pineapple believes it is January 1970 in the moments immediately after it powers up again (and after auto sslstrip has started) -- picks up where the previous log left off before the crash. So, yes, thesugarat, the error with the logs is partly mine own: Each time I backed up sslstrip logs via scp after repeated crashes/unresponsive webUI/plug-pulling cycles, I overwrote my previous log, which of course was also named "Log_70". The essential problem, however (at least for me and, as I understand it, the OP), is that the web interface periodically crashes -- by which I mean it refuses to load or respond -- even though the pineapple remains responsive through SSH. Some further googling turned up this suggestion: Look for these two proccesses: root@Pineapple:~# ps -ef | grep http 1749 root 1136 S /usr/sbin/uhttpd -f -h /www -r Pineapple -x /cgi-bin 1755 root 1160 S /usr/sbin/uhttpd -f -h /pineapple -r Pineapple -c /e If not, try to restart them. /etc/init.d/httpd script You can also use following command: # /etc/init.d/httpd restart # /etc/init.d/httpd start # /etc/init.d/httpd sto I have no idea if that works but it won't be long (at this rate) before I give a shot. Hope you folks try, as well and report back
  8. Cell phone jamming is actually legal in Indonesia, where I live. It's commonly used in mosques, near the entrances of upscale hotels and clubs (rcIED risk), prisons, and, ironically, from what I surmise (based on incidental, non-technical observation) the US Embassy. Not only are jammers incredibly common, so are malicious femtocells and mobile botnets. Unregulated. It's an RF wild west. While jamming can prevent communication in emergencies, it can also save lives. I can also attest that these devices are massively disruptive beyond their intended area.
  9. I'm logging to the SD card. It's a class 10.
  10. I also have this problem. After running sslstrip for an hour or so, return and attempt to open or refresh the web to check its progress. It doesn't load. I can ssh into the pineapple, no problem. What really frustrates me, though, is that when I invariably have to unplug the pineapple (or ssh in and kill -9 the PID for sslstrip), I lose everything the log that had been building! Good stuff -- poof! gone, vanished. It's happened about 6-8 times today alone. And I knew I had some good stuff in those logs, too... The problem predates the latest release, but in my subjective experience, seems to have been exacerbated by it? Maybe just coincidence. I'm willing to work with anyone who wants to test/work this problem.
  11. I haven't tried an ubuntu VM setup. With all due respect to Chris, I thought his tutorial was a little idiosyncratic, since (as I understand it) the setup it yields doesn't work if your network has a firewall that you can't control. An Amazon setup takes little more effort, and (for me at least) removed some of the confusion that a VM introduces. It also allows you to administer the pineapple from any network, anywhere, any time. I did have to watch episode 1112 about 20 times, though. Good luck!
  12. What does it mean when I see this in the sslstrip log?:
  13. Cheeto, I did a writeup last week about configuring a relay server for free on Amazon's EC2 service. I hope it helps you when your pineapple arrives. Configuring a relay for the first time, in my experience, was both easier and harder than others have made it out to be. There's no GUI for this kind of thing. Once you do have your pineapple, you will almost certainly be rolling up your sleeves and mucking around in Terminal more than you expect. I am still learning, but it seems that not all the infusions' GUIs give you the predictability and full range of features that the same program, executed from Terminal, would.
  14. 0.08 BTC reward for whomever can set this up for me and explain how they did it. I'll gladly turn over my keys temporarily.
  15. Thanks for your reply, GuardMoony, but your answer seems at odds with the OpenVPN website: Really? The OpenVPN website seems pretty emphatic that you can't mix tap and tun, as do the comments in the config files: https://forums.openvpn.net/topic14913.html http://openvpn.net/index.php/open-source/faq/community-software-general/305-what-is-the-difference-between-a-tun-device-and-a-tap-device.html Is there something I'm not getting?
  16. I'm trying to set up a VPN tunnel for all traffic connected to the Pineapple in client mode, with the tunnel endpoint being my Ubuntu VPS out in the cloud. The goal here is to provide internet access to all clients connected to the Pineapple, while enabling more powerful MitM attacks like Metasploit using my VPS. I've installed OpenVPN on both my server and Pineapple and set up their respective keys, but I am at a loss now as to the proper configuration. Tun? Tap? Br0? lo? Should I be using tap0 or tun0 for each side of the tunnel? (And how does it hook into the pineapple's traffic?) Could someone kindly sketch out the ideal configs for this kind of setup? In an earlier post, Sebkinne referred a user to this "howto", which specifies the client [=pineapple] as tap0. Forgive my ignorance, but don't you want to make the OpenVPN client side [=pineapple] "tun0" and the OpenVPN tunnel's endpoint on the ubuntu server "tap0"? (Which in turn redirects internet traffic to its internet-facing eth0 interface?) I'm lost. In advance, thank very much for any help you can offer.
  17. My apologies for the delayed reply; after staying up all night to work the problem, I didn't have the heart for a write-up that same morning. My curt "solved" was meant only to save folks from devoting their energies toward my problem unnecessarily. (Hopefully, this detailed answer will cache some good karma, since my next post on VPN tunneling really will require some help!) I had a few hurdles to overcome just to get the ssh connection going. The first and most obvious problem was that I was improperly writing the command for SSHing from my relay into my pineapple. I was specifying the Pineapple by its external IP, rather than "localhost." The .pem key seemed not to be an issue at this step. Apparently, pasting the Pineapple's public key into the relay server's ".ssh/authorized_keys" file (both as ubuntu and root) does indeed work. More on that in a moment. One important point I should make, however, is that the one-step command to connect from your terminal to Pineapple (such as Darren demonstrated in episode 1112.2) does not work in this setup. By which I mean this command: root@kali:~# ssh -i <key>.pem ubuntu@<relay server IP> -p 4255 ...just doesn't work in this setup. Don't know why. You have to do it in two steps. First, SSH from your terminal to the relay server: root@kali:~# ssh -i <keyfile>.pem ubuntu@<relay server IP> next, SSH from the EC2 relay to the Pineapple (as localhost) ubuntu@<relay IP>:~$ ssh root@localhost -p 4255 root@localhost's password: Success! You have your SSH tunnel! Actually, though, there are a few things you need to do first to get there and beyond. Allow me to outline in more detail: The real problem actually came when I tried to set up the web interface. To achieve this, I first modified the Pineapple's /etc/config/autossh file, appending the argument && ssh -f -N -R 6855:localhost:1471 -i <keyfile>.pem ubuntu@<relay server IP>' to the final line of that file. Notice that for this step I used the .pem key, whereas the first part of the command (to set up the SSH connection) uses the "-i /etc/dropbear/id_rsa" argument. Different types of keys, but apparently it works. Don't forget to close that modified argument with the single quotation mark (which was there in the first place). Otherwise, your Pineapple's insides get reformatted into a smoothie. Just kidding. No idea if it's important. And, of course, you need to scp the <key>.pem file to your Pineapple and chmod 400 it. I also modified the Pineapple's /etc/config/uhttpd file, and disabled the RFC1918 checking option like so: option rfc1918_filter 0 A post in a previous thread in the MK4 forums said this is necessary (not sure if this is confirmed). Now for the changes that you have to make on the Amazon instance side: First, you have to modify .ssh/authorized_keys. sudo nano .ssh/authorized_keys You're going to do two things to this file. First, you're going to see some contents already there, consisting of a command and a key (the contents of your .pem file): command="echo 'Please login as the ec2-user user rather than rootuser.';echo;sleep10" ssh-rsa AAAAB3NzaC1yc2EA... Delete everything before "ssh-rsa...". Everything after that is your .pem key; don't touch "ssh-rsa" or anything after it. Just start a new line. Now paste your Pineapple's public key in there on the new line. CTRL + X, save. For some reason, deleting that command from the authorized_keys file -- not just echoing in the Pineapple's key (as demonstrated by Darren and Chris) -- proved to be really important in making the web interface run remotely. My interpretation of the debug output from failed attempts is that maybe it has something to do with permissions for nesting SSH sessions? Even though I'm never actually logging into the relay as root. I really don't know. Next, we need to monkey with sshd_config: sudo -i nano /etc/ssh/sshd_config Make the following changes. If a line below isn't present your file, add it: PermitRootLogin without-password StrictModes no RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys UsePAM yes AllowTcpForwarding yes GatewayPorts yes X11Forwarding yes Save and exit. Now, restart ssh: sudo /etc/init.d/ssh restart Finally, fire up your browser and navigate over to your Amazon EC2 Management Console. Make sure that your security group's rules allow the ports and protocols that you'll be using. Also, on your instance's main page, there's a dropdown menu with an item labeled, "Destination Check/Source Check." Disable that. Not sure if it's critical, but it worked for me. Now, the moment of truth: Let's test whether the tunnel for the web UI works by manually executing the command that starts it (on the pineapple->relay side). To do this, SSH from your terminal to the relay server; then from the relay, SSH to the Pineapple. Once tunneled into your Pineapple, connect back into the relay by manually executing the command that fires up the tunnel for the web UI: root@Pineapple:~# ssh -f -N -R 6855:localhost:1471 -i <keyfile>.pem ubuntu@<relay server IP> root@Pineapple:~# Warning: remote port forwarding failed for listen port 6855 Well that looks discouraging. But let's try dialing it up in a browser anyhow. Navigate to: <relay server IP address>:6855 Success! You get the login page. Works from any computer, anywhere. Lessons learned: Don't just echo when advised to echo in modifications. I learned of several sticking points by opening up each of the config files in nano, combing through them, and then confirming my changes when done. What I'd like to learn to improve on this: 1) Set up a VPN tunnel for all traffic connected to the Pineapple in client mode, with the tunnel endpoint being my VPS, enabling more powerful MitM attacks like Metasploit; and 2) obfuscating the remote web UI as an i2p page. If anyone has any thoughts on what I could have done better, please do let me know. I hope this helps somebody and saves them sleep!
  18. I'm trying to configure AutoSSH to connect to my relay server, which happens to be an Ubuntu 12.04 instance hosted by Amazon's EC2 service. They use .pem certificates. I like them; they're easy. I don't have to mess around with public keys and private keys and Bob and Alice. Sadly, though, the MK5's web UI no longer allows me to specify the command line for AutoSSH, where it seems (at least in previous versions of the UI) I would have been able to replace the "-i /etc/dropbear/id_rsa" with "-i key.pem" and have it work all the same. I followed all the instructions in episode 1112 and (the relevant parts of) Chris Haralson's tutorial. I hoped that doing so would obviate the need for the "-i key.pem" argument when autoSSHing with Amazon's EC2. It did not. When I try to test AutoSSH, it does not connect to the EC2 instance. I need your help. As I see it, there are at least three avenues for solutions: 1) Change a config file in the pinapple's bowels to use an "-i key.pem" argument for AutoSSH (such as I have used successfully when setting up manual SSH sessions - no password required). I prefer this option, for what it's worth. 2) Make the EC2 instance accept whatever crypto the pineapple wants to serve it (what do we call it? an RSA key?). This is basically what I've tried to do so far, by following the instructions given in Darren and Chris's tutorials. It hasn't worked so far, but maybe there's more monkeying around in the server's "sshd_config" or "authorized_keys" that I can still do? 3) Convert Amazon's .pem key into an RSA (public?) key (or whatever it's called) format? Then maybe replacing the contents of the some key file deep in the pineapple's bowls with the output of the pem->rsa conversion? I am not sure this can actually be done; results of preliminary googling are all above my head. Can you folks help me work this problem, walk me through steps for solving it? Thanks in advance.
×
×
  • Create New...