Jump to content

chrizree

Active Members
  • Content Count

    497
  • Joined

  • Last visited

  • Days Won

    31

Posts posted by chrizree

  1. I simply had to see if I was just "the lucky one" to not experience any problems or if I could force the problem to appear.

    So, now I've tested my Nano with the following cards:

    - Intenso MicroSDHC 4 GB Class 4
    - Intenso MicroSDHC 4 GB Class 4 (yes, yet another one)
    - Kingston MicroSDHC 8 GB Class 10
    - SanDisk Ultra MicroSDHC 8 GB Class 10
    - Kingston MicroSDHC 16 GB Class 10
    - SanDisk Ultra MicroSDHC 32 GB Class 10

    And... they all worked! Can't seem to replicate the problems that are reported by some when it comes to SD cards and the Nano.

    In addition to the above, I have my (always working) Kingston 4 GB card since before. So, in total, 7 working SD cards.

    My way of "preparing" the cards is to just run GParted and then
    create a new partition table (Device > Create Partition Table... > msdos > Apply)
    Then create a new partition (Partition > New > fat32)
    Insert it into the Nano and boot it up, then go to the Advanced section > USB & Storage > drop down > Format SD Card
    Wait for the format to finish, then using the card as intended with the Nano

    I'm using FW 2.7.0, i.e. the latest available.

  2. No one is a veteran when it comes to the CyberSec area of expertise :-) It's an ever changing profession that never rests, so in that aspect it doesn't matter how many years you have in your backpack. Of course, it's an advantage to know a bit of many things, but there are others that are far more skilled than I am.

    So, with that said, if I would buy some Hak5 device myself, I would rather go with the Bash Bunny instead of the USB Rubber Ducky. The Ducky is cheaper and can be more "stealth", but the Bunny is more powerful and versatile and easier to use in my point of view.

    If you by XL mean Excel files such as xls/xlsx, I can't really see any big difficulty in adjusting the script you have found to take care of those kinds of file types as well. It should only be a matter of changing "pdf" and "txt" to "xls" and/or "xlsx". It's a bit difficult to say though without seeing the script itself and what it is actually doing.

  3. When it comes to email, you aren't restricted to Gmail only. Any smtp based email delivery should work.

    As far as I know, you have to go with an alternative firmware for the Ducky to be able to store files on the Ducky SD card. The original firmware is read only in "attack mode". Check the article linked below from Null Byte, it's a bit aged, but gives a hint of what might be needed.

    https://null-byte.wonderhowto.com/how-to/modify-usb-rubber-ducky-with-custom-firmware-0177335/

    As an alternative, it's possible to use an ordinary USB flash drive attached to the same computer as the Ducky, but that is kind of a gamble since you most often don't have a clue of how the USB flash drive is enumerated by the OS, i.e. what drive letter (for Windows) that it will eventually get.

  4. I've documented my "USB Charger Router" on my GitHub, check the link out:

    https://github.com/chrizree/UCR

    It offers an AP using OpenWRT and when connected to the wireless network, it's of course possible to SSH into it as well as using the LuCI web gui that comes with OpenWRT. It is possible to configure it to join an already existing wireless network that can automatically be connected to when starting the device. In its current configuration, it doesn't have any reverse VPN, but it's pretty easy to add using an OpenVPN-AS to create a "bridge" into the device from a remote location. The microphone functionality is not available, but could be solved since the hardware used allows USB attached audio devices. It gets a bit bulky though, so it's not fitted in "my" device. With another case/charger, it could be done.

  5. Do you mean known "ordinary" wireless networks? It's possible in the WiFi Pineapple web interface. I always have my Nano to connect to one of my own networks when in reach. I use the USB port for an additional WiFi adapter (wlan2) and let it connect to provide the Nano with an internet connection without interfering with the Nano functionality using the onboard radios (wlan0 and wlan1). It's for sure possible to use one of the onboard radios but, as said, it might reduce the functionality of the Nano. It all depends on how you use the Pineapple. It might not be a problem in your specific case.

  6. Have you tried with or without the "equals sign" (=) when specifying language? Not sure if it makes any real difference (I don't have my Bunny around at the moment so I can't test it), but the documentation is rather non-stringent when it comes to the use of the equals sign or not. The Ducky Script page for the Bash Bunny at docs.hak5.org does not specify the use of the equals sign, and the documentation on the Hak5 GitHub uses as well as does not use the equals sign on the same docs page. Kind of confusing, but might not matter at all. You can at least try with or without the equals sign, i.e. DUCKY_LANG=fr or DUCKY_LANG fr and see if it makes any difference.

    https://docs.hak5.org/hc/en-us/articles/360010554353-Ducky-Script-for-Bash-Bunny

    https://github.com/hak5/bashbunny-payloads/tree/master/docs

  7. I usually leave it powered on using a "charger" that doesn't exceed the limits of the Shark Jack (i.e. not using a USB port on the PC even though it should work well, depends on the type of port of course).

    When charging, the Shark Jack is pulling about 0.2A with my setup, then less and less as the charging progresses (just like an old school car battery charger).

    When the Shark Jack is still attached to the charger, but not charging (i.e. solid blue LED), it is consuming about 0.00 - 0.01A, i.e. stops charging but still powered on.

    I can't say anything about the charging circuitry and any "intelligence" built into that. I'll leave that to Hak5 to answer.

  8. If you use the standard Hak5 firmware (and not any of the alternative firmwares around for the Ducky) then you cannot write data to the flash memory of the Ducky. It's read only when inserted into the Ducky. You have to supply an alternative USB memory device if selecting the "Save To USB" option in the Duck Toolkit. To send the report (or whatever) using the email option, you need access to an smtp service to get it all to work. The Ducky won't supply this for you.

  9. This issue is already being discussed in other threads

    https://forums.hak5.org/topic/53188-sd-card-cant-get-to-work/

    I have never had any problems with SD cards on my Nano, so I haven't dug any deeper into the matter. It seems as if there is some kind of solution coming for it. Not sure when though. The Hak5 team has to answer that, but I guess they are pretty occupied with the Mark VII and Cloud C2 v3 at the moment, but... just my guess. There might be other dev resources linked to the Nano specifically.

    • Like 1
  10. It would be easier to help if you elaborate on the scenario at hand, i.e. what are you trying to do in a "step-by-step" fashion. Even posting your current payload script code would be good. Code is worth a thousand words 😉 To know if the payload has finished, you need to look at the screen. The Ducky just keeps on blinking the same way and (as far as I know) this is why Hak5 started to use its now "standard" application of using LED colors and blink patterns for other Hak5 products to communicate with the user/operator. At least that's my guess. There might be alternative firmware for the Ducky that does this. I know that the Ducky can show red color apart from the standard blue. Not sure though about what's possible since I'm using Hak5 standard firmware on my Ducky. As an alternative, you can always use the already mentioned "look at the screen" option. It's possible to, for example, create a GUI popup that looks non suspicious to any user but still signals that the payload has finished. I.e. use PowerShell to create a dummy/bogus popup, or such. "The printer queue has restarted (just ignore this message)" ...ish

  11. Yes, I agree to your thoughts on having Arming Mode as a way to recover. If one messes around with Arming Mode, it might end up in a Owl that gives you problems. Better to leave it "as is". You can get at least some inspiration from the Owl script/payload example that I have on my GitHub. It connects to a known network if available, otherwise it goes on doing any attack set up in Attack Mode.

    https://github.com/chrizree/Hak5-SignalOwl-Loot-or-Scan

  12. Is it mandatory that this needs to happen in arming mode specifically? You could include the possibility to connect to a known wireless network if it's available "in the air" and circumvent any scripted attack in attack mode if so.

  13. If possible, I would suggest that you verify it all in a "clean" environment. I.e. in an OS installed in an ordinary fashion, no Docker container or virtual environment. Just to rule out the fact that there might be some problem with the Bunny itself. If that works, I would then start to hunt down issues in the Docker implementation.

  14. This works for me...

    With no Bash Bunny plugged in, run bb.sh
    sudo bash ./bb.sh or just sudo ./bb.sh 
    (sudo not needed on Kali if you run as "in the old days", i.e. default to use root all the time)

    Run the setup if it hasn't been run on the particular PC before
    [G]uided setup (recommended)

    Plug in the Bash Bunny in step 3

    After the setup is done, unplug the Bunny and run bb.sh again

    Then select (this is most likely the step that you have missed doing)
    [C]onnect using saved settings

    Plug the Bunny in

    You will get the "Cloud>PC>Bunny" Ascii art after a short while which tells that you are ready to go

    Now ssh into the Bunny

    Try to ping (1.1.1.1 or www.google.com), networking/internet access from the Bunny should now work

    ---

    Note that the bb.sh script "messes up" your iptables rules that most likely makes it impossible to access the internet (or network) from the PC after the Bash Bunny session has ended. BE SURE that you know what you are doing if you have other "non default" iptables rules configured! The rules that are added is viewable in the bb.sh script. Just search for iptables in the script file and you will find them all.

    To mitigate this, you need to delete the iptables rules that bb.sh has added. A reboot of the PC should do the job as well, but perhaps you want to use the PC without rebooting after the Bunny session has finished.

    Run the following to get the rule line number (you may need to disable networking)
    sudo iptables -L FORWARD --line-numbers

    Identify the line number for the rule that is about to be deleted and then delete the rule, for example, use the below command if the rule has number 1
    sudo iptables -D FORWARD 1
    (do the above twice since bb.sh adds 2 forwarding rules)

    Also delete the postrouting nat rule that bb.sh adds
    sudo iptables -t nat -v -L POSTROUTING -n --line-number
    sudo iptables -t nat -D POSTROUTING <rule number>

     

  15. Well, even if I can't get my own Nano running, I won't keep any OpenVPN secrets from you 🙂 Try the following...

    Note that this has been done on a LAN Turtle (and also on my "non Hak5" mips_24kc based GL-AR150), *not* the WiFi Pineapple Nano since it crashes/panics all the time when initiating a VPN connection. As a matter of fact, I'm writing this post using the LAN Turtle based autostarted OpenVPN connection.

    I'm adding a standard "Do this at your own risk" message to begin with 😬

    The OpenVPN modules are of course available in the Pineapple file system, but I wouldn't go down that road for now since it can be done using the command line. Everything is possible and it can of course be included in a module and being controlled using the web GUI, but I don't really see the need for that (or have the time at the moment to make it happen).

    I'm using a free Tunnelbear account here. Not to endorse Tunnelbear in any way, but it was the first free account I had at hand at the moment. It is also an easy way to reproduce it all for anyone in order to verify that OpenVPN works as it should. Then, if it works, one can start getting any other VPN service provider (such as ExpressVPN) to work.

    Since you have OpenVPN working, I guess you have already completed the steps on the following lines, but I'm including them anyway.
    opkg update
    opkg install openvpn-openssl

    I normally do not use the above command when installing OpenVPN since I want opkg to default to installing openvpn-mbedtls instead of openvpn-openssl. openvpn-mbedtls is optimized for embedded devices with limited resources which OpenSSL really isn't in its original implementation, hence most likely "heavier" for OpenWRT devices to carry.

    Get an ovpn file from your VPN service provider (or Tunnelbear to follow this example). Either it's one file only with certs and keys included, or a client config file along with separate key and certificate files. If the files are not included in one (1) file only, then the other files needs to be referred to in the config file. They probably already are if the VPN provider has chosen to keep them as separate files, but I often want to add absolute paths to those files. This can be added to the config file, i.e. if the config file includes references to other needed files like this:
    ca CACertificate.crt
    cert UserCertificate.crt
    key PrivateKey.key

    ... I use to refer to them with their absolute path in the file system, for example:
    ca /etc/openvpn/CACertificate.crt
    cert /etc/openvpn/UserCertificate.crt
    key /etc/openvpn/PrivateKey.key

    The config file mentioned above can really be stored anywhere in the file system of the Nano. I usually put it in one of the following directories:
    /etc/config
    /etc/openvpn
    /root/[some-sub-dir]

    but... since we are automating this, the config file will be put in a directory so that OpenVPN can find it when running as a service, put it in:
    /etc/openvpn
    and name it:
    openvpn.conf

    It's time to verify that the OpenVPN connection works (you will be prompted for username and password to be entered manually for now).
    openvpn --config /etc/openvpn/openvpn.conf
    or, simply
    openvpn /etc/openvpn/openvpn.conf

    If this works, i.e. that you reach the treasure chest at the end of the rainbow = "Initialization Sequence Completed", then you are successful in connecting via VPN and can try to automate this further.

    VPN username and password can be stored in a file and be referred to in the OpenVPN config file. Doing this will skip the need of manually entering the VPN credentials which is good for automation 🙂 Be aware though, since this obviously will expose your VPN credentials in the Pineapple file system!

    Create a file in /etc/openvpn called openvpn.auth

    Edit the file and put the VPN username on line 1, and the VPN password on line 2, nothing more, nothing less.

    Now, edit the OpenVPN config file and add the path to the auth-file that was just created to the line that says auth-user-pass so that it looks like:
    auth-user-pass /etc/openvpn/openvpn.auth

    Also add auth-nocache to the config file to stop passwords from being cached in memory.

    Now, be very sure that everything works as expected. You may end up in a endless boot-loop that will run until Judgment Day if including a non working VPN setup in an autostart scenario. In that case you will have to go through the recovery procedure of the Pineapple that brings it back to the Stone Age and you will need to upgrade the Nano to 2.7.0 again and also stand with empty hands as all the data and settings that wasn't backed up on the Nano will be lost. For me, that is like the Pepsi Max commercial... "been there, done that" 🙂

    OK, so now there should be a working VPN setup that is also doing the login automatically without putting strain on any human fingertips.

    Enable the OpenVPN service so that it starts at boot up:
    /etc/init.d/openvpn enable
    If in need of not having the VPN tunnel to start at boot for some reason, then use:
    /etc/init.d/openvpn disable

    Start the service
    /etc/init.d/openvpn start
    it can be stopped with
    /etc/init.d/openvpn stop

    Now check with ifconfig that you get a tun interface

    Running ps should also show that OpenVPN is up using the config file created
    /usr/sbin/openvpn --syslog openvpn(openvpn) --status /var/run/openvpn.openvpn.status --cd /etc/openvpn --config /etc/openvpn/openvpn.conf

    Restart the device/Pineapple to make sure that the OpenVPN service autostarts at boot and creates a tun interface (ps and ifconfig)

    The routing should be automatically set up for you, but some VPN services can be a struggle to set up to enable this. Most likely because of how the OpenVPN server on the other side is set up, but also because of the fact that the number of possible local interfaces on the device confuses OpenVPN a bit. I have experienced hair-pulling scenarios with some providers, while other works out of the box with the provided OpenVPN configuration file(s). If not routing correctly through the tunnel interface/VPN service, all traffic will get stuck and not moving forward to the internet.

    Also note that some VPN providers use encryption that OpenWRT (or the Nano specifically) can't handle out of the box. This will be "loud and clear" though when trying to connect to your VPN service using OpenVPN. It will just interrupt the connection process telling you that the server mandatory ciphers (or such) aren't supported, for example cipher aes-256-cbc.

×
×
  • Create New...