2021-12-21 15:26:38 Author: infosecwriteups.com(查看原文) 阅读量:26 收藏
Understand How Microservices Work and Ways to hack it.
Microservices are catching a lot of heat these days, they are on the verge of going mainstream, according to a recent survey from Nginx, 36 percent of enterprises surveyed are currently using microservices, with another 26 percent in the research phase. But what exactly is a microservices architecture.
From a Perspective of a Penetration Tester or a Bug Bounty Hunter, it's very important to first know the core working of technology before actually testing to break it. So today let's dive into Microservices.
Microservices is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain. It helps different services to run independently in their pod and to efficiently transfer data between each other without relying much on each other.
How Microservices are different from Monolith and Rest APIs?
The base difference Between Traditional Architecture(Monoliths and RESTful APIs) and Microservices arises from their way of sharing resources and services within the Application All the services are separated based on their domains and functionalities and are further allotted to individual microservices. Each service in the Microservice Architecture is self-contained and implements a single business capability like User Authentication, Searching, and So on.
These microservices have their own load balancer and execution environment to execute their functionalities & at the same time capture data in their own databases. All the internal points are connected from the API Gateway. So, anybody who connects to the API Gateway automatically gets connected to the complete system
Microservices are leveraging complexity in code by adding complexity in interaction and More Complexity leads to More bugs. According to many studies, Microservices are considered to be four times more vulnerable than traditional monolithic applications. Due to its distributed structure, each service API and network layer expose susceptible entry points to potential attack vectors.
Usually, service calls are secured by implementing an API gateway, which acts as the single entry point to receive a call and then route traffic onto different services. This approach of having a single entry point through authentication has its own merits and demerits. Sometimes an attacker only needs to bypass the BFF/API Gateway to control the whole Architecture. This is the worst nightmare for any company
Theoretically, an API gateway limits the attack surface; however, it also turns out to be a single point of failure for potential attack vectors. Mostly the Authentication part is controlled by the gateway making it more Dangerous if bypassed. Recent research also suggests that most traditional attack vectors target an application through API calls.
There are many ways in which you can bypass the API Gateway to move inside the system and conduct further attacks. Let's discuss them.
Who are you talking to??
Whenever a service call is made there is a high probability that it will pass through the API Gateway, and the Gateway performs many actions on the requested path such as routing and path normalization.
If you get to know which services you are talking to then it becomes an easy task to move forward with an attack. Making sure that your Call is listened to by the internal Architecture can help you to conduct attacks like path traversal, directory brute force, etc.
In the above pictures, you can see 2 requests being sent to the same host with almost the same path, but the response is completely different.
Here the gateway is performing a check on the requested path and it makes sure that the Microservice actually exists before forwarding the request ahead(In this case the “auth” microservice). And if the path exists then the request I transferred ahead.
In a practical attack scenario, the attacker can perform a path traversal attack to make the API gateway route the request to the Root of the microservice allowing them to do anything inside the system without any authentication.
The different responses help the attacker to know which services are being hit. This makes the Directory Brute force very easy, as by only knowing a few of the services they can uncover few hidden endpoints.
Identifying Application Routing.
Routing is the process of selecting a path for traffic in a network or between or across multiple networks. This is the most important aspect of Application Security, if not implemented properly then it can lead to Information Disclosure.
We have to perform a few checks to see how the Application is routing the requests to the internal Architecture.
- Performing Directory Traversal
- Try to see if “/v1/auth” returns something else than “/v1/auth/user/../”
- Is the request being transferred without checking the path? “/v1/auth/../../database” is passed on to the Internal Architecture even if the database Service does not exist.
2. Breaking Application with Random Inputs
- We can try to Fuzz the Application using different control characters such as
%23 (#), %3f (?), %26 (&), %2e (.), %2f (/), %40 (@)
- Giving Input as Double/triple URL encoding
3. Noticing Small Changes.
- Does the root(“/”) of the API gateway give out some information?
- Does the behavior suddenly change for certain directories?
- Why does “/v1/auth” return different headers than “/v1/auth/register”?
- “api.comapny.com:443” -> 200 OK and “api.company.com:80” -> 500 INTERNAL SERVER ERROR
- Does Traversing backward allows us to overwrite the API paths?
Microservices are complex yet Vulnerable you just need to think out of the box.
Thanks a lot for reading. Share if you like it 😇😇
You can find me on Twitter: mayank_pandey01
如有侵权请联系:admin#unsafe.sh