নিরবচ্ছিন্ন ইন্টিগ্রেশন এবং নিরবচ্ছিন্ন ডেপ্লয়মেন্ট (CI/CD) pipelineসুসংহত সফটওয়্যার উন্নয়ন সহজতর করতে গুরুত্বপূর্ণ ভূমিকা পালন করে। তবুও, যেহেতু এই pipelineযেহেতু বিষয়গুলো ক্রমশ আরও গুরুত্বপূর্ণ হয়ে উঠছে, তাই সেগুলোকে দুর্বলতা থেকে রক্ষা করার আবশ্যকতা আরও প্রকট হচ্ছে। এই গভীর অনুসন্ধানটি OWASP টপ-১০-এ চিহ্নিত একটি প্রধান ঝুঁকি মোকাবেলার উপর আলোকপাত করে। CI/CD নিরাপত্তা ঝুঁকি: বিষাক্ত Pipeline বাস্তবায়ন (PPE)।
বিষক্রিয়া কি Pipeline মৃত্যুদণ্ড (PPE)
OWASP শীর্ষ-১০ অনুসারে CI/CD নিরাপত্তা ঝুঁকি, “বিষাক্ত Pipeline ফাঁসি (PPEঝুঁকি বলতে বোঝায় সোর্স কন্ট্রোল সিস্টেমে প্রবেশাধিকার থাকা কোনো আক্রমণকারীর সক্ষমতা – কিন্তু বিল্ড এনভায়রনমেন্টে তার কোনো প্রবেশাধিকার নেই – বিল্ড প্রক্রিয়ায় ক্ষতিকারক কোড/কমান্ড প্রবেশ করিয়ে তাকে প্রভাবিত করা pipeline কনফিগারেশনমূলত 'বিষ প্রয়োগ' pipeline এবং বিল্ড প্রক্রিয়ার অংশ হিসেবে ক্ষতিকারক কোড চালানো।
সংক্ষেপে, বিষাক্ত Pipeline কার্য সম্পাদন (PPE) তৈরি হয় যখন আক্রমণকারী পরিবর্তন করতে পারে pipeline যুক্তিবিদ্যা.
দুই আছে রূপগুলো:
- সরাসরি পিপিই (ডি-পিপিই): একটি D-PPE পরিস্থিতিতে, আক্রমণকারী CI কনফিগারেশন ফাইলটি পরিবর্তন করে যে রিপোজিটরিতে তাদের অ্যাক্সেস আছে, সেখানে হয় সরাসরি রিপোটির একটি অসুরক্ষিত রিমোট ব্রাঞ্চে পরিবর্তনটি পুশ করে, অথবা কোনো ব্রাঞ্চ বা ফর্ক থেকে পরিবর্তনসহ একটি পিআর (PR) জমা দিয়ে পরিবর্তনটি করা যায়। যেহেতু সিআই pipeline পরিবর্তিত CI কনফিগারেশন ফাইলের কমান্ডগুলো দ্বারা এক্সিকিউশন নির্ধারিত হয়, আক্রমণকারীর ক্ষতিকারক কমান্ডগুলো অবশেষে বিল্ড নোডে রান করে। pipeline আলোড়ন সৃষ্টি হয়.
- পরোক্ষ PPE (আই-পিপিইকিছু ক্ষেত্রে, কোনো প্রতিপক্ষের কাছে অ্যাক্সেস থাকা সত্ত্বেও ডি-পিপিই (D-PPE) এর সম্ভাবনা উপলব্ধ থাকে না। SCM সংগ্রহস্থল (যেমন যদি pipeline একই রিপোজিটরিতে থাকা একটি আলাদা, সুরক্ষিত শাখা থেকে CI কনফিগারেশন ফাইলটি পুল করার জন্য কনফিগার করা হয়েছে)। এমন পরিস্থিতিতে, বিষ প্রয়োগের পরিবর্তে pipeline আক্রমণকারী নিজেই রেফারেন্সকৃত ফাইলগুলিতে ক্ষতিকারক কোড প্রবেশ করায়। pipeline (উদাহরণস্বরূপ: এর ভেতর থেকে রেফারেন্স করা স্ক্রিপ্টগুলো) pipeline কনফিগারেশন ফাইল)
উভয় ক্ষেত্রেই, গিটহাব পরিবর্তিত সংস্করণটি কার্যকর করবে pipeline পূর্ববর্তী পর্যালোচনা বা অনুমোদনের কোনো প্রয়োজন ছাড়াই.
পিপিই-এর প্রাথমিক সনাক্তকরণ
আমরা কীভাবে এই ধরনের দুর্বলতা শনাক্ত করতে পারি?
চলুন এই উদাহরণটি দেখি। pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_SECRET
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.login }}" "${{ github.workflow }}"
echo Tests executed.
এবং একটি ডামি শেল স্ক্রিপ্টের (runtests.sh) বিষয়বস্তু:
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
সার্জারির pipeline বিষয়টি বেশ সহজ: এর উদ্দেশ্য হলো পর্যালোচককে কিছু প্রাথমিক ইঙ্গিত প্রদান করা। Pull Request (পিআর) গ্রহণ প্রক্রিয়া:
- এটি চালু হবে পুল_রিকোয়েস্ট (অর্থাৎ যখনই একটি পিআর তৈরি করা হয়)
- এটি পিআর কোড (অর্থাৎ অবদানকৃত কোড) চেক করে।
- এটি নির্মাণ করবে
- এটি অবদানকৃত কোডের উপর পরীক্ষা চালাবে (যেমন একটি শেল স্ক্রিপ্ট এক্সিকিউট করার মাধ্যমে)।
ধাপ #৩ (বিল্ড তৈরি করা) এবং #৪ (টেস্ট চালানো) ব্যর্থ হবে যদি কোডটি কম্পাইল না হয় বা টেস্টগুলোতে উত্তীর্ণ হতে না পারে। সুতরাং, এই ধাপগুলো PR গ্রহণ করার জন্য একটি প্রয়োজনীয়, কিন্তু যথেষ্ট নয়, শর্ত হিসেবে কাজ করে। সফল হলে, রিপো অ্যাডমিন জমা দেওয়া কোডটি পর্যালোচনা করতে অগ্রসর হবেন এবং তার উপর ভিত্তি করে তিনি PR-টি গ্রহণ/প্রত্যাখ্যান/মন্তব্য করবেন।
জাইজেনি স্ক্যানার
জাইজেনি একটি CLI প্রদান করে ( "জাইজেনি স্ক্যানার”) যা একটিতে স্থাপন করা যেতে পারে pipeline অথবা কমান্ড-লাইনে চালান। জাইজেনি স্ক্যানারটি প্রক্রিয়া করবে pipelineএটি দুর্বলতা পরীক্ষা করে এবং, যদি একটি GitHub PAT প্রদান করা হয়, তবে এটি org/repo স্তরে দুর্বলতা খুঁজে বের করার জন্য GitHub-এর সাথে সংযোগ স্থাপন করবে।
জাইজেনি ইনভেন্টরি
যখন আমরা এই রেপোতে জাইজেনি স্ক্যানার চালাই, তখন এটি একগুচ্ছ দরকারি অ্যাসেট খুঁজে পায় ( জাইজেনি ইনভেন্টরিইনভেন্টরিটি বিভিন্ন ধরণের জিনিস দিয়ে পূর্ণ করা হবে। CI/CD সম্পদ, যেমন:
- সার্জারির SCM পদ্ধতি যেখানে রিপোটি সংরক্ষিত আছে
- সার্জারির SCM প্লাগইন ইনস্টল/ব্যবহৃত
- সার্জারির কোড রিপোজিটরি নিজেই
- সার্জারির SCM সংগঠন যেখানে রিপোটি অন্তর্গত
- সার্জারির CI/CD Pipelineচাকরি এবং
- সার্জারির CI/CD পদ্ধতি চলমান pipelines
- IaC Resources রেপোতে সংজ্ঞায়িত করা হয়েছে
- বহিরাগত নির্ভরতা
- ইত্যাদি ..
আমাদের উদাহরণে, আমরা কিছু নির্দিষ্ট অ্যাসেট টাইপ (সম্পদের ধরণ) দ্বারা ইনভেন্টরি ফিল্টার করতে পারি।SCM- এবং CICD-সম্পর্কিত সম্পদ), সুতরাং আমরা দেখতে পাচ্ছি যে:
- SCM সিস্টেমটি হলো গিটহাব ক্লাউড
- রিপোটি গিটহাব ক্লাউডে সংরক্ষিত থাকে এবং এটি একটি নির্দিষ্ট গিটহাব অর্গানাইজেশনের অন্তর্গত।
- দুই আছে pipelineগিটহাব দ্বারা চালিত (CI/CD পদ্ধতি)
- প্রতি pipeline এতে একটি নির্দিষ্ট ধাপ রয়েছে
উপরের নির্বাচন করে pipeline আমরা কিছু দুর্বলতা দেখতে পাচ্ছি:
- At pipeline এই স্তরে, এটি উভয়ের প্রতিই ঝুঁকিপূর্ণ। সরাসরি এবং পরোক্ষ PPE।
আমরা বিষক্রিয়ায় আক্রান্তদের বিস্তারিত দেখতে পারি। Pipeline এক্সিকিউশন দুর্বলতা
জাইজেনি শনাক্ত করে যে এটি ডি-পিপিই-এর প্রতি ঝুঁকিপূর্ণ কারণ এটি একটিতে ট্রিগার হয় Pull Request এবং কোনো অতিরিক্ত নিরাপত্তা নিয়ন্ত্রণ না থাকায় যেকোনো রিপো ব্যবহারকারী ইভেন্টটি পরিবর্তন করতে পারে। pipeline এবং সেই পরিবর্তনগুলো কোনো পর্যালোচনা বা অনুমোদন ছাড়াই কার্যকর করা হবে।
একইভাবে, জাইজেনিও শনাক্ত করে যে এটি আই-পিপিই-এর প্রতি ঝুঁকিপূর্ণ শেল স্ক্রিপ্টটি কল করার কারণে pipelineযেকোনো রিপো ব্যবহারকারী শেল স্ক্রিপ্টটি পরিবর্তন করতে পারবেন এবং সেই পরিবর্তনগুলো কোনো পর্যালোচনা বা অনুমোদন ছাড়াই কার্যকর হবে।
আপনি আরও জানতে চান?
পিপিই-র অপব্যবহার
PPE-কে কাজে লাগানোর জন্য, আসুন এমন একটি পরিস্থিতি বিবেচনা করি যেখানে রয়েছে দুই ধরণের রিপো ব্যবহারকারী:
- An অভ্যন্তরীণ ব্যবহারকারী (ঐ রিপোটিতে কর্মরত একজন অভ্যন্তরীণ ডেভেলপার), যার রিপোটিতে লেখার অনুমতি রয়েছে।
- An বহিরাগত ব্যবহারকারী (একজন আউটসোর্সড ডেভেলপার ওই রিপোজিটরিতে কাজ করছেন, কিন্তু তার শুধু পড়ার অনুমতি (রিড পারমিশন) আছে), অর্থাৎ তাকে রিপোজিটরিতে ব্রাঞ্চ তৈরি করার অনুমতি নেই এবং একটি ফর্কে কাজ করতে বাধ্য করা হচ্ছে।
ধরা যাক, উভয়ই বিদ্বেষপরায়ণ আক্রমণকারী (অথবা কোনো বিদ্বেষপরায়ণ ব্যক্তি দ্বারা ছদ্মবেশ ধারণকৃত)। রিপোজিটরিটিতে কিছু গোপনীয় তথ্য রয়েছে এবং উভয়ই তা চায়। রিপো গোপনীয়তা চুরি করতে এবং এটি একটি হ্যাকার-নিয়ন্ত্রিত সার্ভারে পাঠাবে। এটি করার জন্য, তারা Poisoned-এর সুযোগ নেবে। Pipeline এক্সিকিউশন দুর্বলতা pipeline.
উভয় ক্ষেত্রেই (বহিরাগত এবং অভ্যন্তরীণ ব্যবহারকারী), তারা একটি খোলে Pull Request একই পরিবর্তন সহ:
- সার্জারির pipeline এবং শেল স্ক্রিপ্ট পরিবর্তন করা হয়েছে থেকে গোপন রহস্যটি পড়ুন পরিবেশ থেকে এবং এটি একটি হ্যাকার-নিয়ন্ত্রিত সার্ভারে পাঠান
পরিবর্তনগুলো নিম্নরূপ হতে পারে:
উভয় ব্যবহারকারী একটি তৈরি করবে Pull Request পরিবর্তন সহপিআর তৈরি করার পর, গিটহাব উভয় পরিবর্তনই কার্যকর করবে। (পূর্ব পর্যালোচনা বা অনুমোদনের প্রয়োজন ছাড়াই)যার ফলে নিম্নলিখিত বিষয়গুলো ঘটেছে:
লেখা ও পড়ার ব্যবহারকারীদের ক্ষেত্রেও একই, উভয় ক্ষেত্রেই ডি-পিপিই এবং আই-পিপিই প্রয়োগ করা হয়।পার্থক্যটা হলো এই যে পঠন ব্যবহারকারী গোপনীয় তথ্য অ্যাক্সেস করতে পারবে না। (!!!!)
এর কারণ হলো, ফর্ক থেকে আসা পিআর-এর ক্ষেত্রে, গিটহাব রিপো সিক্রেটস-এ অ্যাক্সেস দেয় না। যদিও রিড ইউজার গোপনীয় তথ্য পড়তে পারে না, তবুও সে অন্য যেকোনো প্রোগ্রাম চালাতে পারে। আক্রমণের একটি সাধারণ উদাহরণ হলো এমন পিআর (PR) তৈরি করা যা একটি ক্রিপ্টো মাইনার ডাউনলোড করে, ফলে একটি পয়জনড (poisoned) প্রোগ্রাম চালানোর সময় গিটহাব রানারটি ক্রিপ্টো মাইনারটি চালু করে দেবে। pipeline.
অবশ্যই, এটি কোনো নিরাপদ পরিবেশ নয়!! এটি এড়ানোর জন্য রিপো অ্যাডমিন কী করতে পারেন?
গুগলে কিছুক্ষণ খোঁজাখুঁজি করার পর, রিপো অ্যাডমিন পরিবর্তন করার সিদ্ধান্ত নেন। pipeline একটিতে সক্রিয় হতে পুল_রিকোয়েস্ট_টার্গেট ঘটনা। কেন? কারণ pipelinepull_request_target-এ ট্রিগার হওয়া s কার্যকর করার অনুমতি দেয় না। pipeline পরিবর্তনঅর্থাৎ, ব্যবহারকারীর যেকোনো পরিবর্তন সত্ত্বেও “আসল” pipeline কার্যকর করা হবে।
আমাদের উদাহরণ অনুসরণ করলে, আক্রমণটি আগের মতোই হবে। এরপর কী ঘটবে? pipeline পরিবর্তন?
প্রত্যাশিত, ডি-পিপিই কার্যকর করা হয়নি কিন্তু, যেহেতু আই-পিপিই এখনও আছে, রিড ইউজার এখন রিপো সিক্রেট অ্যাক্সেস করতে পারবে!!!
কী কারণে রিড ইউজার এখন সিক্রেট অ্যাক্সেস পেয়েছে? যদিও pipeline পরিবর্তন করা যাবে না, তবে শেল স্ক্রিপ্টটি পরিবর্তন করা সম্ভব। যখন একটি pipeline `pull_request_target`-এ ট্রিগার হলে, এটি প্রিভিলেজড মোডে এক্সিকিউট হবে। so এটি শেল স্ক্রিপ্টও হবেযার ফলে শেল স্ক্রিপ্টটি রিপো সিক্রেটগুলিতে অ্যাক্সেস পেয়ে যায়!!
প্রতিরোধমূলক ব্যবস্থা
ক্ষতিকর পিআর (PR) থেকে সুরক্ষার জন্য গিটহাব কিছু ব্যবস্থা প্রদান করে।
শাখা সুরক্ষার নিয়ম
গিটহাবের মাধ্যমে আপনি নির্বাচিত ব্রাঞ্চগুলোর জন্য ব্রাঞ্চ প্রোটেকশন রুলস নির্ধারণ করতে পারেন।
আপনার সুরক্ষিত শাখাগুলির জন্য আপনি এমন একটি নীতি নির্দিষ্ট করতে পারেন যা প্রয়োজন একটি pull request একীভূত করার আগে (পাশাপাশি অতিরিক্ত শর্তাবলী, যেমন প্রয়োজনীয় সংখ্যক অনুমোদন, কোড মালিকদের পর্যালোচনা, ইত্যাদি।)
বিশেষ বিবেচনার যোগ্য কয়েকটি শর্ত হলো:
- "নির্দিষ্ট অভিনেতাদের প্রয়োজনীয়তা এড়িয়ে যাওয়ার অনুমতি দিন pull requests".
- "উপরের সেটিংসগুলো বাইপাস করার অনুমতি দেবেন না।"
যদিও বেশিরভাগ শর্তই নীতিমালায় কঠোরতা যোগ করে, এই শর্তগুলো নীতিমালাটিকে শিথিল করে এবং এর ফলে ক্ষতিকর কার্যকলাপের জন্য একটি সুযোগ তৈরি হতে পারে, উদাহরণস্বরূপ, যদি “সুবিধাপ্রাপ্ত” ব্যক্তিরা ক্রেডেনশিয়াল চুরি করে নেয়।
GITHUB_TOKEN-এর অনুমতি সীমিত করুন (সর্বনিম্ন বিশেষাধিকার)
গিটহাব টোকেনের অনুমতি শুধুমাত্র প্রয়োজনীয়গুলোর মধ্যে সীমাবদ্ধ রাখুন; এইভাবে, আক্রমণকারীরা আপনার সিস্টেমের নিরাপত্তা বিঘ্নিত করতে সফল হলেও, pipelineতারা বেশি কিছু করতে পারবে না।
স্ট্রিং ইন্টারপোলেশন এড়াতে ব্যবহার করুন pipeline পরিবেশ ভেরিয়েবল
যখনই আপনি আপনার ইনপুট ভেরিয়েবল ব্যবহার করেন pipelineমনে রাখবেন যে, এগুলিকে ডিফল্টরূপে “অবিশ্বস্ত” ডেটা হিসাবে বিবেচনা করা উচিত (এগুলির বিষয়বস্তু অন্তিম ব্যবহারকারী দ্বারা নিয়ন্ত্রিত হয়)। দেখুন অবিশ্বস্ত কার্যকলাপ এবং কর্মপ্রবাহ সুরক্ষিত এবং গিটহাব অ্যাকশনস শিখুন।
স্ক্রিপ্টের ভিতরে ইনপুট ভেরিয়েবল যোগ করার জন্য স্ট্রিং ইন্টারপোলেশনের পরিবর্তে সর্বদা এনভায়রনমেন্ট ভেরিয়েবল ব্যবহার করা উচিত।
ওয়ার্কফ্লো পরিচালনা এবং অনুমোদনের প্রয়োজনীয়তা
জন্য প্রকাশ্য রিপো, গিটহাব নির্দিষ্ট করার অনুমতি দেয় “এক্সটার্নাল” পিআর-এর সাথে কীভাবে কাজ করবেন.
গিটহাব অর্গানাইজেশন সেটিংস (“Org >> Settings >> Actions >> General”) এর মাধ্যমে এক্সটার্নাল পিআর (PR) কীভাবে ম্যানেজ করতে হবে তা নির্দিষ্ট করা যায়:
ডিফল্টরূপে, গিটহাব প্রথমবারের মতো অবদান রাখা ব্যক্তিদের জন্য পিআর (PR) অনুমোদনের প্রয়োজন হয়, যা ক্ষতিকারক অনুরোধের আক্রমণকে আরও জটিল করে তোলে। তা সত্ত্বেও, আক্রমণকারী কিছু নিরীহ অবদান রাখার মাধ্যমে প্রজেক্ট রক্ষণাবেক্ষণকারীদের বিশ্বাস অর্জন করতে পারে। pull request আসল আক্রমণের আগে।
এই অর্থে, দ তৃতীয় বিকল্পটি (সকল বহিরাগত সহযোগীর জন্য অনুমোদন আবশ্যক করা) আরও উচ্চ স্তরের নিয়ন্ত্রণ প্রদান করে।
জন্য ব্যক্তিগত রিপো-এর ক্ষেত্রে, গিটহাব অর্গানাইজেশন এবং রিপো উভয় স্তরেই সহায়ক নিয়ন্ত্রণ প্রদান করে।
"ওয়ার্কফ্লো চালান Pull Requests” (ডিফল্টরূপে আনচেক করা) ব্যবহারকারীদের ফর্ক পিআর (PR) থেকে ওয়ার্কফ্লো চালানোর অনুমতি দেয় (শুধুমাত্র পঠনযোগ্য অনুমতি এবং গোপনীয় তথ্যে কোনো অ্যাক্সেস ছাড়া একটি GITHUB_TOKEN ব্যবহার করে)। এই বিকল্পটি আগেরটির (“ফর্ক পিআর ওয়ার্কফ্লোর জন্য অনুমোদনের প্রয়োজন”) , আপনি প্রাইভেট রিপোগুলোর মতো একটি নীতি গ্রহণ করতে পারেন (যেমনটি উপরে দেখানো হয়েছে)।
যেমনটি আমরা একজন রিড ইউজারের পিপিই এক্সপ্লয়েটে দেখেছি, ফর্ক থেকে ওয়ার্কফ্লো চালানোর অনুমতি দেওয়া pull requests অনিরাপদ!!
অবশিষ্ট বিকল্পগুলি (“ফর্ক থেকে ওয়ার্কফ্লোতে রাইট টোকেন পাঠান pull requests" এবং "ওয়ার্কফ্লোতে গোপনীয় তথ্য এবং ভেরিয়েবল পাঠান pull requests") নিরাপত্তা স্তর কমানো ফর্ক পিআর-গুলোতে প্রয়োগ করা হয়েছে।
আপনি এই ফর্ক পলিসিটি অর্গানাইজেশন লেভেলে অথবা রেপো-লেভেলে নির্ধারণ করতে পারেন। যদি পলিসিটি অর্গ-লেভেলে নিষ্ক্রিয় করা থাকে, তবে এটি রেপো-লেভেলে সক্রিয় করা যাবে না। কিন্তু, যদি পলিসিটি অর্গ-লেভেলে সক্রিয় করা থাকে, তবে এটি রেপো-লেভেলে নিষ্ক্রিয় করা যেতে পারে।
সংক্ষিপ্তবৃত্তি
আমরা আশা করি আপনি কিছু থাকার পরিণামগুলো দেখেছেন। pipeline বিষক্রিয়ার ঝুঁকিতে Pipeline বাস্তবায়ন। এটা খুবই সহজ commit একজন দুর্বল pipelineএবং একটি নিরাপদ লেখা কঠিন।
তাই এই ধরনের দুর্বলতা সম্পর্কে সচেতন থাকতে জাইজেনি স্ক্যানার ব্যবহার করা অত্যন্ত মূল্যবান।
কোনো দুর্বলতার অস্তিত্ব সম্পর্কে অবগত না হলে আপনি তা সমাধান করতে পারবেন না!
কিন্তু… এখনও একটি প্রশ্ন অমীমাংসিত রয়ে গেছে… আই-পিপিই কীভাবে এড়ানো যায়?
এটাই হবে আমাদের পরবর্তী পোস্টের বিষয় 🙂 … পরোক্ষ বিষক্রিয়া Pipeline বাস্তবায়ন (আই-পিপিই) !!
