[2019 oracle code one] security

Java application security the hard way – a workshop for the serious developer

Speaker: Brian Vermeer @brianverm & Steve Poole

For more blog posts, see The Oracle Code One table of contents



Scary facts

  • In 2016, cybercrime was estimated to be worth slightly more than the illicit drug trade
  • Cybercrime has less risk than drugs. Rarely get caught. And if do get caught, harder to prosecute.
  • Cybercrime is growing faster than drugs.
  • Cybercrime estimated to quadruple between 2016 and 2019. And to triple again between 2020 and 2021.
  • Illicit drug trade is linear/capped.
  • Cybercrime worth about $600 for every person on the planet through tools you rely on.
  • 2017 – Equifax Struts 2 – Remote Code Injection. Discovered July 29, 2017. But the exploit started months prior. The fix for the vulnerability had been out since March 5. On March 5th, they started probing the system for weakness

General

  • With vulnerabilities can: steal your data, change your data, crash your systems, use your compute power and use your system to get to another
  • Hard to spot vulnerabilities – missing code, off by one errors
  • Exploits are chained vulnerabilities
  • https://cve.mitre.org
  • CVEs can be vague so not providing instructions on how to reverse engineer
  • How do you know you are connected to the wifi you expect?
  • How do you know the USB charger you have is yours and not one that has been modified.
  • How do you know a free power charger is just charging phone and not attacking it.
  • In some countries, hotels are designed so only one place convenient to use laptop and they have a camera angled at it.
  • Fixing is easy. Everything else is not – h=How many people affected? How long? How bad?
  • Every time you add flexibility, you add opportunity

Tools for attackers

  • Google filetype:action to learn which app using Struts
  • Browser developer tools returns information. Response headers including web server (unless change config)
  • https://www.shodan.io – search by IP. Used for IoT devices. Can also type keywords like “java”. Information comes from default response haders.
  • https://exploits.shodan.io/welcome – Can search exploits (pre written attack; just provide IP). And filter by platform.
  • https://www.wappalyzer.com – plugin to learn about website
  • https://www.cvedetails.com – search CVEs and see details. Just like it sounds

Demos

  • Note: https://snyk.io/blog/10-java-security-best-practices/
  • Demo: SQL Injection
    • taking parameter in String query vs using PreparedStatement/bind variables
    • SQL Injection still #1 in OWASP top 10 vunlerabilities
  • Demo: XXE (XML External Entity Processing)
    • <!ENTITY xxe SYSTEM “file:///etc/passed”>]> and <a>&xxe;</x>
    • Each XML parser has different way of turning off external general entities
  • Demo: JSON marshalling
    • Don’t trust everyone who can see the log
      Also, laws against having plain text credit card info
    • Automatically provided toString() that contains sensitive info using Project Lombok to automatically provide toString(). Can annotate fields to exclude using Lombok with @ToString.Exclude
    • Also Jackson writeValueAsString() writes out all fields. Easy t send to front end by accident. Has @JsonIgnore annotation to solve this.
  • Demo: Authentication
    • Don’t do yourself unless have to. Better to use an existing provider
    • Use strong crypto hashes – consume a lot of power/CPU so brute forcing less likely. BcCypt or SCrypt. Provided with Spring Security
    • Password encryption should be fast, but not too fast.

Dependencies

  • You write a small fraction of your app.
  • Much is open source that is well known and written by Pivotal (Spring), Apache, etc. Trusted providers
  • Attackers are targeting open source – one vulnerability, many victims
  • Demo: Struts
    • Inject code in Content-type header. Contains Ogml. Injects code including /bin/bash command
    • The bad header is published so effort is low for attackers
    • Upload file to replace a native jdk file by using ..\..\….
    • We think like good guys. Need to think how to break out of the safe parts.
  • Demo: JavaScript with Regular Expressions
    • Backtracking can use a lot of computing power
    • Node.JS app only has one thread
    • If regex is using up CPU, nothing else happens
    • Temporary denial of service
    • Test with long match and long non-matching string
    • Expensive if in cloud because pay for CPU/scaling
  • On average, takes 2.5 years before vulnerability is found/exposed

DevSecOps

  • NPM has most packages indexed in last year (by a large margin). Maven Central is second.
  • Need to look at: yourself, your code and the code you depend on
  • Individual
    • Encrypt laptop so don’t get passwords/keys if steal
    • Don’t reuse passwords
    • Two factor authentication
    • Use password manager
    • Randomly generate password
  • DevOps
    • you have to maintain/support it as the developer
    • open have elevated privileges
  • Solution: Team culture + process + tooling
  • Use tooling to make right process unobtrusive
  • It doesn’t matter what tooling, it matters that you use it
  • Test dependencies for issues before commit
  • SonarCloud/SonarLint

Types of Security Issues

  • Time and state – unexpected interaction
  • Errors – ex: line number in error message gives insight into library in use
  • API abuse – use not as intended
  • Code quality – if can’t understand, how know how it works
  • Security features – authentication, access control, confidentiality, cryptography, privilege management
  • Encapsulation – lack of encapsulation for critical data
  • Input validation & representation – metacharacters, alternate encodings, numeric representations. Trusting input
  • Environment – everything outside source code

Tips

  • Keep libraries current
  • Learn about secure coding
  • Compartmentalize – data, code, access controls, etc
  • Design for intrusion – review levels of “helpfulness” and flexibility
  • Learn more about security tools and services.
  • Lear about penetration testing
  • Understanding that making your development life easier makes the hacker’s job easier.

Free book/report: https://www.ibm.com/downloads/cas/G3L0EPOL

My take

Great start to the morning. A mix of review and new (to me.) Also, useful to have a “the world is a scary place” reminder. Helps motivate to do the right thing!

[2019 oracle code one] advances in java security

New Security Control Enhancements – Java 9-12

Speaker: Jim Manico @manicode

For more blog posts, see The Oracle Code One table of contents



JEP

  • JEP = JDK Enhancement Proposal
  • Formal process
  • A lot of work

Crypto

  • See https://java.com/en/jre-jdk-cryptoroadmap.html (java.com/cryptoroadmap redirects here)
  • Java 8 had a lot of changes and enhancements
    • Ephermal cipher suite – rotates keys regularly
    • Better random number support
  • Consider third party libraries for crypto. Key management is hard. Want keys stored in vault. Your code should never touch the key.

Java 9 : JEP 290 – Filter Incoming Serialization Data

  • When you shut down Tomcat, it is serializes everything including sessions into files. When start up Tomcat, it deserializes.
  • Don’t deserialize anything untrest.
  • Can inject malware, read any file, run any OS command
  • Research talked about problem in 2011
  • Learned about problem in 2016 with Apache Commons Collections Gadget
  • Better to use JSON/XML
  • JEP-290 – ObjectInputFIlter interface. Validates classes before deserialization. Validates array sizes and deserialization limits
  • jdk.serialFilter – can specify limits
  • Was backported all the way back to Java 6

General notes

  • In 2017, “friday the 13th json attacks”
  • Turn off features not using: ex: XML DTD parsing
  • Patching critical. Ex: Jackson in last 18 months
  • Live attacks start within hours of framework/library security announcements
  • Security knowledge becoming more specialized. 20-30 people know spring security really well

Other Java 9

  • JEP 273 – Deterministic Random bit generator – as good as can get in Java
  • JEP-287 – SHA-3
  • etc

TLS Benefits (https)

  • Confidentiality – can’t view data
  • Integrity – can’t change data in transit
  • Authenticity – ensure site think visiting is the right one
  • Use everywhere
  • Internal apps can be easy attack vector if don’t use TLS/HTTPS
  • Symmetric key exchange fast
  • Asymmetric is slow. Used for authentication and key exchange. That way the symmetric key is exchanged asymmetrically.
  • All versions of SSL are dead at this point. TLS 1.0 is also dead.
  • Credit card processor charges higher fees if use old TLS version.
  • TLS 1.2+ encouraged. 1.3 is widespread
  • Test at server at https://www.ssllabs.com

Java 10

  • JEP 319 – open sourced core root certs. Now OpenJDK and Oracle JDK use same certs. Had to sign Oracle’s contributor agreement

Java 11

  • JEP 324 – Curve25519 and Curve448. More efficient and security. Important in Europe because NSA involved in prior versions.
  • JEP 319 – ChaCha20 is a new stream cipher. Poly1305 is one time authenticator. Combined they provide an AEAD algorithm. (authenticated encryption.) Again important outside US because can’t export ciphers to embargoed countries. Some US customers adopt as well.
  • JEP 332 TLS 1.3 – Much faster. Easier to configure. Old ciphers removed. Didn’t add much, but took a lot away. Supported by Chrome 65+, Edge 76+, Safari 12.1+ and Firefox 52+

Java 12

  • No JEPs
  • Many small enhancements like the keytool and SecurityManager

Java 13

  • No JEPs
  • Many small features.
  • Support Microsoft Cryptography Next Generation API

My take

I wish this talk was earlier in the day when my brain was working better. The concepts were good. I think the details were lost on me because Jeanne == morning person. That said, I learned a bunch of stuff and I’m glad I stayed for it! I really liked having the JEPs as reference numbers

[2019 oracle code one] inspecting in CD pipelines

Silence of the Lambs: Inspecting Source Code and Binaries in Continuous Delivery Pipelines

Speaker: Michael Huettermann @Huettermann

For more blog posts, see The Oracle Code One table of contents



General

  • More than one solution.
  • First “DevOps” book – Adam Smith – Wealth of Nations – talks about division of labor
  • Holistic/shared goals/processes/tools
  • Cycle time – across functions, create own definition

Pipelines/cycle time

  • Start with value stream map
  • Identify areas for improvements
  • Every chain has a bottleneck.
  • Consider theory of constraints. Fixing one bottleneck will expose another.
  • Consider as doughnuts, not tubes. Want feedback.
  • Glue together existing tools.
  • Identify stages and quality gates
  • Automate
  • ex: continuous build, dev build, RC build, GA build
  • “Pushing around binaries is a vintage approach” – should add context info

Many tools

  • Binary repo (Nexus, Artifactory)
  • Containerized infrastructure
  • Cloud enabled setup
  • Continuous Inspection (SonarQube for code, Twistlock for Docker)
  • Supporting/cross cutting tools
  • Middleware (Tomcat, JBoss)
  • Functional monitoring (ELK)
  • Automation engine: (Jenkins)

My take

The images were a good case study. While I would have rather have seen a live demo than a video, it was a video the speaker made so pretty equivalent. And he narrated it well.