Vào ngày 19 tháng 2019 năm 106, Capital One nhận được thông báo mà mọi công ty hiện đại đều lo ngại—đã xảy ra vi phạm dữ liệu. Nó ảnh hưởng đến hơn 140 triệu người. 000 số an sinh xã hội Hoa Kỳ, một triệu số an sinh xã hội Canada. 80 tài khoản ngân hàng. Thật khó chịu, bạn có đồng ý không?
Thật không may, vụ hack đã không xảy ra vào ngày 19 tháng XNUMX. Hóa ra, Paige Thompson, hay còn gọi là. Thất thường, đã cam kết trong khoảng thời gian từ ngày 22 tháng 23 đến ngày 2019 tháng XNUMX năm XNUMX. Đó là gần bốn tháng trước. Trên thực tế, chỉ nhờ sự giúp đỡ của các nhà tư vấn bên ngoài, Capital One mới có thể phát hiện ra điều gì đó đã xảy ra.
Một cựu nhân viên của Amazon đã bị bắt và phải đối mặt với mức phạt 250 USD cùng XNUMX năm tù... nhưng vẫn còn rất nhiều điều tiêu cực còn sót lại. Tại sao? Bởi vì nhiều công ty bị hack đang cố gắng rũ bỏ trách nhiệm củng cố cơ sở hạ tầng và ứng dụng của họ trong bối cảnh tội phạm mạng gia tăng.
Dù sao, bạn có thể dễ dàng google câu chuyện này. Chúng ta sẽ không đi vào kịch mà nói về kỹ thuật khía cạnh của vấn đề.
Trước hết, chuyện gì đã xảy ra?
Capital One có khoảng 700 thùng S3 đang chạy, Paige Thompson đã sao chép và bòn rút.
Thứ hai, đây có phải là một trường hợp khác về chính sách nhóm S3 bị định cấu hình sai không?
Không phải bây giờ. Tại đây, cô đã có được quyền truy cập vào một máy chủ có tường lửa được cấu hình không chính xác và thực hiện toàn bộ hoạt động từ đó.
Chờ đã, làm thế nào mà có thể?
Chà, hãy bắt đầu bằng việc đăng nhập vào máy chủ, mặc dù chúng tôi không có nhiều thông tin chi tiết. Chúng tôi chỉ được thông báo rằng sự việc xảy ra thông qua “tường lửa bị định cấu hình sai”. Vì vậy, điều gì đó đơn giản như cài đặt nhóm bảo mật không chính xác hoặc cấu hình tường lửa ứng dụng web (Imperva) hoặc tường lửa mạng (iptables, ufw, Shorewall, v.v.). Capital One chỉ thừa nhận tội lỗi của mình và cho biết đã bịt lỗ hổng.
Stone cho biết Capital One ban đầu không nhận thấy lỗ hổng tường lửa nhưng đã hành động nhanh chóng khi phát hiện ra nó. Điều này chắc chắn đã được hỗ trợ bởi thực tế là hacker được cho là đã để lại thông tin nhận dạng quan trọng trong phạm vi công cộng, Stone nói.
Nếu bạn thắc mắc tại sao chúng tôi không đi sâu hơn vào phần này, hãy hiểu rằng do lượng thông tin hạn chế nên chúng tôi chỉ có thể suy đoán. Điều này vô nghĩa vì vụ hack phụ thuộc vào lỗ hổng do Capital One để lại. Và trừ khi họ cho chúng tôi biết thêm, chúng tôi sẽ chỉ liệt kê tất cả các cách có thể mà Capital One để máy chủ của họ mở kết hợp với tất cả các cách có thể mà ai đó có thể sử dụng một trong các tùy chọn khác nhau này. Những sai sót và kỹ thuật này có thể bao gồm từ những sơ suất cực kỳ ngu ngốc cho đến những mẫu cực kỳ phức tạp. Với nhiều khả năng có thể xảy ra, đây sẽ trở thành một câu chuyện dài không có hồi kết thực sự. Vì vậy, hãy tập trung phân tích phần mà chúng ta có sự thật.
Vì vậy, bài học đầu tiên là: biết tường lửa của bạn cho phép những gì.
Thiết lập một chính sách hoặc quy trình phù hợp để đảm bảo rằng CHỈ những gì cần mở mới được mở. Nếu bạn đang sử dụng các tài nguyên AWS như Nhóm bảo mật hoặc ACL mạng, rõ ràng danh sách kiểm tra để kiểm tra có thể dài... nhưng cũng giống như nhiều tài nguyên được tạo tự động (tức là CloudFormation), bạn cũng có thể tự động hóa quá trình kiểm tra của chúng. Cho dù đó là một tập lệnh tự chế để quét các đối tượng mới để tìm lỗi hay thứ gì đó như kiểm tra bảo mật trong quy trình CI/CD... thì có nhiều tùy chọn dễ dàng để tránh điều này.
Phần "buồn cười" của câu chuyện là nếu ngay từ đầu Capital One đã bịt cái lỗ đó... thì đã không có chuyện gì xảy ra. Và vì vậy, thành thật mà nói, thật sốc khi thấy một điều gì đó thực sự khá đơn giản trở thành lý do duy nhất khiến một công ty bị hack. Đặc biệt là một cái lớn như Capital One.
Vậy, hacker bên trong - chuyện gì xảy ra tiếp theo?
Chà, sau khi xâm nhập vào phiên bản EC2... rất nhiều điều có thể xảy ra sai sót. Thực tế là bạn đang đi trên lưỡi dao nếu bạn để ai đó đi xa đến vậy. Nhưng làm thế nào nó vào được nhóm S3? Để hiểu điều này, hãy thảo luận về Vai trò IAM.
Vì vậy, một cách để truy cập các dịch vụ AWS là trở thành Người dùng. Được rồi, điều này khá rõ ràng. Nhưng điều gì sẽ xảy ra nếu bạn muốn cấp cho các dịch vụ AWS khác, chẳng hạn như máy chủ ứng dụng, quyền truy cập vào bộ chứa S3 của mình? Đó chính là mục đích của vai trò IAM. Chúng bao gồm hai thành phần:
- Chính sách tin cậy - những dịch vụ hoặc người nào có thể sử dụng vai trò này?
- Chính sách quyền - vai trò này cho phép những gì?
Ví dụ: bạn muốn tạo một vai trò IAM cho phép các phiên bản EC2 truy cập vào bộ chứa S3: Đầu tiên, vai trò này được đặt để có Chính sách tin cậy mà EC2 (toàn bộ dịch vụ) hoặc các phiên bản cụ thể có thể “tiếp quản” vai trò. Chấp nhận một vai trò có nghĩa là họ có thể sử dụng quyền của vai trò đó để thực hiện các hành động. Thứ hai, Chính sách quyền cho phép dịch vụ/người/tài nguyên đã “đảm nhận vai trò” thực hiện bất kỳ điều gì trên S3, cho dù đó là truy cập vào một nhóm cụ thể... hay hơn 700, như trong trường hợp của Capital One.
Sau khi sử dụng phiên bản EC2 với vai trò IAM, bạn có thể lấy thông tin xác thực theo một số cách:
- Bạn có thể yêu cầu siêu dữ liệu phiên bản tại
http://169.254.169.254/latest/meta-dataTrong số những thứ khác, bạn có thể tìm thấy vai trò IAM bằng bất kỳ khóa truy cập nào tại địa chỉ này. Tất nhiên, chỉ khi bạn ở trong một trường hợp.
- Sử dụng AWS CLI...
Nếu AWS CLI được cài đặt, nó sẽ được tải thông tin xác thực từ các vai trò IAM, nếu có. Tất cả những gì còn lại là hoạt động QUA phiên bản. Tất nhiên, nếu Chính sách tin cậy của họ được mở, Paige có thể trực tiếp làm mọi việc.
Vì vậy, bản chất của vai trò IAM là chúng cho phép một số tài nguyên thay mặt BẠN hành động trên các NGUỒN LỰC KHÁC.
Bây giờ bạn đã hiểu vai trò của IAM, chúng ta có thể nói về những gì Paige Thompson đã làm:
- Cô ấy đã có được quyền truy cập vào máy chủ (phiên bản EC2) thông qua một lỗ hổng trên tường lửa
Cho dù đó là các nhóm bảo mật/ACL hay tường lửa ứng dụng web của riêng họ, lỗ hổng này có lẽ khá dễ bị cắm, như đã nêu trong hồ sơ chính thức.
- Khi đã ở trên máy chủ, cô ấy có thể hành động “như thể” chính cô ấy là máy chủ
- Vì vai trò máy chủ IAM cho phép S3 truy cập vào hơn 700 nhóm này nên SXNUMX có thể truy cập chúng
Kể từ lúc đó, tất cả những gì cô phải làm là chạy lệnh List Bucketsvà sau đó là lệnh Sync từ AWS CLI...
. Ngăn chặn những thiệt hại như vậy là lý do tại sao các công ty đầu tư rất nhiều vào bảo vệ cơ sở hạ tầng đám mây, DevOps và chuyên gia bảo mật. Và việc chuyển sang đám mây có giá trị và hiệu quả về mặt chi phí như thế nào? Nhiều đến mức ngay cả khi đối mặt với ngày càng nhiều thách thức an ninh mạng !
Ý nghĩa của câu chuyện: kiểm tra sự an toàn của bạn; Thực hiện kiểm toán thường xuyên; Tôn trọng nguyên tắc đặc quyền tối thiểu đối với các chính sách bảo mật.
( Bạn có thể xem báo cáo pháp lý đầy đủ).
Nguồn: www.habr.com