\n\nThis page has been machine-translated from the original page.
\n
I am studying security using “Hack The Box,” a penetration testing learning platform.\nMy current rank on “Hack The Box” is ProHacker at the time of writing.
\n![\"Hack](\"http://www.hackthebox.eu/badge/image/327080\"){kind=icon}
\nIn this article, I summarize what I learned about attack techniques related to “EternalBlue” through solving a HackTheBox machine.
\nTo better understand attacks related to “EternalBlue,” which caused enormous real-world damage, I will summarize what I studied.
\n“EternalBlue” is also known for having been a major factor in the spread of the ransomware “WannaCry,” which wreaked havoc around the world.
\n\nThe content of this article is not intended to promote any actions that violate social order.
\nPlease note in advance that attempting to attack environments you do not own or have not been authorized to access may violate the “Act on Prohibition of Unauthorized Computer Access” (Unauthorized Access Prohibition Act).
\nAll opinions expressed here are my own and do not represent any organization I belong to.
\n\nThis article’s theme is to learn the details of the vulnerability and how it is exploited by reproducing “EternalBlue,” and to apply that knowledge to security measures.
\nEternalBlue refers to an attack tool that exploits a security flaw in Windows SMB1.0.
\nBy exploiting a flaw in “Windows SMB1.0 (SMBv1),” EternalBlue allows an attacker to execute arbitrary code.
\nEternalBlue was addressed by the update “MS17-010,” published in March 2017.\nReference: Microsoft Security Bulletin MS17-010 - Critical | Microsoft Docs
\nEternalBlue was used by the ransomware “WannaCry,” which spread worldwide. It reportedly affected around 230,000 computers, and the total global damage caused by WannaCry is estimated to have reached 4 billion USD.
\nIn Japan as well, many companies, including Hitachi, were affected.
\nReference: Everything About the WannaCry Ransomware | Kaspersky\nReference: What Did Hitachi Learn from the WannaCry Incident? Turning It into an IoT Security Service: IoT Security (1/2) - MONOist
\nEternalBlue was included in the offensive tools leaked by the group known as “Shadow Brokers.”\nThese tools are said to have been leaked from the NSA, although the truth of that remains unclear.
\nWhen searching the internet, you will find pages that describe EternalBlue as a vulnerability and others that use the name for the exploit itself. Based on reports from ESET and Trend Micro, however, it seems most accurate to regard EternalBlue as an exploit that abuses the vulnerability addressed by “MS17-010.”
\nReference: One year later: EternalBlue exploit more popular now than during WannaCryptor outbreak | WeLiveSecurity\nReference: Trend Micro Security Blog: Explaining How EternalBlue, the Vulnerability Exploit That Spread WannaCry, Works | Trend Micro Security Blog
\nAn interesting point is that by the time EternalBlue was publicly leaked, a patch for “MS17-010” had already been released.
\nReference: Protecting customers and evaluating risk – Microsoft Security Response Center
\nDespite the availability of a patch, EternalBlue was still abused around the world.\nAccording to research by Avast, even one year after the WannaCry outbreak, 29% of Windows PCs worldwide still had not been patched and remained vulnerable.
\nIf critical patches had simply been applied, infection of individual machines—or at least the spread of the infection—could likely have been prevented. In that sense, this is probably an incident we should learn from.
\nNow, let’s take a closer look at the attack mechanism used by EternalBlue.
\nThe vulnerability exploited by EternalBlue causes a buffer overflow in the Large Non-PagedPool region during File ExtendedAttribute (FEA) processing by the Windows SMB1.0 kernel function srv!SrvOs2FeaListToNt.
More specifically, when the kernel function srv!SrvOs2FeaListToNt converts FEA (extended file attributes) into NTFEA (Windows NT FEA), it calls srv!SrvOs2FeaListSizeToNt to calculate the size of the FEA list. A bug in that size calculation leads to the overflow.
According to Trend Micro’s analysis, the overflow occurs through the following flow.
\n\n\n\n
\n\n- The
\nsrv!SrvOs2FeaListSizeToNtfunction calculates the size of the FEA list and updates the received FEA list size.- At that point, because of a type conversion to the wrong data type (
\nWORD, an unsigned 2-byte integer in C), the FEA size becomes larger than the original value.- Because the list size is inaccurate, an overflow occurs in the non-paged pool during the iterative conversion of the FEA list into an NTFEA list.
\n
So what exactly is FEA (extended file attributes), the feature whose vulnerability is abused by EternalBlue?
\nAccording to RFC8276, extended file attributes are provided to associate opaque metadata that is not interpreted by the file system with files and directories.
\nIn other words, you can think of them as a mechanism that allows users to associate metadata with a file even though the file system itself does not interpret that metadata.
\nOn the other hand, permissions and attributes such as atime and ctime are strictly defined by the file system as ordinary attributes and are treated separately from FEA.
\nReference:
\nsrv!SrvOs2FeaListSizeToNt FunctionEternalBlue exploits the buffer overflow that occurs when the FEA list size calculated by srv!SrvOs2FeaListSizeToNt is handled.
srv!SrvOs2FeaListSizeToNt is a function included in SRV.sys, the kernel driver for the SMB protocol, and it is responsible for converting an OS/2 FEA list into an NT FEA list.
Reference:
\n\nWe have now seen that the srv!SrvOs2FeaListSizeToNt function exploited by EternalBlue exists in the kernel driver SRV.sys used by the SMB protocol.
But what exactly is the SMB protocol in the first place? (I didn’t really know.)\nI had heard the name often, but I never had a solid grasp of what it actually was.
\nThe SMB protocol is a collective name for communication protocols used mainly in Windows environments for things like file sharing and printer sharing.
\nThe SMB protocol can operate over several different protocols, and SMBv1 can also run directly over TCP on port 445 through a feature called direct hosting SMB.
\nOriginally, the SMB protocol was a file-sharing protocol for file servers running on OS/2-based file server operating systems. It became widely used after file server functionality was added to Windows 3.x and 9x.
\nThat historical background also seems to explain why srv!SrvOs2FeaListSizeToNt performs a conversion from OS/2 FEA lists to NT FEA lists.
Reference:
\nNow that I had roughly finished researching how EternalBlue is exploited and what environment is needed, I wanted to verify the attack technique in practice.
\nFor this validation, I prepared the following environment.
\nWindows 7 64bit (IP:169.254.100.60)
\nkd> vertarget\n\nWindows 7 Kernel Version 7601 (Service Pack 1) MP (1 procs) Free x64\nBuilt by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850\nMachine Name:\nKernel base = 0xfffff800`02e1f000 PsLoadedModuleList = 0xfffff800`03064e90\nDebug session time: Mon Apr 26 01:19:52.742 2021 (UTC + 9:00)\nSystem Uptime: 0 days 0:08:03.468First, enable kernel debugging on the target machine’s Windows 7.
\nBecause the target machine in this case is a virtual machine built with Hyper-V, I configured the serial port used for debugging as a named pipe.
\nNext, log in to the target machine and enable kernel-mode debugging.
\nYou can enable it by running the following commands from a command prompt started with administrator privileges.
\nbcdedit /debug on\nbcdedit /dbgsettings serial debugport:1 baudrate:115200\nshutdown /r /t 0It is also fine to launch Msconfig.exe, specify the COM1 port from Advanced options, enable debugging, and then reboot.
Next, on the target host’s Windows 7, verify that SMBv1 is enabled.
\nIf DEPENDENCIES: MRxSmb10 is present in the output of the following command, you can conclude that SMB 1.0 is enabled.
sc.exe qc lanmanworkstationWith that, preparation on the target machine side is complete.
\nSet up WinDbg on the host-side Windows 10 and use it to perform kernel debugging on the target machine.
\nWinDbg is a kernel-mode and user-mode debugger included in Debugging Tools for Windows.\nUsing WinDbg also makes it possible to debug Windows system drivers.
\nAt the time of writing, there are two major ways to set up WinDbg.
\nReference: Download Debugging Tools for Windows - WinDbg - Windows drivers | Microsoft Docs
\nThe easiest method is to get the preview build of WinDbg from the Microsoft Store, but because it had not yet been officially released and still had many issues, installing the Windows SDK was the safer option.
\nOnce the Windows SDK installation completes with the Debugging Tools for Windows checkbox enabled, a folder called C:\\Program Files (x86)\\Windows Kits\\ is created.
WinDbg is included there.
\nBecause the target machine this time is 64-bit Windows 7, I used the WinDbg located under C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\.
Launch WinDbg from the downloaded C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\ directory with administrator privileges.
Be careful: if you launch it as a normal user, kernel debugging will fail with the error Kernel debugger failed initialization, Win32 error 5 Access is denied when connecting to the target machine.
After launching WinDbg as administrator, choose [File] > [Kernel Debug], and connect to the target machine using a named pipe as shown in the image below.
\nIf a prompt opens and running dt nt!_* prints a symbol list like the one below, the connection has succeeded.
On the first connection, the kernel on the target machine is still running, so it will likely show Busy and you may be unable to enter commands.
\nTo make WinDbg accept commands, press Ctrl+Break (or Ctrl+Fn+B if your keyboard has no Break key), or click the Break button.
While kernel debugging is active, you cannot operate the target machine. If you want to use the target machine again, press F5 or click the Go button.
Now that I was ready to observe the behavior of the kernel driver, I went ahead and reproduced the EternalBlue attack.
\nFor the attack, I used Metasploit’s windows/smb/ms17_010_eternalblue.
When I executed the exploit from the attack server, I was able to obtain a shell with SYSTEM privileges.
\nThis confirmed that the EternalBlue attack could be reproduced in the environment built for this article.
\nNow let’s finally look at the behavior of SRV.sys in WinDbg while the exploit is running.
Because I was debugging a kernel driver, I proceeded while referring to the steps in Debugging Windows Drivers.
\nFirst, after enabling Debugger Markup Language (DML), display the command reference help.
\nThis help is extremely useful.
\nkd> .prefer_dml 1\nkd> .hh .prefer_dmlNext, display the list of loaded kernel modules with the lm command.
A number of modules will be displayed, and among them you need to identify SRV.sys, which is the target this time.\nYou can search for strings with Ctrl+f.
I found what looked like SRV.sys, and when I clicked it, the following details were displayed.
kd> lmDvmsrv\nBrowse full module list\nstart end module name\n93269000 932ba000 srv (deferred) \n Image path: \\SystemRoot\\System32\\DRIVERS\\srv.sys\n Image name: srv.sys\n Browse all global symbols functions data\n Timestamp: Sat Nov 20 17:45:29 2010 (4CE78AA9)\n CheckSum: 0005542B\n ImageSize: 00051000\n Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4\n Information from resource tablesIt appears that SRV.sys is loaded starting at address 93269000.
Next, I identified the address of the problematic function inside SRV.sys.\nRunning the srv!a* command displayed the functions in SRV.sys alphabetically.
The vulnerable function is SrvOs2FeaListSizeToNt, but because the problematic function is called from srv!SrvSmbOpen2, I first identified the address of srv!SrvSmbOpen2.
This completes the setup for kernel debugging with WinDbg.
\nBefore tracing memory behavior during the EternalBlue attack, I wanted to inspect the traffic and see what kind of attack packets were being sent.
\nSurprisingly, there were only about 40 SMB packets sent from the attack server, so I started by looking at those.
\nThe combined size of the 606th and 607th FEA records is 62517 in decimal, and the transfer is carried by exactly 15 packets of 4096 bytes.
At the point where the 607th FEA record is sent, the flow appears to be that the buffer overflow is achieved by exceeding the 0x10000 region specified by SizeOfListInBytes and overwriting the next pool in memory, which belongs to SRVNET.sys.
Finally, I wanted to observe via kernel debugging how sending this 607th record overwrites the SRVNET buffer and part of SRVNET itself.
\nI set the breakpoints like this.
\nbp srv!SrvOs2FeaToNt+04d “.printf \\”MOV2: dst: %p src: %p size:%p\\\\n\\”,ebx,eax,poi(esp+8);g;”\n\nbp srv!SrvOs2FeaListToNt+0xd4When I inspected memory with the dd command at the timing where execution stopped on the breakpoint, it was filled with zeros.
Because the addresses also increase by +5 each time, it seems reasonable to think that this is the part filled with empty FEA records (probably).
\nDoing this 605 times is quite a lot of work, so I temporarily removed the breakpoint at srv!SrvOs2FeaListToNt+0xd4 and changed it to srv!SrvOs2FeaListToNt+0x120 just before the function ends.
I then let the exploit run all the way through, confirmed that the above processing had executed 607 times, and captured the output.
\nIn the end, the 607th record was copied to fffffa8001c9b000 from a value obtained by adding 0xf383 + 0x5 + 0x5 to the previous address, which suggests that the overflow caused by the 607th FEA is happening from there.
Finally, I wanted to confirm that the overflow-based exploit had succeeded by dumping the memory from this address through +a8, but I could not tell from the binary sequence alone whether the overwrite had actually succeeded, so I gave up.
I plan to try again someday after I have gained more knowledge of kernel debugging.
\nThis time, I summarized the results of various experiments conducted with the goal of learning the details of the vulnerability and how it is exploited by reproducing “EternalBlue.”
\nBecause this was my very first experience with Windows kernel debugging, I proceeded by trial and error, and it took quite a bit of time.
\nI think it is extremely educational not only to solve HackTheBox machines, but also to dig more deeply into the vulnerabilities used there.
\nIn particular, the “EternalBlue” covered this time can be reproduced easily using code from Metasploit or ExploitDB, so the machine itself is very easy from a box-solving perspective. Even so, I felt that properly understanding the details of the vulnerability is fairly difficult.
\nI would like to continue writing deep-dive articles on vulnerabilities in the future.\nI was reminded once again that protocol-related topics are still a bit difficult for me, so I am thinking of approaching them by starting with OSS that can be tested more lightly.
\n