Nmap won't run twice

[cyrus104]

@Darren Kitchen / Hak5,

Great product, I'm running into an issue that I thought your code mitigates but isn't working properly. First time I run the SJ it works as expected, when I disconnect and run it again (same network or different vlan) it fails. I say fails but it gets to the pulling dhcp (cyan / magenta) and after that it switches to a quick cleanup and then finish. If I do a cleanup and remove the loot files, the second run will work as expected but I need to do a clean up.

I am using the example Nmap-C2 from the hak5 github.

It looks like you handled this with the SCAN_FILE (/etc/shark/nmap/scan-count), oddly on the SJ I never see this file increment. I see the lines below:

• In setup()

# Create tmp scan file if it doesn't exist

SCAN_FILE=$SCAN_DIR/scan-count

if [ ! -f $SCAN_FILE ]; then

touch $SCAN_FILE && echo 0 > $SCAN_FILE

fi

• In run()

SCAN_N=$(cat $SCAN_FILE)

SCAN_M=$(( $SCAN_N + 1 ))

• In finish()

echo $SCAN_M > $SCAN_FILE

Any thoughts on why the SCAN_FILE next increments would be great. I've cat'd it out after each run and it's always blank or zero.

Thanks a bunch

[emptyhen]

Hello,

I tried this on mine and was surprised to find I had the same issue.

Having had a poke around I noticed the SCAN_FILE (/etc/shark/nmap/scan_count) was empty. I tried setting a value in it but that still didn't work. I ended up adding a line in the finish() routine, just before the 'echo $SCAN_M > $SCAN_FILE' that simply removes the file before saving the new value ('rm $SCAN_FILE'). This seems to have done the trick, but I'm not really sure why it didn't work before...

Hope that helps

Mark

[cyrus104]

Glad to see it's not just me on this one. I also tested all the commands manually and they work (with an update the create file command). I went so far as stripping every single line out of the file besides the ones dealing with the counter and ran it on a linux vm install and it increments the counter every time I run it.

I will try and add the same thing you did. I figured that because it was running as root there wouldn't be an issue with the writing of the file.

[cyrus104]

I created a PR for the github repo of this payload.

[emptyhen]

The really strange thing is it seems to work fine if I run the script in Arming mode. (I comment out the NETMODE DHCP_CLIENT and the 'halt' lines so that it will run) This seems to work fine and the count increments as it should etc. (remember you need to wait a little before checking as the script runs itself in the background - 'run &' on the last line.

I haven't dug into exactly how the Shark Jack runs the payload yet but it must be an issue linked to that. As I mentioned before, even the line that creates the file the first time doesn't work properly either ('touch $SCAN_FILE && echo 0 > $SCAN_FILE') - it creates the empty file but never populates it with the '0'.

For reference, I run the payload with 'ash /root/payload/payload.sh'

[cyrus104]

Interesting, I didn't run it outside of attack mode. With the few changes that were made rm'ing the file before writing it and updating the file creating to "echo 0 > $SCAN_FILE" it's working for me if I keep $SCAN_FILE or if I delete every time. I'm not sure why the touch is even needed, echo 0 > will create a file if it doesn't exist.

I will unmark it as solved. There are some underlying issues that might benefit from being looked at by a dev.

[emptyhen]

I think the touch is needed as it creates the file path too. ie. the /etc/shark/nmap/ (/etc/shark doesn't exist before the payload is run for the first time)

It does appear to be down to the way the SharkJack executes the payload. It essentially runs 'bash -C /root/payload/payload.sh'. If I try that from the command line on the Shark, I get: 'payload/payload.sh: line 31: /etc/shark/nmap/scan-count: cannot overwrite existing file'

Running it without the '-C' works fine, as described before. Interesting....

Either way, adding 'rm $SCAN_FILE' seems to fix the issue - even if it is really just a work around rather than a solution...

[cyrus104]

@emptyhen,

I removed my PR as @Darren Kitchen submitted a complete rewrite of the default payload. While this new payload doesn't trigger the issue that we are seeing, most of the other sample payloads in the github do fall victim to this issue.

I wanted to capture the fix you came up with here, please correct me if I don't get it right.

In /usr/bin/shark_framework you modified line 120.

from: echo "bash -C '$payload'" | at now

to: echo "bash -c '$payload'" | at now

You mention you chmod +x payload.sh, what about doing a chmod +x payload*  at line 110?

 

@Darren Kitchen / @Korben, The updated sample payload is vastly different than all of the other examples that utilize functions and are laid out in a easy to read / modify way. If possible can the change above to shark_framework be made? This would allow the sample payload to be reverted back to the original one which is inline with the other payloads in the git repository.

Thanks

[cyrus104]

Odd my searches didn't turn this up but @Flatlinebb had this problem and did all the troubleshooting months ago.

 

[emptyhen]

@cyrus104, just wanted to check you saw Foxtrot's reply about this on Discord? The changes you suggest are exactly what I'd done and it looks like it's been applied by Foxtrot for the next version of firmware to be released.

Hope that helps. 

 

[cyrus104]

@emptyhen, I did see that they are planning to make the change which is great.

I am struggling right now with the fact that I can run the same scan several times and get different results. Specifically on the default payload which is a ping and I can run a basic ping test using nmap on my machine and get like 12 machines up and the SJ only gets 2-5 at different times... and it's never gotten my NAS.

I'm  a little worried because I'm not sure I can trust the results of using it. 2-5 our of a reliable 12 is bad!

I've tested flashing the older 1.0.0, 1.0.1, and current 1.1.0 all with the same random results.

[emptyhen]

I do get differing results on subsequent runs but I get that on Kali and on a tool on my Android phone but only differing by 3-5. I guess some devices don't respond to all pings or the frames are being dropped by the router? (Some are wireless and some are wired devices). I've found adding the "--host-timeout 30s --max-retries 3" does help a bit. I tried playing with the speed a bit but that generally makes things worse!

You could try a more detailed scan if you want a more accurate list (although this is of course a bit more 'noisy'). Something like "-p 80,21,443,445,139 --host-timeout 30s --max-retries 3"? This may also give you a little more detail at the same time!

Hope that helps.

[cyrus104]

With my nmap runs on a Kali vm, I get some variants too, sometimes none other times 1-3. Because everything is on a local lan, it's never been bad enough to not register 75% of devices using the basic scan. I have made the changes to includ ehte host timeout and max retries but that hasn't really helped out.

For the usage that I have, I'd be happy with turning on -sV and -A but this thing doesn't have the battery life to do that.

 

[emptyhen]

Out of interest, is you Kali VM connected to the network in the same way as the SharkJack? Might be an interesting experiment to connect your Kali box/computer to the same physical port that you are testing the SharkJack and compare the results?

Another thing that occurs to me is that the SharkJack is potentially having to do more on its first scan that the Kali box. The reason for this is that the Kali box will already know the MAC addresses for most or all the devices on the network (since it's probably been running for a while and all be constantly maintaining it's ARP table - and may keep some between re-boots). The SharkJack is having to do all that as well as ping each address as it is always starting from a fresh config - even it's own MAC address is randomised on each boot. If a device doesn't respond to the ARP request in a timely fashion, I don't think the ping will even get sent.

Out of interest, if you ran the NMAP scan twice, do you get more results the second time? (Could try this from arming mode as a quick experiment?)

2 hours ago, cyrus104 said:

For the usage that I have, I'd be happy with turning on -sV and -A but this thing doesn't have the battery life to do that.

Yeah, that's going to take a long time - especially if you have a few devices on the network. That's why I suggested a reduced list of just 5 ports. (HTTP, FTP, HTTPS, & 2xSMB related ports.) You could also add 22 for SSH? My Jack seems to cope with this on a network of ~30 devices a few times before it runs out of juice.

[cyrus104]

@emptyhen,

Super interesting results. The SJ is connected to the same switch the VM is bridged to. I swapped over the port and that didn't do anything different.

I put the SJ in arming mode, change the IP with ifconfig, ressh'd into the SJ and ran the nmap command manually and.... on the first try it got all 13 hosts on the network. I tested it about 3 more times and it got all of them. I reboot the unit and put it into attack and it's back to 4-5 hosts.

Yeah, the ports you have listed is about all that can be expected with the battery constraints.