According to a company blog post, the attack first accessed Cloudflare’s systems for reconnaissance from 14 to 17 November and accessed a number of systems, including the company’s “internal wiki (which uses Atlassian Confluence) and our bug database (Atlassian Jira)”.
The attackers reportedly returned days later on 20 and 21 November, likely to verify that they still had a connection.
Cloudflare said that it failed to rotate those connections but that as of 24 November, all connections that the threat actor had made were terminated.
Impact
While the Cloudflare Jira and Bitbucket systems were accessed, no customer data was breached.
Details
An attacker used credentials that were previously stolen in an attack on Okta back in October 2023. These credentials were still valid and allowed the attacker to gain access.
So less of a “hack” and more of a “logged on”.
The creds were used to access the Jira server and then jump to Bitbucket to access source code.
Communication
Cloudflare released a statement on their blog, which is linked above under Official Statements
Opinion
The biggest issue in this incident is the credentials that were used to access Cloudflare’s systems. These credentials had been stolen in an earlier Okta breach a month earlier in October 2023.
While Cloudflare knew about that breach and had rotated stolen credentials, they left one out of the rotation.
According to Cloudflare this not rotated because “The one service token and three accounts were not rotated because mistakenly it was believed they were unused,”.
Which makes no sense because:
- All credentials should have been rotated, regardless of use
- Why are there credentials in their systems that are not in use?