Phát hiện dấu hiệu chặn bắt lưu lượng mã hóa của Jabber.ru trên Hetzner và Linode
(notes.valdikss.org.ru)- Đã xác nhận dấu hiệu các kết nối XMPP STARTTLS cổng 5222 bị chặn bắt qua proxy MiTM trong suốt trên máy chủ chuyên dụng Hetzner và VPS Linode của dịch vụ XMPP Nga jabber.ru/xmpp.ru
- Kẻ tấn công đã phát hành nhiều chứng chỉ TLS bằng Let’s Encrypt để chấm dứt kết nối mã hóa ở giữa đường truyền, và sự cố bị lộ khi cổng 5222 của jabber.ru trên Hetzner trả về một chứng chỉ đã hết hạn
- Không có dấu vết máy chủ bị xâm nhập hay ARP spoofing trên cùng phân đoạn mạng; các instance Linode cho thấy đường đi và MAC gateway khác với VM thông thường, nên khả năng tái cấu trúc mạng hosting là rất cao
- MiTM được xác nhận tối thiểu từ ngày 21/7/2023 đến 19/10/2023, vẫn có khả năng đã bắt đầu từ 18/4/2023; 100% kết nối cổng 5222 bị ảnh hưởng, còn cổng 5223 thì không
- Cần xem liên lạc jabber.ru/xmpp.ru trong giai đoạn đó là đã bị xâm phạm; cả mã hóa đầu cuối như OMEMO, OTR, PGP cũng chỉ được bảo vệ nếu hai bên đã xác minh khóa
Việc chặn bắt bị lộ ra vì chứng chỉ hết hạn
jabber.rulà dịch vụ XMPP của Nga bắt đầu từ năm 2000, cũng được biết đến với tênxmpp.ru- Khi truy cập dịch vụ ngày 16/10/2023, xuất hiện thông báo “Certificate has expired”, nhưng mọi chứng chỉ cài trên máy chủ đều vẫn còn hiệu lực
- Hiện tượng bất thường chỉ xuất hiện ở cổng 5222 dùng cho XMPP STARTTLS, không thấy ở các cổng khác như cổng 5223 cho XMPP TLS
- Các máy chủ bị ảnh hưởng gồm 1 máy chủ chuyên dụng Hetzner tại Đức và 2 máy chủ ảo Linode
- Trên lưu lượng cổng 5222, quan sát thấy máy chủ nhận được ClientHello đã bị thay thế, thay vì ClientHello gốc từ phía client
Kết quả điều tra khả năng xâm nhập bên trong máy chủ
- Việc điều tra tập trung vào khả năng máy chủ bị hack và khả năng spoofing trên mạng cục bộ
- Phía máy chủ đã kiểm tra các mục sau nhưng không phát hiện điều bất thường
- toàn bộ log
- thời điểm chỉnh sửa của file thực thi và thư viện
- tiến trình đang chạy, memory map, dangling file descriptor
- sự tồn tại của thư viện chiếm quyền
LD_PRELOADở user space bằngbusyboxbiên dịch tĩnh - mô-đun chiếm quyền ở mức kernel bằng cách dump bộ nhớ kernel với LiME và phân tích bằng volatility
- Trong kernel log của máy chủ chuyên dụng Hetzner, ngoại lệ duy nhất là bản ghi cho thấy liên kết mạng vật lý bị mất trong 19 giây vào ngày 18/7/2023
- Các máy chủ Linode chỉ được dùng làm tunnel tuyến thay thế tới máy chủ Hetzner và chỉ chạy các dịch vụ cơ bản như SSH, NTP
- Bên trong tunnel Hetzner↔Linode vẫn thấy ServerHello bình thường từ máy chủ Hetzner, nhưng khi đi ra giao diện mạng Linode để gửi tới client thì nó bị thay đổi
- Điều này có nghĩa cùng một kiểu chặn bắt kết nối mã hóa đã xảy ra ở cả Hetzner lẫn Linode
Dấu hiệu bất thường trong mạng Linode
- Ở góc độ mạng, các hạng mục sau đã được kiểm tra nhưng không tìm thấy dấu vết chiếm quyền trên mạng xung quanh máy chủ
- có ARP spoofing đối với địa chỉ MAC gateway hay không
- trong phân đoạn L2 có một IP phản hồi nhiều lần cho yêu cầu ARP hay không
- có quy tắc định tuyến bất thường bị chèn vào như ICMP redirect hay không
- quy tắc Netfilter
- sự tồn tại của các tunnel khó phát hiện như IPsec
- Các máy Linode bị ảnh hưởng không thể tìm bằng ARP hoặc ping các IP lân cận trong cùng phân đoạn mạng, nhưng từ mạng bên ngoài thì các IP lân cận đó vẫn hoạt động bình thường
- Một VM Linode bên thứ ba không bị ảnh hưởng có thể ping host lân cận và được nối vào router Cisco Systems
- Trong khi đó, VPS bị ảnh hưởng lại nối vào gateway có địa chỉ MAC không xác định được nhà sản xuất
- Sự khác biệt này làm tăng khả năng các VM Linode bị ảnh hưởng đã dùng cấu hình mạng khác với instance Linode thông thường, hoặc bị cô lập trong một VLAN riêng
Chứng chỉ giả mạo và dấu vết trong Certificate Transparency
- Trong cơ sở dữ liệu certificate transparency crt.sh đã phát hiện rogue certificates không phải do các máy chủ jabber.ru phát hành
- Dịch vụ XMPP bình thường dùng hai loại chứng chỉ
xmpp.ru, *.xmpp.rujabber.ru, *.jabber.ru
- Các chứng chỉ được phát hành với mục đích xấu có cấu hình hơi khác chứng chỉ hợp lệ
- thiếu wildcard Subject Alternative Name
- hoặc gộp
jabber.ru, xmpp.ruvào một chứng chỉ duy nhất
- Cấu hình MiTM phía Linode trỏ tới miền
xmpp.rucó một phần thiết lập sai- Máy chủ gốc được cấu hình để cung cấp cả chứng chỉ
jabber.ruvàxmpp.rutùy theo miền XMPP được yêu cầu - Phía MiTM chỉ cung cấp chứng chỉ
xmpp.ru
- Máy chủ gốc được cấu hình để cung cấp cả chứng chỉ
- Thời điểm phát hành chứng chỉ ngày 18/7/2023 gần như trùng với lúc liên kết mạng của máy chủ Hetzner bị ngắt trong vài giây
- Một máy quét mạng bên ngoài xác nhận rằng từ ít nhất ngày 21/7/2023, máy chủ Linode đã cung cấp chứng chỉ
04:b7:85…ở cổng 5222 - Máy quét đó không xử lý dải Hetzner
Thiết bị phía trước cổng 5222 và khác biệt đường đi
- Đã thực hiện thêm các bài kiểm tra mạng từ bên ngoài nhắm vào VPS Linode
- Các host lân cận trong cùng phân đoạn Linode có thể được truy cập ở hop 13 từ kết nối Internet của laptop
- Cổng 5222 bị chặn bắt của máy chủ Linode
dawn.jabber.rucũng đến được ở hop 13 - Nhưng các cổng không bị chặn bắt của cùng máy chủ, như SSH cổng 22, chỉ đến được ở hop 14 sau khi đi qua thêm một hop riêng tư
- Kết quả này cho thấy địa chỉ IP của VM Linode được đặt phía sau một thiết bị bổ sung; thiết bị đó xử lý trực tiếp TCP cổng 5222 và định tuyến các cổng khác tới đích thực
- Bên trong VPS không thể tạo kết nối mới với source port 5222
- router không phản hồi các gói phát ra từ source port đó
- cũng không gửi ICMP error hay Time-to-Live Exceeded đối với outgoing packet có TTL=0 hoặc TTL=1
Cách kết thúc STARTTLS và dấu vân tay phát hiện
- Kết quả kiểm tra bằng testssl.sh cho thấy proxy chặn bắt cho phép anonymous ciphers ở cả Linode
xmpp.ruvà Hetznerjabber.ru - Đây là một cấu hình sai hiếm gặp và có thể dùng làm dấu vân tay phát hiện MiTM XMPP
- Các thư viện SSL/TLS thông thường đa phần được biên dịch mà không hỗ trợ anonymous cipher, và ngay cả khi cho phép rõ trong file cấu hình thì nhiều trường hợp cũng khó cấu hình dịch vụ để sử dụng chúng
- Máy chủ gốc không hề cấu hình anonymous cipher
- Dùng cùng lệnh
testssl.shđể kiểm tra khoảng 20 dịch vụ XMPP phổ biến nhưng không phát hiện dấu hiệu bất thường như hỗ trợ Anonymous NULL Ciphers
Kết luận đã xác nhận và ảnh hưởng tới người dùng
- Kẻ tấn công đã phát hành nhiều chứng chỉ SSL/TLS bằng Let’s Encrypt cho các miền jabber.ru và xmpp.ru từ ngày 18/4/2023
- Cuộc tấn công Man-in-the-Middle nhằm giải mã lưu lượng XMPP client của jabber.ru/xmpp.ru được xác nhận tối thiểu từ ngày 21/7/2023 đến 19/10/2023
- Có khả năng nó đã bắt đầu từ ngày 18/4/2023 nhưng chưa được xác nhận
- Phạm vi ảnh hưởng là 100% kết nối XMPP STARTTLS cổng 5222, không bao gồm cổng 5223
- Kẻ tấn công đã thất bại trong việc gia hạn chứng chỉ TLS, khiến proxy MiTM ở cổng 5222 của jabber.ru trên Hetzner bắt đầu cung cấp chứng chỉ đã hết hạn
- Cuộc tấn công MiTM dừng lại ngay sau cuộc điều tra và các bài kiểm tra mạng ngày 18/10/2023, cũng như sau khi gửi ticket hỗ trợ tới Hetzner và Linode
- Tuy vậy, trên ít nhất một máy chủ Linode vẫn còn tồn tại nghe lén thụ động dưới dạng thêm hop định tuyến
- Không có dấu vết máy chủ bị hack; có vẻ mạng của Hetzner và Linode đã được tái cấu trúc để phục vụ cuộc tấn công nhắm vào địa chỉ IP của dịch vụ XMPP này
- Liên lạc jabber.ru/xmpp.ru trong giai đoạn đó phải được xem là đã bị xâm phạm
- kẻ tấn công có thể hành động như thể được thực hiện từ tài khoản đã xác thực ngay cả khi không biết mật khẩu tài khoản
- có thể tải roster của tài khoản, truy cập toàn bộ lịch sử tin nhắn phía máy chủ không được mã hóa, gửi tin nhắn mới và thay đổi tin nhắn theo thời gian thực
- Liên lạc mã hóa đầu cuối như OMEMO, OTR, PGP chỉ được bảo vệ khỏi việc chặn bắt nếu hai bên đã xác minh khóa mã hóa
- Người dùng cần kiểm tra kho PEP xem có khóa OMEMO·PGP mới chưa được phê duyệt hay không và đổi mật khẩu
Biện pháp phòng ngừa và giám sát mà nhà vận hành có thể thực hiện
- Việc phát hành chứng chỉ mới được ghi vào Certificate Transparency, vì vậy có thể thiết lập giám sát Certificate Transparency
- ví dụ: Cert Spotter, mã nguồn GitHub
- Dùng CAA Record Extensions for Account URI and ACME Method Binding của RFC 8657 để giới hạn phương thức phát hành chứng chỉ và định danh tài khoản được phép phát hành
- Có thể giám sát thay đổi chứng chỉ SSL/TLS của mọi dịch vụ bằng dịch vụ bên ngoài
- Có thể theo dõi sự thay đổi địa chỉ MAC của gateway mặc định
- channel binding của XMPP có thể phát hiện MiTM ngay cả khi phía chặn bắt đưa ra chứng chỉ hợp lệ
- cả client và server đều phải hỗ trợ cơ chế xác thực SCRAM PLUS
- tại thời điểm cuộc tấn công, jabber.ru chưa bật tính năng này
- Khuyến nghị bổ sung từ nhà phát triển ACME Hugo Landau được tổng hợp tại More recommendations from ACME developer Hugo Landau
Phản hồi của Hetzner và Linode
- Tính đến ngày 20/10/2023, vẫn chưa nhận được phản hồi đầy đủ từ Hetzner và Linode
- Trong bản cập nhật ngày 3/11/2023, cả hai công ty vẫn chưa đưa ra phản hồi thích đáng về sự cố này
- Hetzner trả lời rằng với root server chuyên dụng và Cloud server, họ chỉ cung cấp phần cứng, quyền truy cập mạng và hạ tầng cần thiết, nên không thể đưa ra giải pháp bổ sung
- Linode cho biết đã nhận được log nhưng không quan sát thấy hoạt động bất hợp pháp nào ảnh hưởng đến dịch vụ và đã đóng ticket
- Phía vận hành nghiêng về khả năng Hetzner và Linode bị buộc phải áp dụng cấu hình này theo yêu cầu nghe lén hợp pháp từ cảnh sát Đức
- Một khả năng khác là mạng nội bộ của cả Hetzner và Linode đều bị xâm nhập để nhắm riêng vào jabber.ru, nhưng đây là kịch bản khó tin hơn nhiều, dù chưa thể nói là hoàn toàn không thể
1 bình luận
Ý kiến trên Hacker News
Có vẻ rất có khả năng liên quan đến một cuộc điều tra tội phạm mạng của Nga. Nếu từng đọc Krebs hoặc xem các diễn đàn Nga ngầm hơn, hẳn xmpp.ru sẽ khá quen thuộc; thực tế là có bối cảnh như vậy
Không phải tôi muốn gán ghép điều gì cho người vận hành, mà ý là khi vận hành một dịch vụ ẩn danh thì nó sẽ mang tính chất như thế này
https://ddanchev.blogspot.com/2021/03/exposing-currently-act...
https://ddanchev.blogspot.com/2019/07/profiling-currently-ac...
https://blog.talosintelligence.com/picking-apart-remcos/
https://flashpoint.io/wp-content/uploads/Plea-Agreement-USA-...
Bản thân bài viết thật sự rất thú vị, và trông như một ví dụ thực tế cho thấy mọi người nên dùng dịch vụ giám sát Certificate Transparency
Tôi đồng ý với hầu hết các đề xuất giảm thiểu. Nếu là đối tượng rủi ro cao, cũng đáng cân nhắc chồng thêm một lớp xác thực không phụ thuộc vào các tổ chức chứng thực tin cậy: những thứ như Tor onion services, SSH, WireGuard
Tôi đồng ý rằng mọi chứng chỉ SSL/TLS đã được cấp đều thuộc phạm vi Certificate Transparency, và crt.sh cũng có RSS feed
Dùng CAA nói chung là ý hay, nhưng tôi nghi ngờ liệu trong trường hợp này nó có giúp được không. Vì kẻ tấn công chỉ cần yêu cầu đúng cấu hình chứng chỉ được CAA cho phép; nếu có thể giới hạn mạnh hơn một phương thức xác minh cụ thể thì có lẽ sẽ hữu ích
Tôi cũng đồng ý rằng cần giám sát bằng dịch vụ bên ngoài mọi thay đổi chứng chỉ SSL/TLS của tất cả dịch vụ. Đối tượng rủi ro cao phải luôn biết chứng chỉ nào đang hợp lệ và phải kiểm tra điều đó
Cách giám sát thay đổi địa chỉ MAC của default gateway thì, với một cuộc tấn công tinh vi hơn, họ có thể giữ nguyên địa chỉ MAC
Đây là lần đầu tôi biết “channel binding” của XMPP cũng có thể phát hiện tấn công trung gian dù kẻ tấn công xuất trình chứng chỉ hợp lệ
Tất nhiên, điều này giả định nameserver được bảo vệ bằng DNSSEC. Nếu không, yêu cầu DNS cũng có thể bị chặn khi tổ chức chứng thực truy vấn
Có thể xem RFC 8657 để biết đầy đủ các lưu ý bảo mật. RFC này được thiết kế để dễ đọc hơn RFC thông thường
Bài blog của tôi có phần giải thích bối cảnh: https://www.devever.net/~hl/acme-caa-live
Nếu họ thực hiện hoàn hảo một cuộc tấn công trung gian thật sự rồi lại quên gia hạn chứng chỉ, thì chuyện đó khá là kiểu Đức :-)
Hoặc cũng có thể ai đó đã làm theo mệnh lệnh một cách cực kỳ nghiêm túc. Có lệnh thiết lập chứng chỉ, nhưng không có yêu cầu phải tự động gia hạn :)
Bản lưu trữ: https://archive.ph/C0jYJ
Các giả thuyết rất thú vị, và nếu đúng thì giải thích được họ đã lấy chứng chỉ như thế nào. Bài học rút ra ở đây có thể là đặt nhiều probe ở nhiều nhà cung cấp, kiểm tra mọi fingerprint TLS, nhận cảnh báo khi xuất hiện fingerprint lạ, và kiểm tra cả việc có tồn tại trong log Certificate Transparency hay không
openssl s_client -servername news.ycombinator.com -connect news.ycombinator.com:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdinSHA1 Fingerprint=7E:49:BA:40:86:87:B3:39:66:93:94:9E:9C:45:71:85:3C:8D:95:16Vì mọi chứng chỉ SSL/TLS đã được cấp đều thuộc phạm vi Certificate Transparency, nên nên thiết lập giám sát Certificate Transparency như Cert Spotter để nhận email cảnh báo khi chứng chỉ mới được cấp cho domain
Nếu dùng phần mở rộng bản ghi CAA trong RFC 8657, tức Account URI và ACME Method Binding, để giới hạn phương thức xác minh và chỉ định định danh tài khoản chính xác có thể cấp chứng chỉ mới, thì có thể ngăn việc cấp chứng chỉ cho domain thông qua tổ chức chứng thực, tài khoản ACME hoặc phương thức xác minh khác
Cần giám sát bằng dịch vụ bên ngoài mọi thay đổi chứng chỉ SSL/TLS của tất cả dịch vụ, và cũng cần giám sát thay đổi địa chỉ MAC của default gateway
Tôi hơi thắc mắc vì địa chỉ MAC không phải là địa chỉ được quản lý cục bộ. Có vẻ có khả năng ai đó đã cố ý chọn dải địa chỉ này
https://www.google.com/search?q=%2290%253Ade%253A01%22+linod...
Nếu tìm
"90:de:01" linodevà"90:de:00" linode, có vẻ gần đây địa chỉ trong khối này cũng đã được gán cho các VM Linode khác. Hiện tôi không có VM Linode nào để so sánh trực tiếp, nhưng trông như lưu lượng đã được định tuyến tới một VM khác trong hạ tầng LinodeChỉ là suy đoán không có căn cứ, nhưng tôi nghĩ Jabber bị nhắm mục tiêu vì nó nổi tiếng được dùng trong các chợ darknet để giao dịch ma túy hoặc các hoạt động bất hợp pháp khác
Điều này cho thấy không nên chỉ tin rằng “đã mã hóa rồi thì ổn”. Tối thiểu, tin nhắn nên được mã hóa bằng PGP
Tôi cũng tò mò liệu PGP có thể bị máy tính lượng tử phá hay không, và liệu trong tương lai có cơ chế gia cố chống các kiểu tấn công như vậy không. Nếu tin nhắn đã bị thu thập hàng loạt dưới dạng mã hóa, thì cuối cùng việc giải mã có thể chỉ còn là vấn đề thời gian
Và dường như chuyện như thế này đang xảy ra với gần như mọi lưu lượng web có thể thu thập được. Xem https://en.wikipedia.org/wiki/Utah_Data_Center
Tất nhiên, việc trao đổi khóa an toàn với một người bán ma túy ẩn danh trên Internet rất dễ mắc sai lầm
https://therecord.media/genesis-market-takedown-cybercrime
PGP có nhiều vấn đề và cũng có nhiều người khuyên nên tránh. Ví dụ: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ / https://news.ycombinator.com/item?id=20455780
Truyền thông mã hóa đầu cuối như OMEMO, OTR, PGP chỉ bảo vệ khỏi việc bị chặn bắt khi cả hai bên đã xác minh khóa mã hóa. Kẻ tấn công phải dựng một cuộc tấn công trung gian riêng cho từng phương thức mã hóa đầu cuối được sử dụng
Một số client XMPP mà tôi từng thấy sẽ không cho dùng nếu bạn không đánh dấu rõ rằng mình đã xác minh một danh tính mã hóa cụ thể
Dù vậy đây vẫn là một lời nhắc tốt. Nếu bạn chưa từng xử lý một con số dài vô lý hoặc một giá trị tương đương, thì khó có thể nói mã hóa đầu cuối thực sự đã được thiết lập
Có một điểm trong câu chuyện này tôi không hiểu. Nếu là nghe lén hợp pháp, tại sao Hetzner và Linode lại thiết lập nghe lén trung gian bằng chứng chỉ và khóa LE riêng
Lẽ ra họ có thể trích xuất trực tiếp khóa riêng TLS từ RAM hoặc bộ lưu trữ của VPS. Ngay cả với máy chủ vật lý chuyên dụng, cũng có thể lấy dump RAM sau một lần khởi động lại không báo trước để trích xuất khóa riêng
Trích xuất khóa riêng sẽ không lộ trên log CT, nên kín đáo hơn nhiều và thực tế là khó bị phát hiện
Một khả năng khác là một bên là “khám xét” còn bên kia là “nghe lén”, nên mức phê chuẩn có thể khác nhau. Tuy nhiên tôi không rõ tình hình pháp lý hiện nay ở Đức
Nghe như một phương thức quá tiêu chuẩn đối với cơ quan thực thi pháp luật, nên có lẽ loại thiết bị đó đã có sẵn trên thị trường
Một người dùng đã đăng chuyện này lên Reddit từ 3 ngày trước: https://www.reddit.com/r/hetzner/comments/17ankoh/does_hetzn...
Tôi tò mò liệu có cách nào buộc Hetzner/Linode bình luận về tình huống này về mặt pháp lý không. Có vẻ nhiều khả năng đứng sau việc nghe lén là một cơ quan chính phủ hoặc cảnh sát nào đó
Ngược lại, nếu không phải nghe lén hợp pháp thì tôi không nghĩ Hetzner sẽ cho phép. Vì như vậy cũng là vi phạm pháp luật