Question

Use these textbooks to answer the questions;

Chapter 5 in Windows Forensic Analysis DVD Toolkit.

2nd Edition Chapter 5 in Mastering Python Forensics.

Note: Use both textbooks above and collected reliable online resources for your answers (you may utilize the tools mentioned in the textbook or other alternative tools on the internet). All external resources must be listed as references at the end of this document.

1. What is the best way to uncover attempts to compromise an IIS webserver? Why? How do you detect SQL injection attacks to an IIS web server?

2. Where is the Browsing History saved for the web browser(s) you are using on your computer? Find all browsing history and provide screen shots.

Answer 1

Qusetion 1

A log file is an extremely valuable piece of information that is provided by a server. Almost all servers, services, and applications provide some sort of logging. A log file records events and actions that take place during the run time of a service or application.

Log files provide us with a precise view of the behavior of a server as well as critical information like when, how, and by whom a server is being accessed. This kind of information can help us monitor the performance, troubleshoot and debug applications, as well as help forensic investigators unfold the chain of events that may have led to malicious activity.(source- https://www.acunetix.com/blog/articles/using-logs-to-investigate-a-web-application-attack/)

1) Prevent web site attacks with effective web server protection: An application-layer solution works best to inspect requests as they come in from the network and at every level of processing in between. If at any point a possible attack is detected, a solution like this will take over and prevent unauthorized access and/or damage to the web server and host applications. 2) Look for solutions with IIS ISAPI Integration: Solutions developed as an ISAPI filter allow for tighter integration with the web server as compared to other application firewalls. Look for a solution that monitors data as it is processed by IIS, blocking any requests that resemble one of many classes of attack patterns; including SQL injection and cross site scripting. 3) As a site visitor, make sure you have zero-day protection: Look for solutions that use multiple security filters to inspect web server traffic that could cause buffer overflows, parser evasions, directory traversal, or other attacks. This enables blocking of entire classes of attacks, including those attacks that have not yet been discovered. (source- https://www.beyondtrust.com/blog/entry/mass-infection-via-sql-injection-of-iis-websites)

To detect SQL injection attacks-

The only way to know if an input source is potentially vulnerable is to trigger anomalies in the tested webpage or application. In order to do this, the attacker must submit input values that are likely to be incorrectly handled. This technique (named fuzzing) will not yet confirm that an SQL injection flaw is present, but it will help finding what needs further testing.

To create anomalies in the tested script you need to submit input values prone to generate an invalid SQL syntax. Some key testing strings will allow you to achieve this. Those include special characters that should have been filtered by the application. Here are a few examples from the SQL injection testing strings article.

Testing Strings

To create anomalies in the tested script you need to submit input values prone to generate an invalid SQL syntax. Some key testing strings will allow you to achieve this. Those include special characters that should have been filtered by the application. Here are a few examples from the SQL injection testing strings article.

TEST STRINGS TO DETECT SQL INJECTION (1 PER LINE).

xyz'

xyz')

1 OR

1)

Detection Example

Before jumping in the core of the subject let’s take a look at a simple example.

THE QUERY IS BUILT WITHOUT SANITIZING PARAMETERS.

$query = "SELECT title, content FROM posts WHERE page='".$_GET['page']."'";

TEST STRING SUBMITTED BY THE ATTACKER (VALUE OF PAGE PARAMETER).

xyz')

QUERY GENERATED. NOTICE THAT THE INJECTED QUOTE CLOSES THE STRING (COLOR CAN BE CONFUSING HERE)!

SELECT title, content FROM posts WHERE page='xyz')'

As expected, the page returned an error.

In this example it is pretty obvious that there is a security flaw. However, in some cases it is much more difficult to tell. When generic errors or HTTP errors are returned, it becomes hard to know if the suspicious data was intercepted by server-side validation or if the code handled an error generated by the query. For this reason, it is necessary to push tests a bit further.

Confirm Detection

Inference testing is a good technique to confirm that a potential flaw is really vulnerable. Simply put, testing SQL injection by inference will allow the attacker to reconstruct information by analysing the application’s response to different requests. In this case, the tester will craft special SQL segments to make sure he really has control over the query.

Two different tests will be required. The first one will submit input containing a valid parameter followed by a true condition. The second will contain the same parameter followed by a false condition. If the script is vulnerable, the result page of both tests should be different. Moreover, the application's response will habitually be exactly the same with or without the true condition. Let’s recap this technique with the following example.

True Condition Injection

Within a few tries, the attacker finds a way to add a condition without generating an invalid query. The injected parameter and the resulting query are shown below.

PARAMETER SUBMITTED BY THE ATTACKER (DOGS PARAMETER RETURNS A VALID PAGE).

dogs' AND 'a'='a

QUERY GENERATED. WARNING : COLOR CAN BE CONFUSING!

SELECT title, content FROM posts WHERE page='dogs' AND 'a'='a'

The result (or response) does not differ from when the valid parameter is used without condition.

False Condition Injection

For the second test, the attacker uses the same logic.

PARAMETER SUBMITTED BY THE ATTACKER (DOGS PARAMETER RETURNS A VALID PAGE).

dogs' AND 'a'='b

QUERY GENERATED.

SELECT title, content FROM posts WHERE page='dogs' AND 'a'='b'

This time, the page indicates that no such article exists. The detection is successful!

Common alternative to conditions

A common way to achieve the same result without conditions is using equivalent parameters. For example, instead of using a true condition, one could use string concatenation to recreate the original parameter value "dogs". This example will make it more concrete.

USER INPUT (USING STRING CONCATENATION - MYSQL SYNTAX).

do' 'gs

QUERY GENERATED.

SELECT title, content FROM posts WHERE topic='do' 'gs'

THE PREVIOUS QUERY IS EQUIVALENT TO THIS ONE.

SELECT title, content FROM posts WHERE topic='dogs'

As you probably guess, similar principle can be applied to numeric parameters. You will have to be careful when testing those however. For more information take a look at the article about equivalent parameters (available soon).

Query Complexity

The impact of query complexity on the detection process needs a special mention. Examples provided in this article are quite basic and do not present issues a tester might face while trying to detect vulnerabilities in real scenarios. Given a case where the parameter is injected in a sub query or in a complex condition, an SQL injection flaw can become much harder to find. It is still possible but the tester will need a rough idea of the query's structure to achieve an attack

(source- https://www.sqlinjection.net/detection/)

Question 2

First of all you should ensure that you have a SQLite DB console client.
It's provided in MacOS by default, or you can download appropriate binary from SQLite Home Page.
(e.g. for Windows: Page on sqlite.org.
it is tiny in size and needs neither installation nor configuration)

Then you should go to your Chrome directory (eg. in my case "C:\Users\Sashka\AppData\Local\Google\Chrome\User Data\Default")
locate History file
run in command prompt

sqlite History "select datetime(last_visit_time/1000000-11644473600,'unixepoch'),url from urls order by last_visit_time desc" > history_export.txt

command does not dependent on operation system you use.

You would get a plain ASCII file history_export.txt where you find readable dump of your browser history.

(source- https://www.quora.com/How-do-I-access-Chromes-history-saved-browsing-history-file-as-a-readable-format-without-using-third-party-applications-or-extensions)

Note- I could not find the chrome history on my computer due to some problem with it. But the steps would help to find the history. Still if you are not able to find it, do let me know. I will try on some other system.