tools.dykbot has password-looking values world readable in compiled Java class files
Closed, ResolvedPublicSecurity
Actions

Assigned To

Authored By

	taavi
	Feb 25 2021, 5:26 PM

Project Tags

Referenced Files

None

Subscribers

View All 11 Subscribers

Description

While poking around for an unrelated issue I noticed that the dykbot tool has two class files that contain a string that looks like a passwords for User:DYKUpdateBot and User:DYKHousekeepingBot. I have not verified if those are actually working passwords for those accounts. DYKUpdateBot has enwiki admin rights. These bots and the tools is maintaned by User:Shubinator. I did not find a Phabricator account that belongs to them and do not have other private communication channels with them.

[taavi@tools-sgebastion-08 /data/project/dykbot/Bots/dykNomStatsBot]$ strings UserInfo.class 
<init>
Code
LineNumberTable
getUser
()Ljava/lang/String;
getPassword
SourceFile
UserInfo.java
DYKHousekeepingBot
P3nc!lSharpener
dykNomStatsBot/UserInfo
java/lang/Object

[taavi@tools-sgebastion-08 /data/project/dykbot/Bots/dykUpdateBot]$ strings UserInfo.class 
<init>
Code
LineNumberTable
getUser
()Ljava/lang/String;
getPassword
SourceFile
UserInfo.java
DYKUpdateBot
!'klc:QE1S
dykUpdateBot/UserInfo
java/lang/Object

Details

Author Affiliation: Wikimedia Communities

Event Timeline

taavi created this task.Feb 25 2021, 5:26 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 25 2021, 5:26 PM

taavi added a project: cloud-services-team (Kanban).Feb 25 2021, 5:26 PM

taavi added a project: Tools.

I have done a chmod 640 on both those files and emailed the affected user regarding their phab ID.

Those passwords should be revoked/rotated and ideally turned into an owner-only OAuth consumer on a bot password. They are now stored here (oops, sorry) and we can't be certain that I'm the first person to find these which in my opinion isn't an acceptable risk for a sysop-level account.

sbassett added a project: PermanentlyPrivate.Feb 25 2021, 6:30 PM

In T275800#6862216, @Majavah wrote:

Those passwords should be revoked/rotated and ideally turned into an owner-only OAuth consumer on a bot password. They are now stored here (oops, sorry) and we can't be certain that I'm the first person to find these which in my opinion isn't an acceptable risk for a sysop-level account.

That is a Stewards request rather than something the WMCS team can take direct action on.

I locked both accounts as a standard measure for compromised accounts. The on-wiki password was also invalidated, so they'll have to use the password reset system to set a new one once the accounts are unlocked. Please ping me once they should be unlocked.

QuiteUnusual subscribed.Feb 25 2021, 8:40 PM

Adding the tool maintainer, @Shubinator, to this task.

@Shubinator Note the bot is currently locked to prevent any unauthorized activity. Please do let me know once you have time to rotate the password - if you wish to have real-time conversation, I'm happy to talk via IRC.

Whoops, sorry, and thanks for fixing the file permissions. Is a) rotating the passwords, and b) ensuring those files are read-only in the future a solid path forward for now?

Asking as while I'd like to tweak both bots to leverage OAuth, they were written ~11 years ago, before a lot of the newer technology was implemented / widely adopted. Both bots are so old their underlying bot framework, JavaWikiBotFramework (JWBF), is no longer supported / maintained, and its source code deleted from the Internet. If updating the bots' technology is required, there's a fair chance I'll need to either reimplement JWBF myself, or reimplement both bots on a maintained bot platform, either of which will take a significant chunk of time.

Hello @Shubinator,

Thanks for your answer, and for messaging me via IRC. To summarize the conversation, passwords should be rotated now, and accounts unlocked.

It would be really helpful if you migrated to OAuth owner-only credentials, there are the prefered way for bots to authenticate. Alternatively, you can use bot passwords. Both approaches have the advantage that they don't give the holder ultimate control over the account. They wouldn't be able to ie. change your password or email address assigned to your account. Do let me know if you need any help with implementing that.

Best,

Martin Urbanec

In T275800#6864723, @Urbanecm wrote:

Alternatively, you can use bot passwords. Both approaches have the advantage that they don't give the holder ultimate control over the account. They wouldn't be able to ie. change your password or email address assigned to your account. Do let me know if you need any help with implementing that.

+1. Bot passwords were specifically invented to provide this small measure of protection for old bots which for whatever reason cannot be updated to use OAuth owner-only grants.

In T275800#6864637, @Shubinator wrote:

Asking as while I'd like to tweak both bots to leverage OAuth, they were written ~11 years ago, before a lot of the newer technology was implemented / widely adopted. Both bots are so old their underlying bot framework, JavaWikiBotFramework (JWBF), is no longer supported / maintained, and its source code deleted from the Internet. If updating the bots' technology is required, there's a fair chance I'll need to either reimplement JWBF myself, or reimplement both bots on a maintained bot platform, either of which will take a significant chunk of time.

Is it by any chance this JavaWikiBotFramework? https://github.com/eldur/jwbf

Is it by any chance this JavaWikiBotFramework? https://github.com/eldur/jwbf

Yep, that's the one, looks like it migrated from Sourceforge SVN to GitHub.

I'm boldly closing this, as the passwords were rotated, account unlocked again, and hopefully there is no way to access the account now.

The bot is not yet running again, because English Wikipedia's Arbitration Committee has its own procedures for dealing with compromised accounts. That being said, it's a purely on-wiki procedure now, and nothing that needs Phabricator tracking.

Shubinator added subscribers: L235, Bradv.Feb 26 2021, 7:18 PM

@sbassett added a project: PermanentlyPrivate.

Now that the password has been rotated, I don't believe there's any private information here. Can this be made public?

sbassett triaged this task as Low priority.Mar 2 2021, 10:03 PM

sbassett removed a project: PermanentlyPrivate.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".

sbassett changed the edit policy from "Custom Policy" to "All Users".

sbassett moved this task from Incoming to Our Part Is Done on the Security-Team board.

tools.dykbot has password-looking values world readable in compiled Java class filesClosed, ResolvedPublicSecurityActions

Description

Details

Event Timeline

tools.dykbot has password-looking values world readable in compiled Java class files
Closed, ResolvedPublicSecurity
Actions