Public Statement on ClickASnap’s data breach

What happened:

At around 05:00 (GMT) on 24th September 2022, one of ClickASnap’s databases was breached during a malicious hacking attack.

What was released:

User emails were stolen from one of our databases and released. No other personally identifying information was stored or stolen. At ClickASnap we have always prided ourselves on our promise to not harvest or sell your data.

Why did this happen?

A page titled ‘info.php’, which contained login credentials to our servers was left open on a public IP address. These credentials were then used to access a database, which had also been left open to the public.

This was a matter of gross negligence by our previous developers (Marc Thornton and Jim Ready of Skylab Group Limited – AKA MJC Digital and Digital Shift), who as many of you know, failed to deliver on the new website which was originally due to be released in August 2021.

Will this happen again?

Although it is impossible to guarantee that any website will be entirely safe from hackers, we can guarantee that the build of the new ClickASnap website is handled by competent developers who handle NHS (UK health services) and military contracts as well as plethora of other services. This new website will be built to best practice standards as a minimum by Blue Frontier. Alongside this, the company is also implementing ISO 27001 as a base standard for our cyber security, to ensure the correct processes are in place to prevent this from happening again and to keep our members safe.

Furthermore, we will always continue to keep to our promise to not farm or harvest your data. None of your payment data or personally identifying data will ever be held by us. This means that in any potential hacking attempt against us, your personal data is safe.

Blue Frontiers findings were as follows:

The main points of the breach are:

  • The production database was located on a publicly accessible database instance.
  • A php file containing the phpinfo() function allowing environment variables to be displayed was available in the production web container. This would allow anyone who input the correct URL to see the database connection and authentication details.

Given that the production database was located on a publicly accessible database instance. Any person who obtained the connection details via the php script/URL would have been able to connect to the database instance and access/modify the records.

The following information was found via a post on a hacking forum:

On the above website ‘breached’ you can find a statement by the hacker:

  • The website was breached by @thrax — “I was able to breach the database through leaked Amazon RDS credentials”. The website was also defaced as a result.

Based on the above information, this appears to be the most likely cause of the breach/defacement. We were not able to find evidence of other vectors of attack.

Share this post

Leave a Reply

Your email address will not be published.

Stories

More posts from our blog!

We are Hiring!

About the job Are you a multi-talented marketing professional with a passion for tackling a wide variety digital marketing challenges? Do you have experience of

Read More

Looking for something?

Search our blog

Blog

Choose from our categories

Categories

Get in Touch