Revision as of 19:45, 27 December 2013

Template:mIRC Guide

mSL injection is a code injection technique that exploits mIRC's ability to dynamically evaluate code on the run. With mSLs powerful commands and identifiers, the result of a code injection attack can be disastrous. It is important that you understand what to look for when working with vulnerable commands.

This tutorial will try to summarize for you what commands are problematic, how to detect it, and how to fix it.

An eval injection vulnerability consists of two things:

• A script that evaluates a code (via a vulnerable command/ident)
• User input that is not properly validated

The 3 most common commands that possess the ability to dynamically evaluate code are the /timer, /scon, and /scid commands. The $eval() (and its aliases $() and $evalnext()) can also dynamically evaluate code.

The /timer command

Perhaps the most problematic command of them all is the /timer command. The timer command is unique in its behavior has in addition to the way things are evaluated normally, everything passed to the timer is evaluated a second when the timer is triggered.

Let's take a look at an innocent reminder script:

on *:text:!reminder & *:#:{
  timer 1 $2 notice $nick [Reminder] $3- (Set $2 seconds ago)
}

When the correct input is provided, this script works wonderfully. For example:

<Mike> !reminder 18000 jill's birthday tomorrow!
-Bot- [Reminder] jill's birthday tomorrow! (Set 18000 seconds ago)

Although this script might seem simple and innocent, let's that a look at what happens when someone provides incorrect or even malicious as in this case, input:

<Mike> !reminder 0 . | ns drop nick | quit hacked! | noop
-Bot- [Reminder] . (Set 0 seconds ago)
* Bot (~Bot@isp.example.com) Quit (Quit: hacked!)

What Mike in our example has performed is known as mSL injection attack. He provided an input which was interpreted to be part of the bot's which in term executed and caused the bot to quit. Let's take a deeper look into what has happened. After the message Mike typed the bot dropped his nickname and left IRC.

When the timer activated, it will held the following code:

notice Mike [Reminder] . | ns drop nick | quit hacked! | noop (Set 0 seconds ago)

Clearly, you can see how the timer command can be extremely dangerous. The unfortunate part is that there is no clean way of solving this problem. The way we recommend to solve this problem is by encoding the input using based64 encoding. Below is an alias to perform this:

alias safe return $!decode( $encode($1-, m) ,m)

Our new !reminder script looks like this:

on *:text:!reminder & *:#:{
  if ($2 !isnum) {
    notice $nick [Reminder] Syntax Error: !reminder <seconds> <message>
    return
  }
  timer 1 $2 notice $nick [Reminder] $safe($3-) (Set $safe($2) seconds ago)
}

/scon and /scid

Both of these commands were created to evaluate code on a given server. Just like the /timer command, any user input must be escaped somehow (via a variable or encoded).

Consider this less practical example:

on *:text:!global *:#:{
  scon -at1 amsg [AMSG] $1-
}

The script is designed to do a global amsg (i.e. perform an /amsg on every active connection). Just like the timer command, $1- will be evaluated again in the specified connection which means any user code will become part of your bot's code.

Other notable problems

$readini() and $read()

If you have visited our help channel, #mSL, and you had some code that used $read() or $readini() without the n switch you would most likely had people yelling at you to always use it. But why? The reason is:

By default BOTH $read() and $readini() treat the text in the file as code!

So what are some of its consequences? Consider the following greet script:

on *:text:!setgreet*:#:{
  if (!$2-) { notice $nick Syntax Error: !setgreet <greet> | return }
  writeini greets.ini greet $nick $2-
  notice $nick [Greet] Greet Saved.
}
on !*:join:#:{
  if ($readini(greets.ini, greet, $nick)) {
    msg $chan [[ $+ $nick $+ ] $v1
  }
}

Let's see what happens:

<Mike> !setgreet
-Bot- Syntax Error: !setgreet <greet>
<Mike> !setgreet Two things are certain in life, death and taxes. - Benjamin Franklin
-Bot- [Greet] Greet Saved.
/hop
* Rejoined channel #foobar
<Bot> [foobar] Two things are certain in life, death and taxes. - Benjamin Franklin
<Mike> !setgreet Hello $findfile(C:\, *, 1, quit hacked!)
-Bot- [Greet] Greet Saved.
/hop
* Rejoined channel #foobar
* Bot (~Bot@isp.example.com) Quit (Quit: hacked!)

In this example Mike used the fact that $findfile() can execute a command when it finds a matching file. It should be clear how dangerous this can be.

So how do we fix it? Using the n option!

$read(... , n, ...)
;and 
$readini(..., n, ...)

Our new code would look like this:

on *:text:!setgreet*:#:{
  if (!$2-) { notice $nick Syntax Error: !setgreet <greet> | return }
  writeini greets.ini greet $nick $2-
  notice $nick [Greet] Greet Saved.
}
on !*:join:#:{
  if ($readini(greets.ini, n, greet, $nick)) {
    msg $chan [[ $+ $nick $+ ] $v1
  }
}

$calc()

ALL input to $calc should be validated. Since $calc has its own special evaluation routine, it possesses the ability to evaluate variables from within text. Consider the following code:

//var %x = 12345 | tokenize 32 % $+ x | echo -a $1 = $calc($1)

Which will produce the following result:

%x = 12345

Surprise! We bet you did not expect that to happen. (This is actually a side effect of $calc being able to evaluate variables inside parenthesis or immediately after an operator without a space.)

Now let's take a look at a more practical example:

; Assume %password is set to 123456
on *:connect:{
  autojoin -d5
  if ($network == UnderNet) {
    msg x@channels.undernet.org login Wiz126 %password
  }
}
on *:text:!calc *:#:{
  msg $nick [Calc] $2- = $calc($2-)
}

Like most people, this user has an on connect event to register his user and a simple !calc script.

Let's see what Mike can do to him:

<Mike> !calc 3*5+55
<Wiz126> [Calc] 3*5+55 = 70
<Mike> !calc %password
<Wiz126> [Calc] %password = 123456

It's clear how Mike was able to get the value of a pretty important variable.

It's important to note that EVEN if %password was set to "1234rosebud". The $calc() will return "1234", which is not the whole password but it's a big chunk of it.

$chan and sometimes $nick

Just because $chan doesn't come directly from the user's text doesn't make it any less dangerous. Use $safe($chan) EVERYWHERE!

mIRC allows prefixing an identifier with the pound sign to make mIRC prefix (if needed) the evaluated string the pound symbol. For example:

//tokenize 32 A #B | echo -a #$1 #$2

This will produce the following result:

#A #B

So what does that have to do with $chan and timers? Everything!

Consider the following bot:

alias bot_pass return foo_bar_42
on *:connect:{  
  autojoin -d5  
  ns id $bot_pass
}
on *:invite:#:join #
on !*:join:#:{
  timer 1 2 notice $nick Hello $nick $+ , Welcome to # $+ !
}

Everything works just fine under normal conditions. What Mike knows better than to testing things under normal conditions:

* Now talking in #$($bot_pass)
/invite foobar #$($bot_pass)
* Bot joined #$($bot_pass)
/hop #$($bot_pass)
* Attempting to rejoin channel #$($bot_pass)
* Rejoined channel #$($bot_pass)
-Bot- Hello Mike, Welcome to foo_bar_42

Because $chan (or #) was not escaped, it was evaluated. Mike was able to evaluate the $bot_pass alias and get the bot's password.

So how do we fix it? Simple! Use the $safe alias to encode the channel!

; ...
alias safe return $!decode( $encode($1-, m) ,m)
on !*:join:#:{
  timer 1 2 notice $nick Hello $nick $+ , Welcome to $safe(#) $+ !
}

Note: On some really obscure networks, $nick is actually allowed to have $. Watch out!