Speaker: Theresa Mammarella
For more, see the table of contents.
- Annual cost of cyber crime predicting to top 8 trillion. Only US and China have more than that as GDP
- Vulnerability – weakness/flaw in system
- Threat – attack vector, potential action
- Risk – probably frequency of that loss.
- Goal of cybersecurity is to minimize risk. Can’t control intent to do harm so focus on vunlerability
- CVE – Common Vulnerabilities and Exposures
- Format CVE-xxxx-yyyyy. xxxx = year came out. yyyy = identifier
- CVSS scoring – how bad is it on a scale of 0-10. Ten is worst
- CVSS score has three parts – basic (exploitability, impact), temporal, environmental. Good description here
- Basic is the one we see on the CVE
- CVE can be rejected. The number is used and cannot be reused. Example. Something thought found a vulnerability. Investigation was flawed and not an actual issue. Story about it here.
How to talk about
- Private disclosure – organization can choose when/whether to fix/share
- Coordinated/responsible disclosure – best practice – agreed upon time frame
- Full/public disclosure – share everything
- Best to report via company website, security.md file, security files on server, github private vulnerability reporting
Zero day vulnerability
- log4jshell – remote code loading. Was reported responsibility but incomplete fix so zero days on those CVEs
- Could be as simple as a bounds check. For OpenSSL. Announced something big coming and get ready. When announced learned it only affected OpenSSL 3 (not 2) and high, not critical so boy who cried wolf situation.
Security Practices for Developers
- Insider threat includes poor training
- A lot more developers than info security. Increasingly harder for security teams to keep up.
- Cost of finding and fixing bugs increases over time
- Does this touch the internet? take untrusted input/ handle sensitive data?
- OWASP Top 10. Updated in 2021 to add insecure design, software/data integrity failures and server side request forgery (SSRF). Some merged such as injection.
- Starting OWASP Top 10 for Large Language Model Applications. A draft version is available
- mitre/hipcheck – scorecard for supply chain risk. Similarly, Sonatype security rating and OpenSSF Scorecard
- Open source dependency management. Embedded in many projects. 90% of app is open source on average. North Korea attacked many apps including Putty
- Typosquatting – look alike domain with one or two wrong characters
- Open source repo attackes – attempt to get maleware/weakness added into depednecy source
- Build tool attacks
- Dependency confusion – different version that shows up as latest
- Sometimes third party projects. ex: OpenSSF Scorecard
- NPM and PyPI often have supply chain attacks. Maven Central more so
- Scanning tools to find issues can be helpful
- You are responsible when things go wrong
Good talk. Covered concepts and good real life examples. I learned a few things like the OWASP Top 10 for LLMs. Appreciated the shout out to “the Java people in the front row” when talking about log4j. I added a few links in my blog that weren’t in the original presentation for things I wanted to learn more about.
Speaker: Brian Vermeer
For more see the table of contents
- Everything in Star Trek could be real. And some tech surpassed
- Teleportation would be awesome
- Already have, but for data
- Turn object into data stream.
- Send to another system or save on disk
- Basic serialization is easy. Just implement Serializable
- On deserialization, skips constructor and sets fields directly
- No hash/checksum. Can change in a hex editor.
- Man in the middle attack can change data
- If error reading, get a class cast exception
- Anything in classpath could be in memory. Such as library code that will run code for you
- HashMap provides custom implementation for read object
- ysoserial – gadgets for unsafe deserialization.
- examples of issues with frequent issues: jackson, ehcache
- patching to latest helps fix known things
- 17K packages affected
- 800K attacks in first 72 hours
- 57% have has transitive dependencies
- JNDI looks up and retrieves object
- If own LDAP server can return any object
- Then logger calls
- So passng in the JNDI lookup string can have app do anything
- Showed getting an interactive shell to docker container (which is root)
- Does call constructor on serialization
- Opt in – need to implement serializable
- Still call read object
How to improve when writing custom serialization code
- ValidatingObjectInputStream – call accept() with expected type before reading
- ObjectInputFilter.Config.createFilter – allow specific type and deny everything else
- Setting filter on streams overrides global one.
- JEP-415 – OjectInputFilter.Config.setSeriialFilterFactory – let’s you merge the global and local ones
- See blog post
JSON and Jackson
- ObjectMapper has default typing off unless set it to enabled
- With enabled can inject a malicious gadget
- Deserialization product, but can read
- Can create variables (same problem from XML – billion laughs attack). Reference as *myVarName. Keeps expanding until run out of heap
- Doc type references to read other files and reference has &var;
- On by default on XML Parsers
- Need to explicitly turn it off
- Do not deserialize data from unkown soures
- Prevent custom serialization
- Use filters if still need to do so
- Understand settings for JSON/XML/YAML
- Check for insuecre defaults
- Update insecure libraries
- Gadget chain – string of side effects
Good intro to serialization. Sad there is no try with resources in the initial write and read examples. The examples were great. Good mix of slides and demos. I’m surprised I’ve gotten this far without seeing a live log4j demo.
Speaker: Chris Ries
For more see the table of contents
Vulnerabilities and Secure Coding
- “A flaw or weakness … that could be exploited to violated the system’s security policy” RFC 4949
- Cost – remediation, immediate response (mitigation, detection, incident response, intermediate state while fix), reputation effect
- Design – Threat modeling, misuse cases
- Implementation – , code review, static analysis
- Integration/test – , dependency checkers, static analysis, runtime testing
- Deployment/release (ex: missing third party patches) – vulnerability scanning, monitoring (ex: web application firewalls), dependency patching, vulnerability remediation
Scope of Oracle’s doc
- General secure coding guidelines
- Unique/especially relevant to Java
- Not a comprehensive guide
- Software security not security software
- Read once and then use as a reference
- Each section has a name and each item has a numbered key
Privileges and trust boundaries
- FUNDAMENTALS-3 – Restrict privileges – app level isolation, separate services, lower level mechanisms (ex: containers, OS level restrictions)
- FUNDAMENTALS-4 – Establish trust boundaries – identify interactions with untrusted datacode/users, apply security mechanisms, reduce attack surface
Secure third party code
- FUNDAMENTALS-8 – Secure third-party code
- Patching – apply patches, watch out for bundled/renamed code (shading), leverage automated tools
- Best practices – understand model of libraries/frameworks, review config options
- Tracking – check for updates/support, periodically review security “state of the art”
Denial of Service
- DOS-4 – Robust errors/exception handling for services
- Newest one
- Exception causes – malformed input, logic errors, misconfiguration, environment failures, etc
- can handle or propagate
- Apps/libs may want to propagate. Long running systems may need to do more.
- Define policy for when errors/exceptions reach bottom of call stack – ok to have general catch. Could discard current work, log/cleanup and continue. Rare to have to exit and restart
Injection and inclusion
- Covers more common vulnerabilities – ex: SQL injection, XML processing
- Prefer trusted library rather than rolling your own.
- INPUT-1 – Validate inputs – avoid using untrusted input or validate. Validate early to avoid exposure. Validate immediately prior to use
- INPUT-4 – Verify API behavior related to input validation – very thru docs/testing. Use created/returned object vs original input. Do additional validation as needed
- Avoid deserializing untrusted data if at all possible
- SERIAL-6 – Filter untrusted serial data
- jdk.serialFilter – can specify class/packages with default deny.
- Can set resource limits.
- Alternatively, can setObjectInputFilter() on ObjectInputStream instance
- JNDI injection vulnerability
- Untrusted lookup -> malicious server -> info disclosure, denial of service/remote code execution
- INJECT-8 – Avoid JNDI lookups using untrusted data or follow measures in guidance
- FUNDAMENTALS-3 – Restrict privileges. Minimize impact of compromises from zero days
- FUNDAMENTALS-8 – Secure 3rd party code – Log4J often bundled/renamed, challenge to find vulnerable instances
- FUNDAMENTALS-4 – Establish trust boundaries – where does untrusted data enter, what APIs does it reach
- INPUT-1 – Validate inputs – avoid untrusted data or escape/encode/filter. Potentially useful for logged data
This session was during the networking event and the live band was clearly audible. The walls were good as the noise went up greatly when the door opened. Still, I wish sessions weren’t at the same time. Props to the speaker for ignoring the band and the AV guy for managing the speaker
We got to the Oracle Secure Coding Guidelines at minute 15. I thought the whole session would be about this so was surprised there was so much intro. I tried reading the guide last year. Some parts are a tough read so it was nice to see a presentation. And I got to learn about setting filters on ObjectInputStream. The tie to Log4Shell was nice.