Before we knew it, the "LM gang" had been watching the black defense for two years and the period was not over. After practicing for so long, I can start to play one or two moves. After reading the article "DreamWeaver triggers a cyber crisis" in the second episode of Black Defense, the "LM gang" felt indescribable excitement, thinking that 40% of the web pages on the Internet have such loopholes, wouldn't it be possible to harvest N many broilers again? However, after careful study, I found that there are some problems with the method of this article and it is not as easy to use as I imagined. Let’s discuss Session with you below.
Since it is talking about Session deception, let’s first take a look at what Session is and how it works. In ASP, the server can distinguish different browsers through the Session object, because the Session object is used to record variables on the browser side and store some sensitive or useful information such as usernames. This seems to be a bit similar to cookies. But we know that the value of the cookie is stored on the client side, while the value of the Session is stored on the server side. When each visitor first visits an ASP web page of the server, the server will create a new and independent Session object for him, assign a session identification number to the session, and send a cookie (session identification number) of a special encrypted version containing the session identifier to the client. Since the Expires value is not provided in the cookie (session identification number), the session identification number disappears when the browser is closed.
Whenever a user visits this ASP website, the ASP will look up the session identification number through the browser. Named ASPSESSIONIDxxxxxxxxx, where each x is an alphabetical character. We can see when we capture and receive packets:
Set-Cookie: ASPSESSIONIDSQBBQQDS=GCINNKPDIGDNPEAOGLDFFFEM; path=/
However, this cookie (session identification number) will not appear in or in the collection. Although ASP hides it, it is still saved on the browser. For each ASP web page request, the ASP must view the value. The value contained in this cookie (session identification number) indicates the user's session. Therefore, the content of the corresponding Session object (which is already in memory and always contains all the values that were super-operated during the previous page request process) can be handed over to the script in the ASP web page. In other words, the browser has a session ID number assigned by the server. When we have a request, the server can use this ID number to find the value of the corresponding Session object, which can distinguish different browsers.
Utilize
I have a bad writing style, and I wonder if you have a certain understanding of Session from the previous principles. Now let's take a look at how the article "DreamWeaver triggers cyber crisis" uses session sessions.
There is already a website with a login page below: After successfully logging in, you can see sensitive information (with access restrictions, if verification is passed), otherwise you will turn.
In this article, the author wants to construct a web page first, browse the web page, establish a session session, and set the value required for Session verification, and then directly enter the web page after logging in in the address bar. Since it is verified through Session, the author believes that this can be successful. However, through the previous analysis, we know that if it is not on the same server, this kind of attack cannot be achieved. Because the values of the Session object are retained on the server side, it is impossible to let the ASP execute and leave the Session value in IE, what IE has is just a Session session identification number. If we browse on the local machine or other server, the verification value we set is on the server we are located, but the corresponding verification value is not set on the server we are located, and even the Session session has not been established, how can we pass the verification? It can be seen that if it is not on the same server, it will not cause a network crisis.
But we can use this Session deception method to leave ourselves a back door that is not easy to detect and kill after invasion! Let’s take MyPower Power 3.5 as an example to demonstrate how to directly log in to the background through Session spoofing.
Let’s first look at the source code of power, and verify Session in Admin_ChkPurview.asp:
AdminName=replace(session("AdminName"),"'","")
if AdminName="" then
call CloseConn()
"Admin_login.asp"
end if
sqlGetAdmin="select * from Admin where UserName='" & AdminName & "'"
It can be seen that the motivation is authenticated by the AdminName variable in the Session object and used it as the user name to query the database. The initial assignment of AdminName is in Admin_ChkLogin.asp. When the user successfully logs in, you will be given two Session values:
=SessionTimeout
session("AdminName")=rs("username")
Since login is detected through Session objects after logging in, we can construct the following statements (such as):
<%session("AdminName")="admin"%>
This allows you to verify the Session of Admin_ChkPurview.asp. Among them, Admin refers to the existing administrative user name. After this construction, even if any *s on the broiler are checked and killed, as long as the administrator's username has not been changed, we can access it first, and then directly enter Admin_Index.asp to log in to the background directly!
So how to prevent this situation? In fact, the motivation has also used a certain method. You will find that entering other background pages according to this method cannot succeed. This is because there are also verifications in Admin_ChkPurview.asp:
ComeUrl=lcase(trim(("HTTP_REFERER")))
if ComeUrl="" then
"<br><p align=center><font color='red'>Sorry, for system security, it is not allowed to directly enter the address to access the backend management page of this system.</font></p>"
else
cUrl=trim("http://" & ("SERVER_NAME"))
if mid(ComeUrl,len(cUrl)+1,1)=":" then
cUrl=cUrl & ":" & ("SERVER_PORT")
end if
cUrl=lcase(cUrl & ("SCRIPT_NAME"))
if lcase(left(ComeUrl,instrrev(ComeUrl,"/")))<>lcase(left(cUrl,instrrev(cUrl,"/"))) then
"<br><p align=center><font color='red'>Sorry, for system security, access to the backend management page of this system is not allowed from external link addresses.</font></p>"
end if
end if
However, Admin_ChkPurview.asp is not called in the Admin_Index.asp page, so we can pass the verification! Then why not call it? Don't ask me, just try it yourself.
Postscript
We know that closing the browser can end the session, but what we lose is the session identification number assigned to us by the server. Before the life cycle of the Session session ends, the server will not clear the Session value corresponding to the session identification number from memory.
Tips: The life cycle of IIS Session is 20 minutes by default.
Using this principle, if we obtain the Session session identification number established when other browsers log in to the server through a certain passage. Then we can use this session identification number to get the same permissions on the robbed browser. If an administrator is logged in to the background, then we can also log in to the background by using this session identification number on another computer through Session spoofing, thus realizing attacks in a remote location. Welcome to the Black Defense Forum for discussion for specific methods.
If there are any omissions in the article, please point out which brother is welcome to share if there is a better way to use it.
Since it is talking about Session deception, let’s first take a look at what Session is and how it works. In ASP, the server can distinguish different browsers through the Session object, because the Session object is used to record variables on the browser side and store some sensitive or useful information such as usernames. This seems to be a bit similar to cookies. But we know that the value of the cookie is stored on the client side, while the value of the Session is stored on the server side. When each visitor first visits an ASP web page of the server, the server will create a new and independent Session object for him, assign a session identification number to the session, and send a cookie (session identification number) of a special encrypted version containing the session identifier to the client. Since the Expires value is not provided in the cookie (session identification number), the session identification number disappears when the browser is closed.
Whenever a user visits this ASP website, the ASP will look up the session identification number through the browser. Named ASPSESSIONIDxxxxxxxxx, where each x is an alphabetical character. We can see when we capture and receive packets:
Set-Cookie: ASPSESSIONIDSQBBQQDS=GCINNKPDIGDNPEAOGLDFFFEM; path=/
However, this cookie (session identification number) will not appear in or in the collection. Although ASP hides it, it is still saved on the browser. For each ASP web page request, the ASP must view the value. The value contained in this cookie (session identification number) indicates the user's session. Therefore, the content of the corresponding Session object (which is already in memory and always contains all the values that were super-operated during the previous page request process) can be handed over to the script in the ASP web page. In other words, the browser has a session ID number assigned by the server. When we have a request, the server can use this ID number to find the value of the corresponding Session object, which can distinguish different browsers.
Utilize
I have a bad writing style, and I wonder if you have a certain understanding of Session from the previous principles. Now let's take a look at how the article "DreamWeaver triggers cyber crisis" uses session sessions.
There is already a website with a login page below: After successfully logging in, you can see sensitive information (with access restrictions, if verification is passed), otherwise you will turn.
In this article, the author wants to construct a web page first, browse the web page, establish a session session, and set the value required for Session verification, and then directly enter the web page after logging in in the address bar. Since it is verified through Session, the author believes that this can be successful. However, through the previous analysis, we know that if it is not on the same server, this kind of attack cannot be achieved. Because the values of the Session object are retained on the server side, it is impossible to let the ASP execute and leave the Session value in IE, what IE has is just a Session session identification number. If we browse on the local machine or other server, the verification value we set is on the server we are located, but the corresponding verification value is not set on the server we are located, and even the Session session has not been established, how can we pass the verification? It can be seen that if it is not on the same server, it will not cause a network crisis.
But we can use this Session deception method to leave ourselves a back door that is not easy to detect and kill after invasion! Let’s take MyPower Power 3.5 as an example to demonstrate how to directly log in to the background through Session spoofing.
Let’s first look at the source code of power, and verify Session in Admin_ChkPurview.asp:
AdminName=replace(session("AdminName"),"'","")
if AdminName="" then
call CloseConn()
"Admin_login.asp"
end if
sqlGetAdmin="select * from Admin where UserName='" & AdminName & "'"
It can be seen that the motivation is authenticated by the AdminName variable in the Session object and used it as the user name to query the database. The initial assignment of AdminName is in Admin_ChkLogin.asp. When the user successfully logs in, you will be given two Session values:
=SessionTimeout
session("AdminName")=rs("username")
Since login is detected through Session objects after logging in, we can construct the following statements (such as):
<%session("AdminName")="admin"%>
This allows you to verify the Session of Admin_ChkPurview.asp. Among them, Admin refers to the existing administrative user name. After this construction, even if any *s on the broiler are checked and killed, as long as the administrator's username has not been changed, we can access it first, and then directly enter Admin_Index.asp to log in to the background directly!
So how to prevent this situation? In fact, the motivation has also used a certain method. You will find that entering other background pages according to this method cannot succeed. This is because there are also verifications in Admin_ChkPurview.asp:
ComeUrl=lcase(trim(("HTTP_REFERER")))
if ComeUrl="" then
"<br><p align=center><font color='red'>Sorry, for system security, it is not allowed to directly enter the address to access the backend management page of this system.</font></p>"
else
cUrl=trim("http://" & ("SERVER_NAME"))
if mid(ComeUrl,len(cUrl)+1,1)=":" then
cUrl=cUrl & ":" & ("SERVER_PORT")
end if
cUrl=lcase(cUrl & ("SCRIPT_NAME"))
if lcase(left(ComeUrl,instrrev(ComeUrl,"/")))<>lcase(left(cUrl,instrrev(cUrl,"/"))) then
"<br><p align=center><font color='red'>Sorry, for system security, access to the backend management page of this system is not allowed from external link addresses.</font></p>"
end if
end if
However, Admin_ChkPurview.asp is not called in the Admin_Index.asp page, so we can pass the verification! Then why not call it? Don't ask me, just try it yourself.
Postscript
We know that closing the browser can end the session, but what we lose is the session identification number assigned to us by the server. Before the life cycle of the Session session ends, the server will not clear the Session value corresponding to the session identification number from memory.
Tips: The life cycle of IIS Session is 20 minutes by default.
Using this principle, if we obtain the Session session identification number established when other browsers log in to the server through a certain passage. Then we can use this session identification number to get the same permissions on the robbed browser. If an administrator is logged in to the background, then we can also log in to the background by using this session identification number on another computer through Session spoofing, thus realizing attacks in a remote location. Welcome to the Black Defense Forum for discussion for specific methods.
If there are any omissions in the article, please point out which brother is welcome to share if there is a better way to use it.