Attacks on web applications through the session management system. Another vulnerable point is web applications. Of course, the development of corporate web portals is usually entrusted to professional web programmers, but a system administrator and especially an information security specialist should be aware of existing vulnerabilities in web applications. In addition, in small companies, the sysadmin often develops and maintains a corporate portal. So the following information will be useful to many. Modern web portals primarily use Apache as a web server. There is, of course, IIS (Internet Information Services) running on Windows, but most hosting services still use a combination of FreeBSD/Linux+Apache. MySQL or PostgreeSQL is usually used to store the data that the web portal works with. Oracle can be used in high-load industrial systems. PHP or Perl is usually used as a scripting language. There are also high-level tools for developing portal solutions from Microsoft, but in this section we will not touch on them due to their lower prevalence compared to free FreeBSD, Apache, MySQL, PHP. As a practical example, consider attacks on a PHP application through a session management system. The main reasons for the possibility of these attacks are the lack of verification of the user's session ID and the lack of verification of the data stored in the session. Let's look at possible attacks on the application. Session Hijacking. The essence of the attack is that an attacker uses a session identifier belonging to a legitimate user to impersonate the session owner. You can find out the ID of someone else's session by intercepting the traffic of a legitimate user, organizing an XSS attack, or by brute force. The general algorithm of the attack is as follows: 1) the attacker collects information about the victim's IP addresses and the resource to be accessed.; 2) then you need to wait for the attacker to connect to the target resource.; 3) next, the attacker needs to launch ARP relay; 4) when the victim has connected to the target resource and started working with it, the attacker will see a new active connection in the sniffer. Next, the hacker performs a TCP/IP desynchronization attack, which was already described earlier. The victim's connection "falls off" by forcibly sending an RST packet; 5) further, the attacker can work on behalf of the victim and with her account rights; 6) the attacker is forced to reconnect to the target resource, rightly believing that a hardware connection failure has occurred. The attacker sends him an RST; 7) when the hacker finishes working with the system, he stops sending RST and disables ARP-relay; 8) The hacked user can work with the system again. As it is easy to understand from the description, in order to implement such an attack, it is necessary to be connected to the same switch as the attacked one. In other words, they are actually on the same local network as the victim. In a simpler case, an attacker may try to hack someone else's session by spoofing cookies. Here is a small example of such an attack in practice. To implement it, you need a sniffer, such as Wireshark, a browser (such as Firefox), and a Cookie editor (you can use add-on to Firefox). The attacked user connects to the social network portal. The hacker sniffs the traffic. After the traffic interception is completed, the attacker needs to find the cookies transmitted by the user. You can do this in Wireshark as follows. Press Ctrl+F or Edit - Find Packet. In the By: field, select String and Search In, the Packet details option, and specify the Set Cookie in the text field. When the desired packet is found, right-click and select "Follow TCP Stream". Further in this stream, you can find a package similar to the one shown. This is the necessary cookie. Next, you need to open the Cookie Editor (Tools - Cookie Editor). Then click Add and specify the following: Name: _twitter_sess Content: copy paste the information from the TCP Stream (see the red box in the Session Cookie Found from TCP Stream picture) Domain: . twitter.com Path: / In case of successful implementation, the attacker now does not need to provide credentials to log in to the site, just go to the page. The following actions are briefly performed: 1) traffic interception; 2) detecting a package containing a Set Cookie; 3) setting Cookies in the Cookie Editor add-on; 4) accessing the desired site. Session Fixation. To carry out this attack, the attacker does not need the identifier of someone else's session, it is enough to set the identifier of his session to a legitimate user who has passed authorization. As in the previous case, a situation is created when an attacker and a legitimate user have the same session identifier. Session Fixation is a method of attack that forcibly sets the session identifier to a specific value. Depending on the functionality of the attacked site, many different methods can be used to "fix" the session ID. Then the user session ID is fixed, and the attacker waits for those who will log in. As soon as the user does this, the attacker uses the predefined value of the session ID to obtain his online identification with all the ensuing consequences. There are two types of session management systems: "free" and "strict". The session type is determined depending on how the identifier values are generated. The first type of system allows web browsers to specify any identifier. The second type of system accepts only values generated on the server. In free systems, an arbitrary session identifier is processed without accessing the website at all. Strict systems require an attacker to maintain a "trap session" with periodic access to the website to prevent inactivity timeouts. Without active protection against session fixation, an attack can be launched against any website that uses sessions to authenticate users. Websites that use session identifiers usually use cookies, and URLs and hidden form fields are also used. Unfortunately, Cookie-based sessions are easier to attack. Unlike stealing user session IDs performed after they log on to a website, session fixation provides significantly greater opportunities for attack. The active part of the attack is done before users log in to the system. Let's look at an example of classic user session fixation. There are three stages of fixation: 1) Installation; 2) fixing; 3) entry. At the first stage, the attacker installs a "trap session" on the attacked site and obtains this session identifier. Or an attacker can choose a random session ID to attack. But in this case, the value set by the trap session must be maintained (in order to "be alive") with repeated connections to the website. Then, in the next step, the attacker places the value of the trap session in the user's browser and captures the user session ID. And at the third stage, the attacker waits until the user logs into the system of the attacked site. As soon as the user does this, the value of the fixed session identifier will be used, and an attacker can start working with the hacked system. To fix the user session ID, one of the following methods can be performed: issuing cookies using a client script; issuing a new session ID value in a cookie using a client script. Cross-site programming in weak points of the website protection system can be used to change the current cookie value. http://example /<script>document.cookie="sessionid=1234;%20domain=.example.com";</script>.idc Here is an example of issuing a cookie using a META tag. This method is effective, especially when the cross-site programming blocker prevents the injection of HTML script tags, but not META tags. http://example /<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.com">.idc Issuing cookies using the HTTP response header. An attacker causes either a cookie with a session ID to be issued on the target website or on any of its subdomains. This can be done in different ways: hacking a web server in a domain (for example, a poorly maintained server); infection of a user's DNS server, practically with the addition of an attacker's web server to the attacked domain (this type of attack has already been described in the DNS posts); installing a malicious web server in the attacked domain (for example, on a workstation in the Windows2000 domain, all workstations are also located in the DNS domain); using an HTTP response splitting attack. It is also worth noting here that a long-term session fixation attack can be performed by issuing permanent cookies (for example, with a lifetime of 10 years), which will keep the session fixed even after the user restarts the computer. Here is an example: http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc Session Poisoning. The threat of a poisoned session occurs if an attacker has the opportunity to install his PHP script on the server where the attacked application is running. The essence of the attack lies in the fact that if PHP applications are running on the same server, then there is a high probability that, knowing the session ID, the attacker will be able to work with session data created in the attacked application. Poisoning is possible if the attacked application has an error that allows executing arbitrary code, and if the web application runs on the server along with applications from other hosting users. The purpose of this attack is to gain access to read/write session values. If successful, an attacker will be able to read and/or falsify any value stored in the session. Poisoning is used to obtain the personal data of other users, as well as to modify one's own session, impersonate another and/or increase privileges. Here is the simplest example of this attack: $var = $_GET["something"]; $_SESSION["$var"] = $var2; Authentication using forms. When a client visits the page and enters a username and password, his credentials are transmitted to the server. If authentication is successful, the server generates a session ticket for this user, and for all subsequent requests to the server, this ticket is already used, the data of which is stored in a cookie. By default, the ticket's lifetime is 30 minutes. At the end of this time, the ticket can be automatically renewed. If there were no more requests within a certain time interval, the server sends a message to the client with a suggestion to "forget" this ticket, as a result of which the browser deletes this cookie, and the user must re-enter the credentials to log in. It would seem that everything is quite logical and correct. But the client (or rather, the attacker) can periodically ask the server to renew its ticket, in fact, an unlimited number of times. In other words, the server has no control over how many times the ticket has been renewed. And an attacker can simply ignore the offer received from the server to "forget" his ticket and continue to renew it further. Thus, if an attacker was able to steal the ticket cookie, he will be able to use the user session. Cross Site Request Forgery. The good old CSRF is also relevant for .NET. Recall that CSRF is a type of attack on website visitors that exploits the shortcomings of the HTTP protocol. If a victim visits a website created by an attacker, a request is secretly sent on her behalf to another server (for example, to a payment system server) that performs some kind of malicious operation (for example, transferring money to the attacker's account). To carry out this attack, several conditions must be met. First, the victim must be authenticated on the server where the request is being made. Also, this request should not require any user confirmation, which cannot be automated, that is, which cannot be forged by an attacking script. As an example, consider a situation where a user logs in using authentication based on the very forms we discussed earlier. The server performs user authentication and issues a response that includes the user's ticket in a cookie. At the same time, the bank's website trusts any request it receives with a valid ticket in the cookie. Next, the user visits another site without forcibly ending the session on the bank's website, www.hacker.com , which contains an HTML form in which the following data is hidden in the form: <form action=" https://bank.com/api/account" method="post"> <input type="hidden" name="Transaction" value="withdraw" /> <input type="hidden" name="Amount" value="1000000" /> <input type="submit" value="Click to collect your prize!" /> </form> Please note that the form will send the data to the bank's website. This is the "cross-site" part of CSRF. Then, under some pretext, the user is asked to click a button that will secretly send the form data. When submitting the form, the browser will automatically send a cookie ticket for the requested domain, because the user is still formally logged in to the bank's website. As a result, the request will be executed on the bank's website. It is worth noting that using HTTPS does not prevent CSRF attacks. A malicious site can send a request just as easily as an insecure request. Such attacks are made possible by the fact that cookies issued by the application are stored in the browser, these cookies contain, among other things, the session tickets of verified users, and finally the browser sends all domain-related cookies to the web application, regardless of how the request to the application was created in the browser. Oleg Petukhov, lawyer in the field of international law and personal data protection, information security specialist security, protection of information and personal data. Telegram channel: https://t.me/protectioninformation Telegram Group: https://t.me/informationprotection1 Website: https://legascom.ru Email: online@legascom.ru #informationprotection #informationsecurity
Компания ЛЕГАС: адвокат, юрист, жалобы в ЕСПЧ
Attacks on the web through session management.
Attacks on web applications through the session management system.
Another vulnerable point is web applications. Of course, the development of corporate web portals is usually entrusted to professional web programmers, but a system administrator and especially an information security specialist should be aware of existing vulnerabilities in web applications. In addition, in small companies, the sysadmin often develops and maintains a corporate portal. So the following information will be useful to many.
Modern web portals primarily use Apache as a web server. There is, of course, IIS (Internet Information Services) running on Windows, but most hosting services still use a combination of FreeBSD/Linux+Apache. MySQL or PostgreeSQL is usually used to store the data that the web portal works with. Oracle can be used in high-load industrial systems.
PHP or Perl is usually used as a scripting language. There are also high-level tools for developing portal solutions from Microsoft, but in this section we will not touch on them due to their lower prevalence compared to free FreeBSD, Apache, MySQL, PHP.
As a practical example, consider attacks on a PHP application through a session management system. The main reasons for the possibility of these attacks are the lack of verification of the user's session ID and the lack of verification of the data stored in the session.
Let's look at possible attacks on the application.
Session Hijacking.
The essence of the attack is that an attacker uses a session identifier belonging to a legitimate user to impersonate the session owner. You can find out the ID of someone else's session by intercepting the traffic of a legitimate user, organizing an XSS attack, or by brute force.
The general algorithm of the attack is as follows:
1) the attacker collects information about the victim's IP addresses and the resource to be accessed.;
2) then you need to wait for the attacker to connect to the target resource.;
3) next, the attacker needs to launch ARP relay;
4) when the victim has connected to the target resource and started working with it, the attacker will see a new active connection in the sniffer. Next, the hacker performs a TCP/IP desynchronization attack, which was already described earlier. The victim's connection "falls off" by forcibly sending an RST packet;
5) further, the attacker can work on behalf of the victim and with her account rights;
6) the attacker is forced to reconnect to the target resource, rightly believing that a hardware connection failure has occurred. The attacker sends him an RST;
7) when the hacker finishes working with the system, he stops sending RST and disables ARP-relay;
8) The hacked user can work with the system again.
As it is easy to understand from the description, in order to implement such an attack, it is necessary to be connected to the same switch as the attacked one. In other words, they are actually on the same local network as the victim.
In a simpler case, an attacker may try to hack someone else's session by spoofing cookies.
Here is a small example of such an attack in practice.
To implement it, you need a sniffer, such as Wireshark, a browser (such as Firefox), and a Cookie editor (you can use add-on to Firefox).
The attacked user connects to the social network portal.
The hacker sniffs the traffic. After the traffic interception is completed, the attacker needs to find the cookies transmitted by the user. You can do this in Wireshark as follows. Press Ctrl+F or Edit - Find Packet. In the By: field, select String and Search In, the Packet details option, and specify the Set Cookie in the text field.
When the desired packet is found, right-click and select "Follow TCP Stream". Further in this stream, you can find a package similar to the one shown.
This is the necessary cookie. Next, you need to open the Cookie Editor (Tools - Cookie Editor). Then click Add and specify the following:
Name: _twitter_sess
Content: copy paste the information from the TCP Stream (see the red box in the Session Cookie Found from TCP Stream picture)
Domain: . twitter.com Path: /
In case of successful implementation, the attacker now does not need to provide credentials to log in to the site, just go to the page.
The following actions are briefly performed:
1) traffic interception;
2) detecting a package containing a Set Cookie;
3) setting Cookies in the Cookie Editor add-on;
4) accessing the desired site.
Session Fixation.
To carry out this attack, the attacker does not need the identifier of someone else's session, it is enough to set the identifier of his session to a legitimate user who has passed authorization. As in the previous case, a situation is created when an attacker and a legitimate user have the same session identifier.
Session Fixation is a method of attack that forcibly sets the session identifier to a specific value. Depending on the functionality of the attacked site, many different methods can be used to "fix" the session ID. Then the user session ID is fixed, and the attacker waits for those who will log in. As soon as the user does this, the attacker uses the predefined value of the session ID to obtain his online identification with all the ensuing consequences.
There are two types of session management systems: "free" and "strict". The session type is determined depending on how the identifier values are generated. The first type of system allows web browsers to specify any identifier. The second type of system accepts only values generated on the server. In free systems, an arbitrary session identifier is processed without accessing the website at all. Strict systems require an attacker to maintain a "trap session" with periodic access to the website to prevent inactivity timeouts.
Without active protection against session fixation, an attack can be launched against any website that uses sessions to authenticate users. Websites that use session identifiers usually use cookies, and URLs and hidden form fields are also used. Unfortunately, Cookie-based sessions are easier to attack.
Unlike stealing user session IDs performed after they log on to a website, session fixation provides significantly greater opportunities for attack. The active part of the attack is done before users log in to the system.
Let's look at an example of classic user session fixation.
There are three stages of fixation:
1) Installation;
2) fixing;
3) entry.
At the first stage, the attacker installs a "trap session" on the attacked site and obtains this session identifier. Or an attacker can choose a random session ID to attack. But in this case, the value set by the trap session must be maintained (in order to "be alive") with repeated connections to the website.
Then, in the next step, the attacker places the value of the trap session in the user's browser and captures the user session ID. And at the third stage, the attacker waits until the user logs into the system of the attacked site. As soon as the user does this, the value of the fixed session identifier will be used, and an attacker can start working with the hacked system.
To fix the user session ID, one of the following methods can be performed:
issuing cookies using a client script;
issuing a new session ID value in a cookie using a client script. Cross-site programming in weak points of the website protection system can be used to change the current cookie value.
http://example /<script>document.cookie="sessionid=1234;%20domain=.example.com";</script>.idc
Here is an example of issuing a cookie using a META tag. This method is effective, especially when the cross-site programming blocker prevents the injection of HTML script tags, but not META tags.
http://example /<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.com">.idc
Issuing cookies using the HTTP response header.
An attacker causes either a cookie with a session ID to be issued on the target website or on any of its subdomains. This can be done in different ways:
hacking a web server in a domain (for example, a poorly maintained server);
infection of a user's DNS server, practically with the addition of an attacker's web server to the attacked domain (this type of attack has already been described in the DNS posts);
installing a malicious web server in the attacked domain (for example, on a workstation in the Windows2000 domain, all workstations are also located in the DNS domain);
using an HTTP response splitting attack.
It is also worth noting here that a long-term session fixation attack can be performed by issuing permanent cookies (for example, with a lifetime of 10 years), which will keep the session fixed even after the user restarts the computer. Here is an example:
http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc
Session Poisoning.
The threat of a poisoned session occurs if an attacker has the opportunity to install his PHP script on the server where the attacked application is running. The essence of the attack lies in the fact that if PHP applications are running on the same server, then there is a high probability that, knowing the session ID, the attacker will be able to work with session data created in the attacked application. Poisoning is possible if the attacked application has an error that allows executing arbitrary code, and if the web application runs on the server along with applications from other hosting users.
The purpose of this attack is to gain access to read/write session values. If successful, an attacker will be able to read and/or falsify any value stored in the session. Poisoning is used to obtain the personal data of other users, as well as to modify one's own session, impersonate another and/or increase privileges.
Here is the simplest example of this attack:
$var = $_GET["something"];
$_SESSION["$var"] = $var2;
Authentication using forms.
When a client visits the page and enters a username and password, his credentials are transmitted to the server. If authentication is successful, the server generates a session ticket for this user, and for all subsequent requests to the server, this ticket is already used, the data of which is stored in a cookie. By default, the ticket's lifetime is 30 minutes. At the end of this time, the ticket can be automatically renewed. If there were no more requests within a certain time interval, the server sends a message to the client with a suggestion to "forget" this ticket, as a result of which the browser deletes this cookie, and the user must re-enter the credentials to log in.
It would seem that everything is quite logical and correct. But the client (or rather, the attacker) can periodically ask the server to renew its ticket, in fact, an unlimited number of times. In other words, the server has no control over how many times the ticket has been renewed. And an attacker can simply ignore the offer received from the server to "forget" his ticket and continue to renew it further.
Thus, if an attacker was able to steal the ticket cookie, he will be able to use the user session.
Cross Site Request Forgery.
The good old CSRF is also relevant for .NET. Recall that CSRF is a type of attack on website visitors that exploits the shortcomings of the HTTP protocol. If a victim visits a website created by an attacker, a request is secretly sent on her behalf to another server (for example, to a payment system server) that performs some kind of malicious operation (for example, transferring money to the attacker's account).
To carry out this attack, several conditions must be met. First, the victim must be authenticated on the server where the request is being made. Also, this request should not require any
user confirmation, which cannot be automated, that is, which cannot be forged by an attacking script.
As an example, consider a situation where a user logs in using authentication based on the very forms we discussed earlier. The server performs user authentication and issues a response that includes the user's ticket in a cookie. At the same time, the bank's website trusts any request it receives with a valid ticket in the cookie. Next, the user visits another site without forcibly ending the session on the bank's website, www.hacker.com , which contains an HTML form in which the following data is hidden in the form:
<form action=" https://bank.com/api/account" method="post">
<input type="hidden" name="Transaction" value="withdraw" />
<input type="hidden" name="Amount" value="1000000" />
<input type="submit" value="Click to collect your prize!" />
</form>
Please note that the form will send the data to the bank's website. This is the "cross-site" part of CSRF. Then, under some pretext, the user is asked to click a button that will secretly send the form data. When submitting the form, the browser will automatically send a cookie ticket for the requested domain, because the user is still formally logged in to the bank's website. As a result, the request will be executed on the bank's website. It is worth noting that using HTTPS does not prevent CSRF attacks. A malicious site can send a request just as easily as an insecure request.
Such attacks are made possible by the fact that cookies issued by the application are stored in the browser, these cookies contain, among other things, the session tickets of verified users, and finally the browser sends all domain-related cookies to the web application, regardless of how the request to the application was created in the browser.
Oleg Petukhov, lawyer in the field of international law and personal data protection, information security specialist security, protection of information and personal data.
Telegram channel: https://t.me/protectioninformation Telegram Group: https://t.me/informationprotection1 Website: https://legascom.ru Email: online@legascom.ru #informationprotection #informationsecurity