How an Akamai misconfiguration earned us USD 46.000

[Nytro]

How an Akamai misconfiguration earned us USD 46.000

FRANCESCO MARIANI

SEPTEMBER 17, 2022

 

 

A few months ago me and my friend Jacopo Tediosi made an interesting discovery about an Akamai misconfiguration that allowed us to earn more than 46,000 dollars. Our research highlighted how manipulating a particular HTTP header made it possible to change the way how proxies communicated with each other and how this allowed us to perform different request smuggling attacks or, in particular cases, allowed us to poison the cache with arbitrary content chosen by us. In this post we will go directly into detail without explaining how these vulnerabilities work in general, hoping that the reader knows what we are talking about. If not, there are so many resources online and even labs to practice with them.

Now the question is: how were we able to reveal the misconfiguration? and how was it actually handled by major bug bounty platforms and private companies? Even today you can encounter this header in the response in several Server under the Akamai network.

Probably many of you have already understood or had already tried to force the use of Content-Length instead of Transfer-Encoding. But let’s go one step at a time. Once we noticed this particular thing, any attempt to abuse the Connection header with Content-Length as a value to perform a Request Smuggling attack didn’t work.

One curious thing we noticed was some unusual responses being provided by Akamai, such as [no URL].

Or, with www.example.com:

if we use the same host, the server actually provided different responses, but as many will know it is difficult to determine if it was actually Request Smuggling, HTTP Pipelining, or a normal server behavior by setting the Connection header in keep-alive.

Trying to redirect the requests with my co-worker we actually found that it worked. But currently, we only had one potential Denial of Service which is often rejected for lack of impact. Once this was done, we did some tests from a different network to verify that it was an open desync.

Only later we discovered that by inserting other host within the Akamai network we were completely able to redirect each other and finally we had a complete request smuggling. This sounds good, but we had a problem. We don’t have a host within Akamai network. How can you prove that through the attack you can arbitrarily redirect users if you don’t have any logs to show? As we continued to try, and luckily for us, we were able to abuse this bug to arbitrarily cache content from other hosts. We also found that, in addition to the GET method, we could use the OPTIONS method to perform the desired attack, moreover, there were more chances that Akamai would not notice that the request was actually malicious.

To poison the cache, it was necessary to send a first GET or OPTIONS request to a nonexistent path (also to avoid damage to the platform), preferably with static resource extensions (more likely to be taken from the cache), with the second request to arbitrary hosts. After a couple of requests, the content of the second host’s file was correctly cached due to its revalidation, like this:

From then on it was possible to visit the URL /it/it/medusa.txt which returned the robots.txt of the second host.

Obviously, the content we decided to cache was not malicious but we could cache many types of files such as html or js.

Finally, we had a nice impact for the report.

POC:

OPTIONS /random.txt HTTP/1.1
Host: ORIGINAL-HOST
Connection: Content-Length
Content-Length: 42

GET /robots.txt HTTP/1.1
Host: ARBITRARY-AKAMAI-HOST
x: 1

by sending the request twice it was possible to cache the contents of robots.txt of the second host. As soon as the discovery was made, we started responsible disclosure, reporting the vulnerability to Akamai. We have not received immediate confirmation from them. While we waited, we realized that not all Akamai hosts were vulnerable or some did not allow arbitrary content caching (they probably had no cache or particular cache key settings that did not allow the attack). We thought maybe it was some general misconfiguration and decided to report it in bug bounty platforms as well.

Vulnerability management by bug bounty platforms: Our sincere admiration for the triagers of the Hackerone platform. After a very short time, they were able to replicate and understand the vulnerability by assigning the right severity.

Unfortunately, in Bugcrowd many of the triagers were unable to replicate the vulnerability despite providing a oneliner with curls, video POC, screenshots, and more. Some just didn’t put the two blank lines in GET requests, others had wrong burp targets and we have also received duplicated (?). like:

We were very disappointed with the Bugcrowd triagers.

Microsoft: Microsoft replied very late, saying it was unable to replicate the vulnerability (Akamai had already introduced the security fix).

Apple: Apple responded late, and was unable to replicate the vulnerability due to Akamai’s fix. They were very kind and we received thanks by email, but no bounty was paid (we didn’t want any).

Intigriti: We only filed a bug, the triager was very nice and friendly, but he gave us a duplicated.

THE FIX: Akamai took very little time to get the security fix after our report, now any attempt to use the Connection header in an inappropriate way is automatically blocked. Akamai has given us permission to make a public disclosure.

 

Sursa: https://blog.hacktivesecurity.com/index.php/2022/09/17/http/