SIP (Session Initiation Protocol)

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

• 구독 계획 확인하기!
• **💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

기본 정보

SIP (Session Initiation Protocol)은 IP 네트워크 상에서 음성, 비디오, 인스턴트 메시징을 포함한 멀티미디어 세션을 설정, 수정 및 종료하는 데 널리 사용되는 신호 및 통화 제어 프로토콜입니다. **Internet Engineering Task Force (IETF)**에서 개발되었으며, SIP는 RFC 3261에 정의되어 VoIP 및 통합 커뮤니케이션의 사실상 표준이 되었습니다.

SIP의 주요 특징은 다음과 같습니다:

1. 텍스트 기반 프로토콜: SIP는 텍스트 기반 프로토콜로 사람이 읽기 쉽고 디버깅하기 용이합니다. HTTP와 유사한 요청-응답 모델을 기반으로 하며, INVITE, ACK, BYE, CANCEL 등의 메서드를 사용해 통화 세션을 제어합니다.
2. 확장성과 유연성: SIP는 높은 확장성을 가지며 소규모 배포부터 대규모 엔터프라이즈 및 통신사업자급 환경까지 사용할 수 있습니다. 새로운 기능으로 쉽게 확장할 수 있어 다양한 사용 사례와 요구사항에 적응할 수 있습니다.
3. 상호운용성: SIP의 광범위한 채택과 표준화는 다양한 장치, 애플리케이션, 서비스 제공자 간의 더 나은 상호운용성을 보장하여 다양한 플랫폼 간의 원활한 통신을 촉진합니다.
4. 모듈형 설계: SIP는 미디어 전송을 위한 RTP (Real-time Transport Protocol) 및 멀티미디어 세션을 설명하기 위한 SDP (Session Description Protocol) 등 다른 프로토콜과 함께 작동합니다. 이 모듈형 설계는 다양한 미디어 유형과 코덱과의 호환성을 높이고 유연성을 제공합니다.
5. 프록시 및 리다이렉트 서버: SIP는 프록시 및 리다이렉트 서버를 사용하여 통화 라우팅을 용이하게 하며, 착신전환, 통화 전달, 음성사서함과 같은 고급 기능을 제공합니다.
6. 프레즌스 및 인스턴트 메시징: SIP는 음성 및 비디오 통신에 국한되지 않습니다. 프레즌스 및 인스턴트 메시징을 지원하여 다양한 통합 커뮤니케이션 애플리케이션을 가능하게 합니다.

많은 장점에도 불구하고, SIP는 NAT 통과 및 방화벽 문제를 다룰 때 특히 구성 및 관리가 복잡할 수 있습니다. 그러나 그 범용성, 확장성 및 업계 전반의 광범위한 지원으로 인해 VoIP 및 멀티미디어 통신에 인기 있는 선택입니다.

SIP 메서드

RFC 3261에 정의된 핵심 SIP 메서드는 다음과 같습니다:

1. INVITE: 새 세션(통화)을 시작하거나 기존 세션을 수정하는 데 사용됩니다. INVITE 메서드는 제안된 세션의 세부사항(일반적으로 SDP 사용)을 전달하여 수신자에게 미디어 유형, 코덱 및 전송 프로토콜과 같은 정보를 알립니다.
2. ACK: INVITE 요청에 대한 최종 응답의 수신을 확인하기 위해 전송됩니다. ACK 메서드는 종단 간 확인을 제공하여 INVITE 트랜잭션의 신뢰성을 보장합니다.
3. BYE: 확립된 세션(통화)을 종료하는 데 사용됩니다. BYE 메서드는 세션의 어느 쪽이든 통화를 종료하려는 의사를 표시하기 위해 전송됩니다.
4. CANCEL: 세션이 성립되기 전에 보류 중인 INVITE 요청을 취소하기 위해 전송됩니다. CANCEL 메서드는 발신자가 마음을 바꾸거나 수신자로부터 응답이 없는 경우 INVITE 트랜잭션을 중단할 수 있게 합니다.
5. OPTIONS: SIP 서버 또는 사용자 에이전트의 기능을 질의하는 데 사용됩니다. OPTIONS 메서드는 실제로 세션을 성립하지 않고도 지원되는 메서드, 미디어 유형 또는 기타 확장에 대한 정보를 요청할 수 있습니다.
6. REGISTER: 사용자 에이전트가 SIP 레지스트라 서버에 현재 위치를 등록하는 데 사용됩니다. REGISTER 메서드는 사용자의 SIP URI와 현재 IP 주소 간의 최신 매핑을 유지하여 통화 라우팅 및 전달을 가능하게 합니다.

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.

이 핵심 메서드들 외에도 RFC 등 다른 문서들에 정의된 여러 SIP 확장 메서드가 있습니다:

1. SUBSCRIBE: RFC 6665에 정의된 SUBSCRIBE 메서드는 사용자의 프레즌스나 통화 상태와 같은 특정 리소스의 상태에 대한 알림을 요청하는 데 사용됩니다.
2. NOTIFY: 역시 RFC 6665에 정의된 NOTIFY 메서드는 서버가 구독한 사용자 에이전트에게 모니터링 중인 리소스 상태의 변경을 통지하기 위해 전송합니다.
3. REFER: RFC 3515에 정의된 REFER 메서드는 수신자에게 전달을 수행하거나 제3자를 참조하도록 요청하는 데 사용됩니다. 주로 통화 전달 시나리오에서 사용됩니다.
4. MESSAGE: RFC 3428에 정의된 MESSAGE 메서드는 SIP 사용자 에이전트 간에 인스턴트 메시지를 전송하는 데 사용되어 SIP 프레임워크 내에서 텍스트 기반 통신을 가능하게 합니다.
5. UPDATE: RFC 3311에 정의된 UPDATE 메서드는 기존 대화의 상태에 영향을 주지 않고 세션을 수정할 수 있게 합니다. 이는 진행 중인 통화 중에 코덱이나 미디어 유형과 같은 세션 매개변수를 업데이트하는 데 유용합니다.
6. PUBLISH: RFC 3903에 정의된 PUBLISH 메서드는 사용자 에이전트가 서버에 이벤트 상태 정보를 게시하여 다른 관심 있는 당사자들이 이용할 수 있게 합니다.

SIP 응답 코드

• 1xx (임시 응답): 이러한 응답은 요청이 수신되었고 서버가 계속 처리 중임을 나타냅니다.
• 100 Trying: 요청이 수신되었으며 서버가 작업 중입니다.
• 180 Ringing: 피호출자에게 알림이 가고 있으며 통화를 받을 준비를 하고 있습니다.
• 183 Session Progress: 통화의 진행 상황에 대한 정보를 제공합니다.
• 2xx (성공 응답): 이러한 응답은 요청이 성공적으로 수신, 이해 및 수락되었음을 나타냅니다.
• 200 OK: 요청이 성공적으로 처리되었습니다.
• 202 Accepted: 요청이 처리용으로 수락되었지만 아직 완료되지는 않았습니다.
• 3xx (리다이렉션 응답): 이러한 응답은 요청을 완료하기 위해 추가 조치가 필요함을 나타내며, 일반적으로 다른 리소스에 연락해야 함을 의미합니다.
• 300 Multiple Choices: 사용 가능한 여러 옵션이 있으며 사용자나 클라이언트가 하나를 선택해야 합니다.
• 301 Moved Permanently: 요청된 리소스가 새로운 영구 URI로 할당되었습니다.
• 302 Moved Temporarily: 요청된 리소스가 임시로 다른 URI에서 사용 가능합니다.
• 305 Use Proxy: 요청은 지정된 프록시로 전송되어야 합니다.
• 4xx (클라이언트 오류 응답): 이러한 응답은 요청에 잘못된 구문이 포함되었거나 서버가 요청을 이행할 수 없음을 나타냅니다.
• 400 Bad Request: 요청이 잘못되었거나 유효하지 않습니다.
• 401 Unauthorized: 요청에 사용자 인증이 필요합니다.
• 403 Forbidden: 서버는 요청을 이해했지만 이를 이행하기를 거부합니다.
• 404 Not Found: 요청된 리소스를 서버에서 찾을 수 없습니다.
• 408 Request Timeout: 서버가 기다릴 준비가 된 시간 내에 완전한 요청을 수신하지 못했습니다.
• 486 Busy Here: 피호출자가 현재 바빠서 전화를 받을 수 없습니다.
• 5xx (서버 오류 응답): 이러한 응답은 서버가 유효한 요청을 이행하지 못했음을 나타냅니다.
• 500 Internal Server Error: 서버가 요청을 처리하는 동안 오류가 발생했습니다.
• 501 Not Implemented: 서버가 요청을 이행하는 데 필요한 기능을 지원하지 않습니다.
• 503 Service Unavailable: 서버가 유지보수나 과부하로 인해 현재 요청을 처리할 수 없습니다.
• 6xx (전역 실패 응답): 이러한 응답은 네트워크의 어떤 서버도 요청을 이행할 수 없음을 나타냅니다.
• 600 Busy Everywhere: 통화를 위한 가능한 모든 목적지가 바쁩니다.
• 603 Decline: 피호출자가 통화에 참여하고 싶어하지 않습니다.
• 604 Does Not Exist Anywhere: 요청된 리소스가 네트워크 어디에도 존재하지 않습니다.

예제

SIP INVITE 예제

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

SIP REGISTER 예제

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:

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

이 초기 REGISTER 메시지는 UA (Alice)가 레지스트라 서버로 전송합니다. 이 메시지에는 원하는 등록 기간 (Expires), 사용자의 SIP URI (sip:alice@example.com), 그리고 사용자의 연락처 주소 (sip:alice@192.168.1.100:5060)와 같은 중요한 정보가 포함되어 있습니다.

2. 레지스트라 서버로부터의 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
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

레지스트라 서버는 “401 Unauthorized” 응답을 반환하며, 이 응답에는 “WWW-Authenticate” 헤더가 포함됩니다. 이 헤더는 UA가 자신을 인증하는 데 필요한 정보를 포함하며, 예를 들어 authentication realm, nonce, and algorithm 등이 있습니다.

3. REGISTER 요청 with authentication credentials:

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

UA는 또 다른 REGISTER 요청을 보냅니다. 이번에는 제공된 정보와 사용자의 비밀번호를 사용해 계산된 사용자 이름(username), realm, nonce 및 응답값(response value)과 같은 필요한 자격 증명을 포함한 “Authorization” header를 포함합니다.

다음은 Authorization response가 계산되는 방법입니다:

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. 성공적인 등록 응답 (레지스트라 서버로부터):

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

등록 서버가 제공된 자격 증명을 확인한 후, 등록이 성공했음을 알리기 위해 “200 OK” 응답을 전송합니다. 응답에는 등록된 contact 정보와 등록의 만료 시간이 포함됩니다. 이 시점에서 user agent (Alice)는 SIP registrar server에 성공적으로 등록되며, Alice로 향하는 들어오는 SIP 요청은 적절한 contact 주소로 라우팅될 수 있습니다.

Call Example

Tip

언급되지는 않았지만, User B는 전화를 받을 수 있기 전에 REGISTER message to Proxy 2 를 보냈어야 합니다.

SIP Security and Pentesting Notes

이 섹션은 더 광범위한 VoIP 가이드라인을 중복하지 않으면서 실용적이고 프로토콜에 특화된 팁을 추가합니다. 종단간 VoIP 공격 방법론, 도구 및 시나리오에 대해서는 다음을 참조하십시오:

Pentesting VoIP

Fingerprinting and Discovery

• OPTIONS 요청을 전송하고 Allow, Supported, Server 및 User-Agent 헤더를 검토하여 장치와 스택을 fingerprint 합니다:

# 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

• 열거는 일반적으로 REGISTER/INVITE에서 401/407 대 404/403의 차이를 악용합니다. 서버가 균일하게 응답하도록 하여 노출을 방지하세요.
• Asterisk chan_sip: 일반 설정으로 alwaysauthreject=yes 를 설정하여 유효한 사용자를 노출하지 않도록 하세요. 최신 Asterisk(PJSIP)에서는 anonymous endpoint가 정의되지 않는 한 guest calling이 비활성화되어 있고 유사한 “always auth reject” 동작이 기본이지만, 여전히 네트워크 ACL과 perimeter에서의 fail2ban 적용을 강제하세요.

SIP Digest Authentication: algorithms and cracking

• SIP는 일반적으로 HTTP-Digest 스타일 인증을 사용합니다. 역사적으로 MD5(및 MD5-sess)가 널리 사용되었고; 최신 스택은 RFC 8760에 따라 SHA-256 및 SHA-512/256을 지원합니다. 최신 배포에서는 이러한 더 강력한 알고리즘을 우선 사용하고 가능한 경우 MD5를 비활성화하세요.
• pcap에서의 오프라인 크래킹은 MD5 다이제스트에 대해 매우 쉽습니다. challenge/response를 추출한 후 hashcat 모드 11400 (SIP digest, MD5)을 사용할 수 있습니다:

# 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은 HTTP Digest(또는 SIP Digest)에 대해 SHA-256 및 SHA-512/256을 정의합니다. 채택 상황은 균일하지 않습니다; 최신 PBX를 대상으로 할 때 도구들이 이를 처리하는지 확인하세요.

SIP over TLS (SIPS) and over WebSockets

• Signaling encryption:
• sips: URI와 TCP/TLS는 일반적으로 포트 5061을 사용합니다. 엔드포인트에서의 인증서 검증을 확인하세요; 많은 장비가 self-signed 또는 wildcard cert를 허용하여 약한 배포에서는 MitM이 가능해집니다.
• WebRTC softphones는 종종 RFC 7118에 따라 SIP over WebSocket (ws:// 또는 wss://)을 사용합니다. PBX가 WSS를 노출하는 경우 인증 및 CORS를 테스트하고 HTTP 프론트엔드에서도 rate limit이 적용되는지 확인하세요.

DoS quick checks (protocol level)

• INVITE, REGISTER 또는 malformed 메시지 플러딩은 트랜잭션 처리를 소모시킬 수 있습니다.
• UDP/5060에 대한 간단한 rate-limiting 예시(Linux iptables hashlimit):

# 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): 특정 Asterisk 릴리스에서 res_pjsip_endpoint_identifier_ip가 무단 SIP 요청을 로컬 엔드포인트로 잘못 식별할 수 있어 무단 동작 또는 정보 노출을 초래할 수 있습니다. 18.23.1, 20.8.1 및 21.3.1에서 수정되었습니다. 테스트 시 PBX 버전을 검증하고 책임감 있게 보고하세요.

Hardening checklist (SIP-specific)

• 신호(Signaling)는 TLS를 우선 사용하고 미디어에는 SRTP/DTLS-SRTP를 사용하세요; 가능한 경우 평문(cleartext)을 비활성화하세요.
• 강력한 비밀번호와 다이제스트 알고리즘(SHA-256/512-256 지원 시; MD5는 피함)을 적용하세요.
• Asterisk의 경우:
• chan_sip: alwaysauthreject=yes, allowguest=no, 엔드포인트별 permit/deny CIDR ACL 설정.
• PJSIP: 필요하지 않다면 anonymous endpoint를 생성하지 마세요; endpoint acl/media_acl을 강제하고 fail2ban 또는 동등한 것을 활성화하세요.
• 정보 누출(leak)을 줄이기 위해 SIP 프록시(예: outbound proxy/edge SBC)에서 토폴로지 숨기기(topology hiding)를 적용하세요.
• 엄격한 OPTIONS 처리 및 rate limit; 필요하지 않은 메서드(예: MESSAGE, PUBLISH)는 비활성화하세요.

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

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

• 구독 계획 확인하기!
• **💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.