Update (May 11): The flaw discussed here has now been fixed. Jira Support Desk has been updated to no longer allow non-administrators to add new users to a ticket via email or in bulk, according to an Atlassian spokeswomen who emailed Quartz.
Software companies are still being exploited by decades old hacking strategies. Yesterday, a easily preventable fault in a popular online help system was used to unintentionally flood the inboxes of hundreds of email accounts. Even the most highly regarded 21st century software providers can leave themselves susceptible to 20th century hacks.
Atlasssian, a once venture-backed but now $4.5 billion publicly-traded software provider, is responsible for the fault.
The hack, which affected 500 people, began with a message to the help system from a person named Andrei Bourdine soliciting feedback for a website called SlashPixels. The thread immediately devolved into a series of messages from users asking to be unsubscribed. Bourdine did not respond to Quartz’s request for comment.
Quickly it became a roll-call of “unsubscribe” requests.
Those unsubscribe messages only made matters worse. Every reply was sent to every other person added to the thread, and didn’t do anything to adjust the sender’s subscription to the thread.
The flawed product is JIRA Service Desk (not to be confused with the company’s flagship product JIRA) which was built to help companies facilitate customer service through a digital ticketing system. It is intended to allow a company to message back and forth with customers to help them identify flaws and provide guidance.
In all, more than 100 messages were sent to the thread and seemingly automatically created other threads when replies took a certain format. Those messages include ones apparently sent by a sort of auto responder, leading to a flood of echoes on top of the flood of messages.
Atlassian told Quartz that “JIRA Service Desk is designed to share information within a trusted network,” in an emailed statement “We’re exploring ways to address this issue and are committed to preventing the abuse of our services.” Ironically, Atlassian may have been slow to respond to the hack because it was unable to view the offending ticket due to a lack of permission to see items in its customers’ accounts—in most circumstances an admirable policy.
The ticket was created on the portal used by RebelMouse a “publishing platform built and optimized for social media distribution” according to its CEO. A product manager at RebelMouse, Torsten Sandor, said in an email, “Our JIRA setup failed us, and we are working on a fix.”
Sandor did not respond to questions about if or how the RebelMouse account was compromised nor if RebelMouse’s JIRA Service Desk preferences had been customized to allow anyone to create a ticket and subscribe others.
It would appear that Bourdine was able to create a ticket on RebelMouse’s portal of Atlassian’s software and then subscribe 496 other email addresses to the thread.
The ticket now appears to be deleted, so the flood of email may be over. But the circumstances were all the more frustrating for people caught on the thread because there was no easy way to unsubscribe.
All of this could have been prevented if Atlasssian confirmed that email addresses entered into its ticketing system were being properly subscribed or if the company allowed for simpler ways to unsubscribe from tickets.
However it did not require any confirmation from the people behind the email addresses added to the ticket that they wanted to be notified of the issue or that they wished to receive updates via email.
These kinds of confirmations are industry best practice. Websites large and small use them to combat spam and harassment techniques that developed in some of the earliest days of the web.
The emails sent by Atlassian’s servers to alert people of JIRA Service Desk ticket updates do not contain a link to unsubscribe from notifications nor to remove the recipient from the the ticket.
In fact, somehow JIRA Service Desk accounts were created for all of the email address added to the ticket without the email account holder’s permission. To change their notification preferences—on the account they didn’t know they even had—people on the thread are able to log into the service by resetting this automatically created account’s password.
Once logged it is possible to unsubscribe from requests, but that didn’t end up working reliably.
It was also possible change where notification emails are sent, including addresses to accounts that do not belong to the user or accounts that do not actually exist, since Atlassian doesn’t appear to confirm email addresses before they are added into the messaging system.
It is unclear where this list of email addresses came from or why they are associated with each other. Many on the thread appear to be graphic designers or people associated with the profession.
This story was updated with a statement from Atlassian.