Temp Web 939 Report L3 26 Aug 2011 TechM

Date: 26 Aug 2011

Web Application SecurityWeb Application Security AuditAudit

ReportReportForFor

((http://tempweb939.nic.in))((http://tempweb939.nic.in))

SubmittedBy:

E-Security Consulting GroupTECH MAHINDRA Ltd. India

Level: 3

http://tempweb939.nic.in/


Web Application Security Audit Report

All information contained in this document is confidential and proprietary to Tech Mahindra and

Cyber Security Division of NIC. Reproduction, disclosure or use of any information contained in

this document by photographic, electronic or any other means, in whole or part, for any reason

other than for the purpose of operations / network security enhancement of Cyber Security

Division of NIC internal review is strictly prohibited without written consent.

Tech Mahindra shall assume no liability for any changes and omissions in this document. All the

recommendations are provided on as is basis and are void of any warranty expressed or

implied. Tech Mahindra is not liable for any damages financial or otherwise arising out of

use/misuse of this report by any current employee of NIC or any member of general public.

Page 2 of 27 Confidential: For NIC

DISCLAIMER


DOCUMENT NAME Report: Web Application Security Audit of

((http://tempweb939.nic.in) () (http://tempweb939.nic.in))

ABSTRACT This document contains findings and recommendations for

((http://tempweb939.nic.in) () (http://tempweb939.nic.in))

REFERENCE Purchase order/ SOW released by NIC (Phase-14)

VERSIONSTART

DATE

END

DATE

PREPARED

BYCOMMENTS

1.0 24 Aug 2011

26 Aug2011

Ashish Bajpai Level 3

Auditors Ashish Bajpai

Approved and Signed By Manoj Gilra

Document Classification: Confidential

Report Submitted to:

1. Ms Anjana Choudhary 2. Ms. Ratnaboli Ghorai Dinda

3. Mr. Rajesh Mishra 4. Ms. Snigdha Acharaya

Cyber Security Division

of

NIC


Document Control

Table of Contents






Serial No Topics Page No

1. Introduction 5

1.1 Background 5

1.2 Objective 5

1.3 Scope 5

2. Audit Summary 6

2.1 Business Risk 6

2.2 Application Vulnerabilities 7

2.3 Top Ten OWASP Vulnerabilities 8

2.4 Audit Recommendation 9

3. Information Gathering and Findings 10

4. Details of Observations and Recommendations 14

5. Action Items 19

6. Tools / Methodology used 20

7. Technical Risks 21

8. Appendix A – TechM Approach and Methodology 22

9. Appendix B – Glossary of Terms and Abbreviations 23



1.1 Background

Tech Mahindra Limited conducted a Web Application Security Audit based on the requirements

specified by Cyber Security Division of NIC. The security audit team, from TechM’s Security

Engineering Group, conducted Web Application Security Audit of the NIC’s Website. The project

was executed onsite, to test the various security safeguards and technical controls of the web

applications that form part of NIC. TechM is pleased to present the outcome of its findings and

recommendations in this Report.

A statement of work (SOW) document was discussed and signed between Cyber Security

Division of NIC and Tech Mahindra before commencement of this engagement which defined

the scope of engagement, objectives and TechM’s approach and methodology for the

engagement.

1.2 Objective

The objectives of the Web Application Security Audit were to test the web application security

posture of NIC as per Industry standards (Open Web Application Security Project OWASP model),

identify what vulnerabilities may exists and make recommendations on how the security of NIC

web application can be improved.

1.3 Scope

The tests were based on criteria jointly agreed between NIC Cyber Security Division and Tech

Mahindra (refer to the SOW given by NIC dated: Phase-14). The scope of auditing includes the

following:

Identifying security vulnerabilities of each web application provided by NIC for

auditing.

Provide recommendation for the fixing up the vulnerabilities.


1. Introduction


2.1 Business Risk

Overall the audit objectives were achieved. ((http://tempweb939.nic.in) ) ((http://tempweb939.nic.in) ) website was audited against accepted industry best practice with regards to business security with a focus on the technical aspects.

S.No

.Risk

1. Improper Error Handling

2. Email Harvesting


2. Audit Summary




2.2 Application Vulnerabilities

Below is a summary of the application vulnerabilities of audit level 3 of ((http://tempweb939.nic.in) () (http://tempweb939.nic.in) ) for more detail please refer to the section Details Observation and Recommendations.

S.No.Level 3

VulnerabilitiesRisk Rate

Audit

Recommendation

1. Improper Error Handling medium Immediate action to

be taken

2. Email Harvesting Low Immediate action to

be taken

2.3 Top Ten OWASP Vulnerabilities





The web application security audit was conducted on the basis of Open Web Application Security Project (OWASP). OWASP has rated top ten vulnerabilities and which has been compared with the (((http://tempweb939.nic.in) () (http://tempweb939.nic.in))

S.No. Vulnerabilities Level 3

1. Un-validated Input safe

2. Broken Access Control NA

3. Broken Authentication and Session Management

NA

4. Cross Site Scripting (XSS) Flaws

Safe

5. Buffer Overflows safe

6. Injection Flaws Safe

7. Improper Error Handling Unsafe

8. Insecure Storage NA

9. Denial of Service safe

10. Insecure Configuration Management

NA

OWASP 2007 vulnerabilities

11. Cross-site Request Forgery NA

12. Remote file execution NA





2.4 Audit Recommendation

The results from this web application security audit clearly give evidence indicating that appropriate security methodology and industry accepted web application security best practice has not been followed for the ((http://tempweb939.nic.in) () (http://tempweb939.nic.in))

Note: All the tests for ((http://tempweb939.nic.in) ) were performed on the server

((http://tempweb939.nic.in). ). It is recommended to go for vulnerability assessment audit

for Operating Systems and Third party software for the Production Server / Hosting

Server.







Site Structure

http://tempweb939.nic.in http://tempweb939.nic.in/index.phphttp://tempweb939.nic.in/index2.php (same result as index.php)

http://tempweb939.nic.in/index.php?option=com_content&view=frontpage&Itemid=1 Note:- value of parameters—option, view and Itemid are dynamic. http://tempweb939.nic.in/index.php?option=com_content&view=category&layout=blog&id=6&Itemid=2 Note: - value of parameters—option, view, layout, id and Itemid are dynamic.

http://tempweb939.nic.in/index.php?option=com_content&view=article&id=6:ms-kiran-mazumdar-shaw&catid=6:members&Itemid=2 Note: - value of parameters—option, view, catid, id and Itemid are dynamic

http://tempweb939.nic.in/index.php?format=feed&type=rss http://tempweb939.nic.in/index.php?option=com_acajoom http://tempweb939.nic.in/index.php?option=com_xmap&sitemap=1&Itemid=27

Out of scopehttp://www.joobi.co/ google.com facebook.com twitter.com

(Confirm us that all the urls/links given above are correct and no other urls/links are left from crawling.)


3. Information Gathering Findings

http://www.joobi.co/

http://tempweb939.nic.in/index.php?option=com_xmap&sitemap=1&Itemid=27

http://tempweb939.nic.in/index.php?option=com_acajoom

http://tempweb939.nic.in/index.php?format=feed&type=rss

http://tempweb939.nic.in/index.php?option=com_content&view=article&id=6:ms-kiran-mazumdar-shaw&catid=6:members&Itemid=2

http://tempweb939.nic.in/index.php?option=com_content&view=article&id=6:ms-kiran-mazumdar-shaw&catid=6:members&Itemid=2

http://tempweb939.nic.in/index.php?option=com_content&view=category&layout=blog&id=6&Itemid=2

http://tempweb939.nic.in/index.php?option=com_content&view=category&layout=blog&id=6&Itemid=2

http://tempweb939.nic.in/index.php?option=com_content&view=frontpage&Itemid=1

http://tempweb939.nic.in/index2.php

http://tempweb939.nic.in/index.php



Site Structure





http://tempweb939.nic.in/modules/mod_gk_tab/scripts/importer.php


http://tempweb939.nic.in/modules/mod_gk_tab/scripts/importer.php


(Confirm us that all the urls/links given above are correct and no other urls/links are left from crawling.)



4.1 Improper Error Handling

Description: Information gathering is the starting phase before launching an attack on a web

application. Good policy is to disclose less information to the attacker. The more information

released through error messages, target will appear more vulnerable.

Risk Rating: Medium

Recommendation:


4. Details of Observations and Recommendations


1. Server side validation is MANDATORY. All data coming from the user end should be

cleansed before submitting it for processing.

2. Client side validation should also be included as it will minimize the sanitizing time at the server.

3. Customized error messages should be displayed. Messages coming from the server end

should not be disclosed to the visitors of the website. They need not know about

Database errors.

4. All input data coming from user from input fields (option box, check box, combo box,

etc.) should be validated before sending data to SQL Server.

NOTE: PROVIDE CUSTOMIZE ERROR PAGE FOR ERROR HANDLING

4.2 Email Harvesting

Description: E-mail harvesting is the process of obtaining lists of e-mail addresses using various methods for use in bulk e-mail or other purposes usually grouped as spam.



Risk: Low

(Remove the vulnerability from all the other places also)

Recommendations:1. Use Address munging—e.g., changing "[email protected]" to "bob at example dot

com"—is a common technique to make harvesting email addresses more difficult. Though relatively easy to overcome—see, e.g., this Google search—it is still effective. It is somewhat inconvenient to users, who must examine the address and manually correct it.

2. Using images to display part or all of an email address is a very effective harvesting countermeasure. The processing required to automatically extract text from images is not economically viable for spammers. It is very inconvenient for users, who must manually launch their email client and transcribe the address

4.3 Other Observation:

1. Remove all the links/URLs which are not used in the application.



Admin page

(Remove the link if it is not in use)

Dirs found with a 200 response:

/images/

/media/

/templates/

/icons/

/modules/

/plugins/

/includes/

/language/

/components/



/cache/

/libraries/

/logs/

/tmp/

/

/administrator/

/images/banners/

/images/stories/

/images/smilies/

Files found with a 200 responce:

/configuration.php

/index.php

/index2.php

2 When user is selecting the subscription option and submits there details request forward to

some mail id (as shown below)

3. While accessing the page below link appears in the page also



Based on findings above, following is the list of action items that this application must perform:


5. Action Items


Ensure a custom error page is displayed for all type of errors.

Implemented recommendations to stop email harvesting

Tools Used:

1. Burp proxy

2. TamperIE HTTP Data Manipulation tool


6. Tools / Methodology Used


Methodology:

OWASP (Open Web Application Security Project) & TechM Web Application Security Testing

Methodology.



Improper error handling

Email Harvesting possible


7. Technical Risks


Base Approach

For the purpose of executing this engagement, the TechM security testing team adopted the

following base approach:

1. Identify key areas of vulnerability, including but not limited to, authentication and access

control mechanisms, input validation, data sharing violations, privilege escalation, and

session hijacking.

2. Attempt to exploit potential vulnerabilities and determine the extent of unauthorized

access obtained via those vulnerabilities.

3. Examine third-party products supporting the application for existence of any known

vulnerabilities that could lead to a compromise. These third-party products included

Microsoft Windows 2000, Microsoft IIS 5 and component products or technologies

bundled therein.

4. Perform supplemental research and development activities to support analysis.

5. Demonstrate and Prioritize vulnerabilities based upon the ease of exploit, required effort

to remediate, and severity of impact to business operations if exploited.

Methodology

After a walkthrough of the business logic and functionality of APPLICATION from the

development team, the TechM security testing team constructed a custom methodology

utilizing the Open Source Security Testing Methodology Manual’s (OSSTMM) Internet application

security testing framework, the Open Web Application Security Project (OWASP) and NIST

guidelines. Specific elements tested for within the target application were as follows.

1. Communication protocol

2. Authentication

3. Authorization

4. Session Management

5. Data Validation

6. Error Handling

7. Logging

8. Server Side Security


8. Appendix A - TechM Approach and Methodology


9. Database Security

The framework is based on guidelines set by the OWASP (Open Web Application Security Project) and tests were performed according to the OWASP methodology.

Risk Rating

Vulnerabilities identified have been classified based on the ease with which the vulnerabilities

can be exploited through commonly available exploits. The risk ratings for the identified

vulnerabilities have been classified on the following criteria:

Info: Information about a host that does not represent a security threat. However, some of the

information could be used to assess the security of the device, host, or network at large.

Low: Low-risk vulnerability is typically one that only presents a threat in specific and unlikely

circumstances. Such vulnerability may provide an attacker with information that could be

combined with other higher-risk vulnerabilities, in order to compromise the host or its users.

Medium: Medium-risk vulnerabilities are serious security threats that would allow trusted but

non-privileged users to assume complete control of a host, or would permit an un-trusted user

to disrupt service or gain access to sensitive information.

High: High-risk vulnerabilities would allow a user who has not been given any amount of trust

on a susceptible host to take control of it. Other vulnerabilities that severely impact the overall

safety and usability of the network have also been designated as high-risk.



DoS Attack: A Denial of Service (DoS) attack is a remote attack against a servers TCP/IP stack

or services. DoS attacks can saturate a server’s bandwidth, saturate all available connections

for a particular service, or even crash a server.

Exploit: A script or program that takes advantage of vulnerabilities in services or programs to

allow an attacker to gain unauthorized or elevated system access.

Port: A port in the network sense is the pathway that a computer uses to transmit and receive

data. As an example, Web Servers typically listen for requests on port 80.

Service: A service is a program running on a remote machine that in one way or another

provides a service to users. For example, when you visit a website the remote server displays a

web page via its web server service.

Vulnerability: A weakness or a flaw in a program or service that can allow an attacker to gain

unauthorized or elevated system access.

OWASP: Open Web Application Security Testing Project. For more details visit www.owasp.org.

NIST: National Institute of Standards and Technology. For more details go to www.nist.gov

OSSTMM: Open Source Security Testing Methodology Manual. For more information go to

www.isecom.secure.netltd.com

Hidden Field Manipulation: Unsafe passage of information to CGIs.

Example: Hidden fields are often used to save information about the client's session, without

having to maintain a complex database on the server side. The client does not normally attempt

to change the hidden field, or even see it, but, as we have shown, modifying fields is very

simple.

Parameter Tampering: Failure to confirm correctness of CGI parameters embedded inside a

hyperlink.


9. Appendix B - Glossary of Terms and Abbreviations

http://www.owasp.org/


Example: Application use template files to show pages. The function that is used to process the

template receives the template filename as a parameter. This method is useful when there are

common procedures to apply to all retrieved pages. However, by tampering with the name of

the template, a hacker can obtain access to any file he/she wishes.

Stealth Commanding:

Example: A perl script that performs an “eval” method with some of the user’s input may be

vulnerable to this kind of attack. A hacker can plant his/her own commands inside the “eval”

code. Executions in the web-server, such as “eval” and “system” Perl commands, server-side

includes, and SQL queries enable hackers to plant Trojan-horses using form submissions and

run malicious or unauthorized code on the server.

Forceful Browsing:

Example: Some applications do not force a certain browsing order on the client, as this would

require keeping track of user’s sessions. A hacker may exploit this security hole, and “jump”

directly to pages that can normally be accessed only through authentication mechanisms.

No actual enforcement of application logic.

Cross-Site Scripting:

Example: A search feature that returns the string to be searched as part of its response without

validating user’s input may be vulnerable to Cross-Site Scripting attacks. A malicious hacker

may take advantage of such scripts to retrieve sensitive user information such as cookies.

In general, Cross-Site Scripting is the process of inserting code into pages sent by another

source. One way to exploit cross-site scripting is through HTML forms. Cross-Site Scripting

would potentially enable a malicious user to introduce executable code of his choice into

another user’s web session. Once the code was running, it could take a wide range of actions,

from monitoring the user’s web session to stealing session tokens of a valid user and sending

them to the attacker.

Buffer Overflow:

Example: A script in a site copies user input into a buffer of a pre-defined size. If the user sends

a longer input than expected, a buffer overflow occurs and the web server's application stack

becomes corrupted. If the stack is corrupted with the appropriate data, the hacker can run any

program on the web server's machine.

Known Vulnerabilities:



Example: Vulnerabilities such as Nimda and Code-Red are excellent examples for known

vulnerabilities. These two vulnerabilities allow hackers to take over vulnerable versions of web

servers. Known vulnerabilities include all bugs and exploitable holes in the OS, web server,

application server and other 3rd party components that have been published or are generally

known. Most of these vulnerabilities have existing patches. Hackers often exploit systems that

fail to install the patches in a timely fashion.

3rd Party Mis-configurations: Mis-configuration of vendor software:

Example: Some web-servers are configured to permit directory browsing, whether by mistake or

on purpose. Hackers can utilize this feature in order to browse the application's directories and

acquire sensitive information regarding its structure and possible security flaws.


Documents

Temp Web 939 Report L3 26 Aug 2011 TechM