cPGuard আপডেট চ্যানেল হ্যাক: ২,৯৫০ সার্ভারে ব্যাকডোর ও পাসওয়ার্ড চুরি

সারসংক্ষেপ: ২ নভেম্বর ২০২৬-এ cPGuard নামের সার্ভার নিরাপত্তা সফটওয়্যারের আপডেট সিস্টেমে আক্রমণকারী ঢুকে পড়ে এবং গ্রাহকদের সার্ভারে একটি ক্ষতিকর স্ক্রিপ্ট পৌঁছে দেয়। স্ক্রিপ্টটি সার্ভারে ব্যাকডোর বসায় এবং পাসওয়ার্ড হ্যাশ, SSH কী, ডেটাবেস পাসওয়ার্ড—এসব সংবেদনশীল তথ্য চুরি করে পাঠিয়ে দেয়। সংস্থা OPSSHIELD-এর তথ্য অনুযায়ী প্রায় ২,৯৫০টি সার্ভার এই স্ক্রিপ্টটি চালিয়েছে। আপডেট করার পাশাপাশি আক্রান্ত হতে পারে এমন সব সার্ভারে পাসওয়ার্ড ও কী বদলানো অপরিহার্য—কারণ চুরি যাওয়া তথ্য আপডেটের পরেও কাজ করতে পারে।

এই প্রতিবেদনটি OPSSHIELD-এর দুটি অফিসিয়াল নোটিশ (প্রাথমিক সতর্কবার্তা ও বিস্তারিত ঘটনা প্রকাশ), The Hacker News-এর প্রতিবেদন এবং আক্রান্ত শিল্পের সাধারণ নিরাপত্তা-অভ্যাস মিলিয়ে লেখা। প্রতিবেদনের শেষে আপনার সার্ভার আক্রান্ত কি না তা যাচাই করার কমান্ড ও ধাপগুলো দেওয়া আছে।

এক নজরে

• কী আক্রান্ত: cPGuard-এর আপডেট বিতরণ ব্যবস্থা—গ্রাহকদের সার্ভার নয়, বরং সফটওয়্যার সরবরাহের চেইন (supply chain)।
• ক্ষতিকর সংস্করণ: cPGuard ৫.৮৮.১২ থেকে ৫.৮৮.১৯।
• সময়: ২ নভেম্বর ২০২৬, ০২:০৮–০৩:২০ UTC (বাংলাদেশ সময় সকাল ৮:০৮–৯:২০) — প্রায় ৭০ মিনিট।
• ক্ষতিগ্রস্ত সার্ভার: প্রায় ২,৯৫০ (OPSSHIELD-এর হিসাব)।
• বিলিং পোর্টাল অ্যাকাউন্ট: প্রায় ৭,৯০০ গ্রাহকের নাম, প্রতিষ্ঠানের নাম, ঠিকানা, ইমেইল ও পাসওয়ার্ডের bcrypt হ্যাশ চুরি।
• সমাধান: cPGuard ৫.৮৮.২৬ (এবং পরবর্তী একটি আপডেট যা স্ক্রিপ্টের রেখে যাওয়া শিডিউলড টাস্ক মুছে দেয়)।
• শনাক্ত: আপডেট ছাড়ার ১২ ঘণ্টার মধ্যে OPSSHIELD আক্রমণটি ধরতে পারে।

ঘটনাটি কীভাবে ঘটল

OPSSHIELD-এর বিস্তারিত প্রকাশ অনুযায়ী ঘটনাক্রম ছিল এমন (সব সময় UTC):

• ১ নভেম্বর, ১৫:৩৮: আক্রমণকারী OPSSHIELD-এর বিলিং পোর্টাল (manage.opsshield.com) অনুসন্ধান শুরু করে।
• ১ নভেম্বর, ১৬:৩৪: ভুয়া পরিচয়ে একটি গ্রাহক অ্যাকাউন্ট খুলে বিনামূল্যের cPGuard ট্রায়াল নেয়।
• ১ নভেম্বর, ২১:১৭: নিজের সার্ভারে ট্রায়ালটি ইনস্টল করে এজেন্ট কীভাবে লাইসেন্সিং সিস্টেমের সাথে কথা বলে তা পড়াশোনা করে।
• ১ নভেম্বর, ২১:৪০–২১:৫১: cPGuard নিজেই আক্রমণকারীকে দুইবার শনাক্ত করে ব্যান করে—কিন্তু তাতেও সে থামে না।
• ১ নভেম্বর, ২২:৫০: বিলিং পোর্টালের “callback” পেজগুলোতে বিশেষভাবে তৈরি অনুরোধ পাঠায়।
• ১ নভেম্বর, ২২:৫৮: বিলিং ও লাইসেন্সিং সার্ভারে কমান্ড চালানোর ক্ষমতা পেয়ে যায় এবং তথ্য সংগ্রহ শুরু করে।
• ২ নভেম্বর, ০২:০৪–০২:০৯: চুরি করা অ্যাক্সেস কী ব্যবহার করে নকল cPGuard আপডেট আপলোড করে।
• ২ নভেম্বর, ০২:০৮–০৩:২০: গ্রাহক সার্ভারগুলোতে সেই নকল আপডেট ইনস্টল হয়; স্ক্রিপ্টটি রুট (root) অনুমতিতে চলে এবং ফাইলগুলো আক্রমণকারীর সার্ভারে পাঠিয়ে দেয়।
• ২ নভেম্বর, ০২:১৩: আক্রমণকারী OPSSHIELD-এর তিনটি ক্লাউড সার্ভারের কপি তৈরি করে।
• ৩ নভেম্বর: প্রবেশপথ চিহ্নিত করে OPSSHIELD জনসমক্ষে ঘটনা প্রকাশ করে।

কেন এটি ভয়ংকর: “বিশ্বাসের জায়গায়” আঘাত

সাধারণত আমরা ভাবি—নিরাপত্তা সফটওয়্যার মানেই সুরক্ষা। কিন্তু এখানে আক্রমণকারী ওই সফটওয়্যারের আপডেট পথটিকেই অস্ত্র বানিয়েছে। সার্ভার প্রশাসক নিজে কোনো ভুল করেননি; তিনি শুধু নিয়ম মেনে আপডেট নিয়েছেন। ফলে এই ধরনের আক্রমণকে বলে supply chain attack। এর শিক্ষা পরিষ্কার: কোনো সফটওয়্যারের আপডেটও অন্ধভাবে বিশ্বাস করা যায় না—সরবরাহকারীর নিরাপত্তা নিজের নিরাপত্তার অংশ।

স্ক্রিপ্টটি সার্ভারে কী কী পড়েছে

• /etc/shadow ও /etc/passwd — লোকাল ব্যবহারকারীর পাসওয়ার্ড হ্যাশ।
• /root/.ssh — রুটের SSH প্রাইভেট কী, authorized_keys ও known_hosts।
• /root/.my.cnf — যেখানে ছিল, সেখানে MySQL-এর রুট পাসওয়ার্ড।
• রুট ব্যবহারকারীর shell history — যেখানে অনেক সময় টাইপ করা পাসওয়ার্ড বা টোকেন জমে থাকে।
• অল্প কিছু সার্ভারে /root/.s3cfg — ক্লাউড স্টোরেজের কী।

পাশাপাশি স্ক্রিপ্টটি পিছনে রেখে যায়: /var/tmp/.cpg91511_sh (লুকানো, setuid-root শেল), /var/tmp/.i93677/ এবং /etc/cron.d/i93677 (শিডিউলড টাস্ক), এবং /var/tmp/.cpg91511/ (সংগৃহীত ফাইলের ফোল্ডার, যেখানে loot.tgz তৈরি হয়)।

পাসওয়ার্ড হ্যাশ চুরি মানে কী

/etc/shadow-এ পাসওয়ার্ড সরাসরি থাকে না—থাকে একমুখী (one-way) হ্যাশ। সরাসরি ওই হ্যাশ দিয়ে লগইন করা যায় না। কিন্তু সাধারণ, দুর্বল বা আগে ফাঁস হওয়া পাসওয়ার্ডগুলো অফলাইনে অনুমান করে ভেঙে ফেলা সম্ভব। শক্তিশালী ও অনন্য পাসওয়ার্ড ভাঙা কঠিন, তবে ঝুঁকি শূন্য হয় না—তাই আক্রান্ত হতে পারে এমন অ্যাকাউন্টের পাসওয়ার্ড বদলানো বাধ্যতামূলক। আর .my.cnf বা shell history-তে থাকা পাসওয়ার্ড/টোকেন হ্যাশ দিয়ে সুরক্ষিত নয়—সেগুলো সরাসরি ব্যবহারযোগ্য।

আপনার সার্ভার আক্রান্ত কি না—যাচাই করুন

ধাপ ১ — আপডেট লগ দেখুন (সার্ভারে root হিসেবে):

grep 'Successfully updated' /opt/cpguard/logs/install_log

কোনো এন্ট্রিতে ৫.৮৮.১২ থেকে ৫.৮৮.১৯ থাকলে বুঝবেন ওই সার্ভার ক্ষতিকর আপডেট ইনস্টল করেছে। এন্ট্রি থাকা মানে স্ক্রিপ্টটি অবশ্যই চলেছে বা তথ্য পাঠিয়েছে—এমন নিশ্চিত নয়; তবে সার্ভারটিকে ক্ষতিগ্রস্ত ধরেই ব্যবস্থা নিন, এমনকি এখন ৫.৮৮.২৬ চললেও। উল্টোটাও সত্য: লগে কিছু না থাকা, বা লগ অনুপস্থিত/অসম্পূর্ণ থাকা—নিরাপদ প্রমাণ করে না। সন্দেহ হলে OPSSHIELD সাপোর্টে যোগাযোগ করুন।

OPSSHIELD-এর ওয়েবসাইটে সার্ভারের IP বা হোস্টনেম দিয়ে চেক করার একটি ব্যবস্থাও আছে; তবে সেখানে রেকর্ড না থাকা মানে সার্ভার নিরাপদ—এমন নিশ্চয়তা নয়।

এখনই যা করবেন—ধাপে ধাপে

1. আপডেট করুন: প্রতিটি cPGuard সার্ভারে চালান cpgcli update --start।
2. যাচাই করুন: cpgcli --version দিয়ে দেখুন সর্বশেষ সংস্করণ চলছে কি না। ব্যর্থ হলে OPSSHIELD সাপোর্টে জানান।
3. রেখে যাওয়া ফাইল মুছুন: /etc/cron.d/i93677, /var/tmp/.i93677/ এবং /var/tmp/.cpg91511_sh এখনো আছে কি না দেখুন; থাকলে মুছে ফেলুন।
4. পাসওয়ার্ড বদলান: একটি বিশ্বস্ত রিকভারি এনভায়রনমেন্ট থেকে root এবং অন্য সব লোকাল লিনাক্স অ্যাকাউন্টের পাসওয়ার্ড বদলান। অন্য সিস্টেমেও যেসব পাসওয়ার্ড ব্যবহার করা হয়েছিল, সেগুলোও বিশ্বস্ত ডিভাইস থেকে বদলান।
5. ডেটাবেস ও ক্লাউড কী: MySQL রুট পাসওয়ার্ড, /root/.my.cnf-এ থাকা পাসওয়ার্ড, S3 অ্যাক্সেস কী, DigitalOcean টোকেন এবং root shell history-তে থাকা যেকোনো সিক্রেট বদলান।
6. SSH কী: /root/.ssh-এর প্রাইভেট কী নতুন করে তৈরি করুন, পুরোনো পাবলিক কী যেসব সিস্টেমে বিশ্বাস করে সেখান থেকে সরান, এবং authorized_keys-এ অপরিচিত এন্ট্রি আছে কি না দেখুন। যে সার্ভারগুলো এই কী দিয়ে SSH করা যেত, সেগুলোকেও ততক্ষণ ঝুঁকিপূর্ণ ধরুন যতক্ষণ কী বদলানো না হয়।
7. বিলিং পোর্টাল: manage.opsshield.com-এ পাসওয়ার্ড রিসেট করে দুই ধাপের যাচাই (2FA) চালু করুন—এটি সব OPSSHIELD গ্রাহকের জন্য প্রযোজ্য।

সার্ভার নতুন করে বসানো (rebuild) দরকার কি

OPSSHIELD বলছে, এখনকার তথ্য অনুযায়ী রুটিন হিসেবে পুরো সার্ভার রিসেট বা OS রিবিল্ড করা দরকার নেই। তবে তারা স্পষ্ট করেছে—যদি তদন্তে জানা যায় আক্রমণকারী হাতে-কলমে লগইন করেছিল, তাহলে ওই সার্ভারটি ১ নভেম্বরের আগের পরিষ্কার ব্যাকআপ থেকে নতুন করে বসাতে হবে। সন্দেহ থাকলে সাপোর্টের সাথে কেস-বাই-কেস পর্যালোচনা করুন।

OPSSHIELD আরও জানিয়েছে, সতর্কতামূলকভাবে তারা একটি আলাদা আপডেট দিচ্ছে যা আগে যোগ করা সাপোর্ট-অ্যাক্সেস কী (রুটের authorized_keys-এ বসানো OPSSHIELD-এর পাবলিক কী) সরিয়ে দেয়। ওই কী-এর বিপরীত প্রাইভেট কী এই আক্রমণে ফাঁস হয়েছে কি না, তা তারা এখনো জানায়নি—তাই যেসব সার্ভারে সাপোর্ট অ্যাক্সেস দেওয়া হয়েছিল, সেগুলোতে authorized_keys নিজে দেখে নেওয়া ভালো।

ক্ষতিকর ফাইল ও অন্যান্য চিহ্ন (IOC)

• ফাইল: cpguard-v58812-i91511.sh এবং একই নামের b, c, d সংস্করণ।
• SHA-256 (মূল স্ক্রিপ্ট): 2c2acd988da531d133d0e17f245c49bf15781278f837543d18c95e8410eabd38
• SHA-256 (b): ffd7a47f65fa1244429baa936ae94be54676b53d2f88bc39564f24e22011de8a
• SHA-256 (c): d73919af84bf46de941db85e27fd1abc65701ef9ce6cf33bb27c5397f4a41c26
• SHA-256 (d): 6add0201e9a3d02de772d561d05e0da86eb1c538686753b7adcc3aedf7366f77
• ব্যাকডোর শেল: /var/tmp/.cpg91511_sh
• শিডিউলড টাস্ক: /etc/cron.d/i93677, ফোল্ডার /var/tmp/.i93677/
• সংগ্রহ ফোল্ডার: /var/tmp/.cpg91511/, আর্কাইভ loot.tgz
• আক্রমণকারীর প্রধান IP: 94.183.188.91

গুরুত্বপূর্ণ: আপডেট এই ফাইলগুলো মুছে দেয়, তাই আপডেটের পর ফাইল না পাওয়া কোনো প্রমাণ নয় যে স্ক্রিপ্ট চলেনি। এই কারণে লগ যাচাই ও পাসওয়ার্ড বদল—দুটোই করতে হবে।

আমাদের সার্ভারে পরীক্ষা

এই প্রতিবেদন লেখার সময় আমরা আমাদের নিজের সার্ভারটি যাচাই করেছি: সেখানে cPGuard ইনস্টল করা নেই (/opt/cpguard ও cpgcli নেই), ফলে এই আক্রমণে আক্রান্ত হওয়ার প্রশ্নই নেই। পাশাপাশি তালিকাভুক্ত কোনো ক্ষতিকর ফাইল (/var/tmp/.cpg91511_sh, /var/tmp/.i93677/, /etc/cron.d/i93677) পাওয়া যায়নি। আপনার অন্য কোনো সার্ভারে cPGuard থাকলে উপরের ধাপগুলো নিজে করুন বা আমাদের জানান—আমরা যাচাই করে সহায়তা করব।

বড় শিক্ষা: আপডেট নিন, কিন্তু যাচাই করে

• আপডেট অপরিহার্য, কিন্তু অন্ধভাবে নয়: বড় ও অপ্রত্যাশিত আপডেট এলে সরবরাহকারীর অফিসিয়াল নোটিশ মিলিয়ে নিন।
• root-অ্যাক্সেস কমিয়ে রাখুন: যত কম সেবা রুট হিসেবে চলে, তত কম ঝুঁকি।
• শক্তিশালী, আলাদা পাসওয়ার্ড ও কী: প্রতিটি সার্ভারের জন্য আলাদা পাসওয়ার্ড ও SSH কী ব্যবহার করুন—একটি ফাঁস হলে অন্যগুলো বাঁচবে।
• authorized_keys নিয়মিত দেখুন: অপরিচিত পাবলিক কী মানে কেউ ঢোকার দরজা রেখে গেছে।
• লগ রাখুন ও পড়ুন: ইনস্টল লগ, cron ও tmp ফোল্ডার—এই তিন জায়গায় এই ধরনের আক্রমণ সবচেয়ে আগে ধরা পড়ে।
• ব্যাকআপ রাখুন, এবং তা আলাদা জায়গায়: আক্রমণের পর “১ নভেম্বরের আগের পরিষ্কার ব্যাকআপ” কাজে লাগে—অর্থাৎ ব্যাকআপ নিয়মিত ও আলাদা রাখা জরুরি।

সাধারণ কিছু প্রশ্ন

আমার সার্ভারে cPGuard নেই—আমি কি নিরাপদ?

এই নির্দিষ্ট আক্রমণের ক্ষেত্রে হ্যাঁ, কারণ স্ক্রিপ্টটি cPGuard-এর আপডেট চ্যানেল দিয়েই এসেছে। তবে সার্ভারের অন্যান্য নিরাপত্তা (আপডেট, শক্ত পাসওয়ার্ড, 2FA, ব্যাকআপ) আগের মতোই প্রযোজ্য।

আমি OPSSHIELD-এর গ্রাহক—বিলিং পোর্টালের তথ্য ফাঁস হয়েছে কি?

প্রায় ৭,৯০০ অ্যাকাউন্টের নাম, প্রতিষ্ঠানের নাম, ঠিকানা, ইমেইল ও bcrypt হ্যাশ চুরি হয়েছে। তাই manage.opsshield.com-এর পাসওয়ার্ড বদলানো ও 2FA চালু করা জরুরি। ওই একই পাসওয়ার্ড অন্য কোথাও ব্যবহার করলে সেখানেও বদলান।

শুধু cPGuard আপডেট করলেই কি যথেষ্ট?

না। স্ক্রিপ্ট যদি চলে থাকে, তবে চুরি যাওয়া পাসওয়ার্ড ও কী আপডেটের পরেও বৈধ থাকতে পারে। তাই আপডেট + লগ যাচাই + পাসওয়ার্ড ও কী বদল—তিনটিই করতে হবে।

আক্রমণকারীকে চিহ্নিত করা গেছে?

না। OPSSHIELD বলছে আক্রমণকারী অজ্ঞাত। তবে তারা একটি প্রধান IP (94.183.188.91) শনাক্ত করেছে এবং প্রবেশপথ হিসেবে বিলিং অ্যাপ্লিকেশনের দুটি সম্ভাব্য দুর্বলতা প্যাচ করেছে।

সূত্র

• OPSSHIELD — cPGuard Security Advisory: Update Channel Compromise (৩ নভেম্বর ২০২৬)
• OPSSHIELD — Security Incident Disclosure: manage.opsshield.com
• The Hacker News — cPGuard Update Channel Hijacked to Backdoor Linux Servers and Collect Password Hashes

নোট: এই প্রতিবেদনের তথ্য OPSSHIELD-এর অফিসিয়াল নোটিশ ও The Hacker News-এর প্রতিবেদন থেকে নেওয়া। ঘটনাটি তদন্তাধীন, তাই OPSSHIELD-এর নিজস্ব তথ্যও পরবর্তীতে পরিবর্তিত হতে পারে।

আপনার সার্ভার আপডেট, SSH কী ব্যবস্থাপনা, ব্যাকআপ বা নিরাপত্তা নিয়ে সহায়তা দরকার হলে আমাদের সাথে যোগাযোগ করুন। দেখুন Server Configuration & Management, VPS Hosting এবং Backup Policy।