Slick Wraps Data Breach(archive.is)
archive.is
Slick Wraps Data Breach
https://archive.is/yEIJT
3 comments
I found this article after receiving an email from (him?) telling me slick wraps had been hacked and were doing nothing to prevent the loss of my data.
Should probably be merged with: https://news.ycombinator.com/item?id=22384754
https://files.catbox.moe/fxn9r2.pdf
Some comments:
The beginning of the document says "Inspecting the file and testing my findings with initial hand‑crafted POST requests, I discovered that this script allows clients to specify a custom filename which is susceptible to path traversal. To make matters worse, the script does not protect against overwriting existing files": Great, you have path traversal and upload on an old-school PHP platform. You've already won! Report it and move to a bug bounty that actually pays.
Next, "Using this vulnerability, I uploaded a custom .htaccess file (with Options +Indexes ) into the /media directory": This is going too far.
Next, "Further leveraging the insecure upload script, I managed to deploy a custom index.php into an exiting /media subfolder": This is going to far.
Next, "To expedite further testing, I uploaded a copy of the p0wny‑shell. (Note that I slightly modified the file to circumvent common anti‑malware signatures.)": This is going to far.
"Knowing SlickWraps' website was powered by Magento 1.8, I located and decrypted the local configuration file. In here, I found MySQL and Redis credentials, and thus had full access to their entire database... Investigating the complete 17 GB MySQL dump gave me access to the following": Ah, so you knowingly breached real customer data. I think even you know you've gone way too far by now.
I could continue to the next steps in the exploitation chain, but won't. Per their initial Medium writeup, they didn't report it to Slick Wraps until they had walked past a not-so-thin line half a dozen times and extracted the full database content.
This behavior isn't even remotely grey-hat.