Analysts International

Performing a Network Vulnerability Assessment

2

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.

3

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

4

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]

5

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

6

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

7

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!

8

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.)

9

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)

10

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

11

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.

12

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

13

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

14

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

15

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

16

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

17

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

18

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

19

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?

20

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

21

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

22

CVE Example

23

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

24

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

25

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!

26

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.

27

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 back-end 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

28

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

29

Q&A and Brainstorming

Mark Lachniet, Sr. Security EngineerCISSP, MCNE, MCSE, CCSE, LPIC-1, TICSAAnalysts International - Sequoia Services

3101 Technology Blvd. Suite ALansing, MI 48910

phone: 517.336.1004fax: 517.336.1004