SlideShare a Scribd company logo
1 of 80
Download to read offline
Yet Another Dan Kaminsky Talk
(About much more than RNG)
Dan Kaminsky
Chief Scientist
White Ops
Special Guest: Ryan Castellucci, Security Engineer, White Ops
Back To Defcon!
• This is my thirteenth rodeo
• Why?
• It’s fun tech, but why this tech, why this place, why this way?
• Fundamentally subversive, even for Defcon
• Defcon loves to show what can be broken
• I love to show what’s possible
• We can scan the whole Internet, in seconds!
• We can bust violators of Network Neutrality!
• We can play video of Darth Vader doing Riverdance over DNS!
• Among other tricks involving DNS
• Like DNS rebinding and hacking home routers
• These are not actually the same thing
• So why are we here?
Subjects For Today
• Why do we keep getting owned by bad Random Number Generation?
• Users are expected to recognize and maybe even repeat complex
patterns, and they’re failing. Can we do better?
• What do we do about the infinite supply of Browser 0day?
• What do we do about DDoS, which is actually growing substantially?
• So, just how much did the NSA shit the bed?
• But first…I want to talk about why all this stuff we do is useful. By
discussing hard drives.
A Scenario
• An attacker has compromised a system, and put something malicious
on the hard drive. How bad could it be?
• Added an autolaunching daemon?
• Replaced core OS files?
• Put a virus in the MBR?
• Can you just wipe out the drive and be done with this?
What Is The Difference Between…
A Hard Drive A Brick
Given Sufficient Research, None
A Hard Drive == A Brick
==
Theory Vs. Reality: What Is A Hard Drive
Xzibit’s Iron Law Of Computer Architecture
• Yo Dawg, I heard you liked computers, so I put a computer in your
computer so you could compute while you compute
• This is basically how computers work – hard work is offloaded to hardware,
which is really just another computer that has a fast way to influence you
• Fast == trusted == insecure
• Everything is generic now – the iPhone has seven ARM chips
• The biggest lie about your computer is that it’s just one computer
• That hard drive is just another computer with direct access to your system
memory via specially designed protocols
• Doubt me?
From An Old Project with Travis Goodspeed:
Lets Get A Shell On This Here Seagate!
Oh Shell, You’re even self documenting!
Documents commands, their locations, their
arguments…
Get some internal drive metadata…
Learn about the disc you know…
…and the disc you don’t…
Can Even Read It Out…
Nice Test Code!
Don’t think that you need that serial link…
…or that I was kidding about making bricks
• Fate: Platters exposed, fingerprinted. Firmware dumped as 001.rom.
• Fate: Bricked by Dan when he wrote to the buffer. Probably
repairable.
• Fate: Bricked by dan with HDPARM, then sawed apart by Travis for
post-mortem firmware analysis.
• Fate: Semi-bricked by Dan by raising the serial port rate to 625000.
Repairable.
The Paper That Eventually Followed
• Implementation and Implications of a Steath Hard-Drive Backdoor
Jonas Zoldach, Anil Kurmus, Davide Balzarotti, Erik-Oliver Blass,
Aurelien Francillon, Travis Goodspeed, Moitrayee Gupta, and Ioannis
Koltsidas
• I’m an unindicted co-coconspirator 
• 10 months of solid reverse engineering to create the malicious
firmware payload
• Not at all the first time this has been done, but maybe the first time
publicly/academically
The Significance of the Research:
S^X (Storage XOR Execution)
• Highly desirable property for secure clouds
• “It’s not about ownage, it’s about continued ownage. It’s about coming back in a year and
having the door still open for you”
• Requires exploitation and persisted storage
• If your storage doesn’t parse, it can’t be exploited
• If your execution doesn’t store, there’s nowhere to persist
• You can’t start thinking about S^X if you think you already have it
• There are ways of building S^X out of existing gear – but nobody thinks you have to
• Nobody thinks you have to have exclusive hosts on cloud providers either 
• Thus, the value of hacker engineering
• No delusions
• Operation from first principles
• The best thing hackers break are assumptions
• We are needed.
I Believe In The Internet
The Internet Is Not Just For Us
• I believe in TexasGirly1979 having six and a half MILLION people loving her
damn cat
• Without Bob Saget, a laugh track, and a baseball to the testicles as followup
• I believe in responding to being told your music sounds like “rats being
strangled” by becoming a dubstep violinist and getting a half billion hits on
YouTube
• Remixing Skyrim and Zelda and Halo may have something to do with my opinion
• I believe in email over Interoffice memos, Skype over (very) plain old
telephone service, online banking over waiting for a bank teller
• And I believe we could lose it all, and there are some who might even
prefer that
The Thing To Remember
• The Internet was not the first time we tried to create the Internet
• It was like the 8th
• Prodigy tried
• Minitel tried
• America Online really, really tried
• Spent a billion dollars on modem lines!
• (They actually still make $160M/yr off that.)
• The Internet was free
• Not just free as in murka
• It was free as in no rent – all of the above wanted to charge transaction fees
• The Internet just wanted a few pennies a year for a domain name
• The free Internet has disrupted a heck of a lot
• Don’t think there are those who wouldn’t like to disrupt back
The Challenge
• We know what’s really possible
• We know that breaking everything, is really possible
• We don’t know that fixing everything, is really possible…
• …but technically, we don’t actually know fixing everything is impossible
• Technically correct is the best kind of correct
• So why do I do this, and why do I do this here?
• Because here, I see openness to possibility
• Including the possibility the Internet might turn into AOL
• I see the sheer joy of understanding the actual mechanisms at play
• I see the skepticism that allows BS – especially security BS – to be discussed
and recognized
Let’s Talk Random Number Generators
• “The generation of random numbers is too important to be left to
chance”
• Many processes require a generator of unpredictable numbers
• Last 1000 numbers don’t tell you the next number
• Last 1000 numbers also don’t tell you the number 1001 times ago
• That they require such a generator doesn’t mean they’re using such a
generator
What’s happening to all these web
frameworks
• You actually don’t log in very frequently
• Top 10 e-commerce platform: 7 logins a second, worldwide
• Logging in gives you a token
• If you’re lucky, it’s HMAC(who_you_are, key)
• In the real world, it’s often Random()
• Sure would suck if that wasn’t actually random…
Dominique Bongard’s (AKA @reversity)
Beautiful WPS Attack From #Passwords14
Details
• WPS Protocol assumes 128 bits of entropy in AES keys
• Reality: 32 bit LFSR, 32 bit LFSR, 0 bit (aeskey is always 0)
• 2**128: Big
• 2**32: Not so big (~4B, remember your CPU does that many operations in
seconds)
Why Do We Keep Getting Owned By Random
Number Generators?
• Wrong Answers
• “Because we used SHA-1 instead of SHA-256”
• Freaking MD4 would work
• “Because we used HASH_DBRG instead of HMAC_DBRG”
• “Because we used the same entropy for too long”
• “Because we had only one pool for mixing entropy instead of thirty two”
• There’s a thousand ways to build a CSPRNG (cryptographically secure
pseudo random number generator) and all of them would fail less than
what we’re doing
• Even forking/cloning VMs doesn’t fail this frequently
• Right Answers
• 1) No entropy
• 2) No CSPRNG by default
A Little Dab’ll Do Ya
• CSPRNG’s expand a little bit of entropy (128 bits) into billions of
gigabytes
• Best attack would be to brute force the 2**128 possible initial seeds and find
the one that matches the stream
• Good luck with that…unless there’s actually not even 128 bits
• There’s often actually not even 128 bits   
• Turn on a machine, no keyboard, no mouse, no disk…no entropy.
• 1/200 RSA keys on the Internet were badly generated, meaning actually
probably 1/50
• Heninger attack only found all identical private keys, not similar keys
• Private keys are just small chunks of randomness that ended up prime
• Shouldn’t /dev/random or /dev/urandom have prevented this?
Perfection Is The Enemy Of The Good
• Why we like kernel RNGs (/dev/random, /dev/urandom)
• Kernel code gets events from hardware
• General thinking is that event timing from foreign hardware is on a separate clock
• All good entropy is a fast clocked system measuring a slow clocked system
• Inter-keystroke timing from a human to the CPU nanosecond
• There’s also only one kernel
• If anyone gets entropy everyone gets entropy
• Operating systems are supposed to provide services that are easy to screw up
• Can get more complexity/correctness encapsulated in the OS rather than monkey-shoved into
each language or application
• What went wrong
• /dev/[u]random still fails when there’s no events coming in from the hardware
• No keyboard, no mouse, no disk == no events
• Yes, it’d be nice if there was hardware entropy generators, but not happening
Solving The True Entropy Problem
• You don’t have to be perfect every time
• You just need to be better than the ONE NINE OF RELIABILITY the status quo has
achieved
• Be embarrassed
• 1) Force synthesis of events
• 2) Don’t necessarily be afraid to do this in userspace
• Especially in a world of VMs, kernel is nothing but a single threaded process
• What this means
• Measure the real time clock (kilohertz at best) with the CPU (megahertz to gigahertz)
• Possibly do some work with non-deterministic time (atomic memory writes)
• Do standard whitening (Von Neumann – drop 00 and 11, 01 is a 0, 10 is a 1)
• This is the Dakarand (Truerand) approach. It may fail in some very rare scenario. It will
fail less than the status quo.
• Security means it’s OK to fail less.
Solving The True Problem
• Operating systems have /dev/urandom which is generally pretty good – but does
anything use it?
• JavaScript Math.Random(): no
• Ruby Random.rand(): no
• Java.util.Random(): no
• PHP rand(): no
• Glibc rand(): hellllllllllllllll no
• Standard RNG is LFSR or Mersenne Twister – if you want security, you’ve got to hunt
down some other API
• And it’s always funky and different!
Math.random();
var a = new Uint32Array(1); window.crypto.getRandomValues(a);
• How well does insecure by default work anywhere else?
• Pretty badly
The Obvious Question: Why not be secure by
default?
• Instead of requiring some special, magic, and consistently overcomplicated
API for Secure Random™, why not just have all random calls not be crap?
• Liburandy
• Silently hijacks standard randomness functions in common languages, backs them
with /dev/urandom (on Linux)
• Would be CryptGenRandom on Windows
• The OS already does this right, lets just hook dev intent to something that’s not busted
• Initial support for JS(Node, Browsers), Ruby, LD_PRELOAD (arbitrary libc), PHP,
Python. OpenJDK soon
• Ryan Castellucci of White Ops helping to write this
• Will eventually support some important runtime features
• Entropy Metadata (runtime will be defining security rather than source code)
• Fixed seed
• High speed mode
What’s Wrong With Liburandy
(Lets play chess against myself a bit)
• Two General Objection: Seed and Speed
• Seed: Useful for getting consistent test results (Random, but the same
random set)
• 99% of the time you see seeding, it’s C seeding time because people don’t want the
same random results
• Can set a special flag (environment variable)
• Speed: urandom is slower than LFSR/MT
• If you wanted it to be fast why are you writing in in ruby
• This is actually why things have been left crappy – so as to not lose benchmarks 
The Headaches Of Speed
• /dev/urandom is fast enough for almost all uses
• That being said, it’s still a lot slower than LFSR/MT
• Linux: Only 3.7MB/sec – that’s only 947K ints/sec (and that’s with CPU drain)
Should we use a userspace CSPRNG, just not a
crappy one?
• Seed with [u]random from time to time to still absorb whatever entropy it does
get
• Minimal/Fast CSPRNG: SipHash(Seed, Counter++);
• Yes, this actually works
• ~20x speed of /dev/urandom on Linux
• Possible improvement: CLOCK_MONOTONIC
• Ideally, we’d just be able to ask the CPU for some random bits whenever userspace wanted a
few
• That’s way too easy (and we’d probably never trust the output anyway)
• But we can ask the CPU for time
• Even forked, likelihood near zero of repeated return value
• For VMs, you don’t get a surfaced event on clone, but you do get to plunge into the host to find out
nanosecond time
• Also can be done on a per query basis, which cleans up a bunch of buffering issues from
reading off a file handle
My preferred CSPRNG
• SipHash(Secret || Counter++ || Previous_Output || ShiftedTime)
• ShiftedTime is CLOCK_MONOTONIC, shifted by some absolute amount so the
attacker can’t just look up the global time and predict bits
• Previous_Output means if ShiftedTime only has one shot to repeat
• Not using this yet, because I’m an ornery member of Team Just Use
Urandom
• Let’s not debate userspace vs. kernelspace
• We agree: DEATH TO LFSR
• Also possible that other hashes besides SipHash are good
• Blake
• Skein (can actually be 2x speed of SipHash, due to larger output)
• Maybe we make /dev/urandom fast on Linux?
• Probably need an API to probe for metadata about urandom?
The Other Entropy Problem
• d3b07384d113edec49eaa6238ad5ff00
• 1Ngju42mHfxJJDEKA15rHUum17rcDEf699
• A1$jh-89)&@4bc (oh wait, no: **************)
•
STOP PUKING BITS (Images of 8 Bit Vomit)
The Problem At Hand
• Computers need Humans to recognize and remember larger numbers
of bits
• Human face recognition only works to about 16 bits (1/65536)
• Computers want 24-128 bits depending on context
• Recognition: Is this the hash from before?
• Repetition: What is your password?
• Standard Bit Representations are terrible
• Humans did not evolve to recognize hex, Base64, Base58, or…squiggly
Previous Work On Cryptomnemonics
• Some previous work from 2006: Names
• 512 Male Names (9 bits), 1024 Female Names (10 bits), 8192 Last Names (13
bits) == 32 bits per couple
• Heteronormative, but surprisingly diverse!
• Julio and Epifania Dezzutti
Luther and Rolande Doornbos
Manual and Twyla Imbesi
Dirk and Cuc Kolopajlo
Omar and Jeana Hymel
• Important to show names every time a connection is made, not just on
challenge
• Would you remember a face you saw only the one time there was an auth challenge?
Can We Do Better?
• Humans do have memory capacity, it’s just not for arbitrary bits
• We remember objects, and specifically stories, more than we remember 1’s
and 0’s
• So if you can represent 1’s and 0’s as stories, humans will recognize and
repeat them better
• Also, you’ll be able to put a password in and have it spell check
• Experiment: Use triads of adjective/noun/verbs, set up to be
“maximally distant” from eachother
• Encode them in a way that is order independent, i.e. it doesn’t matter if the
dog or the cow is brown or orange
• Ryan Castellucci has been implementing this, here’s how he did it and
where we’re seeing this being immediately useful
Storybits v0.1
• Hex bits: 5e4dcc3b5aa765d61d83 (80 bits)
• Story encoding (early):
• macho acid answering
rustic cable fetching
stuffy jacket forbidding
wacky riot opening
• Story decoder autocorrects
• node demo.js "wckay jacket forbidrustic fetch cableacid mache answering
open riot$$"
• 5e4dcc3b5aa765d61d83
• Words are misspelled, out of order, in different tenses, missing spaces, etc.
Details
• Implementations in JavaScript and Python
• Rough, but releasing soon
• Two major components
• Combinatic Encoder
• Encodes information with symbols that may not repeat
• BADFGC is legal, AABBCC is not
• Because symbols are independent, order doesn’t matter
• Word Mapper
• Maps combinatorial numbers to words in part-of-speech wordlists
• Adjectives, nouns, verbs
• Instead of 321, 561, 312, it’s “rustic fetching acid”
• Allows for strong correction from word variants to original numbers
• Words are chosen to have maximum distance for maximum correctability
On The Selection Of Passwords
• We have to get past l33tspeak as a security technology
• We punt generation of passwords to users because we don’t want to
“screw it up” and we imagine if the user does it, it’s at least their fault for
failing
• This scheme lets passwords be generated server side, that have a hope of
being memorable
• Passwords that can be corrected are passwords that are more easily
remembered
• Faster recovery from silly typos allows password stretching to be more aggressive
• Don’t suffer the stretch delay because you missed a key – it autocorrects and still
works
Major Use Case: Phidelius Approaches Are
Going Mainstream
• Phidelius: Trick from a previous talk that seeded RNG w/ a passphrase
• Allowed passphrases for SSH, SSL certs, pretty much mapped words to asymmetric
crypto
• A little fragile because it was a /dev/[u]random hijack
• These approaches are now popular for asymmetric key management
• Brainwallet:”Word/phrase to a Bitcoin address”
• Minilock: “Word/phrase to a PGP key”
• Incredibly vulnerable to insufficient entropy in the word or phrase
• Because the public key is public, and the whole world can try to crack it
• Has been an expensive problem in Brainwallet
• Tens of thousands of dollars worth of BTC have been taken
Squaring The Circle
• Brainwallet and Minilock need human-memorable entropy
• Actual security needs more entropy
• Storybits increase memorable entropy, allow the entropy to come from
the machine (which can generate it) and not the user (who clearly can’t)
• Extensions
• Split Mode – Allow entropy to be split between two words, one that’s easily
remembered (but very slow to crack), another that’s kept on a hard drive or offline
to allow fast transfer of the key to a new device
• The user gets to transfer in seconds
• The attacker has to try to crack for hours per guess
• Breaks the ~20 bit limit on how much you can stretch a key
Two More Tricks (Not Necessarily Advisable)
• Local Shrinking
• Will always be easier to recognize 24-32 bits instead of 80-128 bits
• If you only force the attacker to match 24 bits, he can brute force random keys until he finally gets
one that matches just the 24 bits you’re looking for
• Olde trick against PGP KeyIds – “DEADBEEF attack”
• But what if the attacker doesn’t know which 24 bits to match?
• If you have a local shrinking code – sort of a password for recognition – it’s hashed against the full size 128 bit
hash and truncated secretly to 24 bits
• The attacker doesn’t know the code for the truncation, so he has to match everything. You do know the code
so you only have to match a little.
• Local Stretching
• Technically can have a “master password” that’s mixed with all your otherwise small passwords
and shared across many sites
• Whether the site uses scrypt or some other key stretcher, its stored password is guaranteed to be
stretched outside of cracking range
• Password Policy Survival: We have mutually exclusive requirements (symbols, no symbols,
numbers, no numbers). Can infer server policy from supplied password, persist it post-stretch
Browser 0day: The Shoe Finally Dropped
• IE had more attacks in 2013 than Java
• How is this possible? MS has been working to secure IE for a decade!
• IE is basically Windows: The Remix (feat. The Internet)
• Take a local object model (COM), hand it to bad guys, wait
• This ultimately applies to every browser, because the spec ends up encoding a COM-like
implementation (there’s an interface description language / IDL).
• Plugins were nice because they were across browsers and tended to be the thing outside
the “sandboxes” but now the browsers themselves are the low hanging fruit
• “My TOR deanon has a first name, it’s Firefox 0day” as the Grugq would sing
Use After Free: The Infinite Well Of Browser
Vulns
• Browsers are constantly allocating memory for objects of all sorts of
interesting types
• Objects can point to eachother
• When nothing points to an object, then you can free/reuse that memory
• Lots and lots of ways to point to an object
• Ever screw it up, all hell breaks loose
• Allocate a table (0x12341234 == Pointer to Table)
• Free the table (0x12341234 == Available For Allocation)
• Allocate an image (0x12341234 == Pointer to Image)
• Access the image via its old context as a table (0x12341234 contains contents of Image, being
accessed via handlers for Table)
• “Use After Free” == 90%-95% of the “deep vulnerable” attack surface for the web
Google and Microsoft Have Solutions
Firefox Doesn’t, And Is Suffering For It
• Google Solution: Typed Heap
• Chrome is allocating all objects of the same type, in the same “sub-heap”
• Memory once used for a table, will never be used for an Image, because that’s going into
the Image heap
• Microsoft Solution: Nondeterministic Freeing
• (Oversimplifying, they’re doing a lot of stuff)
• They’re making it so you don’t quite know when the memory has been freed,
and thus aren’t guaranteed a reliable or rapid attack
• This is great. Attack the unique needs of an exploit – this is counterexploitation
My Trick: Iron Heap
• (Thanks Rob Graham for the name!)
• You can’t Use After Free if you don’t free!
• This is too expensive if you do it with physical memory
• But on 64 bit machines, we have a damn near infinite amount of virtual
memory
• The basic idea is to never reuse an allocation – the physical memory is reused
but the handles aren’t
• 0x1234123412341234, once freed, stops pointing to any physical memory
• Exploit that
Iron Heap Efficiency
• Efficiency
• Finite number of active allocations allowed – you’re leveraging the page tables which
don’t like to be that stressed
• Can have a “hot list” of pages that are directly mapped, and a secondary list that’s
“swapped in” on demand
• How compressed RAM works
• Can potentially add guard pages between allocations to prevent overflows
• Overflows have actually gotten kinda rare
• Forces 8K per alloc, which is a bit high, though the compressed backing store can be fully
packed (no pointers to it are exposed in user space)
• Implementation
• Can be run in both userspace (with libsigsegv to catch the extra accesses) and in
kernel (which is already handling this sort of swapping for, well, swap)
• Don’t necessarily object to kernel dependencies or modules
• Linux has a crazy limitation where you can’t get page permissions without parsing text!
Downsides of Iron Heap
• No code available (yet, just PoC’s are built)
• Really leans on 64 bit
• Browsers aren’t entirely fantastic at that yet
What May Work Today: Diehard(er)
• Interesting secure allocator from Emery Berger @ UMass
• Advanced ASLR implementation w/ out of band heap metadata
• Supports Linux and Windows (and Mac, to some nonzero degree)
• Suppresses Use After Free, mostly by delaying free (similar to MS
approach)
• Available today (you do need to recompile with --disable-jemalloc)
• Probably worth exploring for Tails etc.
• ASLR, NX/DEP, other methods assume corruption has occurred and try to
enforce limits to make the corruption unexploitable
• UAF blockers actually prevent the initial corrupting moment
• There’s nothing going on in Infosec that’s killing more 0day
The Plan
• Firefox needs a story around memory hardening
• It’ll take quite a bit to get them to give up their incredibly efficient jemalloc
• First step, let’s get something production worthy for “special Firefox
installs”
• Tor
• Tails
• Then let’s look at getting it mainstream
• “Like millions of 0day cried out all at once, and were silenced”
• Dr. Emery Berger has agreed to join this effort – we’re going to make
something production worthy!
Need To Start Thinking about DDoS Again
• 1 >100GB flood in 2013
• 114 >100GB floods in 2014
• Generally, we think of DDoS involving botnets firing their hordes at
some poor web server
• The largest and most damaging floods are actually involving spoofed
traffic that’s reflecting off Internet DNS and NTP servers
• No DNSSEC involved or required
• Important to understand why spoofed reflection is so dangerous
Why Reflected Floods
Are Nasty
• Here’s a network.
• Lots of routes
around the core
• Fewer routes from
each source, to each
destination
An unreflected packet
stream
• Packets are always
taking the “fastest”
next hop to the
target network
• Bandwidth ==
maximum available
for the slowest
single hop
(wherever that is)
The Reflected And
Spoofed Packet
Stream
• It goes out to
everywhere,
spreading the load
across all the
inbound hops
• Everyone replies to
just one place, via all
inbound links
• Boom.
What To Do?
• BCP38/URPF
• Ideally, there wouldn’t be networks that allowed you to lie about who you are
• Every network link would have a computed range of addresses it could speak
for, and that would be that
• This actually is a complete success in the DSL/Cable world
• Not saying we shouldn’t continue to strive for BCP38 compliance
• At least 2300 networks w/ no BCP38 compliance
• Can we do more?
Stochastic Tracing: Bringing Back An Old Idea
• This is at least 12-13 years old of an idea (roughly, I’m adding some quirks)
• The Internet and it’s problems were different that long ago. What wasn’t
ideal then might be good now
• Basic idea: One out of every 100K-10M packets, a “tracer” goes out
declaring a hop along the route that sent traffic
• Sort of like a “background traceroute”
• Irrelevant network load for normal streams, but DDoS would become traceable
instantaneously – the bigger the DDoS, the faster degraded networks would identify
themselves
• Implementation receives a GRE stream of a small subset of packets – well supported
• Probably a way to do this w/ command line haxory as well
Maintaining Privacy and Security
• Tracing traffic only goes to hosts that should otherwise be able to see the original
payloads
• Destination IP for all traffic
• Source IP for DNS and NTP (and any other blind responding protocols that pop up)
• Haven’t decided what the payload would be – ICMP, HTTP, etc.
• To be on the open Internet is to get random stuff, so the only question is what’s easily catchable by a
DDoS victim
• One variation: Allow alternate destination to be declared in Reverse DNS space
• 4.3.2.1.in-addr.arpa IN PTR blabla.foo.com
• The in-addr.arpa space could be used for more than just PTR records
• Could declare an alternate destination for tracer traffic, or flags for format / multidrop
• Still under the authority of the IP address
• Obviously should sign tracer payloads with ED25519 keys, possibly declared in
DNS
Long Term Vision
• Reduce the time between receiving a DDoS and tracing the involved
networks
• Ultimately, automatic suppression of DDoS (though this gets really
messy really fast, because so many hops on route see enough to send
the shutdown signal)
• There are large enough floods growing at fast enough frequency
that work like this is necessary
• And since Paul Vixie would kill me if I didn’t say it, please update your DNS
server to support RRD, which dramatically reduces DDoS participation
What I’m Really Nervous About
• Can’t just not talk about the NSA revelations
• Not here to recapitulate Bruce Schneier et al.
• I’m nervous about people’s reactions to them.
Competing on Political FUD instead of
Technical Merit
• “Sure, you could go with that competitor, that’s cheaper, faster, nicer,
more powerful…but OOGA BOOGA $NATIONSTATE”
• Seems ridiculous, until you hear proposals to keep all traffic to and from a
country, within that country
• “Sure, BGP does say you should use this route, because it’s
cheaper/faster/nicer/network neutral/peered…but the law says you have to
keep it within our borders where we’re the only provider, because NSA”
• Again: The Internet was not the first attempt at large scale Internetworking!
It was the first one that worked at large scale, because everything else
demanded gatekeepers and rentiers
• This is the network made by nerds, not by bizdudes and certainly not by politicians
• It seems to work pretty well
Not to put too fine a point on it, but…
• We didn’t exactly want the Chinese Internet, or the Iranian Internet,
before Snowden
• I’m hoping we don’t want that now.
The General Reaction To NSA Corrupting
Crypto Standards (DUAL_EC_DBRG)
The Nuanced, Even More Disturbing Reality
• There’s a reason we were asking the NSA’s advice to avoid
cryptographic vulnerabilities
• Most cryptographic functions do not need the NSA’s help to be fatally
flawed
• That comes for free
• It takes an enormous amount of time and effort to find functions that might
not be flawed, and the NSA seemed good at telling us when we were wrong
• DES
• It’d be nice if we had a governmental department focused on
defensive operations…
• Or maybe a conference…
Even Obviously Good Advice Is Being Treated
With Deep Suspicion
• NIST: Heh, Keccak (SHA-3) is actually too slow. Performance matters.
• Zooko Wilcox-O’Hearn, creator of Tahoe-LAFS (probably the best
cryptographic distributed file system out there right now): Heh,
Keccak (SHA-3) is actually too slow. Performance matters.
• Community: NIST IS DOING MORE EVIL
…are we about to replace NIST with DJB?
(Who keeps releasing fast crypto functions)
No, seriously, I’m actually a huge DJB fan
• I’ve been advocating Curve25519 for use in a TLS-replacing protocol
for years
• But, uh, fewer trusted resources in a time of great need is not helpful
• “Linux scales. Linus does not scale.”
The Problem
0
0.5
1
1.5
2
NSA DJB
Mission Count
We’re All Kind Of Waiting For The Other Shoe
To Drop
• Not implementers, everything new keeps using DJBsec
• Academics aren’t really allowed to “know things” without some degree of
evidence
• Science!
• We do know that DUAL_EC_DBRG is compromised, but nobody was using that
except other feds (sadface)
• Pretty much everyone assumes the NIST P curves are compromised
• Big complex process to turn a “nothing up your sleeve” number (like pi) into a safe ECC curve
• Innocent string used by NIST P curve is c49d360886e704936a6678e1139d26b7819f7e90
• Every shirt has two sleeves
• NIST took the time to declare two curves, a P curve and a K curve, almost as if they assumed
eventually there would be a problem and it’d be nice if the standard could survive it
• The above does not pass scientific epistemology. Nobody cares.
The Larger Issue
• It’s not like cryptography worked particular well before the NSA
revelations
• The hard problems in crypto are not in the math, or the
implementation. They’re not even in “side channel vulnerabilities”, as
Shamir has said.
• Key management is the hard part, because that actually touches
users.
• Cryptography keeps getting seen as Math and Implementation. There
is a third aspect
• There is a complexity that generally goes unmodeled: Operations
My First Law of Operations
• Every project must be measured by the number of meetings required
to accomplish it
• If there is a meeting with someone outside your department, it’s 5x the cost.
If outside your company, 25x the cost.
• When’s the last time you saw meeting count in a crypto function?
• We have to learn to respect usability, and the sacrifices it may
demand
• Alex Stamos at Yahoo backing PGP for their mail interface is actually a pretty
big step – Yahoo knows UX
Summary
• Don’t let an attacker touch your storage – S^X
• Actively gather true entropy and kill the non-CS PRNGs with fire!
• Represent entropy in a way other than bit vomit
• Browsers become vastly more secure once UaF is prevented
• The NSA crypto fallout continues
• Yahoo’s PGP news is fantastic
• And…just one more thing
It’s Apple Related, So I Totally Get To Pull That
Line
• “Safari now blocks ads from automatically redirecting to the App
Store without user interaction. If you still see the previous behavior,
or find legitimate redirection to the App Store to be broken in some
way, please file a bug.”
-- IOS 8 Beta Release Notes from Apple
• YES ACTUALLY, THIS DRIVES ME CRAZY
• “I know you’re trying to browse this website, but I bet what you really want to
do is buy our ****ty game”
• **** THOSE GUYS
• Apple wants help? Hackers, lets do it
• And not for free
Third Party Bug Bounty
• I’ve become a believer in bug bounties
• This is new
• External bug quality can sometimes be of poor quality
• If you want richer bugs, maybe we should enrich bug hunters
• White Ops hereby sponsors an enhanced bug bounty for this particular
Apple bug
• $5,000 to the first autoredirection bug finder
• $2,500 to the second finder
• $1K to the next five finders
• We offered $250 six weeks ago, sorry, my bad
• We believe hackers can help fix things, and we’re putting our money
where our mouth is

More Related Content

What's hot

The best smart contract platforms in 2021
The best smart contract platforms in 2021The best smart contract platforms in 2021
The best smart contract platforms in 2021OliviaJune1
 
Blockchain Digital Transformation Presentation
Blockchain Digital Transformation PresentationBlockchain Digital Transformation Presentation
Blockchain Digital Transformation Presentation101 Blockchains
 
Blockchain Wallet | Blockchain Tutorial for Beginners | Blockchain Training ...
Blockchain Wallet | Blockchain Tutorial for Beginners | Blockchain Training  ...Blockchain Wallet | Blockchain Tutorial for Beginners | Blockchain Training  ...
Blockchain Wallet | Blockchain Tutorial for Beginners | Blockchain Training ...Edureka!
 
Overview of blockchain technology and architecture
Overview of blockchain technology and   architectureOverview of blockchain technology and   architecture
Overview of blockchain technology and architectureEY
 
Blockchain 101 | Blockchain Tutorial | Blockchain Smart Contracts | Blockchai...
Blockchain 101 | Blockchain Tutorial | Blockchain Smart Contracts | Blockchai...Blockchain 101 | Blockchain Tutorial | Blockchain Smart Contracts | Blockchai...
Blockchain 101 | Blockchain Tutorial | Blockchain Smart Contracts | Blockchai...Edureka!
 
MESSARI - Crypto_Theses_2023.pdf
MESSARI - Crypto_Theses_2023.pdfMESSARI - Crypto_Theses_2023.pdf
MESSARI - Crypto_Theses_2023.pdfdigitalinasia
 
Future of AI: Blockchain & Deep Learning
Future of AI: Blockchain & Deep LearningFuture of AI: Blockchain & Deep Learning
Future of AI: Blockchain & Deep LearningMelanie Swan
 
Blockchain in Banking, Business and Beyond
Blockchain in Banking, Business and BeyondBlockchain in Banking, Business and Beyond
Blockchain in Banking, Business and BeyondMichael Novak
 
Bitcoin Protocols 1.0 and 2.0 Explained in the Series: Blockchain: The Inform...
Bitcoin Protocols 1.0 and 2.0 Explained in the Series: Blockchain: The Inform...Bitcoin Protocols 1.0 and 2.0 Explained in the Series: Blockchain: The Inform...
Bitcoin Protocols 1.0 and 2.0 Explained in the Series: Blockchain: The Inform...Melanie Swan
 
Learning Solidity
Learning SolidityLearning Solidity
Learning SolidityArnold Pham
 
Future of cryptocurrency ppt.
Future of cryptocurrency ppt.Future of cryptocurrency ppt.
Future of cryptocurrency ppt.Bitex Global
 
Bitcoin, Ethereum, Smart Contract & Blockchain
Bitcoin, Ethereum, Smart Contract & BlockchainBitcoin, Ethereum, Smart Contract & Blockchain
Bitcoin, Ethereum, Smart Contract & BlockchainJitendra Chittoda
 
The Impact and Potential of Blockchain on the Banking Sector
The Impact and Potential of Blockchain on the Banking SectorThe Impact and Potential of Blockchain on the Banking Sector
The Impact and Potential of Blockchain on the Banking SectorPECB
 

What's hot (20)

Understanding Blockchain
Understanding BlockchainUnderstanding Blockchain
Understanding Blockchain
 
The best smart contract platforms in 2021
The best smart contract platforms in 2021The best smart contract platforms in 2021
The best smart contract platforms in 2021
 
Bitcoin
BitcoinBitcoin
Bitcoin
 
Blockchain Digital Transformation Presentation
Blockchain Digital Transformation PresentationBlockchain Digital Transformation Presentation
Blockchain Digital Transformation Presentation
 
Smart contracts
Smart contractsSmart contracts
Smart contracts
 
web3
web3web3
web3
 
Blockchain 101
Blockchain 101Blockchain 101
Blockchain 101
 
Blockchain Wallet | Blockchain Tutorial for Beginners | Blockchain Training ...
Blockchain Wallet | Blockchain Tutorial for Beginners | Blockchain Training  ...Blockchain Wallet | Blockchain Tutorial for Beginners | Blockchain Training  ...
Blockchain Wallet | Blockchain Tutorial for Beginners | Blockchain Training ...
 
Overview of blockchain technology and architecture
Overview of blockchain technology and   architectureOverview of blockchain technology and   architecture
Overview of blockchain technology and architecture
 
Blockchain 101 | Blockchain Tutorial | Blockchain Smart Contracts | Blockchai...
Blockchain 101 | Blockchain Tutorial | Blockchain Smart Contracts | Blockchai...Blockchain 101 | Blockchain Tutorial | Blockchain Smart Contracts | Blockchai...
Blockchain 101 | Blockchain Tutorial | Blockchain Smart Contracts | Blockchai...
 
MESSARI - Crypto_Theses_2023.pdf
MESSARI - Crypto_Theses_2023.pdfMESSARI - Crypto_Theses_2023.pdf
MESSARI - Crypto_Theses_2023.pdf
 
Future of AI: Blockchain & Deep Learning
Future of AI: Blockchain & Deep LearningFuture of AI: Blockchain & Deep Learning
Future of AI: Blockchain & Deep Learning
 
Blockchain in Banking, Business and Beyond
Blockchain in Banking, Business and BeyondBlockchain in Banking, Business and Beyond
Blockchain in Banking, Business and Beyond
 
Bitcoin Protocols 1.0 and 2.0 Explained in the Series: Blockchain: The Inform...
Bitcoin Protocols 1.0 and 2.0 Explained in the Series: Blockchain: The Inform...Bitcoin Protocols 1.0 and 2.0 Explained in the Series: Blockchain: The Inform...
Bitcoin Protocols 1.0 and 2.0 Explained in the Series: Blockchain: The Inform...
 
Learning Solidity
Learning SolidityLearning Solidity
Learning Solidity
 
Future of cryptocurrency ppt.
Future of cryptocurrency ppt.Future of cryptocurrency ppt.
Future of cryptocurrency ppt.
 
Bitcoin
BitcoinBitcoin
Bitcoin
 
Bitcoin, Ethereum, Smart Contract & Blockchain
Bitcoin, Ethereum, Smart Contract & BlockchainBitcoin, Ethereum, Smart Contract & Blockchain
Bitcoin, Ethereum, Smart Contract & Blockchain
 
The Tokenisation of Assets and Potential Implications for Financial Markets
The Tokenisation of Assets and Potential Implications for Financial MarketsThe Tokenisation of Assets and Potential Implications for Financial Markets
The Tokenisation of Assets and Potential Implications for Financial Markets
 
The Impact and Potential of Blockchain on the Banking Sector
The Impact and Potential of Blockchain on the Banking SectorThe Impact and Potential of Blockchain on the Banking Sector
The Impact and Potential of Blockchain on the Banking Sector
 

Viewers also liked

I Want These * Bugs Off My * Internet
I Want These * Bugs Off My * InternetI Want These * Bugs Off My * Internet
I Want These * Bugs Off My * InternetDan Kaminsky
 
Bh fed-03-kaminsky
Bh fed-03-kaminskyBh fed-03-kaminsky
Bh fed-03-kaminskyDan Kaminsky
 
Black ops of tcp2005 japan
Black ops of tcp2005 japanBlack ops of tcp2005 japan
Black ops of tcp2005 japanDan Kaminsky
 
232 md5-considered-harmful-slides
232 md5-considered-harmful-slides232 md5-considered-harmful-slides
232 md5-considered-harmful-slidesDan Kaminsky
 
How to Make a Decent PowerPoint
How to Make a Decent PowerPointHow to Make a Decent PowerPoint
How to Make a Decent PowerPointAdam Fowler
 
Neira jones pci london january 2013 pdf ready
Neira jones pci london january 2013 pdf readyNeira jones pci london january 2013 pdf ready
Neira jones pci london january 2013 pdf readyNeira Jones
 
Tactical Edge - How Much Security Do You Really Need?
Tactical Edge - How Much Security Do You Really Need?Tactical Edge - How Much Security Do You Really Need?
Tactical Edge - How Much Security Do You Really Need?Wendy Nather
 
RSA 2015 Realities of Private Cloud Security
RSA 2015 Realities of Private Cloud SecurityRSA 2015 Realities of Private Cloud Security
RSA 2015 Realities of Private Cloud SecurityScott Carlson
 
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure softwareBreak it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure softwareLeigh Honeywell
 
Distributed Denial Of Service Introduction
Distributed Denial Of Service IntroductionDistributed Denial Of Service Introduction
Distributed Denial Of Service Introductionwremes
 
AusCERT - Mikko Hypponen
AusCERT - Mikko HypponenAusCERT - Mikko Hypponen
AusCERT - Mikko HypponenMikko Hypponen
 

Viewers also liked (20)

I Want These * Bugs Off My * Internet
I Want These * Bugs Off My * InternetI Want These * Bugs Off My * Internet
I Want These * Bugs Off My * Internet
 
Bh fed-03-kaminsky
Bh fed-03-kaminskyBh fed-03-kaminsky
Bh fed-03-kaminsky
 
Dmk bo2 k7_web
Dmk bo2 k7_webDmk bo2 k7_web
Dmk bo2 k7_web
 
Dmk neut toor
Dmk neut toorDmk neut toor
Dmk neut toor
 
Interpolique
InterpoliqueInterpolique
Interpolique
 
Dmk blackops2006
Dmk blackops2006Dmk blackops2006
Dmk blackops2006
 
Bh eu 05-kaminsky
Bh eu 05-kaminskyBh eu 05-kaminsky
Bh eu 05-kaminsky
 
Dmk bo2 k8_bh_fed
Dmk bo2 k8_bh_fedDmk bo2 k8_bh_fed
Dmk bo2 k8_bh_fed
 
Confidence web
Confidence webConfidence web
Confidence web
 
Black ops of tcp2005 japan
Black ops of tcp2005 japanBlack ops of tcp2005 japan
Black ops of tcp2005 japan
 
Dmk shmoo2007
Dmk shmoo2007Dmk shmoo2007
Dmk shmoo2007
 
232 md5-considered-harmful-slides
232 md5-considered-harmful-slides232 md5-considered-harmful-slides
232 md5-considered-harmful-slides
 
How to Make a Decent PowerPoint
How to Make a Decent PowerPointHow to Make a Decent PowerPoint
How to Make a Decent PowerPoint
 
Neira jones pci london january 2013 pdf ready
Neira jones pci london january 2013 pdf readyNeira jones pci london january 2013 pdf ready
Neira jones pci london january 2013 pdf ready
 
Tactical Edge - How Much Security Do You Really Need?
Tactical Edge - How Much Security Do You Really Need?Tactical Edge - How Much Security Do You Really Need?
Tactical Edge - How Much Security Do You Really Need?
 
RSA 2015 Realities of Private Cloud Security
RSA 2015 Realities of Private Cloud SecurityRSA 2015 Realities of Private Cloud Security
RSA 2015 Realities of Private Cloud Security
 
Break it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure softwareBreak it while you make it: writing (more) secure software
Break it while you make it: writing (more) secure software
 
Distributed Denial Of Service Introduction
Distributed Denial Of Service IntroductionDistributed Denial Of Service Introduction
Distributed Denial Of Service Introduction
 
Dmk bo2 k8
Dmk bo2 k8Dmk bo2 k8
Dmk bo2 k8
 
AusCERT - Mikko Hypponen
AusCERT - Mikko HypponenAusCERT - Mikko Hypponen
AusCERT - Mikko Hypponen
 

Similar to Yet Another Dan Kaminsky Talk (Black Ops 2014)

A Technical Dive into Defensive Trickery
A Technical Dive into Defensive TrickeryA Technical Dive into Defensive Trickery
A Technical Dive into Defensive TrickeryDan Kaminsky
 
Dmk sb2010 web_defense
Dmk sb2010 web_defenseDmk sb2010 web_defense
Dmk sb2010 web_defenseDan Kaminsky
 
Java in High Frequency Trading
Java in High Frequency TradingJava in High Frequency Trading
Java in High Frequency TradingViktor Sovietov
 
Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st Janu...
Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st Janu...Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st Janu...
Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st Janu...Loadzen
 
William Cheswick Presentation - CSO Perspectives Roadshow 2015
William Cheswick Presentation - CSO Perspectives Roadshow 2015William Cheswick Presentation - CSO Perspectives Roadshow 2015
William Cheswick Presentation - CSO Perspectives Roadshow 2015CSO_Presentations
 
Complex things explained easily
Complex things explained easilyComplex things explained easily
Complex things explained easilyLuca Tumedei
 
Dmk blackops2006 ccc
Dmk blackops2006 cccDmk blackops2006 ccc
Dmk blackops2006 cccDan Kaminsky
 
Lets talk about bug hunting
Lets talk about bug huntingLets talk about bug hunting
Lets talk about bug huntingKirill Ermakov
 
Security Meetup 22 октября. «When big brick wall becomes wooden fence» or «ho...
Security Meetup 22 октября. «When big brick wall becomes wooden fence» or «ho...Security Meetup 22 октября. «When big brick wall becomes wooden fence» or «ho...
Security Meetup 22 октября. «When big brick wall becomes wooden fence» or «ho...Mail.ru Group
 
Keynote, LambdaConf 2014 - The Silent Productivity Killer
Keynote, LambdaConf 2014 - The Silent Productivity KillerKeynote, LambdaConf 2014 - The Silent Productivity Killer
Keynote, LambdaConf 2014 - The Silent Productivity KillerPaul Phillips
 
BSides Hannover 2015 - Shell on Wheels
BSides Hannover 2015 - Shell on WheelsBSides Hannover 2015 - Shell on Wheels
BSides Hannover 2015 - Shell on Wheelsinfodox
 
Unbreaking Your Django Application
Unbreaking Your Django ApplicationUnbreaking Your Django Application
Unbreaking Your Django ApplicationOSCON Byrum
 
Password Storage Sucks!
Password Storage Sucks!Password Storage Sucks!
Password Storage Sucks!nerdybeardo
 
Fi fo euc 2014
Fi fo euc 2014Fi fo euc 2014
Fi fo euc 2014Licenser
 
Mongodb, Node.js and You: PART I
Mongodb, Node.js and You: PART IMongodb, Node.js and You: PART I
Mongodb, Node.js and You: PART IMitch Pirtle
 
White-box Cryptography -BayThreat 2013
White-box Cryptography -BayThreat 2013White-box Cryptography -BayThreat 2013
White-box Cryptography -BayThreat 2013Nick Sullivan
 
Bugs Aren't Random
Bugs Aren't RandomBugs Aren't Random
Bugs Aren't RandomDan Kaminsky
 

Similar to Yet Another Dan Kaminsky Talk (Black Ops 2014) (20)

Dmk bo2 k8_ccc
Dmk bo2 k8_cccDmk bo2 k8_ccc
Dmk bo2 k8_ccc
 
A Technical Dive into Defensive Trickery
A Technical Dive into Defensive TrickeryA Technical Dive into Defensive Trickery
A Technical Dive into Defensive Trickery
 
Dmk sb2010 web_defense
Dmk sb2010 web_defenseDmk sb2010 web_defense
Dmk sb2010 web_defense
 
Java in High Frequency Trading
Java in High Frequency TradingJava in High Frequency Trading
Java in High Frequency Trading
 
Reverse engineering
Reverse engineeringReverse engineering
Reverse engineering
 
Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st Janu...
Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st Janu...Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st Janu...
Load testing, Lessons learnt and Loadzen - Martin Buhr at DevTank - 31st Janu...
 
William Cheswick Presentation - CSO Perspectives Roadshow 2015
William Cheswick Presentation - CSO Perspectives Roadshow 2015William Cheswick Presentation - CSO Perspectives Roadshow 2015
William Cheswick Presentation - CSO Perspectives Roadshow 2015
 
Complex things explained easily
Complex things explained easilyComplex things explained easily
Complex things explained easily
 
Dmk blackops2006 ccc
Dmk blackops2006 cccDmk blackops2006 ccc
Dmk blackops2006 ccc
 
Lets talk about bug hunting
Lets talk about bug huntingLets talk about bug hunting
Lets talk about bug hunting
 
Security Meetup 22 октября. «When big brick wall becomes wooden fence» or «ho...
Security Meetup 22 октября. «When big brick wall becomes wooden fence» or «ho...Security Meetup 22 октября. «When big brick wall becomes wooden fence» or «ho...
Security Meetup 22 октября. «When big brick wall becomes wooden fence» or «ho...
 
Keynote, LambdaConf 2014 - The Silent Productivity Killer
Keynote, LambdaConf 2014 - The Silent Productivity KillerKeynote, LambdaConf 2014 - The Silent Productivity Killer
Keynote, LambdaConf 2014 - The Silent Productivity Killer
 
Distributed "Web Scale" Systems
Distributed "Web Scale" SystemsDistributed "Web Scale" Systems
Distributed "Web Scale" Systems
 
BSides Hannover 2015 - Shell on Wheels
BSides Hannover 2015 - Shell on WheelsBSides Hannover 2015 - Shell on Wheels
BSides Hannover 2015 - Shell on Wheels
 
Unbreaking Your Django Application
Unbreaking Your Django ApplicationUnbreaking Your Django Application
Unbreaking Your Django Application
 
Password Storage Sucks!
Password Storage Sucks!Password Storage Sucks!
Password Storage Sucks!
 
Fi fo euc 2014
Fi fo euc 2014Fi fo euc 2014
Fi fo euc 2014
 
Mongodb, Node.js and You: PART I
Mongodb, Node.js and You: PART IMongodb, Node.js and You: PART I
Mongodb, Node.js and You: PART I
 
White-box Cryptography -BayThreat 2013
White-box Cryptography -BayThreat 2013White-box Cryptography -BayThreat 2013
White-box Cryptography -BayThreat 2013
 
Bugs Aren't Random
Bugs Aren't RandomBugs Aren't Random
Bugs Aren't Random
 

More from Dan Kaminsky

Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017Dan Kaminsky
 
Move Fast and Fix Things
Move Fast and Fix ThingsMove Fast and Fix Things
Move Fast and Fix ThingsDan Kaminsky
 
Chicken Chicken Chicken Chicken
Chicken Chicken Chicken ChickenChicken Chicken Chicken Chicken
Chicken Chicken Chicken ChickenDan Kaminsky
 
Some Thoughts On Bitcoin
Some Thoughts On BitcoinSome Thoughts On Bitcoin
Some Thoughts On BitcoinDan Kaminsky
 
Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)Dan Kaminsky
 
Showing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of TryingShowing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of TryingDan Kaminsky
 
Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)Dan Kaminsky
 
Bh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackopsBh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackopsDan Kaminsky
 

More from Dan Kaminsky (17)

Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017
 
Move Fast and Fix Things
Move Fast and Fix ThingsMove Fast and Fix Things
Move Fast and Fix Things
 
Chicken
ChickenChicken
Chicken
 
Chicken Chicken Chicken Chicken
Chicken Chicken Chicken ChickenChicken Chicken Chicken Chicken
Chicken Chicken Chicken Chicken
 
Black ops 2012
Black ops 2012Black ops 2012
Black ops 2012
 
Some Thoughts On Bitcoin
Some Thoughts On BitcoinSome Thoughts On Bitcoin
Some Thoughts On Bitcoin
 
Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)
 
Showing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of TryingShowing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
 
Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)
 
Interpolique
InterpoliqueInterpolique
Interpolique
 
Black opspki 2
Black opspki 2Black opspki 2
Black opspki 2
 
Bh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackopsBh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackops
 
Bh eu 05-kaminsky
Bh eu 05-kaminskyBh eu 05-kaminsky
Bh eu 05-kaminsky
 
Dmk audioviz
Dmk audiovizDmk audioviz
Dmk audioviz
 
Bo2004
Bo2004Bo2004
Bo2004
 
Gwc3
Gwc3Gwc3
Gwc3
 
Advanced open ssh
Advanced open sshAdvanced open ssh
Advanced open ssh
 

Recently uploaded

The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightSafe Software
 
Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)Muhammad Tiham Siddiqui
 
Patch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updatePatch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updateadam112203
 
2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdfThe Good Food Institute
 
How to release an Open Source Dataweave Library
How to release an Open Source Dataweave LibraryHow to release an Open Source Dataweave Library
How to release an Open Source Dataweave Libraryshyamraj55
 
UiPath Studio Web workshop series - Day 1
UiPath Studio Web workshop series  - Day 1UiPath Studio Web workshop series  - Day 1
UiPath Studio Web workshop series - Day 1DianaGray10
 
CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024Brian Pichman
 
UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3DianaGray10
 
Introduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationIntroduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationKnoldus Inc.
 
AI Workshops at Computers In Libraries 2024
AI Workshops at Computers In Libraries 2024AI Workshops at Computers In Libraries 2024
AI Workshops at Computers In Libraries 2024Brian Pichman
 
How to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptxHow to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptxKaustubhBhavsar6
 
Scenario Library et REX Discover industry- and role- based scenarios
Scenario Library et REX Discover industry- and role- based scenariosScenario Library et REX Discover industry- and role- based scenarios
Scenario Library et REX Discover industry- and role- based scenariosErol GIRAUDY
 
Top 10 Squarespace Development Companies
Top 10 Squarespace Development CompaniesTop 10 Squarespace Development Companies
Top 10 Squarespace Development CompaniesTopCSSGallery
 
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENTSIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENTxtailishbaloch
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingFrancesco Corti
 
The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)codyslingerland1
 
LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0DanBrown980551
 
Extra-120324-Visite-Entreprise-icare.pdf
Extra-120324-Visite-Entreprise-icare.pdfExtra-120324-Visite-Entreprise-icare.pdf
Extra-120324-Visite-Entreprise-icare.pdfInfopole1
 
Oracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptxOracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptxSatishbabu Gunukula
 

Recently uploaded (20)

The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and Insight
 
Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)
 
Patch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updatePatch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 update
 
2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf
 
How to release an Open Source Dataweave Library
How to release an Open Source Dataweave LibraryHow to release an Open Source Dataweave Library
How to release an Open Source Dataweave Library
 
SheDev 2024
SheDev 2024SheDev 2024
SheDev 2024
 
UiPath Studio Web workshop series - Day 1
UiPath Studio Web workshop series  - Day 1UiPath Studio Web workshop series  - Day 1
UiPath Studio Web workshop series - Day 1
 
CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024
 
UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3
 
Introduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationIntroduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its application
 
AI Workshops at Computers In Libraries 2024
AI Workshops at Computers In Libraries 2024AI Workshops at Computers In Libraries 2024
AI Workshops at Computers In Libraries 2024
 
How to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptxHow to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptx
 
Scenario Library et REX Discover industry- and role- based scenarios
Scenario Library et REX Discover industry- and role- based scenariosScenario Library et REX Discover industry- and role- based scenarios
Scenario Library et REX Discover industry- and role- based scenarios
 
Top 10 Squarespace Development Companies
Top 10 Squarespace Development CompaniesTop 10 Squarespace Development Companies
Top 10 Squarespace Development Companies
 
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENTSIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is going
 
The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)
 
LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0
 
Extra-120324-Visite-Entreprise-icare.pdf
Extra-120324-Visite-Entreprise-icare.pdfExtra-120324-Visite-Entreprise-icare.pdf
Extra-120324-Visite-Entreprise-icare.pdf
 
Oracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptxOracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptx
 

Yet Another Dan Kaminsky Talk (Black Ops 2014)

  • 1. Yet Another Dan Kaminsky Talk (About much more than RNG) Dan Kaminsky Chief Scientist White Ops Special Guest: Ryan Castellucci, Security Engineer, White Ops
  • 2. Back To Defcon! • This is my thirteenth rodeo • Why? • It’s fun tech, but why this tech, why this place, why this way? • Fundamentally subversive, even for Defcon • Defcon loves to show what can be broken • I love to show what’s possible • We can scan the whole Internet, in seconds! • We can bust violators of Network Neutrality! • We can play video of Darth Vader doing Riverdance over DNS! • Among other tricks involving DNS • Like DNS rebinding and hacking home routers • These are not actually the same thing • So why are we here?
  • 3. Subjects For Today • Why do we keep getting owned by bad Random Number Generation? • Users are expected to recognize and maybe even repeat complex patterns, and they’re failing. Can we do better? • What do we do about the infinite supply of Browser 0day? • What do we do about DDoS, which is actually growing substantially? • So, just how much did the NSA shit the bed? • But first…I want to talk about why all this stuff we do is useful. By discussing hard drives.
  • 4. A Scenario • An attacker has compromised a system, and put something malicious on the hard drive. How bad could it be? • Added an autolaunching daemon? • Replaced core OS files? • Put a virus in the MBR? • Can you just wipe out the drive and be done with this?
  • 5. What Is The Difference Between… A Hard Drive A Brick
  • 6. Given Sufficient Research, None A Hard Drive == A Brick ==
  • 7. Theory Vs. Reality: What Is A Hard Drive
  • 8. Xzibit’s Iron Law Of Computer Architecture • Yo Dawg, I heard you liked computers, so I put a computer in your computer so you could compute while you compute • This is basically how computers work – hard work is offloaded to hardware, which is really just another computer that has a fast way to influence you • Fast == trusted == insecure • Everything is generic now – the iPhone has seven ARM chips • The biggest lie about your computer is that it’s just one computer • That hard drive is just another computer with direct access to your system memory via specially designed protocols • Doubt me?
  • 9. From An Old Project with Travis Goodspeed: Lets Get A Shell On This Here Seagate!
  • 10. Oh Shell, You’re even self documenting!
  • 11. Documents commands, their locations, their arguments…
  • 12. Get some internal drive metadata…
  • 13. Learn about the disc you know…
  • 14. …and the disc you don’t…
  • 15. Can Even Read It Out…
  • 17. Don’t think that you need that serial link…
  • 18. …or that I was kidding about making bricks • Fate: Platters exposed, fingerprinted. Firmware dumped as 001.rom. • Fate: Bricked by Dan when he wrote to the buffer. Probably repairable. • Fate: Bricked by dan with HDPARM, then sawed apart by Travis for post-mortem firmware analysis. • Fate: Semi-bricked by Dan by raising the serial port rate to 625000. Repairable.
  • 19. The Paper That Eventually Followed • Implementation and Implications of a Steath Hard-Drive Backdoor Jonas Zoldach, Anil Kurmus, Davide Balzarotti, Erik-Oliver Blass, Aurelien Francillon, Travis Goodspeed, Moitrayee Gupta, and Ioannis Koltsidas • I’m an unindicted co-coconspirator  • 10 months of solid reverse engineering to create the malicious firmware payload • Not at all the first time this has been done, but maybe the first time publicly/academically
  • 20. The Significance of the Research: S^X (Storage XOR Execution) • Highly desirable property for secure clouds • “It’s not about ownage, it’s about continued ownage. It’s about coming back in a year and having the door still open for you” • Requires exploitation and persisted storage • If your storage doesn’t parse, it can’t be exploited • If your execution doesn’t store, there’s nowhere to persist • You can’t start thinking about S^X if you think you already have it • There are ways of building S^X out of existing gear – but nobody thinks you have to • Nobody thinks you have to have exclusive hosts on cloud providers either  • Thus, the value of hacker engineering • No delusions • Operation from first principles • The best thing hackers break are assumptions • We are needed.
  • 21. I Believe In The Internet
  • 22. The Internet Is Not Just For Us • I believe in TexasGirly1979 having six and a half MILLION people loving her damn cat • Without Bob Saget, a laugh track, and a baseball to the testicles as followup • I believe in responding to being told your music sounds like “rats being strangled” by becoming a dubstep violinist and getting a half billion hits on YouTube • Remixing Skyrim and Zelda and Halo may have something to do with my opinion • I believe in email over Interoffice memos, Skype over (very) plain old telephone service, online banking over waiting for a bank teller • And I believe we could lose it all, and there are some who might even prefer that
  • 23. The Thing To Remember • The Internet was not the first time we tried to create the Internet • It was like the 8th • Prodigy tried • Minitel tried • America Online really, really tried • Spent a billion dollars on modem lines! • (They actually still make $160M/yr off that.) • The Internet was free • Not just free as in murka • It was free as in no rent – all of the above wanted to charge transaction fees • The Internet just wanted a few pennies a year for a domain name • The free Internet has disrupted a heck of a lot • Don’t think there are those who wouldn’t like to disrupt back
  • 24. The Challenge • We know what’s really possible • We know that breaking everything, is really possible • We don’t know that fixing everything, is really possible… • …but technically, we don’t actually know fixing everything is impossible • Technically correct is the best kind of correct • So why do I do this, and why do I do this here? • Because here, I see openness to possibility • Including the possibility the Internet might turn into AOL • I see the sheer joy of understanding the actual mechanisms at play • I see the skepticism that allows BS – especially security BS – to be discussed and recognized
  • 25. Let’s Talk Random Number Generators • “The generation of random numbers is too important to be left to chance” • Many processes require a generator of unpredictable numbers • Last 1000 numbers don’t tell you the next number • Last 1000 numbers also don’t tell you the number 1001 times ago • That they require such a generator doesn’t mean they’re using such a generator
  • 26. What’s happening to all these web frameworks • You actually don’t log in very frequently • Top 10 e-commerce platform: 7 logins a second, worldwide • Logging in gives you a token • If you’re lucky, it’s HMAC(who_you_are, key) • In the real world, it’s often Random() • Sure would suck if that wasn’t actually random…
  • 27. Dominique Bongard’s (AKA @reversity) Beautiful WPS Attack From #Passwords14
  • 28. Details • WPS Protocol assumes 128 bits of entropy in AES keys • Reality: 32 bit LFSR, 32 bit LFSR, 0 bit (aeskey is always 0) • 2**128: Big • 2**32: Not so big (~4B, remember your CPU does that many operations in seconds)
  • 29. Why Do We Keep Getting Owned By Random Number Generators? • Wrong Answers • “Because we used SHA-1 instead of SHA-256” • Freaking MD4 would work • “Because we used HASH_DBRG instead of HMAC_DBRG” • “Because we used the same entropy for too long” • “Because we had only one pool for mixing entropy instead of thirty two” • There’s a thousand ways to build a CSPRNG (cryptographically secure pseudo random number generator) and all of them would fail less than what we’re doing • Even forking/cloning VMs doesn’t fail this frequently • Right Answers • 1) No entropy • 2) No CSPRNG by default
  • 30. A Little Dab’ll Do Ya • CSPRNG’s expand a little bit of entropy (128 bits) into billions of gigabytes • Best attack would be to brute force the 2**128 possible initial seeds and find the one that matches the stream • Good luck with that…unless there’s actually not even 128 bits • There’s often actually not even 128 bits    • Turn on a machine, no keyboard, no mouse, no disk…no entropy. • 1/200 RSA keys on the Internet were badly generated, meaning actually probably 1/50 • Heninger attack only found all identical private keys, not similar keys • Private keys are just small chunks of randomness that ended up prime • Shouldn’t /dev/random or /dev/urandom have prevented this?
  • 31. Perfection Is The Enemy Of The Good • Why we like kernel RNGs (/dev/random, /dev/urandom) • Kernel code gets events from hardware • General thinking is that event timing from foreign hardware is on a separate clock • All good entropy is a fast clocked system measuring a slow clocked system • Inter-keystroke timing from a human to the CPU nanosecond • There’s also only one kernel • If anyone gets entropy everyone gets entropy • Operating systems are supposed to provide services that are easy to screw up • Can get more complexity/correctness encapsulated in the OS rather than monkey-shoved into each language or application • What went wrong • /dev/[u]random still fails when there’s no events coming in from the hardware • No keyboard, no mouse, no disk == no events • Yes, it’d be nice if there was hardware entropy generators, but not happening
  • 32. Solving The True Entropy Problem • You don’t have to be perfect every time • You just need to be better than the ONE NINE OF RELIABILITY the status quo has achieved • Be embarrassed • 1) Force synthesis of events • 2) Don’t necessarily be afraid to do this in userspace • Especially in a world of VMs, kernel is nothing but a single threaded process • What this means • Measure the real time clock (kilohertz at best) with the CPU (megahertz to gigahertz) • Possibly do some work with non-deterministic time (atomic memory writes) • Do standard whitening (Von Neumann – drop 00 and 11, 01 is a 0, 10 is a 1) • This is the Dakarand (Truerand) approach. It may fail in some very rare scenario. It will fail less than the status quo. • Security means it’s OK to fail less.
  • 33. Solving The True Problem • Operating systems have /dev/urandom which is generally pretty good – but does anything use it? • JavaScript Math.Random(): no • Ruby Random.rand(): no • Java.util.Random(): no • PHP rand(): no • Glibc rand(): hellllllllllllllll no • Standard RNG is LFSR or Mersenne Twister – if you want security, you’ve got to hunt down some other API • And it’s always funky and different! Math.random(); var a = new Uint32Array(1); window.crypto.getRandomValues(a); • How well does insecure by default work anywhere else? • Pretty badly
  • 34. The Obvious Question: Why not be secure by default? • Instead of requiring some special, magic, and consistently overcomplicated API for Secure Random™, why not just have all random calls not be crap? • Liburandy • Silently hijacks standard randomness functions in common languages, backs them with /dev/urandom (on Linux) • Would be CryptGenRandom on Windows • The OS already does this right, lets just hook dev intent to something that’s not busted • Initial support for JS(Node, Browsers), Ruby, LD_PRELOAD (arbitrary libc), PHP, Python. OpenJDK soon • Ryan Castellucci of White Ops helping to write this • Will eventually support some important runtime features • Entropy Metadata (runtime will be defining security rather than source code) • Fixed seed • High speed mode
  • 35. What’s Wrong With Liburandy (Lets play chess against myself a bit) • Two General Objection: Seed and Speed • Seed: Useful for getting consistent test results (Random, but the same random set) • 99% of the time you see seeding, it’s C seeding time because people don’t want the same random results • Can set a special flag (environment variable) • Speed: urandom is slower than LFSR/MT • If you wanted it to be fast why are you writing in in ruby • This is actually why things have been left crappy – so as to not lose benchmarks 
  • 36. The Headaches Of Speed • /dev/urandom is fast enough for almost all uses • That being said, it’s still a lot slower than LFSR/MT • Linux: Only 3.7MB/sec – that’s only 947K ints/sec (and that’s with CPU drain)
  • 37. Should we use a userspace CSPRNG, just not a crappy one? • Seed with [u]random from time to time to still absorb whatever entropy it does get • Minimal/Fast CSPRNG: SipHash(Seed, Counter++); • Yes, this actually works • ~20x speed of /dev/urandom on Linux • Possible improvement: CLOCK_MONOTONIC • Ideally, we’d just be able to ask the CPU for some random bits whenever userspace wanted a few • That’s way too easy (and we’d probably never trust the output anyway) • But we can ask the CPU for time • Even forked, likelihood near zero of repeated return value • For VMs, you don’t get a surfaced event on clone, but you do get to plunge into the host to find out nanosecond time • Also can be done on a per query basis, which cleans up a bunch of buffering issues from reading off a file handle
  • 38. My preferred CSPRNG • SipHash(Secret || Counter++ || Previous_Output || ShiftedTime) • ShiftedTime is CLOCK_MONOTONIC, shifted by some absolute amount so the attacker can’t just look up the global time and predict bits • Previous_Output means if ShiftedTime only has one shot to repeat • Not using this yet, because I’m an ornery member of Team Just Use Urandom • Let’s not debate userspace vs. kernelspace • We agree: DEATH TO LFSR • Also possible that other hashes besides SipHash are good • Blake • Skein (can actually be 2x speed of SipHash, due to larger output) • Maybe we make /dev/urandom fast on Linux? • Probably need an API to probe for metadata about urandom?
  • 39. The Other Entropy Problem • d3b07384d113edec49eaa6238ad5ff00 • 1Ngju42mHfxJJDEKA15rHUum17rcDEf699 • A1$jh-89)&@4bc (oh wait, no: **************) •
  • 40. STOP PUKING BITS (Images of 8 Bit Vomit)
  • 41. The Problem At Hand • Computers need Humans to recognize and remember larger numbers of bits • Human face recognition only works to about 16 bits (1/65536) • Computers want 24-128 bits depending on context • Recognition: Is this the hash from before? • Repetition: What is your password? • Standard Bit Representations are terrible • Humans did not evolve to recognize hex, Base64, Base58, or…squiggly
  • 42. Previous Work On Cryptomnemonics • Some previous work from 2006: Names • 512 Male Names (9 bits), 1024 Female Names (10 bits), 8192 Last Names (13 bits) == 32 bits per couple • Heteronormative, but surprisingly diverse! • Julio and Epifania Dezzutti Luther and Rolande Doornbos Manual and Twyla Imbesi Dirk and Cuc Kolopajlo Omar and Jeana Hymel • Important to show names every time a connection is made, not just on challenge • Would you remember a face you saw only the one time there was an auth challenge?
  • 43. Can We Do Better? • Humans do have memory capacity, it’s just not for arbitrary bits • We remember objects, and specifically stories, more than we remember 1’s and 0’s • So if you can represent 1’s and 0’s as stories, humans will recognize and repeat them better • Also, you’ll be able to put a password in and have it spell check • Experiment: Use triads of adjective/noun/verbs, set up to be “maximally distant” from eachother • Encode them in a way that is order independent, i.e. it doesn’t matter if the dog or the cow is brown or orange • Ryan Castellucci has been implementing this, here’s how he did it and where we’re seeing this being immediately useful
  • 44. Storybits v0.1 • Hex bits: 5e4dcc3b5aa765d61d83 (80 bits) • Story encoding (early): • macho acid answering rustic cable fetching stuffy jacket forbidding wacky riot opening • Story decoder autocorrects • node demo.js "wckay jacket forbidrustic fetch cableacid mache answering open riot$$" • 5e4dcc3b5aa765d61d83 • Words are misspelled, out of order, in different tenses, missing spaces, etc.
  • 45. Details • Implementations in JavaScript and Python • Rough, but releasing soon • Two major components • Combinatic Encoder • Encodes information with symbols that may not repeat • BADFGC is legal, AABBCC is not • Because symbols are independent, order doesn’t matter • Word Mapper • Maps combinatorial numbers to words in part-of-speech wordlists • Adjectives, nouns, verbs • Instead of 321, 561, 312, it’s “rustic fetching acid” • Allows for strong correction from word variants to original numbers • Words are chosen to have maximum distance for maximum correctability
  • 46. On The Selection Of Passwords • We have to get past l33tspeak as a security technology • We punt generation of passwords to users because we don’t want to “screw it up” and we imagine if the user does it, it’s at least their fault for failing • This scheme lets passwords be generated server side, that have a hope of being memorable • Passwords that can be corrected are passwords that are more easily remembered • Faster recovery from silly typos allows password stretching to be more aggressive • Don’t suffer the stretch delay because you missed a key – it autocorrects and still works
  • 47. Major Use Case: Phidelius Approaches Are Going Mainstream • Phidelius: Trick from a previous talk that seeded RNG w/ a passphrase • Allowed passphrases for SSH, SSL certs, pretty much mapped words to asymmetric crypto • A little fragile because it was a /dev/[u]random hijack • These approaches are now popular for asymmetric key management • Brainwallet:”Word/phrase to a Bitcoin address” • Minilock: “Word/phrase to a PGP key” • Incredibly vulnerable to insufficient entropy in the word or phrase • Because the public key is public, and the whole world can try to crack it • Has been an expensive problem in Brainwallet • Tens of thousands of dollars worth of BTC have been taken
  • 48. Squaring The Circle • Brainwallet and Minilock need human-memorable entropy • Actual security needs more entropy • Storybits increase memorable entropy, allow the entropy to come from the machine (which can generate it) and not the user (who clearly can’t) • Extensions • Split Mode – Allow entropy to be split between two words, one that’s easily remembered (but very slow to crack), another that’s kept on a hard drive or offline to allow fast transfer of the key to a new device • The user gets to transfer in seconds • The attacker has to try to crack for hours per guess • Breaks the ~20 bit limit on how much you can stretch a key
  • 49. Two More Tricks (Not Necessarily Advisable) • Local Shrinking • Will always be easier to recognize 24-32 bits instead of 80-128 bits • If you only force the attacker to match 24 bits, he can brute force random keys until he finally gets one that matches just the 24 bits you’re looking for • Olde trick against PGP KeyIds – “DEADBEEF attack” • But what if the attacker doesn’t know which 24 bits to match? • If you have a local shrinking code – sort of a password for recognition – it’s hashed against the full size 128 bit hash and truncated secretly to 24 bits • The attacker doesn’t know the code for the truncation, so he has to match everything. You do know the code so you only have to match a little. • Local Stretching • Technically can have a “master password” that’s mixed with all your otherwise small passwords and shared across many sites • Whether the site uses scrypt or some other key stretcher, its stored password is guaranteed to be stretched outside of cracking range • Password Policy Survival: We have mutually exclusive requirements (symbols, no symbols, numbers, no numbers). Can infer server policy from supplied password, persist it post-stretch
  • 50. Browser 0day: The Shoe Finally Dropped • IE had more attacks in 2013 than Java • How is this possible? MS has been working to secure IE for a decade! • IE is basically Windows: The Remix (feat. The Internet) • Take a local object model (COM), hand it to bad guys, wait • This ultimately applies to every browser, because the spec ends up encoding a COM-like implementation (there’s an interface description language / IDL). • Plugins were nice because they were across browsers and tended to be the thing outside the “sandboxes” but now the browsers themselves are the low hanging fruit • “My TOR deanon has a first name, it’s Firefox 0day” as the Grugq would sing
  • 51. Use After Free: The Infinite Well Of Browser Vulns • Browsers are constantly allocating memory for objects of all sorts of interesting types • Objects can point to eachother • When nothing points to an object, then you can free/reuse that memory • Lots and lots of ways to point to an object • Ever screw it up, all hell breaks loose • Allocate a table (0x12341234 == Pointer to Table) • Free the table (0x12341234 == Available For Allocation) • Allocate an image (0x12341234 == Pointer to Image) • Access the image via its old context as a table (0x12341234 contains contents of Image, being accessed via handlers for Table) • “Use After Free” == 90%-95% of the “deep vulnerable” attack surface for the web
  • 52. Google and Microsoft Have Solutions Firefox Doesn’t, And Is Suffering For It • Google Solution: Typed Heap • Chrome is allocating all objects of the same type, in the same “sub-heap” • Memory once used for a table, will never be used for an Image, because that’s going into the Image heap • Microsoft Solution: Nondeterministic Freeing • (Oversimplifying, they’re doing a lot of stuff) • They’re making it so you don’t quite know when the memory has been freed, and thus aren’t guaranteed a reliable or rapid attack • This is great. Attack the unique needs of an exploit – this is counterexploitation
  • 53. My Trick: Iron Heap • (Thanks Rob Graham for the name!) • You can’t Use After Free if you don’t free! • This is too expensive if you do it with physical memory • But on 64 bit machines, we have a damn near infinite amount of virtual memory • The basic idea is to never reuse an allocation – the physical memory is reused but the handles aren’t • 0x1234123412341234, once freed, stops pointing to any physical memory • Exploit that
  • 54. Iron Heap Efficiency • Efficiency • Finite number of active allocations allowed – you’re leveraging the page tables which don’t like to be that stressed • Can have a “hot list” of pages that are directly mapped, and a secondary list that’s “swapped in” on demand • How compressed RAM works • Can potentially add guard pages between allocations to prevent overflows • Overflows have actually gotten kinda rare • Forces 8K per alloc, which is a bit high, though the compressed backing store can be fully packed (no pointers to it are exposed in user space) • Implementation • Can be run in both userspace (with libsigsegv to catch the extra accesses) and in kernel (which is already handling this sort of swapping for, well, swap) • Don’t necessarily object to kernel dependencies or modules • Linux has a crazy limitation where you can’t get page permissions without parsing text!
  • 55. Downsides of Iron Heap • No code available (yet, just PoC’s are built) • Really leans on 64 bit • Browsers aren’t entirely fantastic at that yet
  • 56. What May Work Today: Diehard(er) • Interesting secure allocator from Emery Berger @ UMass • Advanced ASLR implementation w/ out of band heap metadata • Supports Linux and Windows (and Mac, to some nonzero degree) • Suppresses Use After Free, mostly by delaying free (similar to MS approach) • Available today (you do need to recompile with --disable-jemalloc) • Probably worth exploring for Tails etc. • ASLR, NX/DEP, other methods assume corruption has occurred and try to enforce limits to make the corruption unexploitable • UAF blockers actually prevent the initial corrupting moment • There’s nothing going on in Infosec that’s killing more 0day
  • 57. The Plan • Firefox needs a story around memory hardening • It’ll take quite a bit to get them to give up their incredibly efficient jemalloc • First step, let’s get something production worthy for “special Firefox installs” • Tor • Tails • Then let’s look at getting it mainstream • “Like millions of 0day cried out all at once, and were silenced” • Dr. Emery Berger has agreed to join this effort – we’re going to make something production worthy!
  • 58. Need To Start Thinking about DDoS Again • 1 >100GB flood in 2013 • 114 >100GB floods in 2014 • Generally, we think of DDoS involving botnets firing their hordes at some poor web server • The largest and most damaging floods are actually involving spoofed traffic that’s reflecting off Internet DNS and NTP servers • No DNSSEC involved or required • Important to understand why spoofed reflection is so dangerous
  • 59. Why Reflected Floods Are Nasty • Here’s a network. • Lots of routes around the core • Fewer routes from each source, to each destination
  • 60. An unreflected packet stream • Packets are always taking the “fastest” next hop to the target network • Bandwidth == maximum available for the slowest single hop (wherever that is)
  • 61. The Reflected And Spoofed Packet Stream • It goes out to everywhere, spreading the load across all the inbound hops • Everyone replies to just one place, via all inbound links • Boom.
  • 62. What To Do? • BCP38/URPF • Ideally, there wouldn’t be networks that allowed you to lie about who you are • Every network link would have a computed range of addresses it could speak for, and that would be that • This actually is a complete success in the DSL/Cable world • Not saying we shouldn’t continue to strive for BCP38 compliance • At least 2300 networks w/ no BCP38 compliance • Can we do more?
  • 63. Stochastic Tracing: Bringing Back An Old Idea • This is at least 12-13 years old of an idea (roughly, I’m adding some quirks) • The Internet and it’s problems were different that long ago. What wasn’t ideal then might be good now • Basic idea: One out of every 100K-10M packets, a “tracer” goes out declaring a hop along the route that sent traffic • Sort of like a “background traceroute” • Irrelevant network load for normal streams, but DDoS would become traceable instantaneously – the bigger the DDoS, the faster degraded networks would identify themselves • Implementation receives a GRE stream of a small subset of packets – well supported • Probably a way to do this w/ command line haxory as well
  • 64. Maintaining Privacy and Security • Tracing traffic only goes to hosts that should otherwise be able to see the original payloads • Destination IP for all traffic • Source IP for DNS and NTP (and any other blind responding protocols that pop up) • Haven’t decided what the payload would be – ICMP, HTTP, etc. • To be on the open Internet is to get random stuff, so the only question is what’s easily catchable by a DDoS victim • One variation: Allow alternate destination to be declared in Reverse DNS space • 4.3.2.1.in-addr.arpa IN PTR blabla.foo.com • The in-addr.arpa space could be used for more than just PTR records • Could declare an alternate destination for tracer traffic, or flags for format / multidrop • Still under the authority of the IP address • Obviously should sign tracer payloads with ED25519 keys, possibly declared in DNS
  • 65. Long Term Vision • Reduce the time between receiving a DDoS and tracing the involved networks • Ultimately, automatic suppression of DDoS (though this gets really messy really fast, because so many hops on route see enough to send the shutdown signal) • There are large enough floods growing at fast enough frequency that work like this is necessary • And since Paul Vixie would kill me if I didn’t say it, please update your DNS server to support RRD, which dramatically reduces DDoS participation
  • 66. What I’m Really Nervous About • Can’t just not talk about the NSA revelations • Not here to recapitulate Bruce Schneier et al. • I’m nervous about people’s reactions to them.
  • 67. Competing on Political FUD instead of Technical Merit • “Sure, you could go with that competitor, that’s cheaper, faster, nicer, more powerful…but OOGA BOOGA $NATIONSTATE” • Seems ridiculous, until you hear proposals to keep all traffic to and from a country, within that country • “Sure, BGP does say you should use this route, because it’s cheaper/faster/nicer/network neutral/peered…but the law says you have to keep it within our borders where we’re the only provider, because NSA” • Again: The Internet was not the first attempt at large scale Internetworking! It was the first one that worked at large scale, because everything else demanded gatekeepers and rentiers • This is the network made by nerds, not by bizdudes and certainly not by politicians • It seems to work pretty well
  • 68. Not to put too fine a point on it, but… • We didn’t exactly want the Chinese Internet, or the Iranian Internet, before Snowden • I’m hoping we don’t want that now.
  • 69. The General Reaction To NSA Corrupting Crypto Standards (DUAL_EC_DBRG)
  • 70. The Nuanced, Even More Disturbing Reality • There’s a reason we were asking the NSA’s advice to avoid cryptographic vulnerabilities • Most cryptographic functions do not need the NSA’s help to be fatally flawed • That comes for free • It takes an enormous amount of time and effort to find functions that might not be flawed, and the NSA seemed good at telling us when we were wrong • DES • It’d be nice if we had a governmental department focused on defensive operations… • Or maybe a conference…
  • 71. Even Obviously Good Advice Is Being Treated With Deep Suspicion • NIST: Heh, Keccak (SHA-3) is actually too slow. Performance matters. • Zooko Wilcox-O’Hearn, creator of Tahoe-LAFS (probably the best cryptographic distributed file system out there right now): Heh, Keccak (SHA-3) is actually too slow. Performance matters. • Community: NIST IS DOING MORE EVIL
  • 72. …are we about to replace NIST with DJB? (Who keeps releasing fast crypto functions)
  • 73. No, seriously, I’m actually a huge DJB fan • I’ve been advocating Curve25519 for use in a TLS-replacing protocol for years • But, uh, fewer trusted resources in a time of great need is not helpful • “Linux scales. Linus does not scale.”
  • 75. We’re All Kind Of Waiting For The Other Shoe To Drop • Not implementers, everything new keeps using DJBsec • Academics aren’t really allowed to “know things” without some degree of evidence • Science! • We do know that DUAL_EC_DBRG is compromised, but nobody was using that except other feds (sadface) • Pretty much everyone assumes the NIST P curves are compromised • Big complex process to turn a “nothing up your sleeve” number (like pi) into a safe ECC curve • Innocent string used by NIST P curve is c49d360886e704936a6678e1139d26b7819f7e90 • Every shirt has two sleeves • NIST took the time to declare two curves, a P curve and a K curve, almost as if they assumed eventually there would be a problem and it’d be nice if the standard could survive it • The above does not pass scientific epistemology. Nobody cares.
  • 76. The Larger Issue • It’s not like cryptography worked particular well before the NSA revelations • The hard problems in crypto are not in the math, or the implementation. They’re not even in “side channel vulnerabilities”, as Shamir has said. • Key management is the hard part, because that actually touches users. • Cryptography keeps getting seen as Math and Implementation. There is a third aspect • There is a complexity that generally goes unmodeled: Operations
  • 77. My First Law of Operations • Every project must be measured by the number of meetings required to accomplish it • If there is a meeting with someone outside your department, it’s 5x the cost. If outside your company, 25x the cost. • When’s the last time you saw meeting count in a crypto function? • We have to learn to respect usability, and the sacrifices it may demand • Alex Stamos at Yahoo backing PGP for their mail interface is actually a pretty big step – Yahoo knows UX
  • 78. Summary • Don’t let an attacker touch your storage – S^X • Actively gather true entropy and kill the non-CS PRNGs with fire! • Represent entropy in a way other than bit vomit • Browsers become vastly more secure once UaF is prevented • The NSA crypto fallout continues • Yahoo’s PGP news is fantastic • And…just one more thing
  • 79. It’s Apple Related, So I Totally Get To Pull That Line • “Safari now blocks ads from automatically redirecting to the App Store without user interaction. If you still see the previous behavior, or find legitimate redirection to the App Store to be broken in some way, please file a bug.” -- IOS 8 Beta Release Notes from Apple • YES ACTUALLY, THIS DRIVES ME CRAZY • “I know you’re trying to browse this website, but I bet what you really want to do is buy our ****ty game” • **** THOSE GUYS • Apple wants help? Hackers, lets do it • And not for free
  • 80. Third Party Bug Bounty • I’ve become a believer in bug bounties • This is new • External bug quality can sometimes be of poor quality • If you want richer bugs, maybe we should enrich bug hunters • White Ops hereby sponsors an enhanced bug bounty for this particular Apple bug • $5,000 to the first autoredirection bug finder • $2,500 to the second finder • $1K to the next five finders • We offered $250 six weeks ago, sorry, my bad • We believe hackers can help fix things, and we’re putting our money where our mouth is