halvar flake: why johnny can’t tell if he is compromised

Why Johnny can’t tell if he is compromised

...and what you can do about it.

Keynote Area412nd of June 2014, Zurich, Switzerland

[email protected]://goo.gl/3NphRw

mailto:[email protected]

http://goo.gl/3NphRw

Robert Morris Sr.Fundamental rules for IT security - a cynical

view from more than 20 years ago:

Do not own a computerDo not power it on

Do not use it

Situation does not seem to have gotten better

Hacking is addictiveTransitive trust relationships everywhere

Start to hack almost anywhere - compromise boundary grows exponentially

Only limit: Size of net, admin infrastructure

The nowAll major nation states / global powers want to

have “dominance”

Almost nobody is any good at defense

In the limit: Everything compromised (or on compromise boundary) by multiple parties

What does compromise mean?

Somewhat fuzzy concept

Installing malware is clearly a compromise

Illicitly obtaining authentication credentials is also a compromise

Compromise is about “control”

Ownership vs. possessionLegal distinction between ownership and

possession of an object

I am the owner of my car, even if I have lent it to a friend and it is not in my possession

Networked computing devices have a third dimension: “Control”

Possession vs. controlNeither possession nor ownership of a

networked computing device imply control

Being hacked is loss of control without change of ownership or possession

“Getting 0wned” = loss of control over your own computing infrastructure

Who is in control?Establishing who is control of your computer is

nearly impossible

This talk: Exploration of all the ways we can’t tell if we are in control, and how to fix it.

Given a computer ...… try to establish who is in control

For the exercise: Assume WindowsWhere to start ?

All highly-privileged code is in control

Code running with user privileges is partially in control

Control and softwareClearly, someone else is in control (third-party

OS, various bits of third-party software)

This is OK - we have decided to trust these third parties and say “yes” to their software

We trust (some) software vendors to not backdoor us intentionally

Baseline checks

Verify signatures on all userspace

binaries

Verify signatures on all kernel

space binaries

Verify signatures on all BIOS

components

Verify signatures on all device firmwares

Verify signatures on the Intel ME

code

Verify that the signers know about their

signatures

Verify origin of privileged scripts

Check 1: Userspace CodeProblem: Vendors don’t sign their executables

Problem: If they do, they don’t sign their DLLs

Problem: If they sign both executables and DLLs, they don’t sign executable extensions

Problem: 100+ trusted root CAs?

http://social.technet.microsoft.com/wiki/contents/articles/14215.windows-and-windows-phone-8-ssl-root-certificate-program-member-cas.aspx

Baseline checks


binaries


space binaries


components



code


signatures


FAILURE

Check 2: Kernel CodeNumber of CAs that can sign drivers much smaller

than user-space

Irrelevant: Attacker use signed driver with known vulnerability to bootstrap code

Failure to sign userspace means failure to sign kernel space

Not theoretical: Uroburos

Baseline checks


binaries


space binaries


components



code


signatures


FAILURE FAILURE

Check 3: BIOS CodePer-vendor code signing (DELL, HP etc.)

No public documentation or third-party analysis about the way this works

No way for third parties to verify signatures

Even if possible to verify, can’t read relevant regions

Baseline checks


binaries


space binaries


components



code


signatures


FAILURE FAILURE FAILURE

Check 4: Device FirmwaresHDD controllers: Nobody knows how to verify

code inside, but we know attackers can backdoor them

GPU firmware: People are flashing them for overclocking, no way to do third-party validation

Completely stranded

http://spritesmods.com/?art=hddhack&page=1

Baseline checks


binaries


space binaries


components



code


signatures



FAILURE

Check 5: Intel MEARC core on modern mainboards that can execute signed Java applets etc

.

Communicates with host OS via PCI shared mapped region

Highly opaque, no way to verify code running in ME from host OS

http://2012.ruxconbreakpoint.com/assets/Uploads/bpx/Breakpoint%202012%20Skochinsky.pdf

http://2012.ruxconbreakpoint.com/assets/Uploads/bpx/Breakpoint%202012%20Skochinsky.pdf

Baseline checks


binaries


space binaries


components



code


signatures



FAILURE FAILURE

Check 6: Stolen KeysAttackers have compromised software signing

keys and CAs in the past

People with software signing keys can silently “lose” them without this ever being noticed

There is no equivalent of “Certificate Transparency” for code signing

http://www.certificate-transparency.org/

Check 6: Stolen KeysAll PKI architecture assume an invincible CA

and invincible signers

Reality has shown that this is a wrong assumption

No way to verify if a file signed with a key was signed by the person the key was issued to

Check 6: Stolen KeysAfter breaches of the last years, only safe

assumption is:

Code signing keys of many software vendors and CAs have been silently stolen

No good way of detecting this

Baseline checks


binaries


space binaries


components



code


signatures




Check 7: ScriptsLots of interpreters run code with privileges on

your typical host

Javascript-based extensions to your browser

Java-based background tasks

Python and other interpreted languages

Check 7: ScriptsNo good infrastructure exists to tie running

interpreted code back to the scripts from which it was compiled

No good way to determine where the code running inside java.exe or python.exe is coming

from

Baseline checks


binaries


space binaries


components



code


signatures




FAILURE

Failure on all levelsGiven modern infrastructure, it is nearly impossible to determine if a machine is

compromised

It is also nearly impossible to “un-infect” a machine once it has been infected

What needs to change?

Long-term viewProposed measures will take many years to

build

Fundamentally easy, though - no rocket science required

Hardest things to overcome: Organisational inertia, complacency, politics, broken incentive

structures, cost

Step 0: Check trust

IT departments do not ask themselves enough questions about who they trust

Someone well-intentioned but securitywise incompetent will be the weak link that attackers

exploit

This applies to vendors and suppliers !

Control and Power of attorney

Giving “control” over your compute infrastructure is the same as giving a delegable

power-of-attorney over your compute infrastructure to a third party

This encompasses trusting a CA, allowing auto-update of software, and much more.

Control and Power of attorney

Legal departments are rightfully hesitant to issue powers of attorney to third parties

Delegable powers of attorney to random third parties are virtually unheard of

IT industry needs to learn from this

Step 1: Undo CA proliferation

Trusting a code-signing CA is equivalent to a delegable power-of-attorney over your compute

assets

There are way too many code-signing CAs

Only trust a CA that you know very well - which at the moment will be none

Step 2: Trust by-vendor

Most likely, arbitrarily delegable power-of-attorneys are a broken idea

Trust for executable code should be by vendor, not by CA

CA-based trust only for sandboxed web-pages / javascript

Step 3: Update transparency

All software vendors roll their own update mechanism

Allowing someone to update software is also a delegatable power-of-attorney

Software updates need to come in standardized packages and via standardized

protocols

Step 4: Signing transparency

Given likelihood of stolen signing keys, “code signing transparency” is needed

Vendors need to run a public ledger where they explicitly avow “yes, I have signed this binary”

Ideally with information about the exact SVN tag / git hash that was used to produce the

binary

Step 4: Signing transparency

When signed file is encountered, public ledger can be checked

“Dear Vendor, are you aware that file XYZ has been signed with your key?”

Probably the only way to engineer “detectability of key theft” into our systems

Step 5: Reduce firmware opacity

Firmware blobs for devices need to be readable by the main CPU without physical possibility of

interference from the device firmware

Purchasers of hardware need to insist on this transparency

They also need to realize they have a right to demand this

Step 6: ME transparency

There is no excuse for a coprocessor on your mainboard whose code can’t be validated by

you from your main CPU

Purchasers of hardware need to realize that they have a right to demand transparency from

the code running on ME

Step 7: Signed interpreters

In order to run a script with high privileges in an interpreter, the script needs to be signed and

the interpreter needs to be able to tie back the executable form to the original script

For non-privileged code (JS in a tight sandbox etc.) we may be able to make an exception

Transparency vs. tamperproofing

Systems need to be engineered to be easily verified by the owner

Centralization of trust is a failed experiment, especially given government desire to

“dominate cyber”

Demand systems whose integrity you can verify

Paradigm shift“Security” hardware has opted for more opacity

in the past

Fear of side-channel attacks, fear of physical attacks

Prioritized tamperproofing, sacrificed transparency and verifiability

Paradigm shiftSide-channel and physical attacks are a lesser concern than remote attacks provided you are

in possession of your hardware

Remote attacks that you can never tell happened are the bigger threat

Re-prioritize verifiability

Will this give us security?The proposed measures will not yield 100%

security

Will give defenders a fighting chance to deny persistence to the attacker

Will give defenders a fighting chance to detect compromised suppliers

Will this give us security?Hopefully, this will force attackers into exploiting

& re-exploiting for persistence

Better software engineering can then slowly root out bugs

Move from cheap, stealthy mass compromise to individually tailored compromise: Costly

How to pay for it ?

None of the proposed steps are “free”

None are terribly costly, either

Standardized software updating, better signing & verification will actually reduce IT

maintenance costs

Stop buying snake oil?

Huge revenues are generated in our industry with colored appliances that only work as long

as the attacker hasn’t looked at them

Often, these boxes want to be dropped onto privileged points in your infrastructure

Just say no. Spend your money wisely.

Thank youQuestions?

halvar flake: why johnny can’t tell if he is compromised

Technology

control code

code failure

bios code

userspace binaries

privileged code

kernel space binaries

userspace code problem

loss of control