gRPC Security Series: Part 3

Security Vulnerabilities in gRPC

In the previous part 2 article, we got acquainted with different tools that can be used to interact and test an application consuming gRPC technology. In this article, we will be looking at some of the vulnerabilities that we found while performing our research on gRPC. We also developed a vulnerable gRPC application that exposes some CRUD functionalities to have a better understanding. Let us begin our hunt!

Use of Plaintext communication

gRPC servers by default allow communication to happen in plaintext. In addition to this, when developing the client-end code, developers may use the usePlaintext() method while building a communication channel. They may use it to test the client-server interaction while the software is yet to go in production. However, this feature often gets continued to production environment. This poor coding practice leads to exposure of sensitive information that is being exchanged between client and server.

One can confirm this vulnerability via 2 tools — gRPC cURL and Wireshark. When initiating an interaction with a gRPC endpoint via gRPC Curl, simply include the flag “-plaintext”. If you can view the transactions, then it is confirmed that the server communicates in plaintext. One may also start Wireshark to listen for the specific port that the gRPC application is using and capture the data that is being exchanged.

Fig. 1: gRPC Curl tool invoking a gRPC service using plaintext method

Fig. 2: Wireshark capture showing plaintext data being sent across

Unwanted Service Exposure via Service Reflection

This is a useful yet risky feature. It basically allows the server to broadcast the available services that a gRPC server is offering. This can be useful when the application is being developed and can be easily used for testing. However, it can turn into a pain point as it may allow an attacker to enumerate the possible services that are being offered/exposed by the gRPC server. Thus, it is important for developers to selectively use this feature.

Fig. 3: gRPC Curl invoking a service that enables reflection

Vulnerable Dependencies

Although gRPC is a modern technology, there are times when applications are found using outdated vulnerable dependencies. In our case, the application was using vulnerable versions of gRPC-Protobuf. These packages could further expose the application to vulnerabilities like Prototype pollution, RCE etc. It is important that the dependencies of gRPC applications are audited before the application goes into production. gRPC is a very secure technology. But if it’s working in an environment with vulnerable dependencies, then it can lead to exposure of sensitive information and application downtime as well.

Fig. 4: Vulnerable protobuf module

Insecure Protobuf Definition

The Protobuf file is the core component of gRPC. It contains the services, messages, and their definitions. It is important that the developers take utmost care in exposing only the necessary gRPC services and how they are configured. In our case, an improper configuration of the Protobuf file caused a service to cause unwanted data exposure. The application accepted input for a certain blog entry to be displayed but also exposed other sensitive data along with the blog data. Developers must define a blueprint when they are designing their services and be clear on what should be the streaming type for each service.

SQL Injection

gRPC applications are indeed vulnerable to injection-based attacks. These types of attacks come as freebies to any application that accepts user input in any form. In our case too, we had some CRUD operations that accepted input parameters. Upon tampering with the input fields, the application malfunctioned, and it revealed more data than it was required. This often happens when poor coding practice is in place and the user input is not being validated properly.

As part of our regular team upskilling, we conduct CTFs internally. And thus, we created a CTF on exploiting SQL injection in gRPC. Now, ideally, SQL injection in web applications occurs when an exploit is passed in the user input which further gets passed on to the backend server for exploitation. In case of gRPC, it was kind of same. The vulnerable Blog application was also offering CRUD operations. The attacker had to get hold of one such service and exploit their way up to capture the flag.

Fig. 5: SQL injection via user input in request

Tool Requirements (Supports gRPC)

• Go Language installed
• GRPC UI
• GRCP CLI
• Burpsuite

Target instance

• 127.0.0.1:50051

Let’s take the instance of target 127.0.0.1:50051 for this blog

We will first try to list out the blogs available to us in the target scope by using the below command :

grpcurl -plaintext 127.0.0.1:50051 list

Fig. 6: gRPC Curl output for list command

Now we are able to see that the blog service is up and running, we will now check about the list of services running on gRPC server by using the below command:

grpcurl -plaintext 127.0.0.1:50051 list blog.BlogService

Fig. 7: gRPC Curl output for listing Blog Service

Now we will create a blog using the GRPC UI tool and for this we will use the command as follows:

grpcui -plaintext 127.0.0.1:50051

Fig. 8: Initiating gRPC UI to interact with services in vulnerable gRPC App

This command will initiate a UI portal on which we can provide our data to create or modify our blog. There are other operations also which we can use from this portal.

Fig. 9: gRPC UI connected with the vulnerable gRPC application

From here click on update blog and capture the request and in the author id section of the captured request insert a SQL injection payload as below –

Fig. 10: Capture of request/response in Burp Repeater

You can observe the temporary flag value is being returned in the response.

Conclusion

These were some of the vulnerabilities that we found in our quest to exploit this contemporary RPC technology. The CTF challenge gave us a glimpse on how to practically solve or hunt for vulnerabilities in gRPC-based applications. Generally, if you see, gRPC is like another new technology in the industry like REST, SOAP. Mostly, such technologies are being implemented on top of legacy applications, hence hunting for vulnerabilities becomes easier. In the next article, we will be discussing on some of the best practices that can be adopted to harden your gRPC service architecture.

Article By:

Sourish Das (C|EH, Security+, IBM Cloud)

https://www.linkedin.com/in/sclandestined/

Penetration Tester

IBM PTC Penetration Testing and Security Services

Pranshu Tiwari (eWPT, eWPTx)

https://www.linkedin.com/in/pranshu-tiwari/

Penetration Tester

IBM PTC Penetration Testing and Security Services