Evilgrade: Updating a backdoor never gets old

In case you haven’t seen past month advisories, there was a release of multiple vulnerabilities on Original Equipment Manufacturers (OEM) regarding the safety of updates mechanisms.

Most of the vulnerabilities described on those advisories were ported as a module to evilgrade, and additional modules for non OEM were also included as well.

This vulnerabilities were made public by coresecurity and duo, affecting the following vendors:

Samsung, Lenovo, Intel, Acer, Dell, Hewlett Packard, Asus.

From duo labs’ document Out-of-Box Exploitation: A Security Analysis of OEM Updaters:

• Dell: One high-risk vulnerability involving lack of certificate best practices, known as eDellroot.
• Hewlett Packard: Two high-risk vulnerabilities that could have resulted in arbitrary code execution on affected systems. In addition, five medium-to-low risk vulnerabilities were also identified.
• Asus: One high-risk vulnerability that allow for arbitrary code execution as well as one medium severity local privilege escalation.
• Acer: Two high-risk vulnerabilities that allow for arbitrary code execution.
• Lenovo: One high-risk vulnerability that allows for arbitrary code execution.

From coresecurity’s advisories:

• Samsung: Samsung SW Update Tool is prone to a Man in The Middle attack which could result in integrity corruption of the transferred data, information leak and consequently code execution.
• Lenovo: Lenovo SHAREit for Windows and Android are prone to multiple vulnerabilities which could result in integrity corruption, information leak and security bypasses.
• Intel: Intel Driver Update Utility is prone to a Man in The Middle attack which could result in integrity corruption of the transferred data, information leak and consequently code execution.

Non-OEM Additional modules:

• Keepass: Keepass uses in all versions up to the current 2.33, unencrypted HTTP requests to check for new software versions. An attacker can abuse this automatic update check – if enabled – to “release” a new version and redirect the user to a malicious download page.
• Openbazaar: A man in the middle could intercept the update request and reply with a fake JSON response, forcing the electron updater to download a custom payload and, on platforms where code signing is not enforced by settings, this could lead to a remote code execution.
• Sparkle: All applications that use the Sparkle Updater framework and are connecting over HTTP instead of a secure HTTPS connection are vulnerable. On a side note, a few years ago we reported a prior vulnerability of Sparkle, for an example application like Adium. Despite the way the updates were handled was modified, AppCast, the RSS feed that hosts information about software updates and more, is prone to MITM attacks, resulting in insertion of modified HTML and JavaScript code into a WebView component, finally displaying it to the user. From there, there are interesting things you can do, and one of them was applied to the new Sparkle module.
• Timedoctor: The autoupdate implementation in TimeDoctor Pro 1.4.72.3 on Windows relies on unsigned installer files that are retrieved without use of SSL, which makes it easier for man-in-the-middle attackers to execute arbitrary code via a crafted file.

Evilgrade’s latest release (2.0.8 at this moment) includes all the necessary modules to fulfill the exploitation of the mentioned updaters, including one that according to what we know so far hasn’t been published explicitly yet, neither has a CVE, but was mentioned on a blogpost last year, which exploits a firmware update on Lenovo’s mobile devices.

Moreover, there has been fixes and upgrades to the usage of evilgrade and they will be described briefly below:

• A bug on the current version of ReadLine::Gnu that was affecting mostly Kali users was fixed on our side.
• Extended filtering of requests via user agent was added. An example module can be found here. By setting useragent to true, this allows us to trigger an action when the regular expression fields inside of request: req and useragent match the current request. This also grants us the opportunity to filter a request only by the User-Agent header, as seen in sparkle2 module, where req  field accepts all incoming requests “.*” if and only if the useragent matches “Sparkle”.
• 2 new configuration variables <%URL_FILE%> and <%URL_FILE_EXT%> were added to provide a more realistic approach. An example module can be found here. This variables may be used to handle the victim a file with the same name that was requested, for an example. In the asus module scenario, the updater requests an .ide file, for example MODEL_A123.ide that is not legible, but it also has the possibility to request .idx files which are in plaintext. The variables are used to make the updater believe it is asking for the same file but with a different extension.
• Optimization on matching requests: When a module answers a request, the lookup on the following modules stops. This enables evilgrade to serve responses much faster, and encourages users to develop modules that match accordingly.

We hope you enjoy it, and let us know if you have any questions or comments.
https://github.com/infobyte/evilgrade