Anyone tested JIRA with Acunetix?

[Sameera Shaakunthala [inactive]]

After enabling Jelly support, we have decided to run a security scan on our JIRA instance with Acunetix Enterprise web scanner. I would like if anyone has done it before would share your experience and toughts on that.

Even though our major concern is Jelly support, we are keen to study other vulnerabilities as well. One such reported by Acunetix was, source code disclosure in the Dashboard jspa.

I would like to know what kind of scan setup should I use, and are there any known false positives?

Thanks in advance!

[Penny Wyatt (On Leave to July 2021)]

(Although this doesn't address the original question, I'll have to post it as an answer because it's too long for a comment)

Hi Sameera,

I can't speak for how our Support instance is secured as I don't know the details, but some available options are:

• Run Tomcat as a user with that has only limited access to the system (a good idea anyway). Some more information is available at http://confluence.atlassian.com/display/JIRA/Tomcat+security+best+practices . This will limit the actions that can be performed on the system through Jelly.
• Using Apache, limit access to the Jelly screens - including the Jelly runner in Services - to specific known IP addresses. http://confluence.atlassian.com/display/JIRA/Using+Apache+to+Limit+Access+to+the+JIRA+Administration+Interface This will make it much harder for an external attacker to have the ability to run Jelly if they have gained access to a sysadmin account.
• Ensure that XSRF protection is enabled, as it is by default (jira.xsrf.enabled=true in jira-application.properties). This will prevent an attacker from using an XSRF attack to trick your sysadmin into running malicious Jelly code.
• Ensure that WebSudo is enabled, as it is by default (jira.websudo.is.disabled = false in jira-application.properties). This will limit your exposure if the sysadmin account is compromised.

Cheers,

Penny

[Sameera Shaakunthala [inactive]]

Hi Penny,

Thanks a lot for your helpful answer.

Together with the poins included here, http://forums.atlassian.com/message.jspa?messageID=257370954#257370954 , I think we'll be able to secure our JIRA environment.

Cheers! :)

[Sameera Shaakunthala [inactive]]

Hi Penny,

Thanks for the reply.

Since I've read that Atlassian Support also uses Jelly Escalation to automate transitions and commenting, I would like to ask if you follow any security precautions to mitigate concerns with that could specifically arise with Jelly.

One I think is to avoid running Tomcat as root. What else can you recommend?

Regards,

[Sameera Shaakunthala [inactive]]

Hi Penny,

Thanks for the reply. According to your reply, what I understand is if the hosting environment and JIRA instance are separately managed by two business entities, there is a risk since if the JIRA administration account is compromized so the hosting environment can be.

If I am the JIRA administrator and I am the person who manages the server environment there should be no risk enabling Jelly.

Is my understanding correct?

Thanks!

[Penny Wyatt (On Leave to July 2021)]

I'm curious - are you running the scan in order to find out why Jelly is a security concern? If so, I can tell you straight out why - it's because it allows a sysadmin to run arbitrary code on the server as the Tomcat user. Hence, it is a privilege escalation vector.