isolated in its own container? • Separate server and IP? • Separate subnet? • Potential vulnerabilities to look for • RCE, of course J • SQL • SSRF • Path Traversal
• ../../../../../../etc/passwd • I mean, if I find that it’s definitely cool :D • This is what I mean • Microservices use HTTP to make API calls to each other • They take our user input in the API calls (REST API maybe? J ) • Example vulnerable URL • https://app.domain.com/api/v1/user?id=1337
Think of how the application is structured • SQL Injection • Path Traversal • Flow of a request • Hacker -> https://app.domain.com/api/v1/user?id=1337 • Microservice -> https://user-service.domain.internal/users/1337 • Content returned to Hacker
POST, PUT, DELETE, PATCH • Sometimes the microservice will add other details in the request that we need to ignore (or not) • Example microservice request: https://user- service.domain.internal/user/1337/all?admin=false • Only a status code 200 returns the content • https://user-service.domain.internal/user/1337/../../ may fail if the web root is a 404 or 403. • Try and generate as many verbose error messages as possible to gather as much as information as you can about what’s going on
Exposed • Exploit known issues in internal services • Jira SSRF • Jenkins RCE • Information Disclosure • Spring Boot Actuator • Admin Access • PII disclosure • PCI data disclosure • Clear text credentials • API and Oauth keys • Open Redirect to pivot to other web applications • CRLF