Be wary of data stealing suspicious Mobile Apps – eScan

Be wary of data-stealing Mobile Apps:

There is a suspicion that Chinese Mobile Device manufacturers might be accessing consumer data from the smart-phones / devices, without user permission and sending it to Chinese servers which is out of Indian jurisdiction. It had recently asked these mobile handset manufacturers to submit compliance reports on safety and security implemented by them to safeguard the information and to allay the fears of consumer sentiments and protect critical data.

It is not just the Mobile device manufactures we have to wary of but also the mobile apps developers. Mobile Apps have been aggressively developing apps which require permissions to access the sensitive information under the garb of assisting their referral programs or better user experience.

Does it imply that we should be raising our guards the moment a device manufacturer or mobile apps developer transfers the sensitive data to a Chinese controlled server? We have to be judicious in our approach and trust plays an important role in matters concerning Privacy. Privacy invariably is protected by the law of the land, but hard evidence is required before we can conclude that the law has been broken.

Malicious mobile apps have been stealing sensitive data from the devices and storing them on servers, however very recently, researchers discovered a Chinese App for Smartphones, siphoning off with sensitive user data and storing them on private servers. The app in question is the “DU Antivirus Security”, it collected the personal information about its users viz. unique identifiers, contact lists and call logs which was then relayed to two different servers, with one of them belonging to an employee of Baidu. The data was reused commercially by their sister app “Caller ID & Call Block – DU Caller” and as the name suggests is related to providing Caller ID Information.

It’s a long known fact that mobile apps developers have access to user data, furthermore, they use this data for developing and building services, but how much of this is shared with Third-Party is never known unless they suffer some kind of breach or someone stumbles upon it. The third party could be Governments or Advertisement Networks, one cannot be simply sure of this back-door alliance.

It is imperative for all the Governments to wake up to the fact that it’s not just the Device manufactures but also the App Developers who may siphon off the much coveted Citizen’s Personal Information. They also need to introspect about the data being accessed by rogue governments and is the most worrying factor which has had everyone on tenterhooks.

Read More – Blog eScan

Posted in eScan 11, eScan 14, MailScan, Security | Tagged , , , | 1 Comment

Dolphin Attack – Another new threat to smartphone users

Dolphin Attack

Dolphin Attack

Dolphin Attack – Another new threat:

Can you think of a scenario where your smartphone starts making calls, sending text messages or browsing malicious websites automatically without your knowledge? Interestingly, hackers are making this possible with Siri or Google Now (phone’s assistant). Chinese security researchers from Zhejiang University have found an innovative activation of your voice recognition systems by exploiting a security vulnerability which is common among all voice assistants.

Known as Dolphin Attack, this technique works as per commands of ultrasonic frequencies that are too high for us but perfectly audible to the microphones of your devices. The cybercriminals can utter commands into your smartphones and hijack Siri or Google Now and make them open your smart lock to access malicious websites.

This attack can function on all voice recognition platforms and can affect both iOS and Android mobile platforms. Thus, your device is at risk irrespective of iPhone, Nexus or Samsung device. Since smartphone allows users a broad functionality through voice commands like calling, sending SMSs, accessing any web page or setting the phone to airplane mode, the researchers were able to order an iPhone successfully.

The research also says any cybercriminal can send inaudible voice commands to the device forcing to perform malicious tasks like:

  • Visiting any malicious website – resulting in exploitation of the victim’s device with zero-day vulnerabilities.
  • Spying — instructing the victim’s phone to start an outgoing video or phone calls and get access to the images and surrounding sound of the phone.
  • Adding bogus information — instructing the victim’s phone to send fake emails or SMS’ to publish fake information or even adding baseless events to the planner calendar.
  • Denial of Service — adding commands to turn on the ‘airplane mode,’ and then taking the device offline by disconnecting all wireless communications.
  • Concealing attacks — in order to hide the attack, the criminals many times minimize the odds by dimming the screen and lowering the device volume.

Normally, the signal given by the researchers was between 25 to 39kHz. They managed to make the attack work at 175cm, which is a practical figure for sure.

The worry of Dolphin attack:

Dolphin Attack works on anything including Siri, Google Assistant, Samsung S Voice, Huawei Hi Voice, Cortana, and Alexa, on devices such as smartphones, iPads, MacBooks etc. The voice commands that are not audible can be perfectly recognized by the SR [speech recognition] systems on the tested hardware and function even if the criminal has no direct connection to your device and inspite of all the necessary security measures taken.

How to prevent Dolphin Attacks?

In order to prevent this attack, device manufacturers are making few hardware alterations to fix the vulnerability by simply programming the mobile devices to ignore voice commands at inaudible frequencies or at 20 kHz.

From users’ perspective, a prompt solution to avoid Dolphin attacks is to turn off voice assistant apps from settings, before any official patch reaches your device. In order to disable Siri, just go to your iOS device’s settings → General → Accessibility → Home Button → Siri and then toggle “Allow Hey Siri” to off. If you wish to turn off Google Home, you can mute Google Home’s microphones, press and hold its physical mute button at the back. Using an antivirus software is advisable

Read More – Blog eScan

Posted in eScan 11, eScan 14, MailScan, Security | Tagged , , , , , , , , , | Leave a comment

Locky Ransomware extends its family with YKCOL

Locky Variant - YKCOL

A new variant of Locky Ransomware has been discovered and has been spreading through a Spam Campaign with the Subject Line “Status of Invoice”. Moreover, the attachments are compressed using 7z, rather than using the .zip extension, which can easily be uncompressed by normal users.

Ykcol also tries to delete the Shadow Volume Copy so as to refrain the user from recovering the encrypted files. However, there would be instances when deletion of Shadow Volume files fails and victims would be lucky enough to recover from this attack.

MS Windows natively provides the users with the ability to extract files from .zip archives, while the users have to install 7z in order to extract from 7z archives. Due to this, it seems the impact of this particular campaign of Locky Ransomware would not have a major impact.

Extension: .ykcol (reverse of the word Locky Ransomware)

Filename Format: [first_8_hexadecimal_chars_of_id]-[next_4_hexadecimal_chars_of_id]-[next_4_hexadecimal_chars_of_id]-[4_hexadecimal_chars]-[12_hexadecimal_chars]

Unfortunately, as of this time, it is not possible to decrypt .ykcol for free.

Prevention Measures:

• Administrators should block all executable files from being transmitted via emails.
• Administrators should isolate the affected system in the Network.
• The administrator can restore the encrypted files from the backup or from system restore point (if enabled) for affected systems.
• Install and Configure eScan with all security modules active.

1. eScan Real-Time Monitoring
2. eScan Proactive protection
3. eScan Firewall IDS/IPS Intrusion prevention
• Users shouldn’t enable macros in documents.
• Organizations should deploy and maintain a backup solution.
• Most important, Organizations should implement MailScan at the Gateway Level for email servers, to contain the spread of suspicious attachments.

Read more on Locky Ransomware – Other variants

Posted in eScan 11, eScan 14, MailScan, Security | Tagged , , , , | Comments Off on Locky Ransomware extends its family with YKCOL

CAA makes it mandatory to verify SSL issued

Certification Authourity Authourization
CAA – Certification Authority Authorization

As on September 8th 2017, it is now mandatory for the Certifying Authorities to verify the CAA record before issuing the SSL Certificate as directed by Certification Authority Authorization. The sole purpose is to tackle the menace of Fraudulent SSL Certificate generation. CAA standard has been defined in RFC6844

What is CAA?

Certification Authority Authorization(CAA) is an Industry Standard, which allows the Domain Owners to specify which Certifying Authorities (CA) is allowed to issue certificates for their domains. The intention of this is to allow the CAs to avoid mis-issuing of certificates and is an added checking/verification process in their Certificate Issuing Procedures.

Before any certificate is issued, the CA would verify the CAA record to check for its own existence in it and would block any request in case they are not listed.

How to use CAA?

The Domain owner has to publish Certification Authority Authorization(CAA) records the Domain’s DNS specifying the

  1. List of CAs authorized to issue SSL certificates for that domain.
  2. Policies for the entire domain or for specific hosts
  3. Single-Name Certificates, Wildcard Certificates or both can also be mentioned.

Why use CAA?

There have been numerous instances in the past wherein, Certifying Authorities were hacked and fraudulent certificates were issued. Furthermore, in our previous blog-posts too we had raised concerns about the lack of verification and decentralized structure of the CAs which allowed any CA to blatantly issue SSL Certificates on behalf of any domain. Due to this issue, it was of utmost importance to provide a control and verification method of the domain owners to provide and share information with the CAs so that CAs themselves are aware whether or not they are allowed to issue the certificate or not.

It is now the prerogative of the Domain Owners to provide CAA information in case they are using Certificate and it would be the responsibility of the CAs to validate each and every request.

List of DNS Servers Implementing CAA

Although, Certification Authority Authorization(CAA) is fairly new Standard hence, there are very few DNS Servers which provide support for the addition of CAA records.

BIND Yes Prior to version 9.9.6 use RFC 3597 syntax
Knot DNS ≥2.2.0
ldns ≥1.6.17
NSD Yes Prior to version 4.0.1 use RFC 3597 syntax
OpenDNSSEC Yes With ldns ≥1.6.17
PowerDNS ≥4.0.0 Versions 4.0.3 and below are buggy when DNSSEC is enabled.
Simple DNS Plus ≥6.0
tinydns Yes Use generic record syntax
Windows Server 2016 Yes Use RFC 3597 syntax

Domain Owners may check with their respective Domain Registration Service Providers whether they provide addition of CAA records in their DNS Configuration Panel.

In order to create CAA Record, domain owners may visit https://sslmate.com/caa/

How to Verify CAA?

The two of the most popular tools used for looking up DNS records are “dig” and “nslookup”, and both these tools use the “type257” as the query parameter for the CAA.

$ dig google.com type257

;; ANSWER SECTION:
google.com. 86399 IN TYPE257 \# 19 0005697373756573796D616E7465632E636F6D
google.com. 86399 IN TYPE257 \# 15 00056973737565706B692E676F6F67

c:\> nslookup
> set q=type257
> google.com
Server:         8.8.8.8
Address:        8.8.8.8#53
Non-authoritative answer:
google.com rdata_257 = \# 19 0005697373756573796D616E7465632E636F6D
google.com rdata_257 = \# 15 00056973737565706B692E676F6F67

However, these tools are yet to implement CAA record lookup, hence with these tools, you may summarize that there exists a CAA record.

One may visit our domain tools section to lookup for CAA records

Eg: google.com

;; ANSWER SECTION:
google.com.	86399	IN CAA 0 issue "pki.goog"

A complicated CAA Record by hboeck.de

;; ANSWER SECTION:
hboeck.de.	3599	IN CAA 0 issue "letsencrypt.org"
hboeck.de.	3599	IN CAA 0 issuewild ";"
hboeck.de.	3599	IN CAA 0 iodef "https://int21.de/caa/"
hboeck.de.	3599	IN CAA 0 iodef "mailto:hanno@hboeck.de"

Threat Attack Scenarios

With the implementation of CAA the footprint of the attack surface reduces and shifts towards the addition of CAA records by the Domain Owners

  1. Non-Compliance of adding CAA Records in the DNS by Domain Owners
  2. Compromised DNS Panel of the Domain Owner

Fraudulent Digital Certificates – A different Perspective

Fake Google SSL Certificates – Courtesy NIC

Posted in eScan 11, eScan 14, MailScan, Security | Tagged , , , , , | Comments Off on CAA makes it mandatory to verify SSL issued