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, Tru. Secure 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 > 130 k 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 Net. Cat 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. Group. Wise 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 host 64. 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 Group. Wise) << 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/top 20/ • 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 Net. BIOS 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 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 • e. Eye. 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) Net. IQ (www. netiq. com) Latis (www. latis. com) Gfi Lan. Guard (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 Mc. Clure, 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
Скачать презентацию Analysts International Performing a Network Vulnerability Assessment
8e2227e5f45ff39e17d5472f288339c3.ppt