প্রযুক্তি ও উদ্ভাবন

PaperCut সার্ভারে সক্রিয় হামলা: প্রথম প্যাচ দিলেও আবার আপডেট করতে হবে

|লেখক: QUASA সম্পাদকীয় দল|4 মিনিটের পাঠ| 10
PaperCut সার্ভারে সক্রিয় হামলা: প্রথম প্যাচ দিলেও আবার আপডেট করতে হবে

PaperCut NG ও PaperCut MF সার্ভারের দুটি দুর্বলতা সক্রিয় হামলায় ব্যবহৃত হচ্ছে। ২৮ আগস্ট PaperCut Emergency Patch Release 2 প্রকাশ করে প্রথম জরুরি প্যাচ বসানো গ্রাহকদেরও আবার আপডেট করতে বলেছে; প্রতিষ্ঠানটির হালনাগাদ নিরাপত্তা বুলেটিনে নিশ্চিত গ্রাহক-ঘটনা, চলমান তদন্ত, প্রভাবিত সংস্করণ এবং দ্বিতীয় প্যাচের তথ্য রয়েছে।

ঝুঁকিটি শুধু তাত্ত্বিক নয়। ২৮ আগস্টের NHS England সাইবার সতর্কতা CVE-2026-81578 ও CVE-2026-82078-এর সক্রিয় শোষণের খবর দিয়েছে এবং আরও শোষণ চলার সম্ভাবনাকে অত্যন্ত বেশি বলে মূল্যায়ন করেছে। তাই PaperCut পরিচালনাকারী প্রতিষ্ঠানের প্রথম অগ্রাধিকার হলো Release 2 বসানো এবং সার্ভারের ওয়েব ইন্টারফেসকে অবিশ্বস্ত ইন্টারনেট ঠিকানা থেকে বিচ্ছিন্ন করা।

দুটি CVE মিলে যেভাবে কোড চালানোর পথ তৈরি করে

PaperCut NG/MF-এ অননুমোদিত request কনফিগারেশন বদলে server process-এ Java code চালানোর পথ তৈরি করছে

CVE-2026-81578 হলো PaperCut NG/MF-এর ওয়েব ম্যানেজমেন্ট ইন্টারফেসে improper access control দুর্বলতা। নির্দিষ্ট পরিস্থিতিতে দূরবর্তী অননুমোদিত request প্রবেশাধিকার যাচাই শেষ হওয়ার আগেই প্রশাসনিক backend action চালু করতে পারে। এতে আক্রমণকারী নির্দিষ্ট system configuration পরিবর্তনের সুযোগ পায়। এর CVSS v4 স্কোর ৮.৮।

CVE-2026-82078 রয়েছে database connection utility-তে। কনফিগারেশনে থাকা driver name অনুমোদিত তালিকার সঙ্গে যাচাই না করেই সংশ্লিষ্ট class লোড করা হতে পারে। কোনো আক্রমণকারী প্রয়োজনীয় configuration parameter নিয়ন্ত্রণ করতে পারলে application classpath-এ থাকা arbitrary Java bytecode PaperCut server process-এর নিরাপত্তা-অধিকারে চালানো সম্ভব হতে পারে। দুর্বলতাটির CVSS v4 স্কোর ৯.৪।

দুটি ত্রুটির ভূমিকা তাই পরস্পর-সম্পূরক: প্রথমটি authentication ছাড়াই প্রয়োজনীয় কনফিগারেশন বদলানোর পথ দেয়, দ্বিতীয়টি নিয়ন্ত্রিত কনফিগারেশনকে server-side code execution-এ নিয়ে যেতে পারে। তবে প্রকাশিত বিবরণ প্রতিটি deployment-এ একটি request-এই সফল compromise নিশ্চিত করে না; ফল নির্ভর করবে নির্দিষ্ট পরিবেশ ও আক্রমণের শর্তের ওপর।

Release 2 কারা পাবে এবং প্রথম প্যাচ কেন যথেষ্ট নয়

PaperCut NG ও PaperCut MF-এর সব সংস্করণ সম্ভাব্যভাবে প্রভাবিত। Release 2-এর প্যাকেজ v24, v25 ও v26-এর Windows, Linux এবং macOS সংস্করণের জন্য রয়েছে। v23 বা তার আগের installation-এর জন্য আলাদা Release 2 প্যাকেজের বদলে সর্বশেষ সংস্করণে upgrade করার নির্দেশনা দেওয়া হয়েছে।

এটি স্বাভাবিক release process শেষ করে প্রকাশিত পূর্ণাঙ্গ product release নয়, বরং জরুরি patch। প্রথম প্যাচ শুধু v25 ও v26-এর জন্য এসেছিল। পরবর্তী বিশ্লেষণে অতিরিক্ত hardening যোগ করে Release 2 তৈরি করা হয় এবং v24-ও এর আওতায় আসে।

দ্বিতীয় প্যাচের কারণ শুধু সংস্করণ-পরিসর বাড়ানো নয়। BleepingComputer-এর ২৮ আগস্টের প্রতিবেদনে বলা হয়েছে, watchTowr গবেষকেরা প্রাথমিক প্রতিরক্ষা পাশ কাটানোর একাধিক পথ এবং আরেকটি authentication bypass শনাক্ত করার পর নতুন hardening যোগ করা হয়। সেই কারণেই প্রথম জরুরি প্যাচ থাকা সার্ভারকেও Release 2 দিয়ে প্রতিস্থাপন করতে হবে।

শুধু primary Application Server আপডেট করলেই পরিবেশ সম্পূর্ণ patched হবে না। সংশ্লিষ্ট Site Server এবং secondary বা print server-কেও patched অবস্থায় নিতে হবে। Print Deploy ও Mobility Print এই নির্দিষ্ট দুর্বলতায় প্রভাবিত component নয়, তাই তাদের জন্য এই emergency update প্রয়োজন নেই।

প্রশাসকদের অগ্রাধিকারভিত্তিক পদক্ষেপ

PaperCut NG/MF সার্ভারে শুধু internal ও অনুমোদিত VPN IP রেখে অবিশ্বস্ত internet access বন্ধ করা হয়েছে

সবার আগে খুঁজে বের করতে হবে কোন PaperCut Application Server জনসাধারণের ইন্টারনেট থেকে পৌঁছানো যায়। সন্দেহজনক activity দেখা না গেলেও firewall rule, network access control বা সমমানের ব্যবস্থা দিয়ে ওয়েব ইন্টারফেসের প্রবেশ internal address, অনুমোদিত VPN egress এবং প্রয়োজনীয় trusted IP-তে সীমিত রাখতে হবে। প্যাচ বসানোর পরও এই network restriction তুলে নেওয়ার নির্দেশ নেই।

  1. Public IP, reverse proxy, NAT এবং firewall rule পরীক্ষা করে ইন্টারনেট থেকে দৃশ্যমান সব PaperCut web interface-এর তালিকা তৈরি করুন।
  2. অবিশ্বস্ত internet address বন্ধ করে শুধু প্রয়োজনীয় internal network, VPN egress বা নির্দিষ্ট প্রশাসনিক IP অনুমোদন করুন।
  3. NG বা MF v24–v26-এর উপযুক্ত Release 2 প্যাকেজ নিয়ে প্রকাশিত SHA-256 checksum মিলিয়ে standard upgrade procedure অনুসরণ করুন।
  4. Primary Application Server-এর সঙ্গে Site Server এবং secondary বা print server একই patched অবস্থায় আনুন।
  5. ইনস্টলেশনের পর server log, endpoint-security alert, intrusion-detection event এবং network activity পর্যালোচনা করুন।

v23 বা পুরোনো installation-এ সরাসরি Release 2 নেই। সেখানে public exposure সরিয়ে trusted IP restriction কার্যকর করা তাৎক্ষণিক containment, কিন্তু এটি সর্বশেষ সমর্থিত সংস্করণে upgrade করার বিকল্প নয়। একইভাবে, patch দুর্বল code বদলালেও আগে ঘটে যাওয়া অনুপ্রবেশ বা attacker persistence নিজে থেকে অপসারণ করে না।

সার্ভার আক্রান্ত হওয়ার যেসব চিহ্ন জানা গেছে

সম্ভাব্য compromise indicator-এর মধ্যে রয়েছে PaperCut Application Server-সম্পর্কিত intrusion-detection, endpoint-security বা network-monitoring alert এবং pc-app.exe থেকে সন্দেহজনক post-exploitation activity। server.log অনুপস্থিত, মুছে যাওয়া বা অস্বাভাবিকভাবে ছোট হয়ে যাওয়াও তদন্তের কারণ।

server.log-এ “No suitable driver found for jdbc:no:x” অথবা cardID lookup-সংশ্লিষ্ট “VALUES CAST” database error পাওয়া গেলেও তা খতিয়ে দেখতে হবে। তবে এসব চিহ্ন না থাকাকে সার্ভার আক্রান্ত হয়নি—এমন প্রমাণ হিসেবে ধরা যাবে না। সন্দেহভাজন compromise পাওয়া গেলে সংশ্লিষ্ট host বিচ্ছিন্ন করা, patch-এর আগের telemetry সংরক্ষণ করা এবং প্রতিষ্ঠানের incident-response প্রক্রিয়া চালু করা প্রয়োজন।

External database থেকে Card বা ID number lookup ব্যবহারকারী সীমিত কিছু deployment-এ Release 2 বসানোর পর অতিরিক্ত configuration লাগতে পারে। feature-টি চালু রাখতে server/security.properties ফাইলে security.card-number-lookup.enabled=Y যোগ করে Application Server restart করতে হবে; default অবস্থায় external lookup বন্ধ থাকে। পরিবর্তনের আগে deployment-টি সত্যিই ওই external lookup-এর ওপর নির্ভরশীল কি না নিশ্চিত করা দরকার।

তদন্তে এখনো যা অজানা

২৮ আগস্ট পর্যন্ত আক্রমণকারীদের পরিচয়, আক্রান্ত প্রতিষ্ঠানের মোট সংখ্যা এবং compromise-এর পরে তারা কী করেছে—এসব প্রকাশ করা হয়নি। তদন্ত চলমান থাকায় নতুন যাচাইকৃত indicator of compromise ও remediation guidance পরে যোগ হতে পারে।

বর্তমান নিশ্চিত অবস্থা হলো: সব NG/MF সংস্করণ সম্ভাব্য ঝুঁকির মধ্যে, v24–v26-এর জন্য Release 2 পাওয়া যাচ্ছে এবং আগের emergency patch চূড়ান্ত প্রতিকার নয়। ফলে ইন্টারনেট exposure সীমিত করা, সংশ্লিষ্ট সব server component আপডেট করা এবং patch-পূর্ব activity পরীক্ষা—তিনটি কাজই জরুরি।

শেয়ার করুন:

আমাদের নিউজলেটার নিন

সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।

0