记一次渗透测试信息收集(子域名+端口)

目录

一、当主站没啥业务功能时

二、信息收集之子域名挖掘

三、信息收集之端口扫描

四、弱口令

五、后台SQL注入

六、SQL注入之排序注入

七、SQL注入之排序注入2

八、SQL注入之排序注入—补充

        碰到个有意思的，记录一下

---

一、当主站没啥业务功能时

    www.kxxxxxxxxxxxxxxoo.com

似乎没有啥业务功能点，开始寻找该单位的其他的资产（站点）

…

二、信息收集之子域名挖掘

针对“域名”作信息收集

这里没有借助其他工具，只是单纯的在fofa里直接搜索主域名

发现存在 子域名 service.kexxxxx.com

下方箭头指示的ip，大概率是真实ip

点击访问此子域名，发现页面用户名及密码字段已自动填充

打开f12，定位到密码处，将type=password 的值改成任意 type=xxx 字段

就可以得到明文密码了

奇怪的是，这里点击登录一直在转圈圈，页面无任何反应...

如同是一个假的登录框，无利用价值......

开始思考其他可测试方式

…….

三、信息收集之端口扫描

上文提到“真实ip”的概念，此个过程为专门针对于“ip”作信息收集

第一种方式：在fofa中点击此处

会返回fofa中此“ip”历史开放端口的记录（缺点：不够全面，没有最新开放端口）

第二种方式：使用端口扫描器对此“ip”进行开放端口测试，如nmap等

这里我没有使用全端口扫描

接下里就是一个端口一个端口的访问

......

四、弱口令

8087端口上开放了一个应用系统后台

盲猜弱口令 admin/123456 admin/admin 无果（无test用户），就想着爆破，然后看了下登录的请求包，发现是302跳转（不管密码是否正确，都是302跳转）

此时，两种方式

1. 继续盲猜弱口令，尝试更多常见口令

1. 啥也不管，直接爆破

为何密码与否会有字节差异呢

来观察一下，

Location : 该属性表示该网页的跳转网址，也被称为重定向网址。

Ps：以后碰到302跳转的登录请求，可以尝试直接爆破。

五、后台SQL注入

        用户管理处，点击搜索

        一个单引号

        两个单引号

        三个单引号

        四个单引号

        ...

        确定存在SQL注入

        开始手工注入（也可以用sqlmap）

        Poc: 'and+'a'+like+'a

        //搜索处的SQL查询语句大多为  '' like '%%'

跑用户名：c......

        Poc:1'or+user()+like+'c%

六、SQL注入之排序注入

        关键参数值 desc

检测方法：

,1  &&  ,0

,1/1  &&  ,1/0

,exp(71) && ,exp(710)

异或

        这里使用的是exp() //数值大于709就会溢出

        Poc：AdminID+desc,exp(7)

        Poc:AdminID+desc,exp(710)

        此时不难发现，溢出时，响应时间比较长

        所以在盲注中，建议条件为真时溢出

        Poc 开始变形

        Poc:AdminID+desc,if(user()+like+'r%',exp(710),exp(7))

        Poc:AdminID+desc,if(user()+like+'c%',exp(710),exp(7))

七、SQL注入之排序注入2

        同ip的8080端口，注册一个账号进行登录

        点击产品管理

        此时的请求包

        Orderby参数处添加单引号无任何区别

其他的测试思路：

        orderby 顾名思义 是对字段进行排序，我是否可以赋给它一个很大的值，看是否会有异常（当排序的字段数超过查询语句中的字段数，会产生异常信息）

        页面出现异常信息，说明orderby 参数的值是代入到数据库进行查询的

       使用反引号

        使用排序注入常规的测试方式

        构造poc，注出用户名

        值得一说的是，这里用不了substr  也用不了 单引号 及 ascii函数

        //substr

        //单引号

        //ascii

        这里使用 mid  hex

        Poc：

        1,case+when+hex(mid(user(),1,1))=63+then+exp(789)+else+exp(0)+end

        得到用户名的第一位为 c

        ......

八、SQL注入之排序注入—补充

        碰到个有意思的，记录一下

        1、因果的因：

        最近碰到挺多排序注入（关键字：orderby，desc，asc等）构造的poc大多为

        1,if(1,exp(789),1)

        1,case+when+hex(mid(user(),1,1))=63+then+exp(789)+else+exp(0)+end  

        ……

        （poc的书写取决于站点是否对相关函数、单引号有所拦截）

        总之都是利用盲注的方式来获取数据，从基础的poc fuzz到poc2、poc3甚至poc4，取决于waf的强弱、个人习惯。

        2、因果的果：

        图一是使用报错注入获取用户名

        图二是验证此poc是否可用（图一图二是同一系统不同的注入点）

        图三是在有waf的情况下使用（有没有觉得这个poc有点眼熟呀）

        拿着这个poc去尝试这些天碰到的排序注入，发现都可以嗷，对比盲注来说，漏洞证明的过程还是会节省一些时间。暂不知是否通用，还需要大量的案例来验证。

        由于时间关系，只验证了排序注入，也未在本地尝试。

        ……