How to protect your android from viruses. Protect your phone from loss or theft - Android Device Manager. Web and App Security

The recently unveiled iPhone 7 confirmed fears that Apple is in a major crisis of ideas. The main novelty of the model was the rejection of the traditional headphone jack, which was replaced by wireless plugs for 12,990 rubles (twelve thousand nine hundred ninety rubles).

Here are some security tips for those who have finally decided to switch from iOS to Android (and also for long-time fans of the platform from Google):

1. App Lock

Sometimes acquaintances ask for your smartphone to look at photos or quickly find something on the Internet. It's inconvenient to say no, but you don't want strangers digging into your personal files. Especially for such cases, Android 5.0 Lolipop introduced the ability to lock the device in desired application.

To activate the function, go to the section Security - Lock in the application - On.

After that, in any desired application, you can click the "Recent" button, and then the pin icon. The app will open, but you won't be able to exit it.

To unlock, press Back and Recents at the same time, then enter your PIN or password.

2. ESET Mobile Security

Home protection for your Android - reliable antivirus, the effectiveness of which has been proven by independent virus laboratories.

Comprehensive protection devices in real time provides cloud technology ESET Live Grid, Antiphishing and Antispam modules. The function will make the Android gadget safe even for the smallest ones.

Module to determine the location of the smartphone by GPS if the device is lost or stolen. In addition, Anti-Theft allows you to remotely block your gadget or erase all data so that they do not fall into the wrong hands.

3. Password Manager

Any Internet user has dozens or even hundreds of accounts on various sites and services. However, few people can remember a unique password for each of them, so the same password is used almost everywhere (you are no exception, right?)

It's good that application developers have already taken care of solving this problem. Password managers like LastPass or 1Password help users generate and store any number of passwords.

How to come up with complex password and remember it forever, read in.

4. Two-factor authentication

Try to minimize the risk of data leakage and use the two-factor authentication feature wherever possible.

Most modern services allow you to enable confirmation of authorization by SMS. Thus, scammers will not be able to access your account if they do not have your mobile phone in their hands.

Some applications allow you to do without SMS (for example, Authy). The program automatically generates a six-digit code that disappears after 12 seconds. You can use Authy with all services that support two-factor authentication.

5. Smart unlock Smart Lock

All gadget users know that a device screen lock adds an extra layer of security against online and offline threats. However, most ignore this security measure because entering a PIN dozens of times a day can be very tiring.

Luckily, the developers of Android 5.0 Lolipop figured out how to bypass annoying passwords without sacrificing security. Smart Lock feature allows you to unlock mobile device 3 ways:

• Trusted Devices - The device unlocks when a familiar Bluetooth or
• Safe places - unlocking the device by geolocation (for example, at home or in the office)
• Face recognition - the device is unlocked if the gadget "recognized" the owner

1. Settings - Security - Screen lock
2. Select one of the screen lock methods (other than Swipe)
3. Go to the end of the list, find Trust Agents and activate Smart Lock
4. Go back to the beginning of the "Security" section and open the Smart Lock menu
5. Select one of the smart unlock options listed above

While the Android operating system is indeed slightly more vulnerable to malware attacks than iOS, the situation with it is by no means as bad as Apple would like you to believe. A few simple tricks and a bit of common sense will make your system invulnerable to any attack.

1. Set a lock screen

Yes, Android's lock screen doesn't look like much of a barrier - but even that can provide some protection against random attacks.

It gives you several unlock options - pattern, pin, password and Face Unlock, at least on stock Android devices. Of the above methods password is the most secure. A pin code is technically more chaotic than a pattern (at least in theory). However, the pattern, although it looks funny, leaves you vulnerable to attacks on it - which, according to analysts, work in ideal conditions 68 percent of the time.

But whichever method of protection you choose is still better than no protection at all, and a simple password can repel most casual attacks. Believe me, it's worth one second of inconvenience 50 times a day.

2. InstallAnti— Malwareprogram

Just like on Windows machines, having some kind of anti-virus program on your system will be very helpful. There are a large number of Anti-Malware programs, many of which are free. Well deserved recommendations Lookout, AVGandAvast. They are able to track malicious code, check installed applications by database known threats and generally monitor safe work your phone.

3. Don't cache passwords

This is somewhat annoying, but true. Password caching is, of course, incredibly convenient, but it's also a gift from heaven to someone who can steal your phone. Thanks to them, an attacker from one phone can extract the logins of your Email, accounts social networks and many other things. Of course, other security measures, like lock screens, provide some protection, but the only reliable method here is to simply refuse to save passwords. Basically, your internet browser—in other words, Chrome—stores them.

4. Check SuperUser Privileges

If you have rooted your Android (which is generally more than justified), you need to be especially vigilant in matters of security. Rooting your phone allows apps to run as root, bypassing standard system checks. A rooted malicious app will be incredibly dangerous - in fact, it will be able to do whatever it wants on your phone without your knowledge (this is the main reason why phones don't come with root rights out of the box).

but this is not a reason not to root. Instead, you just need to pay a little more attention to managing your applications. Once rooted, you will most likely install SuperSU or Superuser, which allows you to root applications and see which programs are actually using their advanced privileges. Be extremely careful about the programs you give SuperUser permission to - only give them to trusted apps from trusted sources. It is also useful to review the list from time to time and remove unnecessary programs from it.

5. Install apps ONLY from trusted sources

One of the most common methods of Android infection is downloading an infected application. An anti-malware program, as mentioned earlier, can give you one extra layer of protection against such threats by flagging everything it finds suspicious.

But the best protection is definitely common sense. Thanks to Google's efforts, most of the apps in the Android store are clean and threats come mainly from various exploits that infect common applications, for example, through an advertising system. In any case, well-known and popular applications are more likely to be secure; installing programs from third-party resources will always be potentially dangerous, and the whole question in this case comes down to the level of your naivety (or, if you like, gullibility).

Many experts recognize Android as not only the most popular, but also the most vulnerable platform. By exploiting a hole in the security system and gaining access to the device, attackers can do almost anything they want with it: send SMS to paid numbers, spy on personal correspondence and steal credit card numbers. How to protect yourself from viruses and arm your "robot" to the teeth - read the material Vestey.Hytech.

The security issue should first of all be paid attention to by owners of devices running Android versions 2.3 (Gingerbread) and 4.0 (Ice Cream Sandwich), which, based on a recent report from Kaspersky Lab, are more vulnerable than others. Edition 4.1 / 4.2 (Jelly Bean) is not yet very common due to segmentation of the Google platform, and writing viruses for outdated versions(2.2 Froyo, 2.1 Eclair and others) is not as cost effective. However, this does not diminish the significance of the problem.

According to LK, which relies on data from its own antivirus, it was Gingerbread (2.3.6) that accounted for 28% of blocked attempts to execute malicious code, and ICS (4.0.4) for 22%. In the third quarter, more than half of the threats, the company notes, turned out to be associated with SMS Trojans. Of particular note was the OpFake family (found in 38.3% of all malware for Android), masquerading as the Opera Mini browser. Plangton Trojan, which collects data on a smartphone, sends it to the "command center" and waits for commands from cybercriminals, accounted for a fifth of all attacks. This Trojan can silently change bookmarks and the home page. The third place was taken by the FakeInst family (17%), which imitates popular applications, but in reality turns out to be a Trojan or a backdoor.

Data coming from other companies is also disappointing. According to IDC, 75% of smartphones shipped worldwide ran Android in Q3, making Google phones an ideal target for virus writers. According to research (PDF) conducted by F-Secure, 51,447 unique Android virus samples were detected in Q3. This is many times more than the malware found in the second (5 thousand 33) and first (3 thousand 63) quarters of 2012.

And Lookout previously estimated that a million dollars was stolen from Android users in 2011. Obviously, by the end of 2012, much more will be stolen. In connection with the growing pandemic of Trojans and rootkits, Vesti.Hitek decided to give some tips on how to protect your Android smartphone from threats.

Install and update your antivirus regularly. Protecting your smartphone is just as important, if not more so, than your computer. The phone stores information related to a specific person, so location, personal correspondence, phone numbers you called, and other personal data that can be sold can be obtained by hackers. However, according to Trend Micro for the third quarter, only one in five Android device owners use antivirus.

However, it is necessary to have such a program. In addition to protecting against "harmful" applications, mobile antiviruses offer many other useful features. For example, they can remotely lock a smartphone if it is stolen or lost, or automatically backup contacts.

One of the best defenders is Norton Mobile Security. The antivirus can remotely delete all information, protect against unwanted calls and SMS, detect phishing (fake) sites and tightly block the smartphone if a SIM card is pulled out of it. In addition, it scans directories for threats not only on the device itself, but also on the SD memory card.

Norton offers several plug-ins for antivirus: application manager and running processes, protection from "bad" QR codes, parental control.

Another antivirus of this kind is avast! Mobile Security used by over 10 million people. Its capabilities are the same as those of Norton: scanning links for malicious code, a web panel for tracking a smartphone using GPS, remote blocking and cleaning content, an SMS and call filter. Also avast! keeps track of incoming/outgoing traffic and how much memory applications consume.

Android is a young operating system, and, like any other newborn OS, it is customary to blame it for the lack of an adequate level of security. Antivirus companies and industry analysts are reporting a real boom in Android malware and are predicting an army of zombie viruses that will soon empty users' wallets. But is it vulnerable? green robot in fact?

Introduction

In the early days of its development, Android became a real magnet for attacks from antivirus companies and independent researchers: Google engineers were accused of shortsightedness, a huge number of flaws, and the general unreliability of the Android architecture. This applied to all components of the system, but the main blow of the experts fell on the implementation of the rights differentiation mechanism, which allegedly limited applications from each other, but had a gap in its very foundation.

Examples commonly cited were applications that used exploits of the Linux kernel, which made it possible to obtain root permissions, and then do whatever the attacker wants with the system. These few vulnerabilities found were enough to create a hype in the tabloids that has not subsided to this day.

But how are things really? Does the problem exist or not? Should Android users be afraid for the safety of their data, or switch to iOS, and how, if possible, to protect their data from intruders? All this is narrated by our today's review.

Hole in a hole?

At its core, Android relies on the Linux kernel to do most of the dirty work for it. Linux is responsible for such things as respecting access rights, keeping track of processes and their correct execution. In fact, this means that none android app cannot access another application's data until the latter wishes to do so.

This is done in a simple and excellent way: by respecting access rights. In Android, each application is a separate user with its own access rights and permissions. Each application in such a system gets its own user ID (UID) and its own directory inside the /data directory, so that all its data is protected with simple permissions that allow the application itself to read own files, but prevent any other process from doing so.

In Android, this is called sandboxing, which allows you to keep the data of neighboring applications from each other, preventing malware from stealing private information saved by any application on the system. Absolutely all applications fall into the sandbox, including those pre-installed on the device. In fact, only a small part of Android runs as root, namely initial process zygote, which performs application execution control functions, and a small part of system services. All other applications always work in sandboxes, which is why malware, even if it has been “stealed” to the user, cannot steal anything of value except the contents of the SD card, which is open to everyone by default (we will return to this later).

In addition to the data of individual applications, the basic Android installation, which is located on a separate section of the internal NAND memory and connected to the / system directory, is also closed for access. By default, it is mounted in read-only mode and, in principle, does not store any confidential information(sandboxes in /data are also used to place it), so it will not work in some cunning way to register at startup or modify system components (unless, of course, you use exploits to obtain root rights, which I will discuss in more detail below).

Several options for IPC are available for applications to communicate, with native Linux communication tools such as shared memory and sockets being available only to processes that belong to the same application, and even then only if at least part of the application is written in a language compiled to machine code , i.e. using the Android NDK. In all other cases, applications will be able to use Binder for secure messaging and intents to call third-party applications (we will also talk about them below).

Interestingly, in Android, since version 2.2, there is the concept of a device administrator, but it does not mean at all what UNIX and Windows users understand by it. It's just an API through which an application can change the password security policy, as well as request the need to encrypt the data store and perform a remote wipe of the smartphone. This is a kind of crutch that was invented in response to requests from corporate Android users who wanted more control over the security of data on employee smartphones. In fact, any application can use this API, but for this the user must explicitly confirm their intention to grant such permissions to the application. Also in the latest versions of Android, it became possible to boot the device into safe mode when the user only accesses the pre-installed apps. It may be needed if the device is compromised by a third-party application.

Starting with version 3.0, Android has native support for encrypting all user data using the standard dmcrypt subsystem of the Linux kernel. Encryption is performed in respect of the /data directory itself with the AES128 algorithm in CBC mode and ESSIV:SHA256 using a key generated based on a password that must be entered during OS boot. It should be borne in mind that the memory card is not encrypted, so the data stored on it remains completely open.

Applications and Permissions

Along with the sandbox, one of the main mechanisms of the system android security are the access rights of applications to the functions of the Android system (privileges), which allow you to control which OS features will be available to the application. These can be both camera functions or access to files on a memory card, as well as the ability to use functionality that can lead to leakage of information from a smartphone (access to the Web) or to a waste of user funds from an account mobile operator(sending SMS and making calls).

Android has a wonderful feature: absolutely any application must contain information about which of the Android functions it can use. This information is contained in the AndroidManifest.xml file inside the APK file and is extracted by the installer before installing the application so that the user can familiarize himself with what smartphone functionality the application can access. In this case, the user must necessarily agree with this list before installing the application.

At the dawn of Android, this approach was criticized as too naive, however, as time has shown, its effectiveness turned out to be extremely high. Despite the fact that most users ignore the list of privileges before installing the application, many get acquainted with it and if they find any inconsistencies (for example, when the game asks for the ability to send SMS or access to the address book), they talk about it in the reviews and put one star . As a result, the application gets a low overall rating and a large number of negative comments very quickly.

I would also like to note that all possible privileges are quite clearly and logically separated, due to which there is practically no abuse of privileges. For example, an application may require the ability to read SMS, but not send them or receive notifications of incoming messages. In fact, the only serious drawback of the privilege system was found only in the fact that Google engineers did not provide any restrictions on reading the memory card at all (writing is nevertheless limited), considering it meaningless for removable drives. At one time, this "gap" led to the possibility of obtaining smartphone coordinates, obtained from the cache of the standard Gallery application, which was stored on a memory card. Which, in turn, forced Google to add to the settings latest versions android option, after activation of which the system will explicitly ask the user about the possibility of accessing any application to the SD card.

Another important feature of such a system is that user settings will always take precedence over application requests, which means that if the user turns off GPS, the application will not be able to turn it on on its own, even if it has all rights to use GPS. At the same time, some OS functions are not available for applications at all. For example, only the operating system has the right to manipulate the SIM card, and no one except it.

Privilege checking takes place at the lowest level of the OS, including the Linux kernel, so to bypass this security system, the malware will not only have to gain root rights on the device, but also somehow compromise the kernel, which is a much more difficult task.

IPC

As mentioned above, applications can exchange information using standard Android Tools Binder communications, Intents, and Content Providers. The first is a remote procedure call (RPC) mechanism implemented at the Linux kernel level, but controlled by the Service Manager system service. From the point of view of the programming interface, Binder is just a means of importing objects from another application, but from the point of view of security, it is completely controlled by the access rights differentiation mechanism discussed above. This means that applications can only access each other if they both want to. This is especially important in light of the fact that in Android Binder is the main communication tool on which the GUI, as well as other OS components available to the programmer. Access to them is restricted using the privilege mechanism discussed above. Both system components and third-party applications can restrict access to their functionality by declaring rights to access their functions. In the case of system components, they are all described in the documentation for Android application programmers. Independent developers who wish to expose an API to their applications should describe the required privileges in AndroidManifest.xml and publish the relevant documentation. This also applies to Content Providers, a special interface (also implemented on top of Binder) through which applications can share their data with other applications. In Android, data providers are everywhere, including the address book, playlists, and settings storage. Access to them is again limited by the mechanism of privileges and access rights.

On top of Binder, the so-called technology of intents is also implemented, simple broadcast messages. Applications can send them "into the system" in order to call external applications to perform some action. For example, an application might use intents to call mail client indicating the address, opening a web page, directory in file system and anything that can be written as a URI. The system automatically finds all applications capable of receiving given type intents (more specifically, URI addresses), and passes the URI to them (or rather, one of them, chosen by the user). What types of intents an application can accept and process is determined by the programmer at application build time. In addition, it can use URI content filtering to avoid "spam".

By themselves, the listed mechanisms for exchanging data and calling application functions controlled using the privilege system in Android are implemented quite clearly and clearly, but they can lead to problems if the programmer does not take seriously enough the declaration of privileges required to access his application. This can lead to information leaks or the possibility of using the functionality of the application by anyone. For example, in the early versions of Dropbox for Android, there was a problem with the correct definition of privileges, which led to the fact that any installed application could use the Dropbox client to upload any information to " cloud drive»www.securelist.com.

Stack fall protection

To protect applications built using the Android NDK, as well as system components written in the C language, Android includes an extensive set of anti-stack protection mechanisms that have been implemented by a wide variety of developers for various projects in their time. In Android 1.5, system components were switched to use the safe-iop library, which implements functions for safely performing arithmetic operations on integers (protection against integer overflow). The implementation of the dmalloc function was borrowed from OpenBSD to prevent double deallocation attacks and chunk consistency attacks, as well as the calloc function, which checks for the possibility of an integer overflow during a memory allocation operation. All low-level Android code, starting from version 1.5, is built using the GCC ProPolice compiler mechanism to protect against stack breaks at compile time.

In version 2.3, all possible string manipulation vulnerabilities identified by building sources with the '-Wformat-security', '-Werror=format-security' flags were fixed in the code, and "iron" mechanisms of protection against stack breaks were applied ( bit No eXecute (NX), available since ARMv6). Android 2.3 also uses a method to protect against a vulnerability found in November 2009 in all Linux 2.6 kernels (the ability to dereference a NULL pointer) by writing a non-zero value to the /proc/sys/vm/mmap_min_addr file. This method of protection made it possible to eliminate the vulnerability without the need to update the Linux kernel itself, which is not possible on many devices.

Starting with version 4.0, Google implemented Address space layout randomization (ASLR) technology in Android, which allows you to randomly arrange the image of the executable file, loadable libraries, heap and stack in the address space of the process. This makes exploitation of many types of attacks much more difficult, since the attacker has to guess the hop addresses in order to successfully execute the attack. In addition, starting with version 4.1, Android is built using the RELRO (Read-only relocations) mechanism, which allows you to protect system components from attacks based on overwriting sections of an ELF file loaded into memory. In the same version 4.1, the dmesg_restrict kernel feature (/proc/sys/kernel/dmesg_restrict) was first activated, which appeared in the 2.6.37 kernel and allows you to disable the ability to read the kernel system log (dmesg) by unprivileged users.

INFO

In the alternative MIUI Android firmware, no third-party application will be able to send SMS without explicit confirmation from the user.

CyanogenMod Extends the Standard Permissions Mechanism android capability cancellation of any authority after the installation of the application.

• As part of the SE Android pilot project, work is underway on a fork of Android with the SELinux security system activated.

Application repository

repository Google Apps Play (nee Android Market) has always been Android's weakest point. Despite the fact that the mechanism that required applications to specify a list of their privileges before installation worked correctly from the outset and allowed creating an ecosystem in which users themselves could warn each other about possible malicious behavior of a program published in the repository, users continually infected their smartphones by viruses.

The main problem here was that the application and its author were not subjected to any serious checks before publishing the package to the repository. In fact, all that had to be done was to write a program, create a Google Play account, pay a membership fee, and publish the application. Absolutely anyone could do all this by posting any code to the Market, which has been repeatedly demonstrated in various Android security studies.

In order to at least partially solve this problem without resorting to manual verification security apps like Apple did App Store, Google earlier this year launched the Bouncer service, which is a virtual machine that automatically launches any application published in the repository. Bouncer performs multiple launches of the software, performs many actions that simulate the user's work with the application, and analyzes the state of the system before and after launch in order to find out if there were any attempts to access confidential information, send SMS to short paid numbers, and so on.

By according to Google, Bouncer allowed to reduce the number of malware immediately after the launch of the service by 40%. However, as further research showed, it could be easily bypassed: analyze some characteristics of the system (e-mail address of the “smartphone” owner, OS version, and so on) and then create an application that, if they were detected, would not arouse suspicion, and after hitting a real smart phone to do all the dirty work.

Most likely, Google has already developed a scheme to counter Bouncer detection by generating unique virtual environments for each new application, but one way or another, viruses will continue to penetrate Google Play, and you should be careful when installing applications, be sure to read user reviews and analyze the list of application permissions before installing it.

Code review and updates

Last, but not least, what I would like to say about the Android security system is the code review and the process of the development team's response to the emergence of new vulnerabilities. Once upon a time, the OpenBSD programmers showed that this was one of the most important aspects of developing a secure OS, and Google is following suit quite clearly.

Google has a full-time Android Security Team, whose task is to monitor the quality of the code operating system, identify and correct errors found during the development of a new version of the OS, respond to error reports sent by users and security companies. In general, this team works in three directions:

• Analysis of new serious OS innovations for security. Any architectural change to Android must be approved by these guys.
• Testing of the developed code, in which the Google Information Security Engineering team and independent consultants also take part. It goes on constantly throughout the entire cycle of preparing a new release of the OS.
• Responding to the discovery of a vulnerability in an already released OS. Includes constant monitoring of possible sources of information about the found vulnerability, as well as support for a standard bug tracker.

If a vulnerability is discovered, the security team starts the following process:

1. Notifies OHA (Open Handset Alliance) companies and initiates discussion options problem solving.
2. As soon as a solution is found, corrections are made to the code.
3. A patch containing a solution to the problem is sent to OHA members.
4. The patch is submitted to the Android Open Source Project repository.
5. Manufacturers/operators start updating their devices in OTA mode or publish a patched firmware version on their websites.

Particularly important in this chain is the fact that the discussion of the problem will only take place with those OHA members who have signed a non-disclosure agreement. This ensures that the public will only become aware of a found problem after it has already been resolved by the companies, and the fix appears in the AOSP repository. If the vulnerability becomes known from public sources (for example, a forum), the security team will immediately begin to resolve the problem in the AOSP repository, so that everyone will have access to the fix as soon as possible.

Again, the weak point here remains device manufacturers and carriers, which can delay the publication of the corrected version, despite the early access to the fix.

conclusions

Like any other operating system, Android is not without vulnerabilities and various architectural assumptions that make life easier for malware writers. But to say that Android is vulnerable by definition is also not worth it. It clearly shows the influence latest trends in the development of secure operating systems. These are sandboxes for applications, and a mechanism for exchanging data between applications that is clearly controlled by the system, and the developments of the OpenBSD project - the only OS general purpose, which has always been developed with an emphasis on security.

Games, photo editors with elf faces, calorie calculators and online dictionaries in the smartphone entertain us and make life easier. But the sensational story with the Meitu app is that not all of them are safe. An expert from Positive Technologies told how to protect a smartphone from malicious applications.

Nikolai Anisenya

Security Research Specialist mobile applications Positive Technologies

Trojans? No, have not heard

In the language of IT professionals, malware software(Software) that masquerades as a harmless program is called a Trojan. Such applications force the user to install them themselves and issue the necessary privileges.

All Trojans can be divided into two types. The former use vulnerabilities in the operating system or applications installed on the smartphone. The latter force the user to allow some actions, for example, access to one-time passwords from SMS messages, the camera, the gadget's desktop or other applications.

In case of using OS vulnerabilities, notice malicious activity pretty hard. So, a program, for example, aimed at stealing money through mobile banking, will make itself felt already upon debiting funds from the account.

Protecting yourself from malware that forces you to grant access to data or allow you to perform fraudulent activities is also difficult. Such malware uses legal techniques, so the user remains to blame. Without reading the application installation conditions, he trusts and allows a free dictionary or game to read his messages, make paid calls, and sometimes take full control of the device.

Rule 1: install applications only from official markets

Most malicious applications get into smartphones from unofficial app markets or via links from sites with unlicensed content. Google Play and the App Store review apps before they are made available to users. It is much more difficult to catch an infection there. If you still decide to download something from an unknown resource, check the box "Install applications from untrusted sources" during installation.

Rule 2: Read carefully what accesses, permissions and features the installed application requires to enable

Fraudsters often embed malware into clones of popular paid apps, luring the victim with free music or games. Getting into the gadget, the virus exploits the vulnerabilities of older versions of the OS in order to gain increased control over the victim's device. Some may, for example, force the victim to enable special developer features - USB debugging. So the installation software from the computer will be able to get unhindered access to installing applications on the smartphone with any privileges.

Rule 3: Update Your Apps Regularly

Research has shown that 99% of attacks target vulnerabilities for which developers have released patches. Releasing a new release, they always officially notify about the fixed shortcomings and loopholes. Fraudsters carefully study them and direct their malware to those users who did not have time to update the old version. Therefore, timely updating of both the device OS and installed applications can reduce the risk of attacks.

Rule 4: forget about root rights

Almost all Android users can take full control over the system of their gadget. Root rights Root is the main administrator account. If a fraudster gains access to this profile, then he has a number of features that are not available in normal operation. provide the ability to change system folders and files: for example, allow you to delete standard applications(calendar, maps and various embedded services), change and delete themes, shortcuts, optimize the performance of your device, overclock the processor. There are ones that take full control of the system, but they also completely destroy the security on the device.

Do not use a rooted Android device to perform banking transactions. If malware obtains these root rights, then it will be able to integrate into all system processes: read SMS with a one-time password from the bank, delete SMS notifications about debiting funds, have access to data bank cards and even listen to conversations. In this case, all these activities will be hidden from the user.

Rule 5: Don't Give Apps Weird Permissions

If the application needs to use, for example, access to the contact list, then during installation it will definitely ask for this permission. Starting with Android 6, some permissions cannot be granted during installation - they are granted only after they are launched. So, if the application needs access to read SMS, location or other confidential information, the user can refuse it. To protect yourself, you need to be very careful about such offers.

The most popular permissions that malware requests are:

Reading SMS. Many applications, including banking, use SMS messages to deliver a one-time password. Having gained access to SMS, an attacker will be able to log in to your account and confirm their transactions.

Sending SMS and making calls. The application can imitate calls and sending SMS to paid numbers, stealing money from the phone account.

"Overlay on top of other windows" in Android OS. This resolution can be used to distort almost any information displayed on a smartphone screen. By overlaying a picture of windows, malware can trick the user into, for example, confirming remittance. Different windows can be displayed on top of the banking application so that the user taps on certain parts of the screen (this is called tapjacking) and ends up sending money to someone else's account. The software can also change the amount of the transfer by hiding a couple of zeros in it: the user will think that he is transferring 1 ruble, but in fact - 100.

Device Administrator. This permission will give the malware almost complete control over the device. He will be able not only to steal money, infiltrate any account, but also protect himself from deletion.

Regular revision of applications and the permissions issued to them will be useful. Starting with Android 6, access to permissions can be disabled. You can do this according to the scheme: Settings -> Applications -> Application Permissions / Overlay on top of other windows.

Are there no viruses in iOS?

It is much more difficult for iOS users to run into a Trojan. But even here, malware has ways to get into the device. Apple permits the installation of internal enterprise applications that bypass the App Store, provided that the user trusts the developer. Therefore, attackers disguise viruses as harmless applications, often free clones. paid programs. You should not install such, especially if you commit monetary transactions from your device.

Once the malware gets on the device, it can use vulnerabilities in iOS to disable protection mechanisms (perform the so-called jailbreak) and take full control of the device. If the user disables the protection mechanisms on their own, then it makes life much easier for scammers.

The malware can also target vulnerabilities not in iOS itself, but in applications - for example, insecure data storage in your mobile banking. As in the case of Android, timely software updates will help against such attacks.

Bottom line: things to remember

Every application should be treated as if it had unlimited access to the device. An application may look harmless, but act covertly or trick it into performing unwanted actions. It is worth trusting those developers who place their products in official markets (Google play, App Store). It is necessary to pay attention to whether there are suspicious applications such as "Root rights", "Wi-Fi accelerator", "battery saver" among the developer's list. Positive reviews and the number of downloads can also become additional criteria in favor of choosing a developer.

Ready to look you in the eye on the best day of summer - August 3, at the Afisha Picnic. The Cure, Pusha-T, Basta, Gruppa Skryptonite, Mura Masa, Eighteen - and this is just the beginning.