প্রিভিলেজ এস্কেলেশন বেসিকস
এই পাঠে যা শিখবেন
- ভার্টিকাল ও হরাইজন্টাল প্রিভিলেজ এস্কেলেশনের পার্থক্য, বাস্তব উদাহরণসহ
- প্রিভিলেজ এস্কেলেশনের সবচেয়ে সাধারণ চারটি কারণ
- Principle of Least Privilege ঠিক কী এবং কেন এটি সবচেয়ে কার্যকর প্রতিরক্ষা
- একটি নিরাপদ কোড সিমুলেশনে মিসকনফিগার্ড ফাইল-পারমিশনের কারণে এস্কেলেশন কীভাবে ঘটে তা দেখা এবং ফিক্স করা
১ · ভার্টিকাল বনাম হরাইজন্টাল প্রিভিলেজ এস্কেলেশন
একবার আক্রমণকারী কোনোভাবে (ফিশিং, একটি দুর্বল ওয়েব অ্যাপ, বা অন্য কোনো পথে) প্রাথমিক অ্যাক্সেস পেয়ে যায়, সেই অ্যাক্সেস প্রায়ই কম-প্রিভিলেজ পর্যায়ের হয়। পরবর্তী লক্ষ্য থাকে প্রিভিলেজ এস্কেলেশনPrivilege Escalationএকজন আক্রমণকারী তার প্রাথমিক অ্যাক্সেসের চেয়ে বেশি পারমিশন/ক্ষমতা অর্জন করার প্রক্রিয়া। — যা দুটি ভিন্ন দিকে ঘটতে পারে।
কম-প্রিভিলেজ ব্যবহারকারী থেকে admin/root-এর মতো উচ্চতর প্রিভিলেজ অর্জন করা — একটি "নিচ থেকে উপরে" মুভমেন্ট।
একই প্রিভিলেজ-স্তরে থেকেই অন্য একজন ব্যবহারকারীর সমান-প্রিভিলেজের রিসোর্স/ডেটা অ্যাক্সেস করা — এটি মূলত L18-এ শেখা IDOR-এর মতোই একটি বিশেষ ক্ষেত্র।
২ · সাধারণ কারণ
- মিসকনফিগার্ড ফাইল/সার্ভিস পারমিশন — এমন একটি ফাইল বা সার্ভিস যা ভুলবশত কম-প্রিভিলেজ ব্যবহারকারীকে পরিবর্তন/নিয়ন্ত্রণ করার অনুমতি দিয়ে দেয়, যদিও তার সেই অনুমতি পাওয়ার কথা নয়।
- আনপ্যাচড লোকাল কার্নেল এক্সপ্লয়েট — অপারেটিং সিস্টেমের কার্নেলে থাকা একটি পরিচিত কিন্তু আনপ্যাচড দুর্বলতা, যা স্থানীয়ভাবে ব্যবহার করে সরাসরি root/system প্রিভিলেজ পাওয়া যায়।
- স্ক্রিপ্ট/কনফিগ ফাইলে এক্সপোজড ক্রেডেনশিয়াল — একটি অ্যাডমিন স্ক্রিপ্ট বা কনফিগ ফাইলে প্লেইনটেক্সট পাসওয়ার্ড/API কী রেখে দেওয়া, যা কম-প্রিভিলেজ ব্যবহারকারীও পড়তে পারে যদি ফাইল পারমিশন সঠিকভাবে সীমাবদ্ধ না থাকে।
- উচ্চ-প্রিভিলেজে চলা সিডিউলড টাস্ক — একটি scheduled task/cron job যা root/admin অ্যাকাউন্টে চলে, কিন্তু তার স্ক্রিপ্ট ফাইলটি কম-প্রিভিলেজ ব্যবহারকারীর জন্যও লেখার (write) অনুমতিসহ রেখে দেওয়া হয় — আক্রমণকারী সেই স্ক্রিপ্ট পরিবর্তন করে দিলে তার কোড উচ্চ-প্রিভিলেজে চলে যায়।
৩ · প্রতিরক্ষা — Principle of Least Privilege
প্রতিটি ব্যবহারকারী, অ্যাকাউন্ট বা প্রসেসকে শুধুমাত্র তার কাজের জন্য প্রয়োজনীয় ন্যূনতম পারমিশন দেওয়া উচিত, এর বেশি কিছু নয়। একটি ব্যাকআপ স্ক্রিপ্টের শুধু নির্দিষ্ট ফোল্ডার পড়ার অ্যাক্সেস প্রয়োজন, পুরো সিস্টেম-প্রশাসকের অ্যাক্সেস নয়। এই নীতি কঠোরভাবে মানলে, কোনো একটি অ্যাকাউন্ট বা প্রসেস কম্প্রোমাইজ হলেও আক্রমণকারীর সেখান থেকে এস্কেলেট করার সুযোগ ব্যাপকভাবে সীমিত হয়ে যায় — এটি "blast radius" ছোট রাখার মূল কৌশল। এর সাথে নিয়মিত পারমিশন অডিট (কে কীসের অ্যাক্সেস পেয়েছে তা পর্যায়ক্রমে পুনর্মূল্যায়ন) যোগ হলে, সময়ের সাথে জমে থাকা "প্রয়োজনের চেয়ে বেশি" পারমিশন খুঁজে বের করে সংশোধন করা যায়।
৪ · কোড ডেমো — মিসকনফিগার্ড ফাইল-পারমিশনের কারণে এস্কেলেশন
নিচের কোড সেলটি সম্পূর্ণ নিরাপদ ও ইন-মেমরি — এটি একটি টয় "ফাইলসিস্টেম-পারমিশন" মডেল সিমুলেট করছে, কোনো বাস্তব ফাইল বা সিস্টেমকে স্পর্শ না করেই।
def can_modify(filesystem, file_path, user):
return user in filesystem[file_path]["allowed_writers"]
def attempt_escalation(filesystem, file_path, low_priv_user):
if can_modify(filesystem, file_path, low_priv_user):
owner = filesystem[file_path]["runs_as"]
return f"এস্কেলেশন সফল — {low_priv_user} এই ফাইল পরিবর্তন করে '{owner}' প্রিভিলেজে কোড চালাতে পারবে"
return f"এস্কেলেশন ব্যর্থ — {low_priv_user}-এর এই ফাইল পরিবর্তনের অনুমতি নেই"
# পরিস্থিতি ১: মিসকনফিগার্ড — root-এ চলা সিডিউলড টাস্ক স্ক্রিপ্টে ভুলবশত সবাইকে লেখার অনুমতি দেওয়া হয়েছে
insecure_filesystem = {
"/etc/cron.d/daily-backup.sh": {
"runs_as": "root",
"allowed_writers": ["root", "backup-admin", "intern_rahim"], # ভুলবশত কম-প্রিভিলেজ ব্যবহারকারীও যোগ হয়ে গেছে
}
}
# পরিস্থিতি ২: সঠিকভাবে কনফিগার করা — শুধু root ও অথরাইজড অ্যাডমিন লিখতে পারবে
secure_filesystem = {
"/etc/cron.d/daily-backup.sh": {
"runs_as": "root",
"allowed_writers": ["root", "backup-admin"], # কম-প্রিভিলেজ ব্যবহারকারী বাদ
}
}
print("মিসকনফিগার্ড সিস্টেমে:", attempt_escalation(insecure_filesystem, "/etc/cron.d/daily-backup.sh", "intern_rahim"))
print("ফিক্সড সিস্টেমে: ", attempt_escalation(secure_filesystem, "/etc/cron.d/daily-backup.sh", "intern_rahim"))daily-backup.sh স্ক্রিপ্টটি root প্রিভিলেজে চলে, এবং সেই তথ্য একই।
পার্থক্যটা শুধু allowed_writers লিস্টে — মিসকনফিগার্ড সিস্টেমে intern_rahim ভুলবশত
লেখার অনুমতি পেয়ে গেছে, যা তাকে root-এ চলা একটি স্ক্রিপ্ট পরিবর্তন করে পরোক্ষভাবে root প্রিভিলেজে কোড
চালানোর সুযোগ দেয়। ফিক্সড সংস্করণে এই একই ভুল সংশোধন করা হয়েছে শুধু allowed_writers লিস্ট থেকে অননুমোদিত
ব্যবহারকারী বাদ দিয়ে — এটাই Principle of Least Privilege-এর ব্যবহারিক প্রয়োগ।
L01-এর নীতি অনুযায়ী — প্রিভিলেজ এস্কেলেশন কৌশল অনুশীলন করুন শুধুমাত্র নিজের ল্যাব পরিবেশ বা অনুমোদিত CTF/পেনিট্রেশন-টেস্ট পরিবেশে। কোনো বাস্তব সিস্টেমে লিখিত অনুমতি ছাড়া প্রিভিলেজ এস্কেলেশনের চেষ্টা করা একটি গুরুতর ফৌজদারি অপরাধ, এমনকি যদি উদ্দেশ্য শুধু "দুর্বলতা প্রমাণ করা" হয়।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ হরাইজন্টাল প্রিভিলেজ এস্কেলেশন ও L18-এর IDOR-এর মধ্যে সম্পর্ক কী?
দুটোই একই মূল সমস্যা শেয়ার করে — সার্ভার ঠিকমতো যাচাই করে না যে অনুরোধকারী ব্যবহারকারী আসলেই সেই নির্দিষ্ট রিসোর্সের মালিক কি না। IDOR সাধারণত এই সমস্যাকে ওয়েব-অ্যাপ-লেভেলে (যেমন অর্ডার আইডি বদলানো) বর্ণনা করে, আর হরাইজন্টাল এস্কেলেশন একই ধরনের সমস্যাকে বৃহত্তর সিস্টেম-প্রেক্ষাপটে (যেমন একই সার্ভারে অন্য ব্যবহারকারীর ফাইল অ্যাক্সেস) বর্ণনা করে — উভয় ক্ষেত্রেই সমাধান একই: প্রতিটি অ্যাক্সেস-অনুরোধে server-side ownership যাচাই।
প্র ০২ উচ্চ-প্রিভিলেজে চলা সিডিউলড টাস্ক কেন প্রিভিলেজ এস্কেলেশনের এত ক্লাসিক একটি পথ?
কারণ এটি স্বয়ংক্রিয়ভাবে, নিয়মিত বিরতিতে চলে — আক্রমণকারীকে কোনো ইন্টারঅ্যাকশন ট্রিগার করতে হয় না, শুধু স্ক্রিপ্ট ফাইলটি একবার পরিবর্তন করে অপেক্ষা করলেই পরবর্তী শিডিউলে সেটি স্বয়ংক্রিয়ভাবে উচ্চ প্রিভিলেজে চলে যায়। অনেক সিস্টেম প্রশাসক স্ক্রিপ্ট ফাইলের "চলে কে" (runs_as) ঠিকমতো সেট করলেও ফাইলটি "কে পরিবর্তন করতে পারবে" তা যাচাই করতে ভুলে যান — ঠিক এই ফাঁকটাই কোড ডেমোতে দেখানো হয়েছে।
প্র ০৩ Principle of Least Privilege মেনে চললেও কি একজন আক্রমণকারী প্রাথমিক অ্যাক্সেস পেতে পারে? তাহলে এই নীতি আসলে কী রক্ষা করে?
হ্যাঁ, Least Privilege প্রাথমিক অ্যাক্সেস (initial foothold) ঠেকানোর নীতি নয় — সেটা অন্য প্রতিরক্ষার (পাসওয়ার্ড নিরাপত্তা, প্যাচিং, ফিশিং-সচেতনতা) কাজ। Least Privilege রক্ষা করে একবার আক্রমণকারী কিছু একটা অ্যাক্সেস পেয়ে গেলে সেখান থেকে সে কতটা এগোতে পারবে — অর্থাৎ "blast radius" সীমিত রাখে। এই কারণেই এটিকে defense-in-depth-এর একটি স্তর বলা হয়, একমাত্র সমাধান নয়।
অনুশীলন
-
পরীক্ষা করুন: কোড সেলে
secure_filesystem-এরallowed_writers-এ ভুলবশত আবার"intern_rahim"যোগ করে চালান — ফলাফল কী দেখায়, এবং এটি বাস্তব জীবনে কেন গুরুত্বপূর্ণ শিক্ষা?ফলাফল আবার "এস্কেলেশন সফল" দেখাবে — কারণ ফাংশনটি শুধু লিস্টের বর্তমান অবস্থা দেখে, "উদ্দেশ্য" কী ছিল তা জানে না। এটি দেখায় নিরাপত্তা নির্ভর করে কনফিগারেশনের প্রকৃত বর্তমান অবস্থার উপর, অতীতে কী ঠিক করা হয়েছিল তার উপর নয় — এই কারণেই নিয়মিত, স্বয়ংক্রিয় পারমিশন অডিট প্রয়োজন, একবারের ম্যানুয়াল ফিক্স যথেষ্ট নয়।
-
চিন্তা করুন: কোনটি সাধারণত খুঁজে বের করা কঠিন — একটি মিসকনফিগার্ড ফাইল-পারমিশন, নাকি একটি আনপ্যাচড কার্নেল এক্সপ্লয়েট? এবং কেন?
সাধারণত মিসকনফিগারেশন খুঁজে বের করা তুলনামূলক সহজ (স্বয়ংক্রিয় পারমিশন-অডিট টুল দিয়ে স্ক্যান করা যায়), যেখানে আনপ্যাচড কার্নেল এক্সপ্লয়েট শনাক্ত করতে জানতে হবে ঠিক কোন CVE প্রযোজ্য এবং প্যাচ লাগানো হয়েছে কি না তা ট্র্যাক করতে হয় (ties to L14-L16)। তবে বাস্তবে মিসকনফিগারেশনই বেশি সাধারণ কারণ, কারণ এটি মানুষের ভুল থেকে আসে এবং প্রতিদিন নতুন কনফিগ পরিবর্তন হতেই থাকে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৬০টি পাঠ পরবর্তী পাঠ — বাফার ওভারফ্লো পরিচিতি।
- Discrete Mathematics কোর্স সহায়ক কোর্স RSA এনক্রিপশন ও নাম্বার থিওরির গণিত শিখতে দেখুন — M7 ক্রিপ্টোগ্রাফি মডিউলের ভিত্তি।
- System Design & Software Architecture কোর্স সঙ্গী কোর্স অ্যাক্সেস কন্ট্রোল ও পারমিশন মডেল কীভাবে বড় সিস্টেমে ডিজাইন করা হয় তা শিখতে দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design ও Cybersecurity — সব এক জায়গায়।