Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×
Nächste SlideShare
Dmk blackops2006
Dmk blackops2006
Wird geladen in …3

Hier ansehen

1 von 88 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Black ops 2012 (20)


Aktuellste (20)


Black ops 2012

  1. 1. Black Ops Dan Kaminsky Chief Scientist DKH dan@doxpara.com (2012)
  2. 2. Another Year, Another Talk  Good News and Bad News  Good News: We‟re going to fix this thing.  We have no choice. The global economy is based on Information Technology being trustworthy.  An economy where you have to be big enough to field a “cyber army” in order to participate, is a broken economy indeed  It‟s not like the big guys are doing a great job defensively  Bad News: We‟re not going to fix it according to dogma.  How‟s the status quo working out for us?  There are many alternatives to dogma that are even worse  How do we find those that are better?
  3. 3. A Riddle  What is the fundamental difference between attack and defense?
  4. 4. Answer  When an attack doesn’t work, you can tell.  Offense has an inherent quality filter  “Put up or shut up”  Doesn‟t mean there aren‟t bugs in offensive disclosure  The “Oracle Critical” is just an unencrypted transport – if it‟s a bug, then Wireshark is dropping hundreds of 0day  Press Will Report Anything  But it‟s not the same
  5. 5. The Reality Of Defense  Too much dogma  Not enough science  “You have to defend against every bug” -> “That‟s impossible” -> “You don‟t have to show you‟ve defended against anything”  Critiques of defenses aren‟t much better – nobody is measuring or critiquing effectiveness  So this is a talk about skepticism and the processes of finding effective defenses to the real and legitimate threats we cannot ignore  You shouldn’t agree with everything I‟m going to present  My goal is to show you some new ideas, and give you a framework to consider them as worthwhile or not  This is the only way we‟re going to get defense to work  Lest you think there‟s nothing concrete here…
  6. 6. The Fundamental Test  Take 2000 systems with a defense.  Take 2000 systems without.  Come back in six months, and manually audit all 4000 systems.  Is there or is there not a statistically significant difference in the infection rate?  Even if we don‟t do the above, let us at least respect a gold standard when we see one!  The time may come when we spend as much money on security research as we do on medical research.  Medicine took hundreds of years to become scientific, and they had dead bodies to motivate them  We don‟t have dead bodies, or hundreds of years.  We still need to fix these problems.  Some vendors out there care along these lines. Reward them!
  7. 7. The Three Heads Of The Security Hydra  1) The inability to authenticate  2) The inability to write secure code  3) The inability to bust the bad guys  What we‟re not talking about today  Authentication – DNSSEC – no time, ask me in private (or wait a few months)  Busting the bad guys  Remarkable lack of consensus regarding which bad guys are most important  I tend to worry about the Aurora attack, which involved espionage against (lets face it) the entire Fortune 500, and against those raiding SMB payrolls, because that calls into question the very viability of SMB  Others have different priorities  What we are talking about  The inability to write secure code
  8. 8. An immediate clarification  It‟s not that it‟s impossible to write secure code  It‟s not impossible to deploy X.509 PKI  It‟s not impossible to bust the bad guys  It’s just plainly and utterly improbable  At least in most organizations  “Possible is not enough. Probable or bust.”
  9. 9. What are we looking at today?  How do we address timing attacks?  How do we generate random numbers?  How do we suppress SQL Injection?  How do we detect network manipulation?  How do we scan the Internet?  These are all things that are possible today. How do we make them more deployable, less expensive…more probable?
  10. 10. Timing Attacks  Many systems are modeled in terms of just what data they send  Not in terms of when they send it  Sometimes data leaks – security sensitive data  Possible to distinguish 15-100 microseconds of latency over Internet, and 100 nanoseconds of latency over LAN (1000 samples)  Opportunities and limits of remote timing attacks (Scott A Crosby , Rudolf H. Riedi , Dan S. Wallach)  Possible to exploit string comparison functions in widespread scripting languages, thus breaking HMAC compare (OpenID/OAuth)  Exploiting timing attacks in widespread systems Nate Lawson and Taylor Nelson @ Black Hat 2010
  11. 11. The Proposed Fix  Any time values need to compared in a security critical context, compare them in constant time (so that there‟s no correlation between what‟s compared, and how long it takes)  public static boolean isEqual(byte[] a, byte[] b) { if (a.length != b.length) { return false; } int result = 0; for (int i = 0; i < a.length; i++) { result |= a[i] ^ b[i] } return result == 0; }  Looks good, right?
  12. 12. The Problem  You have to remember to do this everywhere there’s a security critical comparison  You don‟t get to do it all the time, because the performance impact is too high  You thus must actually identify all the security critical comparisons  It‟s possible. But it‟s not probable.
  13. 13. A Solution?  I seem to note that distinguishing against Internet noise yields less accuracy (15,000-100,000ns) than LAN noise (100ns)  That‟s three to four orders of magnitude!  And Internet noise is not actually random  What if we actually did have a random delay?  tc qdisc change dev eth0 root netem delay 3ms 1ms  “For all packets emitted from the first Ethernet interface, add a random amount of lag between 1,000,000ns and 3,000,000ns”  “Boltzmann Filter”  At minimum, the LAN should be as secure as the Internet. Maybe Internet attackers also are impacted.  This is a lot easier to deploy. That really matters.  But does it work?
  14. 14. What Could Go Wrong?  “All timing noise can be averaged out eventually, so a global random delay can‟t work”  Pretty much all password comparisons are done with non-constant time compares, so I guess all passwords are vulnerable?  Here‟s some SSH 0day sys_auth_passwd(Authctxt *authctxt, const char *password){… /* Encrypt the candidate password using the proper salt. */ encrypted_password = xcrypt(password, (pw_password[0] && pw_password[1]) ? pw_password : "xx"); return (strcmp(encrypted_password, pw_password) == 0);  Strcmp is not constant time. So, you just offline brute force for passwords that have certain characters and see how far you get.  It is highly unlikely that the above “attack” actually works  Nanosecond differentials are too small to recover  Maybe not locally…hmmm…
  15. 15. What We Really Need To Know  How much timing noise, of what nature, will permanently obscure how much timing signal beyond the point of infeasible return?  Somewhere between “1 nanosecond” and “1 day” there is an amount of noise that will indefinitely obscure an n nanosecond differential  There‟s likely to be an equation here  “CSI Enhance” has its limits  There is a limit to how much lag we can ask for, from the performance guys  It is higher for some requests than for others  We might require more lag than perf is willing to give (at least in general)  Need to discover these numbers
  16. 16. What could actually go wrong  The distribution of lag from the interface may be easy to filter  Quantized into 1ms chunks?  Gaussian when it should be uniform, or uniform when it should be Gaussian  Could be filterable thanks to TCP timestamps (which have ~10ms accuracy, but also have sharp edges)  All of the above can be fixed, the question is if they need to be  The perfect (constant time comparisons) is the enemy of the good (interface-wide jitter)  Jitter does not need to apply to all packets; could be a TCP setsockopt or whatnot  Could also be applied at the end of a php script
  17. 17. Another Day, Another Time  “RSA is broken!”  No, not the thing with the smartcards that would (maybe, depending on vendor) leak their private key  No, not the thing with the SecureID seeds that were stolen  The thing with certificates with easily breakable RSA keys  Something like 1 in 200 RSA keys on the Internet failed!  Hughes and Lenstra had first announce, Nadia Heninger had parallel research  At the time, the break was blamed on RSA itself  Two primes in RSA (p and q)  If either is repeated (p and q1, p and q2), then all are easy to derive  Euclid‟s Greatest Common Denominator  “RSA is bad!”
  18. 18. Reality  Bad random number generators create trapdoor functions in all cryptosystems  Rather than breaking the crypto, you guess the key  Basic concept of 2011‟s Phidelius (expanded a password into a pseudorandom stream, which was then used to feed a key generator for RSA/DSA/ECC).  “Bad RNG isn‟t a bug, it‟s a feature!”  They thought they‟d shown RSA was bad  They actually showed that RNG‟s are still broken  Debian‟s bug wasn‟t just Debian‟s  Weren‟t operating systems supposed to fix this?
  19. 19. Theory  “Collecting and providing entropy is hard; let the operating system do it for you”  /dev/random for good bits, /dev/urandom for best effort bits  If /dev/random runs out of bits, block until more are found  Sources for entropy  Hardware RNG  Keyboard  Mouse  Disk Rotation (as impacted by air)  Problem: Lots of environments don‟t have any of that
  20. 20. Actual Environments  Desktops  Humans w/ keyboards and mice  Often disks  Servers  Sometimes have disks  VMs  Embedded devices
  21. 21. The Reality of Hardware RNG  It‟s just not there.  Yes, I know Ivy Bridge is coming out with a Hardware RNG. In 2012.  That‟s top of the line gear now.  Yes, I know some TPM‟s are reported to have Hardware RNGs.  For some reason, people treat TPM hardware as unstable radioactive gunk  It‟s also rarely in embedded kit
  22. 22. What‟s Happening: An Analogy  Proteins causes cancer  http://ukpmc.ac.uk/abstract/MED/3007842/reload=0;jsessionid =3X3Cs6G7VbyRT1xEPcUX.4  Carbohydrates cause cancer  http://www.smh.com.au/lifestyle/diet-and-fitness/high- carbohydrate-diet-tied-to-cancer-20110616-1g4o9.html  Fats cause cancer  http://www.telegraph.co.uk/health/healthnews/5650141/High- fat-diet-can-increase-risk-of-deadly-cancer.html  Alcohol causes cancer  http://pubs.niaaa.nih.gov/publications/arh25-4/263-270.htm  So you don‟t consume proteins, carbohydrates, fats, or booze.  You starve to death.
  23. 23. What Actually Happens  How do I know? I actually asked some devs.  1) They have some code that depends on /dev/random  2) On initialization of their embedded device, the code tries to generate a key.  3) There‟s no human at the keyboard, no hand at the mouse, no disk to spin, and no hardware RNG. /dev/random blocks. The device is a brick.  Quite literally, starving for entropy  4) At best, they switch to /dev/urandom. At worst they switch to rand() and then they ship.  /dev/urandom is underseeded, though, and is still broken
  24. 24. A comparison  What perfectionists think will happen:  It‟s broken! Sure they‟ll demand hardware RNG!  What developers actually do:  Security failed us again. Lets ship something that works.  Perfectionism caused (at least) 1 out of 200 RSA keys on the Net to be easily broken  It‟s almost certainly worse than that  Those are just the keys we can easily detect  We can do better.
  25. 25. TrueRand: An Old Hack [0]  Why do we like measuring keyboard and mice?  Humans and computers are not synchronized  Humans do not operate on nanosecond clocks like computers do  Human is slow clock, CPU is fast clock  Any system with two clocks, has a Hardware Random Number Generator  Even if the error is one part per million, that‟s a bit per second per megahertz  The error is generally much larger than a part per million, just from thermal noise  (Not just thermal noise)
  26. 26. TrueRand: An Old Hack [1]  What TrueRand (from Matt Blaze and D.P. Mitchell, in 1996) does  Run the CPU in a tight loop (count++);  Every 16ms, fire an interrupt  On interrupt, shuffle the count variable, and integrate it into a buffer  The entropy comes in here – timer is slow clock, CPU is fast clock  After 11 shuffles, return the buffer as an integer  Hash two buffers together using sha1, return only the first byte  It ain‟t bad. But it‟s disowned.  That‟s too bad, because it would have prevented (at least) 1/200 keys from being broken.
  27. 27. Why is it disowned?  (Literally – Matt Blaze was vaguely horrified that I‟m revisiting this code)  Perfectionism  “We can‟t model its behavior. We don‟t know how good or bad it is, so we shouldn‟t do it at all.”  This attitude has actually led to a reduction in available entropy in the Linux kernel  Used to look at interrupt counts from various devices  Now they aren‟t used, because they “might be polluted”
  28. 28. DakaRand 1.0 [0]  An update to the old model  Multiple generators  Sleepers: Measure usleep with  CLOCK_MONOTONIC  CLOCK_REALTIME  RDTSC (on X86 platforms)  CPU counter – there are equivalents for ARM, MIPS  Incrementer: See how many times we can increment an integer within a certain time period (100% CPU)
  29. 29. DakaRand 1.0 [1]  RTC: Measure interrupts from the realtime clock using CLOCK_MONOTONIC (dedicated IRQ!)  128hz  8192hz  Threads: Measure the status of an integer modulated by a runaway thread (100% CPU)  Anyone who thinks computers are completely deterministic creations has never written threaded code ;)  Two Threads, One Int (one adds, one subtracts, main polls)  Two Threads, Two ints (both add, main compares)  One Thread, One Int (one adds, main polls)  Possible addition: Noisier functions than add
  30. 30. DakaRand Flow  Short version  Push all bits into a SHA-256 Hash  Don‟t undercount entropy  Only count them as entropy when they pass Von Neumann‟s debiasing check  Count 1‟s to decide whether 0 or 1  Throw away 00 and 11, count only 01 and 10  Actually insert a 0 or a 1 when you count a bit  Don‟t overcount entropy  Scrypt (time/memory hard function) the resulting SHA- 256 value  Make it miserable to guess entropy  Use the output of Scrypt as the input to AES-256-CTR, emit the resulting stream
  31. 31. Attacking DakaRand  The game: Find a platform (Desktop/Server/VM/Embed) or an OS under which DakaRand provides poor entropy in one of its modes  Userspace/Hypervisor Scheduling  We‟re only called some number of times per second  These times per second may be at predictable intervals  If sufficiently predictable, they‟ll bias the output  Will they simultaneously and identically bias both clocked entities?  Autoclocking  If you time something against itself, you‟re going to have a bad time  Clocks are highly correlated to themselves  RTC and CLOCK_MONOTONIC could be the same underlying timer in a VM  VMs, more than anything else, should be exposing a random device (even if the random device itself uses clock differentials)  Still, this code seems to still work on VMs
  32. 32. The VM Cloning Issue  /dev/random keeps bits around for a long time  When you clone an image, you end up with those bits being static for a long time  Meaning you keep generating the same entropy for a long time   DakaRand attempted guarantee: Each read is atomic  The results of the read may be used across multiple images  But two separate calls at two separate times MUST yield two uncorrelated streams  Can‟t do anything after the read is fully completed  During the read (which does last a second, due to scrypt) is already after  I actually don‟t think you can do better than this, though I was considering XORing the keystream with /dev/urandom anyway
  33. 33. Is The Underlying Use Of Crypto Safe?  Modified Von Neumann  We absorb a tremendous amount of data into our hash structure that has obvious patterns  If you have 100GB of 0‟s and 128 bits of actual randomness, output of hash has 128 bits of randomness  We do explicitly include the 0 and 1  Stream Function vs. Raw Output  Lots of raw output from a function tends to leak external state  So lets not leak external state.  Cryptographic Stream Function  RNG‟s tend to have their own family of functions that are distinctly not cryptographically validated  Mersenne Twister, not AES-256 in Counter Mode  Is it in fact the case that strong (not RC4) cryptographic functions encompass all properties of RNGs?  Well, what does dieharder say?
  34. 34. DieHarder CipherSuite Test  About 16,000 CPU hours of DieHarder Entropy Tests was run across 21 ciphers, with inputs of either 16MB of zero or (the same) 16MB of /dev/urandom output  About 24,000 different tests per cipher/content class  Thanks, Jamie Schwettman, who did all the work to make this sweep happen  No obvious statistical leanings to the data  Machine learning people are taking a look  Thanks, Prior Knowledge, Aleks Jakulin!  No conclusive findings yet  Releasing this data too
  35. 35. Neat tool – want it? csql: run SQL against CSV files  $ cat pass2.csv | head -n 20000 | ./csql - "SELECT cipher, content, test, subtest, count(pv), avg(pv) from c group by cipher, content, test, subtest;" | head -n 10  aes-128-cbc,urandom,dab_bytedistrib,0,10,0.0  aes-128-cbc,urandom,dab_dct,256,10,0.47393035  aes-128-cbc,urandom,diehard_2dsphere,2,10,0.627572674  aes-128-cbc,urandom,diehard_3dsphere,3,10,0.664239991  aes-128-cbc,urandom,diehard_birthdays,0,10,0.50850473  aes-128-cbc,urandom,diehard_bitstream,0,10,0.017056331  aes-128-cbc,urandom,diehard_count_1s_byt,0,10,0.441374983  aes-128-cbc,urandom,diehard_count_1s_str,0,10,0.538731369  aes-128-cbc,urandom,diehard_craps,0,20,0.0394997795  aes-128-cbc,urandom,diehard_dna,0,10,0.396250338
  36. 36. Kernel Recommendations  /dev/random MUST not block.  Make an IOCTL if you must  Return data slowly if you like  CryptGenRandom on Windows does not appear to block  1 out of 200 RDP keys are not likely to be corrupt  Don‟t be so shy about interrupt sources  Care less about interrupt counts than interrupt timings  ftrace exposes microsecond timings, which might not be fine grained enough  Use nanosecond arrival times, as much as possible, from devices on foreign busses. The slower the foreign device is, the better.  You want to be measuring slow clocks against fast clocks  By definition, the kernel is interrupted at finer grain than userspace.  Obviously you don‟t have to include every last interrupt – it takes time to check the time.  Maybe consider this Modified Von Neumann construction
  37. 37. From The Bottom To The Top  Our biggest problems in security do not revolve around Random Number Generation  They revolve around languages  Language Theoretic Security: The hypothesis that security vulnerabilities are the consequence of the languages code is written in  Coined by Len Sassaman and Meredith Patterson  “Sapir-Whorf is true for code”  Corollary: If language got us into this mess, language can get us out  More important corollary: Languages are spoken or written by humans. Ignore their needs at your peril.
  38. 38. The Shift  One way to look at language theoretic security is through the lens of computability theory  Different classes of code have different amounts of “power”, and communication should be limited to the least amount of power necessary  Attacks expands power from Declarative to through Regular Expression through “Turing Complete”  This is indeed a valid lens  Another lens
  39. 39. Diagramming Sentences: IT WAS ACTUALLY USEFUL
  40. 40. Injection Vulnerabilities: When Trees Disagree  Parsers, almost by definition, turn streams of bytes into trees  Injection Vulnerabilities exist when a sending language and a receiving language (which may or may not be the same) disagree on the nature of the tree sent  An extreme case of this is when bytes flow out into surrounding memory  But SQL Injection, LDAP Injection, XSS, etc are all just situations where (generally) the sender thought it sent the user‟s data, but the receiver thought it received a peer‟s code  A purely declarative language can still (easily) be injected into, and complexity can remain declarative and still yield damage. The attack is not in the increase of complexity, but in the transition of content from one identity/context to another through parse tree differentials.  So what?
  41. 41. We have to stop injection vulnerabilities  They‟re killing us  They‟re not l33t  They‟re totally effective  They‟re the vast majority of vulnerabilities ever written and discovered  We haven‟t actually fixed them  If we did fix them, they wouldn‟t still be costing billions of dollars  [Yes, we‟re going to revisit Interpolique…it‟s OK, we‟re going to bash it too]
  42. 42. What is the importance of another theoretical model?  It declares the rules of the game.  1) We want to synchronize parse trees.  2) We want developers to actually use our method.  A language unspoken has a term: A dead language  It explains what is surprisingly not understood  Why did XML become popular?  Instead of spending months figuring out just how to say hello, they have their code, you have your code, and it‟s self describing strings in each direction. No fiddly “the eighth bit on the fourth byte changes everything”  Why did JSON become popular?  XML invented its own modes of being fiddly
  43. 43. The Hard Truth  Developers are in charge.  Not architects (they love ASN.1 and XML and WS- ZOMG)  Not academics (they love Haskell)  Not management (they love money)  Money is made by performance, reliability, maintainability, features, rapid development  Money is later lost by security, maybe  So, not us.  What is the #1 thing developers like?  Code working
  44. 44. Thus, the biggest explanation  Why is PHP so popular?  If you don‟t think it is, see here:  What is PHP incredibly good at?  Copy and paste code…and it works  We understand that CPAN makes PERL  We don‟t understand that PHP sample code makes PHP  Java Alternative: Look how much code my IDE can write for me!  Copy and paste with a suit on
  45. 45. The Language Success Metric  What are the odds, if I try this, that it will work?  Not, when it fails, it fails fast!  Surprisingly, nobody tracks this metric  (Except maybe Processing, which is incredible)  That‟s why all the successful languages tend to be the brainstorms of one guy  Art is science before we know what we‟re doing   PHP beats your favorite language  If we want to fix security, here is a good place to work
  46. 46. What‟s Wrong With ORMs?  Object Relational Models  Problems with SQL Injection? Don‟t use SQL! Instead, the database just looks like your favorite language‟s native objects.  Great, right up until the moment you need to make a query.
  47. 47. Look at this. It matters.  +[,+[-[>+>+<<-]>[<+>-]+>>++++++++[<-------->-]<-[< [- ]>>>+[<+<+>>-] <[>+<-]<[<++>>>+[<+<->>-]<[>+<- ]]>[<]<]>>[-]<<<[[- ]<[>>+>+<<<-]>> [<<+>>- ]>>++++++++[<-------->-]<->>++++[<++++ ++++>-]<- <[>>>+<<[ >+>[-]<<-]>[<+>- ]>[<<<<<+>>>>++++[<++++++++>-]>-]< <-<-]>[<<<<[- ]>>>>[<<<<->>>>-]]<<++++[<<++++++++>>-]<<- [>>+>+<<<-]>>[<<+ >>-]+>>+++++[<----->-]<-[<[- ]>>>+[<+<->>-]<[>+ <-]<[<++>>>+[<+<+ >>-]<[>+<- ]]>[<]<]>>[-]<<<[[-]<<[>>+>+<<<-]> >[<<+>>-]+>------------ [<[-]>>>+[<+<->>-]<[>+<-]<[<++>>>+[<+<+>>-]< [>+<- ]]>[<]<]>>[-]< <<<<------------->>[[-]+++++[<<+++++>>- ]<<+>> ]<[>++++[<<+++++++ +>>-]<-]>]<[- ]++++++++[<++++++++>-]<+>]<.[ -]+>>+<]>[[-]<]<]
  48. 48. BrainF*ck‟s Rejoinder  There are more things in this world broken by punctuation than just BrainF*ck.  Compare.  $result = from('$name')->in($names) ->where('$name => strlen($name) < 5') ->select('$name');  32 characters of punctuation, deeply interspersed  $result = query(“SELECT $name FROM $names WHERE length($name)<5”);  12 characters of punctuation (with large gaps)  Which would you rather write?  There‟s a reason SQL persists after all these years. It‟s really expressive and surprisingly without noise.  Put another way: It‟s a language that‟s shockingly good for structured queries.  Turns out this matters.
  49. 49. The Classics  Escape?  mysql_real_escape_string – really? 25 characters?  Bigger problems: Fails open – code still works if it‟s just missing  “Greppability” is huge – you can‟t grep for a missing escape!  Escapes are a blacklist. When‟s the last time you saw a blacklist work properly?  Parameterization  First you declare a template for a query  Then you link individual variables to the template, on a positional basis  “This is the first argument”  “This is the second argument”  MAYBE, if you‟re lucky, your language supports argument aliases.  “The argument marked with :name should get the value of the variable „name‟”  One line of code becomes many  Resources need to be synced
  50. 50. Reality  Nobody has ever written a parameterized query without a gun to their head. We know, we hold the gun.  Even secure code, when audited, tends to be “safe things written quickly” and “we realized this was unsafe so we parameterized it”  That you have to threaten people with getting fired, is itself a data point.  For some strange reason, databases don‟t seem to provide mechanisms to disable unparameterized queries entirely  More interestingly, it‟s a crapshoot whether you get to parameterize at all  Just try to parameterize “SELECT”.  SQL, for all its elegance, builds a remarkably complex parse tree out of a mostly unpunctuated string  Some nodes in the parse tree can be filled by functions, some can be parameterized, etc.  It‟s a decent RNG to know what you can get away with 
  51. 51. Interpolique [0]  Released in 2010 at HOPE  Concept for eliminating injection attacks while retaining “dangerous” (but developer preferred) coding styles  Both SQLi and XSS  Basic idea  “SELECT * FROM foo where x=$x and y=$y”  Humans can pretty easily see the separation between code and data. Data begins with $. Code does not.  The language throws that data away and just smashes strings together.  Does it have to?
  52. 52. Interpolique [1]  The original approach for Interpolique  First, use an alternate syntax to identify the desired variables  “SELECT * FROM foo where x=^^x and y=^^y”  Then, create a function that returns the code we‟d have liked the developer to write.  $stmt = $conn->prepare(“SELECT * FROM foo where x=? and y=?”); $stmt->bind_param(“ss”, $x, $y); $stmt->execute();  Finally, evaluate the generated code  eval(b(“SELECT * FROM foo where x=^^x and y=^^y”);  Eval is, surprisingly, the only way to retrieve the values of $x and $y from inside the function b().
  53. 53. What‟s Wrong With Interpolique?  What if the dev writes:  eval(b(“SELECT * FROM foo where x=$x and y=$y”);  If $x and $y are attacker controlled, he‟s not far from an eval that will run code in PHP‟s context!  The b() function is in a position to defend the code that ultimately enters eval, but now you‟re entirely dependent on b() knowing what PHP will do given arbitrary bytes.  GOOD LUCK WITH THAT  Highly greppable error case, but it‟s pretty scary
  54. 54. Building A Safe Interpolique  Eval only exists so that variables from the calling scope can be dereferenced  One approach is to implement create_selfscoped_function()  Returns a function that always runs in the scope of its parent  Could implement “proxies” so it can only read variables, and can‟t rewrite  $rows=$mysql_safequery(“select * from foo where x=^^x and y=^^y”);  Requires a patch to PHP -- Daniel Zulla is working on this!
  55. 55. Code Rewriting?  If we know what we would have liked developers to have written, why don‟t we just transform code once?  Never really been a fan of this  Have you ever audited autogenerated code?   What do you do when the code looks like: $z = “SELECT * from foo where x=$x and y=$y;”; $rows = mysql_query($z);  Static analysis can of course find such situations (thus knowing $x came in from a HTTP variable) but most devs don‟t have access to such static analysis tools  Should they?
  56. 56. Tainting  What if we actually marked every character that came in from an HTTP query as “tainted”?  Metadata, on a character by character basis  Would survive passing from function to function  Might even survive reasonable mangling by built in filters  Then, you could write something like: mysql_query_safe(“select * from foo where x=$x and y=$y;”);  Even though $x and $y would expand, the wrapper function would see that those particular characters were once tainted with the “mark of the web”, and could rewrite the unsafe query around it  This still works with mysql_query_safe($x) when $x was assembled elsewhere, even concatenated;  Could have problems with silent failure with filtering functions  Requires a patch to PHP – Daniel Zulla also working on this
  57. 57. SuperEncoding as Explicit Tainting  Based on discussions with Zane Lackey and Nick Galbreath at Etsy, based on an approach they’re already running in production  What if all variables from the web, were encoded in a whitelisted format?  Simple hex encoding -- &%41 – which, coincidentally, renders as an A in any HTML parser  All non-DB access would have to go through accessors  r($x) to read, w($x) to write  Surprisingly easy to grep for access that isn’t wrapped  Could do two things  mysql_query_safe($x) could simply treat all superencoded characters as “data” and parameterize accordingly  mysql itself could have its lexer modified to handle HTML encoding, exposing such characters to less of the SQL parser (“this is just a string”) – very LangSec
  58. 58. A Last Minute Alternative  Perhaps we‟ve got this backwards  Rather than tainting data as data, we mark code as code.  SQL tends not to be passed around from function to function, let alone parsed in the frontend  $sql = c(“select * from foo where x=“); $sql += $x; $sql += c(“and y =“); $sql += $y;  Then either mysql_query_safe or mysql itself (cowardly) refuses to execute anything with unmarked code  Or, if this is baked into MySQL, it just doesn‟t see bytes as code if they‟re not deeply marked as code  Moderately greppable – you‟re basically finding all SQL in your code and wrapping it with some sort of taint  Either implicit as per Zulla, or explicit as per Etsy  Most likely failure mode is an attacker controlled variable somehow getting inside of c(“”);
  59. 59. This is what LangSec means  “What are people trying to say?”  “How can we make it easier to say that?”  “How hard will it be for people to migrate?”  “What errors will they make when trying to use this?”  “Can we limit how much code might contain a bug?”  CARE ABOUT YOUR DEVS OR THEY WILL NOT CARE ABOUT YOU
  60. 60. What‟s Going On With The Web?  It doesn‟t matter what code you write, if there are parties in the middle changing or blocking what you send  Content alteration and blocking is becoming a real thing  Verizon is claiming the first amendment right to rewrite Internet connections  Entire countries are silently blocking web pages  Indonesia‟s blocking a million porn sites in the run up to Ramadan
  61. 61. What Went Wrong With N00ter  N00ter was a really fun (and really powerful) mechanism for detecting network manipulation  Allowed a remote server and a cooperating client to “pretend” to have a conversation with anyone on the Internet, using any protocol  To any MITM, it would look like a real, unmodified conversation  So any alterations that might normally hit the real server, would hit this too  Unfortunately, N00ter does a lot of very low level packetcrafting, meaning (realistically) it requires custom hardware in front of user machines  This is not fun to deploy   Especially if you need to get between NAT and actual network connection  Not impossible. Definitely improbable.
  62. 62. What Else Can We Use?  Executable code on the client  OONI-Probe  Web Pages with Iframes  Herdict (“Herd Verdict”)  Needs either user cooperation, or a Chrome extension, to know if content is up or down  Is it possible to determine whether content is up or not, from just a web page?  Can we crowdsource censorship data?  Maximize data per user  Minimize installation load per user
  63. 63. Imaging  Browser‟s Same Origin Policy usually prevents web pages from doing much with one another  You wouldn‟t want Yahoo able to read from your Gmail account  But there is one exception  Any domain is allowed to load any other domain‟s images  Beyond that, it‟s allowed to know that the load was successful  Not merely that there was a file at that location, but that it was actually an image  You even get image dimensions (which you‟d have to, because it resizes the page)  If a domain is being censored, the image will not load  What one image is on most domains?
  64. 64. Favicon.ico  (It‟s the picture to the left of Google in the tab)
  65. 65. So this is CensorSweeper (Also by Joseph Van Geffen and Michael Tiffany) Written for Wall Street Journal Data Transparency Hackathon
  66. 66. What‟s going on…  img = new Image(); img.onload = function(event) { }// render favicon img.onerror = function(event) { validate(); } img.src = “http://somesite.com/favicon.ico”  The above is done in parallel, reading from a list of sites that have confirmed presence of favicon.ico  Six failures are required before a “bomb” is dropped on the map
  67. 67. Error Handling  Six failures isn‟t actually enough!  Web browsers provide remarkably little feedback to a developer to know what‟s failing, and why  Put simply, “flow control” hasn‟t really been implemented for the web  Everything‟s been designed around infinite bandwidth  For reliability, going to need to shut down all other traffic, and then do two simultaneous lookups  One for a known-up site, the other for the supposedly- down site  That being said, CensorSweeper works pretty well  Can we do better?
  68. 68. Sockets  Once upon a time, web browsers could act like proxies, giving you connections anywhere  There were bugs in Flash and Java; we fixed them  They can now only create connections to IP addresses that invite them  But ~20% of the time there are transparent proxies between web servers and their users  See “Staring into the Abyss” by me, or “Socket Capable Browser Plugins Result In Transparent Proxy Abuse” by Bob Augur  This has been known…but not explored for mapping censorship!
  69. 69. HTTP Censorship Detection  1) Using Flash (or HaXe) Create a HTTP connection back to your own IP on port 80  Host a socket policy file, so Flash allows this  2) Request anything, from any domain  If the request comes to you, there is no transparent proxy  Otherwise, the request will be hijacked by the proxy, serviced, and sent back to your Flash app  You now see what that user would see, if they browsed to that site! You can then submit it back to yourself.
  70. 70. HTTPS Certificate Extraction  Just as HTTP traffic on 80/tcp is hijacked, so may HTTPS traffic on 443/tcp  MITM may have an alternate certificate for you  But (if you‟re careful) it can‟t tell the difference between the browser starting SSL, and Flash/HaXe starting SSL  It has to know which domain to pretend to have a certificate for  The proxy can parse the Server Hello, with its certificate  (It‟s your server saying hello)  The proxy can parse the Client Hello, with its Server Name Indication  (It‟s your Flash app saying hello)  You can actually host the real Facebook certificate, or even proxy the real Facebook SSL endpoint  Hard to keep track of all of Facebook‟s IPs  It has to forge the certificate, before you have to prove you actually have Facebook‟s private key (assuming you aren‟t proxying)
  71. 71. Slight Annoyance  No normal way, via Browser DOM, to determine the certificate that provided content  This at least allows a page to query for its exposed certificates – kinda cool!  Limitations  You can test anyone‟s certificate, as long as the attacker isn‟t interposing themselves via DNS hijacking  The Flash app sees what‟s at the named IP; if hijacking is at the DNS layer, then Flash won‟t get hijacked  You are able to test your own certificate, but then the attacker has already MITM‟d you and can alter your security validation layer
  72. 72. Full Proxying  One of the goals of N00ter was seeing if everyday content was being altered or slowed down  One of the headaches with these custom probes is writing these custom probes  How do you look just like a real web browser trying to access YouTube?  Answer: Be a real web browser trying to access YouTube  The last time we played with Flash and Sockets, we created a full VPN  But now sockets are limited to a single destination…  It turns out that it may still be possible/useful to proxy an entire browser (at the server) down to the Flash app (in the client), which will then make open connections back to the server who will proxy them to the rest of the Internet  This will allow, at minimum, a protocol correct sequence of messages for HTTP and HTTPS that are only incorrect by destination IP  So basically, if the intercepting server doesn‟t care about IP correctness, you get to interrogate its ruleset with no installed code on the client 
  73. 73. Last but not least: Scanning Networks Quickly  Actionable Intelligence: What can an attacker do today, that he couldn‟t do yesterday, for what class attacker, to what class victim?  Rather related to this: How many potential victims are out there?  I‟ve run two major scans this year (that I‟ve talked about)  Telnet  Determining presence of Telnet Encryption support  Answer: Very rare  RDP  Determining presence of open RDP access  Answer: VERY common
  74. 74. My Process  Once upon a time, simply flooding TCP SYNs was enough to find out what was out there  Nowadays, many, many IP addresses will three way handshake, but there won‟t actually be anything there  Solution: Split process  1) Identify candidate IP addresses, that are listening on a given port  2) Given a candidate, actually connect to the IP
  75. 75. More Detail  Candidate collection  For each IP, incrementing the first byte first, (,,…), send a TCP SYN on the required port (23 for telnet, 3389 for RDP)  In a separate window, log TCP SYN|ACKs with tcpdump  tcpdump –w log 'tcp[tcpflags] = (tcp-syn|tcp-ack)'  Scanrand was being buggy, this maximized logging  Candidate Inspection  Telnet Encryption – nmap team whipped up a quick check, so I just fed the IP list to it  Very few found
  76. 76. RDP Sweep: Black Mamba  Probably the most pleasant environment for reasonable scale TCP probing ever devised  http://rootfoo.org/blackmamba  from blackmamba import * def get(host, port=80): msg = "GET / HTTP/1.1rnHost: %srnrn" % host yield connect(host, port) yield write(msg) response = yield read() yield close() print response def generate(host, count=100): for i in range(count): yield get('example.com') run(generate('example.com'))  You end up getting ~3000 IPs a second  May need to increase ulimit –n  May need to alter hardcoded limits in blackmamba.py
  77. 77. Can We Get Faster?  Always wanted to write a userspace TCP stack  HD Moore kinda kicked me into working on one for critical.io, his mysterious new scanning project  I am not at all beyond being motivated by other people‟s awesome and mysterious projects  Especially when they give me CPU and Network Bandwidth  So. Scanrand3! A new scanner that doesn‟t just flood SYNs, but actually connects to every node and extracts data  Original plan: TCP stack with SQLite as the backend  “SELECT * FROM sockets WHERE data_sent!=data_acked and data_sent_time-now()>3” (to find sockets where a retransmit is needed) is just funny!  SQLite, in memory-only mode, is really really fast  160K inserts/sec fast  Unfortunately, that speed disappears when you add indexes  20K inserts/sec with two indexes 
  78. 78. New Plan: Let The Servers Keep TCP State 
  79. 79. Details! Details!  Scanrand didn‟t get its speed by keeping track of who it did or didn‟t send traffic to  Why should Scanrand3?  1) Send SYN  Maximum Segment Size==1460  Window Size==1460 (for all packets)  2) Upon receiving a SYN|ACK, reply with an ACK  Include “GET / HTTP/1.0” payload  Yes, you can put a payload in the initial ACK!  3) Upon receiving an ACK, if there is a payload, ACK it  Save the payload  4) Upon receiving a FIN|ACK, RST  Save the payload, if any
  80. 80. No Local State  If the first SYN is dropped – OK, nobody‟s around to retransmit it  May want to log RST|ACK to avoid future retransmits  If the SYN|ACK is dropped to the client, server retransmits SYN|ACK  If the ACK w/ initial payload is dropped to the server, server retransmits SYN|ACK, causing new ACK w/ payload  If any ACK w/ response payload is dropped to the client, server will retransmit ACK w/ response payload  Same with FIN|ACK  Window size of 1460 means we always know which particular packet to acknowledge – only one in flight (usually)
  81. 81. Performance  Relatively unoptimized code on a well hosted but underpowered server (cheap Dual Opteron)  50-80K servers/sec w/ full payloads  3.25M IPs takes 60-80 seconds, retrieves about 800MB of content  Task is embarrassingly parallelizable across threads, databases, etc.  Should be able to use multiple bpf filters to route packets to their appropriate thread with kernel filtering  Writing to a SQLite DB, and then backing up to disk, is really fast (substantially faster than fwrite, though haven‟t tested a large mmap yet)  You basically reassemble payloads in SQLite as a postprocess
  82. 82. Security  Scanrand pioneered inverse SYN cookies – you protect against spoofed responses by validating fields in the response against hashes of data plus a secret only you know  16 bits in source port + 32 bits in sequence number are possible  May be able to get another 32 bits out of TCP Timestamps, which are usually supported  Haven‟t implemented yet, so very easy to poison me   Sequence space becomes less secure, the more data you actually send  You do know the exact size of each payload, so you can say “I only accept responses with no payload seq, payload 1 seq, payload 2 seq, etc”  Technically the other said can ACK at any byte offset, but that doesn‟t mean they actually will
  83. 83. Some Notes  Kernels have actually gotten kind of fast  Non-blocking connect() plus epoll should be able to get pretty fast  Certainly easier to code for that model!  Didn‟t work for me (not sure why)  This approach ultimately becomes fastest  Probably need a “writev” call to spew many packets w/o a write for each
  84. 84. More Notes  Can also try more efficient stores than sqlite  Giant allocation of RAM with fixed offsets per IP  MemSQL  Neat project by ex-facebookers – compiles SQL to C++  They think even with the indexes they can do +100K  Can have merged approaches too  Only start keeping state if I like the response from the server  Note that stateless client + stateless server = no retransmits 
  85. 85. What should the coding model be?  Flat file / command line?  C?  JavaScript?  Lua?  Could implement support for nmap scripts
  86. 86. Most Important Feature  Blacklist support  Most networks don‟t mind getting swept  They certainly are, already  Some do  Part of being a whitehat is you let people know who you are, and listen to their requests  So you end up with a pile of IP ranges not to sweep  It can actually take a substantial amount of CPU if you check the list naively  Need to compile it into a quickly queriable structure  I don‟t think firewall rules apply to spoofed traffic
  87. 87. Simple Architectural Note  Don‟t try to interact with the Linux firewall  Just pick another IP on the LAN and send from their  Respond to ARP traffic for it  (Yes, it is an advantage of the socket model that you don‟t need to requisition another IP)
  88. 88. Whew!  Lots of stuff!  Hope you enjoyed!  This may not be how you try to fix stuff…but it‟s what I try to do   Thanks to everyone cited in the slides  Thanks also to Nick, Johnny, Blackstock, Alex, Allessandra, Allessa ndra, and Andrew of The Sub for putting up with me in DEFCON mode ;)