This Week in Security: XCode Infections, Freepik, and Crypto Fails

There is a scenario that keep security gurus up at night: Malware that can detect software compilation and insert itself into the resulting binary. A new Mac malware, XCSSET (PDF), does just that, running whenever Xcode is used to build an application. Not only is there the danger of compiled apps being malicious, the malware also collects data from the developer’s machine. It seems that the malware spreads through infected Xcode projects.

WordPress Plugins

WordPress has a complicated security track record. The core project has had very few serious vulnerabilities over the years. On the other hand, WordPress sites are routinely compromised. How? Generally through vulnerable plugins. Case in point? Advanced Access Manager. It’s a third party WordPress plugin with an estimate 100,000 installations. The problem is that this plugin requires user levels, a deprecated and removed WordPress feature. The missing feature had some unexpected results, like allowing any user to request administrator privileges.

The issue has been fixed in 6.6.2 of the plugin, so if you happen to run the Advanced Access Manager plugin, make sure to get it updated. Beyond that, maybe it’s time to do an audit on your WordPress site. Uninstall unused plugins, and make sure the rest are up to date, along with the WordPress installation itself.

Freepik

A source of graphics and stock photos, Freepik gives a few bits away for free, and requires a monthly subscription for access to the rest of the library. A few days ago, someone discovered a SQL injection attack on the icon site, and the user database was grabbed. A few things caught my interest about their report. First, the report claims that the only data that escaped was email addresses and in some cases, password hashes. It’s unclear why addresses and credit card information weren’t part of the leak.

The next tidbit of interest is that any account using a federated login, that is using a Facebook, Twitter, or Google account to log in, only exposed an email address. In retrospect, it’s an obvious advantage of using a single sign on. The service has that much less information to lose about the account. The other bit of interest is that a few older accounts still used salted MD5 password hashes, while the vast majority used the more modern bcrypt.

Overcoming Exploit Mitigations

Crowdstrike put out a pair of blog posts about the state of OS hardening techniques, and how to overcome them. Data Execution Prevention and Address Space Layout Randomization are considered legacy techniques at this point, so go check out the series to get up to date.

Let’s Talk About Crypto

What’s the first rule of crypto? “Don’t roll your own crypto.” What exactly does that mean, and why? We have a case study in how crypto can go wrong, and a few tips on how to do it right. The project in question is a .net implementation of the Branca token, which is an interesting protocol in itself.

That warning about rolling your own crypto usually means that you should use published algorithms, that have been proven by time and peer review. For years now, AES has had smarter people than you or I looking for flaws. It’s very likely that it’s a better block cipher than anything we could come up with. That warning, however, doesn’t mean that you shouldn’t ever build anything crypto related. If there isn’t a library that does what you need for a project, go for it, built it from scratch. But take some precautions to keep yourself out of trouble.

Test vectors are the published results of running an algorithm with specific settings. If you run AES with a certain key and a certain input text, you get a known ciphertext every time. A good set of test vectors will include possible edge cases, like an empty string for the plaintext. Find the test vectors for the crypto you’re using, and make sure your project replicates them. Even better, build in unit testing, and automate that process. The Branca token has published vectors, and the .net implementation in question failed to replicate. Oops.

Another bit of good crypto hygiene is to use constant time functions to thwart timing-based attacks. Again, in our example library, Branca uses the Poly1305 Message Authentication Code (MAC). A MAC is essentially a keyed hash that is appended to the string to be verified. It’s the last thing changed on the outgoing message, and the first thing checked on the incoming message. If the MAC doesn’t validate, the message can be dropped right away. It’s possible that an attacker would be able to detect how long it takes the receiving end to drop a message with an invalid MAC. If the comparison is done in a naive way, as it is here, the timing gives away how far into the comparison the message differed from what was expected. You know the scene in the movie when the super secret password is being guessed one character at a time? That’s kind of how a timing attack against this sort of flaw would work, and that’s what you want to avoid.

There are obviously more gotchas when working with cryptography, but this particular story underlines two of the first steps you should take to be sure that you’re using cryptography correctly. Use known good code and algorithms, verify inputs with outputs, and follow best practices like constant time string comparisons.

Hacking Google’s infrastructure for Fun and Profit

[Wouter ter Maat] and [Ezequiel Pereira] were researching Google’s Cloud SQL service, and found a SQL injection in a CSV export function. Just a bit of cleverness allowed them to dump data from a database into a specified file in the /mysql/temp/ directory. The real trick is that they could run the export again, but intercept the API call and modify it, adding command line options to the mysqldump command.

One of those options? Specifying an authentication plugin. Since they already had the ability to drop a file on the filesystem, getting mysqldump to run a malicious plugin was fairly easy, leading to a reverse shell. For their efforts, they got a message from the Google Site Reliability Engineering (SRE) team in the form of a greetings.txt file. The bugs they found have been fixed, but not before they discovered an SSH hijack that allowed escaping the SQL container. Let’s hope Google paid them a nice bounty for their hard work.