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? Why 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.
The author gives us a short list of the
critical elements of an