Honeypots are an entertaining way to learn about new attacks. A simulated vulnerable system is exposed to the internet, inviting anyone to try to break into it. Rather than actually compromising a deployed device, and attacker just gives away information about how they would attack the real thing. A honeypot run by 360Netlab found something interesting back in April: an RCE attack against QNAP NAS devices. The vulnerability is found in the logout endpoint, which takes external values without properly sanitizing them. These values are used as part of an snprintf statement, and then executed with a system() call. Because there isn’t any sanitization, special characters like semicolons can be injected into the final command to be run, resulting in a trivial RCE.

QNAP has released new firmware that fixes the issue by replacing the system() call with execv(). This change means that the shell isn’t part of the execution process, and the command injection loses its bite. Version 4.3.3 was the first firmware release to contain this fix, so if you run a QNAP device, be sure to go check the firmware version. While this vulnerability was being used in the wild, there doesn’t seem to have been a widespread campaign exploiting it.

Notarized Malware

Once upon a time, it was reasonably accurate to say that Mac machines didn’t get viruses. Strictly speaking, that hasn’t been true since 1987, when nVIR was discovered traveling on floppy disks and infecting Macintosh machines. Regardless, as Macs have gotten more popular, and as Microsoft has slowly improved the security of Windows systems, it’s becoming less and less accurate to say that Macs don’t get viruses. In response, Apple has introduced Code Notarization for macOS, a system where developers submit their apps to Apple for review. After the app has been verified to be non-malicious, it’s signed with Apple’s key, and will run on a Mac machine without needing any special steps.

The problem is the inherent difficulty in determining whether a program is malicious, just through static analysis. Apple seems to be signing almost all requests, and simply revoking signatures of apps that prove to be malicious. [Patrick Wardle] from Objective-See brings us the report of an active Mac malware campaign that’s using notarized malware. The situation was reported to Apple, who quickly revoked the signatures. Within 48 hours, the malware campaign once again had notarized malicious binaries. It remains to be seen how the situation will resolve, but for now, it seems like notarized code isn’t a very good indicator of trustworthy code.

You Don’t Need to see My Identification

Contactless payments are impressive. Just wave a credit card over a payment terminal, and a cryptographic handshake confirms that you really have the credit card. In the case of high value transactions, a PIN is also required. The protocol that powers this is EMV, named for Eurocard, Mastercard, and Visa, the corporations that cooperated to develop the standard. Researchers at ETH Zurich took a look at that protocol, and published a paper about some flaws they found (pdf). The attack I found most interesting is the “Jedi Mind Trick” they pulled off using a pair of cell phones as intermediaries. The attack is a simple man-in-the-middle where a few bytes are changed in transit. These bytes instruct the payment terminal not to require a PIN entry, even for very large purchases.

Be Careful Compiling Secrets

The reason that security is so difficult is that there’s just so many ways to mess it up. This time, we’re talking about static keys that get compiled into released software. [Abss] got curious about Android security, and started working on a project. He grabbed as many APKs as he could get hands hands on, and decompiled them. From there, a clever grep search for variables and strings resulted in a bunch of interesting hits, like Google API keys.

That was all well and good, but it seemed like there should be something interesting that could be done with the harvested keys. The answer was the Firebase Cloud Messaging service, by Google. A valid key FCM server key and a bit of boolean trickery allows sending a message to every user of an app. It’s not hard to imagine that many applications are written with the assumption that the incoming FCM messages are trustworthy. Breaking that assumption leads to all sorts of problems, including RCE in four of Google’s official apps.

Cisco Jabber

Jabber is a messenger service, built on top of the XMPP. Cicso provides a proprietary jabber that was recently discovered to be vulnerable to a serious RCE attack. The vulnerability boils down to a cross-site-scripting filter that works in a blacklist mode, and doesn’t successfully block everything it should. The filter could be bypassed by sending an img element with the onanimationstart attribute.

Because the vulnerability can be triggered with a single message, it’s also considered a wormable vulnerability, and so scored a 9.9 severity. This issue was reported privately, and an updated version is now available with fixes, so if your organization uses Cisco Jabber, make sure it gets updated!

When The Code Stares Back

If there is a perverse pleasure in finding vulnerabilities in security products, then there must be doubly so for finding them in vulnerability scanners themselves. And that is exactly what [Gabor Mutuz] found himself doing — trying to break vulnerability scanners. As complex as modern containerized applications are, it’s not surprising that it’s possible to trip up a vulnerability scanner.

While it might seem like useless vulnerability research, consider that some projects have these scanners plugged into their continuous integration pipeline. I’ve seen some projects that even run the CI checks on every pull request. It’s not an attack vector that’s normally considered, but it’s extremely important that even these tools are hardened for security. [Gabor] reported the issues he found, and they’ve been fixed in subsequent updates. Be sure to go check out his post about it for all the details.