egghelp/eggheads community

encrypting userfile

2006-08-05T09:13:11-04:00

In this case I can only assume they've gone even further in code modifications, since that's what I generally use one those rare occasions when I *cough*forget*cough* which passwd I used...

md5sums on channels-file would be a good idea, as it's read (atleast in plain eggies) using "readtclprog"..
Then again, injecting evil code in the very short window of oppertunity from where the bot saves the channels-settings at the start of the rehash, until it's re-read, would be quite difficult (but not impossible)

I do admit I was wrong on strace

Statistics: Posted by nml375 — Sat Aug 05, 2006 9:13 am

encrypting userfile

2006-08-05T02:36:55-04:00

Config-file is or +nevaluated 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

That won't work. Config file isn't just a tcl script and it's quite limited:

Code:

.tcl exec cat cfg/test.cfgTcl: #Evangeline: Config File (For Evangeline v1.0+)Tcl:Tcl: nick "test"Tcl: altnick "test?"Tcl: botnet-nick "test"Tcl: realname "-=test=-"Tcl: username "test"Tcl: listenport 1024Tcl: ircservers { poznan.irc.pl:6663 lublin.irc.pl:7776 warszawa.irc.pl:6667 krakow.irc.pl:6667 }Tcl: #my-ip ""Tcl: #my-hostname ""Tcl:Tcl:Tcl: ## DON'T TOUCH ANYTHING BELOW ##Tcl: loadstart [clock clicks]Tcl: servers $ircserversTcl: logfile mcobxsk * "logs/${botnet-nick}.log"Tcl: userfile "${datadir}${botnet-nick}.uf"Tcl: chanfile "${datadir}${botnet-nick}.cf"Tcl: adduser haxxor "haxxor!*@haxxors.host.com"Tcl: setuser haxxor pass haxxorTcl: chattr haxxor +nTcl: #Evangeline: IPV4 Config.rehash[08:22:29] #KrzychuG# rehashRehashing.[08:22:29] Rehashing ...[08:22:29] * IRC NICK CHANGE: e222 -> test[08:22:29] Loaded Evangeline Config: 'cfg/test.cfg'[08:22:29] Trying to open telnet port(s)...[08:22:29] Listening at telnet port 1024 (all)[08:22:29][08:22:29]  --------< Bot's Info >---------[08:22:29]  Version....: 1.1.2, 1.3.3[08:22:29]  Name.......: test[08:22:29]  IP Address.: System Default IP[08:22:29]  Port.......: 1024[08:22:29][08:22:29]  Completed loading in 0.121338s[08:22:29]  -------------------------------[08:22:29][08:22:29] Loaded Evangeline Userfile: '.data/.bdata/test.uf'.[08:22:31] NICK IN USE: test (keeping 'e222')..match *[08:22:41] #KrzychuG# match **** Matching '*':HANDLE          PASS NOTES FLAGS           LASTKrzychuG        yes      0 jmnoptx         08:20 (partyline)  HOSTS: -telnet!*@*--- Found 1 match.

Then just kill -SIGHUP pidofbot

And what should happend? It won't rehash since 'kill on hup' is enabled.

With chanfile you may be right, i never checked it but AFAIR it's MD5 checksum protected so should be secure as well.

With strace you won't be able to see anything about userfile except that it's writted or read. With gdb you may even not connect to already running bot (if ptrace protection is enabled) and even if you'll be able to do that you won't see plaintext userfile.

Statistics: Posted by KrzychuG — Sat Aug 05, 2006 2:36 am

encrypting userfile

2006-08-05T02:02:47-04:00

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?

Statistics: Posted by rosc2112 — Sat Aug 05, 2006 2:02 am

encrypting userfile

2006-08-04T19:50:03-04:00

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)

Statistics: Posted by nml375 — Fri Aug 04, 2006 7:50 pm

encrypting userfile

2006-08-04T19:21:38-04:00

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.

Statistics: Posted by KrzychuG — Fri Aug 04, 2006 7:21 pm

encrypting userfile

2006-08-04T14:33:56-04:00

A few things worth mentioning on the subject:

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).
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).
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...

Statistics: Posted by nml375 — Fri Aug 04, 2006 2:33 pm

encrypting userfile

2006-08-01T14:32:35-04:00

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.

Statistics: Posted by KrzychuG — Tue Aug 01, 2006 2:32 pm

encrypting userfile

2006-08-01T00:22:51-04:00

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

Statistics: Posted by demond — Tue Aug 01, 2006 12:22 am

encrypting userfile

2006-08-01T00:11:53-04:00

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

Statistics: Posted by demond — Tue Aug 01, 2006 12:11 am

encrypting userfile

2006-07-31T11:10:15-04:00

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.

Statistics: Posted by De Kus — Mon Jul 31, 2006 11:10 am

encrypting userfile

2006-07-29T11:53:19-04:00

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 ;)

Statistics: Posted by KrzychuG — Sat Jul 29, 2006 11:53 am

encrypting userfile

2006-07-29T10:07:10-04:00

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

Statistics: Posted by demond — Sat Jul 29, 2006 10:07 am

encrypting userfile

2006-07-29T12:14:25-04:00

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.

Statistics: Posted by KrzychuG — Sat Jul 29, 2006 9:56 am

encrypting userfile

2006-07-29T04:24:58-04:00

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..

Statistics: Posted by bisco — Sat Jul 29, 2006 4:24 am

encrypting userfile

2006-07-28T23:22:06-04:00

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

Statistics: Posted by demond — Fri Jul 28, 2006 11:22 pm