5.1 Router & Switch Management: SNMP, SSH & Authentication

5.1 Router & Switch Management: SNMP, SSH & Authentication

In enterprise network environments, the management plane governs administrative access, telemetry collection, device provisioning, and operational monitoring. A vulnerability or misconfiguration in management protocols grants an adversary full control over the underlying control and data planes, bypassing perimeter firewalls and segmentations. For the CREST Practitioner Security Analyst (CPSA) examination, candidates must understand how network devices are managed, how administrative protocols operate at the packet level, and how legacy protocols expose network equipment to reconnaissance and unauthorized reconfiguration.

---

1. Simple Network Management Protocol (SNMP)

Simple Network Management Protocol (SNMP) is an Application Layer protocol that provides a standardized framework for monitoring and managing network-connected devices, including routers, switches, firewalls, load balancers, and servers.

+-------------------------------------------------------------------------+
|                        SNMP ARCHITECTURE OVERVIEW                       |
+-------------------------------------------------------------------------+
|                                                                         |
|   +-----------------------+              +--------------------------+   |
|   |    SNMP Manager       |              |    SNMP Managed Device   |   |
|   |  (NMS / Monitoring)   |              |   (Router / Switch / OS) |   |
|   +-----------------------+              +--------------------------+   |
|         |            ^                         |             ^          |
|         | UDP 161    |                         | UDP 161     |          |
|         | Polling    | UDP 162                 | Polling     | UDP 162  |
|         v            | Traps                   v             | Traps    |
|   +-----------------------+              +--------------------------+   |
|   |  Get / GetNext / Set  | ------------>|   SNMP Agent Software    |   |
|   |  GetBulk Requests     |              |   Reads / Writes to MIB  |   |
|   +-----------------------+              +--------------------------+   |
+-------------------------------------------------------------------------+

SNMP Architecture & Transport Mechanics

SNMP operates in a client-server relationship across two specific UDP ports:

• UDP Port 161 (SNMP Agent): The SNMP Manager (Network Management Station or NMS) issues polling queries (GetRequest, GetNextRequest, GetBulkRequest, SetRequest) to the SNMP Agent listening on UDP 161 of the managed device.
• UDP Port 162 (SNMP Trap/Notification Receiver): The managed device's SNMP Agent emits unsolicited asynchronous event alerts (Trap or InformRequest) to the SNMP Manager listening on UDP 162.

The Management Information Base (MIB) and Object Identifiers (OIDs)

SNMP exposes operational variables organized within a hierarchical, tree-structured database called the Management Information Base (MIB). Each accessible parameter or metric within the MIB is uniquely designated by an Object Identifier (OID)—a dot-delimited sequence of integers representing the path from the root of the tree down to the specific leaf node:

$\text{Root} \rightarrow \text{iso(1)} \rightarrow \text{org(3)} \rightarrow \text{dod(6)} \rightarrow \text{internet(1)} \rightarrow \text{mgmt(2)} \rightarrow \text{mib-2(1)} \rightarrow 1.3.6.1.2.1$

Protocol Versions: SNMPv1, SNMPv2c, and SNMPv3

+---------------------------------------------------------------------------------------------------+
|                                    SNMP PROTOCOL EVOLUTION                                        |
+---------------------------------------------------------------------------------------------------+
| Feature / Dimension     | SNMPv1 (RFC 1157)      | SNMPv2c (RFC 1901)     | SNMPv3 (RFC 3411-3418)|
+-------------------------+------------------------+------------------------+-----------------------+
| Authentication          | Cleartext Community    | Cleartext Community    | USM: MD5 or SHA HMAC  |
| Encryption / Privacy    | None (Plaintext)       | None (Plaintext)       | USM: DES, 3DES, AES   |
| Access Control          | Primitive Community    | Primitive Community    | VACM (View-Based)     |
| Counter Width           | 32-bit only            | 64-bit counter support | 64-bit counter support|
| Bulk Data Retrieval     | Iterative GetNext only | High-speed GetBulk     | High-speed GetBulk    |
| Trap Reliability        | Unacknowledged Trap    | InformRequest (ACKed)  | InformRequest (ACKed) |
+---------------------------------------------------------------------------------------------------+

SNMPv1 and SNMPv2c Security Weaknesses

Both SNMPv1 and SNMPv2c rely on community strings, which act as cleartext, unencrypted shared passwords transmitted directly within each UDP datagram:

• public (Read-Only / RO): Permits querying device status, interface statistics, and system parameters.
• private (Read-Write / RW): Permits modifying device configurations, altering routing entries, and rebooting network devices.

Because community strings traverse the network in cleartext, an eavesdropper with an active packet capture tool (e.g., Wireshark or tcpdump) can extract valid strings instantly. Furthermore, default community strings (public, private, cisco, manager, monitor) are routinely left unchanged by administrators. Attackers exploit this using high-speed brute-force tools such as onesixtyone to test thousands of community string dictionaries per second against target ranges:

# Rapid community string scanning using onesixtyone
onesixtyone -c /usr/share/wordlists/metasploit/snmp_default_pass.txt 192.168.1.1

# Performing recursive subtree walk using snmpwalk
snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.1

If an attacker discovers a Read-Write (RW) community string on a Cisco IOS device, they can trigger remote configuration extraction or modification by leveraging the cisco-copy-entry OID (1.3.6.1.4.1.9.9.96.1.1.1.1), instructing the target router to upload its entire active running-config to an attacker-controlled TFTP server.

SNMPv3 Security Architecture: USM and VACM

SNMPv3 addresses the vulnerabilities of legacy versions by introducing two cryptographic models:

1. User-Based Security Model (USM): Defines user credentials, message authentication algorithms, and payload encryption mechanisms.
2. View-Based Access Control Model (VACM): Restricts which MIB trees, subtrees, and individual OID objects a specific authenticated user or group is authorized to view or configure.

SNMPv3 USM establishes three distinct Security Levels:

• noAuthNoPriv: No authentication and no privacy. Uses a simple username without cryptographic validation; packets traverse the wire in cleartext. Rare in production.
• authNoPriv: Provides message authentication and integrity verification without privacy. Utilizes HMAC-MD5 or HMAC-SHA to hash the message payload with a shared user secret, defeating packet tampering and unauthorized origin spoofing; however, the payload remains unencrypted.
• authPriv: Enforces both authentication and privacy. In addition to HMAC-SHA (or MD5) integrity checking, the entire SNMP PDU payload is encrypted using symmetric block ciphers—historically 56-bit CBC-DES, and modernly AES-128, AES-192, or AES-256 (CFB mode).

---

2. Cisco IOS Configuration Analysis & Password Security

Cisco Internetwork Operating System (IOS) switches and routers store configuration directives in two primary files:

• startup-config: Persisted in Non-Volatile RAM (NVRAM); loaded into active system memory during boot.
• running-config: Stored in volatile dynamic RAM (DRAM); reflects the immediate, real-time operational state of the device.

When conducting a configuration review during a CREST assessment, a penetration tester or security auditor must scrutinize these files for structural vulnerabilities and password hashing weaknesses.

+---------------------------------------------------------------------------------------------------+
|                               CISCO IOS PASSWORD ENCRYPTION TYPES                                 |
+---------------------------------------------------------------------------------------------------+
| Type   | Algorithm / Cipher            | Hashcat Mode | Practical Security Status                 |
+--------+-------------------------------+--------------+-------------------------------------------+
| Type 0 | Plaintext (Unencrypted)       | N/A          | Critical risk; fully human-readable       |
| Type 7 | Vigenère-style XOR Table      | N/A          | Trivial; decoded instantly (cisco-decrypt)|
| Type 5 | Salted MD5 (cisco-ios-md5)    | 500          | Deprecated; vulnerable to GPU cracking    |
| Type 8 | PBKDF2 with HMAC-SHA256       | 9200         | Robust; standard modern protection        |
| Type 9 | scrypt (Memory-Hard)          | 9300         | High security; resistant to ASIC/GPU      |
+---------------------------------------------------------------------------------------------------+

Password Hashing and Encryption Mechanics

1. Type 0 (Plaintext)

Passwords entered directly without encryption directives (e.g., password Cisco123 or enable password Cisco123) appear as unencoded plaintext within the configuration file, visible to anyone with read privileges.

2. Type 7 (Proprietary Obfuscation)

Enabled when the global configuration command service password-encryption is executed. Type 7 was designed to protect passwords from casual "shoulder-surfing" over an administrator's monitor. It is not a cryptographic hash; it is a symmetric, reversible Vigenère-style polyalphabetic substitution cipher utilizing a fixed, hardcoded 16-byte key table (dsfd;kfo30rvbvfl) embedded directly within the Cisco IOS binary image.

• The first two characters of a Type 7 string represent the numeric index (from 00 to 15) of the starting position within Cisco's hardcoded key array.
• Type 7 passwords can be reversed in microseconds using tools like cisco-decrypt or one-line scripts:

# Reversing a Type 7 password using cisco-decrypt
cisco-decrypt 0822455B0A10091E1D
# Result: "CiscoAdmin123"

3. Type 5 (Salted MD5 Crypt)

Generated using the command enable secret <password> or username <user> secret <password>. Type 5 hashes are formatted as $1$<salt>$<hash>, utilizing a variant of the standard Unix crypt() MD5 function with a 4-character salt and 1,000 hashing iterations. While significantly stronger than Type 7, modern GPU cracking clusters can evaluate hundreds of millions of Type 5 hashes per second using Hashcat (hashcat -m 500 hashes.txt wordlist.txt).

4. Type 8 (PBKDF2 with HMAC-SHA256)

Configured using enable algorithm-type sha256. Type 8 implements the Password-Based Key Derivation Function 2 (PBKDF2) standard, pairing HMAC-SHA256 with an 80-bit salt and 20,000 hashing iterations. Hash strings appear formatted as $8$<salt>$<hash>.

5. Type 9 (scrypt)

Configured using enable algorithm-type scrypt. Type 9 applies the memory-hard scrypt key derivation function, deliberately forcing high memory consumption during hash calculation to render parallel ASIC and FPGA hardware brute-forcing computationally cost-prohibitive. Hash strings appear formatted as $9$<salt>$<hash>.

Critical Audit Checks in Cisco Configurations

During security reviews, penetration testers evaluate device configuration blocks for common hardening deficiencies:

1. Insecure Administrative Interfaces:
   • Unencrypted Web Servers: Directives ip http server (listening on TCP port 80) transmit administrative sessions, authentication headers, and credentials in cleartext. Configurations must mandate no ip http server and restrict secure access via ip http secure-server (HTTPS/TLS) bound to management ACLs.
   • Exposed Telnet Lines: Inspect the Virtual Terminal (line vty 0 4) configuration. If transport input telnet or transport input all is present, administration credentials traverse the network in cleartext. Hardened configurations mandate transport input ssh and require login local.
2. Console and Auxiliary Port Hardening:
   • Unprotected auxiliary ports (line aux 0) must be disabled via no exec and transport output none to prevent backdoor modem access.
   • Console ports (line con 0) must enforce an administrative idle timeout via exec-timeout 5 0 (5 minutes, 0 seconds) to prevent unauthorized local terminal hijacking.
3. Logging and Telemetry Verification:
   • Logging buffers must be sized appropriately (logging buffered 64000 warnings).
   • Syslog output (logging host <IP>) must forward event logs to an isolated SIEM or syslog collector.
   • Audit timestamps must record sub-second telemetry using service timestamps log datetime msec.

---

3. AAA Framework: TACACS+ vs RADIUS

The AAA (Authentication, Authorization, and Accounting) framework governs centralized identity and policy enforcement across enterprise network devices:

• Authentication: Validates the identity of the user attempting access (e.g., verifying a username against a central database via password, token, or digital certificate).
• Authorization: Dictates the specific commands, privilege tiers (0-15 on Cisco), and resources an authenticated user is permitted to execute.
• Accounting: Generates an auditable record detailing when the user logged in, which commands they entered, files transferred, and session termination times.

+---------------------------------------------------------------------------------------------------+
|                                 AAA PROTOCOL COMPARISON ARCHITECTURE                              |
+---------------------------------------------------------------------------------------------------+
| Feature / Dimension     | TACACS+ (RFC 8907 / Cisco)          | RADIUS (RFC 2865 / 2866 - IETF)   |
+-------------------------+-------------------------------------+-----------------------------------+
| Transport Layer         | TCP Port 49 (Connection-Oriented)   | UDP Ports 1812 (Auth) / 1813 (Acct|
|                         |                                     | Legacy: UDP 1645 (Auth) / 1646(Acct
| AAA Architectural Model | Completely Decoupled / Independent  | Combines Auth & Authorization     |
| Packet Encryption Scope | Encrypts ENTIRE packet payload      | Encrypts ONLY the Password field  |
|                         | (Only 12-byte header in cleartext)  | (Headers, attributes in cleartext)|
| Command Authorization   | Per-command granularity             | Session-level / Service profile   |
| Primary Deployment Case | Administrative device management    | Network access (802.1X, VPNs, Dial
+---------------------------------------------------------------------------------------------------+

TACACS+ Packet Layout (TCP Port 49):
+---------------------+---------------------------------------------------------------+
| 12-Byte Header      | Encrypted Body Payload (Ciphertext via MD5 XOR Stream)        |
| (Cleartext)         | Includes: Usernames, Passwords, Executed Commands, Arguments  |
+---------------------+---------------------------------------------------------------+

RADIUS Packet Layout (UDP Ports 1812 / 1813):
+---------------------+-----------------------------------+---------------------------+
| 20-Byte Header      | Attribute 1: User-Name (Cleartext)| Attribute 2: User-Password|
| (Cleartext)         | Value: "admin"                    | (MD5 Encrypted Payload)   |
+---------------------+-----------------------------------+---------------------------+

TACACS+ Mechanics

TACACS+ (Terminal Access Controller Access-Control System Plus) is a Cisco-developed enhancement to legacy TACACS, standardized in RFC 8907:

• Connection Reliability: Operates over TCP port 49, benefiting from connection-oriented acknowledgments and flow control.
• Decoupled Architecture: TACACS+ treats Authentication, Authorization, and Accounting as separate processes. A device can authenticate an administrator against an Active Directory LDAP server, authorize specific Cisco CLI commands against a centralized Cisco Identity Services Engine (ISE) rule engine, and log session accounting to a dedicated audit cluster.
• Cryptographic Security: TACACS+ encrypts the entire body of every packet using a pseudo-random keystream generated by hashing the shared secret key, session ID, and sequence number using MD5. Only the 12-byte fixed header (containing version, sequence number, flags, and session ID) remains unencrypted on the wire.
• Granular Command Authorization: When an administrator types configure terminal or reload, the router suspends execution and sends a TACACS+ authorization request packet containing the exact command string. The server responds with PERMIT or DENY, enabling per-command access control.

RADIUS Mechanics

RADIUS (Remote Authentication Dial-In User Service) is an open standard protocol defined in RFC 2865 (Authentication) and RFC 2866 (Accounting):

• Connectionless Transport: Operates over UDP ports 1812 (Authentication/Authorization) and 1813 (Accounting). Legacy implementations utilize UDP ports 1645 and 1646.
• Combined Authentication & Authorization: When a network access client sends an Access-Request, the RADIUS server evaluates credentials and returns an Access-Accept containing authorization parameters (e.g., Assigned VLAN, Session Timeout, Filter-ID) inside Attribute-Value Pairs (AVPs). Authorization cannot be separated from initial authentication.
• Cryptographic Limitations: RADIUS encrypts only the User-Password attribute by XORing the password with an MD5 hash of the shared secret and the 16-byte Request Authenticator. The packet header, username, IP addresses, vendor-specific attributes, and all accounting data are transmitted in unencrypted cleartext.
• Operational Scope: RADIUS is optimized for bulk network admission control (such as IEEE 802.1X port-based authentication for enterprise Wi-Fi and switch access) rather than fine-grained administrative CLI command filtering.