SIP (Session Initiation Protocol)

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Якщо ви хочете побачити вашу компанію рекламовану в HackTricks або завантажити HackTricks у форматі PDF, перевірте ПЛАНИ ПІДПИСКИ!
Отримайте офіційний PEASS & HackTricks мерч
Дізнайтеся про Сім'ю PEASS, нашу колекцію ексклюзивних NFT
Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @carlospolopm.
Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв GitHub.

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

SIP (Session Initiation Protocol) - це сигнальний та керуючий протокол дзвінками, широко використовуваний для встановлення, зміни та завершення мультимедійних сеансів, включаючи голос, відео та миттєві повідомлення, через IP-мережі. Розроблений Internet Engineering Task Force (IETF), SIP визначений у RFC 3261 і став де-факто стандартом для VoIP та об'єднаних комунікацій.

Деякі ключові особливості SIP включають:

Текстовий протокол: SIP - це текстовий протокол, що робить його читабельним для людини та легким у відлагодженні. Він базується на моделі запит-відповідь, схожій на HTTP, та використовує методи, такі як INVITE, ACK, BYE та CANCEL для керування дзвінками.
Масштабованість та гнучкість: SIP дуже масштабовний і може використовуватися як у невеликих розгортаннях, так і в великих підприємствах та сервісних середовищах. Його легко розширювати новими функціями, що робить його адаптивним до різних випадків використання та вимог.
Інтероперабельність: Широке поширення та стандартизація SIP забезпечують кращу взаємодію між різними пристроями, додатками та постачальниками послуг, сприяючи безперервній комунікації на різних платформах.
Модульний дизайн: SIP працює з іншими протоколами, такими як RTP (Real-time Transport Protocol) для передачі медіа та SDP (Session Description Protocol) для опису мультимедійних сеансів. Цей модульний дизайн дозволяє більшу гнучкість та сумісність з різними типами медіа та кодеками.
Проксі та перенаправлення серверів: SIP може використовувати проксі та сервери перенаправлення для полегшення маршрутизації дзвінків та надання розширених функцій, таких як переадресація дзвінків, перенаправлення дзвінків та послуги голосової пошти.
Присутність та миттєві повідомлення: SIP не обмежується лише голосовим та відео зв'язком. Він також підтримує присутність та миттєві повідомлення, що дозволяє широкий спектр об'єднаних комунікаційних додатків.

Незважаючи на багато переваг, SIP може бути складним у налаштуванні та управлінні, особливо при роботі з проблемами NAT-переходу та брандмауерами. Однак його універсальність, масштабованість та широка підтримка у всій галузі роблять його популярним вибором для VoIP та мультимедійних комунікацій.

Методи SIP

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

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

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

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

SUBSCRIBE: Визначений у RFC 6665, метод SUBSCRIBE використовується для запиту сповіщень про стан конкретного ресурсу, такого як присутність користувача або статус дзвінка.
NOTIFY: Також визначений у RFC 6665, метод NOTIFY надсилається сервером для повідомлення підписаному агенту користувача про зміни у стані контрольованого ресурсу.
REFER: Визначений у RFC 3515, метод REFER використовується для запиту, щоб отримувач виконав перенаправлення або посилання на третю сторону. Це зазвичай використовується для сценаріїв перенаправлення дзвінків.
MESSAGE: Визначений у RFC 3428, метод MESSAGE використовується для надсилання миттєвих повідомлень між агентами користувача SIP, дозволяючи текстовий зв'язок в межах SIP-фреймворку.
UPDATE: Визначений у RFC 3311, метод UPDATE дозволяє змінювати сеанс без впливу на стан існуючого діалогу. Це корисно для оновлення параметрів сеансу, таких як кодеки або типи медіа, під час тривалого дзвінка.
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: Особа, яку викликають, за

Приклади

Приклад 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/8000te

Кожен параметр пояснено

Request-Line: INVITE sip:jdoe@example.com SIP/2.0 - Цей рядок вказує метод (INVITE), запит URI (sip:jdoe@example.com), та версію SIP (SIP/2.0).
Via: Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds - Заголовок Via вказує протокол передачі (UDP) та адресу клієнта (pc33.example.com). Параметр "branch" використовується для виявлення петель та відповідності транзакцій.
Max-Forwards: Max-Forwards: 70 - Це поле заголовка обмежує кількість разів, які запит може бути пересланий проксі для уникнення безкінечних петель.
To: To: John Doe <sip:jdoe@example.com> - Заголовок To вказує отримувача дзвінка, включаючи їх відображене ім'я (John Doe) та SIP URI (sip:jdoe@example.com).
From: From: Jane Smith <sip:jsmith@example.org>;tag=1928301774 - Заголовок From вказує відправника дзвінка, включаючи їх відображене ім'я (Jane Smith) та SIP URI (sip:jsmith@example.org). Параметр "tag" використовується для унікальної ідентифікації ролі відправника в діалозі.
Call-ID: Call-ID: a84b4c76e66710 - Заголовок Call-ID унікально ідентифікує сеанс дзвінка між двома агентами користувача.
CSeq: CSeq: 314159 INVITE - Заголовок CSeq містить номер послідовності та метод, використаний у запиті. Він використовується для відповідей на запити та виявлення повідомлень, що надходять не в порядку.
Contact: Contact: <sip:jsmith@pc33.example.com> - Заголовок Contact надає прямий маршрут до відправника, який може бути використаний для наступних запитів та відповідей.
User-Agent: User-Agent: ExampleSIPClient/1.0 - Заголовок User-Agent надає інформацію про програмне забезпечення або апаратне забезпечення відправника, включаючи його назву та версію.
Allow: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO - Заголовок Allow перелічує підтримувані методи SIP відправника. Це допомагає отримувачу зрозуміти, які методи можна використовувати під час зв'язку.
Content-Type: Content-Type: application/sdp - Заголовок Content-Type вказує медіа-тип тіла повідомлення, у цьому випадку, SDP (Протокол опису сеансу).
Content-Length: Content-Length: 142 - Заголовок Content-Length вказує розмір тіла повідомлення в байтах.
Тіло повідомлення: Тіло повідомлення містить опис сеансу 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 (Протокол реального часу / Профіль аудіо-відео) та формат 0 (PCMU/8000).
a=rtpmap:0 PCMU/8000 - Атрибут, що відображає формат (0) на кодек (PCMU) та його частоту дискретизації (8000 Гц).

Приклад реєстрації SIP

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

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

Початковий запит REGISTER від UA до сервера реєстрації:

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 (Аліса) на сервер реєстрації. Воно містить важливу інформацію, таку як бажаний термін реєстрації (Expires), SIP URI користувача (sip:alice@example.com), та контактну адресу користувача (sip:alice@192.168.1.100:5060).

Відповідь 401 Unauthorized від сервера реєстрації:

cssCopy codeSIP/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 для автентифікації, таку як область аутентифікації, nonce та алгоритм.

Запит REGISTER з аутентифікаційними обліковими даними:

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, на цей раз включаючи заголовок "Authorization" з необхідними обліковими даними, такими як ім'я користувача, область, nonce та значення відповіді, розраховане за наданими даними та паролем користувача.

Ось як розраховується відповідь авторизації:

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}")

Успішна реєстрація відповідь від сервера реєстратора:

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" для підтвердження успішної реєстрації. У відповіді міститься зареєстрована контактна інформація та час закінчення реєстрації. На цьому етапі агент користувача (Аліса) успішно зареєстрований на сервері реєстрації SIP, і вхідні запити SIP для Аліси можуть бути маршрутизовані на відповідну контактну адресу.

Приклад дзвінка

Не зазначено, але користувачу B потрібно було відправити повідомлення REGISTER на Proxy 2, перш ніж він зможе отримувати дзвінки.

PreviousBasic VoIP Protocols NextPentesting Remote GdbServer

Last updated 1 month ago