Remedy Application Data Security Risks & Mitigations

Transcription

1 Remedy Application Data Security Risks & Mitigations Web-Access related Dinesh Singh Panwar 8/8/2012 This Document describes risks related to web access for Remedy. It also shows how those risks and the cause and how these could be mitigated by simple customizations

2 Contents 1. Introduction Approval Inbox Security Risks and Mitigation Overview of Approval Inbox Security Risk How the risk could be exploited How the risk could be mitigated Session Security User Spoofing Overview of Session Security Risk How the risk could be exploited How the risk could be mitigated dinesh.s.panwar@gmail.com

3 1. Introduction Many a times Custom and Out-of-Box Applications and Features of Remedy are subjected to Data Security penetration tests and concerns are raised about Data Security. This document tries to suggest resolutions to some of the critical Data Security concerns. The Core Out-of-Box ITSM Application is generally secure with respect to Data by extensive use of Assignee Groups Field to enforce multitenancy. Custom Applications and Peripherals features like Approval Inbox however have potential leakages from where sensitive information could be retrieved out without Authorization. The Document is essentially meant for Development Team to provide immediate resolutions to Security concerns on Remedy based Application, if the local environment/policies/guidelines allow. The Document is on the basis of Remedy v7.1, however may still be valid for subsequent versions. 2. Approval Inbox Security Risks and Mitigation This section highlights the Security flaws in the Approval Inbox and discusses the ways to make it secure depending on Organization s Policy. 2.1 Overview of Approval Inbox Security Risk The Out-of-Box Approval Inbox is OOTB Tool to view the Approval Signatures. Technically, it lists down the Records in the Form AP: Detail-Signature, on the basis of the below query: Status = Pending AND ( Approvers LIKE %;$USER$;% OR Approvers LIKE $USER$;% OR Approvers LIKE %;$USER$ ) In a typical web-environment, the flow of information is depicted by below schematic diagram. The arrow highlighted in RED, denotes the area where a vulnerability of Client Side manipulation exists. 3 dinesh.s.panwar@gmail.com

4 Now, interestingly Remedy Table Qualifications are shared to and fro between the browser and the Mid- Tier in a Remedy encoded Format (which is not hard to break) and it is possible to change that appropriately to retrieve whatever query we want to pass on to the Server. This makes it vulnerable. From a Business Logic perspective, an Approver shall only sees pending requests where he appears as Approver or Alternate Approver. From authorization perspective, he should not be able to view request in the queue of other users or at-least other Companies (Multi-tenancy). However, it s possible to manipulate the communication between Browser and Mid-Tier to retrieve the Approval request of other users, even if the user belongs to other Companies! Company level multitenancy of Companies isn t implemented out-of-box for Approval Records. There is, however, a silver lining that viewing the original request using the View Button would fail if relevant permission are not there (because in such case control goes back to relevant ITSM App where multitenancy and Functional restriction are in place) 2.2 How the risk could be exploited In a typical interaction between browser and the Mid-Tier, there are various HTTP Request and Response that are interacted before any Remedy Page is rendered on the user s screen. These requests are termed as Back channel calls. In a Remedy Page that contains a Table (like Approval Inbox), the query is sent to Mid-Tier in one of these Backchannel calls that can be easily manipulated to retrieve the unauthorized Data (in case of Approval it will be the Approval request of other users or other Companies) Proxy tools such as BURP can be used to intercept the outgoing and incoming HTTP requests and responses. Such tools act a proxy and allow the Request/Response to be intercepted and manipulated. If we were to intercept the HTTP Requests from Browser to the Mid-Tier (using Tools like BURP Proxy), then a typical request containing the Table Qualification, would be like below POST HTTP/1.0 <<Some Web Info>> 286/ServerRunProcess/37/the_backend-Applicationsvr_or_lb_fqdn 26/AP:Central- SetInternalQual1/01/09/ /0/2/0/2/0/13/1/9/ /1/138/ 'Approval Status' = 0 AND ('Approvers' = "usr1" OR 'Approvers' LIKE "usr1;%" OR 'Approvers' LIKE "%;usr1" OR 'Approvers' LIKE "%;usr1;%")5/1/1/ dinesh.s.panwar@gmail.com

5 This request can, for instance, be changed to below to list down all the Pending Approvals for all the users POST HTTP/1.0 <<Some Web Info>> 195/ServerRunProcess/37/the_backend-Applicationsvr_or_lb_fqdn26/AP:Central- SetInternalQual1/01/09/ /0/2/0/2/0/13/1/9/ /1/49/ 'Approval Status' = 0 AND ('Approvers' LIKE "%")5/1/1/ How the risk could be mitigated The Risk mitigation to such a security risk is done by performing Data restrictions in the Application Server in addition to the Table Qualifications which are vulnerable in a web transaction. Since Application Server is behind the Data Centre firewalls, so the risk is greatly reduced. To apply this Data restriction, Core Fields like Assigned To or the Assignee Groups could be utilized. The use of Assignee Groups (Field ID 112) is same as it is used in OOTB ITSM Applications. Typically the steps involved are Note that, 1. Give Assignee Groups permissions in the Request ID Field (ID =1) 2. Remove any Public permission if any from the Request ID 3. Write Filter on AP:Signature on every Submit/Modify RUN IF: Approvers!= DB.Approvers ACTION: Assignee Groups = Approvers This will enforce a strict Row Level Restriction on the Approval Signatures where access is strictly allowed for the Approvers (& Alternates). This is different from Multi-tenancy where Row level Access is little relieved as it s there for Company Wide. Row Level Restriction like this is enforced automatically at Application Server and hence any manipulation at Client Side doesn t impact this restriction. Depending on the Security Policy, the above implementation could be eased and kept at Company Level. However, for that the Company Group ID needs to be pushed/looked up from the corresponding Application Request Record, since Company information is NOT present in Approval Forms. 5 dinesh.s.panwar@gmail.com

6 Below Diagram shows the rough Data Flow across the 4 Tiers as it happens. As we can see, the manipulation risk exists on the Presentation Layer and it s mitigated by Row Level Restriction at the Application Layer. 6 dinesh.s.panwar@gmail.com

7 3. Session Security User Spoofing This section deals with the possibility of changing an active session to that of a different user without knowing the Password. It will also discuss on the Customization that could be done to mitigate such a risk. 3.1 Overview of Session Security Risk Remedy uses popular Web-Server and Servlet Engine (like IIS/Apache and Tomcat) as the underlying Platform for the Web-Server, so the actual Platform session is secure. But, Remedy Applications have another layer of user session which is the Remedy Session that deals with the Remedy Profile and Group Permissions. Underlying Web-Technology is, if you like, unaware of this and additional Mid-Tier Code manages this additional layer of Session using Out-of-box Mid-tier code JavaScript & java. To maintain that session layer across the App-server, Web-Server & Browser, there is Remedy Specific Code that share Remedy Profile data (like user ID) using JavaScript. This could be intercepted using Tools like BURP on the Browser Side. Below diagram (Source: BMC Software Inc.), shows the role of Mid-Tier. Typically, it replaces the Remedy Thick Client (AR User), in conjugation with the Browser (also called thin Client). So, theoretically, most of the core functionalities of AR User - including Authentication are split 7 dinesh.s.panwar@gmail.com

8 apart into components running in Browser and that running on Mid-Tier. These components share the data over HTTP Protocol & Java Scripts. Tools like BURP can be used to eavesdrop. 3.2 How the risk could be exploited Proxy tools could be set up such that request are routed through this tool. Now, the Mid-Tier would send back the responses and in one of the responses it would send some of the User Profile Information in some java-script file. The Contents would look something like below The Browser Code hence forth uses this Profile information while executing various Client Side Code such as some actions of Active Links where references to $USER$ is made UserData_Init(){ARKWSetup(2,"<<the user ID>>" If you change the User Id before forwarding this response to the browser, then various functionalities are vulnerable to be done on behalf of the new User ID. For instance, if we submit a Record where submitter is defaulted to $USER$, then the record would show to be submitted by that new User. It should be noted that this breach is possible only on the Client Side (i.e. Browser) and the corresponding Server session still maintains the Original $USER$. This means, most of the Functionalities running on Server (like Filters) are NOT impacted. 3.3 How the risk could be mitigated The risk mitigation lies on the fact that Server Side session is remains safe. Now, this sharing of User Data happens before a FORM is rendered on the Browser. Therefore, if we somehow cross-check if the $USER$ of client side is indeed same as $USER$ of the corresponding Server Session, and the user could be logged out in case it s different. This can be made possible by having below implementing below Login using Active Link, Service Call and Filter 8 dinesh.s.panwar@gmail.com

9 Thing to be noted here is that, this workflow based solution in not an ideal solution due to overhead of back-channel calls. Ideal solution shall be done at the Platform Level itself. 9 dinesh.s.panwar@gmail.com