PGqtwrbp

1I hacked SlickWraps. This is how.
2
3Follow
4
5Feb 21 · 10 min read
6
7...
8
9In June of 2019, SlickWraps Inc., a Kansas-based phone accessories company, sold precisely 10,744 orders through their eCommerce platform.
10
11They collected $199,128.51 USD in revenue.
12
13They accepted $1,314.80 USD in refunds.
14
15They authorized 560 returns.
16
17I have this data this because I am a cybersecurity analyst… and SlickWraps has abysmal cybersecurity.
18
19Today, I will tell you the story of why their vulnerabilities are being exposed.
20
21Before I begin, it is important to note that I have exhausted all other options.
22
23I notified SlickWraps multiple times of their egregious security vulnerabilities which (still) exist on their Magento-based eCommerce platform.
24
25They had no interest in accepting security advice from me. They simply blocked and ignored me.
26
27Their time is now up.
28
29Let’s start at the beginning.
30
31...
32
33In June of 2019, while perusing Twitter, I came across a public allegation (link) made against SlickWraps regarding the deceptive “False Advertising” of their prices and never-ending sales.
34
35Scrolling through the thread, I found further allegations that SlickWraps leveraged automated user accounts (“bots”) for self-promotion.
36
37Littered through the thread were even more (potentially unsubstantiated) allegations that SlickWraps engages in a wide array of unscrupulous business activities:
38
39•“Stealing” from artists who produce designs for their products (link)
40
41•Extorting their customers (link)
42
43•Holding fraudulent giveaways (link)
44
45•Providing poor service (link)
46
47•Suppressing customer grievances (link)
48
49•Spamming on Reddit (link)
50
51•Accusing competitors of paedophilia (link)
52
53While the allegations against SlickWraps piqued my interest in a theatrical sense, I had no particular curiosities about them from the perspective of a security analyst.
54
55That changed in January of 2020, when a supposed “hacker” gained access to the SlickWraps Zendesk customer support platform and sent a mass-email to SlickWraps customers, alleging that the entire business was a scam.
56
57This was indeed a claim I felt equipped to investigate for myself.
58
59At this juncture, if you’re a technical reader and would like to skip straight to the SlickWraps Penetration Test Results, click here. Otherwise, let’s continue in layman’s terms.
60
61After a few dead-ends, my investigation led me to the SlickWraps phone case customization area of their website (link).
62
63This page contained an inexcusable vulnerability: anyone with the right toolkit could upload any file to any location in the highest directory on their server (i.e. the “web root”).
64
65From there, a simple .htaccess file was uploaded, enabling a path to:
66
67- Resumes of current and past SlickWraps employees (incl. selfies, email addresses, home addresses, phone numbers, etc.)
68
69- 9GB of personal customer photos, uploaded via the SlickWraps phone case customization tool (incl. backups of customer-uploaded pornography).
70
71Due to SlickWraps’ blatant disregard for any semblance of operational security, I was effortlessly able to achieve remote code execution and unlock the ability to execute shell commands.
72
73For the uninitiated, the ability to execute shell commands is akin to obtaining a skeleton key. It unlocks everything.
74
75After a quick decryption of their local config file, I found the proper credentials to access their entire 17GB MySQL database. This included:
76
77•All SlickWraps admin account details, including password hashes
78
79•All current and historical SlickWraps customer billing addresses
80
81•All current and historical SlickWraps customer shipping addresses
82
83•All current and historical SlickWraps customer email addresses
84
85•All current and historical SlickWraps customer phone numbers
86
87•All current and historical SlickWraps customer transaction history
88
89•Current SlickWraps API credentials for MadMimi (their email marketing service provider)
90
91•Current SlickWraps API credentials for PayPal Payments Pro (one of their credit card and payment handlers)
92
93•Current SlickWraps API credentials for Braintree (another one of their credit card and payment handlers)
94
95•Current SlickWraps API credentials for ShipHero (their warehouse management system)
96
97•Current SlickWraps API credentials for Zendesk (their customer service platform)
98
99•Current SlickWraps API credentials for Facebook (yes… their official brand Facebook account)
100
101•Current SlickWraps API credentials for Twitter (again — yes… their official brand Twitter account)
102
103•Current SlickWraps API credentials for Instagram (once more, you guessed it… their official brand Instagram account)
104
105Because of my newfound Zendesk API credential access, I was able to add myself as the Owner of their Zendesk platform.
106
107Perusing the platform, I found their customer service to be just as abhorrent as rumors suggested (note the Backlog and First Reply Time metrics).
108
109Now that I had the ability to receive emails at an inbox which was tied to multiple SlickWraps accounts, I simply sent password resets and further unlocked:
110
111•Full access to their corporate Slack team — one which had 135,000 historical messages contained within it.
112
113•Current account balances and transaction logs for their payment gateways (PayPal and Braintree).
114
115Unfortunately, it doesn’t stop there.
116
117I found that their administrator panel (i.e. the interface for SlickWraps employees and executives to pull reports and manage content on the SlickWraps website) was carelessly protected by a pointless firewall (remember: I had the “skeleton key”).
118
119I added myself as an admin user and immediately gained full control over their content management system.
120
121At this point, I could have deleted their entire company.
122
123Fortunately for SlickWraps, I had no nefarious intent. As I’ve done countless times before, I put things back where they belonged, left quietly, and prepared to disclose a severe vulnerability report.
124
125To say I went to great lengths to treat SlickWraps equitably would be an understatement. Candidly, after the staggering number of primitive security flaws exhibited by their administrators (e.g. the vulnerability to Dirty COW, an exploit which was patched in 2016), I question whether they deserved the leniency I am about to describe.
126
127...
128
129Below is a chronology of my attempts to notify SlickWraps of their cascading vulnerabilities:
130
131First, I sent a subtle tweet, anticipating that the “Security Researcher, White Hat Hacker” designation in my Twitter bio would be sufficient enough to spark a line of communication.
132
133I followed up with an email to their customer support desk (one which would end up being permanently ignored).
134
135SlickWraps automated customer support reply
136
137I then tweeted the contents from one of their unanswered customer support emails, indicating that I had access to their Zendesk API credentials.
138
139As a final proof of concept, I uploaded a .txt file to their server.
140
141To even the most inept of system administrators, this would be an alarming demonstration of internal vulnerabilities.
142
143At the time of uploading the .txt, and to this very day, both my access to their database and my safeguarding of its sensitive contents remains in-tact.
144
145Data points from a SlickWraps order
146
147Within eleven minutes of the `proof_of_concept.txt` file being posted to Twitter, I found that @SlickWraps had blocked me.
148
149Unfortunately, it gets worse. Looking at activity on the back-end of their website, I took note of SlickWraps actively trying to erase this data breach from the record books.
150
151They reset passwords, they attempted to remove my shell execution capabilities, they changed their API keys… they even went so far as to reinstall their entire Magento eCommerce platform.
152
153Throughout all this, they failed to remove the glaring vulnerability that I had exploited.
154
155Even after publicly tagging them about my knowledge of their surreptitious cover-up, they remained unresponsive.
156
157As I write this, I still cannot grasp why SlickWraps didn’t simply communicate with me to learn where the foundational vulnerabilities lay. I was becoming increasingly frustrated by the fact that they were not acting on their obligation to inform customers of the privacy breach.
158
159To understand the gravity of this data breach, note that non-compliance of notifying customers of a data breach within the EU can result in administrative fines of up to €20 million, or four percent of a company’s global annual turnover — whichever is higher.
160
161At this point, I reached out to Troy Hunt, founder of haveibeenpwned.com.
162
163For the uninitiated, haveibeenpwned is a prolific website which allows internet users to check whether their personal data has been compromised by data breaches.
164
165Troy agreed to take a “good look” at the leaked SlickWraps customer database.
166
167I’m fortunate enough to have worked with Troy in the past. Earlier this year, I discovered a publicly available database which held personal details of over 56 million US residents (link).
168
169Meanwhile, as SlickWraps was mindlessly reinstalling Magento,…
170
171…it appeared that at least one other security analyst took notice of my warnings.
172
173It also became apparent that other vulnerability testers were accessing the SlickWraps servers.
174
175The following day, nearly 2.5 days since the first point of contacts were made with SlickWraps, I continued publicly expressing my bewilderment.
176
177Putting aside the issue of SlickWraps feigning ignorance to my outreach, my concerns focused around the amount of damage a bad actor in my position could inflict on the hundreds of thousands of unsuspecting SlickWraps customers.
178
179Not only did those victims have no idea that their confidential information was up for grabs, but the responsible party seemed to have no interest in being held accountable.
180
181Despite the time which had passed, the shell execution was still active on the server, as was their incompetently guarded administrative panel.
182
183A financial snapshot of SlickWraps
184
185Reaching my limit, I posted one more tweet:
186
187Exactly nineteen minutes later, @SlickWrapsHelp (their dedicated customer support handle) finally opened a line of communication… in the strangest possible way.
188
189As you can see, they reached out — not to reply to my vulnerability exploits, but rather to address what they believed to be a customer order complaint.
190
191In other words, they mistook the leaked customer data I posted as an actual customer grievance.
192
193I can say with confidence that no company has ever asked me for an order number when notified of a data breach.
194
195Ninety-one minutes later, @SlickWrapsHelp finally appeared to realize what was going on. They sent a follow-up DM to ask if I was looking for a bounty.
196
197Given my line of work, this indeed would have been part of my protocol when sharing a vulnerability report.
198
199However, given the circumstances, I was far beyond seeking monetary compensation. I only wanted SlickWraps to do right by their customers and fulfill their obligation to disclose this serious data breach to the appropriate parties.
200
201I first demanded that their official brand handle (@SlickWraps, the same one which had blocked me three days prior) unblock me and make contact.
202
203They agreed.
204
205At this stage, I was fed up with the gross incompetence and criminal negligence which had been exhibited by SlickWraps. They had made no efforts to follow protocol on a security issue of this magnitude.
206
207…and here it is. Their first real contact: Hello.
208
209That’s it.
210
211I laid out my terms as candidly as possible and addressed the message directly to Jonathan Endicott, the CEO and founder of SlickWraps.
212
213The @SlickWraps account followed up:
214
215“Because this is an egregious data breach and the affected parties deserve to know,” I thought.
216
217“Yes, but not if you’re going to continue trying to cover your tracks,” I thought.
218
219I thought it only fair to afford this purported “3rd party social team” the benefit of the doubt.
220
221I looked to my admin panel records, found “User ID 1” (Jonathan Endicott, CEO of SlickWraps) and sent a very concise email.
222
223Within three minutes, I was once again blocked. This would be the last time I had any contact with Mr. Endicott or SlickWraps.
224
225I gave this my best effort.