Chris - Network Vulnerability Assessments: Lessons Learned - ClubHack2008
Upcoming SlideShare
Loading in...5

Chris - Network Vulnerability Assessments: Lessons Learned - ClubHack2008






Total Views
Views on SlideShare
Embed Views



2 Embeds 21 14 7



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Chris - Network Vulnerability Assessments: Lessons Learned - ClubHack2008 Chris - Network Vulnerability Assessments: Lessons Learned - ClubHack2008 Presentation Transcript

    • Network Vulnerability Assessments Lessons Learned Chris Goggans [email_address]
    • What are Vulnerability Assessments?
      • Internal and external attacks
      • Validation of existing security mechanisms
      • Detailed analysis of all networked devices and services
      • Audits for policy compliance and deficiencies in existing policies
      • Prioritized recommendations for improving security posture
    • Vulnerability Assessments: WHY?
      • Only realistic way to determine vulnerabilities
      • Get a baseline of vulnerability state
      • Prioritize remedial actions
      • Correct serious problems quickly
      • Assure that policies address real vulnerabilities
      • Industry best practice
    • Vulnerability Assessments: H OW ?
      • External Assessment
        • Internet
        • Modems
        • Wireless
        • Partner Connectivity
      • In-briefing
      • Internal Assessment
      • Out-briefing
      • Report preparation and delivery
      • Executive briefing
    • Government Contractor
      • Unpassworded TELNET access into print server
      • SNMP Read/Write community string exposed in printer configuration menu
      • Community string also used on devices such as routers, switches, etc.
      • “ Level 7” hashes in Cisco config files exposed the password “mbhafnitsoscar”
      • This password also used by Domain Administrator on Windows PDC
      • Windows Domain also tied to NetWare eDirectory, sharing account names and passwords
      • In total, compromise of nearly 15,000 accounts and 99.99% of all systems and network devices…all from one insecure printer
    • Government Contractor Lessons Learned:
      • Even the most insignificant network device can provide information that uncovers a major attack path
        • Always examine everything connected to your networks!
      • Always utilize the greatest password protection possible
        • MD5 vs Level7
      • In situations where accounts and passwords are shared across platforms, a single compromise of the weakest platform can lead to massive compromise
        • Rainbow Tables & NTLMv1
    • Civilian Government Agency
      • Development WWW server running with default cold fusion scripts that allow remote viewing of web source
      • Attack Path 1
        • ODBC setup in web page source code exposed z/OS RACF account and password used for DB2 queries
        • Account found to have “system programmer” access on IBM Mainframe
      • Attack Path 2
        • MS-SQL “sa” account and password in web source
        • SQL “XP_CMDSHELL” stored procedure gave remote “SYSTEM” access to Windows OS
        • Local SAM file exposed Domain Administrator account
        • SAM file on PDC had roughly 50,000 accounts
        • Certain users used same password on Windows as they did on very large High Performance Computing cluster
    • Civilian Government Agency Lessons Learned:
      • Passwords embedded in web applications are never a good thing
      • Web Application Vulnerability Assessments have become as important as Network Vulnerability Assessments
      • Database security is also critical and often left unchecked
    • Another Government Agency
      • Large network of Solaris and Windows systems
      • All machines and applications patched
      • Many important UNIX services are TCP-wrapped
        • NFS, NIS, etc.
      • Customer had recently deployed new KVM switches in their racks
      • In addition to 3 rd party software, KVM Switch also had HTTPS based management interface with a default “Admin” account with no password
      • HTTPS-based access also provided JAVA-based remote console program
      • Open consoles found on Windows system (as Administrator) and Solaris system (as root)
      • NIS passwd-byname tables and Windows SAM and locally cached account hashes pulled
      • All systems compromised
    • Another Government Agency Lessons Learned:
      • Every host on a network must undergo some level of security hardening before being allowed to connect to the production network
      • Every console should be forced to either screen-lock or auto-logout when not in use
    • Managed Service Provider
      • Customer had limited Internet exposure, primarily HTTP traffic allowed to “Hosting” LAN (primarily only TCP 80 & 443)
      • Web server compromised with Apache “Chunked-code vulnerability”
      • Server had 3 interfaces (2 for normal access, 3 rd interface leading to NOC management-LAN for “out of band” SNMP)
      • System on NOC network compromised with common Windows vulnerability
      • NOC network had visibility into entire corporate network, as well as other hosted customers
    • Managed Service Provider Lessons Learned:
      • It only takes one vulnerable service to give attackers a strong foothold into your network
      • Management networks or VLANs are often excellent points to bridge between networks without direct connectivity
      • Systems hosted by 3 rd parties are often compromised by attacks originating from less secure customers at the same hosting facility
    • Telecommunications
      • Large US telephone company
      • Dial-ups found with unpassworded pcAnywhere
      • pcAnywhere system used primarily for access into security camera monitoring of unmanned facilities
      • Full access to internal network, including switching systems, billing, etc.
    • Telecommunications Lessons Learned:
      • Modems can still be a major external threat!
      • Critical systems should be firewalled against general network access
    • Emergency Response
      • Organization responsible for state-wide emergency medical services
      • Internet connectivity shared with major university
      • Organization tied to other state-run networks through dedicated lines
      • Firewall rules allowed certain hosts on University network & State Government networks into EMS network using insecure protocols (MS-SQL, SMB)
      • Common exploits led to massive compromise
    • Emergency Response Lessons Learned:
      • All inbound partner connections should be examined as part of a vulnerability assessment
      • Firewall rules should likewise be examined to uncover any potential weak points for permitted communications
      • Your network is ultimately only as secure as the weakest host connected to you
    • Law Enforcement
      • Compromised Windows Workstation through un-patched IIS Web server – obtained local SAM file with domain accounts
      • Compromised Windows PDC by escalating privileges with access gained from previous machine
      • Compromised Investigator’s workstation with Domain Admin rights
      • Workstation had VNC remote control software – password retrieved from Windows registry
      • Logged in using remote control GUI
      • Icon on desktop for MILES/NCIC
        • Just a keystroke capture program away from access to the FBI
    • Law Enforcement Lessons Learned:
      • Users should not be allowed to install random applications on their workstations
        • Especially those that facilitate remote control!
      • Applications that utilize proprietary authentication are usually easily broken
      • Any system with multiple Network Connections can be used as a gateway to bridge secure networks to insecure networks
        • The same holds true for VPNs, PPP connections, Wireless LAN access, etc.
      • Even one of the most “secure” systems in the US can be compromised if accessed in an insecure fashion
    • Uncovering Attacks During Assessment
      • Many assessments will reveal existing evidence of prior attack activity
      • Some attacks may be more serious than others
      • Most attack information found on Internet-based hosts are from random hacker groups running scripts
      • Attacks found on internal machines are usually much more serious
    • Real Incident – Local Government
      • Internet assessment found that IIS server was vulnerable to attack
      • Several strange files found in the “SCRIPTS” directory
      • Files were backdoor CMD shells and host scanning scripts
      • Web log analysis showed that the host had been compromised by at least two separate groups: one in USA, one in Korea
      • Host was patched and files were removed
    • Real Incident – Service Provider
      • Customer had servers hosted at Tier-1 internet provider
      • Poor password on MSSQL server led to compromise of machine
      • Customer noticed that the server was losing disk space
      • Hidden directories had over 30GB of movies and music
      • Netstat output showed that server was connecting to IRC server
      • Ethernet Sniffing revealed IRC channel and channel key being used
      • IRC Channel was being used by German software pirates
      • We joined the channel and surprised the pirate group. They apologized and told us we could keep copies of the movies.
    • Real Incident - Telephone Company
      • Systems Administrator making threats about taking down Telephone switches
      • Multiple root-shell files found on critical UNIX servers throughout the enterprise
      • Backdoor access to switching systems found through X.29 PADs
      • Administrator’s contract was terminated
    • Real Incident – Web Services
      • Systems administrator fired for sexual harassment
      • Windows machines began experiencing problems
      • False accounts discovered on Internet accessible machine
      • Trojan Horse discovered on internal workstations
      • Real motive was intellectual property theft, and administrator was arrested
    • Real Incident - Banking
      • Vulnerability assessment conducted against bank network
      • Trojan Horse discovered on workstation
      • Workstation used primarily as database for all customer credit-card data
      • No data available to identify how Trojan Horse was delivered
      • All credit cards on server had to be re-issued
    • Common Assessment Problems
      • Customer Perception
      • Misconfigured Hosts
      • Bad Programming
    • Problem – Customer Perception
      • Customer knew that we had gained access to all UNIX systems
      • Administrator complained that TACACS server no longer worked, and thought our assessment caused the issue
      • Review of TACACS config file showed that it had been recently modified by the Administrator
      • We discovered that the Administrator had put in an additional # in file that caused the problem
      • Administrator was very embarrassed
    • Problem – Misconfigured Hosts
      • Solaris file system became full and caused kernel panic
      • Problem occurred when the server was port scanned, starting somewhere above 30000
      • /var/log/messages file showed that “Inetd” process was failing and writing hundreds of errors per minute to file, causing the disk usage
      • Analysis of /etc/inetd.conf file showed that a process (kcms_server) was allowed to spawn by inetd on port 32774
      • Examination of files showed that the kcms_server program (and many other unused programs) had been erased by system integrator during original install
      • Addition of a single # in inetd before the program name corrected the problem
    • Problem – Bad Programming
      • Port scans of a host indicated multiple unknown applications running on database server
      • When connecting to these services with netcat or telnet to obtain banner and protocol information, the service crashed
      • Analysis of the source code indicated that application programmers did not put in any error handling routines for TCP connections
      • Programmers were able to fix the issue very quickly
    • Final Thoughts
      • Insecure Web Applications have become one of the biggest targets for attackers.
      • Modems (authorized and unauthorized) are still not receiving the attention they deserve as potential threats.
      • Patch & Configuration management are consistently neglected, or only applied to Core OS (not applications).
      • The concepts of Internal and External access have begun to blur:
        • Partner connections
        • Inbound “Phishing” emails and Web Pages downloading malicious code that open up outbound “shell” access
      • Poor passwords are the number one mechanism to gain host-level access.