Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Unsafe at Any Speed (PyDays Vienna, 5th May 2018)

Unsafe at Any Speed (PyDays Vienna, 5th May 2018)

The default settings of some libraries and tools are so useless, or even dangerous, that they should never be used. While they give the impression of being easy to use or performant, they actually represent traps for the unwary user. I look at some examples, consider the reasons why these bad defaults might have arisen, and offer some guidelines for setting up projects with good defaults.

Links and resources:

CKAN: https://github.com/ckan/ckan/pull/2164

MongoDB security: https://blog.shodan.io/its-the-data-stupid/, https://www.mongodb.com/blog/post/update-how-to-avoid-a-malicious-attack-that-ransoms-your-data

Elasticsearch: http://bouk.co/blog/elasticsearch-rce/

PEP 476: http://legacy.python.org/dev/peps/pep-0476/

Tom Eastman's Serialization talk: http://s3.eastman.net.nz/serialization/, https://www.youtube.com/watch?v=kjZHjvrAS74
PyYAML issue: https://github.com/yaml/pyyaml/issues/5

MongoDB durability: https://docs.mongodb.com/manual/release-notes/2.6-compatibility/#write-method-acknowledgements

Misconfigured Django apps: https://securityaffairs.co/wordpress/70869/hacking/django-apps-misconfigured.html

Li and Evans, Insecure by Default?: https://www.cs.virginia.edu/~evans/pubs/webframeworks2016/insecurebydefault.pdf

The Zen of Python: https://www.python.org/dev/peps/pep-0020/


Rae Knowler

May 05, 2018

More Decks by Rae Knowler

Other Decks in Programming


  1. Unsafe at Any Speed Rae Knowler PyDays Vienna, 5 May

  2. Who I am @RaeKnowler Python (Django, CKAN) PHP, Go, JavaScript

    they/them/their https://www.flickr.com/photos/zurichtourism/5160475075
  3. Intro


  5. @RaeKnowler #PyDays18 https://nader.org/books/unsafe-any-speed/

  6. @RaeKnowler #PyDays18 https://commons.wikimedia.org/wiki/File:1962_Corvair_01.jpg

  7. @RaeKnowler #PyDays18 Unsafe at Any Speed, Ralph Nader

  8. @RaeKnowler #PyDays18 Unsafe at Any Speed, Ralph Nader

  9. The right thing to do is non-obvious, and the obvious

    thing to do is bad
  10. Defaults aren't bad, bad defaults are bad

  11. @RaeKnowler #PyDays18 What is a bad default? • Data loss

    • Security breaches • Becoming part of a botnet
  12. Examples

  13. None
  14. @RaeKnowler #PyDays18 CKAN "hack" https://github.com/ckan/ckan/pull/2164

  15. @RaeKnowler #PyDays18 595.2 TB Data exposed on the Internet via

    publicly accessible MongoDB databases with no authentication (2015) https://blog.shodan.io/its-the-data-stupid/
  16. @RaeKnowler #PyDays18 https://www.mongodb.com/blog/post/update-how-to-avoid-a- malicious-attack-that-ransoms-your-data

  17. @RaeKnowler #PyDays18 MongoDB and insecure access • By default, DBs

    were open to remote connections, and authentication was not required • Lots of DBs were hacked, ransomed or just wiped • Localhost-only binding became default in packaged releases from 2.6.0 (April 2014) • Implemented in MongoDB server directly from 3.6 (upcoming) • But lots of people won't hear or bother to update their installations!
  18. @RaeKnowler #PyDays18 Other insecure access defaults • Hadoop • Redis

    • UDP (Memcrashed): https://blog.cloudflare.com/memcrashed-major-amplification-attack s-from-port-11211/ • Elasticsearch (this one is weird!): http://bouk.co/blog/elasticsearch-rce/
  19. "The 'S' in 'HTTPS' stands for secure." PEP 476

  20. @RaeKnowler #PyDays18 PEP 476 • stdlib http modules used not

    to verify X509 certificates for https connections • Result: API calls looked simple but were unexpectedly insecure • Many people used requests instead • This was changed in the stdlib based on PEP 476 (August 2014)
  21. 'goodbye': !!python/object/apply:os.system ['rm *'] Tom Eastman, Serialization formats are not

  22. @RaeKnowler #PyDays18 Parsing YAML • PyYAML's default is to use

    load() • Use safe_load() • A long discussion on the topic: https://github.com/yaml/pyyaml/issues/5 • Fix: August 2017. Not yet released!
  23. @RaeKnowler #PyDays18 https://www.flickr.com/photos/sealegssnapshots/2672780121

  24. @RaeKnowler #PyDays18 MongoDB: durability • Write operations used to be

    'fire and forget' by default • Needed to explicitly check for errors • Otherwise, data could be silently lost • Fixed in 2.6, at a performance cost
  25. Good defaults are not enough

  26. @RaeKnowler #PyDays18 https://docs.djangoproject.com/en/2.0/ref/settings/

  27. @RaeKnowler #PyDays18 https://securityaffairs.co/wordpress/70869/hacking/django-apps-misconfigured.html

  28. Setting up good defaults

  29. @RaeKnowler #PyDays18 Why bad defaults get set up • Developer

    knows the tool • Unconsidered use cases • Desire to make the tool seem easy • Desire to make the tool seem performant • Internal tools becoming external • Improved methods are added later
  30. "We expect most of the insecure aspects of current web

    frameworks are not due to ignorance or carelessness on the parts of their designers, but difficult tradeoffs between security, functionality, usability, and ease of development" Li and Evans, Insecure by Default?
  31. Explicit is better than implicit Errors should never pass silently

    The Zen of Python
  32. @RaeKnowler #PyDays18 Good defaults • Secure • Reliable (rather than

    performant) • Never swallow errors • Hard fail on serious errors • Demand explicit configuration if there's no safe default • If a bad default does happen, be brave enough to fix it
  33. Thank you!

  34. @RaeKnowler #PyDays18 Thanks to @BunkyFob, @DRMacIver, @_tomchristie, @alexwlchan, @glasnt, @infosecabaret,

    @janepipistrelle, @mgedmin, @moreati, @n0x13 and @ncoghlan_dev … in default sort order, of course!