Gợi nhớ đến một vụ hack Roblox từ thời xa xưa: người dùng có thể đăng ký trên một trang staging phi sản xuất, nơi có biểu ngữ "mọi thứ ở đây đều không mang tính vĩnh viễn". Khi một tài khoản quản trị mới được thêm vào tài khoản production, ai đó đã đăng ký trên trang staging với cùng tên người dùng rồi dùng cookie và token để chiếm đoạt tài khoản production, đẩy trang web vào tình thế rủi ro. Thật khó tin nếu cho rằng những vấn đề như vậy là hiếm gặp: chẳng hạn khi tạo token mã hóa dựa trên tên người dùng hoặc ID người dùng mà không có bí mật riêng cho production/staging, hoặc khi trang staging giao tiếp với dịch vụ bên ngoài vốn nhầm lẫn quyền production.
Ranh giới giữa dev và production ở các tập đoàn lớn dễ bị xuyên thủng hơn nhiều so với mọi người tưởng. Nghĩ về một ngày điển hình: đăng nhập vào PC, kiểm tra email, rồi dùng cùng bộ thông tin xác thực để đăng nhập vào cổng Azure, tất cả đều được hỗ trợ bởi cùng một tenant. Tài khoản đó lại còn được liên kết với GitHub và các tài khoản đám mây.
Để mọi người có thể làm việc trong Teams hay OneDrive, các group và team với những quyền hạn khó hiểu được tạo ra khắp nơi, rồi vẫn tồn tại dưới dạng các security group gần như không thể phân biệt trong thư mục công ty.
Thỉnh thoảng có email tự động hỏi liệu bạn còn đang dùng thứ gì đó cần thiết hay không, nhưng nội dung thì mơ hồ, và ở những công ty thật sự lớn thì chẳng có ai để hỏi cả. Help desk mất hai ngày mới trả lời, cũng không thể nhắn cho John Savill trên Twitter, nên mọi người cứ bấm xác nhận rồi tiếp tục.
Cuối cùng cấu trúc sẽ rách ra, và kẻ tấn công chỉ cần gặp may ở điểm yếu nào đó là có thể lấy được thứ chúng muốn trên nhiều tenant.
Như một CISO khôn ngoan từng nói: hacker không xâm nhập, họ đăng nhập.
Trong ngành an ninh mạng, chuyện này thường được gọi là "whoopsie".
Kevin Beaumont, nhà nghiên cứu và chuyên gia bảo mật, chỉ ra trên Mastodon rằng tài khoản nào có thể gán vai trò full_access_as_app cho ứng dụng OAuth thì phải có quyền quản trị. Ông nói rằng "ai đó" đã mắc một lỗi cấu hình khá nghiêm trọng trong môi trường production.
Không biết chi tiết của hệ thống, nhưng có vẻ đó không nên là vấn đề, và thật ngạc nhiên khi một chuyên gia lại nói đó là vấn đề. Lẽ ra không được tồn tại cách nào để mắc loại lỗi đó. Người thiết kế và quản trị phải khiến điều đó trở nên bất khả thi, và họ phải chịu trách nhiệm.
Dù có đủ loại chứng chỉ bảo mật hào nhoáng, dường như những best practice được suy nghĩ kỹ lưỡng trong một cuốn sách giá 36 USD trên Amazon lại bị phớt lờ hoàn toàn.
Điều còn thiếu trong bài đăng này: các tác giả định nghĩa "production" như thế nào, và vì sao một tài khoản "phi sản xuất" lại có thể có quyền quản trị đối với domain production.
Mẫu hình này không phải ngoại lệ mà là quy tắc trên toàn bộ hệ sinh thái MS, nhưng việc chính Microsoft cũng làm như vậy thì đặc biệt khó xử.
Có một công ty lưu mật khẩu của toàn bộ server và database production trong file text của kho mã nguồn chỉ vì kiến trúc sư trưởng không muốn phải nhớ mật khẩu. Khi ai đó chỉ ra với CTO rằng chuyện này ngu ngốc đến mức nào, họ nhận được câu trả lời "chúng tôi tin tưởng nhân viên của mình" và "chúng tôi đã vượt qua kiểm toán bảo mật".
Khi đến chỗ làm mới, thật khó chịu khi có người cấp quá nhiều quyền chỉ vì "cho dễ". Không nên làm vậy. Không chỉ khiến công ty bị phơi bày rủi ro, mà còn đẩy bản thân vào trách nhiệm không mong muốn. Bạn có thể vô tình phá hỏng thứ gì đó quan trọng, và nếu bị hack thì vì bạn có quyền nên người ta có thể nghi ngờ là bạn đã làm.
Tại sao điều này lại được xem là một "sai lầm"? Đây cũng có thể là hành động của một gián điệp làm quản trị viên ở Microsoft.
1 bình luận
Ý kiến trên Hacker News
full_access_as_appcho ứng dụng OAuth thì phải có quyền quản trị. Ông nói rằng "ai đó" đã mắc một lỗi cấu hình khá nghiêm trọng trong môi trường production.