Someone pointed me to a problem with the module. On quick review of 7.x, there are major problems. Here's one:

sso_multi_domain/spacer/%/%, a router item accessible to everyone, invokes the page callback sso_multi_domain_spacer_image($hash, $url) :

function sso_multi_domain_spacer_image($hash, $url) {

  $url = base64_decode($url);
  $url = $url . '/' . $hash;
  // Send request to retrieve user details stored using unique hash.
  $response = drupal_http_request($url);
  if ($response->code == 200) {
    // Decodes the json data returned by requested url.
    $login_data = drupal_json_decode($response->data);
    // Process login procedure if we status is 1 returned by web service.
    if ($login_data['status'] == 1) {
      $username = $login_data['username'];
      $password = $login_data['password'];
      $user_data = $login_data['account'];

      // Decrypts the username and password.
      $username = sso_multi_domain_decrypt_string($username);
      $password = sso_multi_domain_decrypt_string($password);

      // Check if an account with given username exists or not.
      $account = user_load_by_name($username);

      // If account do not exists.
      if (!$account) {
        $is_registration_allowed = variable_get('sso_multi_domain_allow_registration', 0);

        // Check if registration allowed for this domain or not.
        // If registration allowed then call create account function to create
        // the user account.
        if ($is_registration_allowed) {
          sso_multi_domain_create_account($account, $username, $password, $user_data);
        }
      }
// Elided...  
    }
  }
}

So, it appears that if sso_multi_domain_allow_registration is enabled, an attacker can provide as "url" a base64_encoded URL of a website _the attacker_ controls and have it provide JSON with a nice username and any role they desire on the target site.

Mind you, this is all from code review, not actual testing.

Additional issues will be incoming.

CommentFileSizeAuthor
#7 sso_multi_domain-add_secret_key-2361503-7.patch1.98 KBMax_Headroom
#6 sso_multi_domain-add_add_secret_key-2361503-6.patch1.98 KBMax_Headroom

Comments

heine’s picture

heine commented
Title: sso_multi_domain_allow_registration » Security issue: Create users with chosen roles.
varunmishra2006’s picture

varunmishra2006 commented

@Heine

I can sort out this security rist by doing following things:-
1) In the admin section we will provide a text field for the unique secret key.
2) After that when I will generate the hash, it will be combination of secret key and current time.

This is way no can predict the hash value.

Let me know if that sounds ok?

terramedia’s picture

terramedia commented

@varunmishra2006

Did you end up rolling your suggested fix into this module? I'd love to try it out on a new multisite I'm working on if the security issue is resolved.

varunmishra2006’s picture

varunmishra2006 commented

@terramedia

I am in process of writing more secure version of this module which will not have the above mentioned security issue.

asifnoor’s picture

asifnoor commented

@varunmishra2006

Were you able to place a fix for this? I am planning to use this module.

Max_Headroom’s picture

Max_Headroom commented
Status: Active » Needs review
StatusFileSize
new sso_multi_domain-add_add_secret_key-2361503-6.patch1.98 KB

Based on the comment in #2 I created a patch to add a secret key to the hash.
I can not comment if this would increase the security, so please test.

Max_Headroom’s picture

Max_Headroom commented
StatusFileSize
new sso_multi_domain-add_secret_key-2361503-7.patch1.98 KB

Ignore last patch. fixed an issue.

thummel’s picture

thummel commented

Is the security issue limited to the account creation and role sync? I hope to use this module for sso only. No account create or role synce. Instead, I'm sharing the user and role tables between 3 drupal sites.

Thank you,
Tracey

mc0e’s picture

mc0e commented

See also https://www.drupal.org/node/2361529.

It seems unlikely that the issues with this module will be resolved any time soon.

MattWithoos’s picture

MattWithoos commented

I keep coming across this module in my Google searches and I'm incredibly disappointed it is still around and not deactivated into a sandbox project.

I came here to follow up on this comment in user Heine's original issue post:

Mind you, this is all from code review, not actual testing.

I now have a Proof-of-Concept script that confirms this vulnerability and it's quite disconcerting given it didn't take me that long and there are 200+ (reported) sites with this module. I have tested it locally and confirmed it is no longer just theoretical - it is a literal reality. In fact, access concerns aside, one could theoretically fill a Drupal site with millions or billions of bogus users simply by calling that URL in a loop.

The script doesn't even need a Drupal install.

I am not sure how the above patch would solve anything at all. The hash can be made up. There is no verification on the hash prior to creating a user.

The author has published other modules, with similar security issues. I would caution anyone using this module, or any other module by this author. There may be other issues (in fact, there are others for this module), both in this module and others (in fact, the author has open security issues for at least one other module I checked).

MattWithoos’s picture

MattWithoos commented

Hiding this patch as it doesn't solve the issue here... all it does is make a legitimate iDP site more legitimate. Doesn't solve the issue of an illegitimate iDP site/script/hacker providing a made-up hash. The hash is only used to retrieve or confirm a record within the module's own self-created database. Encrypting it further is helpful for edge-cases but is better posted to another issue.