New issue
Advanced search Search tips
Starred by 9 users
Status: Fixed
Owner:
Closed: Feb 2016
Cc:

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
MalwareBytes: multiple security issues
Project Member Reported by taviso@google.com, Feb 2 2016 Back to list
[[ This issue is a duplicate of issue 615 and issue 631, but with the hardcoded RC4 key censored. MalwareBytes are concerned that publishing the RC4 key could be damaging, and while I'm quite certain anyone interested in the key is capable of figuring it out, I agreed to censor it ]]

Malwarebytes updates are not signed or downloaded over a secure channel.
========================================================================


MalwareBytes fetches their signature updates over HTTP, permitting a man in the middle attack. The protocol involves downloading YAML files over HTTP for each update from http://data-cdn.mbamupdates.com. Although the YAML files include an MD5 checksum, as it's served over HTTP and not signed, an attacker can simply replace it.

It's possible the developer believed that an attacker cannot tamper with the data, as it's encrypted with the hardcoded RC4 key `████████████████████████████████` for configuration data, and `████████████████████████████████` for definitions. However, this is not the case. The following openssl commands can be used to decrypt, edit, and then re-encrypt the definitions and configuration data:

For configuration data:

$ openssl enc -rc4 -d -nosalt -in net.conf -K ████████████████████████████████ > net.conf.txt

For definitions, which are also deflate compressed:

$ openssl enc -rc4 -d -nosalt -in rules.ref -K ████████████████████████████████ | zlib-flate -uncompress > rules.txt

Therefore, this scheme is not sufficient to prevent tampering and the developer should sign them.

There are numerous simple ways to turn this into code execution, such as specifying a target file in the network configuration, writing a new TXTREPLACE rule to modify configuration files, or modifying a Registry Key with a REPLACE rule.


Malwarebytes uses incorrect ACLs allowing trivial privilege escalation.
=======================================================================

MalwareBytes stores it's configuration and definitions in %PROGRAMDATA%, but the default ACLs permit all Users the ability to create and modify files. This is trivial for unprivileged users to exploit and become SYSTEM.


C:\>icacls "%PROGRAMDATA%\Malwarebytes\Malwarebytes Anti-Malware"
C:\ProgramData\Malwarebytes\Malwarebytes Anti-Malware NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
                                                      BUILTIN\Administrators:(I)(OI)(CI)(F)
                                                      CREATOR OWNER:(I)(OI)(CI)(IO)(F)
                                                      BUILTIN\Users:(I)(OI)(CI)(RX)
                                                      BUILTIN\Users:(I)(CI)(WD,AD,WEA,WA)

Successfully processed 1 files; Failed processing 0 files

C:\>dir "%PROGRAMDATA%\Malwarebytes\Malwarebytes Anti-Malware"
 Volume in drive C has no label.
 Volume Serial Number is 4A36-A1CA

 Directory of C:\ProgramData\Malwarebytes\Malwarebytes Anti-Malware

11/09/2015  01:07 PM    <DIR>          .
11/09/2015  01:07 PM    <DIR>          ..
10/05/2015  09:46 AM             2,025 actions.ref
10/05/2015  09:46 AM                92 akadomains.ref
10/05/2015  09:46 AM                92 akaips.ref
11/05/2015  01:14 PM    <DIR>          Configuration
10/05/2015  09:46 AM           267,877 domains.ref
10/05/2015  09:46 AM                 0 exclusions.dat
10/05/2015  09:46 AM            18,787 ips.ref
11/05/2015  01:14 PM    <DIR>          Logs
11/05/2015  01:14 PM    <DIR>          Quarantine
10/05/2015  09:46 AM        10,258,263 rules.ref
11/09/2015  01:07 PM                 0 swissarmy.ref
               8 File(s)     10,547,136 bytes
               5 Dir(s)  24,273,035,264 bytes free

The configuration files are encrypted with the hardcoded symmetric RC4 key `████████████████████████████████` for configuration data, and `████████████████████████████████` for definitions. The following openssl commands can be used to decrypt, edit, and then re-encrypt the definitions and configuration data:

For configuration data:

$ openssl enc -rc4 -d -nosalt -in net.conf -K ████████████████████████████████ > net.conf.txt

For definitions, which are also deflate compressed:

$ openssl enc -rc4 -d -nosalt -in rules.ref -K ████████████████████████████████ | zlib-flate -uncompress > rules.txt

Symmetric RC4 encryption does not authenticate or prevent tampering of configuration or definition files. An unprivileged attacker can easily create a hostile rule or configuration to execute arbitrary code, such as writing a new TXTREPLACE rule to modify configuration files, or modifying a Registry Key with a REPLACE rule


TXTREPLACE rules are not context aware
======================================

Malwarebytes has various classes of rules, such as PESECTION, DIGISIG and REPLACE. The TXTREPLACE rules specify simple patterns that should be substituted if found. There are hundreds of rules like this that do not understand context that they execute in, and can result in remote code execution.

For example, consider this rule:

TXTREPLACE=PUP.Optional.ChatZum, %FFPROFILE%\prefs.js,browser.startup.homepage*chatzum.com, browser.startup.homepage",,"https://www.malwarebytes.org/restorebrowser/

An attacker can arrange for a preference to contain the string browser.startup.homepage=chatzum.com, and the action would result in incorrectly substituting new code.


ACTIONs can result in remote code execution
===========================================


Malwarebytes defines several custom cleanup procedures for various detection rules, these are called ACTION's, and are generally a list of commands to execute. Several ACTIONs, like BRWSRFLSH_ACTION and CLRSHORT2_ACTION, attempt to programmatically generate visual basic scripts or batch files, and then run them. These scripts do not adequately handle untrusted input and can result in remote code execution.


This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

 
Project Member Comment 1 by taviso@google.com, Feb 2 2016
Status: Fixed
MalwareBytes have published an advisory for this issue.

https://blog.malwarebytes.org/news/2016/02/malwarebytes-anti-malware-vulnerability-disclosure
Project Member Comment 2 by taviso@google.com, Feb 2 2016
Issue 615 has been merged into this issue.
Project Member Comment 3 by taviso@google.com, Feb 2 2016
Issue 631 has been merged into this issue.
Comment 4 Deleted
Project Member Comment 5 by taviso@google.com, Feb 8 2016
Labels: Restrict-AddIssueComment-Commit
Sign in to add a comment