Analysts International
Performing a Network
Vulnerability Assessment
Introductions
• Mark Lachniet from Analysts International,
Sequoia Services Group
• Senior Security Engineer and Security
Services technical lead
• Former I.S. director for Holt Public Schools
• Certified Information Systems Security
Professional (CISSP)
• Microsoft MCSE, Novell Master CNE, Linux
LPI Certified LPIC-1, Check Point Certified
CCSE, TruSecure TICSA, etc.
2
Agenda
•
•
•
•
•
•
•
•
•
Defining a Vulnerability Assessment
Defining Scope
Network Survey
Port Scanning
Vulnerability Research / Validation
Common Vulnerabilities
Industry Databases (CVE)
Tools, products and information
Round table – Q&A – Brainstorming
3
Definition of a Vulnerability
Assessment
vulnerability assessment:
1. The systematic examination of a system to identify
those critical infrastructures or related components
that may be at risk from an attack and the
determination of appropriate procedures that can
be implemented to reduce that risk.
2. [The] systematic examination of an information
system (IS) or product to determine the adequacy of
security measures. identify security deficiencies,
provide data from which to predict the effectiveness
of proposed security measures, and confirm the
adequacy of such measures after implementation.
[INFOSEC-99]
4
Pen-Test vs. Vuln-Assessment
• This presentation is about doing a “vulnerability
assessment” or “penetration test” depending on your
terminology, primarily on Internet hosts
• Most people conceive of of a “Penetration Test” as
being labor intensive, with the explicit goal of finding
some way into the system, not “all ways”
• Conversely, a vulnerability assessment attempts to
find all known holes on all systems, not necessarily
exploiting them but identifying them, usually w/ tools
• Consider the metaphor of the house – a pen-test will
walk through the first door and call it done, while a
vulnerability assessment will try all doors and
windows and give you a complete report
5
About This Presentation
• This methodology comes from my own work at my
company, and is the basis of how we do things
• Many other companies offer similar services
• Many different methodologies and tools are available
to perform these types of assessment – for the public
sector you can also “partner” with someone else
• To take a vendor-neutral position, the work of the
“Open Source Security Testing Methodology Manual”
can be used to provide a baseline
• You can get this document for free from:
http://www.isecom.org/
• A Vulnerability Assessment methodology is only a
start, a good background in computer security is
essential for interpreting the results and doing
something about it
6
Defining Scope
• Before beginning any work, you must
carefully define your scope:
–
–
–
–
–
–
–
–
Which machines to test (IP ranges or addresses)
Which machines to exclude
Which times are good and bad to perform testing
Are you going to test for Denial of Service
susceptibility?
Contact information for both the tester and the
customer. This is needed in case there is a problem and
the assessment must be stopped
Type of assessment to be done - Black Box (nothing is
known), Grey Box (some things are known), or White
Box (all things are known)
This presentation assumes a Grey Box assessment
Make sure you have legal rights to do the assessment!
7
Network Survey
• Perform some data collection to get the more information
for your assessment
• In a Black Box situation, you may have to get all of this
information the hard way, instead of just asking
• Ask the customer to identify all known hosts on the
segment (be prepared to find ones they didn’t know about)
• Find out what services are running on the hosts – this may
influence your methodology or tools (ie, heavily reliant on
Microsoft or UNIX platforms)
• Analyze network maps, with an emphasis on DMZ and
Internet-facing connections
• Analyze ‘whois’ and ARIN data to determine ownership of
domains, etc.
• Identify DNS information for the target (hostnames, mail
MX records, etc.)
8
Port Scanning
• Use a portscanner such as ‘nmap’ to map the subnet
• Identify live IP addresses
• Determine what ports (and hence services) are
available on the network (eg: 25/STMP, 21/FTP)
• Look for open, as well as closed and filtered ports.
(filtered implies a firewall or similar device dropped
the packets instead of allowing an “ICMP Port
Unreachable” message. Determines FW policy)
• Ports range from 1-65,535 for both TCP and UDP.
That means you could be testing > 130k ports.
• You must decide if you want to:
– test ALL ports (and hence have a better chance of finding
results, but also taking a very long time)
– Test a LIMITED number of ports (and hence possibly miss
something, but do it very quickly)
9
ID System and Services
• Can use software such as nmap or queso to
identify the target systems operating system
(due to quirks in the vendor-specific
implementation of TCP/IP)
• Note that OS signatures can be spoofed
• Also, specific port sets are very common to
specific operating systems (e.g. port 445 is
almost always Windows 2000+)
• Connect to ports using a program such as
Telnet or NetCat to grab banners or other
useful information:
220 lachniet.hn.org ESMTP Sendmail 8.12.5/8.12.5; Mon, 17
Feb 2003 16:23:35 -0500
10
Vulnerability Research
• Use a variety (no less than two) of security scanning tools from
different sources
• These tools typically have a database of vulnerability signatures,
just like an anti-virus product
• Ideally, the program will test every signature in its database
against every port (not just expected ports)
• This should find known (ie, documented and in the signature
database) vulnerabilities on the target server
• Sometimes, single-purpose scripts must be used, or signatures
created for the tools
• Regular updates of the signature database is necessary
• Manual analysis of services, especially “odd” ones is usually
necessary – use the Internet to look for vulnerabilities,
discussion threads, do google searches, check dshield.org,
incidents.org, etc.
11
Vulnerability Verification
• Just because a tool reports a vulnerability doesn’t
mean it is actually there! This is a false positive
• Vulnerability Assessment tools typically operate on a
“chat” sequence – send something, get something
back, repeat as necessary and analyze
• This can lead to false positives if the software isn’t
intelligent enough to assess the information it gets
• False positives can also be tagged through reading
service banners, etc. (for example, what if someone
patched the source code flaw but was still at a
“known vulnerable” version of the software?)
• False positives are the bane of the security analyst,
but not nearly as embarrassing as false negatives
• In some cases, its necessary to manually test using
Telnet or other tools to determine if the vulnerability
is real
12
Example: Mail Relay
• One false positive that frequently comes up is that of
an open mail relay
• This means that a target mail server will forward
email from anyone, to anyone
• Spammers use this to send their junk mail without
getting caught
• Subscription services exist to find open relays, and
then ban them. This is great if you want to get less
spam, but not so great if your company gets on the
list, since subscribers won’t be able to get any email
from your company.
• Some mail servers are not exactly “obvious” about
whether they will relay or not. GroupWise will gladly
accept the email as if it was going to forward it, but
then silently stick it into a junk directory
13
Example: Mail Relay
>> telnet lachniet.com 25
<< 220 lachniet.hn.org ESMTP Sendmail 8.12.5/8.12.5; Mon,
17 Feb 2003 16:48:12 –0500
>> helo bigfake.com
<< 250 lachniet.hn.org Hello host64.lan.sequoianet.com
[207.73.216.64], pleased to meet you
>> mail from: merit@nowhere.org
<< 250 2.1.0 isaca@nowhere.org... Sender ok
>> rcpt to: pres@whitehouse.gov
<< 550 5.7.1 pres@whitehouse.org... Relaying denied
This is good! If you saw the following you would almost
certainly have an open mail relay! (or GroupWise)
<< 250 2.1.5 pres@whitehouse.gov... Recipient ok
14
Example: Mail Relay
• Essentially, we just did manually what every Internet
email program does automatically
• This technique is also known as “fakemail” since you
can make email appear to come from anyone or
anything
• I sometimes like to harass friends with emails from
god@heaven.org, and so on
• This is also sometimes used to trick people – you
would probably open an attachment that seemed to
come from your spouse, but not from me
• Note that the BEST way of testing this is to make
yourself be the recipient. If you get an email in your
mailbox, then it is actually relaying
• This is what the ORDB service does, and there is
really no disputing their findings
15
Common Vulnerabilities
• SANS.ORG has a list of the top 20
vulnerabilities at http://www.sans.org/top20/
• Web server flaws that can lead to enhanced
access
– Some will give you system/root access
– Some will only give you “nobody” or “guest”
– Usually from default/unpatched configurations
• FTP Servers
– Anonymous read-only access to sensitive files (such as
debug files used by developers!)
– Anonymous write access. Generally turns your server
into a “warez” host in short order
16
Common Vulnerabilities
• Windows NetBIOS vulns
– Open access to ports 135, 137, 139, 445, etc.
– Unrestricted or open file shares
– Anonymous session / null login (allows enumeration of a lot
of sensitive data)
– Poor or blank user passwords
– Also allows for popup ads, etc.
– Massive reconnaissance opportunities (last logon, etc.)
• Microsoft SQL server
– A-la the “slammer” worm
– Never allow SQL to the Internet!
– Also found in the MSDE package (a desktop version of SQL
server that ships with many products)
– Easy to attack through web logic, so you need app security
17
System Back Doors / Trojans
• Anything that can provide remote
access to a desktop is inherently
dangerous
–
–
–
–
–
–
Windows Terminal Services
Citrix / Metaframe
AT&T’s Virtual Network Console (VNC)
Timbuktu
Back Orifice Trojan
Net Bus
• These can frequently be identified by
the known ports they operate on such as
31337
18
Documenting Vulnerabilities
• Once the vulnerabilities have been identified and
verified, they must be documented
• This documentation should include:
– All hosts the the vulnerability
– A detailed description of the vulnerability
– Links to places with more information
– Information on how to fix the problem
– Some type of rating of the severity of the hole:
• High, medium, and low?
• Remote compromise or local compromise?
• Level of access granted through the hole
(admin?)
• Information leakage?
19
Use Industry Databases
• The most common one is the CVE at
http://cve.mitre.org
• Common Vulnerabilities and Exposures
(CVE®) is:
• A list of standardized names for
vulnerabilities and other information security
exposures — CVE aims to standardize the
names for all publicly known vulnerabilities
and security exposures.
–
–
–
–
A Dictionary, NOT a Database
A Community-Wide Effort
Freely Available for Review or Download
Currently has 2,223 vulnerabilities
20
Use Industry Databases
• CVE is useful because it provides a
common baseline for describing and
correlating vulnerabilities
– Gives a standard name, based on CVE entry
– This allows you to correlate results between
multiple tools that supply CVE entries
• Uses a review process to make sure that
entries are well considered
– Starts with a nomination as a CAN (didate)
– Is confirmed as a CVE (vulnerability) by the
editorial board
21
CVE Example
22
Creating the Toolkit
• Commercial Scanners give a certain level of
comfort, and are often well supported and
robust
• Internet Security Systems (iss.net) has a
number of good (but very expensive)
products:
– Internet Scanner (for typical Vuln Assessments)
– Database Scanner (for focused DB analysis)
– Wireless Scanner
• eEye.com has the Retina Network Security
Scanner that is pretty well regarded
23
Creating the Toolkit
• Other commercial vendors to consider:
–
–
–
–
–
–
Foundstone (www.foundstone.com)
Vigilante (www.vigilante.com)
NetIQ (www.netiq.com)
Latis (www.latis.com)
Gfi LanGuard (www.gfi.com)
Heat (www.heatscanner.com)
• Your mileage may vary – check for
reviews on the Internet, etc.
• Some of the best tools are actually free
24
Creating the Toolkit
• The open-source Nessus Project is
highly regarded as a low-cost option
– Runs on UNIX/Linux operating systems
– Completely open-source for program and
vulnerability databases
– Customizable, possible to write your own NASL
signatures
– Provides for basic reporting, with ways to import
into a database for correlation and making pretty
– Nessus is updated frequently and actively
supported by the authors
– Runs through a client-server architecture – you
may have one central scanner and many clients
– Supports SSL web servers!
25
Creating the Toolkit
• Create a list of security web sites that
contain information (and working
attack scripts) for vulnerabilities
• The best is: packetstormsecurity.org
• Others that are essential include:
– www.sans.org: A source for training, as well as
student papers and example security policies
– www.securityfocus.com: A general web site (now
owned by Symantec) that hosts a lot of discussion
lists (such as pen-test) Good for finding
information on specific products, etc.
26
Beware Application Security!
• As attackers get more sophisticated, so are the attacks
• In particular, attackers are now becoming skilled enough to
attack application logic
• This means looking for flaws in the client and server side logic
(ASP, PHP, etc.) to attack the system
• This is particularly dangerous for systems that talk to a backend database such as a SQL server
• It is possible to pass commands through the application logic (if
it is not properly controlled) and onto the database
• Since the database usually runs as administrator, this usually
means a compromise of the box
• If you have in-house development of *any* code that can run OS
commands, you need to assess your code!
• Check out the Open Source Web Application Security Project at
www.owasp.org
27
Good Books!
• Any of the “Hacking Exposed” by Stuart
McClure, et al books are actually quite good
• They can be picked up in the average Barnes and
Noble / Borders book store
• Editions exist for NT, Windows 2000, and Linux
• Contain detailed, step-by-step instructions on
how the attacks work
• You should hack yourself! This is the best way to
understand how to do a vulnerability assessment
• Also, be warned, this information is out there for
anyone else to buy as well 
28
Q&A and Brainstorming
Mark Lachniet, Sr. Security Engineer
CISSP, MCNE, MCSE, CCSE, LPIC-1, TICSA
Analysts International - Sequoia Services
3101 Technology Blvd. Suite A
Lansing, MI 48910
phone: 517.336.1004
fax: 517.336.1004
29