INTRO TO ETHICAL HACKING

MIS 5211.001

Introduction

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

Course Plan

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 presentation5 (9/24) System and User enumeration

Assignment presentation6 (10/1) Sniffers7 (10/8) Midterm

NetCat8 (10/15) Social Engineering, Encoding, and Encryption9 (10/22) Malware including Trojans, Backdoors, Zero-days, Virus, Worms, and

Polymorphic malware10 (10/29) Web application hacking, Intercepting Proxies, and URL Editing11 (11/5) SQL injection

Assignment presentation12 (11/12) Web Services13 (11/19) Evasion Techniques14 (12/3) Final

About the Course

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

Caution

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.

Mindset

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.

Mindset (Continued)

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!

Threat vs. Vulnerability vs. Risk

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

Threat vs. Vulnerability vs. RiskContinued

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.

General Types of AttacksActive vs Passive

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

General Types of AttacksInternal vs External

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

Ethical Hacking

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

Penetration Testing

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

Security Assessments

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

Benefits of Alternatives

Unlikely to crash systems Staff performing these evaluations often

bring different and unique skill sets to the table

Different perspectives on the organization

Why Do We Do This

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

What To Do With Findings

Document the findings From the client perspective:

Document issues Develop action plans Mitigate

OR Risk Acceptance

Types of Tests

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

Phases

Reconnaissance What technology is in use in the target

environment Scanning

What vulnerabilities exist within the target environment

Exploitation Can the vulnerabilities be used

Going to Far

Malicious attackers go further Maintaining access Covert Channels Infiltrating Data Covering Tracks

Iteration and Following Hunches

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

Limitations

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

LimitationsKnown Vulnerabilities

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

Public Methodologies

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 OWASP Testing Framework

https://www.owasp.org/index.php/The_OWASP_Testing_Framework NIST SP800-115

http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf Penetration Testing Framework

http://www.pen-tests.com/penetration-testing-framework.html Penetration Testing Framework 0.59

http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html

Infrastructure for Penetration Testing

Software Tools Hardware Network Infrastructure

We will cover some basics Adjust as needed to suite need Dependent on type of targets and tests

Operating Systems

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

Software for Testing in this Course

Kali BackTrack Reborn according to Offensive Security,

the providers of Kali Available at:

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/ If you already have VMWare Workstation that

will work as well

Other Free Tools

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

Some Sources of Tools and Exploits

Exploit Database http://www.exploit-db.com/

Packet Storm http://packetstormsecurity.com/

Pentest-Tools https://pentest-tools.com/home

Security Audit Systems http://www.security-audit.com/blog/penetration-

testing-tools/

I am not endorsing these sites, just making you aware of them.

Vulnerability Research

US-CERT https://www.us-cert.gov/

National Vulnerability Database http://nvd.nist.gov/home.cfm

Mitre CVE http://cve.mitre.org/

Exploit Database http://www.exploit-db.com/

CVE Details http://www.cvedetails.com/

Commercial Tools

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

In House Tools

Talk to your developers May have already built scripts and tools May already own some commercial tools that

can be leveraged

Going Further With Labs

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

Machines for Testing

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

Virtual Test Machines

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

ISPs

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

Cloud

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

Infrastructure Firewalls

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.

Host Firewalls

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

Harden Test Machines

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/

Microsoft Baseline Security Analyzer also helps http://

www.microsoft.com/en-us/download/details.aspx?id=7558

Protecting Test Results

Consider encrypting test findings as they accumulate

Example PGP

http://buy.symantec.com/estore/clp/smb_d4v2_9p9s_pgpencryption1_default

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

Clean Test Machines Between Tests

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

Penetration Testing Process

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

Permissions

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

Insurance & Limitation of Liability

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

Rules of Engagement

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

Shunning

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

Black Box vs Crystal Box

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

Data on Compromised Systems

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

Observed Tests

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

Completing Planning

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

Scope

Identify Client Security Concerns Disclosure? Availability? Reputation? Financial Loss? Other?

Only the client can tell you what they are really worried about

Scope Creep

Identify known issues Do you need to verify them?

Identify likely threats State Actors Disgruntled Employees

Determine what to focus on

What to Test

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

Third Parties

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

Production vs Test

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

How to Test

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

Internal or Near Internal Testing

What about insider threats Possibilities

Official site visit and granted access Onsite and breaks in WiFi Dial-In VPN Citrix Public Kiosk

Client Side

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)

Social Engineering

Very powerful Manipulating employees may impact

morale, but also may serve an awareness function

Client needs to think through and consider pros and cons

Conducting a Social Engineering Test

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

Denial of Service

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

Dangerous Exploits

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

Reporting Results

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

Scan Results Are Not A Report

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

Suggested Format

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)

Executive Summary

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

Executive Summary

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

Screenshots and Illustrations

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