Page 1

February 2013 | Page - 1

February 2013 | Page - 2

Content-Type Attack: Dark Hole in a Secure Environment

Introduction Content-Type attacks are related to the vulnerabilities in client side software that are used to read the content like adobe reader, Microsoft office, Image viewer. Attackers attempt to exploit programming flaws in that code to induce memory corruption issues, resulting in their own attack code being run on the victim computer that opened the PDF or DOC file. Content-Type attack is Dark Hole in a secure environment due to following reasons: 

Un-detective Nature: There are multiple types of attack e.g. crosssite scripting, SQL injection, DNS cache poisoning, HTTP tunneling etc. Though there are multiple devices like WAF (Web Application Firewall), IPS (Intrusion Prevention System) that can be used to detect and prevent these attacks, it's

difficult to detect contenttype attack. Ignorance: Most of the penetration testing assignments focus on webapplication testing and some are for critical servers in the infrastructure. But very rarely organizations focus on the workstation in the environment. Even if the organizations look for workstation related vulnerabilities and patches, it is still limited to Windows or any other critical application running in the environment. Last, if any organization looks into vulnerability of content reading software then 0day attacks cannot be avoided without any other preventive measurements. False sense of Security: When we talk about security of any environment components like firewall, IPS, IDS, Anti-Virus comes first in the mind. But having these components does not mean that environment is completely secure. It also required best configuration of these component as well as other components in the environment like Proxy Server, outbound policy at internet gateway etc.

February 2013 | Page - 3

Content-Type Attack Process: 

This attack document is sent by an attacker to a victim, perhaps using a compromised machine to relay the e-mail to help conceal the attacker’s identify. If the victim opens the file attached to the e-mail, the application registered for the file type launches and starts parsing the file.

written and run, the attacker’s code writes out a “clean file” also contained in the attack document and opens the application with the content of that clean file. In the meantime, the malicious EXE file that has been written to the file system is run, carrying out whatever mission the attacker intended. Malicious Content-Type Attack Document Structure A malicious document is combination of multiple components that is used by attacker to compromise any victim machine. Following are the different components.

In this malicious file, the attacker will have embedded malformed content that exploits a file-parsing vulnerability, causing the application to corrupt memory on the stack or heap. Successful exploits transfer control to the attacker’s shell code that has been loaded from the file into memory. The shell code often instructs the machine to write out an EXE file embedded at a fixed offset and run that executable. After the EXE file is

 Vulnerability: This code is used by attacker to exploit the vulnerability of the content reading software. After successful exploitation control gets transfer to shellcode part of the document. ShellCode: This part of document is used by attacker for post exploitation activity, which can vary from executing binary file, downloading malicious file, installation of key-logger, reverse tunnel to attacker controlled server and many more.

February 2013 | Page - 4

reader, i.e. you have to download Adobe Acrobat 5.0 to view %PDF-1.4.

 PDF Body: The body of a PDF file consists of objects that compose the contents of the document. These objects include image data, fonts, annotations, text streams and so on. Users can also integrate invisible objects or elements. These objects embed the interactive features in a document like animation or graphics. A user can also implement logical structure in the document. You can also make the content of a PDF document more secure by implementing security features. One can protect the content of a document from unauthorized printing, viewing, editing or modifying. The body of a PDF also supports two types of numbers called integers and real numbers.

Embedded binary code: Embedded binary code is the executable code that attacker wants to execute on victim machine as part of post-exploitation activity. Clean Document within context: This part is used by attacker to clean the evidences or to cover the attack vector.

PDF File Analysis This part includes brief about PDF file structure, PDF file format and different objects which are interest of attacker as well as for analysis of PDF file. Also analysis of PDF using python based scripts. PDF file structure: PDF file is divided into four main parts - PDF Header, Body, Cross-Reference table and Trailer. 

PDF Header: The first line of the PDF specifies the version of a PDF file format. These headers are the topmost portion of a document. It reveals the basic information of a PDF file, for example, "%PDF-1.4"; it means that this PDF format is the fourth version. By the way, to read a PDF, you need a later version of PDF

The Cross-Reference Table: The cross-reference table consists of links to all the objects or elements in a file. You can deploy this feature to navigate to other pages or content in a document. When users update

February 2013 | Page - 5

their PDF files, they will automatically get updated in the cross-reference table. One can also trace the updated changes in the cross-reference table. The Trailer: The trailer contains links to cross-reference table and always ends up with "%%EOF" to identify the end of a PDF file. The "%%EOF" is necessary for a PDF file, if this line missed, the PDF-file is not complete and may not be processed correctly. This is not same as PostScript files. If the last few lines of a PostScript file missed, you will still print most of the pages. For a PDF file, you lose everything. The trailer enables a user to navigate to the next page by clicking on the link provided.

PDF file format PDF file format use Post-Scripting language to describe a PDF file. In which one object contains reference of other objects and form a tree like structure as shown below.

In the body (the object list), there are following different kind of definitions: 

Indirect reference (n r R): References an object, e.g. 5 0 R. If the objects doesn't exist this is equivalent to the Null object (see below). Name (/Name): Names are identifiers. If you know Lisp or Scheme, this is similar to the quote special form (e.g. 'ok). The initial / introduces the name but isn't part of the name; this is similar to $ in Bash, Perl or PHP.

February 2013 | Page - 6

 

Dictionary (<< ... >>): This is an unordered list of (Name, Object) pairs. They are essentially hash tables. The Object part can be another Name (e.g. /Type /Font). Array ([x y z ...]): an ordered list of objects, e.g. [0 0 200 200]. String Object ((text)): text. The complete syntax is complex, but for now suffice to say it's text between parenthesis, e.g. (Hello, world!). Stream (<< /Length ... >> stream ... endstream): Embedded data can be compressed. It starts with a dictionary that describes the stream such as its length or the encoding (/Filter) is uses.

PDF File analysis using scripts Multiple scripts are available publically to analyze PDF file. For demonstration purpose I will use and scripts developed by Didier Stevens. PDF analysis using This tool will parse a PDF document to identify the fundamental elements used in the analyzed file. It will not render a PDF document.

The stats option display statistics of the objects found in the PDF document. Use this to identify PDF documents with unusual/unexpected objects, or to classify PDF documents. The search option searches for a string in indirect objects (not inside the stream of indirect objects). The search is not case-sensitive, and is susceptible to the obfuscation technique. filter option applies the filter(s) to the stream. For the moment, only FlateDecode is supported. The raw option makes pdf-parser output raw data. OBJECT outputs the data of the indirect object which ID was specified. This ID is not version dependent. If more than one object have the same ID (disregarding the version), all these objects will be outputted. reference allows you to select all objects referencing the specified indirect object. This ID is not version dependent. type allows you to select all objects of a given type. The type is a Name and as such is case-sensitive and must start with a slashcharacter (/).

February 2013 | Page - 7

PDF analysis using This tool is not a PDF parser, but it will scan a file to look for certain PDF keywords, allowing you to identify PDF documents that contain (for example) JavaScript or execute an action when opened. PDFiD will also handle name obfuscation.

PDFiD will scan a PDF document for different type of objects as shown in the below snapshot and count the occurrences (total and obfuscated) of each word. 

Protection Measure Against Content-Type Attack Following are the few protection measure that can be used to protect the environment.

Security update: All the security updates must be available, which can prevent from exploitation of all vulnerabilities except 0-day attack. 0-day attack can be avoided by use of other protection measures. Java script in Adobe reader: Java Script is used for automation of some task in PDF e.g. calculation, form filling etc. But attackers use the same for some malicious activity. So Java Script should be disabled in PDF and should be enabled only if required. DEP implementation: DEP (Data Execution Prevention) prevents execution of code in non-executable area. Attacker usually tries to overflow the buffer to execute the code in non-executable area. So DEP should be enabled and if required it should be enabled for trusted application. Security Awareness: Security awareness related to emails & attachments can prevent contenttype attack. This awareness should motivate employee to submit attachment from un-trusted source for analysis purpose. White-list based proxy: Internet proxy can be implemented in two ways. First black-list based which prevent access to some of the URL's like Facebook, Gmail etc. Second white-list based which grant access to only allowed URL's. White-list based proxy implementation can prevent from post exploitation activity where attacker wants victim to connect to malicious websites. Strong outbound firewall policy: Strong firewall policy both for inbound and outbound traffic

February 2013 | Page - 8

also prevents from post exploitation activity where attacker's post exploitation code tries to open reverse channel from victim to attacker controlled machine as shown in Content-Type attack process diagram. Every organization should implement maximum of the protection measure to secure the environment from Content-Type Attack.

References    ams/pdf-tools/ /pdf-file-structure.html n_to_PDF

Raman Gupta Raman Gupta works in TCS as Information Security consultant. His work area includes vulnerability assessment, penetration testing and secure configuration of network. Raman is also interested in reverse engineering and exploit writing.

February 2013 | Page - 9

GRC – An introduction Usually when one talks about Information Security audit, governance, risk management, compliance and such topics it is dubbed “management-speak” and wished away by hacker community members. It worked the same way for the management people too who wished away the geeky types who could bang a keyboard at the speed of light or “go where no one had been before”. Times are a changin’ and the twain are set to meet. Yes, over the years, the ethical hacker has realized that he/she has to learned that report writing is as much a difficult skill as finding a 0-day and claiming a 100k prize (ok not as difficult but maybe equivalent to a 50k prize ). While the hacker community was learning the difference between an Executive Summary and a Summary and the necessity of running a spell and grammar check before closing a document (oh oh! don’t forget you need to have a standard font through and also font size)… ok while the community was learning these subtle differences, the management and auditor types started brushing up on their

knowledge about tools, exploits, ports, networks, vulnerabilities, remediation and more. While CH Mag has been fulfilling the need for the non-techie to learn and understand the techie’s hackie thought process, there has been a gap in terms of providing the techie with non-techie knowledge and skills. And, this is now due for change with the new section on GRC et al starting off with this issue. I have the privilege of penning this kickoff piece and will spend the remaining bytes walking you into the bright world of audit, risk and compliance. Fundamentally, everyone is on the same team and doing the same work, except that the methods vary. The ethical hacker goes blind into a system, runs tools / exploits, uses his/her knowledge of IT infrastructure to discover weaknesses and then presents findings along with the solution for closing the vulnerabilities. In the same manner, an auditor too goes blind into the organization and calls for evidence that will prove that the organization is complying with the policies they have formulated – he/she will use his knowledge and skills to dig into

February 2013 | Page - 10

documents and systems and will do a good bit of mind reading and body language analysis to discover weaknesses in the processes and technologies which will be reported along with suggestions for closure of the same.

requirement of the auditor too! He/She, as an information security professional has to understand and know about all the areas mentioned above, plus all those that are not mentioned. And of course, report writing is an integral part of the profession itself.

In effect – the same work (assessment, testing, analysis…); the same goal (information, IT, data, security…); work done at the same place and the same deliverables submitted (soft copy and hard copy of the report with remediation).

A GRC (Governance, Risk, and Compliance) professional is an information security practitioner and may be working as a CISO (Chief Information Security Officer), an IS Manager, or Auditor in an organization. Other roles may be that of Change Manager, Incident Manager, Risk Manager etc.

For the sake of simplicity, we shall call this the GRC domain while the techie domain may be referred to as Hackers. Enough said, and we move on to know more about this specialization in Information – certifications are aplenty and some carry a strong reputation while some are around. Some of the most well-known certifications are CISSP, CISA, CISM, ITIL, ISO27001 Implementation, ISO27001 Lead Auditor, BCP, CIA, CRISC, CGEIT, CFE, C|CISO, DISA, CIPP, ABCP, CBCP and many others covering various specializations. These professional certifications usually require the person to have a few years of work experience then qualify by passing an examination. The areas of specialization and experience will be in IT Audit, systems audit, risk management, business continuity, disaster recovery, governance, compliance, asset management, data center audits, IS management, ISMS implementation, metrics management and much more. We usually bundle all these specialist areas of work under the single label of GRC or IS / IT Auditor which may seem to be incorrect but, in a different manner, it is representative of the knowledge

The fundamental attributes that drive the profession are the principles of Confidentiality, Integrity and Availability of IT for running the business and as applied to People, Process and Technology using ‘controls’ or ‘rules’. As one starts on the GRC practice the first thing one is usually asked for is a Gap Analysis or a Risk Assessment. The gap analysis is just that – an analysis of the area of investigation and discovery of the gaps so it is a VA but carried out on processes and not on systems. A Risk Assessment is a more critical activity because it is not something which is done and then on an annual basis but more dynamic as it has to be made part of the overall organization culture - this is critical to the success of any Information Security program in an organization. In fact a VA/PT or AppSec is usually termed as a Technical Risk Assessment and is usually carried out as a result of a risk or gap assessment. While implementing Information Security in any organization the team carries out a Risk Assessment and identifies risk areas along with the path and strategy for mitigation. Risks are identified in respect of

February 2013 | Page - 11

current practices and processes, technologies deployed in the infrastructure, people related policies and practices, assets etc. The mantra followed by all mature organizations, and advised by all Information Security Auditors / practitioners / consultants is that all controls and policies should be risk based. In effect this means that any new control or asset must be deployed once a proper risk assessment has been carried out. A thorough risk assessment will identify threats, vulnerabilities, challenges, issues relating to the process in terms of the environment and working and the organization management will be able to take informed decisions for the same. Risk values can be quantitative or qualitative – which means that it can be expressed as a number or stated as ‘high’, ‘medium’, ‘low’ or in one’s own terminology as it is a gut feel. The most basic formula is risk = impact * probability – where impact or probability can be a number on a defined scale. These inputs are received from the asset stakeholders by the Risk Assessor based on specific interactions and informed questioning. This is a very basic introduction to risk assessment and this is a very big area of specialization. Risk managers carry huge responsibilities in their organizations and they depend on much more than this basic formula. Needless to say this will be an important topic that will be carried in future issues and hope you will gain a deeper understanding which you can apply to your work too and benefit.

ISO27001, CoBIT etc. and provide organizations with the necessary direction, guidance and controls for effective information security and management.

Dinesh O Bareja Dinesh is an Information Security professional specializing in security strategy, architecture design and operations. He is an Advisor to Cyber Defence Research Centre (Special Branch, Jharkhand). He also leads the Indian Honeynet Project.

Elements of GRC, like governance, risk management, gap analysis, change management and others are based on best practices and standards like ITIL,

February 2013 | Page - 12

HAWAS – Hybrid Analyzer for Web Application Security

parameter guessing etc. When a part of the test is boring and time consuming then testers usually tend to skip it or not do proper justice to it. Needless to say this can turn out to be very dangerous for the site’s security.

Penetration testing is more than just running automated tools and redoing the same manual testing workflow. It is about analyzing the target, understanding how it is built and coming up with unique attack scenarios.

HAWAS is a tool designed to help testers in these areas. It will help perform automatic analysis of the site and provide data in an easily consumable form so that you can identify patterns and map connections. It also helps automate tests for CSRF, Privilege Escalation, Access Control and Hidden Parameter Guessing, these tests would otherwise take up a lot of manual effort and time.

When you are testing a web application of even moderate size then the amount of pages, parameters and values travelling between the browser and the server can become overwhelming even for seasoned testers. Finding patterns or mapping connections in a maze of data is not a trivial task.

HAWAS is built as a Module for IronWASP and is bundled along with it. To use HAWAS you must first start IronWASP, configure your browser to use IronWASP as the proxy and then browse through the target site. This way IronWASP will collect all the site information in its proxy logs. Once the entire site is covered you can launch HAWAS from the ‘Modules’ menu, it will be available under the ‘Analysis’ category.

Another problem arises when you have to do a technically simple check repeatedly for a large number of times. For example, checking for CSRF vulne-rabilities across the site is a very simple but time consuming and I must say also a very boring process. The same is true for privilege escalation checks, hidden Figure 1 - Launching HAWAS from the Modules menu

February 2013 | Page - 13

Once HAWAS is started up, just click on the ‘Start Analysis’ button, this will start the analysis of the data collected in the Proxy Logs. Depending on the size of the log this analysis could take anywhere from a minute to a significantly longer time. Once the analysis is complete click on the ‘Show Results’ button.

see the sections in which this parameter was found, E.g. Query, Cookie etc. When you click on a particular section you can see the list of all the values this parameter had when it occurred in the selected section. This section is of great important as it lists all the information about the site in one single location, in an easily analyzable way.

Figure 2 - HAWAS has been launched, click ‘Start Analysis’ to begin

Figure 3 - HAWAS is analyzing the Proxy logs

Figure 4 - Analysis is done, click on ‘Show Results’ to view the results

The results section has multiple tabs, let’s look at them one by one.

Let’s look at some scenarios where this can come in handy.

Parameter Names and Values

In the list of parameters if you see a parameter named ‘is_admin’ then you will immediately agree that this is worth exploring. Maybe this parameter is used to decide if you must be shown the admin page or not, you could try manipulating this parameter manually and probe further. If this parameter appeared only once in the entire site then without HAWAS it is very likely that you could have missed this.

The first tab lists information about all the parameter names and values discovered in the logs. This information is categorized by hostname. The list of hostnames found in the log are shown on the left-side of this tab. When you click on a hostname you can see the list of all parameter names found in the logs related to that hostname. When you click on any of the parameter names you can

February 2013 | Page - 14

Let’s say there is a parameter named ‘SessionId’ and this parameter contains the session id for the application. When you click on this parameter name HAWAS will tell you which sections this parameter occurred in. If it only occurs in Cookie then its fine but if it occurs in Query as well then you have a problem because passing Session id over Urls is not safe. Out of a 1000 pages the application might have sent the session id over url in just one page but HAWAS still picks it up and makes this very obvious to you. Without HAWAS this could have most likely been lost in the noise.

When you look at the list of all parameter values you might pick up some interesting leads. For example if there is a parameter value that looks like “” then you know that this parameter needs to be tested for Open Redirect and Remote File Include vulnerabilities. Similarly if you see a parameter value like “./lib/report.php” then this is a candidate for Local File Include testing. Sometimes you might miss noticing these items when you are crawling through the site but with HAWAS you would always notice these interesting patterns.

Figure 5 - Click on Hostname to view Parameters, click on a Parameter to view Sections, click on a Section to view Values, click on a Value to view details about the Value

February 2013 | Page - 15

Encoded Parameter Values Sometimes web applications transmit values in encoded form. The encoded value might look harmless or might look like junk but when decoded could actually be holding something sensitive. Hex and Base64 are the most commonly used encoding schemes in web applications. When there are thousands of parameters in an application it is practically impossible for a tester to determine which ones look like encoded values. HAWAS performs this task automatically. It tries to Hex and Base64 decode every single parameter value, if the result of decoding is a proper ASCII string then this is added to this section. The left-side of this tab contains the list of all hostnames that contain encoded parameter values. If you click on any of the

hostnames then the encoded value, the type of encoding and the decoded values are displayed. HAWAS makes it almost impossible to miss these types of encoding in the application (Fig. 6). Hashed Parameter Values Like the use of encoding sometimes applications might transmit hashed values. What could be even more interesting is often these hashed values are created from some other parameter values within the same application. For example when a user logs in with a username and password then the password might be hashed and this hashed value might be passed around in other sections of the application in some other parameter. Identifying this manually is a very difficult task but HAWAS automates this entire process.

Figure 6 - Click on Hostname to view list of Encoded values, click on an Encoded Value to view details

February 2013 | Page - 16

First it identifies all parameter values that look like MD5, SHA1, SHA256, SHA384 or SHA512 hashes. Then it uses the list of all parameter values belonging to that host as a dictionary list and tries to crack these hashes. The results are shown to the user in this section. The left-side of this tab lists all the hostnames where parameters containing hashed values were discovered. When you click on the hostname then the hashed value and the type of hash are displayed. If HAWAS was able to crack this hash then the cracked value is also displayed (Fig. 7).

an uphill task however HAWAS makes this task easy for you. HAWAS stores every single request parameter value found in the log in memory and then checks if any of the responses have this same value embedded in them. Letâ&#x20AC;&#x2122;s say Response B was found to have a parameter value that originally found in Request A then HAWAS checks if Request B also had the same parameter value. If Request B did not have this value then it is very likely that this value was sent by Request A, saved on the server-side and then reflected back in

Figure 7 - Click on Hostname to view list of Hashed values, click on a Hashed Value to view details

Stored XSS Candidates: Stored XSS are difficult to detect because in a big application it is very hard to find out which parameter values are stored on the server-side and reflected back at a later stage. Manually finding out this pattern is

Response B. This would make it an ideal candidate for Stored XSS testing. HAWAS identifies all such instances and shows them in this section (Fig. 8)

February 2013 | Page - 17

Figure 8 - Click on Hostname to view list of Stored Reflections, click on a Stored Reflection to view details

Interactive Testing


This section was originally supposed to be implemented within the HAWAS UI itself but to provide a better experience this was instead added as a core component of IronWASP.

If an application does not send a CSRF token or if it does not properly validate a CSRF token when performing an important action then it is vulnerable to CSRF.

This section provides a single area from which you can automate the testing for CSRF, Privilege Escalation, Access Control and Hidden Parameter Guessing vulnerabilities. Though these four vulnerabilities are very different the testing methodology for them is more or less similar. For the sake of those unfamiliar let me briefly explain these vulnerabilities and how to test for them. For detailed explanation on these issues please refer to the OWASP portal.

You test for this issue by picking a request that already has this token then you resend this request after deleting this token or editing it with some junk value. You compare this response with the response of the original request. If both are same then it means the application is not properly validating the token. If the responses are different then it indicates that the application had rejected this request due to an invalid CSRF token, you can confirm this by analysis exactly which section of the two responses are different.

February 2013 | Page - 18

Privilege Escalation:

Hidden Parameter Guessing:

If an application allows a low privileged user to access sections of the site and perform actions that are only meant for high privileged users then it is vulnerable to Privilege Escalation attack.

Sometimes applications have hidden backdoors because of which you might be able to access hidden functionality by adding a special parameter and value. For example if you add a new parameter ‘admin=1’ to the url then you might be able to access administrative functions of the site.

To test for it you first browser through the site as a high privileged user and then you resend the same requests but this time you set the session id as the session id of the low privileged user. If the response is similar then it means the low privileged user is able to access the same section and the application is vulnerable. If the responses are different then probably the application rejected the request of low privilege user, you can confirm this by analyzing the differences between both the responses. Access Control: Some sections of the site are only meant to be accessed after the user is logged in. But if the application allows even unauthenticated users to access some of these pages then it has Access Control issues. To test for it you first browser through the site as an authenticated user and then you resend the same requests but this time you either remove the session id or replace it with an unauthenticated session id. If the response is similar then it means the unauthenticated user is able to access the authenticated section and the application is vulnerable. If the responses are different then probably the application rejected the request of unauthenticated user, you can confirm this by analyzing the differences between both the responses.

To test for it you first browser through the site normally and then you resend the same requests but this time you add a new parameter name and value, like ‘admin=true’. If the response is similar then it means the added parameter did not have any effect on the application. If the responses are different then probably the application exposed some new functionality based on this parameter, you can confirm this by analyzing the differences between both the responses. Automating these Tests: By now you would have seen the common pattern in these tests. In all of them we edit, delete or add a parameter in the request, send it to the server and compare the new response with the old response. And based on the results of this comparison we determine if there is vulnerability or not. To automate these steps you must go to the Logs section of IronWASP. At the top-right corner of this section you can see a button named ‘Search and Analyze Logs’, clicking this button would launch the Log Analyzer. Here you can set a filter and search the logs. When the search results are displayed you can either select all the logs from the results or select only the logs you are interested in testing. After selecting, click on the ‘Test Selected Sessions’ button, this will launch the Log Tester. February 2013 | Page - 19

Figure 9 - Click on ‘Search and Analyze Logs’ to launch the Log Analysis utility

Figure 10 - Specify a log filter (File Extensions to ignore and Response Codes to include are selected here) and click on ‘Search with this Filter’

Figure 11 - Select the logs to test from the search results and click on ‘Test Selected Session’. To individually select a log entry first set the ‘Click Action’ value to ‘Select Log’ from the default value of ‘Display Log’

February 2013 | Page - 20

The Log Tester will show a wizard where you are given three test options: 1) New Parameter Addition Test 2) Edit Existing Parameter Test 3) Delete Existing Parameter Test The names of the test are self-explanatory, once you select one these tests and click ‘Next’ you will asked to enter the details of

the parameter. You must mention if it is a Query, Body, Cookie or Header parameter. After mention the type of the parameter you must mention the name of the parameter. If you selected ‘New Parameter Addition’ or ‘Edit Existing Parameter’ options then you would be asked to enter the value of the parameter also.

Figure 12 - Test Options shown, select one and click ‘Next Step ->’

February 2013 | Page - 21

Figure 13 - Enter the details of the Parameter that must be manipulated and click on ‘Start Test’

Once this is done you can click ‘Start Test’. Now IronWASP will send each of the selected requests once without making any changes, this is called as Resent Request. After this the parameter manipulation you selected will be made, be it adding a new parameter, editing an existing parameter or deleting a parameter. The edited request will be sent to the server, this is called as the Test Request. After sending these requests and getting the responses, the response details are shown to you. The results UI shows the response status code and length of the original response from the log, the status code and length of the resent response, the status code and length of the test response.

them. 0% means that the responses are the same and 100% means the responses are completely different. By looking at this information you can immediately determine if the parameter manipulation had any effect. If it looks like there was some effect you can explore it more by clicking on one of the entries, this will display the original request/response, resent request/response, test request/response and the detailed diff of these requests and responses. From one single place you can analyze and find out what where the exact differences between the responses and based on that determine if the vulnerability actually exists.

Apart from these values IronWASP also does a diff of all the three responses and shows the percentage of difference between

February 2013 | Page - 22

Figure 14 - Test Results are displayed. Click on any of the result item to view more details about it

This feature can help reduce your testing time for these tests from days to mere minutes! It can also handle complex scenarios where while testing for CSRF you would have to maintain the session. For example during the test you want to constantly check if the user is logged in to the application and perform a login if user is logged out. To handle this you can make use of the Session Plugin support built-in. When you are creating a test you will asked if you want to make use of this feature, if you choose to use it then a GUI based assistant will get the details from you and create a Session Plugin and then handle authentication or any other customization. By making use of these features you can hugely increase your test coverage while simultaneously reducing your testing time, so don’t forget to reap the benefits of HAWAS in your next pentest.

Lavakumar Kuppan Lavakumar is the author of IronWASP, the advanced Web Security Testing Platform. He has also authored many other security tools like ‘Shell of the Future’, JS-Recon, Imposter and the HTLM5 based Distributed Computing System – Ravan. He has spoken at multiple conferences like BlackHat, OWASP AppSec Asia, ClubHack, Securitybyte, Nullcon, etc. February 2013 | Page - 23

Case Study Section 66C Vinod Kaushik and Ors. V. Madhvika Joshi and Ors., Before Sh. Rajesh Aggarwal, Adjudicating Officer, Information Technology Act, 2000, Government of Maharastra, At Mantralaya, Mumbai 400032, Complaint No.2 of 2010 192 The adjudicating officer held that the act of the wife to access information from the email account of the husband without his permission is unauthorized access under Section 43 of the IT Act, 2000. It also noted that there cannot be any compensation as the wife has not published the information. She has only submitted it to the police and court. The adjudicating officer also held the wife liable under Section 66-C 193 of the IT Act for dishonestly making use of password of any other person. The main issue in this case is whether accessing husband’s and father in law’s email account without their permission amounts to ‘unauthorized access’.

In this case, the first respondent had accessed the email account of her husband and father in law, in order to acquire evidence in a Dowry harassment case. The Adjudicating Officer held that, accessing email account without authorization amounts to contravention of section 43 of the Information Technology Act, 2000. There was no compensation awarded to the complainant as the respondent has only submitted the information so obtained to the police and the court. The Adjudicating Officer, however ordered the first respondent to pay a fine of Rs. 100, as she was held to be in contravention of Section 66-C (identity theft and dishonest use of password of any other person) of the Information Technology Act, 2000. Defense of a bonafide intention, in case of violation of privacy by accessing e-mail account without the consent of the user was upheld. The relationship of husband and wife was also taken into consideration The adjudicating officer also relied on the reasoning that the information procured by the ‘unauthorized access’ was only disclosed before the Court and the police, therefore the respondent is not liable to pay any compensation to the complainant.

February 2013 | Page - 24

It can be safely concluded that this judicial interpretation was made due to the peculiar facts of the case that the relationship between the Petitioner and Respondent was that of husband and wife and that the information was used only to be shared with the police as evidence

Vaishali Bhagwat Vaishali Bhagwat is a Computer Science graduate and now practicing lawyer in Pune since last 15 years. She has vast experience in Cyber Cases, both civil and criminal and is an advisor to several IT and ITES companies in India

February 2013 | Page - 25

February 2013 | Page - 26


Hacking Magazine: Issue 37 – Feb2013


Hacking Magazine: Issue 37 – Feb2013