Hacking a Google Web Toolkit application

Hello ethical hackers and bug bounty hunters! I’ve recently conducted a successful penetration testing against a web application built using Google Web Toolkit, and I want to share with you the process I followed and the bugs I found. Hopefully, this episode will inspire you to try harder during your own bug bounty hunting and penetration testing journey.

I will briefly explain what Google Web Toolkit is and what research has already been made around it. Then, I will explain why and how I built a Burp extension to help me during the penetration testing process. Finally, I will share with you some vulnerabilities I found, especially a cool one which required further effort. So stay with me as we smash this web application into pieces!

A brief introduction of Google Web Toolkit

Throughout this episode, I will use Google Web toolkit and GWT interchangeably. It is pronounced GWiT according to the official website.

What is Google Web Toolkit?

Throughout my career, I’ve encountered GWT applications two times only. It’s a relatively old technology, but it’s still used by some companies. According to the official GWT website, Google Web Toolkit is

[…] a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript.

From the official GWT website

In other words, GWT allows developers to write web applications in Java, without having to worry about client-side technologies. In fact, it cross-compiles Java code into JavaScript ready to be used cross-browsers. 

How do Google Web Toolkit requests look like?

It’s easy to tell when you are in front of a GWT application. Typically, you will mostly see POST requests in your web proxy, with a series of strings separated with pipes. It seems intimidating at first, but when you understand how the POST data is structured, it’s fairly easy to spot what it does with a bit of practice. The following is the kind of data you will encounter in a typical GWT web applications.

Understanding the Google Web Toolkit body

I’ve built my knowledge upon this awesome article which explains the previous work that has been done, the GWT body structure and how you can enumerate the endpoints in such a technology. Although it doesn’t completely apply to recent versions, I still recommend you take some time to read it. However, if you still don’t want to manually analyze the requests, it’s possible to parse the GWT requests and pinpoint exactly where the user input is located thanks to a parser available on GitHub. Using this tool, the following command takes the GWT request body and returns the user input marked with the same highlight that BurpSuite uses in the Intruder tool.

Even with this, it’s impractical for me to manually copy the request body from BurpSuite and run the parser for each and every request. I think it would be great if BurpSuite automatically highlights the user input whenever it encounters a GWT request.

Writing my own Burp Extension for Google Web Toolkit

I have always wanted to write a BurpSuite extension, and this was the best opportunity for me to do so. In fact, I didn’t find any publicly available extension that would successfully parse this kind of requests. For example, the GWT Insertion Points is an extension which doesn’t seem to work, at least for me. It hasn’t been updated for 3 years. Moreover, ZAProxy supports scanning GWT requests, but it doesn’t support them during manual security testing.

The birth of GWTab

With the penetration testing schedule I had, I planned for one day to write the extension. Therefore, I had to keep it simple. The goal was to show a new tab in BurpSuite containing the user input for every GWT request. That way, I can significantly increase my efficiency by focusing only on the marked strings without having to manually run the parsing command. Hence, GWTab was born.

The process of writing GWTab

Writing GWTab involved three main actions:

• Show a new tab in Burp: I used the custom editor tab template provided by BurpSuite, which gave me a quick start and let me focus on only the GWT feature I wanted to develop. 
• Parse the GWT body: I used the parser I mentioned earlier. As I said, it can highlight the user input with the Burp Intruder’s marker, which is useful if I want to perform some automated fuzzing later, or even active scanning based on the highlighted input.
• Extensive reading: I had to read parts of the Burp Extender API in order to properly understand the signature of the functions, the interfaces to use and what to implement.

After a lot of trial and error, I finally got it working! I made it available for everyone on GitHub. The following screenshot shows the new GWT tab containing the user input that I can focus on.

Limitations of GWTab

Some requests containing long values make the GWT parser crash. Therefore, GWTab will sometimes show the message “Parser Failed” whenever that happens. Unfortunately, I couldn’t invest more time to fix this issue on the parser.

Now that I can spot user input in most GWT requests on the fly, I was ready to start hunting for those juicy bugs!

Low hanging fruits

I found many low hanging vulnerabilities during this assessment because developers simply didn’t bother implementing any sort of proper access control.

Security through obscurity is a flaw by design

Because the GWT body seems complex, developers assume hackers won’t be able to understand and exploit it. I guess they ignore the very definition of a hacker. If you are a developer reading this, just know that curiosity and challenge are key drivers for a hacker. Besides, be aware that security through obscurity is a fundamentally false protection. It has only pushed hackers to dig even deeper. 

This application was no different. In fact, Broken Access Control and IDOR vulnerabilities were everywhere.

IDOR everywhere

Because of the false assumption I mentioned earlier, almost all endpoints were vulnerable to IDOR vulnerabilities. To make things worse, most requests use increasing numerical identifiers. Besides, it was easy to spot such IDs without even using GWTab since there was only one identifier per request. All I needed was a trained eye, which came naturally with practice. These vulnerable endpoints allowed me to access, edit and even delete resources of other accounts.

However, I want to share details about one bug which required more effort to fully exploit. I chose this one because I want to demonstrate why impact is critical and what techniques you can use to increase it.

Beyond trivial IDOR vulnerabilities

This application is a service exchange platform which allows its clients to offer and consume services. Therefore, if an attacker can delete arbitrary offers, it means that the whole purpose of the application is compromised. Guess what! I found just how to achieve that!

Vulnerability detection

Detecting this vulnerability was easy. In fact, I followed the same approach I mentioned in the video tutorial about Broken Access Control. In a nutshell, I used two separate accounts. Using the first account, I created an offer and triggered the request to delete it. Before deleting it though, I captured the request using BurpSuite and sent it to the Repeater, then dropped the request to preserve the offer. From there, I took the JSON Web Token of the attacking user and inserted it into the vulnerable request. When I sent it to the server, the victim’s offer got deleted.

Impact analysis

Looking at the POST data revealed a huge payload containing multiple objects, IDs and string values. As a bug bounty hunter, you would quickly report this bug right? Well, the impact is still not clear. In fact, I had no idea how an attacker can realistically build such POST data. If you have listened to read the episode about writing a good report, you know that impact plays a huge role in the bug bounty game. To prove the impact, I had to dig deeper into the application.

Exploiting the vulnerability

I first assumed that the server might delete the offer whose ID is present in the request. Therefore, I tried injecting the victim’s offer ID in all the potential inputs present in the POST data. I had to do it by hand since the GWTab extension failed at parsing the POST data. However, after many tries, it became obvious that this was not the right approach because nothing was deleted.

I didn’t want to give up so quickly. I knew that the application allowed users to search for offers of other users. What if I could grab the entire offer object from the results? Unfortunately, this idea failed since both objects didn’t fully match.

It was clear that I needed two requirements if I wanted to successfully exploit this vulnerability.

• First, I needed a request which uses the same offer object structure.
• Second, this dream request should be accessible to the attacker.

Based on these two requirements, I started looking through the application features for all the actions a user can perform on offers published by other users. After some time, I found that the user can like and unlike an offer. Lucky for me, the unlike operation uses the exact same offer object as the one used in the offer deletion request! I couldn’t believe my eyes, I was really lucky!

From there, the attack scenario became clear:

• An attacker browses the offers list, which is public.
• He/she likes the victim’s offer, then unlikes it.
• He/she captures the offer object and injects it into the vulnerable request.
• The victim’s offer gets deleted from the database.

Writing the report

Now that the impact is clear, you can finally and safely report that bug without worrying about rejection. Besides, you might even reduce the probability of getting duplicated since your vulnerability requires more effort to exploit, and not all bug bounty hunters are willing to take the extra steps. Moreover, even if the team accepts your not-so-convincing-impact report, the reward of a clear impact will certainly be much higher.

Conclusion

In the offensive security industry, whether you are a full-time penetration tester or a seasoned bug bounty hunter, curiosity and challenge are the fuel which will push your limits. In my case, I always wanted to write a Burp extension to solve a problem, and this application presented the right opportunity for me to challenge myself. Besides, I always seek ways to achieve the highest impact not only to get higher bounties but to give a better return on investment to my clients as well.

Later I found that the developers were already aware of this issue. However, because of the complexity of the POST data, they assumed that nobody would figure out how to successfully exploit the vulnerability. Thanks to this full exploit, they’ve learnt that they should never rely on obscurity…the hard way!

I hope you found this content useful. If you did, then support me by commenting, sharing and subscribing. Until next time, stay curious, keep learning and go find some bugs.