Tag Archives: security

github – one of your dependencies has a security vulnerability

Posted on by
Reply

Yesterday, I committed a new project to github. I wasn’t paying attention and made a (mental) typo in typing the jackson-databind version number. I typed 2.2.3 instead of 2.10.3. The former is an old version with security vulnerabilities.

This meant I got to try out a new feature I had only read about – github informing you about the security issue in a dependency. Looking at the repo, I saw a nice yellow box – “We found potential security vulnerabilities in your dependencies. Only the owner of this repository can see this message”

GitHub also created a pull request offering to “Bump jackson-databind from 2.2.3 to 2.9.10.3”. I chose not to accept the pull request and choose the later version I intended – 2.10.3.

After pushing that change, the yellow box went away. GitHub even noticed that I updated the pom.xml and closed the pull request with the message “Looks like com.fasterxml.jackson.core:jackson-databind is up-to-date now, so this is no longer needed.”.

I then went into my gmail and deleted the 18 emails with the subject “One of your dependencies has a security vulnerability.” All of these emails arrived within two hours after I committed. That’s way too many notifications!

[2020 devnexus] Developers Need to Take Notice – Malicious Attacks On Open Source Are Getting Worse

Posted on by
Reply

Speaker: Derek Weeks @weekstweets

Deck: https://speakerdeck.com/derekeweeks/devnexus-presentation-derek-weeks

For more, see table of contents

Fun

  • 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”

Notes

  • 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.

Attacks

  • 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
  • Backdoors
  • Happening to Docker, Python, Ruby, NPM, etc

Supply Chain

  • 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.
  • JavaScript hit 10B package downloads in 2019 alone. Just over 51% 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

Behavioral clusters

  • 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

Developers

  • 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.

My take

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.

[2019 oracle code one] security

Posted on by
Reply

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!