Hacking Netflix Eureka!

“Whose Registry Is This”?

Official Netflix Eureka description from the GitHub repository:

Find me a microservice!

Let’s start with some basics to understand how it works based on test lab example:

  1. Two services on the backend inside the local network, webservice and secretservice
  2. Spring Cloud Gateway(further referred to as gateway) configured to route all HTTP requests to webservice
  3. !!! there is no HTTP route from the gateway to secretservice
  4. registry eureka server is in DMZ, supposing that it is exposed by mistake
  5. and user/attacker on the internet.
.route("webservice",
r -> r.path("/**")
.uri("lb://WEBSERVICE"))
For PoC secretservice contains flag(CTF guy detected :p) we need to extract.
here web service asks Eureka client to find secretservice address and then send request there

Exploitation

The main idea for attack vectors is changing HTTP routing with some profit for exploitation.

Attack Vector 1: Server Side Request Forgery

Attack Vector 2: Traffic Hijack and XSS

How to Communicate with Eureka

Just try this

update fields app(both in path and param), ipAddr, hostname

…or if the above request doesn’t work

If the protocol has changed somehow since this publication, the easiest way to extract the correct request is to run simple eureka client+server locally and use Wireshark(it should take ~10mins). Check any tutorial about registry, e.g. https://spring.io/guides/gs/service-registration-and-discovery/

Defense is boring, but we have to…

Bear in mind that keeping Eureka NOT exposed to the internet must not be considered the main defense because IT happens.

Keep it Safe on Application Layer

Eureka supports basic HTTP authentication; use it. Yes, basic authentication is not the best practice, and you have to share one password between multiple micro-services. But it still saves you some time after the attacker finds an exposed registry.

Keep it Safe on Presentation Layer

mTLS between micro-services will help against registering malicious service outside(against traffic hijack).

Keep it Safe on Transport/Network Layers

And, of course, micro-segmentation and strict firewall rules. There is no need to have network connectivity between the gateway and secretservice - it will safe from SSRF. As well as an uncontrolled outbound network connection to public networks must be prohibited - it will save from traffic hijacking (and from reverse shell :p).

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store