Dan Kaminsky's Blog

Here’s my slides from Black Hat and Defcon for 2012.  Pile of interesting heresies — should make for interesting discussion.  Here’s what we’ve got:

1) Generic timing attack defense through network interface jitter 2) Revisiting Random Number Generation through clock drift 3) Suppressing injection attacks by altering variable scope and per-character taint 4) Deployable mechanisms for detecting censorship, content alteration, and certificate replacement 5) Stateless TCP w/ payload retrieval

I hate saying “code to be released shortly”, but I want to post the slides and the code’s pretty hairy.  Email me if you want to test anything, particularly if you’d like to try to break this stuff or wrap it up for release.  I’ll also be at Toorcamp, if you want to chat there.

MS12-020, a use-after-free discovered by Luigi Auriemma, is roiling the Information Security community something fierce. That’s somewhat to be expected — this is a genuinely nasty bug. But if there’s one thing that’s not acceptable, it’s the victim shaming.

As people who know me, know well, nothing really gets my hackles up like blaming the victims of the cybersecurity crisis. “Who could possibly be so stupid as to put RDP on the open Internet”, they ask. Well, here’s some actual data:

On 16-Mar-2012, I initiated a scan across approximately 8.3% of the Internet (300M IPs were probed; the scan is ongoing). 415K of ~300M IP addresses showed evidence of speaking the RDP protocol (about twice as many had listeners on 3389/tcp — always be sure to speak a bit of the protocol before citing connectivity!)

Extrapolating from this sample, we can see that there’s approximately five million RDP endpoints on the Internet today.

Now, some subset of these endpoints are patched, and some (very small) subset of these endpoints aren’t actually the Microsoft Terminal Services code at all. But it’s pretty clear that, yes, RDP is actually an enormously deployed service, across most networks in the world (21767 of 57344 /16’s, at 8.3% coverage).

There’s something larger going on, and it’s the relevance of a bug on what can be possibly called the Critical Server Attack Surface. Not all bugs are equally dangerous because not all code is equally deployed. Some flaws are simply more accessible than others, and RDP — as the primary mechanism by which Windows systems are remotely administered — is a lot more accessible than a lot of people were aware of.

So one of the core aspects of my mostly-kidding-but-no-really White Hat Hacker Flowchart is that, if the target is a web page, and it’s not running on your server, you kind of need permission to actively probe for vulnerabilities.

Luckily, there are actually a decent number of sites that provide this permission.

Paypal Facebook 37 Signals Salesforce Microsoft Google Twitter Mozilla UPDATE 1: eBay Adobe UPDATE 2, courtesy of Neal Poole: Reddit (this is particularly awesome) GitHub UPDATE 3: Constant Contact

One could make the argument that you can detect who in the marketplace has a crack security team, by who’s willing and able to commit the resources for an open vulnerability review policy.

Some smaller sites have also jumped on board (mostly absorbing and reiterating Salesforce’s policy — cool!):

Zeggio Simplify, LLC Team Unify Skoodat Relaso Modus CSR CloudNetz UPDATE 2: EMPTrust Apriva

There’s some interesting implications to all of this, but for now lets just get the list out there. Feel free to post more in the comments!

For your consideration. Rather obviously not to be taken as legal advice. Seems to be roughly what’s evolved over the last decade.

So, one of my goals for 2012 has been to write quite a bit more — more code, and more long form analysis. So far, so good.

Doesn’t mean it’s all going to be about security, or even that it’s all going to be all that serious. My whole #Protolol thing worked out pretty amusingly…and so, here’s #nerdflix.

LOL. Some highlights. I can’t even imagine the horrible punnery I’m going to wake up to.

UPDATE 1: Apparently at some point #nerdflix was trending worldwide? It’s certainly taken San Francisco by storm 😉

Update 2: Also, Germany. This is not surprising.

@dakami: Memory Resident Evil @dakami: Driving Miss Daisy Chain (h/t @wadebaker) @dakami: Raiders of the Lost ARP (h/t @quadling) @dakami: –wx—— (h/t @ennor) @AtheistHacker: A Beautiful BIND @RySub Desperate house wifi’s @JGoldOrlando: no SALT @johngineer: Ohm Alone @kickfroggy: I Now Pronounce You PCI Compliant @kickfroggy: There’s Something About Mary’s Code @KrisPaget: Full Metal Packet @l0qii: Beverly Hills Pcap @marshray: Batman Returns-into-libc @mratzlaff: Extremely pwned and Incredibly hosed @otanistudio: ~/alone @otanistudio: HTML5 Gordon @plaverty24: Born on December 31, 1969 @redtwitdown: The Kaminsky Code (cc @dakami) @wadebaker: Gone with the rm Memorable line: “frankly Scarlet, -rf” @Walshman23: Girl, Interrupt-driven @jadedsecurity: Apache Down @chenb0x: The Netbook @manzuik: Whitehats Can’t Code. @afabmedia: Magnum, 3.1415926535897932384626433832795028841971693993751058209 @felipeLvalero: RT @Mackaber: RT @Voulnet: Despicable WindowsME / Lol @0x17h: Gone with the Windows @vogon: @dakami The SHA-1 Redemption @vogon: @dakami 1U Over the Cuckoo’s Nest @ThemsonMester: Oceans 802.11 @enriquereyes: 500 days of evaluation period @a_r_w: The TEMPEST (staring Van Eck) @marshray: Batman Returns-into-libc @marshray: The Bitcoin Miner’s Daughter @gbrunkhorst: The Little Endian in the Cupboard @bm_: RT @_jtmelton: @dakami Lost in Machine Translation @kickfroggy: Paul Blart: Mall CISSP << lol @0x17h: The Deprecated @0x17h: All About Eve Online @afabmedia: So I Married a VAX Murderer @infojeff: Pink Floyd The Wall of Sheep @jdunck: Referer never dies /cc @kevinmarks @kickfroggy: Fast Times at 802.3bg @kickfroggy: How to Train Your User @liambeeton: Firewall Club @longobord: Schindler’s Linked List @mfukar: reinterpret_cast Away @obscuresec: Inglorious Hackers @obscuresec: Toy Story 2++ (should be Toy Story ++2, actually. –Dan) @pageman: The preg_replace ment Killers @rattis: hackers on a plane (come one, someone had to do it). (HOAP, is a real thing). @RySub: Puss in boot sector @someara: @dakami Oh Backup Where Art Thou @theharmonyguy: @dakami XSS in the City, with sequel XSS in the City: alert(2) @ThemsonMester: Oceans 802.11 @Twirrim: 12 Angry Sysadmins @redtwitdown: @Twirrim Saving Private Ryan [XX……………….] 5.7% 16h47m remaining. @0x17h: Twelve Code Monkeys @davehull: APT Pupil @Mackaber: The Angry Birds @spridel11: $ whoami Legend @Pickering: The King’s Speech Recognition Software @BrightApollo: Saving Private Keys @fkorling: Apocalype System.currentTimeMillis() @OhAxi: Teenage Mutant Logo Turtles @andreasudo: Planet of the APIs @Ryallcowling: #00FF00 Lantern @Pickering: The FIOS Connection @andreasudo: Citizen DANE @courtneyBolton: Gone with the Meme @danvesma: Sense and adSensibility @fkorling: In Her Majesty’s SQL Server @ThemsonMester: To Kill an AWKing Bird books to movie… @eikonoklastic: I Know What You Did Last Summer of Code @mfukar: Port Knocked Up @mfukar: Fantastic ARCFOUR @ennor: Top GNU @SecurityHumor: Two Macs One CUPS @Madrox: Harry Potter and the Order Of Operations @hmier: The Manchurian release candidate @rogueclown: Kernighan and Ritchie do America @alanpdx: Death Race Condition 2000 @hmier: A beautiful BIND @Tylos: The Ring 0 @Tylos: ulimitless @0x17h: The Hunchback of Notre DOM @afabmedia: Information Technology Came from Outer Space @Voulnet: BackTrack Mountain @scottymuse: Sopadish @davidgropper: The Girl With The Snapdragon Tattoo (cc: @0x17h) @liambeeton: Independence 0day @johngineer: 2 Fast 2 Fourier @l0qii: elements[4] @Slanderous23: Beauty and the BSD @dakami: The A* Team (h/t @GKokoris) @GKokoris: Jurassic PARC @drb0n3z: James and the Giant Peach Fuzzer @Mackaber: Indiana Jones and the Last Cross-site scripting @artisan002: DIMM and DIMMer @yawnbox: Stateless in Seattle @addelindh: Low Orbit Ion Canonball Run @buckstwits: Sudo The Right Thing @ma1: A Phisher Called from Rwanda @speno: Enemy Minecraft @Rzieher: Sheldon Island @Rzieher: The Men Who Stare at Goatse @damphi: The good, the bad and the code you inherited from your predecessor @damphi: Python on a plane @agnat: 007 – License to … read, write and execute @b4seb4nd: A League of Their Chown @damphi: Deep Packet Inspector Gadget @damphi: RoboCopy @hvcco: Terminate and stay resident evil @Nightwolf42: rm -rf / now @0x17h: How to Train Your Dragon NaturallySpeaking @FnordZilla: The Breakpoint Club @0x17h: Paypal It Forward @bocki_nbg: monty.py @ArchangelAmael: Guess Who’s coming to Audit @aymro: Google Intentions 2.0 @alech: When Alice Met Bob. @stronate: We Need to Talk About Kelvin @ArchangelAmael: The Birth of an Exploit @meznak: vi for vendetta @j4rkiLL: Alien vs. Administrator @ArchangelAmael: The Grapes of $PATH @artisan002: Two and a Half Men in the Middle @angbor3D: Wall-E The Garbagecollector @SeveQ: The Hills have iPhones @ThemsonMester: Zack and Miri Configure, Make, Make Install a Porno @artisan002: Dirty Twisted Pair @swiftruss: Cowboys and Alienware @mechtroid: Crank IPv4: Chev must surf the internet constantly. If he doesn’t find something funny every minute, he goes into cardiac arrest. @eikonoklastic: How Stella Got Her Algorithm Back @Nightwolf42: It’s a wonderful runtime @KlaasJohansen: The Big Kernel Lock Theory #ReplaceFilmTitlesWithKernel @Megaglest: Four web browsers and an Internet @j0sema: LDAP Confidential @FnordZilla: Clock Generator Orange @TeethGrind3r: Crouching Tigerteam, Hidden Night Dragon @_7and6_: “We can’t stop here, this is bash-country!” – Fear and Loathing in /usr/bin #nerdflix @TeethGrind3r: Citizen Cain & Abel @damphi: Dick Tracert @_7and6_: Sex, Lies and Avi-Files @yooogan: Watchdogmen @stevelord: No country for old code @_c_v_e_n: The Seven Layer Itch @0x17h: Annie Hall-effect sensor @apilosov: Da Vixie Code @ArchangelAmael: The Magnificent Seven; layers of the OSI model @xomexx: One overflow the cuckoo’s nest @krizzzn: SELECT American FROM London WHERE wolf = 1 @GoddamnGeek: @dakami EIP Man @0x17h: Malcolm X11 @imlxgr: The Bucket Sort @ArchangelAmael: Who >iFramed< Roger Rabbit @Meihrenfacht: @wlet @BeerweasleDev Lost in compilation ROFL @ex1up: momopeche: Weekend At Bernoulli’s @SubwayDealer: SHA Wars @Voulnet: Batman BEGINS; DECLARES; @Voulnet: netcat in the Hat @fmiffal: grep -c “Monte Cristo” @ira_victor: Monty Python and The Advanced Persistent Grail @HamdanD: Sharepoint must die @mrdaiber: wget -shorty / i See Deadpeople / wag the.doc / ctrl-s ‘lastdance.txt’ @HeshamAboElMagd: Pulp Function @EmadMokhtar: RT @Voulnet: this.IsSparta(); @Ahmad_Hadeed: The Matrix[][] @juphoff: Tim Cook, the Thief, His Wife & Her Lover. @Voulnet: VBScript She Wrote @old_man_mose: Indiana Jones and the Mountain of Dew @Ibrahimism: How I hacked your mother @f70r1: Grave of the Firefoxes @otac0nFluX: the /x41 team @mrdaiber: Alice in WLANd @jochenWolters: Family GUI @saschaleib: 0x20, the final frontier #NotAMovieTitle @MagnusRevang: Enemy of the Statemachine @f70r1: American History XML – an experienced coder wants to prevent his young colleague from taking the same wrong path that he did. @cmhscout: Rear Windows 3.1 @imlxgr: 2038 @yeahyeahyens: dude, where’s my cdr? @deepsec: Game of Inodes. @lnxkid: The XORcist @f70r1: The Old Man and the C @webtonull: Ah, forgot “NoSQL for old men” @mrngm: gcc -Wall -E @mrdaiber: my big fat32 Greek wedding @mrdaiber: revenge of the sithadmin @kinesias: Mozilla (by Roland Emmerich) @bluehavana: Sk!diocracy @Politik2_0: 9 1/2 leaks @SwieSchnubb: The Hurt Logger @brx0: I dream of JNI @mbeison: Murder on the Object Orient Express @robotviki: Das BOOTP @0xerror: How I Met Your Motherboard [redacted]: Break Point @Bashar3A: She’s Out Of My Scope @JarrarM: AJAX Shrugged @brx0: Spongebob O(N^2)Pants

There’s been a lot of talk about this supposed vulnerability in RSA, independently discovered by Arjen Lenstra and James P. Hughes et al, and Nadia Heninger et al. I wrote about the bug a few days ago, but that was before Heninger posted her data. Lets talk about what’s one of the more interesting, if misunderstood, bugs in quite some time.

SUMMARY INTRODUCTION THE ATTACK IT’S NOT ABOUT RON AND WHIT WHO MATTERS FAILURE TO ENROLL THE ACTUAL THREAT ACTIONABLE INTELLIGENCE CONCLUSION

SUMMARY

• The “weak RSA moduli” bug is almost (and possibly) exclusively found within certificates that were already insecure (i.e. expired, or not signed by a valid CA).
• This attack almost certainly affects not a single production website.
• The attack utilizes a property of RSA whereby if half the private key material is shared between two public keys, the private key is leaked. Researchers scaled this method to cross-compare every RSA key on the Internet against every other RSA key on the Internet.
• The flaw has nothing to do with RSA or “multi-secret” systems. The exact same broken random number generator would play just as much havoc, if not more, with “single-secret” algorithms such as ECDSA.
• DSA, unlike RSA, leaks the private key with every signature under conditions of faulty entropy. That is arguably worse than RSA which leaks its private key only during generation, only if a similar device emits the same key, and only if the attacker finds both devices’ keys.
• The first major finding is that most devices offer no crypto at all, and even when they do, the crypto is easily man-in-the-middled due to a presumption that nobody cares whether the right public key is in use.
• Cost and deployment difficulty drive the non-deployment of cryptographic keys even while almost all systems acquire enough configuration for basic connectivity.
• DNSSEC will dramatically reduce this cost, but can do nothing if devices themselves are generating poor key material and expecting DNSSEC to publish it.
• The second major finding is that it is very likely that these findings are only the low hanging fruit of easily discoverable bad random number generation flaws in devices. It is specifically unlikely that only a third of one particular product had bad keys, and the rest managed to call quality entropy.
• This is a particularly nice attack in that no knowledge of the underlying hardware or software architecture is required to extract the lost key material.
• Recommendations:
  1. Don’t panic about websites. This has very little to absolutely nothing to do with them.
  2. When possible and justifiable, generate private key material outside your embedded devices, and push the keys into them. Have their surrouding certificates signed, if feasible.
  3. Audit smartcard keys.
  4. Stop buying or building CPUs without hardware random number generators.
  5. Revisit truerand, an entropy source that only requires two desynchronized clocks, possibly integrating it into OpenSSL and libc.
  6. When doing global sweeps of the net, be sure to validate that a specific population is affected by your attack before including it in the vulnerability set.
  7. Start seriously looking into DNSSEC. You are deploying a tremendous number of systems that nobody can authenticate.

INTRODUCTION If there’s one thing to take away from this entire post, it’s the following line from Nadia Heninger’s writeup:

Only one of the factorable SSL keys was signed by a trusted certificate authority and it has already expired.

What this means, in a nutshell, is that there was never any security to be lost from crackable RSA keys; due to failures in key management, almost certainly all of the affected keys were vulnerable to being silently “swapped out” by a Man-In-The-Middle attacker. It isn’t merely the fact that all the headlines proclaiming “0.2% of websites using RSA are insecure” are straight up false, because the flaws are concentrated on devices. It’s also the case that the devices themselves were already using RSA insecurely to begin with, merely by being deployed outside a key management system.

If there’s a second thing to take away, it’s that this is important research with real actions that should be taken by the security community in response. There’s no question this research is pointing to things that are very wrong with the systems we depend on. Do not make the mistake of discounting this work as merely academic. We have a problem with random numbers, that is even larger than Lenstra and Hughes and Heninger are finding with their particular mechanism.

(UPDATE: I’ve written quite a bit more about this subject, in the wake of Nadia Heninger posting some fantastic data on the subject.)

Recently, Arjen Lenstra and James Hughes et al released some excellent survey work in their “Ron Was Wrong, Whit Was Right” paper regarding the quality of keys exposed on the global Internet. Rather than just assume proper generation of public key material, this survey looked at 11.7 million public keys in as much depth as possible.

The conclusion they reached was that RSA, because it has two secrets (the two primes, p and q), is “significantly riskier” than systems using “single-secrets” like (EC)DSA or ElGamel.

What?

Let me be clear. This is a mostly great paper, with lots of solid data on the state of key material on the Internet. We’re an industry that really operates without data, and with this work, we see (for example) that there’s not an obvious Debian-class time bomb floating around out there.

But there’s just no way we get from this survey work, to the thesis that surrounds it.

FINDING: WPS was designed to be secure against a malicious access point. It isn’t: A malicious AP recovers the entire PIN after only two protocol exchanges. This server to client attack is substantially easier than the client to server attack, with the important caveat that the latter does not require a client to be “lured”.

SUMMARY: Stefan Viehböck’s WPS vuln was one of the bigger flaws found in all of 2011, and should be understood as an attempt to improve the usability of a security technology in the face of severe and ongoing deficiencies in our ability to manage key management (something we’re fixing with DNSSEC). WPS seems to have started as a mechanism to integrate UI-less consumer electronics into the Wi-Fi fold; it grew to be a primary mechanism for PCs to link up. WPS attempted to use an online “proof of possession” process to mutually authenticate and securely configure clients for APs, including the provisioning of WEP/WPA/WPA2 secrets. In what appears to have been a mechanism to prevent malicious “evil twin” APs from extracting PINs from rerouted clients, the already small PIN was split in half. Stefan noted that this made brute force efforts much easier, as the first half could be guessed independently of the second half. While rate limiting at the AP server is an obvious defense, it turns out to be the only defense, as both not continuing the protocol, and providing a fake message, are trivially detectable signs that the half-PIN was guessed incorrectly. Meanwhile, providing the legitimate response even in the face of an incorrect PIN guess actually leaks enough data for the attacker to brute force the PIN. I further note that, even for the purposes of mutual authentication, the split-PIN is problematic. Servers can immediately offline brute force the first half of the PIN from the M4 message, and after resetting the protocol, they can generate the appropriate messages to allow them to offline brute the second half of the PIN. To conclude, I discuss the vagaries of just how much needs to be patched, and thus how long we need to wait, before this vulnerability can actually be addressed server side. Finally, I note that we can directly trace the existence of this vulnerability to the unclear patent state of Secure Remote Passwords (SRP), which really is the canonical way to do Password Authenticated Key Exchange (PAKE).

Note: I really should be writing about DNSSEC right now. What’s interesting is, in a very weird way, I actually am.

SECTIONS: Introduction On Usability Attacks, Online and Off A Simple Plan Rate Limiting: The Only Option? It Gets (Unexpectedly) Worse On Patching Right Tech, Wrong Law

INTRODUCTION

Security is not usually a field with good news. Generally, all our discussions center around the latest compromise, the newest vulnerabilities, or even the old bugs that stubbornly refuse to disappear despite our “best practices”. I’m somewhat strange, in that I’m the ornery optimist that’s been convinced we can, must, and will (three different things) fix this broken and critical system we call the Internet.

Just a small post, because Rob Graham asked.

The question is: What is the differential complexity increase offered by salting hashes in a password database?

The short answer, in bits, is: The square root base 2 log of the number of accounts the attacker is interested in cracking.

Rob wanted me to explain this in a bit more depth, and so I’m happy to. In theory, the basic properties of a cryptographic hash is that it’s infeasible to invert the hash back to the bitstream that forged it. This is used in password stores by taking the plaintext password provided by the user, hashing it, and comparing the hash from the database to the hash of the user provided plaintext. If they match, the user is authenticated. Even if the database is lost, the attack won’t be able to invert the database back to the passwords, and users are protected.

There are, of course, two attacks against this model. The first, surprisingly ignored, is that the plaintext password still passes through the web app front end before it is hash-compared against the value in the database. An attacker with sufficient access to dump the database often has sufficient access to get code running on either the server or client front ends (and you thought cross-site scripting was uninteresting!). Granted, this type of attack reduces exposed users from “everyone” to “everyone who logs in while the site is compromised”. That’d probably be more of an improvement, if we believed attackers were only interested in instantaneous smash-and-grabs and were unable to, or afraid of persisting their threats for long periods of time.

Heh.

TL;DR: New toy.

$ phidelius Phidelius 1.0: Entropy Spoofing Engine Author: Dan Kaminsky / Description: This code replaces most sources of an application's entropy with a psuedorandom stream seeded from a password, a file, or a generated sequence. This causes most cryptographic key generators (ssh-keygen, openssl, etc) to emit apparently strong keys with a presumably memorable backdoor. For many protocols this creates PAKE (Password Authenticated Key Exchange) semantics without the server updating any code or even being aware of the password stored client side. However, the cost of blinding the server is increased exposure to offline brute force attacks by a MITM, a risk only partially mitigatable by time/memory hard crack resistance. Example: phidelius -p "ax-op-nm-qw-yi" -e "ssh-keygen -f id_dsa"

Passwords are a problem. They’re constantly being lost, forgotten, and stolen. Something like 50% of compromises are associated with their loss. Somewhere along the way, websites started thinking l33tsp33k was a security technology to be enforced upon users.

So what we’re about to talk about in this post — and, in fact, what’s in the code I’m about to finally drop — is by no means a good idea. It may perhaps be an interesting idea, however.

So! First discussed in my Black Ops of 2011 talk, I’m finally releasing Phidelius 1.0. Phidelius allows a client armed with nothing but a password to generate predictable RSA/DSA/ECC keypairs that can then be used, unmodified, against real world applications such as SSH, SSL, IPsec, PGP, and even BitCoin (though I haven’t quite figured out that particular invocation yet — it’s pretty cool, you could send money to the bearer of a photograph).

Now, why would you do this? There’s been a longstanding question as to how can a server support passwords, without necessarily learning those passwords. The standard exhortations against storing unhashed passwords mean nothing against this problem; even if the server is storing hashed values, it’s still receiving them in plain text. There are hash-based challenge response protocols (“please give me the password hashed with this random value”) but they require the server to then store the password (or a password equivalent) so they can recognize valid responses.

There’s been a third class of solutions, belonging to the PAKE (Password Authenticated Key Exchange) family. These solutions generally come down to “password authenticated Diffie-Helman”. For various reasons, not least of which have been patents, these approaches haven’t gotten far. Phidelius basically “solves” PAKE, by totally cheating. Rather than authenticating an otherwise random exchange, the keypair itself is nothing but an encoding of the password. The server doesn’t even have to know. (If you are a dev, your ears just perked up. Solutions that require only one side to patch are infinitely easier to deploy.) How can this work?