Sharetronix <= 3.1.1 Two PHP Code Injection Vulnerabilities

Sharetronix 3.1.1.3, 3.1.1, and earlier allows remote attackers to execute arbitrary PHP code via the (1) activities_text parameter to services/activities/set or (2) comments_text parameter to services/comments/set, which is not properly handled when executing the preg_replace function with the e modifier.

Recent assessments:

wchen-r7 at September 12, 2019 6:07pm UTC reported:

According to the advisory: <http://karmainsecurity.com/KIS-2013-11&gt;

1. Input passed via the “activities_text” POST parameter to /services/activities/set is not properly sanitised before being used in a call to the “preg_replace()” function with the “e” modifier in the /system/classes/class_post.php script. This can be exploited to inject and execute arbitrary PHP code.

2. Input passed via the “comments_text” POST parameter to /services/comments/set is not properly sanitised before being used in a call to the “preg_replace()” function with the “e” modifier in the /system/classes/class_postcomment.php script. This can be exploited to inject and execute arbitrary PHP code.

And: No official solution is currently available (at the time of advisory publication).

Downloaded Sharetronix 3.1.1 from the official website and found it:

• class_postcomment.php

  $message = htmlspecialchars($this->comment_message);

  if( FALSE!==strpos($message,‘http://’) || FALSE!==strpos($message,‘http://’) || FALSE!==strpos($message,‘ftp://’) ) {
  $message = preg_replace(‘#(^|\s)((http|https|ftp)://\w+[^\s[]]+)#ie’, ‘post::_postparse_build_link(“\2”, “\1”)’, $message);
  }

• class_post.php

  $message = htmlspecialchars($this->post_message);
  if( FALSE!==strpos($message,‘http://’) || FALSE!==strpos($message,‘http://’) || FALSE!==strpos($message,‘ftp://’) ) {
  $message = preg_replace(‘#(^|\s)((http|https|ftp)://\w+[^\s[]]+)#ie’, ‘post::_postparse_build_link(“\2”, “\1”)’, $message);
  }

Unfortunately, in both cases, htmlspecialchars is called over \(this->comment_message or \)this->post_message, so, evenwhen the preg_replace with /e flag is there, you need “ to scape, unfortunately htmlspecialchars is htmlencoding ” (double quotes).

I guess it was silently patched or something like that, unfortunately, I haven’t access to older versions, I can’t find nothing in the vendor homepage :(

Assessed Attacker Value: 0
Assessed Attacker Value: 0Assessed Attacker Value: 0