Preface
Because I was not willing to be called a monkey who could only click the mouse, I started mining a certain SRC vulnerability for more than a week. The article is a bit long, but please be patient and read it. It records the complete actual practice of SRC vulnerability mining.
Osmosis process
Because the chosen lucky person did not plan the test scope, there is no scope this time.
First take a look at the main domain name to see what effective information can be collected:
Found a search box:
Test point +1
I looked through the pages and found nothing useful.
After grabbing the packet, I found that the website has a CDN and special files:
Difficulty +1, Information +1
Google it and you will find that Sitecore is a CMS. If you can determine the version of this CMS, it becomes a white-box audit. However, after trying it, you can't determine the version and you can only test it with CMS vulnerabilities disclosed on the Internet.
Only one CVE-2021-42237 (Sitecore XP remote code execution vulnerability) was found online. Find a POC to try:
After searching for a long time, I could only find these few. It may be because this CMS has relatively few users or because it is well-written and has no loopholes.
Test with one of these:
POC utilization failed, prompting a connection error. Analysis of POC code:
The POC address of the discovery request is:
After manually requesting the URL address, I found that access was denied by the server, and the other party restricted access to sensitive addresses:
After searching for CMS information, we learned that /Sitecore is the backend address directory of Sitecore CMS, which makes sense. We can try to bypass restricted access in the future.
+1 for the test point.
Run a port scan on it to see what services are exposed. You can use nmap or other methods, but I prefer to use nmap for port scanning.
Access the collected ports one by one. Only port 443 can be accessed. This website has a MySQL service. Port 1723 has a VPN service used by internal staff, but it cannot be accessed. The same is true for other ports.
Use public online platforms to scan:
I confirmed the information collected earlier and found a few more test points.
The simple information collection of this domain name is completed. Let’s see what loopholes there are. You can do a small test on the loopholes:
You can see that the website does not filter special symbols, so there may be SQL or XSS injection here.
Looking at the source code of the page, I found that the statements here seem to be very unsafe and may not have been translated.
The test found that there is a WAF. You can try to bypass the WAF here, but you will not bypass it for now. Picking the hard persimmons at the beginning of the penetration test may lead to a bad start.
Then go online to see what vulnerabilities the collected plug-ins may have. After searching, I only found that the Vue framework has a template injection vulnerability that may be useful:
But unfortunately, Vue is a front-end framework, and the impact of Vue's vulnerabilities is bound to not be too great. Usually Vue.js data is data bound through double curly braces { {}} or v-text directive. Vue.js will automatically compile the corresponding template into JS code. But its source code does not filter the input data. Test with public POC:
Sure enough, it was intercepted by WAF.
Trying another way to test it also doesn’t work:
There may be additional benefits to visiting robots.txt:
Make sure the CMS is Sitecore, access/api is 403, access Sitemap:
Continue jumping:
It is an XML configuration file used when developing a website. It is considered an information leak, but it is not harmful.
You can also try 403byass. The specific bypass process will not be demonstrated here. The bypass is achieved by covering the path with X-Rewrite-URL:
But when I went to the page, I found that it was bypassed, but not completely bypassed. It was still redirected to the main page.
Then collect side sites and subdomains. You can use tools like Layer or dark engines like FOFA and SHODAN. The author used FOFA here to collect:
As the saying goes, a cigarette, a glass of wine, and a website test are enough for a day. I collected it for a day, and also tested it for a day. I used various missing scanning tools, and the IP was blocked after scanning. Whether it’s delaying or hooking up a proxy, after all, there are loopholes that the missed scan tool cannot scan. Besides, I can only use the missed scan tool, so I’m still a monkey who can click the mouse. In order to successfully eat the watermelon this time, We had no choice but to use manual testing for the most part.
Of course, it is impossible to gain nothing in one day, because the company tested this time is a large-scale company (a leader in the industry), so their exposure will be relatively wider:
We have collected several relatively useful sites:
These sites are very interesting. They use the same CMS, have the same content, and have the same functions. There is no difference. It may be a test page used when building the website.
There is also a website titled Project Management Website, but when I click on it, it has no functions. Even the background scan and the missing scanning tool scan nothing (isn’t this just a scam?).
But this is when I discovered that a website is blank and displays nothing. Generally speaking, this kind of blank website may have unexpected gains, because it may be a website that the developer has missed.
I scanned it with the background scanning tool and found two files:
visit
The development files of the website were leaked and we got the specific version of the website plugin
The other is a GIF picture:
There is nothing special about the page. Right-click to view the source code of the page and see that the developer ID value is leaked:
However, the two discovered vulnerabilities have no substantive effect and may be exploited later with other vulnerabilities. In actual combat situations, it’s so frustrating
Then test the previously discovered website with the same template, and also use the POC of Vue's template injection vulnerability:
The page outputs the result of the multiplication operation, further verification confirms that there is a Vue template injection vulnerability, and a successful pop-up window appears:
After verification, this vulnerability also exists in the other two websites. It can be found that this vulnerability exists because these test websites did not build WAF. It may be a site that the developer missed. Therefore, you have to be picky about the soft persimmons. You can't just test a fortress with heavy defenses from the beginning. That may waste a long time without any gains.
So now we can know that this vulnerability must also exist on the main domain name, and what needs to be done is to bypass the WAF. There are tutorials on how to bypass them online, so I won’t go into details here. This is the final result:
Payload：{ {constructor.constructor%0a(%27\u0061\u006c\u0065\u0072\u0074`1`%27)()}}
I succeeded in eating watermelon, but this vulnerability is essentially just an XSS. I can’t just let it go after it took me so long, right?
Continue to collect and test domain names. During this period, we collected some various website backends. We only briefly tested whether there were SQL and logic vulnerabilities, but there was no substantial gain. I really encountered a tough problem. These websites are maintained by personnel. Not only do they have WAF, but basically all the vulnerabilities that need to be fixed have been fixed. Even OpenSSH 1.1.1 has been upgraded to 1.1.1.c. I want to change SRC and test again. .
Finally, one day a week later, while continuing to collect information, I found a Service Web Service interface on FOFA.
I clicked on one of them and found that the calling code of the interface was given, and there were also interfaces for file upload and XML upload:
Try calling the interface:
The interface call failed, and I tried many times, but it still failed. Changing safe files, suffixes, and 00 truncation did not succeed. Because I was not sure what the specific reason was, I wrote a java script to test the specific reason:
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();//Set the request method and request header
con.setRequestMethod("POST");
con.setRequestProperty("Content-Type", "text/xml; charset=utf-8");
con.setRequestProperty("SOAPAction", "http ://tempuri.org/UploadFile”);// Construct the SOAP message body
String fs = ""; // TODO: Convert the file content to a base64 encoded string
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” +
“” +
“” + fs + “” +
“” + path + “ ” +
“” + fileName + “” +
“” +
“</soap:Body>” +
“</soap:Envelope>”;//Send SOAP message body
con.setDoOutput(true);
OutputStream os = con.getOutputStream();
os.write(soapXml.getBytes());// Read the response
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();//Print response
System.out.println(response.toString());
}
}
The program prompts the other party's server to actively refuse the connection, indicating that the administrator has restricted the IP address of calling the file upload interface (which is really a hard nut), and the same is true for XML upload.
I had no choice but to change the direction and use the background scanning tool to scan, and a large number of sensitive files were indeed scanned out:
Because Uncle Hat + these data are really very sensitive, it is not convenient to display them. I can only give a rough summary:
target.com/log/ stores the server log file
target.com/data/ stores the database file
target.com/data/Setting.xml contains the database user name, password, and IP address
target.com/old/ contains the server name and password
target .com/trace.axd contains the application code carried by the server
target.com/update/ stores internal system files, applications, dll
target.com/update/Setting.xml service name, IP, computer name, password and internal IP address
This watermelon is sweet, but when the penetration test progressed to this point, it had already taken a week, so the author was not very satisfied. So let’s test the remaining interfaces one by one. One of the interfaces is used to inventory product information:
Using the file leak vulnerability, construct the data packet and then test it:
Enter the product number in the whcode parameter, and the return value of the StocktakingStartResult parameter in the returned package is 0.
If you enter any data that does not exist, the return value of the StocktakingStartResult parameter in the returned package is -1. It can be seen that the return value of the interface call is 0 if it is successful, and -1 if it fails:
Further construct a judgment statement to see if there is a SQL injection vulnerability:
- Verification: -1' OR 1=1 ==> true return value is 0
- Verification: -1' OR 3+220-220-1=0+0+0+1 ==> false The return value is -1
- Verification: -1' OR 3*2=6 AND 000220=000220 ==> true The return value is 0
So there must be a SQL injection vulnerability at the whcode parameter.
After the judgment is completed, SQL injection begins:
I found that an error was reported. At first, I thought that the statement structure was wrong. After changing several statements to no avail, I wanted to see what the echo of the calling interface was and what the problem was, so I wrote a script to help judge.
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:Bodytns:StocktakingStarttns:usertsSLAueP</tns:user>tns:whcode1</tns:whcode>tns:PDtype1</tns:PDtype>tns:UNITCODE94102</tns:UNITCODE>tns:BRANDCODE94102</tns:BRANDCODE></tns:StocktakingStart></soap12:Body></soap12:Envelope>”;// 创建连接
URL requestUrl = new URL(url);
HttpURLConnection connection = (HttpURLConnection) requestUrl.openConnection();// Ignore SSL certificate verification
javax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(
(hostname, sslSession) -> true);
trustAllHttpsCertificates();//Set the request method and header
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();// Output echo
System.out.println(response);
}// Ignore methods required for SSL certificate verification
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()); }// Ignore classes required for SSL certificate verification
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;
}
}
}
But I was surprised to find that there was no echo, only data packets, and the echoes were all in the data packets. Then this would be difficult to handle, and I had to find another way.
After racking my brain and thinking for more than a day, I thought that since there is no echo, I would construct the entire sentence into a judgment sentence:
Payload：-1’ OR ASCII(SUBSTRC((SELECT NVL(CAST(user AS VARCHAR(4000)),CHR(32)) FROM aaaa),1,1))>0 AND 000360=000360 –
This code uses the size of the ASCII code to determine the username and password. Assume: the first ASCII code of the username is 66. If during the judgment process, 66>67, then the second half of the value will be false, and vice versa. real. In this way, the database username and password can be determined. Because I have previously learned the database username and password through an information leakage vulnerability, I directly verified the username and password, and the result was the same.
It finally paid off. It took the author more than a week, and finally I ate a big watermelon. With the SQL injection vulnerability, I don’t need to say more about it later. Of course, you have to be careful when mining SRC, otherwise there will be haters coming to find you.
Summarize:
In a word, pick the persimmons that are soft when pinched. Penetration testing ideas are the most important. Everyone has different ideas when doing penetration testing. Only when you have ideas and ideas can you proceed.
How to learn hacking & network security
As long as you like my article today, my private network security learning materials will be shared with you for free. Come and see what is available.
1. Learning roadmap
There are a lot of things to learn about attack and defense. I have written down the specific things you need to learn in the road map above. If you can complete them, you will have no problem getting a job or taking on a private job.
2. Video tutorial
Although there are many learning resources on the Internet, they are basically incomplete. This is an Internet security video tutorial I recorded myself. I have accompanying video explanations for every knowledge point in the roadmap above.
The content covers the study of network security laws, network security operations and other security assessments, penetration testing basics, detailed explanations of vulnerabilities, basic computer knowledge, etc. They are all must-know learning contents for getting started with network security.
(They are all packaged into one piece and cannot be expanded one by one. There are more than 300 episodes in total)
Due to limited space, only part of the information is displayed. You need to click on the link below to obtain it.
3. Technical documents and e-books
I also compiled the technical documents myself, including my experience and technical points in participating in large-scale network security operations, CTF, and digging SRC vulnerabilities. There are more than 200 e-books. Due to the sensitivity of the content, I will not display them one by one.
Due to limited space, only part of the information is displayed. You need to click on the link below to obtain it.
4. Toolkit, interview questions and source code
"If you want to do your job well, you must first sharpen your tools." I have summarized dozens of the most popular hacking tools for everyone. The scope of coverage mainly focuses on information collection, Android hacking tools, automation tools, phishing, etc. Interested students should not miss it.
There is also the case source code and corresponding toolkit mentioned in my video, which you can take away if needed.
Due to limited space, only part of the information is displayed. You need to click on the link below to obtain it.
Finally, here are the interview questions about network security that I have compiled over the past few years. If you are looking for a job in network security, they will definitely help you a lot.
These questions are often encountered when interviewing Sangfor, Qi Anxin, Tencent or other major companies. If you have good questions or good insights, please share them.
Reference analysis: Sangfor official website, Qi’anxin official website, Freebuf, csdn, etc.
Content features: Clear organization and graphical representation to make it easier to understand.
Content summary: Including intranet, operating system, protocol, penetration testing, security service, vulnerability, injection, XSS, CSRF, SSRF, file upload, file download, file inclusion, XXE, logical vulnerability, tools, SQLmap, NMAP, BP, MSF…
Due to limited space, only part of the information is displayed. You need to click on the link below to obtain it.