MSSQL 注入漏洞利用技术分析

漏洞发现过程

1. 初始发现：

   • 在某目标上触发单引号报错，发现疑似注入点
   • 根据报错回显判断后端数据库为 MSSQL
   • 基础报错注入语句尝试失败，返回"格式不对"提示

2. 初步测试：

   • 使用基础语法 X'OR'1'='1 尝试
   • 返回语法错误：Incorrect syntax near the keyword 'OR'
   • 测试表明输入被带入SQL查询但出现语法错误

问题分析

1. 两种可能性：

   • 输入格式有特定要求
   • SQL查询不是标准查询语句（可能在存储过程/自定义函数/复杂查询中）

2. 排除第一种可能性：

   • 不同格式输入均返回相同语法错误
   • 确认语句被带入SQL查询

3. 确认第二种情况：

   • 需要闭合单引号
   • 注释方式尝试（X'+or+1=convert(int,@@version)--）返回"Invalid format"
   • 无论输入什么注释都返回"Invalid format"

突破方法

1. 成功利用技术：

   • 使用原生方法中的单引号闭合：waitfor delay '0:0:2'
   • 延时成功，确认漏洞存在

2. 进一步验证：

   • 使用延时盲注：'if(len(db_name()))<100 WAITFOR DELAY '0:0:2
   • 发现用户名长度测试成功：'if(len(user))<100 WAITFOR DELAY '0:0:2

限制条件

1. 长度限制：

   • 发现存在40字符限制
   • WAITFOR+DELAY+'0:0:2 占用20字符
   • 剩余20字符空间限制了技术选择

2. 应对策略：

   • 使用LIKE替代SUBSTRING和ASCII
   • 简化IF语法：用空格代替括号
   • 示例：'if+len(user)=13+waitfor+delay'0:0:2

实际利用技术

1. 用户名爆破：

   • 使用LIKE和通配符：'if+user+like'i%25'waitfor+delay'0:0:2
   • 分段测试：'if+user+like'is%25' 和 'if+user+like'%25user'

2. 技术限制：

   • 无法获取数据库版本（version()占用字符过多）
   • 无法获取数据库名（db_name()同样问题）
   • 实际数据提取困难（字符限制）

技术要点总结

1. 关键发现：

   • 非常规SQL上下文中的注入
   • 原生函数单引号闭合技术
   • 严格的长度限制

2. 利用技巧：

   • 延时盲注作为主要技术
   • LIKE操作符替代常规方法
   • 语法简化（去除不必要字符）

3. 局限性：

   • 40字符限制严重制约利用可能性
   • 只能获取非常有限的信息
   • 实际危害等级较低

防御建议

1. 修复方案：

   • 使用参数化查询
   • 实施严格的输入过滤
   • 限制错误信息输出

2. 监控措施：

   • 检测异常的WAITFOR DELAY请求
   • 监控异常的LIKE模式查询
   • 设置SQL查询长度限制