Công ty tài chính lưu mật khẩu root DB trên file Excel với mật khẩu dễ đoán

Chào mừng bạn đến với chuyên mục PWNED, nơi chúng tôi kể lại những câu chuyện về các chuyên gia IT tự đào hố cho mình và nhảy xuống đó. Tuần này, câu chuyện xoay quanh việc lưu trữ thông tin nhạy cảm ở một nơi cực kỳ dễ bị tấn công mà không được bảo vệ đúng cách.

Câu chuyện này được chia sẻ bởi Stanislav Kazanov, người đứng đầu bộ phận thực chiến chiến lược tại công ty phát triển phần mềm Innowise. Cách đây vài năm, Kazanov và nhóm của ông được thuê để thực hiện kiểm toán tuân thủ và kiến trúc dữ liệu cho một startup fintech. Công ty này đã đầu tư hơn 1 triệu USD để phát triển hệ thống bảo mật "quân sự", bao gồm xác thực đa yếu tố sinh trắc học (biometric MFA), phát hiện điểm cuối và rất nhiều biện pháp an ninh vật lý.

Trong quá trình kiểm toán, Kazanov đã đăng nhập vào trang SharePoint của công ty và tìm thấy một thư mục có tên "DevOps_Handoff" trên mạng nội bộ mà bất kỳ nhân viên nào cũng có thể truy cập. Bên trong thư mục đó là một bảng tính với tên file rất "tối mật" và khó đoán: Prod_DB_Root_Creds_DO_NOT_SHARE.xlsx. Rõ ràng, quy trình đặt tên này sẽ đánh lừa được bất kỳ hacker nào.

Mặt tích cực là file Excel này có được bảo vệ bằng mật khẩu. Vậy nên, ít nhất cũng có một chút bảo vệ, nhưng liệu nó có thực sự an toàn không?

Khi Kazanov hỏi kỹ sư trưởng về mật khẩu, người này đã xấu hổ đến mức nhìn xuống đất và lí nhí đáp: "Nó là [tên công ty] + [năm]". Chúng ta không biết tên thực tế của công ty, nhưng hãy giả sử nó là Contoso. Khi đó, mật khẩu sẽ là contoso2026. Mật khẩu này không hẳn là "admin123" nhưng cũng đủ gần để có thể đoán ra.

Kỹ sư trưởng giải thích với Kazanov lý do tồn tại của file này. Thật ra, đội ngũ DevOps nội bộ và đội ngũ DBA bên ngoài đã có bất đồng về việc nên sử dụng trình quản lý mật khẩu doanh nghiệp nào. Để giải quyết "tạm thời" bất đồng này, họ đã đổ toàn bộ thông tin đăng nhập root DB và khóa IAM chủ của AWS vào bảng tính này. File này đã tồn tại tới 8 tháng trước khi Kazanov phát hiện ra.

Câu chuyện của chúng ta kết thúc tại đây. Chúng tôi giả định rằng vấn đề này đã được giải quyết sau sự can thiệp của Kazanov và trước khi thảm họa xảy ra. Tuy nhiên, nó cho thấy rằng những bất đồng về cách bảo vệ tài nguyên có thể dẫn đến những sự thỏa hiệp nguy hiểm.

Trong trường hợp này, đội ngũ DevOps nội bộ nên có quyền quyết định cuối cùng về việc sử dụng trình quản lý mật khẩu nào cho họ và các nhà thầu. Dù bảng tính có được bảo vệ bằng mật khẩu mạnh đến đâu, họ cũng không bao giờ nên để sự xung đột này dẫn đến việc đưa các bí mật vào một file Excel.

Nguyên tắc cơ bản nhất của an ninh mạng là chỉ cấp quyền truy cập và thông tin đăng nhập cá nhân cho những người thực sự cần nó. Nhưng ở đây, file được đặt trên mạng nội bộ mà mọi nhân viên, thậm chí cả nhà thầu như Kazanov đều có thể truy cập. Vì đây là một công ty fintech, dữ liệu liên quan có thể ảnh hưởng đến hàng triệu hoặc thậm chí hàng tỷ USD của người khác. Đây là một tình huống nghiêm trọng và bất kỳ ai lơ là với an ninh như vậy đều không xứng đáng để xử lý một đồng tài sản hay giao dịch nào.