Chapter 11, Performing a Web Site Vulnerability and Security Assessment
This lesson presents some material from chapter 11. Objectives important
to this lesson:
Vulnerability assessment vs. application testing
Discovery
Vulnerability and security assessment
Planned attacks
Vulnerabilities in back-end and SQL databases
Preparing a report
Best practices
Concepts:
Chapter 11
Looks like the author was saving some pages for this chapter.
The chapter opens with a warning that you should have heard by now: don't
make aggressive probes into a network without having proper permission from
the right authority to do so. This is the sort of thing that a cyber defense
staff watches for, and unauthorized probes are treated as real attacks.
The
author gives us a short list of the critical elements of an application
test:
Does the application meet the stated user
requirements? (User requirements are common when we write our
own software. They are less common for over-the-counter programs, but
they are just as important for them.)
Does the application work
as it is desired and expected to? Does it produce errors?
Does the application have any compatibility
problems with our other applications or operating systems?
The answers to those questions are supposed to be yes, yes, no, and no.
Note that these concerns do not deal specifically with security issues.
The text moves on to consider factors in a security
evaluation of a web site.
the web server software
the hardware and operating
system of the box that runs the web server
applications that are used
on the site and their features, such as the customer interface for browsing
and ordering products
the databases that are used
by the web server and by its applications
I think the author's point is that we have a lot more to check from the
security point of view. He continues the chapter with some methods of
discovering the components of a web site, using them as an attacker might,
starting with a ping.
Ping all IP addresses in the
presumed system's network range to find live addresses.
You may want to use Nmap.
Use Nmap or Zenmap
to find open ports on the active
IP addresses.
Use Nmap or Nessus
to determine the operating systems
of targets.
Use Nessus
to scan for vulnerabilities.
Follow the first link to a Life Hacker article about using Nessus. Follow
that second link to the SecTools site for other suggestions. On page
277, the text recommends running an authenticated scan with Nessus when
possible. This requires that you have admin credentials, but it provides
more information on policies and domain relationships. You could also
use several of the tools we have used in labs this term. Several are
discussed on this
web scanners page, such as Burp Suite and skipfish. As you should
be aware, there are many tools available in your Kali server for this
purpose.
The text pauses again on page 276, warning us that scanning with these
tools (and others) can actually be harmful to the servers involved, so
white hat scanning should be done against test copies of the systems.
For those who prefer videos, this video
walks you through installing Nessus on a Kali box. The presenter gives
us a bit more than the Life Hacker article provides.
On page 282, the text proposes that we make and follow a plan
for site testing. It recommends three general steps for penetration testing:
Develop a plan for the attack
Identify vulnerabilities
Attack and escalate privilege
The first two steps have been discussed already. Step 3 includes access
to data at whatever level we attain. The ideal would be to attain root/administrator
privileges, which the text sort-of recommends by using a buffer overflow
attack to start a new shell, or to break out to a command prompt with
the current admin's privileges.
The text continues with a recommendation to search for security flaws
in back-end and SQL databases with tools meant for such testing. The author's
picks are Metasploit and Acunetix. Metasploit
tools are available in Kali. Acunetix
is mentioned in the link in web page link in the unordered list above.
This is a link
to its home page. Page 285 gives us a general recipe for an SQL injection.
Page 286 starts the section about report writing. It presents an outline
for a formal report to upper management
which may be confusing to anyone who has not had the pleasure of preparing
such a document. Let's look at its parts:
Executive summary - This is
the headline version of the report. Tell your story to people who don't
have time to read the entire paper. I once worked in an organization
that was run by an executive who had the reputation of only reading
a few lines of any email or memo that he received. He trained us to
tell the story in a few words. This is what you do in this section of
the report.
Summary of findings - Think
of this as the technical summary.
What did you find, what did that tell you, and what are you proposing
that we do about it? You can use more sentences and more numbers than
you use in the executive summary: people who read this section want
to get an overview of your actual work, so they can decide whether they
need to read the rest of the report.
Details of the vulnerability assessment
and the security assessment
- This is the part that you write for an analyst who is going to follow
up on your work, for peers to review, for a historical record of what
you did, what you found, and what it all means. This part is full of
details. It is meant to convince
people who do this kind of work that you did a good job.
Recommendations - What do
you propose we should do in the short
term, and in the long term?
How can we remediate the problems? Is there a quick fix? Are there things
we must do that can be spread out for a while? Whye does that last part
matter? No one ever has a budget that will cover everything you want
to do. Learn to make good choices, and learn to sell the things that
still need to be done.
The chapter ends with general suggestions about testing and not stopping.
Use the right tools for your scans. If you don't find what you expect
to find, research other tools and try them.
Test outside your network as well as inside it. If you can't test
inside it due to lack of credentials, stop and ask yourself what you
are doing. Don't hack without authorization, children.
Research again. Learn from good reporters what happened in successful
exploits. Learn to protect and learn to probe from actual events.
Assignments
Continue the reading assignments for the course.
This week we will begin work on your term project/final exam.
I will set up a discussion for it, and points will be given for
participation.