Title: Snuffleupagus versus recent high-profile vulnerabilities Date: 2019-07-01 20:30 According to [Halvar Flake's](https://twitter.com/halvarflake/status/1125169161125158913)'s laws, exploit mitigations are only useful if they, at least: - Have a clear threat model; - Don't add a crazy lot of complexity/significantly hinder performances/make everything undebuggeable; - Render a couple of real-world past bugs unexploitable. [Snuffleupagus](https://github.com/nbs-system/snuffleupagus) being almost 2 years old, it's time to look back and check if the project is doing a decent job. If it does not, all its hardening mechanisms should be removed, to only keep the virtual-patching capability. - The threat model is laid out in the [documentation](https://snuffleupagus.readthedocs.io/features.html) - Regarding complexity, Snuffleupagus is around 4400 lines of (clean) C code, with a coverage close to 100%, and its configuration is as [straightforward](https://snuffleupagus.readthedocs.io/config.html) as it could be. We tested its syntax by making a pool of sysadmin and devops write some rules, and we didn't get a single complain. Nobody opened a single issue on our bugtracker about it. - Performance-wise, it [doesn't have a measurable impact]({filename}/php/snuffleupagus_0.3.0.md) - Debugeability isn't hindered: Snuffleupagus logs every disruptive action it takes, along with the line number, the file name and can even dump the whole request if wanted: if it detects something, it will tell you precisely where, when and why. So the only remaining question is: Does it kill vulnerabilities? ## Drupal 7 and 8 — RCE — CVE-2019-6338 and CVE-2019-6339 [SA-CORE-2019-001]( https://www.drupal.org/sa-core-2019-001 ) and [SA-CORE-2019-002]( https://www.drupal.org/sa-core-2019-002 ), also known as CVE-2019-6338 and CVE-2019-6339 are two remote code executions in [Drupal](https://www.drupal.org/), achieved via [phar-based deserialisation](https://github.com/orangetw/My-CTF-Web-Challenges#babyh-master-php-2017). Snuffleupagus ships with a [rule](https://github.com/nbs-system/snuffleupagus/blob/master/config/default.rules#L27) to block this vector, although it's not enabled by default since some people do need to use the `phar://` wrapper. The one-liner to kill this class of vulnerability is `sp.wrappers_whitelist.list("php");`. It has the nice side-effect of killing other ones that could be reached via [other stream wrappers](https://www.php.net/manual/en/wrappers.php). ## Magento 2 — RCE Daniel Le Gall from SCRT [published an RCE](https://blog.scrt.ch/2019/01/24/magento-rce-local-file-read-with-low-privilege-admin-rights/) for [Magento 2](https://magento.com/). While it can be trivially virtual-patched, it is already blocked by the two enabled-by-default mitigations: 1. `sp.readonly_exec.enable();`, preventing writeable files from being executed. 2. `sp.upload_validation.script("your_script.py").enable();`, detecting if uploaded files contains valid PHP code, and if they do, aborting the execution. ## Drupal 8 — RCE — CVE-2019-6340 [SA-CORE-2019-003](https://www.drupal.org/sa-core-2019-003) is an unserialize-based remote code execution. Snuffleupagus provides a generic mitigation against this kind of attacks: `sp.unserialize_hmac.enable()`, preventing unauthenticated payloads from being unserialized. This mitigation is [commented](https://github.com/nbs-system/snuffleupagus/blob/master/config/default.rules#L20) in the default configuration file, since it might break websites that stored serialized content **before** enabling this feature, although the *simulation* mode can be used to seamlessly update the data, before enabling the mitigation in *drop* mode. ## Horde — Arbitrary file upload — CVE-2019-9858 Ratiosec found an [arbitrary file upload](https://www.ratiosec.com/2019/horde-groupware-webmail-authenticated-arbitrary-file-injection-to-rce/) in [Horde](https://www.horde.org/), mitigated exactly like Daniel Le Gall's Magento 2 RCE: 1. `sp.readonly_exec.enable();`, preventing writeable files from being executed. 2. `sp.upload_validation.script("your_script.py").enable();`, detecting if uploaded files contain PHP code, and if they do, abort the execution. ## Drupal — RCE — CVE-2018-7600 [SA-CORE-2018-002](https://www.drupal.org/sa-core-2018-002) is a remote code execution, via an interesting vector (see [Checkpoint's analysis](https://research.checkpoint.com/uncovering-drupalgeddon-2/) for more details). Snuffleupagus doesn't come with generic mitigations to make this vulnerability unexploitable, but it still has some interesting/fun counter-measures to catch the kiddies: 1. [Whitelist support in eval]( https://snuffleupagus.readthedocs.io/features.html#white-and-blacklist-in-eval), killing Checkpoint's exploit, and forcing the attacker to find an other way to get their payload executed. 2. [Automatic generation of whitelist](https://github.com/nbs-system/snuffleupagus/blob/master/scripts/generate_rules.php), preventing the introduction of new callsites to dangerous functions, forcing attackers to use only existing sites, à la [*ret2libc*](https://en.wikipedia.org/wiki/Return-to-libc_attack). 3. [Basic parameters filtering for `system` and its friends](https://github.com/nbs-system/snuffleupagus/blob/master/config/default.rules#L62), making it harder to get code execution with a single request. While it shouldn't take much time to a serious attacker to walk around those mitigations, this will likely stop some kiddies. ## Magento 2 - SQLI — CVE-2019-7139 [Charles Fol](https://twitter.com/cfreal_) from ambionics found an [unauthenticated SQL injection]( https://www.ambionics.io/blog/magento-sqli ) in Magento2. Unfortunately, Snuffleupagus doesn't have a publicly available generic anti-SQLI feature. ## Prestashop — Privesc — CVE-2018-13784 Charles Fol, again, from [ambionics](https://www.ambionics.io/blog/prestashop-privilege-escalation) disclosed a privilege escalation in [Prestashop](https://www.prestashop.com/en), via an attack on the insecure cryptographic mechanism used by Prestashop to handle sessions. Snuffleupagus' [cookie encryption]( https://snuffleupagus.readthedocs.io/cookies.html#cookie-encryption ) features not only prevents stolen cookies from being used, but also ensure their integrity, preventing this attack. ## GLPI — A bit of everything — CVE-2019-10231, CVE-2019-10233 and CVE-2019-10477 Julien Szlamowicz, Thomas Chauchefoin and Damin Picard, from Synacktiv recently dumped a couple of [GLPI](https://glpi-project.org/) vulnerabilities: - An [authentication bypass via type-juggling](https://www.synacktiv.com/ressources/GLPI_9.4.0_Type_juggling_auth_bypass.pdf), mitigated by `sp.sloppy_comparison.enable();`, disabled by default because a lot of applications are breaking when type-juggling is disabled. - A [SQL injection](https://www.synacktiv.com/ressources/advisories/GLPI_9.3.3_SQL_Injection.pdf), which, like Magento 2's CVE-2019-7139, isn't mitigated in a generic way, yet. - An [user enumeration via a timing attack](https://www.synacktiv.com/ressources/GLPI_9.4.0_Timing_attack_user_enumeration.pdf), that can't be mitigated in a generic way. - An [arbitrary function call](https://www.synacktiv.com/ressources/GLPI_FusionInventory_9.4.0_Arbitrary_call_user_func_array.pdf) that can't be mitigated in a generic way, since it's a direct call to `call_user_func_array` with user-controlled parameters. ## Wordpress — RCE — CVE-2019-8942 Simon Scannell from RIPS found a [path traversal and a local file inclusion](https://blog.ripstech.com/2019/wordpress-image-remote-code-execution/) in WordPress, leading to a remote code execution. The path traversal isn't prevented by Snuffleupagus, since they can't be distinguished from **legitimate** usages. However, the LFI is prevented by `sp.readonly_exec.enable();`, denying writeable files from being executed by PHP. The second layer of defense, `sp.upload_validation.script("your_script.py").enable();`, to detect whether uploaded files contain PHP code, might be bypassed: The GD library used to process the images will compress them after they've been uploaded, allowing an attacker to hide their backdoor from Snuffleupagus, only to have it available after decompression. ## Wordpress — CSRF → XSS → RCE — CVE-2019-9787 Simon Scannell from RIPS found a [Cross-Site Request Forgery]( https://blog.ripstech.com/2019/wordpress-csrf-to-rce/ ) in Wordpress, leading to an XSS and can be escalated to an RCE. The CSRF is mitigated by the [SameSite marking](https://snuffleupagus.readthedocs.io/features.html#protection-against-cross-site-request-forgery) feature of Snuffleupagus, while the XSS isn't, and well, since RCE when you're admin is a Wordpress feature, there is little nothing we can do to prevent it without completely breaking Wordpress :P ## phpBB — RCE — CVE-2018-19274 Simon Scannell from RIPS disclosed a [`phar://`-based unserialize remote code execution]( https://blog.ripstech.com/2018/phpbb3-phar-deserialization-to-remote-code-execution/ ) in [phpBB](https://www.phpbb.com/), mitigated by the [wrapper whitelist feature](https://snuffleupagus.readthedocs.io/config.html#whitelist-of-stream-wrappers) of Snuffleupagus. ## WooCommerce — RCE — CVE-2018-20714 Simon Scannell from RIPS found a [logic-based remote code execution]( https://blog.ripstech.com/2018/wordpress-design-flaw-leads-to-woocommerce-rce/ ) in WooCommerce, that can't be generically prevented. ## Pydio — RCE — CVE-2018-20718 Simon Scannell and Robin Peraglie from RIPS reported a [remote code execution]( https://blog.ripstech.com/2018/pydio-unauthenticated-remote-code-execution/ ) via `unserialize` in Pydio, mitigated by `sp.unserialize_hmac.enable()`. ## Moodle — RCE — CVE-2018-1133 Robin Peraglie from [RIPS]( https://blog.ripstech.com/2018/moodle-remote-code-execution/ ) disclosed a RCE via `eval` injection in Moodle. This can be mitigated via the [eval whitelist]( https://snuffleupagus.readthedocs.io/features.html#white-and-blacklist-in-eval) feature, with something like `sp.eval_whitelist.list().simulation();`. ## Prestashop — RCE — CVE-2018-20717 Robin Peraglie from [RIPS](https://blog.ripstech.com/2018/prestashop-remote-code-execution/) reported an unserialize-based remote code execution, mitigated by `sp.unserialize_hmac.enable()`, just like `CVE-2019-6340` and `CVE-2018-20718`. ## SPIP — RCE — CVE-2019-11071 [g0uZ](https://www.root-me.org/g0uZ?lang=en) burned a cool [RCE](https://blog.spip.net/Mise-a-jour-CRITIQUE-de-securite-Sortie-de-SPIP-3-1-10-et-SPIP-3-2-4.html) in SPIP. The root cause lies in a *creative* [sessions handling](https://github.com/spip/SPIP/compare/1e3872c...9861a47#diff-3277d37ffd8a1016dd66f0fd2297094cL607), and while this can trivially be virtual-patched in various ways, there is unfortunately no generic mitigation that could prevent the RCE from being exploitable without completely breaking SPIP. ## Magento2 — XSS to RCE Simon Scannell from RIPS found a [stored XSS to RCE]( https://blog.ripstech.com/2019/magento-rce-via-xss/ ) in Magento 2. The XSS isn't mitigated, but the RCE is, but the [wrapper whitelist](https://snuffleupagus.readthedocs.io/config.html#whitelist-of-stream-wrappers). ## Drupal — Authentication bypass — CVE-2019-6342 Reported by Dave Botsch, the authentication bypass, [SA-CORE-2019-008](https://www.drupal.org/sa-core-2019-008), is a [logic bug ](https://github.com/drupal/drupal/commit/b64c4afc50939fd0e6600aec00e4c2962120862e): Snuffleupagus can't do anything against this in a generic way, but can trivially virtual patch it. ## TYPO3 — XSS to RCE — CVE-2019-12748 and CVE-2019-12748 Robin Peraglie from RIPS [reported](https://blog.ripstech.com/2019/typo3-overriding-the-database/) a deserialization-based remote code execution, mitigated by `sp.unserialize_hmac.enable()`. The XSS relies on insufficient sanitization during the handling of a TYPO3-specific pseudo-scheme to create URL (`t3://`), which is out of scope of Snuffleupagus' mitigations. # Conclusion The only vulnerabilities that weren't killed are either: - Logic issues, that can't be generically mitigated. - Client-side issues, like XSS, that are explicitly out of scope. - Application-specific issues that can't be dealt with in a generic way. - SQLI, since I'd like this feature to remain private for now. It seems that Snuffleupagus is doing a decent job! Feel free to send me an [email](https://dustri.org/) if you have other cool vulnerabilities that you would like to be added to this article.