记一次某通奇葩的登陆绕过漏洞

 

前言：故事起源于我大哥"深情哥"告诉我，某通比较好挖些，于是我就抱着试试的心态去摸摸。

 

大哥照片

信息搜集-敏感信息泄露

 

00x1:  

抱着捡漏的心态我就开始了

首先就通过被动扫描，用资产灯塔搜集资产，挂着看能不能搜到什么服务，结果发现了spring框架的敏感信息泄露，运气感爆棚，于是进行相关目录扫描，看看有没有更多的可用信息。

00x2:

于是我就尝试下载heapdump文件进行分析，此文件包含很多可利用信息，比如：当前使用者token、当前使用数据库库名、账号密码、当前所启用相关服务的账号密码....等等大量敏感信息。

利用JDumpSpider-1.1-SNAPSHOT-full.jar对heapdump文件进行分析

很多账号密码可以看到，尝试了网易邮箱利用、相关服务利用，均未成功，其中可以直接利用的是druid服务

00x3:

利用发现的druid服务的账号进行登录，发现登陆成功，从中间可以直接看到相关的url接口以及session信息（随后截的图）

00x4:

先利用session信息进行替换看是否登录成功，通过不断地尝试发现无法利用，于是转换思路利用它的session进行对相关目录访问，发现可以，随后经过尝试发现，其实可以未授权访问相关信息

信息搜集-未授权访问

 

00x5:

根据以上所得到的相关信息，发现可以未授权访问，发现泄露了一些相关人员的敏感信息

信息搜集目前到此所得信息就这么多，提交后他们说没有更深入利用，就只给了30，其实不止的

重点来喽

奇葩的登录绕过

 

00x6:

根据以上相关信息呢，我有想找找这个站还有什么洞，于是我就着手尝试业务逻辑，发现无从下手，于是我就观察它的返回包，就想着可以试试更改返回包吧，结果发现没有什么效果。

00x7:

我又转念一想，这个ip下面长得一样的站很多，于是我就搜集了他的很多端口，进行尝试和观察。

我随意输入账号密码拦截登录的响应包

00x8：

将其信息改为如下

说明：为什么要这么改？其实这是一种登录绕过的方式。有这么一种情况，客户端与服务端进行通讯时，首先客户端将登录信息发至服务端，服务端进行校验，然后将成功或失败的结果发至客户端，客户端再进行数据校验，随后客户端再发包将信息发至服务端，服务端再继续与客户端通信。在此过程中呢，我们就可以在第一次服务端响应客户端的数据进行篡改，使客户端误以为所发的数据是正确的，这样，客户端再向服务端发送后续正常的用户数据请求，服务端即返回相关请求数据。最终达到登陆绕过。

00x9：

进行尝试发现仅仅更改以上信息无法达到绕过的目的，于是我重新拦截接着一步一步放包，观察还有什么数据包进行了相关校验，放到第二个数据包时，我发现这个数据包貌似是检测当前用户的一个数据包，因为current是当前的意思

于是我就想着丢包试试，让它无法进行此次校验，达到进一步绕过，结果发现不行。

00x10：

正当我想着放弃的时候，突然想到上面的未授权，里面有个接口是user/list，他可直接进行未授权访问，于是我就尝试直接更改current为list，让其不对当前用户检验，直接请求list用户列表，相当于正常用户发送请求数据一样，更改后一直放包，发现成功绕过了。当前用户仅为普通用户权限

因为资产很偏所以奖金很少

最后我帮朋友问一下，谁的身份证和复印件掉了，赶快联系我

原来是我的，呜呜呜呜呜

原文始发于微信公众号（CtrlC安全实验室）：记一次某通奇葩的登陆绕过漏洞