睡了一觉起来，什么鬼，深信服 EDR终端检测响应平台又出事了，又爆出了两个漏洞，一个是官方公布的升级包中泄漏了源代码，一个是未授权访问，不使用账号、密码就可直接登陆管理后台。我滴天啦！
复现：
payload:https://ip:prot/ui/login.php?user=随便写一点儿字母
例如：
在登录框访问https://ip:prot/ui/login.php?user=qwer，然后回车
登陆成功：
代码分析：
根据payload,在/ui/login.php当中搜索$_GET['user']或者$_GET[“user”]
定位到20行至39行。
可以看到它先进行了判断：要是$_SERVER["REMOTE_ADDR"]等于127.0.0.2/1,执行，要是$docker=true，也
会执行，如下：
（
isset($_SERVER["REMOTE_ADDR"])：判断$_SERVER["REMOTE_ADDR"]是否有值
且
$_SERVER["REMOTE_ADDR"]的值等于127.0.0.2
或者
$_SERVER["REMOTE_ADDR"]的值等于127.0.0.1
）
或者
$docker
从第9行可以看到，变量$docker被赋值成了false
接着往下分析看：
11行：从cookie中获取的scl_session的值赋值给变量$check
14-15行：读取配置文件docker.ini，并保存在多维数组$ini_content中
17-18行：判断配置文件docker.ini中[$username]["scl_session"]的值是否与cookie中scl_session的值相等
如果是，则$docker=true，第20行判断满足，执行30行语句，$auth_value["auth_user"] = $username;
把cookie中username的值赋值给auth_value,登陆成功。
好吧，分析至此，我也明白了，这个免密登陆不是由这个$docker引起的。
但是如果设置cookie当中scl_session的值为docker.ini中scl_session的值，也能造成未授权访问。
那就一定是由$_SERVER["REMOTE_ADDR"]=127.0.0.1或者127.0.0.2，引起的
在文件夹中搜索这个两个IP地址：
发现一个文档中存在一下内容：
注：学艺不精，各位见笑了，怀疑漏洞触发的原因也可能为nginx代理设置问题或是docker配置问题
getenv("EPS_INSTALL_ROOT")取环境变量EPS_INSTALL_ROOT的值-EPS安装路径，并在后面拼接上config/docker.ini
file_exists() 函数检查文件或目录是否存在。
parse_ini_file() 函数解析一个配置文件（ini 文件），并以数组的形式返回其中的设置。
| process_sections | 可选。如果设置为 TRUE，则返回一个多维数组，包括了配置文件中每一节的名称和设置。默认是 FALSE。 |