GitBook: [#3024] No subject

SUMMARY.md

@@ -329,9 +329,10 @@
 * [3389 - Pentesting RDP](pentesting/pentesting-rdp.md)
 * [3632 - Pentesting distcc](pentesting/3632-pentesting-distcc.md)
 * [3690 - Pentesting Subversion (svn server)](pentesting/3690-pentesting-subversion-svn-server.md)
+* [3702/UDP - Pentesting WS-Discovery](pentesting/3702-udp-pentesting-ws-discovery.md)
 * [4369 - Pentesting Erlang Port Mapper Daemon (epmd)](pentesting/4369-pentesting-erlang-port-mapper-daemon-epmd.md)
 * [5000 - Pentesting Docker Registry](pentesting/5000-pentesting-docker-registry.md)
-* [5353/UDP Multicast DNS (mDNS)](pentesting/5353-udp-multicast-dns-mdns.md)
+* [5353/UDP Multicast DNS (mDNS) and DNS-SD](pentesting/5353-udp-multicast-dns-mdns.md)
 * [5432,5433 - Pentesting Postgresql](pentesting/pentesting-postgresql.md)
 * [5555 - Android Debug Bridge](pentesting/5555-android-debug-bridge.md)
 * [5601 - Pentesting Kibana](pentesting/5601-pentesting-kibana.md)

brute-force.md

@@ -198,6 +198,12 @@ jwt-cracker "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibm
 nmap --script ldap-brute -p 389 <IP>
 ```
 
+### MQTT
+
+```
+ncrack mqtt://127.0.0.1 --user test –P /root/Desktop/pass.txt -v
+```
+
 ### Mongo
 
 ```bash

cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md

@@ -537,7 +537,7 @@ More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security
 
 An admission controller is a piece of code that **intercepts requests to the Kubernetes API server** before the persistence of the object, but **after the request is authenticated** **and authorized**.
 
-![](<../../../.gitbook/assets/image (651).png>)
+![](<../../../.gitbook/assets/image (651) (1).png>)
 
 If an attacker somehow manages to **inject a Mutationg Adminssion Controller**, he will be able to **modify already authenticated requests**. Being able to potentially privesc, and more usually persist in the cluster.
 

pentesting-web/deserialization/python-yaml-deserialization.md

@@ -89,7 +89,7 @@ Or you could also use this **one-liner provided by @ishaack**:
 !!python/object/new:str {state: !!python/tuple ['print(exec("print(o"+"pen(\"flag.txt\",\"r\").read())"))', !!python/object/new:Warning {state : {update : !!python/name:exec } }]}
 ```
 
-Note that in **recent versions** you cannot **no longer call `.load()`** **without a `Loader`** and the **`FullLoader`** is **no longer vulnerable** to that attack.
+Note that in **recent versions** you cannot **no longer call `.load()`** **without a `Loader`** and the **`FullLoader`** is **no longer vulnerable** to this attack.
 
 ## RCE
 

pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md

@@ -72,7 +72,7 @@ Note that **even** with that **restriction** you still can perform attacks like
 
 Usually this restriction doesn't exist so you can **smuggle request into the connection between the reverse proxy and the back end** that other people are using, but it's even **possible** that the **proxy** doesn't **even reuse a connection with connections from the same IP** (pretty heavy restriction for this kind of attack).
 
-![](<../../.gitbook/assets/image (646).png>)
+![](<../../.gitbook/assets/image (646) (1).png>)
 
 In the heaviest restriction (no connection reuse) you will detect the vulnerability with the Time Based technique, but then testing it you will find that it's a "false positive".
 

pentesting-web/http-response-smuggling-desync.md

@@ -14,7 +14,7 @@ HTTP/1.1 allows to ask for **different resources without needing to wait for pre
 
 However, there is a problem desynchronising the responses queue. If an attacker send a HTTP Response smuggling attack and the responses to the **initial request and the smuggled one are responded immediately**, the smuggled response won't be inserted inside the queue of the victim response but will **just be discarded as an error**.
 
-![](<../.gitbook/assets/image (635) (1).png>)
+![](<../.gitbook/assets/image (635) (1) (1).png>)
 
 Therefore, it's needed that the **smuggled** **request** **takes more time to be processed** inside the back-end server. Therefore, by the time the smuggled request is processed, the communication with the attacker will be over.
 
@@ -70,7 +70,7 @@ Therefore, if an attacker **injects** a **HEAD** request, like in this images:
 
 Then, **once the blue one is responded to the attacker**, the next victims request is going to be introduced in the queue:
 
-![](<../.gitbook/assets/image (651) (1).png>)
+![](<../.gitbook/assets/image (651) (1) (1).png>)
 
 Then, the **victim** will **receive** the **response** from the **HEAD** request, which is **going to contain a Content-Length but no content at all**. Therefore, the proxy **won't send this response** to the victim, but will **wait** for some **content**, which actually is going to be **response to the yellow request** (also injected by the attacker):
 
@@ -120,7 +120,7 @@ After the first request is resolved and sent back to the attacker, the **victims
 
 The victim will receive as response the **HEAD response + the content of the second request response (containing part of the reflected data):**
 
-![](<../.gitbook/assets/image (633).png>)
+![](<../.gitbook/assets/image (633) (1).png>)
 
 However, note how the **reflected data had a size according to the Content-Length** of the **HEAD** response that **generated a valid HTTP response in the response queue**.
 

pentesting/1883-pentesting-mqtt-mosquitto.md

@@ -2,7 +2,7 @@
 
 ## Basic Information
 
-MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. The design principles are to minimise network bandwidth and device resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery. These principles also turn out to make the protocol ideal of the emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices, and for mobile applications where bandwidth and battery power are at a premium.
+MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, **extremely simple and lightweight messaging protocol**, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. The design principles are to minimise network bandwidth and device resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery. These principles also turn out to make the protocol ideal of the emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices, and for mobile applications where bandwidth and battery power are at a premium.
 
 **Default port:** 1883
 
@@ -11,6 +11,14 @@ PORT     STATE SERVICE                 REASON
 1883/tcp open  mosquitto version 1.4.8 syn-ack
 ```
 
+## Inspecting the traffic
+
+MQTT brokers send a **CONNACK** packet in **response** to a CONNECT packet. The **return code 0x00** indicates the credentials are valid and the return code **0x05 indicates they aren't. 0x05 example:**
+
+![](<../.gitbook/assets/image (645).png>)
+
+### ****[**Brute-Force MQTT**](../brute-force.md#mqtt)****
+
 ## Pentesting MQTT
 
 **Authentication is totally optional** and even if authentication is being performed, **encryption is not used by default** (credentials are sent in clear text). MITM attacks can still be executed to steal passwords.
@@ -23,7 +31,14 @@ To connect to a MQTT service you can use: [https://github.com/bapowell/python-mq
 > subscribe "$SYS/#"
 ```
 
-You could also use [https://github.com/akamai-threat-research/mqtt-pwn](https://github.com/akamai-threat-research/mqtt-pwn)
+You could also use [**https://github.com/akamai-threat-research/mqtt-pwn**](https://github.com/akamai-threat-research/mqtt-pwn)****
+
+You can also use:
+
+```bash
+apt-get install mosquitto mosquitto-clients
+mosquitto_sub -t 'test/topic' -v #Subscriribe to 'test/topic'
+```
 
 Or you could **run this code to try to connect to a MQTT service without authentication, subscribe to every topic and listen them**:
 
@@ -69,7 +84,7 @@ The publish/subscribe model is composed of:
 * **Broker**: routes all the messages from the publishers to the subscribers.
 * **Topic**: consists of one or more levels that are separated by a a forward slash (e.g., /smartshouse/livingroom/temperature).
 
-![](https://miro.medium.com/max/60/1\*sIxvchdgHSqAGebJjFHBAg.png?q=20)![](https://miro.medium.com/max/1073/1\*sIxvchdgHSqAGebJjFHBAg.png)Figure 01: The Publish/Subscribe Model
+![](https://miro.medium.com/max/1073/1\*sIxvchdgHSqAGebJjFHBAg.png)
 
 ### Packet Format <a href="#f15a" id="f15a"></a>
 

pentesting/3702-udp-pentesting-ws-discovery.md

@@ -0,0 +1,25 @@
+# 3702/UDP - Pentesting WS-Discovery
+
+## Basic Information
+
+The Web Services Dynamic Discovery Protocol (WS-Discovery) is a multicast discovery protocol that locates services on a local network.
+
+In WS-Discovery terminology, a Target Service is an endpoint that makes itself available for discovery, whereas a Client is an endpoint that searches for Target Services. Both use SOAP queries over UDP to the 239.255.255.250 multicast address with the destination UDP port 3702.
+
+![](<../.gitbook/assets/image (633).png>)
+
+A Target Service sends a multicast Hello 1 when it joins a network. The Target Service can receive a multicast Probe 2, a message sent by a Client searching for a Target Service by Type, at any time. The Type is an identifier for the endpoint. For example, an IP camera could have NetworkVideoTransmitter as a Type. It might also send a unicast Probe Match3 if the Target Service matches a Probe (other matching Target Services might also send unicast Probe Matches). Similarly, a Target Service might receive a multicast Resolve4 at any time, a message sent by a
+
+Client searching for a Target by name, and send a unicast Resolve Match5 if it’s the target of a Resolve. Finally, when a Target Service leaves a network, it makes an effort to send a multicast Bye 6.
+
+**Default port**: 3702
+
+```
+PORT     STATE         SERVICE
+3702/udp open|filtered unknown
+| wsdd-discover:
+|   Devices
+|     Message id: 39a2b7f2-fdbd-690c-c7c9-deadbeefceb3
+|     Address: http://10.0.200.116:50000
+|_    Type: Device wprt:PrintDeviceType
+```

pentesting/5353-udp-multicast-dns-mdns.md

@@ -1,8 +1,8 @@
-# 5353/UDP Multicast DNS (mDNS)
+# 5353/UDP Multicast DNS (mDNS) and DNS-SD
 
 ## Basic Information
 
-Apple Bonjour and Linux zero-configuration networking implementations (e.g., Avahi) use mDNS to discover network peripherals within the local network.\
+Multicast DNS (mDNS) is a **zero-configuration protocol** that lets you perform **DNS-like operations** on the local network in the absence of a conventional, unicast DNS server. The protocol uses the **same** API, **packet formats**, and operating semantics as DNS, allowing you to resolve domain names on the local network. **DNS Service Discovery (DNS-SD)** is a protocol that allows clients to **discover a list of named instances of services** (such as test.\_ipps.\_tcp.local, or linux.\_ssh.\_tcp.local) in a domain using standard DNS queries. DNS-SD is most often used in conjunction with mDNS but isn’t dependent on it. They’re both used by many IoT devices, such as network printers, Apple TVs, Google Chromecast, Network-Attached Storage (NAS) devices, and cameras. \
 **Default port:** 5353/UDP
 
 ```
@@ -10,8 +10,33 @@ PORT     STATE SERVICE
 5353/udp open  zeroconf
 ```
 
+### How mDNS Works
+
+Devices use mDNS when the local network **lacks** a conventional **unicast DNS server**. To resolve a domain name for a local address using mDNS, the device sends a **DNS query for a domain name** ending with **.local** to the **multicast** **address** 224.0.0.251 (for IPv4) or FF02::FB (for IPv6). You can also use mDNS to resolve **global domain names** (non .local ones), but mDNS implementations are supposed to **disable** this behavior by default. mDNS requests and responses use **UDP** and **port 5353** as both the source and destination port.
+
+The mDNS replies contain several important flags, including a **Time-to- Live** (TTL) value that signifies how many seconds the record is valid. Sending a reply with **TTL=0 means that the corresponding record should be cleared**. Another important flag is the QU bit, which denotes whether or not the query is a unicast query. If the **QU bit isn’t set**, the packet is a **multicast** query (QM). Because it’s possible to **receive unicast queries outside of the local link**, secure mDNS implementations should always **check that the source address in the packet matches the local subnet address range**.
+
+### How DNS-SD Works
+
+DNS-SD allows clients to **discover available services on the network**. To use it, clients send standard DNS queries for pointer records (PTR), which map the type of service to a list of names of specific instances of that type of service.
+
+To request a PTR record, clients use the name form "\<Service>.\<Domain>". The **\<Service>** part  the **service name** preceded by "\_" (for example, \_ipps, \_printer, or \_ipp) and either **\_tcp or \_udp**. The **\<Domain>** portion is "**.local**".\
+**Responders** then return the PTR records that point to the accompanying **service (SRV)** and **text (TXT) records**. Here is an example of a PTR record:
+
+```
+  _ipps._tcp.local: type PTR, class IN, test._ipps._tcp.local
+```
+
+The part of the PTR record to the **left** of the colon is its **name**, and the part on the **right** is the **SRV** **record** to which the PTR record points. The **SRV** record lists the target **host** and **port** where the **service** instance can be reached. For example, the next image shows a "test.\_ipps.\_tcp.local" SRV record in Wireshark in host ubuntu.local and port 8000:
+
+![](<../.gitbook/assets/image (651).png>)
+
+Therefore, the **name of the SRV** record is **like** the **PTR** record **preceded** by the **\<Instance>** name (test in this case). The **TXT** has the **same** **name** as the **SRV** record and contains the information needed when the IP address and port number (contained in the SRV record) for a service aren’t sufficient to identify it.
+
 ## Enumeration
 
+### nmap
+
 ```bash
 nmap -Pn -sUC -p5353 192.168.1.2
 
@@ -29,3 +54,38 @@ PORT     STATE SERVICE
 |   445/tcp smb
 |     Address=192.168.1.2
 ```
+
+### Network Enumeration
+
+You can learn a lot about the local network by simply sending mDNS requests and capturing multicast mDNS traffic.
+
+You can use the tool [**Pholus**](https://github.com/aatlasis/Pholus/) to send a mDNS requests (-rq) on the local network and capture multicast mDNS traffic (for -stimeout 10 seconds):
+
+```bash
+sudo python3 pholus3.py eth0 -rq -stimeout 10
+```
+
+## Attacks
+
+### Abusing the mDNS Probing Phase
+
+When a mDNS responder starts or changes its connectivity, it asks the local network if there is **any resource with the name he plans to use**. If the answer contains the record in question, the probing host **should choose a new name**. If 15 conflicts take place within 10 seconds, the host must then wait at least five seconds before any additional attempt. Additionally, if one minute passes during which the host can’t find an unused name, it reports an error to the user.
+
+The following command line will prevent any new device to get any new name as it will indicate that **any name is already taken**:
+
+```bash
+sudo python pholus.py eth0 -afre -stimeout 1000
+```
+
+### Spoofing/MitM
+
+The most interesting attack you can perform over this service is to perform a **MitM** in the **communication between the client and the real server**. You might be able to obtain sensitive files (MitM the communication with the printer) of even credentials (Windows authentication).\
+For more information check:
+
+{% content-ref url="pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md" %}
+[spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md](pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
+{% endcontent-ref %}
+
+## References
+
+* [Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things](https://books.google.co.uk/books/about/Practical\_IoT\_Hacking.html?id=GbYEEAAAQBAJ\&redir\_esc=y)

pentesting/pentesting-kubernetes/exposing-services-in-kubernetes.md

@@ -60,7 +60,7 @@ _This method requires you to run `kubectl` as an **authenticated user**._
 
 **NodePort opens a specific port on all the Nodes** (the VMs), and any **traffic** that is sent to this port is **forwarded to the service**. This is a really bad option usually.
 
-![](<../../.gitbook/assets/image (635).png>)
+![](<../../.gitbook/assets/image (635) (1).png>)
 
 An example of NodePort specification:
 

pentesting/pentesting-network/README.md

@@ -60,9 +60,13 @@ The nmap line proposed before will test the **top 100 UDP ports** in every host
 nmap -T4 -sY -n --open -Pn <IP/range>
 ```
 
-## [Attacking the Wifi](wifi-attacks/)
+## Pentesting Wifi
 
-[Here you can find a nice guide of all the well known Wifi attacks at the time of the writing.](wifi-attacks/)
+Here you can find a nice guide of all the well known Wifi attacks at the time of the writing:
+
+{% content-ref url="wifi-attacks/" %}
+[wifi-attacks](wifi-attacks/)
+{% endcontent-ref %}
 
 ## Discovering hosts from the inside
 
@@ -111,7 +115,7 @@ alive6 <IFACE> # Send a pingv6 to multicast.
 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`&#x20;
+* 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 `-PEPM` flag of `nmap`to perform host discovery sending **ICMPv4 echo**, **timestamp**, and **subnet mask requests:** `nmap -PEPM -sP –vvv -n 10.12.5.0/24`
 
@@ -185,9 +189,17 @@ nmap -T4 -sY -n -oA SCTFastScan <IP>
 nmap -T4 -p- -sY -sV -sC -F -n -oA SCTAllScan <IP>
 ```
 
-### [Info about IDS and IPS evasion](ids-evasion.md)
+### IDS and IPS evasion
 
-### \*\*\*\*[**More nmap options**](nmap-summary-esp.md)\*\*\*\*
+{% 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
 
@@ -272,18 +284,25 @@ In modern switches this vulnerability has been fixed.
 
 #### Dynamic Trunking
 
-Many switches support the Dynamic Trunking Protocol (DTP) by default, however, which an adversary can abuse to **emulate a switch and receive traffic across all VLANs**. The tool [_dtpscan.sh_](https://github.com/commonexploits/dtpscan) can sniff an interface and **reports if switch is in Default mode, trunk, dynamic, auto or access mode** (this is the only one that would avoid VLAN hopping). The tool will indicate if the switch is vulnerable or not.
+Many switches support the Dynamic Trunking Protocol (DTP) by default, however, which an adversary can abuse to **emulate a switch and receive traffic across all VLANs**. The tool [_**dtpscan.sh**_](https://github.com/commonexploits/dtpscan) **** can sniff an interface and **reports if switch is in Default mode, trunk, dynamic, auto or access mode** (this is the only one that would avoid VLAN hopping). The tool will indicate if the switch is vulnerable or not.
 
 If it was discovered that the the network is vulnerable, you can use _**Yersinia**_ to launch an "**enable trunking**" using protocol "**DTP**" and you will be able to see network packets from all the 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
 ```
 
+![](<../../.gitbook/assets/image (646).png>)
+
+To access the VLAN packets
+
 #### Attacking specific VLANs
 
 Once you known VLAN IDs and IPs values, you can **configure a virtual interface to attack a specific VLAN**.\
@@ -308,16 +327,34 @@ eth1.250  Link encap:Ethernet  HWaddr 00:0e:c6:f0:29:65
 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
+```
+
 #### 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)
+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 than can perform some interesting actions (like SNMP).
+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.
 
+![](<../../.gitbook/assets/image (635).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)
+```
+
 #### Layer 3 Private VLAN Bypass
 
 In guest wireless networks and other environments, private VLAN (also known as _port isolation_) settings are used to **prevent peers from interacting** (i.e., clients **connect to a wireless access point but cannot address one another**). Depending on network ACLs (or lack thereof), it might be possible to send IP packets up to a router, which are then forwarded back to a neighbouring peer.
@@ -366,7 +403,7 @@ ettercap -T -i eth1 -B eth2 -q #Set a bridge between 2 interfaces to forwardpack
 
 ### CDP Attacks
 
-CISCO Discovery Protocol is the protocol used by CISCO devices to talk among them, discover who is alive and what features does they have. You can make a DoS attack to a CISCO switch by exhausting the device memory simulating real CISCO devices.
+CISCO Discovery Protocol is the protocol used by CISCO devices to talk among them, **discover who is alive** and what features does they have. You can make a DoS attack to a CISCO switch by exhausting the device memory simulating real CISCO devices.
 
 You could use `Yersina` to capture CDP frames and show the information
 
@@ -378,6 +415,22 @@ 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
+
+Although intended for use by the employees’ Voice over Internet Protocol (VoIP) phones, modern VoIP devices are increasingly integrated with IoT devices. Many employees can now unlock doors using a special phone number, control the room’s thermostat...
+
+The tool [**voiphopper**](http://voiphopper.sourceforge.net) **** mimics the behavior of a VoIP phone in Cisco, Avaya, Nortel, and Alcatel-Lucent environments. It automatically discovers the correct VLAN ID for the voice network using one of the device discovery protocols it supports, such as the Cisco Discovery Protocol (CDP), the Dynamic Host Configuration Protocol (DHCP), Link Layer Discovery Protocol Media Endpoint Discovery (LLDP-MED), and 802.1Q ARP.
+
+**VoIP Hopper** supports **three** CDP modes. The **sniff** mode inspects the network packets and attempts to locate the VLAN ID. To use it, set the **`-c`** parameter to `0`. The **spoof** mode generates custom packets similar to the ones a real VoIP device would transmit in the corporate network. To use it, set the **`-c`** parameter to **`1`**. The spoof with a **pre-madepacket** mode sends the same packets as a Cisco 7971G-GE IP phone. To use it, set the **`-c`** parameter to **`2`**.
+
+We use the last method because it’s the fastest approach. The **`-i`** parameter specifies the attacker’s **network** **interface**, and the **`-E`** parameter specifies the **name of the VOIP device** being imitated. We chose the name SEP001EEEEEEEEE, which is compatible with the Cisco naming format for VoIP phones. The format consists of the word “SEP” followed by a MAC address. In corporate environments, you can imitate an existing VoIP device by looking at the MAC label on the back of the phone; by pressing the Settings button and selecting the Model Information option on the phone’s display screen; or by attaching the VoIP device’s Ethernet cable to your laptop and observing the device’s CDP requests using Wireshark.
+
+```bash
+voiphopper -i eth1 -E 'SEP001EEEEEEEEE ' -c 2
+```
+
+If the tool executes successfully, the **VLAN network will assign an IPv4 address to the attacker’s device**.
+
 ### DHCP
 
 #### Enumeration

pentesting/pentesting-network/spoofing-ssdp-and-upnp-devices.md

@@ -6,15 +6,125 @@
 
 ### **What is SSDP?**
 
-SSDP or Simple Service Discovery Protocol is a network protocol designed for advertisement and discovery of network services. It can work without any DHCP or DNS Configuration. It was designed to be used in residential or small office environments. It uses UDP as the underlying transport protocol on port 1900. It uses the HTTP method NOTIFY to announce the establishment or withdrawal of services to a multicast group. It is the basis of the discovery protocol UPnP.
+SSDP or Simple Service Discovery Protocol is a network protocol designed for **advertisement and discovery of network services**. It can work without any DHCP or DNS Configuration. It was designed to be used in residential or small office environments. It uses UDP as the underlying transport protocol on **port 1900**. It uses the HTTP method NOTIFY to announce the establishment or withdrawal of services to a multicast group. It is the basis of the discovery protocol UPnP.
 
 ### **What are UPnP devices?**
 
-UPnP or Universal Plug and Play is a set of networking protocols that allows networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points, and mobile devices to discover each other’s availability on the network and establish network services for communications, data sharing, and entertainment. The UPnP architecture supports zero-configuration networking. A UPnP compatible device from any vendor can dynamically join a network, obtain an IP address, announce its name, advertise or convey its capabilities upon request, and learn about the presence and capabilities of other devices.
+UPnP or Universal Plug and Play is a set of **networking protocols** that allows networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points, and mobile devices to **discover each other’s availability on the network** and establish network services for communications, data sharing, and entertainment. The UPnP architecture supports zero-configuration networking. A UPnP compatible device from any vendor can dynamically join a network, obtain an IP address, **announce its name, advertise or convey its capabilities** upon request, and learn about the presence and capabilities of other devices.
 
-Now that we understood the basic functions of SSDP or UPnP, let’s use it to manipulate the target user in order to steal their credentials.
+### **Flow**
 
-### **Installation**
+The **UPnP** stack consists of **six layers**: addressing, discovery, description, control, eventing, and presentation.
+
+In the addressing layer, UPnP-enabled systems try to get an IP address through **DHCP**. If that isn’t possible, they’ll **self-assign an address** from the 169.254.0.0/16 range (RFC 3927), a process known as AutoIP.
+
+Next is the discovery layer, in which the system searches for other devices on the network using the **Simple Service Discovery Protocol** (SSDP). The two ways to discover devices are **actively** and **passively**. When using the **active** method, UPnP-capable devices **send a discovery message** (called an **M-SEARCH request**) to the multicast address **239.255.255.250 on UDP port 1900.** We call this request HTTPU (HTTP over UDP) because it contains a header similar to the HTTP header. The M-SEARCH request looks like this:
+
+```
+  M-SEARCH * HTTP/1.1
+  ST: ssdp:all
+  MX: 5
+  MAN: ssdp:discover
+  HOST: 239.255.255.250:1900
+```
+
+UPnP systems that listen for this request are expected to reply with a **UDP unicast message that announces the HTTP location of the description XML** file, which lists the device’s supported services.
+
+When using the **passive** **method** for discovering devices, UPnP-capable devices periodically announce their services on the network by sending a **NOTIFY message to the multicast address** 239.255.255.250 on UDP port 1900. This message, which follows, looks like the one sent as a response to the active discovery:
+
+```
+  NOTIFY * HTTP/1.1\r\n
+  HOST: 239.255.255.250:1900\r\n
+  CACHE-CONTROL: max-age=60\r\n
+  LOCATION: http://192.168.10.254:5000/rootDesc.xml\r\n
+  SERVER: OpenWRT/18.06-SNAPSHOT UPnP/1.1 MiniUPnPd/2.1\r\n
+  NT: urn:schemas-upnp-org:service:WANIPConnection:2\r\n
+```
+
+The description of every UPnP profile is referenced in either the LOCATION field value of the response message received during active discovery or the NOTIFY message received during passive discovery.
+
+The **control layer** is probably the most **important** one; it allows **clients to send commands** to the UPnP device using the URLs from the description file. They can do this using the Simple Object Access Protocol (**SOAP**), a messaging protocol that uses XML over HTTP. Devices send SOAP requests to the controlURL endpoint, described in the \<service> tag inside the description file. A \<service> tag looks like this:
+
+```xml
+ <service>
+     <serviceType>urn:schemas-upnp-org:service:WANIPConnection:2</serviceType>
+     <serviceId>urn:upnp-org:serviceId:WANIPConn1</serviceId>
+     <SCPDURL>/WANIPCn.xml</SCPDURL>
+     <controlURL>/ctl/IPConn</controlURL>
+     <eventSubURL>/evt/IPConn</eventSubURL>
+ </service>
+```
+
+### **IGD - Internet Gateway Device**
+
+**IGD** maps ports in network address translation (NAT) setups. IGD **allows** an application to dynamically **add a temporary port mapping on the router** for a certain time period (without needing the user to perform any manual step).
+
+Most devices **don’t** normally **accept** **SSDP** packets through the **WAN** **interface**, but some of them can still **accept IGD** commands through open SOAP control points.
+
+In the **Umap tool section** you can find a way to exploit this vector.
+
+## **Tools**
+
+### **Miranda**
+
+****[**Miranda**](https://raw.githubusercontent.com/0x90/miranda-upnp/master/src/miranda.py) **** is a **python2** **UPnP** **client** that can be useful to **discover** UPnP services, get the **details** and **send commands** to them:
+
+```
+upnp> msearch
+
+Entering discovery mode for 'upnp:rootdevice', Ctl+C to stop...
+
+****************************************************************
+SSDP reply message from 192.168.1.254:49152
+XML file is located at http://192.168.1.254:49152/wps_device.xml
+Device is running Unspecified, UPnP/1.0, Unspecified
+****************************************************************
+
+****************************************************************
+SSDP reply message from 192.168.1.254:53350
+XML file is located at http://192.168.1.254:53350/37699b14/rootDesc.xml
+Device is running Linux/3.4.11 UPnP/1.0 MiniUPnPd/1.9
+****************************************************************
+
+upnp> host list
+	[0] 192.168.1.254:49152
+	[1] 192.168.1.254:53350
+
+upnp> host get 0
+upnp> host details 0
+
+Host name:         192.168.1.254:49152
+UPNP XML File:     http://192.168.1.254:49152/wps_device.xml
+
+
+Device information:
+	Device Name: WFADevice
+		Service Name: WFAWLANConfig
+			controlURL: wps_control
+			eventSubURL: wps_event
+			serviceId: urn:wifialliance-org:serviceId:WFAWLANConfig1
+			SCPDURL: wps_scpd.xml
+			fullName: urn:schemas-wifialliance-org:service:WFAWLANConfig:1
+			ServiceActions:
+				PutMessage
+					NewInMessage 
+						InMessage:
+							dataType: bin.base64
+
+[...]
+
+upnp> host send 0 WFADevice WFAWLANConfig PutMessage
+```
+
+### Umap
+
+The tool [**umap**](https://github.com/0x90/upnp-arsenal/blob/master/umap-bypass.py) **** can help to **discover upnp commands** that are **available** from **WAN** interfaces even if those aren't announced in those interfaces (this is because of buggy implementations). Note that if, for example, you are testing a router and you have access to it from both the internal network and the WAN interface, you should try to **enumerate all the services from the internal** network (using **miranda** for example) and then try to **call those services from the external** network.
+
+### **Other UPnP Tools**
+
+Find in [**https://github.com/0x90/upnp-arsenal**](https://github.com/0x90/upnp-arsenal) **** more upnp tools
+
+### **Evil SSDP**
 
 The Evil SSDP too was developed by [initstring](https://twitter.com/init\_string). This tool is hosted on the GitHub. We will be using the git clone command to clone all the contents of the git onto our attacker machine. The git clone command will create a directory with the same name as on GitHub. Since the tool is developed in Python version 3, we will have to use the python3 followed by the name of the .py file in order to run the program. Here we can see a basic help screen of the tool.