Last week, Atlassian published an advisory for CVE-2023-22518. The vulnerability is a trivial to exploit authentication bypass vulnerability [1]. Atlassian emphasized the importance of the advisory with a quote from its CISO: "There are no reports of active exploitation at this time; customers must take immediate action to protect their instances." On Friday, Atlassian confirmed that attackers are actively exploiting the vulnerability.

The vulnerability is rated with a CVSS score of 9.1. Three different URLs are affected according to the advisory:

/json/setup-restore.action
/json/setup-restore-local.action
/json/setup-restore-progress.action

Looking at different published exploits, the other common denominator is the addition of a, in hindsight, obvious header:

 "X-Atlassian-Token": "no-check",

One of the exploits is also hitting this URL

/rest/api/user?username=

I went back through our data to see how much exploitation we see for these URLs. We started seeing the first attempts on November 2nd (Thursday), just as Atlassian reported seeing these exploits being used against customers.

The first request detected came in on Nov 2nd from %%IP:206.189.179.132%%. The IP is a Digital Ocean IP and pretty quiet, but no stranger to our logs. We saw two requests back in March for /t4 (WebLogic?) [2]. 

The total request sent by this IP on November 2nd:

GET /json/setup-restore.action HTTP/1.1
Host: [redacted]:8090
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2919.83 Safari/537.36
Connection: close
Accept: */*
Accept-Language: en
Accept-Encoding: gzip

This request is still missing the "X-Atlassian-Token" header. It may just be an attempt to collect targets. The host this was sent to is interestingly responding to a hostname related to a fictitious medical organization, and this particular hostname was used in the request. The source IP also attempted TLS connections and first sent a simple "HEAD" request for the index page to confirm connectivity.

Other early IPs scanning for the vulnerability:

103.207.14.235 Indian IP address with no prior history.
103.207.14.196 Indian IP address with no previous record.
104.238.130.6 US-based cloud provider (vultr.com)
99.245.96.12 Canadian Consumer IP address (Rogers) exposing a router login, according to Shodan.

the /rest/api/user URL, while unrelated to CVE-2023-22518, had some interesting results:

/rest/api/user?username=pleasepatch
/rest/api/user?username=systemadm.bkp
/rest/api/user?username=hacked
/rest/api/user?username=Atlassian_Guest
/rest/api/user?username=pleasepatchconcac
/rest/api/user?username=systemuser
/rest/api/user?username=ConUAdmin
/rest/api/user?username=favouser
/rest/api/user?username=adminstartor 
/rest/api/user?username=trader
/rest/api/user?username=test09
/rest/api/user?username=pleasepatchlj
/rest/api/user?username=zerolove
/rest/api/user?username=root

Some of them appear to be attempts to notify administrators of unpatched Atlassian instances. These scans started on October 13th and are likely related to an earlier Atlassian vulnerability.

[1] https://jira.atlassian.com/browse/CONFSERVER-93142
[2] https://isc.sans.edu/weblogs/sourcedetails.html?date=2023-03-21&ip=206.189.179.132

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|