আমি 5 বছরের মতো ব্যাখ্যা করুন: রিমোট ডেস্কটপ প্রোটোকল (RDP)
সুচিপত্র
- ভূমিকা
- আরডিপি সংযোগ
- সংযোগ ক্রম | বেসিক ইনপুট এবং আউটপুট
- আরডিপিতে চ্যানেল | তথ্য সংকোচন
- আরডিপি নিরাপত্তা | সাম্প্রতিক RDP দুর্বলতা
- উপসংহার
- তথ্যসূত্র
ভূমিকা
আরডিপি উইন্ডোজ মেশিনে দূরবর্তী অ্যাক্সেসের জন্য একটি অত্যন্ত জনপ্রিয় প্রোটোকল। প্রকৃতপক্ষে, 4.5 মিলিয়নেরও বেশি আরডিপি সার্ভার শুধুমাত্র ইন্টারনেটে উন্মুক্ত রয়েছে এবং আরও অনেকগুলি অভ্যন্তরীণ নেটওয়ার্কগুলির মধ্যে থেকে অ্যাক্সেসযোগ্য।
RDP জানা এবং বোঝার গুরুত্ব কখনও বেশি ছিল না – বিশেষ করে সাম্প্রতিক জটিল দুর্বলতার আলোকে যা প্রোটোকলের মধ্যে পাওয়া গেছে। এটি এখন অপরিহার্য জ্ঞান যা নিরাপত্তা শিল্পের প্রত্যেকের জন্য একেবারে গুরুত্বপূর্ণ। RDP অনেক এক্সটেনশন সহ একটি জটিল প্রোটোকল এবং নতুন সমালোচনামূলক বাগ খুঁজে পাওয়ার সম্ভাবনা এখনও বেশি। এই কারণেই নিরাপত্তা শিল্পকে এটি সম্পর্কে নিজেকে শিক্ষিত করতে হবে।
RDP এখন আগের চেয়ে অনেক বেশি প্রাসঙ্গিক, মাইক্রোসফ্টের Azure এবং Hyper-V প্ল্যাটফর্মগুলি এটিকে ডিফল্ট রিমোট সংযোগ প্রোটোকল হিসাবে ব্যবহার করে এবং আক্রমণকারীদের দ্বারা এই প্রোটোকলের প্রতি আগ্রহ বৃদ্ধি পায়, উভয়ই প্রাথমিক সংক্রমণ ভেক্টর এবং একটি প্রচার পদ্ধতি হিসাবে।
যেহেতু আমরা এই প্রোটোকলের একটি হজমযোগ্য ওভারভিউ খুঁজে পাইনি, এই প্রবন্ধে আমরা RDP-এর বুনিয়াদি, তারা কীভাবে কাজ করে এবং কীভাবে RDP-তে পাওয়া কিছু জটিল দুর্বলতাগুলি বাস্তবের বৃহত্তর চিত্রের সাথে মানানসই হয় তা নিয়ে আলোচনা করব। আরডিপি সংযোগ। আমাদের আশা হল আপনি প্রোটোকলের একটি প্রাথমিক ধারণা নিয়ে চলে যাবেন যাতে আপনি ভবিষ্যতের যেকোনো প্রয়োজনের জন্য প্রোটোকল সম্পর্কে আরও পড়া এবং গবেষণা চালিয়ে যেতে পারেন।
আরডিপি: দ্য বেসিকস
"মাইক্রোসফট রিমোট ডেস্কটপ প্রোটোকল (RDP) একটি সার্ভারে চলমান উইন্ডোজ-ভিত্তিক অ্যাপ্লিকেশনগুলির জন্য নেটওয়ার্ক সংযোগগুলিতে দূরবর্তী প্রদর্শন এবং ইনপুট ক্ষমতা প্রদান করে।" (MSDN)
মূলত, আরডিপি ব্যবহারকারীদের তাদের দূরবর্তী উইন্ডোজ মেশিন নিয়ন্ত্রণ করতে দেয় যেন তারা স্থানীয়ভাবে এটিতে কাজ করছে (ভাল, প্রায়)।
চিত্র 1: RDP কি?
RDP-তে যোগাযোগ একাধিক চ্যানেলের উপর ভিত্তি করে, এবং প্রোটোকল তাত্ত্বিকভাবে 64,000টি অনন্য চ্যানেলকে সমর্থন করে।
RDP এর মৌলিক কার্যকারিতা হল রিমোট সার্ভার থেকে ক্লায়েন্টে একটি মনিটর (আউটপুট ডিভাইস) এবং ক্লায়েন্ট থেকে রিমোট সার্ভারে কীবোর্ড এবং/অথবা মাউস (ইনপুট ডিভাইস) প্রেরণ করা। একটি RDP সংযোগের সময় যোগাযোগ অত্যন্ত অসমমিত হবে, যখন বেশিরভাগ ডেটা সার্ভার থেকে ক্লায়েন্টে যাবে। RDP যোগাযোগ ডিফল্টরূপে RSA এর RC4 ব্লক সাইফারের সাথে এনক্রিপ্ট করা হয়।
চিত্র 2: অসমমিত যোগাযোগ
একটি আরডিপি সংযোগ আসলে কীভাবে কাজ করে তা দেখার আগে, আসুন আমরা সেই প্রোটোকল/মানগুলি পরীক্ষা করি যার উপর আরডিপি নির্ভর করে। RDP প্রোটোকল স্ট্যাক নিম্নরূপ দেখায়:
চিত্র 3: প্রোটোকল স্ট্যাক
TPKT ISO ট্রান্সপোর্ট সার্ভিস নামে পরিচিত TCP. TPKT সমবয়সীদের তথ্য ইউনিট বিনিময় করতে সক্ষম করে যেগুলি ট্রান্সপোর্ট প্রোটোকল ডেটা ইউনিট (TPDUPDU)।
X.224 একটি সংযোগ-ওরিয়েন্টেড ট্রান্সপোর্ট প্রোটোকল, এটি একটি সংযোগ-মোড পরিবহন প্রদান করে সেবা RDP প্রাথমিক সংযোগ অনুরোধ এবং প্রতিক্রিয়াতে এটি ব্যবহার করে৷
T.125 MCS একটি মাল্টিপয়েন্ট কমিউনিকেশন সার্ভিস। এটি RDP-কে একাধিক চ্যানেলের মাধ্যমে যোগাযোগ ও পরিচালনা করার অনুমতি দেয়।
RDP স্ট্যাকের মাধ্যমে ডেটা পাঠানো এবং গ্রহণ করা মূলত যোগাযোগের জন্য 7 স্তরের OSI মডেলের মতোই। প্রেরিত ডেটা বিভাগ করা হয়, একটি চ্যানেলে নির্দেশিত, এনক্রিপ্ট করা, মোড়ানো, ফ্রেম করা এবং অন্য পক্ষের কাছে তারের উপরে যাওয়ার আগে প্যাকেজ করা হয়, তারপর এটি বিপরীতভাবে একই প্রক্রিয়ার মধ্য দিয়ে যায়।
এমএস আরডিপির বাস্তবায়ন প্রোটোকল স্ট্যাকের সমস্ত জটিলতাকে বিমূর্ত করেছে এবং এটি বিকাশকারীদের সহজেই প্রোটোকলে এক্সটেনশন লিখতে দেয়।
আরডিপি সংযোগ
এই অংশে, আমরা একটি RDP সংযোগের মূল বিষয়গুলি ব্যাখ্যা করব। মনে রাখবেন যে সরলতার জন্য, কিছু বিবরণ বাদ দেওয়া হয়েছিল। সংযোগ সম্পর্কে আরও তথ্যের জন্য (সঠিক কাঠামো, ধ্রুবক, ইত্যাদি সহ) অনুগ্রহ করে দেখুন [MS-RDPBCGR].
সংযোগের ক্রম
চিত্র 4: সংযোগ পর্যায়
RDP সংযোগকে কয়েকটি পর্যায়ে বিভক্ত করা যেতে পারে:
- সংযোগের সূচনা
- বেসিক সেটিংস এক্সচেঞ্জ
- চ্যানেল সংযোগ
- নিরাপত্তা আরম্ভ
- সুরক্ষিত সেটিংস এক্সচেঞ্জ
- লাইসেন্সিং
- ক্ষমতা বিনিময়
- সংযোগ চূড়ান্তকরণ
- তথ্য বিনিময়
সংযোগের সূচনা
চিত্র 5: সংযোগের সূচনা
RDP সংযোগটি ক্লায়েন্ট দ্বারা একটি X.224 সংযোগ অনুরোধ PDU ব্যবহার করে শুরু করা হয়। এই প্যাকেটে একটি RDP নেগোশিয়েশন রিকোয়েস্ট রয়েছে যেটিতে কয়েকটি সংযোগ পতাকা এবং ক্লায়েন্ট দ্বারা সমর্থিত নিরাপত্তা প্রোটোকল রয়েছে। এই নিরাপত্তা প্রোটোকল দুটি বিভাগের একটি হতে পারে:
স্ট্যান্ডার্ড RDP নিরাপত্তা
- RSA এর RC4 এনক্রিপশনের ডিফল্ট
উন্নত RDP নিরাপত্তা
- টিএলএস
- ক্রেডএসএসপি (TLS + NTLM/Kerberos)
- RDSTLS - TLS এর সাথে RDP উন্নত করা হয়েছে
RDP নিরাপত্তা সম্পর্কে আরও তথ্য পরবর্তী বিভাগে উপলব্ধ।
সংযোগ একটি X.224 সংযোগ নিশ্চিতকরণ PDU ব্যবহার করে সার্ভার দ্বারা নিশ্চিত করা হয়। এই প্যাকেটে রয়েছে RDP নেগোশিয়েশন রেসপন্স যা ক্লায়েন্টকে নির্বাচিত নিরাপত্তা প্রোটোকল (ক্লায়েন্টের সমর্থিত প্রোটোকল থেকে বেছে নেওয়া) জানাতে ব্যবহৃত হয় যা সমগ্র সংযোগ জীবনকাল জুড়ে ব্যবহার করা হবে।
এই বিন্দু থেকে, পরবর্তী ডেটা একটি X.224 ডেটা PDU এ মোড়ানো হবে।
বেসিক সেটিংস এক্সচেঞ্জ
চিত্র 6: মৌলিক সেটিংস বিনিময়
এই পর্যায়ে, একটি MCS Connect প্রাথমিক PDU এবং একটি MCS Connect প্রতিক্রিয়া PDU (যথাক্রমে) ব্যবহার করে ক্লায়েন্ট এবং সার্ভারের মধ্যে মৌলিক সেটিংস বিনিময় করা হয়। এই সেটিংস (ক্লায়েন্ট এবং সার্ভার উভয় থেকে) অন্তর্ভুক্ত:
- কোর ডেটা – RDP সংস্করণ, ডেস্কটপ রেজোলিউশন, রঙের গভীরতা, কীবোর্ড তথ্য, হোস্টনাম, ক্লায়েন্ট সফ্টওয়্যার তথ্য (পণ্য আইডি, বিল্ড নম্বর), ইত্যাদি।
- নিরাপত্তা ডেটা – এনক্রিপশন পদ্ধতি, সেশন কীগুলির আকার, সার্ভার র্যান্ডম (পরে সেশন কী তৈরি করতে ব্যবহৃত হয়) এবং সার্ভারের শংসাপত্র (এর মধ্যে কিছু শুধুমাত্র স্ট্যান্ডার্ড RDP নিরাপত্তা ব্যবহার করার সময় প্রাসঙ্গিক। )।
- নেটওয়ার্ক ডেটা – অনুরোধ করা এবং বরাদ্দকৃত ভার্চুয়াল চ্যানেল সম্পর্কে তথ্য। এতে চ্যানেলের সংখ্যা এবং নির্দিষ্ট ভার্চুয়াল চ্যানেলের একটি অ্যারে রয়েছে। ক্লায়েন্ট অনুরোধে চ্যানেলের সঠিক প্রকারের অনুরোধ করে এবং সার্ভার প্রতিক্রিয়াতে প্রকৃত চ্যানেল আইডি সরবরাহ করে। এই চ্যানেলগুলি সম্পর্কে আরও তথ্যের জন্য RDP-তে চ্যানেলগুলি নীচের বিভাগটি দেখুন৷
চ্যানেল সংযোগ
চিত্র 7: চ্যানেল সংযোগ
RDP অধিবেশনে ব্যবহৃত ভার্চুয়াল চ্যানেলগুলির তালিকা স্থাপন করার পরে, এখানে সেই পর্যায়ে আসে যেখানে প্রতিটি চ্যানেল সংযোগ করা হয়। এটির কয়েকটি উপ-পর্যায় রয়েছে:
- MCS খাড়া ডোমেন অনুরোধ – MCS ডোমেনের উচ্চতা। যেহেতু RDP উন্নত MCS টপোলজির সুবিধা নেয় না, তাই এটি হবে 0.
- MCS ব্যবহারকারীর অনুরোধ সংযুক্ত করুন – একটি ব্যবহারকারী চ্যানেল আইডির জন্য অনুরোধ
- MCS সংযুক্ত করুন ব্যবহারকারী নিশ্চিত করুন – ইউজার চ্যানেলের আইডি
- (+5) MCS চ্যানেলে যোগদানের অনুরোধ এবং নিশ্চিতকরণ – ক্লায়েন্ট তাদের আইডি ব্যবহার করে ভার্চুয়াল চ্যানেলে যোগদানের অনুরোধ করতে শুরু করবে। ব্যবহারকারী চ্যানেল, I/O চ্যানেল দিয়ে শুরু করে এবং মৌলিক সেটিংস বিনিময়ে আলোচনা করা ভার্চুয়াল চ্যানেলগুলির সাথে চালিয়ে যাওয়া। সার্ভার, ঘুরে, প্রতিটি সফল চ্যানেল যোগদান নিশ্চিত করবে৷৷
এই বিন্দু থেকে, ক্লায়েন্টের পাঠানো পরবর্তী ডেটা একটি MCS Send Data Request PDU-তে মোড়ানো হবে, যখন সার্ভারের পাঠানো ডেটা MCS Send Data Indication PDU-তে মোড়ানো হবে। ডেটা এখন ভার্চুয়াল চ্যানেলে পুনঃনির্দেশিত করা যেতে পারে।
নিরাপত্তা আরম্ভ
চিত্র 8: নিরাপত্তা শুরু
ক্লায়েন্ট একটি Security Exchange PDU পাঠায় যাতে সার্ভারের পাবলিক কী দিয়ে ক্লায়েন্ট র্যান্ডম এনক্রিপ্ট করা থাকে। সেশন এনক্রিপশন কী তৈরি করতে ক্লায়েন্ট এবং সার্ভার তারপর র্যান্ডম নম্বর ব্যবহার করে (উভয়টিই বেসিক সেটিংস এক্সচেঞ্জের সিকিউরিটি ডেটা এবং সিকিউরিটি এক্সচেঞ্জ পিডিইউ থেকে)।
এই বিন্দু থেকে, পরবর্তী RDP ট্র্যাফিক এনক্রিপ্ট করা যেতে পারে।
সুরক্ষিত সেটিংস এক্সচেঞ্জ
চিত্র 9: সুরক্ষিত সেটিংস বিনিময়
এই মুহুর্তে, ক্লায়েন্ট একটি এনক্রিপ্ট করা পাঠায় ক্লায়েন্ট ইনফো PDU সমর্থিত ধরণের কম্প্রেশন, ব্যবহারকারীর ডোমেন, ব্যবহারকারীর নাম, পাসওয়ার্ড, কাজের ডিরেক্টরি, ইত্যাদি।
লাইসেন্সিং
চিত্র 10: লাইসেন্সিং
এই পর্যায়টি অনুমোদিত ব্যবহারকারীদের একটি টার্মিনাল সার্ভারের সাথে সংযোগ করার অনুমতি দেওয়ার জন্য ডিজাইন করা হয়েছে। এটি হল একটি সার্ভারে 2টির বেশি একযোগে সংযোগ (যা "Windows' RDP সার্ভার" এর জন্য ডিফল্ট) সমর্থন করা। এর জন্য মাইক্রোসফ্ট থেকে লাইসেন্স কেনার প্রয়োজন।
অনেক ক্ষেত্রে, RDP সার্ভারের জন্য কোনো লাইসেন্সিং সার্ভার কনফিগার করা হয় না, সেই ক্ষেত্রে, RDP সার্ভার কেবলমাত্র ক্লায়েন্টের কাছে একটি PDU পাঠাবে যেটি তার লাইসেন্স "অনুমোদন" করে (শুধুমাত্র 2 সেশন পর্যন্ত)।
আপনি এখানে বর্ধিত লাইসেন্সিং পর্ব এবং RDP সার্ভার এবং লাইসেন্স সার্ভারের মধ্যে যোগাযোগ সম্পর্কে আরও তথ্য পেতে পারেন [MS-RDPELE] .
ক্ষমতা বিনিময়
চিত্র 11: ক্ষমতা বিনিময়
সার্ভারটি একটি ডিমান্ড অ্যাক্টিভ PDU-এ তার সমর্থিত ক্ষমতা পাঠায়। এই পিডিইউতে একটি কাঠামো রয়েছে যার বিভিন্ন ধরণের অনেক ক্ষমতা রয়েছে। মাইক্রোসফ্টের মতে, আমাদের 28 ধরনের ক্ষমতা সেট রয়েছে। প্রধান প্রকারগুলি হল সাধারণ (OS সংস্করণ, সাধারণ কম্প্রেশন), ইনপুট (কীবোর্ডের ধরন এবং বৈশিষ্ট্য, দ্রুত-পথ সমর্থন, ইত্যাদি), ফন্ট, ভার্চুয়াল চ্যানেল, বিটম্যাপ কোডেক এবং আরও অনেক কিছু। তারপরে, সার্ভারে ডিসপ্লে মনিটরগুলি বর্ণনা করতে সার্ভার একটি মনিটর লেআউট PDU পাঠাতে পারে বা নাও পারে৷ তারপরে ক্লায়েন্ট একটি Confirm Active PDU এর নিজস্ব ক্ষমতার সেট সহ সাড়া দেবে।
সংযোগ চূড়ান্তকরণ
চিত্র 12: সংযোগ চূড়ান্তকরণ
সংযোগ চূড়ান্ত করার জন্য ক্লায়েন্ট এবং সার্ভার কয়েক ধরনের PDU বিনিময় করে। এই সমস্ত PDU ক্লায়েন্ট থেকে উদ্ভূত হয় (একটি প্রতিক্রিয়ার জন্য অপেক্ষা না করে PDU একের পর এক পাঠানো যেতে পারে)। PDUগুলি হল:
- ক্লায়েন্ট/সার্ভার সিঙ্ক্রোনাইজ PDU – ক্লায়েন্ট সার্ভারের মধ্যে ব্যবহারকারী শনাক্তকারী সিঙ্ক্রোনাইজ করতে ব্যবহৃত হয়।
- ক্লায়েন্ট/সার্ভার কন্ট্রোল PDU (সহযোগিতা) - ক্লায়েন্ট এবং সার্ভার উভয়েই এই PDU পাঠায় সেশনের উপর শেয়ার করা নিয়ন্ত্রণ নির্দেশ করতে।
- ক্লায়েন্ট কন্ট্রোল PDU (অনুরোধ/গ্রান্ট কন্ট্রোল) – ক্লায়েন্ট নিয়ন্ত্রণের জন্য অনুরোধ পাঠায়, সার্ভার তা মঞ্জুর করে।
- Psistent Key List PDU/PDUs (ঐচ্ছিক) - ক্লায়েন্ট সার্ভারকে কীগুলির একটি তালিকা পাঠায়, প্রতিটি কী একটি ক্যাশে করা বিটম্যাপ সনাক্ত করে। এটি বিটম্যাপ ক্যাশেকে স্থায়ী হতে সক্ষম করে (সংযোগের জীবনকালের মধ্যে সীমাবদ্ধ হওয়ার বিপরীতে)। বিটম্যাপ ক্যাশিং হল সার্ভার থেকে ক্লায়েন্টে একটি গ্রাফিকাল আউটপুট স্থানান্তর করার জন্য প্রয়োজনীয় নেটওয়ার্ক ট্র্যাফিক কমাতে ব্যবহৃত একটি পদ্ধতি৷
- ফন্ট লিস্ট/ম্যাপ PDU – এই PDU গুলি RDP সেশনের জন্য ফন্ট সম্পর্কে তথ্য রাখার জন্য ছিল (ফন্টের নাম, গড় প্রস্থ, স্বাক্ষর, ইত্যাদি), তবে, মনে হয় যেমন মাইক্রোসফ্ট এটি ব্যবহার করছে না। এটি বলার পরে, সেই PDUগুলি এখনও সেই সময়ে ক্লায়েন্ট এবং সার্ভারের মধ্যে আদান-প্রদান করা হয়, কিন্তু এতে কোনও প্রকৃত ডেটা নেই (এমনকি কোনও ডেটা থাকলেও, Microsoft-এর ডকুমেন্টেশন আপনাকে এটি উপেক্ষা করা উচিত বলে উল্লেখ করে)৷
তথ্য বিনিময়
চিত্র 13: ডেটা বিনিময়
সংযোগ চূড়ান্ত হওয়ার পরে, ক্লায়েন্ট এবং সার্ভারের মধ্যে পাঠানো ডেটার প্রধান অংশটি হবে ইনপুট ডেটা (ক্লায়েন্ট->সার্ভার) এবং গ্রাফিক্স ডেটা (সার্ভার->ক্লায়েন্ট)। অতিরিক্ত ডেটা যা স্থানান্তর করা যেতে পারে তার মধ্যে রয়েছে সংযোগ ব্যবস্থাপনার তথ্য এবং ভার্চুয়াল চ্যানেলের বার্তা।
বেসিক ইনপুট এবং আউটপুট
সংযোগের জীবদ্দশায়, ক্লায়েন্ট এবং সার্ভার মৌলিক ইনপুট/আউটপুট ডেটা বিনিময় করে। ক্লায়েন্ট ইনপুট পাঠাচ্ছে এবং সার্ভার আউটপুট পাঠাচ্ছে।
ইনপুট ডেটা - এতে মাউস এবং কীবোর্ডের তথ্য রয়েছে, পাশাপাশি পর্যায়ক্রমিক সিঙ্ক্রোনাইজেশন (যেমন NAM_LOCK / CAPS_LOCK কী অবস্থা)
আউটপুট ডেটা – মৌলিক আউটপুট ডেটাতে সার্ভারে ব্যবহারকারীর সেশনের বিটম্যাপ চিত্র থাকে। উপরন্তু, সার্ভার শব্দ তথ্য পাঠাতে পারে (শুধুমাত্র খুব প্রাথমিক "বীপ" আকারে - ফ্রিকোয়েন্সি + সময়কাল)।
এই মৌলিক ইনপুট/আউটপুট ডেটা দুটি উপায়ে প্রেরণ করা যেতে পারে: ধীর-পথ বা দ্রুত-পথ।
স্লো-পাথ – সমস্ত RDP প্রোটোকল স্ট্যাক হেডার সহ সাধারণ PDU
ফাস্ট-পাথ - নাম অনুসারে, এটি প্রেরিত ডেটার পরিমাণ এবং এটি প্রক্রিয়া করার জন্য প্রয়োজনীয় প্রক্রিয়াকরণের পরিমাণ উভয়ই কমাতে তৈরি করা হয়েছিল। এটি নির্দিষ্ট PDU প্রকার (যেমন কীবোর্ড/মাউস ইনপুট) থেকে PDU শিরোনাম হ্রাস/মুছে ফেলার মাধ্যমে করা হয়।
আরডিপিতে চ্যানেল
RDP-তে, বেশিরভাগ ডেটা বিভিন্ন চ্যানেলের (MCS লেয়ার) মাধ্যমে পরিবহণ করা হয়। দুটি প্রধান ধরনের চ্যানেল আছে: স্ট্যাটিক ভার্চুয়াল চ্যানেল এবং ডাইনামিক ভার্চুয়াল চ্যানেল।
স্ট্যাটিক ভার্চুয়াল চ্যানেল (SVC)
SVC প্রধান RDP ডেটা সংযোগের মাধ্যমে বিভিন্ন ক্লায়েন্ট এবং সার্ভার উপাদানগুলির মধ্যে যোগাযোগের অনুমতি দেয়। প্রতি সংযোগে সর্বাধিক 31টি স্ট্যাটিক ভার্চুয়াল চ্যানেল রয়েছে এবং প্রতিটি চ্যানেল একটি স্বাধীন ডেটা স্ট্রিম হিসাবে কাজ করে। এই চ্যানেলগুলি স্থির কারণ সংযোগ সূচনার সময় বেসিক সেটিংস এক্সচেঞ্জ ফেজে সেগুলিকে অনুরোধ করা হয় এবং তৈরি করা হয় এবং সেশন চলাকালীন সেগুলি একেবারেই পরিবর্তন হয় না৷
সব SVC সমানভাবে তৈরি করা হয় না, কিছু ডিফল্টরূপে খোলা হয়, এবং কিছু বেসিক সেটিংস এক্সচেঞ্জ ফেজ চলাকালীন আলোচনা করা হয়। ডিফল্টরূপে তৈরি করা SVCগুলি একটি RDP সংযোগের কার্যকারিতার জন্য অত্যন্ত গুরুত্বপূর্ণ, অন্যগুলি প্রোটোকলের জন্য বিভিন্ন এক্সটেনশন সক্ষম করে৷
ডিফল্টরূপে তৈরি SVC-এর উদাহরণ:
- আই/ও চ্যানেল
- বার্তা চ্যানেল
- ব্যবহারকারী চ্যানেল
- সার্ভার চ্যানেল
এক্সটেনশন SVC একটি 8-বাইট নাম দ্বারা চিহ্নিত করা হয়, উদাহরণস্বরূপ:
- rdpdr - ফাইল সিস্টেম এক্সটেনশন। সার্ভার থেকে ক্লায়েন্ট ফাইল সিস্টেমে অ্যাক্সেসের পুনঃনির্দেশের অনুমতি দেয়।
- rdpsnd – সাউন্ড আউটপুট এক্সটেনশন।
- cliprdr - ক্লিপবোর্ড এক্সটেনশন। ক্লায়েন্ট এবং সার্ভারের মধ্যে ক্লিপবোর্ড ভাগ করার অনুমতি দেয়।
- drdynvc – ডাইনামিক ভার্চুয়াল চ্যানেল এক্সটেনশন (নীচে DVC দেখুন)
সমস্ত SVCs চ্যানেল আইডিগুলি 2 SVC ব্যতীত বেসিক সেটিংস এক্সচেঞ্জ পর্বের সময় সরবরাহ করা হয়: ব্যবহারকারীর চ্যানেল যা চ্যানেল সংযোগ পর্যায়ে সরবরাহ করা হয় ব্যবহারকারীর নিশ্চিতকরণ PDU-এ এবং সার্ভার চ্যানেল যার একটি নির্দিষ্ট মান 0x03EA (1002)।
ডাইনামিক ভার্চুয়াল চ্যানেল (DVC)
যেহেতু স্ট্যাটিক ভার্চুয়াল চ্যানেল সংখ্যা 31-এ সীমাবদ্ধ, তাই RDP ডাইনামিক ভার্চুয়াল চ্যানেলগুলিকেও সমর্থন করে। ডায়নামিক ভার্চুয়াল চ্যানেলগুলি একটি নির্দিষ্ট স্ট্যাটিক ভার্চুয়াল চ্যানেল - DRDYNVC-এর মাধ্যমে পরিবহণ করা হয়। এই চ্যানেলগুলি গতিশীল কারণ আপনি সংযোগের জীবনকালের যে কোনও পর্যায়ে (সূচনা করার পরে) সেগুলি তৈরি এবং ধ্বংস করতে পারেন। বিকাশকারীরা এমন এক্সটেনশন তৈরি করতে পারে যা একটি ডায়নামিক ভার্চুয়াল চ্যানেলে ডেটা পরিবহন করবে। DVC-এর সাধারণ ব্যবহার হল অডিও ইনপুট (ক্লায়েন্ট -> সার্ভার), PnP পুনঃনির্দেশ, গ্রাফিক্স রেন্ডারিং, ইকো চ্যানেল, ভিডিও পুনঃনির্দেশ এবং আরও অনেক কিছু।
নিম্নলিখিত চিত্রটি RDP-তে বিভিন্ন ধরণের চ্যানেলের মধ্যে সম্পর্ক বর্ণনা করে:
চিত্র 14: চ্যানেলের শ্রেণিবিন্যাস
তথ্য সংকোচন
RDP আউটপুট ডেটা (উভয় দ্রুত-পথ এবং ধীর-পথ) এবং ভার্চুয়াল চ্যানেলগুলিতে কম্প্রেশন ব্যবহার করতে পারে। ক্লায়েন্ট এবং সার্ভার উভয়কেই সাধারণভাবে কম্প্রেশন সমর্থন করতে হবে, এবং সংযোগের জন্য আলোচনা করা নির্দিষ্ট ধরনের কম্প্রেশন। ক্লায়েন্ট সিকিউর সেটিংস এক্সচেঞ্জের সময় ক্লায়েন্ট ইনফো PDU-তে যে কম্প্রেশন প্রকারগুলি সমর্থন করে তার বিজ্ঞাপন দেয়।
প্রতিটি PDU যাতে সংকুচিত ডেটা থাকে, সেই নির্দিষ্ট PDU-এর শিরোনামে কিছু কম্প্রেশন ফ্ল্যাগ (সংকোচনের ধরন ইত্যাদি সহ) সেট করা দরকার।
আরডিপি নিরাপত্তা
আগে সংক্ষেপে উল্লেখ করা হয়েছে, RDP প্রোটোকলের নিরাপত্তা দুই ধরনের হতে পারে:
স্ট্যান্ডার্ড নিরাপত্তা
ট্রাফিক RSA-এর RC4 এনক্রিপশন অ্যালগরিদম ব্যবহার করে এনক্রিপ্ট করা হয়, ক্লায়েন্ট এবং সার্ভারের র্যান্ডম মান ব্যবহার করে যা সংযোগ শুরুতে বেসিক সেটিংস এক্সচেঞ্জ পর্যায়ে বিনিময় করা হয়।
উন্নত নিরাপত্তা
এই ধরনের নিরাপত্তা RDP-কে সমস্ত নিরাপত্তা ক্রিয়াকলাপ (এনক্রিপশন/ডিক্রিপশন, ইন্টিগ্রিটি চেক, ইত্যাদি) বহিরাগত নিরাপত্তা প্রোটোকলে আউটসোর্স করতে সক্ষম করে। এটি নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:
- TLS 1.0/1.1/1.2
- ক্রেডএসএসপি
- RDSTLS
একটি উন্নত নিরাপত্তা প্রোটোকলের বিষয়ে সিদ্ধান্ত নেওয়া হয় আলোচনা-ভিত্তিক বা সরাসরি হতে পারে। আলোচনা-ভিত্তিক মানে হল যে সংযোগ শুরু করা (x.224 সংযোগ অনুরোধ এবং প্রতিক্রিয়া) নিরাপত্তা প্রোটোকলের সুযোগের বাইরে। সূচনা করার পরে, ক্লায়েন্ট এবং সার্ভার একটি নিরাপত্তা প্রোটোকল বেছে নেয়, বাহ্যিক নিরাপত্তা প্রোটোকল হ্যান্ডশেক করে এবং এখন থেকে RDP সংযোগের অন্যান্য সমস্ত ধাপগুলি সেই বাহ্যিক সুরক্ষা প্রোটোকলের মধ্যে অন্তর্ভুক্ত করা হবে৷
অন্য বিকল্প - direct পদ্ধতিটি সামঞ্জস্যের চেয়ে নিরাপত্তার পক্ষে। এই পদ্ধতিতে, ক্লায়েন্ট কোনও RDP সম্পর্কিত ডেটা পাঠানোর আগে বাহ্যিক সুরক্ষা প্রোটোকল হ্যান্ডশেক দিয়ে শুরু করবে৷
বর্ধিত নিরাপত্তা বেছে নেওয়ার অর্থ হল নিরাপত্তা শুরুর পর্যায়টি কার্যকর করা হবে না।
RDP বর্ধিত নিরাপত্তা ব্যবহার করার মূল সুবিধা হল এটি নেটওয়ার্ক লেয়ার প্রমাণীকরণ সক্ষম করে (বিশদ বিবরণ নীচে উপলব্ধ)।
নেটওয়ার্ক স্তরের প্রমাণীকরণ
Network Level Authentication (NLA) CredSSP-এর ব্যবহারকে বোঝায় ব্যবহারকারীকে প্রমাণীকরণের জন্য আগে RDP সংযোগের সূচনা। এটি সার্ভারকে শুধুমাত্র প্রমাণীকৃত ব্যবহারকারীদের জন্য সম্পদ উৎসর্গ করার অনুমতি দেয়।
RDP প্রোটোকলের একটি গুরুতর দুর্বলতার ক্ষেত্রে, NLA শুধুমাত্র প্রমাণীকৃত ব্যবহারকারীদের জন্য এই দুর্বলতার শোষণকে সীমাবদ্ধ করতে পারে।
সাম্প্রতিক RDP দুর্বলতা
এখন যেহেতু আমরা RDP প্রোটোকলের মূল বিষয়গুলি বুঝতে পেরেছি, আসুন সাম্প্রতিক কিছু জটিল দুর্বলতাগুলি পর্যালোচনা করি যা পাওয়া গেছে এবং দেখুন কিভাবে সেগুলি RDP প্রোটোকলের বৃহত্তর চিত্রের সাথে খাপ খায়।
ব্লুকিপ
BlueKeep (CVE-2019-0708) হল Microsoft এর RDP সার্ভারের একটি RCE দুর্বলতা, যা Windows 2000 থেকে Windows 7 এবং Windows Server 2008 R2 পর্যন্ত উইন্ডোজ মেশিনগুলিকে প্রভাবিত করে৷ এটি 2019 সালের মে মাসে পাওয়া গিয়েছিল এবং প্যাচ করা হয়েছিল। এই দুর্বলতাটি হল একটি ব্যবহারের পরে-মুক্ত যা RDP সংযোগগুলি পরিচালনা করে এমন উইন্ডোজ কার্নেল ড্রাইভারে উপস্থিত ছিল – termdd.sys.
এই দুর্বলতা RDP এর সংযোগ প্রাথমিক পর্যায়ে কাজে লাগানো যেতে পারে। পূর্বে উল্লিখিত হিসাবে, বেসিক সেটিংস এক্সচেঞ্জের সময় ক্লায়েন্ট এবং সার্ভার আলোচনা করে যে কোন স্ট্যাটিক ভার্চুয়াল চ্যানেলগুলি সংযোগের জন্য আরম্ভ করবে এবং এমন চ্যানেল রয়েছে যা MS_T120 চ্যানেল সহ ক্লায়েন্টের অনুরোধ নির্বিশেষে সংযোগে বরাদ্দ করা হবে।
termdd.sys একটি টেবিল তৈরি করে যাতে প্রতিটি তৈরি করা চ্যানেলের জন্য একটি চ্যানেল কাঠামোর একটি পয়েন্টার থাকে। এই টেবিলে 32টি (0x20) চ্যানেল রয়েছে। স্ট্যাটিক ভার্চুয়াল চ্যানেল MS_T120 ডিফল্টরূপে তৈরি করা হয় এবং এটি সর্বদা 0x1F সূচকে থাকে। এটি এমনকি আগে সংযোগের ক্রম শুরু হয়।
এই দুর্বলতা ট্রিগার করার জন্য, একজনকে একটি কাস্টম RDP ক্লায়েন্ট তৈরি করতে হবে, যা বেসিক সেটিংস এক্সচেঞ্জে MS_T120 নামে একটি স্ট্যাটিক ভার্চুয়াল চ্যানেলের জন্য অনুরোধ করবে। যদি এই ধরনের চ্যানেলের অনুরোধ করা হয়, তাহলে RDP সার্ভার এই সংযোগের জন্য এই চ্যানেলটি ইতিমধ্যে তৈরি করা হয়েছে কিনা তা খুঁজে বের করার চেষ্টা করবে। যদি তাই হয়, এটি একটি নতুন তৈরি করার পরিবর্তে বিদ্যমান চ্যানেল নিয়ন্ত্রণ কাঠামোতে পয়েন্টারটিকে ফিরিয়ে দেবে। এই মুহুর্তে, আমাদের কাছে একটি ডেটা স্ট্রাকচারের দিকে নির্দেশ করে দুটি পয়েন্টার থাকবে এবং সংযোগ চ্যানেল অ্যারে দেখতে এইরকম হবে:
চিত্র 15: স্মৃতিতে কাঠামো
বাগটি ট্রিগার করতে, RDP ক্লায়েন্টকে অবশ্যই একটি প্যাকেট পাঠাতে হবে যা সার্ভারকে MS_T120 চ্যানেল (বৈধ এবং নথিভুক্ত আচরণ) বন্ধ করে দেবে। চ্যানেলটি বন্ধ করার পরে, সার্ভার এগিয়ে যাবে এবং MS_T120 এর চ্যানেল নিয়ন্ত্রণ কাঠামো এবং সংযোগ চ্যানেল অ্যারেতে এটির পয়েন্টারটি মুক্ত করবে, তবে শুধুমাত্র ক্লায়েন্ট অনুরোধের কারণে তৈরি করা হয়েছে (সার্ভার দ্বারা স্বয়ংক্রিয়ভাবে তৈরি নয়) . এখন আমাদের কাছে একটি ঝুলন্ত পয়েন্টার আছে, এবং পরের বার সার্ভারটি MS_T120 চ্যানেল অ্যাক্সেস করার চেষ্টা করবে (যা প্রায়শই ঘটে যেহেতু এটি RDP-এর অপারেশনের জন্য একটি গুরুত্বপূর্ণ চ্যানেল), সিস্টেমটি বাগ চেক করবে।
চিত্র 16: BlueKeep চিত্রণ
যেহেতু এই দুর্বলতার জন্য এখন পর্যন্ত বেশ কয়েকটি লেখা আছে, তাই আমি যে কেউ এটিকে ট্রিগার এবং শোষণের জন্য সমস্ত প্রযুক্তিগত বিবরণ পেতে আগ্রহী তাদের জন্য কিছু রেফারেন্স রেখে দেব।
তথ্যসূত্র:
- https://www.zerodayinitiative.com/blog/2019/5/27/cve-2019-0708-a-comprehensive-analysis-of-a-remote-desktop-services-vulnerability
- https://unit42.paloaltonetworks.com/exploitation-of-windows-cve-2019-0708-bluekeep-three-ways-to-write-data-into-the-kernel-with-rdp-pdu/
- https://www.malwaretech.com/2019/05/analysis-of-cve-2019-0708-bluekeep.html
- https://www.coresecurity.com/blog/low-level-reversing-bluekeep-vulnerability-cve-2019-0708
- https://blog.tetrane.com/2020/01/22/bluekeep.html
দেজাব্লু
DejaBlue (CVE-2019-1181 এবং CVE-2019-1182) হল মাইক্রোসফটের আরডিপি সার্ভারে আরেকটি RCE দুর্বলতা (অতএব নাম) 2019 সালে আবিষ্কৃত হয়েছে। এবার, দুর্বলতা উইন্ডোজের সমস্ত সংস্করণকে প্রভাবিত করেছে (7- 10) প্যাচ পর্যন্ত. DejaBlue হল একটি পূর্ণসংখ্যা ওভারফ্লো দুর্বলতা যা RDP সার্ভারের একটি মূল DLL-তে উপস্থিত ছিল - RDPCoreTS.dll / RDPBase.dll (উইন্ডোজ সংস্করণের উপর নির্ভর করে) .
একটি ডাইনামিক ভার্চুয়াল চ্যানেল (DVC) এর মাধ্যমে পাঠানো ডেটা ডিকম্প্রেস করে এমন ফাংশনের মধ্যে দুর্বলতা রয়েছে। একটি DVC-তে সংকুচিত ডেটা একটি DYNVC_DATA_FIRST_COMPRESSED / DYNVC_DATA_COMPRESSED PDU-তে পাঠানো হয়। এই PDU-এর যেকোনো একটির প্রকৃত ডেটা RDP_SEGMENTED_DATA আকারে থাকে যাতে একাধিক সেগমেন্ট থাকতে পারে। একটি সংকুচিত RDP_SEGMENTED_DATA ডেটা আনকপ্রেসড সাইজ ধারণ করবে।
যখন RDP সার্ভার একটি সংকুচিত DVC PDU পায়, তখন এটি একটি ফাংশনকে কল করবে যা এটিকে ডিকম্প্রেস করবে - DecompressUnchopper::Decompress()। ডিকম্প্রেস ফাংশন ডিকম্প্রেসড ডেটার জন্য মেমরি বরাদ্দ করবে ফলাফলের আকারের জন্য কোনো চেক ছাড়াই uncompressedSize + 0x2000 আকারের। একজন আক্রমণকারী এই ফলাফলকে পূর্ণসংখ্যা তৈরি করতে পারে এবং বরাদ্দকৃত মেমরিটিকে প্রকৃত ডিকম্প্রেসড ডেটার আকারের চেয়ে ছোট করে তুলতে পারে। এটি কার্যকরভাবে একটি হিপ ওভারফ্লো হতে পারে, যা কোড এক্সিকিউশনে কাজে লাগানো যেতে পারে।
চিত্র 17: DejaBlue
এই পোস্ট লেখার সময় থেকে, এখনও কোন PoC/শোষণ সর্বজনীনভাবে উপলব্ধ নেই। উল্লেখযোগ্য ঝুঁকির কারণে এই দুর্বলতা জনসাধারণের সামনে দাঁড়াতে পারে, আমরা এই মুহূর্তে কোনো অতিরিক্ত তথ্য শেয়ার করব না। আরও পড়ার জন্য, এখানে DejaBlue-এর গভীর বিশ্লেষণের জন্য কয়েকটি পাবলিক রেফারেন্স।
- https://www.malwaretech.com/2019/08/dejablue-analyzing-a-rdp-heap-overflow.html
- https://cyberx-labs.com/blog/analyzing-the-dejablue-heap-overflow-vulnerability/#_Toc28622447
- https://bbs.pediy.com/thread-256766.htm (চীনা)
আপনার আরডিপি সুরক্ষিত করা
অনুসরণ করার জন্য সাধারণ সুপারিশ রয়েছে যা আক্রমণকারীদের জন্য আপনার RDP সার্ভারে আক্রমণ করার কাজটিকে আরও কঠিন করে তুলতে পারে। আপনি 2টি সহজ পদক্ষেপ নিতে পারেন যেগুলি হবে:
- আপনার ফায়ারওয়ালের পিছনে রেখে আপনার RDP সার্ভারের ইন্টারনেটে এক্সপোজার রোধ করুন।
- NLA সক্ষম করুন
এটি সম্ভাব্য আক্রমণকারীদের শুধুমাত্র আপনার নেটওয়ার্কে যারা আছে এবং ইতিমধ্যেই প্রমাণীকরণ করা হয়েছে তাদের মধ্যে সীমাবদ্ধ করে আক্রমণের পৃষ্ঠকে ছোট করতে পারে।
উপসংহার
যেহেতু এটি RDP-এর একটি পরিচায়ক নিবন্ধ ছিল, তাই আমি শত শত পৃষ্ঠার RDP ডকুমেন্টেশনকে একটি হজমযোগ্য এবং মোটামুটি সংক্ষিপ্ত তথ্যের মধ্যে পাতানোর চেষ্টা করেছি, তাই এমন অনেক কিছু আছে যা আমি এখানে কভার করিনি। আমাদের লক্ষ্য ছিল পাঠককে প্রোটোকলের একটি প্রাথমিক বোঝার সাথে সাথে তাদের আগ্রহের নির্দিষ্ট বিষয়গুলি সম্পর্কে আরও পড়া এবং গবেষণা চালিয়ে যাওয়ার ক্ষমতা নিয়ে আসা।
গত বছরে, আমরা এই প্রোটোকলটিতে 2টি জটিল দুর্বলতা দেখেছি এবং 4.5 মিলিয়নেরও বেশি RDP সার্ভার ইন্টারনেটে উন্মুক্ত (shodan.io< অনুযায়ী) a i=2>) এবং RDP চালিত প্রাদুর্ভাবের ঝুঁকি অনেক বেশি।
যদিও সমস্ত RDP সার্ভার উইন্ডোজ সার্ভার নয়, আমরা RDP সার্ভারের বিভিন্ন বাস্তবায়নের মধ্যে ভাগ করা অনুরূপ দুর্বলতা দেখেছি, তাই উইন্ডোজ একমাত্র সম্ভাব্য লক্ষ্য নয়। উদাহরণস্বরূপ, DejaBlue, CVE-2018-8785-এর সাথে খুব মিল – ফ্রিআরডিপি (জনপ্রিয় ওপেন-সোর্স RDP সার্ভার) একটি দুর্বলতা যা DejaBlue আবিষ্কারের প্রায় এক বছর আগে Eyal Itkin দ্বারা পাওয়া গিয়েছিল।
আমরা এই ব্লগটি শুরু করেছি কিভাবে RDP অনেক এক্সটেনশন সহ একটি জটিল প্রোটোকল। এর জটিলতার কারণে, নতুন সমালোচনামূলক বাগগুলি খুঁজে পাওয়ার সম্ভাবনা এখনও অনেক বেশি এবং বন্যতে অপব্যবহারের আগে সেগুলিকে খুঁজে পেতে এবং ঠিক করার জন্য আমাদের প্রস্তুত থাকতে হবে, বা দ্রুত প্রতিক্রিয়া জানাতে এবং সম্ভাব্য ভবিষ্যতের দুর্বলতার ক্ষতি কমিয়ে দেওয়ার ক্ষমতা থাকতে হবে। .
