encrypting userfile

[bisco]

hi guys,
is there a way to encrypt not only the users' passwords, but the entire user file? it should be a nice feature.

thanks

[Alchera]

hi guys,
is there a way to encrypt not only the users' passwords, but the entire user file? it should be a nice feature.

thanks

I am unaware that there is. I am also not sure of what benefit, if any, this would be.

[demond]

there are many ways, and many implementations of that, all private, typically developed & used by takeover groups on EFnet/IRCnet to prevent their botnets from being "owned" by other monkeys utilizing cracked shell accounts & forged userfiles/scripts

this works as long as your enemy don't have a clue what to do with your stolen eggdrop binary - which typically isn't the case - as soon as a programmer loads it into a debugger, it's a simple matter of time until they crack your encryption, since you keep the encryption key embedded into that binary anyway

[bisco]

I haven't illegal shell accounts, I want to prevent that if someone has access to one of mine accounts, he can't modify userfile making easy a takeover.
I used a private botpack that encrypt all files of eggdrop, but it is an older version and there are many problems to build it; obviously, I'm not able to modify this botpack using new versions of eggdrop.

On some websites, I read that the blowfish module can encrypt userfile, but there is no explained way to do it.

can you help me?

PS: sorry for my english..

[KrzychuG]

Look here for efprintf references, then download whole (or at least *user*.c files) source code and find rest of code. In userent.c you'll find few function which saves most of user data to userfile. Some parts are in flags.c, some in userrec.c or users.c. You need to dig for it. It's a bot based on Eggdrop 1.6.16 so you should be able to match most of the code with modern eggdrop and find out the diffrences.

[demond]

Look here for efprintf references, then download whole (or at least *user*.c files) source code and find rest of code. In userent.c you'll find few function which saves most of user data to userfile. Some parts are in flags.h, some in userrec.c or users.c. You need to dig for it. It's a bot based on Eggdrop 1.6.16 so you should be able to match most of the code with modern eggdrop and find out the diffrences.

what's the point of public domain encryption that carries its key within itself? every crackhead out there will break that in a heartbeat

the whole point of encrypting whatever is NOT to provide the key to unauthorized parties

[KrzychuG]

Who said that key is public? In case i presented it's random (generated by another program) or set by user (up to 32 chars as far as i remember). Yes, it's stored somewhere in binary but you won't get it out so easly as you think. Besides, the point of uf encryption method i presented is to show how can it be done now how it should be done. That's one of the simplest and nicest solution, but not the only one.

There is always a chance that such userfile will be decrypted and because there are no 100% sure methods Eggdrop will not support userfile encryption by default. No matter what i don't see a reason to forget about it and abandon that topic. It is still a problem for some lamers who usually taking part in IRC wars and believe me, it helps.

I my old botpack i used compressed chanfiles just for fun or to save few bytes on HDD (reason is not really important). Quite a lot of peole who used that botpack had troubles with reading it and even though it's encrypted somehow. Since people have troubles with reading doc files (where i mentioned that chanfile is compressed) they won't handle it ;)

[De Kus]

The only way to give encryption some little use would be to make the key used to be entered on start up (and therefore be only avaible in memory and not on hard disc). Of course that way your bot will nolonger be able to restart via cron . The possibility to read the eggdrops memory will most likely depend on the kernel used.

[demond]

Who said that key is public?

I meant your source code that you provide to a public forum, not the key

Yes, it's stored somewhere in binary but you won't get it out so easly as you think.

not me (although 10 years ago I might have given it a try), but the crack monkey who broke into your shell account and stole the binary; what makes you think that cracking a known protection scheme (you made your code public, remember?) is harder than cracking, say, Windows apps that you don't have source code of? and such are being cracked each and every day by the dozens

Besides, the point of uf encryption method i presented is to show how can it be done now how it should be done. That's one of the simplest and nicest solution, but not the only one.

I'd concur the point of all that is mostly educational - and not much more than that

[demond]

The only way to give encryption some little use would be to make the key used to be entered on start up (and therefore be only avaible in memory and not on hard disc). Of course that way your bot will nolonger be able to restart via cron . The possibility to read the eggdrops memory will most likely depend on the kernel used.

you got that right - "little use" - but not because of the reason you think

the bad guys, after breaking into your shell, would typically get root and install sniffer and terminal logger, so typing in the key will be, as you put it, of little use

[KrzychuG]

not me (although 10 years ago I might have given it a try), but the crack monkey who broke into your shell account and stole the binary; what makes you think that cracking a known protection scheme (you made your code public, remember?) is harder than cracking, say, Windows apps that you don't have source code of? and such are being cracked each and every day by the dozens

Just give it a try and feel free to post results. I suggest you to check psotnic source code as well. You may be suprised.

You assume that every person who gain access to shell account and steal binary is a a good cracker? Don't forget that quite a lot of people playing those stupid wars, bots are using popular exploits and doesn't really know much about cracking. They're mostly a kids who want to have fun. At least that's how IRCnet looks like today. Some of them can't even handle compressed file without proper extension or header. That's the real word, not everyone is a proffesionalist and such, let's say, protection is always better that pure, fully viewable and editable userfile. There is always a chance that thief will give up tryin'.

In evangeline case even non-ecrypted userfile won't help you to add users since bot won't load file with diffrent MD5 checksum.

[nml375]

A few things worth mentioning on the subject:

1. Encrypting your userfile does'nt help much unless you also encrypt/checksum any file parsed as a tcl-script (such as config-file, channels, file, scripts).
2. In many cases strace is available (and as stated by some poster above, this is entirely up to the shell-admin setting up the kernel). Makes a nice dump of the userfile every time it's saved (prior encryption).
3. Security by obscurity many times have the downside of making you believe your system/application/service is secure when it really is'nt

This said, there's nothing wrong with applying encryption/checksums.. Just don't think it'll make a great contribution to your bot's security/integrity.
Personally tho, I'd put more effort into preventing intrusion/shell compromize in the first place...

[KrzychuG]

1. In my case userfile is also protected by MD5 checksum set in encrypted file hidden in tcpro compiled script ;) Config file isn't a tcl script, channel file is left almost untouched (except MD5 checksum check). If user will enable possibility to load custom tcl scripts that's the small security risk he have to agree with ;)
2. strace won't help too much. You won't be able to see the key and even if you stop process in the middle of writing you won't get clear userfile. It's saved line by line. There is no raw data stored anywhere (except memory for a short ammount of time).
3. Point.

Well, usually you don't have any affect on shell security since you're just a client (in most cases), not an admin and even if encrypted files aren't 100% secure (because they aren't) it's always better than nothing in case of any unexpected visitors. That's my personal oppionion, no matter if it causes some troubles with updating that software and can be cracked.

[nml375]

Config-file is evaluated like any other script...

Try this at the end of your config-file:
adduser haxxor "haxxor!*@haxxors.host.com"
setuser haxxor pass haxxor
chattr haxxor +n

Then just kill -SIGHUP pidofbot

You'll find it behaving much like if putting it in any other script...
Same thing goes for channels-file...

As for strace, password would still be encrypted yes (since it's encrypted in a checksum-fashion), rest of the output would still be in plaintext, giving evil haxxor a login-name and a passwdhash to use for bruteforce/dictionary cracking. And there's quite a few script-kiddie programs out there for just that sinlge purpose :/

And once again, there's nothing wrong with adding extra encryptions, as long as you keep in mind it does not improve security against any malicious hacker with atleast some programming/debugging experience..

Checksumming do however provide some security; not by guaranteeing that all files are untouch, but that any file failing checksumming is certainly compromized (taken granted that the tools and list of correct checksums are properly protected)

[rosc2112]

2. strace won't help too much. You won't be able to see the key and even if you stop process in the middle of writing you won't get clear userfile. It's saved line by line. There is no raw data stored anywhere (except memory for a short ammount of time).

Hm..maybe I'm naieve, but if there's raw data stored in memory, wouldn't you be able to simply run this through debug and get it?