A non-technical aspect of security – how could I have prevented the 2014 Jabbim password leak?

The 2014 Jabbim breach has happened almost five years ago, but there is still one interesting information to reveal. It is something I am not much proud of, but we can learn from both my mistake and Jabbim's mistake.

My experience with a past vulnerability report

Some time before the breach (2013-11-21), I had reported some seemingly unrelated vulnerability. Well, it was also an SQL injection, but on a different place. Moreover, just a script crash there had some unexpected consequences:

1. Some part of the DB remained locked.
2. This has caused many script waiting for releasing the lock.
3. As many web scripts were waiting, the server has reached the fork limit. As far as I remember, it was unable to serve even static files.

Maybe you can imagine what happened. Without having an idea that the status icon script is backed by a SQL database and without any bad intentions, just putting an apostrophe in the url accidentally caused an SQL injection and subsequent webserver crash.

I had good intentions, so I promptly reported the issue to admins. The reaction was like “Thank you for crashing our server. I could have been at home right now.”. Well, they fixed the issue, but my feeling from the communication was not much good.

My report of the vulnerability abused in the breach

The same day, I had also discovered another SQL injection vulnerability – in user search. That is, the same vulnerability that was abused in the 2014 breach. I also reported it, but I decided to contact another (hopefully more friendly) admin. However, I was just told about not having enough time for handling it.

So, I was about to report it to the unpleasant admin. He was offline that time, so I had to wait. When waiting, I started thinking about giving a report that demonstrates the danger but stands in limits of white-hat hacking.

However, this takes some time. As I was doing this in my free time for my fun and someone's else profit, I did not have enough time for making the report perfect. I needed to do some other duties, maybe something school-related. So, I postponed it for indefinite amount of time and you know the result… I am really sorry for that.

What could have been done better from the reporter side?

Although I would not describe me as a perfectionist, I admit I sometimes have some perfectionistic traits in a limited way. That said, I am not perfect at avoiding perfectionism. But “perfect” is an enemy of “done”. I could have opted for a trade-off – to try to make the report perfect until some deadline. Once the deadline passes, I would report it in however imperfect form.

What could have been done better from the admin side?

This is much related to the first vulnerability report.

• Do not discourage white hats: While I understand that a vulnerability report might be something unpleasant to handle in general, they could have responded in a more kind way. I believe it was obvious I had no bad intentions and tried to behave as responsibly as possible.
• Encourage white hats: There are some companies that even reward vulnerability reports and/or put your name to a hall of fame. If vulnerability rewards are expensive, you still can have a hall of fame, like some companies (even Google) have.
• Have a contact for reporting of security issues. It is also a good idea to have security.txt file, but it should not be the only way to contact responsible persons. (I know, security.txt has started in 2017, so they could not have it. But today, it is a good idea to have one.)
• When you receive a vulnerability report but you are not the right person to handle it, forward it to someone responsible as soon as possible.