NRDS Draft report _web pen test_

Document Sample
NRDS Draft report _web pen test_ Powered By Docstoc
					Confidential – PulseSecure Pte Ltd


1.      Web Application Penetration Test Results

1.1     Scan History

 Assessment Date                                                    By
 1 – 3 Nov 2010                                                     PulseSecure Pte Ltd

1.2     Scope

 URL                                                                     Remark
 https://uat.ndrs.hpb.gov.sg/ndrs/index.do                               NRDS

1.3     Summary

 Application Assessment                High       Medium      Low         Info        Total
 Web Application Penetration Test        0            2        3           0              5

1.4     Summary of Findings

 Vulnerability                                               Risk        Ref         Status*
 Possible to change password on behalf of other users        Medium      NRDS-01     Open
 Potential SQL Injection                                     Medium      NRDS-02     Open
 File upload function does not restrict on type              Low         NRDS-03     Open
 Insufficient access control on approving request for data   Low         NRDS-04     Open
 Sensitive information is cached                             Low         NRDS-05     Open




                                             Page 1 of 17
Confidential – PulseSecure Pte Ltd


2.      Risk Ratings
All the findings are classified according to the following risk ratings. Note that other factors not
listed below may influence the final rating for a specific vulnerability.

                              Impact Analysis
 Impact                       Attacker Potential Gain
                              Business Owners Security Considerations
                              Possibility of such a vulnerability being exploited
 Likelihood
                              Level of skill needed to exploit such a vulnerability

                                  Final Risk = Impact x Likelihood

We then can computed the final risk rating with respect to the below table.

                                                             Likelihood
                                               High          Medium        Low
                              High             High          High          Medium
                   Impact     Medium           High          Medium        Low
                              Low              Medium        Low           Low

All the findings were classified according to the following final risk ratings.


                    These are vulnerabilities that, if exploited, present an attacker with
                    some possibility of gaining full control of the server and full access to all
                    data stored on the server.
      High          Vulnerabilities with a high nature may also be vulnerabilities that are
                    easily exploitable. If exploited, they may have the potential to cause
                    great loss in terms of reputation or cost. High vulnerabilities should be
                    reviewed and mitigated within a week of discovery.

                    Medium risk vulnerabilities, if exploited, allow the attacker partial or
                    limited access to the server, which might allow him access to certain
                    sensitive data.
     Medium         Vulnerabilities with a medium nature may also be vulnerabilities that are
                    moderately easy to exploit. If exploited, they may have the potential to
                    cause some loss in terms of reputation or cost. Medium vulnerabilities
                    should be reviewed and mitigated within a month of discovery.

                    The attacker is not able to access the server readily by exploiting these
                    low risk vulnerabilities. However, he could use these vulnerabilities to
                    gather more information about the internal structure of the
      Low           server/network. This information could help the attacker to fine tune his
                    future attacks. Low vulnerabilities should be constantly reviewed
                    and an effort to mitigate these vulnerabilities should be made during the
                    maintenance cycles or within 3 months.

 Informational      This item is highlighted for information only.




                                             Page 2 of 17
Confidential – PulseSecure Pte Ltd



Ref:               Vulnerability Description: Possible to change password on behalf of other users
NRDS-01
                          Filename/Function: Change password function
                                                                          Likelihood: Low
              Risk Rating and breakdown:              Medium
                                                                              Impact: High
Details

It is possible to change the password of another user, if the victim’s existing password is known or by
guessing, and changing the loginName parameter value to the victim’s.

               :
               :
               :

Example

Login as qa1_test, and access the Change Password function.




Submit the following request and modify the loginName parameter value from qa1_test to qa2_test:

POST /ndrs/jsp/itrust/userchangepassword2.jsp
oriPassword=password2&newPassword=password3&newPassword2=password3&question=color&answ
er=blue&loginName=qa2_test

The request is accepted by the application.
When user qa2_test tries to login with the old password – password 2, login will fail.




                                           Page 3 of 17
Confidential – PulseSecure Pte Ltd




When user qa2_test tries to login with the new password set by qa1_test – password 3, login will be
successful.




Implications

An attacker can attempt to change another user’s password by guessing it, to gain unauthorised access
to that account and also cause a denial-of-service for the legitimate user.

This form of brute-force password guessing attack is not protected by the account lockout feature found
on the login page.

Recommendations

To include checks to verify if the current user is authorised to change the password of the requested
account.



                                           Page 4 of 17
Confidential – PulseSecure Pte Ltd


Follow-Up (to be completed by Customer)
Have you applied any remedy?            YES / NO
If YES,    Please state the date you    (DD/MM/YY)
           have applied the remedy.
           Please explain the
           remedy/solution/mitigation
           you have applied.
If NO,     Please state the reason.     Changes will be done in next quarter as the risk
           (or any form of existing     implication is still low since the system is only used
           mitigation already in-place) by authorized NRDO users and it’s not an internet
                                        application.
           Please state an estimated    (DD/MM/YY)
           date you plan to apply the   30/03/2011
           remedy.
Follow-Up Review (to be completed by Assessor)
Vulnerability fixed?
Review Date:
Review Details:




                                      Page 5 of 17
Confidential – PulseSecure Pte Ltd



Ref:           Vulnerability Description: Potential SQL Injection
NRDS-02               Filename/Function: Search Request
                                                                 Likelihood: Medium
             Risk Rating and breakdown:      Medium
                                                                    Impact: Medium
Details

When SQL meta characters are submitted in the parameters for Search Request function. The results
show that the parameters could have been directly used to construct the SQL query statement.

Example

Go to Common - > Request Data -> Update Request Status.

Submit a search request and inject '+and+1=1-- behind a valid query string (“2005/001”) in requestID
parameter, it will make the SQL statement true, as follows:

POST /ndrs/workflow/searchRequest.do
org.apache.struts.taglib.html.TOKEN=7b287a37b06cfbc76f866a703e260db4&registryId=&requestTo.r
equestId=2005%2F001'+and+1=1--
&requestTo.requestStatus=&requestTo.requesterRefId=&requestTo.requestFreq=&fromDate=&toDat
e=&functionType=search&searchedInd=Y&moduleId=Cancer&paramValue=&wfReqIdNo=

2 records are returned.




Submit a search request and inject '+and+1=2-- behind a valid query string (“2005/001”) in requestID
parameter, it will make the SQL statement false, as follows:

POST /ndrs/workflow/searchRequest.do
org.apache.struts.taglib.html.TOKEN=7b287a37b06cfbc76f866a703e260db4&registryId=&requestTo.r
equestId=2005%2F001'+and+1=2--
&requestTo.requestStatus=&requestTo.requesterRefId=&requestTo.requestFreq=&fromDate=&toDat
e=&functionType=search&searchedInd=Y&moduleId=Cancer&paramValue=&wfReqIdNo=

                                         Page 6 of 17
Confidential – PulseSecure Pte Ltd


No records are returned.




Submit a search request and inject '+or+1=2-- behind a valid query string (“2005/001”) in requestID
parameter, it will make the SQL statement true, as follows:

POST /ndrs/workflow/searchRequest.do
org.apache.struts.taglib.html.TOKEN=7b287a37b06cfbc76f866a703e260db4&registryId=&requestTo.r
equestId=2005%2F001'+or+1=2--
&requestTo.requestStatus=&requestTo.requesterRefId=&requestTo.requestFreq=&fromDate=&toDat
e=&functionType=search&searchedInd=Y&moduleId=Cancer&paramValue=&wfReqIdNo=

2 records are returned again.




The logical operator “or” and “and” result in different response. This shows that the user input could
be directly used as part of the construction of the SQL statement to retrieve data.



                                           Page 7 of 17
Confidential – PulseSecure Pte Ltd


Implications

SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL
queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in
which their input appears and interfere with the structure of the surrounding query.

Various attacks can be delivered via SQL injection, including reading or modifying critical application
data, interfering with application logic, escalating privileges within the database and executing
operating system commands.

Recommendations

Do not trust client side input even if there is client side validation. In general,

•       Do not create dynamic SQL query by simple string concatenation.
•       Use Parameterized queries, using bound, typed parameters.
•       Escape on SQL meta characters if query is constructed using string concatenation.

The most effective way to prevent SQL injection attacks is to use parameterised queries (also known
as prepared statements) for all database access. This method uses two steps to incorporate
potentially tainted data into SQL queries: first, the application specifies the structure of the query,
leaving placeholders for each item of user input; second, the application specifies the contents of each
placeholder. Because the structure of the query has already defined in the first step, it is not possible
for malformed data in the second step to interfere with the query structure. You should review the
documentation for your database and application platform to determine the appropriate APIs which
you can use to perform parameterised queries. It is strongly recommended that you parameterise
every variable data item that is incorporated into database queries, even if it is not obviously tainted,
to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere
within the code base of the application.

Follow-Up (to be completed by Customer)
Have you applied any remedy?             YES/NO
If YES,     Please state the date you
            have applied the remedy.
            Please explain the
            remedy/solution/mitigation
            you have applied.
If NO,      Please state the reason.     Changes will be done in next quarter as the risk
            (or any form of existing     implication is still low since the system is only
            mitigation already in-place) used by authorized NRDO users and it’s not an
                                         internet application.
            Please state an estimated    30/03/2011
            date you plan to apply the
            remedy.
Follow-Up Review (to be completed by Assessor)
Vulnerability fixed?                     YES/NO
Review Date:                             (DD/MM/YY)
Review Details:




                                              Page 8 of 17
Confidential – PulseSecure Pte Ltd



Ref:                Vulnerability Description:      File upload function does not restrict on type
NRDS-03
                           Filename/Function:       File upload function

                                                                             Likelihood:     Low
                 Risk Rating and breakdown:              Low
                                                                                 Impact:     Medium
Details

The file upload function does not restrict on the file types which are accepted. It is possible to upload
potentially dangerous types like HTML (could perform cross-site scripting attacks on user), executable /
VB script (could compromise user machine) and JSP (could attack server).

Due to constraints in UAT environment, we are unable to test the results of downloading these files from
server.




Implications

It is possible for attacker to upload malicious files to the server. When other users download and open
these files, they would be attacked. It is also possible to upload server script files (JSP) which could be
executed by the server.

However, only users with users with Administrator role have access rights to upload files.

Recommendations

It is recommended that the application has a whitelist of acceptable file types and avoid accepting


                                            Page 9 of 17
Confidential – PulseSecure Pte Ltd

potentially dangerous ones (e.g. html, htm, jsp, exe, vbs).

Perform anti-virus scan on uploaded files at the server to look out for known virus/malware.


Follow-Up (to be completed by Customer)
Have you applied any remedy?                     YES / NO
If YES,      Please state the date you have      (DD/MM/YY)
             applied the remedy.
             Please explain the
             remedy/solution/mitigation you
             have applied.
If NO,       Please state the reason.            It’s a low risk implication as only privileged NRDO users
             (or any form of existing            have access to upload files to servers and their activities
             mitigation already in-place)        are logged in the system. Users are aware of the risk that
                                                 files may contain virus, therefore be careful on the files
                                                 they upload. Furthermore, this is an online Intranet
                                                 application and is only accessible within NDRO work
                                                 area. Anti-virus scan has been in placed to scan files for
                                                 known virus/malware on the servers.
              Please state an estimated date (DD/MM/YY)
              you plan to apply the remedy.
Follow-Up Review (to be completed by Assessor)
Vulnerability fixed?
Review Date:
Review Details:




                                           Page 10 of 17
Confidential – PulseSecure Pte Ltd



Ref:             Vulnerability Description: Insufficient access control on approving request for
                                                  data
NRDS-04
                         Filename/Function: Update Request Status
                                                                         Likelihood: Low
              Risk Rating and breakdown:                 Low
                                                                             Impact: Low
Details

The Update Request Status function does not restrict users from approving/rejecting any requests, even
if they are not the approval authorities.

Example

Login as qa1_test, holding Stroke_RC and qa roles.

Go to Common - > Request Data -> Update Request Status. Search and open request SCR/2010/007.
The current status is “Pending Approval”.

The “Approved” and “Rejected” radio buttons are not greyed out under IV Approval Authority, even
though qa1_test is not the correct approving party (user is neither Admin11 nor holds Admin Role).




It is possible to select the “approved” radio button, add comment and save for approval.




                                          Page 11 of 17
Confidential – PulseSecure Pte Ltd




The submission to save the request for approval is accepted. Search for request SCR/2010/007, the
status is now “Approved”.




Implications
Users with access rights to Update Request Status function can approve or reject any requests, even if
they are not the approval authorities.

                                         Page 12 of 17
Confidential – PulseSecure Pte Ltd


This function is currently not in use but the application team will be fixing the vulnerability, in case it is
required in the future.

Recommendations

Include checks to verify if user is authorised to approve or reject the requests.

Just greying out the radio buttons is not sufficient, as the parameter values in the HTTP request could be
modified by attackers. Validation checks must be performed at the server side.

Follow-Up (to be completed by Customer)
Have you applied any remedy?            YES / NO
If YES,    Please state the date you    (DD/MM/YY)
           have applied the remedy.
           Please explain the
           remedy/solution/mitigation
           you have applied.
If NO,     Please state the reason.     Changes will be done in next quarter as the risk
           (or any form of existing     implication is low since this function is not in used
           mitigation already in-place) by authorized NRDO users.
           Please state an estimated    (DD/MM/YY)
           date you plan to apply the   30/03/2011
           remedy.
Follow-Up Review (to be completed by Assessor)
Vulnerability fixed?
Review Date:
Review Details:




                                             Page 13 of 17
Confidential – PulseSecure Pte Ltd



Ref:             Vulnerability Description: Sensitive information is cached
NRDS-05
                         Filename/Function: Multiple functions
                                                                          Likelihood: Low
              Risk Rating and breakdown:                Low
                                                                               Impact: Medium
Details

The application does not restrict caching by web browser for most pages. Some of these cached pages
may contain sensitive information (e.g. medical information, login ID, reset password question/answer).

Examples




ID/username are hashed but other patient particulars and medical information is still retrievable.




                                           Page 14 of 17
Confidential – PulseSecure Pte Ltd




Implications

Sensitive information (e.g. medical information, login ID, reset password question/answer) can be
retrieved from the cached pages by other users who have access to the computer.

Recommendations

The application should explicitly set the no cache setting for pages that contain sensitive information.

The best way is to set HTTP header with: 'Pragma: No-cache', 'Cache-control: No-cache' and 'Cache-
control: No-store”.

Alternatively, this can be set in the HTML header by:
<META HTTP-EQUIV='Pragma' CONTENT='no-cache'>
<META HTTP-EQUIV='Cache-Control' CONTENT='no-cache'>
<META HTTP-EQUIV='Cache-Control' CONTENT='no-store'>

Follow-Up (to be completed by Customer)
Have you applied any remedy?            YES / NO
If YES,    Please state the date you    (DD/MM/YY)
           have applied the remedy.
           Please explain the
           remedy/solution/mitigation
           you have applied.
If NO,     Please state the reason.     There’s no risk implication as the cache medical info
           (or any form of existing     does not contain identifiable data like NRIC, Name,
           mitigation already in-place) Contact address or number. Other information like
                                        login ID, password reset question/answer in cache
                                        pages has no risk implication as this is an online
                                        Intranet application and is only accessible within
                                        NDRO work area and NRDO work area is only
                                        accessible by NRDO staff. Furthermore, all the PCs
                                        and laptops in NRDO work area are password
                                        protected, so non NRDO users would not have
                                           Page 15 of 17
Confidential – PulseSecure Pte Ltd


                                             access to the machines.
            Please state an estimated        (DD/MM/YY)
            date you plan to apply the
            remedy.
Follow-Up Review (to be completed by Assessor)
Vulnerability fixed?
Review Date:
Review Details:




                                         Page 16 of 17
Confidential – PulseSecure Pte Ltd


                                End of Report




                                     Page 17 of 17

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:2/3/2013
language:Latin
pages:17