01. Concept introduction
1.1 xss
XSS attacks usually refer to exploiting vulnerabilities left during web development and injecting malicious instruction code into web pages through clever methods, allowing users to load and execute web programs maliciously created by attackers. These malicious web programs are usually JavaScript, but can also include Java, VBScript, ActiveX, Flash or even plain HTML. After a successful attack, the attacker may obtain various contents including but not limited to higher privileges (such as performing some operations), private web content, sessions, and cookies.
Reference: Baidu Encyclopedia
1.2 pr privilege escalation
PR privilege escalation exploits a local overflow vulnerability in Windows. Its main function is to elevate low-privilege users to system privileges. It is common in webshell privilege escalation. The patch number is KB952004.
02. Shooting range environment
Attack machine: Mac ip: 10.211.55.2
Target drone: Windows Server2003 + xycms
Moving website ip: 10.211.55.17:81
Examine security testing capabilities:
If you want to learn automated testing, I recommend a set of videos to you. This video can be said to be the number one automated testing tutorial on the entire network played by Bilibili. The number of people online at the same time has reached 1,000, and there are also notes that can be collected and distributed. Lu Dashen technical communication: 798478386
03. Security testing process
ps: There are currently a variety of safety solutions available for testing at the shooting range. The solutions in the article are for reference only!
3.1 Information collection
Browse the website:
3.1.1 Directory Scan
Here, first use the directory scanner to scan the directory:
dirsearch -u http://10.211.55.17:81/
[14:59:34] 301 - 149B - /js -> http://10.211.55.17:81/js/
[14:59:34] 403 - 32B - /%2e%2e//google.com
[14:59:34] 500 - 3KB - /.ashx
[14:59:34] 500 - 3KB - /.asmx
[14:59:34] 500 - 3KB - /.aspx
[14:59:34] 500 - 3KB - /.axd
[14:59:37] 301 - 152B - /ADMIN -> http://10.211.55.17:81/ADMIN/
[14:59:37] 301 - 152B - /Admin -> http://10.211.55.17:81/Admin/
[14:59:38] 500 - 3KB - /Trace.axd
[14:59:39] 500 - 3KB - /WebResource.axd?d=LER8t9aS
[14:59:39] 403 - 32B - /\..\..\..\..\..\..\..\..\..\etc\passwd
[14:59:40] 301 - 152B - /admin -> http://10.211.55.17:81/admin/
[14:59:40] 200 - 3KB - /admin/
[14:59:40] 200 - 3KB - /admin/?/login
[14:59:46] 301 - 153B - /editor -> http://10.211.55.17:81/editor/
[14:59:46] 200 - 1KB - /editor/
[14:59:46] 500 - 3KB - /elmah.axd
[14:59:48] 301 - 153B - /images -> http://10.211.55.17:81/images/
[14:59:48] 200 - 3KB - /images/
[14:59:48] 301 - 150B - /inc -> http://10.211.55.17:81/inc/
[14:59:48] 200 - 806B - /inc/
[14:59:48] 200 - 739B - /js/
[14:59:53] 500 - 3KB - /service.asmx
[14:59:54] 301 - 152B - /style -> http://10.211.55.17:81/style/
[14:59:55] 500 - 3KB - /umbraco/webservices/codeEditorSave.asmx
[14:59:56] 500 - 3KB - /web.config
Task Completed
There should be some background information here.
3.1.2 Plug-in collection
Information collected through the Wappalyzer plug-in can be found:
The system should be running on Windows Server, and the language running the website is asp, and the web server is IIS.
3.2 Injection vulnerability testing
Normal page:
http://10.211.55.17:81/news_detail.asp?id=109
The page after adding single quotes:
http://10.211.55.17:81/news_detail.asp?id=109'
Therefore, possible SQL injection is suspected here.
3.3 Weak password vulnerability
There is currently the following information in the background:
-
The background display is XYCMS enterprise website building system, which is a commercial CMS
-
There may be a weak password in the background, and it seems that it cannot be cracked by brute force because there is a verification code.
For the above information, try weak passwords first.
Using admin admin in the background for testing found that you can directly enter the background, so there is a weak password vulnerability.
And a bak file was found here, which should be a backup file. Click to download and try it out:
So the current file here doesn't make much sense.
3.4 Verification code vulnerability
Also in the background interface, when we use Burpsuite for brute force cracking, although there is a verification code, after testing, the verification code here can be reused multiple times, so there is a verification code reuse vulnerability.
3.5 xss vulnerability
When browsing the website, I saw that you can fill in reservation information here. Based on experience, I know that this type of cms should have xss vulnerabilities, and will be tested in the future.
04. Vulnerability verification
4.1 Injection vulnerability
In 3.2, it has been discovered that there may be a SQL injection vulnerability here, so sqlmap is used here for testing.
sqlmap -u http://10.211.55.17:81/news_detail.asp?id=109
At this time, it was discovered that there is a Boolean blind injection, and the database is accessed. For this type of database, you can use the Pangolin (Pangolin) injection tool for quick injection.
At this point it is also quickly discovered that there is an injection.
Directly obtain database account and password information:
Get the md5 value of the account and password at this time:
admin|21232f297a57a5a743894a0e4a801fc3|
Try to decrypt the md5 at this time:
Password is admin
4.2 xss touch typing
Blind typing means not knowing where XSS vulnerabilities may exist, and testing in multiple places where js statements can be inserted.
In 3.5, it was proved that the cms may have xss vulnerability, so it can be tested here.
First, set an xss payload on the self-built xss platform:
Copy the current payload and insert it into the message board just now. Modify the front-end code and insert the xss code directly:
At this time, it shows that the xss statement has been inserted successfully.
Log in based on the address and password you just knew in the backend, click on Online Appointment Management, you can see that all the messages here are invisible, you can open any one to take a look.
After opening it, no valid information can be seen:
At this time, go to the xss platform to view:
At this point you can see that the background address and cookie information have been obtained.
Visit here through another new browser
http://10.211.55.17:81/index.asp,
And use Cookie Editor to replace the cookie just now.
visit again
http://10.211.55.17:81/admin/xycms.asp
At this point, you successfully entered the background.
This proves that the website has a stored XSS vulnerability.
4.3 Background getshell
After entering the background, try to get a shell.
In the background, we found that this cms is XYCMS. We collected vulnerabilities about this cms on the Internet:
I found an article on the Internet about the method of gettingshell in the xycms background:
Then try it in the background:
Insert this sentence in the website name (actually, you can choose any of the website name, website description, and website keywords here), and then save the system settings.
Visit: http://10.211.55.17:81/inc/config.asp
Use the webshell management tool to connect, here use Ant Sword:
After adding it as shown below, double-click to open:
Webshell connection successful: