Transcript Internal Penetration Testing

How to Fix A Broken Window
©1999, 2000 Laurie Brosius
Erik Pace Birkholz, CISSP, Principal Consultant, Foundstone
[email protected]
Part 1:
Intranet Penetration Testing: Discovering network negligence
Part 2:
Strengthening Microsoft: When # is not an option
Background Information
 Who am i?
 When did I start security?
 Where do I work?
 What is my job?
 Why do you care?
 What was your inspiration for this talk?
Background Information

Who am i?





When did I start security?






Erik Pace Birkholz, CISSP – MCSE
Contrary to popular belief, I am 27 years old.
From New Jersey, just outside of Philadelphia.
BS in Computer Science from Dickinson College, PA (est 1773)
1995, NCSA - National Computer Security Association, Carlisle, PA
1997, KPMG - Information Risk Management, Manhattan, NY
1998, E&Y – National Attack and Penetration Team, Los Angeles, CA
1999, ISS – Lead Consultant, Hollywood, CA
2000, Foundstone Inc., Irvine, CA
Where do I work?
 Foundstone

KNOW VULNERABILITIES
Background Information
 What is my job?
 Principal Consultant
 Internet and Intranet Penetration tests
 Instructor for Foundstone courses
 Contributing Author for Hacking Exposed
series
Background Information
 Why do you care?
 You probably don’t, but that’s ok.
 In you are trying to decide if you should
head off to Halvar or Chip’s talk instead.
 What was your inspiration for this talk?
Inspiration / Rant
Year 2001 was the year that got away.
Our comfort zone crumbled. Seemingly
well laid plans turned to dust. Systems
crashed and networks halted as
faceless network attacks tore through
cyberspace.
Inspiration / Rant
As a nation and an industry, we fell
victim to devastating attacks that could
have been avoided. Security and
comfort slipped through our fingers
and was gone.
Inspiration / Rant
Ladies and gentleman, security has reached
the board room. Management wants
answers. They want solutions. Above all
else they want piece of mind this won’t
happen again. Purse-strings are opening;
now is the time for IT to make things right.
Management finally understands a simple
fact that can no longer be avoided:
responsibility without authority is a recipe
for failure.
Inspiration / Rant
C:\>net send * “Don’t expect secure
networks if you haven’t empowered
your internal security team.”
Inspiration / Rant
Security vs. usability may finally become
a balanced equation. All the usability in
the world isn’t worth a damn if your
internal network is a wasteland of
default configurations and blank
passwords.
Inspiration / Rant
Security teams are now a required
internal resource. Contrary to popular
belief there are NOT 24 working hours
in a day. Security can not be treated as
a side order. The excuses need to stop
- now.
10 Lessons from 2001
 Secure perimeters still allow web attacks.
 Laptops tend to be promiscuous, spending time in untrusted networks
then coming home to the corporate LAN.
 Employee’s REALLY DO get disgruntled.
 Default configurations are bad, even if they are internal only.
 Flat networks are bad.
10 Lessons from 2001
 Inconsistent server configuration will hurt you.
 Exploits can be scripted to replicate just like a virus.
 Users WILL click on a link to a picture of Anna Kournikova.
 There is NOT one tool that replaces the human element of a security
expert.
10 Lessons from 2001
Responsibility without authority is
impossible in the security world.
C:\>net send * “Don’t expect secure networks if you
haven’t empowered your internal security team.”
Internal Penetration Testing
 Two scenarios
 CYA and documentation
 Defining scope and goals
 Tools of the Trade
 Presentation of findings
Internal Penetration Testing
 Two scenarios
 Third party assessment






Foundstone
@stake
Big 5
Guardent
ISS
etc…
 Internal security team
 Current IT staff vs. pure security team
Two scenarios
 Third party assessment
 Be VERY selective




Current methodology
Established in the security community
Provides report samples
Onsite team guarantee
 Biographies provided and approved
Two scenarios
 Third party assessment
 Be VERY selective




Provides reputable references for previous work
Guidelines and standards for data destruction
Considers YOUR company important
Will help teach you to fish
Two scenarios
 Third party assessment
 Use 3rd party assessments to compliment
your year round security testing
 brushing teeth vs. dentist office visit
 Use multiple vendors
 Each assessment should be independent of the previous
 Request all raw data in addition to reports
Two scenarios
 Internal Security Team
 Current IT staff vs. pure security team?
 What is a pure security team?
 Internal staff with the sole function of security
 Can they exist in small companies?
 Can they exist in large corporations?
 Can these two teams peacefully co-exist?
 Of course.
Sample structure for large corporation
Two scenarios
 From here on out, lets consider the
assessment team is interchangeable
between internal and 3rd party.
Stuff you already know
Windows NT/2000 Domains:
The Impact of Local and Domain Account Compromises
NT/2000 domains, simply put, are Windows systems connected to
facilitate the sharing of resources and ease of
administration. The glue that binds this domain together is
centralized administration of users and their access/restriction to
domain resources. This administration is achieved through
Domain Controllers. Domain controllers contain all the domain
accounts and provide access/restriction to domain resources
based on these accounts. NT/2000 systems also have local
accounts that provide access to local resources. Depending on
the role and configuration of the server, these resources can be
exploited to gain administrative domain access. With that said,
the end goal of penetrating an NT/2000 domain is achieved by
compromising an administrative level domain account
Stuff you already know
Domain Controllers
Domain Controllers are the "treasure chest" for Windows NT/2000
accounts and passwords. If a Domain Controller is compromised
at an administrative level, all usernames and encrypted password
hashes for that domain will likely be stolen and cracked offline on
the attackers system. This includes all administrative level
domain accounts.
Since Domain Controllers are the foundation of any Microsoft
NT/2000 Domain. A compromise at this level almost ensures
compromise of Application servers and Member
servers. Additionally, due to password reuse, it is feasible that
an attacker could compromise other NT/2000 Domains, Standalone servers, as well as non-NT/2000 operating systems.
Stuff you already know
Domain Controllers
Domain controllers must be single function servers. This means they
should not perform or offer any other functions to the domain. The user
account database is their critical resource and this must be protected at
all costs.
Provided the server is locked-down as a single function server offering no
services beyond what is required, an attacker will need to compromise a
username/password that is a member of the local Administrators group
or one with administrative level privileges (ie. Domain Admins
group). This can be achieved by password guessing or password reuse
from other sources. With that said, the compromise of an account that
has administrative domain privileges usually signifies "game over" for
the domain, its systems and their resources. These accounts are stored
on Domain Controllers and must be protected with the strongest
passwords controls allowable by corporate policies.
Stuff you already know
Application servers
Application servers on the network provide access to services such as Web, FTP,
SQL, Oracle, Mail and File sharing. These servers are usually the second tier of
an attack against and NT/2000 domain. Generally, vulnerabilities in these
services will be attacked with exploits that in many cases result in a complete
compromise of the system.
Unnecessary services should not be run on application servers. These services
constitute a potential avenue for attack. These services, if required at all, must be
kept up to date with current stable vendor patches. If an attacker gains control of
an Application server, the username/passwords from that system will often
provide the credentials needed to compromise a domain account that has
administrative privileges. Additionally, previously established connections and
trusts can be leveraged to compromise other systems. For example, web servers
often contain e-commerce data, existing connections and scripted passwords to
backend databases. The worst-case scenario would be an attacker gaining an
administrative domain account from a Application server compromise. This can
be avoided by never running services in the context of an administrative domain
account on non-Domain Controllers.
Stuff you already know
Member Servers
Member servers (workstations, test systems, back-up servers, etc) are
usually the final targets for an NT/2000 attacker with zero network
knowledge. Unless an attacker is unsuccessful in the first two tiers
they will most likely already have full access to all Member
servers. Common targets of this type are administrative workstations
and desktops of Supervisors and Executives. Accounts should not
exist on these systems that would allow an attacker to gain domain
level access via password reuse. An attacker that compromises a
member server will have full access to all data on the system
(personal & corporate) and may have access to systems administered
from this system. The worst-case scenario would be an attacker
gaining an administrative domain account from a Member server
compromise. This can be avoided by never running services in the
context of an administrative domain account on non-Domain
Controllers.
Stuff you already know
Critical Application Servers (Non-Domain Requirement)
Critical Application Servers (Payroll/Finance/HR) typically are not
required to be accessible from the domain except by a very tightly
restricted group. The isolation of these servers can be exaggerated
by removing them from the domain and creating strict access control
lists or firewall rules for protection. Individuals who require access
should be using a `static´ workstation with a defined IP address. This
address will be one of the few that will be allowed remote connection
to shared drives. Accounts should be unique to this system with both
userid and passwords different from the primary domain. Applications
running such as Peoplesoft or Oracle Financials, which require the
general population the ability to connect, should be controlled by
creating strict access control lists or firewall rules limiting connections
only to the application server port.
Internal Penetration Testing
 Two scenarios
 CYA and documentation
 Defining scope and goals
 Tools of the Trade
 Presentation of findings
CYA and Documentation
BEFORE YOU BEGIN
 Get signed approval
 Gather contact/emergency information
 Obtain critical operations information
 Maintenance windows
 Agree on documentation and reporting
 Screenshots?
Internal Penetration Testing
 Two scenarios
 CYA and documentation
 Defining scope and goals
 Tools of the Trade
 Presentation of findings
Defining Scope and Goals
 Define specific goals for assessment




What defines success?
Identify vs. exploit?
Should systems be tagged?
Are screenshots enough?
 Create timelines
 Active assessment?
LIMITS?
Out of scope? Not for hackers








Reading email in attempt to gain passwords
Attacking workstations to gain network credentials
Attacking administrative workstations to gain admin access
Searching .txt and .doc files on workstations
Searching .txt and .doc files on production systems
Sniffing traffic
Keystroke loggers
Intentional denial of service
 The bad guys can/may/will do these things.
Internal Penetration Testing
Internal vs. External
What is the difference?
•less or no access controls
•test systems
•trust relationships
Internal Penetration Testing
 Two scenarios
 CYA and documentation
 Defining scope and goals
 Tools of the Trade
 Presentation of findings
Internal Penetration Testing








Footprint
Host Identification
Service Identification
Service Enumeration
Host Enumeration
Network Map
HSV Scans
Vulnerability Mapping/Exploitation
Internal Penetration Testing
Footprint
Goal:
identify ranges and domains
Internal Penetration Testing
Footprint
Identify domains
net view /domain
Internal Penetration Testing
Footprint
Identify IP ranges
 SNMP
 DNS
 ICMP
www.solarwinds.net
Internal Penetration Testing








Footprint
Host Identification
Service Identification
Service Enumeration
Host Enumeration
Network Map
HSV Scans
Vulnerability Mapping/Exploitation
Internal Penetration Testing
Host Identification
Identify Hosts
 TCP
 ICMP
Fscan - Foundstone
Internal Penetration Testing
Host Identification
Identify domain members
using the NET command
net view /domain:<domain>
Internal Penetration Testing








Footprint
Host Identification
Service Identification
Service Enumeration
Host Enumeration
Network Map
HSV Scans
Vulnerability Mapping/Exploitation
Internal Penetration Testing
Service Identification
Identify Ports
 TCP
 UDP
Fscan - Foundstone
Internal Penetration Testing
Service Identification
Don’t forget source port scans!
Fscan –i <ip>
Fscan – www.Foundstone.com
Internal Penetration Testing








Footprint
Host Identification
Service Identification
Service Enumeration
Host Enumeration
Network Map
HSV Scans
Vulnerability Mapping/Exploitation
Internal Penetration Testing
Service Enumeration
Identify what is running
on listening ports


TCP
UDP
Fscan - Foundstone
Internal Penetration Testing








Footprint
Host Identification
Service Identification
Service Enumeration
Host Enumeration
Network Map
HSV Scans
Vulnerability Mapping/Exploitation
Internal Penetration Testing
Host Enumeration: use all the
previous information to make
accurate guess at OS and version
Internal Penetration Testing








Footprint
Host Identification
Service Identification
Service Enumeration
Host Enumeration
Network Map
HSV Scans
Vulnerability Mapping/Exploitation
Internal Penetration Testing
Network Maps should be created to
identify hosts, services and access
paths.
Internal Penetration Testing








Footprint
Host Identification
Service Identification
Service Enumeration
Host Enumeration
Network Map
HSV Scans
Vulnerability Mapping/Exploitation
Internal Penetration Testing
High Severity Vulnerability (HSV)
Scans should be performed to
identify systems with high severity
vulnerability.
Internal Penetration Testing
High Severity Vulnerability Scans
NetBIOS weak passwords
SQL weak passwords
Web Vulnerabilities
Internal Penetration Testing
High Severity Vulnerability Scans
NetBIOS weak passwords
Internal Penetration Testing
High Severity Vulnerability Scans
NetBIOS weak passwords
Internal Penetration Testing
High Severity Vulnerability Scans
SQL weak passwords
Internal Penetration Testing
High Severity Vulnerability Scans
SQL weak passwords
Internal Penetration Testing
High Severity Vulnerability Scans
Web vulnerabilities
Internal Penetration Testing








Footprint
Host Identification
Service Identification
Service Enumeration
Host Enumeration
Network Map
HSV Scans
Vulnerability Mapping/Exploitation
Internal Penetration Testing
Vulnerability Mapping/Exploitation
Source port attacks
If you use IPSec don’t forget to use the
NoDefaultExempt key
HKLM\SYSTEM\CCS\Services\IPSEC\NoDefaultExec
DWORD = 1
Internal Penetration Testing
Vulnerability Mapping/Exploitation
.printer
unicode
Internal Penetration Testing
Vulnerability Mapping/Exploitation
Internal Penetration Testing
Vulnerability Mapping/Exploitation
Internal Penetration Testing
Vulnerability Mapping/Exploitation
Demo
Internal Penetration Testing
 Two scenarios
 CYA and documentation
 Defining scope and goals
 Tools of the Trade
 Presentation of findings
Presentation of Findings
 HSVs should be reported ASAP
 Report should be clear and concise
 Include screenshots
 Use action items for remediation
Presentation of Findings
 Do not confuse symptoms for systemic
causes
 Think about systemic causes
 Categorize findings
 TACTICAL
 STRATEGIC
Strengthening Microsoft Networks
 strong domain architectures
 rigid user management
 hardened applications
 principle of least privilege
Strengthening Microsoft Networks
 security baselines for systems
 defense in depth
 network segmentation
 3rd party audit
Summary
 What was the point again?
 Where can we get these slides?
 Do you have a web site?
 Is there time for Q&A?
Question and Answer
How to Fix A Broken Window
©1999, 2000 Laurie Brosius
Erik Pace Birkholz, CISSP, Principal Consultant, Foundstone
[email protected]