In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-02-25 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >
Share
Shulou(Shulou.com)06/02 Report--
How to use Microsoft.Workflow.Comiler to execute unsigned arbitrary code, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, hope you can gain something.
Bypass technique
Microsoft.Workflow.Comiler.exe is a utility that comes with the .NET Framework by default, and users can provide a serialized workflow to execute arbitrary unsigned code in the form of a XOML workflow file. This bypass technique works very similar to CaseySmith's msbuild.exe bypass technology. Microsoft.Workflow.Comiler.exe requires two command-line arguments, the first of which must be the path to a XML file (consisting of a serialized CompilerInput object), and the second must be the file path where the serialized compilation results are written.
The root node of the execution vector is that Microsoft.Workflow.Comiler.exe calls the Assembly.Load (byte []) method provided by the attacker, but simply loading the compilation file does not implement code execution. When the attacker provides C # or VB.Net code in the form of a XOML file, the system will call the class constructor during assembly. The only restriction here is that the class constructor must be derived from the System.Workflow.ComponentModel.Activity class.
This technology can bypass current code integrity control mechanisms on many security products, such as WindowsDefender application controls (including Windows 10S), AppLocker, and other application whitelist-based products. But here we are not worried about how to bypass the application whitelist, we need to focus on how to execute arbitrary unsigned code through a signed and highly trusted built-in application.
The PoC attack process of bypass technology is as follows:
1. The resulting XOML file is stored on the target disk, and the XOML file should contain C# or VB.Net code provided by the attacker for compilation, loading, and calling. The attack logic needs to be implemented in the class constructor, which is derived from the System.Workflow.ComponetModel.Activity class.
two。 Stores the XML file that contains serialized CompilerInput objects to the target disk.
3. Provide the XML path and execute the Microsoft.Workflow.Comiler.exe.
The following is a sample call to Microsoft.Workflow.Comiler.exe:
The contents of C:\ Windows\ Microsoft.Net\ Framework64\ v4.0.30319\ Microsoft.Workflow.Compiler.exetest.xml results.xmltest.xml are as follows: the contents of the test.xomlfalsetruefalsefalse-1falsefalsefalseCSharptest.xoml file are as follows:
After calling Microsoft.Workflow.Compiler.exe, it compiles the C # code, loads the compiled DLL, and invokes the "Foo" constructor.
The process of discovering vulnerabilities
Personally, I prefer to study the security issues of .NET Framework methods. For example, one of the unsafe methods is Assembly.Load (byte []). Here I chose to use the dnSpy tool to determine the scan, and found the code snippet in the System.Workflow.ComponentModel.Compiler.WorkflowCompilerInternal.Compile method as follows:
After analyzing the workflow of the GenerateLocalAssembly method, I found that this method will eventually call the standard .NET compile / load method [related materials]:
Simply loading an assembler does not allow arbitrary code execution, but fortunately, the System.Workflow.ComponentModel.Compiler.XomlCompilerHelper.InternalCompileFromDomBatch method iterates through all loaded assemblers and then instantiates all instances that inherit the System.Workflow.ComponentModel.Activity class:
Now that we have almost seen the "hope" of arbitrary code execution, we need to figure out which code format to use in order for the program's compiler to receive input data and XOML workflow files.
When Microsoft.Workflow.Compiler.exe starts, the first parameter is passed to the ReadCompilerInput method, which, when it receives the file path, deserializes it into a CompilerInput object:
So the question now is, how do you generate serialized CompilerInput objects? Here I found an internal method called Microsoft.Workflow.Compiler.CompilerWrapper.SerializeInputToWrapper:
I also wrote a PowerShell function to realize the automatic generation of XML files:
Function New-CompilerInputXml {
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.