Lỗ hổng 0-day bị một công ty giám sát thương mại khai thác tại Ai Cập

• Google TAG và The Citizen Lab đã phát hiện một chuỗi khai thác 0-day nhắm vào iPhone trong các cuộc tấn công thực tế, trong đó Intellexa dùng nó để âm thầm cài đặt spyware Predator
• Apple đã vá CVE-2023-41991·41992·41993 trong iOS 16.7 và iOS 17.0.1; Google khuyến nghị người dùng iOS cập nhật ngay lập tức
• Cuộc tấn công chặn lưu lượng bằng chèn MITM khi mục tiêu truy cập các trang HTTP, rồi chuyển hướng tới c.betly[.]me và sec-flare[.]com, nên không cần nhấp chuột riêng hay trả lời cuộc gọi
• Chuỗi iOS bắt đầu bằng thực thi mã từ xa trên Safari, vấn đề xác minh chứng chỉ, rồi leo thang đặc quyền cục bộ trong XNU Kernel; sau đó một binary nhỏ quyết định có cài đặt toàn bộ implant Predator hay không
• Các cuộc tấn công nhắm vào Android cũng được quan sát tại Ai Cập; lỗ hổng thực thi mã từ xa ban đầu trong renderer của Chrome, khai thác CVE-2023-4762, đã được vá ngày 5 tháng 9

---

Chuỗi khai thác dùng để cài đặt Predator của Intellexa

• Google Threat Analysis Group(TAG), cùng với The Citizen Lab, đã phát hiện một chuỗi khai thác 0-day dành cho iPhone đang được dùng trong các cuộc tấn công thực tế
• Chuỗi này, do công ty giám sát thương mại Intellexa phát triển, được dùng để bí mật cài đặt spyware Predator lên thiết bị
• Apple đã vá các lỗ hổng sau trong iOS 16.7 và iOS 17.0.1
  • CVE-2023-41991
  • CVE-2023-41992
  • CVE-2023-41993
• Việc vá nhanh đã tăng cường bảo vệ người dùng, và mọi người dùng iOS được khuyến nghị cài đặt sớm nhất có thể

Cách phân phối qua MITM

• Chuỗi khai thác của Intellexa được phân phối bằng tấn công man-in-the-middle(MITM)
• Trong tấn công MITM, kẻ tấn công chen vào giữa mục tiêu và trang web mà mục tiêu muốn truy cập để chặn lưu lượng
• Khi mục tiêu truy cập một trang http, kẻ tấn công có thể trả về dữ liệu giả để chuyển họ sang một trang web khác
• Với trang https, lưu lượng được mã hóa và có thể dùng chứng chỉ để xác minh dữ liệu nhận được có đến từ đúng trang web dự định hay không
• Trong chiến dịch này, bất kể mục tiêu truy cập trang http nào, họ đều bị âm thầm chuyển hướng bằng chèn lưu lượng tới trang Intellexa c.betly[.]me
  • Nếu người dùng là mục tiêu dự kiến, họ tiếp tục được chuyển tới máy chủ khai thác sec-flare[.]com
  • Không cần hành động nào từ người dùng như mở tài liệu, nhấp vào một liên kết cụ thể hay trả lời cuộc gọi

Cấu thành chuỗi khai thác iOS

• Khi mục tiêu được chuyển hướng tới máy chủ khai thác, chuỗi khai thác iOS sẽ chạy
• Chuỗi này gồm ba lỗ hổng
  • CVE-2023-41993: thực thi mã từ xa(RCE) ban đầu trong Safari
  • CVE-2023-41991: vấn đề xác minh chứng chỉ
  • CVE-2023-41992: leo thang đặc quyền cục bộ(LPE) trong XNU Kernel
• Sau đó, một binary nhỏ được chạy để quyết định có cài đặt toàn bộ implant Predator hay không
• TAG không thu được toàn bộ implant Predator
• Google dự định công bố phân tích kỹ thuật chuyên sâu về exploit này theo Google vulnerability disclosure policy

Tấn công nhắm vào Android và lỗ hổng Chrome

• Kẻ tấn công cũng sở hữu chuỗi khai thác để cài đặt Predator lên thiết bị Android tại Ai Cập
• TAG quan sát thấy exploit Android được phân phối theo hai cách
  • Chèn MITM
  • Liên kết dùng một lần gửi trực tiếp tới mục tiêu
• TAG chỉ thu được lỗ hổng thực thi mã từ xa ban đầu trong renderer của Chrome, lỗ hổng này khai thác CVE-2023-4762
• Lỗi này đã được một nhà nghiên cứu bảo mật độc lập báo cáo trước đó cho Chrome Vulnerability Rewards Program và được vá vào ngày 5 tháng 9
• Google đánh giá rằng Intellexa trước đó đã dùng lỗ hổng này như một 0-day

Phòng vệ MITM của Chrome và phản ứng của Google

• Chrome trong nhiều năm qua đã thúc đẩy phổ cập HTTPS trên toàn web
• “HTTPS-First Mode” của Chrome có thể giảm khả năng phân phối exploit qua chèn mạng MITM
  • Trước tiên cố gắng tải mọi trang bằng HTTPS
  • Hiển thị cảnh báo lớn trước khi quay lại yêu cầu HTTP
• Thiết lập này được bật mặc định cho người dùng đã đăng ký Advanced Protection Program và đăng nhập vào Chrome
• Google khuyến nghị mọi người dùng bật “HTTPS-First Mode” để phòng vệ trước tấn công MITM
• Chiến dịch này cho thấy sự lan rộng của các công ty giám sát thương mại có thể tạo ra rủi ro nghiêm trọng cho an toàn của người dùng trực tuyến
• TAG sẽ tiếp tục thực hiện các biện pháp và công bố nghiên cứu về ngành spyware thương mại, đồng thời hợp tác với khu vực công và tư để duy trì các phản ứng liên quan

[GN⁺]

Ý kiến trên Hacker News

• Việc có thêm thông tin là tốt, nhưng hơi đáng lo khi bài chỉ nhắc đến bản vá Chrome. Tôi tò mò không biết việc thoát sandbox trên Android là gì.
  Ngay cả khi có thể thực thi mã bên trong tiến trình Chrome trên Android, lẽ ra nó vẫn không thể đạt được khả năng duy trì hiện diện, nên chắc chắn còn có lỗ hổng khác.
  Vector tấn công lần này là tấn công xen giữa HTTP và liên kết dùng một lần trong một chiến dịch nhắm mục tiêu, nhưng dường như cũng không có gì ngăn ai đó đưa nó vào chiến dịch quảng cáo hoặc spam qua SMS/Discord/Matrix để phát tán hàng loạt, tạo botnet hoặc đánh cắp thông tin xác thực của người dùng.

  • Đây mới thực sự là điểm cốt lõi. Bài blog thiếu thông tin đó nên phải đọc giữa các dòng, và nghe như phía Android hiện có vấn đề chưa được vá.
  • Họ nói rằng không bắt được các bước tiếp theo của chuỗi Android, chỉ thu được thành phần thực thi ban đầu.
    Tức là còn thiếu lỗi thoát sandbox và leo thang đặc quyền.
    Ngoài ra, ở đây có vẻ nó được phân phối qua tấn công xen giữa ở cấp ISP bằng chức năng nghe lén hợp pháp, nhưng không có lý do gì mà exploit này không thể được phân phối theo kiểu một cú nhấp qua liên kết phishing.
  • Có thể họ đang lược bớt một số chi tiết vì có hàng triệu thiết bị Android bị nhà sản xuất bỏ rơi, nên đây là lỗi chưa được vá và có lẽ sẽ vĩnh viễn không được vá.
  • Trọng tâm của bài là chuỗi exploit iPhone: exploit Safari → vượt PAC → exploit kernel.
    Phiên bản Android cũng khá tương tự, nhưng có vẻ cần thêm hai exploit nữa để vượt qua các cơ chế giảm thiểu của Linux kernel.
    Trên PZ có một bài phân tích kỹ thuật hay.
  • Tôi không rành lắm về môi trường di động, nhưng nếu thoát khỏi sandbox của Chrome thì chẳng phải là vào được hệ điều hành nền rồi sao? Từ đó, không khai thác thêm lỗ hổng thì không tạo được khả năng duy trì hiện diện à?

• HTTPS vẫn tốt hơn là không có, và cuộc tấn công này dùng HTTP để chèn payload ban đầu, nhưng tôi nghĩ tác nhân được nhà nước hậu thuẫn ở một số quốc gia cũng có thể đơn giản là vượt qua hoặc chiếm quyền hạ tầng CA hoặc CDN.

  • Nếu giả mạo chứng chỉ theo cách đó, mọi trình duyệt rất có thể sẽ phát hiện và loại bỏ CA đó, nên vẫn có cơ chế bảo vệ.
  • Hoặc họ có thể khiến người dùng nhấp vào một tên miền giả mạo được LetsEncrypt mà tất cả chúng ta yêu mến chứng nhận.
    Có vẻ thứ cần thiết chỉ là phản hồi chuyển hướng HTTP 302/307 đưa client tới c.betly[.]me. Payload chuyển hướng HTML, hoặc có lẽ cả DNS, cũng có thể khả thi.
  • Điểm quan trọng là chỉ cần một lần truy cập bất kỳ trang HTTP nào cũng đã hoặc đang đủ để chiếm thiết bị.

• Có một tập gần đây liên quan của Darknet Diaries nói về spyware Predator: https://darknetdiaries.com/episode/137/

• Điều mà những 0-day như thế này dạy chúng ta là, nếu bạn là mục tiêu của một đối thủ mạnh, bạn phải hành xử cực kỳ hoang tưởng và giảm bề mặt tấn công tối đa.
  Nếu James Bond muốn liên lạc an toàn với M, tốt hơn là dùng một thiết bị di động phần cứng tùy biến chỉ làm đúng chức năng đó. Phải để lại tin nhắn mã hóa trên một diễn đàn ngẫu nhiên bằng thiết bị trả trước của bên thứ ba ẩn danh, theo thứ tự codebook khóa địa lý luân phiên đã thỏa thuận trước. Chỉ cần an ninh vận hành yếu hơn một chút là xong.
  Nếu một người bình thường dùng thiết bị số có kết nối theo cách bình thường, nên giả định rằng những gì đưa vào thiết bị đó đã bị đánh cắp. Nếu thật sự muốn giữ riêng tư, đừng đưa lên số; hãy để trên giấy hoặc băng analog kiểu cũ. Khi đó ít nhất kẻ tấn công phải đánh cắp vật lý, điều có thể khó hơn nhiều tùy hoàn cảnh, nhưng không nhất thiết nghĩa là an toàn hơn. Rốt cuộc kiểu gì cũng thua.
  Lối thoát thực tế duy nhất là có một chính phủ dân chủ với minh bạch và cơ chế kiểm soát–đối trọng vận hành mạnh, luật bảo vệ quyền riêng tư được thực thi nghiêm, và sự ủng hộ mạnh mẽ cho các hoạt động như Citizen Lab.

• Lỗ hổng này nhiều khả năng đã được chính quyền Ai Cập dùng để hack điện thoại của ứng viên Ahmed El Tantawy, người cạnh tranh trong cuộc bầu cử tổng thống với tổng thống đương nhiệm Abdel Fatah El Sisi.
  https://x.com/jsrailton/status/1705271600868692416?s=46&t=Kq...

• Bài viết không nhắc tới, nhưng Lockdown Mode của iOS đã chặn được chuỗi exploit này.

• Có một điểm tôi không hiểu: cả các công ty spyware lẫn các công ty bán 0-day đều có nhân sự chuyên trách tìm 0-day. Tại sao Google và Apple không đơn giản là tuyển những người này về?
  Google và Apple chắc hẳn có thể đưa ra mức lương rất cạnh tranh, nên tôi thắc mắc vì sao họ không làm vậy. Có phải họ cho rằng chi phí lôi kéo gần như toàn bộ các thợ săn 0-day lành nghề còn lớn hơn chi phí phát hành bản vá không?

  • Tôi chính là người làm việc đó. Tôi làm nhà nghiên cứu 0-day.
    Từ góc nhìn nhân viên, lương cũng tương tự. Công việc ở Big Tech kém thú vị hơn. Bạn xây các cỗ máy dò lỗi lớn tìm được nhiều bug, rồi đưa bug vào trình theo dõi lỗi và có khi 3 tháng sau nó mới được sửa. Công việc bên bảo mật tấn công thú vị hơn. Các lỗ hổng nông đã được Big Tech tìm, nên thứ cần chỉ là vài lỗi và phải hiểu sâu hệ thống nghiên cứu. Cũng cần kiến thức để đi từ lỗ hổng tới thực thi mã. Viết exploit không phải việc dễ. Khó giải thích vì sao kỹ sư lại làm ở những công ty mà tôi cho là phi đạo đức, nhưng có lẽ vì họ không cảm nhận theo cùng cách với tôi.
    Từ góc nhìn nhà tuyển dụng, đây là bài toán “sẽ chi bao nhiêu cho tỷ lệ tìm được X lỗ hổng mỗi năm”. Nếu mã có bug nhưng vẫn được thị trường xem là mã an toàn nhất, tăng ngân sách bảo mật có thể không mang lại lợi ích cho công ty. Nếu tăng ngân sách bảo mật, phải cân nhắc sẽ cắt ngân sách bộ phận nào và tác động ròng lên sức khỏe công ty là gì.
    Nếu muốn sửa lỗ hổng, phải đẩy giá tìm và khai thác lỗ hổng lên mức người mua không kham nổi. Và phải tiếp tục giữ giá đó cao hơn khi những tiến bộ trong bảo mật tấn công làm giảm chi phí phát hiện và khai thác. Sự lệch pha xuất hiện vì các công ty phòng thủ chủ yếu không kiếm tiền từ việc ngăn bug, còn các công ty tấn công chủ yếu kiếm tiền từ việc tìm bug. Lỗ hổng tối hậu của công ty hay bất kỳ tổ chức nào là tài nguyên hữu hạn.
  • Google có một trong những đội giỏi nhất mà tiền bạc và danh tiếng có thể mua được: https://en.m.wikipedia.org/wiki/Project_Zero
    Họ cũng hợp tác rất tốt với các nhà nghiên cứu độc lập trên toàn thế giới. Nhưng xét lượng phần mềm được viết mỗi ngày, việc vẫn bỏ sót một số vấn đề là điều có thể xảy ra.
  • Điều này có vẻ giống như nhìn vào ngân sách chính phủ Mỹ rồi hỏi “sao không mua chuộc hết những tội phạm tiềm năng để giảm phần lớn tội phạm ở Mỹ”.
  • Một số người trong đó ngay từ đầu đã không muốn làm cho Google hay Apple, bất kể lương thế nào.
    Dù hôm nay tuyển được họ, ngày mai sẽ lại có hàng loạt người mới làm ở những công ty kiểu đó, nên đây sẽ là một vòng lặp vô tận.
  • Ý tưởng hay, nhưng ở một khía cạnh nào đó, đây là bài toán khó tương tự câu hỏi “vì sao quốc gia giàu nhất thế giới không thuê hết các tướng lĩnh quân sự giỏi nhất thế giới để không còn ai cho các nước khác”.
    Có nhiều lý do khiến điều đó bất khả thi, nhưng rốt cuộc đều quy về việc thế giới và nhân loại quá lớn và phức tạp để một chủ thể có thể sở hữu tất cả, thậm chí là phần lớn. Có quá nhiều khác biệt đa dạng được gắn sẵn trong mọi thứ. Cũng có nhiều thế giới quan và lòng trung thành vượt lên trên tiền bạc.

• Firefox cũng có Https First, nhưng có vẻ phải bật thiết lập dom.security.https_first.
  Nếu có thể, “HTTPS-Only Mode” chắc chắn là tốt nhất.

  • Dù vậy vẫn phải cưỡng lại thôi thúc bấm “vẫn cho phép”. Thành thật mà nói, dù biết rủi ro, có lẽ chính tôi cũng sẽ bấm. Vì đơn giản là tôi muốn truy cập trang đó.
    Trừ khi prompt trông cực kỳ đáng ngờ, chẳng hạn xuất hiện trên một trang mà bạn biết có hỗ trợ HTTPS như Google.com, còn không thì điều này chẳng giải quyết được gì.

• Bài của Citizen Lab được liên kết trong bài viết này có chi tiết về tấn công xen giữa. Gần như khó gọi là tấn công, vì mạng dường như được thiết kế để chèn nội dung khi cần.