Could the FORCED BROWSING be a case of the tester having an open browser on a form and then opening another browser? Because they are logged in under one browser session a second will see the login and not ask for credentials.
Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, LJ CTR MDA/IC Sent: Monday, October 08, 2012 7:57 AM To: arslist@ARSLIST.ORG Subject: Re: Results of a application pen-test - need to close holes Dan, 1 - Privilege Escalation - I can't speak to the service catalog (I think that's by design)...but if you need the preference record to be only viewable by themselves, you could change the permission on field 1 to only allow the 'Submitter' group access. This isn't a case of privilege escalation, simply a case of being able to do something the evaluator felt they shouldn't be able to do 2 - Improper Error Handling - Yes and No...I vaguely understand the concern, but I'm not entirely seeing the 'attack vector' based on the content of the messages 3 - No Session Timeout - Already addressed 4 - Concurrent User Sessions - Already addressed 5 - Forced Browsing - I'm not familiar with the ability to get into forms without authentication, but you could look into applying a 'filter' to your tomcat 'arsys' context, thus enabling forced authentication at the web server....ideally you would want this authentication to be automatic (SSO) so that you don't first need to authenticate to the context, then ALSO need to log onto the remedy app...that would simply be annoying to the users 6 - Autocomplete - Already addressed 7 - Banner Grabbing - I have no information about this one...sorry, hopefully someone else can assist. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dan Miller Sent: Sunday, October 07, 2012 4:15 AM To: arslist@ARSLIST.ORG Subject: Results of a application pen-test - need to close holes 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"
