Closed sjstein closed 8 months ago
Look at the bot currently handles a new password request.
I suspect a new user will be created in the XML file, but the old one is still there.
If that's the case, it needs to be changed as that's a pretty bad vuln
Blew away all but one user on my local db and then added myself back. Two users now - host file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<HostSecurityData>
<Banned_Users>
</Banned_Users>
<Unique_Logins>
<UniqueLogin>
<Name>Albertan</Name>
<UID>A71A82BD214C3273DE00646EF53C5FB48A7CB07D0AA72F3D0BC3BB812504E311</UID>
<Password>GHv=F{bumo=PNvAoV</Password>
</UniqueLogin>
<UniqueLogin>
<Name></Name>
<UID></UID>
<Password>5pG0GIr2]0d{{J^Cs_Xxn3O-|</Password>
</UniqueLogin>
</Unique_Logins>
</HostSecurityData>
The second record here is the one I just added with the /add_user command note: Name field not filled in. Since Run8 blows it away anyway, probably not a big deal - but still odd.
| Name field not filled in. Since Run8 blows it away anyway, probably not a big deal - but still odd. Never mind - the name field isn't filled in since that is the Run8 name field, not the discord name field (per HostSecurity.xml "specs")
after executing the /refresh_pass command to request a new password, the host file looks good - still only two records:
<?xml version="1.0" encoding="utf-8"?>
<HostSecurityData>
<Banned_Users>
</Banned_Users>
<Unique_Logins>
<UniqueLogin>
<Name>Albertan</Name>
<UID>A71A82BD214C3273DE00646EF53C5FB48A7CB07D0AA72F3D0BC3BB812504E311</UID>
<Password>GHv=F{bumo=PNvAoV</Password>
</UniqueLogin>
<UniqueLogin>
<Name></Name>
<UID></UID>
<Password>[S@J.ALV8()BAIt9`^?Jd.f:-</Password>
</UniqueLogin>
</Unique_Logins>
</HostSecurityData>
now to add a UID so that gets populated. I'll just add any string and see that it gets pushed back into our db.
In order to force the refresh, I'll add another user
Updated host file after changing my UID:
<?xml version="1.0" encoding="utf-8"?>
<HostSecurityData>
<Banned_Users>
</Banned_Users>
<Unique_Logins>
<UniqueLogin>
<Name>Albertan</Name>
<UID>A71A82BD214C3273DE00646EF53C5FB48A7CB07D0AA72F3D0BC3BB812504E311</UID>
<Password>GHv=F{bumo=PNvAoV</Password>
</UniqueLogin>
<UniqueLogin>
<Name></Name>
<UID>OU812</UID>
<Password>[S@J.ALV8()BAIt9`^?Jd.f:-</Password>
</UniqueLogin>
</Unique_Logins>
</HostSecurityData>
Now I added garrison as a new user and saw the host file get updated properly:
<?xml version="1.0" encoding="utf-8"?>
<HostSecurityData>
<Banned_Users>
</Banned_Users>
<Unique_Logins>
<UniqueLogin>
<Name>Albertan</Name>
<UID>A71A82BD214C3273DE00646EF53C5FB48A7CB07D0AA72F3D0BC3BB812504E311</UID>
<Password>GHv=F{bumo=PNvAoV</Password>
</UniqueLogin>
<UniqueLogin>
<Name></Name>
<UID>OU812</UID>
<Password>[S@J.ALV8()BAIt9`^?Jd.f:-</Password>
</UniqueLogin>
<UniqueLogin>
<Name></Name>
<UID></UID>
<Password>,_fU`}#x2Abz%qBqJ</Password>
</UniqueLogin>
</Unique_Logins>
</HostSecurityData>
Showing details for my SID from our db shows the UID as being populated properly:
sid: 2
discord_name: sinistar666
discord_id: 280113231668969472
run8_name:
uid: OU812
role:
password: [S@J.ALV8()BAIt9`^?Jd.f:-
join_date: 10/9/23
ip:
banned: False
ban_date:
ban_duration:
notes:
now to /refresh_pass on my account and see what happens to the host file:
<?xml version="1.0" encoding="utf-8"?>
<HostSecurityData>
<Banned_Users>
</Banned_Users>
<Unique_Logins>
<UniqueLogin>
<Name>Albertan</Name>
<UID>A71A82BD214C3273DE00646EF53C5FB48A7CB07D0AA72F3D0BC3BB812504E311</UID>
<Password>GHv=F{bumo=PNvAoV</Password>
</UniqueLogin>
<UniqueLogin>
<Name></Name>
<UID>OU812</UID>
<Password>uhH6`}GrUN:@ToiQSu</Password>
</UniqueLogin>
<UniqueLogin>
<Name></Name>
<UID>None</UID>
<Password>,_fU`}#x2Abz%qBqJ</Password>
</UniqueLogin>
</Unique_Logins>
</HostSecurityData>
ok - so the good news is that the new password is associated with the same SID, so no new record is created (Note: Oddly, now garrison's Name field has been populated with 'None')
So I think the best way to handle different/multiple UIDs is to just have the user request a new password when they change machines. This means I will need to change the code slightly here to - on password change - blow away the UID field.
NOTE; It has probably been lost in my ramblings over this project over the weeks, but it is important to put this out there again: When there is a blank record in the HostSecurity file with only a password, Run8 will allow ANYONE with that password to log in. It is only at that time that the UID is associated with that particular password.
This is a pretty big fucking deal - and absolutely exploitable by a pissed off user who still has creds on the server - effectively "giving" his credentials to someone else.
It would go like this:
----but now I think I see at least a little bit of accounting that could be done. We need to log the password changes since the passwords used to log into Run8 are stored in cleartext in the log
ok in summary:
This was closed in merge #52
Pasted from discord:
since we don't have access to the algorithm that Run8 uses to determine the UID, I don't know if there is anything we can do other than have them ask for a new password when they change machines which means the host file is going to continue to grow gross hmmm- it's early, so I'm not firing on all cylinders however, what about if when a user requests a new password, their UID (that we save in our db) is blown away this way when the HostSecurity file is re-written, that record will be purged ? again - not thinking clearly. Not sure what will happen testing needed