Testing Workload Protection

This section describes how to verify that Workload Protection works as expected to protect the IoT device.

The installation package installs sample attack files in this directory:

/etc/cp/workloadProtection/samples

Testing Command Injection Protection / Remote Code Execution

Shell injection is a type of cyber attack where an attacker sends specially designed input to combine a legitimate command with a malicious command. This happens because the software does not properly check the user input. As a result, the attacker can execute malicious commands on the device, access connected networks, tamper with the device, install crypto miners, or even deploy ransomware.

To simulate a shell injection attack, follow these steps using the Anti-Shell Injection sample:

  1. Create a new server inside the IoT device that has a built-in vulnerability (CVE).

  2. Try to attack the IoT device by exploiting this vulnerability.

  3. Verify whether the Workload Protection blocks the attack.

To test the Anti-Shell Injection plugin:

  1. Create a process of a web server that listens on port 3333:

    LD_PRELOAD=libwlp-core.so ./si_vulnerable_webserver.sample 3333 &

  2. Run the exploit script, which tries to exploit the sample’s vulnerability and kill the internal web server:

    ./antisi.exploit 3333

    If the Workload Protection successfully blocked the attack, you get the following message:

    Shell injection detected at: [ping -c 1 8.8.8.8;telnetd;echo hacked]

    The same message(s) appear in the log file at /var/log/nano_agent/cp-nano-orchestration.log

Testing the File Monitor Plugin

Attackers who gain access to an IoT device often modify executable files and add malicious code to them. This causes the device to execute malicious commands in addition to (or instead of) its normal operation. For example, deploying botnets or crypto miners, accessing resources on the network, and so on. The File Monitor plugin blocks any attempt to change executable files on the IoT device.

In this example, we try to modify the executable file ls and verify whether the File Monitor plugin blocks it.

To test the File Monitor plugin:

  1. Back up the executable file:

    cp /bin/ls ./ls

  2. Run the terminal with the Workload Protection (replace bash with the terminal you prefer):

    LD_PRELOAD=libwlp-core.so bash

  3. Try to modify the file.

    echo “This should not happen” > ./ls

    By default, the File Monitor does not allow overwriting executable files. Therefore, this operation must fail in a protected shell.

    Example:

    echo “This should not happen” > ./ls

    ash: can't create /bin/ls: Invalid argument

    Depending on the shell, this may fail in a different way such as printing to the screen instead of the file.

  4. Verify that ./ls is still a binary ELF executable and not an ASCII text file. To do that, run:

    file ./ls

    cat ./ls

  5. Open the log file:

    /var/log/nano_agent/cp-nano-orchestration.log

    If the Workload Protection worked correctly, the log file displays a message.

Testing the Hooks

Hooks allow you to add custom logic to a process at specific points, allowing you to inspect or change its behavior. For example, you can place a hook on a function such as printf to monitor its inputs. This hook runs your code before the original function, allowing you to analyze or modify the data passed by the function.

To verify whether hooks are applied correctly to the protected processes:

  1. To list the protected processes on the device, run:

    wlptool -p

  2. To list the hooks inside a specific protected process, run:

    wlptool -d <pid>

    The output varies depending on the activated plugins and the process functions.