Userfile encryption with MD5

[Matta]

Why isn't MD5 used to encrypt the passwords in the userfile? That is probably the most widely used algorithm, and can be easily used from other applications to authenticate against the eggdrop userfile.

[Petersen]

blowfish is a slightly better algorithm (mainly due to the fact that its more complicated than md5, and thus takes longer to brute force). there ain't nothing stopping you using md5 for the crypto if you really want - just write an md5 module based on the blowfish module.

[Mapherick]

I remember raeky had an MD5 and a SHA1 module on his site (www.raeky.com, which is down now )

I'll see if i have it archived somewhere

[guppy]

I believe blowfish was around before md5 but I could be wrong. Either way, we don't change it because it would invalidate all the exist userfiles. Using md5 over blowfish .. there is no real strength gained or lost. No one decrypts passwords ... they just edit the userfile and put in a password they know :)

Jeff

[Mapherick]

If you set up your bot to use AES, SHA1 or MD5 over blowfish, you will gain security strength because putting in a 'password one knows' wouldnt work anymore. The hash in the userfile would have been generated differently from the hash generated at login. This would be actually very strong in combination with an encrypted conf file (I think i saw someone talking about it, don't remember who). If you run popular channels, you might want to implement this type of security as an extra security border. It doesnt take much more to do an 0-day SSH exploit than just good timing, but reversing the ELMs that contain the keys to either decrypting the conf file or hashing the passwords requires more skill than the average h4x0r has.

just a little rant.

PS: I found two modules, rijndael (AES) and SHA1, on one of my boxes. Will upload them to a somewhat faster public server soon. The rijndael is specificly made to replace blowfish in the userfile. Both algos are stronger than MD5 / BlowFish.

[guppy]

Uhm .. no one actually brute forces the passwords in a userfile. They just modify the config file and kill -HUP the bot or shutdown the bot, modify the userfile, and restart it. It doesn't matter if yer using Blowfish, MD5, etc ...

As for encrypted bot packs -- if your entire userfile is encrypted, there's no real reason to encrypt the passwords seperately. Also, 99% of botpacks are insecure and can be gotten around by anyone with half a brain in a couple of hours.

Jeff

[Mapherick]

First of all, here's the modules:
SHA1: http://mapherick.apl-productions.org/sha-1.6.3.tar.gz
AES: http://mapherick.apl-productions.org/rijndael1.0.tar.gz

Continuing the discussion:

Uhm .. no one actually brute forces the passwords in a userfile. They just modify the config file and kill -HUP the bot or shutdown the bot, modify the userfile, and restart it. It doesn't matter if yer using Blowfish, MD5, etc ...

So what happens when we encrypt the config file? Wouldn't that gain some strength in the above scenario? What about a module that checks the config file's CRC hash over the botnet and executes a remotely triggered cmd_die in the case of a failing CRC check? In short, there are many possible measures to prevent the above from happening.

As for encrypted bot packs -- if your entire userfile is encrypted, there's no real reason to encrypt the passwords seperately.

Yes, but that's not what I am trying to say. I actually think there's no real reason to encrypt the userfile entirely unless you have some privacy issues with hostmasks and the alike. What i meant was more of a form of "Security-Through-Obscurity". For example, if you systematicly change all the procedure names and procedure call names in your sources to something harder to understand before you compile, and make little smart use of encryption, the average 'they' will give up much sooner than when you dont.

What if i call my SHA1 module blowfish.so and even better: make this file the same size as the blowfish.so originally compiled with the eggdrop? I would like to see how long it's going to take some of the smarter people out there to figure that out. Eventually this will ofcourse be broken, but the time spent to break something custom can be used for reactive security measures.

Also, 99% of botpacks are insecure and can be gotten around by anyone with half a brain in a couple of hours.

Wouldn't it be a great challenge to decrease this percentage?

[ppslim]

So what happens when we encrypt the config file? Wouldn't that gain some strength in the above scenario?

No, this would either require a static key compiled into the binary, or one passed over the command line, which can then be read from memory.

What about a module that checks the config file's CRC hash over the botnet and executes a remotely triggered cmd_die in the case of a failing CRC check?

This would imply that you have a botnet.

Many users use eggdrop on servers which have services enabled and available. In this situation, the service does primary control, while eggdrop is there to do customisable automatic managment. As such, the need for a bot is only one.

The idea of using cmd_die is just stupid. Many eggdrop crackers will try and obtain access to the channel using a hack on the userfile. If this option isn't available to them, they will simply try and kill the bot. Your method would simply add fuel to the fire on killing a bot method.

What i meant was more of a form of "Security-Through-Obscurity".

Visit http://developer.microsft.com/job-application/ . MS would love to have you helping them

This is the worst kind of security you can have. You shouldn't hide the problems, you should fix them.

It may take twice as long to do, but running an strace on the bot with modified code, and one with unmodified can show the pattern of function calls. Eventualy, a map of how to get around this security can be obtained.

What if i call my SHA1 module blowfish.so and even better: make this file the same size as the blowfish.so originally compiled with the eggdrop?

straces on encryption functions would simply show that blowfish is not operating as it should.

If a cracker is smart enough to get onto the shell, and work through eggdrop without modification, they are only a few steps off doing the same with modifications.

Wouldn't it be a great challenge to decrease this percentage?

Yes it would.
Step 1: Force users to read documetation somehow (telepathy)
Step 2: Add bloat to eggdrop, to destingush if certain setting could pose security risk. Warn user at startup 500 times before going to background.
Step 3: Refuse to add all hostmasks on the ground they are weak, because the user doesn't understand the concept of how hostmasks work, and how they could relate to other users.
Step 4: Force user to change password every 12hours
Step 5: Give all shell providers a clue

Cracking eggdrop is usualy 99% down to user attitude. Some1 annoys the wrong person, they think they are same coz of there |337 eggdrop.

Once that part is done, it's 50% down to user security, and 50% down to shell security (statistics taken from the back of my head).

Unless a owner understads security, and tries to do somthing about it, they are wide open.

The rest is down to picking the right shell provider. Most shove a box on the net with a software firewall on it. Woopy doo, what does this do apart from provide a way for the admin to block ports. He still has to have them wide open for SSH, HTTP, TELNET, FTP and IDENTD. They pretty much fail to update software. This is all down to the afct, they want to show a poxxy nice uptime on there webpage.

If my shell provider rebooted once a motnh, it wouldn't matter. So long any security explots are blocked between, unless it would compromise system stability and usage, in which case, ti should be done immidiatly.

Why should we buld security into eggdrop, for the purpose of protecting a shell providers system or prettecting the clueless users?

[Mapherick]

ppslim,

I sense alot of cynism in your post, i hope i'm not stepping on someone's toes by giving out my thoughts

No, this would either require a static key compiled into the binary, or one passed over the command line, which can then be read from memory.

I don't say it's perfect, but perfect security doesn't exist anyway. That's not what I'm going for here. Good security does exist and that's my goal.

I am conveinced that if NASA started to write their own operating system or modify the standards, their intrusion rate would become drasticly lower. If it would work for them, why wouldn't it work for us?

Many users use eggdrop on servers which have services enabled and available. In this situation, the service does primary control, while eggdrop is there to do customisable automatic managment. As such, the need for a bot is only one.

I am not aiming at those users that have services on their IRC networks. I am unlucky to have lived my e-life on EFNet so far and thus for me, and with me 80k other EFNet users, bots are the primary security measure (next to ofcourse the 'new' chanfix.) Securing the security is actually what I am trying to do.

The idea of using cmd_die is just stupid. Many eggdrop crackers will try and obtain access to the channel using a hack on the userfile. If this option isn't available to them, they will simply try and kill the bot.

Oof! You're right, thanks. I'm actually really scared of doing -bot, but maybe a 'force unlink' flag, like how +d works for users, would do. Near perfect segmentation of the bottree in combination with trusted hosting of the main hub would ofcourse be demanded. As for just killing the bot, forced startup from remote should be possible (costs a process tho)

This is the worst kind of security you can have. You shouldn't hide the problems, you should fix them.

I never said anything about not fixing problems. Look at it as an extra layer.

If a cracker is smart enough to get onto the shell, and work through eggdrop without modification, they are only a few steps off doing the same with modifications.

From what i experienced personally, most takeover people aren't THAT sophisticated. I wouldn't even call the most of them crackers, rather 'scriptkids' (was trying to avoid this term.) I'm not underestimating people, it's just that most of the takeovers are not sophisticated and I'm sure the largest part is caused by leaked passwords.

One and a half year back, a russian IRC server was 'hacked' to do a big takeover. It succeeded, by using an (i think ssh) exploit and modifying the ircd.conf. I spoke to the 'hacker' some time later and he told me he was learning to reverse (on windows) and learning some asm because he only knew vb and pascal. I am sure that when the ircd.conf would've been encrypted, the kid would prolly have given up or his 'hack' wouldn't have been stealthy after a while.

Step 1: Force users to read documetation somehow (telepathy)
Step 2: Add bloat to eggdrop, to destingush if certain setting could pose security risk. Warn user at startup 500 times before going to background.
Step 3: Refuse to add all hostmasks on the ground they are weak, because the user doesn't understand the concept of how hostmasks work, and how they could relate to other users.
Step 4: Force user to change password every 12hours
Step 5: Give all shell providers a clue

Especially step 3 is very true. Security is the opponent of functionality. The more functionality you remove, the more secure your eggdrop will be, and the more security you add, the lesser functional the eggdrop will be. For this reason i remove everything i dont use from the sources, the identify function is always off, masters/owners have no hostmasks attached to their user record, dcc chat is off, just a few examples.

However, if someone who implements eggdrop for security doesn't care about security and doesnt read manuals, isn't interested in best practises and doesn't get a strategy on security, then is such user worth worrying about?

Cracking eggdrop is usualy 99% down to user attitude. Some1 annoys the wrong person, they think they are same coz of there |337 eggdrop.

Security is ALWAYS down to user attitude. And guess what, i never had no ignorant users, anywhere. Next to that, someone who can permit to annoy the wrong person because the security is tight would have alot more fun. Anyone can probably remember from his youth not to [censored] around with the big boys, unless you like to be beaten up, that is.

Unless a owner understads security, and tries to do somthing about it, they are wide open.

I guess that's what i'm trying to do: to do something about it.

[ppslim]

I was not trying to critisise your post intentionaly, more make a point the harsh way.

All your points are true, however, there are flaws in the system, as there would be in any method to secure eggdrop more.

I am conveinced that if NASA started to write their own operating system or modify the standards, their intrusion rate would become drasticly lower. If it would work for them, why wouldn't it work for us?

Rather true.
However, this is at OS level.
In our case, the OS is the shell provider or the eggdrop user, and this we can't change.

Oof! You're right, thanks. I'm actually really scared of doing -bot, but maybe a 'force unlink' flag, like how +d works for users, would do. Near perfect segmentation of the bottree in combination with trusted hosting of the main hub would ofcourse be demanded.

The force unlink flag is allready available.

For this reason i remove everything i dont use from the sources, the identify function is always off, masters/owners have no hostmasks attached to their user record, dcc chat is off, just a few examples

This is the responisbility of the user.

Remember, as you stated, the more security you add, the less functionality.

The goal is to provide a functional bot, with the ability to secure it and add features at the same time. This is available allready, you just have to read the documentation, and spend time looking after the problem.

However, if someone who implements eggdrop for security doesn't care about security and doesnt read manuals, isn't interested in best practises and doesn't get a strategy on security, then is such user worth worrying about?

Exactly. Why should the development team, or any1 else for that matter, provide script/code to add security to eggdrop (as above, thus removing functionality), for a user that can't be bothered doing it themselves.

They don't need scripting knowledge to add secuirty. Many of eggdrop's settings can be changed to close a lot of areas.

Once this is done, the only real means of access is through insecure hostmasks, or via the shell. One again, is down the user, and the other is the shell providers problem. Thus, eggdev can't do anything about this.

In genral - we should be trying to educate users, not give out free "get out of [censored] fast" patches.

Example:

Before moving home, I was involved in a 60 to 80 bot botnet (varied from day to day). My main area was related to the botnet security.

Most of my ideas where tutorial based. Giving our users a list of settings, how they affect security and the best value for them.

My best friend is involved in cracking (at least he likes to think he is, he mainly hangs in the channels, gives out +n and invites trouble). He had a 7 bot botnet, linked directly into our master hub (Limbo bot, due to high load - very busy scrited botnet - which I owned).

He would monthly have to rebuild his bots from scratch, using new passwords (he would even have to rebuild other botnets, because he did not know where the information leaf was from) and everything. This would be due to a channel takeover.

Once every 3 months, the same takeover king would come to our channel, and threaten it. He would try an take it, but there was no success.

This was down to one thing. The security that I had helped to impliment.

All MSG commands where banned, with the exception of ident, which was rebound to myident (lame yes, but a crude and effective way (yes, this probably is security through obscurity, but can you tell me any other method of providing a ident command)) and config settign being changed to the most secure value.

AT the time, the person concerned with trying to takeover was in probably the second best tae over ground on EFnet.

Now throught he carefull selection of shell providers,a nd the careful use of settings and hostmasks, it has been proven that you can have a secure botnet and takeover free channel.

[Mapherick]

In our case, the OS is the shell provider or the eggdrop user, and this we can't change.

Point taken.

The force unlink flag is allready available.

I should rtfm more often, so I actually remember what I read

Exactly. Why should the development team, or any1 else for that matter, provide script/code to add security to eggdrop (as above, thus removing functionality), for a user that can't be bothered doing it themselves.

They don't need scripting knowledge to add secuirty. Many of eggdrop's settings can be changed to close a lot of areas.

Should security scripts/mods be made on request only then? I can't really imagine someone who doesn't have coding experience to know exactly what should be secured. For example, by testing a modified cookieop script for a friend, I suddenly realized the problem of bot authentication, while I had been running a botnet for over 2 years prior to that, without any takeovers. I did *some* assesments on my net, but really, do we expect eggdrop users to do a complete security audit on their bot(s) before they implement it? I would have that done for my business, but I think that even I wouldn't have done audits if I didn't put efforts into security a little more than a year back, because my boss asked me to.

How many eggdrop users know skilled and willing hackers to assist them on their security assessment job? Or what percentage is skilled enough to do it themselfes?

Once this is done, the only real means of access is through insecure hostmasks, or via the shell. One again, is down the user, and the other is the shell providers problem. Thus, eggdev can't do anything about this.

If I run my net of a shell provider that is insecure, the problem would be mine as well. Even worse, if a FreeBSD coder doesn't care about security and my provider runs it, it's still my problem. If there would be some providers that actually did apply all patches on 0-day, whom I think do not exist as of yet, the solution would be simple. However, since there is as far as I know no such thing as a trusted commercial shell provider, the solution isn't that simple and we might want to look into dealing with those problems.

You said that we should fix problems and not hide them, I would like to add that we shouldn't run away from them or ignore them either.

In genral - we should be trying to educate users, not give out free "get out of **** fast" patches.

True, increasing security awareness is always a good thing to do, although in this case it's not a simple task to put yourself to.

All MSG commands where banned, with the exception of ident, which was rebound to myident (lame yes, but a crude and effective way (yes, this probably is security through obscurity, but can you tell me any other method of providing a ident command)) and config settign being changed to the most secure value.

DCC might be more secure in protocol than MSG, but a DCC console does offer a lot more functionality (and thus insecurity).

Example: What I used to do is restricting +p to masters and keep only the msg:op. On my channels, the botnet is divine, the ops are just privileged users on the channel, not on the botnet. Ops are NOT trusted. I started with this after the only takeover I ever had to deal with was done by a trusted insider, not an outsider. If he would have had console access and in a worse case, ident access, I'm sure it would've been much more of a mess and I wouldn't have had the channel back after 2 hours.

The only complete solution I can think of is having a second, dcc:op only, dcc chat option where ops can op themselfes, and ban all the MSG commands.

[ppslim]

Example: What I used to do is restricting +p to masters and keep only the msg:op. On my channels, the botnet is divine, the ops are just privileged users on the channel, not on the botnet. Ops are NOT trusted. I started with this after the only takeover I ever had to deal with was done by a trusted insider, not an outsider. If he would have had console access and in a worse case, ident access, I'm sure it would've been much more of a mess and I wouldn't have had the channel back after 2 hours.

Other methods available are flood protection.

We have too flood levels. One very sensitive to users, and one less sensitive to bots. With the adition of no more than 3 duplicated modes per incoming mode command.

IE, a users would be removed from the channel after only 6 mode changes of -o (2 mode lines).

Bots where kicked after 9 (3 lines)

There is no reason to have bots sending modes at more than 3 -o or +o per line.

This flood protection meant that even a trusted user, could not use the bot, or his own clients to mass deop.

Granted, this would only work on large channels, or rahter, channels with a high population of bots.

Other protection methods, done through scripts included tree based mass deop kicks.

IE
Bot1 sets mode +o SubOp1
SubOp1 sets mode +o Lame1, Lame2, Lame3
Lame1, 2 and 3 set modes +o to many drones

2 scripts are in use:
One on 2 3rd's of the bot net.
This will deop the drones, and the person that set them +o
It will also provide an API for emergancy userfile mangment via the botnet

This leaves SubOp1, who is trusted (+o upwards)
The second script, ont he rest of the bots, would first kick SubOp1
It would then use the userfile API to remove all occurinaces of SubOp1's host from userfiles, and then set the user +d on all bots, including Bot1
If Bot1 is not longer linked tot he botnet, the it is segrigated and set +d, to prevent this misuse coming back

This script system, will go back into the tree of OP's, until it reaches a trusted bot. In this case, Bot1 was trusted. This stop point is implimented, so that the bots do not try kicking themselves, due tot he fact they OP'd Bot1 in the first place.

This, while very advanced, is all scriptable (and in use (or at least was)).

While you can setup a channel, to be very secure without this. When you run a MP3 channel (not mine, but I help out in controled scripting), floods happen, and users go bad. When you have a split net, where bots can't be controled via the botnet, you will never have full control. This sort fo script can help inmprov the control, without the need for a botnet link.

[Mapherick]

I think it's nice to conclude that eggdrop can be secure if properly used. That should be the message to those who are security aware, because i feel that many (more sophisticated) botmasters don't know that eggdrop is possibly saver than their own, self-coded botpacks which will almost always have lots of bugs.

I will start on writing the .conf CRC'ing module however, but will not distro it out of my own domains unless someone asks for it. Looks to me like a nice middle-of-the-road solution.

Let's have the security discussion some time later again since this is way too offtopic right now

[lordares]

guppy:
Some people DO brute force blowfish passwords. Happend to me last month. Some guy brute forced a password of an owner on a leaf bot shell he hacked into, then used it to gain hub access.

[ppslim]

Just the same way any password can be brute forced.

Regardless of the alogrythm in use, there isn't much that can be do to counter this.