某协同系统漏洞挖掘过程记录
记录一次某协同系统SQL注入漏洞挖掘过程
记录一次某协同系统SQL注入漏洞挖掘过程 0x01 寻找注入点 ---------- 分析项目结构和依赖，发现没有如mybatis等第三方数据持久化框架，存在Dao目录 > 在Java Web开发中，DAO（Data Access Object）是一个设计模式，用于将数据访问逻辑从业务逻辑中分离出来，提高代码的可维护性和可重用性。DAO层是一个抽象接口，封装了数据的CRUD操作（增加、删除、修改、查询），并且提供了面向对象的方式访问数据库。 所以一般来讲其与数据库交互的代码都是在该目录中实现的。 我们首先找到dao接口（主要是定义了对数据库进行CRUD操作的方法） 其中`SysDao`接口定义了查询数据库等操作的方法  他有5个实现，其中`BasicDaoImpl`，`ModeDaoImpl`和`SysTableDao`为Dao实现类  我们看到在`SysDao`定义方法中`getStringData`这个方法看命名就像是通过传入string来获取数据，于是我们根据到`getStringData(String var1)`的实现  其在`SysTableDao`类中，调用重载方法`String getStringData(String sql, Object[] params)`  最终调用`getStringData(final String sql, final Object[] params, boolean debug)`，该方法也是`getStringData`的具体实现  其主要逻辑是 - 从回调方法允许获取`Connection`实例； - 通过`Connection`实例创建`PreparedStatement`实例； - 通过`executeQuery`执行SQL语句，如果是查询，则通过`ResultSet`读取结果集 - 最后处理结果集类型，返回 当调用`getStringData(String sql)`是传入的参数`params`为null，不会进入if逻辑中处理，其实就相当于直接执行了`sql`参数。 于是我们寻找哪里调用了`getStringData(String)`方法。  发现有6个jsp中调用了`getStringData(String)`方法 一个个跟进发现除了index.jsp外其他jsp均可控  例如`share_select.jsp`中获取请求中`type`和`fid`参数，当`type`的值为`2`时会直接拼接`fid`到sql语句中，调用`getStringData`方法。这里很明显存在SQL注入。 但是尝试直接访问该JSP会跳转至登录页，该系统存在jsp的鉴权操作。我们顺势找找有关的filter，看有没有可以绕过的方法。 0x02 绕过鉴权 --------- 我们找到`web.xml`，寻找有没有相关filter  果然有一个拦截`.jsp`的filter，跟进到其中找到`doFilter`方法实现  首先调用`ServletRequest.getRequestURI()`获取请求接口地址，随后判断请求接口地址是否包括或者以某特定字符串结尾做响应处理。从中看到当我们请求jsp时会调用`validata()`方法  其主要是获取请求参数，检测sql注入黑名单字符： ```java private static boolean sqlValidate(String str) { str = str.toLowerCase(); String[] badStrs = new String[]{"exec%20", "execute%20", "drop%20", "truncate%20", "net%20user%20", "xp_cmdshell%20", "select%20", "insert%20", "update%20"}; String[] arr$ = badStrs; int len$ = badStrs.length; for(int i$ = 0; i$ < len$; ++i$) { String badStr = arr$[i$]; if (str.contains(badStr)) { return true; } } return false; } ``` 当存在以上黑名单字符串时返回true，最后进入if逻辑跳转至登录页。 扎眼一看好像该filter只会对参数存在sql注入黑名单字符串的请求进行跳转，直接访问应该是直接放行，但是我们实际访问还是跳到了登录页，有点迷惑。 根据关键字找到该filter中有一个方法`verificationURL()`：  当是未授权请求时（即UserSession为null）会进行设置返回包跳转，在doFilter方法中有三处调用  当我们访问`xx.jsp`时会进入到这个if判断中 ```java if ((!uri.endsWith(".jsp") || !this.isNotValidatePage(uri)) && !uri.endsWith(".xml") && !uri.endsWith(".xf") || this.verificationURL(request, uri, response)) ``` 其逻辑是请求`xxx.jsp`，`!uri.endsWith(".jsp")`默认为false，会依次调用`isNotValidatePage()`（`isNotValidatePage`主要是判断请求的jsp是不是登录等可以未授权方法的白名单jsp文件，默认也是返回false）和`verificationURL()`。 此时因为我们是未授权访问所以该if语句最终结果为`if(false || false || false)`不会进入到下面逻辑中，所以被进行了拦截返回到了登录页。 不过此处因为调用`request.getRequestURI()`方法，可以利用`;`进行绕过（即构造xxx.jsp;.jpg），同时在`doFilter`逻辑中当访问路径以图片后缀结尾时直接放行  于是我们可以构造访问地址为`/xxxx/share_select.jsp;jpg`可成功测试SQL注入  0x03 寻找绕过sqlValidate的利用 ----------------------- 我们回到`SysDao`接口，其还有一个继承接口`Dao`  看到其定义了`getFieldSetBySql()`的方法，这个方法也像是通过sql语法获取数据。 我们跟进来点其实现类`BasicDaoImpl`中查看其具体实现  他有两个`getFieldSetBySql`的重载方法，主要是实现是在`getFieldSetBySql(String sql, Object[] params, String tableName)`方法中 其首先是调用SQLTranslatorManager.translator()解析处理sql语句  这里`translator`默认是`false`，所以直接返回原始sql语句  回到`getFieldSetBySql`方法，处理完sql语句，调用`this.getDataTable`方法执行sql语句获取结果  因为传入`tableName`为null，所以不在if逻辑中，当我们调用`getFieldSetBySql(String sql, String tableName)`方法时，传入`params`参数为null，也会跳过`ToolFormatSql.format(sql, params);`，最后调用`execute`方法执行sql语句。 分析完`getFieldSetBySql`方法处理逻辑，我们寻找调用该方法且参数可控地方，利用IDEA找到了多处调用  但是基本都是拼接`user.getUserID`作为SQL语句，没有找到可控点，一时陷入不知所措 不过根据javaweb项目 有`Dao`层就会有`Service`层 > Service层叫服务层，被称为服务，粗略的理解就是对一个或多个Dao进行再次封装，封装成一个服务，所以这一层不会是一个原子操作了，需要事务控制。 我们在其`Service`层寻找有没有调用`getFieldSetBySql`的方法，经过筛查最终找到一处在`FormService`类中调用`getFieldSetBySql`的方法，其拼接参数到sql语句且处理逻辑比较简单  右键方法名找到调用该方法的地方，最后定位在`validate.jsp`中  可以看到这里解析请求中的json数据，根据type选择处理方式，当type等于0是进入`formService.getFormTableInfo`方法，所以`relId`这个参数存在SQL注入风险，同时根据json特性可通过unicode编码绕过前面filter中对sql注入的检测，具体利用就不赘述了
发表于 2023-07-24 09:00:00
阅读 ( 6618 )
分类：
漏洞分析
0 推荐
收藏
1 条评论
中铁13层打工人
79 篇文章
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
