ofcms代码审计

2022-07-29

漏洞审计思路

审计流程

主要是看使用了什么框架，是ssm还是ssh，还是servelt等。
看针对权限控制是否使用了shiro,springsecurity等统一的权限控制框架，如果未使用任务权限验证框架，而是采用了手动的人工权限验证，则容易存在业务逻辑漏洞。
通过lib文件夹下，pom文件等查看使用的开源组件和版本信息，作为审计开源组件通用漏洞的突破口
了解平台所使用的市场上常见的成熟的cms技术和版本，可以从供应链入手查找其他类似项目
熟悉系统的源码构成，按照MVC思想，了解主要的功能模板和对应的javabean
在1-5基础上针对各类漏洞源码分析发现漏洞

Ofcms-1.1.2代码审计

首先可以看目录结构和readme的文档，可以发现并没有使用常见的ssm和ssh，而是使用了一个叫做jfinal的框架。

同时也找到了对项目结构的解释

通用性漏洞-SSTI模板注入

通过阅读pom.xml可以发现，使用了freemarker开源组件freemarker开源组件

freemarker模板注入

<dependency>
           <groupId>org.freemarker</groupId>
           <artifactId>freemarker</artifactId>
           <version>2.3.21</version>
</dependency>

接下来我们可以去寻找对应的模板新增页面（业务功能）。

功能点是在后台的模板设置里面

在其中插入我们网上搜索到的payload

1	<#assign value="freemarker.template.utility.Execute"?new()>${value("calc.exe")}

回到首页弹框计算器

在当时抓包发现请求的路径为

找到源码中的路径

1	src/main/java/com/ofsoft/cms/admin/controller/cms/TemplateController.java中的save方法。

public void save() {
        String resPath = getPara("res_path");
        File pathFile = null;
        if("res".equals(resPath)){
            pathFile = new File(SystemUtile.getSiteTemplateResourcePath());
        }else {
            pathFile = new File(SystemUtile.getSiteTemplatePath());
        }
        String dirName = getPara("dirs");
        if (dirName != null) {
            pathFile = new File(pathFile, dirName);
        }
        String fileName = getPara("file_name");
        // 没有用getPara原因是，getPara因为安全问题会过滤某些html元素。
        String fileContent = getRequest().getParameter("file_content");
        fileContent = fileContent.replace("&lt;", "<").replace("&gt;", ">");
        File file = new File(pathFile, fileName);
        FileUtils.writeString(file, fileContent);
        rendSuccessJson();
    }

可见这个方法并没有做任何过滤，而且貌似还助长了XSS漏洞，它主动把&lt换成了<。猜想肯定是为了保证业务的正常处理。

另一种利用方式

除了该模板注入，我们换个思维想，这个方法恰巧也达成了任意文件上传。

1 2	File file = new File(pathFile, fileName); FileUtils.writeString(file, fileContent);

因为其只是单纯的创建了文件并且写入了文件内容。所以我们重新发送此包

发现在Tomcat的web-inf包下有了新的文件

SQL注入

SQL注入需要关注的点是来自于前端的参数且用户可控且为安全处理后拼接到sql中执行。

发生场景有:1.在jdbc技术中直接使用”+”来拼接。2.在mybatis中使用$符号。3.在hibernate中使用“+”

需要特别注意一下将从前端获取到的值作为数据sql语句执行的字段名称，而不仅仅是字段的value。

通过对前端界面的寻找，发现在管理界面的系统设置有个代码生成的功能。

并且增加处可以直接输入sql语句

抓包发现请求路径如下

通过寻找源码发现调用的是

1	src/main/java/com/ofsoft/cms/admin/controller/system/SystemGenerateController.java中的create方法

	public void create() {
		try {
			String sql = getPara("sql");
			Db.update(sql);
			rendSuccessJson();
		} catch (Exception e) {
			e.printStackTrace();
			rendFailedJson(ErrorCode.get("9999"), e.getMessage());
		}
	}
}

进行跟踪溯源，我们可以知道底层调用的方法如下：

int update(Config config, Connection conn, String sql, Object... paras) throws SQLException {
      PreparedStatement pst = conn.prepareStatement(sql);
      config.dialect.fillStatement(pst, paras);
      int result = pst.executeUpdate();
      DbKit.close(pst);
      return result;
  }

这里就会发现，开发者犯了一个错误，prepareStatement虽然使用的是预编译对象，但是并没有按照预编译占位符的方式进行处理（这就让预编译形同虚设）。

正确的形式应该如下：

1 2	PreparedStatement pstmt = (PreparedStatement) conn.prepareStatement(sql); pstmt.setString(1,sno);

所以我们可以发现该sql初并没有做任何安全处理，那么我们就可以小注一下

1 2	update of_cms_link set link_name=updatexml(1,concat(0x7e,(user())),0) where link_id=2

报出数据库名字。

XSS漏洞

XSS漏洞的审计，我们一般先通审有不有一个XSS过滤器的存在，因为XSS漏洞⽆法针对所有的参数进⾏ESAPI,也就是说⼀般⽆全局过滤器多数存在XSS注⼊漏洞。

进行全局搜索，发现确实有XSS过滤相关字样，但是这个东西只是单纯过滤ueditor富文本编辑器的，并没有对整个web做xss检测。

一直找也找不出个所以然来，干脆就直接上，在文章管理里新建一个公司新闻，然后填入XSS代码。

为了验证刚才只对这个富文本编辑器做xss处理，所以我弹出不同的值。

去首页新闻处点击新增的新闻，发现弹框只能1和4，至少证明了富文本编辑器确实有过滤效果，其余并没有做其他过滤。