Research Update Enhanced src/network-services-pentesting/pen...

src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md

@@ -95,7 +95,7 @@ s=-
 c=IN IP4 pc33.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
-a=rtpmap:0 PCMU/8000te
+a=rtpmap:0 PCMU/8000
 ```
 
 <details>
@@ -151,8 +151,8 @@ This initial REGISTER message is sent by the UA (Alice) to the registrar server.
 
 2. **401 Unauthorized** response from the registrar server:
 
-```css
-cssCopy codeSIP/2.0 401 Unauthorized
+```
+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
@@ -182,7 +182,7 @@ 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:
+This is how the **Authorization response** is calculated:
 
 ```python
 import hashlib
@@ -240,7 +240,89 @@ After the registrar server verifies the provided credentials, **it sends a "200
 > [!TIP]
 > It's not mentioned, but User B needs to have sent a **REGISTER message to Proxy 2** before he is able to receive calls.
 
-{{#include ../../../banners/hacktricks-training.md}}
 
 
+---
+
+## SIP Security and Pentesting Notes
+
+This section adds practical, protocol-specific tips without duplicating the broader VoIP guidance. For end-to-end VoIP attacking methodology, tools and scenarios, see:
+
+{{#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`. Harden servers to reply uniformly.
+  - 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}}