🥇কিভাবে macOS এ প্রসেস এবং কার্নেল এক্সটেনশন রক্ষা করবেন

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

একটি প্রক্রিয়া "হত্যা" করার ক্লাসিক উপায়

একটি প্রক্রিয়াকে "হত্যা" করার একটি সুপরিচিত উপায় হল প্রক্রিয়াটিতে একটি সিগকিল সংকেত পাঠানো। ব্যাশের মাধ্যমে আপনি মারতে স্ট্যান্ডার্ড "কিল -সিগকিল পিআইডি" বা "পিকিল -9 নাম" কল করতে পারেন। "কিল" কমান্ডটি UNIX-এর দিন থেকে পরিচিত এবং এটি শুধুমাত্র macOS-এ নয়, অন্যান্য UNIX-এর মতো সিস্টেমেও উপলব্ধ।

UNIX-এর মতো সিস্টেমের মতো, macOS আপনাকে দুটি ছাড়া একটি প্রক্রিয়ার যেকোনো সংকেত আটকাতে দেয় - SIGKILL এবং SIGSTOP। এই নিবন্ধটি প্রাথমিকভাবে সিগকিল সংকেতকে একটি সংকেত হিসাবে ফোকাস করবে যা একটি প্রক্রিয়াকে হত্যা করে।

macOS সুনির্দিষ্ট

macOS-এ, XNU কার্নেলে কিল সিস্টেম কল psignal(SIGKILL,...) ফাংশনকে কল করে। ইউজারস্পেসে অন্যান্য ব্যবহারকারীর ক্রিয়াগুলিকে সিগন্যাল ফাংশন দ্বারা বলা যেতে পারে তা দেখার চেষ্টা করা যাক। আসুন কার্নেলের অভ্যন্তরীণ মেকানিজমের সিগন্যাল ফাংশনের কলগুলিকে বাদ দেই (যদিও সেগুলি অ-তুচ্ছ হতে পারে, আমরা সেগুলিকে অন্য নিবন্ধের জন্য ছেড়ে দেব 🙂 - স্বাক্ষর যাচাইকরণ, মেমরি ত্রুটি, প্রস্থান/বন্ধ হ্যান্ডলিং, ফাইল সুরক্ষা লঙ্ঘন ইত্যাদি .

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

static int
terminate_with_payload_internal(struct proc *cur_proc, int target_pid, uint32_t reason_namespace,
				uint64_t reason_code, user_addr_t payload, uint32_t payload_size,
				user_addr_t reason_string, uint64_t reason_flags)
{
...
	target_proc = proc_find(target_pid);
...
	if (!cansignal(cur_proc, cur_cred, target_proc, SIGKILL)) {
		proc_rele(target_proc);
		return EPERM;
	}
...
	if (target_pid == cur_proc->p_pid) {
		/*
		 * psignal_thread_with_reason() will pend a SIGKILL on the specified thread or
		 * return if the thread and/or task are already terminating. Either way, the
		 * current thread won't return to userspace.
		 */
		psignal_thread_with_reason(target_proc, current_thread(), SIGKILL, signal_reason);
	} else {
		psignal_with_reason(target_proc, SIGKILL, signal_reason);
	}
...
}

চালু

সিস্টেম স্টার্টআপে ডেমন তৈরি করার এবং তাদের জীবনকাল নিয়ন্ত্রণ করার আদর্শ উপায় চালু করা হয়েছে। অনুগ্রহ করে মনে রাখবেন যে উত্সগুলি ম্যাকওএস 10.10 পর্যন্ত লঞ্চটিএল-এর পুরানো সংস্করণের জন্য, কোড উদাহরণগুলি উদাহরণের উদ্দেশ্যে দেওয়া হয়েছে। আধুনিক লঞ্চটিএল এক্সপিসির মাধ্যমে লঞ্চড সংকেত পাঠায়, লঞ্চটিএল লজিক এটিতে সরানো হয়েছে।

চলুন দেখে নেওয়া যাক ঠিক কিভাবে অ্যাপ্লিকেশন বন্ধ করা হয়। SIGTERM সংকেত পাঠানোর আগে, অ্যাপ্লিকেশনটিকে "proc_terminate" সিস্টেম কল ব্যবহার করে বন্ধ করার চেষ্টা করা হয়।

<launchctl src/core.c>
...
	error = proc_terminate(j->p, &sig);
	if (error) {
		job_log(j, LOG_ERR | LOG_CONSOLE, "Could not terminate job: %d: %s", error, strerror(error));
		job_log(j, LOG_NOTICE | LOG_CONSOLE, "Using fallback option to terminate job...");
		error = kill2(j->p, SIGTERM);
		if (error) {
			job_log(j, LOG_ERR, "Could not signal job: %d: %s", error, strerror(error));
		} 
...
<>

হুডের নিচে, proc_terminate, এর নাম থাকা সত্ত্বেও, SIGTERM এর সাথে শুধুমাত্র psignal পাঠাতে পারে না, SIGKILLও পাঠাতে পারে।

পরোক্ষ হত্যা - সম্পদ সীমা

একটি আরও আকর্ষণীয় কেস অন্য সিস্টেম কলে দেখা যায় প্রক্রিয়া_নীতি. এই সিস্টেম কলের একটি সাধারণ ব্যবহার হল অ্যাপ্লিকেশন সংস্থানগুলিকে সীমিত করা, যেমন একটি সূচকের জন্য সিপিইউ সময় এবং মেমরি কোটা সীমিত করা যাতে ফাইল ক্যাশিং কার্যক্রম দ্বারা সিস্টেমটি উল্লেখযোগ্যভাবে ধীর না হয়। যদি একটি অ্যাপ্লিকেশন তার রিসোর্স সীমায় পৌঁছে যায়, যেমনটি proc_apply_resource_actions থেকে দেখা যায়, প্রক্রিয়াটিতে একটি SIGKILL সংকেত পাঠানো হয়।

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

অতএব, আপনি যদি অ্যাপ্লিকেশনটির CPU ব্যবহারের কোটা "সীমিত" করেন (উদাহরণস্বরূপ, শুধুমাত্র 1 এনএস চালানোর অনুমতি দেওয়া হয়), তাহলে আপনি সিস্টেমের যেকোনো প্রক্রিয়াকে মেরে ফেলতে পারেন। সুতরাং, ম্যালওয়্যার অ্যান্টিভাইরাস প্রক্রিয়া সহ সিস্টেমের যে কোনও প্রক্রিয়াকে মেরে ফেলতে পারে। পিড 1 (লঞ্চসিটিএল) দিয়ে একটি প্রক্রিয়াকে হত্যা করার সময় যে প্রভাবটি ঘটে তাও আকর্ষণীয় - সিগকিল সংকেত প্রক্রিয়া করার চেষ্টা করার সময় কার্নেল প্যানিক :)

কিভাবে সমস্যা সমাধান?

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

প্রথমত, যে চিহ্নটি sysent-এর মেমরি অবস্থান নিয়ন্ত্রণ করে তা শুধুমাত্র XNU কার্নেল চিহ্নের ব্যক্তিগত নয়, কিন্তু কার্নেল প্রতীকগুলিতে পাওয়া যাবে না। আপনাকে হিউরিস্টিক অনুসন্ধান পদ্ধতি ব্যবহার করতে হবে, যেমন ফাংশনটি গতিশীলভাবে বিচ্ছিন্ন করা এবং এতে একটি পয়েন্টার অনুসন্ধান করা।

দ্বিতীয়ত, টেবিলের এন্ট্রির গঠন নির্ভর করে কার্নেলটি যে ফ্ল্যাগের সাথে কম্পাইল করা হয়েছিল তার উপর। যদি CONFIG_REQUIRES_U32_MUNGING পতাকা ঘোষণা করা হয়, তাহলে কাঠামোর আকার পরিবর্তন করা হবে - একটি অতিরিক্ত ক্ষেত্র যোগ করা হবে sy_arg_munge32. কার্নেল কোন ফ্ল্যাগের সাথে কম্পাইল করা হয়েছে তা নির্ধারণ করতে একটি অতিরিক্ত চেক করা প্রয়োজন, অথবা বিকল্পভাবে, পরিচিতদের বিরুদ্ধে ফাংশন পয়েন্টার চেক করুন।

struct sysent {         /* system call table */
        sy_call_t       *sy_call;       /* implementing function */
#if CONFIG_REQUIRES_U32_MUNGING || (__arm__ && (__BIGGEST_ALIGNMENT__ > 4))
        sy_munge_t      *sy_arg_munge32; /* system call arguments munger for 32-bit process */
#endif
        int32_t         sy_return_type; /* system call return types */
        int16_t         sy_narg;        /* number of args */
        uint16_t        sy_arg_bytes;   /* Total size of arguments in bytes for
                                         * 32-bit system calls
                                         */
};

সৌভাগ্যবশত, macOS-এর আধুনিক সংস্করণগুলিতে, অ্যাপল প্রক্রিয়াগুলির সাথে কাজ করার জন্য একটি নতুন API প্রদান করে। এন্ডপয়েন্ট সিকিউরিটি এপিআই ক্লায়েন্টদের অন্যান্য প্রক্রিয়ার জন্য অনেক অনুরোধ অনুমোদন করতে দেয়। এইভাবে, আপনি উপরে উল্লিখিত API ব্যবহার করে SIGKILL সংকেত সহ প্রসেসগুলিতে যেকোন সংকেত ব্লক করতে পারেন।

#include <bsm/libbsm.h>
#include <EndpointSecurity/EndpointSecurity.h>
#include <unistd.h>

int main(int argc, const char * argv[]) {
    es_client_t* cli = nullptr;
    {
        auto res = es_new_client(&cli, ^(es_client_t * client, const es_message_t * message) {
            switch (message->event_type) {
                case ES_EVENT_TYPE_AUTH_SIGNAL:
                {
                    auto& msg = message->event.signal;
                    auto target = msg.target;
                    auto& token = target->audit_token;
                    auto pid = audit_token_to_pid(token);
                    printf("signal '%d' sent to pid '%d'n", msg.sig, pid);
                    es_respond_auth_result(client, message, pid == getpid() ? ES_AUTH_RESULT_DENY : ES_AUTH_RESULT_ALLOW, false);
                }
                    break;
                default:
                    break;
            }
        });
    }

    {
        es_event_type_t evs[] = { ES_EVENT_TYPE_AUTH_SIGNAL };
        es_subscribe(cli, evs, sizeof(evs) / sizeof(*evs));
    }

    printf("%dn", getpid());
    sleep(60); // could be replaced with other waiting primitive

    es_unsubscribe_all(cli);
    es_delete_client(cli);

    return 0;
}

একইভাবে, একটি MAC নীতি কার্নেলে নিবন্ধিত হতে পারে, যা একটি সংকেত সুরক্ষা পদ্ধতি প্রদান করে (নীতি proc_check_signal), কিন্তু API আনুষ্ঠানিকভাবে সমর্থিত নয়।

কার্নেল এক্সটেনশন সুরক্ষা

সিস্টেমে প্রক্রিয়াগুলি রক্ষা করার পাশাপাশি, কার্নেল এক্সটেনশন নিজেই (কেক্সট) রক্ষা করাও প্রয়োজনীয়। macOS ডেভেলপারদের সহজে IOKit ডিভাইস ড্রাইভার তৈরি করার জন্য একটি কাঠামো প্রদান করে। ডিভাইসগুলির সাথে কাজ করার জন্য সরঞ্জামগুলি সরবরাহ করার পাশাপাশি, IOKit C++ ক্লাসের উদাহরণ ব্যবহার করে ড্রাইভার স্ট্যাকিংয়ের পদ্ধতি সরবরাহ করে। ইউজারস্পেসে একটি অ্যাপ্লিকেশন একটি কার্নেল-ব্যবহারকারী স্থান সম্পর্ক স্থাপন করতে ক্লাসের একটি নিবন্ধিত উদাহরণ "খুঁজে" পেতে সক্ষম হবে।

সিস্টেমে ক্লাস ইনস্ট্যান্সের সংখ্যা সনাক্ত করতে, ioclasscount ইউটিলিটি রয়েছে।

my_kext_ioservice = 1
my_kext_iouserclient = 1

যে কোন কার্নেল এক্সটেনশন ড্রাইভার স্ট্যাকের সাথে নিবন্ধন করতে চায় তাকে অবশ্যই এমন একটি ক্লাস ঘোষণা করতে হবে যা IOService থেকে উত্তরাধিকারসূত্রে পাওয়া যায়, উদাহরণস্বরূপ my_kext_ioservice এই ক্ষেত্রে৷ ব্যবহারকারী অ্যাপ্লিকেশনগুলিকে সংযুক্ত করার ফলে ক্লাসের একটি নতুন দৃষ্টান্ত তৈরি হয় যা IOUserClient থেকে উত্তরাধিকারসূত্রে পাওয়া যায়, উদাহরণস্বরূপ my_kext_iouserclient৷

সিস্টেম থেকে ড্রাইভার আনলোড করার চেষ্টা করার সময় (kextunload কমান্ড), ভার্চুয়াল ফাংশন "বুল টার্মিনেট(IOOptionBits বিকল্প)" বলা হয়। কেক্সটুনলোড অক্ষম করতে আনলোড করার চেষ্টা করার সময় বন্ধ করার জন্য কলে মিথ্যা ফেরত দেওয়া যথেষ্ট।

bool Kext::terminate(IOOptionBits options)
{

  if (!IsUnloadAllowed)
  {
    // Unload is not allowed, returning false
    return false;
  }

  return super::terminate(options);
}

লোড করার সময় IOUserClient দ্বারা IsUnloadAllowed পতাকা সেট করা যেতে পারে। যখন একটি ডাউনলোড সীমা থাকে, কেক্সটুনলোড কমান্ড নিম্নলিখিত আউটপুটটি ফিরিয়ে দেবে:

admin@admins-Mac drivermanager % sudo kextunload ./test.kext
Password:
(kernel) Can't remove kext my.kext.test; services failed to terminate - 0xe00002c7.
Failed to unload my.kext.test - (iokit/common) unsupported function.

IOUserClient এর জন্য অনুরূপ সুরক্ষা করা আবশ্যক। IOKitLib ইউজারস্পেস ফাংশন "IOCatalogueTerminate(mach_port_t, uint32_t পতাকা, io_name_t বিবরণ);" ব্যবহার করে ক্লাসের উদাহরণগুলি আনলোড করা যেতে পারে। আপনি "টার্মিনেট" কমান্ডে কল করার সময় মিথ্যা ফেরত দিতে পারেন যতক্ষণ না ইউজারস্পেস অ্যাপ্লিকেশন "ডিস" হয়, অর্থাৎ "ক্লায়েন্টডিড" ফাংশনটি কল না করা হয়।

ফাইল সুরক্ষা

ফাইলগুলি সুরক্ষিত করতে, Kauth API ব্যবহার করা যথেষ্ট, যা আপনাকে ফাইলগুলিতে অ্যাক্সেস সীমাবদ্ধ করতে দেয়৷ অ্যাপল ডেভেলপারদের সুযোগের বিভিন্ন ইভেন্ট সম্পর্কে বিজ্ঞপ্তি প্রদান করে; আমাদের জন্য, KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA এবং KAUTH_VNODE_DELETE_CHILD অপারেশনগুলি গুরুত্বপূর্ণ৷ ফাইলগুলিতে অ্যাক্সেস সীমাবদ্ধ করার সবচেয়ে সহজ উপায় হল পাথ - আমরা ফাইলের পাথ পেতে এবং পাথ প্রিফিক্সের তুলনা করতে "vn_getpath" API ব্যবহার করি। মনে রাখবেন যে ফাইল ফোল্ডার পাথের রিনামিং অপ্টিমাইজ করার জন্য, সিস্টেম প্রতিটি ফাইলে অ্যাক্সেস অনুমোদন করে না, তবে শুধুমাত্র সেই ফোল্ডারে যা পুনঃনামকরণ করা হয়েছে। মূল পথের তুলনা করা এবং এটির জন্য KAUTH_VNODE_DELETE সীমাবদ্ধ করা প্রয়োজন৷

উপসর্গের সংখ্যা বৃদ্ধির কারণে এই পদ্ধতির অসুবিধা কম কর্মক্ষমতা হতে পারে। তুলনাটি O(উপসর্গ*দৈর্ঘ্য) এর সমান না হয় তা নিশ্চিত করতে, যেখানে উপসর্গ হল উপসর্গের সংখ্যা, দৈর্ঘ্য হল স্ট্রিংটির দৈর্ঘ্য, আপনি উপসর্গ দ্বারা নির্মিত একটি নির্ধারক সসীম অটোমেটন (DFA) ব্যবহার করতে পারেন।

প্রদত্ত উপসর্গের সেটের জন্য একটি DFA নির্মাণের একটি পদ্ধতি বিবেচনা করা যাক। আমরা প্রতিটি উপসর্গের শুরুতে কার্সারগুলি শুরু করি। যদি সমস্ত কার্সার একই অক্ষর নির্দেশ করে, তাহলে প্রতিটি কার্সারকে একটি অক্ষর দ্বারা বৃদ্ধি করুন এবং মনে রাখবেন যে একই লাইনের দৈর্ঘ্য এক দ্বারা বড়। যদি আলাদা আলাদা চিহ্ন সহ দুটি কার্সার থাকে, তাহলে কার্সারগুলিকে তারা যে চিহ্নের দিকে নির্দেশ করে সেই অনুসারে গ্রুপে ভাগ করুন এবং প্রতিটি গ্রুপের জন্য অ্যালগরিদম পুনরাবৃত্তি করুন।

প্রথম ক্ষেত্রে (কারসারের অধীনে সমস্ত অক্ষর একই), আমরা একটি DFA অবস্থা পাই যার একই লাইন বরাবর শুধুমাত্র একটি রূপান্তর রয়েছে। দ্বিতীয় ক্ষেত্রে, আমরা ফাংশনটিকে পুনরাবৃত্তভাবে কল করার মাধ্যমে প্রাপ্ত পরবর্তী স্টেটে 256 আকারের (অক্ষরের সংখ্যা এবং সর্বাধিক সংখ্যক গ্রুপ) রূপান্তরের একটি টেবিল পাই।

এর একটি উদাহরণ তাকান. উপসর্গগুলির একটি সেটের জন্য (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) আপনি নিম্নলিখিতগুলি পেতে পারেন ডিএফএ। চিত্রটি শুধুমাত্র অন্যান্য রাজ্যের দিকে নিয়ে যাওয়া রূপান্তর দেখায়; অন্যান্য রূপান্তর চূড়ান্ত হবে না।

DKA রাজ্যের মধ্য দিয়ে যাওয়ার সময়, 3টি মামলা হতে পারে।

চূড়ান্ত অবস্থায় পৌঁছে গেছে - পথটি সুরক্ষিত, আমরা KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA এবং KAUTH_VNODE_DELETE_CHILD অপারেশন সীমিত করি
চূড়ান্ত অবস্থায় পৌঁছানো যায়নি, কিন্তু পথ "শেষ" (নাল টার্মিনেটর পৌঁছেছে) - পথটি একটি অভিভাবক, এটি KAUTH_VNODE_DELETE সীমাবদ্ধ করা প্রয়োজন৷ মনে রাখবেন যে vnode একটি ফোল্ডার হলে, আপনাকে শেষে একটি '/' যোগ করতে হবে, অন্যথায় এটি "/foor/bar/t" ফাইলে সীমাবদ্ধ হতে পারে, যা ভুল।
চূড়ান্ত অবস্থায় পৌঁছায়নি, পথ শেষ হয়নি। উপসর্গগুলির একটিও এর সাথে মেলে না, আমরা বিধিনিষেধ প্রবর্তন করি না।

উপসংহার

যে নিরাপত্তা সমাধানগুলি তৈরি করা হচ্ছে তার লক্ষ্য হল ব্যবহারকারী এবং তার ডেটার নিরাপত্তার স্তর বাড়ানো। একদিকে, অ্যাক্রোনিস সফ্টওয়্যার পণ্যের বিকাশের মাধ্যমে এই লক্ষ্যটি অর্জন করা হয়, যা সেই দুর্বলতাগুলি বন্ধ করে যেখানে অপারেটিং সিস্টেম নিজেই "দুর্বল"। অন্যদিকে, OS এর দিকে উন্নত করা যেতে পারে এমন নিরাপত্তার দিকগুলিকে শক্তিশালী করার বিষয়ে আমাদের অবহেলা করা উচিত নয়, বিশেষ করে যেহেতু এই ধরনের দুর্বলতাগুলি বন্ধ করা পণ্য হিসাবে আমাদের নিজস্ব স্থায়িত্ব বাড়ায়। দুর্বলতা অ্যাপল প্রোডাক্ট সিকিউরিটি টিমের কাছে রিপোর্ট করা হয়েছে এবং macOS 10.14.5 (https://support.apple.com/en-gb/HT210119) এ ঠিক করা হয়েছে।

আপনার ইউটিলিটি আনুষ্ঠানিকভাবে কার্নেলে ইনস্টল করা থাকলেই এই সব করা যেতে পারে। অর্থাৎ, বাহ্যিক এবং অবাঞ্ছিত সফ্টওয়্যারগুলির জন্য এই ধরনের কোন ত্রুটি নেই। যাইহোক, আপনি দেখতে পাচ্ছেন, এমনকি অ্যান্টিভাইরাস এবং ব্যাকআপ সিস্টেমের মতো বৈধ প্রোগ্রামগুলিকে রক্ষা করার জন্যও কাজ করা প্রয়োজন। কিন্তু এখন macOS-এর জন্য নতুন Acronis পণ্যগুলির সিস্টেম থেকে আনলোড করার বিরুদ্ধে অতিরিক্ত সুরক্ষা থাকবে।

উত্স: www.habr.com

কিভাবে macOS এ প্রসেস এবং কার্নেল এক্সটেনশন রক্ষা করবেন