جزئیات فنی هک Capital One در AWS

در 19 ژوئیه 2019، Capital One این پیام را دریافت کرد که هر شرکت مدرن از آن می ترسد - یک نقض داده رخ داده است. بیش از 106 میلیون نفر را تحت تأثیر قرار داد. 140 شماره تامین اجتماعی ایالات متحده، یک میلیون شماره تامین اجتماعی کانادا. 000 حساب بانکی ناخوشایند، موافق نیستید؟

متأسفانه این هک در 19 جولای رخ نداد. همانطور که مشخص است، پیج تامپسون، با نام مستعار. دمدمی مزاج، آن را بین ۲۲ تا ۲۳ مارس ۲۰۱۹ انجام داد. به این معنا که تقریبا چهار ماه پیش. در واقع تنها با کمک مشاوران خارجی بود که کپیتال وان توانست کشف کند که اتفاقی افتاده است.

یکی از کارمندان سابق آمازون دستگیر شد و با 250 هزار دلار جریمه و پنج سال زندان روبرو شد... اما هنوز چیزهای منفی زیادی باقی مانده است. چرا؟ زیرا بسیاری از شرکت‌هایی که از هک‌ها رنج می‌برند، در بحبوحه افزایش جرایم سایبری تلاش می‌کنند از مسئولیت تقویت زیرساخت‌ها و برنامه‌های کاربردی خود شانه خالی کنند.

به هر حال شما به راحتی می توانید این داستان را در گوگل جستجو کنید. ما وارد درام نمی‌شویم، اما در مورد آن صحبت می‌کنیم فنی طرف قضیه

اول از همه، چه اتفاقی افتاد؟

Capital One حدود 700 سطل S3 در حال اجرا داشت که پیج تامپسون آنها را کپی کرده و از بین برد.

ثانیا، آیا این مورد دیگری از سیاست سطل S3 پیکربندی نادرست است؟

نه این دفعه نه. در اینجا او به سروری با فایروال پیکربندی نادرست دسترسی پیدا کرد و کل عملیات را از آنجا انجام داد.

صبر کن، چطور ممکن است؟

خوب، اجازه دهید با ورود به سرور شروع کنیم، اگرچه جزئیات زیادی نداریم. فقط به ما گفته شد که این اتفاق از طریق یک "دیوار آتش نادرست پیکربندی شده" رخ داده است. بنابراین، چیزی به سادگی تنظیمات گروه امنیتی نادرست یا پیکربندی فایروال برنامه وب (Imperva)، یا فایروال شبکه (iptables، ufw، shorewall و غیره). پایتخت یک تنها به گناه خود اعتراف کرد و گفت که سوراخ را بسته است.

استون گفت که Capital One در ابتدا متوجه آسیب‌پذیری فایروال نشده بود، اما به محض اینکه متوجه شد به سرعت عمل کرد. استون گفت که مطمئناً با این واقعیت که هکر اطلاعات شناسایی کلیدی را در مالکیت عمومی گذاشته است، به این امر کمک کرد.

اگر تعجب می کنید که چرا ما به این بخش عمیق تر نمی پردازیم، لطفاً درک کنید که به دلیل اطلاعات محدود، ما فقط می توانیم حدس بزنیم. با توجه به اینکه هک به حفره ای بستگی دارد که Capital One ایجاد کرده است، این منطقی نیست. و مگر اینکه آنها بیشتر به ما بگویند، ما فقط همه راه‌های ممکن را که Capital One سرور خود را باز گذاشته است، در ترکیب با تمام راه‌های ممکن برای استفاده از یکی از این گزینه‌های مختلف فهرست می‌کنیم. این نقص ها و تکنیک ها می توانند از نادیده گرفتن های بسیار احمقانه تا الگوهای فوق العاده پیچیده متغیر باشند. با توجه به طیف وسیعی از احتمالات، این به یک حماسه طولانی و بدون نتیجه واقعی تبدیل خواهد شد. بنابراین، بیایید بر تجزیه و تحلیل بخشی که در آن حقایق داریم تمرکز کنیم.

بنابراین اولین نکته این است: بدانید که دیوارهای آتش شما چه اجازه ای می دهند.

یک خط مشی یا فرآیند مناسب ایجاد کنید تا اطمینان حاصل کنید که فقط آنچه باید باز شود باز می شود. اگر از منابع AWS مانند گروه‌های امنیتی یا شبکه ACL استفاده می‌کنید، بدیهی است که فهرست چک برای ممیزی طولانی است... اما درست مانند بسیاری از منابع که به‌طور خودکار ایجاد می‌شوند (یعنی CloudFormation)، امکان خودکارسازی ممیزی آنها نیز وجود دارد. خواه این یک اسکریپت خانگی باشد که اشیاء جدید را برای عیوب اسکن می کند، یا چیزی شبیه ممیزی امنیتی در یک فرآیند CI/CD... گزینه های آسان بسیاری برای جلوگیری از این امر وجود دارد.

بخش "خنده دار" داستان این است که اگر پایتخت وان از همان ابتدا سوراخ را مسدود می کرد ... هیچ اتفاقی نمی افتاد. و بنابراین، صادقانه بگویم، همیشه دیدن اینکه واقعاً چیزی چگونه است، تکان دهنده است خیلی ساده تنها دلیل هک شدن یک شرکت است. به خصوص یکی به بزرگی Capital One.

بنابراین، هکر داخل - بعد چه اتفاقی افتاد؟

خوب، پس از شکستن یک نمونه EC2 ... بسیاری از موارد ممکن است اشتباه کنند. اگر به کسی اجازه دهید تا این حد برود، عملاً روی لبه چاقو راه می‌روید. اما چگونه وارد سطل های S3 شد؟ برای درک این موضوع، اجازه دهید نقش IAM را مورد بحث قرار دهیم.

بنابراین، یکی از راه‌های دسترسی به خدمات AWS، کاربر بودن است. خوب، این یکی کاملا واضح است. اما اگر بخواهید به سایر خدمات AWS مانند سرورهای اپلیکیشن خود دسترسی به سطل های S3 خود بدهید، چه؟ نقش‌های IAM برای همین است. آنها از دو جزء تشکیل شده اند:

1. خط مشی اعتماد - چه خدمات یا افرادی می توانند از این نقش استفاده کنند؟
2. خط مشی مجوزها - این نقش چه چیزی را اجازه می دهد؟

به عنوان مثال، می‌خواهید یک نقش IAM ایجاد کنید که به نمونه‌های EC2 اجازه دسترسی به یک سطل S3 را بدهد: ابتدا، نقش تنظیم شده است که دارای یک خط‌مشی اعتماد باشد که EC2 (کل سرویس) یا نمونه‌های خاص می‌توانند نقش را «تسخیر کنند». پذیرش یک نقش به این معنی است که آنها می توانند از مجوزهای نقش برای انجام اقدامات استفاده کنند. ثانیاً، خط مشی مجوزها به سرویس/شخص/منابعی که «نقش را برعهده گرفته است» اجازه می دهد تا هر کاری را در S3 انجام دهد، خواه دسترسی به یک سطل خاص... یا بیش از 700، مانند مورد Capital One.

هنگامی که در یک نمونه EC2 با نقش IAM قرار گرفتید، می توانید اعتبارنامه را به چند روش دریافت کنید:

1. می‌توانید فراداده نمونه را در این آدرس درخواست کنید http://169.254.169.254/latest/meta-data

   از جمله، می‌توانید نقش IAM را با هر یک از کلیدهای دسترسی در این آدرس پیدا کنید. البته فقط اگر در یک نمونه باشید.

2. استفاده از AWS CLI...

   اگر AWS CLI نصب شده باشد، در صورت وجود، با اعتبارنامه‌های نقش‌های IAM بارگیری می‌شود. تنها کاری که باقی می ماند این است که از طریق نمونه کار کنید. البته، اگر سیاست اعتماد آنها باز بود، پیج می‌توانست مستقیماً همه کارها را انجام دهد.

بنابراین ماهیت نقش‌های IAM این است که به برخی منابع اجازه می‌دهند تا از طرف شما در منابع دیگر عمل کنند.

اکنون که نقش های IAM را درک کرده اید، می توانیم در مورد کاری که پیج تامپسون انجام داد صحبت کنیم:

1. او از طریق سوراخی در فایروال به سرور (نمونه EC2) دسترسی پیدا کرد

   چه گروه‌های امنیتی/ACL و چه فایروال‌های برنامه‌های وب خودشان، احتمالاً همانطور که در سوابق رسمی ذکر شده است، وصل کردن سوراخ بسیار آسان بود.

2. هنگامی که روی سرور قرار گرفت، او توانست "به گونه ای" عمل کند که انگار خودش سرور است
3. از آنجایی که نقش سرور IAM به S3 اجازه دسترسی به این بیش از 700 سطل را می داد، می توانست به آنها دسترسی داشته باشد

از آن لحظه به بعد، تنها کاری که او باید انجام می داد اجرای فرمان بود List Bucketsو سپس فرمان Sync از AWS CLI...

بانک Capital One خسارت ناشی از هک را بین 100 تا 150 میلیون دلار تخمین زده است. جلوگیری از چنین آسیب‌هایی به این دلیل است که شرکت‌ها در حفاظت از زیرساخت‌های ابری، DevOps و کارشناسان امنیتی سرمایه‌گذاری زیادی می‌کنند. و حرکت به سمت ابر چقدر ارزشمند و مقرون به صرفه است؟ به حدی که حتی در مواجهه با چالش های بیشتر و بیشتر امنیت سایبری کل بازار ابر عمومی 42 درصد در سه ماهه اول 2019 رشد کرد!

اخلاقیات داستان: ایمنی خود را بررسی کنید. انجام ممیزی های منظم؛ به اصل کمترین امتیاز برای سیاست های امنیتی احترام بگذارید.

(اینجا می توانید گزارش کامل حقوقی را مشاهده کنید).

منبع: www.habr.com