Without knowing it, the LM gang saw that the black anti-DDOS service had already been in the spring and autumn, and the period had not fallen. After so long of hard work, you can start playing with one or two tricks. After reading the article "Dreamweaver causes network crisis" in the second phase of anti-DDoS pro, the LM gang was excited and thought that 40% of the web pages on the Internet had such vulnerabilities, isn't it possible to reap n more bots. But after careful research, we found that Article The method has some problems and is not as easy to use as you think. Next we will discuss the session with you.
Since we talk about session spoofing, Let's first look at what the session is and how it works. In ASP, the server can distinguish different browsers by session objects, because session objects are used to record browser variables and store sensitive or useful information such as user names. This seems like cookie. However, we know that cookie values are stored on the client, while session values are stored on the server. When each visitor accesses an ASP Webpage on the server through a browser for the first time, the server creates a new and independent Session object for the visitor and assigns the session a session ID number, and send a cookie (session ID) containing the special encrypted version of the session identifier to the customer. Because the expires value is not provided in the cookie (session ID), when the browser is closed, the session ID disappears.
Whenever a user accesses this ASP Website, ASP searches for the session ID in the browser. The name is aspsessionidxxxxxxxx. Each X is a letter. We can see the following when capturing and receiving packets:
Set-COOKIE: aspsessionidsqbbqqds = gcinnkpdigdnpeaogldfffem; Path =/
However, this cookie (session ID) does not appear in the request. Cookies or respsones. Cookies set. Although ASP hides it, it is stored in the browser. For each ASP Webpage request, Asp must view this value. Indicates the user's session. Therefore, the corresponding session object (the object is already in the memory and always contains all the values that exceed the requested value in the previous page) can be handed over to the script on the ASP Web page. That is to say, the browser has a session ID assigned by the server. When we have a request, the server can use this ID to find the value of the corresponding session object, thus, different browsers are differentiated.
Exploitation
I don't know if you have a certain understanding of the session from the previous principles. Now let's take a look at how Dreamweaver triggers a network crisis to use session sessions.
A website named abc.com has a logon page: login. ASP. After Successful Logon, you can view the sensitive information. ASP (with access restrictions, it will be displayed if the verification passes); otherwise, it will be switched to fail. ASP.
In this article, the author wants to construct an hack first. ASP Web page, through browsing this web page, establish a session, set the value required for session verification, and then directly enter the OK page after logon in the address bar. ASP, because OK. ASP is verified through session, so the author thinks this can be successful. However, through the previous analysis, we know that such attacks cannot be implemented if OK. asp and hack. asp are not on the same server. Because the value of the session object is kept on the server end, it is impossible to let ASP execute and leave the session value in IE, as the author said, all Internet Explorer has is the session ID of a session. If we browse hack on the local machine or other servers. ASP, set the verification value in hack. on the server where ASP is located, but on OK. the server where ASP is located does not set the corresponding verification value, even the session is not established. How can this problem be verified? It can be seen that if OK. asp and hack. asp are not on the same server, it will not cause a network crisis.
However, we can use this session spoofing method to leave a difficult backdoor for ourselves after intrusion! The following uses mypower 3.5 as an example to demonstrate how to directly log on to the background through session spoofing.
Let's take a look at the power Source code In admin_chkpurview.asp:
Adminname = Replace (Session ("adminname "),"'","")
If adminname = "" then
Call closeconn ()
Response. Redirect "admin_login.asp"
End if
Sqlgetadmin = "select * from Admin where username = '" & adminname &"'"
It can be seen that the power is verified by the adminname variable in the session object and used as the user name to query the database. The initial value of adminname is in admin_chklogin.asp, when the user successfully logs on, two session values will be given to you:
Session. Timeout = sessiontimeout
Session ("adminname") = RS ("username ")
Since session objects are used for detection after logon, the following statements (such as copyright. asp) can be constructed on any ASP Webpage that can be accessed ):
<% SESSION ("adminname") = "admin" %>
In this way, you can pass the session verification of admin_chkpurview.asp. Here, admin refers to an existing management user name. After this structure, even if any Trojan on the bot is scanned and killed, as long as the administrator's user name is not changed, we can access copyright first. ASP, and then directly enter admin_index.asp to log on to the background!
How can we prevent this situation? In fact, the power also uses a certain method. You will find that inputting other background pages in this method cannot be successful, because the following verification is available in admin_chkpurview.asp:
Comeurl = lcase (TRIM (request. servervariables ("http_referer ")))
If comeurl = "" then
Response. Write "<br> <p align = center> <font color = 'red'> sorry, for system security, you are not allowed to directly enter an address to access the background management page of the system. </Font> </P>"
Response. End
Else
Curl = trim ("http: //" & request. servervariables ("SERVER_NAME "))
If mid (comeurl, Len (curl) + 1,1) = ":" Then
Curl = curl & ":" & request. servervariables ("server_port ")
End if
Curl = lcase (curl & request. servervariables ("script_name "))
If lcase (left (comeurl, condition Rev (comeurl, "/") <> lcase (left (curl, condition Rev (curl, "/") then
Response. write "<br> <p align = center> <font color = 'red'> sorry, for system security, you are not allowed to access the background management page of the system from an external link address. </Font> </P>"
Response. End
End if
End if
However, the admin_chkpurview.asp page does not call admin_chkpurview.asp, so we can pass the verification! So why not call it? Don't ask me any more. Just give me a try.
Postscript
We know that we can end the session by closing the browser, but all we lose is the session ID assigned to us by the server. Before the session lifecycle ends, the server does not clear the session value corresponding to the session ID from the memory.
TIPS: Generally, the session lifecycle of IIS is 20 minutes by default.
With this principle, if we obtain the session ID number created when logging on to the server from another browser through a certain path. Then we can use this session ID to obtain the same permissions on the compromised browser. If an Administrator logs on to the background, we can log on to the background using the session ID number on another computer through session spoofing, thus achieving remote attacks. For details, visit the anti-DDoS forum.
If any omission exists in this article, let us know which one of them is welcome to share their best practices.
