CVE-2013-5400: Analysis Of Authentication Bypass Vulnerability in IBM Platform Symphony

  • Post author:
  • Reading time:7 mins read

IBM Platform Symphony Developer Edition is a free software to develop and test High-performance computing (HPC) and Grid Computing SDK, which pool out your technical computing resources to run big data and/or compute-intensive problems. CVE-2013-5400 is an authentication bypass vulnerability in IBM platform symphony. However, these vulnerabilities can be remediated by using a vulnerability management software.

Vulnerability Description:

The “login.jsp” servlet in IBM Platform Symphony Developer Edition (DE) 5.2 and 6.1.x through 6.1.1 has hard coded credentials. It allows remote attackers to bypass authentication and obtain “local environment” access. However, CVE-2013-5400 can be avoided using the right patch management tool.

We tested authentication bypass successfully on IBM Platform Symphony Developer Edition Version 6.1.1

Below is a start-up image of IBM Platform Symphony Developer Edition. When we click on the button “Access Console”, it directly redirects us to the main Symphony Applications page without asking for authentication as done by CVE-2013-5400.

Screenshot from 2014-02-21 18:16:15

Below image shows up the main IBM Symphony Applications page with an demo application “symping6.1.1” running.

Screenshot from 2014-02-21 18:27:34

Lets analyse what’s happening in the backend by sniffing the network traffic.
Below is the request and response captured, when “Access Console” button is clicked on the startup page.

GET /platform/dealUserLogin.do HTTP/1.1 Host: 192.168.1.26:18080 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Referer: http://192.168.1.26:18080/platform/index_de.jsp Cookie: JSESSIONID=5B8CDE191C292F3BF9D312147D81ED7B; DE_GUIplatform.username="OG0Q3YUPHWw="; DE_GUIplatform.password="OG0Q3YUPHWw="; DE_GUIplatform.descookie=""; DE_GUIplatform.token=testToken; DE_GUIplatform.userrole=1; DE_GUIplatform.logindate=1392991266996; DE_GUIplatform.renewtoken=1392993066996; platform.username="OG0Q3YUPHWw=" HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: DE_GUIplatform.username="OG0Q3YUPHWw="; Version=1; Path=/ Set-Cookie: DE_GUIplatform.password="OG0Q3YUPHWw="; Version=1; Path=/ Set-Cookie: DE_GUIplatform.descookie=""; Path=/ Set-Cookie: DE_GUIplatform.token=testToken; Path=/ Set-Cookie: DE_GUIplatform.userrole=1; Path=/ Set-Cookie: DE_GUIplatform.logindate=1392991759887; Path=/ Set-Cookie: DE_GUIplatform.renewtoken=1392993559887; Path=/ Content-Type: text/html;charset=UTF-8 Content-Length: 272

Check out the cookie section “DE_GUIplatform.username=”OG0Q3YUPHWw=”;” “DE_GUIplatform.password=”OG0Q3YUPHWw=”;”

The “/platform/dealUserLogin.do” which actually is an “index.jsp” a servlet page. It sets the username and the password in the cookie and sends it to “login.jsp” servlet page.

Now lets see how “login.jsp” servlet handles the cookie. The servlet “login.jsp” is setting up username variable (userName) and password variable (userPwd) value from the cookie as show in the below picture.

login-code

And then it’s assigning variable value “userName” to “userToken”.

userToken = userName;

Now let’s check the HTML form part in “login.jsp”

<form name=”loginform” method=”post” action=”<%=loginUrl%>”
style=”display: none”>
<input id=”j_username” name=”j_username”
value=”<%=userRole%><%=userToken%>” /> <br /> <input
id=”j_password” name=”j_password” value=”<%=userPwd%>” /> <input
type=”submit” value=”OK” name=”b1? />
</form>

As we can notice from the above code, the servlet is hard-coding username and password values. Therefore, Its creating USERNAME value by making use of “userRole” and “userToken” (which is userName) and PASSWORD value as userPwd. 

<input id="j_username" name="j_username" value="<%=userRole%><%=userToken%>" />
<inputid="j_password" name="j_password" value="<%=userPwd%>" />

Next it sends a POST request to “/symgui/j_spring_security_check” as shown below

POST /symgui/j_spring_security_check HTTP/1.1
Host: 192.168.1.26:18080
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://192.168.1.26:18080/symgui/login.jsp?
Cookie: JSESSIONID=46957C6AF61C9E6A47D5F1DD58FEED75; DE_GUIplatform.username=”OG0Q3YUPHWw=”; DE_GUIplatform.password=”OG0Q3YUPHWw=”; DE_GUIplatform.descookie=”"; DE_GUIplatform.token=testToken; DE_GUIplatform.userrole=1; DE_GUIplatform.logindate=1392991759887; DE_GUIplatform.renewtoken=1392993559887; platform.username=”OG0Q3YUPHWw=”
Content-Type: application/x-www-form-urlencoded
Content-Length: 57

j_username=1%2522OG0Q3YUPHWw%3D&j_password=OG0Q3YUPHWw%3D

Check the POST data, j_username=1%2522OG0Q3YUPHWw%3D j_password=OG0Q3YUPHWw%3D Url decoded of it is j_username=1″OG0Q3YUPHWw= j_password=OG0Q3YUPHWw=

After this it redirects to main Symphony Applications area. Then we can access and control to all the available information i.e we can view, run, modify, delete the information.

Below is an image which shows up results after running “symping6.1.1” demo application. Moreover, we can see the authorization and various details in the below picture.

cred2

Solution: Vendor has advised the users of IBM Platform Symphony Developer Edition to configure it on local loopback IP address (127.0.0.1) only.

– Shashi Kiran

Share this article
Tags: , ,