Users running a non-download version of Vanilla (pulled from github), on branch release/2019.016 or master from the last 2 weeks should upgrade to release/2019.017 or latest master for security reasons. Downloaded official open sources releases are not affected.

Warning: Potentially serious security issue if you use jsConnect and reinstall your site.

This discussion is related to the Vanilla jsConnect addon.
businessdadbusinessdad Stealth contributor MVP
edited November 2012 in Feedback

Today I stumbled upon an odd behaviour of the latest JsConnect plugin. I was doing a demo to a colleague, and invited him to register to our main website, then move to our forum to show how JsConnect + Auto JsConnect work together. When he opened the forum, he got his account created on it, but, for reasons I can't explain, he got incorrectly assigned the roles Administrator and Forum Moderator.

Our website does not pass any roles to Vanilla, hence we expected the new User to be created as Member. When I went into the Control Panel to check, I also noticed that the column First Visit shows May 18, while this person has never had access to the forum before today (it wasn't even published). Interestingly, May 18 is the date of my first visit, i.e. the day when I installed the forum and set myself as an Administrator. There cannot be any chance that the User already existed, as we never met him before last week and I nobody could have created him an account in May.

I haven't been able to consistently reproduce the issue. All my further attempts to register new Users results in them being correctly created as Members. This, however, makes the issue even more dangerous, as a User could find himself Administrator without anybody noticing, and make all sorts of mess (voluntarily or not).

Tagged:
«1

Comments

  • Ah i would check default roles, first. I'm not saying don't have kittens but don't have kittens yet.

    grep is your friend.

  • I re read you post. I wonder it this could have been a collision to a previously authorised connection, or a pre existing account.

    grep is your friend.

  • x00x00 MVP
    edited November 2012

    The coincidence is pretty huge though.

    grep is your friend.

  • businessdadbusinessdad Stealth contributor MVP

    No default roles are set in the configuration, and nobody ever connected to our forum from that laptop, therefore there could not have been any "hanging sessions". There is only one JsConnect client set up (our website), and it was installed and configured yesterday, from scratch, on a new server. This excludes any earlier registration attempt.

    As I wrote in my original post, there's also no chance that the account could have been pre-existing, as this person is new. Besides, the "First Visit: May 18" rises more than a suspicion, since it matches the day when the forum was installed and the Super Administrator account was created. I know for sure that nobody ever connected that day, as I installed JsConnect the first time in July or August.

  • This was pretty much the first connect outside those that previously didn't use connect?

    grep is your friend.

  • x00x00 MVP
    edited November 2012

    I guess you could try replicate 1000s of attempts to test it out.

    grep is your friend.

  • businessdadbusinessdad Stealth contributor MVP

    This user was the first one to connect to the forum, apart from myself, when I created a few test accounts (all of which were set up correctly as Members). One more coincidence, which could be a red herring, but maybe not: the new User was the first of the list in Vanilla Users. Immediately after, there is my User Name, i.e. the Super Administrator, which was the first of the list until the new registration.

    About brute force attacks: I can't connect a brute force attack to the issue, as it happened as soon as the new person registered (we saw that he immediately got access to the Admin dashboard). Besides, my anti-brute force plugin is installed and running on that forum, and it's set with very restrictive parameters: three wrong passwords, and you're banned from logging in. Its log doesn't display any failed login attempt, anyway.

  • brute force is the wrong terminology, that implies you are trying to hit an entry requirement rather than some chance event.

    grep is your friend.

  • Out of interest your user ID is 1? not 0

    grep is your friend.

  • It is only roles assigned not the Admin Column? You haven't deleted rows form the user table, and if so did you reset the auto index.

    grep is your friend.

  • businessdadbusinessdad Stealth contributor MVP

    My User ID (Super Admin) is 1, and the Admin column in User table is zero for the new User. Tables haven't been touched by anyone except Vanilla itself.

    One more interesting finding, which clarifies what may have happened, but not why: I have some Users created by JsConnect with ID 4, 5 and 6 (6 was the highest User ID in use today, when the new person registered).

    The new User was given ID 2. Such ID belonged to an existing, active User (created manually by me, long before I tried JsConnect), to whom, now that I think about it, I indeed gave Administrator and Forum Moderator roles. That would explain May 18 as well, since I probably created the account straight away to allow the second Admin to familiarise with the backend.

    I just noticed it because the other Admin entered some sample posts to populate the forum with some data. When I permanently deleted the "wrong Administrator", such data was gone. This means that JsConnect (or EventController) decided to overwrite an existing active User with the new one. Since no role was given to the new User, it simply kept the old ones.

    It would be interesting to find out how did this happen, and why.

  • businessdadbusinessdad Stealth contributor MVP
    edited November 2012

    Update
    I can reproduce the issue consistently now. I restored a backup, and I can confirm that the issue that occurred is exactly what I described: User with ID 2, which was a regular, active User created manually, got overwritten by a new User when he connected to the forum for the first time.

  • LincLinc Director of Development Detroit Vanilla Staff

    You probably either passed a username or email that matched the existing user. jsConnect will match up users with existing forum accounts if one exists.

  • businessdadbusinessdad Stealth contributor MVP

    @Lincoln That's not the case. Both User Name and Email are completely unique. I reproduced the issue for the first time, and, for some reason, User ID 2 gets overwritten with new data.

    Before this happens, the existing Users are the following:
    - Admin. ID: 1, email: [email protected]
    - Steve. ID: 2, email: [email protected]
    - [Deleted User]. ID: 3, email: [email protected]
    - TestUser. ID: 4, email: [email protected]
    - Test Test, ID: 5, email: [email protected]
    - John Doe, ID: 6, email: [email protected]

    The new User has name "Brian XYZ" and email "[email protected]". When he visits the forum, he gets ID 2, which becomes: Brian XYZ. ID: 2, email: [email protected]. Everything else (password, roles, etc) is the same that was used by Steve.

  • ToddTodd Chief Product Officer Vanilla Staff
    edited November 2012

    Can you do the following? You'll need to do some querying.

    On your current database:

    select *
    from GDN_UserAuthentication
    where UserID = 2
    

    Restore a backup again and run the same query.

    Can you tell me what you see in those queries, specifically for the ForeignUserKey column?

  • LincLinc Director of Development Detroit Vanilla Staff

    Can you show us the JSON response your side of the SSO connection is sending when signing in as this happens?

    Are those the actual values you're using in the test or did you replace the actual email addresses before sharing?

    Could you search your config.php file for 'SystemUserID' and, if it's there, tell me what value it has?

  • LincLinc Director of Development Detroit Vanilla Staff

    Also, when you reproduced this, did you use precisely the same data the second time? The UserID association is stored after the first login, so even if you manually reverted UserID 2 to 'Steve' after the first SSO login, the system would still remember it signed in Brian XYZ as UserID 2 and do it again anyway. My understanding is you'd need to clear the UserAuthentication table to test it from scratch.

  • LincLinc Director of Development Detroit Vanilla Staff

    In fact - what's in your UserAuthentication table right now?

  • businessdadbusinessdad Stealth contributor MVP

    @Todd No worries about running SQL, databases are my element. To answer your question, ForeignUserKey for User ID 2 is 3, before and after it gets overwritten.

    @Lincoln
    - Here's the JSON from the request: {"email":"[email protected]","name":"Brian XYZ","photourl":"","uniqueid":"3","client_id":"1733013941","signature":"b807319a46c2fb8d4fdb54b233116795"}.
    - The values I wrote for the Users are actual values, except for the email domains.
    - SystemUserID doesn't exist in config.php file, in any of the Vanilla installations I'm using.
    - To reproduce the issue I used exactly the same data, restored from a backup. No manual intervention. UserAuthentication table was, therefore, reverted to its clean state.

    Note: I'm seeing a possible connection between the JSON and the UserAuthentication table. It's a speculation, but could it be that the uniqueid: 3 is used to determine a User ID? That would explain the issue. ID 3 is used to search in table UserAuthentication, it matches User ID 2, which is then overwritten.

Sign In or Register to comment.