egghelp.org community

[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
_________________
free your mind!

[Alchera]

[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
_________________
connection, sharing, dcc problems? click <here>
before asking for scripting help, read <this>
use [code] tag when posting logs, code

[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..
_________________
free your mind!

[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.
_________________
Que?

[demond]

[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 ;)
_________________
Que?

[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.
_________________
De Kus
StarZ|De_Kus, De_Kus or DeKus on IRC
Copyright © 2005-2009 by De Kus - published under The MIT License
Love hurts, love strengthens...

[demond]

[demond]

[KrzychuG]

[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.
_________________
Que?

[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)
_________________
NML_375, idling at #eggdrop@IrcNET

[rosc2112]