SIP (Session Initiation Protocol)

Reading time: 16 minutes

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Основна інформація

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

Основні методи SIP, визначені в RFC 3261, включають:

  1. INVITE: Використовується для ініціювання нової сесії (дзвінка) або зміни існуючої. Метод INVITE несе опис сесії (зазвичай за допомогою SDP), щоб інформувати отримувача про деталі пропонованої сесії, такі як типи медіа, кодеки та транспортні протоколи.
  2. ACK: Надсилається для підтвердження отримання остаточної відповіді на запит INVITE. Метод ACK забезпечує надійність транзакцій INVITE, надаючи підтвердження від кінця до кінця.
  3. BYE: Використовується для завершення встановленої сесії (дзвінка). Метод BYE надсилається будь-якою з сторін у сесії, щоб вказати на бажання завершити зв'язок.
  4. CANCEL: Надсилається для скасування очікуваного INVITE запиту до встановлення сесії. Метод CANCEL дозволяє відправнику припинити транзакцію INVITE, якщо він передумає або якщо немає відповіді від отримувача.
  5. OPTIONS: Використовується для запиту можливостей SIP сервера або user agent. Метод OPTIONS може бути надісланий для отримання інформації про підтримувані методи, типи медіа або інші розширення без фактичного встановлення сесії.
  6. REGISTER: Використовується user agent для реєстрації свого поточного місцезнаходження на SIP registrar server. Метод REGISTER допомагає підтримувати актуальне відображення між SIP URI користувача та його поточною IP-адресою, дозволяючи маршрутизацію та доставку дзвінків.

warning

Зверніть увагу, що для здійснення дзвінка необов'язково використовувати REGISTER для чогось.\
Однак можливо, що для виконання INVITE абоненту спочатку потрібно аутентифікуватися, інакше він отримає 401 Unauthorized відповідь.

Окрім цих основних методів, існує кілька розширень SIP, визначених в інших RFC, таких як:

  1. SUBSCRIBE: Визначений у RFC 6665, метод SUBSCRIBE використовується для запиту сповіщень про стан конкретного ресурсу, наприклад присутності користувача або статусу виклику.
  2. NOTIFY: Також визначений у RFC 6665, метод NOTIFY надсилається сервером для інформування підписаного user agent про зміни в стані монітореного ресурсу.
  3. REFER: Визначений у RFC 3515, метод REFER використовується для запиту, щоб отримувач виконав передачу або перенаправив на третю сторону. Це зазвичай використовується для сценаріїв переведення виклику.
  4. MESSAGE: Визначений у RFC 3428, метод MESSAGE використовується для відправки миттєвих повідомлень між SIP user agents, що дозволяє текстову комунікацію в межах SIP.
  5. UPDATE: Визначений у RFC 3311, метод UPDATE дозволяє змінювати сесію без впливу на стан існуючого діалогу. Це корисно для оновлення параметрів сесії, таких як кодеки або типи медіа, під час поточного дзвінка.
  6. PUBLISH: Визначений у RFC 3903, метод PUBLISH використовується user agent для публікації інформації про стан подій на сервері, роблячи її доступною для інших зацікавлених сторін.

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
Пояснення кожного параметра
  1. Request-Line: INVITE sip:jdoe@example.com SIP/2.0 - Цей рядок вказує метод (INVITE), URI запиту (sip:jdoe@example.com) та версію SIP (SIP/2.0).
  2. Via: Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds - Заголовок Via вказує протокол транспорту (UDP) та адресу клієнта (pc33.example.com). Параметр "branch" використовується для виявлення циклів і співставлення транзакцій.
  3. Max-Forwards: Max-Forwards: 70 - Це поле заголовка обмежує кількість переадресацій запиту проксі, щоб уникнути нескінченних циклів.
  4. To: To: John Doe <sip:jdoe@example.com> - Заголовок To вказує отримувача дзвінка, включаючи його відображуване ім'я (John Doe) та SIP URI (sip:jdoe@example.com).
  5. From: From: Jane Smith <sip:jsmith@example.org>;tag=1928301774 - Заголовок From вказує відправника дзвінка, включаючи його відображуване ім'я (Jane Smith) та SIP URI (sip:jsmith@example.org). Параметр "tag" використовується для унікальної ідентифікації ролі відправника в діалозі.
  6. Call-ID: Call-ID: a84b4c76e66710 - Заголовок Call-ID унікально ідентифікує сеанс дзвінка між двома агентами користувача.
  7. CSeq: CSeq: 314159 INVITE - Заголовок CSeq містить номер послідовності та метод, який використовується в запиті. Він використовується для співставлення відповідей із запитами та виявлення повідомлень, що надійшли не в порядку.
  8. Contact: Contact: <sip:jsmith@pc33.example.com> - Заголовок Contact надає прямий маршрут до відправника, який може використовуватися для наступних запитів і відповідей.
  9. User-Agent: User-Agent: ExampleSIPClient/1.0 - Заголовок User-Agent містить інформацію про програмне або апаратне забезпечення відправника, включаючи його назву та версію.
  10. Allow: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO - Заголовок Allow перераховує SIP-методи, які підтримуються відправником. Це допомагає отримувачу зрозуміти, які методи можна використовувати під час зв'язку.
  11. Content-Type: Content-Type: application/sdp - Заголовок Content-Type вказує тип медіа тіла повідомлення, у цьому випадку SDP (Session Description Protocol).
  12. Content-Length: Content-Length: 142 - Заголовок Content-Length вказує розмір тіла повідомлення в байтах.
  13. Message Body: Тіло повідомлення містить опис сесії SDP, який включає інформацію про типи медіа, кодеки та протоколи транспорту для пропонованої сесії.
  • v=0 - Версія протоколу (0 для SDP)
  • o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com - Ініціатор і ідентифікатор сесії
  • s=- - Назва сесії (один дефіс означає відсутність назви сесії)
  • c=IN IP4 pc33.example.com - Інформація про з'єднання (тип мережі, тип адреси та адреса)
  • t=0 0 - Інформація про час (час початку і завершення, 0 0 означає, що сесія не обмежена)
  • m=audio 49170 RTP/AVP 0 - Опис медіа (тип медіа, номер порту, транспортний протокол і список форматів). В цьому випадку вказано аудіопотік з використанням RTP/AVP (Real-time Transport Protocol / Audio Video Profile) і форматом 0 (PCMU/8000).
  • a=rtpmap:0 PCMU/8000 - Атрибут, що відображає формат (0) на кодек (PCMU) та його частоту дискретизації (8000 Гц).

Приклад SIP REGISTER

Метод REGISTER використовується в Протоколі ініціації сесії (SIP), щоб дозволити агенту користувача (UA), наприклад VoIP-телефону або софтфону, зареєструвати своє місцезнаходження на сервері реєстрації SIP. Цей процес дає серверу знати куди направляти вхідні SIP-запити, призначені для зареєстрованого користувача. Сервер реєстрації зазвичай є частиною SIP proxy-сервера або виділеного сервера реєстрації.

Ось детальний приклад SIP-повідомлень, що беруть участь у процесі автентифікації REGISTER:

  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

Це початкове повідомлення REGISTER відправляється UA (Alice) до реєстраційного сервера. Воно містить важливу інформацію, таку як бажана тривалість реєстрації (Expires), SIP URI користувача (sip:alice@example.com) та контактна адреса користувача (sip:alice@192.168.1.100:5060).

  1. 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 для автентифікації, наприклад realm аутентифікації, nonce та алгоритм.

  1. REGISTER request з обліковими даними для автентифікації:
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

UA надсилає ще один REGISTER request, цього разу включаючи "Authorization" header з необхідними обліковими даними, такими як username, realm, nonce та response value, які обчислюються за допомогою наданої інформації та пароля користувача.

Ось як обчислюється Authorization response:

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}")
  1. Успішна реєстрація — відповідь від реєстраційного сервера:
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

Після того як registrar server перевіряє надані облікові дані, він надсилає відповідь "200 OK", щоб вказати, що реєстрація пройшла успішно. У відповіді міститься зареєстрована контактна інформація та час життя реєстрації. На цьому етапі user agent (Alice) успішно зареєстрований на SIP registrar server, і вхідні SIP-запити для Alice можна маршрутизувати до відповідної контактної адреси.

Call Example

tip

Це не вказано вище, але User B повинен був надіслати REGISTER message to Proxy 2 перед тим, як він зміг би приймати дзвінки.


SIP Security and Pentesting Notes

Цей розділ додає практичні, специфічні для протоколу поради без дублювання ширшого VoIP керівництва. Для методології атак end-to-end на VoIP, інструментів та сценаріїв дивіться:

Pentesting VoIP

Fingerprinting and Discovery

  • Надішліть OPTIONS запит і перегляньте заголовки Allow, Supported, Server та User-Agent, щоб fingerprint пристроїв та стеків:
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

  • Перерахування зазвичай зловживає відмінностями між відповідями 401/407 та 404/403 на REGISTER/INVITE. Закріпіть сервери, щоб вони відповідали однорідно.
  • Asterisk chan_sip: встановіть alwaysauthreject=yes (загалом), щоб уникати розкриття дійсних користувачів. У новіших версіях Asterisk (PJSIP) гостьові дзвінки вимкнені, якщо не визначено anonymous endpoint, а подібна поведінка "always auth reject" є за замовчуванням; все ж застосовуйте мережеві ACL та fail2ban на периметрі.

SIP Digest Authentication: algorithms and cracking

  • SIP зазвичай використовує HTTP-Digest стиль аутентифікації. Історично переважали MD5 (і MD5-sess); новіші стекі підтримують SHA-256 та SHA-512/256 згідно RFC 8760. Впроваджуйте сильніші алгоритми в сучасних розгортаннях та вимикайте MD5, коли це можливо.
  • Офлайн-крейкінг з pcap тривіальний для MD5 digest. Після витягання challenge/response ви можете використати 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 визначає SHA-256 та SHA-512/256 для HTTP Digest (також застосовується до SIP Digest). Рівень впровадження непостійний; переконайтеся, що ваші інструменти підтримують ці алгоритми при тестуванні сучасних PBX.

SIP over TLS (SIPS) and over WebSockets

  • Шифрування сигналінгу:
  • sips: URI та TCP/TLS зазвичай на 5061. Перевіряйте валідацію сертифікатів на кінцевих точках; багато пристроїв приймають self-signed або wildcard сертифікати, що робить можливим MitM у слабких розгортаннях.
  • WebRTC softphones часто використовують SIP over WebSocket згідно RFC 7118 (ws:// або wss://). Якщо PBX відкриває WSS, перевіряйте аутентифікацію і CORS, і забезпечте, що на HTTP фронтенді також застосовані ліміти швидкості.

DoS quick checks (protocol level)

  • Flooding INVITE, REGISTER або malformed повідомлення можуть вичерпати обробку транзакцій.
  • Простий приклад rate-limiting для 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): У певних випусках Asterisk res_pjsip_endpoint_identifier_ip міг помилково ідентифікувати неавторизовані SIP-запити як локальну кінцеву точку, що потенційно дозволяло неавторизовані дії або розкриття інформації. Виправлено в 18.23.1, 20.8.1 та 21.3.1. Перевіряйте версію вашого PBX під час тестування та відповідально звітуйте.

Hardening checklist (SIP-specific)

  • Віддавайте перевагу TLS для сигналінгу та SRTP/DTLS-SRTP для медіа; вимикайте cleartext де це можливо.
  • Запровадьте сильні паролі та алгоритми digest (SHA-256/512-256 де підтримується; уникайте MD5).
  • Для Asterisk:
  • chan_sip: alwaysauthreject=yes, allowguest=no, per-endpoint permit/deny CIDR ACLs.
  • PJSIP: не створюйте anonymous endpoint без потреби; запровадьте endpoint acl/media_acl; увімкніть fail2ban або еквівалент.
  • Topology hiding на SIP proxies (наприклад, outbound proxy/edge SBC) щоб зменшити information leakage.
  • Жорстке оброблення OPTIONS та ліміти швидкості; вимикайте непотрібні методи (наприклад, 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 Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks