🥇 AWS এ ক্যাপিটাল ওয়ান হ্যাকের প্রযুক্তিগত বিবরণ

19 জুলাই, 2019-এ, ক্যাপিটাল ওয়ান এমন বার্তা পেয়েছে যে প্রতিটি আধুনিক কোম্পানি ভয় পায়—একটি ডেটা লঙ্ঘন ঘটেছে। এটি 106 মিলিয়নেরও বেশি লোককে প্রভাবিত করেছে। 140 মার্কিন সামাজিক নিরাপত্তা নম্বর, এক মিলিয়ন কানাডিয়ান সামাজিক নিরাপত্তা নম্বর। 000 ব্যাঙ্ক অ্যাকাউন্ট। অপ্রীতিকর, আপনি একমত না?

দুর্ভাগ্যবশত, হ্যাকটি জুলাই 19 তারিখে ঘটেনি। দেখা যাচ্ছে, পেজ থম্পসন, ওরফে অনিশ্চিত, 22 মার্চ থেকে 23 মার্চ, 2019 এর মধ্যে এটি প্রতিশ্রুতিবদ্ধ। এটাই প্রায় চার মাস আগে. প্রকৃতপক্ষে, এটি শুধুমাত্র বাইরের পরামর্শদাতাদের সাহায্যে ছিল যে ক্যাপিটাল ওয়ান আবিষ্কার করতে সক্ষম হয়েছিল যে কিছু ঘটেছে।

অ্যামাজনের একজন প্রাক্তন কর্মচারীকে গ্রেপ্তার করা হয়েছিল এবং তাকে $250 জরিমানা এবং পাঁচ বছরের কারাদণ্ডের সম্মুখীন হতে হয়েছে... কিন্তু এখনও অনেক নেতিবাচকতা বাকি আছে। কেন? কারণ অনেক কোম্পানি যারা হ্যাকের শিকার হয়েছে তারা সাইবার ক্রাইমের বৃদ্ধির মধ্যে তাদের অবকাঠামো এবং অ্যাপ্লিকেশনগুলিকে শক্তিশালী করার দায়িত্ব এড়িয়ে যাওয়ার চেষ্টা করছে।

যাইহোক, আপনি সহজেই এই গল্পটি গুগল করতে পারেন। আমরা নাটকে যাব না, কথা বলব প্রযুক্তিগত বিষয়টির দিক।

প্রথমত, কী হয়েছে?

ক্যাপিটাল ওয়ানে প্রায় 700টি S3 বালতি চলমান ছিল, যা পেজ থম্পসন অনুলিপি করেছিলেন এবং বন্ধ করে দিয়েছিলেন।

দ্বিতীয়ত, এটি কি ভুল কনফিগার করা S3 বাকেট নীতির আরেকটি কেস?

না এই মুহূর্তে না. এখানে তিনি একটি ভুলভাবে কনফিগার করা ফায়ারওয়াল সহ একটি সার্ভারে অ্যাক্সেস পেয়েছিলেন এবং সেখান থেকে পুরো অপারেশনটি চালিয়েছিলেন।

দাঁড়াও, এটা কিভাবে সম্ভব?

আচ্ছা, সার্ভারে লগ ইন করে শুরু করা যাক, যদিও আমাদের কাছে অনেক বিস্তারিত নেই। আমাদের শুধুমাত্র বলা হয়েছিল যে এটি একটি "মিসকনফিগার করা ফায়ারওয়াল" এর মাধ্যমে ঘটেছে। সুতরাং, ওয়েব অ্যাপ্লিকেশন ফায়ারওয়াল (Imperva), বা নেটওয়ার্ক ফায়ারওয়াল (iptables, ufw, shorewall, ইত্যাদি) এর ভুল নিরাপত্তা গ্রুপ সেটিংস বা কনফিগারেশনের মতো সহজ কিছু। ক্যাপিটাল ওয়ান শুধুমাত্র তার দোষ স্বীকার করেছে এবং বলেছে যে এটি গর্তটি বন্ধ করে দিয়েছে।

স্টোন বলেছিলেন যে ক্যাপিটাল ওয়ান প্রাথমিকভাবে ফায়ারওয়ালের দুর্বলতা লক্ষ্য করেনি তবে এটি সচেতন হওয়ার পরে দ্রুত কাজ করেছে। এটি অবশ্যই সাহায্য করেছিল যে হ্যাকার পাবলিক ডোমেনে মূল শনাক্তকরণ তথ্য রেখে গেছে বলে, স্টোন বলেছেন।

আপনি যদি ভাবছেন কেন আমরা এই অংশের গভীরে যাচ্ছি না, অনুগ্রহ করে বুঝুন যে সীমিত তথ্যের কারণে আমরা কেবল অনুমান করতে পারি। হ্যাকটি ক্যাপিটাল ওয়ানের রেখে যাওয়া একটি গর্তের উপর নির্ভর করে এমন কোনও অর্থ নেই। এবং যতক্ষণ না তারা আমাদের আরও কিছু বলে, আমরা কেবলমাত্র ক্যাপিটাল ওয়ান তাদের সার্ভার খোলা রেখে দেওয়া সমস্ত সম্ভাব্য উপায়গুলির তালিকা করব যাতে কেউ এই বিভিন্ন বিকল্পগুলির মধ্যে একটি ব্যবহার করতে পারে। এই ত্রুটিগুলি এবং কৌশলগুলি বন্য বোকা নজরদারি থেকে অবিশ্বাস্যভাবে জটিল নিদর্শন পর্যন্ত হতে পারে। সম্ভাবনার পরিসরের পরিপ্রেক্ষিতে, এটি একটি দীর্ঘ গল্প হয়ে উঠবে যার কোন বাস্তব উপসংহার নেই। অতএব, আসুন আমরা যে অংশে তথ্য আছে তা বিশ্লেষণ করার দিকে মনোনিবেশ করি।

সুতরাং প্রথম টেকঅ্যাওয়ে হল: আপনার ফায়ারওয়ালগুলি কী অনুমতি দেয় তা জানুন।

শুধুমাত্র যা খোলার প্রয়োজন তা নিশ্চিত করার জন্য একটি নীতি বা সঠিক প্রক্রিয়া স্থাপন করুন। আপনি যদি নিরাপত্তা গোষ্ঠী বা নেটওয়ার্ক ACL এর মতো AWS সংস্থানগুলি ব্যবহার করেন, তাহলে স্পষ্টতই অডিট করার চেকলিস্ট দীর্ঘ হতে পারে... কিন্তু ঠিক যেমন অনেক সংস্থান স্বয়ংক্রিয়ভাবে তৈরি হয় (যেমন ক্লাউডফর্মেশন), তাদের অডিটিং স্বয়ংক্রিয় করাও সম্ভব৷ এটি একটি হোমমেড স্ক্রিপ্ট যা ত্রুটিগুলির জন্য নতুন বস্তু স্ক্যান করে, বা একটি CI/CD প্রক্রিয়ায় নিরাপত্তা নিরীক্ষার মতো কিছু... এটি এড়াতে অনেক সহজ বিকল্প রয়েছে।

গল্পের "মজার" অংশটি হল যে যদি ক্যাপিটাল ওয়ান প্রথমে গর্তটি প্লাগ করত... কিছুই ঘটত না। এবং তাই, সত্যি কথা বলতে কি, সত্যিই কিছু কেমন তা দেখতে সবসময় মর্মাহত হয় বেশ সহজ একটি কোম্পানি হ্যাক হওয়ার একমাত্র কারণ হয়ে ওঠে। বিশেষ করে ক্যাপিটাল ওয়ানের মতো বড়।

তো, ভেতরে হ্যাকার- এরপর কী হলো?

ভাল, একটি EC2 দৃষ্টান্ত ভাঙ্গার পরে... অনেক ভুল হতে পারে। আপনি কার্যত ছুরির ধারে হাঁটছেন যদি আপনি কাউকে এতদূর যেতে দেন। কিন্তু কিভাবে এটা S3 বালতি মধ্যে পেতে? এটি বোঝার জন্য, আসুন IAM ভূমিকা নিয়ে আলোচনা করি।

সুতরাং, AWS পরিষেবাগুলি অ্যাক্সেস করার একটি উপায় হল একজন ব্যবহারকারী হওয়া। ঠিক আছে, এই এক বেশ সুস্পষ্ট. কিন্তু আপনি যদি অন্যান্য AWS পরিষেবা দিতে চান, যেমন আপনার অ্যাপ্লিকেশন সার্ভার, আপনার S3 বালতিতে অ্যাক্সেস দিতে চান? যে জন্য IAM ভূমিকা হয়. তারা দুটি উপাদান নিয়ে গঠিত:

বিশ্বাস নীতি - কোন পরিষেবা বা লোকেরা এই ভূমিকা ব্যবহার করতে পারে?
অনুমতি নীতি - এই ভূমিকা কি অনুমতি দেয়?

উদাহরণস্বরূপ, আপনি একটি IAM ভূমিকা তৈরি করতে চান যা EC2 দৃষ্টান্তগুলিকে একটি S3 বালতি অ্যাক্সেস করার অনুমতি দেবে: প্রথমত, ভূমিকাটি একটি ট্রাস্ট নীতিতে সেট করা হয়েছে যা EC2 (সম্পূর্ণ পরিষেবা) বা নির্দিষ্ট উদাহরণগুলি ভূমিকাটি "অধিগ্রহণ" করতে পারে৷ একটি ভূমিকা গ্রহণ করার অর্থ হল তারা ক্রিয়া সম্পাদনের জন্য ভূমিকার অনুমতিগুলি ব্যবহার করতে পারে৷ দ্বিতীয়ত, পারমিশন পলিসি যে পরিষেবা/ব্যক্তি/সম্পদকে "ভুমিকা নিয়েছে" S3-তে যেকোন কিছু করার অনুমতি দেয়, তা একটি নির্দিষ্ট বালতি অ্যাক্সেস করা হোক... বা 700-এর বেশি, যেমন ক্যাপিটাল ওয়ানের ক্ষেত্রে।

একবার আপনি IAM ভূমিকা সহ একটি EC2 উদাহরণে থাকলে, আপনি বিভিন্ন উপায়ে শংসাপত্রগুলি পেতে পারেন:

আপনি এখানে ইনস্ট্যান্স মেটাডেটা অনুরোধ করতে পারেন http://169.254.169.254/latest/meta-data
অন্যান্য জিনিসের মধ্যে, আপনি এই ঠিকানায় অ্যাক্সেস কীগুলির যেকোনো একটি দিয়ে IAM ভূমিকা খুঁজে পেতে পারেন। অবশ্যই, শুধুমাত্র যদি আপনি একটি উদাহরণ মধ্যে হয়.
AWS CLI ব্যবহার করুন...
যদি AWS CLI ইনস্টল করা থাকে, তাহলে এটি IAM ভূমিকা থেকে শংসাপত্রের সাথে লোড করা হয়, যদি উপস্থিত থাকে। যা অবশিষ্ট থাকে তা হল দৃষ্টান্তের মাধ্যমে কাজ করা। অবশ্যই, তাদের ট্রাস্ট নীতি খোলা থাকলে, Paige সরাসরি সবকিছু করতে পারে।

তাই IAM ভূমিকার সারমর্ম হল যে তারা কিছু সংস্থানকে আপনার পক্ষ থেকে অন্যান্য সংস্থানগুলিতে কাজ করার অনুমতি দেয়৷

এখন আপনি আইএএম-এর ভূমিকা বুঝতে পেরেছেন, আমরা পেজ থম্পসন কী করেছিলেন তা নিয়ে কথা বলতে পারি:

তিনি ফায়ারওয়ালের একটি গর্তের মাধ্যমে সার্ভারে (EC2 উদাহরণ) অ্যাক্সেস অর্জন করেছিলেন
এটি নিরাপত্তা গোষ্ঠী/ACL বা তাদের নিজস্ব ওয়েব অ্যাপ্লিকেশন ফায়ারওয়াল হোক না কেন, অফিসিয়াল রেকর্ডে বলা হয়েছে, গর্তটি সম্ভবত প্লাগ করা বেশ সহজ ছিল।
একবার সার্ভারে, তিনি "যেন" কাজ করতে সক্ষম হয়েছিলেন সে নিজেই সার্ভার
যেহেতু IAM সার্ভার ভূমিকা S3 700+ বালতিগুলিতে অ্যাক্সেসের অনুমতি দিয়েছে, তাই এটি সেগুলি অ্যাক্সেস করতে সক্ষম হয়েছিল

সেই মুহূর্ত থেকে, তাকে যা করতে হয়েছিল তা হল কমান্ড চালানো List Bucketsএবং তারপর আদেশ Sync AWS CLI থেকে...

ক্যাপিটাল ওয়ান ব্যাংক হ্যাক থেকে $100 থেকে $150 মিলিয়নের মধ্যে ক্ষতির অনুমান করেছে. এই ধরনের ক্ষয়ক্ষতি রোধ করার জন্য কেন কোম্পানিগুলি ক্লাউড অবকাঠামো সুরক্ষা, DevOps এবং নিরাপত্তা বিশেষজ্ঞগুলিতে এত বেশি বিনিয়োগ করে। এবং কিভাবে মূল্যবান এবং সাশ্রয়ী মূল্যের মেঘ সরানো হয়? এত বেশি যে এমনকি আরও বেশি সংখ্যক সাইবার নিরাপত্তা চ্যালেঞ্জের মুখে 42 সালের প্রথম ত্রৈমাসিকে সামগ্রিক পাবলিক ক্লাউড বাজার 2019% বৃদ্ধি পেয়েছে!

গল্পের নৈতিকতা: আপনার নিরাপত্তা পরীক্ষা করুন; নিয়মিত অডিট পরিচালনা; নিরাপত্তা নীতির জন্য ন্যূনতম বিশেষাধিকারের নীতিকে সম্মান করুন।

(এটা হল আপনি সম্পূর্ণ আইনি প্রতিবেদন দেখতে পারেন)।

উত্স: www.habr.com

AWS-এ ক্যাপিটাল ওয়ান ব্যাঙ্ক হ্যাকের প্রযুক্তিগত বিবরণ