AWS Security đưa ra lựa chọn khó hiểu

Cách ly thông tin xác thực bị rò rỉ là chưa đủ để bảo vệ tài khoản AWS của bạn.

Một trong những cách tốt nhất để giảm hóa đơn AWS của bạn tới 99% hoặc hơn là không bao giờ để lộ khóa truy cập vào các kho lưu trữ GitHub công khai. Nhiều người trong chúng ta đã từng vô tình làm điều này trong nhiều năm qua, và các biện pháp phòng thủ chống lại điều đó đã được cải thiện đáng kể (tôi thích nhất là "việc sử dụng thông tin xác thực không tạm thời có nguồn gốc từ OIDC hoặc SSO là một phản mẫu"), nhưng điều đó vẫn xảy ra. Vào thứ Sáu, BleepingComputer đã đưa tin về một phát hiện của Truffle Security rằng hàng trăm khóa AWS bị rò rỉ là khóa root và vẫn còn hoạt động và hợp lệ. AWS Security là nơi quy tụ những người rất thông minh, những người quan tâm sâu sắc đến nhiều vấn đề, bao gồm cả "không tiếp tay cho tội phạm". Nếu họ phát hiện (thường bằng phương tiện tự động) rằng một thông tin xác thực đã bị rò rỉ, họ sẽ nhanh chóng áp dụng Chính sách cách ly (Quarantine Policy) cho nó. Vấn đề là chính sách đó liệt kê một loạt các hành vi xấu trong một mạng lưới ngày càng mở rộng gồm các đối tượng chính và hành vi liên quan.

Quan điểm của AWS về vấn đề này là họ không muốn phá vỡ môi trường của khách hàng: "Chính sách này nhằm mục đích hạn chế thiệt hại tiềm ẩn do các hoạt động liên quan đến gian lận dẫn đến các khoản phí trái phép, trong khi không ảnh hưởng đến các tài nguyên hiện có."

Quan điểm này của AWS là sai lầm. Nếu tôi có quyền truy cập vào thông tin xác thực của bạn (chưa nói đến thông tin xác thực root, trời ơi), việc vô hiệu hóa chúng có thể phá vỡ khối lượng công việc của bạn vì bất cứ thứ gì dựa vào những thông tin xác thực đó sẽ bắt đầu thất bại. Cho đến khi bạn xoay vòng chúng, các khối lượng công việc này sẽ tiếp tục thất bại. Điều đó thật tệ! Nhưng tôi đảm bảo với bạn, với tư cách là một kẻ xấu, tôi có thể làm những điều tồi tệ hơn nhiều với bạn.

Giữ trà của tôi

Hãy áp dụng chính sách cách ly cho một bộ thông tin xác thực và đưa nó cho tôi. Tôi sẽ không thể mua gói tiết kiệm, đọc dữ liệu S3 của bạn, sửa đổi các hàm Lambda, và nhiều thứ khác. Nhưng đây là những gì tôi có thể làm. Bất cứ điều gì tôi muốn trên RDS. Bạn không có gì quan trọng trong cơ sở dữ liệu, phải không? ssm:SendCommand / ssm:StartSession được phép, điều đó có nghĩa là tôi có thể chạy lệnh với quyền root trên các instance EC2, và do đó sẽ gọi với quyền của vai trò instance đó. sts:AssumeRole có nghĩa là tôi có thể giả định bất kỳ vai trò nào khác trong tài khoản và có được quyền của nó, khiến toàn bộ danh sách hạn chế có thể trở nên vô nghĩa. Tôi có thể sử dụng autoscaling:CreateAutoScalingGroup / UpdateAutoScalingGroup để khởi chạy các instance thông qua vai trò liên kết dịch vụ Auto Scaling, do đó lệnh từ chối ec2:RunInstances không bao giờ được áp dụng. cloudtrail:LookupEvents bị từ chối (điều đó sẽ ngăn bạn đọc nhật ký kiểm toán), nhưng tôi có thể gọi cả cloudtrail:StopLogging và DeleteTrail và chúng thực hiện chính xác những gì bạn mong đợi; bạn không còn nhật ký kiểm toán nữa.

SES từ chối các hành động ses:GetSendQuota / ListIdentities, nhưng bạn biết điều gì đang thiếu không? SendEmail, vì vậy tôi có thể gửi thư rác của mình tới toàn bộ danh sách của bạn. sns:GetSMSAttributes nghĩa là tôi không thể lấy cấu hình SMS của bạn, nhưng tôi hoàn toàn có thể sns:Publish để gửi tin nhắn văn bản lừa đảo đến bất cứ đâu tôi muốn. s3:DeleteObject bị từ chối, nhưng s3:PutObject được phép. Tôi không thể xóa dữ liệu của bạn, nhưng tôi có thể làm đầy một bucket lên đến petabyte. Tiếp theo, họ không chặn s3:PutBucketVersioning, s3:PutObjectLockConfiguration, s3:PutObjectRetention và s3:PutObjectLegalHold. Vì vậy, trên bất kỳ bucket hiện có nào, như cái bucket tôi vừa nhồi đầy petabyte vào đó, tôi có thể bật versioning, bật Object Lock và đặt mặc định retention ở chế độ COMPLIANCE đến năm 2126, hoặc cách khác là áp dụng nó cho từng đối tượng. Retention COMPLIANCE không thể được rút ngắn hoặc xóa bởi bất kỳ ai, kể cả root tài khoản và AWS Support. Cách duy nhất để loại bỏ nó là xóa toàn bộ tài khoản AWS.

secretsmanager:GetSecretValue, ssm:GetParameter* (WithDecryption) và kms:Decrypt đều không bị cản trở, vì vậy bí mật của bạn giờ là bí mật của tôi. Chia sẻ là tốt!

Sao lưu rất quan trọng, thật đáng tiếc khi bạn không có cái nào. Chà, không phải sau khi tôi kích hoạt backup:DeleteRecoveryPoint / DeleteBackupVault và rds:DeleteDBSnapshot. Nếu bạn đang sử dụng CloudFormation, và vì một số thứ chắc chắn bạn đang sử dụng, việc cloudformation:DeleteStack không được đề cập nghĩa là bạn không sử dụng nó nữa và tất cả các stack của bạn đã biến mất.

Tôi sẽ có những lựa chọn khác

Đây không phải là một danh sách toàn diện - chỉ là một vài điều tôi nghĩ ra trong khoảng một giờ. Tôi không phải là kẻ xấu; tôi gần như chắc chắn rằng tôi đang bỏ lỡ rất nhiều thứ. AWS gần như chắc chắn sẽ thay đổi điều này. Câu hỏi của tôi dành cho họ chỉ đơn giản là, "Một sự cố khách hàng lớn đến mức nào cần xảy ra trước khi bạn hành động?" ®

Chuyên mục

• Bảo mật
• AWS
• Amazon