Có thể một máy ảo (VM) hack hack một máy ảo khác chạy trên cùng một máy vật lý không?

Câu hỏi:

• Nếu một VM bị hỏng (bị hack), tôi sẽ gặp rủi ro gì với các VM khác đang chạy trên cùng một máy vật lý?
• Có những loại vấn đề bảo mật nào giữa các máy ảo chạy trên cùng một máy chủ vật lý?
• Có (bạn có thể lập) một danh sách những điểm yếu (tiềm năng) và / hoặc vấn đề không?

Cảnh báo:

Tôi biết nhiều loại / giải pháp ảo hóa tồn tại và có thể có những điểm yếu khác nhau. Tuy nhiên, tôi chủ yếu tìm kiếm các vấn đề bảo mật chung về các kỹ thuật ảo hóa, thay vì một lỗi của nhà cung cấp cụ thể.

Vui lòng cung cấp sự thật, nghiên cứu (nghiêm túc), vấn đề có kinh nghiệm hoặc giải thích kỹ thuật. Hãy cụ thể. Đừng (chỉ) đưa ra ý kiến ​​của bạn.

• Ví dụ:

Hai năm trước, tôi đã nghe nói rằng có thể có các vấn đề bảo mật liên quan đến MMU (tôi nghĩ rằng việc truy cập bộ nhớ chính của các máy khác), nhưng tôi không biết liệu đó có phải là một mối đe dọa thực tế như ngày nay hay chỉ là một nghiên cứu lý thuyết môn học.

EDIT: Tôi cũng thấy cuộc tấn công "Flush + Tải lại" này có khả năng truy xuất các khóa bí mật GnuPG trên cùng một máy vật lý, bằng cách khai thác bộ đệm CPU L3, ngay cả khi GnuPG chạy trênmáy ảo khác . GnuPG đã được vá từ đó.

Tất nhiên có thể khai thác một VM khác chạy trên cùng phần cứng, được khai thác. Ngoài ra, người ta có thể tồn tại. Câu hỏi của bạn trích dẫn một số công việc gần đây cho thấy một. Tôi sẽ không chia sẻ bất kỳ khai thác cụ thể hoặc PoC nào ở đây, nhưng tôi sẽ vui mừng nói làm thế nào chúng có thể được thực hiện.

Các khai thác được sử dụng trong ngữ cảnh này hoàn toàn khác với các khai thác hoạt động khi bạn đang chạy trên cùng một máy mà bạn đang cố gắng khai thác một dịch vụ trên đó và chúng có xu hướng khó hơn một chút do sự cô lập ngày càng tăng. Tuy nhiên, một số cách tiếp cận chung có thể được sử dụng để thực hiện khai thác như vậy bao gồm:

• Tấn công các siêu giám sát . Nếu bạn có thể nhận được một lớp vỏ đặc quyền đủ trên trình ảo hóa được cung cấp một VM, bạn có thể giành quyền kiểm soát bất kỳ VM nào trên hệ thống. Cách để tiếp cận điều này là tìm kiếm các luồng dữ liệu tồn tại từ VM vào bộ ảo hóa và phụ thuộc rất nhiều vào trình ảo hóa; những thứ như trình điều khiển ảo hóa, chia sẻ clipboard, đầu ra hiển thị và lưu lượng truy cập mạng có xu hướng tạo loại kênh này. Ví dụ, một cuộc gọi độc hại đến một thiết bị mạng bị ảo hóa có thể dẫn đến việc thực thi mã tùy ý trong bối cảnh của trình ảo hóa chịu trách nhiệm truyền lưu lượng truy cập đó đến trình điều khiển NIC vật lý.
• Tấn công phần cứng trên máy chủ . Nhiều thiết bị cho phép cập nhật chương trình cơ sở và nếu có thể truy cập cơ chế đó từ máy ảo, bạn có thể tải lên chương trình cơ sở mới phù hợp với ý định của mình. Ví dụ: nếu bạn được phép cập nhật chương trình cơ sở trên NIC, bạn có thể khiến nó trùng lặp lưu lượng truy cập bị ràng buộc cho một địa chỉ MAC (của nạn nhân), nhưng với một địa chỉ MAC đích khác (của bạn). Vì lý do này, nhiều nhà ảo thuật lọc các lệnh như vậy nếu có thể; ESXi lọc các bản cập nhật vi mã CPU khi chúng bắt nguồn từ VM.
• Tấn công kiến ​​trúc của chủ nhà. Cuộc tấn công mà bạn đã trích dẫn, về cơ bản là một cuộc tấn công tiết lộ khóa dựa trên thời gian khác, thực hiện điều này: nó khai thác tác động của cơ chế bộ đệm vào thời gian hoạt động để phân biệt dữ liệu được sử dụng bởi VM nạn nhân trong các hoạt động của nó. Cốt lõi của ảo hóa là việc chia sẻ các thành phần; trong đó một thành phần được chia sẻ, khả năng của một kênh bên tồn tại. Trong phạm vi mà một VM khác trên cùng một máy chủ có thể ảnh hưởng đến hành vi của phần cứng trong khi chạy trong bối cảnh của VM nạn nhân, VM nạn nhân được điều khiển bởi kẻ tấn công. Cuộc tấn công được tham chiếu sử dụng khả năng của VM để kiểm soát hành vi của bộ đệm CPU (về cơ bản là trạng thái chung được chia sẻ) để lần truy cập bộ nhớ của nạn nhân tiết lộ chính xác hơn dữ liệu mà nó đang truy cập; bất cứ nơi nào chia sẻ nhà nước toàn cầu, khả năng tiết lộ cũng tồn tại. Để đưa ra giả thuyết để đưa ra các ví dụ, hãy tưởng tượng một cuộc tấn công làm mát VMFS của ESX và làm cho các phần của khối ảo tham chiếu cùng một địa chỉ đĩa vật lý hoặc một cuộc tấn công làm cho hệ thống khinh khí cầu bộ nhớ tin rằng một số bộ nhớ có thể được chia sẻ khi thực tế nó phải được chia sẻ riêng tư (điều này rất giống với cách khai thác sử dụng sau khi miễn phí hoặc phân bổ kép). Hãy xem xét một MSR CPU giả định (thanh ghi cụ thể theo mô hình) mà trình ảo hóa bỏ qua nhưng cho phép truy cập; điều này có thể được sử dụng để truyền dữ liệu giữa các máy ảo, phá vỡ sự cô lập mà trình ảo hóa được cho là sẽ cung cấp. Cũng xem xét khả năng nén được sử dụng để các thành phần trùng lặp của đĩa ảo chỉ được lưu trữ một lần - kênh bên (rất khó) có thể tồn tại trong một số cấu hình trong đó kẻ tấn công có thể nhận ra nội dung của các đĩa ảo khác bằng cách ghi vào chính nó và quan sát những gì các siêu giám sát làm. Tất nhiên, một nhà ảo thuật có nhiệm vụ bảo vệ chống lại điều này và các ví dụ giả thuyết sẽ là các lỗi bảo mật quan trọng, nhưng đôi khi những điều này lại xảy ra.
• Tấn công VM khác trực tiếp . Nếu bạn có máy chủ gần với máy ảo nạn nhân, bạn có thể tận dụng điều khiển truy cập thoải mái hoặc liên lạc giữa các máy ảo có chủ ý tùy thuộc vào cách máy chủ được cấu hình và giả định nào được thực hiện khi triển khai kiểm soát truy cập. Điều này chỉ hơi liên quan, nhưng nó không đề cập đến.

Các cuộc tấn công cụ thể sẽ phát sinh và được vá khi thời gian tiếp diễn, do đó không bao giờ hợp lệ để phân loại một số cơ chế cụ thể là có thể khai thác, chỉ có thể khai thác trong điều kiện phòng thí nghiệm hoặc không thể khai thác. Như bạn có thể thấy, các cuộc tấn công có xu hướng liên quan và khó khăn, nhưng những cuộc tấn công khả thi tại một thời điểm cụ thể là điều gì đó thay đổi nhanh chóng, và bạn cần phải chuẩn bị.

Điều đó nói rằng, các vectơ tôi đã đề cập ở trên (với ngoại lệ có thể có của vectơ cuối cùng trong một số trường hợp nhất định) đơn giản là không tồn tại trong môi trường kim loại trần. Vì vậy, có, cho rằng bảo mật là về việc bảo vệ chống lại các khai thác mà bạn không biết và không có trong tự nhiên cũng như những gì đã được tiết lộ công khai, bạn có thể có được một chút bảo mật bằng cách chạy trong kim loại trần hoặc tại ít nhất là trong một môi trường mà trình ảo hóa không lưu trữ VM cho tất cả và lặt vặt.

Nói chung, một chiến lược hiệu quả để lập trình ứng dụng an toàn sẽ là giả định rằng máy tính có các tiến trình khác chạy trên nó có thể do kẻ tấn công kiểm soát hoặc độc hại và sử dụng các kỹ thuật lập trình nhận biết khai thác, ngay cả khi bạn nghĩ rằng bạn không đảm bảo quy trình đó tồn tại trong VM của bạn. Tuy nhiên, đặc biệt với hai loại đầu tiên, hãy nhớ rằng người nào chạm vào phần cứng trước sẽ chiến thắng.

Về lý thuyết, không. Toàn bộ quan điểm của hypanneror là cách ly các máy ảo với nhau.

Trong thực tế, đã có (và có thể trong tương lai) các lỗi bảo mật trong các trình ảo hóa khác nhau có thể cho phép một máy ảo ảnh hưởng đến cả trình ảo hóa hoặc các máy ảo khác trên cùng một máy chủ. Các biện pháp bảo mật như sVirt (đối với KVM / QEMU) nhằm giải quyết vấn đề này.

Chỉnh sửa: Tôi nghĩ chủ đề này đã được thực hiện từ nhiều tháng trước, nhưng nó đã được hồi sinh và bây giờ OP đang yêu cầu thêm 'sự thật, trích dẫn các nghiên cứu', v.v., vì vậy tôi đã tìm ra cái quái gì.

Khai thác bản chất này là:

1. Hiếm
2. Nhạy cảm về bản chất và do đó không được chia sẻ công khai, và khi có, các khai thác sẽ được nhà cung cấp vá lại trước khi bất kỳ ai trên trang web này biết về họ.
3. Phức tạp và sẽ thay đổi theo nhà cung cấp

Chúng tôi không thể nói rằng không thể hack một trình ảo hóa và có quyền truy cập vào các máy ảo khác. Chúng tôi cũng không thể định lượng được có bao nhiêu rủi ro, ngoại trừ trải nghiệm đó cho chúng tôi thấy rằng nó khá thấp, vì bạn sẽ không tìm thấy nhiều câu chuyện về các cuộc tấn công sử dụng khai thác hypanneror.

Đây là một loại bài viết thú vị ngược lại cho thấy rằng hơn một vài cuộc tấn công dựa trên hypanneror đã được thực hiện.

Tuy nhiên, với công nghệ phụ thuộc vào các siêu giám sát hơn bao giờ hết, các khai thác như vậy sẽ được vá và bảo vệ chống lại sự khẩn cấp hơn hầu hết các loại khai thác khác.

Dưới đây là đoạn trích từ Báo cáo rủi ro và xu hướng giữa năm của IBM X-Force 2010:

(Vui lòng mở hình ảnh này trong một tab mới để xem kích thước đầy đủ.)

Lưu ý tỷ lệ phần trăm đo được của các lỗ hổng "Escape to hypanneror", nghe có vẻ khá đáng sợ đối với tôi. Đương nhiên, bạn muốn đọc phần còn lại của báo cáo vì có nhiều dữ liệu hơn trong đó để sao lưu các khiếu nại.

Dưới đây là một câu chuyện về một khai thác có thể được thực hiện trên máy ảo hóa Playstation 3, gây cười. Có thể không ảnh hưởng đến doanh nghiệp của bạn, trừ khi doanh nghiệp của bạn là Sony, trong trường hợp đó, nó cực kỳ có ảnh hưởng.

Đây là một bài viết tuyệt vời của Eric Horschman của VMware, trong đó anh ấy nói với tôi nghe có vẻ như một thiếu niên sẽ chống lại Micro $ oft đầy đủ, nhưng nó vẫn là một bài viết hay. Trong bài viết này, bạn sẽ tìm thấy các mẩu tin như thế này:

Các cư dân tại nhà kính của Microsoft có một số viên đá khác ném theo cách của chúng tôi. Microsoft đã chỉ ra CVE-2009-1244 như một ví dụ về lỗ hổng đột phá của khách trong ESX và ESXi. Một khai thác đột phá của khách là một công việc nghiêm túc, nhưng, một lần nữa, Microsoft đang trình bày sai sự thật. VMware đã phản hồi nhanh chóng để vá lỗ hổng đó trong các sản phẩm của chúng tôi và ESX ít bị ảnh hưởng hơn Microsoft sẽ khiến bạn tin rằng:

Phân biệt giữa các đối thủ cạnh tranh. Nhưng có lẽ điều sáng suốt nhất mà ông nói trong toàn bộ bài viết là đây:

Sự thật là, các lỗ hổng và khai thác sẽ không bao giờ biến mất hoàn toàn cho bất kỳ phần mềm doanh nghiệp nào.

Theo de Raddt từng được trích dẫn của dự án OpenBSD:

Bạn hoàn toàn bị lừa dối, nếu không ngu ngốc, nếu bạn nghĩ rằng một tập hợp các kỹ sư phần mềm trên toàn thế giới không thể viết các hệ điều hành hoặc ứng dụng không có lỗ hổng bảo mật, thì có thể quay lại và đột nhiên viết các lớp ảo hóa mà không có lỗ hổng bảo mật.

Một chút viêm nhưng quan điểm của ông được thực hiện tốt. Trong lý thuyết, ảo hóa được cho là cung cấp sự cách ly hoàn toàn giữa các máy ảo và máy chủ của chúng. Trong thực tế, thỉnh thoảng có các lỗ hổng bảo mật cho phép những kẻ tấn công tiên tiến đi vòng quanh các biện pháp bảo vệ này và có quyền truy cập vào các máy ảo khác hoặc thậm chí tệ hơn là máy chủ của chúng (xem Nghiên cứu thực nghiệm về tiếp xúc bảo mật với máy chủ của môi trường ảo hóa thù địch ). Như Ryan Ries đề cập đến các loại lỗ hổng này khá hiếm (điều đó không có nghĩa là chúng không có ở đó) và thường không được các nhà cung cấp tiết lộ nhưng chúng vẫn tồn tại.

Nếu bạn lo ngại về khả năng xảy ra các loại tấn công này (và tôi nghĩ ở một mức độ nào đó bạn nên làm) Tôi khuyên bạn không nên trộn các vùng bảo mật trên một máy chủ ảo hoặc cụm máy chủ ảo. Ví dụ: bạn sẽ có một cụm máy chủ ảo dành riêng cho máy chủ ảo DMZ, cụm dành riêng cho phần mềm trung gian và cụm dành riêng cho tài sản được bảo vệ. Bằng cách này, trong trường hợp lỗ hổng được khai thác theo cách cho phép kẻ tấn công phá hoại các máy ảo khác hoặc tệ hơn là chính trình ảo hóa, mô hình bảo mật của bạn vẫn còn nguyên vẹn.