Đang load dữ liệu
Danh tiếng về bảo mật của iOS, hệ điều hành từng được xem như vững chắc nhất thế giới, đã bị sứt mẻ không ít sau hàng loạt lỗ hổng bị phát hiện trong tháng vừa qua.
Hội nghị Black Hat tháng trước đã tiết lộ về những lỗ hổng cho phép thực hiện khoảng nửa tá các loại tấn công không thể chống đỡ khác nhau trên iPhone với chỉ một cú click chuột. Tiếp đó là 5 chuỗi lỗ hổng khai thác khác trên iOS được đưa vào các trang web độc hại để giành quyền kiểm soát thiết bị của nạn nhân. Thậm chí số lượng lỗ hổng trên iOS giờ đang nhiều đến mức những nhà môi giới lỗ hổng khai thác zero-day đã phải giảm giá mua vào các thủ thuật này.
Khi công ty đang chuẩn bị ra mắt chiếc iPhone 11 của năm 2019 trong đêm nay, rõ ràng đây là thời điểm công ty không chỉ cần vá lại các lỗ hổng bảo mật đơn lẻ này mà còn tìm hiểu nguyên nhân sâu xa hơn dẫn đến việc tạo ra cơn mưa lỗ hổng này. Nhưng theo các nhà nghiên cứu bảo mật, điều này cũng có nghĩa là phải nhìn sâu hơn vào hai trụ cột trong iPhone: trình duyệt Safari và iMessage.
Linus Henze, hacker nổi tiếng đối với việc tiết lộ lỗ hổng trên MacOS có tên gọi KeySteal vào đầu năm nay, cùng nhiều nhà nghiên cứu iOS khác cho rằng, những vấn đề bảo mật của iMessage và WebKit – engine trình duyệt cho không chỉ Safari mà tất cả các trình duyệt khác trên iOS – đang trở thành vấn nạn với hệ điều hành này khi Apple luôn ưu tiên code của riêng họ trên các công ty khác.
Henze cho biết: “Apple tin tưởng những dòng code của riêng họ hơn của người khác. Họ không muốn chấp nhận thực tế rằng họ cũng đang tạo ra các lỗ hổng trong những dòng code của mình.”
WebKit trên iOS
Trên iOS, Apple yêu cầu mọi trình duyệt đều phải sử dụng cùng engine WebKit như Safari sử dụng – nghĩa là về cơ bản, mọi trình duyệt như Chrome, Firefox, Brave đều chỉ là Safari với các giao diện người dùng khác nhau.
Theo Henze, yêu cầu này của Apple là vì sự phức tạp của các website chạy JavaScript buộc các trình duyệt phải sử dụng một kỹ thuật được gọi là biên dịch kịp thời JIT (Just-in-Time compilation) như một thủ thuật để tiết kiệm thời gian. Trong khi các chương trình chạy trên iOS cần phải được sign bằng mật mã bởi Apple hoặc một nhà phát triển được cấp phép nào đó, việc tối ưu tốc độ JIT của trình duyệt lại không có biện pháp bảo đảm này.
Theo những nhà nghiên cứu bảo mật, vấn đề với engine WebKit là trong một số khía cạnh nào đó, nó kém bảo mật hơn của engine của Chrome.
Amy Burnett, nhà sáng lập hãng bảo mật Ret2, người đứng đầu việc huấn luyện trên các lỗ hổng khai thác của cả WebKit và Chrome, cho biết không có khác biệt rõ ràng về việc trình duyệt nào có nhiều lỗ hổng khai thác hơn. Tuy nhiên, các lỗ hổng trên Chrome được sửa nhanh hơn, thường được thực hiện thông qua các kỹ thuật như fuzzing – quá trình tự động tìm các lỗ hổng phần mềm bằng cách nạp ngẫu nhiên các trật tự dữ liệu khác nhau cho đến khi lộ ra lỗ hổng.
Ngoài ra Google cũng có chương trình tiền thưởng khá hào phóng cho các lỗ hổng trong Chrome, trong khi Apple không có chương trình tiền thưởng nào như vậy đối với WebKit, trừ khi một lỗ hổng nào đó trên WebKit được tích hợp vào một kỹ thuật tấn công nhắm vào sâu bên trong iOS.
Burnett còn bổ sung thêm rằng, tính năng sandbox của Chrome – nhằm cô lập trình duyệt khỏi phần còn lại của hệ điều hành – cũng làm nó khó qua mặt hơn nhiều so với WebKit, do vậy làm cho các lỗ hổng trên Chrome không mấy hữu ích nếu muốn tấn công giành quyền kiểm soát thiết bị.
Các tham chiếu độc hại
Theo nhà nghiên cứu bảo mật độc lập Luca Todesco, người từng phát hành các kỹ thuật hack WebKit và toàn bộ iOS, cho biết, WebKit còn có một thành phần đặc trưng trong kiến trúc khiến nó có thể trở thành lỗ hổng có thể hack.
Nó được gọi là mô hình đối tượng tài liệu (document object model), hay còn có tên WebCore, vốn được các trình duyệt WebKit sử dụng để dựng hình các website. WebCore yêu cầu một nhà phát triển trình duyệt phải cẩn thận theo dõi những đối tượng dữ liệu sẽ trở thành tham chiếu cho đối tượng khác – một quá trình được gọi là “đếm tham chiếu” (reference counting).
Nhà phát triển chỉ cần mắc một sai lầm nào đó và một trong những tham chiếu đó sẽ chỉ đến một đối tượng không có ở đó. Khi đó một hacker có thể lấp đầy chỗ trống đó bằng một đối tượng độc hại do họ tự chọn, gây ra các rủi ro về những khả năng tấn công trong tương lai.
Ngược lại, phiên bản WebCore của riêng Chrome được bao gồm một lớp bảo vệ khác còn được gọi là “người dọn rác” (garbage collector) để làm sạch các đường dẫn đến những đối tượng bị thiếu, vì vậy chúng sẽ không để lại các lỗ hổng cho những kẻ tấn công. Ngược lại WebKit sử dụng một hệ thống đếm tham chiếu tự động có tên gọi “smart pointer”, nhưng theo Todesco nó vẫn có khả năng phát sinh lỗi.
Apple cũng nhận thấy vấn đề này, vì vậy từ hơn một năm nay, iOS đã được trang bị một biện pháp nhằm giảm nhẹ vấn đề bảo mật được gọi là các đống cô lập (isolated heaps) hay còn được gọi là “isoheap”, được thiết kế để làm các lỗi trong bộ đếm tham chiếu không thể khai thác được. Ngoài ra còn có các biện pháp giảm nhẹ bằng phần cứng trên iPhone XS và XS MAX và XR.
Nhưng cả Todesco và Burnett đều nhấn mạnh rằng, cho dù các biện pháp này giúp cải thiện đáng kể khả năng bảo mật của WebCore, nhưng nó cũng không hoàn toàn ngăn chặn các cuộc tấn công nhắm vào nền tảng này. Todesco cho biết, kể từ khi isoheap được giới thiệu vào năm 2018, đã xuất hiện thêm nhiều lỗ hổng trong bộ đếm tham chiếu.
Lỗ hổng trong iMessage
Các lỗ hổng trên iOS hiếm hơn nhiều so với WebKit. Nhưng chúng lại mạnh mẽ và nguy hiểm hơn nhiều, do vậy chúng thường được sử dụng như bước đầu tiên trong kỹ thuật hack để giành quyền kiểm soát thiết bị mà không cần tương tác với người dùng.
Vì vậy, không có gì ngạc nhiên khi vào tháng trước, Natalie Silvanovich, một nhà nghiên cứu thuộc nhóm Project Zero của Google đã tiết lộ một bộ sưu tập các lỗ hổng chưa từng biết đến trên iMessage, có thể được sử dụng trong những cuộc tấn công chiếm quyền trên iPhone từ xa, mà người dùng không cần click vào đường dẫn.
Đáng lo ngại hơn cả là sự tồn tại của những lỗ hổng riêng lẻ này đều có nguồn gốc từ cùng một vấn đề bảo mật: iMessage cho kẻ tấn công tiếp xúc với “bộ hủy đánh số thứ” (unserializer) của mình, một thành phần có nhiệm vụ mở các loại dữ liệu khác nhau gửi tới thiết bị qua iMessage.
Patrick Wardle, nhà nghiên cứu bảo mật tại hãng Jamf, mô tả sai sót này giống như việc mù quáng mở bất kỳ hộp nào được gửi tới cho bạn, trong đó chứa các thành phần đã được tháo rời và lắp chúng lại với nhau mà không kiểm tra xem chúng có chứa điều gì đó nguy hiểm hay không.
Hơn nữa, iMessage lại có các đặc quyền ưu tiên trong iOS hơn các ứng dụng nhắn tin khác. Trên thực tế, các ứng dụng không phải của Apple đều được nối với phần còn lại của hệ điều hành thông qua các sandbox nghiêm ngặt. Điều đó có nghĩa là nếu một ứng dụng bên thứ ba như WhatsApp bị xâm phạm, các hacker sẽ tiếp tục phải tìm cách vượt qua các sandbox để tấn công vào sâu hơn trong thiết bị.
Trong khi đó, Silvanovich nhấn mạnh rằng một số thành phần dễ bị tổn thương của iMessage được tích hợp trực tiếp với SpringBoard, chuong trình trong iOS để quản lý màn hình Home của thiết bị nhưng lại không có sandbox nào để bảo vệ nó.
Linus Henze viết về iMessage rằng: “Cá nhân tôi không hiểu tại sao họ lại không hề đặt nó vào sandbox. Họ nên giả định rằng, dòng code riêng của họ cũng sẽ có lỗi và đảm bảo rằng code của họ phải được sandbox theo cùng cách mà họ làm với code của các nhà phát triển khác, ví dụ như với WhatsApp hay Signal hay bất kỳ ứng dụng nào khác.”
Apple, vốn nổi danh vì việc hạn chế một cách cẩn thận những ứng dụng nào được phép đưa lên App Store của mình, và sau đó lại cẩn thận cô lập các ứng dụng đó bên trong phần mềm của điện thoại. Nhưng với các sự cố đối với phần mềm của họ gần đây, Apple có lẽ cần kiểm tra lại hệ thống bảo mật của riêng mình – và đối xử với phần code bên trong phần mềm của họ tương tự như những gì họ đang làm với người khác.
Nguồn: Devmaster Academy viaTechTalk and GenK
.png "Lập trình frontend với reacjs (Full)")