Secure Coding Martin Carnogursky admin@sourcecode.ai Authentication & Authorization in practice Don‘t repeat the same mistakes I did ... • DON‘T Make your own auth system (username & password) • ^ If there is one thing you should remember from this • Use existing 1st / 3rd party services by integrating into them • Use existing protocols (ex. OpenID/OIDC/OAuth, ...) • Plan carefully into the future • Swapping auth system is very high-risk, time consuming and something always goes wrong Quick reference • OpenID -> use the OpenID provider to log in to your application (e.g. Sign in via Google); Authentication layer: proving who you are • OAuth -> allow an application to act on your behalf (e.g. Post a message to Twitter); Authorization layer: grant access to functionality/data • OIDC -> OpenID Connect • SSO -> Single Sign On; done usually via OpenID or SAML • SAML limitations -> browser workflow only, no mobile devices/rest api What to plan for • Verify identity of a given user (user+password, SSO, api tokens, ...) • Authentication & Authorization • Role based model: admin vs „normal“ user vs tech support and more • Impersonation • Password reset, 2FA, enrolling users • API tokens • Inherit user permissions • Account lockdowns & resets must affect api tokens as well 3rd party auth providers* OIDC Redirect MFA/2FA JWT/API Tokens * Personal preference/experience Authentication & Authorization for developers (and employees) • Access to the database • Access to the server (ssh, ftps, ...) • Access for (server/performance) monitoring (or dashboard) • Interns (temporary access to some resources) • People leaving company • Enrolling new developers • Bug reporting • Audits You are a high value target as a developer! • Root/admin access on servers • Unrestricted read/write to DBs • Read/write access to the source code • Access to a CI pipeline • Access to deployments (docker, kubernetes, nomad, ...) • Access to releases (package, exe, ...) • Access to sensitive 3rd party APIs (ex. Payment gateway) • Copies of data (db, customer details, dumps) Common mistakes • Shared API keys • No access policy • No auditing/logs • Config files vs. Environ vars • dotenv HashiCorp Vault / OpenBao* • ACL for managing secrets • Generate temporary secrets on the fly • Automatic expiration & renewal • Roles & policies for every user & secret • Easy revocations • Awareness of active secrets • Full audit logs: what secret was issued to whom, when, with what priviledges, start & end (expiration) dates etc... • Many engines supporting many protocols: • SQL DBs (postgres, mariadb, mssql, ...) • NoSQL DBs (kafka, mongo, ...) • Other systems (Cas, SSL certs, SSH, JWT tokens, ...) • Integration with OIDC * Personal preference/experience that I stick with, there are other alternatives Software supply chain What is a supply chain? Image source: http://img.scoop.it/Fwh7RipNyY3N384cITe5qbnTzqrqzN7Y9aBZTaXoQ8Q= Includes auth principles that we just talked about How babies packages are made peewee-2.27.1.tar.gz Setup.py <- „.py“ means it‘s executable setup( # We are in fact calling a python function with the following arguments ... name='windows95', author='Bill Gates', author_email='bill.gates@microsoft.com', url='https://github.com/coleifer/peewee/', packages=['requests', 'cGVld2Vl\n'.decode('base64') , 'ipaddress'], install_requires=random.choice(["pkg1", "pkg2", "pkg3", "pkg4", "pkg5"]), ... ) TL;DR: Most packages (and/or their formats) are not deterministic! Types of attacks • Namesquatting • Typosquatting • Stub package • Phishing • Starjacking • Dependency confusion • Existing packages • Malicious dependency • Package takeover • Dependency hijack • Source code modification Typosquatting/namesquatting What was the name again? a) pip install pewe b) pip install peewe c) pip install pewee d) pip install peewee Types of attacks • Namesquatting • Typosquatting • Stub package • Phishing • Starjacking • Dependency confusion • Existing packages • Malicious dependency • Package takeover • Dependency hijack • Source code modification Starjacking Types of attacks • Namesquatting • Typosquatting • Stub package • Phishing • Starjacking • Dependency confusion • Existing packages • Malicious dependency • Package takeover • Dependency hijack • Source code modification Dependency confusion Source: • https://portswigger.net/daily-swig/dependency-confusion-attack-mounted-via-pypi-repo-exposes-flawed-package-installer-behavior • https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 Types of attacks • Namesquatting • Typosquatting • Stub package • Phishing • Starjacking • Dependency confusion • Existing packages • Malicious dependency • Package takeover • Dependency hijack • Source code modification Source: https://security.snyk.io/vuln/SNYK-JS-NODEIPC-2426370 Exploiting PRs/commits workflow • GitHub diff view doesn‘t like NULL characters • Automatic trigger of CI pipeline • Self-approve PRs • Add new CI/CD workflows • Fake digital signatures More reading: https://iter.ca/post/gh-sig-pwn/ Malicious PR Leaking credentials User aclark Pillow: Image processing library 14323814 Downloads 3324 # of dependencies 17.05.2022 Last updated Aimelia: simple todo list (?) 723 Downloads 0 # of dependencies 02.04.2017 Last updated It‘s not important, or is it? Contains pypi password forIs maintainer of Less importantMore important This doesn‘t always work... Disclaimer: Not recent, found in 2018, first significant finding of the Aura project. Reported to Python security team and forced password reset. Threat modeling via graphs By compromising user aclark we have access to all these packages via (in)direct dependencies. Compromising key strategic packages/users is enough to compromise most of the pypi ecosystem. Source code modifications Reproducible builds How can we make sure, whatever is in github is the exact same version deployed on pypi without any additional modifications such as malware, backdoors etc? More reading: https://reproducible-builds.org ^SourceCode\.AI$ admin@sourcecode.ai https://openssf.org • ^Aura$ • ^Ambience$ Lab/Seminar: https://github.com/SourceCode-AI/secure_coding 2021 Solarwinds breach... • Attackers even mimicked the coding style of developers to remain stealth • Could be (arguably) easily detected by behavioral indicators Static behavioral indicators Privilege escalation Tampers with user/account privileges Enumerates system information using VMI Reads information about one or more running processes Source: https://blog.reversinglabs.com/blog/sunburst-the-next-level-of-stealth