SMS Privacy was attacked last night

This morning I checked on the list of SMS Privacy user accounts, as I do every morning, and found that quite a large number had been created overnight, between 22:48 and 23:10 GMT on 24th of Feb 2017. Most of them had names like:

(select(0)from(select(sleep(6)))v)/*'+(select(0)from(select(sleep(6)))v)+'"+(select(0)from(select(sleep(6)))v)+"*/

BWfUtOFm';select pg_sleep(2); --

-1 OR 3+847-847-1=0+0+0+1

which is obviously an attempt at SQL injection.

What did they do?

It was clearly an automated tool. It made over 12k requests over 22 minutes.

Apart from it being highly unethical to do vulnerability scanning on somebody else's website without permission, it's also pretty illegal...

The first request was "GET /acunetix-wvs-test-for-some-inexistent-file", which points to Acunetix. The User-Agent string was:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.21 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.21

which, judging by this StackOverflow post is also used by Acunetix. Of course, it could easily be another tool that is just disguising itself as Acunetix but I consider that unlikely. It was most likely just Acunetix.

All of the requests went to the Tor hidden service.

What did they find?

I looked through the access logs to see if I could find anything untoward. There were no requests with uncharacteristically-large response sizes, indicating there was no bulk transfer of data out of the database. There were 6 requests with a response code of 500 (Internal Server Error).

I get emails whenever Mojolicious writes anything to its error log, and I got some emails about:

[Fri Feb 24 22:50:20 2017] [error] DBD::mysql::db selectrow_hashref failed: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='

This is a bit troubling. It shouldn't be possible for user input to cause errors, let alone SQL errors. It turns out that inputting characters to the signup/login forms that exist in UTF-8 but not in latin1 caused this error, even though it was passing the username to MySQL with a bound parameter. Surprising, although probably not exploitable.

I'm quite confident there are no SQL injection vulnerabilities in SMS Privacy.

What did I do?

Matt (with permission) ran sqlmap on the login form, and found no exploitable inputs. This isn't a surprise.

To prevent the "Illegal mix of collations" error from MySQL, I have added stricter validation on the contents of usernames in both the signup and login forms. The "correct" thing to do would be to handle UTF-8 correctly, but this was the path of least resistance. All existing legitimate usernames are still allowed.

Who was it?

Since they used the Tor hidden service, I have no way to even know which IP address the attack originated from. We can only speculate on motive.

I think it's unlikely to be a sophisticated or well-financed attacker (e.g. a nation state) as they would presumably be a bit more subtle about it.

Maybe a script kiddie was just doing it for fun? Maybe a criminal was doing it to find vulnerabilities to sell? Maybe a criminal was doing it to try to read people's messages? Maybe a customer was doing it to make sure the service is adequately secure? Maybe it wasn't targeted, and was just an automated attack on a large number of Tor hidden services?

Don't know.

Conclusion

No harm was done. I've improved the username validation, and I'm now aware that SMS Privacy is the subject of potentially-targeted attacks, which is scary but probably to be expected.

And if you want to do some security testing of SMS Privacy, that's fine, but please get permission first :).