Speaker: Derek Weeks @weekstweets
For more, see table of contents
- XKCD – reinvent the wheel – “We don’t want to reinvent the wheel, so every day we google image search “wheel” and whatever object comes up, that’s what we attach to our vehicles. Sure external dependencies carry risks, but so far, they’ve all been pretty good wheels”
- If just moving fast, have a problem
- DevOps teams use more open source
- 70% deploy at least once a week
- Challenge: be faster than evil
- In past 5 years, breaches increased 70%
- Can’t predict when vulnerability will come up. Have to use without knowing what will happen.
- Equifax is old news by now. Had opportunity to patch
- Adversaries can also contribute to open source. ex: npm event-stream attack on CoPay
- 2019 – Gems bootstrap-saas – added backdoor
- Typo squatting
- Happening to Docker, Python, Ruby, NPM, etc
- 2019 Software Supply Chain Report
- suppliers (open source)
- warehouses, (component repos)
- manufacturers (softare dev teams)
- finished goods (software applications)
- Maven Central had over 200B downloads in 2019 alone. Almost 10% had known vulnerabilities they day they were downloaded.
- 85% of app is sourced from external suppliers
Enterprise vs Open Source
- Multiple deploys per day vs versioned releases
- Consistent Dev team vs fluid group of developers
- Predictable/well resources vs variable resources
- Deploymen tvs release frequency
- Organizational performance vs popularity
- Mean time to restore vs time to remediate vulnerabilities
Is it true?
- TRUE: Projects that release frequently have better outcomes – more popular, attack more developers and higher level of support from foundations. Also, avoids problem of having to wait for all the transitive dependencies to be in a version we are using.
- TRUE: Projects that update dependencies more frequently are general more secure
- FALSE: Projects with fewer dependencies will stay more up to date. Interestingly, smaller teams tend to have less dependencies. Not clear if correlation or causationl
- FALSE: More popular projects will be better about staying up to date
- Small teams; excellent time to update
- Large teams; excellent time to update, often foundation supported, popular
- Laggards – release slowly, more likely to be commercially supported
- Features first – release frequently, but poor time to update
- Caution – good time to update, but seldom completely up to date
- 38% schedule dependency updates
- 46% strive to use latest version
- 50% have process to add new dependency
- 30% have process to proactively remove problematic or unused dependency
- 37% have automated tool to track, managed and/or ensure policy compliance of dependencies
If only do one thing
- If stay on latest version, by default more secure and less security issues.
Good talk. Especially once the projector issues were fixed. I lik the graphs and data behind the main points. I’ve seen similar presentations, but the newer parts/stats were still good to hear.
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
- 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
- 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
- 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
- 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.
- 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.
- 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
- 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
- Encrypt laptop so don’t get passwords/keys if steal
- Don’t reuse passwords
- Two factor authentication
- Use password manager
- Randomly generate password
- 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
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
- 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
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!
New Security Control Enhancements – Java 9-12
Speaker: Jim Manico @manicode
For more blog posts, see The Oracle Code One table of contents
- JEP = JDK Enhancement Proposal
- Formal process
- A lot of work
- 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
- 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
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
- JEP 319 – open sourced core root certs. Now OpenJDK and Oracle JDK use same certs. Had to sign Oracle’s contributor agreement
- 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+
- No JEPs
- Many small enhancements like the keytool and SecurityManager
- No JEPs
- Many small features.
- Support Microsoft Cryptography Next Generation API
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