- Trong quá trình kiểm tra mã nguồn mở viễn thông sau vụ xâm nhập Salt Typhoon, người ta phát hiện một lỗi tràn bộ đệm không cần xác thực trong thư viện XMLRPC được đóng gói kèm FreeSWITCH
- Lỗ hổng phát sinh từ đoạn mã ghi Request URI do kẻ tấn công cung cấp vào biến stack 4096 byte bằng
sprintf(), và tách biệt với giới hạn của trình duyệt, có thể gửi yêu cầu dài hơn 4096 ký tự - SignalWire trả lời rằng 3 PR sửa lỗi đã được công khai trên GitHub vào tháng 2/2025, nhưng cho biết bản phát hành mới của FreeSWITCH Community không được lên kế hoạch cho đến mùa hè 2025
- Trên Shodan có khoảng 8.300 kết quả tìm kiếm FreeSWITCH, và những đơn vị vận hành không có thẻ phát hành phải tự ứng phó bằng cách build từ mã nguồn hoặc chặn bằng tường lửa
- Trường hợp này cho thấy rủi ro của bảo mật viễn thông không chỉ nằm ở bản thân lỗ hổng mà còn gia tăng ở quản lý lỗ hổng và phản ứng phát hành; ngay cả sau khi CVE-2025-44087 được gán vào ngày 30/4/2025, FreeSWITCH vẫn chưa có bản phát hành
Cơ duyên xem xét FreeSWITCH sau Salt Typhoon
- Cuối năm 2024, tin tức rằng nhóm Salt Typhoon, được cho là có liên hệ với chính phủ Trung Quốc, đã xâm nhập T-Mobile và các nhà mạng khác là điểm khởi đầu
- Không thể trực tiếp điều tra mạng của nhà mạng di động, nhưng trên GitHub có nhiều dự án mã nguồn mở liên quan đến viễn thông
- Dù từng làm việc với các công ty sử dụng Asterisk và FreeSWITCH, tác giả chưa có kinh nghiệm phân tích sâu PBX, SIP hay mã hóa âm thanh
- Trong lĩnh vực viễn thông có các lập trình viên C xuất sắc, cộng đồng hacker lâu đời và truyền thống của các kỹ sư xuất thân từ Bell Labs, nên tác giả dự đoán các lỗ hổng đơn giản hẳn đã được phát hiện
- Tuy nhiên, ngay sau khi mở mã nguồn FreeSWITCH, lỗ hổng đã được phát hiện
Tràn bộ đệm trong bộ xử lý yêu cầu HTTP XMLRPC
- Bộ xử lý yêu cầu HTTP của thư viện XMLRPC được đóng gói kèm FreeSWITCH ghi URI vào bộ đệm stack kích thước cố định
z[4096] - Đoạn mã có vấn đề có dạng
sprintf(z, "Index of %s" CRLF, uri);, trong đóuriđến từ phần path của Request URI nên kẻ tấn công có thể kiểm soát - Các trình duyệt thông thường thường không hỗ trợ tốt URL dài hơn 2048 ký tự, nhưng các RFC liên quan phần lớn cho phép đến khoảng 8KB, còn Cloudflare hỗ trợ đến 32KB
- Việc giả định kẻ tấn công có thể gửi Request URI dài hơn 4096 ký tự là hợp lý, và điều kiện này dẫn đến tràn bộ đệm không cần xác thực trong thư viện XMLRPC
- Không đề cập đến quá trình mở rộng thành thực thi mã từ xa
Cách sửa và bản vá đã công khai
- Hướng sửa là dùng
snprintf()thay chosprintf() - Đây là một thực hành lập trình C phòng thủ cơ bản
- SignalWire cho biết vấn đề gần đây đã được sửa và đưa ra các PR sau
- Vì bản vá đã được công khai trên GitHub, tác giả cho rằng có thể viết bài công khai
Quá trình công bố lỗ hổng và khoảng trống phát hành
- Ngày 27/1/2025, tác giả gửi chi tiết lỗ hổng đến địa chỉ email ghi trong chính sách bảo mật của FreeSWITCH
- Ngày 7/2/2025, tác giả gửi email theo dõi để xác nhận họ đã nhận báo cáo hay chưa
- Cùng ngày, Andrey Volk trả lời rằng lỗ hổng gần đây đã được sửa và đề nghị xem các PR liên quan
- Khi hỏi về lịch gắn thẻ phát hành có chứa bản sửa bảo mật mới, tác giả nhận được câu trả lời rằng bản phát hành FreeSWITCH Community không được lên kế hoạch cho đến mùa hè 2025
- Vì vậy, người dùng không trả tiền cho FreeSWITCH Advantage có thể vẫn ở trong trạng thái dễ bị tấn công cho đến thời điểm phát hành định kỳ
Quy mô phơi lộ và tác động đối với đơn vị vận hành
- Vào thời điểm đó, kết quả tìm kiếm FreeSWITCH trên Shodan là khoảng 8.300
- Vì khó có thể cho rằng tất cả các instance này đều trả tiền hỗ trợ doanh nghiệp, tác giả cho rằng hàng nghìn stack viễn thông trên toàn thế giới có thể vẫn dễ bị tấn công cho đến mùa hè
- Ngay cả khi bản vá đã công khai trên GitHub, nếu không có thẻ phát hành thì các đơn vị vận hành thông thường khó cập nhật dễ dàng
- Đơn vị vận hành FreeSWITCH nên cân nhắc các biện pháp sau thay vì chờ bản phát hành của SignalWire
- Build lại trực tiếp từ mã nguồn
- Chặn truy cập HTTP công khai vào stack FreeSWITCH ở cấp tường lửa
Vấn đề mang tính cấu trúc của bảo mật viễn thông
- Trong trao đổi với người quen trong ngành viễn thông, phản ứng đưa ra là tốc độ phản hồi của FreeSWITCH như vậy thậm chí còn thuộc loại nhanh
- Ngay cả tháng 12/2024, cảnh báo về lỗ hổng SS7 đã tồn tại 17 năm trong mạng điện thoại lại được nêu ra
- Sau trải nghiệm này, tác giả không xem xét thêm Asterisk hay phần mềm nào khác
- Kết luận là bảo mật viễn thông hiện nay ở trong tình trạng không tốt
- Một nguyên nhân lớn có vẻ là gần như không có động lực kiếm tiền từ việc làm cho các hệ thống này an toàn
Tình trạng sau đó
- Trong bản cập nhật ngày 30/4/2025, lỗi tràn bộ đệm được báo cáo đã được gán CVE-2025-44087
- Vào cùng thời điểm đó, FreeSWITCH vẫn chưa có thẻ hay bản phát hành nào
1 bình luận
Ý kiến trên Hacker News
Người viết thừa nhận rằng hoàn toàn không có kinh nghiệm về hạ tầng cấp nhà mạng, nhưng bản thân sự nghi ngờ nhìn chung là đúng
Thực tế tôi đã làm khá nhiều kiểm thử xâm nhập 4G/5G và nghiên cứu bảo mật nhắm vào nhiều nhà mạng lớn, và dù có khác biệt giữa từng nhà mạng và nhà cung cấp thiết bị, tình hình vẫn gần như là một màn kinh dị hoàn chỉnh
Cho đến rất gần đây, bảo mật về cơ bản chỉ là bảo mật nhờ che giấu, và các tiêu chuẩn 4G/5G đã bắt đầu xử lý vấn đề này, nhưng vẫn còn những lỗ hổng lớn đủ để gây lo ngại nghiêm trọng
Không hề quá lời khi nói rằng một tác nhân đe dọa từ mức trung bình trở lên muốn tạo bàn đạp trong một nhà mạng là có thể làm được; tôi đã nhiều lần trình diễn điều đó trong công việc
Một số nhà cung cấp thiết bị ở một quốc gia Đông Á có chất lượng stack phần mềm thấp đến mức gần như có thể xếp vào APT, và bảo mật về cơ bản là không tồn tại
Các nước phương Tây có lý do chính đáng khi cấm họ, và phần mềm của các nhà cung cấp thiết bị phương Tây trưởng thành hơn nhiều, nhưng vẫn tụt hậu nhiều năm so với mức mà chúng ta coi là các thực hành bảo mật hiện đại tốt nhất
GCHQ cho rằng chất lượng mã ở mức không thể rà soát được, và thậm chí không thể bảo đảm rằng mã nguồn được cung cấp chính là mã chạy trên thiết bị thực tế
Lý do là Huawei có thể tự cập nhật trực tiếp, và theo tôi biết thì thiết bị đó đã bị cấm sau năm 2020: https://www.washingtonpost.com/world/national-security/brita...
Tôi muốn mua một chiếc trên AliExpress về mổ xẻ, liên kết này có phải điểm bắt đầu ổn không?
https://vulners.com/search/types/huawei
Tôi thật sự không hiểu vì sao đến năm 2025 mà các tiêu chuẩn di động vẫn dùng khóa chia sẻ trước
RSA và Diffie-Hellman[1] đã tồn tại hàng chục năm, hệ thống tổ chức chứng thực cũng đã có từ lâu, vậy mà SIM vẫn được phát hành với khóa chia sẻ trước chỉ thẻ và nhà mạng biết, rồi toàn bộ xác thực và mã hóa sau đó đều dựa trên khóa ấy
Nếu nhà mạng bị hack và khóa bị lộ thì không thể làm gì được
Tệ hơn nữa, nhà sản xuất SIM phải gửi khóa đó cho nhà mạng, và nếu nhà sản xuất ở nước khác thì có thể chịu yêu cầu của chính phủ nước ngoài, tạo ra rất nhiều cơ hội để nhà sản xuất bị hack hoặc khóa bị đánh cắp trong quá trình truyền
Điều này giống như một lỗ hổng NOBUS, và nếu nhà sản xuất SIM hoặc nhà cung cấp thiết bị mạng lõi cấu kết với NSA để giao khóa, họ có thể nghe lén tiềm tàng lưu lượng di động trên toàn thế giới
[1] Tôi biết các thuật toán này hiện không còn là thực hành tốt nhất và đường cong elliptic tốt hơn, nhưng dù sao RSA vẫn hơn hiện tại
[2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...
“Theo các tài liệu tuyệt mật của NSA do Edward Snowden cung cấp, gián điệp Mỹ và Anh đã hack mạng máy tính nội bộ của nhà sản xuất SIM lớn nhất thế giới và đánh cắp các khóa mã hóa dùng để bảo vệ quyền riêng tư của liên lạc điện thoại di động trên toàn thế giới”
https://theintercept.com/2015/02/19/great-sim-heist/
Tôi không biết hiện giờ còn như vậy không, nhưng trước đây khó có thể coi điện thoại di động là một phương tiện liên lạc an toàn
Có lẽ nên trao đổi bằng truyền dữ liệu được mã hóa đầu cuối giữa các thiết bị
Thuật toán khóa đối xứng cũng có ưu điểm là an toàn trước lượng tử
Dù vậy, đến năm 2025 thì ít nhất tôi cũng mong có hỗ trợ ECC, và giờ đây hầu hết smartcard đáng ra phải hỗ trợ mặc định được rồi
Nếu không thể tin nhà cung cấp SIM thì về cơ bản không có lời giải
Ngay cả với cách bất đối xứng, đường tấn công chỉ hơi khác đi; nếu không tin phần mềm chạy trên thẻ thì làm sao biết được nó không rò rỉ bản rõ thông qua việc chọn số ngẫu nhiên của một thuật toán không tất định?
Ý tưởng rằng thêm RSA vào một hệ thống đối xứng sẽ khiến nó an toàn hơn có cơ sở yếu, thậm chí gần như là ngược lại
Cách gọi “lỗ hổng NOBUS” cũng đặc biệt kỳ lạ, vì gốc tin cậy của hệ thống như vậy chính là nhà mạng
Không cần hỏi liệu nhà mạng Mỹ có “cấu kết” với cơ quan tình báo Mỹ hay không; nên xem như điều đó đã là thực tế
Kẻ lừa đảo là khách hàng lớn của nhà mạng, và nếu bị bắt rồi bị chặn, họ sẽ quay lại, trả phí đăng ký đường dây mới và lặp lại quy trình tương tự
Nhờ những kẻ lừa đảo, nhà mạng còn có thể upsell các tính năng bổ sung, nên việc không giải quyết vấn đề lại tiếp tục sinh lời
Như kết luận của bài blog, việc Freeswitch không thay đổi lịch phát hành cộng đồng chẳng có gì đáng ngạc nhiên
Freeswitch ngày trước từng có tinh thần cộng đồng rất mạnh, nhưng vài năm trước, sau khi được thương mại hóa quyết liệt hơn, bầu không khí đã thay đổi
Kể từ đó, muốn truy cập những thứ lẽ ra nên công khai thì phải trải qua quy trình “đăng ký”, và theo tôi nhớ thì có vẻ cả kho APT hay thứ tương tự cũng bị giấu sau bức tường đăng ký
Tôi không muốn đăng ký với một công ty thương mại chỉ để truy cập nội dung cộng đồng phần mềm tự do
Vì ai trong ngành công nghệ cũng biết rằng khi cung cấp thông tin cho một công ty thương mại, nhân viên bán hàng sẽ làm phiền bằng up-sell/cross-sell và đưa bạn vào các mailing list không mong muốn
Tôi cũng đã thấy những phần khác của cộng đồng VoIP điều chỉnh lại mức độ hào phóng với mã nguồn mở, và thành thật là khó trách họ
Nhóm Matrix.org cũng nói điều tương tự trong một bài trình bày tại FOSDEM’25, về vấn đề các nhà cung cấp thương mại ăn theo miễn phí công sức phát triển
Nếu họ còn cập nhật miễn phí cả kho APT thì thật đáng cảm kích, nhưng cũng chỉ là một việc “đáng cảm kích” đến mức đó mà thôi
Nếu bạn phụ thuộc vào mã của họ nhưng không muốn trả chi phí hỗ trợ, thì hãy tự build các gói APT
Tôi không chắc nên kỳ vọng tinh thần cộng đồng nào ở một dự án được duy trì bởi một công ty duy nhất theo kiểu này
Xét đến các tác nhân đe dọa nước ngoài, các liên minh phương Tây như Five Eyes, và áp lực phải liên tục tăng các con số, có thể xem rằng trên mạng không có ẩn danh thật sự
Nếu họ muốn bạn, họ cũng có phương tiện để bắt được bạn
Thực ra điều này không khác thời tiền Internet là bao
Nếu không muốn bị nghe lén/chặn bắt, bạn phải mã hóa theo cách mà các cơ quan an ninh lớn không thể dễ dàng truy cập bằng điện tử
Chẳng hạn như giấy nhắn vật lý, truyền miệng, cử chỉ tay
Ngoài ra, khi tác nhân nhà nước thực sự phân bổ nguồn lực để khai thác dữ liệu, bạn cần sẵn sàng gánh chịu hậu quả từ những gì mình nói và làm trên mạng
Chỉ đọc bài viết thì tôi chưa hoàn toàn bị thuyết phục bởi kết luận “bảo mật viễn thông ngày nay là một mớ hỗn độn”
Vì nó gần giống việc chọn ngẫu nhiên Freeswitch rồi tìm thấy một lỗi tràn bộ đệm
“Telecom stack” có thể dễ tổn thương hoặc không, nhưng bằng chứng được đưa ra ở đây rất yếu
Các cuộc tấn công Salt Typhoon được cho là đã khai thác lỗ hổng Cisco, nhưng các nhà phân tích cũng nêu khả năng kẻ tấn công đã dùng thông tin xác thực hợp lệ: https://cyberscoop.com/cisco-talos-salt-typhoon-initial-acce...
Vì vậy nó không liên quan đến Freeswitch
Oracle SBC chỉ với hành vi mặc định thôi cũng thường bất ổn, và chắc chắn trong mớ hỗn độn của phần triển khai TRouter mà Teams tung ra tuần này vẫn còn lỗi từ chối dịch vụ chưa được cô lập đúng cách
Đừng nói đến mớ hỗn loạn của MF Tandem hay việc gần như mọi nhà mạng để lưu lượng SIP UDP thô không mã hóa chảy thẳng ra Internet
Có thể xây dựng hệ thống an toàn trong lĩnh vực này, nhưng thực tế là hầu hết các nhà mạng lớn đang vận hành các nền tảng độc quyền, không thể sửa đổi của những công ty hoặc dự án đã chết từ lâu như Nortel, Metaswitch, cùng những núi nợ kỹ thuật còn tệ hơn cả đống thiết bị cũ kỹ, chưa được vá tạo nên mạng lưới
Câu “mọi thứ đều là mớ hỗn độn và không có động lực để sửa” chỉ là tóm tắt mà thôi
Thành thật mà nói, nếu không biết thuật ngữ chuyên ngành thì rất khó theo kịp các cuộc trò chuyện đó, và bản thân tôi cũng không hiểu đủ lĩnh vực này để muốn cố giải thích một cách vụng về, nên tôi chỉ viết như vậy
Tôi hoàn toàn không ngờ blog của mình lại xuất hiện trên Hacker News
Đó là mã phân tích các giao thức mạng phức tạp có nhiều thế hệ legacy, thường được viết bí mật, và phần lớn là C/C++
Chắc chắn nó không thể có lỗ hổng được đâu. Ừ, đúng rồi
Các giao thức như SS7 được thiết kế mà không có khái niệm hacker hay tác nhân độc hại
Bạn có thể đặt firewall lên trên, nhưng nó xung đột với các tính năng mong muốn, và ngay cả khi không xung đột thì cũng cần đầu tư thêm
DIAMETER tốt hơn, nhưng vẫn còn nhiều lỗ hổng
Trong vài năm gần đây, bảo mật viễn thông đã trở thành ưu tiên nên có cải thiện, nhưng vẫn phải bọc quanh hàng chục năm phần cứng, phần mềm, firmware và thiết kế mạng legacy
Tôi không nghĩ có nơi nào trong mạng viễn thông chạy Freeswitch chuẩn nguyên bản, nhưng các kiểu vấn đề như ở Freeswitch — một sản phẩm viễn thông lâu đời, nơi bảo mật không được săn tìm kỹ như kỳ vọng — thì có ở khắp nơi
Việc tác giả xem mã trong thời gian rảnh, tìm lỗi và báo cáo là rất đáng khen, và tôi hoàn toàn không muốn ngăn cản
Nhưng chỉ vì một maintainer của một phần mềm không cúi mình trước tác giả theo đúng best practice của ngành bảo mật thì chưa đủ cơ sở để nói “bảo mật viễn thông ngày nay là một mớ hỗn độn”
Nếu ai đó mang đến cho bạn một lỗi trong mã của bạn nhưng không nói rằng nó đang bị khai thác thực tế, cũng không cung cấp PoC để xác nhận khả năng khai thác, thì có lý do gì để không xử lý nó như một lỗi thông thường?
Sửa ngay bây giờ rồi đưa vào bản phát hành kế tiếp là được
Mọi người có thể thấy thay đổi ư? Đúng, họ cũng có thể thấy mọi thay đổi khác
Nếu tìm được exploit thì chúc may mắn, còn người báo cáo thì chưa tìm được
Chuyện tương tự cũng xảy ra ở các bản phân phối Linux
Lỗi bảo mật được báo cáo, và đôi khi tác giả upstream không chỉ cứng đầu mà theo đúng nghĩa đen là đã qua đời
Nếu muốn thay đổi theo lịch của mình thì hãy tự phát hành
Một lĩnh vực có vẻ Freeswitch được dùng khá thường xuyên là các cài đặt BigBlueButton ở trường học và đại học
Đây là hệ thống lớp học ảo, và có lẽ nhiều nơi dùng mà không có hợp đồng hỗ trợ; tôi lo về phía này hơn là các nhà mạng
Tôi thắc mắc thực tế có bao nhiêu người dùng mô-đun XML RPC
Nó không được tải theo mặc định
Sửa: theo Shodan là 468 cái
Cũng thắc mắc liệu
senddirectorydocumenttrong mô-đun XML RPC có thực sự được dùng hay khôngcurl --show-error --get --request GET --user freeswitch:works "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}";Có ý tưởng nào về cách trigger không?
Nếu ít nhất có PoC gây segfault thì khả năng có bản phát hành bảo mật sẽ cao hơn
Pha hack thực sự hay nằm ở tiêm CAMEL MAP
Nó kiểm soát đủ thứ ngon lành, từ SMS, USSD cho tới viên ngọc quý là dịch vụ định vị
Nhiều công ty “SMS số lượng lớn” ở các hòn đảo giàu có vùng Caribe hoặc những nơi như Indonesia đang làm nhiều việc hơn hẳn so với chỉ gửi spam
Vì vậy nó đã cũ, còn 2G được thiết kế từ thập niên 1990
Tôi không rõ mọi người kỳ vọng điều gì
Thành thật mà nói, chỉ cần nó chạy được đã là may rồi
Các nhà mạng lớn không chạy FreeSwitch hay Asterisk trong core
Dĩ nhiên Motorola đang khai tử sản phẩm đó, nhưng nó vẫn tồn tại ngoài hiện trường
Hệ thống tôi phụ trách được chặn firewall rất chặt, nhưng tôi nghĩ không phải cái nào cũng vậy
Hầu hết doanh nghiệp có PBX muốn làm nhiều hơn định tuyến cuộc gọi cơ bản và kết nối PSTN có lẽ đều dùng công cụ bên thứ ba
Và khá nhiều công cụ như vậy được xây dựng trên FreeSWITCH, Asterisk hoặc thứ tương tự
Tôi rất khuyến nghị bài trình bày của P1 Security liên quan đến bảo mật viễn thông di động: https://www.slideshare.net/slideshow/day1-hacking-telcoequip...
Tài liệu đã cũ, nhưng không có lý do gì để tin rằng tình hình đã tốt hơn
Vì hoàn toàn không có động lực để cải thiện
Hơn nữa, lỗ hổng bảo mật phần mềm chỉ là một phần của vấn đề; phía còn lại là các nhà mạng sẵn sàng thuê ngoài quyền kiểm soát và quyền truy cập cốt lõi cho bên chào giá thấp nhất: https://berthub.eu/articles/posts/5g-elephant-in-the-room/