Category: Fity Feeds

This Week in Security: uTorrent Vulnerable, Crowd-Sourcing Your Fail2Ban, and Cryptographers at Casinos

The uTorrent client was recently updated to fix a null pointer dereference (CVE-2020-8437), discovered by [whtaguy]. Triggering the dereference simply crashes the client — so far an actual RCE hasn’t been found. Given the nature of the null pointer dereference, it’s possible this bug is limited to denial of service. That’s extremely good, because the flaw is extremely easy to target.

Why Are Applications Difficult to Secure?

With the onset of digital transformation, applications have become a priority for businesses. They’ve also grown as a target to would-be hackers. We know that securing applications is paramount, but why are they difficult to secure?

This Week in Security News: Cybercriminals Distribute Backdoor with VPN Installer and New ‘Alien’ Malware can Steal Passwords from 226 Android Apps

Welcome to our weekly roundup, where we share what you need to know about the cybersecurity news and events that happened over the past few days. This week, learn about how threat actors are bundling Windscribe VPN installers with backdoors. Also, read about a new strain of Android malware that comes with a wide array of features allowing it to steal credentials from 226 applications.

Israeli intelligence helps deter hacking attempts in UAE

On Tuesday the UAE Head of NCSC Muhammad Al-Kuwaiti reported that the intel that Israel are sharing has helped to deter and amend any hacking attempts. For the first time the Israeli and UAE cyber chiefs, al-Kuwaiti and Israel National Cyber Directorate (INCD) Chief Yigal Unna, appeared at a virtual conference at Tel Aviv University. In response to a question about the effect of the Israeli-UAE cyber cooperation as a result of the normalization deals, al-Kuwaiti said that “it has been really a positive and added value to many sectors and aspects” to defending the UAE against hacking attempts.

Improved client-side encryption: Explicit KeyIds and key commitment

I’m excited to announce the launch of two new features in the AWS Encryption SDK (ESDK): local KeyId filtering and key commitment. These features each enhance security for our customers, acting as additional layers of protection for your most critical data. In this post I’ll tell you how they work. Let’s dig in.

The ESDK is a client-side encryption library designed to make it easy for you to implement client-side encryption in your application using industry standards and best practices. Since the security of your encryption is only as strong as the security of your key management, the ESDK integrates with the AWS Key Management Service (AWS KMS), though the ESDK doesn’t require you to use any particular source of keys. When using AWS KMS, the ESDK wraps data keys to one or more customer master keys (CMKs) stored in AWS KMS on encrypt, and calls AWS KMS again on decrypt to unwrap the keys.

It’s important to use only CMKs you trust. If you encrypt to an untrusted CMK, someone with access to the message and that CMK could decrypt your message. It’s equally important to only use trusted CMKs on decrypt! Decrypting with an untrusted CMK could expose you to ciphertext substitution, where you could decrypt a message that was valid, but written by an untrusted actor. There are several controls you can use to prevent this. I recommend a belt-and-suspenders approach. (Technically, this post’s approach is more like a belt, suspenders, and an extra pair of pants.)

The first two controls aren’t new, but they’re important to consider. First, you should configure your application with an AWS Identity and Access Management (IAM) policy that only allows it to use specific CMKs. An IAM policy allowing Decrypt on “Resource”:”*” might be appropriate for a development or testing account, but production accounts should list out CMKs explicitly. Take a look at our best practices for IAM policies for use with AWS KMS for more detailed guidance. Using IAM policy to control access to specific CMKs is a powerful control, because you can programmatically audit that the policy is being used across all of your accounts. To help with this, AWS Config has added new rules and AWS Security Hub added new controls to detect existing IAM policies that might allow broader use of CMKs than you intended. We recommend that you enable Security Hub’s Foundational Security Best Practices standard in all of your accounts and regions. This standard includes a set of vetted automated security checks that can help you assess your security posture across your AWS environment. To help you when writing new policies, the IAM policy visual editor in the AWS Management Console warns you if you are about to create a new policy that would add the “Resource”:”*” condition in any policy.

The second control to consider is to make sure you’re passing the KeyId parameter to AWS KMS on Decrypt and ReEncrypt requests. KeyId is optional for symmetric CMKs on these requests, since the ciphertext blob that the Encrypt request returns includes the KeyId as metadata embedded in the blob. That’s quite useful—it’s easier to use, and means you can’t (permanently) lose track of the KeyId without also losing the ciphertext. That’s an important concern for data that you need to access over long periods of time. Data stores that would otherwise include the ciphertext and KeyId as separate objects get re-architected over time and the mapping between the two objects might be lost. If you explicitly pass the KeyId in a decrypt operation, AWS KMS will only use that KeyId to decrypt, and you won’t be surprised by using an untrusted CMK. As a best practice, pass KeyId whenever you know it. ESDK messages always include the KeyId; as part of this release, the ESDK will now always pass KeyId when making AWS KMS Decrypt requests.

A third control to protect you from using an unexpected CMK is called local KeyId filtering. If you explicitly pass the KeyId of an untrusted CMK, you would still be open to ciphertext substitution—so you need to be sure you’re only passing KeyIds that you trust. The ESDK will now filter KeyIds locally by using a list of trusted CMKs or AWS account IDs you configure. This enforcement happens client-side, before calling AWS KMS. Let’s walk through a code sample. I’ll use Java here, but this feature is available in all of the supported languages of the ESDK.

Let’s say your app is decrypting ESDK messages read out of an Amazon Simple Queue Service (Amazon SQS) queue. Somewhere you’ll likely have a function like this:

public byte[] decryptMessage(final byte[] messageBytes, final Map<String, String> encryptionContext) { // The Amazon Resource Name (ARN) of your CMK. final String keyArn = "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"; // 1. Instantiate the SDK AwsCrypto crypto = AwsCrypto.builder().build();

Taurus Project stealer now spreading via malvertising campaign

For the past several months, Taurus Project—a relatively new stealer that appeared in the spring of 2020—has been distributed via malspam campaigns targeting users in the United States. The macro-laced documents spawn a PowerShell script that invokes certutil to run an autoit script ultimately responsible for downloading the Taurus binary.

Taurus was originally built as a fork by the developer behind Predator the thief. It boasts many of the same capabilities as Predator the thief, namely the ability to steal credentials from browsers, FTP, VPN, and email clients as well as cryptocurrency wallets.

Starting in late August, we began noticing large malvertising campaigns, including, in particular, one campaign that we dubbed Malsmoke that distributes Smoke Loader. During the past few days we observed a new infection pushing the Taurus stealer.

Campaign scope

Like the other malvertising campaigns we covered, this latest one is also targeting visitors to adult sites. Victims are mostly from the US, but also Australia and the UK.

Traffic is fed into the Fallout exploit kit, probably one of the most dominant drive-by toolsets at the moment. The Taurus stealer is deployed onto vulnerable systems running unpatched versions of Internet Explorer or Flash Player.

Because of code similarities, many sandboxes and security products will detect Taurus as Predator the thief.

The execution flow is indeed pretty much identical with scraping the system for data to steal, exfiltrating it and then loading additional malware payloads. In this instance we observed SystemBC and QBot.

Stealer – loader combo continues to be popular

Stealers are a popular malware payload these days and some families have diversified to become more than plain stealers, not only in terms of advanced features but also as loaders for additional malware.

Even though the threat actors behind Predator the thief have appeared to have handed over a fork of their original creation and disappeared, the market for stealers is still very strong.

Malwarebytes users are protected against this threat via our anti-exploit layer which stops the Fallout exploit kit.

We would like to thank Fumik0_ for background information about Predator the thief and Taurus.

Indicators of Compromise

Malvertising infrastructure

casigamewin[.]com

Redirector

89.203.249[.]76

Taurus binary

84f6fd5103bfa97b8479af5a6db82100149167690502bb0231e6832fc463af13

Free VPNs are bad for your privacy

VPNs are in high demand as Americans scramble to keep access to TikTok and WeChat amid a looming government ban. There are dozens of free VPNs out there that promise to protect your privacy by keeping you anonymous on the internet and hiding your browsing history.

Sandbox in security: what is it, and how it relates to malware

To better understand modern malware detection methods, it’s a good idea to look at sandboxes. In cybersecurity, the use of sandboxes has gained a lot of traction over the last decade or so. With the plethora of new malware coming our way every day, security researchers needed something to test new programs without investing too much of their precious time.