Install Tools

[squish]

I feel really stupid for asking this but how do I install the tools? Do I copy the repo to the bunny and run from /media/root/BashBunny/payloads/library/tools_installer or do I run it from a clone copy of the repo or do I run it from the serial console? When I tried to run it from /media it wouldn't let me (I tried to chmod +x but it still wouldn't run). When I tried to run it from the cloned console it wouldn't run (gave me the message find: ‘/root/udisk/payloads/’: No such file or directory). I can't find the directory in the serial console. 

 

Thanks for the help,

Tim

[peterkozmd]

Hopefully there will be a video or some kinda tutorial instructions on release on how to install stuff like installers, updates,etc.You already got one? lucky you

[goto10]

I'm running into similar troubles as you @squish

the '/root/udisk' folder is empty when I serial into it. I can't even seem to find where the mass storage is mounting to. I have tried to do a find for a file I put into the payloads folder. 

 
root@bunny:~# ll /media/
total 8
drwxr-xr-x  2 root root 4096 Feb  9  2017 ./
drwxr-xr-x 22 root root 4096 Dec 31 16:00 ../
root@bunny:~# ll /root/udisk/
total 8
drwxr-xr-x 2 root root 4096 Dec 31 16:10 ./
drwx------ 6 root root 4096 Dec 31  1969 ../
root@bunny:~# 

I'm wondering if it didn't get flashed properly and if there is a was to re-flash it from the console. 

[Foxtrot]

mount -o sync /dev/nandf /root/udisk

[jhaddix]

Tip 1) Here are the setup docs: http://wiki.bashbunny.com/#!index.md

Tip 2) Here are the payloads: https://github.com/hak5/bashbunny-payloads

Tip 3) Here are the forums: https://forums.hak5.org/index.php?/forum/92-bash-bunny/

Tip 4) You need to run tools_installer to get Responder on the Linux partition, then QuickCreds payload will work.

This means if it isn't in your library, you need to download tools_install from Github's payloads library. Then drag the contents of that folder onto a switch folder. Then remove device, change to the corresponding switch, and wait till the transfer of files completes to get to the Linux partition. This will install Responder.

Tip 5) If an operation fails during config, reboot your machine to flush the USB cache. 

Tip 6) Be patient with the time it takes your system to recognize the bunny, sometimes can take up to a minute.

[squish]

I got it to move the files but it didn't complete. I just ran the python setup script from the console and now everything is working. Thanks for the help!

[Darren Kitchen]

It seems that I've simplified it so much that we're over thinking it. The tools_installer payload is just that -- a payload. It's meant to be run just as any other payload -- by copying it to a switch folder from Arming mode, ejecting the BashBunny USB flash disk, putting the switch in that position and plugging it into your PC. It'll then run the install.sh.

I'm going to be updating the documentation tomorrow to outline how the Bash Bunny framework operates, from USB disk mounting to Install.sh, payload.txt, etc. Then I'll be doing some screencasts over the weekend similar to what I did with the LAN Turtle. It's really intuitive once you get the gist -- but if you treat it like a complex Linux box and not a easy drag-and-drop tool, it'll over complicate things. 

[peterkozmd]

Darren will we have to update/ install anything day 1? or will be able to throw payloads on and start using right away

[NightStalker]

I had the same issue with the /root/udev being empty. When I copied payloads over (tools install) and unplugged the bunny the install.sh and readme copied but the directories did not causing the bunny to when trying to execute the payload. After running the command by Foxtrot I can see the data in /root/udisk/ now:

root@bunny:~# mount -o sync /dev/nandf /root/udisk/
root@bunny:~# ll /root/udisk/
total 36
drwxr-xr-x 4 root root 4096 Dec 31 16:00 ./
drwx------ 6 root root 4096 Dec 31 16:03 ../
drwxr-xr-x 2 root root 4096 Mar  4  2017 System Volume Information/
drwxr-xr-x 5 root root 4096 Dec 31  1979 payloads/
-rwxr-xr-x 1 root root 9010 Dec 31  1979 readme.txt*
-rwxr-xr-x 1 root root    8 Dec 31  1979 version.txt*
-rwxr-xr-x 1 root root 3300 Dec 31  1979 win7-win8-cdc-acm.inf*

 

However, when I plug the bunny back in armed to switch2 the directory is blank again and the payload for the tools fails to install:

root@bunny:~# ll /root/udisk/
total 8
drwxr-xr-x 2 root root 4096 Feb  9  2017 ./
drwx------ 6 root root 4096 Dec 31  1969 ../

 

If I go back to arming mode and run the mount command again I see the payload, but not before running the sync again.

 

Cheers, NightStalker

[Foxtrot]

Yes, it seems that /dev/nandf is not mounted upon boot. Solved by running the mount command I mentioned..

[Darren Kitchen]

From the perspective of the Bash Bunny, the USB Disk is mounted before executing the payload, and unmounted when the payload completes. The mount location is /root/udisk. You can use this location in your payloads. If you access the Bash Bunny terminal after a payload completes, this location will be unmounted (unpopulated).

From the perspective of the computer, if a STORAGE attack mode is used in the payload - it will register as mass storage with the label "BashBunny".

It's important to understand that when the computer accesses the nandf partition as a USB disk using the STORAGE attack mode, it is in control of the file system. This is why a synchronization is necessary for payloads which write to /root/udisk. It's also best practice to safely eject -- but that's true with any flash drive.

This behavior is most likely going to change in future versions. Just be advised that's how it works in 1.0

Regarding the question from peterkozmd regarding day-1 usage -- it's ready to go. Just load it up with payloads from the repo and you're off to the races. Each payload has a readme which will spell out if there are any particular requirements. For instance, QuickCreds requires that the tools_installer payload be run first in order to install the dependencies.

In the future we will be simplifying the tools installation method in such a way that the current tools_installer payload will become not necessary. I think you'll find it even more convenient.

Anyways - very early days here and I'm excited for all of the feedback and to make changes to the platform that make it even easier :)

[Caleb]

Hey guys, I am also trying to run install tools and the light goes to "red", other payloads work fine - any ideas? 

 

Thanks,

Caleb

[Darren Kitchen]

2 hours ago, Caleb said:

Hey guys, I am also trying to run install tools and the light goes to "red", other payloads work fine - any ideas? 

 

Thanks,

Caleb

What OS are you using? This is odd -- 3 reports now of this issue and yet I'm unable to reproduce it with a fresh Bash Bunny and a fresh copy of the payloads repo. 

[NightStalker]

3 minutes ago, Darren Kitchen said:

What OS are you using? This is odd -- 3 reports now of this issue and yet I'm unable to reproduce it with a fresh Bash Bunny and a fresh copy of the payloads repo. 

Hello Darren,

On mine I am running Windows 10 Pro 64-Bit.

I did clear all of my payloads and start fresh as well, I get the same failure when it tried to read the files in /root/udisk/payloads/. I would be glad to provide any logs/debugs if you like, just let me know what you need.

Regards,

NightStalker

[Bitstream]

24 minutes ago, Darren Kitchen said:

What OS are you using? This is odd -- 3 reports now of this issue and yet I'm unable to reproduce it with a fresh Bash Bunny and a fresh copy of the payloads repo. 

This happens to me on Ubuntu Mate 16.04.

[super-6-1]

What I found out is if I manually move the tools to /pentest and then run it. It works. When I use a fresh run without moving the files manually it doesn't work. It maybe a way the USB storage sees the files. 

[illwill]

Violation of CoC

[diverg]

Haven't gotten my bunny yet but from what Ive gathered is install.sh another special filename like payload.txt that gets run? When looking through the tools_installer payload.txt there is nothing that actually calls the install.sh file which might be part of the confusion about how the tools installer is supposed to be run. 

[Cpt.Pickles]

would like to increase the count to 4 reports of this happening. Followed the following procedure:

• Copied all files from tools_installer into payloads/switch1 and ejected the bunny
• switched to position 1 and plugged in
• LED remains solid red

After mounting (mount -o sync /dev/nandf /root/udisk/) and attempting to run install.sh alone, bunny reports "./install.sh: line 46: syntax error: unexpected end of file"... and looking at the code I can't find any errors. I copied and pasted each line from github to attempt to identify failure point, no luck, it completed successfully. No syntax errors, no red LED. @Darren Kitchen is it possible the payload is finishing, unmounting and then attempting to run the install script? To diverg's point the install script is never called in the payload.txt, thus the payload should exit after establishing the attackmode, no?

[diverg]

3 hours ago, Cpt.Pickles said:

would like to increase the count to 4 reports of this happening. Followed the following procedure:

• Copied all files from tools_installer into payloads/switch1 and ejected the bunny
• switched to position 1 and plugged in
• LED remains solid red

After mounting (mount -o sync /dev/nandf /root/udisk/) and attempting to run install.sh alone, bunny reports "./install.sh: line 46: syntax error: unexpected end of file"... and looking at the code I can't find any errors. I copied and pasted each line from github to attempt to identify failure point, no luck, it completed successfully. No syntax errors, no red LED. @Darren Kitchen is it possible the payload is finishing, unmounting and then attempting to run the install script? To diverg's point the install script is never called in the payload.txt, thus the payload should exit after establishing the attackmode, no?

Should the payload not be this below? (Not sure where the payload.txt is being run so I hardcoded the full path instead of ./install.sh) Also it says that install.sh is renamed once completed but I don't see that anywhere in the install.sh script. 

#!/bin/bash
# All of the heavy lifting of this payload occurs in install.sh
# which gets renamed to install.sh.INSTALLED once completed.
ATTACKMODE SERIAL STORAGE
/root/udisk/payloads/switchX/install.sh

 

[wrewdison]

I also got a solid red upon trying to run the install_tools payload.  So, I connected via serial and tried to run install.sh manually and also got the "unexpected end of file" error.  When I opened install.sh in vi I noted it had ^M line endings, so I copied the file from github and pasted the text of it into a new install.sh, which ran fine.  It looks like the original was created on Windows and the line endings cause some problems.

I still got the solid red on running it, and discovered that after moving impacket and responder to /pentest there were two things remaining in tools_to_install (._impacket and ._responder) that show up with ls -A (which the script runs to check that the move was successful) I rm'd those,  and did an rm -rf on /pentest and re-ran install.sh, which now completed successfully. 

 

 

 

[Cpt.Pickles]

23 minutes ago, wrewdison said:

I also got a solid red upon trying to run the install_tools payload.  So, I connected via serial and tried to run install.sh manually and also got the "unexpected end of file" error.  When I opened install.sh in vi I noted it had ^M line endings, so I copied the file from github and pasted the text of it into a new install.sh, which ran fine.  It looks like the original was created on Windows and the line endings cause some problems.

Did you happen to also test this automated install with your new install.sh? What I mean is did you test the installation outside of serial and just let the bunny hop to the finish line alone without help ;). Good catch BTW, forgot to check for odd line endings.

[wrewdison]

I didn't - so not sure if they cause problems with the automated install, or if that's caused by the ._impacket and ._responder.    I'll test later this afternoon/evening though. 

[rastating]

I can confirm I also ran into the bug with the tools_installer payload, caused by the line endings. Removed them and tested with a clean slate (i.e. empty /pentest/) and it worked fine via one of the switches.

I've opened up a pull request to merge in the file without line endings here, if anyone wants to grab a copy of the clean file: https://github.com/hak5/bashbunny-payloads/pull/12

[maehko]

@Darren KitchenI too am seeing this.  

During the initial run, the tools_to_install directory content is moved to /pentest but the script immediately fails on line 21 thereafter, setting LED R.  

Since line 4 and 21 are both

if [ "$(ls -A $TOOLSDIR)" ]; then

it seems that the logic is inverted for line 21.

line 4 - quit if the <payload tools directory> is empty

line 17 - empty <payload tools directory>

line 21 - install tools if <payload tools directory> is not empty 

<insert segfault here> - of course it's empty - i just told you to move everything out of it...

Should line 21 be looking at the target folder rather than the destination folder?

Bonus questions for responder newbie, does it need to be installed or do the files just need to be present?