1 / 76

How to Fix A Broken Window

How to Fix A Broken Window. ©1999, 2000 Laurie Brosius . Erik Pace Birkholz, CISSP, Principal Consultant, Foundstone erik@foundstone.com. Part 1: Intranet Penetration Testing: Discovering network negligence Part 2: Strengthening Microsoft: When # is not an option .

kurt
Download Presentation

How to Fix A Broken Window

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. How to Fix A Broken Window ©1999, 2000 Laurie Brosius Erik Pace Birkholz, CISSP, Principal Consultant, Foundstone erik@foundstone.com

  2. Part 1: Intranet Penetration Testing: Discovering network negligence Part 2: Strengthening Microsoft: When # is not an option

  3. 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?

  4. Background Information • Who am i? • 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) • When did I start security? • 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

  5. Background Information • What is my job? • Principal Consultant • Internet and Intranet Penetration tests • Instructor for Foundstone courses • Contributing Author for Hacking Exposed series

  6. 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?

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

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

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

  10. Inspiration / Rant C:\>net send * “Don’t expect secure networks if you haven’t empowered your internal security team.”

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

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

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

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

  15. 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.”

  16. Internal Penetration Testing • Two scenarios • CYA and documentation • Defining scope and goals • Tools of the Trade • Presentation of findings

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

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

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

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

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

  22. Sample structure for large corporation

  23. Two scenarios • From here on out, lets consider the assessment team is interchangeable between internal and 3rd party.

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

  25. 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, Stand-alone servers, as well as non-NT/2000 operating systems. 

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

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

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

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

  30. Internal Penetration Testing • Two scenarios • CYA and documentation • Defining scope and goals • Tools of the Trade • Presentation of findings

  31. 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?

  32. Internal Penetration Testing • Two scenarios • CYA and documentation • Defining scope and goals • Tools of the Trade • Presentation of findings

  33. 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?

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

  35. Internal Penetration Testing • Internal vs. External • What is the difference? • less or no access controls • test systems • trust relationships

  36. Internal Penetration Testing • Two scenarios • CYA and documentation • Defining scope and goals • Tools of the Trade • Presentation of findings

  37. Internal Penetration Testing • Footprint • Host Identification • Service Identification • Service Enumeration • Host Enumeration • Network Map • HSV Scans • Vulnerability Mapping/Exploitation

  38. Internal Penetration Testing Footprint Goal: identify ranges and domains

  39. Internal Penetration Testing Footprint Identify domains net view /domain

  40. Internal Penetration Testing Footprint Identify IP ranges • SNMP • DNS • ICMP www.solarwinds.net

  41. Internal Penetration Testing • Footprint • Host Identification • Service Identification • Service Enumeration • Host Enumeration • Network Map • HSV Scans • Vulnerability Mapping/Exploitation

  42. Internal Penetration Testing Host Identification Identify Hosts • TCP • ICMP Fscan - Foundstone

  43. Internal Penetration Testing Host Identification Identify domain members using the NET command net view /domain:<domain>

  44. Internal Penetration Testing • Footprint • Host Identification • Service Identification • Service Enumeration • Host Enumeration • Network Map • HSV Scans • Vulnerability Mapping/Exploitation

  45. Internal Penetration Testing Service Identification Identify Ports • TCP • UDP Fscan - Foundstone

  46. Internal Penetration Testing Service Identification Don’t forget source port scans! Fscan –i <ip> Fscan – www.Foundstone.com

  47. Internal Penetration Testing • Footprint • Host Identification • Service Identification • Service Enumeration • Host Enumeration • Network Map • HSV Scans • Vulnerability Mapping/Exploitation

  48. Internal Penetration Testing Service Enumeration Identify what is running on listening ports • TCP • UDP Fscan - Foundstone

  49. Internal Penetration Testing • Footprint • Host Identification • Service Identification • Service Enumeration • Host Enumeration • Network Map • HSV Scans • Vulnerability Mapping/Exploitation

  50. Internal Penetration Testing Host Enumeration: use all the previous information to make accurate guess at OS and version

More Related