Github is struggling to keep up with a malware campaign that’s a new twist on typosquatting. The play is straightforward: Clone popular repositories, add malware, and advertise the forks as the original. Some developers mistake the forks for the real projects, and unintentionally run the malware. The obvious naming choice is forksquatting, but the researchers at apiiro went with the safer name of “Repo Confusion”.

The campaign is automated, and GitHub is aware of it, with the vast majority of these malicious repositories getting removed right away. For whatever reason, the GitHub algorithm isn’t catching all of the new repos. The current campaign appears to publishing millions of forks, using code from over 100,000 legitimate projects. It’s beginning to seem that the squatting family of attacks are here to stay.

RustDesk and Odd Certificates

The RustDesk remote access software is interesting, as it’s open source, allows self-hosting, and written in Rust. I’ve had exploring RustDesk as a todo item for a long time, but a bit of concerning drama has just finished playing out. A user pointed out back in November that a test root certificate was installed as part of the RustDesk installation. That root cert is self-signed with SHA1. There is also concern that the RustDesk binaries are signed with a different certificate.

There have been new events since then. First, there was a Hacker News thread about the issue earlier this month. The next day, CVE-2024-25140 was registered with NIST, ranking an insane CVE 9.8 CVSS. Let’s cut through some FUD and talk about what’s really going on.

First, root certificates ought to be signed with a more secure hashing function than SHA1. But not for the reason you think, and in this case it doesn’t matter. Root certificates are self-signed by definition, and the only reason they’re signed at all is because these certificates must be signed to be valid. Child certs are not protected by the root’s signature. The important function that depends on that root signature is the ability to issue a revocation request. That would be really bad for one of the widely trusted root certificates, and not an issue at all for an untrusted cert like this one.

Next, RustDesk has a valid, signed certificate for the executables. The self-signed root certificate is strictly for signing a kernel driver, which requires an Extended Validation (EV) certificate. It’s a bit disconcerting that this requirement can be so easily sidestepped by installing a root cert during application install, but that’s on Microsoft, not RustDesk.

The final concern here is that this certificate is being installed as a system-wide Certificate Authority (CA). That is the most worrying element of this saga, but certificates have a field specifiying their Key Usage (KU) and Extended Key Usage (EKU). The RustDesk CA is strictly for Code Signing. This does not allow RustDesk or anyone in possession of this key to break TLS or spoof web sites. It does allow code signing, which could be a valid concern, but is not the hair-on-fire situation it first appears.

RustDesk has pulled this key from their installation, which happens to disable the virtual display driver. That was the functionality that required a signed kernel driver. The latest news is that the RustDesk devs are getting some assistance, and are pursuing an EV code-signing certificate, and expect to have that process wrapped up in about a month. And that CVE, scoring a severity 9.8? Seems completely bogus.

Ultimate Member SQL Injection

The Ultimate Member WordPress plugin has been updated to release 2.8.3, fixing a SQL injection flaw that was accessible as an unauthenticated user. Based on the update diff, the key issue is probably a missed prepare() on line 704. Oh, and it’s apparently being probed and potentially exploited in the wild, so go patch.

This is probably a good time to have a chat about why there are so many SQL injection attacks in WordPress. First, SQL injection is when user supplied data is interpreted as part of the SQL command to execute. That’s done by including an unexpected character. For instance, a semicolon indicates the end of a statement, and can be used to start the next. So where a naive program expects a number, an input of 15; DROP TABLE Students will satisfy one SQL statement and inject a second statement to be executed on the database.

Broadly speaking, there are two approaches to prevent SQL injection: input sanitization and prepared statements. And both is good, too! First, sanitize user input. Make sure that integer is actually an integer and only an integer. Strip out quotation marks, semicolons, and other potentially hazardous characters.

The second approach is to use prepared statements. This separates the SQL command from the data in a fundamental way. It’s something like $database->prepare("INSERT INTO Students (name, age) VALUES (?, ?)"); to send the SQL commands. Then it’s followed by $database->bind_param("si", $name, $age); to set the values to be used. And finally a $database->execute(); actually runs the query. There is no injection possible because of the strict separation between the code and values.

Now we come to WordPress, which has its own wpdb class for database calls. That includes a helpful function, wpdb::prepare() that looks almost like a prepared statement as shown above.

$wpdb->prepare( "u.user_registered BETWEEN %s AND %s", $from_date, $to_date );

Except it’s not at all. The prepare() function strictly does a sanitization pass, and an sprintf() value substitution. The prepare() function does not actually produce a prepared database statement. WordPress does not provide a way to actually use prepared statements. One of the basic paradigms to keep developers out of trouble with SQL injections is missing.

The M&Ms Are Watching

I have something of a hobby. I find it fun to spot misbehaving machines, and try to figure out what OS is running underneath the shiny GUI. The weirdest embedded device I’ve found is a page scanner that ran a full-fat copy of Windows. The price scanners in your local big-box store might just run Windows CE. The airplane seat-back infotainment centers run a really old Linux. And apparently the M&M vending machines at the University of Waterloo run Windows with the Invenda.Vending.FacialRecognition.App.exe application.

We know that because [SquidKid47] caught an unknown software exception on the vending machine’s display screen, and shared it on reddit. A school newspaper picked up the story (pdf) and determined that the vending machine uses a camera and facial detection as a combination of smart motion sensor and demographics detector for targeted advertising. Yes, these vending machines serves targeted ads. At least they did. These vending machines have met their Waterloo at the University of Waterloo, with the school now formally requesting their removal.

Bits and Bytes

Ring Doorbell to Pwn: It turns out that some smart doorbells aren’t all that smart. It’s not surprising that there’s a process to reset a smart doorbell, to associate it with another account. It is rather surprising that this process is as easy as holding the big doorbell button itself for 8 seconds. At the very least, the legitimate owner will receive an email about the change.

Printer insecurity is nothing new, but 3D printer security is still a bit of a niche idea. That may be changing, now that the equivalent of a “greetings.txt” file has been dropped on a bunch of Anycubic printers. Apparently Anycubic uses an MQTT server that really doesn’t have sufficient access controls.

It’s that time again, when a vulnerability fix has been released for GitLab, and it’s time to go update. The stand-out this time is a Cross Site Scripting (XSS) flaw upon visiting a user’s profile page. I leave it as an exercise for the reader, to produce sample code that copies “samy is my hero” to the profile page of each visitor.

And finally, in the irony department, Avast has been fined for using a browser privacy plugin as a platform to collect and sell user data. This happened from 2014 to 2020, using the Jumpshot platform for the actual selling of data. The data was nominally anonymized, but the amount and detail of information available is a bit staggering. It is worth pointing out that Jumpshot is no more, and Avast is now owned by another company. Hopefully without harvesting user information.