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.
Infecting the compilation process is an old trick, as documented in Ken Thompson’s “Reflections on Trusting Trust” https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html
I had the link to Thompson’s paper pulled up, and thought about sneaking it into the article somewhere. It’s such a classic piece of computer history.
It’s also one of the things that gives many involved in security nightmares. Stuxnet is a perfect example of trusting trust.
SQL injection is made easy and dangerous by the non-standard use of the semicolon to separate SQL commands. This functionality is superfluous, commands can be issued separately even within a transaction. Get rid of this stupid feature.
Modern REAL SQLi attacks don’t even factor in termination.. It’s all second order, or UNION and OUTPUT or append based. Also mostly blind..
SQLi still exists because people usually get designer or “back-end” jobs days or weeks after even learning what a database is.. Kind of like the reality of C++ developers..
Anybody who doesn’t use test vectors when doing crypto code – even if only calling know libraries that you haven’t written yourself – is an idiot.
It’s about the first thing you write – ie something to cycle through the test vectors and check the results!
I wouldn’t trust any library that I hadn’t tested that way, let alone my own code…
One possibility is that the software was automatically migrating to bcrypt at the one time when the password is available in the clear: at log on. Perhaps the MD5 digests were associated with users that hadn’t signed in for a long time?
To avoid risk and the burden of compliance, many companies don’t allow payment card information into their applications or even onto their networks. They outsource the whole process including to a 3rd party that is better equipped to protect the data and simply ask them to collect X amount of money and then wait to hear if it was successful. It’s very conceivable that a user database could be compromised and no actual payment card information be leaked other than a token that is only useful for collecting additional money on the original applications behalf.