Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 04:33:28 +00:00
Code Issues Projects Releases Packages Wiki Activity

GITBOOK-3875: change request with no subject merged in GitBook

Browse source
This commit is contained in:
CPol 2023-04-17 15:16:32 +00:00 committed by gitbook-bot
parent 28ce005c4a
commit bef0b1cc79
No known key found for this signature in database
GPG key ID: 07D2180C7B12D0FF
5 changed files with 623 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
.gitbook/assets/image (666).png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 38 KiB

3
SUMMARY.md
View file

@ -302,6 +302,9 @@
* [Print Job Retention](network-services-pentesting/pentesting-printers/print-job-retention.md) * [Print Job Retention](network-services-pentesting/pentesting-printers/print-job-retention.md)
* [Scanner and Fax](network-services-pentesting/pentesting-printers/scanner-and-fax.md) * [Scanner and Fax](network-services-pentesting/pentesting-printers/scanner-and-fax.md)
* [Pentesting SAP](network-services-pentesting/pentesting-sap.md) * [Pentesting SAP](network-services-pentesting/pentesting-sap.md)
* [Pentesting VoIP](network-services-pentesting/pentesting-voip/README.md)
* [Basic VoIP Protocols](network-services-pentesting/pentesting-voip/basic-voip-protocols/README.md)
* [SIP (Session Initiation Protocol)](network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md)
* [Pentesting Remote GdbServer](network-services-pentesting/pentesting-remote-gdbserver.md) * [Pentesting Remote GdbServer](network-services-pentesting/pentesting-remote-gdbserver.md)
* [7/tcp/udp - Pentesting Echo](network-services-pentesting/7-tcp-udp-pentesting-echo.md) * [7/tcp/udp - Pentesting Echo](network-services-pentesting/7-tcp-udp-pentesting-echo.md)
* [21 - Pentesting FTP](network-services-pentesting/pentesting-ftp/README.md) * [21 - Pentesting FTP](network-services-pentesting/pentesting-ftp/README.md)

238
network-services-pentesting/pentesting-voip/README.md Normal file
View file

@ -0,0 +1,238 @@
# Pentesting VoIP
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a><a href="https://twitter.com/carlospolopm"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
</details>
## VoIP Basic Information
To start learning about how VoIP works check:
{% content-ref url="basic-voip-protocols/" %}
[basic-voip-protocols](basic-voip-protocols/)
{% endcontent-ref %}
## VoIP Red Team Methodology
## VoIP Enumeration
### Telephone Numbers
One of the first steps a Red Team could do is to search available phone numbers to contact with the company using OSINT tools, Google Searches or scraping the web pages.
Once you have the telephone numbers you could use online services to identify the operator:
* [https://www.numberingplans.com/?page=analysis\&sub=phonenr](https://www.numberingplans.com/?page=analysis\&sub=phonenr)
* [https://mobilenumbertracker.com/](https://mobilenumbertracker.com/)
* [https://www.whitepages.com/](https://www.whitepages.com/)
* [https://www.twilio.com/lookup](https://www.twilio.com/lookup)
Knowing if the operator provides VoIP services you could identify if the company is using VoIP... Moreover, it's possible that the company hasn't hired VoIP services but is using PSTN cards to connect it's own VoIP PBX to the traditional telephony network.
Things such as automated responses of music usually indicates that VoIP is being used.
### Google Dorks
```bash
# Grandstream phones
intitle:"Grandstream Device Configuration" Password
intitle:"Grandstream Device Configuration" (intext:password & intext:"Grandstream Device Configuration" & intext:"Grandstream Networks" | inurl:cgi-bin) -.com|org
# Cisco Callmanager
inurl:"ccmuser/logon.asp"
intitle:"Cisco CallManager User Options Log On" "Please enter your User ID and Password in the spaces provided below and click the Log On button"
# Cisco phones
inurl:"NetworkConfiguration" cisco
# Linksys phones
intitle:"Sipura SPA Configuration"
# Snom phones
intitle:"snom" intext:"Welcome to Your Phone!" inurl:line_login.htm
# Polycom SoundPoint IP & phones
intitle:"SoundPoint IP Configuration Utility - Registration"
"Welcome to Polycom Web Configuration Utility" "Login as" "Password"
intext: "Welcome to Polycom Web Configuration Utility" intitle:"Polycom - Configuration Utility" inurl:"coreConf.htm"
intitle:"Polycom Login" inurl:"/login.html"
intitle:"Polycom Login" -.com
# Elastix
intitle:"Elastix - Login page" intext:"Elastix is licensed under GPL"
# FreePBX
inurl:"maint/index.php?FreePBX" intitle: "FreePBX" intext:"FreePBX Admministration"
```
### OSINT information
Any other OSINT enumeration that helps to identify VoIP software being used will be helpful for a Red Team.
### Network Enumeration
* **`nmap`** is capable of scanning UDP services, but because of the number of UDP services being scanned, it's very slow and might not ve very accurante with this kind of services.
* **`svmap`** from SIPVicious (`sudo apt install sipvicious`): Will locate SIP services in the indicated network.
* `svmap` is **easy to block** because it uses the User-Agent `friendly-scanner`, but you could modify the code from `/usr/share/sipvicious/sipvicious` and change it.
```bash
# Use --fp to fingerprint the services
svmap 192.168.1.0/24 -p 5060-5070 [--fp]
```
* **`sipscan.py`** from [**sippts**](https://github.com/Pepelux/sippts)**:** Sipscan is a very fast scanner for SIP services over UDP, TCP or TLS. It uses multithread and can scan large ranges of networks. It allows to easily indicate a port range, scan both TCP & UDP, use another method (by default it will use OPTIONS) and specify a different User-Agent (and more).
```bash
./sipscan.py -i 192.168.2.0/24 -p all -r 5060-5080 -th 200 -ua Cisco [-m REGISTER]
[!] IP/Network: 192.168.2.0/24
[!] Port range: 5060-5080
[!] Protocol: UDP, TCP, TLS
[!] Method to scan: REGISTER
[!] Customized User-Agent: Cisco
[!] Used threads: 200
```
* **metasploit**:
```
auxiliary/scanner/sip/options_tcp normal No SIP Endpoint Scanner (TCP)
auxiliary/scanner/sip/options normal No SIP Endpoint Scanner (UDP)
```
#### Extra Network Enumeration
The PBX could also be exposing other network services such as:
* **69/UDP (TFTP)**: Firmware updates
* **80 (HTTP) / 443 (HTTPS)**: To manage the device from the web
* **389 (LDAP)**: Alternative to store the users information
* **3306 (MySQL**): MySQL database
* **5038 (Manager)**: Allows to use Asterisk from other platforms
* **5222 (XMPP)**: Messages using Jabber
* **5432 (PostgreSQL)**: PostgreSQL database
* And others...
### Extension Enumeration
Extensions in a PBX (Private Branch Exchange) system refer to the **unique internal identifiers assigned to individual** phone lines, devices, or users within an organization or business. Extensions make it possible to **route calls within the organization efficiently**, without the need for individual external phone numbers for each user or device.
* **`svwar`** from SIPVicious (`sudo apt install sipvicious`): `svwar` is a free SIP PBX extension line scanner. In concept it works similar to traditional wardialers by **guessing a range of extensions or a given list of extensions**.
```bash
svwar 192.168.1.15 -p5060 -e100-300 -m REGISTER
```
* **`sipextend.py`** from [**sippts**](https://github.com/Pepelux/sippts)**:** Sipexten identifies extensions on a SIP server. Sipexten can check large network and port ranges.
```bash
python3 sipexten.py -i 192.168.2.203 -r 5080 -e 100-200
```
* **metasploit**: You can also enumerate extensions/usernames with metasploit:
```
auxiliary/scanner/sip/enumerator_tcp normal No SIP Username Enumerator (TCP)
auxiliary/scanner/sip/enumerator normal No SIP Username Enumerator (UDP)
```
* **`enumiax` (`apt install enumiax`): enumIAX** is an Inter Asterisk Exchange protocol **username brute-force enumerator**. enumIAX may operate in two distinct modes; Sequential Username Guessing or Dictionary Attack.
```bash
enumiax -d /usr/share/wordlists/metasploit/unix_users.txt 192.168.1.1 # Use dictionary
enumiax -v -m3 -M3 192.168.1.1
```
## VoIP Attacks
### Password Brute-Force
Having discovered the **PBX** and some **extensions/usernames**, a Red Team could try to **authenticate via the `REGISTER` method** to an extension using a dictionary of common passwords to brute force the authentication.
{% hint style="danger" %}
Note that a **username** can be the same as the extension, but this practice may vary depending on the PBX system, its configuration, and the organization's preferences...
If the username is not the same as the extension, you will need to **figure out the username to brute-force it**.
{% endhint %}
* **`svcrack`** from SIPVicious (`sudo apt install sipvicious`): SVCrack allows you to crack the password for a specific username/extension on a PBX.
```bash
svcrack -u100 -d dictionary.txt udp://10.0.0.1:5080 #Crack known username
svcrack -u100 -r1-9999 -z4 10.0.0.1 #Check username in extensions
```
* **`sipcrack.py`** from [**sippts**](https://github.com/Pepelux/sippts)**:** SIP Digest Crack is a tool to crack the digest authentications within the SIP protocol.
{% code overflow="wrap" %}
```bash
python3 siprcrack.py -i 192.168.2.203 -r 5080 -e 100,101,103-105 -w wordlist/rockyou.txt
```
{% endcode %}
* **Metasploit**:
* [https://github.com/jesusprubio/metasploit-sip/blob/master/sipcrack.rb](https://github.com/jesusprubio/metasploit-sip/blob/master/sipcrack.rb)
* [https://github.com/jesusprubio/metasploit-sip/blob/master/sipcrack\_tcp.rb](https://github.com/jesusprubio/metasploit-sip/blob/master/sipcrack\_tcp.rb)
### VoIP Sniffing
If you find VoIP equipment inside an **Open Wifi network**, you could **sniff all the information**. Moreover, if you are inside a more closed network (connected via Ethernet or protected Wifi) you could perform **MitM attacks such as** [**ARPspoofing**](../../generic-methodologies-and-resources/pentesting-network/#arp-spoofing) between the **PBX and the gateway** in order to sniff the information.
Among the network information, you could find **web credentials** to manage the equipment, user **extensions**, **username**, **IP** addresses, even **hashed passwords** and **RTP packets** that you could reproduce to **hear the conversation**, and more.
{% hint style="danger" %}
Note that if **TLS is used in the SIP communication** you won't be able to see the SIP communication in clear.\
The same will happen if **SRTP** and **ZRTP** is used, **RTP packets won't be in clear text**.
{% endhint %}
#### SIP credentials
[Check this example to understand better a **SIP REGISTER communication**](basic-voip-protocols/sip-session-initiation-protocol.md#sip-register-example) to learn how are **credentials being sent**.
* **`sipdump`** & **`sipcrack`,** part of **sipcrack** (`apt-get install sipcrack`): These tools can **extract** from a **pcap** the **digest authentications** within the SIP protocol and **bruteforce** them.
```bash
sipdump -p net-capture.pcap sip-creds.txt
sipcrack sip-creds.txt -w dict.txt
```
* **`siptshar.py`, `sipdump.py`, `sipcrack.py`** from [**sippts**](https://github.com/Pepelux/sippts)**:**
* **SipTshark** extracts data of SIP protocol from a PCAP file.
* **SipDump** Extracts SIP Digest authentications from a PCAP file.
* **SIP Digest Crack** is a tool to crack the digest authentications within the SIP protocol.
```bash
python3 siptshark.py -f captura3.pcap [-filter auth]
python3 sipdump.py -f captura3.pcap -o data.txt
python3 sipcrack.py -f data.txt -w wordlist/rockyou.txt
```
#### DTMF codes
**Not only SIP credentials** can be found in the network traffic, it's also possible to find DTMF codes which are used for example to access the **voicemail**.\
It's possible to send these codes in **INFO SIP messages**, in **audio** or inside **RTP packets**. If the codes are inside RTP packets, you could cut that part of the conversation and use the tool multimo to extract them:
```bash
multimon -a DTMF -t wac pin.wav
```
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a><a href="https://twitter.com/carlospolopm"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
</details>

117
network-services-pentesting/pentesting-voip/basic-voip-protocols/README.md Normal file
View file

@ -0,0 +1,117 @@
# Basic VoIP Protocols
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a><a href="https://twitter.com/carlospolopm"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
</details>
## Signaling Protocols
### SIP (Session Initiation Protocol)
This is the industry standard, for more information check:
{% content-ref url="sip-session-initiation-protocol.md" %}
[sip-session-initiation-protocol.md](sip-session-initiation-protocol.md)
{% endcontent-ref %}
### MGCP (Media Gateway Control Protocol)
MGCP (Media Gateway Control Protocol) is a **signaling** and **call** **control protocol** outlined in RFC 3435. It operates in a centralized architecture, which consists of three main components:
1. **Call Agent or Media Gateway Controller (MGC)**: The master gateway in the MGCP architecture is responsible for **managing and controlling the media gateways**. It handles call setup, modification, and termination processes. The MGC communicates with the media gateways using the MGCP protocol.
2. **Media Gateways (MGs) or Slave Gateways**: These devices **convert digital media streams between different networks**, such as traditional circuit-switched telephony and packet-switched IP networks. They are managed by the MGC and execute commands received from it. Media gateways may include functions like transcoding, packetization, and echo cancellation.
3. **Signaling Gateways (SGs)**: These gateways are responsible for **converting signaling messages between different networks**, enabling seamless communication between traditional telephony systems (e.g., SS7) and IP-based networks (e.g., SIP or H.323). Signaling gateways are crucial for interoperability and ensuring that call control information is properly communicated between the different networks.
In summary, MGCP centralizes the call control logic in the call agent, which simplifies the management of media and signaling gateways, providing better scalability, reliability, and efficiency in telecommunication networks.
### SCCP (Skinny Client Control Protocol)
Skinny Client Control Protocol (SCCP) is a **proprietary signaling and call control protocol** owned by Cisco Systems. It is primarily **used** for communication between **Cisco Unified Communications Manager** (formerly known as CallManager) and Cisco IP phones or other Cisco voice and video endpoints.
SCCP is a lightweight protocol that simplifies the communication between the call control server and the endpoint devices. It is referred to as "Skinny" because of its minimalistic design and reduced bandwidth requirements compared to other VoIP protocols like H.323 or SIP.
The main components of an SCCP-based system are:
1. **Call Control Server**: This server, typically a Cisco Unified Communications Manager, manages the call setup, modification, and termination processes, as well as other telephony features such as call forwarding, call transfer, and call hold.
2. **SCCP Endpoints**: These are devices such as IP phones, video conferencing units, or other Cisco voice and video endpoints that use SCCP to communicate with the call control server. They register with the server, send and receive signaling messages, and follow the instructions provided by the call control server for call handling.
3. **Gateways**: These devices, such as voice gateways or media gateways, are responsible for converting media streams between different networks, like traditional circuit-switched telephony and packet-switched IP networks. They may also include additional functionality, such as transcoding or echo cancellation.
SCCP offers a simple and efficient communication method between Cisco call control servers and endpoint devices. However, it is worth noting that **SCCP is a proprietary protocol**, which can limit interoperability with non-Cisco systems. In such cases, other standard VoIP protocols like SIP may be more suitable.
### H.323
H.323 is a **suite of protocols** for multimedia communication, including voice, video, and data conferencing over packet-switched networks, such as IP-based networks. It was developed by the **International Telecommunication Union** (ITU-T) and provides a comprehensive framework for managing multimedia communication sessions.
Some key components of the H.323 suite include:
1. **Terminals**: These are endpoint devices, such as IP phones, video conferencing systems, or software applications, that support H.323 and can participate in multimedia communication sessions.
2. **Gateways**: These devices convert media streams between different networks, like traditional circuit-switched telephony and packet-switched IP networks, enabling interoperability between H.323 and other communication systems. They may also include additional functionality, such as transcoding or echo cancellation.
3. **Gatekeepers**: These are optional components that provide call control and management services in an H.323 network. They perform functions such as address translation, bandwidth management, and admission control, helping to manage and optimize network resources.
4. **Multipoint Control Units (MCUs)**: These devices facilitate multipoint conferences by managing and mixing media streams from multiple endpoints. MCUs enable features such as video layout control, voice-activated switching, and continuous presence, making it possible to host large-scale conferences with multiple participants.
H.323 supports a range of audio and video codecs, as well as other supplementary services like call forwarding, call transfer, call hold, and call waiting. Despite its widespread adoption in the early days of VoIP, H.323 has been gradually replaced by more modern and flexible protocols like the **Session Initiation Protocol (SIP)**, which offers better interoperability and easier implementation. However, H.323 remains in use in many legacy systems and continues to be supported by various equipment vendors.
### IAX (Inter Asterisk eXchange)
IAX (Inter-Asterisk eXchange) is a **signaling and call control protocol** primarily used for communication between Asterisk PBX (Private Branch Exchange) servers and other VoIP devices. It was developed by Mark Spencer, the creator of the Asterisk open-source PBX software, as an alternative to other VoIP protocols like SIP and H.323.
IAX is known for its **simplicity, efficiency, and ease of implementation**. Some key features of IAX include:
1. **Single UDP Port**: IAX uses a single UDP port (4569) for both signaling and media traffic, which simplifies firewall and NAT traversal, making it easier to deploy in various network environments.
2. **Binary Protocol**: Unlike text-based protocols like SIP, IAX is a binary protocol, which reduces its bandwidth consumption and makes it more efficient for transmitting signaling and media data.
3. **Trunking**: IAX supports trunking, which allows multiple calls to be combined into a single network connection, reducing overhead and improving bandwidth utilization.
4. **Native Encryption**: IAX has built-in support for encryption, using methods like RSA for key exchange and AES for media encryption, providing secure communication between endpoints.
5. **Peer-to-Peer Communication**: IAX can be used for direct communication between endpoints without the need for a central server, enabling simpler and more efficient call routing.
Despite its benefits, IAX has some limitations, such as its primary focus on the Asterisk ecosystem and less widespread adoption compared to more established protocols like SIP. As a result, IAX might not be the best choice for interoperability with non-Asterisk systems or devices. However, for those working within the Asterisk environment, IAX offers a robust and efficient solution for VoIP communication.
## Transmission & Transport Protocols
### SDP (Session Description Protocol)
SDP (Session Description Protocol) is a **text-based format** used to describe the characteristics of multimedia sessions, such as voice, video, or data conferencing, over IP networks. It was developed by the **Internet Engineering Task Force (IETF)** and is defined in **RFC 4566**. SDP does not handle the actual media transmission or session establishment but is used in conjunction with other signaling protocols, like **SIP (Session Initiation Protocol)**, to negotiate and exchange information about the media streams and their attributes.
Some key elements of SDP include:
1. **Session Information**: SDP describes the details of a multimedia session, including session name, session description, start time, and end time.
2. **Media Streams**: SDP defines the characteristics of media streams, such as the media type (audio, video, or text), transport protocol (e.g., RTP or SRTP), and the media format (e.g., codec information).
3. **Connection Information**: SDP provides information about the network address (IP address) and port number where the media should be sent or received.
4. **Attributes**: SDP supports the use of attributes to provide additional, optional information about a session or media stream. Attributes can be used for specifying various features like encryption keys, bandwidth requirements, or media control mechanisms.
SDP is typically used in the following process:
1. An initiating party creates an SDP description of the proposed multimedia session, including the details of the media streams and their attributes.
2. The SDP description is sent to the receiving party, usually embedded within a signaling protocol message like SIP or RTSP.
3. The receiving party processes the SDP description, and based on its capabilities, it may accept, reject, or modify the proposed session.
4. The final SDP description is sent back to the initiating party as part of the signaling protocol message, completing the negotiation process.
SDP's simplicity and flexibility make it a widely adopted standard for describing multimedia sessions in various communication systems, playing a crucial role in establishing and managing real-time multimedia sessions over IP networks.
### RTP / RTCP / SRTP / ZRTP
1. **RTP (Real-time Transport Protocol)**: RTP is a network protocol designed for the delivery of audio and video data, or other real-time media, over IP networks. Developed by the **IETF** and defined in **RFC 3550**, RTP is commonly used with signaling protocols like SIP and H.323 to enable multimedia communication. RTP provides mechanisms for **synchronization**, **sequencing**, and **timestamping** of media streams, helping to ensure smooth and timely media playback.
2. **RTCP (Real-time Transport Control Protocol)**: RTCP is a companion protocol to RTP, used for monitoring the quality of service (QoS) and providing feedback on the transmission of media streams. Defined in the same **RFC 3550** as RTP, RTCP **periodically exchanges control packets between participants in an RTP session**. It shares information such as packet loss, jitter, and round-trip time, which helps in diagnosing and adapting to network conditions, improving overall media quality.
3. **SRTP (Secure Real-time Transport Protocol)**: SRTP is an extension of RTP that provides **encryption**, **message authentication**, and **replay protection** for media streams, ensuring secure transmission of sensitive audio and video data. Defined in **RFC 3711**, SRTP uses cryptographic algorithms like AES for encryption and HMAC-SHA1 for message authentication. SRTP is often used in combination with secure signaling protocols like SIP over TLS to provide end-to-end security in multimedia communication.
4. **ZRTP (Zimmermann Real-time Transport Protocol)**: ZRTP is a cryptographic key-agreement protocol that provides **end-to-end encryption** for RTP media streams. Developed by Phil Zimmermann, the creator of PGP, ZRTP is described in **RFC 6189**. Unlike SRTP, which relies on signaling protocols for key exchange, ZRTP is designed to work independently of the signaling protocol. It uses **Diffie-Hellman key exchange** to establish a shared secret between the communicating parties, without requiring prior trust or a public key infrastructure (PKI). ZRTP also includes features like **Short Authentication Strings (SAS)** to protect against man-in-the-middle attacks.
These protocols play essential roles in **delivering and securing real-time multimedia communication over IP networks**. While RTP and RTCP handle the actual media transmission and quality monitoring, SRTP and ZRTP ensure that the transmitted media is protected against eavesdropping, tampering, and replay attacks.
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a><a href="https://twitter.com/carlospolopm"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
</details>

265
network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md Normal file
View file

@ -0,0 +1,265 @@
# SIP (Session Initiation Protocol)
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a><a href="https://twitter.com/carlospolopm"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
</details>
## Basic Information
SIP (Session Initiation Protocol) is a **signaling and call control protocol** widely used for establishing, modifying, and terminating multimedia sessions, including voice, video, and instant messaging, over IP networks. Developed by the **Internet Engineering Task Force (IETF)**, SIP is defined in **RFC 3261** and has become the de facto standard for VoIP and unified communications.
Some key features of SIP include:
1. **Text-based Protocol**: SIP is a text-based protocol, which makes it human-readable and easier to debug. It is based on a request-response model, similar to HTTP, and uses methods like INVITE, ACK, BYE, and CANCEL for controlling call sessions.
2. **Scalability and Flexibility**: SIP is highly scalable and can be used in small-scale deployments as well as large enterprise and carrier-grade environments. It can be easily extended with new features, making it adaptable to various use cases and requirements.
3. **Interoperability**: SIP's widespread adoption and standardization ensure better interoperability between different devices, applications, and service providers, promoting seamless communication across various platforms.
4. **Modular Design**: SIP works with other protocols like **RTP (Real-time Transport Protocol)** for media transmission and **SDP (Session Description Protocol)** for describing multimedia sessions. This modular design allows for greater flexibility and compatibility with different media types and codecs.
5. **Proxy and Redirect Servers**: SIP can use proxy and redirect servers to facilitate call routing and provide advanced features like call forwarding, call transfer, and voicemail services.
6. **Presence and Instant Messaging**: SIP is not limited to voice and video communication. It also supports presence and instant messaging, enabling a wide range of unified communication applications.
Despite its many advantages, SIP can be complex to configure and manage, particularly when dealing with NAT traversal and firewall issues. However, its versatility, scalability, and extensive support across the industry make it a popular choice for VoIP and multimedia communication.
### SIP Methods
The core SIP methods defined in **RFC 3261** include:
1. **INVITE**: Used to **initiate a new session (call)** or modify an existing one. The INVITE method carries the session description (typically using SDP) to inform the recipient about the details of the proposed session, such as media types, codecs, and transport protocols.
2. **ACK**: Sent to **confirm the receipt** of a final response to an INVITE request. The ACK method ensures the reliability of INVITE transactions by providing end-to-end acknowledgement.
3. **BYE**: Used to **terminate an established session (call)**. The BYE method is sent by either party in the session to indicate that they wish to end the communication.
4. **CANCEL**: Sent to **cancel a pending INVITE** request before the session is established. The CANCEL method allows the sender to abort an INVITE transaction if they change their mind or if there is no response from the recipient.
5. **OPTIONS**: Used to **query the capabilities of a SIP server or user agent**. The OPTIONS method can be sent to request information about supported methods, media types, or other extensions without actually establishing a session.
6. **REGISTER**: Used by a user agent to **register its current location with a SIP registrar server**. The REGISTER method helps in maintaining an up-to-date mapping between a user's SIP URI and their current IP address, enabling call routing and delivery.
{% hint style="warning" %}
Note that to call someone it's **not neccesary to use the REGISTER** for anything.\
However, it's possible that in order to perform an **INVITE** the caller needs to **authenticate** first or he will receive a **`401 Unauthorized`** response.
{% endhint %}
In addition to these core methods, there are **several SIP extension methods** defined in other RFCs, such as:
1. **SUBSCRIBE**: Defined in RFC 6665, the SUBSCRIBE method is used to **request notifications** about the state of a specific resource, such as a user's presence or call status.
2. **NOTIFY**: Also defined in RFC 6665, the NOTIFY method is sent by a server to **inform a subscribed user agent** about changes in the state of a monitored resource.
3. **REFER**: Defined in RFC 3515, the REFER method is used to **request that the recipient performs a transfer or refers to a third party**. This is typically used for **call transfer** scenarios.
4. **MESSAGE**: Defined in RFC 3428, the MESSAGE method is used to **send instant messages between SIP user agents**, enabling text-based communication within the SIP framework.
5. **UPDATE**: Defined in RFC 3311, the UPDATE method allows **modifying a session without affecting the state of the existing dialog**. This is useful for updating session parameters, such as codecs or media types, during an ongoing call.
6. **PUBLISH**: Defined in RFC 3903, the PUBLISH method is used by a user agent to **publish event state information to a server**, making it available to other interested parties.
### SIP Response Codes
* **1xx (Provisional Responses)**: These responses indicate that the request was received, and the server is continuing to process it.
* 100 Trying: The request was received, and the server is working on it.
* 180 Ringing: The callee is being alerted and will take the call.
* 183 Session Progress: Provides information about the progress of the call.
* **2xx (Successful Responses)**: These responses indicate that the request was successfully received, understood, and accepted.
* 200 OK: The request was successful, and the server has fulfilled it.
* 202 Accepted: The request was accepted for processing, but it hasn't been completed yet.
* **3xx (Redirection Responses)**: These responses indicate that further action is required to fulfill the request, typically by contacting an alternate resource.
* 300 Multiple Choices: There are multiple options available, and the user or client must choose one.
* 301 Moved Permanently: The requested resource has been assigned a new permanent URI.
* 302 Moved Temporarily: The requested resource is temporarily available at a different URI.
* 305 Use Proxy: The request must be sent to a specified proxy.
* **4xx (Client Error Responses)**: These responses indicate that the request contains bad syntax or cannot be fulfilled by the server.
* 400 Bad Request: The request was malformed or invalid.
* 401 Unauthorized: The request requires user authentication.
* 403 Forbidden: The server understood the request but refuses to fulfill it.
* 404 Not Found: The requested resource was not found on the server.
* 408 Request Timeout: The server did not receive a complete request within the time it was prepared to wait.
* 486 Busy Here: The callee is currently busy and unable to take the call.
* **5xx (Server Error Responses)**: These responses indicate that the server failed to fulfill a valid request.
* 500 Internal Server Error: The server encountered an error while processing the request.
* 501 Not Implemented: The server does not support the functionality required to fulfill the request.
* 503 Service Unavailable: The server is currently unable to handle the request due to maintenance or overload.
* **6xx (Global Failure Responses)**: These responses indicate that the request cannot be fulfilled by any server.
* 600 Busy Everywhere: All possible destinations for the call are busy.
* 603 Decline: The callee does not wish to participate in the call.
* 604 Does Not Exist Anywhere: The requested resource is not available anywhere in the network.
## Examples
### SIP INVITE Example
```
INVITE sip:jdoe@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: John Doe <sip:jdoe@example.com>
From: Jane Smith <sip:jsmith@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jsmith@pc33.example.com>
User-Agent: ExampleSIPClient/1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Content-Length: 142
v=0
o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com
s=-
c=IN IP4 pc33.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000te
```
<details>
<summary>Each Param Explained</summary>
1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - This line indicates the method (INVITE), the request URI (sip:[jdoe@example.com](mailto:jdoe@example.com)), and the SIP version (SIP/2.0).
2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - The Via header specifies the transport protocol (UDP) and the client's address (pc33.example.com). The "branch" parameter is used for loop detection and transaction matching.
3. **Max-Forwards**: `Max-Forwards: 70` - This header field limits the number of times the request can be forwarded by proxies to avoid infinite loops.
4. **To**: `To: John Doe <sip:jdoe@example.com>` - The To header specifies the recipient of the call, including their display name (John Doe) and SIP URI (sip:[jdoe@example.com](mailto:jdoe@example.com)).
5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - The From header specifies the sender of the call, including their display name (Jane Smith) and SIP URI (sip:[jsmith@example.org](mailto:jsmith@example.org)). The "tag" parameter is used to uniquely identify the sender's role in the dialog.
6. **Call-ID**: `Call-ID: a84b4c76e66710` - The Call-ID header uniquely identifies a call session between two user agents.
7. **CSeq**: `CSeq: 314159 INVITE` - The CSeq header contains a sequence number and the method used in the request. It's used to match responses to requests and detect out-of-order messages.
8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - The Contact header provides a direct route to the sender, which can be used for subsequent requests and responses.
9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - The User-Agent header provides information about the software or hardware of the sender, including its name and version.
10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - The Allow header lists the SIP methods supported by the sender. This helps the recipient understand which methods can be used during the communication.
11. **Content-Type**: `Content-Type: application/sdp` - The Content-Type header specifies the media type of the message body, in this case, SDP (Session Description Protocol).
12. **Content-Length**: `Content-Length: 142` - The Content-Length header indicates the size of the message body in bytes.
13. **Message Body**: The message body contains the SDP session description, which includes information about the media types, codecs, and transport protocols for the proposed session.
* `v=0` - Protocol version (0 for SDP)
* `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originator and session identifier
* `s=-` - Session name (a single hyphen indicates no session name)
* `c=IN IP4 pc33.example.com` - Connection information (network type, address type, and address)
* `t=0 0` - Timing information (start and stop times, 0 0 means the session is not bounded)
* `m=audio 49170 RTP/AVP 0` - Media description (media type, port number, transport protocol, and format list). In this case, it specifies an audio stream using RTP/AVP (Real-time Transport Protocol / Audio Video Profile) and format 0 (PCMU/8000).
* `a=rtpmap:0 PCMU/8000` - Attribute mapping the format (0) to the codec (PCMU) and its clock rate (8000 Hz).
</details>
### SIP REGISTER Example
The REGISTER method is used in Session Initiation Protocol (SIP) to allow a user agent (UA), such as a VoIP phone or a softphone, to **register its location with a SIP registrar server**. This process lets the server know **where to route incoming SIP requests destined for the registered user**. The registrar server is usually part of a SIP proxy server or a dedicated registration server.
Here's a detailed example of the SIP messages involved in a REGISTER authentication process:
1. Initial **REGISTER** request from UA to the registrar server:
```yaml
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0
```
This initial REGISTER message is sent by the UA (Alice) to the registrar server. It includes important information such as the desired registration duration (Expires), the user's SIP URI (sip:[alice@example.com](mailto:alice@example.com)), and the user's contact address (sip:alice@192.168.1.100:5060).
2. **401 Unauthorized** response from the registrar server:
```css
cssCopy codeSIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
Content-Length: 0
```
The registrar server responds with a "401 Unauthorized" message, which includes a "WWW-Authenticate" header. This header contains information required for the UA to authenticate itself, such as the **authentication realm, nonce, and algorithm**.
3. REGISTER request **with authentication credentials**:
```vbnet
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
Content-Length: 0
```
The UA sends another REGISTER request, this time including the **"Authorization" header with the necessary credentials, such as the username, realm, nonce, and a response value** calculated using the provided information and the user's password.
This is how the **Authorizarion response** is calculated:
```python
import hashlib
def calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop):
# 1. Calculate HA1 (concatenation of username, realm, and password)
ha1_input = f"{username}:{realm}:{password}"
ha1 = hashlib.md5(ha1_input.encode()).hexdigest()
# 2. Calculate HA2 (concatenation of method and uri)
ha2_input = f"{method}:{uri}"
ha2 = hashlib.md5(ha2_input.encode()).hexdigest()
# 3. Calculate the final response value (concatenation of h1, stuff and h2)
response_input = f"{ha1}:{nonce}:{nc}:{cnonce}:{qop}:{ha2}"
response = hashlib.md5(response_input.encode()).hexdigest()
return response
# Example usage
username = "alice"
password = "mysecretpassword"
realm = "example.com"
method = "REGISTER"
uri = "sip:example.com"
nonce = "abcdefghijk"
nc = "00000001"
cnonce = "lmnopqrst"
qop = "auth"
response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
print(f"MD5 response value: {response}")
```
4. **Successful registration** response from the registrar server:
```yaml
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0
```
After the registrar server verifies the provided credentials, **it sends a "200 OK" response to indicate that the registration was successful**. The response includes the registered contact information and the expiration time for the registration. At this point, the user agent (Alice) is successfully registered with the SIP registrar server, and incoming SIP requests for Alice can be routed to the appropriate contact address.
### Call Example
<figure><img src="../../../.gitbook/assets/image (666).png" alt=""><figcaption></figcaption></figure>
{% hint style="info" %}
It's not mentioned, but User B needs to have sent a **REGISTER message to Proxy 2** before he is able to receive calls.
{% endhint %}
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a><a href="https://twitter.com/carlospolopm"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
</details>