Starting in the evening on Thursday 8 March (UTC), several instances with customer public signup switched on have been flooded with spam accounts.

On many of these instances, the spam accounts appear to be part of a systematic phishing attack against a list of @mail.ru email addresses, where a message inviting the victim to collect a prize by following a http://telegra.ph link is sent through the account verification email feature by way of the “full name” field.

Possible solutions to this problem might involve improving the honeypot strategy (it’s currently very simple and personally I’m surprised it lasted as long as it did), imposing a CAPTCHA on some or all customer signups, or some other solution or combination of them, but we’ll make a solution available as soon as we can.

Workaround (JSD 3.2+)

Switch the honeypot off

Switching the honeypot off will revert your instance to the old behaviour, where a CAPTCHA is imposed on the customer public signup form whenever it’s imposed on the JIRA counterpart.

1. Switch the CAPTCHA on signup setting on for the instance
2. Go to the dark feature settings page (<context>/secure/SiteDarkFeatures!default.jspa)
3. Add the following feature flag: sd.portal.help.center.customer.signup.secondary.email.disabled

A fix that achieves this will be released with the next version of JSD 3.9 in accordance with our release schedule.

Switch to JIRA’s public signup form

If your customers don’t need to be able to raise their first request over email, and you can find a way to tell potential customers to use JIRA’s signup form (<context>/secure/Signup!default.jspa), such as through the name and logo of your help center, you can effectively allow public signup with a CAPTCHA in three steps:

1. Switch customer public signup off for all projects in JSD’s global configuration
2. On the Applications page, click Set defaults for new users and clear all of the boxes
3. Switch the CAPTCHA on signup and traditional public signup settings on for the instance

Configuring your instance not to give new users access to any of the JIRA applications is important, because users that have access to an application will consume a seat for that application (including JIRA Core seats, when access is given to it but no others). Customers who only need to use the customer portal do not need to be given access to JIRA Service Desk.

Workaround (JSD 3.10+)

Affected instances that are on JSD 3.10 or newer can mitigate the attack by switching the account verification email feature off (please note that the setting is only visible when public signup is switched on at the project level). While this won’t prevent the creation of spam accounts, doing so will no longer be enough to make the instance send mail to the given address.

Cleaning up the spam (internal directory)

Notice - you will need to stop JIRA before performing actual deletions (step 5 below)
1) Back up your instance before directly connecting to your database
2) Find a SELECT query for cwd_user that best matches the spam, such as:

SELECT id, display_name, email_address FROM cwd_user
WHERE display_name LIKE '%http://telegra.ph/%'
AND email_address LIKE '%@mail.ru';

3) Create a temporary table to keep track of the accounts you want to delete:

CREATE [PRIVATE] TEMPORARY TABLE list_of_spam_accounts AS <your SELECT query from step #2>;

4) Review your list of accounts and issue SQL queries to amend it as necessary
5) STOP JIRA
6)* Switch autocommit off for the remainder of your session and issue a BEGIN;
Issue the following queries to delete the accounts on your list:

DELETE FROM app_user WHERE id IN (SELECT id FROM list_of_spam_accounts);
DELETE FROM cwd_membership WHERE child_id IN (SELECT id FROM list_of_spam_accounts);
DELETE FROM cwd_user_attributes WHERE id IN (SELECT id FROM list_of_spam_accounts);
DELETE FROM cwd_user WHERE id IN (SELECT id FROM list_of_spam_accounts);

7) Commit the transaction with your DELETE queries by issuing a COMMIT;

8) Start and re-index JIRAPlease

*To deactivate the accounts rather than delete them, replace the queries in step #6 with this query:

UPDATE cwd_user SET active = 0 WHERE id IN (SELECT id FROM list_of_spam_accounts);

9) You may need to apply the workaround from :

• https://confluence.atlassian.com/jirakb/user-exists-but-has-no-unique-key-mapping-user-xxx-has-no-unique-key-mapping-the-jira-server-was-contacted-but-has-returned-an-error-response-373261121.html