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

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

15. 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.” 10 Lessons from 2001

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 3 rd 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 3 rd 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:

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

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

52. Internal Penetration Testing Network Maps should be created to identify hosts, services and access paths.

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

54. Internal Penetration Testing High Severity Vulnerability (HSV) Scans should be performed to identify systems with high severity vulnerability.

55. Internal Penetration Testing High Severity Vulnerability Scans NetBIOS weak passwords SQL weak passwords Web Vulnerabilities

56. Internal Penetration Testing High Severity Vulnerability Scans NetBIOS weak passwords

57. Internal Penetration Testing High Severity Vulnerability Scans NetBIOS weak passwords

58. Internal Penetration Testing High Severity Vulnerability Scans SQL weak passwords

59. Internal Penetration Testing High Severity Vulnerability Scans SQL weak passwords

60. Internal Penetration Testing High Severity Vulnerability Scans Web vulnerabilities

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

62. Internal Penetration Testing Vulnerability Mapping/Exploitation Source port attacks

63. If you use IPSec don’t forget to use the NoDefaultExempt key HKLM\SYSTEM\CCS\Services\IPSEC\NoDefaultExec DWORD = 1

64. Internal Penetration Testing Vulnerability Mapping/Exploitation.printer unicode

65. Internal Penetration Testing Vulnerability Mapping/Exploitation

66. Internal Penetration Testing Vulnerability Mapping/Exploitation

67. Internal Penetration Testing Vulnerability Mapping/Exploitation

68. Demo

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

70. Presentation of Findings  HSVs should be reported ASAP  Report should be clear and concise  Include screenshots  Use action items for remediation

71. Presentation of Findings  Do not confuse symptoms for systemic causes  Think about systemic causes  Categorize findings  TACTICAL  STRATEGIC

72. Strengthening Microsoft Networks  strong domain architectures  rigid user management  hardened applications  principle of least privilege

73. Strengthening Microsoft Networks  security baselines for systems  defense in depth  network segmentation  3rd party audit

74. Summary  What was the point again?  Where can we get these slides?  Do you have a web site?  Is there time for Q&A?

75. Question and Answer

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