maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
hacktricks/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md

317 lines
21 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# SIP (Session Initiation Protocol)
{{#include ../../../banners/hacktricks-training.md}}
## Basiese Inligting
SIP (Session Initiation Protocol) is 'n **seinen- en oproepbeheerprotokol** wat wyd gebruik word vir die totstandbrenging, wysiging en beëindiging van multimedia-sessies, insluitend stem, video en instant messaging, oor IP-netwerke. Ontwikkel deur die **Internet Engineering Task Force (IETF)**, is SIP gedefinieer in **RFC 3261** en het dit die de-facto standaard vir VoIP en verenigde kommunikasie geword.
Sommige sleutelkenmerke van SIP sluit in:
1. **Teksgebaseerde Protokol**: SIP is 'n teksgebaseerde protokol, wat dit mensleesbaar maak en makliker om te debug. Dit is gebaseer op 'n versoek-antwoord model, soortgelyk aan HTTP, en gebruik metodes soos INVITE, ACK, BYE, en CANCEL vir die beheer van oproepsessies.
2. **Skalbaarheid en Buigsaamheid**: SIP is hoogs skaalbaar en kan in klein skaal ontplooiings sowel as groot onderneming- en carrier-grade omgewings gebruik word. Dit kan maklik met nuwe funksies uitgebrei word, wat dit aanpasbaar maak by verskeie gebruiksgevalle en vereistes.
3. **Interoperabiliteit**: SIP se wydverspreide aanneming en standaardisering verseker beter interoperabiliteit tussen verskillende toestelle, toepassings en diensverskaffers, wat naatlose kommunikasie oor verskeie platforms bevorder.
4. **Modulêre Ontwerp**: SIP werk saam met ander protokolle soos **RTP (Real-time Transport Protocol)** vir media-oordrag en **SDP (Session Description Protocol)** vir die beskrywing van multimedia-sessies. Hierdie modulêre ontwerp laat groter buigsaamheid en versoenbaarheid met verskillende media-tipes en codecs toe.
5. **Proxy- en Redirect-bedieners**: SIP kan proxy- en redirect-bedieners gebruik om oproeprigting te fasiliteer en gevorderde funksies soos oproep-vooruitsending, oproep-oordrag en voicemail-dienste te bied.
6. **Presence en Instant Messaging**: SIP is nie beperk tot stem- en video-kommunikasie nie. Dit ondersteun ook presence en instant messaging, wat 'n wye verskeidenheid verenigde kommunikasie-toepassings moontlik maak.
Ten spyte van sy vele voordele, kan SIP kompleks wees om te konfigureer en te bestuur, veral wanneer NAT-traversal en firewall-kwessies hanteer moet word. Sy veelsydigheid, skalbaarheid en uitgebreide ondersteuning in die bedryf maak dit egter 'n gewilde keuse vir VoIP en multimedia-kommunikasie.
### SIP Metodes
Die kern SIP-metodes wat in **RFC 3261** gedefinieer is sluit in:
1. **INVITE**: Word gebruik om 'n **nuwe sessie (oproep) te begin** of 'n bestaande een te wysig. Die INVITE-metode dra die sessiebeskrywing (gewoonlik met SDP) om die ontvanger in te lig oor die besonderhede van die voorgestelde sessie, soos media-tipes, codecs en vervoerprotokolle.
2. **ACK**: Gestuur om die **ontvangs van 'n finale reaksie** op 'n INVITE-versoek te bevestig. Die ACK-metode verseker die betroubaarheid van INVITE-transaksies deur end-tot-end erkenning te bied.
3. **BYE**: Word gebruik om 'n **opgestelde sessie (oproep) te beëindig**. Die BYE-metode word deur enige van die partye in die sessie gestuur om aan te dui dat hulle die kommunikasie wil beëindig.
4. **CANCEL**: Gestuur om 'n **hangende INVITE** versoek te kanselleer voordat die sessie tot stand gebring is. Die CANCEL-metode laat die sender toe om 'n INVITE-transaksie te staak as hulle van plan verander of as daar geen reaksie van die ontvanger is nie.
5. **OPTIONS**: Word gebruik om **die vermoëns van 'n SIP-bediener of user agent te navraag**. Die OPTIONS-metode kan gestuur word om inligting te versoek oor ondersteunde metodes, media-tipes of ander uitbreidings sonder om werklik 'n sessie te vestig.
6. **REGISTER**: Word deur 'n user agent gebruik om **sy huidige ligging by 'n SIP registrar server te registreer**. Die REGISTER-metode help om 'n op-datum kartering tussen 'n gebruiker se SIP URI en hul huidige IP-adres te handhaaf, wat oproeprigting en aflewering moontlik maak.
> [!WARNING]
> Let daarop dat om iemand te bel dit **nie noodsaaklik is om die REGISTER** vir enigiets te gebruik nie.\
> Dit is egter moontlik dat om 'n **INVITE** uit te voer die roeper eers moet **authentikeer**, anders sal hy 'n **`401 Unauthorized`** reaksie ontvang.
Benewens hierdie kernmetodes is daar **verskeie SIP-uitbreidingsmetodes** in ander RFC's gedefinieer, soos:
1. **SUBSCRIBE**: Gedefinieer in RFC 6665, die SUBSCRIBE-metode word gebruik om **kennisgewings te versoek** oor die toestand van 'n spesifieke hulpbron, soos 'n gebruiker se presence of oproepstatus.
2. **NOTIFY**: Ook gedefinieer in RFC 6665, die NOTIFY-metode word deur 'n bediener gestuur om **'n ingeskrewe user agent in te lig** oor veranderinge in die toestand van 'n gemonitorde hulpbron.
3. **REFER**: Gedefinieer in RFC 3515, die REFER-metode word gebruik om te **versoek dat die ontvanger 'n oordrag uitvoer of na 'n derde party verwys**. Dit word gewoonlik vir **oproep-oordrag** scenario's gebruik.
4. **MESSAGE**: Gedefinieer in RFC 3428, die MESSAGE-metode word gebruik om **instant messages tussen SIP user agents te stuur**, wat teksgebaseerde kommunikasie binne die SIP-raamwerk moontlik maak.
5. **UPDATE**: Gedefinieer in RFC 3311, die UPDATE-metode laat toe om **'n sessie te wysig sonder om die toestand van die bestaande dialoog te beïnvloed**. Dit is nuttig vir die bywerking van sessieparameters, soos codecs of media-tipes, tydens 'n voortgaande oproep.
6. **PUBLISH**: Gedefinieer in RFC 3903, die PUBLISH-metode word deur 'n user agent gebruik om **gebeurtenistoestand-inligting aan 'n bediener te publiseer**, waardeur dit beskikbaar gestel word aan ander belangstellendes.
### SIP Response Codes
- **1xx (Provisional Responses)**: Hierdie reaksies dui aan dat die versoek ontvang is, en die bediener is besig om dit verder te verwerk.
- 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)**: Hierdie reaksies dui aan dat die versoek suksesvol ontvang, verstaan en aanvaar is.
- 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)**: Hierdie reaksies dui aan dat verdere optrede benodig word om die versoek te vervul, tipies deur 'n alternatiewe hulpbron te kontak.
- 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)**: Hierdie reaksies dui aan dat die versoek slegte sintaksis bevat of nie deur die bediener vervul kan word nie.
- 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)**: Hierdie reaksies dui aan dat die bediener daarin misluk het om 'n geldige versoek te vervul.
- 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)**: Hierdie reaksies dui aan dat die versoek deur geen bediener vervul kan word nie.
- 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.
## Voorbeelde
### 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/8000
```
<details>
<summary>Elke Parameter Verduidelik</summary>
1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Hierdie reël dui die metode (INVITE), die versoek-URI (sip:[jdoe@example.com](mailto:jdoe@example.com)), en die SIP-weergawe (SIP/2.0) aan.
2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Die Via-kop spesifiseer die vervoersprotokol (UDP) en die kliënt se adres (pc33.example.com). Die "branch" parameter word gebruik vir lus-detectie en transaksie-ooreenstemming.
3. **Max-Forwards**: `Max-Forwards: 70` - Hierdie headerveld beperk die aantal kere wat die versoek deur proxies deurgegee kan word om oneindige lusse te voorkom.
4. **To**: `To: John Doe <sip:jdoe@example.com>` - Die To-kop dui die ontvanger van die oproep aan, insluitend hul vertoonnaam (John Doe) en SIP-URI (sip:[jdoe@example.com](mailto:jdoe@example.com)).
5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - Die From-kop spesifiseer die sender van die oproep, insluitend hul vertoonnaam (Jane Smith) en SIP-URI (sip:[jsmith@example.org](mailto:jsmith@example.org)). Die "tag" parameter word gebruik om die sender se rol in die dialoog uniek te identifiseer.
6. **Call-ID**: `Call-ID: a84b4c76e66710` - Die Call-ID-kop identifiseer 'n oproepsessie eenduidig tussen twee user agents.
7. **CSeq**: `CSeq: 314159 INVITE` - Die CSeq-kop bevat 'n volgnummer en die metode wat in die versoek gebruik is. Dit word gebruik om antwoorde aan versoeke te koppel en om boodskappe wat uit volgorde is, te ontdek.
8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - Die Contact-kop verskaf 'n direkte roete na die sender wat vir daaropvolgende versoeke en antwoorde gebruik kan word.
9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - Die User-Agent-kop verskaf inligting oor die sagteware of hardeware van die sender, insluitend sy naam en weergawe.
10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Die Allow-kop lys die SIP-metodes wat deur die sender ondersteun word. Dit help die ontvanger om te verstaan watter metodes tydens die kommunikasie gebruik kan word.
11. **Content-Type**: `Content-Type: application/sdp` - Die Content-Type-kop spesifiseer die mediatipe van die boodskapliggaam — in hierdie geval SDP (Session Description Protocol).
12. **Content-Length**: `Content-Length: 142` - Die Content-Length-kop dui die grootte van die boodskapliggaam in bytes aan.
13. **Message Body**: Die boodskapliggaam bevat die SDP-sessiebeskrywing, wat inligting oor media-tipes, codecs, en vervoersprotokolle vir die voorgestelde sessie insluit.
- `v=0` - Protokolweergawe (0 vir SDP)
- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Oorsprong en sessie-identifiseerder
- `s=-` - Sessie naam ('n enkele koppelteken dui geen sessienaam aan)
- `c=IN IP4 pc33.example.com` - Konneksie-inligting (netwerk tipe, adres tipe en adres)
- `t=0 0` - Tydsinligting (begin- en eindtye; 0 0 beteken die sessie is nie begrens nie)
- `m=audio 49170 RTP/AVP 0` - Media beskrywing (media tipe, poortnommer, vervoersprotokol, en formaatlys). In hierdie geval spesifiseer dit 'n audio-stroom wat RTP/AVP (Real-time Transport Protocol / Audio Video Profile) en formaat 0 (PCMU/8000) gebruik.
- `a=rtpmap:0 PCMU/8000` - Attribuut wat die formaat (0) aan die codec (PCMU) en sy klokfrekwensie (8000 Hz) koppel.
</details>
### SIP REGISTER Voorbeeld
Die REGISTER-metode word in Session Initiation Protocol (SIP) gebruik om 'n user agent (UA), soos 'n VoIP-foon of 'n softphone, in staat te stel om **sy ligging by 'n SIP registrar server te registreer**. Hierdie proses laat die bediener weet **waarheen inkomende SIP-versoeke wat vir die geregistreerde gebruiker bedoel is, gerouteer moet word**. Die registrar server is gewoonlik deel van 'n SIP proxy server of 'n toegewyde registrasie-bediener.
Hier is 'n gedetailleerde voorbeeld van die SIP-boodskappe wat betrokke is by 'n REGISTER-verifikasieproses:
1. Aanvanklike **REGISTER** versoek van UA na die 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
```
Hierdie aanvanklike REGISTER-boodskap word deur die UA (Alice) na die registrar-bediener gestuur. Dit sluit belangrike inligting in soos die verlangde registrasieduur (Expires), die gebruiker se SIP URI (sip:[alice@example.com](mailto:alice@example.com)), en die gebruiker se kontakadres (sip:alice@192.168.1.100:5060).
2. **401 Unauthorized** antwoord van die registrar-bediener:
```
SIP/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
```
Die registrar-bediener reageer met '401 Unauthorized' boodskap, wat 'WWW-Authenticate' header insluit. Hierdie header bevat inligting wat nodig is vir die UA om homself te verifieer, soos die **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
```
Die UA stuur nog 'n REGISTER request, hierdie keer met die **"Authorization" header wat die nodige credentials bevat, soos die username, realm, nonce en 'n response value** wat bereken word met die verskafte inligting en die gebruiker se wagwoord.
So word die **Authorization response** soos volg bereken:
```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. **Suksesvolle registrasie** respons vanaf die registrar-bediener:
```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="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>
> [!TIP]
> Dit word nie genoem nie, maar User B moet eers 'n **REGISTER message to Proxy 2** gestuur het voordat hy oproepe kan ontvang.
---
## SIP Security and Pentesting Notes
Hierdie afdeling voeg praktiese, protokol-spesifieke wenke by sonder om die breër VoIP-riglyne te dupliseer. Vir end-to-end VoIP attacking methodology, tools and scenarios, sien:
{{#ref}}
../README.md
{{#endref}}
### Fingerprinting and Discovery
- Send an OPTIONS request and review `Allow`, `Supported`, `Server` and `User-Agent` headers to fingerprint devices and stacks:
```bash
# nmap NSE (UDP 5060 by default)
sudo nmap -sU -p 5060 --script sip-methods <target>
# Minimal raw OPTIONS over UDP
printf "OPTIONS sip:<target> SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: <sip:probe@attacker>;tag=1\r\nTo: <sip:probe@<target>>\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: <sip:probe@attacker>\r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 <target> 5060
```
### Username/Extension Enumeration Behavior
- Enumeration typically abuses differences between `401/407` vs `404/403` on `REGISTER`/`INVITE`. Maak bedieners sodat hulle uniform reageer.
- Asterisk chan_sip: set `alwaysauthreject=yes` (general) to avoid disclosing valid users. In newer Asterisk (PJSIP), guest calling is disabled unless an `anonymous` endpoint is defined and similar "always auth reject" behavior is the default; still enforce network ACLs and fail2ban at the perimeter.
### SIP Digest Authentication: algorithms and cracking
- SIP commonly uses HTTP-Digest style auth. Historically MD5 (and MD5-sess) are prevalent; newer stacks support SHA-256 and SHA-512/256 per RFC 8760. Prefer these stronger algorithms in modern deployments and disable MD5 when possible.
- Offline cracking from a pcap is trivial for MD5 digests. After extracting the challenge/response, you can use hashcat mode 11400 (SIP digest, MD5):
```bash
# Example hash format (single line)
# username:realm:method:uri:nonce:cnonce:nc:qop:response
echo 'alice:example.com:REGISTER:sip:example.com:abcdef:11223344:00000001:auth:65a8e2285879283831b664bd8b7f14d4' > sip.hash
# Crack with a wordlist
hashcat -a 0 -m 11400 sip.hash /path/to/wordlist.txt
```
> [!NOTE]
> RFC 8760 defines SHA-256 and SHA-512/256 for HTTP Digest (used by SIP). Adoption is uneven; ensure your tools handle these when targeting modern PBXs.
### SIP over TLS (SIPS) and over WebSockets
- Signaling encryption:
- `sips:` URIs and TCP/TLS typically on 5061. Verify certificate validation on endpoints; many accept self-signed or wildcard certs, enabling MitM in weak deployments.
- WebRTC softphones often use SIP over WebSocket per RFC 7118 (`ws://` or `wss://`). If the PBX exposes WSS, test authentication and CORS, and ensure rate limits are enforced on the HTTP front end as well.
### DoS quick checks (protocol level)
- Flooding INVITE, REGISTER or malformed messages can exhaust transaction processing.
- Simple rate-limiting example for UDP/5060 (Linux iptables hashlimit):
```bash
# Limit new SIP packets from a single IP to 20/s with burst 40
iptables -A INPUT -p udp --dport 5060 -m hashlimit \
--hashlimit-name SIP --hashlimit 20/second --hashlimit-burst 40 \
--hashlimit-mode srcip -j ACCEPT
iptables -A INPUT -p udp --dport 5060 -j DROP
```
### Recent, relevant SIP-stack CVE to watch (Asterisk PJSIP)
- CVE-2024-35190 (published May 17, 2024): In specific Asterisk releases, `res_pjsip_endpoint_identifier_ip` could misidentify unauthorized SIP requests as a local endpoint, potentially enabling unauthorized actions or information exposure. Fixed in 18.23.1, 20.8.1 and 21.3.1. Validate your PBX version when testing and report responsibly.
### Hardening checklist (SIP-specific)
- Prefer TLS for signaling and SRTP/DTLS-SRTP for media; disable cleartext where feasible.
- Enforce strong passwords and digest algorithms (SHA-256/512-256 where supported; avoid MD5).
- For Asterisk:
- chan_sip: `alwaysauthreject=yes`, `allowguest=no`, per-endpoint `permit`/`deny` CIDR ACLs.
- PJSIP: do not create an `anonymous` endpoint unless needed; enforce endpoint `acl`/`media_acl`; enable fail2ban or equivalent.
- Topology hiding on SIP proxies (e.g., outbound proxy/edge SBC) to reduce information leakage.
- Strict `OPTIONS` handling and rate limits; disable unused methods (e.g., `MESSAGE`, `PUBLISH`) if not required.
## References
- RFC 8760 – Using SHA-256 and SHA-512/256 for HTTP Digest (applies to SIP Digest too): https://www.rfc-editor.org/rfc/rfc8760
- Asterisk GHSA advisory for CVE-2024-35190: https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9
{{#include ../../../banners/hacktricks-training.md}}
Reference in New Issue View Git Blame Copy Permalink