Forums Bug Reports Social Engineering Exploit (Severity: Low)

I can't believe anyone (or that even I) hasn't thought of this before. Perhaps they have. At any rate better safe than sorry.

mIRC does not strip 0x0A (line feed) from text the user enters into the editbox or generally text sent to the server by scripts or whatever.

Because of this, any command that takes parameters and sends them to the server also sends the 0x0A character. This is important because IRC servers use this to determine the end of a command and the beginning of a new one (ie the new command is on a new line).

So, if I user is convinced to run a one-line script that generates a 0x0A character, it will do more than they may expect.

Ok I rambled on too much. Here is a proof of concept to make it clearer:

//say This is a cool script! $+ $chr(10) $+ QUIT :it makes me quit the server

Or, the person could disguise it with $encode and $decode:

//[ $decode(bXNnICNHYW1lU3BpZmYgSSBIQVRFIE1aWlQKUVVJVCA6Q0FVU0UgSEUgTUFLRVMgTUUgUVVJVA==, m) ]

(This will cause the user running it to quit the server they are connected to, after saying a line of text to the active channel.)

Of course, this exploit can not do nearly as much damage as a well-crafted /run command. Thus I give it a low severity. If a user can be tricked

The reason I bring it up at is it that it would be relatively easy to modify the mIRC commands for /say /msg /me /describe /notice, etc etc etc so that they strip any 0x0A characters before sending their text to the server. This can be done in the low level code that dispatches raw text to the server.

Misc Notes:
Character 0x0D (carraige return) seems to be stripped off by mIRC along with any characters following it before being sent to the server.

This cannot be used to execute programs or scripts on the local computer, only IRC server commands.

Tricking a user to execute a script which sends it's parameters to the server multiple times with a 0x0A in there will have a multiplicable effect on the exploit and can be used to make a person flood off the server or earn them a kline.

mIRC will not be aware the extra command was sent, however for most commands (except PRIVMSG) IRC clients usually do not need to keep track of commands sent since servers will reply with text the client can act on (such as, for NICK or JOIN, the server will let mIRC know if it has joined a channel or has had it's nick changed. mIRC does not need to care if the user executed a JOIN or NICK command).

Testing this proof-of-concept on other people was fun >_>

Worst things that could theoretically be done with this:
- Trick people into saying things on the server that they may never see locally (since PRIVMSG is never echoed back to the user who sends it).
- Tricking a user into quitting the server, either with a QUIT or PRIVMSG :IRCOP UR GAY LOL
- Tricking a user into dropping a nickserv nick, a chanserv channel, or changing passwords for either of these, or changing any account info for those.

The charactor is not interpreted by the server, it never reaches the server.

In an example such as //say test $+ $chr(10) $+ test. It is evaluated before being sent. So in this example if you do not have a 'test' alias you will recieve an 'test Unknown command' error. the reason quit works is because there is an internal /quit alias.

To be honest, i dont particularly see how this is much of a risk, if your silly enough to copy/paste a command when you dont know what it does then theres a lesson learnt. (the very same lesson learnt if you paste //say test | quit test). I dont really see it is any risk in premade scripts either, because shoving a line like "//say bla $+ $chr(10) $+ quit bla" in the script is really no different than putting it on two seperate lines fex:
"//say bla"
"quit bla"

Using chr 10 like that is no different than using chr 124 (pipe). As for all intensive purposes they seem to be treated pretty much the same by mirc.

Not exactly. The "test Unknown command" error is actually received from the server, which let you know that the server doesn't know this command. This means it did infact reach the server.

This is the raw:

• 
  421 ERR_UNKNOWNCOMMAND
  "<command> :Unknown command"
  - Returned to a registered client to indicate that the
  command sent is unknown by the server.

Type //debug @debug, and test that example again.

Should look something like:

-> Zagreb.HR.Eu.UnderNet.org PRIVMSG #cellka :test<linefeed>test
<- :Zagreb.HR.Eu.UnderNet.org 421 FiberOPtics test :Unknown command

Your right, easy mistake but at closer examination mirc does infact return in the same error format, but with the command name in capitals.

I stand corrected, in which case i agree it could be a problem. Maybe mirc should force evaluate a $chr(10), and then treat the line feed in the same manner as it does a pipe? shrug

Limiting mirc (except for $decode maybe, which really has no use in command line) to "protect" users is a really bad idea and only ends up annoying users. A lot of people use this feature (which you call exploit) to send multiple commands to the server in one packet (thus eliminating any delay between those commands, a common example is ban+kick) and wouldn't like to see it gone.

The argument "users can be tricked" isn't valid because users can be tricked into typing/doing anything. Why should LF sending be disabled and not for example /run? Or /remove? Or $findfile()? I could go on forever listing commands that are 10 times more dangerous than allowing LFs. The point is, mirc shouldn't be crippled because some users don't know better than typing whatever they're told on IRC. The best you can do for these types of problems is user education: help channels, websites etc.

Yes, I did mention that there are worse things that can be done with social engineering, especially involving /run

I've been scripting for years (I'm a sad IRC addict >.>) and I've never ran into a situation where the speed of packets has mattered to me when sending out commands to the server.

Perhaps LF filtering could be an option that's on by default, so if one uses a script that uses it (I can't imagine why or how though, given my above stated experience and since we have /raw) it could be allowed.

And like I said, it's low severity.

if your gonna con them into typing that just get them to type this

//say I am unstopable no one can hurt me, i wont be stoped! if you want to quit fighting me or not click one of these >>> | Quit | Fight |

I say If someones gonna type somethings stupid theres no stopping them!

Agreed. People need to learn not to type things. If they aren't going to be that smart, then they should suddenly find themselves being QUIT from the server so that they are then smarter and maybe won't type stuff like that again.

i like replying to people who send the to be OP message type /blaqh bvalh $decode blah balh

i send them one back (using a second nick since they normally have u on ignore) thats a encoded line also, but when it decodes it says "OMG I CANT BELEIVE YOU RAN THIS, I COULD HAVE DELETED YOUR HARD DRIVE" in a nice $input window :-)

This seems to get the message across to them quite well.

LOL nice