Retrospective: Death of the Promo Checker Tool - What went wrong & What we learned
RIP Alpha Version 1 - Born 03/24 - Died 07/21
Largest Takeaways if we were to attempt this again:
The larger concept of being able to scroll through a page and just see the final discounted price on items is still sound & we may explore it again in the future. The implementation of using a tool like burpsuite was absolutely not the correct approach to take.
The purpose and intent of this tool has always been, and remains, strictly 100% for the purpose of finding and applying legitimate and valid promo/discount codes. This tool is not intended to use any type of unethical nor improper means of achieving a discount and/or savings. Every vendor has the right to refuse any promotional discount at their own individual discretion. This applies to any and all who use this tool.
Hire a PROFESSIONAL next time. Our team currently lacks anyone with actual experience or background in this type of project. We are not software engineers, we’re not coders, and we’re not developers. Clearly this lack of knowledge and experience has shown in this first trial run.
Pay for a remote server host next time, do NOT host on our primary network ourselves for cost savings. The risk and potential downsides are far too high.
Create a CUSTOM tool or chrome extension that is actually written by a professional to try and accomplish our vision. Off the shelf technologies are great but taking existing tools like burpsuite and trying to customize and modify them to serve our purpose quickly becomes far too unpredictable and unfeasible.
Next time do not set up automatic responder email that sends anyone who applies for testing the connection details. Consider how to implement some type of vetting system so that testers are verified and we are confident we know who they are and what they are doing within our systems.
Primary Issues Discovered with Alpha Testing:
DO NOT use Burpsuite for next version. Burpsuite seems to be the biggest issue. It is not a tool designed for this use in any way. Trying to use this software as our basis proved to be difficult for that reason.
Burpsuite Deployment with custom automations was extremely unreliable. Random & unpredictable issues with tasks occurring out of order.
Issue with differences between websites - some worked flawlessly with the tool, while other websites where simply incompatible due to differences in how they are laid out / different coding styles, patterns, and techniques.
We assumed that any website selling products online would be secure enough to not cause conflicts with our tool. We were wrong.
Unexpectedly, some websites depend on their FORWARD facing values during the shopping and/or checkout process. Normally this would not be an issue, but with our tool using those user facing facing values we found conflicts can occur.
Some sites would display discount price all the way through checkout and confirmation, but actual transaction would occur for a completely different amount, usually equal to the original price. Meaning the user thought they were paying less than what they actually paid. Still not clear how this occurs.
Some sites would display normal retail price all the way through checkout and confirmation, but actual transaction would occur for a completely different amount, usually equal to the lowest discount price found. Meaning the user thought they were paying more than what they actually paid. Still not clear how this occurs.
Some sites would display a completely random price all the way through checkout and confirmation, but actual transaction would occur for a completely different amount, usually equal to some other random form field or some tiny default amount such as 0.01 or 99999. Meaning the user really had no idea what the actual payment was going to be. Still not clear how this occurs.
It turns out, front end value modification is blocked by some sites as they believe that it can be a security risk. We believed this wouldnt be an issue due to the modern security standards and coding practices but some websites still use outdated and insecure methods which could result in the host server thinking there is some type of malicious attack occurring, even though there is none.
Form Fields are sometimes mixed up due to different token values. This causes fields to show one label but actually be for an entirely different value.
The security breach that ended it:
Choice to deploy to alpha testers via a direct RDP connection to our virtual test server was an ignorant decision in hindsight. Our belief at the time was that creating a separate virtual server would protect our larger network…However we learned that granting even only those small permissions were enough to exploit. Somehow it was possible to tunnel out of the virtual environment and have access to our larger network of devices and systems. We are still not clear on how this was possible, it is likely that a software engineer or cybersecurity expert needs to be consulted to get more information and answers.
Message appeared on virtual server demanding payment of bitcoin in order to regain access to our systems and data.
Entire virtual server was taken over and they attempted to force us to pay a ransom. We chose to not capitulate and to act to protect our data by formatting our systems rather than letting them be stolen and potentially leaked. We lost a significant amount of data, software, code, and most of all time.
Our entire server was sacrificed and wiped in order to prevent further infection, protect our partners data, and to refuse capitulation to the hackers.
All of our developed automations, burp settings, access logs, email accounts, changelogs, cookies and histories were lost.
For more information or questions please reach out to info@wvaz.org