Security Addendum 2010-04-16 - Determining if your public JIRA instance has been compromised

On this page:

Overview

In April 2010, some public JIRA sites were attacked via security vulnerabilities in JIRA. This document provides instructions on how to determine if your JIRA instance has been compromised. Please refer to the JIRA Security Advisory 2010-04-16 for more information about these vulnerabilities and patching your JIRA instances.

The attacker would require web access to your JIRA instance. If your JIRA instance is behind a firewall and you are maintaining usual security measures to restrict external access to this JIRA instance (for example, removing user accounts of individuals who no longer require access to it), then there is low risk of your JIRA instance being attacked.

If your JIRA instance was compromised, the attacker would have initially gained administrative privileges via an XSS attack or by successfully discovering a JIRA administrator's password. Once the system is compromised, the attacker would be able to read and modify files and database information.

To determine if your JIRA instance has been compromised, please do the following:

1. Check the server running JIRA for recently modified files
2. Check your access logs for the attack vectors
3. Verify the integrity of existing JIRA administrator accounts

1. Check for modified files on the server

Running the following command in UNIX-based systems (for example, Linux and Mac OS X) will show all files modified in the last fifteen days:

find /path/to/JIRA -mtime -15

On Windows, you can search for files using the graphical search utility:

Check for any files in the JIRA installation that have not been modified by you or one of your known administrators within this time period.

The files which are likely to have been affected by these attacks include the following:

• a modified WEB-INF/web.xml file, such as the addition of new servlet filters
• newly added or modified JAR files in WEB-INF/lib/
• newly added JSP files at various places inside the web application
• newly added GIF files in /images/

If you need more information, please contact Atlassian support using the Get Support link below.

2. Check your access logs for the attack vectors

JIRA does not keep access logs unless you have manually configured it. However, many web servers like Apache HTTPD are set up to capture access logs by default. If your web server or application server or JIRA has been configured to generate access logs, you can use these logs to check for the access patterns below.

To check for patterns in access logs on Unix-based systems (e.g. Linux, Mac OS X), you can use the grep tool on one or more files:

grep 'search-string' *.log

To check for patterns in access logs on Windows, you can use the findstr tool on the command line:

findstr "search-string" *.log

2.1 Administrative setting changes from unknown IP addresses

The attacker may have modified the attachment directory configured in the JIRA administration area. To check for access to the vulnerable settings pages, search the access logs for:

• secure/admin/EditAttachmentSettings
• secure/admin/IndexReIndex
• secure/admin/EditService
• secure/admin/XmlBackup
• secure/admin/XmlRestore
• secure/admin/JiraSupportRequest

Below is an example of access logs which contain changes to the attachment settings on a JIRA instance.

...
...
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "GET /secure/admin/jira/EditAttachmentSettings!default.jspa HTTP/1.1" 200 7259 "-" "-" 518092
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "POST /secure/admin/jira/EditAttachmentSettings.jspa HTTP/1.1" 302 20 "-" "-" 50425
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "GET /secure/admin/jira/EditAttachmentSettings!default.jspa HTTP/1.1" 200 7288 "-" "-" 53665
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "POST /secure/admin/jira/EditAttachmentSettings.jspa HTTP/1.1" 302 20 "-" "-" 13190
...
...

If you need more information, please contact Atlassian support using the Get Support link below.

2.2 Check for an unusually large number of login attempts

It is possible that administrative access may have been gained via a brute-force attack. To get a list of all login attempts, search the access logs for:

• /login.jsp

Evidence of such an attack will look like this in the access logs where the timestamps between requests are very close together and the number of attempts is extremely high:

...
...
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "POST /login.jsp HTTP/1.1" 200 5547 "-" "-" 126482
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "POST /login.jsp HTTP/1.1" 200 5542 "-" "-" 119285
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "POST /login.jsp HTTP/1.1" 200 5547 "-" "-" 119801
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "POST /login.jsp HTTP/1.1" 200 5557 "-" "-" 117931
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "POST /login.jsp HTTP/1.1" 200 5546 "-" "-" 116953
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "POST /login.jsp HTTP/1.1" 200 5547 "-" "-" 125371
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "POST /login.jsp HTTP/1.1" 200 5549 "-" "-" 117773
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "POST /login.jsp HTTP/1.1" 200 5548 "-" "-" 119681
xxx.xxx.xxx.xxx - - [xx/Apr/2010:00:00:00 -0500] "POST /login.jsp HTTP/1.1" 200 5545 "-" "-" 126654
...
...

If you need more information, please contact Atlassian support using the Get Support link below.

2.3 Cross-Site Scripting attacks

Cross-Site Scripting (XSS) attacks were attempted on sites at Apache. These XSS attacks were attempts to steal other users' session cookies or other credentials, by sending the credentials back to the attacker's own web server.

For more information about XSS attacks, please refer to the relevant articles on the cgisecurity, CERT websites.

If XSS attacks have occurred on your JIRA instance, the following strings may be present in your access logs:

• <script
• %3Cscript
• </script>
• document.cookie
• document.write
• window.location

More advanced patterns to identify XSS requests (and those of other injection-type attacks) from access logs can be found on Symantec's Detection of SQL Injection and Cross-site Scripting Attacks.

If you need more information, please contact Atlassian support using the Get Support link below.

3. Verify the integrity of existing JIRA administrator accounts

The attacker could gain administration access via a brute-force attack to determine an administrator's password. Once access is gained, a number of different actions could be performed, including:

• The addition of a new administrative account
  or
• Modification of an existing user account's email address or password and subsequent use of that account

You should check that all emails are valid and that all administrator accounts are known users.

If you need more information, please contact Atlassian support using the Get Support link below.

Additional Resources

• Apache Blog
• cgisecurity article
• CERT article

If you suspect that your JIRA instance has been compromised

If you suspect your JIRA instance has been compromised we strongly recommend involving your local security team for further investigation. Atlassian is happy to review your customer log files and provide an opinion on whether your system has been compromised. To request this please file a support request via http://support.atlassian.com/.

Please note, however, that the final determination of whether your JIRA instance has been compromised and what actions to take as a result remains with you the customer.

If it is determined that your JIRA instance has been compromised, our advice is to immediately shut down JIRA and disconnect the server from the network/Internet. Also, you may want to immediately shut down any other systems which potentially share a userbase or have common username/password combinations with the compromised system. Do not apply the patch described in JIRA Security Advisory 2010-04-16 until you have worked with your local security team to identify the scope of the breach and your recovery options.