mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Dec 2003
Posts: 6
D
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
D
Joined: Dec 2003
Posts: 6
Hi there,

I have an idea how to stop all .ini based worms/virii/backdoors:

It's able to block all DCC operations. It is also already able to block /run and /dll operations.

How about adding an option for blocking socket operations (most scripts doesn't use them) and file operations by default? The User would just have to activate them if he needs 'em. And I say, who activates such functions, that person (at least should) knows what (s)he does.

"Okay, man ... most virii just overwrite the .ini file. That wouldn work for a protection of getting infected. The virii will make new settings and same as before..."

Not quite. A possible, but very effective way to prevent worms/virii to activate locked functions would be this: Grab the serial number of the hard disk/partition (see checkdisk) and encrypt it with a good key. Maybe also with a second registry key. Worm/Virii programmers will search a very long time for a solution.

"With this, you would lock out 'normal' scripts from being loaded." - That's not quite true. The user could activate those functions in the options with one single mouse click and all would work like before.

What if mirc finds an ini file what isn't conform? Well, mirc would enable the lock for such options. The user would have an option in the options menu to import (maybe backuped) files or ready-made scripts.

Is that an idea?


--
Someone already paid for your fault: Jesus Christ.
Joined: Jan 2003
Posts: 3,012
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
First, I just wanna say that it is viruses not virii. Same with syllabus. It's syllabuses, not sylabii.

Second, most *viruses* and trojans acome with mirc already. I can almost bet that 99% of the viruses are installed without the user's persmission, and not by them installing an ini file themselves. Same with most software, mIRC trojans are usually compiled first, then released. They put together a script to distrubute, then load it.

I don't see how stopping other mIRC commands will fix this.


-KingTomato
Joined: Mar 2003
Posts: 1,271
L
Hoopy frood
Offline
Hoopy frood
L
Joined: Mar 2003
Posts: 1,271
problem 1: if you block all DCC operations, helpchannels will be flooded with users complaining that the new mIRC won't let them send/receive files anymore.

problem 2: users who intend to share files will either turn it off themselves, or ask someone else how to turn it off. Since those people generally use the aforementuioned scripts, we're back at square one.

problem 3: how does grabbing the serial of the HD prevent anything? And what if I change my HD?

I maybe a little uptight about this, but I do not see a reason for Khaled to go out of his way to protect ignorant people. It's the whole attitude that's a problem. What you are suggesting further diminishes the need of mIRC users to show a little responsibility. If they would take a moment to get to know the program they're using, to not install junk when they have no idea what it does, this wouldn't be a problem. Same with people typing up strange code when a stranger gives it to them and tells them to type it out. People who act so irresponsible imho only get what's comiong to them, and there is nothing anyone can do to stop it. Should this suggestion become a reality, Those people who created the trojans to work will find a way to get around it, and the people who you are trying to protect this way will get suckered into it again, and we're back at square one.

Make something idiot-proof, and the world will make a better idiot.


DALnet #Helpdesk
I hear and I forget. I see and I remember. I do and I understand. -Confucius
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
I think it should be possible to block or put a warning on file write operations, perhaps sockets too although it wouldn't be at all hard for a trojaner to make their script connect to a server and send the info over an IRC-based connection instead. However if you get to that level of command restriction I think it would have to be able to be set on a per-script-file basis (and also for the command-line of course), since people could often have different scripts which they trust to varying degrees. I certainly don't think any such options should be on by default though, it would cause way too many disruptions.

I don't think protection from an imported ini file is really needed, if people are stupid enough to load the settings provided with a script they don't trust then that's their own fault.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Or lets just go the next step and create a fully customizable sandbox with enable/disabled commands and scopes. Even go as far as different permission levels for each script, defining the directory(s) it has access to and such...

Of course this would be exceedingly complex, but I see no other way everyone would be happy.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2003
Posts: 6
D
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
D
Joined: Dec 2003
Posts: 6
@ KingTomato:
I never answered on spelling flames on UseNet, and I don't do it here.

@LocutusofBorg
Hmmm I think you didn't quite catch what I meant.

I was talking about SHS/VBS/whatever files that simply overwrite the mirc.ini file. Not more, not less. MANY of them spreading over IRC via socket operations, i.e. the ROL.VBS worm

And: My idea was to disable ON SOCKET, SOCKLISTEN etc. commands by default, but if the user needs them, to enable them in the options.

About the drive serial: Well, mirc stores settings in the mirc.ini file. So I just wanted to create a protection what makes it not possible to re-enable that locked functions by simply replacing the .ini file. Not less, not more. I just wanted to put some obstacles in the way that makes it difficult for viruses/worms/however-KingTomato-would-call-them to spread/activate some TYPICAL functions.

The thing is: Users who know what they're doing, they will activate functions manually (and I guess, they won't open I'm-soooo-sexy.jpg.bat.pif.vbs.html.shs.com.exe files). Users who don't, they can just use mIRC for what it's made for: chatting. Now, often they just wonder why they get banned/killed/k-lined etc. and cannot use the server at all - and cannot ask ANY help channels because they can't connect.

@Raccoon
Surely, there is no ABSOLUTELY protection. But imagine this:
Maybe you have a high security door with camera, fingerprint detection, eye scanner, 16-digit PIN code, voice acknowledge and five locks with high security level what never can be picked by unauthorized persons. And you have an open garage at the back side of the house that is open by default and has a simple door to your kitchen. If you've got an intruder, where would he enter the house? My idea was just to close the garage door; if somebody need it to open, he would do it. smile


--
Someone already paid for your fault: Jesus Christ.
Joined: Jan 2003
Posts: 3,012
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
The spelling correction was simply an fyi. It was not intended to 'flame' your ability to spell, or use grammar. I was just letting you know how it was spelled.

As for the restriction to certain commands, there are already /run and /dll restriction built into mirc. Such restriction still haven't stopped trojans and virsuses, how would a socket restriction do so? As I already mentioned, any form of worm or virus installed on a clients computer comes as a package, not a single mrc or ini (or a group of them for that matter). Its almost always an exe that installs a customized mIRC version, configuration, and harmful files. So any and all restriction put onto a task or group of tasks would already be null and void.

Additionally such a restriction wouldn't go far. Why would people download a mirc that comes with all these new handy protections when there is already (several) versions without such protections? The idea of getting version 6.13, 6.3, or even 7.0 just so they can bypass it would be idiotic.

With the url warning box, users who still, at that point, can't see reason enough to not want to continue on to a website with 7 different extensions almost deserves what happens. mIRC gives plenty of warning to the user about opening a url over the internet adnd how it may be harmful. At some point common sense has to enter, and not programmed protections.


-KingTomato
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Quote:
And you have an open garage at the back side of the house that is open by default and has a simple door to your kitchen. If you've got an intruder, where would he enter the house? My idea was just to close the garage door; if somebody need it to open, he would do it.

Don't forget to put bars on the 40 open first-floor windows.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 349
S
Fjord artisan
Offline
Fjord artisan
S
Joined: Dec 2002
Posts: 349
And where would mirc store its key? The rol.vbs method of infection you mentioned can be used to launch any payload of any type, as an .exe the trojan would have access to the same information the mirc.exe does. Maybe mIRC could use an obscure encryption of some sort, but the point of encryption is to keep data safe even when the decryption method is known, how long would it take for someone to figure it out?

I think the first 'stop' shouldn't be restricting commands/identifiers, but simply stopping mirc from loading the files in the first place. With a 'safe' .ini, we could hopefully assume that the remote files in the list are legit. mIRC could also monitor the .ini and remove remote files that 'appear' in its rfiles section while it's running. Keeping its own version of the .ini in memory and flushing it to disk on close/at set durations would make modifying the .ini rather pointless (nearly). A mutex on the file could prevent read/write access, but would kinda stuff up multiple instances.

To LocutusofBorg: my mIRC should be more insecure than it has to be because of 'ignorant people'?..... Righhhht.

Joined: Oct 2003
Posts: 29
I
iRP Offline
Ameglian cow
Offline
Ameglian cow
I
Joined: Oct 2003
Posts: 29
I've got something to add to this that I've been thinking of. That is to add a warning message like the one that popups before visiting a URL when you execute the /run and possibly/optionally the /dll command???


Good job Khaled for 140,100+ lines of source code!!!

Link Copied to Clipboard