Broken Authentication and Session Management
===============================================
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords,keys,or session tokens, or to exploit other implementation flaws to assume other user's identities.
Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, time-outs, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique
Session IDs
=================
A Session is a unique identifier....
As we know that HTTP is a stateless protocol, which means that it provides no integrated way for a web server to maintain states throughout user’s subsequent requests.
A session identifier, session ID or session token is a piece of data that is used in network communications (often over HTTP) to identify a session, a series of related message exchanges. Session identifiers become necessary in cases where the communications infrastructure uses a stateless protocol such as HTTP.
For example, a buyer who visits a seller's site wants to collect a number of articles in a virtual shopping cart and then finalize the shopping by going to the site's checkout page. This typically involves an ongoing communication where several web pages are requested by the client and sent back to them by the server. In such a situation, it is vital to keep track of the current state of the shopper's cart, and a session ID is one way to achieve that goal.
A session ID is typically granted to a visitor on his first visit to a site. It is different from a user ID in that sessions are typically short-lived (they expire after a preset time of inactivity which may be minutes or hours) and may become invalid after a certain goal has been met (for example, once the buyer has finalized his order, he cannot use the same session ID to add more items).
Three widely used methods for maintaining sessions in WEB
=======================================================
1) URL arguments
2) Hidden form fields
3) Cookies (cookies have proven to be the most convenient)
************************************
Cross Site Scripting => Click on me :)
Basics for SQL Injection and Remediations => Click on me :)
Nmap with Metasploits => Click one me :)
*************************************************************
Session Management
=====================
Session management is the process of keeping track of a user's activity across sessions of interaction with the computer system.
Types
======
Desktop session management => A desktop session manager is a program that can save and restore desktop sessions. A desktop session is all the windows currently running and their current content.
Browser session management => Session management is particularly useful in a web browser where a user can save all open pages and settings and restore them at a later date. To help recover from a system or application crash, pages and settings can also be restored on next run.
Web Server Session management => Hypertext Transfer Protocol (HTTP) is stateless: a client computer running a web browser must establish a new Transmission Control Protocol (TCP) network connection to the web server with each new HTTP GET or POST request. The web server, therefore, cannot rely on an established TCP network connection for longer than a single HTTP GET or POST operation. Session management is the technique used by the web developer to make the stateless HTTP protocol support session state. For example, once a user has been authenticated to the web server, the user's next HTTP request (GET or POST) should not cause the web server to ask for the user's account and password again. For a discussion of the methods used to accomplish this see HTTP cookie and Session ID
Session management over SMS =>
Vulnerabilities
===========================
> User authentication credentials aren’t protected when stored using hashing or encryption.
> Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
> Session IDs are exposed in the URL (e.g., URL rewriting).
> Session IDs are vulnerable to session fixation attacks.
> Session IDs don’t time-out, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, aren’t properly invalidated during logout.
> Session IDs aren’t rotated after successful login.
> Passwords, session IDs, and other credentials are sent over unencrypted connections.
Attacks Done on Session IDs
=====================================
1) Session Hijacking => The attacker gains access to the user’s session by obtaining his session ID, is called session hijacking
2) Session fixation => The attacker fixes the user’s session ID before the user even logs into the target server, thereby eliminating the need to obtain the user’s session ID afterwards.
Attacks made in session fixation =>
*) Interception (Encrypted communication effectively protects against interception)
*) Prediction (Cryptographically strong pseudo random number generators and carefully chosen seeds that don’t leak from the serve prevents prediction of session IDs)
*) Brute-force (Bit-length is large enough with respect to the number of simultaneous sessions)
Session fixation vs. session hijacking
==========================================
Timing
Session fixation : Attacker attacks the user’s browser before he logs in to the target server.
Session hijacking : Attacker attacks the user’s browser after he logs in to the target server.
Impact Duration
Session fixation : Attacker gains one-time, temporary or long-term access to the user’s session(s).
Session hijacking : Attacker usually gains one-time access to the user’s session and has to repeat the attack in order to gain access to another one.
Session Maintenance
Session fixation : Can require the attacker to maintain the trap session until the user logs into it.
Session hijacking : Requires no session maintenance.
Attack Vectors
Session fixation
1. Tricking the user to log in through a malicious hyperlink or a malicious login form
2. Exploiting a cross-site scripting vulnerability on any web server in the target server’s domain
3. Exploiting a meta tag injection vulnerability on any web server in the target server’s domain
4. Exploiting the “session adoption” feature of some web servers
5. Breaking into any host in the target server’s domain
6. Adding a domain cookie-issuing server to the target server’s domain in the user’s DNS server
7. Network traffic modification
Session hijacking
1. Exploiting a cross-site scripting vulnerability on the target server
2. Obtaining the session ID in the HTTP Referer header sent to another web server
3. Network traffic sniffing (only works with an unencrypted link to the target server)
Attack Target Area
Session fixation : Communication link, target web server, all hosts in target server’s domain, user’s DNS server
Session hijacking : Communication link, target web server
Mitigation
===============
1) HTTPonly
2) Secure flag if HTTPS is there
3) Encrypted communication between the user’s browser and the target web server
4) Ensuring that sessions expire and within a reasonable period of time
Broken Authentication and Session Management Cases
=====================================================
Case 1:
Plain text storage of password
Storing a password in plaintext may result in a system compromise
Attacker can sniff the network with the help of any sniffing tool (such as wire-shark)
Case 2:
Improper Authentication
The user claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.
Case 3:
Missing Encryption of Sensitive Data
The software/website does not encrypt sensitive or critical information before storage or transmission
The lack of proper data encryption passes up the guarantees of confidentiality, integrity, and accountability that properly implemented encryption conveys.
For example : Storage for credit card no. or pin, user info or password
Case 4:
Clear text Transmission of Sensitive Information
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by an attacker.
Many communication channels can be "sniffed" by attackers during data transmission. For example, network traffic can often be sniffed by an attacker who has access to a network interface. This significantly lowers the difficulty of exploitation by attackers.
Case 5:
Session Fixation
Read above for session fixation
Case 6:
Insufficiently Protected Credentials
Login pages not using adequate measures to protect the username and password while they are in transit from the client to the server
Use SSL
Case 7:
Insufficient Session Expiration
"Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
The lack of proper session expiration may improve the likely success of certain attacks. For example, an attacker may intercept a session ID, possibly via a network sniffer or Cross-site Scripting attack. Although short session expiration times do not help if a stolen token is immediately used, they will protect against ongoing replaying of the session ID. In another scenario, a user might access a website from a shared computer (such as at a library, Internet cafe, or open work environment). Insufficient Session Expiration could allow an attacker to use the browser's back button to access web pages previously accessed by the victim.
> Set sessions/credentials expiration date
Case 8:
Unverified Password Change
When setting a new password for a user, the product does not require knowledge of the original password or using another form of authentication.
This could be used by an attacker to change passwords for another user, thus gaining the privileges associated with that user. (may lead to CSRF)
Case 9:
Weak Password Recovery Mechanism for Forgotten Password
The software contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Very often the password recovery mechanism is weak, which has the effect of making it more likely that it would be possible for a person other than the legitimate system user to gain access to that user's account.(May lead to Brute force attack)
This weakness may be that the security question is too easy to guess or find an answer to (e.g. because it is too common). Or there might be an implementation weakness in the password recovery mechanism code that may for instance trick the system into e-mailing the new password to an e-mail account other than that of the user. There might be no throttling done on the rate of password resets so that a legitimate user can be denied service by an attacker if an attacker tries to recover their password in a rapid succession. The system may send the original password to the user rather than generating a new temporary password. In summary, password recovery functionality, if not carefully designed and implemented can often become the system's weakest link that can be misused in a way that would allow an attacker to gain unauthorized access to the system. Weak password recovery schemes completely undermine a strong password
Exploitation With SessionId
================================
IMP : https://www.exploit-db.com/papers/15990/
=============
Exploit 1 : Session Fixation
A bank website, Session IDs are transported from browser to server within a URL argument sessionid.
The attacker – who in this case is also a legitimate user of the system – logs into the server and is issued a session ID 1234. The attacker then sends a hyperlink
http://online.worldbank.dom/login.jsp?sessionid=1234 to the victim, trying to lure him into clicking on it. The victim clicks on the link, which opens the server’s login page in his browser.
Note that upon request for login.jsp?sessionid=1234, the web application has established that a session already exists for this user and a new one need not be created. Finally, the user provides his credentials to the login script and the server grants him access to his bank account. However, at this point, knowing the session ID, the attacker can also access the victim's account via account.jsp?sessionid=1234. Since the session has already been fixed before the user logged in, we say that the user logged into the attacker’s session.
Attackers Uses http://online.worldbank.dom/<script>document.cookie="sessionid=1234”;</script>.idc to fix the session id in to victim browser
For Domain Cookies fixation
Attacker uses http://online.worldbank.dom/<script>document.cookie="sessionid=1234;domain=.worldbank.dom”;</script>.idc
Meta tag injection
====================
Issuing a cookie using the <META> tag with Set-Cookie attribute
<meta http-equiv=Set-Cookie content="sessionid=1234">
http://online.worldbank.dom/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20Expires=Friday,%201-Jan-2010%2000:00:00%20GMT”>.idc
Exploit 2 : Network Base attack (man in the middle attack)
Sniffing the packets with in the network coming to and from the victim computer
The attacker can inject a small (invisible) image in any web server’s response to the browser – for example when the user is reading Yahoo news. This image would originate from any web server in the .website.com domain. Upon requesting the image content, the browser would connect to this web server and the attacker, intercepting the request, could send a fake response by the web server, including a Set-Cookie header, thereby fixing the user’s session.
Exploit 3 : Prediction
The attacker can predict the session if session ids are not unique or random numbers are no coming
For example :
The session id is 123456
session id2 is 123456789
session id3 is predictable may be 123456789101112
===============================================
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords,keys,or session tokens, or to exploit other implementation flaws to assume other user's identities.
Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, time-outs, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique
Session IDs
=================
A Session is a unique identifier....
As we know that HTTP is a stateless protocol, which means that it provides no integrated way for a web server to maintain states throughout user’s subsequent requests.
A session identifier, session ID or session token is a piece of data that is used in network communications (often over HTTP) to identify a session, a series of related message exchanges. Session identifiers become necessary in cases where the communications infrastructure uses a stateless protocol such as HTTP.
For example, a buyer who visits a seller's site wants to collect a number of articles in a virtual shopping cart and then finalize the shopping by going to the site's checkout page. This typically involves an ongoing communication where several web pages are requested by the client and sent back to them by the server. In such a situation, it is vital to keep track of the current state of the shopper's cart, and a session ID is one way to achieve that goal.
A session ID is typically granted to a visitor on his first visit to a site. It is different from a user ID in that sessions are typically short-lived (they expire after a preset time of inactivity which may be minutes or hours) and may become invalid after a certain goal has been met (for example, once the buyer has finalized his order, he cannot use the same session ID to add more items).
Three widely used methods for maintaining sessions in WEB
=======================================================
1) URL arguments
2) Hidden form fields
3) Cookies (cookies have proven to be the most convenient)
************************************
Cross Site Scripting => Click on me :)
Basics for SQL Injection and Remediations => Click on me :)
Nmap with Metasploits => Click one me :)
*************************************************************
Session Management
=====================
Session management is the process of keeping track of a user's activity across sessions of interaction with the computer system.
Types
======
Desktop session management => A desktop session manager is a program that can save and restore desktop sessions. A desktop session is all the windows currently running and their current content.
Browser session management => Session management is particularly useful in a web browser where a user can save all open pages and settings and restore them at a later date. To help recover from a system or application crash, pages and settings can also be restored on next run.
Web Server Session management => Hypertext Transfer Protocol (HTTP) is stateless: a client computer running a web browser must establish a new Transmission Control Protocol (TCP) network connection to the web server with each new HTTP GET or POST request. The web server, therefore, cannot rely on an established TCP network connection for longer than a single HTTP GET or POST operation. Session management is the technique used by the web developer to make the stateless HTTP protocol support session state. For example, once a user has been authenticated to the web server, the user's next HTTP request (GET or POST) should not cause the web server to ask for the user's account and password again. For a discussion of the methods used to accomplish this see HTTP cookie and Session ID
Session management over SMS =>
Vulnerabilities
===========================
> User authentication credentials aren’t protected when stored using hashing or encryption.
> Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
> Session IDs are exposed in the URL (e.g., URL rewriting).
> Session IDs are vulnerable to session fixation attacks.
> Session IDs don’t time-out, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, aren’t properly invalidated during logout.
> Session IDs aren’t rotated after successful login.
> Passwords, session IDs, and other credentials are sent over unencrypted connections.
Attacks Done on Session IDs
=====================================
1) Session Hijacking => The attacker gains access to the user’s session by obtaining his session ID, is called session hijacking
2) Session fixation => The attacker fixes the user’s session ID before the user even logs into the target server, thereby eliminating the need to obtain the user’s session ID afterwards.
Attacks made in session fixation =>
*) Interception (Encrypted communication effectively protects against interception)
*) Prediction (Cryptographically strong pseudo random number generators and carefully chosen seeds that don’t leak from the serve prevents prediction of session IDs)
*) Brute-force (Bit-length is large enough with respect to the number of simultaneous sessions)
Session fixation vs. session hijacking
==========================================
Timing
Session fixation : Attacker attacks the user’s browser before he logs in to the target server.
Session hijacking : Attacker attacks the user’s browser after he logs in to the target server.
Impact Duration
Session fixation : Attacker gains one-time, temporary or long-term access to the user’s session(s).
Session hijacking : Attacker usually gains one-time access to the user’s session and has to repeat the attack in order to gain access to another one.
Session Maintenance
Session fixation : Can require the attacker to maintain the trap session until the user logs into it.
Session hijacking : Requires no session maintenance.
Attack Vectors
Session fixation
1. Tricking the user to log in through a malicious hyperlink or a malicious login form
2. Exploiting a cross-site scripting vulnerability on any web server in the target server’s domain
3. Exploiting a meta tag injection vulnerability on any web server in the target server’s domain
4. Exploiting the “session adoption” feature of some web servers
5. Breaking into any host in the target server’s domain
6. Adding a domain cookie-issuing server to the target server’s domain in the user’s DNS server
7. Network traffic modification
Session hijacking
1. Exploiting a cross-site scripting vulnerability on the target server
2. Obtaining the session ID in the HTTP Referer header sent to another web server
3. Network traffic sniffing (only works with an unencrypted link to the target server)
Attack Target Area
Session fixation : Communication link, target web server, all hosts in target server’s domain, user’s DNS server
Session hijacking : Communication link, target web server
Mitigation
===============
1) HTTPonly
2) Secure flag if HTTPS is there
3) Encrypted communication between the user’s browser and the target web server
4) Ensuring that sessions expire and within a reasonable period of time
Broken Authentication and Session Management Cases
=====================================================
Case 1:
Plain text storage of password
Storing a password in plaintext may result in a system compromise
Attacker can sniff the network with the help of any sniffing tool (such as wire-shark)
Case 2:
Improper Authentication
The user claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.
Case 3:
Missing Encryption of Sensitive Data
The software/website does not encrypt sensitive or critical information before storage or transmission
The lack of proper data encryption passes up the guarantees of confidentiality, integrity, and accountability that properly implemented encryption conveys.
For example : Storage for credit card no. or pin, user info or password
Case 4:
Clear text Transmission of Sensitive Information
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by an attacker.
Many communication channels can be "sniffed" by attackers during data transmission. For example, network traffic can often be sniffed by an attacker who has access to a network interface. This significantly lowers the difficulty of exploitation by attackers.
Case 5:
Session Fixation
Read above for session fixation
Case 6:
Insufficiently Protected Credentials
Login pages not using adequate measures to protect the username and password while they are in transit from the client to the server
Use SSL
Case 7:
Insufficient Session Expiration
"Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
The lack of proper session expiration may improve the likely success of certain attacks. For example, an attacker may intercept a session ID, possibly via a network sniffer or Cross-site Scripting attack. Although short session expiration times do not help if a stolen token is immediately used, they will protect against ongoing replaying of the session ID. In another scenario, a user might access a website from a shared computer (such as at a library, Internet cafe, or open work environment). Insufficient Session Expiration could allow an attacker to use the browser's back button to access web pages previously accessed by the victim.
> Set sessions/credentials expiration date
Case 8:
Unverified Password Change
When setting a new password for a user, the product does not require knowledge of the original password or using another form of authentication.
This could be used by an attacker to change passwords for another user, thus gaining the privileges associated with that user. (may lead to CSRF)
Case 9:
Weak Password Recovery Mechanism for Forgotten Password
The software contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Very often the password recovery mechanism is weak, which has the effect of making it more likely that it would be possible for a person other than the legitimate system user to gain access to that user's account.(May lead to Brute force attack)
This weakness may be that the security question is too easy to guess or find an answer to (e.g. because it is too common). Or there might be an implementation weakness in the password recovery mechanism code that may for instance trick the system into e-mailing the new password to an e-mail account other than that of the user. There might be no throttling done on the rate of password resets so that a legitimate user can be denied service by an attacker if an attacker tries to recover their password in a rapid succession. The system may send the original password to the user rather than generating a new temporary password. In summary, password recovery functionality, if not carefully designed and implemented can often become the system's weakest link that can be misused in a way that would allow an attacker to gain unauthorized access to the system. Weak password recovery schemes completely undermine a strong password
Exploitation With SessionId
================================
IMP : https://www.exploit-db.com/papers/15990/
=============
Exploit 1 : Session Fixation
A bank website, Session IDs are transported from browser to server within a URL argument sessionid.
The attacker – who in this case is also a legitimate user of the system – logs into the server and is issued a session ID 1234. The attacker then sends a hyperlink
http://online.worldbank.dom/login.jsp?sessionid=1234 to the victim, trying to lure him into clicking on it. The victim clicks on the link, which opens the server’s login page in his browser.
Note that upon request for login.jsp?sessionid=1234, the web application has established that a session already exists for this user and a new one need not be created. Finally, the user provides his credentials to the login script and the server grants him access to his bank account. However, at this point, knowing the session ID, the attacker can also access the victim's account via account.jsp?sessionid=1234. Since the session has already been fixed before the user logged in, we say that the user logged into the attacker’s session.
Attackers Uses http://online.worldbank.dom/<script>document.cookie="sessionid=1234”;</script>.idc to fix the session id in to victim browser
For Domain Cookies fixation
Attacker uses http://online.worldbank.dom/<script>document.cookie="sessionid=1234;domain=.worldbank.dom”;</script>.idc
Meta tag injection
====================
Issuing a cookie using the <META> tag with Set-Cookie attribute
<meta http-equiv=Set-Cookie content="sessionid=1234">
http://online.worldbank.dom/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20Expires=Friday,%201-Jan-2010%2000:00:00%20GMT”>.idc
Exploit 2 : Network Base attack (man in the middle attack)
Sniffing the packets with in the network coming to and from the victim computer
The attacker can inject a small (invisible) image in any web server’s response to the browser – for example when the user is reading Yahoo news. This image would originate from any web server in the .website.com domain. Upon requesting the image content, the browser would connect to this web server and the attacker, intercepting the request, could send a fake response by the web server, including a Set-Cookie header, thereby fixing the user’s session.
Exploit 3 : Prediction
The attacker can predict the session if session ids are not unique or random numbers are no coming
For example :
The session id is 123456
session id2 is 123456789
session id3 is predictable may be 123456789101112
0 comments:
Post a Comment