Mathspace breach-এ ১০.৮ লাখ মানুষ—password নয়, পরিচয়ই phishing-এর হাতিয়ার
Mathspace-এর ৮ সেপ্টেম্বরের হালনাগাদ অনুযায়ী, প্রতিষ্ঠানটি ৩ সেপ্টেম্বর ২০২৬ তার অভ্যন্তরীণ রিপোর্টিং সিস্টেমে অননুমোদিত প্রবেশ ও তথ্য ডাউনলোডের ঘটনা নিশ্চিত করে। অস্ট্রেলিয়া ও নিউজিল্যান্ডের শিক্ষার্থী, অভিভাবক বা অভিভাবক-প্রতিনিধি, শিক্ষক এবং কর্মী মিলিয়ে ১,০৭৯,৮১৯ জন আক্রান্ত হয়েছেন। স্কুলের যোগাযোগকারীদের জানানো শুরু হয় ৪ সেপ্টেম্বর; ব্যক্তিগত নোটিফিকেশন পাঠানো শুরু হয় ৬ সেপ্টেম্বর।
ওই ৮ সেপ্টেম্বরের নিশ্চিত পরিসরে গ্রাহকের পাসওয়ার্ড, authentication token, SSO credential বা academic record ছিল না। তবে নাম, ইমেইল, ব্যবহারকারীর ধরন ও লগইন-সংক্রান্ত তারিখ ছিল—যেগুলো দিয়ে প্রতারক শিক্ষার্থী, অভিভাবক বা শিক্ষককে আলাদা করে লক্ষ্য করে বিশ্বাসযোগ্য ফিশিং বার্তা বানাতে পারে। এখন ঝুঁকিটি সরাসরি ফাঁস হওয়া পাসওয়ার্ডের চেয়ে পরিচয় ব্যবহার করে নতুন credential আদায়ের চেষ্টা।
Reporting system কীভাবে প্রবেশপথ হয়েছিল
আক্রমণটি শিক্ষার্থীদের lesson বা assignment interface-এ হয়নি; লক্ষ্য ছিল Mathspace-এর নিজস্ব ব্যবস্থাপনায় চলা Metabase installation, যা অভ্যন্তরীণ reporting-এর কাজে ব্যবহৃত হতো। দুর্বলতাটি বৈধ login ছাড়াই administrator access তৈরির সুযোগ দিয়েছিল।
Metabase-এর প্রযুক্তিগত বিবরণে বলা হয়েছে, password-reset endpoint থেকে শুরু হওয়া SQL injection ব্যবহার করে পরিচিত user ID-র একটি বৈধ session তৈরি করা এবং পরে API key বানিয়ে বিপুল পরিমাণ data download করা সম্ভব ছিল। প্রতিষ্ঠানটি ৬ আগস্ট patched version প্রকাশ করেছিল; আক্রান্ত ছিল 0.58 ও পরবর্তী একাধিক সংস্করণ।
Mathspace-এর incident timeline দেখায়, patch বসানো আর আগের compromise খোঁজা এক কাজ নয়। প্রথম security advisory যথাযথভাবে শনাক্ত ও ঊর্ধ্বতন পর্যায়ে পাঠানো হয়নি; পরে software update করা হলেও সম্ভাব্য আক্রান্ত system-এর অতীত activity পরীক্ষা তখন সম্পন্ন হয়নি। Historical access log পর্যালোচনায় update-এর আগের অননুমোদিত প্রবেশ ধরা পড়ে।
কোন তথ্য বেরিয়েছে, কোনটি বেরোয়নি
ABC News-এর স্বাধীন প্রতিবেদনে আক্রান্তের সংখ্যা ও অঞ্চল ছাড়াও exported field এবং বাদ থাকা data category-গুলো Mathspace-এর disclosure-এর সঙ্গে মিলেছে। প্রত্যেক ব্যক্তির record-এ নিচের সব field ছিল না।
বেরিয়ে যাওয়া তথ্য
- অভ্যন্তরীণ user ID ও username;
- প্রথম ও শেষ নাম এবং email address;
- দেশ, time zone ও user type—যেমন শিক্ষার্থী, অভিভাবক, শিক্ষক বা কর্মী;
- email verification status;
- account খোলার, সর্বশেষ সক্রিয় থাকার ও সর্বশেষ login-এর তারিখ।
প্রকাশিত পরিসরে না থাকা তথ্য
- password ও password hash;
- authentication token, SSO credential ও API credential;
- academic record, learning activity, result ও assessment record;
- কোন account কোন স্কুলের সঙ্গে যুক্ত, তার সরাসরি record।
শেষ সীমাটির একটি গুরুত্বপূর্ণ ব্যতিক্রম আছে। কোনো স্কুলের email domain স্বতন্ত্র ও সহজে চেনা হলে address থেকেই সম্ভাব্য affiliation অনুমান করা যেতে পারে। তাই সরাসরি school mapping না থাকলেও স্কুলের পরিচয়ে প্রতারণার সুযোগ পুরোপুরি বাদ যায় না।
Password না গেলেও ফিশিং কেন বিশ্বাসযোগ্য হতে পারে
নাম, email address ও user type একসঙ্গে থাকলে একই বার্তা সবার কাছে না পাঠিয়ে ভূমিকা অনুযায়ী সাজানো যায়। শিক্ষার্থীর কাছে assignment access, অভিভাবকের কাছে child account verification, শিক্ষকের কাছে class roster এবং administrator-এর কাছে breach response-এর অজুহাত দেখানো হতে পারে। এগুলো সম্ভাব্য অপব্যবহারের উদাহরণ; এমন প্রতারণা ইতিমধ্যে ঘটেছে—তার প্রমাণ নয়।
Last-login date বা email-verification status ব্যবহার করে “account সম্প্রতি ব্যবহৃত হয়েছে” কিংবা “verification অসম্পূর্ণ” ধরনের দাবি আরও বিশ্বাসযোগ্য করা সম্ভব। আসল password চুরি না হলেও নকল sign-in page-এ সেটি লিখিয়ে নেওয়া, verification code আদায় বা ক্ষতিকর attachment খোলানো হতে পারে আক্রমণকারীর পরবর্তী লক্ষ্য।
এই ঘটনায় Mathspace বাধ্যতামূলক password reset চায়নি। তবে একই password অন্য service-এ ব্যবহার করা হলে সেখানে আলাদা password দেওয়া যুক্তিসঙ্গত, কারণ নতুন phishing প্রচেষ্টা সফল হলে পুনর্ব্যবহৃত credential একাধিক account ঝুঁকিতে ফেলতে পারে। কোনো বার্তার জবাবে password বা one-time code দেওয়া উচিত নয়।
Notification email স্বাধীনভাবে যাচাই করবেন যেভাবে
ঘটনাটি সত্য হলেও সেটির নাম ব্যবহার করা প্রতিটি email সত্য নয়। যাচাইয়ের জন্য সন্দেহজনক message-এর link, attachment, reply address বা সেখানে দেওয়া phone number ব্যবহার করলে প্রেরকই যাচাইয়ের পথ নিয়ন্ত্রণ করতে পারে।
- Message-এর link খুলবেন না: sender name, logo বা ব্যক্তিগত তথ্য ঠিক দেখালেও button চাপবেন না এবং attachment খুলবেন না।
- নতুন করে যোগাযোগ শুরু করুন: browser-এ নিজে Mathspace-এর website খুলে support channel নিন, অথবা নতুন email লিখে [email protected] ঠিকানায় পাঠান। সন্দেহজনক message-এ reply করবেন না।
- সীমিত তথ্য দিয়ে নিশ্চিত হন: notification-টি আসল কি না এবং আপনার account affected list-এ আছে কি না জিজ্ঞাসা করুন। Password, verification code বা অপ্রয়োজনীয় পরিচয়পত্র পাঠাবেন না।
- স্কুলের পরিচিত channel ব্যবহার করুন: আগে থেকে জানা parent portal, website বা phone number দিয়ে administrator-এর কাছে notice যাচাই করুন।
- সন্দেহজনক বার্তা সংরক্ষণ করুন: sender address, সময় ও message header রেখে Mathspace বা স্কুলের নির্ধারিত security contact-কে জানান।
অপ্রাপ্তবয়স্ক শিক্ষার্থীর কাছে এমন বার্তা এলে অভিভাবক বা শিক্ষককে সঙ্গে নিয়ে যাচাই করা উচিত। “Account বন্ধ হবে” বা “এখনই sign in করুন”—এমন জরুরি ভাষা কোনো message-এর সত্যতার প্রমাণ নয়।
স্কুলের scope ও historical compromise check
শুধু বর্তমান student list মিলিয়ে দেখলে আক্রান্তের প্রকৃত পরিসর অসম্পূর্ণ থেকে যেতে পারে। Reporting database-এ record থাকলে সাবেক বা inactive account-ও জড়িত হতে পারে; স্কুল ছেড়ে যাওয়া বা Mathspace ব্যবহার বন্ধ করা তথ্যটি নিরাপদ ছিল—এমন প্রমাণ নয়।
- বর্তমান শিক্ষার্থী, শিক্ষক, কর্মী এবং parent বা guardian account আলাদা করে গণনা করুন;
- সাবেক ব্যবহারকারী ও inactive account-কে অনুসন্ধানের পরিসরে রাখুন;
- Mathspace-এর incident-response ঠিকানায় স্কুলের সঙ্গে যুক্ত affected category ও record count চান;
- ব্যক্তিগত record দরকার হলে আগে secure sharing পদ্ধতি ঠিক করুন; সাধারণ email-এ পূর্ণ তালিকা চাওয়া এড়িয়ে চলুন;
- নিজস্ব school domain থেকে affiliation অনুমান করা যায় কি না মূল্যায়ন করুন;
- কে notification পেয়েছেন, কে পাননি এবং কোন address পুরোনো—তার নিয়ন্ত্রিত হিসাব রাখুন;
- Metabase বা অন্য reporting tool patch করার পর পুরোনো access log, অচেনা admin account, session, API key ও database credential আলাদাভাবে পরীক্ষা করুন।
Patch ভবিষ্যতে একই দুর্বলতার ব্যবহার ঠেকাতে পারে, কিন্তু patch-এর আগের access, তৈরি হওয়া session বা data export মুছে দেয় না। Mathspace compromised reporting system offline করেছে, API key বাতিল করেছে, সংশ্লিষ্ট database-access account নিষ্ক্রিয় করেছে এবং credential বদলেছে; recovery check শেষ না হওয়া পর্যন্ত system-টি offline রয়েছে।
এখন পর্যন্ত চুরি হওয়া তথ্য প্রকাশ, বিক্রি, বিতরণ বা অপব্যবহারের প্রমাণ পাওয়া যায়নি এবং আক্রমণকারীর পরিচয়ও অজানা। Individual notification, স্কুলগুলোর তথ্যের অনুরোধ এবং reporting system-এর recovery work এখনও চলমান—তাই “পাসওয়ার্ড বেরোয়নি” বলে ঘটনাটিকে শেষ হয়ে যাওয়া ঝুঁকি হিসেবে দেখা যাবে না।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।