|Anonymous | Login | Signup for a new account||2019-07-17 07:43 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008718||TestLink||Security - General||public||2019-07-08 09:46||2019-07-13 11:12|
|Platform||Linux Kernel 3.10||OS||CentOS||OS Version||7.5.1804|
|Product Version||1.9.18 (2018 Q3)|
|Fixed in Version|
|Summary||0008718: Suspicious remote account creation even when user register has been disabled|
|Description||We are facing a strange issue: in last two weeks we have had two attacks to our public testlink instance: https://production.eng.it/testlink. [^]|
We started to receive a lot of email notifications about newly Testlink account created, with typical SQL/command Injection patterns.
So we decided to disable the possibility for end users to register themselves ($tlCfg->user_self_signup = FALSE within custom_config.inc.php file).
On last friday (July 5th) we had the same attack, and we started to receive a lot of email notifications about new accounts created in our Testlink instance, even with user self signup disabled.
Email stopped when we shutdown the Testlink instance.
In both cases anyway actually no new account has been created (double-ckecked from Testlink GUI and directly within the DB), and I also checked whether are there remote API to create accounts or not, but Testlink actually doesn't have a remote API for this.
Moreover: no trace on Testlink and web server log about remote invocation of Testlink account creation functionalities.
Is there something else we have to take into account to prevent this kind of attack?
|Steps To Reproduce||Not enough information to reproduce it|
|Tags||No tags attached.|
|QA Team - Task Workflow Status|
|Attached Files|| Screen Shot 2019-07-13 at 13.08.33.png [^] (40,085 bytes) 2019-07-13 11:12
|Just in case: there could be the possibility of a bug in the notification mechanism, so it could send a notification email even when the new account isn't actually created?|
edited on: 2019-07-13 11:12
unfortunately, if you can not provide an example of how to reproduce the attack is very difficult to develop a remediation.
Can you provide some samples of the mails you have received?
remove the firstLogin.php file as a security measure.
just tested and got: the attached image
the attack is not using this page
|2019-07-08 09:46||danzone||New Issue|
|2019-07-08 10:00||danzone||Note Added: 0028990|
|2019-07-13 11:01||fman||Note Added: 0029022|
|2019-07-13 11:05||fman||Note Edited: 0029022||View Revisions|
|2019-07-13 11:11||fman||Note Edited: 0029022||View Revisions|
|2019-07-13 11:12||fman||Note Edited: 0029022||View Revisions|
|2019-07-13 11:12||fman||File Added: Screen Shot 2019-07-13 at 13.08.33.png|
|Copyright © 2000 - 2019 MantisBT Team|