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

# SIP (Session Initiation Protocol)

{{#include ../../../banners/hacktricks-training.md}}

## Βασικές Πληροφορίες

SIP (Session Initiation Protocol) είναι ένα πρωτόκολλο σηματοδότησης και ελέγχου κλήσεων που χρησιμοποιείται ευρέως για την εγκαθίδρυση, τροποποίηση και τερματισμό multimedia συνεδριών, συμπεριλαμβανομένης της φωνής, του βίντεο και του instant messaging, πάνω από δίκτυα IP. Αναπτύχθηκε από το **Internet Engineering Task Force (IETF)**, το SIP ορίζεται στο **RFC 3261** και έχει γίνει το de facto πρότυπο για VoIP και unified communications.

Κάποιες βασικές δυνατότητες του SIP περιλαμβάνουν:

1. **Text-based Protocol**: Το SIP είναι ένα πρωτόκολλο βάσει κειμένου, το οποίο το καθιστά αναγνώσιμο από ανθρώπους και ευκολότερο στο debugging. Βασίζεται σε μοντέλο request-response, παρόμοιο με το HTTP, και χρησιμοποιεί μεθόδους όπως INVITE, ACK, BYE και CANCEL για τον έλεγχο των call sessions.
2. **Scalability and Flexibility**: Το SIP είναι ιδιαίτερα κλιμακώσιμο και μπορεί να χρησιμοποιηθεί τόσο σε μικρής κλίμακας εγκαταστάσεις όσο και σε μεγάλα enterprise και carrier-grade περιβάλλοντα. Μπορεί να επεκταθεί εύκολα με νέες δυνατότητες, καθιστώντας το προσαρμόσιμο σε διάφορα use cases και απαιτήσεις.
3. **Interoperability**: Η ευρεία υιοθέτηση και τυποποίηση του SIP εξασφαλίζει καλύτερη διαλειτουργικότητα μεταξύ διαφορετικών συσκευών, εφαρμογών και παρόχων υπηρεσιών, προωθώντας ομαλή επικοινωνία σε διάφορες πλατφόρμες.
4. **Modular Design**: Το SIP συνεργάζεται με άλλα πρωτόκολλα όπως **RTP (Real-time Transport Protocol)** για τη μετάδοση μέσων και **SDP (Session Description Protocol)** για την περιγραφή multimedia συνεδριών. Αυτός ο modular σχεδιασμός επιτρέπει μεγαλύτερη ευελιξία και συμβατότητα με διαφορετικούς τύπους μέσων και codecs.
5. **Proxy and Redirect Servers**: Το SIP μπορεί να χρησιμοποιεί proxy και redirect servers για να διευκολύνει το routing κλήσεων και να παρέχει προηγμένες λειτουργίες όπως call forwarding, call transfer και voicemail υπηρεσίες.
6. **Presence and Instant Messaging**: Το SIP δεν περιορίζεται στη φωνή και το βίντεο. Υποστηρίζει επίσης presence και instant messaging, επιτρέποντας ένα ευρύ φάσμα εφαρμογών unified communication.

Παρά τα πολλά του πλεονεκτήματα, το SIP μπορεί να είναι περίπλοκο στην παραμετροποίηση και διαχείριση, ειδικά όταν αντιμετωπίζονται θέματα NAT traversal και firewall. Ωστόσο, η ευελιξία, η κλιμάκωση και η εκτεταμένη υποστήριξη του στη βιομηχανία το καθιστούν δημοφιλή επιλογή για VoIP και multimedia επικοινωνία.

### SIP Methods

Οι βασικές μέθοδοι SIP που ορίζονται στο **RFC 3261** περιλαμβάνουν:

1. **INVITE**: Χρησιμοποιείται για να **ξεκινήσει μια νέα συνεδρία (κλήση)** ή να τροποποιήσει μια υπάρχουσα. Η μέθοδος INVITE μεταφέρει την περιγραφή της συνεδρίας (συνήθως χρησιμοποιώντας SDP) για να ενημερώσει τον παραλήπτη σχετικά με τις λεπτομέρειες της προτεινόμενης συνεδρίας, όπως τύπους μέσων, codecs και πρωτόκολλα μεταφοράς.
2. **ACK**: Αποστέλλεται για να **επιβεβαιώσει την παραλαβή** μιας τελικής απάντησης σε ένα INVITE request. Η μέθοδος ACK εξασφαλίζει την αξιοπιστία των INVITE transactions παρέχοντας end-to-end acknowledgement.
3. **BYE**: Χρησιμοποιείται για να **τερματίσει μια καθιερωμένη συνεδρία (κλήση)**. Η μέθοδος BYE αποστέλλεται από οποιοδήποτε μέρος της συνεδρίας για να υποδείξει ότι επιθυμεί να τερματίσει την επικοινωνία.
4. **CANCEL**: Αποστέλλεται για να **ακυρώσει ένα εκκρεμές INVITE** request πριν η συνεδρία εγκαθιδρυθεί. Η μέθοδος CANCEL επιτρέπει στον αποστολέα να διακόψει μια INVITE συναλλαγή εάν αλλάξει γνώμη ή δεν υπάρχει απάντηση από τον παραλήπτη.
5. **OPTIONS**: Χρησιμοποιείται για να **ερωτήσει τις δυνατότητες ενός SIP server ή user agent**. Η μέθοδος OPTIONS μπορεί να σταλεί για να ζητήσει πληροφορίες σχετικά με υποστηριζόμενες μεθόδους, τύπους μέσων ή άλλες επεκτάσεις χωρίς στην πραγματικότητα να εγκαθιδρύσει συνεδρία.
6. **REGISTER**: Χρησιμοποιείται από έναν user agent για να **καταχωρήσει την τρέχουσα τοποθεσία του σε έναν SIP registrar server**. Η μέθοδος REGISTER βοηθά στη διατήρηση ενός ενημερωμένου mapping μεταξύ του SIP URI ενός χρήστη και της τρέχουσας IP διεύθυνσής του, επιτρέποντας το routing και την παράδοση κλήσεων.

> [!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.

Εκτός από αυτές τις βασικές μεθόδους, υπάρχουν **διάφορες επεκτάσεις SIP** που ορίζονται σε άλλα RFC, όπως:

1. **SUBSCRIBE**: Ορισμένη στο RFC 6665, η μέθοδος SUBSCRIBE χρησιμοποιείται για να **ζητήσει ειδοποιήσεις** σχετικά με την κατάσταση ενός συγκεκριμένου πόρου, όπως την presence ενός χρήστη ή την κατάσταση μιας κλήσης.
2. **NOTIFY**: Επίσης ορισμένη στο RFC 6665, η μέθοδος NOTIFY αποστέλλεται από έναν server για να **ενημερώσει έναν subscribed user agent** για αλλαγές στην κατάσταση ενός παρακολουθούμενου πόρου.
3. **REFER**: Ορισμένη στο RFC 3515, η μέθοδος REFER χρησιμοποιείται για να **ζητήσει από τον παραλήπτη να εκτελέσει μια μεταφορά ή να αναφέρεται σε τρίτο μέρος**. Αυτό χρησιμοποιείται συνήθως σε σενάρια call transfer.
4. **MESSAGE**: Ορισμένη στο RFC 3428, η μέθοδος MESSAGE χρησιμοποιείται για να **αποστείλει instant messages μεταξύ SIP user agents**, επιτρέποντας επικοινωνία βάσει κειμένου εντός του πλαισίου SIP.
5. **UPDATE**: Ορισμένη στο RFC 3311, η μέθοδος UPDATE επιτρέπει την **τροποποίηση μιας συνεδρίας χωρίς να επηρεάζεται η κατάσταση του υπάρχοντος dialog**. Αυτό είναι χρήσιμο για ενημερώσεις παραμέτρων συνεδρίας, όπως codecs ή τύπους μέσων, κατά τη διάρκεια μιας ενεργής κλήσης.
6. **PUBLISH**: Ορισμένη στο RFC 3903, η μέθοδος PUBLISH χρησιμοποιείται από έναν user agent για να **δημοσιοποιήσει πληροφορίες κατάστασης γεγονότων σε έναν server**, καθιστώντας τες διαθέσιμες σε άλλα ενδιαφερόμενα μέρη.

### SIP Response Codes

- **1xx (Provisional Responses)**: Αυτές οι απαντήσεις υποδεικνύουν ότι το request λήφθηκε και ο server συνεχίζει να το επεξεργάζεται.
- 100 Trying: Το request λήφθηκε και ο server εργάζεται πάνω σε αυτό.
- 180 Ringing: Ο καλούμενος ειδοποιείται και θα απαντήσει στην κλήση.
- 183 Session Progress: Παρέχει πληροφορίες σχετικά με την πρόοδο της κλήσης.
- **2xx (Successful Responses)**: Αυτές οι απαντήσεις υποδεικνύουν ότι το request λήφθηκε επιτυχώς, κατανοήθηκε και έγινε αποδεκτό.
- 200 OK: Το request ήταν επιτυχές και ο server το εκπλήρωσε.
- 202 Accepted: Το request έγινε αποδεκτό για επεξεργασία, αλλά δεν έχει ολοκληρωθεί ακόμα.
- **3xx (Redirection Responses)**: Αυτές οι απαντήσεις υποδεικνύουν ότι απαιτείται περαιτέρω ενέργεια για την εκπλήρωση του request, συνήθως επικοινωνώντας με έναν εναλλακτικό πόρο.
- 300 Multiple Choices: Υπάρχουν πολλαπλές διαθέσιμες επιλογές και ο χρήστης ή ο client πρέπει να επιλέξει μία.
- 301 Moved Permanently: Ο ζητούμενος πόρος έχει ανατεθεί σε νέο μόνιμο URI.
- 302 Moved Temporarily: Ο ζητούμενος πόρος είναι προσωρινά διαθέσιμος σε διαφορετικό URI.
- 305 Use Proxy: Το request πρέπει να σταλεί σε καθορισμένο proxy.
- **4xx (Client Error Responses)**: Αυτές οι απαντήσεις υποδεικνύουν ότι το request περιέχει κακή σύνταξη ή δεν μπορεί να εκπληρωθεί από τον server.
- 400 Bad Request: Το request ήταν παραμορφωμένο ή άκυρο.
- 401 Unauthorized: Το request απαιτεί authentication χρήστη.
- 403 Forbidden: Ο server κατανόησε το request αλλά αρνείται να το εκπληρώσει.
- 404 Not Found: Ο ζητούμενος πόρος δεν βρέθηκε στον server.
- 408 Request Timeout: Ο server δεν έλαβε ένα πλήρες request εντός του χρόνου που ήταν διατεθειμένος να περιμένει.
- 486 Busy Here: Ο καλούμενος είναι αυτήν τη στιγμή απασχολημένος και δεν μπορεί να δεχτεί την κλήση.
- **5xx (Server Error Responses)**: Αυτές οι απαντήσεις υποδεικνύουν ότι ο server απέτυχε να εκπληρώσει ένα έγκυρο request.
- 500 Internal Server Error: Ο server αντιμετώπισε σφάλμα κατά την επεξεργασία του request.
- 501 Not Implemented: Ο server δεν υποστηρίζει τη λειτουργικότητα που απαιτείται για να εκπληρώσει το request.
- 503 Service Unavailable: Ο server αυτή τη στιγμή δεν μπορεί να χειριστεί το request λόγω συντήρησης ή υπερφόρτωσης.
- **6xx (Global Failure Responses)**: Αυτές οι απαντήσεις υποδεικνύουν ότι το request δεν μπορεί να εκπληρωθεί από κανέναν server.
- 600 Busy Everywhere: Όλοι οι πιθανοί προορισμοί για την κλήση είναι απασχολημένοι.
- 603 Decline: Ο καλούμενος δεν επιθυμεί να συμμετάσχει στην κλήση.
- 604 Does Not Exist Anywhere: Ο ζητούμενος πόρος δεν είναι διαθέσιμος πουθενά στο δίκτυο.

## Παραδείγματα

### SIP INVITE Example
```
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
```
<details>

<summary>Επεξήγηση κάθε παραμέτρου</summary>

1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Αυτή η γραμμή υποδεικνύει τη μέθοδο (INVITE), το URI αιτήματος (sip:[jdoe@example.com](mailto:jdoe@example.com)) και την έκδοση SIP (SIP/2.0).
2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Το header Via καθορίζει το πρωτόκολλο μεταφοράς (UDP) και τη διεύθυνση του client (pc33.example.com). Η παράμετρος "branch" χρησιμοποιείται για ανίχνευση βρόχου και ταύτιση transaction.
3. **Max-Forwards**: `Max-Forwards: 70` - Αυτό το πεδίο header περιορίζει τον αριθμό φορτώσεων του αιτήματος από proxies για να αποφευχθούν άπειροι βρόχοι.
4. **To**: `To: John Doe <sip:jdoe@example.com>` - Το header To καθορίζει τον παραλήπτη της κλήσης, περιλαμβάνοντας το εμφανιζόμενο όνομα (John Doe) και το SIP URI (sip:[jdoe@example.com](mailto:jdoe@example.com)).
5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - Το header From καθορίζει τον αποστολέα της κλήσης, περιλαμβάνοντας το εμφανιζόμενο όνομα (Jane Smith) και το SIP URI (sip:[jsmith@example.org](mailto:jsmith@example.org)). Η παράμετρος "tag" χρησιμοποιείται για μοναδική αναγνώριση του ρόλου του αποστολέα στο dialog.
6. **Call-ID**: `Call-ID: a84b4c76e66710` - Το Call-ID header αναγνωρίζει μοναδικά μια συνεδρία κλήσης μεταξύ δύο user agents.
7. **CSeq**: `CSeq: 314159 INVITE` - Το header CSeq περιέχει έναν αριθμό ακολουθίας και τη μέθοδο που χρησιμοποιήθηκε στο αίτημα. Χρησιμοποιείται για ταύτιση απαντήσεων με αιτήματα και για ανίχνευση μηνυμάτων εκτός σειράς.
8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - Το header Contact παρέχει μια άμεση διαδρομή προς τον αποστολέα, η οποία μπορεί να χρησιμοποιηθεί για επόμενα αιτήματα και απαντήσεις.
9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - Το header User-Agent δίνει πληροφορίες για το λογισμικό ή το υλικό του αποστολέα, συμπεριλαμβανομένου του ονόματος και της έκδοσής του.
10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Το header Allow απαριθμεί τις SIP μεθόδους που υποστηρίζονται από τον αποστολέα. Αυτό βοηθά τον παραλήπτη να κατανοήσει ποιες μεθόδους μπορούν να χρησιμοποιηθούν κατά τη διάρκεια της επικοινωνίας.
11. **Content-Type**: `Content-Type: application/sdp` - Το header Content-Type καθορίζει τον τύπο μέσου (media type) του σώματος του μηνύματος, σε αυτή την περίπτωση SDP (Session Description Protocol).
12. **Content-Length**: `Content-Length: 142` - Το header Content-Length υποδεικνύει το μέγεθος του σώματος του μηνύματος σε bytes.
13. **Message Body**: Το σώμα του μηνύματος περιέχει την περιγραφή συνεδρίας SDP, η οποία περιλαμβάνει πληροφορίες για τους τύπους μέσων, τους codecs και τα πρωτόκολλα μεταφοράς για την προτεινόμενη συνεδρία.

- `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` - Περιγραφή μέσου (τύπος μέσου, αριθμός θύρας, πρωτόκολλο μεταφοράς και λίστα φορμάτων). Σε αυτή την περίπτωση, δηλώνει ροή audio που χρησιμοποιεί RTP/AVP και format 0 (PCMU/8000).
- `a=rtpmap:0 PCMU/8000` - Attribute που αντιστοιχεί το format (0) με τον codec (PCMU) και το ρυθμό ρολογιού του (8000 Hz).

</details>

### Παράδειγμα SIP REGISTER

Η μέθοδος REGISTER χρησιμοποιείται στο Session Initiation Protocol (SIP) για να επιτρέψει σε έναν user agent (UA), όπως ένα VoIP phone ή ένα softphone, να **καταχωρήσει την τοποθεσία του σε έναν SIP registrar server**. Αυτή η διαδικασία επιτρέπει στον server να γνωρίζει **πού να δρομολογεί τα εισερχόμενα SIP αιτήματα που προορίζονται για τον καταχωρημένο χρήστη**. Ο registrar server συνήθως αποτελεί μέρος ενός SIP proxy server ή ενός αφιερωμένου registration server.

Ακολουθεί ένα λεπτομερές παράδειγμα των SIP μηνυμάτων που εμπλέκονται στη διαδικασία πιστοποίησης REGISTER:

1. Αρχικό **REGISTER** αίτημα από τον UA προς τον 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) στον registrar server. Περιλαμβάνει σημαντικές πληροφορίες, όπως την επιθυμητή διάρκεια εγγραφής (Expires), το SIP URI του χρήστη (sip:[alice@example.com](mailto:alice@example.com)) και τη διεύθυνση επαφής του χρήστη (sip:alice@192.168.1.100:5060).

2. **401 Unauthorized** απάντηση από τον registrar server:
```
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
```
Ο registrar server απαντά με ένα μήνυμα "401 Unauthorized", το οποίο περιλαμβάνει την κεφαλίδα "WWW-Authenticate". Αυτή η κεφαλίδα περιέχει πληροφορίες που απαιτούνται για να αυθεντικοποιηθεί ο UA, όπως το **realm αυθεντικοποίησης, nonce, και αλγόριθμος**.

3. 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}")
```
4. **Επιτυχής εγγραφή** απάντηση από τον registrar server:
```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" για να υποδείξει ότι η εγγραφή ήταν επιτυχής**. Η απάντηση περιλαμβάνει τις εγγεγραμμένες πληροφορίες contact και τον χρόνο λήξης για την εγγραφή. Σε αυτό το σημείο, ο user agent (Alice) είναι επιτυχώς εγγεγραμμένος στον SIP registrar server, και εισερχόμενα SIP requests για την Alice μπορούν να δρομολογηθούν στη κατάλληλη contact διεύθυνση.

### Call Example

<figure><img src="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>

> [!TIP]
> Δεν αναφέρεται, αλλά ο User B πρέπει να έχει στείλει ένα **REGISTER message to Proxy 2** πριν να μπορεί να λαμβάνει κλήσεις.



---

## SIP Security and Pentesting Notes

Αυτό το τμήμα προσθέτει πρακτικές, ειδικές για το πρωτόκολλο συμβουλές χωρίς να επαναλαμβάνει τη γενικότερη καθοδήγηση για VoIP. Για end-to-end VoIP attacking methodology, εργαλεία και σενάρια, δείτε:

{{#ref}}
../README.md
{{#endref}}

### Fingerprinting and Discovery

- Στείλτε ένα OPTIONS request και ελέγξτε τα headers `Allow`, `Supported`, `Server` και `User-Agent` για fingerprinting συσκευών και 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 συνήθως εκμεταλλεύεται διαφορές ανάμεσα σε `401/407` vs `404/403` σε `REGISTER`/`INVITE`. Σκληρύνετε τους servers ώστε να απαντούν ομοιόμορφα.
- Asterisk chan_sip: ρυθμίστε `alwaysauthreject=yes` (γενικά) για να αποφύγετε την αποκάλυψη έγκυρων χρηστών. Σε νεότερο Asterisk (PJSIP), το guest calling είναι απενεργοποιημένο εκτός εάν οριστεί ένα `anonymous` endpoint και παρόμοια "always auth reject" συμπεριφορά είναι η προεπιλογή· παρόλα αυτά επιβάλλετε network ACLs και fail2ban στο περίγραμμα.

### SIP Digest Authentication: algorithms and cracking

- Το SIP χρησιμοποιεί συνήθως HTTP-Digest τύπο auth. Ιστορικά το MD5 (και MD5-sess) είναι διαδεδομένο· νεότερα stacks υποστηρίζουν SHA-256 και SHA-512/256 σύμφωνα με το RFC 8760. Προτιμήστε αυτούς τους πιο ισχυρούς αλγόριθμους σε σύγχρονες αναπτύξεις και απενεργοποιήστε το MD5 όπου είναι δυνατό.
- Το offline cracking από ένα pcap είναι απλό για MD5 digests. Αφού εξαχθούν το 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 defines SHA-256 and SHA-512/256 for HTTP Digest (used by SIP). Η υιοθέτηση είναι ανομοιόμορφη· βεβαιωθείτε ότι τα εργαλεία σας υποστηρίζουν αυτές τις επιλογές όταν στοχεύετε σύγχρονους PBX.

### SIP over TLS (SIPS) and over WebSockets

- Κρυπτογράφηση signaling:
- Τα `sips:` URIs και TCP/TLS τυπικά στο 5061. Επαληθεύστε την επικύρωση πιστοποιητικών στα endpoints· πολλά δέχονται self-signed ή wildcard certs, επιτρέποντας MitM σε αδύναμες εγκαταστάσεις.
- Τα WebRTC softphones συχνά χρησιμοποιούν SIP πάνω από WebSocket σύμφωνα με το RFC 7118 (`ws://` ή `wss://`). Αν το PBX εκθέτει WSS, δοκιμάστε authentication και CORS, και βεβαιωθείτε ότι επιβάλλονται rate limits και στο HTTP front end.

### 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 requests ως τοπικό endpoint, ενδεχομένως επιτρέποντας μη εξουσιοδοτημένες ενέργειες ή αποκάλυψη πληροφοριών. Διορθώθηκε στις 18.23.1, 20.8.1 και 21.3.1. Επαληθεύστε την έκδοση του PBX όταν δοκιμάζετε και αναφέρετε υπεύθυνα.

### Hardening checklist (SIP-specific)

- Προτιμήστε TLS για signaling και SRTP/DTLS-SRTP για media· απενεργοποιήστε 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` και rate limits· απενεργοποιήστε μη χρησιμοποιούμενες μεθόδους (π.χ. `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
{{#include ../../../banners/hacktricks-training.md}}