Over the past few years, we’ve become accustomed to logging into important websites and apps, such as online banking ones, using a password and another verification method. This could be a one-time password (OTP) sent via a text message, email or push notification, a code from an authenticator app or even a special USB device — a token. This way of logging in is called two-factor authentication (2FA), and it makes hacking much more difficult. Stealing or guessing a password alone is no longer enough to hijack an account. But what should you do if you haven’t tried to log in anywhere, but suddenly receive a one-time code or a request to enter it?

There are three reasons why this situation might occur:

A hacking attempt. Hackers have somehow learned, guessed, or stolen your password and are now trying to use it to access your account. You have received a legitimate message from the service they are trying to access.
Preparation for a hack. Hackers have either learned your password or are trying to trick you into revealing it, in which case the OTP message is a form of phishing. The message is fake, although it may look very similar to a genuine one.
Just a mistake. Sometimes online services are set up to first request a confirmation code from a text message, and then a password, or authenticate with just one code. In this case, another user could make a typo and enter your phone/email instead of theirs — and you’ll receive the code.

As you can see, there may be a malicious intent behind this message. But the good news is that at this stage, there has been no irreparable damage, and by taking the right action you can avoid any trouble.

What to do when receiving a code request

Most importantly, do not click the confirmation button if the message is in the “Yes/No” form, do not log in anywhere, and do not share any received codes with anyone.

If the code request message contains links, do not follow them.

These are the most essential rules to follow. As long as you don’t confirm your login, your account is safe. However, it’s highly likely that your account’s password is known to attackers. Therefore, the next thing to do is to change the password for this account. Go to the relevant service by entering its web address manually, not by following a link. Enter your password, get a new (that’s important!) confirmation code, and enter it. Then find the password settings and set a new strong password. If you use the same password for other accounts, you’ll need to change the password for them, too — but make sure to create a unique password for each account. We understand that it’s difficult to remember so many passwords, so we highly recommend storing them in a dedicated password manager.

This stage — changing your passwords — is not so urgent. There’s no need to do it in a rush, but also don’t postpone it for another day. For valuable accounts (like banking), attackers may try to intercept the OTP if it is sent via a text message. This is done through SIM swapping (registering a new SIM card to your number) or attacking via the operator’s service network, utilizing a flaw in the SS7 communications protocol. Therefore, it’s important to change the password before they attempt such an attack. In general, one-time codes sent in text messages are less reliable than authenticator apps and USB tokens. We recommend always using the most secure 2FA method available; a review of different two-factor authentication methods can be found here.

What to do if you’re receiving a lot of OTP requests

In an attempt to make you confirm a login, hackers may bombard you with codes. They try to log in to the account again and again, hoping either that you’ll make a mistake and click “Confirm”, or go to the service and disable 2FA out of annoyance. It’s important to keep cool and do neither. The best thing to do is go to the service’s site as described above (open the site manually, not through a link) and quickly change the password; but for this, you’ll need to receive and enter your own, legitimate OTP. Some authentication requests (for example, warnings about logging into Google services) have a separate “No, it’s not me” button — usually, this button causes automated systems on the service side to automatically block the attacker and any new 2FA requests. Another option, albeit not the most convenient one, would be to switch the phone to silent or even airplane mode for half an hour or so until the wave of codes subsides.

What to do if you accidentally confirm a stranger’s login

This is the worst-case scenario, as you have likely allowed an attacker into your account. Attackers act quickly, changing settings and passwords, so you’ll have to play catch-up and deal with the consequences of the hack. We’ve provided advice for this scenario here.

How to protect yourself?

The best method of defense in this case is to stay one step ahead of the criminals: si vis pacem, para bellum. This is where our security solution comes in handy. It tracks leaks of your accounts linked to both email addresses and phone numbers, including on the dark web. You can add the phone numbers and email addresses of all your family members, and if any account data becomes public or is discovered in leaked databases, Kaspersky Premium will alert you and give advice on what to do.

Included in the subscription, Kaspersky Password Manager will warn you about compromised passwords and help you change them, generating new uncrackable passwords for you. You can also add two-factor authentication tokens to it or easily transfer them from Google Authenticator in a few clicks. Secure storage for your personal documents will safeguard your most important documents and files, such as passport scans or personal photos, in encrypted form so that only you can access them.

Moreover, your logins, passwords, authentication codes and saved documents will be available from any of your devices — computer, smartphone or tablet — so even if you somehow lose your phone, you won’t lose your data and access, and you’ll be able to easily restore them on a new device. And to access all your data, you only need to remember one password — the main one — which is not stored anywhere except in your head and is used for banking-standard AES data encryption.

With the “zero disclosure principle”, no one can access your passwords and data — not even Kaspersky employees. The reliability and effectiveness of our security solutions have been confirmed by numerous independent tests, and our home protection solutions received the highest award — “Product of the Year 2023” — in tests by the independent European laboratory AV-Comparatives.

Kaspersky official blog – ​Read More

The labor market has long experienced a shortage of cybersecurity experts. Often, companies in need of information-security specialists can’t find any – at least, those with specialized formal education and the necessary experience. In order to understand how important it is for a company to have specialists with a formal education in this area, and how well such education meets modern needs, our colleagues conducted a study – A portrait of a modern information security professional – in which they interviewed more than a thousand employees from 29 countries in different regions of the world. Among the respondents were specialists of various levels: from beginners with two years of experience, to CIOs and SOC managers with 10. And judging by the respondents’ answers, it looks like classical education isn’t keeping up with InfoSec trends.

First and foremost, the survey showed that not all specialists have a higher education: more than half (53%) of InfoSec workers have no post-graduate education. But as to those with it, every second worker doubts that their formal education really helps them perform their job duties.

Cybersecurity is a rapidly changing industry. The threat landscape is changing so fast that even a couple of months lag can be critical – while it can take four to five years to obtain an academic degree. During this time, attackers can modernize their tactics and methods in such a way that a graduate InfoSec “specialist” would have to quickly read all the latest articles about threats and defense methods in the event of an actual attack.

InfoSec specialists with real life experience argue that educational institutions in any case don’t provide enough practical knowledge – and don’t have access to modern technologies and equipment. Thus, to work in the InfoSec field and to fight real cyberthreats, some additional education is required anyway.

All this, of course, doesn’t mean that cybersecurity professionals with higher education are less competent than their colleagues without it. Ultimately, passion and the ability to continually improve are of the utmost importance in professional development. Many respondents noted that they received more theoretical than practical knowledge in traditional educational institutions, but felt that formal education was still useful since, without a solid theoretical basis, absorption of new knowledge would progress more slowly. On the other hand, specialists who don’t have post-graduate education at all, or who came to information security from another IT industry, can also become effective specialists in protecting against cyberthreats. It really does all depend on the individual.

How to improve the labor market situation

In order for the market to attract a sufficient number of information security experts, the situation needs to be balanced on both sides. First, it makes sense for universities to consider partnering with cybersecurity companies. This would allow them to provide students with more practically applicable knowledge. And second, it’s a good idea for companies to periodically increase the expertise of their employees with the help of specialized educational courses.

Kaspersky official blog – ​Read More

An article in Science Magazine published mid-January describes a non-trivial method of snooping on smartphone users through an ambient light sensor. All smartphones and tablets have this component built-in — as do many laptops and TVs. Its primary task is to sense the amount of ambient light in the environment the device finds itself in, and to alter the brightness of the display accordingly.

But first we need to explain why a threat actor would use a tool ill-suited for capturing footage instead of the target device’s regular camera. The reason is that such “ill-suited” sensors are usually totally unprotected. Let’s imagine an attacker tricked a user into installing a malicious program on their smartphone. The malware will struggle to gain access to oft-targeted components, such as the microphone or camera. But to the light sensor? Easy as pie.

So, the researchers proved that this ambient light sensor can be used instead of a camera; for example, to get a snapshot of the user’s hand entering a PIN on a virtual keyboard. In theory, by analyzing such data, it’s possible to reconstruct the password itself. This post explains the ins and outs in plain language.

A light sensor is a rather primitive piece of technology. It’s a light-sensitive photocell for measuring the brightness of ambient light several times per second. Digital cameras use very similar (albeit smaller) light sensors, but there are many millions of them. The lens projects an image onto this photocell matrix, the brightness of each element is measured, and the result is a digital photograph. Thus, you could describe a light sensor as the most primitive digital camera there is: its resolution is exactly one pixel. How could such a thing ever capture what’s going on around the device?

The researchers used the Helmholtz reciprocity principle, formulated back in the mid-19th century. This principle is widely used in computer graphics, for example, where it greatly simplifies calculations. In 2005, the principle formed the basis of the proposed dual photography method. Let’s take an illustration from this paper to help explain:

Imagine you’re photographing objects on a table. A lamp shines on the objects, the reflected light hits the camera lens, and the result is a photograph. Nothing out of the ordinary. In the illustration above, the image on the left is precisely that — a regular photo. Next, in greatly simplified terms, the researchers began to alter the brightness of the lamp and record the changes in illumination. As a result, they collected enough information to reconstruct the image on the right — taken as if from the point of view of the lamp. There’s no camera in this position and never was, but based on the measurements, the scene was successfully reconstructed.

Most interesting of all is that this trick doesn’t even require a camera. A simple photoresistor will do… just like the one in an ambient light sensor. A photoresistor (or “single-pixel camera”) measures changes in the light reflected from objects, and this data is used to construct a photograph of them. The quality of the image will be low, and many measurements must be taken — numbering in the hundreds or thousands.

Let’s return to the study and the light sensor. The authors of the paper used a fairly large Samsung Galaxy View tablet with a 17-inch display. Various patterns of black and white rectangles were displayed on the tablet’s screen. A mannequin was positioned facing the screen in the role of a user entering something on the on-screen keyboard. The light sensor captured changes in brightness. In several hundred measurements like this, an image of the mannequin’s hand was produced. That is, the authors applied the Helmholtz reciprocity principle to get a photograph of the hand, taken as if from the point of view of the screen. The researchers effectively turned the tablet display into an extremely low-quality camera.

True, not the sharpest image. The above-left picture shows what needed to be captured: in one case, the open palm of the mannequin; in the other, how the “user” appears to tap something on the display. The images in the center are a reconstructed “photo” at 32×32 pixel resolution, in which almost nothing is visible — too much noise in the data. But with the help of machine-learning algorithms, the noise was filtered out to produce the images on the right, where we can distinguish one hand position from the other. The authors of the paper give other examples of typical gestures that people make when using a tablet touchscreen. Or rather, examples of how they managed to “photograph” them:

So can we apply this method in practice? Is it possible to monitor how the user interacts with the touchscreen of a tablet or smartphone? How they enter text on the on-screen keyboard? How they enter credit card details? How they open apps? Fortunately, it’s not that straightforward. Note the captions above the “photographs” in the illustration above. They show how slow this method works. In the best-case scenario, the researchers were able to reconstruct a “photo” of the hand in just over three minutes. The image in the previous illustration took 17 minutes to capture. Real-time surveillance at such speeds is out of the question. It’s also clear now why most of the experiments featured a mannequin’s hand: a human being simply can’t hold their hand motionless for that long.

But that doesn’t rule out the possibility of the method being improved. Let’s ponder the worst-case scenario: if each hand image can be obtained not in three minutes, but in, say, half a second; if the on-screen output is not some strange black-and-white figures, but a video or set of pictures or animation of interest to the user; and if the user does something worth spying on… — then the attack would make sense. But even then — not much sense. All the researchers’ efforts are undermined by the fact that if an attacker managed to slip malware onto the victim’s device, there are many easier ways to then trick them into entering a password or credit card number. Perhaps for the first time in covering such papers (examples: one, two, three, four), we are struggling even to imagine a real-life scenario for such an attack.

All we can do is marvel at the beauty of the proposed method. This research serves as another reminder that the seemingly familiar, inconspicuous devices we are surrounded by can harbor unusual, lesser-known functionalities. That said, for those concerned about this potential violation of privacy, the solution is simple. Such low-quality images are due to the fact that the light sensor takes measurements quite infrequently: 10–20 times per second. The output data also lacks precision. However, that’s only relevant for turning the sensor into a camera. For the main task — measuring ambient light — this rate is even too high. We can “coarsen” the data even more — transmitting it, say, five times per second instead of 20. For matching the screen brightness to the level of ambient light, this is more than enough. But spying through the sensor — already improbable — would become impossible. Perhaps for the best.

Kaspersky official blog – ​Read More

On January 30, security researchers published information about a vulnerability they discovered in the glibc (GNU C Library), which could potentially allow attackers elevate their privileges on Linux systems to root level. The library provides system calls and basic system functions – including syslog and vsyslog, which are used to write messages to the system message log. The vulnerability has received the identifier CVE-2023-6246, and a score of 8.4 on the CVSS v3.1 scale. Despite the fact that the level of this threat is not critical – it’s just high – there’s a high probability of its exploitation in large-scale attacks since glibc is the main system library that’s used by almost all Linux programs.

Which systems are affected by CVE-2023-6246?

The Qualys researchers who discovered the vulnerability tested a number of popular Linux-based system installations, and identified several vulnerable systems: Debian 12 and 13, Ubuntu 23.04 and 23.10, and Fedora Linux versions 37 through 39. However, experts add that other distributions are probably also affected by this vulnerability. CVE-2023-6246 is present in the library version 2.36 and older. The glibc developers fixed the vulnerability in version 2.39 on January 31 – a day after information about it was published.

What is the CVE-2023-6246 vulnerability and where did it come from?

The vulnerability CVE-2023-6246 is related to a dynamic memory buffer overflow and belongs to the LPE (Local Privilege Escalation) class. In simple terms, an attacker who already has user access to a system can use vulnerable function calls to escalate their privileges to the super-user level.

This vulnerability was first added to the library in version 2.37, in August 2022, in an attempt to close the less dangerous vulnerability CVE-2022-39046. Subsequently, the library developers made the same change in version 2.36.

How to stay safe?

First you need to update the glibc library to version 2.39. Since attackers must already have access to the system to exploit this vulnerability (and all LPE vulnerabilities in general), CVE-2023-6246 will most likely be exploited in complex multi-stage attacks. Therefore, we recommend using solutions that can protect Linux as well. For example, our Kaspersky Endpoint Security solution includes the Kaspersky Endpoint Security for Linux application, which combats modern threats to Linux-based systems.

Kaspersky official blog – ​Read More

Although embedded computing systems are crucial business tools for many companies, their security is often overlooked. Systems such as ATMs, payment terminals, vending machines, ticket kiosks, medical computer tomographs, and even automated gas stations handle financial and other confidential data that criminals can use to their advantage. This makes these systems attractive targets for cyberattacks, so protecting them from cyberthreats should be a priority for any company. However, despite their apparent similarity to conventional computers, embedded systems have a number of significant differences that must be considered when developing a security strategy; otherwise, companies may face a range of serious challenges.

Features of embedded systems

Usage model. Unlike a conventional computer, which is typically used by a single employee for a wide range of tasks, an embedded system can have an unlimited number of users, and usually provides a meager set of functions built into the system during its initial creation. Interaction with such systems is often carried out using specific input devices (such as a digital keypad or a touch screen with a narrowly specialized user interface) that do not permit the execution of arbitrary commands and files. Ports for connecting external peripherals to these devices are usually accessible only to technical specialists. Communication with the outside world takes place through the internet and local network; in addition, embedded systems are often used with functionally-limited storage devices such as banking, savings or discount cards. Such systems should in no way be used for reading emails or visiting websites — that way attackers cannot rely on these vectors for infection. However, the significance of network connections is increased. And this is one of the main channels used for attacks on embedded systems; after all, almost all types of embedded systems have a connection to the company’s local network — meaning that once inside this network, attackers can reach these specialized machines. As for ports, the specific physical location of such devices can help a hacker.

Physical location. To facilitate the usage model, the vast majority of devices based on embedded systems are located in public spaces. Typically, device components are protected from unauthorized access by a sturdy steel casing and interaction restrictions. However, all devices require some degree of maintenance, so even those with the most robust encasing need to be openable with a key. And this is where attackers can enter. Having gained access to the hardware part of the device, they can connect a standard mouse and keyboard, a storage device with the malware they want to use, or even an operating system that can allow them to bypass the hacked device’s own OS. In some cases, attackers even connect a single-board computer with which they can hack the system or, for example, analyze commands that make the dispenser issue banknotes to the user. The rest is pretty straightforward: the hacker just needs to introduce their tools into the embedded system and then they can make it do whatever they want — from dispensing money or conducting shadow transactions to stealing user data. Unless, of course, the embedded system is properly protected.

Long-term use and limited system resources. Embedded systems are built for specific, highly specialized tasks, so they usually have only the “necessary and sufficient” level of processing power. Since devices using embedded computer systems often have a long service life, it’s not uncommon to encounter functioning ATMs or cash registers with weak, outdated hardware. From a security standpoint, this can pose a significant problem: such a configuration is clearly not compatible with many of the latest security solutions.

Outdated, vulnerable software. The long life of expensive devices based on embedded systems generates another side effect: outdated software. Often, it’s simply impossible to use a newer OS on a modest system configuration, and current specialized application software may not work on the old OS. And sometimes, the new programs necessary for working with the unique peripherals of the device (cash dispensers, card readers, medical monitoring systems, tomographs, and so on) may simply not exist. The consequence of this is that such systems for which security updates are no longer released are actively targeted by hackers. But finding a solution that will work on an old OS, such as Windows XP, and at the same time protect against current threats is extremely challenging; the vast majority of security product developers have discontinued their support for legacy operating systems.

Weak internet connection. Some devices, such as ATMs, ticket terminals and automatic fuel dispensers, may be located in remote places where there’s no wired internet. Also, wireless network access in such places is usually based on cellular communication, so it may work slowly and with interruptions. Application software is designed for such a scenario; for example, transactions can be serviced asynchronously by a bank — they are performed when the connection allows it. However, many modern security solutions are much more reliant on a stable communication channel. In an effort to reduce deployment time and the size of installed software, they rely heavily upon cloud infrastructure, which means that if the connection is poor their performance may be impacted.

Regulatory requirements. Since the vast majority of embedded systems handle valuable financial and personal data, their operation is regulated by relevant legislation. Though regulatory bodies mandate the presence of reliable protection, its implementation is largely left up to companies; however, the task is to minimize the risks of an incident occurring while ensuring that detailed logs are recorded for investigation if an incident does occur. Moreover, the list of recommendations may include certain technologies, such as system integrity control, which are simply unavailable in typical endpoint security solutions, or are provided only in server versions.

Seeking a compromise

Summing up, these systems are multi-user, single-task, low-power, and susceptible to specific attack vectors (network connection and/or direct device access). At the same time, they handle extremely valuable data (not necessarily financial data; it could be personal medical information in the case of medical equipment), for which not only confidentiality is important, but also integrity. There may be a number of difficulties regarding the data’s protection, as a typical endpoint security solution will face problems working on weak hardware, and generally won’t work on outdated operating systems, which are still quite common. If such a solution does run, there may be performance issues, and sometimes compatibility issues too (after all, the solution is intended for regular computers).

One of the approaches that many manufacturers of security solutions for such systems have taken is to completely prohibit anything that’s not needed for the device’s main task: application control technology in default-deny mode simply blocks any programs not initially included in the so-called allowlist. In theory, this means you don’t need any threat detection mechanisms; a virus simply won’t run, nor will any other unnecessary program, and such technology requires very few resources — allowing the solution to work even on very weak systems.

However, this approach may be powerless against, for example, code injection into a legal, already running process in memory — which can be achieved through exploiting those same vulnerabilities in outdated software. Techniques developed by hackers to exploit elements of the system itself for malicious purposes often mean that the use of actual malware is reduced to a minimum. Yes, there are also fewer options available to hackers in a weak system, but… a business dependent on embedded systems, such as a bank or retail network, is unlikely to use only devices belonging to just one generation. This gives hackers some room to maneuver. What to do? Should you install different solutions — products based on the default-deny principle on weak systems, and a regular antivirus for workstations on more powerful machines, hoping to avoid compatibility issues? Or try to find a truly universal solution?

Special protection for special devices

If you look at the current security solutions for embedded systems on the market, most vendors offer two options:

An “economical” resource-efficient solution that can work on outdated systems but offers simple single-layer protection based on application control technology and default-deny mode. This option usually lacks the means to resist the full range of typical attacks on embedded systems, and is often managed separately from other products in the vendor’s ecosystem, creating additional challenges.
A typical endpoint security solution. For newer systems, most manufacturers suggest installing the same solution that protects regular workstations. Undoubtedly, such solutions have an up-to-date stack of security technologies and can be integrated into the vendor’s ecosystem. However, they usually lack certain technologies specifically required for protecting embedded systems. Also, such solutions only work on the latest and most powerful devices, leaving behind still functional but outdated ones.

Even if both options are used simultaneously, the full range of problems cannot be addressed. Moreover, inconsistent management approaches can make the work of IT and security admins much more complicated (especially if solutions from different manufacturers are used).

Based on all this, let’s try to imagine the ideal security solution suitable for a wide range of embedded systems and their use scenarios:

The solution should provide the maximum possible level of protection. In today’s world, this means having a stack of various technologies to protect against the range of attack vectors and techniques typically used on embedded systems of all types.
The solution should provide maximum protection to systems with different capabilities — both old, low-spec ones, and the newer ones with plenty of computing power and memory. However, since it’s simply impossible to physically run every technology simultaneously on weak hardware, scalability is required. In other words, the solution should allow separate management of protection layers so you can disable unnecessary tools and activate those which provide maximum protection for a specific hardware and use scenario.
The solution should support the most popular operating systems used to create embedded systems; that is — at least Windows and Linux.
The solution should support outdated OS versions used on embedded systems that are still in operation.
The solution should meet regulatory requirements, have recommended technologies in its security stack, and be able to perform detailed event logging in a centralized security event monitoring system (SIEM).
The solution should be thoroughly tested for compatibility — at least with typical configurations of different types of embedded systems. Ideally, it should be supplied as part of a software/hardware system all components of which have been tested for compatibility by the manufacturer.
The solution should have centralized management — ideally unified with other products in the vendor’s ecosystem to create a comprehensive security system providing monitoring and protection of all levels of the company’s IT infrastructure through a single console.

Kaspersky Embedded Systems Security

Many years ago, before fully understanding what a specialized solution for protecting embedded systems should look like, Kaspersky also attempted to use applications from the Kaspersky Security for Business product line for this task. However, it soon became clear that using a conventional application for the entire range of embedded systems was simply impossible. Therefore, the decision was made to develop a separate solution that could meet the ideal requirements to the maximum extent. The result was the emergence of Kaspersky Embedded Systems Security — initially supporting Windows and later Linux as well.

Our solution offers an exceptionally rare combination in the global market: a multi-layered technological stack for different platforms, very modest system resource requirements, and support for outdated OS versions (down to Windows XP SP2). At the same time, it’s part of Kaspersky’s rich security ecosystem. All of this means that Kaspersky Embedded Systems Security comes very close to the ideal solution that we describe above. You can familiarize yourself with the main features of the product on its webpage; for technical details, you can visit the Kaspersky support site sections dedicated to the product’s applications for Windows and/or Linux.

Kaspersky official blog – ​Read More