Passwordless libpurple backend (read: Telegram) allows easy identity stealing

[pvgoran]

1. I register with my Telegram phone number on a Spectrum Telegram transport and pass SMS authorization.
2. I log out of the telegram transport.
3. Someone else registers with my Telegram phone number on the same transport.
4. The libpurple backend reuses existing authorization information and allows that other user to connect to Telegram on my behalf!

This seems to be a huge security problem for all Spectrum Telegram transport users, and possibly for all other passwordless libpuprple backends (if any).

I'm using (gateway mode) Spectrum version 2.0.3, libpurple from pidgin 2.12.0, telegram-purple version 1.3.1, running on Gentoo. Jabber server is ejabberd version 16.09.

[pvgoran]

Here is my transport configuration: telegram.cfg.zip

[pvgoran]

The only workaround I can think of would be to somehow completely disable registration with affected transport(s). (Is it even possible without changing the code?)

[vitalyster]

https://github.com/SpectrumIM/spectrum2/blob/master/spectrum/src/sample2.cfg#L104

[pvgoran]

The best correction for this would probably be adding the user JID to the names of account directories inside /var/lib/spectrum2/<transport-jid>/telegram-purple, so that they were called something like +1234567890@user@jabber.server instead of just +1234567890. This may turn out to be impossible if libpurple manages these directories without any control from spectrum2_libpurple_backend.

Another, less reliable correction would be to disallow registration if the legacy network username is already user by someone else. Also, when a user de-registers, the associated libpurple backend account needs to be deleted (right now, it's kept intact).

[pvgoran]

https://github.com/SpectrumIM/spectrum2/blob/master/spectrum/src/sample2.cfg#L104

This controls public registration (from foreign Jabber servers), but if I disable it, registration from the "local" Jabber server will still be allowed, right?

[vitalyster]

AFAIR, it only allows to register by admin

[pvgoran]

AFAIR, it only allows to register by admin

Both you and me were wrong. If registration.enable_public_registration is zero, only users from Jabber servers listed in service.allowed_servers are allowed to register; if service.allowed_servers is not defined, even users from the local Jabber server can't register. (Well, probably admins can register anyway - I didn't check this.)

So, setting registration.enable_public_registration to zero and ensuring service.allowed_servers is not defined serves as a workaround, at least for personal or semi-personal transport instances, where registrations are seldom and can be made/assisted by admin.

[s4Ne1]

Anything new about this issue?

[edhelas]

Up

[vitalyster]

This should be fixed on latest master, please test and let me know if there are some issues

[pvgoran]

It may take a while, but I'll try to find a possibility to test it.

[vitalyster]

If you are able to use Docker, then we have master tag in our Docker image

[pvgoran]

@vitalyster Thanks for the suggestion. However, even if using Docker, I'll need to set up domains, a Jabber server, and connection between the server and the transport.

[vitalyster]

You can take a look at the example configuration on localhost: no need to set up domain for using transports - https://github.com/SpectrumIM/spectrum2/pull/385/files