[devnexus 2022] hacking the OSS supply changes

Speaker: Stephen Chin

@steveonjava

Link to table of contents

———————

Theme is security with sci fi references

Examples

  • Equifax data breah – from not patching Struts for at least two months
  • Solarwinds – hacked TeamCity instance injected
  • log4shell – zero day in log4j core. Affected almost all systems. Could send class file and having it excecute on the serer
  • spring4shell

Binary repos

  • Which do you trust?
  • npm, pypi, rubygems, maven central
  • Like picking up thumb drive off sidewalk and plugging into your production server

Dependency confusion attack

  • Sci fi – Matrix – agents disguised theselves as other people
  • package mining
  • npm has no security on namespaces
  • Can use same name as a company internal package and give it higher version number
  • If grabing latest version, pull mallicious package
  • When pull from npm, announcing what package you have
  • Artifactory resolves against internal repo first. Protects even if using virtual repo which mixes public and private content

Supply Chain Attacks

  • Sci fi: millinium falcon
  • Assume depedencies built on a clean system
  • Anyone can upoad to pipi
  • About 400 zero day volunerabiities in open source/cloed source/OS, embedded systems, etc
  • Sveder uploaded library to go to his website
  • JFrog scans looking for suspicious Python code behavior
  • noblesse – “optimizes your PC for python” – steals credit card/passwords and sends via dicord
  • pythatoras – supposed to help with calculations but does remote code executio

Namespaces

  • Sci fi: War games
  • Moscow – Russia and Idaho
  • St Petersburg – Russian and Florida
  • azure-core-tracing is proper name. Created core-tracing.
  • NPM took down once repored. At least 218 packages affected.
  • Stole personal data
  • Think bug bounty of test because minimal and not steaing credit cards

Pyrisa

  • Scitfi: Avengers
  • Need automated (IronMan), trustworthy (Black Widow) and dependable (Captain America)
  • trusted binary network – secure by defaut, reliable inimal outages), open
  • peer to peer
  • multi-node verification
  • reproducabe build trust model

Websites

  • research.jfrog.com

My take

I hadn’t heard of all those attacks so learned about the Python ones. The sci fi element was a nice touch. As was the community picture with a ton of people on stage.

[2021 kcdc] lessons learned from enterprise cloud securty programs

This post is my live blog from KCDC. For more, see the 2021 KCDC live blog TOC

Speaker:Karl Ots

Twitter @karlgots

Book: Azure Security Handbook

————————-

Cloud Security

  • Need cloud native security – specific to cloud provider using
  • ”Cloud can be as safe or unsafe as what you did before”

Shared responsiblity

  • Customer responsiblity: data, endpoints
  • Shared responsiblity: identity, application, os/middleware, network
  • Cloud provider responsiblity: physical

Security Program

  • Need to balance speed/“shadow cloud” (someone signing up for their own cloud account) with existing security requirements/eisting EA, lack of security awareness
  • Phases – cloud straegy, governance model, security, guidelines (ex: implementation guidelines and refernee architecture)
  • Cloud security framework defines architecture, policies and controls to secure cloud envrionment
  • Don’t be a generic list of controls. Just be tailored. Doesn’t make sense to apply anything. Cloud security alliance has a list of about 200 sample controls. Don’t just go thru a list of controls in Excel.
  • Terraform (or other tools) typically built by subject matter experts. Ex: database expert writes terraform module for database security
  • Certified products/platform concept – if you use products/components/tools that are pre-approved, can get through security faster. Vetted already

Identity and Access Management (IAM)

  • Integrate with existing IAM processes
  • DevSecOps CI/CD deloys using Azure AD ideneity to application resources. Other identities to actuall run (but not deploy and change things).
  • Need to be able to provide the CI/CD credentials not available/used by others
  • Create a vending machine type system so have to request things. ex: give me a X. Makes automated to request things

Detection and Monitoring

  • Need to enforce logging across landing zone and anything deployed
  • Centralize logs.
  • Ok to have temporary copy as well to focus on new info. Also some alerts verbose and ony want to monior key ones
  • Can build custom alerts, but doesn’t scale. If 10K Azure resources all with own logs, can be unmanagable.
  • Integrate with your SIEM an SOC
  • Separate resource logs (ex: who accessed X) and application logs (what developers log)

Network security

  • Cross subscription, cross region and cross cloud
  • Traffic from platform and infrastructure as a service + app level
  • Can grant access through
    • RBAC in the subnet – fast to do, but dev has to do it
    • Pre-provisioned NICs – medium, thru centralized cloud operations
    • Outside Azure/cloud – slow, thru centralized ops

Supply chain

  • New attack with pre-provisioned agent https://www.wiz.io/blog/omigod-critical-vulnerabilities-in-omi-azure

My take

I’ve learned/used AWS. The speaker is an Azure expert. He tried to make the presentation as cloud agnostic as possible. It was realy good for me to see how much is common across clould providers. It was goo to understand how things I’m doing fit into the bigger picture and something I wish we did differently

why java records aren’t quite immutable

A new type called a “record” was previewed in Java 14 and released in Java 16. One of the benefits is that it creates immutable objects. Kind of.

An immutable record

This is record is an immutable object. Since it is a record, it is automatically final and has no setters. All is good.

public record Book (String title, int numPages) { }

A mutable record

There there is this record. Do you see why it is mutable?

public record Book (String title, int numPages, List<String> chapters) { }

The problem is that records use shallow immutability. The caller can’t change the “chapters” object to a different reference. The caller can change the values in the “chapters” to their heart’s content. That means this object is still mutable.

Here’s an example showing that the code prints [1, 2, 3] and therefore changes the list of chapters.

List<String> chapters = new ArrayList<>();
chapters.add("1");

Book book = new Book("Breaking and entering", 289, chapters);

chapters.add("2");
book.chapters().add("3");
System.out.println(book.chapters());

Making the record actually be immutable

It’s pretty easy to make the Book record actually be immutable. In fact, it only requires three extra lines! Records have a compact constructor which takes care of the setting fields for you. However, you can choose to change that behavior. In this example, I rely on the default set of “title” and “numPages”. However, for “chapters”, I choose to make an immutable copy to prevent changing the list.

public record Book (String title, int numPages, List<String> chapters) {

    public Book {
        chapters = List.copyOf(chapters);
    }
}

Now the test program fails with an UnsupportedOperationException. Much better. A real immutable record.