Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

70
Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International

Transcript of Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Page 1: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Vulnerability Assessments

Part 2

3/10/04

Mark Lachniet, Analysts International

Page 2: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Introductions

• Mark Lachniet, Technical Director of Analyst International’s Security Services Group

• Technical lead developing for services, methodology, quality control, technical presales

• Certified Information Systems Auditor (CISA) from ISACA

• Certified Information Systems Security Professional (CISSP) ISC^2

• Linux LPIC-1, Novell Master CNE, Microsoft MCSE, Checkpoint CCSE, TruSecure ICSA, etc.

• Former I.T. director of Holt Public Schools• Frequent speaker for local organizations

Page 3: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Agenda

• Defining a Vulnerability Assessment• Defining Scope• Network Survey• Port Scanning• Vulnerability Research / Validation• Common Vulnerabilities• Industry Databases (CVE)• Web Application Security• Tools, products and information

Page 4: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Class Logistics

• Frequent breaks, maybe not 20 mins.• I do not mind if you mess around with your

computers while I am talking, in fact I encourage it - you are here because you want to be

• Will attempt to do more hands-on exercises and less talking

• Please speak up! This will be most useful if you ask questions! Don’t wait for the end

• Consider finding a partner, especially one of a higher or lower technical skill level

Page 5: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Class CD-ROM

• I have included a CD-ROM with many tools and utilities on it

• Some of these we will use, some of them we may not

• Most are 30-day expiring demos

• You should go to the web site(s) yourself and download the software, so you can get registered

Page 6: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Classroom Network

EthernetMACUL 2004

LAN

CISCO AIRONET 350 SERIES

WIRELESS ACCESS POINT

Presenter's Laptop192.168.2.171

Windows Hacker Laptop192.168.2.173

Linux hackers Laptop192.168.2.172

Student192.168.2.100-170

Student192.168.2.100-170

Student192.168.2.100-170

USR 8054 AP192.168.2.254

Page 7: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Definition of a Vulnerability Assessment

Vulnerability assessment: • 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.

• [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]

Page 8: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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 without 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

Page 9: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

Page 10: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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 testee. 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!

Page 11: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

Page 12: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Understanding TCP/IP

• Most Internet-connected hosts speak TCP/IP Version 4

• TCP/IP Version 6 is available, and has a much larger address space, as well as enhanced security

• TCP/IP is generally referred to as including related protocols such as ICMP and UDP

• It is important to know how TCP/IP and related protocols work in order to secure your hosts, firewalls and routers

Page 13: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

TCP/IP and the OSI Model

• Note that Internet (IP) is lower and talks IP and ICMP• TCP and UDP may be on top of IP (and others as well)

Page 14: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Understanding IP

• At the IP layer, we are concerned about hosts being available - routing, congestion, etc.

• The IP layers uses ICMP (Internet Control Message Protocol) packets to pass information

• The most common types of ICMP messages are:– “0 Echo Reply” and “8 Echo” (used in ping)

– “3 Destination Unreachable” (sometimes used to convey information from a higher layer, like UDP or TCP ports or IP hosts not being available)

– “30 Traceroute” (used in traceroute)

– “5 Redirect” (used to indicate a better route)

• See http://www.iana.org/assignments/icmp-parameters

Page 15: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Understanding ICMP

• In order to understand what we have on our network, it is useful to “ping” each IP in a range of potentially live addresses

• This is known as a “ping sweep”

• Essentially, we are sending an ICMP Echo Request to each IP address in a list or range, and hoping to get an ICMP Echo Reply back

• If we get a reply, we assume that the host is live, and connected to the Internet

• If we don’t get a reply, the host *may* not be live, but it may also be behind a firewall, or have some other type of protection

Page 16: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Activity #1: Ping Sweep with NMAP

• First install WinPCap 3.0 from the CD

• Then install NMAPNT to a directory on your computer

• Once this is done, attempt to ping-sweep our classroom network to find out who is “live”

• nmap -v -sP 192.168.2.0/24

• Scroll up, see which hosts are live

• Did any host names resolve?

Page 17: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

The 3-Way TCP Handshake

• One important TCP/IP concept to understand is the TCP 3-way handshake

• TCP is a connection oriented protocol - both the client and the server want to know when a connection is open, and when it can be closed

• The handshake is how a node will negotiate a TCP connection with another node (for example to get a web page or FTP transfer a file)

Page 18: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

The 3-Way TCP Handshake

Page 19: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

TCP Port Scanning• Once we know what hosts are live (via ICMP ping) we want

to know what services are available on the hosts (for example 25/STMP, 21/FTP, 80/WWW, 443/HTTPS, etc.)

• Every port is associated with a process or service. If the port is open, the associated program is probably running

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

Page 20: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Activity#2: TCP Connect Scanning

• In this exercise, pick a partner (victim)• Using just their IP address, we will do a

standard TCP connect scan of their computer• Turn off personal firewalls (if any)• nmap -v -sT 192.168.2.X -p 1-1024• Note how long this takes…. Now try all TCP

ports!• nmap -v -sT 192.168.2.X -p 1-65535• Get coffee… and muffins…• How long did it take? Bored yet?

Page 21: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Non-TCP Connect Scanning• It is also possible to scan hosts without actually

completing the 3-way handshake

• This is faster, as we only need 2 packets, not 3

• It is also sneakier, as the target may not consider the connection “made” until the final ACK arrives

• Thus, we may be able to scan a host without generating any log entries at all

• This is also the basis of many Denial of Service (DoS) attack - too many SYN packets can deplete memory and network resources and cause problems

• With NMAP we may scan with the -sS or other sneaky types of packet types

• Be warned, firewalls are hip to this trick

Page 22: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Useful TCP Scanning

• One great use of TCP port scanning is to quickly identify services, especially when they just discovered a new security flaw and you aren’t sure which machines need updates

• For example:– nmap -sT -p 80 192.168.2.X/24 (find all machines

running web servers)

– nmap -sT -p 5631 192.168.2.X/24 (find all machines running PC Anywhere)

– nmap -sT -p 25 192.168.2.X/24 (find all machines running a mail server)

• You get the idea...

Page 23: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

• We can also fingerprint services, nmap default• Connect to ports using a program such as Telnet

or NetCat to grab banners or other useful information

Page 24: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Activity #3: Grabbing Banners

• In this case, we want to manually connect to the web server to see what version it is

• telnet 192.168.2.171 80• type the following (exactly)• GET / HTTP/1.1• Then hit “enter” twice• This can be done for some (but not all)

services• Also note that banners can (and should) be

changed to confuse and irritate hackers

Page 25: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

UDP Port Scanning

• UDP is a connectionless protocol, so it is a little bit harder to scan

• With a UDP scan, you send a packet to each UDP port on a host, and if you *do* get a response back, it is probably an “ICMP Port Unreachable” type message, indicating failure

• It could also be that there is a firewall in the way that is silently dropping UDP packets before the target host sees them and replies with an ICMP message

• Even assuming that there *is* a listening service, it might be tough to figure out which one, except based on the port number

Page 26: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Activity #4: UDP Scanning

• Fortunately for us, there is no firewall in the way, and we are using Windows boxes which use UDP, so we should get good results

• Pick a victim and scan them:• nmap -v -sU -p 1-1024 192.168.2.X• Note the ever popular 137/UDP and

138/UDP for Windows NetBIOS networking• If you ever see this on your public segment,

be very worried (and then go firewall it)

Page 27: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Vulnerability Scanning• Once you have mapped your network, use a variety

(no less than two) of security scanning tools from different sources to find vulnerabilities

• These tools typically have a database of vulnerability signatures, just like anti-virus

• 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

Page 28: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Vulnerability Scanning

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

• Just because a tool reports a vulnerability doesn’t mean it is actually there! This is a false positive

Page 29: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Vulnerability Verification

• 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

Page 30: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

Page 31: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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: [email protected]<< 250 2.1.0 [email protected]... Sender ok>> rcpt to: [email protected]<< 550 5.7.1 [email protected]... 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 [email protected]... Recipient ok

Page 32: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

[email protected], and so on (its not actually illegal. Yet)• 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

Page 33: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Nessus• 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 reports– 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!

Page 34: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Nessus

• Nessus is (in my personal opinion) the best of the vulnerability assessment tools, primarily because of price!

• Nessus is used by just about everyone who does vulnerability testing, either as the primary tool or the supplemental tool

• Nessus is client-server based, and uses strong encryption and authentication, and runs on UNIX

• Nessus has a database of over 2,000 known vulnerabilities

• There are also flexible (if difficult to configure) features such as reporting and modules

Page 35: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Nessus - Client Server

• Nessus allows multiple simultaneous users, jobs, and targets, so you can set up one Nessus server and let multiple people use it

The Internet

NESSUS SERVER

NESSUS CLIENT#2

VICTIM#2

VICTIM#1NESSUS CLIENT#1

Page 36: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Nessus WX

• While Nessus runs on UNIX, it is possible to run a Client on Windows

• This is particularly useful if you are not a UNIX person, or if you like to quickly generate PDF reports of findings

• Check out http://nessuswx.nessus.org/ for more information

• It has most of the features, and is fairly user friendly

• You might consider setting up one Nessus box, give your IT staff NessusWX clients, and ask them to scan each server before being placed on the Internet

Page 37: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

NeWT• Unfortunately, we don’t have time to install nessus

on UNIX or Linux

• However, someone identified a commercial opportunity and ported the Nessus server to the Windows environment

• Check out Tenable software at http://www.tenablesecurity.com/

• Although not free, it may well be cheaper than hiring a UNIX geek to install and maintain it for you

• There are also a number of other products from Tenable that are worth looking at

• They offer discounts for K-12, and the pricing is reasonable for what you get!

Page 38: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Activity #5: Using NeWT

• Install Newt from the CD-ROM• Run the plug-in update program• Run NeWT• Select “New Scan Task”• Type in your loopback IP “127.0.0.1”• Enable all but dangerous plugins• Run the scan• View the report - note references to CVE and

CAN, as well as links to more information about the plugin and/or issue

Page 39: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Activity #6: Configuring NeWT

• Click on the “Configure NeWT” link• (walkthrough of features)• Click on the “Manage Plugins” link on the left-

hand side• Not the ability to create and select vulnerability

profiles (this will cut your scanning time down, but you may miss something)

• You may also create host profiles such as “all Internet hosts” or “all windows servers” to make things easier

Page 40: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

Page 41: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

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

Page 42: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

LanGuard

• A great tool for Windows environments is LanGuard from GFI

• This will do scans like Nessus, but is much more aware of the Windows environment

• Given proper authorization, it will even check the status of machines for patches, and help you to push patches to those machines that need them*

• There is also scripting capability built into the product, if you need more power or flexibility

• This may be a great way to keep all of those Windows boxes up to date!

Page 43: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Activity #7: LanGuard

• Install LanGuard from the CD-ROM

• Check for updates and restart

• Type in ‘127.0.0.1’ in the target box

• View the results - its amazing what Windows will tell you, isn’t it?

• Go to Scan->options, note the ability to crack passwords

• Also allows you to set settings (such as auditing) on multiple hosts at once, reducing maintenance overhead

Page 44: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

Page 45: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Documenting Vulnerabilities• Once the vulnerabilities have been identified and

verified, they must be documented and fixed• 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?

• Then read the links, prioritize and go fix!

Page 46: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

Page 47: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

Page 48: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

CVE Example

Page 49: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

Page 50: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

Page 51: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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.

Page 52: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Web Applications

• Where a conventional application requires physical proximity and client software, web access is intended to be accessible to the widest possible audience

• As a result, they are typically open to the entire Internet community

• It is logical to assume that the larger the user community is, the more likely it is that someone may choose to analyze the security of the application

• Due to the fact that a good hacker can effectively cover their tracks and anonymously probe the security of applications, there is very little risk to the hacker to do so (as compared to an attack that requires physical proximity)

• Thus, web applications may require more security than others

Page 53: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Conceptual Overview of Web Apps

• Web applications are generally developed in Tiers– User / Client– Web Server– Business Logic– Database

• In many cases, the database is the same one that holds other critical organizational data!

Page 54: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Logical / Physical Overview

• Let us pretend that we are looking at a State of Michigan web site (note: this is only pretending!!)

• The purpose of the web site is to allow “self service” access to Human Resources information:– Pay stubs, deductions, direct deposit bank name– Demographic information– Emergency Contact information– Education– Dependants (names, ages)

• The application was written by a combination of internal and external programmers

• The application was written in Microsoft .NET, and communicates with the actual State of Michigan Human Resources HRMN system

Page 55: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Logical / Physical Overview

Internal Network(Protected Machines)

DMZ Network(Internet Accessible Machines)

The Internet

Bad Person

Good Person

Company Firewall

Demonstrative WebApplication Diagram

Internet Router

Self ServiceWeb Server

Human ResourcesDatabase

Page 56: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

• In order for this all to work, the HRMN system needs to trust the self service web application to access data

• Thus, the program logic of the self service application may be critically important, responsible for ensuring that:– Users are properly authenticated– Users are authorized to use the system– Adequate logging of activity takes place– The Internet-facing components do not have known

security flaws• In short, a part of the security of the human

resources database now lies in an Internet-facing web application, possibly bypassing the more established and mature database security

• What could possibly go wrong?

Implications

Page 57: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

What Can Go Wrong???

• Frankly, a lot…..• Secure programming practices have not really been

taught in higher education• Productivity pressures have made security a

secondary priority• A lot of insecure web sites have been implemented• In fact, a recent study found that no less than 92% of

web pages surveyed over a 4-year period had serious security flawshttp://www.vnunet.com/News/1152521

• Are you confident that your web site is within the fortunate 8%?

• If you don’t have an explicit set of controls for application development, security and ongoing testing, you shouldn’t be!

Page 58: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Recent Example

• http://seattlepi.nwsource.com/national/apus_story.asp?category=1110&slug=Hackers%20State%20Computers

Friday, February 13, 2004 · Last updated 8:31 p.m. PT

SACRAMENTO, Calif. -- Hackers broke into a state agency's server containing the sensitive personal information of tens of thousands of people who work as nannies, butlers, and gardeners, and those who employ them.

The hackers gained access to employee's names, Social Security numbers and wage records, and some employers' Social Security numbers, Callori said.

• This is, unfortunately, more than enough information to cause harm, such as identity theft

Page 59: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Types of Flaws in Web Applications

• Lets look at the statistics from the previously quoted article:

– Cross-site scripting (80 per cent)– SQL injection (62 per cent)– Parameter tampering (60 per cent)– Cookie poisoning (37 per cent)– Database server (33 per cent)– Web server (23 per cent)– Buffer overflow (19 per cent)

• My personal experience indicates that these numbers are about right

• Any one of these flaws could lead to a disclosure of critical or protected data

• Lets look at a few examples

Page 60: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Cross-Site Scripting

• Occurs when input from a user is not “sanitized” before being re-displayed on a web site

• For example, an Internet guest book may allow you to enter a message, along with the time and date that you visited a web site

• It may be possible to craft this message in such a way that users’ Internet browsers interpret the message as HTML code, instead of plain text

• If this happens, person A can make it appear to person B’s computer that a web site (presumably a trusted one) is the source of a tricky attack

• This commonly used to do things like steal authentication information, or redirect to a “phishing” web site to harvest passwords, credit card numbers or bank account numbers

Page 61: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Real Life Example of CSS

• While working for a customer, analyzing a well known SSL VPN appliance, I discovered a CSS bug

• I then created a proof of concept to demonstrate this bug• I created a (virtually) identical copy of the VPN server’s

login page, and put this on a server that I had control of• I then created a special CSS web address (URL) that, when

entered, would redirect the user transparently to this external web site

• The fake web site said “session has timed out, please log in again” message, and had a place to log in again

• When the user entered their username and password on the fake login, this information was written to disk on my “hacker” computer, and the user was redirected back to the *real* VPN server’s “incorrect password” page

• The end user would simply think that their session had timed out, and that they had mis-typed their password

Page 62: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

SQL Injection

• The next most common flaw, SQL injection, is worse• In this case, a hacker would find a part of the application

code that did not perform proper input sanitization• By passing special characters in form fields (e.g. a place

to type in a query or address) it is then possible to embed additional commands for the HR database

• Since the application server is “trusted” by the back end database, it assumes that the request is legitimate and performs the query

• The “normal” results, as well as the database commands entered by the hacker are displayed in the browser

• This attack can be used to completely bypass application and database security

• In our working example, an identity thief hacker could then print out the names, SSN#’s and addresses of all employees and use this to steal their ID

Page 63: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Real Life Example of SQL Injection

• While analyzing a production Internet web site during a WASA (Web Application Security Analysis) I discovered a SQL injection flaw in the application code

• With this knowledge, I configured a program called “data thief” to assist me in demonstrating the vulnerability

• Using data thief, I was able to copy the entire back-end database, with all of the data, including usernames and passwords, across the Internet to my computer

• Using this database of logins and passwords, I was able to log in, and access the application as an administrator

• At that point, I also had the ability to run software on the database server, which was on the internal, protected network

• If I were a bad guy, I could have used this access to compromise additional systems on the Internal network

Page 64: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Real Life SQL Injection Example

Page 65: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Other Web Application Risks

• There are a number of other risks that need to be looked at:– Ability to bypass authentication systems– Ability to steal user “sessions”– Flaws in the underlying operating system / web server– Flaws in the “chain of trust” (relying on an additional

system for some security component such as a SSO (Single Sign On) system)

– Flaws that allow a hacker to deny service to the system (e.g. by using all of the licensed connections, flooding the server, or causing a software crash)

– Reliance on client-side security (especially client-side scripting)

• And so on….

Page 66: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

How to Protect Your Organization

• There are several things you want to consider when analyzing web applications:– Has a design of the system been validated both by

app. Dev, DBA and I.T. security staff?– Has an adequate System Development Life Cycle

(SDLC) been used throughout the project to promote consistent and quality code?

– Have programmers been trained in secure programming standards? Is there an internal Q.C.?

– Has a proper change control system been used to develop and maintain the system?

– Has the system had a formal web application security assessment? Is the system “hardened”? (many internal and external resources can help with this)

Page 67: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Security Products – Web Application

• Although this is a relatively new area, a number of products exist to assist an I.T. analyst

• One such product, the one that is used at Analysts International, is “SPI WebInspect” from SPI Dynamics, Inc.

• http://www.spidynamics.com• This product is very flexible, and can save thousands

of hours of manual assessment time• Can export pieces of data, print detailed reports, and

maintain full information about the scanning activity that has occurred

• One of the better web application security tools available, and reasonably priced

• As always, don’t take my word for it, do a product evaluation of your own

Page 68: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Security Best Practices

• A lot of information is available for programmers, auditors and I.T. staff on web application security issues

• The most referenced one is the Open Web Application Security Project at http://www.owasp.org

• OWASP has specific guidelines for what programmers should and shouldn’t do, as well as detailed information on what the issues are and how they can be detected

• For more information on how to go about assessing an application using accepted methods, check out “Open Source Security Testing Methodology Manual” at http://www.isecom.org/projects/osstmm.shtml

• A number of product-specific web sites for major vendors also exist. A good one for both theory and practice for Microsoft is at:

• http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=055FF772-97FE-41B8-A58C-BF9C6593F25E

Page 69: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

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

Page 70: Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International.

Discussion

• This presentation to be available at:http://lachniet.com/powerpoint

Mark LachnietCISSP, CISA, MCSE, MCNE, CCSE, LPIC-1, TICSATechnical Director, Security GroupAnalysts International(517) 336-1004 (voice)(517) 336-1100 (fax)mailto: [email protected]