Application Links (sometimes called “app links”) is a bundled app that allows you to set up links, share information, and provide access to certain resources or functionality across multiple Atlassian products.

Linking Confluence to other applications allows you to include information from those applications in pages or blogs that you create in Confluence. For example, you could link Confluence to Jira Software and display issues on a Confluence page using the Jira Issues Macro.

https://confluence.atlassian.com/doc/linking-to-another-application-360677690.html

The /plugins/servlet/jira-chart-proxy endpoint in the Server version of Confluence, when being called, will make a GET request to the /rest/gadget/1.0/piechart/generate endpoint of the linked Jira application in order to get the corresponding pie chart of the given JQL query. If this is the first time you hear about JQL, then it is a query language created for searching issues in Jira more efficiently, especially when your search includes multiple criteria, for example:

status=resolved OR projects="BB" OR assigne=ycs OR text ~ "yeuchism*"

You can read more information about the JQL here, or take a quick look at its cheatsheet to get the idea on how it works.

Back to the /plugins/servlet/jira-chart-proxy endpoint. When no results match the query, the following image will be returned:

Otherwise, we will get a chart that looks like this:

It should come as no surprise that because of the Same-Origin Policy (SOP), we cannot read the content of images hosted on other origins. However, the interesting thing is that SOP does not prevent us from getting the dimension of those images (for the styling purpose I guess), which means that an attacker can abuse the /plugins/servlet/jira-chart-proxy endpoint to determine whether a provided JQL matches any issues or not, based on the dimension of the returned image (400×250 vs 400×35). In short, we have a XS-Search vulnerability here, with the ability to leak details of the issues from the linked Jira application.

The “hardest” part in exploiting this issue is that you need to know the Application ID of the linked Jira, which is an unguessable value. Luckily, this missing piece can be found on an unauthenticated endpoint of Confluence (fixed now). Let’s give it a try and see if you can find it or not.

POC

Exploiting the issue on Jira Software 8.3.0 & Confluence 6.15.7

Note: Due to the new SameSite behavior implemented in recent versions of Chrome, the cookies/session of the victim will not be sent with cross-origin requests. If you want to reproduce the issue on your side, please use Firefox to avoid any trouble.

Timeline

  • 23 Jul 2019: Submission created on Bugcrowd.
  • 21 Nov 2019: The issue got resolved (bounty: $600).

Xin gửi lời yêu thương đến 2 chuyên gia vigov và mov vì đã dành thời gian vàng ngọc xem trước bài.

Leave a comment

Comments are better than Likes

%d bloggers like this: