Most Recent News from the Lab
 

Wednesday, August 20, 2014

 
Data vs. Metadata Posted by Sean @ 13:10 GMT

Google uses HTTPS for all search queries. That's good, because it means that all of the questions you ask (a.k.a. your data) will be encrypted. However… regardless of HTTPS, inferences about your searches can still be made by somebody with access to your network traffic. For example:

Network Traffic Analysis, Google to AA

In the screenshot above, a popular "packet analyzer" displays DNS queries (a.k.a. metadata). We first connected our test device to google.com and performed a search — and then we clicked on the top search result link — and connected to aa.org.

The deductive reasoning skills of Sherlock Holmes aren't required to figure out "alcoholics anonymous" was searched for. And even if aa.org used HTTPS encryption (it doesn't), using DNS metadata, we can still infer the contents of the search data. The connections made offer all the evidence needed.

And that's why metadata matters.

 
 

 
 
Friday, August 15, 2014

 
Ransomware Race (Part 4): Adult Content, Browlock's Staying Power Posted by Patricia @ 14:51 GMT

Lately, our eyes have been caught by the rise of Ransomware families. It is very evident that the bad guys are constantly developing this type of malware family as seen in our previous posts about CryptoWall and CTB-Locker and Synolocker. In addition to these families, we have also been observing a rather simpler type of Ransomware, yet pretty active and very much alive since it was first encountered in 2013 - Browlock.

Compared to other Ransomware families, Browlock does not encrypt the victim's files, and does not add nor run any files on the victim's machine. It only scares the user by “locking” the browser with an alert that claims to be from the police or authorities, stating that the victim has committed a crime by viewing child pornography website or downloading pirated software. It prevents the user from closing the browser, but terminating the browser process using task manager, for example, resolves the problem.

The following are statistics taken from Browlock hits in our telemetry from June onwards.

HitCount2 (51k image)


According to our statistics, the target victims were users visiting adult sites. More than half of them were redirected to Browlock pages after going to adult-related websites. Others were redirected through the use of ad networks. We didn’t notice any adult website that stood out from our data, however, for the ad networks percentage, almost 60% were from trafficbroker.com alone.

referer (63k image)


Browlock's landing pages have different IPs and URLs from time to time. You may see more observation of this from malekal’s website . The URLs may look random, however it has noticeable patterns. Below are some examples:


 •   http:// alert. policecoin. info/ FI/cls.php
 •   http:// alert. porschepolice. net/ FI/cls.php
 •   http:// alert. xraypolice. com/ FI/cls.php

 •   http:// alert-police. barbrastreisandagent. com/
 •   http:// alert-police. estateagentsolutions. net/

 •   http:// attention.starpolice. biz/FI/cls.php
 •   http:// attention.starpolice. co/FI/cls.php

 •   http:// police. grantscards. com/
 •   http:// police. redunderground. com/

 •   http:// security-scan-nuqbqakx. in/
 •   http:// security-scan-jdytiujg. in/

 •   http:// system-check-abevbrye. in/
 •   http:// system-check-ipxmjdry. in/

 •   http:// security-akechksv-check. in/

 •   http:// security-zxqkcohl-chk. in/

 •   http:// law-enforcement-tqvrlbqb. in/
 •   http:// law-enforcement-icgkjyrr. in/

From the month of June, we have observed the following most reported URLs in our upstream, with its corresponding IPs where it is hosted:

IPtable3 (62k image)


The graph below shows the duration of these URL patterns being actively reported in our upstream. It seems that on average, Browlock was able to keep a single URL pattern of its landing pages for about two weeks to a month long.

ip_graph2 (92k image)


We have also noticed that United States, United Kingdom, and countries in Europe were the most affected.

top5countries (8k image)


We’ve seen this operation going on for quite a while now, wondering if the bad guys are really getting money from this very simple mechanism. We don’t really know for sure how many victims have given in into paying a ransom from its fake alert message. But what we know for sure, is that while we see this ransomware families being active, we will keep our eyes open to keep protecting our customers from this threat.

 
 

 
 
Thursday, August 14, 2014

 
Testing the Xiaomi RedMi 1S - now with OTA update Posted by FSLabs @ 05:42 GMT

On August 10 Xiaomi addressed privacy concerns related to the MIUI Cloud Messaging function of its smartphones by releasing an OTA update intended to make this an opt-in feature, rather then a default one.

Since we already had the phone set up, we downloaded and applied the update to the same Redmi 1S phone we used in the previous testing:

xiaomi_otaupdate (48k image) xiaomi_phone (124k image)

Then we factory reset it. Once the phone restarted, we noted that cloud messaging is now by default set to Off under Settings:

xiaomi_phone_settings (42k image)

We then went through the following steps:

   • Add a new contact
   • Send and receive an SMS message
   • Make and receive a phone call

During these activities, we did not see any data being sent out from the phone.

Next, we activated the cloud messaging function and logged into the Mi Cloud. At this point, we saw base-64 encoded traffic being sent to https://api.account.xiaomi.com:

for_xm_cropped (181k image)

Note that this is now over HTTPS rather than HTTP, as seen in our previous testing. We had to use a HTTPS proxy in order to view what was being passed:

traffic_cropped (33k image)

This was a quick test to check if the update had addressed points highlighted in various media reports. Xiaomi VP Hugo Barra has also posted more details of the MIUI Cloud Messaging implementation.

 
 

 
 
Wednesday, August 13, 2014

 
Ransomware Race (Part 3): SynoLocker Under The Hood Posted by Artturi @ 13:17 GMT

Last week we wrote about a new ransomware family called SynoLocker that was targeting network attached storage devices manufactured by Synology. Initial rumours suggested SynoLocker might be related to the infamous CryptoLocker, so we decided to dig deeper.

On the surface, SynoLocker and CryptoLocker share many similarities, not the least of which are a similar name, similar choice of encryption algorithms and the idea of extorting money from victims. Under the surface however, the similarities quickly end. When first infected with SynoLocker, a unique RSA key pair is generated for the victim. The private key never leaves the malware operator(s) but the public key is stored onto the victim device. This public key can be used to encrypt data in such a way that it can only be decrypted with the associated private key. As long as the malware operator(s) are in control of the private key, they can deny the victim access to their encrypted files.

For encrypting the actual contents of the victims files, SynoLocker uses AES. First an initialization vector (IV) is generated from the size and name of the file to be encrypted. This IV is later used by the encryption algorithm, but it is also used, combined with a randomly generated string, to generate the actual encryption key. Next, the contents of the original file are encrypted. Simultaneously, a so-called keyed-hash message authentication code (HMAC), commonly used to verify the integrity of data, is also generated from the unencrypted data. Finally, the random string used to generate the key is encrypted using the RSA public key. This ensures, that the only way to regenerate the key for decrypting the data, is by first decrypting the random string using the RSA private key.

Diagram of the encryption process and resulting file
Diagram of the encryption process and resulting file

Once finished with the encryption of a file, SynoLocker will replace to original with a new one. To the new file, SynoLocker first writes the RSA-encrypted random string. Next, it writes a marker string "THE_REAL_PWNED_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX_1337" (for those counting, there are 40 Xs) which it uses to identify files it has encrypted. After the marker, the IV used in the encryption process is written. Next, the encrypted version of the original file contents is written to the new file. Finally, the HMAC generated during the encryption process is written to the end of the new file. All this is done by SynoLocker in such a way, that were anything to fail or go wrong at any point during the process, the original data would not be lost. Only once everything is done, will SynoLocker replace the original file with the new one. Finally, it will also attempt to overwrite the original file with random data to make recovery more difficult.

File encrypted by SynoLocker, as viewed in a hex editor
A file encrypted by SynoLocker, as viewed in a hex editor (Arrows pointing to beginning of marker string)

When attempting to decrypt files, the above described process is essentially reversed. First SynoLocker obtains the random character string by decrypting it with the victims RSA private key. Next, the string is used together with the IV obtained from the encrypted file, to generate the actual AES key. Finally, the file data is decrypted using this key. At the same time, SynoLocker generates a new HMAC from the decrypted data. Finally, the HMAC of the original data is compared with the newly generated HMAC and only if they match, is the decryption process deemed successful. Again, this ensures, that if anything goes wrong during the process, existing data is not lost.

In addition to the encryption methods used by SynoLocker, we were also interested in finding out more about the infection vector(s) used. Despite our best efforts, we have so far been unable to identify the exact infection vector used by SynoLocker. It is however clear, that SynoLocker is more a collection of files uploaded to the device through the infection vector, rather than just a single malicious binary. These files all have specific purposes and are often dependent on each other to fully function. A list of SynoLocker related files is available at the end of this post.

While analysing the SynoLocker binaries, we have also continued monitoring other aspects of the operation, and it seems the operator(s) are on the move. Recently, the website where victims are instructed to go to for payment instructions, has been updated. The page now includes the notice "This website is closing soon...". The operator(s) also claim that they are still in possession of over 5500 private keys but that they are willing to sell the entire collection for 200 bitcoins.

Recent screenshot of SynoLocker website
Recent screenshot of SynoLocker website

Whether the operator(s) follow through with their plans and what that might entail for victims will remain to be seen.

List of SynoLocker related files:
/etc/synolock/server
/etc/synolock/synosync
/etc/synolock/synolock
/etc/synolock/crypted.log
/etc/synolock/decrytped.log (spelling mistake in SynoLocker)
/etc/synolock/RSA_PUBLIC_KEY
/etc/synolock/RSA_PRIVATE_KEY
/etc/synolock/.restore
/etc/synolock/.decrypt
/etc/synolock/watch.sh
/etc/synolock/uninstall.sh
/etc/synolock/watchdogtest.sh
/usr/syno/synoman/crypted.log
/usr/syno/synoman/decrypted.log
/usr/syno/synoman/index.html
/usr/syno/synoman/redirect.html
/usr/syno/synoman/lock.png
/usr/syno/synoman/style.css
/usr/syno/synoman/synolockcode.txt
/tmp/.SYNO_ENCRYPT_LOCK
/tmp/.SYNO_DECRYPT_LOCK
/tmp/.SYNO_SERVER_LOCK
/tmp/.server
/usr/syno/etc.defaults/rc.d/S99boot.sh
/usr/syno/etc.defaults/rc.d/S99check.sh

Sample hashes:
9ccd05d4afe6bedac7aa6695c78d5475df5f9b0d (server)
c160c1fd18841ebb5e4186ef5ac7ef223b688bc4 (synosync)

We detect these as Trojan:Linux/SynoLocker.A

Post by Artturi (@lehtior2)

 
 

 
 
Tuesday, August 12, 2014

 
Timo Discusses Dynamic Analysis of Flash Files Posted by Sean @ 13:24 GMT

Senior Researcher Timo Hirvonen presented at Black Hat USA 2014, and publicly released a tool which enables dynamic analysis of malicious Flash files. He spoke about it with SC Magazine's Adam Greenberg last week:


Video source

Download the tool from GitHub: F-Secure / Sulo

 
 

 
 
Thursday, August 7, 2014

 
Testing the Xiaomi RedMi 1S Posted by FSLabs @ 03:42 GMT

Xiaomi phones have made the news off and on in the last few months for their cheap, value for money phones and corporate moves. More recently, there were also reports that these popular devices also silently sent out user details to a remote server. That news came on the heels of other reports of smartphones being pre-installed with suspect apps.

We thought we'd take a quick look into this, so we got our hands on a brand new RedMi 1S:

xiaomi redmi

We started with a "fresh out of the box" test, so no account setup was done or cloud service connection was allowed. Then we went through the following steps:

  •  Inserted SIM card
  •  Connected to WiFi
  •  Allowed the GPS location service
  •  Added a new contact into the phonebook
  •  Send and received an SMS and MMS message
  •  Made and received a phone call

We saw that on startup, the phone sent the telco name to the server api.account.xiaomi.com. It also sent IMEI and phone number to the same server:

xiaomi data

The phone number of the contacts added to the phone book and also from SMS messages received was also forwarded.

Next we connected to and logged into Mi Cloud, the iCloud-like service from Xiaomi. Then we repeated the same test steps as before. This time, the IMSI details were sent to api.account.xiaomi.com, as well as the IMEI and phone number.

At this point, this was just a quick test to see if the behavior being reported can be confirmed. In response to the reports, Xiaomi itself has released a statement addressing potential privacy concerns (In Chinese on the company's Hong Kong Facebook page, with an English translation linked).

Updated to add:

Hugo Barra, a vice president at Xiaomi, posted this on August 10th: MIUI Cloud Messaging & Privacy.

 
 

 
 
Wednesday, August 6, 2014

 
Ransomware Race (part 2): Personal media the next frontier? Posted by Artturi @ 09:36 GMT

It seems malware authors have recently taken a liking to the network-attached storage (NAS) devices manufactured by Synology Inc. First they were hit by Bitcoin mining malware in the beginning of this year and now by file encrypting ransomware similar to CryptoLocker. NAS devices are used by home and business users alike to easily store and share files over a network. Many, like ones manufactured by Synology, also feature remote access. In this case, it would seem hackers were able to abuse the remote access feature, possibly by exploiting a vulnerability in older versions of the Synology DSM -operating system, to gain access to the devices. Once they had access, they proceeded to install a ransomware they have dubbed "SynoLocker".

Once the device has been infected with SynoLocker, the malware will proceed to encrypt files stored on the device. It will search the device for files with extensions matching a hardcoded list (shown below). Extensions are matched such, that only the beginning of the extension needs to match the hardcoded list. This means, for instance, that both .doc and .docx files will be encrypted, since the list contains ".do".

Screenshot of extension list hardcoded inside SynoLocker
Extension list hardcoded inside SynoLocker

Once all files have been encrypted, SynoLocker will present the user with a ransom message. The ransom message instructs the user to first download and install the Tor Browser Bundle. Next, users are to browse to a specific website on the Tor network. On that website, users will be further instructed to make a payment of 0.6 BTC (approximately 260€ or 350USD) to a specific Bitcoin wallet. Once payment has been received, the malware author(s) promise to supply the user with a decryption key for recovering their files.

synolocker (98k image)
Screenshot of the SynoLocker page on the Tor network as presented to victims

The ransom message presented by the malware also purports to describe the technical details of the encryption process. The process described is very similar to the process used by the infamous CryptoLocker ransomware family. The process begins with the generation of a unique RSA-2048 keypair on a remote server. Next, the generated public key is passed to the malware. When encrypting files, the malware will generate a separate, random 256-bit key that is used to encrypt the files with the AES-256 CBC symmetric cypher. The key used for this encryption process is next encrypted with the RSA-2048 public key and stored on the device before being removed from the device memory. If implemented correctly, this process ensures, that the only way to restore the encrypted files is by obtaining the RSA-2048 private key and first decrypting the file containing the 256-bit encryption key used.

Based on our analysis of SynoLocker, the malware author(s) have followed through with their threats and have properly implemented the process described. Sadly this means any files stored on the NAS device will have been lost unless the user has kept a separate backup. There have also been reports of users paying the malware author(s) and successfully receiving the RSA-2048 private key and decrypting their files, but we strongly discourage ever paying malware authors. It only encourages them to continue their malicious work.

For users of Synology NAS devices, we highly recommend following Synology's official advice on mitigating or remediating this threat.

Sample hashes:
9ccd05d4afe6bedac7aa6695c78d5475df5f9b0d
c160c1fd18841ebb5e4186ef5ac7ef223b688bc4

We detect these as Trojan:Linux/SynoLocker.A

Post by Artturi (@lehtior2)