Reversing Bytecode into Bounties: Uncovering Vulnerabilities in Jira and Confluence Plugins

We have uh Juliana and Jamal and they're going to share with us uh reversing by code into bounties. So give it up.

>> Thanks. Hi everyone. Um welcome to our talk reversing bite code into bounties. I'm Juliana. I work on the security testing team at Atlassian. And this is Jamal. He works on the product security team at Atlassian. um but did a brief stint in my team which is where the good stuff from this presentation's come from. Um and today we're going to teach you how to hack plugins. So if you haven't heard of Atlassian before, we're a big software company that makes software for other companies. Um two of our main products that I'm sure everyone here knows and loves completely. Um yep, Confluence and Jira. So Confluence, you haven't heard of it, it's like online word. Uh and Jira helps

you track tasks. So just for the context of this presentation, keep that in the back of your minds. We're software a software company that makes software products that everyone loves uh and plugins. We'll go into those and we'll get into that shortly. So we have two main offerings. If you've used Jira and Confluence, you might have used the cloud versions. Um, if you're on a bit of the older side, maybe you've used the data center products, which are the onremise versions that you can install locally on your computer and run them yourself or on a host of servers or whatever floats your boat. Um, they're the original ones that were created like over 20 years ago. And those those

products are the ones we're going to talk about today in terms of the plugins that belong to data center or what we're going to refer to as DC in this presentation. So yeah. Okay. So the Atlassian marketplace is where you can download both the data center or DC apps and the cloud apps. Um it's marketplace. And yeah there the DC versions of these apps are Java apps that you just download locally and then you can upload them to wherever your Confluence or Jira instance might lie. Um, so yeah, um, that's why we kind of call them plugins rather than apps cuz they're like directly plugging into the existing code of the product rather than the cloud

apps which themselves you download directly onto the cloud version and it's all hosted by Atlassian and you don't really see or touch that install process. So yeah, um, anyone can download these plugins. you could bring it up today and and download a JAR file and and have the plug-in locally without even a Confluence or Jira instance. They're free for the most part um until you purchase a license for a lot of them. Um so yeah, you can play around with them yourself. And a few months ago, we were tasked with pentesting some of these apps. Um and we were pentest we were tasked with pentesting the riskiest ones. Uh, and we'll go through that process of like why we would do that,

why do we care, and um, yeah, how to hack them as well. It's a pretty new process for us as well. So, yeah. Um, back to what I was mentioning about how these plugins reside on the same host as the app that's running like Jira or Confluence. Um, it makes the attack surface pretty large and pretty risky because the plugins are using the same exact like database that Jirro and Confluence is using to store like the bulk of what's important, what what our customers care about, right? Um, and you know, it was designed this way a long time ago because like the founders wanted extensibility and really customizability and the ability for marketplace vendors to kind of like

borrow a lot of functionality from the existing Jira and Confluence. So they're quite powerful as well and that's what makes them quite risky um given they can do a lot and they're very tightly coupled with Jira and Confluence. So we had a couple incidents um over the years involving compromises of apps which then resulted in the compromise of the Jerro and Confluence Enterprise DC version of some large customers which raised our concerns. You know it's not something that's entirely within our control in order to you know we we don't own this code. This code's written by third party vendors. It's it's like downloading something from the app store. You know, Apple doesn't have control over the code

that gets written on the app store. They can just manage the ecosystem. So, apart from doing some things to help make that ecosystem better, how do we actually ensure the code on there is secure? It's really hard. So, our team got asked to pentest the apps. And usually we're pretty good at pentesting code we own because we're used to doing white box tests, but this was a pretty new surface area for us because um it's code we don't own. These apps are jar files written by other people. How do we pentest them in a way that we feel confident that we've covered them really well. So the project was called too big to fail. Um and it actually included both

the cloud and the DC apps. Um, but we're quite a small team at Atlassian with pentesting. Um, so we borrowed some help from consultants and our suppliers to get some of the cloud stuff done. Um, and our internal team focused a lot on these DC apps. So yeah, we tested around 20 of the most risky apps um, based on a bunch of parameters including like how many install counts the app might have and um, what types of customers if they're really large enterprise customers that have them installed. Um but yeah um 20 apps which is uh where we found 18 vulnerabilities which is almost one per app and 13 were high and critical which we think pretty I mean

it's good in terms of outcome for our team not so good in terms of the apps themselves but um if you're looking to then participate in a bug bounty program should give you a bit of confidence that you know there's a good chance that you'll find something especially because we only looked 20 to start with. We're going to look at more in the future, but maybe you'll beat us to it and find some of these vans. Um, we did the math and this would have made us about 20k over 3 months if we were submitting them to the public uh bounty programs. Um, so 3 months for us, 20k, that would have meant maybe 80k of income in the year.

Um, you know, that's that's that's okay. That's okay. It's not going to get us this beautiful $2 million house in Sydney. We'd need to do that work. We'd need to submit bugs for about 25 years and not spend a single scent on anything else if we wanted that. And I'd have to live with Jamal as well. But, you know, that's okay. Um, yeah. Okay. So, we promised we'd tell you how to hack them, right? So, we're going to go through firstly how to choose a target. A lot of apps on that marketplace. How do you how do you pick which one you're going to focus on? Um, then we're going to show you how to decompile them.

They're JAR files after all, and we are whitebox hackers. Uh, we like code a lot. So, if we can decompile them and use the source code to find vulnerabilities, we're really happy. And then, uh, obviously doing a code review um on that code. And finally, the fun part, actually testing and finding the vulnerabilities. So, let's kick it off. The first step, how do we choose a good target for hacking? Here's two of some of the most popular DC plugins for um Jira. These ones are for um some of you might have heard of them. It's okay if you haven't. ScriptRunner for Jira and X-ray test management for Jira. So notice that they've got a pretty high install count,

almost 40,000 um for each of them. Don't ask me why the ratings are out of four. I don't know. It's really bugs me, but that's okay. Um yeah, but one of them script runner lets you execute arbitrary code. So what could go wrong with that? That's like really really awesome. Um and test management. This one it does let you run tests and integrate with like your favorite pipeline software like I don't know Jenkins or Bitbucket pipelines. Um and yeah you can execute developer written tests. So also kind of code execution right. Um, so the attack surface like I was mentioning earlier, it's pretty wide. There's there's a lot you can do with these apps and they have

they're pretty powerful. They've got a lot of functionality. So having a look at what one of these apps would look like on marketplace. This one spreadsheets for Jira is just one we've made up. It's a demo vulnerable app and we'll share the code with you at the end of the presentation as well. It's the one we're going to be hacking today. Um, yeah, you can see you might take a look at the install count. You might double check that it's definitely for data center. Um, and then you might also notice if it's part of the bug bounty program, and that part's crucial because if it's not, you're not going to get paid for finding phones,

right? So, you really want to make sure it's part of the bug bounty program before you go and start hacking. Um, yeah. Okay. So, on that same file, that's where you can download the JAR file, the the plugin in its entirety um to your local machine and get started on the hacking. So I'll pass it over to Jamal to explain what even is a JAR file. >> Yeah, thank you. Thanks Juliana. So at this point we're looking to hack a marketplace plugin. We've identified a plugin that we think looks interesting. It's got a high download count and we've gone and downloaded that jar. But what is a jar? So a JAR file is essentially a

a packaged up stands for Java archive. And it's a package of all of the class files, metadata, and other resources that that plugin needs to be able to run. So it includes everything that it needs. And these JAR files are created so that you can easily distribute this plugin wherever you need to put it. Essentially, a JAR file is just a zip. It's an archive and you can actually just run unzip on it. And that's the going to be the first step that we do. Um, by unzipping it, you get access to all of the resources, all of the class files, and all of the information that you need to then be able to decompile

it. Now, what is a class file, I might hear you say? Well, a class file is the binary of this Java file. So, it's the Java byte code. And if we actually open that up in our text editor, it'll look something like this, which is horrible to read. You can't understand a thing of what it's saying. You can see there's some strings there, but a lot of it is really just gibberish. Now, we need to go through the process of converting this back into a Java file, something that we can read and understand and actually analyze the vulnerabilities. Now, some idees will actually have this little button you can click or some other functionality which let you

convert that into bite code. This makes it slightly better. Uh you can kind of I don't know, maybe some of you can read this. I definitely can't. I have no idea what's going on here. uh we need to actually go that next step and convert this into Java code. And to do that, we're going to need to actually decompile it with a decompiler. Once we use the decompiler, we'll actually end up with our beautiful Java source code source code that we know and love that we can read and analyze and look for vulnerabilities. So during our testing, we actually developed a script to be able to do this for us on mass. Uh we used two different

open-source Java decompilers. There's quite a few out there, uh, but we actually ended up choosing to use two every time that we decompiled a plugin. And the reason for this is that we actually discovered that the the decompilers weren't consistent with what they were producing. They were pretty consistent. They they pretty much produced the same source code, but later when we looked for vulnerabilities in that source code, one of the decompilers might have, you know, decompiled a bit of code that identified as being vulnerable, and the other decompiler might not have. So, we actually ended up using two throughout the whole process. Um, so we developed a script to be able to do this. Uh, and we're going to share

this in the resources at the end. Uh, the script does a few things. Uh, it first goes through and looks at the current directory to find any jar files that are in the directory. And when it finds them, it'll run both decompiles on them. Oh, can I click play on the video? I'm not sure if that's going to work. That's okay. Um, so the Yes. So we we run our script and it will go through and find all the JAR files and decompile those. It's also going to unzip all the JAR files so that we can get access to the metadata. There's a specific file in there that we'll show you later that is quite interesting and specific to

Atlassian that will show you the routing paths for all of the rest endpoints that you might want to look at. Uh and the other thing that it's going to do is occasionally when you download a marketplace plugin, you're going to get an OBR file instead of a JAR file. The decompile script that we've created handles those as well. that essentially unzips the OBR file and then goes through it and looks for all the JAR files that are inside it and then decompiles each of those. Now, the plugin that we're looking at today, the demo vulnerable plugin is it's a very simple plugin, right? We we've made it to be very simple. It's got one vulnerability that's vulnerable to which

is also very basic and it doesn't have a lot of code. So, it decompiles very quickly. But if you're downloading a plugin off the marketplace, say ScripRunn or X-Ray, they're going to take substantially longer to decompile because the JAR file actually contains everything that this plug-in needs to run. That includes all of the third party libraries, literally all of the code that it needs. So when you decompile it, it's also going to be decompiling Jackson, JSON, JSU, what whatever other libraries that that needs to run, and you're going to end up with quite a complex directory of decompiled code. So, if you run the decompiler on our demo plugin, you get this very nice, neat uh sort of directory structure.

Again, if you're running it on an actual plugin, this is going to be a lot bigger. The key things that you're going to get here, uh, up the top here, you can see I don't know if my pointer shows up. It does. You're going to get the spreadsheets for Jira snapshot directory. This is the unzipped jar. So, in here, you're going to have interesting metadata. A key one that we'll look at later is the Atlassian plug-in.xml. This has all the routing information. And you're also going to get a bunch of resources, front-end uh velocity templates and things like that. The the next thing you'll get is this decompiled directory with both a proon and CFR directory. Now, Proon and CFR

are the decompilers that we used. We'll also have links to those in the resources at the end. Uh and that's going to then have the all of the decompiled code. And you can see here we've got um a more classic directory structure that you'd expect from Java, including our implementation and rest resources down here. All right, I'm going to hand back over to Jake. >> Cool. Okay, so the next step we have to do is use all that goodness, all the code that we've decompiled and try and analyze it for leads, potential vulnerabilities that we might want to look for. Okay, so for most people you might be familiar with SAS. It stands for static

analysis security testing. Um, for our purposes we're going to be running some tools. Um, the one we're going to focus on today is going to be SEM grep, but it could be as simple as just string searching, gpping for things um, or more complicated which some of these tools will do, you know, source sync analysis and things like that. Um, some are a jack of all trades like Smap. Some are a bit more focused in. Um, we like Smap because of its ability to you can give it customized rules. Maybe as you pentest more and more of these apps, you you find more and more patterns and you decide to build yourself a custom rule

set that makes it super quick for you to hack all these apps. But in our case, we just use the Java the standard Java rule set which works pretty well um given that it's decompiled Java code. Um, so yeah, s you can run it like this. Um, again, I don't know if these these demos are running, but it's just running this exact command. Smp and the config for Java are in the current directory of our decompiled code for the app that we're currently looking at. So, pretty simple one to run. And then, um, this is an example of what one of the findings or leads might look like from Smra. Um you can see it's got three at least three

parts. Um sometimes they're a bit more wordy, but we've extracted just the most important parts here. Um the first section is the file, the actual path of the file that contains what might be vulnerable code. The second line is the vulnerability that it sus suspects is in that file and then the line of code what actually is vulnerable. So um yeah, we can take a look at this and use this to actually, you know, investigate the code a bit more and cut down our time just in general like takes a bit long to look through every single code file. So it's always nice when you can have some places to start that you're pretty confident might have vulnerabilities in

them. So yeah, um this one in particular is for an XXE vulnerability. So um just a quick recap for those who might not be u might have forgotten or might not be aware, what's XXE? Okay, so got to start off with XML. Everyone's favorite file format. Um, so you can see here this is a very simple XML file. Comprises of some metadata at the top and then some what kind of looks like HTML custom tags, um, spreadsheet tags for here cuz we're working with a spreadsheet for Jira app that expects certain spreadsheet um, template data. Um, it contains a row, one row, which has two columns in it, character and a powerup. Pretty simple. Why might an attacker

care about XML files? It turns out they're pretty powerful. So, they let you upload files if you like into your XML. Um, and yeah, why why not be able to do that? Um, in this case it's just a simple seems like a pretty mundane like powerup file that you might want to display as like an image inside of your spreadsheet. Pretty normal, right? Um, so how might an attacker decide to leverage this? Well, notice that the file is it's coming from uh the file protocol. You might be able to load up something from where the servers hosted at the moment. the local file system of that server. Maybe a file that contains um sensitive content, right? Something

you as an attacker might want to read. Okay, so this is a a pretty simple, more malicious XML file that would allow you to potentially perform an external entity injection. So yeah, here you're just loading up that Etsy password file and then if an attacker were to be able to upload this file to a server, then they might get out the contents of that file which looks something like this for our purposes, right? And that would be enough to kind of show a proof of concept in our case or for a bug bounty program that um yeah, you've been able to exploit this XXE vulnerability. So yeah, let's see how we might be able to

analyze. go back to that sam grep finding we found see if we can trace that in the code how do we actually exploit this in the app itself okay so we want to notice here the spreadsheet service implementation java file that's where we want to start so we'll open up that file which um sits underneath the implementation directory from all of our decompiled code from earlier so open that one up and it looks a little like this so you'll notice um that vulnerable line of code that SEM grip's pointing us towards. It doesn't look like anything stands out in terms of just that line itself when you look at it, but it's what's missing that kind

of matters for XXE in Java at least. Um, and that's those lines of code that are kind of commented out that um, is been kindly included in the demo vulnerable app that probably won't be there in real life, but just for these purposes, um, xxe is generally present when you haven't added specific features enabled into that document builder factory that Java has. So you haven't set features to disallow dock type declarations or general entities and all of that good stuff that generally helps code be secure. So um they're all commented out which is helping us feel a little more confident now that we we might have xxe as long as there's some way for an

attacker to actually upload a file upload an XML file somewhere where this code is being executed. So let's take a look bit sus. um we want to trace this f this function or method name process spreadsheet xml and we can find some usages of that across our code base. Um let's just open one of them up the spreadsheet resource java which if you've had a keen eye here you'll notice that's sitting in the rest directory which is a good sign because it might be an API endpoint that's being exposed. So we can go have a look at that API endpoint. We'll see here there's a /process XML endpoint. It's of the post method type and it's calling our

vulnerable what we think is our vulnerable method, which is good so far. As long as this endpoint's exposed, right? If it's exposed, then this is probably going to be vulnerable to XXE. So, how do we find out if this endpoint's exposed for an Atlassian DC plugin? It's actually pretty easy. The Atlassian plug-in XML file. This file exists for every single marketplace app that's uploaded to um the marketplace. Uh it's developed, it's a metadata file that also contains all the routing information like Jamal mentioned earlier. So if we take a look inside of that, the part we care about is this annotation here that defines the path, the version, and the package where the REST APIs for this plugin are defined.

Now, it's all in the Atlassian docs. Remember these are the plugins that are developed by people on the internet. So the docs for these plugins are really good and you can go and read them and figure out exactly how routes are formed. But for purpose of the presentation um the way it works is that path what's defined in that key the spreadsheet value that forms like the root path for your app's entire rest definition and then it's followed by the version. So spreadsheet 1.0 and then it's followed by those endpoints that are defined in that file we just looked at. So process XML and that will look something like this. The red part is the

part defined by the app developer themsself. And then the Jira rest part that's just something that every API has that's uploaded to you know all the even the Jira like Atlassian own APIs have this Jira rest at the start of them. So that's kind of just the route that you add to all of them and then the stuff defined by the app developer and it's very quite simple then to build your full API path. Okay. So just to recap the files we used uh to do this source to sync analysis we started in the spreadsheet service implementation which contained the vulnerable code. We traced that to a rest endpoint inside of the spreadsheet resource on Java and then we were able

to get the full path definition from the Atlassian plug-in XML file. So yeah just to remember not all app structures will look identical. There might be a couple more jumps in between there for you but the process is the same. Cool. Okay. Some other tips, things that we found testing these plugins that might help you out finding bugs a bit faster. Okay. Authorization annotations. Atlassian has some annotations that we designed for app developers to try and help them make it easier to secure their apps. Um, some of them are authorization related. Um, and in our testing, we found that apps generally either used these everywhere and pretty well and extensively or they just didn't at all.

And you kind of knew in the first like 5 minutes of reading the decompiled source code if like, yeah, this one's going to have some issues or not. Um, not always the case, but it's just a good um like indicator if you're really trying to find bugs first. being able to find these annotations and doing quick quick GP searches to see if like they're used in the right spots, you might be able to get a quick win by just finding some some endpoint that might be, you know, not protected correctly or something like that. Um, the next one is that all plugins have HTML encoding enabled by default. Um, unless the developers decide to use this annotation, the

disable HTML escaping annotation that will like well not like it says it doesn't disable HTML escape. It disables HTML encoding. I don't know why it's named like this. It's old. Jira is old. Um, anyway, it is what it is. But if they've disabled this, you might just have an XSS on your hands as well. So, another quick thing you can grap around for. Um, yeah. And then another thing that we found with some of the apps is that they decided to do client side validation of the app license. So they literally just would gray out buttons in the front end for like premium features that you're only supposed to be able to use with a

paid license. But then if you were to just hit the REST API endpoint that those premium features do all the actual stuff for um that would work fine. So um yeah, we we really care about enforcing this cuz Atlassian gets some of the money from the licenses. So like if you find this, it' be good to tell us cuz we'll make more money. Um yeah. Um >> cool. Okay, so I'll pass it back over to Jamal to show you actually how to test this. Fantastic. Thank you. So, at this point, we've we've identified our plug-in. We have decompiled it and we now have access to the source code. We've done some scanning or some initial

uh sort of hunting and we think we've found a lead. We've found something that we think is interesting. We've done the source to sync. It looks like it should be vulnerable. Now, we need to actually test this, build out a proof of concept so that we can submit that to the bug bounty. So, the first thing that you're going to need to to do that is the Atlassian SDK. The Alassian SDK will make it super simple to be able to download and run Jira or Confluence DC. Uh, and there's today I'm going to show you two different ways to do that. The first way I'm going to show you of doing that is going to be to run our demo vulnerable

plugin that has a slightly different command which makes it super quick to get it spun up and running because we actually give you access to the source code. Then I'm going to show you how to spin up just a standalone version of Jirro or Confluence and you can use that to test out any DC plugin in the marketplace. So the first one here is super simple. Once we give you the resources at the end of this, it's just a GitHub repo. Uh once you clone that, you can cd into the spreadsheets for Jira plug-in directory and just run atlas run. Doing that is going to download Jira DC. It's going to pre-install that plugin for you and it's

going to start that instance on your local host with the plug-in already there to go. So, you can get started very easily after this talk and go and recreate exactly what we've what we've shown you here today. Going forwards, if you want to go and test a different marketplace plugin, one that you don't get given the source code for, you're going to need to go through the process of downloading the jar from the marketplace plugin uh sorry, from the marketplace listing. And while you're there, you're going to want to check what version of data center this plug-in uses. Once you've got that version, you can use the Atlassian SDK using this other command, Atlas run

standalone. Specify the product that you want to run and the version that you need to run, and that will go and spin up a local instance of that product for you to then install the plugin into. So after running that, it'll go away. It'll download about half of the internet. It will take quite a bit of time, but you will be presented with this screen that says, "Hey, uh, Jira is ready on localhost 2990/jira. Uh, and you can go and start to install the plugin. When you go to that link, you'll be presented with a login page. You can use the default credentials admin to log in as the admin, and it is the admin user that has permission to

install plugins to that instance. Once you're in, up the top right, there's the little cog. You can hit that and then hit manage apps. From there, you'll see the list of all of the plugins that are currently installed in the instance. Now, our products actually do come pre-installed with a bunch of plugins. Um, these come with all of them, but we need to upload our own plugin. And here you can use the upload app button and then upload the JAR file from the demo vulnerable plugin or from the JAR file that you downloaded from the marketplace. Upon doing that, it'll show up in the list of installed plugins for your instance. And the quickest way to

actually start interacting with that plugin and actually playing around with the functionality that that plugin introduces is by coming down the bottom and clicking that configure button on the plugin. Clicking that will bring you into the functionality for the app. So for our demo vulnerable plugin, uh we have this functionality in here that says, hey, you can uh load spreadsheets uh and process XML to generate these spreadsheets. So for our demo plugin, we're going to click on that. And in there, we're going to find that functionality that allows you to upload an XML file, potentially a malicious one, and then process that file. In the resources, we also provide a malicious XML file that you can use. And upon that

and processing it, you get the contents of etc password. Uh this is one way of doing it in the UI. Of course, the other way that we could do it is by going through and using curl using that REST endpoint that we discovered earlier. Uh and if we did that, we would uh write a curl command that looks something like this, including the default credentials, the malicious XML, and then putting in that REST endpoint that we built out from our source to sync analysis. And that's going to get you the same results. You'll be presented etc password. So these are some of the benefits of using uh glassbox um sorry white box hacking we call it we call it glass box

internally I don't know why um white box hacking you get access to the source code you can run scanners uh you can actually review that code and do that source to sync analysis that you otherwise can't do when you're doing blackbox testing I'm very good at animating >> this is all Jamal

Thank you.

So, some of you might be thinking, okay, this is this is all very cool, but it's very idealized. You know, what what are the chances of of actually having such a simple vulnerability in a production plugin? Surely our our real production plugins aren't vulnerable to such basic vulnerabilities, right? >> Anyway, um so security improvements, what is Atlassian doing? If you're if you're like paying for enterprise right now, thank you for your money. We just wanted to give you a little bit of confidence that we're doing some things internally apart from testing the apps that are going to help with this. So um we have an app scanner that we've deployed across all of the DC plugins.

Um and it does a range of things. Uh first one is it looks for secrets hardcoded um in plug-in source code. Um and it does this in a very similar way to kind of how we stepped through today. Like it actually does download jars. It decompiles the jars cuz again we don't have the source code and it runs uh SAS scanners against it. Right? So it's kind of doing that in an automated process. It's looking for secrets. um it's looking for vulnerabilities. So um SAS scanners, it's looking for vulnerabilities in the app source code itself. It's looking for vulnerabilities in packages that that the app might be using as well. Um and then also uh

something we've added recently is it looks for any malicious activity. if the app seems to be trying to download and exfiltrate sensitive files or deploy ransomware or something like that, it's also uh it's scanning for that activity in the plugins, too. So, um yeah, we we've got some scanners going. Um but, you know, doesn't stop you still being able to search for some of these vons themselves um with our bug bounty program. Um the other thing that I guess is like you know the way how would you avoid this if you're sitting there like I don't want to be hacked by these plugins and have your own all my all my secrets are stored in confluence you

know it's right it's like my personal journal I don't want that on the internet um how would you prevent that you could also move to cloud like everyone else that's you know all other software companies um but the thing with the cloud apps is we actually run the code for them ourselves and in a sandbox boxed environment and it's a lot more modern and you know um secure. It's a more secure environment for the apps to be running in themselves. So um yeah, if you care about that, cloud's probably the way to go. But you know, this talk did promise bounties. It promised you money, right? So how do you get that money? Um, you could, if you'd like to,

um, do the same methods, the same like decompiling and scanning and vulnerability identification with our actual products if you wanted to, like Jira DC, Confluence DC, the payouts for those are even higher than the marketplace apps. So, if also if you're someone sitting here that's kind of like, you know, I'm kind of ready for a bigger challenge. I'm I'm maybe used to these bigger apps and things like that. You can go and hack those. Um I've put some of the payouts from this was a couple weeks ago, just a screenshot, six grand USD for P1s at the moment for the DC apps. Um which pretty good. You could make probably more money than than the

marketplace apps. But if you're sitting here and you're like, I I just want something easy, um something a bit more simple, smaller things to tackle, um then we have the marketplace apps themselves. Um and yeah, they they also the benefit of the marketplace app testing is because they are designed for random people, third party people to develop. There's a lot of documentation on the internet, probably more than like what even we've read on like how to how to design them, how to write code for them. So you as an attacker can read all of that and get a really good understanding as to like the inner workings of these apps and that will give you like a really good

understanding of then how to hack them, right? So um yeah, it's it's um a really great beginner area to get started in in bug bounty stuff, I think. Um yeah. Um so how do you join these programs? So they are private at the moment, but they're getting opened up to the public and we have this link. the private, but if you go to this link and you just ask to join the specific app. So, say you want to join ScriptRunner for Jira's bug bounty program, just ask Bug Crowd. They'll let you in. Um, so the other cool thing about that is because they're private programs, we haven't gotten many submissions for a lot of them. Um, so

the the surface here for you to go and find potentially like lowhanging fruit is quite high. um especially because there's much more apps on the on these programs than what we've even tested internally so far. So um yeah, you can go to this link, create a ticket. Um here's an example like say this checklist for Jira by hero coders. Um we did this process like on our personal accounts just to make sure it all worked and what it would look like. So you just send bug crowder requests. You say, "Hi, can I just join the hero coders private program? uh I want to find DC Marketplace um plug-in vulnerabilities. And then they in our case they replied

to us the next day not knowing that we work at Atassian. So that's pretty cool. That's good to know. Um yeah and they said like thanks here you go enjoy enjoy hunting. And we got invited within a day. So um super easy to get uh added to these. Um and yeah cuz they're private you don't have you know it's good cuz you don't have all these random people spamming with all these vulnerabilities. Um, so it's good for you. Um, if you're sick of Atlassian by the end of this talk, um, here's some other companies that also have uh, Java software that they use. They also have public bounty programs that you can go and hack and

use the same process of decompiling, code analysis, and testing that we showed you today, um, but in their software. Um, and there's even greater amount of companies that have private programs. Um, so maybe if you can find some bugs here and then you can get invited to those and you'll become a Java expert. Um, cool. So if you're interested in any of the resources that we've been through today, the decompiling script, the vulnerable app, um, the link to submit things to the bounty program, um, where you can download all the Atlassian SDKs and the tools we use, SEM grip, all of that. Scan this QR code and you'll get all those resources. um you know,

promise it's it's a legit QR code. Um I promise. Um cool. So yeah, if you have any questions, you can always email us. We have LinkedIn, too, or you can ask us. We'll be around today as well. Um yeah, thanks everyone. Thank you.

Well, uh, thank you very much for that very entertaining talk and, um, does anyone have any questions? Jamal, Juliana, >> that's it.

>> That's good. >> Quick question. Thanks very much for the talk. It was awesome. Um I just wanted to ask since um Adolescent uses a lot of uh Spring MBC and componentry like that. Have you ever dived into the internals of Spring for example looking at the routing mechanisms and um the authentication componentry and things like that? >> I I haven't specifically. We've we've got quite a few people internally who have done that. We've also um gotten external contractors to do security research into some of those especially some of the older frameworks that Atlassian uses. Obviously, Atlassian's quite an old company. We've got some old software. Uh some of it, you know, doesn't have a lot of really good

documentation. Uh so, no, not not myself personally, but elsewhere in the team, we absolutely have. >> Awesome. And another one over here. Hey, on the um marketplace had like a little icon that said like cloud fortified on those apps. What does that mean? >> Yeah, so it's based on a bunch of parameters like if they're in if they've opted into having a private bounty program then they that's one of the criteria. Um and things like if we know that they are patching their vulnerabilities in the SLOs's that we require them to that will also contribute to that badge. So there's some criteria. I don't know all of them off the top of my head, but I'm sure

it's also online. But yeah, they can app vendors can lose that badge if they aren't adhering to all the requirements. There's also a link in the GitHub that I'm pretty sure lists all the actual security requirements we have of them. Things like, you know, um make sure you have CSRF protections on your endpoints, things like that. So, if they've violated those and haven't fixed them in the time that we've asked them to, they lose that badge. So, it's supposed to give um customers a little bit of confidence that these apps might be a little bit um more secure to install on your instance than others. >> Uh you said this testing was new for the

team. Um what was the catalyst that made the decision to start this testing? And >> uh as candidly as you can be, what was your assessment and the team's assessment of the security posture of the marketplace at the end of it? >> Yeah. Um so yeah the too big to fail program is what we called it. It was definitely off the back of some internal incidents we had um large enterprise customers coming to us and saying basically we got hacked via this app and you know it's not really good enough for us as a company to say well that's not our code so that's not our problem because we facilitate that marketplace at the end of the day right so we want

to do as much as we can given you know what we have to make that more secure um and to you know try and just uplift the general security of of our marketplace platform in general. Um, I would definitely say that there there were more issues in these plugins than um, you know, what we'd anticipate from finding in our usual assessments of our internal program of our internal products and apps. But that's also kind of to be expected, right? Because these vendors are, you know, just people out there trying to make money. They don't have like formal training. A lot of them probably don't have formal training in security, right? But like you expect the

code we write internally to be more secure. So we did find more and we were generally like, you know, there's definitely a lot of work to do here. But I think that the work we're doing with like scanning and things like that is definitely uplifting um that in general. And if you check out our cloud offerings for the apps, it's it has come a long way since DC. Um but yeah, for for this talk at least and um your purposes that we still pay out for DC plugins and it's a great way to learn. So um yeah, I might not recommend going and if you're going to install Jira today, I wouldn't be like go and set up a DC instance.

There's nothing wrong with it, but I'd probably just say cloud's better, but if you want to hack, DC is fun, too. Mine uh is uh I think piggybacking on what you've just mentioned. Thank you both for uh that interesting talk. Uh not around DC per se more on the cloud and uh being an enterprise customer. What are the marketplace apps? you slightly touched on that it runs on a sandbox environment and u understanding that your team uh probably didn't work on but I'm sure you have had shared insight into this um for the cloud version of the marketplace apps um and running on the sandbox environment as a part of a responsibility model is the developer who are pushing the apps

are responsible for any vulnerability mitigation before it gets published to the marketplace apps or Atlassian takes that acknowledgement inhouse and pushes patches or I'm trying to bring a bit of a structure on what Apple rigorous security practices are before uploading into the app store. So something that you mentioned so I'm trying to find a baseline that is that a similar practice in Atlassian for cloud marketplace apps. >> I don't think we do pentest before they go live. I I don't think we do pen tests before apps go live if that's what you're asking for our for our cloud offerings. Um the the cloud offerings have also a lot of scanners and different things going on as well. Um as

well as just a lot more restrictions on the environment in terms of what they're allowed to do. There there's two main versions of of cloud apps that we have. We have connect apps and then we also have the newer forge apps. Um the the forge apps are essentially just like AWS lambdas that are running in in heavily sandboxed environments. uh and we've done we've done a lot of work to make the cloud products a lot more secure and isolated in what they can do but I don't think there's necessarily you know pre pre-published to marketplace pentests that are occurring >> something I will add though is we have for cloud when you install an app it

does like a similar thing to Apple where it tells you all the permissions that the app's asking for in cloud so we'll say like this app's asking to maybe connect to an external URL here's the URL so when you install it, you do get a lot more information about what the app's actually allowed to do. And by default, that that permission set is extremely restrictive. Like it can basically do nothing without your permission. So bit different. >> Fair. Thank you. >> Excellent. Thank you again, Juliana and Jamal.