bởi SeerLight
Xây dựng bất kỳ dịch vụ nào nhất thiết phải bao gồm công việc liên tục về bảo mật. Bảo mật là một quá trình liên tục bao gồm phân tích và cải tiến liên tục về bảo mật sản phẩm, theo dõi tin tức về các lỗ hổng và hơn thế nữa. Bao gồm cả kiểm toán. Các cuộc kiểm tra được thực hiện cả trong nội bộ và bởi các chuyên gia bên ngoài, những người có thể hỗ trợ triệt để về vấn đề bảo mật vì họ không đắm chìm trong dự án và có tư duy cởi mở.
Bài viết trình bày quan điểm thẳng thắn nhất của các chuyên gia bên ngoài đã giúp nhóm Giải pháp đám mây Mail.ru (MCS) thử nghiệm dịch vụ đám mây và về những gì họ đã tìm thấy. Là “thế lực bên ngoài”, MCS đã lựa chọn công ty Digital Security, được biết đến với chuyên môn cao trong giới bảo mật thông tin. Và trong bài viết này, chúng tôi sẽ phân tích một số lỗ hổng thú vị được phát hiện trong quá trình kiểm tra bên ngoài - để bạn tránh được tình trạng tương tự khi tạo dịch vụ đám mây của riêng mình.
Описание продукта
là một nền tảng để xây dựng cơ sở hạ tầng ảo trên đám mây. Nó bao gồm IaaS, PaaS và thị trường hình ảnh ứng dụng làm sẵn dành cho nhà phát triển. Khi tính đến kiến trúc MCS, cần kiểm tra độ an toàn của sản phẩm trong các lĩnh vực sau:
- bảo vệ cơ sở hạ tầng của môi trường ảo hóa: bộ ảo hóa, định tuyến, tường lửa;
- bảo vệ hạ tầng ảo của khách hàng: cách ly với nhau, bao gồm mạng, mạng riêng trong SDN;
- OpenStack và các thành phần mở của nó;
- S3 do chúng tôi thiết kế;
- IAM: các dự án có nhiều người thuê với một hình mẫu;
- Vision (thị giác máy tính): API và lỗ hổng khi làm việc với hình ảnh;
- giao diện web và các cuộc tấn công web cổ điển;
- lỗ hổng của các thành phần PaaS;
- API của tất cả các thành phần.
Có lẽ đó là tất cả những gì cần thiết cho lịch sử xa hơn.
Loại công việc nào đã được thực hiện và tại sao nó lại cần thiết?
Kiểm tra bảo mật nhằm mục đích xác định các lỗ hổng và lỗi cấu hình có thể dẫn đến rò rỉ dữ liệu cá nhân, sửa đổi thông tin nhạy cảm hoặc gián đoạn tính khả dụng của dịch vụ.
Trong quá trình làm việc kéo dài trung bình 1-2 tháng, kiểm toán viên lặp lại hành động của những kẻ tấn công tiềm năng và tìm kiếm các lỗ hổng trong các bộ phận máy khách và máy chủ của dịch vụ đã chọn. Trong bối cảnh kiểm tra nền tảng đám mây MCS, các mục tiêu sau đã được xác định:
- Phân tích xác thực trong dịch vụ. Các lỗ hổng trong thành phần này sẽ giúp truy cập ngay vào tài khoản của người khác.
- Nghiên cứu mô hình vai trò và kiểm soát truy cập giữa các tài khoản khác nhau. Đối với kẻ tấn công, khả năng truy cập vào máy ảo của người khác là mục tiêu mong muốn.
- Lỗ hổng phía khách hàng. XSS/CSRF/CRLF/vv. Có thể tấn công người dùng khác thông qua các liên kết độc hại?
- Các lỗ hổng phía máy chủ: RCE và tất cả các kiểu tiêm (SQL/XXE/SSRF, v.v.). Các lỗ hổng máy chủ thường khó tìm hơn nhưng chúng dẫn đến sự xâm phạm của nhiều người dùng cùng một lúc.
- Phân tích sự cô lập phân khúc người dùng ở cấp độ mạng. Đối với kẻ tấn công, việc thiếu sự cô lập làm tăng đáng kể bề mặt tấn công chống lại những người dùng khác.
- Phân tích logic kinh doanh. Có thể lừa doanh nghiệp và tạo máy ảo miễn phí?
Trong dự án này, công việc được thực hiện theo mô hình “Hộp xám”: kiểm tra viên tương tác với dịch vụ với đặc quyền của người dùng thông thường, nhưng sở hữu một phần mã nguồn của API và có cơ hội làm rõ chi tiết với nhà phát triển. Đây thường là mô hình làm việc thuận tiện nhất và đồng thời khá thực tế: thông tin nội bộ vẫn có thể bị kẻ tấn công thu thập, đó chỉ là vấn đề thời gian.
Lỗ hổng được tìm thấy
Trước khi kiểm toán viên bắt đầu gửi các tải trọng khác nhau (tải trọng được sử dụng để thực hiện cuộc tấn công) đến các địa điểm ngẫu nhiên, cần phải hiểu cách mọi thứ hoạt động và chức năng nào được cung cấp. Có vẻ như đây là một bài tập vô ích, vì hầu hết những nơi được nghiên cứu sẽ không có lỗ hổng. Nhưng chỉ hiểu cấu trúc của ứng dụng và logic hoạt động của nó mới có thể tìm ra các vectơ tấn công phức tạp nhất.
Điều quan trọng là phải tìm ra những địa điểm có vẻ đáng ngờ hoặc rất khác biệt với những địa điểm khác về mặt nào đó. Và lỗ hổng nguy hiểm đầu tiên đã được tìm thấy theo cách này.
IDOR
Lỗ hổng IDOR (Tham chiếu đối tượng trực tiếp không an toàn) là một trong những lỗ hổng phổ biến nhất trong logic nghiệp vụ, cho phép người này hoặc người khác có quyền truy cập vào các đối tượng mà quyền truy cập thực sự không được phép. Lỗ hổng IDOR tạo ra khả năng thu thập thông tin về người dùng ở các mức độ nghiêm trọng khác nhau.
Một trong các tùy chọn IDOR là thực hiện các hành động với các đối tượng hệ thống (người dùng, tài khoản ngân hàng, các mặt hàng trong giỏ hàng) bằng cách thao tác các mã định danh truy cập đối với các đối tượng này. Điều này dẫn đến những hậu quả khó lường nhất. Ví dụ: khả năng thay thế tài khoản của người gửi tiền, qua đó bạn có thể đánh cắp chúng từ những người dùng khác.
Trong trường hợp MCS, kiểm toán viên vừa phát hiện ra lỗ hổng IDOR liên quan đến số nhận dạng không an toàn. Trong tài khoản cá nhân của người dùng, số nhận dạng UUID được sử dụng để truy cập vào bất kỳ đối tượng nào, như các chuyên gia bảo mật cho biết, dường như không an toàn một cách ấn tượng (nghĩa là được bảo vệ khỏi các cuộc tấn công vũ phu). Nhưng đối với một số thực thể nhất định, người ta phát hiện ra rằng các con số có thể dự đoán thường xuyên được sử dụng để thu thập thông tin về người dùng ứng dụng. Tôi nghĩ bạn có thể đoán rằng có thể thay đổi từng ID người dùng, gửi lại yêu cầu và do đó lấy được thông tin bỏ qua ACL (danh sách kiểm soát truy cập, quy tắc truy cập dữ liệu cho quy trình và người dùng).
Yêu cầu phía máy chủ giả mạo (SSRF)
Điểm hay của các sản phẩm OpenSource là chúng có một số lượng lớn diễn đàn với các mô tả kỹ thuật chi tiết về các vấn đề phát sinh và nếu bạn may mắn, cả mô tả về giải pháp. Nhưng đồng xu này có một mặt trái: các lỗ hổng đã biết cũng được mô tả chi tiết. Ví dụ: có những mô tả tuyệt vời về lỗ hổng trên diễn đàn OpenStack и , vì lý do nào đó mà không ai vội sửa chữa.
Chức năng chung của các ứng dụng là khả năng người dùng gửi liên kết đến máy chủ mà máy chủ nhấp vào (ví dụ: tải xuống hình ảnh từ một nguồn được chỉ định). Nếu các công cụ bảo mật không tự lọc các liên kết hoặc phản hồi được máy chủ trả về cho người dùng thì những kẻ tấn công có thể dễ dàng sử dụng chức năng đó.
Các lỗ hổng SSRF có thể thúc đẩy đáng kể sự phát triển của một cuộc tấn công. Kẻ tấn công có thể nhận được:
- hạn chế quyền truy cập vào mạng cục bộ bị tấn công, chẳng hạn như chỉ thông qua các phân đoạn mạng nhất định và sử dụng một giao thức nhất định;
- toàn quyền truy cập vào mạng cục bộ, nếu có thể hạ cấp từ cấp ứng dụng xuống cấp vận chuyển và do đó quản lý toàn tải ở cấp ứng dụng;
- quyền truy cập để đọc các tệp cục bộ trên máy chủ (nếu sơ đồ tệp: /// được hỗ trợ);
- và nhiều hơn nữa.
Một lỗ hổng SSRF đã được biết đến từ lâu trong OpenStack, có bản chất là “mù”: khi bạn liên hệ với máy chủ, bạn không nhận được phản hồi từ nó mà nhận được các loại lỗi/độ trễ khác nhau, tùy thuộc vào kết quả của yêu cầu . Dựa vào đó, bạn có thể thực hiện quét cổng trên các máy chủ trong mạng nội bộ, với tất cả những hậu quả sau đó không nên đánh giá thấp. Ví dụ: một sản phẩm có thể có API hỗ trợ chỉ có thể truy cập được từ mạng công ty. Với tài liệu (đừng quên nội bộ), kẻ tấn công có thể sử dụng SSRF để truy cập các phương thức nội bộ. Ví dụ: nếu bằng cách nào đó bạn có thể có được danh sách gần đúng các URL hữu ích thì khi sử dụng SSRF, bạn có thể xem qua chúng và thực hiện yêu cầu - nói một cách tương đối, chuyển tiền từ tài khoản này sang tài khoản khác hoặc thay đổi giới hạn.
Đây không phải là lần đầu tiên lỗ hổng SSRF được phát hiện trong OpenStack. Trước đây, có thể tải xuống image ISO VM từ liên kết trực tiếp, điều này cũng dẫn đến hậu quả tương tự. Tính năng này hiện đã bị xóa khỏi OpenStack. Rõ ràng, cộng đồng coi đây là giải pháp đơn giản và đáng tin cậy nhất cho vấn đề này.
Và trong báo cáo có sẵn công khai từ dịch vụ HackerOne (h1), việc khai thác SSRF không còn mù mờ với khả năng đọc siêu dữ liệu phiên bản dẫn đến quyền truy cập Root vào toàn bộ cơ sở hạ tầng Shopify.
Trong MCS, lỗ hổng SSRF được phát hiện ở hai nơi có chức năng tương tự nhau, nhưng chúng gần như không thể khai thác được do tường lửa và các biện pháp bảo vệ khác. Bằng cách này hay cách khác, nhóm MCS vẫn khắc phục được sự cố này mà không cần chờ đợi cộng đồng.
XSS thay vì tải shell
Bất chấp hàng trăm nghiên cứu đã được viết ra, cuộc tấn công XSS (cross-site scripting) năm này qua năm khác vẫn là cuộc tấn công nhiều nhất. lỗ hổng web (hoặc ?).
Tải tệp lên là nơi yêu thích của bất kỳ nhà nghiên cứu bảo mật nào. Nó thường chỉ ra rằng bạn có thể tải một tập lệnh tùy ý (asp/jsp/php) và thực thi các lệnh của hệ điều hành, theo thuật ngữ của pentesters - “tải shell”. Nhưng mức độ phổ biến của các lỗ hổng như vậy hoạt động theo cả hai hướng: chúng được ghi nhớ và các biện pháp khắc phục được phát triển để chống lại chúng, do đó, gần đây xác suất “tải shell” có xu hướng bằng không.
Đội tấn công (đại diện bởi Digital Security) đã gặp may. OK, trong MCS ở phía máy chủ, nội dung của các tệp đã tải xuống đã được kiểm tra, chỉ cho phép hình ảnh. Nhưng SVG cũng là một bức tranh. Hình ảnh SVG có thể nguy hiểm như thế nào? Bởi vì bạn có thể nhúng các đoạn mã JavaScript vào chúng!
Hóa ra các tệp đã tải xuống có sẵn cho tất cả người dùng dịch vụ MCS, điều đó có nghĩa là có thể tấn công những người dùng đám mây khác, cụ thể là quản trị viên.
Một ví dụ về cuộc tấn công XSS vào biểu mẫu đăng nhập lừa đảo
Ví dụ về khai thác tấn công XSS:
- Tại sao lại cố gắng đánh cắp một phiên (đặc biệt là vì hiện tại các cookie chỉ HTTP có ở khắp mọi nơi, được bảo vệ khỏi bị đánh cắp bằng cách sử dụng tập lệnh js), nếu tập lệnh đã tải có thể truy cập ngay vào API tài nguyên? Trong trường hợp này, tải trọng có thể sử dụng các yêu cầu XHR để thay đổi cấu hình máy chủ, chẳng hạn như thêm khóa SSH công khai của kẻ tấn công và giành quyền truy cập SSH vào máy chủ.
- Nếu chính sách CSP (chính sách bảo vệ nội dung) cấm chèn JavaScript thì kẻ tấn công có thể xâm nhập mà không cần đến nó. Sử dụng HTML thuần túy, tạo một biểu mẫu đăng nhập giả mạo cho trang web và đánh cắp mật khẩu của quản trị viên thông qua hoạt động lừa đảo nâng cao này: trang lừa đảo dành cho người dùng có cùng một URL và người dùng sẽ khó phát hiện ra nó hơn.
- Cuối cùng, kẻ tấn công có thể sắp xếp — đặt Cookie lớn hơn 4 KB. Người dùng chỉ cần mở liên kết một lần và toàn bộ trang web sẽ không thể truy cập được cho đến khi người dùng nghĩ đến việc dọn dẹp trình duyệt một cách cụ thể: trong phần lớn các trường hợp, máy chủ web sẽ từ chối chấp nhận một ứng dụng khách như vậy.
Hãy xem một ví dụ về một XSS khác được phát hiện, lần này với cách khai thác thông minh hơn. Dịch vụ MCS cho phép bạn kết hợp các cài đặt tường lửa thành các nhóm. Tên nhóm là nơi phát hiện XSS. Điểm đặc biệt của nó là vectơ không được kích hoạt ngay lập tức, không phải khi xem danh sách quy tắc mà khi xóa một nhóm:
Nghĩa là, tình huống hóa ra như sau: kẻ tấn công tạo quy tắc tường lửa có tên "tải", quản trị viên sẽ nhận thấy điều đó sau một thời gian và bắt đầu quá trình xóa. Và đây là nơi JS độc hại hoạt động.
Đối với các nhà phát triển MCS, để bảo vệ khỏi XSS trong các hình ảnh SVG đã tải xuống (nếu không thể bỏ chúng), nhóm Bảo mật Kỹ thuật số đã khuyến nghị:
- Đặt các tệp do người dùng tải lên trên một miền riêng không liên quan gì đến “cookie”. Tập lệnh sẽ được thực thi trong bối cảnh của một miền khác và sẽ không gây ra mối đe dọa cho MCS.
- Trong phản hồi HTTP của máy chủ, hãy gửi tiêu đề “Bố trí nội dung: tệp đính kèm”. Khi đó các tập tin sẽ được trình duyệt tải xuống và không được thực thi.
Ngoài ra, hiện nay có nhiều cách dành cho nhà phát triển để giảm thiểu rủi ro khi khai thác XSS:
- bằng cách sử dụng cờ “Chỉ HTTP”, bạn có thể làm cho các tiêu đề “Cookie” của phiên không thể truy cập được đối với JavaScript độc hại;
- sẽ khiến kẻ tấn công khai thác XSS khó khăn hơn nhiều;
- các công cụ tạo mẫu hiện đại như Angular hoặc React tự động vệ sinh dữ liệu người dùng trước khi xuất dữ liệu đó ra trình duyệt của người dùng.
Lỗ hổng xác thực hai yếu tố
Để nâng cao tính bảo mật tài khoản, người dùng luôn được khuyến cáo kích hoạt 2FA (xác thực hai yếu tố). Thật vậy, đây là một cách hiệu quả để ngăn chặn kẻ tấn công truy cập vào dịch vụ nếu thông tin xác thực của người dùng bị xâm phạm.
Nhưng việc sử dụng yếu tố xác thực thứ hai có luôn đảm bảo an toàn cho tài khoản không? Có các vấn đề bảo mật sau khi triển khai 2FA:
- Tìm kiếm mạnh mẽ mã OTP (mã một lần). Mặc dù hoạt động đơn giản nhưng các lỗi như thiếu khả năng bảo vệ chống lại sự tấn công mạnh mẽ của OTP cũng được các công ty lớn gặp phải: , .
- Thuật toán tạo yếu, ví dụ như khả năng dự đoán mã tiếp theo.
- Các lỗi logic, chẳng hạn như khả năng yêu cầu OTP của người khác trên điện thoại của bạn, như thế này từ Shopify.
Trong trường hợp MCS, 2FA được triển khai dựa trên Google Authenticator và . Bản thân giao thức đã được kiểm tra theo thời gian, nhưng việc triển khai xác minh mã ở phía ứng dụng vẫn đáng để kiểm tra.
MCS 2FA được sử dụng ở một số nơi:
- Khi xác thực người dùng. Có tính năng bảo vệ chống lại lực lượng vũ phu: người dùng chỉ có một vài lần thử nhập mật khẩu một lần, sau đó đầu vào sẽ bị chặn trong một thời gian. Điều này ngăn chặn khả năng lựa chọn OTP một cách thô bạo.
- Khi tạo mã dự phòng ngoại tuyến để thực hiện 2FA, cũng như vô hiệu hóa nó. Ở đây, không có biện pháp bảo vệ vũ lực nào được triển khai, điều này giúp bạn có thể tạo lại mã dự phòng hoặc vô hiệu hóa hoàn toàn 2FA nếu bạn có mật khẩu cho tài khoản và phiên hoạt động.
Xét rằng các mã dự phòng nằm trong cùng phạm vi giá trị chuỗi với mã do ứng dụng OTP tạo ra, cơ hội tìm thấy mã trong thời gian ngắn sẽ cao hơn nhiều.
Quá trình chọn OTP để vô hiệu hóa 2FA bằng công cụ “Burp: Intruder”
Kết quả
Nhìn chung, MCS có vẻ an toàn như một sản phẩm. Trong quá trình kiểm tra, nhóm pentest không thể truy cập vào máy ảo khách và dữ liệu của họ, đồng thời nhóm MCS đã nhanh chóng sửa chữa các lỗ hổng được tìm thấy.
Nhưng ở đây điều quan trọng cần lưu ý là bảo mật là một công việc liên tục. Dịch vụ không tĩnh, chúng không ngừng phát triển. Và không thể phát triển một sản phẩm hoàn toàn không có lỗ hổng. Nhưng bạn có thể phát hiện chúng kịp thời và giảm thiểu nguy cơ chúng tái phát.
Bây giờ tất cả các lỗ hổng được đề cập trong MCS đã được sửa. Và để giữ số lượng cái mới ở mức tối thiểu và giảm thời gian tồn tại của chúng, nhóm nền tảng tiếp tục làm điều này:
- thường xuyên tiến hành kiểm toán bởi các công ty bên ngoài;
- hỗ trợ và phát triển sự tham gia;
- tham gia bảo mật. 🙂
Nguồn: www.habr.com