Researchers crack open unusually advanced malware that hid for 5 years

The name "Project Sauron" came from code contained in one of the malware's configuration files. (credit: Kaspersky Lab)

Security experts have discovered a malware platform that's so advanced in its design and execution that it could probably have been developed only with the active support of a nation state.

The malware—known alternatively as "ProjectSauron" by researchers from Kaspersky Lab and "Remsec" by their counterparts from Symantec—has been active since at least 2011 and has been discovered on 30 or so targets. Its ability to operate undetected for five years is a testament to its creators, who clearly studied other state-sponsored hacking groups in an attempt to replicate their advances and avoid their mistakes. State-sponsored groups have been responsible for malware like the Stuxnet- or National Security Agency-linked Flame, Duqu, and Regin. Much of ProjectSauron resides solely in computer memory and was written in the form of Binary Large Objects, making it hard to detect using antivirus.

Because of the way the software was written, clues left behind by ProjectSauron in so-called software artifacts are unique to each of its targets. That means that clues collected from one infection don't help researchers uncover new infections. Unlike many malware operations that reuse servers, domain names, or IP addresses for command and control channels, the people behind ProjectSauron chose a different one for almost every target.

Read 8 remaining paragraphs | Comments

‘Cat-Loving’ Mobile Ransomware Operates With Control Panel

Recently the McAfee Labs Mobile Malware Research team found a sample of ransomware for Android with botnet capabilities and a web-based control panel service. The malware is running on a legitimate cloud service provider.

The payload of this malware can encrypt a victim’s files, steal SMS messages, and block access to the device. In this variant the malware’s authors include a picture of a cat:

20160808 ElGato 1

The ransomware constantly requests commands from the control server via HTTP, and the malicious server responds with the attackers’ instructions defined in the control panel. All of this traffic is transmitted without encryption.

20160808 ElGato 2

The commands that this threat can receive and perform are described in the following table:

Command Tag Description
0 Read commands HTTP request to control server for new commands
1 Send SMS message Send message from infected device
2 Remove all SMS Forward and delete all SMS messages
3 Encrypt SD files Encrypt all files on SD card and add extension .enc
4 Encrypt path in SD Encrypt all files on SD card in a specific path with extension .enc
5 Decrypt SD files Decrypt affected files on SD card that contain extension .enc
6 Decrypt path in SD files Decrypt files in a specific path on SD card
7 Lock Lock screen
8 Exit Kill application and exit

 

Reading commands from the control server:

20160808 ElGato 3

Some interesting features of this ransomware include the ability to encrypt specific files, steal SMS messages while forwarding them to the attacker and avoiding the victim’s message visualization, lock access to the device and the encryption using an AES algorithm with a hardcoded password. Unlike asymmetric encryption, using a hardcoded password makes decryption trivial. Moreover, the application code contains a method to decrypt the affected files; thus this ransomware app can be forced to decrypt files if one invokes the appropriate method.

Decrypting the affected files:

20160808 ElGato 4

The malicious server control panel for the botnet allows several remote commands:

  • Lock/unlock the screen (with a cat image).
  • Send SMS messages to the victim.
  • Encrypt/decrypt SD card memory files (with a hardcoded password).
  • Silently steal SMS messages from the victim’s device.

20160808 ElGato 5

McAfee Labs has informed the owners of the abused servers and has requested they take down the malicious service.

This ransomware variant looks like a demo version used to commercialize malware kits for cybercriminals because the control server interface is not protected and includes in the code words such as MyDificultPassw.

These kinds of threats are usually distributed by attackers who buy exploit kits on black markets and who want to attack a specific company or group of people. The attackers often use phishing campaigns, Trojanized apps, social media networks, or other social engineering techniques.

McAfee Mobile Security detects this Android threat as Android/Ransom.ElGato and alerts mobile users if the malware is present, while protecting them from any data loss. Follow this link for more information about McAfee Mobile Security.

For help in combatting ransomware, follow this link to the site No More Ransom!

To keep up with the latest security threats, follow @IntelSec_Home on Twitter and like us on Facebook.

 

The post ‘Cat-Loving’ Mobile Ransomware Operates With Control Panel appeared first on McAfee.

Setting Up HTTPS for Google App Engine Applications

Thursday, we posted advice on creating a custom domain name for an application developed with Google’s App Engine. In this post, we will learn how to add SSL support and force the App Engine application to use only SSL.

Start by obtaining an SSL certificate for your domain from an authorized certificate authority. Consider following elements while buying the certificate:

  • The name of the certificate should match the domain name. The certificate can be a single domain or multidomain but should not be a wildcard certificate.
  • The certificate should be signed using a strong signing algorithm such as SHA-256.
  • For financial and other sensitive applications, it is best to have an extended validation for the certificate.

Before adding SSL support, make sure you have added a custom domain name for your application. If not already done so, you can refer to this blog and follow these steps:

Regardless of whether you use a custom domain for your application; it is important to note that by default HTTPS is not strictly enforced for App Engine applications. This means your web application will be available over plain HTTP and HTTPS. HTTP is a clear-text protocol, and sensitive information is sent unencrypted over the network; that is not safe. Now let’s see how we can enforce HTTPS for the applications developed using App Engine:

Add these two lines in the file app.yaml in the folder WEB-INF:

url: .*
secure: always

For Java applications, we can achieve the same effect through the file web.xml:

<web-app>
………
<!– Enforcing HTTPS –>
<security-constraint>
<web-resource-collection>
<web-resource-name>HTTPS</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
………
</web-app>

HTTP Strict Transport Security

The preceding method of enforcing HTTPS works via redirection. If a user issues a request over HTTP, it will be redirected to HTTPS. The problem with this initial HTTP request is that it is vulnerable to a man-in-the-middle attack, allowing an attacker to redirect the user to a malicious page. For example, a user connects to an open Wi-Fi service at an airport or café and requests web application over HTTP. Because this Wi-Fi is controlled by the attacker, the user is redirected to a malicious page instead of the real web application. To protect users from such scenarios, a web application can make use of the HTTP Strict Transport Security (HSTS) header. Through HSTS, a web application can instruct a browser that the site can be accessed only using HTTPS.

HSTS can solve this problem only if a user has previously accessed the web application over HTTPS.

To use HSTS headers with the App Engine, the domain needs to be whitelisted by contacting [email protected].

 

Reference

https://cloud.google.com/appengine/docs/java/console/using-custom-domains-and-ssl

The post Setting Up HTTPS for Google App Engine Applications appeared first on McAfee.

Oracle-owned point-of-sale service suffers from malware attack

MICROS, an Oracle-owned division that's one of the world's top three point-of-sale services, has suffered a security breach. The attack possibly comes at the hands of a Russian crime gang that siphoned out more than $1 billion from banks and retailers in past hacks, security news site KrebsOnSecurity reported Monday.

Oracle representatives have told reporter Brian Krebs that company engineers "detected and addressed malicious code in certain legacy MICROS systems" and that the service has asked all customers to reset their passwords for the MICROS online support site. Anonymous people have told Krebs that Oracle engineers initially thought the breach was limited to a small number of computers in the company's retail division. The engineers later realized the infection affected more than 700 systems.

Krebs went on to report that two security experts briefed on the breach investigation said the MICROS support portal was seen communicating with a server that's known to be used by the Carbanak Gang. Over the past few years, Carbanak members are suspected of funneling more than $1 billion out of banks, retailers, and hospitality firms the group hacked into.

Read 4 remaining paragraphs | Comments