[RELEASE+SOURCE]Telnet GM-Tool

Updates:

- Code cleaned up and several comments added
- Settings Menu seperated to three menus
-- Host/Port Settings
-- Database Settings
-- Misc Settings

(v1.7.1 will be coming out tonight (it will replace all above the below line)

-----------

I am planning to implement a login system for accessing telnet/db features, at this time I am seeking opinions on this!

Do you think it should simply be left to the Owner passing InstaGM to his GM's to decide to give/not-give that GM details he would need to access features

OR

Do you think InstaGM should force you to login with a GM (permission 100) account [tied to the owners account/character db] and if you complete login instagm will fetch the data (ENCRYPTED)

Thanks for your time,
TealSky

A login feature might be a good idea indeed.

I think, you should use a SMP, that way, if the user wants to bind InstaGM account to regular rappelz account, or if he wants a separate table, he just have to change the SMP (instead of not having the feature he wants or changing the code)

In further version, you might add a config option for a sort of 'installer' to auto configure the SMP.

And that SMP, for example, would check if the user has a correct GM permission in the case of using rappelz accounts. (Or check whatever needs to be checked)

As using a SMP might cause problems, having some information in case of errors might also be useful (like if the SMP does not exist, tell the user about that, or create it automatically.)

for the SMP, I would choose 2 strings (username & password) as input and a boolean as output indicating if the user is allowed to login.

(If more information will be needed later in the development of your InstaGM, you better to add SMP rather than returning all needed information in the login SMP, to the boolean should be enough I think)

Quote:

Originally Posted by TealSky I am planning to implement a login system for accessing telnet/db features, at this time I am seeking opinions on this! Do you think it should simply be left to the Owner passing InstaGM to his GM's to decide to give/not-give that GM details he would need to access features OR Do you think InstaGM should force you to login with a GM (permission 100) account [tied to the owners account/character db] and if you complete login instagm will fetch the data (ENCRYPTED) Thanks for your time, TealSky

There is no sense in implementing a user-sided authentification system, as long as the users still have the db/telnet credentials. The only real thing would be a translation tool. So on the server side there would be a tiny tool which connects to the server on telnet and sql basis LOCALLY, so those doors would be shut from the outside, and that tool would then provide a secure door, where the gm tool can login, via SSH or throu an encrypted tunnel. Then there would also be a fair chance to block any unwanted commands. But thats a rather huge thing for some GM stuff.

Quote:

Originally Posted by haxti There is no sense in implementing a user-sided authentification system, as long as the users still have the db/telnet credentials. The only real thing would be a translation tool. So on the server side there would be a tiny tool which connects to the server on telnet and sql basis LOCALLY, so those doors would be shut from the outside, and that tool would then provide a secure door, where the gm tool can login, via SSH or throu an encrypted tunnel. Then there would also be a fair chance to block any unwanted commands. But thats a rather huge thing for some GM stuff.

To be honest in the beginning; I personally thought that the tools ability to use telnet/itembox/sql should be limited to the discretion of the server owner passing it out.

But a few friends of mine told me to use a VPN (glandu/thebrain) or to create some sense of interference. As my experience isn't enough to just jump into creating a client/server setup -- I decided to implement regex/character checking into all telnet/db related fields/commands.

Command Checking Example

The login I am speaking of would be a simple check against existing information (now remember haxti you can use a non-standard sql port + des encrypted password + privilage limited account (read only) to fetch information from auth)

Now if the user attempted to log in an admin account that has a character with permission 100 || this user is now allowed access to the "instant" functions of this tool. All he has to do is press a button which will fetch the relative info under encryption.

Storing these encrypted variables (telnet port/telnet password/db passwords etc..) until they are called for a function. When called they are decrypted into throw-away variables used then those variables are blanked leaving only the encrypted variables.

This is what I have thought anyway, any constructive comments are welcomed.

(P.S.

Remember that in good practice any and all SQL sided functions should operate under a heavily restricted account built and secured specifically for that function e.g. a READ ONLY account for anything that only reads or a WRITE only account who can't delete/update etc..etc..)

Quote:

Originally Posted by TealSky To be honest in the beginning; I personally thought that the tools ability to use telnet/itembox/sql should be limited to the discretion of the server owner passing it out. But a few friends of mine told me to use a VPN (glandu/thebrain) or to create some sense of interference. As my experience isn't enough to just jump into creating a client/server setup -- I decided to implement regex/character checking into all telnet/db related fields/commands. Command Checking Example  Spoiler [Only registered and activated users can see links. Click Here To Register...] I know it's not the perfect method but it does provide some protection, previous I had forgot that in a test I left "enter to send command" enabled and he didn't have proper regex/char checking. The login I am speaking of would be a simple check against existing information (now remember haxti you can use a non-standard sql port + des encrypted password + privilage limited account (read only) to fetch information from auth) Now if the user attempted to log in an admin account that has a character with permission 100 || this user is now allowed access to the "instant" functions of this tool. All he has to do is press a button which will fetch the relative info under encryption. Storing these encrypted variables (telnet port/telnet password/db passwords etc..) until they are called for a function. When called they are decrypted into throw-away variables used then those variables are blanked leaving only the encrypted variables. This is what I have thought anyway, any constructive comments are welcomed. (P.S. Remember that in good practice any and all SQL sided functions should operate under a heavily restricted account built and secured specifically for that function e.g. a READ ONLY account for anything that only reads or a WRITE only account who can't delete/update etc..etc..)

Again: Your Commandchecking isn't working at all what about #return get_env("console.password") and suicide do not need the "#" same for list. teminate, kill are missing completely set, get missing too. But this isn't the biggest problem since every command have to start with #

you should work with string.Contains() if you want to disallow a command and use the startswith only for the #

For your "encryption":
You know that it's pretty easy to load a c# program into a debugger to read your "throw away variables" decrypted? (This will work even with an obfuscated program!) Or you can decompile the program to get the encryption/decryption algorythm

On top of that a telnet connection is never encrypted. IF you want you can read the pw from the network traffic. Login via cmdtelnet (no restriction) get sql pw for the dbusers. decrypt the pwhash with one of the public desdecrypter. Login via the open sql connection that you tool needs ... activating xp_cmdshell and having shell access to the machine...

Quote:

Originally Posted by TealSky The login I am speaking of would be a simple check against existing information (now remember haxti you can use a non-standard sql port + des encrypted password + privilage limited account (read only) to fetch information from auth) Now if the user attempted to log in an admin account that has a character with permission 100 || this user is now allowed access to the "instant" functions of this tool. All he has to do is press a button which will fetch the relative info under encryption. Storing these encrypted variables (telnet port/telnet password/db passwords etc..) until they are called for a function. When called they are decrypted into throw-away variables used then those variables are blanked leaving only the encrypted variables. This is what I have thought anyway, any constructive comments are welcomed. (P.S. Remember that in good practice any and all SQL sided functions should operate under a heavily restricted account built and secured specifically for that function e.g. a READ ONLY account for anything that only reads or a WRITE only account who can't delete/update etc..etc..)

Well I can totally understand the intention behind that system, but I think there will be to many problems with that, which you can't really fix. The first thing is, that you have the SQL Server kind of exposed.

So if I get you right, you are thinking about this:

1. USER (got limited DB Access Credential, to let the tool connect to the DB) --> 2. USER should then provide his ID/PW and the DB will compare the hash --> 3. USER gets telnet data in return -> 4. USER establishing a telnet connection

So the things I dont get:
A) If you want some access to the DB, you need the credentials. If you give those to the user, why would the user play the "check my login name"? So instead of going form point 1 to 2, they could also start searching the db manually and get the data for point 3, without an ok-gm-login, cause (as far as i know) you would have to store the login info anywere the current DB login has access to. Even if not, you can still jump to plan B and start cracking the MD5 hash offline.
B) At point 4 the user got the data in his memory. Even if those things will be secure, which i doubt, cause decompiling all those .Net tools is terrible simple, we have another problem with esabtlishing the telnet connection afterwards. We are sending our sensitive command OTA with no encryption again. Even if you plan to do a funny lua-encryption (which won't be secure i guess), all those tricks will only work AFTER logging in. So the damage is already done.

There may be plenty of other ways to attack this "protocol" but those where the first on my mind.

Quote:

Originally Posted by c1ph3r For your "encryption": You know that it's pretty easy to load a c# program into a debugger to read your "throw away variables" decrypted? (This will work even with an obfuscated program!) Or you can decompile the program to get the encryption/decryption algorythm On top of that a telnet connection is never encrypted. IF you want you can read the pw from the network traffic. Login via cmdtelnet (no restriction) get sql pw for the dbusers. Login via the open sql connection that you tool needs and have a lot of fun on the hacked server!

Thats the long way short.


The main problem is the telnet usage. I think the easiest way to get that part a little more secure would be, to use hamachi again. As far as I know, they use AES 256 which should be sufficient for this case.

Quote:

Originally Posted by haxti Well I can totally understand the intention behind that system, but I think there will be to many problems with that, which you can't really fix. The first thing is, that you have the SQL Server kind of exposed. So if I get you right, you are thinking about this: 1. USER (got limited DB Access Credential, to let the tool connect to the DB) --> 2. USER should then provide his ID/PW and the DB will compare the hash --> 3. USER gets telnet data in return -> 4. USER establishing a telnet connection So the things I dont get: A) If you want some access to the DB, you need the credentials. If you give those to the user, why would the user play the "check my login name"? So instead of going form point 1 to 2, they could also start searching the db manually and get the data for point 3, without an ok-gm-login, cause (as far as i know) you would have to store the login info anywere the current DB login has access to. Even if not, you can still jump to plan B and start cracking the MD5 hash offline. B) At point 4 the user got the data in his memory. Even if those things will be secure, which i doubt, cause decompiling all those .Net tools is terrible simple, we have another problem with esabtlishing the telnet connection afterwards. We are sending our sensitive command OTA with no encryption again. Even if you plan to do a funny lua-encryption (which won't be secure i guess), all those tricks will only work AFTER logging in. So the damage is already done. There may be plenty of other ways to attack this "protocol" but those where the first on my mind. Thats the long way short. The main problem is the telnet usage. I think the easiest way to get that part a little more secure would be, to use hamachi again. As far as I know, they use AES 256 which should be sufficient for this case.

But even with hamachi you have to provide the telnet pw to the user and he is able to login via telnet to get everything he wants. The GS needs a full adminuser for the dbs! That means even if there are readonly accounts in the tool it's easy to get the servercredentials via telnet. The tool means full dbaccess+telnetaccess for the user. You can't fix that if the tool will login directly to DB and telnet!

Quote:

Originally Posted by c1ph3r But even with hamachi you have to provide the telnet pw to the user and he is able to login via telnet to get everything he wants. The GS needs a full adminuser for the dbs! That means even if there are readonly accounts in the tool it's easy to get the servercredentials via telnet. The tool means full dbaccess+telnetaccess for the user. You can't fix that if the tool will login directly to DB and telnet!

Sure. Hamachi is no solution for that problem. As i stated earlier, you would need another tool, to handle this properly. But Hamachi would make external access to the server more secure, as the password can't be read that easy. But telnet access should still be restricted to trusted members, which are allowed to access the server directly. This is the same security level.

I feel oblidged to point out that the GS does NOT require full privileged accounts. As-long as the permissions available to the telecaster user are: read/update/insert/execute(to execute smps) he will function just fine. (On this topic each name Telecaster/Arcadia/Auth should ALL be given VERY strict privileges based on their function [e.g. arcadia needs ONLY select permission]..by mapping the security schema's you also security lock each name to their respective db (meaning arcadia name can not touch Telecaster/Auth))

I explain creating a Restricted Privilege account for Telecaster (for use in InstaGM) [Only registered and activated users can see links. Click Here To Register...]

I have stated I felt from the beginning that since this tool is being converted to be able to do all actions to clip-board; the server owner should only give privileged information to those he can absolutely 100% trust. I said this from the beginning, all this talk about telnet insecurity and database opening should be common knowledge for anyone who works with Telnet/Database(sql) connections on a regular basis.

I appreciate the comments, at this point it seems that privileged access/info is being left up to the discretion of the Owner of the server. If you are not aware of inherent Telnet insecurity than you should not use this tool, if you do not wish database access from this tool it's as simple as not giving that information to your gm's (as again InstaGM by completion will be able to operate without Telnet/Database connections)

Thanks for the insight ^^

-- couple updates

I have removed the Items/States being sent to Clipboard/Itembox text and the items/states loaded from the item/buff tabs in order to be utilize the space available. New icons have been added to state the destination of items/buffs!

There is an entirely new menu design and more, hopefully v1.8.5 will release tonight, maybe not I still have to convert the player tab to be manual or automatic instead of only automatic/same with the summon tab. (Time has been short RL for me, sorry for this)

Here is a teaser to v1.8.5

[Only registered and activated users can see links. Click Here To Register...]

P.S.

The "name" field on the stab tab is being eliminated as the Description already contains the name, unfortunately this is not implemented yet as my son shut my computer off prematurely and my test dbs need restoration at this point :P (can't make a new list without dbs :D)

P.S.S.

Release of 1.8.5 deferred because what little time I had today was spent restoring another epic 5.2 auction house, I did manage to get the basis of the manual functions down for the player tab so the next release isn't far off thanks for being patient.