1. MIS 5211.001

2.  Wade T Mackey  Wade.mackey@temple.com Wade.mackey@temple.com  717-682-2925

3. 1 (8/27) Philosophy of Ethical Hacking and Penetration Testing, and the hacking process. 2 (9/3) TCP/IP and Network Architecture and its impact on the process of hacking. Google Hacking 3 (9/10)Reconnaissance 4 (9/17) Vulnerability scanning and analysis of results Assignment presentation 5 (9/24) System and User enumeration Assignment presentation 6 (10/1)Sniffers 7 (10/8) Midterm NetCat 8 (10/15)Social Engineering, Encoding, and Encryption 9 (10/22) Malware including Trojans, Backdoors, Zero-days, Virus, Worms, and Polymorphic malware 10 (10/29)Web application hacking, Intercepting Proxies, and URL Editing 11 (11/5) SQL injection Assignment presentation 12 (11/12)Web Services 13 (11/19)Evasion Techniques 14 (12/3)Final

4.  Our focus will be to provide you with an understanding of the process involved in penetration test and the primary tools sets used  Organized around the workflow of a professional tester  Tips for avoiding common pitfalls

5.  The tools and techniques discussed and used in this course should only be used on systems you personally own, or have written permission to use.  Some of the tools used have the potential to disrupt or break computer systems.

6.  Successful penetration testers look at the world through a different lens  They think outside the box  They do things differently  They don’t look at the glass as half full or half empty, instead they look at the glass and think “If I hit the glass just right, I can crack it and drain out just what I want.

7.  Successful penetration tester also need to have the following work habits  Methodical  Thorough  Careful  Ethical  habitual note taker and documentation fiend  If you can’t duplicate a finding, you didn’t find it!

8.  Threat: Any circumstance or event with the potential to adversely impact organizational operations.  Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source.  Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event  A risk exist when a threat actor (or agent) targets a vulnerability Source: NIST SP 800-30 r1

9.  A penetration tester:  identifies vulnerabilities  Evaluates likely threats  Recommends corrective actions  In other words, you don’t just say you found something bad. You also have to suggest how to fix it.

10.  Attacks violate CIA (Confidentiality, Integrity, or Availability.  Active Attack  Manipulates or changes systems or information  Examples – Malware, Spear Phishing, Man-in-the- Middle  Passive Attack  No manipulation or Change  Monitoring only  Example – Sniffing wireless traffic

11.  Internal  Launched from within an organization  Typically considered insider threat  Could also be a trespasser  External  From the internet  From partners on leased lines  From exposed WiFi

12.  Hacking traditionally means manipulating technology to do something it was not originally intended to do  Ethical Hacking: Hack into a computer network in order to test or evaluate its security, rather than with malicious or criminal intent. Source: Oxford Dictionaries

13.  Focused on finding vulnerabilities  Uses many of the same tools and techniques as criminals  Penetration Testing is a subset of Ethical Hacking  Penetration Testing and Ethical Hacking are often used interchangeably  Penetration Testing usually means going a bit further then Ethical Hacking in order to prove a system can be breached and data obtained

14.  Generally focused on identifying vulnerabilities without actually compromising systems  Vulnerability Scanning  Architectural Reviews  Configuration Reviews  Code Reviews  Audits

15.  Unlikely to crash systems  Staff performing these evaluations often bring different and unique skill sets to the table  Different perspectives on the organization

16.  Find vulnerabilities before the “Bad” guys do  Ensure management understands the risks in their systems  Informs Security Operations as to what to look for in their monitoring systems  Security Operations is often not informed of work to test if appropriate monitoring is in place

17.  Document the findings  From the client perspective:  Document issues  Develop action plans  Mitigate OR  Risk Acceptance

18.  Infrastructure (Network)  Web  Dial-Up (War Driving)  Wireless  Social Engineering  Physical  Application

19.  Reconnaissance  What technology is in use in the target environment  Scanning  What vulnerabilities exist within the target environment  Exploitation  Can the vulnerabilities be used

20.  Malicious attackers go further  Maintaining access  Covert Channels  Infiltrating Data  Covering Tracks

21.  Phases are not usually this clean  Some jumping around is to be expected  Skilled testers often get a feel for where vulnerabilities may exist based on their experience in similar systems

22.  Penetration Testing can’t find everything  Limited time  Limited scope  Some vulnerabilities are only exposed in specific conditions that may not exist at the time of testing  Testers have different strengths and weaknesses  Some techniques will be off-limits due to potential negative impacts on a target environment

23.  Tool sets only find known vulnerabilities  Few tester have the skill set to find unknown vulnerabilities and develop custom attacks  Even fewer organizations want to fund this level of investigation  May violate terms and conditions of software or hardware licensing

24.  A number of groups publish methodologies for testing systems for vulnerabilities  Can be useful as guidelines for establishing how you pursue testing  Examples:  Open Source Security Testing Methodology Manual (OSSTMM)  http://www.pen-tests.com/goto/link/125/1 http://www.pen-tests.com/goto/link/125/1  OWASP Testing Framework  https://www.owasp.org/index.php/The_OWASP_Testing_Framewor k https://www.owasp.org/index.php/The_OWASP_Testing_Framewor k  NIST SP800-115  http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf  Penetration Testing Framework  http://www.pen-tests.com/penetration-testing-framework.html http://www.pen-tests.com/penetration-testing-framework.html  Penetration Testing Framework 0.59  http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html

25.  Software Tools  Hardware  Network Infrastructure  We will cover some basics  Adjust as needed to suite need  Dependent on type of targets and tests

26.  Penetration Testers need to shift between multiple operating systems  Some tools are only available on one platform  Some tools may be available on multiple platforms, but work better (or worse) on specific platforms  At a minimum, some Linux and Windows proficiency is needed

27.  Kali  BackTrack Reborn according to Offensive Security, the providers of Kali  Available at:  http://www.kali.org/downloads/ http://www.kali.org/downloads/  Kali is large (2.9G), so give yourself some time  VMWare Player  Free for personal use, scroll down  Available at:  http://www.vmware.com/products/player/ http://www.vmware.com/products/player/  If you already have VMWare Workstation that will work as well

28.  Many other tools are available  You will not need them in this class  If you go on to do penetration testing, you will likely collect a number of tools  Be careful  Research tool before downloading  Run them in a test environment first

29.  Exploit Database  http://www.exploit-db.com/ http://www.exploit-db.com/  Packet Storm  http://packetstormsecurity.com/ http://packetstormsecurity.com/  Pentest-Tools  https://pentest-tools.com/home https://pentest-tools.com/home  Security Audit Systems  http://www.security-audit.com/blog/penetration- testing-tools/ http://www.security-audit.com/blog/penetration- testing-tools/ I am not endorsing these sites, just making you aware of them.

30.  US-CERT  https://www.us-cert.gov/ https://www.us-cert.gov/  National Vulnerability Database  http://nvd.nist.gov/home.cfm http://nvd.nist.gov/home.cfm  Mitre CVE  http://cve.mitre.org/ http://cve.mitre.org/  Exploit Database  http://www.exploit-db.com/ http://www.exploit-db.com/  CVE Details  http://www.cvedetails.com/ http://www.cvedetails.com/

31.  Many commercial tools are available, for a price  Tenable - Commercial version of Nessus  Qualys – Vulnerability Scanner (alternative to Nessus)  Rapid7 – Commercial Metasploit  Core Security – Core Impact  HP – Fortify Code Scanner

32.  Talk to your developers  May have already built scripts and tools  May already own some commercial tools that can be leveraged

33.  Not needed for this course  Consider building out a hardware lab  Free tools should be tested in a lab before using them in testing  Mimic what you expect to test  Mix up OSs  Does not need to be new equipment, recycle  Good environment to continue learning

34.  Dedicated machines for conducting tests  Not used for normal activity  Do not keep any sensitive information  May be tied up for long periods of time doing scanning  If you expect to do a great deal of scanning, consider a separate server dedicated to scanning

35.  Host Machines  VMWare Player  VMWare Workstation  ESX  ZEN  Microsoft Virtual PC  Guest machines may be ideal for testing  Can be built for test  Can be reset if corrupted  Can be deleted after testing  Can be duplicated if additional guests are need  We will go over setting up VMWare for testing in week three

36.  Many ISPs monitor traffic for malicious activity  Inform your ISP prior to starting Pen Testing  May need to move to a business account  May need to “negotiate” with the ISP

37.  Cloud can be very effective for replicating Distributed Denial of Service attacks  Will require permission form cloud provider or your account may be closed  Cloud providers are reluctant to host Penetration Testing activities  May be possible after some negotiations

38.  Firewalls may block or minimize the capabilities of penetration testing.  Pen testing activity, especially scanning, can cause performance issues in firewalls  HTTP Proxies may alter encoding  Next Generation firewalls (Like PaloAlto) may perform analysis and drop packets that are not well formed.

39.  Avoid using firewalls on your test network and attack machines  May block activity before it ever leaves your systems  Since this exposes test machines to attack, use a separate, off-network machine to take notes.  Utilize USB drives to transfer information

40.  Machines in you testing network should be baselined and locked down as much as possible  Keep patching up to date  Turn off all unnecessary ports and services  Increase security settings where possible  Center for Internet Security provides some guidelines  http://www.cisecurity.org/ http://www.cisecurity.org/  Microsoft Baseline Security Analyzer also helps  http://www.microsoft.com/en- us/download/details.aspx?id=7558 http://www.microsoft.com/en- us/download/details.aspx?id=7558

41.  Consider encrypting test findings as they accumulate  Example  PGP  http://buy.symantec.com/estore/clp/smb_d4v2_9p9s_pgpe ncryption1_default http://buy.symantec.com/estore/clp/smb_d4v2_9p9s_pgpe ncryption1_default  BitLocker  http://windows.microsoft.com/en- US/windows7/products/features/bitlocker http://windows.microsoft.com/en- US/windows7/products/features/bitlocker  Encryption technologies are changing, stay up to date on what works, and what has been broken

42.  When an engagement ends  Move test results off of systems  Scrub systems thoroughly  Secure Deletion  Reimage  Revert to baseline Note: Consider using Solid State Drive w/ Trim turned on, faster and deleted data auto zero’s

43.  Preparation  NDAs if applicable  Client concerns  Rules of Engagement  Scope  Written Permission and Acknowledgement of Testing Risks  Testing  Perform Test  Conclusion  Analyze results and retest as needed  Develop report and presentation if needed

44.  Vital that written permission be obtained  Without this you could be held criminally responsible  Good intentions are no defense  Ensure individual granting permission has the authority to do so  Corporate Officer  Director  P&L Responsibility

45.  Permission alone is not sufficient  If you are not working “In-House”  Contract language needs Limitation of Liability language  Time to call in the lawyers  You, or the company you work for will also need liability insurance

46.  At a minimum  Contact Information  Periodic Debriefing (Daily?)  Dates and Times for Testing  When to start  When to stop  Hours when testing is acceptable  Announced or Unannounced

47.  What if Sys Admins detect testing and attempt to block.  Is this good, or bad?  Stop test, or remove blocks and keep testing?  Verify if client IDS, IPS, or WAF may block attacks  This may be OK if test was focused on effectiveness of these systems  However:  Could cause Denial of Service  Resource consumption  May need to get you traffic excluded from protections to test systems behind these controls and Scope Creep

48.  Black Box:  No data provided to tester other then target IP Address or URL  Mimics malicious attackers vantage point  Time and resource consuming  Crystal Box:  Tester provided detailed data on systems and architecture  Allows tester to quickly move to value added work  May not uncover data leaked into public space that would have been found during reconnaissance phase

49.  How far should test team go?  Configuration Data  User Info  PII  Should likely stop at configuration data  Testers do have a responsibility to not go past agreed to boundaries  Also applies to sniffer data

50.  Is a client representative going to observe all testing  Ensure client data is protected  Inform testers that some area may be off limits  Is client staff going to work with testing team  Client may want their staff to become familiar with tolls and methodology

51.  Establish agreement on issues prior to starting  Document the agreement and get sign-off from all parties  Congratulations – You now have your Rules of Engagement, remember that from slide 46

52.  Identify Client Security Concerns  Disclosure?  Availability?  Reputation?  Financial Loss?  Other?  Only the client can tell you what they are really worried about

53.  Identify known issues  Do you need to verify them?  Identify likely threats  State Actors  Disgruntled Employees  Determine what to focus on

54.  Determine clear and explicit scope  What to test  Which systems?  Which address space?  Individual hosts?  What to stay away from  Known “brittle” systems  Critical systems

55.  If third parties are to be tested, they need to provide written permission  If out of scope, need to know who and what they are to avoid them  This is a particular concern in web application testing as sites routinely link or have content hosted form third parties

56.  Test environments offer lower risk of impact  May not match production  May respond slower, impacting test efficiency  May not be possible, as only a production system exists

57.  How hard are you going to try  Ping Sweeps  Port Scanning  Vulnerability Scanning  Penetration into Target  Application Level Attacks  Client Side Attacks  Business Logic  Physical  Social Engineering  Denial of Service

58.  What about insider threats  Possibilities  Official site visit and granted access  Onsite and breaks in  WiFi  Dial-In  VPN  Citrix  Public Kiosk

59.  Old process focused on servers and infrastructure  More and more focus on client side testing  Can I pivot through a compromised client browser (Think Target)  Can I target vulnerable staff? Or does the client organizing want to provide a willing target to accept the attack (and avoid embarrassing employees)

60.  Very powerful  Manipulating employees may impact morale, but also may serve an awareness function  Client needs to think through and consider pros and cons

61.  Explicit written permissions  Defined goal, what are you after?  Develop several scripts and get them vetted by client  Select the right tester  People person  Someone others want to help  Sympathetic

62.  Dangerous to test  Often not done because it is already known that systems can be knocked down  If in scope, ensure specifically documented as “in scope”  Consider carving out a subsystem to test so as not to take down entire client

63.  Some tests are known to be dangerous  Nessus has separate category of vulnerabilities it can scan for that are known to knock targets of line  Some Metasploit attacks will either succeed or crash the target system  Access testing can lock out users inadvertently

64.  Always create a report  It may be the only evidence you where there  Will likely be around a long time  Therefore, make sure it is clean, correct, and reflects well on the effort you put in  Report may make the difference between repeat engagement or no more engagements  Even if “In-House” create the report  Brands your team and their effort

65.  Scanning reports may be included in an appendix, but they should not constitute the body of the report  Description of findings, with impact and recommended mitigation go in the body of a report  Don’t accept scanning result ratings at face value.  May need to adjust based on other information developed during test

66.  Executive Summary  Introduction  Methodology  How did you do the testing  Findings  Ranked by severity  Recommendations  Conclusion  Clients often want to know how they stack up against their vertical  Appendices (if needed)

67.  Most important part of test  Management representatives may never read beyond the summary  Keep it short  1 page, 1.5 at most  Briefly acknowledge test team and client employees who participated  Summarize overall risk posture

68.  Include bulleted list of most significant findings  Three to six at most  Framed in terms of business impact  Why does the line of business care about the risks identified  Describe mitigation paths  People  Processes  Technology

69.  Screenshots or illustrations help capture audience attention and make findings more “real”  Only include “useful” screenshots  Focus on important area, zoom in  Mask are exclude sensitive information  Passwords  User Names  Employee or Customer Data