We present the possible attack vectors for Corrade and the methods used to mitigate the attacks in the following chapters. Here is a quick checkpoint list:

• Is the configuration file properly secured?
• Are your groups granted access to only the notifications and permissions they really need?
• Are you allowing outbound connections from Corrade only to trusted servers or the grid you are connecting to?
• Are you properly limiting the resources Corrade can use?
• Are you using llRequestSecureURL instead of llRequestURL in LSL scripts?

An attacker could possibly recover the MD5 non-salted SecondLife account password from Corrade's configuration file. This could be accomplished in the following ways:

• If you have Corrade on shared-hosting, then the configuration file can be read by a different user if they know the path. You should look into Windows ACLs and on Linux POSIX ACLs to secure files containing sensitive information.
• If you have execute permission set to a group and a user of Corrade uses the execute command, then they can overwrite the configuration file over the wire. You can mitigate this attack by granting the execute permission sparingly to groups.
• The configuration file can be read by using the configuration command, which, is protected by the system permission. They can then dump the file to some external service and recover it. As for execute, you should grant the system permission sparingly to groups.

The MD5 could be reversed given MD5 weaknesses into a password - otherwise, if the MD5 is compromised, then an attacker will be able to use it to log into the SecondLife website account with the MD5 hash. In case the MD5 hash is compromised, make sure you change the password as soon as possible by logging-in to SecondLife and changing the account password.

Additionally, the group password that Corrade uses to identify users could be read if your script is full-permission. The same can be accomplished using the system and execute permissions in case configured groups have access.

To avoid these issues, make sure your scripts are not full permission. It is currently not possible to read a script if it is not full-permission - regardless of the method. For more information on copying items, please see our modified viewers section.

Corrade benefits from a per-group configurable database which is not encrypted or protected in any way. An user could potentially read the database using the system and execute permissions as well as potentially alter the databases given operating system permissions.

To mitigate such attacks, please make sure that the databases have appropriate ACLs set and that Corrade is not running with elevated privileges. Corrade uses flat-file SQLite per-group databases such that cross-database attacks should not be possible.

Corrade can be used to root your box in case you have the execute permission set for a group and a user with your group password in Corrade uses the execute command - this is simply because the execute permission allows a granted group to run any command on your box under the same privileges that Corrade runs on.

You should grant the execute permission sparingly ' to configured groups as well as use the operating system's ACL system to run Corrade with low privileges (ie: do not run Corrade as root or Administrator with the execute permission granted unless you want to be able to run superuser commands with Corrade).

Furthermore, depending on your application, you may want to not run Corrade with elevated privileges. Instead, create a new group and a new user and run Corrade under its own user and group.

Corrade implements mechanisms via the Windows User Account Control (UAC) that temporarily elevate privileges only when necessary. Nevertheless, if UAC is turned off, or running Corrade on a non .NET compliant platform, be aware that the execute command will make Corrade execute a user supplied command under the same privileges of the user running Corrade.

Corrade should be impervious to in-world annoyances ("grieving", whatever…). If you want to secure the bot even more, make sure that you only use the permissions and notifications that you really need and disable the ones you do not need.

Since Corrade is controlled via scripts and will listen to commands over instant messages, it is wise to place Corrade in a "safe" location. For example, if you need a Corrade bot to do some group management of a highly populated simulator, there is no reason why Corrade should be on the same simulator. In the event that the simulator goes down, Corrade will still be able to perform the group management.

Corrade completely ignores any requests from scripts that do not supply a correct group and password pair such that DoS attacks from attackers without any sort of access to Corrade are highly unlikely to depend on a Corrade misconfiguration.

Nevertheless, it is worth mentioning that Corrade will try to satisfy requests to the operating system's limits such that enabling notifications that need to pass large amounts of data will slow your bot down.

• The grid that Corrade connects to is capable of determining your IP address.
• All Linden viewers have to send a MAC - a hash of the network card MAC address and an ID0 - a hash of the identifier of the first disk drive on the system. While the MAC of the network card can in some cases be changed, the ID0 could be used to track your bot's movements on various grids you may connect to.
• Configured groups and people that are allowed to use your bot can by default determine the bot's IP address. They can accomplish that by setting a callback to a server controlled by them, and, since Corrade does not connect through the grid to deliver the callback, then they would just read the IP address. To mitigate this attack, please see the limiting outbound callbacks section.

Also known as Man-In-The-Middle (MITM); these attacks can be performed in case the URLs used to pass data to and from Corrade occur through HTTP instead of HTTPs.

However, Corrade is happy to use HTTPs URLs and, if you are programming in LSL, you should favour the usage of llRequestSecureURL for passing data back into SecondLife instead of llRequestURL.

Note that Corrade does not send group passwords back to callback URLs.

Similar to GITS (or MITM), since users can refer to in-world primitives by name and furthermore since primitive names are not unique, then an avatar could possibly inject their own primitive to impersonate a primitive that Corrade is supposed to interact with.

To mitigate such cases, llSensor and llSensorRepeat can be used to retrieve the UUID of a primitive you are looking for and then pass the UUID of the primitive instead of the name to Corrade commands. Furthermore, referring to primitives by name carries its own performance penalty so it is best avoided.

Corrade does not use any unsafe .NET constructs and is thus safe from memory overflows such as buffer overflows that would facilitate the overwrite of memory locations.

Corrade accepts by default any URL to be passed as a callback parameter. That means that depending on the script, users may be able to send data to any web-server which may lead to Corrade's IP being revealed. In case that is undesirable, then the recommended option is to limit Corrade's outbound connection to Second Life's IP range.

On Windows, this involves using the Windows Firewall service to allow Corrade.exe's outbound connections only to the following IP ranges that represent the official Linden Labs registered simulators (including login servers):

If you are using Linux, provided that Corrade runs as the system user corrade, the following script will restrict all outbound traffic to Linden Labs' IP block:

corrade_firewall.sh

#!/bin/sh
## Whitelist all connections from the corrade system user to Linden Labs IP blocks.
## Corrade must run under the user corrade for this to work.
iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -m iprange --dst-range 8.2.32.0-8.2.35.255 -j ACCEPT
iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -m iprange --dst-range 8.4.128.0-8.4.131.255 -j ACCEPT
iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -m iprange --dst-range 8.10.144.0-8.10.151.255 -j ACCEPT
iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -m iprange --dst-range 63.210.156.0-63.210.159.255 -j ACCEPT
iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -m iprange --dst-range 64.154.220.0-64.154.223.255 -j ACCEPT
iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -m iprange --dst-range 216.82.0.0-216.82.63.255 -j ACCEPT
iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -j DROP

This only works if Corrade runs under the user corrade - as the provided init scripts do. To check what user Corrade runs under, issue:

ps aux | grep mono

and you should see the following output:

corrade  32698  5.4  1.9 280816 39812 ?        Sl   01:45   0:35 /usr/bin/mono /srv/Corrade/Corrade.exe

The first column lists corrade as the user running /srv/Corrade/Corrade.exe.

With the firewall in-place, if we try to access any outbound IPs in the callback parameter. For example, by triggering a stand command with a callback to http://www.google.com:

        llInstantMessage(CORRADE, wasKeyValueEncode(
            [
                "command", "stand",
                "group", GROUP,
                "password", PASSWORD,
                "callback", "http://www.google.com"
            ])
        );

we will notice the following error:

Donald Duck (354fd715-7e19-4486-bb19-eee1cb5ec511) : command "stand" for group "[Wizardry and Steamworks]:Support" has "succeeded" with error code "42" and message "stood".
Feedback to URL "http://www.google.com" failed to be sent with error message "The request timed out".

which indicates that we were unable to access the URL.

It seems that at the time of writing (and before) all secure URLs generated via llRequestSecureURL are, in fact, not secure since the certificates generated by Linden Lab have an unknown issuer problem due to being self-signed certificates. Furthermore, more of the same applies to other grid-services that need to make HTTP requests such that Corrade has no way of mitigating this flaw and accepts certificates blindly. The problem is that an user is left wide-open to a MITM attack such that it is at least recommended to use packet-level filters (such as a firewall) in order to ensure that Corrade connects to the right servers - one solution is provided on this page and globally restricts outbound connections to SL servers for the Corrade process. Adding encryption and combining with packet-level filters matching the LL IP ranges should at least ensure that Corrade connects to only whitelisted IPs and uses encryption to secure data transmission; albeit, not an ideal solution but nothing can be done here unless LL decides to generate a wildcard certificate for all their LL generated URLs.

Various commands and configuration options may be used to make Corrade non-compliant with the SecondLife ToS and/or EULA, however, it is up to the owners of Corrade bots, and that of Corrade service providers, to not disable ToS and/or EULA compliance features as well as to not use Corrade for activities that would break the rules established by Linden Lab. Corrade provides the means to use the SecondLife protocol to the full extent of what is not enforced by server-side checks, yet, as with any other third-party viewers, it is up to the user to ensure that they are not violating either Second Life regulations or third-party rules imposed by in-world asset or land holders.