{CodingBlocks}.NET

iTunes Spotify PlayerFM Overcast Podchaser Pocket Casts iHeartRadio YouTube feed LinkedIn Twitter Facebook Reddit

Navigation

PagerDuty’s Security Training for Engineers

By Leave a Comment

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | TuneIn | RSS

We’re taking our time as we discuss PagerDuty’s Security Training presentations and what it means to “roll the pepper” while Michael is embarrassed in front of the whole Internet, Franklin Allen Underwood is on a full name basis, and don’t talk to Joe about corn.

The full show notes for this episode are available at https://www.codingblocks.net/episode174.

Sponsors

  • Linode – Sign up for $100 in free credit and simplify your infrastructure with Linode’s Linux virtual machines.

Survey Says

How much personal time off do you take on average each year?
vote
×

News

  • Thanks for the reviews!
    • iTunes: Goofiw, totalwhine, Kpbmx, Viv-or-vyv
  • Game Ja-Ja-Ja-Jamuary is coming up, sign up is open now! (itch.io)
  • Question about unit tests, is extra code that’s only used by unit tests acceptable?
  • Huge congrats to Jamie Taylor for making Microsoft MVP! Check out some of his podcasts:

Why this topic?

  • It’s good to learn about the common security vulnerabilities when developing software! What they are, how they are exploited, and how they are prevented.
  • WebGoat is a website you can run w/ known vulnerabilities. It is designed for you to poke at and find problems with to help you learn how attackers can take advantage of problems. (OWASP.org)
  • “But the framework takes care of that for me”
    • Don’t be that person!
    • Recent vulnerability with Grafana, CVE-2021-43798. (SOCPrime.com)
    • The Log4j fiasco begins. (CNN)
  • You can’t always wait for a vulnerability patch to be released. You may need to patch one yourself.
  • Basically, even if you’re using a framework, it doesn’t mean you can be naïve to everything about it.
  • You shouldn’t use the excuse “It’s just for a hackathon” or “It’s a proof of concept.”
    • This can include things like disabling firewalls, etc.
    • Don’t put things on a public repo, as you might accidentally share company secrets, intellectual property, etc.
      • Open sourcing may be an option later, but it should be looked through first.
    • NEVER use customer data when doing hackathons or proofs of concepts. Too many things can go wrong if it leaks out.
      • Maybe a better rule of thumb would be to never use customer data for any type of development. Instead, always use fake data.
  • The slides had an interesting story that was redacted: there was a software vulnerability that was discovered that existed due to a missing check-in of code, i.e. everything was functioning perfectly fine, and there was an effort already to plug a hole in the code, but it just never made it into the repo. Nearly impossible to detect by automated tools.

Vulnerability #1 – SQL Injection

  • OWASP has more a generic “Injection” as the #3 position, down from #1 in 2017.
  • An example is manipulating a query at runtime with user provided input.
    • This typically implies that strings are patched into a query directly, i.e. WHERE password = '$providedPassword'.
    • Can be attacked by doing something like providedPassword = ' OR 1=1 --.
    • Which effectively turns into WHERE password = '' OR 1=1 --.
    • This is the basis for the tale of little Bobby Tables (xkcd).
  • Users should NEVER be able to directly impact the runnable query.
    • They can provide values, and those should be parameterized, or validated first.
  • The real problem is that people with SQL knowledge can string multiple lines of SQL together to manipulate the original query in some scary ways.

Blind Injection

Boolean

  • Boolean based attacks take time but the scripting throws errors if script results are true.
    • Example they provided is “If the first database starts with an A, throw”, “If the first database starts with a B, throw”, etc.

Time Based

  • Uses the Boolean based attack, but puts them on a delay so they won’t be as easily detected.
  • So you can just regular expressions for keywords and escape quotes right?! Ummm … no!
    • There’s just too many combinations of things you’d need to know as well as weird characters and tricks you couldn’t even be aware of, double or triple encoding, exceptions, etc.
    • It’s surprisingly tricky. For example, how would you allow single quotes? Replace them all with \'? Unless there’s already a \ in front of it, but what if it’s \?
    • You can theoretically overcome all of these problems … but … why? Why not just do it the right way?
  • The answer is to use prepared statements and/or parameterized queries.
    • The difference between a prepared statement and what was mentioned above is the user’s input doesn’t directly modify a query, rather the input is substituted in the appropriate place.
      • Side benefit is prepared statements often execute quicker than manually constructed SQL queries.

Vulnerability #2 – Storing Passwords

  • OWASP has the more generic “Cryptographic Failures” at #2, up from #3 in 2017.
  • Never store passwords in plain text!
  • I’ve heard hashing is good, right?
    • Kind of, until you hear that there’s this thing called rainbow tables.
      • Rainbow tables are basically dictionaries of passwords that have been hashed using various algorithms. This allows you to quickly look up a previously known password with a common hashing algorithm.
  • Using a salt:
    • This is essentially appending a random string of data to the end of a password before hashing it.
      • This salt must NEVER be reused, and it should be changed every time a password is created or changes.
      • The sole purpose of a salt is to ensure rainbow tables will be ineffective. The salts can be stored as plain text right next to the password, they are not a secret, they just ensure the hash will be different even if the same passwords are used multiple times.
  • Using “a” pepper:
    • They referred to it as a site-wide salt, which is pretty accurate.
    • The pepper does the same thing as the salt, it’s appended to every password before hashing.
      • The biggest difference is that the pepper is not stored alongside the data, rather it’s stored in a file on a server separate from the data.
      • Essentially you’re double-salting your password before hashing.
      • Password + Salt (stored next to the password with the data) + Pepper (stored on separate server), then hash.
  • Pepper can make it more difficult for hackers as if they steal the database, they still don’t have the pepper.
  • Pepper can also make it more difficult for the owners of the system as “rolling a pepper” can be difficult, and you have to potentially keep track of all historical peppers.
  • Even with the salts and peppers, this still doesn’t fully solve the problem. Why?
    • Can’t use a rainbow table, but … if a hacker has the salt and pepper, they can try to brute force the password hashes.
      • They can do this because depending on the hashing algorithm chosen, the hashing is just too fast: MD5, SHA-1, etc.
      • Those algorithms weren’t designed for security, they were designed for speed.
    • Solution: Key-stretching
      • This is running the password through a hash algorithm a large number of times.
        • The output of the first hash will be the input for the second hash, and so on.
        • The whole point is to make it take longer to hash. If you were to hash a password 100k times, it might take a second.
          • This means for a legit user, it’s going to take a second to hash and compare a login, but for a hacker trying to crack passwords, at MOST they’ll be able to do one attempt per second.
          • Following the math here, previously with a single MD5 or similar hash, the hacker could attempt 100k password cracks per second vs one per second.
      • It’s still not perfect. Hardware is constantly getting better. So what’s a good and slow today, may not be in a year.
  • Adaptive Hashing:
    • Same concepts as above, except you can increase the number of hashing rounds as time goes on.
    • Really what you want is the cost to hack a password for a given algorithm. PagerDuty had a nice slide on this that estimated the cost of hardware to crack a password in one year.
    • Good algorithms for increasing the cost to hackers are bcrypt, scrypt and PBKDF2.
      • These were designed for hashing passwords specifically.
      • Salting and key stretching are also built into the algorithms so you don’t have to go do it on your own.

Resources we Like

Tip of the Week

  • Did you know you can mail merge in Gmail? It works well! (developers.google.com)
  • Tip from Jamie Taylor: DockerSlim is a tool for slimming down your Docker images to reduce your image sizes and security foot print. You can minify it by up to 30x. Free and open-source. (GitHub)
  • Game Jam is coming up, checking out the free assets provided by Unity in the asset store. The quality is incredible and inspiring and the items range from art work to controllers (think FPS, 3P) to full “microgames” that you can take and build with till your heart’s content. Most are free and the one’s that aren’t are cheap and interesting. (assetstore.unity.com)
  • while True: learn() is a puzzle video game that can help teach you machine learning techniques. Thanks to Alex from GamingFyx for sharing this!
  • Now that Zsh is the default shell in macOS, it’s time to get comfy and set up tab completion (ScriptingOSX.com)
  • GiTerm is a command line tool for visualizing Git information. (GitHub)

Share the joy