Intruders and Intrusion Detection

Mahalingam Ramkumar

Intruders

A significant issue for networked systems hostile or unwanted access

either via network or local

Classes of intruders:masqueradermisfeasorclandestine user

Varying levels of competence

Intruders

Growing and much publicized problem “Wily Hacker” in 1986/87 escalating CERT stats

May seem benign, but still costs resourcesMay use compromised system to launch other

attacks

The Wily Hacker

Lawrence Berkeley Lab (LBL) - 1986 – 87Decided to observe attacker after detectionCollaborative efforts of FBI and many military

organizationsOff-line monitors to track everything done by

the attackerAnalyzed by computers “loosely” coupled to

the LANNot a very sophisticated attacker

The Wily Hacker...

Just used known and widely reported flaws in O/S es and applications (emacs, vi)

Traceback was probably a lot simpler in those days Not too many “entry” points into the InternetEntry points were usually banks of modems

Attacker simultaneously using several entry pointsPhone records!

The Wily Hacker...

Provided various “baits” to the attacker to enable traceback

Traced back to many locationsUltimately traced back to GermanyUsing LBL as the base of operations WH had

compromised computers in various other organizations and universities.

Spy???Rumored to have been funded by KGBThree arrests made in 1988.

Intrusion Techniques

Aim - to increase privileges on a systemBasic attack methodology

target acquisition and information gathering initial access privilege escalation covering tracks

First step is to acquire passwords then exercise access rights of owner

Password Guessing

One of the most common attacksAttacker knows a login ID (from email/web page etc) Then attempts to guess password

try default passwords shipped with systemstry all short passwordssearching dictionaries of common wordsintelligent searches - try passwords associated with the user (variations

on names, birthday, phone, common words/interests) exhaustive search of all possible passwords

Check by login attempt or against stolen password file Success depends on password chosen by user

Many users choose poorly

Password Capture

Another attack involves password capture watching over shoulder as password is entered using a trojan horse program to collectmonitoring an insecure network login (eg. telnet, FTP, web,

email) extracting recorded info after successful login (web

history/cache, last number dialed etc)

Using valid login/password, can impersonate userUsers need to be educated to use suitable

precautions/countermeasures

Intrusion Detection

Not perfect - inevitably will have security failures

Need to detect intrusions block access / processes if detected quicklyact as deterrentcollect info for improving security

Assumption - intruder behaves differently (from a legitimate user)may not always be a valid assumption

Approaches to Intrusion Detection

Statistical anomaly detectionthresholdprofile based

Rule-based detectionanomalypenetration identification

Audit Records

Fundamental tool for intrusion detectionNative audit records

part of all common multi-user O/Salready available for usemay not have the required info in desired form

Detection-specific audit recordscreated specifically to collect required infoat cost of additional overhead on the systemsubject, action, object, exception-conditions,

resource-usage, time-stamp

Statistical Anomaly Detection

Threshold detectionCount occurrences of specific event over time

if exceeds a reasonable value - assume intrusion

By itself a crude & ineffective detector

profile basedcharacterize past behavior of usersdetect significant deviations from thisprofile usually multi-parameter

Audit Record Analysis

Foundation of statistical approachesAnalyze records to get metrics over time

counter, gauge, interval timer, resource use

Use various tests on these to determine if current behavior is acceptablemean & standard deviation, multivariate, markov

process, time series, operational

No prior knowledge used

Rule-Based Intrusion Detection

Observe events on system & apply rules to decide if activity is suspicious or not

Rule-based anomaly detectionanalyze historical audit records to identify usage

patterns & auto-generate rules for themobserve current behavior & match against ruleslike statistical anomaly detection - does not

require prior knowledge of security flaws

Rule-Based Intrusion Detection

Rule-based penetration identificationrules identify known penetration, weakness

patterns, or suspicious behaviorrules usually machine & O/S specificrules are generated by experts who interview &

codify knowledge of security adminsquality depends on how well this is donecompare audit records or states against rules

Base-Rate Fallacy

An intrusion detection system needs to detect a substantial percentage of intrusions with few false alarmsif too few intrusions detected -> false sense of

securityif too many false alarms -> admins will start

ignoring alarms

This is very hard to doExisting systems do not seem to have a good

record!

Base-Rate Fallacy - Example

Accuracy of a test for detecting disease D is 85%If D, Pr{+} is 0.85If not D (or W) – Pr{+} is 0.15

D occurs only amongst 1% of the populationLet us say some one test positive for D – what is the

probability of false alarm?False alarm occurrence = A = Pr{+ / W} Pr{W} Total occurrences = B =[Pr{+ / W} Pr{W}] + [Pr{+ / D}Pr{D}]A = 0.15*0.99 = 0.1480, B = 0.14850 + 0.85*0.01 = 0.157A/B = Pr{False Alarm} = 94.6% If Pr{+ / W} = 0.99 then Pr{False Alarm} = 0.5

Distributed Intrusion Detection

Traditional focus is on single systemsbut typically systems are networked

More effective defense has these working together to detect intrusions

Issuesdealing with varying audit record formatsintegrity & confidentiality of networked datacentralized or decentralized architecture

Distributed Intrusion Detection – Architecture (UC Davis)

Distributed Intrusion Detection – Agent Implementation

Honeypots

Decoy systems to lure attackersaway from accessing critical systemsand collect information of their activitiesand to encourage attacker to “stay on system” so

administrator can respond (or traceback)

Fabricated information Instrumented to collect detailed information on

attackers activitiesMay be single or multiple networked systems

Password Management

Front-line defense against intrudersUsers supply both:

login – determines privileges of that userpassword – to authenticate them

Passwords often stored encryptedUnix uses multiple DES (crypt(3) – DES variant

with salt)more recent systems use cryptographic hash

functions

Managing Passwords

Need policies and good user education Ensure every account has a default password

different default passwords for different privelege levels

Ensure users change the default passwords to something they can remember

Protect password file from general accessSet technical policies to enforce good passwords

minimum length (>6) require a mix of upper & lower case letters, numbers,

punctuation block know dictionary words

Managing Passwords...

May reactively run password guessing tools note that good dictionaries exist for almost any

language/interest group

May enforce periodic changing of passwords Have system monitor failed login attempts, & lockout

account if too many attempts are seen in a short period

Need to educate users and get support Balance requirements with user acceptance Be aware of social engineering attacks

Proactive Password Checking

Most promising approach to improving password security

Allow users to select own passwordBut have system verify it is acceptable

simple rule enforcementcompare against dictionary of bad passwordsuse algorithmic models (markov model or bloom

filter) to detect poor choices.

Protecting Passwords

SSL/TLS● Send username/passwords only over

protected channelsOne-time passwords● User generates a hash chain● User starts with x0, computes x1=h(x0) , x2=h( x1)⋯xn=h( xn−1)

xn stored by the server First login user sends xn−1

Server verifies h( xn−1)=xn and stores xn−1

Next login user sends xn−2

Server verifies h( xn−2)=xn−1 and stores xn−2

and so on for n logins

Challenge-Response Protocols With Weak Secrets

● Challenge-response using weak secrets (like passwords)

– Challenge-response should not reveal weak-secret– Convenient to use the weak secret to establish a

strong secret.● Assume client and server share a weak secret

(password) W– C-> S: K_W=E(W,K). Encrypt a secret K using the

weak secret W as key– S: K=(W,K_W); h_K= h(K)– S->C: h_K, indicating server has decrypted K as it

has access to secret W● Issues?

Brute Forcing Weak Secrets

● Attacker has access to K_W=E(W,K) and h_K

● Attacker can easily brute force the weak weak secret.

● For every possible weak secret W'– Check if h(D(W',K_W))=h_K– The value W' for which the above relationship is

satisfied is the actual weak secret.

Encrypted Key Exchange

● Client generates asymmetric key pair (R,U)● Encrypts public key U using password W– C->S: U_W=E(W,U)

● Server decrypts public key as U=D(W,U_W)● Server choose secret K, encrypts using public key

U of client; – C->S: K' = E_U(K). Client can decrypt K=D_R(K')

● Server and client – Have confirmed that they both have access to the

password– Have established a strong secret K

EKE

● Attacker has access to U_W=E(W,U) and K'=E_U(K).

● Attacker brute forces different values of W to get different candidate U's

● However this does not help attacker determine K

● Not so fast!– Attacker may only need to know U_W – IF the public key U has a known structure

EKE

● If the public key is easily distinguishable from a random value

– Only the correct W' will yield a valid public key● For example, let public key U be RSA modulus● For different choice of W' attacker will get different

random U' ● But a random U' will not have the structure required

for a RSA modulus– A large number that is almost impossible to factorize– And can be easily recognized as not being a prime (by

doing Fermat's test)

EKE

● Work Around– Generate RSA with large encryption exponent e

● Do not encrypt modulus n, only encrypt exponent e● Most random numbers cannot be distinguished from a

valid encryption exponent (any odd number can be an encryption exponent)

– Use Diffie Hellman– Any number can be a valid public key

● Bottom line...– Do not encrypt any known value or any non random value

using a weak secret– Else, weak secret can be brute-forced easily.

α=gamod p