Akeo Consulting Rufus fails to update itself securely

2017-08-2900:00:00

www.kb.cert.org

512

0.008 Low

EPSS

Percentile

81.4%

JSON

Overview

Akeo Consulting Rufus fails to securely check for and retrieve updates, which an allow an authenticated attacker to execute arbitrary code on a vulnerable system.

Description

Akeo Consulting Rufus 2.16 retrieves updates over HTTP. While Rufus does attempt to perform some basic signature checking of downloaded updates, it does not ensure that the update was signed by a trusted certificate authority (CA). This lack of CA checking allows the use of a self-signed certificate. Because of these two weaknesses, an attacker can subvert the update process to achieve arbitrary code execution.

Impact

An attacker on the same network as, or who can otherwise affect network traffic from, a Rufus user can cause the Rufus update process to execute arbitrary code.

Solution

Apply an update

This issue is addressed in Rufus 2.17.1187. Please also consider the following workarounds:

Don’t use built-in update capabilities

Because Rufus does not include the ability to securely install updates, any Rufus updates should be obtained from <https://rufus.akeo.ie/> directly, using your web browser.

Avoid untrusted networks

Avoid using untrusted networks, including public WiFi. Using your device on an untrusted network increases the chance of falling victim to a MITM attack.

Vendor Information

403768

Filter by status: All Affected Not Affected Unknown

Filter by content: __ Additional information available

__ Sort by: Status Alphabetical

Expand all

Javascript is disabled. Click here to view vendors.

Akeo Consulting __ Affected

Updated: August 29, 2017

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

You do realize that the executable is digitally signed, in which case the matter in which it was download does not matter, do you?

I would encourage you to further your knowledge of security practices, because, just because something says “secure” in its name, it doesn’t mean that it is actually secure (the transmission of data is “secured”, but if the source download is compromised, which is something that’s fairly easy to achieve if you physically threaten the person administering the server, downloading through SSL won’t bring you any “security”), or just because something does not say “secure”, it doesn’t mean that it is insecure if it is digitally signed. Likewise, people tend to believe that self signed certificates are more insecure that the ones issued by Certification Authority, but there are occasions where they are actually safer. I’ve been dealing with PKI matters for more than 15 years, and written quite a few applications that revolve around it, so I hope that, rather than jumping to the conclusion that experienced developers don’t know what they are doing, you will actually take the approach that, maybe, they have greater knowledge than you do about security matters, and, because of it, they can make educated decisions about discarding security practices that are entirely redundant and aren’t bringing anything to the equation. You may also want to read the second part of what I wrote here when I was recently questioned about the same subject.

As a matter of fact, the next version of Rufus will switch the update check (and other downloads) back to http rather than https (8b094e8), because, due to the way Rufus is designed, using http does not make our downloads any less “safe”, even if the NSA or whatever 3-letter security agency has control of the connection and attempts to inject malicious content into it.

Now, provided you spend time reading and understanding the topics being discussed on our page about Security in Rufus and especially this part, I’ll be happy to debunk any scenario you can propose, where you think the use of HTTP in Rufus is going to make its users less secure than if HTTPS was used.