৮,৩৯৩ Gitea সার্ভার এখনো ঝুঁকিতে: খোলা নিবন্ধনেই ঢুকতে পারে হামলাকারী

২৮ আগস্ট Shadowserver জানিয়েছে, আগের দিনের স্ক্যানে ৮,৩৯৩টি ইন্টারনেটমুখী Gitea IP CVE-2026-60004-এর জন্য ঝুঁকিপূর্ণ হিসেবে শনাক্ত হয়েছে। Shadowserver-এর ২৭ আগস্টের স্ক্যানফল IP-এর সংখ্যা নির্দেশ করে—এটি সফলভাবে দখল হওয়া সার্ভার বা আক্রান্ত প্রতিষ্ঠানের হিসাব নয়।

এই ২৮ আগস্টের অবস্থায় ত্রুটিটি সক্রিয় আক্রমণে ব্যবহারের প্রমাণ রয়েছে। Repository-তে সাধারণ write access থাকা কেউ ঝুঁকিপূর্ণ Gitea instance-এ service account-এর ক্ষমতায় shell command চালাতে পারে; open registration চালু থাকলে নতুন দর্শক account ও repository তৈরি করেই প্রয়োজনীয় access পেতে পারে। সরাসরি সমাধান হলো Gitea 1.27.1 বা নতুন সংস্করণে আপডেট করা।

কোন সংস্করণ ঝুঁকিপূর্ণ, প্যাচ কোথায়

Gitea-এর আনুষ্ঠানিক নিরাপত্তা advisory অনুযায়ী 1.17 থেকে 1.27.1-এর আগের সংস্করণগুলো প্রভাবিত এবং patched version হলো 1.27.1। তাই package, container image বা deployment manifest-এ প্রত্যাশিত version লেখা আছে কি না দেখাই যথেষ্ট নয়; প্রতিটি চলমান node আসলে কোন binary পরিবেশন করছে, সেটি নিশ্চিত করতে হবে।

আক্রমণের নির্দিষ্ট chain-এর জন্য Git 2.32 বা নতুন সংস্করণ, সক্রিয় diffpatch route এবং লিখনযোগ্য ও executable temporary filesystem প্রয়োজন। এসব শর্তের কোনোটি অনুপস্থিত থাকলে পরিচিত chain ব্যর্থ হতে পারে, কিন্তু configuration-নির্ভর এই বাধাগুলো patch-এর বিকল্প নয়। পুরোনো replica, standby node বা rollback image থেকে গেলে আপডেটের পরও exposure ফিরে আসতে পারে।

diffpatch কীভাবে Git hook চালায়

ঝুঁকিপূর্ণ বাস্তবায়ন attacker-controlled patch একটি shared bare temporary clone-এ প্রয়োগ করে। একইভাবে তৈরি patch দ্বিতীয়বার জমা দিলে Git-এর three-way fallback একটি executable entry-কে bare repository-র hooks directory-তে পৌঁছে দিতে পারে; index লেখার সময় সেটি সক্রিয় Git hook হয়ে যায়।

Hook-টি সাধারণ ওয়েব ব্যবহারকারীর সীমিত অধিকার নিয়ে নয়, Gitea চালানো operating-system service account হিসেবে চলে। ফলে আক্রমণকারীর server administrator হওয়া দরকার নেই—repository-তে সাধারণ write access-ই যথেষ্ট। Advisory-তে দেখানো কৌশলে command output Git object ও আলাদা branch-এর মাধ্যমে ফেরত নেওয়া যায়, তাই outbound callback না দেখাকে নিরাপদ থাকার প্রমাণ ধরা যাবে না।

সফল exploitation deployment-এর isolation ও service account-এর অনুমতির ওপর নির্ভর করে app.ini, application secret, process environment, mounted repository, database credential ও content এবং OAuth বা integration credential উন্মুক্ত করতে পারে। Gitea account-এর সীমার বাইরে service account যে অভ্যন্তরীণ ব্যবস্থায় পৌঁছাতে পারে, সেগুলোও তখন তদন্তের আওতায় আসে।

open registration কেন বাইরের পথ ছোট করে

Open registration নিজে command execution ঘটায় না; এটি প্রয়োজনীয় পরিচয় ও repository write access পাওয়ার বাধা কমায়। ফিচারটি চালু থাকলে আগে কোনো account না থাকা দর্শক সাধারণ ব্যবহারকারী হিসেবে নিবন্ধন করে repository তৈরি করতে পারে, তারপর diffpatch chain ব্যবহার করতে পারে। এই কারণেই প্রযুক্তিগতভাবে authenticated ত্রুটিটি উন্মুক্ত instance-এ পূর্বপরিচয়হীন হামলাকারীর নাগালে যেতে পারে।

নিবন্ধন বন্ধ করলে নতুন দর্শকের ওই পথটি বন্ধ হয়, কিন্তু vulnerability দূর হয় না। আগে তৈরি account, বৈধ collaborator, চুরি হওয়া session বা token এবং ইতিমধ্যে write access থাকা ব্যবহারকারী তখনও প্রবেশপথ হতে পারে। তাই registration নিয়ন্ত্রণ সাময়িক exposure reduction; পূর্ণ remediation হলো patched release চালু করা।

যে প্রতিষ্ঠানে self-registration প্রয়োজন, তাদের জন্য invitation, manual approval, অনুমোদিত identity provider বা network-level restriction বিবেচনা করা যায়। তবে এগুলো প্রতিরক্ষার অতিরিক্ত স্তর—1.27.1-এর আগের instance চালিয়ে যাওয়ার যুক্তি নয়।

প্রশাসকের তাৎক্ষণিক অগ্রাধিকার

২৫ আগস্ট CISA ত্রুটিটিকে Known Exploited Vulnerabilities তালিকায় যোগ করেছে বলে কানাডার Cyber Centre advisory নিশ্চিত করেছে; সেখানে 1.27.1-এর আগের Gitea-কে প্রভাবিত বলা হয়েছে। ফলে নিয়মিত maintenance window পর্যন্ত অপেক্ষা না করে exposure কমানো, প্রমাণ সংরক্ষণ এবং patched deployment চালু করাই যুক্তিসঙ্গত অগ্রাধিকার।

1. সব internet-facing instance, replica, worker ও standby node-এর চলমান version যাচাই করুন। 1.27.1-এর আগের node আপডেট না হওয়া পর্যন্ত internet থেকে সরান বা কঠোর access control-এর পেছনে রাখুন।
2. অপারেশনের জন্য প্রয়োজন না হলে নতুন user registration বন্ধ করুন। একই সঙ্গে সাম্প্রতিক account, নতুন repository এবং অস্বাভাবিক write permission পর্যালোচনা করুন।
3. Reverse-proxy, Gitea, authentication, Git ও host audit log সংরক্ষণ করুন। সন্দেহজনক host সঙ্গে সঙ্গে মুছে বা reimage করার আগে snapshot বা forensic copy নিলে তদন্তের প্রমাণ বাঁচে।
4. Patched deployment-এর পরে load balancer-এর পেছনের প্রত্যেক node আবার যাচাই করুন। Deployment manifest, image tag ও rollback artefact-এ পুরোনো build রয়ে গেছে কি না দেখুন।

Compromise যাচাই ও secret rotation

তদন্তে diffpatch API-তে অস্বাভাবিক বা পুনরাবৃত্ত request, সদ্য খোলা account ও repository, অপ্রত্যাশিত branch বা Git object এবং Gitea process থেকে শুরু হওয়া shell বা child process খুঁজতে হবে। Temporary repository বা Git hooks directory-তে executable file, service account-এর অস্বাভাবিক persistence এবং অপরিচিত network connection-ও প্রাসঙ্গিক সংকেত।

কোনো একটি সংকেত না পাওয়াকে compromise না হওয়ার নিশ্চয়তা ধরা যাবে না। Log retention কম হলে, host পুনরায় চালু হলে বা আক্রমণকারী artefact সরিয়ে ফেললে প্রমাণ অসম্পূর্ণ থাকতে পারে। Exposure window নির্ধারণের জন্য vulnerable version প্রথম internet-facing হওয়ার সময় থেকে patched deployment সম্পন্ন হওয়া পর্যন্ত proxy, authentication ও host telemetry মিলিয়ে দেখা প্রয়োজন।

Exploitation-এর প্রমাণ বা শক্তিশালী সন্দেহ থাকলে আক্রান্ত host বিচ্ছিন্ন করে বিশ্বস্ত image থেকে পুনর্গঠন করা উচিত। তারপর application secret, database credential, OAuth ও integration token, CI/CD secret, deploy key এবং service account থেকে পড়া সম্ভব অন্য credential বাতিল করে নতুন মান দিতে হবে। Persistence সরানোর আগে rotation করলে নতুন secret আবারও চুরি হওয়ার ঝুঁকি থাকে।

এখন পর্যন্ত নিশ্চিত চিত্র হলো, 1.27.1-এ patch থাকা সত্ত্বেও ২৭ আগস্টের স্ক্যানে ৮,৩৯৩টি IP ঝুঁকিপূর্ণ ছিল এবং ত্রুটিটি KEV তালিকায় রয়েছে। প্রকাশ্যে সফল compromise-এর মোট সংখ্যা, সব লক্ষ্যবস্তু বা আক্রমণকারী গোষ্ঠীর পূর্ণ হিসাব নেই; তাই প্রতিটি প্রশাসককে নিজের চলমান version, registration policy, exposure ও telemetry থেকেই ঝুঁকি নির্ধারণ করতে হবে।