Lỗi NULL pointer dereference trong xác minh STIR/SHAKEN của Asterisk gây từ chối dịch vụ từ xa

Asterisk là một bộ công cụ tổng đài riêng và viễn thông mã nguồn mở. Trong các phiên bản đến và bao gồm 18.26.2, từ 20.00.0 đến 20.15.0, 20.7-cert6, 21.00.0, từ 22.00.0 đến 22.5.0, tồn tại điều kiện DoS từ xa và RCE có thể xảy ra trong asterisk/res/res_stir_shaken /verification.c có thể bị khai thác khi kẻ tấn công có thể đặt một Identity header tùy ý, hoặc khi STIR/SHAKEN được bật với Verification được cấu hình trong SIP profile gắn với endpoint bị tấn công. Lỗi này được sửa trong các phiên bản 18.26.3, 20.7-cert6, 20.15.1, 21.10.1 và 22.5.1.

• Asterisk < 18.26.3 bị ảnh hưởng; bản sửa tương ứng là 18.26.3.
• Asterisk >= 20.00.0, < 20.15.1 bị ảnh hưởng; bản sửa tương ứng là 20.15.1.
• Asterisk >= 21.00.0, < 21.10.1 bị ảnh hưởng; bản sửa tương ứng là 21.10.1.
• Asterisk >= 22.00.0, < 22.5.1 bị ảnh hưởng; bản sửa tương ứng là 22.5.1.
• Nhánh certified >= 20.7-cert6, < 20.7-cert7 bị ảnh hưởng; advisory của nhà cung cấp xác định bản sửa là 20.7-cert7.
• Có mâu thuẫn giữa mô tả nguồn được cung cấp, trong đó ghi 20.7-cert6 là bản sửa, và dữ liệu affected có cấu trúc cùng advisory của CNA, trong đó xác định 20.7-cert7 là bản patched. Khi xử lý nhánh certified, nên ưu tiên dữ liệu affected và advisory của CNA.

Thành phần bị ảnh hưởng là asterisk/res/res_stir_shaken /verification.c, trong luồng xác minh STIR/SHAKEN. Mã nguồn tìm dấu chấm phẩy trong Identity header bằng strchr. Nếu phần bắt buộc của header không có dấu chấm phẩy, con trỏ trả về có thể là NULL, nhưng mã vẫn tính len bằng phép trừ con trỏ này với ctx->identity_hdr. Giá trị không hợp lệ sau đó được dùng cho ast_malloc() và memcpy(), có thể làm Asterisk bị crash; advisory của nhà cung cấp đánh giá rằng RCE cũng có thể xảy ra, nhưng không xác nhận đây là kết quả có thể khai thác một cách đáng tin cậy. Điều kiện khai thác yêu cầu endpoint bị ảnh hưởng có xác minh STIR/SHAKEN được bật trong SIP profile và attacker có thể đưa một Identity header tùy ý vào luồng xử lý. Chi tiết còn thiếu là mức độ kiểm soát ổn định đối với hậu quả bộ nhớ sau lỗi, vì vậy không nên coi RCE là đã được chứng minh.

Lỗ hổng có thể bị tiếp cận qua mạng khi endpoint Asterisk liên quan có thể nhận lưu lượng SIP từ attacker. Điều kiện khai thác được nêu là attacker có thể đặt một Identity header tùy ý, hoặc STIR/SHAKEN được bật với Verification được cấu hình trong SIP profile gắn với endpoint bị tấn công. Hồ sơ đánh giá cho biết cần quyền hạn thấp, không cần tương tác người dùng và độ phức tạp khai thác thấp. Advisory của nhà cung cấp có kèm proof of concept, và record đánh dấu có public exploit. Bằng chứng hiện có không xác lập rằng lỗ hổng đã được khai thác trong thực tế; DoS là hậu quả được chứng minh, còn RCE vẫn được mô tả là có thể xảy ra.

Hậu quả kỹ thuật chính là làm mất tính sẵn sàng của tiến trình hoặc dịch vụ Asterisk khi xử lý một Identity header không phù hợp. Việc tính độ dài từ con trỏ NULL rồi sử dụng giá trị đó trong cấp phát bộ nhớ và sao chép dữ liệu có thể dẫn đến crash; advisory cũng nêu khả năng RCE, nhưng chưa chứng minh RCE là kết quả có thể kiểm soát ổn định. Tác động được giới hạn trực tiếp ở thành phần Asterisk bị xử lý, và bằng chứng hiện có không xác nhận việc thay đổi dữ liệu hoặc truy cập dữ liệu bí mật. Về tổ chức, hệ thống thoại có thể bị gián đoạn và cần failover hoặc khôi phục dịch vụ nếu endpoint bị khai thác lặp lại.

• Một request SIP được tạo phù hợp có thể làm tiến trình Asterisk crash hoặc mất ổn định, gây gián đoạn xử lý cuộc gọi và làm giảm tính sẵn sàng của dịch vụ thoại.
• Nếu hậu quả bộ nhớ có thể bị kiểm soát vượt qua việc gây crash, RCE có thể mở rộng tác động từ gián đoạn dịch vụ sang xâm phạm máy chủ, nhưng advisory không xác nhận một đường khai thác RCE ổn định.
• Tác động trực tiếp đã được chứng minh là lên availability của Asterisk. Bằng chứng hiện có không xác lập việc lộ dữ liệu hoặc sửa đổi dữ liệu.

1. Nâng cấp Asterisk theo đúng nhánh đang sử dụng: lên 18.26.3, 20.15.1, 21.10.1, 22.5.1 hoặc 20.7-cert7 tương ứng. Không suy ra rằng bản sửa của một nhánh tự động bao phủ các nhánh khác.
2. Xác nhận sau nâng cấp rằng gói hoặc build đang chạy thực sự thuộc bản đã sửa, đặc biệt với nhánh certified và các bản phân phối đóng gói lại.
3. Nếu chưa thể nâng cấp ngay, lập tức xác định các SIP profile bật STIR/SHAKEN Verification và các endpoint mà nguồn không tin cậy có thể tiếp cận. Việc tắt hoặc hạn chế tạm thời luồng xác minh đó có thể giảm bề mặt tấn công nếu phù hợp với yêu cầu vận hành, nhưng record và advisory không cung cấp một workaround được xác nhận chính thức.
4. Sau khi cập nhật hoặc thay đổi cấu hình, kiểm tra lại khả năng nhận cuộc gọi, xác minh STIR/SHAKEN và log lỗi của res_stir_shaken.

• Lập inventory các hệ thống chạy Asterisk, gồm cả các nhánh certified, rồi đối chiếu phiên bản cài đặt với các mốc đã được sửa trong advisory.
• Kiểm tra cấu hình SIP profile để xác định STIR/SHAKEN có được bật hay không và Verification có áp dụng cho các endpoint có thể nhận lưu lượng từ nguồn không tin cậy hay không.
• Xác định liệu attacker từ mạng liên quan có thể kiểm soát Identity header trước khi header đi vào luồng xác minh hay không.
• Rà soát log và crash report có chứa res_stir_shaken/verification.c, ast_stir_shaken_vs_verify, lỗi cấp phát bộ nhớ cho encoded JWT hoặc dấu hiệu segfault.
• Việc không tìm thấy các log này không chứng minh hệ thống an toàn; cần kết hợp kiểm tra cấu hình, khả năng truy cập và phiên bản.