Determining whether your Jira instance has been compromised by CVE-2019-11581
This document provides guidance you may use in your security assessment, but cannot guarantee that your system has not been compromised. We strongly advise you to consult your IT Security team for further guidance.
Access logs may have been tampered, rotated or deleted, so this is not an exhaustive approach. Where applicable, compare your Jira instance’s logs with other sources such as those from the reverse proxy and load balancer.
Command-line instructions given in this document are for Linux environments. Equivalent commands can be used in Windows environments.
IP addresses used in the examples below are just example IP addresses.
The steps below focus on the “Contact Administrators” form as an example, but you can adapt the same steps to examine the
SendBulkMailendpoint.
- Your Jira instance is not vulnerable if the mitigation steps have been followed exactly, with all the relevant endpoints blocked.
- Your Jira instance is not externally vulnerable if it's not accessible through the Internet.
- For more information about the vulnerability, how to mitigate it on your Jira instance, and what versions to upgrade to, see the full advisory.
Tracing form submissions and emails
When the “Contact Administrators” form is legitimately used, each submission can be traced back to an email. Conversely, exploiting the bug may result in an email, but with a strange email subject or body (such as « 2 »). This allows us to identify suspicious activity on the “Contact Administrators” form.
What do I need to know to start checking this?
The “Contact Site Administrators” form is submitted through a POST to
/<context_path>/secure/ContactAdministrators.jspa.The “Send email” form is only accessible to admins and submitted through a POST to
/<context_path>/secure/admin/SendBulkMail.jspa.The Tomcat access log valve is enabled by default in server.xml so this information is available in the access logs under
<JIRA_INSTALL>/logs/access_log.YYYY-MM-DD.If the form was legitimately used, each submission will be traced back to an email:
to the Jira administrators if the “Contact Administrators” form was used.
the role/group chosen if the SendBulkMail endpoint was used.
Steps
Search for all timestamps of POSTs to
/<context_path/secure/ContactAdministrators.jspain the access log files:grep '"POST /<context_path>/secure/ContactAdministrators!default.jspa' access_log.* | grep -o "\[.*\]" [12/Jun/2019:09:22:31 +0200] [10/Jul/2019:10:13:37 +0200] [10/Jul/2019:10:14:11 +0200]Cross-check the timestamps with the emails received by the Jira admins.
Cross-check the timestamps with processing errors on your SMTP server.
If you have subject line logging active in your SMTP server, inspect the subjects of the emails sent to the admins around the times extracted above for any suspicious content (subjects with numbers or several special characters, empty subjects, …)
Review your SMTP logs for any blocking errors based on email content. For example, the Google SMTP servers block suspicious emails and show this message:
The error was: com.sun.mail.smtp.SMTPSendFailedException: 552-5.7.0 This message was blocked because its content presents a potential 552-5.7.0 security issue. Please visit 552-5.7.0 https://support.google.com/mail/?p=BlockedMessage to review our 552 5.7.0 message content and attachment content guidelines. q7sm17997992wrx.6 - gsmtp
Tracing the source IPs of suspicious requests
Jira’s access logs contain the source IPs of the requests. You can analyze this data and look carefully for IPs originating outside of your corporate network or VPN.
Steps
Extract all the source IPs of POSTs to
/<context_path/secure/ContactAdministrators.jspain the access log files, and save them in a text file.grep '"POST /<context_path>/secure/ContactAdministrators!default.jspa' access_log.* | cut -d' ' -f1 | grep '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | grep -vE '^(192\.168|10\.|172\.1[6789]\.|172\.2[0-9]\.|172\.3[01]\.)' | sort -u 192.0.2.65 198.51.100.24 198.51.100.89 203.0.113.134 203.0.113.211You can Regex search at the command line, e.g.
grep -vE '^(192.168|10.|172.1[6789].|172.2[0-9].|172.3[01].)', to exclude private IPs. You can also adapt this command to exclude known corporate and VPN IP addresses.
Review the resulting list for suspicious IP addresses.
Examining request counts
Per IP
Many POST requests to the form from the same IP address can indicate suspicious activity. You can generate a sorted count of requests per IP as follows:
grep '"POST /<context_path>/secure/ContactAdministrators!default.jspa' access_log.* | cut -d' ' -f1 | grep '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | grep -vE '^(192\.168|10\.|172\.1[6789]\.|172\.2[0-9]\.|172\.3[01]\.)' | sort | uniq -c | sort -n
1 192.0.2.65
1 198.51.100.24
1 198.51.100.89
35 203.0.113.134
1 203.0.113.211Per minute
Alternately, you can search as follows to find the time periods with the most activity:
grep '"POST /<context_path>/secure/ContactAdministrators!default.jspa' access_log.* | grep -o "\[.*\]" | cut -d\[ -f2 | cut -d: -f1,2,3 | uniq -c
1 10/Jul/2019:08:30
1 10/Jul/2019:09:30
26 10/Jul/2019:10:14
1 10/Jul/2019:10:30
1 10/Jul/2019:12:10