vulnerability testing and security analysis · example: logging is absent or does not work as it...

Michael Sonntag

Institute of Networks and Security

Vulnerability testing

and security analysis

What’s this all about?

„We have a very secure system!“

Really? How do you know? Can you prove this?

Is this possible to confirm at all?

No! We can confirm that security does not work, by

getting in/stealing data/installing malware/…,

but we cannot prove that nobody will ever (now) be able to do this!

Still there is very much demand for this…

“Solution”: Try to hack the system; if we do not manage this, we

declare it to be secure

This requires similar skills than those of real attackers, but they

operate with a different intention - and with permission!

2

Term definitions

Bug: Technical problem

A program does not exactly do what & when it should do it

Produces an incorrect or unexpected result or behaves in an

unintended way

Weakness: Technical aspect

Position in or part of a system where it can be "damaged"

(attacked, exploited…)

Not necessarily a bug: design errors

Vulnerability: Weakness with security implications

A weakness, which can be used to circumvent, deceive or modify

security services

Also depends on our definition of “security”, i.e. the aims

3

Term definitions

Security issues are security problems, but not necessarily actual

vulnerabilities

Example: Logging is absent or does not work as it should This will not allow someone to break into the system or cause any

other problem

But IF (when!) someone breaks in, it will make tracing them and their

actions significantly harder!

Testing: Investigation into the quality of a software/system

Objective, independent, and repeatable

Success = Bug/vulnerability/… found

Failure = Nothing found Nothing there or not sought hard

enough, at the right places, with the right tools etc???

Typically restricted in scope: Security, timeliness, features, …

4

Term definitions

Exploit: Developing an attack using a vulnerability

Typically not the theory but rather a practical program for this Software to attain privileges which should not be granted

Note: Exploits are often published widely to "encourage" vendors

to fix the vulnerability But this also means, that the exploit can be readily (ab)used...

"Good" hackers inform the company (set a deadline) and publish the

exploit only some time afterwards

Currently: Setting a brief time (e.g. 30 days) after which it will be

published anyway “Get the patch our, or we will publish!”

“Zero-day exploit”: An exploit developed on the same day when

the vulnerability was detected (theory!) Practice: An exploit where the public/vendor does not know about the

vulnerability at all

Very expensive to buy; often kept secret and used stealthily

Zero-day attack

5

Term definitions

Threat: Aims at exploiting a vulnerability to reduce or remove one of

the aims of security

Plan for an attack; must be concrete, not abstract

Attack: A threat is realized and put into motion

Nothing problematic has happened yet The action of the attacker

Except perhaps filling the log and alerts!

Incident: An attack was successfully completed

Security has been breached

We have not necessarily "lost" anything valuable, but we could not

have prevented it

Successful attack = incident (no difference then) The result of the actions of the attacker

6

Term definitions

Risk: Probability of an (undesirable) event happening, times the

anticipated damage caused by it (DIN, VDE Norm 31000)

Other definition: „Something that may evolve from an issue to a

problem if nothing is done about it“

Risk = Probability * Damage The probability is very hard to estimate, especially for attacks

The potential damage can also be very difficult to guess

Audit: (Security) test against a defined standard

Check for compliance with “…”

“Official” certification of a specific security level

By an independent third party You can test internally, but a real “audit” must be external

7

Security testing

General problem (as opposed to functionality, ...) testing:

We try to prove that something (=vulnerability) is absent

Functionality: Try it out (might be hard enough!) Works? Can we get in when we enter the correct password?

Security: Even if everything works and all known problems are

tested to be absent, new classes of attacks might surface Can we get in when we enter a wrong password?

Or if we boot from a DVD? Or press “Ctrl+Esc” at the right time? Or

submit a password of 256 chars + some shellcode? Or if we enter the

default override password of the manufacturer? ……

Must take into account the various aims an attacker might have:

Getting in, stealing data, DoS, crashing, modification, … The hacker’s means are also important, but typically they are assumed

to be almost unlimited (after all, he has unlimited time)!

!

8

Security testing – Why? (1)

Obtain a snapshot of the current security state

Are we good, so-so, badly, …secured?

Any specific (old) vulnerabilities?

Anything looking suspicious and should therefore receive

additional protection (e.g. put behind a firewall, ALG, tighter

restrictions, chroot jail/container/VM?)

Evaluate the capacities to

face an attack (alerts, notifications, false positives etc.)

use intermediate measures (e.g. HW, SW, reduced service)

recover from an attack (backups etc.)

obtain evidence of an attack (to decide on/allow prosecution)

However: This includes also processes ( ISMS), often only “search

for vulnerabilities” is covered!

9

Security testing – Why? (2)

Better: How well does the tested system meet specific security

objectives? Security policy needed!

Because it is required!

PCI-DSS (Payment Card Industry – Data Security Standard) 12 requirements are mandatory, including:

“11. Regularly test security systems and processes”

Internal and external vulnerability scans at least quarterly and after

every significant change in the network

Internal scans must be performed by qualified personnel

No “high risk” vulnerabilities may remain

External scans only by “Approved Scanning Vendors (ASVs)”

Network- and application layer penetration tests required

External and internal penetration test at least annually and after

every significant network change

No exploitable vulnerabilities may remain

10

Security policy

The start: No policy No security testing

Why?

Because we would not know what to test and what to reach!

Examples:

What if the policy specifies, that everyone can open an account for

free (= ad-sponsored service)? “Creating an account” is definitely not a security problem then!

Which parts of the website need to be kept “secret”/”internal”/

”for partners only”/”only after login”/…?

Backups may remain unencrypted, because they are physically

transferred by guards to a bank vault

Internal connections are unencrypted, because we cannot afford

the loss of speed Make especially sure that the perimeter is secure

11

Defining a security test (1)

A security test needs to be planned:

What do we want to protect? “Assets” are protected by “controls”, which have “limitations”

Examples: Internal network, web server, application X, …

“Internal network” is protected by “firewall”, which is “stateless”

What is the “engagement zone”, i.e. assets + protection

mechanisms + processes/services around it? Interaction with assets occurs there

Examples: Server + services + network

What is the “scope”? Everything needed to keep the assets operational, but outside the

engagement zone

Examples: Authentication servers, firewalls, cooling facilities, UPS,

personnel

12

Defining a security test (2)

How does the scope interact (=“vectors”)? Within itself and with the outside: Logical compartments

Assets: “Servers”, “Clients”, …

Directions: Inside-to-outside, department A to department B, …

Defines from where to where you have to test

What equipment will be needed? Five common channels, which all might be tested:

Human, physical, wireless, telecommunications, data network

Human: “Impersonators” needed; physical: lockpicks; wireless:

access points, clients, GSM scanners etc.; telecommunications: e.g.

IMSI catcher; data NW: wiretaps, interfaces, …

What information should be learned from the test? See test types below!

Do tests comply with the “rules of engagement” (=legal)?

13

Test types

14

Test types

Blind: No prior knowledge of attacker about target, but target knows

exactly that a test will take place

Ethical hacking; less a test of the security of the system than of

the capabilities of the tester!

Double blind (Black box test, Penetration test):

No prior knowledge of attacker about target or target about

attacker (nobody knows anything); “normal” attacker Not recommended for security testing!

Gray box: Limited knowledge about defences and assets, full

knowledge of channels exists at attacker; the target is prepared for

the test (vulnerability test)

Much more efficient, as information collection is reduced and

unsuitable attacks can be ignored

15

Test types

Double gray box (white box test): Similar as gray box, but the target

knows no details about the attacks, e.g. the channels tested or the

test vectors

Tandem (in-house audit, crystal box test): Both sides know all about

the test; they might even work together

Very thorough and efficient, but ignores “readiness” of target

Similar to code review and bug finding

Reversal (red team exercise): The tester knows all, but the target is

unaware. The main aim is to test the preparedness for attacks.

So less about “finding vulnerabilities”, but rather about alarm

systems, the IT departments reaction to alarms, collecting data

about attackers etc.

16

Attack awareness

Open test: Relevant staff knows about it

Limited impact and opportunity for training

Less risk of damages to live systems

Cheaper: Stealth needs time, some help (information) reduces

need for reconnaissance

More comprehensive: Everything is “found” and can be tested,

circumventing hard obstacles allows testing internal systems

without risk and through lower effort

Covert test: Only management knows about it

Especially useful for training and assessment of response

Full check of security policy

Simulates real attacks/attackers

More costly and less comprehensive

„Audit“

„Penetration test“

17

Properties of security tests

Intrusive: Can impact system, “real” test

Exclude potentially dangerous tests (but document this!)

Review/test: Inspecting documents/files/configurations, but not

checking whether reality matches them or whether they can actually

be exploited

No danger through the review itself, but no proof (test) either

Comprehensive/Selective: What/who will be investigated

Physical/personnel/network: What to investigate

Automatic/manual: Start a scanner or search manually

18

Rules of engagement (1)

What you may/must do during testing (and agree on before) And before: Marketing your services etc here omitted!

Also after: Report details see below!

Explicit written permission is required (target/other authority)

Obviously highly insecure/unstable systems may not be tested

until they are reasonably secured

Even without a NDA, confidentiality is required Both customer information (e.g. received for testing) and results

Limits and dangers of the test must be disclosed Both sides: “Dangerous” tests as well as systems that are critical and

may not be crashed/data downloaded etc!

Emergency contacts (names, phone, E-Mail, …) must be obtained

in advance ( when a test crashes a system, immediate action to

restore/secure is required, …)

19


Clear and specific permissions/guidelines for survivability failures,

DoS, process testing, social engineering are needed

Definition of scope: What systems are to be investigated and via

which channels

Safety, health, welfare, and privacy both within and outside the

scope must be respected and maintained. “Accidental finds” may only be used according to contract and legal

requirements

All laws must be obeyed Both at the physical location of the equipment tested and at the

physical location of the tester!

When testing with privileges: “Typical” accounts must be provided

Always test first without privileges, only then with them!

20


Tests on persons may only be performed on those identified and

never on private persons, customers, partners, associates, or

other external entities without written permission from both the

tested company and those entities

Testing may not negatively impact third-party systems Using third parties as DoS reflectors, filling up the ISP providers

bandwidth etc Use only private systems/channels for this

Unless explicitly agreed upon, e.g. leased equipment

“Agree”: Owner of equipment && user!

Note: Difficult to identify (perhaps banners)

When an intrusion was successful, the access must be closed

afterwards (after documentation/proof) As fast as possible if others (=real attackers) might benefit from this

too, e.g. temporarily disabling a security feature

The system must never be left more vulnerable than it was before

testing!

21


▪ Immediate report to the customer with a practical solution for all

significant problems that are discovered during testing, as these are

too dangerous to wait for the report:▪ Current breaches: Someone else is there as well…

▪ Vulnerabilities with known/high exploitation rates: Current attacks

▪ Vulnerabilities which are exploitable for full, unmonitored, or untraceable

access: Just too dangerous

▪ Vulnerabilities which may immediately endanger lives

▪ No involving third parties, except expressly authorized▪ E.g. external password cracking services, outsourcing parts of the test,

dropbox/cloud service for temporary storage of data, …

▪ Example: Create arbitrary text file and send it to dropbox

Evidence of possibility for data exfiltration; but send hashed

password directly

22

The authorization letter

A written and signed letter from the “appropriate person” who may

authorize a test. Could be the owner, manager, public official, CIO, …

Content:

Who will perform the test

When the test will take place

What the aim of the test is and which type it will be

What kinds of tests will be performed

What systems and/or persons will be targeted

Contact information for verification/alerts

Confidentiality requirements

Reasons to abort the test

Who is liable for what and to which extent

23

Performing tests

Every test should be

Planned: What exactly are we going to do? May we do it?

Reasoned: What advantage do we expect from it? Successful break-in? Confirmation of knowledge? Information?

Safe: What might happen to the them (target)? Nothing, alert, system crash, DoS, lost customer, …

(Undoable): Revert any changes (not: logs, …)

The outcome defined in advance: What will be a success/failure/inconclusive…?

See next slides!

Logged: For the report and because of potential liability

24

Test outcomes: Error handling

False positive: Determined as true, but is actually false

Attention: Depends on question! “Is the system secure?” “Yes”, but it does have problems

“Are there vulnerabilities?” “Yes”, but in reality it is secure

You should always test “<Specific security problem> exists?” “Erring on the safe side”

False negative: Determined as false, but actually is true

Example: “System is secure”, but something was not tested,

overlooked, the test applied incorrectly, …

Gray positive: Answers is always true, even if state is false

Security through obscurity: Does it really answer true for

everything you could ask (or only for what we tested)?

Gray negative: Answer is always false, even if state is true

25


Specter: Answer is random; independent of actual state

Often the case when the answer is in reality from somewhere else

or a third system influences the outcome

Indiscretion: Answer depends on when test is performed

Especially dangerous, as testing at the wrong time leads to

incorrect results

Example: Different behaviour during work hours and at night

Entropy error: Answer is lost or confused in signal noise

Rare in lab, common in practical use

Example: Ping times Depends on traffic of other systems

Human error: Answer depends on the skill of the tester

Lack of ability, experience, or comprehension

26


Falsification: Answer depends on how/where the test is performed

Difficult to identify, unless multiple ways/channels are tested

Sampling error: Only a part is tested, so the answer does not apply to

the whole system

Example: Definition of scope, what is to be tested

Constraint: Answer depends on the tools used

The tools are appropriate and work fine, but their margin of

error/constraints/limitations are ignored

Example: Precision is given too high

Propagation: Answer is assumed without test Naming: Errors introduced through this propagate to later tests

Experience or confirmation bias: “It must be like this!”

27

Security test results

Date and time of test, duration

Names of testers

Test type: Blind, gray box, …

Scope of test: Environment around the tested systems

Channel tested: Human, physical, wireless, TelCo, network

Test vector: From where to where, what was done/sent/…

Attack surface metrics: Visibility, trust, and access relative to the

scope (number of targets, how to reach them)

Which tests were (not/partially/fully) completed & to what

extent

Any issues regarding the test and the validity of the results

Error margins of the test/results

Any processes which influence the security limitations

Any unknowns or anomalies

28

Kinds of security tests

Penetration tests: Data network security

Try to break in like a hacker

Most common security test, as the number of potential attackers is

largest (and they can easily remain hidden!)

Often includes also wireless security

Social engineering: Personnel security

More expensive, and rare; most useful if you already have human

guards or in large organizations

Burglary: Physical security

Very expensive and extremely rare; normally an audit or a review

is sufficient

May include electromagnetic emanations

29

Penetration testing – What is it?

Test the complete system similar as an attacker would do

Attempt to violate the security policy Get in, steal data, stop service, … - whatever is to be prevented

Is conducted on the live system Therefore a potential problem to availability, customer data, …!

Difference to hacking: The authorization letter!

Typical approach:

Red team: The attackers; try to discover vulnerabilities

Blue team: Normal administration; try to detect/repel attacks May not know of their role!

White team: Produce a normal workload and capture results;

“arbiter” (management of target system)

30

Variations of Penetration testing

Simulated system, e.g. investigate test/backup

Typically problematic, as these are never exactly the same Different internet access, older SW versions, additional SW…

Additional information: See test types!

Helps to reduce initial work in discovery

Give the testers freely and immediately what they would otherwise

discover anyway after some work ( cost reduction)

System access provided

Test only elevation of privilege

The attacker got in, but can he achieve admin rights?

Internal attacker: Normal authorized user access provided

Increase privileges or violate the policy

31

Internal vs external attackers

External: Little knowledge to begin with

Reconnaissance is first step

Check external weaknesses & vulnerabilities (“Getting in”)

First target: Publicly available services

Huge number of potential attackers, most of them simple

Internal: Knowledge and some permissions present

Reconnaissance much easier or not needed

Weaknesses& vulnerabilities of internal systems Privilege escalation from provided credentials

Overcoming segmentation; data extrusion (“Getting out”)

Defence in depth: Sometime someone will get in, then …?

Specific targets for verification: configuration, individual system

hardening, compartmentalization, authentication, access control,

auditing (logging)

32

Penetration testing - Process

Several steps have to be performed in sequence

Reconnaissance/Foot printing Look, but don’t touch, gather information form 3rd party sources

Scanning/Discovery/Visibility What is there to potentially be attacked; only “legitimate” traffic

“Legitimate”: No attack itself, but might look uncommon/suspicious

Exploiting/Penetration “Illegal” traffic with a) actual attacks and b) including exploits

Data collection/”limited pillaging” Gather evidence of “being in” or information about vulnerability

Or other vulnerabilities: Getting back out, exfiltrating data etc.

Cleanup Restore security settings, so system is as secure as before

Reporting/presentation

33


Penetration testing is a layered process with loops

You start with some information

When more information/a first foothold has been obtained, the text

step it “attacked”

Typical: Some access allows retrieving encrypted/hashed

passwords; these can then be decrypted for further access

The aim of the test must make clear: Where to start: What is already known/achieved

Where to stop: Do we really have to try to break all passwords or can

we just assume, that someone will be successful?

34


http://www.isaca.org/chapters3/Atlanta/AboutOurChapter/Documents/Penetration%20Testing.pdf

35

Problems of penetration testing

No clearly defined process (only very general)

When are we finished? Should we continue looking?

Depends very much on knowledge & experience & perseverance

(and luck!) of tester

Several testers might be useful, depending on the systems to

investigate (specialists for web applications, the SAP system, DB

experts, Windows/Linux specialists, …)

Not predictable (or very coarse only): Time, effort

We cannot say when we are finished, as this depends on what is

actually found and how it can be used

Penetration testing looks for problems

It does not (directly) check whether security mechanisms

work/work at their best/are configured correctly

36

Penetration testing: What to test

What should we test?

Check with customer and use vulnerabilities as a guideline Everything which is known should be tested, as this will certainly be

done by attackers as well

Vulnerability scanners: Same tools as attackers!

Use lists of common problems as start CWE/SANS Top 25 most dangerous SW errors

http://www.sans.org/top25-software-errors/

OWASP top 10 Web application specific ( see course “Web security!”)

https://www.owasp.org/index.php/Top_10_2013-Top_10

Note: Many problems are not that difficult to avoid … Getting rid of the “easy” ones will help very much

Even simple penetration testing is very helpful there!

37

Reconnaissance / Foot printing

38

Reconnaissance & foot printing

Information sources:

Third-party websites, especially social networks

WhoIS information: Domains, IPs, ISPs

Job advertisements (especially for social engineering)

US: SEC EDGAR database (all SEC filings companies have to

send; mostly about publicly traded stock companies)

Austria: Firmenbuch (not free!)

Network sniffing – if possible

What to gather:

IP addresses/-blocks; domain names and their owner

Physical location of systems and their owner

ISP (or several ISPs, phone companies, leased line providers, …)

providing network access

39

What to gather (cont.)

IP addresses/-block, domain names of the same owners IP1 Owner of IP1 = Owner of IP2 IP2

Routing protocols used (internal/external)

Similar/mistyped domain names

Which DNs resolve to system outside of the owner’s control Caching devices, CDNs, external hosting, …

Which DNs/IPs are located outside the owner’s location

Reverse lookups: Where do they lead to?

Who controls the name servers/is the registrar?

Trace to the systems: Which other systems are on the path?

Timezone, holidays, work schedules for the locations of the

systems to be tested

Somewhere (security companies) shown as customer, testimonial,

or reference?

40

What to gather (cont.)

Help forums/discussion groups: Posts with E-Mails from this

company HW/SW used, problems, configurations, …

Parent companies and information on them

Recent mergers Attack sub-company and get in through new

cross-connection (which might be ad-hoc, unsecured…)

External connections (e.g. VPNs): partner/sub-companies

Internal computer names or modem access numbers? Social engineering: All internal telephone numbers, authentication

mechanisms (tokens?)

Dumpster diving: Discarded documents with passwords or other

information

Note: Technical information only

Regarding people/organization other things are relevant!

41

Scanning / Discovery / Visibility

42

Scanning process

Hosts: Which systems can be attacked?

Note: Port forwarding etc. find out where you actually are

Can be many, so some pre-selection may be necessary

Ports: Specific points of entry

Normally they specify the protocol as well, but this is not a

necessity; often uncommon ports are used (e.g. 8080, 8000, … for

WWW instead of 80)

Services: What application is behind the port

Webserver, mail server, …; which SW/version, …?

Vulnerabilities: Depending on service, SW, and version

Try common vulnerabilities as they are documented

Try common misconfigurations

43

Pitfalls and traps

Beware of traps or false information!

Information may be outdated, e.g. DNS person information may

not have been updated for many years Presenting yourself as “Mr. X, the admin” is bad, if “X” was fired

several years ago!

Traps: Some information may be intentionally incorrect, so (at

least some) persons can identify attacks immediately “Hidden” webpages with wrong information

E.g. “Disallow” entries in robots.txt with alert if accessed

Honeypots of all kinds (network, websites, E-Mail address, …)

Only for “automated users”, never shown/applicable to humans

Infinite loops: Links no user would click on

Tar pits: Delay tests if too many come in (additional captcha, low

priority, … Doesn’t hinder real users too much!)

False vulnerabilities, fake authentication methods/credentials

44

Scanning

Ping sweep: What systems are online/reachable Including broadcast requests/responses

Port scans: Not every system responds to ping… Also: Which services do these systems provide?

Including responses to packets with specific source, e.g. UDP 53

(=fake and unsolicited “DNS response”)

Identify the actual daemon & application behind open ports

Identify local time of system

Identify operating system, processor architecture (x86/PowerPC,

ARM, …) and bitcount (32/64)

Identify version numbers of software used Especially via banners

Connection speed of system and properties (TTL, ping time)

Load balancing, caching, traffic shaping, QoS/Quotas

45

Scanning (cont.)

Existence of third-party filtering: URL filtering of web access, virus

scanning, IDS, spam scanners, … Both for incoming and outgoing traffic

Including how the updates/live connection is arranged

Service banners: Version numbers, SW Verify through valid and invalid requests

SNMP community names: Trying/testing Especially default/common/device-specific ones

Send mail which is certainly going to be rejected/returned Analyse the response (or if nothing is returned)

Check for responses of common malware (already installed!)

Identify all points where authorization is required for access Find out usernames, if possible, as well as authorization

means/procedure (password, token, both, …)

46

Scanning (cont.)

Spoof address to come from a trusted/internal system

Mirror of website

Check robots.txt for excluded content

NetBIOS enumeration (when already in LAN)

IPC$ - Default share allows access to list of users, groups, …

Password requirements: Complexity/frequency/history

47

Network scan types

Port scanning: Which ports are open

Typical tool: nmap

Ports: 0…1023 (well-known/reserved; standardized),

1024-49151 (registered; can be used for various services),

49152-65535 (dynamic/private; clients only) – THEORY! List: See http://www.iana.org/assignments/service-names-port-

numbers/service-names-port-numbers.xhtml

However, many different kinds of scans are possible

Note: Source IP address is visible for all kinds of direct scans The only chance is to spoof them (but then seeing the replies is

problematic!), or use a “proxy” (which can be identified, but you don’t

care as it cannot be traced back to you)

48

Network scan types (TCP)

Full scan: Three-way handshake

Start a complete TCP connection, then close it

Will typ. leave lots of traces in logs (“Connection lost”)

SYN scan: Send a SYN packet only and wait for response

“Half-open scan”: SYN/ACK: Port is listening Send RST

Most sites do not log such “connections” Not “established”!

FIN scan: Send a FIN packet only (no SYN!)

FIN packets pass through many firewalls

Closed ports reply with RST, open ports ignore them According to RFC; firewalls often ignore it (and such packets!)

Most sites do not log such “connections” Not “established”!

49

Network scan types (UDP)

UDP scans are problematic:

Open ports do not have to send an ACK Some protocols my send some reply, but that may also depend on

whether the packet (content) received is “acceptable” (=correct syntax

& semantics etc)

Closed ports do not have to send an error message Most hosts do send “ICMP – Port unreachable”

Classic filtering on firewalls / deactivated on firewall

Outgoing ICMP messages are limited Slow scan required

Result: You can sometimes find out when a port is definitely closed

You can sometimes find out when a port is definitely opened

Most of the time you don’t find out anything

50

Stealth scan

Port scanning is very “noisy”, and therefore suspicious

Strategies to keep inconspicuous:

Delays (days!) to spread traffic sScan takes very long

Special techniques to keep out of logs Drawback: If detected, this is a clear sign of an attack!

Examples: SYN or FIN scans, fragmented packets, …

Drowning: Sent huge amount of scans with fake sources and one

with correct ones Target cannot decide which target IPs are the “real” source

Target will definitely know that something is going on!

51

Other scan types

These are in clear violation of the standard!

Null scan: No flags set at all

Closed ports should reply with RST

Mostly works for Linux variants only

Xmax scan: Most (FIN, URG, PSH ) or all flags set

Closed ports should reply with RST

Mostly works for Linux variants only

ACK scan: Acknowledge flag alone set

Variation: Other scan with ACK set. Stateless packet filtering will

allow this to pass as an “established” connection, but stateful

filtering will throw it out!

Variant: Window scan. Variations in window size may allow

detection of open/closed/filtered (few OS affected)

52

Idle scan

Completely stealthy scan – not sending any packet “directly” to the

system to be queried!

But will only work rarely today, because of prerequisites!

Requirements: We need a decoy (“zombie”)

Note: This is not a “real” zombie, all that is required is: It must be running and reachable from the attacker

It is unused (=almost no traffic to/from it)

It assigns IP sequence numbers sequentially and globally

Modern OS use random numbers, not globally, and not sequentially,

but older or simple devices (IoT!), e.g. printers/cameras/network

devices might still be useful

Result: Any attack (=port scanning) will appear to come from the

zombie and no investigation (on the target) will reveal the actual

source (and the zombie won’t have logs!)

53

Idle scan – How it works

Step 1: Send a packet to the zombie and note the IP ID in the reply

packet (we don’t care about this packet at all!)

Step 2: Send a SYN message to the target with the source IP

spoofed to come from the zombie

Step 3: Target will respond with a SYN/ACK to the zombie

Step 4: Zombie will send RST to target (connection unknown!)

This will increment the IP ID on the zombie

Step 5: Send packet to zombie and note returned IP ID

Incremented by 1? Target did not reply!

Incremented by 2? Target did send a packet back!

Repeat several times if inconclusive

As some traffic is always going to exist at the zombie

54

Idle scan - diagram

Attacker Zombie Target

SYN/ACK (ID probe)

RST (ID=12345)

SYN (SRC = IPZombie)

SYN/ACK (Open port)

RST (ID = 12346)

SYN/ACK (ID probe)

RST (ID=12347)

RST (Closed port)

SYN/ACK (ID probe)

RST (ID=12346) Filtered ports: Same as closed

(Target does not respond at all,

so zombie does not increase ID)

55

Exploiting / Penetration

56

Exploiting

Use vulnerability scanners, like Nessus, OpenVAS, …

They are very general frameworks with lots of plugins

Each plugin models a single vulnerability What exactly to send and a test whether it succeeded

Might also contain elements to actually “get in” This is called a “payload”, typically a remote shell or some

phone-home program to load and run additional code

In many cases this must be tiny, so a dual/multi-stage approach is

taken to transfer ever larger SW to the target system

Example: Metasploit

Manually search for problems

Very difficult and needs lots of experience and intimate knowledge

of the actual target system (OS, HW, SW…)

57

Vulnerability scanners

Automation is useful and often necessary

These are used by attackers too What they find will definitely

be found by them too!

Advantages:

Very quick: They only try vulnerabilities Allows frequent scanning; ideally against baseline (=last scan)

False positive rate typically low

If lengthy tests are performed (e.g. fuzzing), they can work

unattended and during times of lower normal system load

Some can work distributed, i.e. from different systems to one

target or several targets simultaneously

58

Limitation of vulnerability scanners

Up-to-date version with the latest vulnerabilities needed

This might be costly/unavailable in free versions

Should allow automation, e.g. comparison to previous result, scan

profiles (non-destructive only), scripting (add own

vulnerabilities/strategies) etc.

Require logic: Apache exploits useless when attacking IIS

So the system/SW must be discovered/configured first!

Need some preparation and experience to be useful

What systems to scan, which vulnerabilities to try, what to

exclude; false positives must be removed afterwards

Network security testing is good, as vulnerable SW is “common”, but

bad for application security (especially custom ones)

Serious problems are often "specific”

59

Elements of exploits/penetration

Obtaining credentials:

Social engineering: Just ask for them

Thievery: Get in and filch HW tokens, disks, computers …

Brute force: Just try long lists of potential names/passwords Recon. helps: What usernames exist? How are they generally built?

How long are passwords? Complexity requirements?

Cracking: Recreate passwords from hashes/encrypted forms

Reuse: All passwords found anywhere should be tried at all

possible authorization points and in several variations

Default accounts: Check them all!

Check if caches can be poisoned, especially DNS

If local access (already): ARP caches as well

Allows man-in-the-middle attacks on websites, so users e.g. enter

their password on “your” site

60


Check all ways/versions of authorization “recovery”

“Reset password” links/E-Mails, helpdesks, …

Prepare answers for common security questions from foot-printing

(mother’s maiden name, pet name, license plate, …)

Encryption: Check whether correctly applied

Downgrade attacks: “Sorry, I cannot do ANY encryption!”

Verification of certificates: Issuer/Fingerprint/… or only

mathematically correct ( use a self-signed certificate!)?

Old/very weak encryptions (ZIP passwords, Backup pwds…)

DoS: Continuously raise alarms Turned off?

Or is your IP blocked after some time (and when/how long)?

Can we inject data?

SQL injection, log injection, …

61


Especially investigate all unused services

What exists, but is not really used, is probably largely unmonitored

and not updated!

Test all web applications

Most companies have several, public as well as internal ones Most of them are (partially) custom and must therefore be tested

manually (no “known” vulnerabilities!)

Client-side exploits

Send programs as attachment by mail and try to get users to

execute this program

Send links to them and hope they will click on them

Drop prepared memory sticks and hope they will be inserted

Wireless attacks

62

Password attacks

Try passwords already discovered somewhere else

People reuse passwords very often!

Ideally: Same person & same company (less: private)

Less good: Dictionary or lists of passwords from other hacks

Brute force attack: Try all possible combinations

Only useful for very short passwords or where length and

character set is exactly known

Hybrid checks: Use known password (or dictionary) plus variations

(e.g. “e” “3”, “O” “0”; append “1”, …)

Shoulder surfing: Try to watch someone enter the password (at least

length and approximate character set)

Useful: Spy cameras (“pens”, “car keys”, …)

63

Weak passwords

Dumpster diving: E-Mails often contain passwords and are printed

out; also look for notes from admins

In my opinion less useful for passwords, more for general

information and preparation for social engineering!

Try common passwords: Blank or single space, “password“,

“company name/abbreviation”, “physical location/city”, “12345[678]”,

“qwerty/z”, “abc123”, “111111”, “iloveyou”, “admin”, “letmein”,

“monkey”, “shadow”, “sunshine”, “princess”, “trustno1”, first name of

user, “2580” for phones

With requirements: “Password1”, Season+Year, Month+Year,

incremental numbers, …+”123”, common first name+”1” etc.

64

Social engineering

Deception, misrepresentation, and persuasion

Get someone to do something that he/she is allowed to do and

generally should do, but nor for you

Especially in large companies not everybody knows everyone: “new

employee”, “janitor”, “technician”, …

Or just mingle (smoking is good outside follow in)

Sell a new security system and ask what they currently have

Exploit helfulness: The help desk is (generally and usually) there to

help people, not to turn down their requests

Or simply bribe them: Not part of typical security tests!

Main targets:

Get inside access: Plug in small computer to internal LAN

Search offices, install bugs/keyloggers, use unlocked PCs…

65

Data collection / Limited pillaging

66

Collecting data

Two aspects:

Evidence that the attack was successful Very little data is already sufficient

Often also small modifications introduced as evidence

Make sure to save the original and that they do not pose a problem

in the meantime (e.g. changing blood group in medical DB!)

Take care that this data remains secret

Information/possibilities for further attacks (next level) Make sure that it is ONLY used for this!

Introducing programs: Tools for further attacks

Installing rootkits, shells, keyloggers etc.

Documentation absolutely necessary for deletion!

67

Cleanup

68

Cleanup

Remove all added accounts/backdoors/rootkits/…

Includes any permissions added

Remove all added files (and restore deleted, if any)

Make sure to use secure delete (if possible)

Restore all changed data, especially configuration

Enable all security measures that were turned off

Reset firewall rules, switch on IDS, start/stop services …

But never (unless explicitly requested):

Clean log files (might be needed later - less of a security problem

in itself, except if publicly available)

Reset any alerts that occurred (= e.g. evidence of scan might be

needed for audit!)

69

Reporting / Presentation

70

Report

Executive summary (1 page at most!)

Objectives, assumptions, and restrictions

What was to be tested and how; what was not to be tested

Timeline: Start and end

Everything outside is not the testers responsibility!

Details:

Which approach was followed and which tools were used

What was detected at which system (and what not)

What could follow from this (potential danger/damage) And was it only found or actually tested?

What is the likelihood/prerequisites for successful exploitation?

Summary of findings and recommendations

Make sure delivery of the report is secure

71

Report

Other important content (not separate chapters):

Who did the test and from where E.g. source IPs (so they can be excluded in logs/later tests)!

Any intermediate changes made to the systems and why these

were acceptable and did not pose a security problem

Changes not undone

References, appendices (screenshots, tool output, CVE lists …),

glossary

Version of the document

Review/approval information, classification, “copy X of Y”, …

Copy of authorization letter

Non-content (may never be in or must be masked!):

Personal information, passwords, …

72

Executive summary

Background: Purpose of test (audit; internal/external…)

Overall result, especially regarding processes

Obligations fulfilled/certification granted/…

Risk ranking: How many problems of which large class were found

by the investigation

Class might be risk (critical, high, medium, low) or other (patch,

WWW, guessable credentials etc.)

Recommendation: What to do and in which timeframe

Prioritized roadmap (very high level)

E.g.: 1/6/12 month; “Establish security policy/enforce password

guidelines/patch servers X and Y/new audit/…”

73

Report appendix: Information gathering

Passive intelligence: Obtained from third parties

Reconnaissance, foot printing

Active intelligence: Obtained from target (e.g. scanning)

Corporate/personnel intelligence: Data on company or specific

persons Social engineering

“Superfluous” data: Devices/services that should not be there, e.g.

access points, clients (mobile phones, servers), additional web

directories, …

Not main target, but will typically show up on scanning and can

often (e.g. data provided) be identified as unauthorized

Can be used for removal or as help for next security test!

74

Report: Vulnerability assessment

Vulnerability classification levels: Too many exist Which one is

used (may be many; each tool might have its own!)

Individual vulnerabilities:

How found, where found, exposure

Confirmation: Success, time required, result privileges/data For non-deterministic vulnerabilities: Success/failure ratio

Example: Phishing, client-side attacks (USB sticks, browser, …)

Type: Local and/or remote, authentication needed, …

Impact on target: What data could be gained, DoS, … Ability for persistence, exfiltration

Probability of detection (IDS, logs, …)

Escalation path: What could be done from here on further

Remediation: Reference to vulnerab. DB, documentation, … Might also include mitigation techniques

75

CVE

Common Vulnerabilities and Exposures

List of publicly known vulnerabilities (=concrete)

Big advantage: Assigns them a number which is often used Standard name and cross-references to other names

Each entry (“CVE-ID”) consists of three elements: Since 1.1.2014 the number was extended (previously: max. 9999

vulnerabilities per year were possible; always 4 digits)

Unique ID CVE prefix: “CVE-”, Year (4 digits), Sequential number: Minimum of 4

digits (“0001”), extension when necessary

Example: “CVE-2014-4744”: Number 4744 in year 2014

Description

References: Numbers at other places like security providers, bug

fixes/reports, …

76

Example: CVE-2014-4744

Multiple cross-site scripting (XSS) vulnerabilities in osTicket before

1.9.2 allow remote attackers to inject arbitrary web script or HTML via

the (1) Phone Number field to open.php or (2) Phone number field,

(3) passwd1 field, (4) passwd2 field, or (5) do parameter to

account.php

References: MISC:https://www.netsparker.com/critical-xss-vulnerabilities-in-osticket/

CONFIRM:https://github.com/osTicket/osTicket-1.8/releases/tag/v1.9.2

SECUNIA:59539

URL:http://secunia.com/advisories/59539

77

JOHANNES KEPLER

UNIVERSITÄT LINZ

Altenberger Straße 69

4040 Linz, Österreich

www.jku.at

Michael Sonntag

[email protected]

+43 (732) 2468 - 4137

S3 235 (Science park 3, 2nd floor)

https://www.ins.jku.atTHANK YOU FOR

YOUR ATTENTION!

Literature

Open Source Security Testing Methodology Manualhttp://passthrough.fw-

notify.net/download/610846/http://www.isecom.org/mirror/OSSTMM.3.pdf

79