Hi forum,
I hope you can help, and I am sorry in advance for the long post, but I am
trying to get all this into one post, hoping that someone has gone through this
exercise before. So basically, we had an application pen-test before releasing
our remedy platform to the public internet. We got 7 things that we need to
fix, some of them before we can go live, others that can wait a while.
Summary:
1. Privilege Escalation
2. Improper Error Handling
3. No session time out
4. Concurrent User Sessions
5. Forced Browsing
6. Autocomplete feature
7. Banner Grabbing
Below I have described them a little more with description, recommendation, but
also the problem I have in getting them implemented. We are 18 months into our
first ever Remedy journey, so security is something we have not really
considered.
Can you please help?
1. Privilege Escalation
--------------------------------------
Description:
-----------------
Privilege escalation in Remedy application allows a user to gain elevated
access to resources that are meant a privileged user. It was observed that in
Remedy a user can view / read other user’s Service catalogue and preference
details. The privilege values should be checked from the database and not be
stored in a client side cookie.
Vulnerable Urls:
https://<hostname>/arsys/forms/<server-mame>/SRS%3ACFGApplicationPreferences/Dialog+Console/?cacheid=aeabdc61&format=html
https://
<hostname>/arsys/forms/<server-mame>/SRS%3AServiceRequestConsole/enduser/?cacheid=1bc6c61&format=html
https:// <hostname >/arsys/atrium/ServiceCatalog.swf
this means the user can get more rights than they are entitled too. In this
case a test user was able to see other users preferences, this may need to go
back to BMC if T&T are unable to resolve as it may be an application fault.
Recommended fix is to enable server side authentication and not client side
which is currently in place.
Recommendation:
-------------------------
It is strongly recommended to check the privilege values from the database
before granting access to secured recourses applications.
Problem:
------------
How do I even start with this one…. Is there something I am not doing in terms
of application lock down? Is it something to do with object-list within
mid-tier so URLs can be directly browsed to?
2. Improper Error Handling
---------------------------------------
Description
---------------
If a web application encounters an error condition it may need to display an
appropriate error message. Sometimes these messages can be detailed enough to
give away crucial information about the application. This information may
include database schema/table names, user names, platform specific information
etc. Applications giving out detailed error messages run the risk of exposing
crucial information which can be used later to launch further attacks.
Our Remedy installation seems to have been configured in an insecure way.
Whenever the application encounters any kind of error condition (such as failed
execution of an
SQL query), an error message of failure SQL operation is sent back to the
user’s browser.
Example typical error:
“The SQL database operation failed. : The data types text and varchar are
incompatible in the equal to operator. (SQL Server 402) (ARERR 552)”
Recommendation:
------------------------
In a live environment, application error messages should be kept as short as
possible. Hence it is advisable that the error messages emanating from certain
scripts be restricted. Only custom HTTP error messages should be displayed
instead of the detailed ones.
Problem:
------------
Again, not sure what to do here. I have not enabled anything special as far as
I can see. I think we did set something to make the error appear in the bar
rather than popping up, but other than that, can I disable error messages
altogether for user-level remedy users?
3. No session time out
Description:
----------------
this means the application session will never time out, in the case where a
user was using a shared PC a session could be hi-jacked or stolen.
Recommendation:
------------------------
Session timeout should be enabled. For web facing system session timeout should
be 20/30 minutes, to protect customers.
Problem:
------------
I am pretty sure this is a setting on a user by user basis. Is there a way to
globally push a new timeout setting to all of the currently configured users?
There is a session timeout in mid-tier but I don’t think that actually logs
people out of remedy…
4. Concurrent User Sessions
Description:
----------------
Concurrent login sessions allow multiple users to log into the application
using a single user ID. This makes it difficult for the web application to
maintain traceability of user activity. If concurrent sessions are allowed,
there is a possibility that users may access the same account in parallel and a
legitimate user might not be able to identify that his account is being
accessed by an unauthorised user. In this case there would be loss of
traceability of user activities.
Recommendation:
------------------------
It is recommended to check the user’s logged in status. If the user ID and
password supplied are correct, the system should check whether or not the user
is already logged in. This is to ensure concurrent user sessions are not
allowed.
Problem:
------------
I cannot find a setting for this anywhere! And when googling, all I find is
licensing information doh!
5. Forced Browsing
Description:
----------------
Forced browsing is a process where it is possible to gain access to the
restricted resources without first being authenticated or having the
appropriate level of application access. The motive behind forced browsing is
to try and enumerate and access resources that are not referenced by the
application, but are still accessible. It was observed that
https://service.btireland.com application by requesting the URL directly; an
unauthenticated user could access the documents. There are no authentications
and authorisation checks performed before providing access to the internal
files. (Survey form) Vulnerable URL:
https://<hostname>/arsys/forms/<servername>/SRM%3ASurvey/RequesterAnswer
Recommendation:
------------------------
An application serving protected content should implement the authentication
and authorisation logic on all the pages before access is granted to any user.
Problem:
------------
Where do I even start on this one? I thought remedy were on top of this sort
of thing… it is a little like the privilege escalation issue, where users can
directly browse to pages
6. Autocomplete feature
Description:
----------------
this means the computer stores usernames and passwords
Recommendation:
------------------------
This should be disabled and should be an option in the application
configuration.
Problem:
------------
This is not a setting in remedy, so do we need to open up the JSP for login and
set autocomplete or something? Or is there something in tomcat?
7. Information Disclosure through Banner Grabbing
Description:
----------------
this means an attacker is able to find out information about the platform, such
as webserver type, versions etc.
Recommendation:
------------------------
This should be disabled and should be an option in the application
configuration. This can be changed and should be, to display information not
relating to the platform.
Problem:
------------
I have added the “server=dans server” parameter to the connection string for
tomcat, but I suspect there is a way to disable ANY banner, do you know how?
There is probably a tomcat hardening guide somewhere
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
