Add content from: Research Update: Enhanced src/network-services-pentesting/pe...

- Remove searchindex.js (auto-generated file)
This commit is contained in:
HackTricks News Bot 2025-09-08 01:33:25 +00:00
parent 6eb10b90f9
commit a75a3e08fa
2 changed files with 89 additions and 8 deletions

File diff suppressed because one or more lines are too long

View File

@ -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.
---
## 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}}