দুর্বৃত্ত PowerShell কোড দিয়ে একটি আনপ্যাচড এক্সচেঞ্জ সার্ভার কিভাবে হ্যাক করবেন

মাত্র দুই মাসের কম আগে, কিছু উদ্বেগজনক বাগ নিউজ ব্রেক করেছিল: মাইক্রোসফ্ট এক্সচেঞ্জে একজোড়া শূন্য-দিনের দুর্বলতা ঘোষণা করা হয়েছিল।

আমরা যেমন এ সময় পরামর্শ দেওয়া হয়, এই দুর্বলতা, আনুষ্ঠানিকভাবে মনোনীত জন্য CVE-2022-41040 এবং জন্য CVE-2022-41082:

দুটি শূন্য-দিন যা একসাথে শিকল দিয়ে বেঁধে রাখা যেতে পারে, প্রথম বাগটি দূরবর্তীভাবে ব্যবহার করা হয় যাতে দ্বিতীয় বাগটি ট্রিগার করার জন্য যথেষ্ট গর্ত খোলা হয়, যা এক্সচেঞ্জ সার্ভারেই রিমোট কোড এক্সিকিউশন (RCE) সম্ভাব্যভাবে অনুমতি দেয়।

প্রথম দুর্বলতা কষ্টকর এবং ব্যাপকভাবে অপব্যবহারের কথা মনে করিয়ে দেয় ProxyShell নিরাপত্তা গর্ত 2021 সালের আগস্টে পিছন থেকে, কারণ এটি এক্সচেঞ্জের অটোডিসকভার বৈশিষ্ট্যে বিপজ্জনক আচরণের উপর নির্ভর করে, মাইক্রোসফ্ট দ্বারা বর্ণিত একটি প্রোটোকল হিসাবে যে "আউটলুক এবং EAS [এক্সচেঞ্জ অ্যাক্টিভসিঙ্ক] ক্লায়েন্টদের দ্বারা এক্সচেঞ্জে মেলবক্সগুলি খুঁজে পেতে এবং সংযোগ করতে ব্যবহৃত হয়".

সৌভাগ্যবশত, অটোডিসকভারের ভুল বৈশিষ্ট্য যা প্রক্সিশেল আক্রমণে যেকোনো দূরবর্তী ব্যবহারকারীর দ্বারা ব্যবহার করা যেতে পারে, লগ-ইন করা হোক বা না হোক, ছিল এক বছরেরও বেশি আগে প্যাচ করা হয়েছে.

দুর্ভাগ্যবশত, ProxyShell প্যাচগুলি প্রমাণীকৃত ব্যবহারকারীদের শোষণ বন্ধ করার জন্য যথেষ্ট কাজ করেনি, যার ফলে নতুন CVE-2022-40140 শূন্য-দিনের দিকে পরিচালিত হয়, যা শীঘ্রই ল্যাকনিকভাবে, যদি বিভ্রান্তিকরভাবে হয়, ডাব ProxyNotShell.

বিপজ্জনক নয়, তবে বিপজ্জনক তবুও

স্পষ্টতই, ProxyNotShell আসল ProxyShell এর মতো বিপজ্জনক কোথাও ছিল না, প্রদত্ত যে এটির জন্য যা প্রমাণীকৃত অ্যাক্সেস হিসাবে পরিচিত তা প্রয়োজন, তাই এটি যেকোন জায়গা থেকে শুধুমাত্র কারো দ্বারা অপব্যবহারের জন্য উন্মুক্ত ছিল না।

কিন্তু এটি দ্রুত রূপান্তরিত হয়েছে যে অনেক এক্সচেঞ্জ সার্ভারে, যে কোনও ব্যবহারকারীর লগইন নাম এবং পাসওয়ার্ড জেনে রাখাই প্রমাণীকৃত হিসাবে পাস করার জন্য এবং এই আক্রমণটি মাউন্ট করার জন্য যথেষ্ট হবে, এমনকি যদি সেই ব্যবহারকারীকে অ্যাক্সেস করার জন্য সঠিকভাবে লগইন করতে দ্বি-ফ্যাক্টর প্রমাণীকরণ (2FA) ব্যবহার করতে হবে। তাদের ইমেইল.

সোফোস বিশেষজ্ঞ চেস্টার উইসনিউস্কি হিসাবে এটা রাখো সময়:

এটি একটি "মধ্য প্রমাণীকরণ দুর্বলতা", যদি আপনি এটিকে বলতে চান। এটি একটি মিশ্র আশীর্বাদ। এর মানে এই যে একটি স্বয়ংক্রিয় পাইথন স্ক্রিপ্ট শুধুমাত্র পুরো ইন্টারনেট স্ক্যান করতে পারে না এবং কয়েক মিনিট বা ঘন্টার মধ্যে বিশ্বের প্রতিটি এক্সচেঞ্জ সার্ভারকে সম্ভাব্যভাবে শোষণ করতে পারে না, যেমনটি আমরা 2021 সালে প্রক্সিলগন এবং প্রক্সিশেলের সাথে ঘটেছে।

আপনার একটি পাসওয়ার্ড দরকার, কিন্তু যে কোনো এক্সচেঞ্জ সার্ভারে বৈধ একটি ইমেল ঠিকানা এবং পাসওয়ার্ডের সমন্বয় খুঁজে পাওয়া দুর্ভাগ্যবশত খুব কঠিন নয়। এবং আপনি আজ অবধি শোষিত নাও হতে পারেন, কারণ সফলভাবে Outlook Web Access [OWA]-এ লগ ইন করার জন্য তাদের FIDO টোকেন, বা তাদের প্রমাণীকরণকারী, বা আপনি যেকোন দ্বিতীয় ফ্যাক্টর ব্যবহার করতে পারেন।

কিন্তু এই আক্রমণের জন্য সেই দ্বিতীয় ফ্যাক্টরের প্রয়োজন নেই। […] শুধু একটি ব্যবহারকারীর নাম এবং পাসওয়ার্ড সংমিশ্রণ অর্জন একটি সুন্দর কম বাধা।

আপনার সম্ভবত মনে আছে, আমাদের মধ্যে অনেকেই ধরে নিয়েছিলেন (বা অন্তত আশা করেছিলেন) যে মাইক্রোসফ্ট প্রক্সিনটশেল গর্তগুলির সমাধান করতে ছুটে আসবে, কারণ অক্টোবরের প্যাচ মঙ্গলবার পর্যন্ত এখনও দুই সপ্তাহ বাকি রয়েছে।

কিন্তু আপাতদৃষ্টিতে একটি নির্ভরযোগ্য সমাধান খুঁজে পেয়ে আমরা হতাশ হয়েছি প্রত্যাশিত তুলনায় আরো জটিল, এবং অক্টোবর এসেছে এবং ProxyNotShell এর সাথে চলে গেছে শুধুমাত্র সমাধানের মাধ্যমে, সঠিক প্যাচ দ্বারা নয়।

এমনকি নভেম্বরের প্যাচ মঙ্গলবার সরাসরি প্রয়োজনীয় সংশোধনগুলি প্রদান করেনি, যদিও প্যাচগুলি তবুও বেরিয়ে এল একই দিনে এক্সচেঞ্জ-নির্দিষ্ট নিরাপত্তা আপডেটের অংশ হিসাবে যা আলাদাভাবে আনা এবং ইনস্টল করা যেতে পারে:

প্রুফ-অফ-ধারণা প্রকাশ

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

খারাপ খবর, প্রকাশ্য শোষণ প্রকাশ সম্পর্কে আপনার মতামতের উপর নির্ভর করে, ZDI টিম এখন কার্যকরভাবে একটি প্রমাণ-অফ-কনসেপ্ট (PoC) প্রদান করেছে যা ব্যাখ্যা করে কিভাবে এক্সচেঞ্জ সার্ভারে আক্রমণ করা যায়।

ভাল খবর, অবশ্যই, যে:

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

কিভাবে এটা কাজ করে

ZDI এর ব্যাখ্যা এই দুর্বলতাটি একটি আকর্ষণীয় গল্পের জন্য তৈরি করে যে একটি দুর্বলতাকে একটি কার্যকর শোষণে পরিণত করার জন্য আপনার প্রয়োজনীয় সমস্ত অংশকে একত্রিত করা কতটা জটিল হতে পারে।

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

ব্যাখ্যাটি হল, প্রয়োজনীয়, জটিল এবং বেশ প্রযুক্তিগত, এবং শেষ পর্যন্ত রিমোট কোড এক্সিকিউশন (RCE) অর্জনের জন্য একটি দীর্ঘ সিরিজের মাধ্যমে আপনাকে এগিয়ে নিয়ে যায়।

আপনি যদি ZDI রিপোর্ট পড়ার সিদ্ধান্ত নেন তাহলে আপনাকে উচ্চ-স্তরের বিশদগুলি আরও সহজে অনুসরণ করতে সাহায্য করার আশায়, এখানে উল্টো তালিকাভুক্ত পদক্ষেপগুলির সাথে একটি আশা-অতি-সরলীকৃত সারাংশ রয়েছে...

…তাই আপনি আগে থেকেই জানতে পারবেন কেন গল্পটি নির্দেশনা নেয়:

• স্টেপ 4. আপনার পছন্দের একটি .NET অবজেক্ট ইনস্ট্যান্টিশিয়েট করার জন্য এক্সচেঞ্জকে দূরবর্তীভাবে চালান, আপনার পছন্দের একটি প্রারম্ভিক প্যারামিটার সহ।

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

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

বস্তুর সাথে সাধারণত একটি প্রোগ্রাম্যাটিক ফাংশন যুক্ত থাকে যাকে বলা হয় নির্মাতা, যা সঠিক পরিমাণ মেমরি এবং সিস্টেম সংস্থানগুলির সঠিক সেট বরাদ্দ করার জন্য একটি নতুন বস্তু তৈরি করা হলে স্বয়ংক্রিয়ভাবে কার্যকর হয়।

সাধারণত, আপনাকে কনস্ট্রাক্টরের কাছে আর্গুমেন্ট হিসাবে এক বা একাধিক প্যারামিটার পাস করতে হবে, এটি বোঝাতে যে আপনি কীভাবে অবজেক্টটি শুরু করার সময় কনফিগার করতে চান।

সহজভাবে বললে, আপনি যদি তাৎক্ষণিকভাবে বলুন, ক TextString বস্তু (আমরা এই নামগুলি তৈরি করছি, কিন্তু আপনি ধারণা পেয়েছেন) একটি প্যারামিটার ব্যবহার করে যা নিজেই একটি পাঠ্য স্ট্রিং যেমন example.com:8888...

…আপনি সম্ভবত আপনার পাঠ্য ধরে রাখার জন্য বরাদ্দ করা একটি মেমরি বাফার দিয়ে শেষ করবেন, আরম্ভ করা হয়েছে যাতে এটি একই মান ধরে রাখে যা আপনি পাস করেছেন, যথা কাঁচা পাঠ্য example.com:8888.

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

কিন্তু যদি আপনি তাৎক্ষণিকভাবে বলেন, ক ConnectedTCPClient এর একই টেক্সট স্ট্রিং প্যারামিটার ব্যবহার করে অবজেক্ট example.com:8888, আপনি অস্থায়ী ডেটা রাখার জন্য প্রস্তুত একটি মেমরি বাফার সহ অপারেটিং সিস্টেম দ্বারা বরাদ্দ করা একটি নেটওয়ার্ক সকেট সহ শেষ করতে পারেন যা সার্ভারের সাথে ডেটা আদান-প্রদানের জন্য প্রস্তুত। example.com TCP পোর্টের উপরে 8888.

আপনি সেখানে রিমোট কোড এক্সিকিউশন ঝুঁকি দেখতে পাবেন, এমনকি যদি আপনি কখনই ওপেন সকেটে কোনো ডেটা পাঠাতে না পারেন, তবে আপনি সার্ভারকে আপনার নিয়ন্ত্রণে থাকা একটি অবস্থানে বাড়িতে কল করার জন্য প্রতারণা করেছেন।

এমনকি আপনি একটি বস্তু খুঁজে পেতে পারেন, বলুন, RunCmdAndReadOutput, যেখানে আপনি একটি প্যারামিটার হিসেবে যে পাঠ্য স্ট্রিংটি পাঠান তা হল, বেশ আক্ষরিক অর্থে, আপনি বস্তুটি তৈরি হওয়ার সাথে সাথে স্বয়ংক্রিয়ভাবে একটি কমান্ড চালাতে চান, যাতে আপনি পরে এটির আউটপুট সংগ্রহ করতে পারেন।

এমনকি যদি আপনি কখনই কমান্ডের আউটপুট পুনরুদ্ধার করতে না পান, তবে এই ধরনের একটি বস্তুকে তাৎক্ষণিকভাবে চালু করলে তা আপনাকে চালানোর জন্য একটি কমান্ড বেছে নিতে দেয়, এইভাবে আপনাকে জেনেরিক রিমোট কোড এক্সিকিউশন দেয় এবং শুধুমাত্র সার্ভার প্রক্রিয়ার অ্যাক্সেস অধিকার দ্বারা সীমিত একটি ঝুঁকি উপস্থাপন করে। .

অবশ্যই, আপনি শেষ পর্যায়ে পৌঁছানোর পরে আক্রমণটি কেবলমাত্র এত সহজ, যা আপনি করতে সক্ষম হবেন বলে মনে করা হয় না, কারণ এক্সচেঞ্জের একটি কঠোর অনুমোদন তালিকা রয়েছে যা আপনাকে ইনস্ট্যান্টিয়েট করার জন্য কোনও পুরানো বস্তু বেছে নিতে বাধা দেয়।

তাত্ত্বিকভাবে, PowerShell এর মাধ্যমে দূরবর্তীভাবে শুধুমাত্র নিরাপদ বা কম-ঝুঁকির বস্তু তৈরি করা যেতে পারে, যাতে আমাদের কাল্পনিক TextString উপরে, বা ক SimpleIntegerValue, গ্রহণযোগ্য বলে বিবেচিত হতে পারে, যখন ক ConnectedTCPClient বা একটি RunCmdAndReadOutput অবশ্যই হবে না।

কিন্তু ZDI গবেষকরা লক্ষ্য করেছেন যে শেষ পদক্ষেপটি ট্রিগার করার আগে, তারা এটি করতে পারে:

• ধাপ 3. দূরবর্তীভাবে এক্সচেঞ্জকে এই চিন্তা করার জন্য কৌশল করুন যে নিরাপত্তা পরীক্ষায় উত্তীর্ণ একটি কম-ঝুঁকিপূর্ণ বস্তু আসলে আপনার পছন্দের অন্য কোনো বস্তু।

তবুও, আপনি আশা করতে পারেন এক্সচেঞ্জ কম-ঝুঁকিপূর্ণ বস্তুরও দূরবর্তী সৃষ্টি রোধ করবে, হুমকিকে আরও কমিয়ে আনবে।

কিন্তু গবেষকরা খুঁজে পেয়েছেন যে তারা পারেন:

• ধাপ 2. দূরবর্তীভাবে এক্সচেঞ্জকে ব্যবহার করার জন্য কৌশল করুন পাওয়ারশেল রিমোটিং বাহ্যিকভাবে নিয়ন্ত্রিত প্রারম্ভিক পরামিতির উপর ভিত্তি করে একটি বস্তু তৈরি করার বৈশিষ্ট্য।

এবং এটি সম্ভব হয়েছিল প্রক্সিশেলের মতো গর্তের কারণে যা কেবল আধা-প্যাচযুক্ত ছিল:

• পদক্ষেপ 1. দূরবর্তীভাবে এক্সচেঞ্জকে একটি বৈধ প্যাকিং করে কোড সহ একটি ওয়েব অনুরোধ গ্রহণ এবং প্রক্রিয়াকরণের জন্য কৌশল করুন username:password পাশাপাশি অনুরোধের মধ্যে ক্ষেত্র.

এমনকি অনুরোধে নামযুক্ত ব্যবহারকারী আসলে লগ ইন না করলেও, এবং তাদের নিজস্ব মেলবক্স অ্যাক্সেস করার জন্য কিছু ধরণের 2FA প্রক্রিয়ার মধ্য দিয়ে যেতে হবে, একজন আক্রমণকারী যে তাদের জানত username:password কম্বিনেশনের কাছে এক্সচেঞ্জকে একটি ওয়েব সংযোগ গ্রহণ করার জন্য কৌশলে পর্যাপ্ত প্রমাণীকরণের তথ্য থাকবে যা উপরে 2 থেকে 4 ধাপে বর্ণিত অ্যাটাক চেইনটি চালু করতে ব্যবহার করা যেতে পারে।

ঢিলেঢালাভাবে বলতে গেলে, কোনো বৈধ username:password সংমিশ্রণটি করবে, এই প্রদত্ত যে "প্রমাণিকরণ" প্রয়োজন কেবলমাত্র এক্সচেঞ্জকে HTTP অনুরোধ প্রত্যাখ্যান করা থেকে প্রতিরোধ করার জন্য।

কি করো?

মনে রাখবেন যে এই আক্রমণ শুধুমাত্র কাজ করে:

• আপনার যদি অন-প্রিমিসেস এক্সচেঞ্জ সার্ভার থাকে। মাইক্রোসফ্ট তার নিজস্ব ক্লাউড পরিষেবাগুলিকে দ্রুত লক ডাউন করেছে বলে দাবি করেছে, তাই এক্সচেঞ্জ অনলাইন প্রভাবিত হয় না৷ নিশ্চিত হও আপনার এক্সচেঞ্জ সার্ভারগুলি কোথায় তা জানুন. এমনকি যদি আপনি এখন এক্সচেঞ্জ অনলাইন ব্যবহার করেন, তবুও আপনার অন-প্রিমিসেস সার্ভারগুলি চলমান থাকতে পারে, সম্ভবত আপনার মাইগ্রেশন প্রক্রিয়া থেকে ভুলবশত বাকি আছে।
• আপনার সার্ভার আনপ্যাচ করা হয়. নিশ্চিত করো যে তোমার আছে 2022-11-08-এর এক্সচেঞ্জ সফ্টওয়্যার আপডেট প্রয়োগ করেছে৷ থেকে দুর্বলতা বন্ধ করুন যে শোষণ প্রয়োজন.
• যদি আপনার সার্ভার এখনও মৌলিক প্রমাণীকরণ গ্রহণ করে, যা লিগ্যাসি প্রমাণীকরণ নামেও পরিচিত। নিশ্চিত করো যে তোমার আছে উত্তরাধিকার প্রমাণীকরণের সমস্ত দিক অবরুদ্ধ তাই আপনার সার্ভার গ্রহণ করবে না username:password উপরে উল্লিখিত শিরোনাম, এবং প্রথম স্থানে ঝুঁকিপূর্ণ অটোডিসকভার প্রোটোকল অনুরোধগুলি গ্রহণ করবে না। এই আক্রমণকারীদের থামায় একটি সার্ভারকে তাদের বোবি-ট্র্যাপড অবজেক্ট ইনস্ট্যান্টেশন ট্রিকস গ্রহণ করার জন্য প্রতারণা করে, এমনকি যদি সেই সার্ভারটি প্যাচ করা না থাকে।

আপনি ট্র্যাক রাখা আমাদের সরকারী প্রতিরোধ, প্রতিকার এবং প্রতিক্রিয়া পরামর্শ এবং Sophos গ্রাহকরা Sophos X-Ops টুইটার ফিড (@SophosXOps).

CVE-2022-41040 এবং CVE-2022-41082 সম্পর্কিত নতুন তথ্য প্রকাশিত হয়েছে: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) নভেম্বর 21, 2022

---

এক্সচেঞ্জ প্রমাণীকরণ এবং OAUTH2 সম্পর্কে আরও জানুন

পল ডকলিন এবং চেস্টার উইসনিউস্কির সাথে
ইন্ট্রো এবং আউটরো সঙ্গীত দ্বারা এডিথ মুজ.

---