Access Control & Malware · Traceability Generating Secrets Usability Foundations of Cybersecurity 2016 Keep it simple. The security of a system should not depend on the secrecy of

Prof. Dr. Michael Backes

Access Control & Malware

Organizational Issues

Correct formatting (Tutorial group 1, Exercise 1):

[1][Exercise 1]

1Foundations of Cybersecurity 2016

No additional whitespaces! No <>!

New submission mail address to avoid confusion:

[email protected]

- Different prefix than regular mailing list

- Old submission addresses still work

Exercise groups started on Wednesday

mailto:[email protected]

Organizational Issues

Foundations of Cybersecurity 2016

Solution to exercise 1 leaked over the mailing list

- Exercises are considered (small) examinations

- Influence final grading

We will soon require you to run a virtual machine…

- Do you have a laptop?

- If not, email to [email protected]

Linux Essentials Tutorial by our tutors

- Office Hour slot: Tuesday 13 – 14, Building E1 3, CIP-R 012

We have to drop exercise 1 from the grading

mailto:[email protected]


Recap: Principles & Authentication

Recap: Chapter “System Security” Overview

Practical security (How to exploit vulnerabilities?)

- Security principles

- Basic design of (in-)secure systems

- Basics of access control, malware

- How to hijack control in computer systems?

- How to defend against such control hijacking attacks?

- Authentication methods

Project: Learn about basic control-flow hijacking

Some advanced topics are part of follow-up lectures


Recap: Security Principles

Simplicity

Open Design

Compartmentalization

Minimum Exposure

Least Privilege

Minimum Trust and Maximum Trustworthiness

Secure, Fail-Safe Defaults

Complete Mediation

No Single Point of Failure

Traceability

Generating Secrets

Usability


Keep it simple.

The security of a system should not depend on the secrecy of its protection mechanisms.

Organize resources into isolated groups of similar needs.

Minimize the attack surface a system presents to the adversary.

Any component (and user) of a system should operate using the least set of privileges necessary to complete its job.

Minimize trust and maximize trustworthiness.

The system should start in a secure state and return to a secure state in the event of a failure.

Access to any object must be monitored and controlled.

Build redundant security mechanisms whenever feasible.

Log security-relevant system events.

Maximize the entropy of secrets.

Design usable security mechanisms.

Recap: Authentication

Identification is whom you claim to be

Authentication is how you prove your ID

- Credentials: Evidence used to prove the ID

- Usually a prerequisite for authorization to use system resources

Forms of authentication

- Something you know(e.g., a password)

- Something you have(e.g., smart card, TAN generator)

- Something you are(e.g., fingerprint)

- Combination of those above(e.g., two-factor authentication for online banking)


Recap: Basic password scheme

Cryptographic hash function h: strings strings

- Given h(password), hard to find password

- No known algorithm better than trial and error

User password stored as h(password)

When user enters password: compare hash instead of plaintext


Input space Output space

Collisions

{0,1}ℕ ???

Recap: Salting

Salting:

[Alice, saltA, h(passwordAlice || saltA)],[Bob, saltB, h(passwordBob || saltB)], …

Salt is random for every user

With salt:

- One password hashed 248 different ways (8 character salt)

• Pre-compute hash file?

- Need much larger file to cover all common strings(248 pre-computed hashes per possible password storage problem)

• Dictionary attack on known password file

- For each salt found in file, try all common strings

- Important: Salt like password hash are publicly readable

No “Break once, break everywhere”-condition


Recap: Biometrics

Use a person’s physical characteristics

- fingerprint, voice, face, keyboard timing, …

Advantages

- Cannot be disclosed, lost, forgotten

Disadvantages

- Cost, installation, maintenance

- Reliability of comparison algorithms

• False positive: Allow access to unauthorized person

• False negative: Disallow access to authorized person

- Privacy?

- If forged, how do you revoke?


Recap: Token-based authentication

Several configurations and modes of use

- Device produces password, user types into system

- User unlocks device using PIN

- User unlocks device, enters challenge

Example: S/Key

- User enters string, device computes sequence

• p0 = hash(string|rand); pi+1 = hash(pi)

• pn placed on server; set counter k = n

- Device can be used n times before reinitializing

• Send pk-1 = to server, set k = k-1

• Sever checks hash(pk-1) = pk , stores pk-1


Recap: Two-Factor Authentication

Combine two of the three types of authentication

Use second factor to work around limitations of first

Important security requirement:Both channels are independent from each other, socompromise of one channel does not compromisethe other

Examples:

- Online banking password plus generated TAN

- Online banking password plus mTAN(unless banking done on same phonethat receives mTAN)

- Account password plus authenticator

- RSA SecurID card plus PIN



Access Control Concepts

Access Control Concepts

Access control fundamentals

- Protection System

- Reference Monitor

- Security Models


Threat Model

Threat Model

- Defines set of operations that an attacker may use to compromise a system

• Usually: Inject operations from the network and be in control of some processes

- Commercial OSes: Assume that any software running on behalf of a subject is trusted by that subject (i.e., has the subject’s privileges)


Access Enforcement Mechanism

Authorizes requests by subjects to perform operations on objects

Two important components:

1. Reference Monitor

• Access enforcement mechanism

- Example: Part of the virtual file system in the OS

2. Security Policy

• Rules to describes the operations that a subject can perform on objects

• Defines how the rules can be modified


Reference Monitor

Assumption: System knows who the subject is

- Authentication via name and password, other credential

Access requests pass through gatekeeper (“reference monitor”)

Needs to fulfill well-defined properties


Object(e.g., Resource

like File)

Subject(e.g., User process)

Reference monitor

access request

Security policy

authorized?If authorized

Reference Monitor: Properties


Complete Mediation

System must not allow monitor to be bypassed

Tamperproof

Monitor must be protected from compromise

Verifiable

Monitor should be small enough to be analyzed. It should be verifiable that the system provides its security goals.

Physical Access Control

Everybody in this room probably carries a special „key“ ...

Student ID

- Open doors

- Pay at mensa

- Get access to car park


“Reference monitor”

Foundational papers


1971

1975

Access control matrix [Lampson]

Columns: Objects

Rows: Subjects

Cell (s,o) with s ∈ Subjects and o ∈ Objects: Access rights of subject s for object o

- In example: access rights from {read, write}


File 1 File 2 File 3 … File n

User 1 read write - - read

User 2 write write write - -

User 3 - - - read read

…

User m read write read write read

Subjects

Objects

(User 1, File 1) = “read”:

User 1 can read File 1

How to store access rights: ACL vs Capabilities

Access control list (ACL)

- Object-centered: Associate each object with list

- Reference monitor checks subject against list ofaccessed object

- Relies on authentication: need to know user

Capabilities

- Subject-centered: Capability is unforgeable ticket (token) that defines the privileges of its holder

• Usual implementation: random bit sequence (reference), or managed by OS

• Can be passed from one process to another

- Reference monitor checks token

• Does not need to know identity of user/process


File 1 User A User B

read

write

read

Inheriting Access Rights and Capabilities

ACL: Inherit privileges through subject identity (here User ID)

- E.g.: U = unprivileged user,P = privileged user


Process X

User P

Process Q

User P

Process R

User U

Process X

Capability c,d

Process R

Capability c

Process Q

Capability c

Capability: Inherit privileges through capability token

- E.g.: c = read files, d = write files

ACL vs Capabilities

Delegation: Assign (“delegate”) privileges to another subject

Revocation: Remove privileges from a subject


CapabilityACL

Delegation

Revocation

Process can pass on capability at run time

Try to get owner to add permission to list?More common: let other process act under current user

Try to get capability back from process?Possible in some systems if appropriate bookkeeping• OS knows which data is

capability• If capability is used for

multiple resources, have to revoke all or none …

• Other details …

Remove/modify cell in ACL for revoked resource(s) or remove row of user from ACL

Roles

How to scale this to multiple users?

- One rule for every user?

Role = set of users

- Administrator, PowerUser, Users, Guest

- Assign permissions to roles; each user gets permission

Role hierarchy

- Partial order of roles

- Each role getspermissions of roles below

- List only new permissionsgiven to each role


Administrator

Guest

PowerUser

User X User Y

(also called Groups)

Role-Based Access Control


Individuals Roles Resources

engineering

marketing

human res

Server 1

Server 3

Server 2

Access Control Types

Personally vs

Keys for your flat

- You can give arbitrary people access

Login to your laptop

- Biometric profiles managed by yourself

- You can add new people


Centrally-Managed

Keys for your office

- You are not allowed to replicate

Iris scan for high security rooms

- Managed by company

- Only IT department can grant access

Access Control Types

vs

Keys for your flat

- You can give arbitrary people access

Login to your laptop

- Biometric profiles managed by yourself

- You can add new people


Keys for your office

- You are not allowed to replicate

Iris scan for high security rooms

- Managed by company

- Only IT department can grant access

Discretionary vs Mandatory Access Control

Discretionary vs Mandatory Access Control

Discretionary Access Control (DAC): Later

- Subjects can freely delegate/revoke/modify access rights to objects for which they have certain access rights, e.g.

• that they own

• for which they have a capability

- We will see the Unix implementation of this in a few slides

Mandatory Access Control (MAC): Now

- Security policy set and modified centrally by trusted administrator

- Users and untrusted processes cannot override the policy (e.g., delegate rights if not allowed by policy)

- Subjects and objects usually labeled with security attributes

- Access rules describe allowed operations between labels

- Transition rules describe how labels of subjects/objects can change


Multi-Level Security (MLS) Concepts

Military security policy

- Classification involves sensitivity levels, compartments

- Do not let classified information leak to unclassified files

Group individuals and resources

- Use some form of hierarchy to organize policy

Bell-LaPadula Model

- Primarily for military/government MLS

- Control information confidentiality: “No read up, no write down”

• Subject cannot read an object of higher security level

• Subject cannot write to an object of lower security level


Military Security Policy

Subjects and objects have one sensitivity level and a set of categories

For example:

- Levels: Unclassified < Restricted < Confidential < Secret < Top Secret

- Category: Crypto, Planes, Troops, Submarines

To read an object, a subject must have at least as high a sensitivity level as the object and must be cleared for each category (“no read up”)

- To write: Complement of this rule (“no write down”)

Example: Who can read which file(s)?


File Level Category

warplan Top Secret Troops, Subs, Planes

runway Confidential Planes

sonar Top Secret Subs

torpedo Secret Subs

Person Cleared for:

Sven Secret, Subs

Oliver Top Secret, Planes

Solution


File Level Category




torpedo Secret Subs

Person Cleared for:

Sven Secret, Subs

Person Cleared for:

Oliver Top Secret, Planes

File Level Category




torpedo Secret Subs

Access denied Access granted

Detour: Information Flow

Information flow as basis for specifying secrecy and integrity requirements

Information flow represents how data moves between subject 𝑠 ∈ 𝑆𝑢𝑏𝑗𝑒𝑐𝑡𝑠and object 𝑜 ∈ 𝑂𝑏𝑗𝑒𝑐𝑡𝑠 in the system:

Read operation: 𝑠 ⟵ 𝑜 ; Write operation: 𝑠 ⟶ 𝑜

Information flow graph G(V,E): (1) set of vertices V is the union of the subjects/objects in the system and (2) set of directed edges E consists of read/write information flows


File 1 File 2 File 3

User 1 read read -

User 2read

write- write

User 1

User 2

File 2

File 1

File 3


Information flow policies on a set of security classes rather represented as finite latticesstructures

- Consists of a finite partially ordered set together with least upper and greatest lower bound operators on the set

- Set of security classes is, e.g., set of all labels in MLS

Partial ordering ≤ on a set L is a relation where:

- For all 𝑎 ∈ 𝐿, 𝑎 ≤ 𝑎 holds (reflexive)

- For all 𝑎 ∈ 𝐿, if 𝑎 ≤ 𝑏, 𝑏 ≤ 𝑐, then 𝑎 ≤ 𝑐 (transitive)

- For all 𝑎 ∈ 𝐿, if 𝑎 ≤ 𝑏 and 𝑏 ≤ 𝑎, then 𝑎 = 𝑏 (antisymmetric)

Dominance indicates which security class is more sensitive

- 𝐴 ≥ 𝐵 (read 𝐴 dominates 𝐵) if and only if 𝐵 ⟶ 𝐴

- 𝐴 and 𝐵 are comparable if 𝐴 ≥ 𝐵 or 𝐵 ≥ 𝐴, otherwise 𝐴 and 𝐵 are incomparable

𝐶 is an upper bound of 𝐴 and 𝐵 if 𝐴 ≤ 𝐶 and 𝐵 ≤ 𝐶. 𝐶 is least upper bound if for any upper bound 𝐷 of 𝐴 and 𝐵, 𝐶 ≤ 𝐷.

- Lower bound and greatest lower bound work the same way



Example: Military Security Policy (simpler version)

- Levels: Unclassified (U) < Secret (S) < Top Secret (T)

• Unclassified without categories for anything non-secret

- Categories: Crypto, Planes

Least Upper Bound

Greatest Lower Bound

T:

{Crypto,Planes}

S:

{Crypto,Planes}

T:

{Planes}

T:

{Crypto}

S:

{Crypto}

S:

{Planes}

T:

∅S:

∅U:

∅


“Hasse diagram”

Other security policies

Conditional policies

- Temporal policies

• “Allow access between 10AM and 6PM”

- Context-aware policies

• “Allow access if current location is office”

Biba Model

- Dual of Bell-LaPadula

- Preservation of data integrity: “No read down, no write up”

• Subject cannot read an object of lower security level

• Subject cannot write an object of higher security level


These policies (or their combinations)

cannot be represented using an access matrix

Other security policies

Separation of duty

- If amount is over $10,000, check is only valid if signed by two authorized people

- Two people must be different

- Policy involves role membership and

Chinese Wall Policy

- Lawyers L1, L2 in same firm

- If company C1 sues C2,

• L1 and L2 can each work for either C1 or C2

• No lawyer can work for opposite sides in any case

- Permission depends on use of other permissions


These policies (or their combinations)

cannot be represented using an access matrix


Access Control Example:Unix file security

Unix file security

Each file has owner and group

Permissions set by owner

- Access rights: Read, write, execute

- Subjects: Owner, group, other

- Represented:

• Symbolic (most common)

• Bit field in octal notation

- Example: rwxr-xr-x = 755

Only owner and root can change permissions

- This privilege cannot be delegated or shared

→ DAC


rwx

owner

rwx

group

rwx

other

-

File type

Question

Owner can have fewer privileges than other

- What happens on write access by owner?

• Owner gets access to write?

• Owner does not?

Prioritized resolution of differences

- if user = owner then owner permissionelse if user in group then group permission

else other permission

→ Does not get write access!

• But: Owner can change access rights to restore write privileges for owner


r--

owner

r--

group

rw-

other

Short example: Output ‘ls’ command


File

permissions

Owner Group File size Modification

date

File Name

-rwxr-x--- bernd users 9.1K Jul 24 14:36 Foobar.zip

How can user ‘bernd’ access the file?

- rwx: read, write, execute

How can user in group ‘users’ access the file?

- r-x: read, execute; not write

How can a user that is neither ‘bernd’ nor in group ‘users’ access the file?

- ---: not at all

Effective user id (EUID)

Each process has three IDs (+ more under Linux)

- Real user ID (RUID)

• same as the user ID of parent (unless changed)

• used to determine which user started the process

- Effective user ID (EUID)

• from set user ID bit on the file being executed, or system call

• determines the permissions for process

- file access and port binding

- Saved user ID (SUID)

• So previous EUID can be restored

Real group ID and effective group ID used similarly


Process Operations and IDs

Root

- ID=0 for superuser root; full filesystem privileges

Fork and Exec

- Inherit three IDs, except exec of file with setuid bit

Setuid system calls

- seteuid(newid) can set EUID to

• Real ID or saved ID, regardless of current EUID

• Any ID, if EUID=0

Details are actually more complicated

- Several different calls: setuid, seteuid, setreuid


Example

…;

…;

exec( );

RUID 25 SetUID

program

…;

…;

i=getruid()

setuid(i);

…;

…;

RUID 25

EUID 18

RUID 25

EUID 25

-rw-r--r--

file

-rw-r--r--

file

Owner 18

Owner 25

read/write

read/write

Owner 18


UNIX example: passwd

File to store the users’ passwords on a UNIX system:-rw------- 1 root root 651 Jul 8 14:20 /etc/shadow

- Who can read this file?

- How can users change their password entry in /etc/shadow?

Solution: passwd tool-rwsr-xr-x 1 root root 45604 May 10 15:24 /usr/bin/passwd

- Setuid for root can read/write the shadow file

- Everybody can execute it everybody can use it to modify shadow

- Apparent security hole?

• passwd is carefully designed that users can only modify the entry for their own user id but not for any other user

• root user is the exception and can change the entry for any user


Setuid programming

Be Careful!

- Root can do anything; don’t get tricked

- Principle of least privilege – change EUID when root privileges no longer needed

Setuid scripts

- This is a bad idea

- Historically, race conditions

• Begin executing setuid program; change contentsof program before it loads and is executed


Unix summary

Good things

- Some protection from most users

- Flexible enough to make things possible

Main bad thing

- Too tempting to use root privileges

- No way to assume some root privileges without all root privileges


Authorization in reality


http://imgs.xkcd.com/comics/authorization.png


Malware

A malware is a malicious software that runs on your computer and makes your system do something that an attacker wants it to do.

- Steal personal information

- Delete files

- Click fraud

- Steal software serial numbers

- Use your computer as relay


What is Malware?

There are several characteristics of malware that can be used forclassification:

- Infection method

- Propagation strategy

- Payload

- Dependencies

- Detection mitigation strategy

- Resilience against defense mechanisms


Classification

... infects other programs by modifying them to include a, possibly evolved, version of itself

Fred Cohen 1983


Infection

Spreading behavior

Targets

Dependencies

Famous example

Characteristics

Virus

Execution of an infected file

Injects (modified) copies of itself into new hosts

Executable or interpretable files

Needs access rights for potential host files

Concept, Leap.A, ILOVEYOU

Infection and spreading requires user interaction

• Polymorphic viruses

• Virus body is encrypted

• Re-encrypt new copies to have different ciphertext

• Metamorphic viruses

• Rewrite actual code before spreading

• Interpreted code can directly be changed

• Compiled code is more involved

• Either change source and recompile

• Or change the binary


Virus

... appears to perform a desirable function but in fact performs undisclosed malicious functions that allow unauthorized access to the victim computer


Trojan Horse

Infection

Spreading behavior

Targets

Dependencies

Famous example

Characteristics

Execution of seemingly benign application that carries the trojan

None

Benign applications

Mimicked application is trusted by the user

Zeus, Browser Toolbars

Social engineering: make the user believe the program is completely benign

Can carry arbitrary payload

Often used in combination with spyware


Trojans are nowadays also very popular on phones

• Publishing apps is easy

• A lot of personal data is within reach

• Users tend to ignore the permission screen

• Overprivileged apps are common

• Hurts the principle of least privilege

Dissecting Android Malware: Characterization and Evolution[Zhou et al., IEEE Security & Privacy 2012]

Trojan Horse

... uses stealth to maintain a persistent and undetectable presence on the machine

Source: Symantec


Infection

Spreading behavior

Targets

Dependencies

Famous examples

Characteristics

Rootkit

Often carried as payload of a trojan horse

None

MBR, Kernel, Middleware

Needs elevated privileges

Blue Pill, Sony DRM Rootkit

Seeks permanent and undetected presence on the target system

User-mode and kernel-mode variants

Please hide me


Rootkit

... is a self-replicating computer program. It often uses a network to send copies of itself to other nodes and do so without any user intervention.


Infection

Spreading behavior

Targets

Dependencies

Famous example

Characteristics

The blaster worm: Then and now[Bailey et al., IEEE Conference on Malicious and Unwanted Software 2005]

Worm

Using vulnerable software, mostly over networks

Automated, aggressive spreading

Network nodes, usb devices, mails

Vulnerable version of software needs to be present

Remote code execution vulnerability

Morris, Blaster, Samy, Conficker

Often no user interaction is required

Every Windows XP without Service Pack has a vulnerability (an error) in the RPC network service.

Every Windows XP will be infected by Blaster when connected to the Internet.

Blaster

RPC

RPC

RPC

RPCFoundations of Cybersecurity 2016

Worm

Spyware

... reads keyboard input, browser input or captures the screen or webcam in order to collect information (credit card numbers, logins, ...)


Infection

Spreading behavior

Targets

Dependencies

Famous examples

Characteristics

Dynamic Spyware Analysis.[Egele et al., USENIX ATC 2007]

Often carried as payload of a trojan horse

None

Browser, input controls, system libraries, files

Access to critical information

Regin, RCSAndroid

Hooks into existing functionality

Communicates its findings to a remote server

Spyware

Kto: 12345678

Pass: secret94


... restricts access to the computer system that it infects, and demands a ransom paid to the creator(s) of the malware in order for the restriction to be removed.


Infection

Spreading behavior

Targets

Dependencies

Famous example

Characteristics

Ransomware

Often via trojan horse

None

Files, critical resources

Access to critical resources

„BKA trojan“, CryptoLocker

Financially motivated

Often uses cryptography to restrict access

Social engineering characteristics

BKA Trojan


... arrange their victims (“Zombies”) in controlled, interconnected networks to await further instructions from the botnet owner.


Infection

Spreading behavior

Targets

Dependencies

Famous example

Characteristics

Highly resilient peer-to-peer botnets are here: An analysis of Gameover Zeus[Andriesse et al., IEEE Conference on Malicious and Unwanted Software 2013]

SoK: P2PWNED - Modeling and Evaluating the Resilience of Peer-to-Peer Botnets[Rossow et al., IEEE Security & Privacy 2013]

Botnets

Often via trojan horse

Diverse

Desktops, Smartphones, Servers, Routers

Network connection for the communication

Gameover Zeus, Sality, ZeroAccess

Peer-2-Peer vs central C&C server

Is controlled by (mostly signed) announcements

Can install new malware on all hosts

Real Life Malware


• Mentioned malware types are prototypes only

• Real life malware combines several categories

• In many cases no clear distinction possible

• Increasing sophistication

• Transition from hobby projects up to state level development

Over 40 years of malware


History


1971 Creeper as one of the first malware

1981 Elk Cloner virus for Apple 2

1983 Cohen defines „virus“

1986 First PC virus MS DOS

1988 First worm: Morris worm

1990 First polymorphic virus

1998 First Java virus

1998 Back orifice

1999 Melissa worm

1999 Zombie concept

1999 Knark rootkit

2000 ILOVEYOU worm

2001 Code Red worm

2001 Kernel Intrusion System

2001 Nimda worm

2003 SQL Slammer worm

2004 Cabir Symbian worm

2008 Conficker worm

2010 Stuxnet targets SCADA systems

2011 Zeus banking trojan

2013 Cryptolocker ransomware

2014 Regin trojan horse

Number of malware signatures


http://www.infosecisland.com/uploads/remoteimg/ab8f5d07d73133e8a2457c664a48ab8b.jpg

Malware repartition


Kaspersky Lab 2012

Malware:Propagation VectorProf. Dr. Michael Backes

Shared folder


Email propagation


Valentine‘s day


Waledac malicious domain from pandalab blog

Email again


Fake codec


QuickTime™ and aGIF decompressor

are needed to see this picture.

Fake anti-virus


Hijack your browser


Fake page!


Malware:DefensesProf. Dr. Michael Backes

Vulnerable Software

Software Updates

- Manufacturer/developer can fix bugs after release of software

- Software Updates only prevent future infections

- Exploitation cannot be detected without other defenses

- After an infection, a software update doesn’t help


Why patches do not suffice

Zero-Day Exploits

- Knowledge about vulnerability in software

- Can be used to make millions of computers do whatever an attacker wants

- When used before there is a software-update, no chance for a user to patch vulnerability

- Hence the name: “Zero days” between discovery and patch

Vu

lne

rab

ility

dis

co

ve

red

Vu

lne

rab

ility

re

po

rte

d

Vu

lne

rab

ility

fix

ed

time


Anti-Virus

Aims to protect against known and zero day malware

Analyze system behavior

Analyze binary to decide if it is malicious

Components:

- Scanner

- Real time monitor


Used by scanner component of anti-virus

Find a string that can identify the virus (or virus family)

Fingerprint database is continuously updated

New virus might not have a signature yet

DatabaseW32.Blaster W32.Stuxnet

hfdad.exe

csrss.exe

Calc.exe


Virus-Signature

Compute a checksum for

- Good binary

- Configuration file

Detect change by comparing checksum

At some point there will be more malware than “goodware”


Checksum

Real time monitor component of anti-virus

Watch out for suspicious behavior

- Network access

- File open

- Attempt to delete file

- Attempt to modify the boot sector

- Attempt to replicate themselves


Heuristics

Similar to a self-extracting ZIP archive

Malware is payload that gets extracted/loaded

May contain benign host executable (e.g. “Calculator”)

MalwareOriginal OS

Executable

Packer

Payload

Executable Code Data of the executable

Replace original operating system file(e.g. calc.exe)

Pretends

normal

behavior to

the user


OmniUnpack: Fast, Generic, and Safe Unpacking of Malware.[Martignoni et al., IEEE ACSAC 2007]

Executable infection (“Packers”)

Sandbox analysis

Running the executable in a carefully prepared VM

Observe it

- File activity

- Network

- Memory

Packers are more complex

- Launch

- Wait until it is unpacked

- Dump the memory


Discussion: sandbox analysis

Grant internet access?

- Pro: Some malware refuses to work without internet access

• Makes dynamic analysis possible

- Contra: malicious activities during sandboxing

• Sandbox can be misused for spamming

• Potential legal problems

Red Pill?

- Emulation can be detected

• Presence of specific hardware features

• Timing attacks reveal delay due to virtualization

- Malware can change or stop malicious behavior

- Can even try to break out of the sandbox


Documents

Access Control & Malware · Traceability Generating Secrets Usability Foundations of Cybersecurity 2016 Keep it simple. The security of a system should not depend on the secrecy of