Imavex Server Database Breach and Dump - Cursory Analysis     2021/08/25
by Ami Sapphire

Updated: 2021/08/29

[0828]
Added data exposure - located on table named 'Site'
Corrected data exposure regarding table 'NewsLetterList'
Added new notice and identifying the possible compromise vector

[0829]
Updated last notice with Port 21 wide open to the world
Added Notes and Conclusion


NOTICE: This is merely a cursory write-up on the database's data itself, as it
has not been extensively analyzed. The introduction would need a bit of polish
as well.



Introduction

The August 15, 2021 imavex.com client and administrator data breach is a
fundamental lesson in practicing basic technical security. This was originally
thought to have been a secureserver.tv-only breach (they only started existing
on May 16, 2020), but the database having data stemming from 2009/2010 says
otherwise.


Main issue found by Kiwi Farms users back on June 13, 2021 were the following:

Ports 22 (SSH) and 3306 (MySQL and its variants) were open.
Looking at secureserver.tv's claims (military grade encryption), they just use
  a Let's Encrypt website cert, to quote: "includes using 2048-bit RSA, an
  algorithm dangerously close to being broken."


Main issues found by the database dumper on August 15-21, 2021 (quoted
verbatim):

The PHP for all of the sites is likely stolen from a template and is incredibly
  badly written
They stored the data from all of these sites in a single database on a server
  with a weak password
Imavex has not notified anyone that everything on their servers has been stolen
  yet (to my knowledge)
Very likely that someone else has breached before and skimmed full credit card
  info


Main issue noticed by me on August 24, 2021 were the following:

Services and sub-services are all Wordpress website layouts. This is combined
  with the age of the database and server setup; it is an issue.
Vector may either be an outdated plugin within secureserver.tv or bruteforcing
  SSH auth (as Port 22 is still open as of this document).


Main issue noticed by me on August 28, 2021 was the following:

FTP server login info was exposed since the breach (and Port 21 to that server
is still open as of this document update - 2021/08/29), and upon seeing the
table named 'Site', this may have been the original vector; assuming the
database is along with the usual client info AND assuming there were unlimited
login attempts set on the server. From there, you can grab the database info
from one of the many Wordpress installs and make a new one. There were recent
installs, some old ones had very obvious fake names as Client Names as well as
recent ones. To be honest, I think the server was compromised for years.



Database analysis

Database name: business
Tables: too many to list


Analyzed tables so far:

FormSubmission - Contact info box for various sites/sub-service within the
Imavex ecosystem. Survey, inquiries, comments, etc. are stored there.
Affected data: First name, Last name, e-mail address, phone number, recorded
IP address.

NewsletterList - List for subscribing to newsletters on sites within the Imavex
ecosystem.
Affected data: First name, Last name, e-mail address

Orders - Customer data for orders placed on various sites within the Imavex
ecosystem.
Affected data: First name, Last name, physical address, e-mail address, phone
number, old package tracking number.

Site - Client (customer) data for partial site configuration of various sites
within the Imavex ecosystem.
Affected data: Client name, phone number, fax number, e-mail address, physical
address, client Stripe API keys (both public and private), Imavex FTP login
info (plaintext).

Transaction - Subscription tokens for services paid on sites hosted within the
Imavex ecosystem.
Affected data: old subscription tokens that stretch back to September 2010.

User - Service data, subscription data, and account data for websites that are
within the Imavex ecosystem. (Do NOT ask why this was severely co-mingled.)
Interestingly, this was not the largest table size-wise (FormSubmission is that
one so far).
Affected data: First name, Last name, e-mail address, phone number, physical
address, username, password, IP address, last 4-digit CC info, CC expiry info
(and much more).
Notes: Not much was gleaned otherwise, as this table has ~224500 records and an
untold amount of columns, and can easily crash the user's viewer without proper
filtering.

UserAddress - Physical address data for an unknown site/sub-service within the
Imavex ecosystem.
Affected data: physical address (obviously).


There are more tables in the leaked database I haven't looked through more
extensively, mainly because I haven't a dedicated test box yet.



Notes

Server FTP Username and Password are weak
Server FTP Username and Password were stored in the database as plaintext
Sensitive data stored in the database
  * private Stripe API keys
  * partial credit card info
  * credit card expiry info
  * physical address
  * real names
All resources (client database and website layout) were stored on one server
Client data was all piled up in one database



Conclusion

Firewall ports 22, 3306 as restricted to allowed IP addresses
  * 22 - SSH
  * 3306 - MySQL
Do not use non-secure FTP
  * Result: possibly close port 21, depending on secure FTP setup
Use a strong password for the FTP credential
Do not store FTP credentials in the database, especially as plaintext
Do not store certain PII in the database
  * CC info should be hashed and passed securely through to destination
  * Do not store private Stripe API keys in the database
Client resources should be on a server different from the database
Separate client database resources to their own databases
  * Otherwise it becomes an extremely unmanageable mess