Jump to content

TCPDUMP payload leads to blinking red when using my external USB


Cautious1

Recommended Posts

Posted

Hi All, 

I was sent a Pcket Squirrel Mark II by mistake from Hak5.  They were kind enough to provide me with updated FW and instructions to flash the device.    The new payloads loaded on the device work, but I am interested only in the tcpdump payload for now added below.  

I have formatted several USB drives to NTFS and EXT4 and still no luck for the script to write to the device and run without any issues.  "/etc/rc.d/S98usb: sh: write error: No such device"

Any ideas or recommendations or is there something wrong with the script?  

 

#!/bin/bash
# 
# Title:		TCPDump
# Description:	Dumps networking-data to USB storage. Completes on button-press or storage full.
# Author: 		Hak5
# Version:		1.0
# Category:		sniffing
# Target: 		Any
# Net Mode:		TRANSPARENT

# LEDs
# SUCCESS:		Dump complete
# FAIL:			No USB storage found

function monitor_space() {
	while true
	do
		[[ $(df | grep /mnt | awk '{print $4}') -lt 10000 ]] && {
			kill $1
			LED G SUCCESS
			sync
			break
		}
		sleep 5
	done
}

function finish() {
	# Kill TCPDump and sync filesystem
	kill $1
	wait $1
	sync

	# Indicate successful shutdown
	LED R SUCCESS
	sleep 1

	# Halt the system
	LED OFF
	halt
}

function run() {
	# Create loot directory
	mkdir -p /mnt/loot/tcpdump &> /dev/null
	
	# Set networking to TRANSPARENT mode and wait five seconds
	NETMODE TRANSPARENT
	sleep 5
	
	# Start tcpdump on the bridge interface
	tcpdump -i br-lan -s 0 -w /mnt/loot/tcpdump/dump_$(date +%Y-%m-%d-%H%M%S).pcap &>/dev/null &
	tpid=$!

	# Wait for button to be pressed (disable button LED)
	NO_LED=true BUTTON
	finish $tpid
}


# This payload will only run if we have USB storage
[[ ! -f /mnt/NO_MOUNT ]] && {
	LED ATTACK
	run &
	monitor_space $! &
} || {
	LED FAIL
}

 

Posted

(Using the same text as I did on Discord)

Mark II? Well, I'm not sure there's something wrong with the script specifically. Have you tried some other payload that writes to the attached USB drive? To troubleshoot it, one starting point would perhaps be to check mounted devices using the 'mount' command and make sure the USB device is mounted correctly (and to what mount point in the file system), also try to "navigate" the USB storage device directory structure to make sure it's possible to access it from the Squirrel side without issues.

Posted

It's plain and simple Linux basics. Just verify the mountpoint first for the USB storage device (should be /mnt/loot) and then create a bash script that copies a file from /root to /mnt/loot and after that verify that the file has been copied.

Posted

I did try this below but it does not write to the USB Drive.   I already did fdisk -l  and confirmed the path on the packet squirrel but no luck with writing.  

NETMODE TRANSPARENT
Sleep 5

mkdir -p /mnt/loot/tcpdump &> /dev/null 
mount /dev/sda1 /mnt/loot/tcpdump

tcpdump -i br-lan -s 0 -w /mnt/loot/tcpdump/dump.pcap &>/dev/null & tpid=$!
Now
 
 
Posted

Actually, you don't need to write a payload to check this. It's just to ssh into the Squirrel and execute

df -h

to check that the USB storage device is mounted (and where)

It should output something like this (apart from storage size, remaining, etc, that most likely differs)

/dev/sda1                 3.6G    325.6M      3.1G   9% /mnt

You could of course also use the mentioned "fdisk -l" (or "mount"), the interesting part is what mountpoint the USB storage device is mounted to

A sample payload to test this would be:

#!/bin/bash

LED ATTACK

rm /mnt/testfile.txt

echo Testfile > /root/testfile.txt

cp /root/testfile.txt /mnt

LED FINISH

Then check if testfile.txt has been copied to /mnt

Posted

Hi,  I did what you asked, and here are the outputs.  

root@squirrel:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 25.0M 25.0M 0 100% /rom
tmpfs 28.1M 124.0K 28.0M 0% /tmp
/dev/mtdblock6 4.6M 304.0K 4.3M 6% /overlay
overlayfs:/overlay 4.6M 304.0K 4.3M 6% /
tmpfs 512.0K 0 512.0K 0% /dev
/dev/sda1 1.9G 11.7M 1.9G 1% /usb

Then I added your script to the payload and see it only creates the file on the Packet squirrel as shared in the images under /mnt/testfile.txt.  It seems there may be a missing Linux driver that needs to accept the USB.   

There is a log in the packet Squirrel that says this

Wi/log.txt - root@172.16.32.1 - Editor - WinSCP
Could not load USB storage. Stopping...

 

Posted

If you compare my line from the df command with your output, you can see that your Squirrel mounts the USB storage device to /usb, not /mnt

Try changing it by editing /etc/hotplug.d/block/20-usb
change the lines
    umount /usb
        mount /dev/$DEVNAME /usb

to
    umount /mnt
        mount /dev/$DEVNAME /mnt

also make sure that /mnt is created and available in the file system

reboot

verify

Posted

The file does not seem to be created.  I have green lights.  Are there any lines I can add to get logs from the device when I run the Payload? 

Posted

Did you try my "test script" as well? Is the testfile.txt being copied to /mnt ?

Regarding the TCPDump payload, you can add echo lines at certain places in the code that writes to a log file to (at least) verify which stages of the payload that the Squirrel is executing (same as using LEDs, but can be a good way of getting the execution "documented"). Something like:

echo "The payload is now at stage XXXYYYZZZ" >> /root/tcp_payload.log

For example:

[[ ! -f /mnt/NO_MOUNT ]] && {
    echo "Starting payload" >> /root/tcp_payload.log
    LED ATTACK
    run &
    monitor_space $! &
} || {
    echo "Payload failed, no USB storage device detected" >> /root/tcp_payload.log
    LED FAIL
}

(and on other places in the functions that are called)

Does the TCPDump payload ever make the Squirrel blink yellow?

Posted

 

So I created this updated payload script and saw the packet squirrel device blinking yellow, but still not getting any "dump.pcap" installed on the device or the USB.  

 

Here is my output to the tcp_payload.log that was created on the device.  

Starting payload
MKDIR Created
TCPDUMP Payload started

NETMODE TRANSPARENT
Sleep 5


function run() {

	# Create loot directory
	mkdir -p /mnt/loot/tcpdump &> /dev/null
    echo "MKDIR Created" >> /root/tcp_payload.log

	
	# Start tcpdump on the bridge interface
	tcpdump -i br-lan -s 0 -w /mnt/loot/tcpdump/dump.pcap &> /dev/null & tpid=$!
    echo "TCPDUMP Payload started" >> /root/tcp_payload.log
    
   

	# Wait for button to be pressed (disable button LED)
	NO_LED=true BUTTON
	finish $tpid
}


# This payload will only run if we have USB storage
#[[ ! -f /mnt/NO_MOUNT ]] && {
[[ ! -f /mnt/NO_MOUNT ]] && {
    echo "Starting payload" >> /root/tcp_payload.log
    LED ATTACK
    run &
    monitor_space $! &
} || {
    echo "Payload failed, no USB storage device detected" >> /root/tcp_payload.log
    LED FAIL
}

Is there anything wrong with the script?  

 

Posted

OK, getting that in the "log" at least tells that it passes through the payload and that is positive since it seems to find the USB storage device and the intended mountpoint.

Try splitting the line:

tcpdump -i br-lan -s 0 -w /mnt/loot/tcpdump/dump.pcap &> /dev/null & tpid=$!

into:

tcpdump -i br-lan -s 0 -w /mnt/loot/tcpdump/dump.pcap &> /dev/null &
tpid=$!

Also:

Sleep 5

won't work, it needs to be

sleep 5

but that's no real issue if it works or not

The line

finish $tpid

won't do anything since the finish function is removed from your payload, and that goes for the following line as well

monitor_space $! &

 

Posted

Hey,  Yes that worked and now I am able to capture traffic on the packet squirrel.   What command do I use to see where the traffic originated from?  I mean that I have the PS (packet squirrel) connected between my router and the telecommunication router but do not see the MAC address or any way to know where the request is coming from to get the response.  I only see the MAC of the routers.  

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...