offensive-dependency-confusion

# Offensive Dependency Confusion and Namespace Attacks

Dependency confusion exploits a fundamental design tension in package managers:
the need to resolve packages from multiple sources. When an organization
maintains internal packages alongside public dependencies, the resolution
logic becomes an attack surface. You exploit the gap between how developers
intend packages to resolve and how package managers actually resolve them.

Alex Birsan's 2021 research demonstrated that this class of attack affected
Apple, Microsoft, PayPal, Shopify, Netflix, Yelp, Tesla, and Uber, among
others. The root cause -- preferring a higher-versioned public package over
a lower-versioned private one -- remains exploitable wherever registry
configuration is incomplete.

This skill provides ecosystem-specific exploitation techniques, safe PoC
methodology, and comprehensive reconnaissance approaches for discovering
internal package names during authorized engagements.

## Quick Workflow

1. Perform reconnaissance to discover internal/private package names used by the target.
2. Identify the target's package ecosystems and registry configuration.
3. Verify that candidate package names are unclaimed on the corresponding public registry.
4. Prepare a safe PoC package with a DNS canary or HTTP callback and a high version number.
5. Publish the PoC to the public registry with a clear security research description.
6. Monitor the callback endpoint for execution confirmations from target infrastructure.
7. Record callback metadata (hostname, username, CI flag, timestamp) as evidence.
8. Remove the PoC package from the public registry after confirmation or engagement window closes.
9. Document the full attack chain, impacted systems, and registry hardening recommendations.

---

## Reconnaissance for Internal Package Names

Discovering what internal packages a target uses is the critical first step.
You extract package names from every available artifact and signal.

### Lock File Analysis

Lock files are the highest-fidelity source of internal package names. They
list every resolved dependency with exact versions and, in some formats,
the registry source.

```bash
# npm: package-lock.json reveals resolved URLs
# Internal packages often resolve to a private registry
cat package-lock.json | jq -r '
  .packages | to_entries[] |
  select(.value.resolved != null) |
  select(.value.resolved | test("registry.npmjs.org") | not) |
  .key
' | sed 's|node_modules/||' | sort -u

# yarn: yarn.lock includes registry URLs inline
grep -B1 'resolved "https://registry.yarnpkg.com' yarn.lock | \
  grep -v 'resolved' | sed 's/@.*//' | sort -u > public_packages.txt
grep -B1 'resolved "https://' yarn.lock | \
  grep -v 'resolved' | grep -v 'yarnpkg.com' | grep -v 'npmjs.org' | \
  sed 's/@.*//' | sort -u > possibly_internal.txt

# pip: requirements.txt may reference internal packages
# Look for packages not found on public PyPI
grep -v '^#' requirements.txt | grep -v '^\s*$' | \
  sed 's/[>=<!\[].*//; s/\s*$//' | while read pkg; do
    code=$(curl -s -o /dev/null -w "%{http_code}" "https://pypi.org/pypi/$pkg/json")
    [ "$code" = "404" ] && echo "[INTERNAL] $pkg"
  done

# Pipfile.lock contains source information
cat Pipfile.lock | jq -r '.default | keys[]' > pipfile_packages.txt
```

### JavaScript Source Maps

Production JavaScript bundles sometimes ship with source maps or readable
module paths that reveal internal package names.

```bash
# Extract source map URLs from JavaScript bundles
curl -s https://target.example.com/app.js | \
  grep -oP '//# sourceMappingURL=\K.*'

# Download and parse source map for internal module paths
curl -s https://target.example.com/app.js.map | \
  jq -r '.sources[]' | grep -E 'node_modules/(@[^/]+/[^/]+|[^/]+)' | \
  sed 's|.*node_modules/||; s|/.*||' | sort -u

# Look for webpack chunk manifests
curl -s https://target.example.com/ | \
  grep -oP 'src="[^"]*chunk[^"]*"' | \
  sed 's/src="//;s/"//' | while read chunk; do
    curl -s "https://target.example.com/$chunk" | \
      grep -oP '"[a-zA-Z@][a-zA-Z0-9_./-]+"' | sort -u
  done
```

### Error Messages and Stack Traces

Application errors leak internal package names in stack traces and module
resolution failures. Trigger 404 pages, API errors, and debug endpoints.

```bash
curl -s https://target.example.com/nonexistent 2>&1 | \
  grep -oP 'Cannot find module .?\K[a-zA-Z@][a-zA-Z0-9_.-/]+'
# Also search Wayback Machine for cached error pages with module names
```

### GitHub Repository Mining

```bash
# Search GitHub for the organization's package manifests and registry configs
gh api search/code \
  -X GET \
  -f q='org:targetcorp filename:package.json registry.corp' \
  -f per_page=10 | jq -r '.items[].path'

# Search for .npmrc files that reveal scope-to-registry mappings
gh api search/code \
  -X GET \
  -f q='org:targetcorp filename:.npmrc' \
  -f per_page=10

# Search for requirements.txt with --extra-index-url
gh api search/code \
  -X GET \
  -f q='org:targetcorp extra-index-url filename:requirements' \
  -f per_page=10

# Search for NuGet.config with private feeds
gh api search/code \
  -X GET \
  -f q='org:targetcorp filename:nuget.config packageSources' \
  -f per_page=10
```

### Additional Recon Sources

```bash
# Docker Hub, npm org scopes, PyPI author search
curl -s "https://hub.docker.com/v2/repositories/targetcorp/?page_size=100" | jq -r '.results[].name'
curl -s "https://registry.npmjs.org/-/org/targetcorp/package" | jq -r 'keys[]'
# Also mine job postings for internal tool names and library references
```

---

## npm Scope Confusion

npm uses scoped packages (`@scope/package-name`) to namespace packages. The
confusion arises when internal scoped packages are not properly mapped to a
private registry, or when unscoped internal packages exist.

### Unscoped Package Confusion

When an organization uses unscoped internal packages, npm resolves from the
default registry (npmjs.org) unless explicitly overridden.

```ini
# Vulnerable .