how to restrict bypassing of authentication

[govardan_raj]

HI experts,

we have second factor authentication involved in our portal product , by using hacking tool burp Suite im able to capture the response and request coming from the server .

Case 1 : user have primary authentication with user name and password , and secondary authentication as his OTP send to his mobile , after entering this OTP , he can login into the portal .Now at the end stage im getting an Authenticated response from the server as show below

HTTP/1.1 302 Found
content-type: text/plain
set-cookie: MYSAPSSO2=********************************************************************************************************************************************************************************************

***************************************************************************************************************************************************

************************************************************************************************************%3D;path=/;domain=.*************;HttpOnly
set-cookie: JSESSIONMARKID=(J2EE2816900)ID1049281650DB414bde284b5152939d4cf5487d21ccc0cffd7091End; Version=1; Path=/; Secure; HttpOnly
location: https://hosthttps://host/irj/servlet/prt/portal/prtroot/com.sap.portal.navigation.portallauncher.default:443/irj/servlet/prt/portal/prtroot/com.sap.portal.navigation.portallauncher.default
content-length: 0
date: Wed, 28 May 2014 05:27:09 GMT
set-cookie: com.sap.engine.security.authentication.original_application_url=; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/

This is the reponse which we are able to capture and now again we can login , using wrong user name and wrong password using  burp suite tool intercept the response and replaing the above response we are able to login.

Here we are not able to restrict this particular stage.

is there any solution to stop this please suggest us..

Regards

Govardan Raj S

[Former Member]

Hi,

what you describe above is a man in the middle attack. This is usually countered by using SSL to encrypt the traffic. Actually, the system will not even try to evaluate the username and password supplied, as you have all the info identifiying the users session at hand and therefor the system believes, this is a valid session of the user, which had just been authenticated using his credentials.

For more info on how to protect your system, I'd recommend to read 'Protectiing SAP Apps' as it gives some background info and furhter tips on how to secure your system. In addition, you can always check the security guides.

Kind regards,

Patrick

[govardan_raj]

hi Patrick ,

Thanks for your suggestion after going through the pdf , we have configured sessionIDregeneration enabled property , and restarted the sever. specified in 1310561 - SAP J2EE Engine Session Fixation Protection

According to this , set-cookie: JSESSIONMARKID=(J2EE2816900)-- should be changing every time i.e when user logs in.

After  capturing above response HTTP/1.1 302 etc , when user gives valid credentials and logs in ,

and now ill give wrong password and wrong user id and on click of log on button, i can intercept the request and response coming from the server and when i replace this valid response stil im able to login in to the portal , which should not happen as JESSIONMARKID is changed , server should not allow , but it is loggin in.

My server version is EP 7.01

Please suggest a solution so that if we restric the hacker at this stage , no matter he can never hijack the sesiona and login  with invalid username and  password.

Regards

Govardan

[govardan_raj]

Hi Patrick ,

i would like to add some  more points to the above reply , after testing using interception tool , the jsession mark id is getting changed every time  when user logs in , but here even though the jsession mark id is changed , when we replace the response indicating (user authentication failed ) with the above valid response (in my frist message http1.1 /302 found etc)  the server is allowing the user to log in.

How to restrict this type of log in ?

Regards

Govardan Raj

[Former Member]

Hi Govardan,

as said, you can't if you allow an atacker to play man in the middle. Once you have access to the communication data exchanged between the browser and the server, the two have no chance to protect themselves against missusing the info. The JSessionMarkID only helps against XSS and XSRF (frontend based attacks using JavaScript) not against MITM. To protect against MITM, you have to make sure, the conversation between the browser and the server is kept confidential and can not be tampered. This is, why you would use SSL to connect to the server. Any interception tools however will just negate this and are required to be able to read this information and need to be able to tamper any data part of this conversation.

Kind regards,

Patrick

[govardan_raj]

Hi Patrick,

Thanks for the reply ,

even though the connections are based on ssl ,when we have a proxy server all our systems request are all passed via proxy server,

the proxy administrator has an option to track the request and response and intecept the same via the burp suite tool , so in this case

as explained earlier  we can bypass the authentication ,

bypassing the authentication is happening even in the standard sap logon Page.

please suggest a solution...

Regards

Govardan Raj

[Former Member]

Hi Raj,

there are only two solutions. Stop using Burp on the proxy servers, as this not only allows for tampering password info but ALL information passwd through (i.e. change business data like account details in invoices) or use an other authentication scheme like SAML2 with an external IdP or some Hardware based token with feedback channel which is not using the tracked SSL proxies.

Please be aware, that as long as you are able to directly intercept into the communication between the client and the server, everything that is not digitally singed by the sender can not be trusted by the receiver. However a solution to digitally sign every message in HTTP based communications (not the channel but the message itself) is not known to me for standard HTTP based communications. Also this would require changes to both the browser and the server.

Regards,

Patrick