Why Your Service Could Use Exploiting

My Web App Service Got Exploited

Just a little over three months ago, I launched a virtual number service and today, a vulnerability got exploited. I want to use the term “hacked” but then most people might think a hacker broke in and made it unsecure or breached some data. Fortunately, that wasn’t actually the case. So I’d rather use the term “exploit” than “hack”. I found out about it because I woke up to a customer complaining that my service wasn’t working for him.

I called my own virtual number to check if his claims were true, and nothing was happening. I restarted the VPS, just to be sure, and sure enough, same results. I then went to check the API that my virtual number service uses and that is where I saw the problem: the account balance was -$0.43 (negative 43 cents). What could have possibly gone wrong? I checked the logs and that is where I saw what I needed to see.

Before I tell you what I saw, I must tell you what led up to it. When I first released my virtual number service, the only way for someone to check if it was available in their country was to check the pricing rates, and just believe that whatever it told them was true. For the most part, this method is fairly accurate, though I have had one country in which it said “Not available in your country” but when testing with the visitor, the service worked! When I can chat with someone firsthand from China, Kenya, South Africa, Tanzania, Russia, Australia, Ireland, etc., and test the service with them, it helps me to find the API system is sometimes wrong in its claims that it is not available in a certain country.

To try and compliment the price check and availability check, I built a system to “test the service” before you start using it, as there is no way for me to really offer “free” as an option. This meant that you would put your phone number into the system and you would get a phone call with a 60 second message stating to sign up for the service and to give it a try along with additional information about the service. If someone got a phone call, it was more than likely the service would definitely work in their country.

Offering this test was completely complimentary, but it also meant I was stuck paying the rates for everyone checking to see if the service worked in their country. Rates to different countries also meant different pricing, as high as $0.50 or more in some countries. While I happily ate the costs in hopes to get new customers, it would soon come across the eyes of someone or someones who were going to abuse it. I have only myself to blame for not putting additional restrictions on the test service, but the test service fully worked and was only doing what it was supposed to be doing: sending people a test call.

Now here is what happened:

When I checked the logs, it appeared as if someone was just checking every random number they could in a series of different countries. Over 200 phone calls were made. Unfortunately, the test service only records the FROM number and the TO number. So I could see what numbers were being called, but I could not see who was actually putting in those numbers. The test service has since been removed until I can figure out another method to allow people to test the service, likely to be more personal, such as submitting your email first, and then I would have to manually send the test. Or sending a text verification to be verified before sending the test phone call, as text messages are slightly cheaper to most countries.

When you release any web app into the wild, you really have no idea what is going to happen. You know what you use it for and you know what you programmed it to do, but sometimes you find people using it for other things that you would have never thought they could use it for. Sometimes this is a great thing and you can advertise it as another method for using your web app, while other times, it may not be so great that a service was exploited the way it was.

Most of us are just happy to have created something that we can put out there and we try to give anyone who comes across it the benefit of the doubt. Unfortunately, with the good will also come the bad. Thus, I did not foresee the abuse of the test service when assuming people were going to use the actual service for testing. While I would like to say that offering the “test service” convinced people to sign up and pay for the service, a survey actually showed that most people signed up for the service regardless of that test, and many came from a search engine, where they were more convinced about signing up due to my SEO efforts.

While I am not happy that over 200 calls were made to random countries across the world, in a span of about 24 hours, which depleted the funds of Call Me Private and Text Me Private, I am certainly content that the exploit was caught early on, and there were not enough funds in the service to break any business bank accounts connected to it. It is also interesting to note just how fast a web app can make it around the world.

I could not tell you who the people were that received the phone call from Call Me Private, but I can only hope that at least a few will sign up. For any people living in another country that received an unsolicited call from Call Me Private, I do apologize for someone exploiting the service and sending you a phone call.

So a lesson learned: while it is upsetting to see my web app being exploited, it taught me how to patch things, how to prevent exploits, and has helped me to get more creative with my services. While I could sit here and blame someone else for exploiting my service, I have to realize that I must admit the fault is my own and accept responsibility for creating a situation where the service could be exploited. It only drives me to continue working on improving my virtual number services.

Image Sources: Google