new bash bunny networking wierdness

[raf]

Hi,

I just got a bash bunny yesterday. I'm using macos, and initially I
could connect via serial in arming mode (switch 3) and I
could connect via ethernet (switch 1).

I did an apt-get update/upgrade, ran into the problem
with systemctl not knowing about procps, fixed that
thanks to this forum, but after that, ethernet no
longer worked (with the default switch 1 payload.txt:
ATTACKMODE ECM_ETHERNET STORAGE).

I've just looked at the doco again and noticed that it
says (for macos) to use RNDIS_ETHERNET (not
ECM_ETHERNET) which would mean that the default switch
2 payload.txt was the right one: ATTACKMODE
RNDIS_ETHERNET STORAGE

So that's confusing me. It looks like I did the wrong
thing but it worked anyway (or maybe the doco is
wrong?).

Anyway, when I try switch 1, macos now reports that the
RNDIS gadget has a self-assigned IP and when I try
switch 2, it says that the RNDIS device is not
connected. So that makes me think that ECM_ETHERNET is
better on macos than RNDIS_ETHERNET.

The self-assigned IP is because dhcp isn't working and
I think the dhcp server isn't working because of a
problem with usb0 but I can't seem to find the error
message that mentioned usb0 anymore. Anyway, here's
what I can find from arming mode (where I can still
connect via serial):

  # systemctl --failed
    UNIT                    LOAD   ACTIVE SUB    DESCRIPTION
   isc-dhcp-server.service loaded failed failed LSB: DHCP server
 
  LOAD   = Reflects whether the unit definition was properly loaded.
  ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
  SUB    = The low-level unit activation state, values depend on unit type.
 
  1 loaded units listed. Pass --all to see loaded but inactive units, too.
  To show all installed unit files use 'systemctl list-unit-files'.
 
  # systemctl status isc-dhcp-server
  ● isc-dhcp-server.service - LSB: DHCP server
     Loaded: loaded (/etc/init.d/isc-dhcp-server)
     Active: failed (Result: exit-code) since Thu 1970-01-01 00:00:13 UTC; 1min 31s ago
    Process: 244 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
 
  Jan 01 00:00:11 bunny dhcpd[266]:
  Jan 01 00:00:11 bunny dhcpd[266]: No subnet declaration for usb0 (no IPv4 a...).
  Jan 01 00:00:11 bunny dhcpd[266]: ** Ignoring requests on usb0.  If this is...at
  Jan 01 00:00:11 bunny dhcpd[266]: you want, please write a subnet declaration
  Jan 01 00:00:11 bunny dhcpd[266]: in your dhcpd.conf file for the network s...nt
  Jan 01 00:00:13 bunny isc-dhcp-server[244]: Starting ISC DHCP server: dhcpdc...!
  Jan 01 00:00:13 bunny isc-dhcp-server[244]: failed!
  Jan 01 00:00:13 bunny systemd[1]: isc-dhcp-server.service: control process ...=1
  Jan 01 00:00:13 bunny systemd[1]: Failed to start LSB: DHCP server.
  Jan 01 00:00:13 bunny systemd[1]: Unit isc-dhcp-server.service entered fail...e.
 
  # dmesg
  [    9.031393] usb open backing file: /dev/nandf, 0xd3c55e00
  [    9.031572] g_ether gadget: Mass Storage Function, version: 2009/09/11
  [    9.031586] g_ether gadget: Number of LUNs=1
  [    9.031603]  lun0: LUN: removable file: /dev/nandf
  [    9.031636] gadget_is_softwinner_otg is not -int
  [    9.031645] gadget_is_softwinner_otg is not -int
  [    9.031668] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
  [    9.031693] g_ether gadget: g_ether ready
  [    9.262859] g_ether gadget: high-speed config #2: CDC Ethernet (ECM)
 
  # ifconfig -a
  eth0      Link encap:Ethernet  HWaddr 7a:9c:df:7a:46:2a  
            BROADCAST MULTICAST  MTU:1500  Metric:1
            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:1000
            RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
            Interrupt:114
 
  gre0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
            NOARP  MTU:1476  Metric:1
            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:0
            RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
  ip6tnl0   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
            NOARP  MTU:1452  Metric:1
            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:0
            RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
  lo        Link encap:Local Loopback  
            inet addr:127.0.0.1  Mask:255.0.0.0
            inet6 addr: ::1/128 Scope:Host
            UP LOOPBACK RUNNING  MTU:16436  Metric:1
            RX packets:8 errors:0 dropped:0 overruns:0 frame:0
            TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:0
            RX bytes:520 (520.0 B)  TX bytes:520 (520.0 B)
 
  sit0      Link encap:IPv6-in-IPv4  
            NOARP  MTU:1480  Metric:1
            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:0
            RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
  tunl0     Link encap:IPIP Tunnel  HWaddr   
            NOARP  MTU:1480  Metric:1
            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:0
            RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

I changed the switch 1 payload.txt to "ATTACKMODE
ECM_ETHERNET SERIAL" so I could access it via the
serial port while it was trying to get ethernet
working. This is what I see now:

  # dmesg
  [    8.533890] usb0: MAC 5a:00:00:5a:5a:00
  [    8.533907] usb0: HOST MAC 00:11:22:33:44:55
  [    8.534006] gadget_is_softwinner_otg is not -int
  [    8.534016] gadget_is_softwinner_otg is not -int
  [    8.534043] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
  [    8.534069] g_ether gadget: g_ether ready
  [    8.761748] g_ether gadget: high-speed config #2: CDC Ethernet (ECM)
  [    8.862089] ADDRCONF(NETDEV_UP): usb0: link is not ready
  [    9.118930] ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
  [   19.470040] usb0: no IPv6 routers present

  # ifconfig
  [...]
  usb0      Link encap:Ethernet  HWaddr 5a:00:00:5a:5a:00  
            inet addr:172.16.64.1  Bcast:172.16.64.255  Mask:255.255.255.0
            inet6 addr: fe80::5800:ff:fe5a:5a00/64 Scope:Link
            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
            RX packets:113 errors:0 dropped:0 overruns:0 frame:0
            TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:1000
            RX bytes:37528 (36.6 KiB)  TX bytes:720 (720.0 B)

So it now has a usb0 network interface, with the right address,
but from macos it still sees a self-assigned address.

Ah, but I can do systemctl start isc-dhcp-server and it succeeds,
and from macos, it says the RNDIS gadget is "Connected" and has
the right address, but it still doesn't work. apt-get update says:

  Err http://httpredir.debian.org jessie/main armhf Packages
    504  Gateway Time-out
  W: Failed to fetch http://httpredir.debian.org/debian/dists/jessie/main/binary-armhf/Packages 504  Gateway Time-out

Any idea what I've done wrong or what I can do to
get ethernet working again?

I tried rebooting and isc-dhcp-server failed again, starting
it manually worked and everything looks ok but network connectivity
still isn't working.

This is wierd. From the macos host, I can ssh root@172.16.64.1
and it works, but only after I've done a manual:

  systemctl start isc-dhcp-server

from my serial port login.

But from the bunny, I can't do:

  apt-get update

So the networking is only working in one direction.

Any idea what's going on? This is wierd.

Thanks for any advice.

cheers,
raf

 

Update: I have a lame solution for dhcp not starting up

for me when ATTACKMODE has ECM_ETHERNET. It seems

like maybe there's a bug in /root/ATTACKMODE but I can't

see what it is. I don't know why isc-dhcp-server isn't running

by the time that ATTACKMODE completes, but adding this to

payload.txt after ATTACKMODE seems to fix it:

 

  systemctl status isc-dhcp-server || systemctl start isc-dhcp-server

 

I still have the problem that apt-get update doesn't work anymore but

it's got nothing to do with the bunny's networking. It is making a request

to the squid proxy on the host server and squid is replying with:

 

    HTTP/1.0 504 Gateway time-out

 

So it's a problem elsewhere (i.e. not bunny-related).

 

cheers,

raf

 

[raf]

Update: The apt-get update problem was squid getting a refusal/error from a dns server

but quitting and restarting squid got it working again.

 

Rather than using squid and $http_proxy, as recommended by:

    https://docs.hak5.org/hc/en-us/articles/360010554233-Sharing-an-Internet-connection-from-OSX

It would be better if we could use macos internet sharing to get more than just http proxying.

Unfortunately, when I tried that, the macos host never got past the self-assigned ip address.

It never got the right 172.16.64.10 address. There's probably a good reason for that but I don't what

it is.

Has anyone  got normal macos internet sharing working with a bash bunny?

[raf]

Update: I found out why the host mac doesn't get an IP address when internet sharing is turned on.

I've been told that, when the mac is doing internet sharing, instead of it acting as a dhcp client getting an

address from the bash bunny, it acts as a dhcp server instead and expects the bash bunny to act as

a dhcp client.

 

So, to get full internet access working on the bash bunny, rather than just http proxying, either the mac

needs to be told not to act as a dhcp server when doing internet sharing, or the bash bunny needs to

act as a dhcp client rather than a dhcp server. I'm sure that's doable by stopping the dhcp server after

ATTACKMODE ECM_ETHERNET (if it started up properly which it doesn't for me) and then using

isc-dhcp-client (i.e. dhclient). I suspect it'll be much easier to change the bash bunny's behaviour

than the mac's behaviour.

[meshx86]

is this still an issue with 1.5 FW? i've done latest apt-get upgrade and looks like it breaks it.

sometimes it works, sometimes i have to manually restart dhcpserver

also udisk doesn't get mounted automaticlly on either switch 1 or switch 2

where do i have to look to troubleshoot more?

[zup]

After I did the same thing as you (apt update and upgrade) and fixed the procps-thing, Dhcp did not work for my bash bunny. It looks like the service isc-dhcp-server fails on startup, and I have to manually set the ip for the ndis card. Then I can log in using ssh and just restart the iscp-dhcp-server service and it works fine. I think the issue is that the usb0 interface is not ready yet when the dhcp service tries to start and therefore it fail. I have yet found out how to fix this problem

[raf]

Hi meshx86. It is still a problem with v1.5. I see the same as you. Sometimes the DHCP server starts and sometimes it doesn't.
However, since I'm plugging the bash bunny into my mac, having the DHCP server running on the bash bunny isn't actually helpful.
It should be a DHCP client to share the mac's network. I wrote the DHCLIENT extension to make this happen. The first thing it does
is to stop isc-dhcp-server if it is running. But it might be a problem when plugging the bash bunny into a windows host. I'm not sure.

Hi Zup. I think a (lame) solution to the problem is to add this to /etc/rc.local:

systemctl status isc-dhcp-server || systemctl start isc-dhcp-server

That should start the DHCP server at the end of the boot process if it failed to start earlier.

But make sure that /etc/rc.local looks ok. I found a typo in there in the first line that would stop it running at all
(i.e. something like "-e #!/bin/sh -e" instead of "#!/bin/bash -e").

[Bob123]

Forgive my ignorance and at the same time please educate me but my bash bunny is at firmware 1.3.  If I wanted to go to firmware 1.5 can't I just load up the latest firmware into the BB?  Do I have to do an apt-get update/upgrade?  I'm curious cause looking at the most recent posts in the BB section of the forums, it seems that the update/upgrade is what's killing them.  Is that correct to say?  I'm currently trying to help someone else with quick creds and in determining if it's the BB or the win10 box, all things being equal, if I update the firmware from 1.3 to 1.5 then back to 1.3 my results should be the same with any script right?  I started at 1.3 and the script worked, I upped the firmware to 1.5 then downgraded the firmware back to 1.3.  Doing an apt-get update/upgrade is actually changing the underlying software that runs below the firmware correct?  Again I'm just trying to wrap my head around this issue.  Sorry for crashing this thread but you all seem to be the most active on working on this.  Thanks.

[raf]

Hi Bob123, I'm not entirely sure but I think you are right. I think that the Bash Bunny Updater updates the Hak5-related software but not the underlying debian software. If that's the case, then everything might work fine as long as you don't do apt-get update/upgrade since Hak5's testing would be done with debian in its non-upgraded stated. In fact, I think that if you have done apt-get upgrade followed by using the Bash Bunny Updater, it puts the old debian back and another apt-get upgrade will upgrade it all again. At least, that's what I remember happening. It's a pity, though. I want to update all the software and even upgrade to debian9 but perhaps that's not a good idea.

So, in answer to your question, you don't have to do apt-get update/upgrade. If you have already done it, I think using the Bash Bunny Updater will undo it. You can test that by doing apt-get update and apt-get upgrade but just to see what will be upgraded without actually upgrdaing it.

Good luck.

[zup]

Well, I tried upgrading to Debian9 as the first thing I did when I got it. It broke and nothing worked at all basically. So I reverted it using a firmware downgrade before upgrading to 1.5 again.

[zup]

On 4/8/2019 at 2:15 AM, raf said:

Hi meshx86. It is still a problem with v1.5. I see the same as you. Sometimes the DHCP server starts and sometimes it doesn't.
However, since I'm plugging the bash bunny into my mac, having the DHCP server running on the bash bunny isn't actually helpful.
It should be a DHCP client to share the mac's network. I wrote the DHCLIENT extension to make this happen. The first thing it does
is to stop isc-dhcp-server if it is running. But it might be a problem when plugging the bash bunny into a windows host. I'm not sure.

Hi Zup. I think a (lame) solution to the problem is to add this to /etc/rc.local:

systemctl status isc-dhcp-server || systemctl start isc-dhcp-server

That should start the DHCP server at the end of the boot process if it failed to start earlier.

But make sure that /etc/rc.local looks ok. I found a typo in there in the first line that would stop it running at all
(i.e. something like "-e #!/bin/sh -e" instead of "#!/bin/bash -e").

Hey! It did not work to add this to rc.local. it still get the same error. Maby rc.local runs this before the network device is ready?

[zup]

59 minutes ago, zup said:

Hey! It did not work to add this to rc.local. it still get the same error. Maby rc.local runs this before the network device is ready?

I fixed it. I just disabled the isc-dhcp-server service. The bunny framework starts this when it enables the network adapter. Somehow it had been enabled 

[raf]

That makes sense. Thanks.