|MalwareBytes: multiple security issues|
|Project Member Reported by firstname.lastname@example.org, 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.
Feb 2 2016,
MalwareBytes have published an advisory for this issue. https://blog.malwarebytes.org/news/2016/02/malwarebytes-anti-malware-vulnerability-disclosure
Feb 2 2016,
Issue 615 has been merged into this issue.
Feb 2 2016,
Issue 631 has been merged into this issue.
Feb 8 2016,
|► Sign in to add a comment|