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:
llRequestURLin 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:
executepermission 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
executepermission sparingly to groups.
systempermission. They can then dump the file to some external service and recover it. As for
execute, you should grant the
systempermission 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
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
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.
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
MACof the network card can in some cases be changed, the
ID0could be used to track your bot's movements on various grids you may connect to.
callbackto 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
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,
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
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:
#!/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 126.96.36.199-188.8.131.52 -j ACCEPT iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -m iprange --dst-range 184.108.40.206-220.127.116.11 -j ACCEPT iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -m iprange --dst-range 18.104.22.168-22.214.171.124 -j ACCEPT iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -m iprange --dst-range 126.96.36.199-188.8.131.52 -j ACCEPT iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -m iprange --dst-range 184.108.40.206-220.127.116.11 -j ACCEPT iptables -A OUTPUT -p tcp -m owner --uid-owner corrade -m iprange --dst-range 18.104.22.168-22.214.171.124 -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
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
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
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.