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

Episode 330 of the Transatlantic Cable podcast kicks things off with talk around the potential for A.I poisoning, which could allow malicious actors to turn AI chatbots into ‘sleeper agents’. From there the team talk about eBay and a truly bizarre story involving spiders, cockroaches and death threats, as well as China’s crackdown on casino’s, which has led to an underground boom in crypto-casinos.

If you like what you heard, please consider subscribing.

AI poisoning could turn open models into destructive “sleeper agents”
Defending reality: Truth in an age of synthetic media
eBay pays $3m fine in blogger harassment case
China’s gambling crackdown spawned wave of illegal online casinos

Kaspersky official blog – ​Read More

Facebook recently launched a new feature called link history. This post explains what link history is, why Facebook rolled it out, why you should turn it off, and most importantly — how.

What is Facebook link history?

Facebook mobile apps come with a built-in browser. Whenever you follow an external link posted on Facebook, it opens in this very browser. Recently the social network decided to start collecting the history of all the links you click, and to use this data to show you targeted ads.

Why does Facebook need it? Because it’s not just the largest social network in the world, but also one of the most powerful global advertising platforms — second only to Google in terms of scale and capabilities. Previously, to collect data on user interests and show targeted ads based on it, Facebook used third-party cookies. However, support for third-party cookies is being phased out in the world’s most popular browser — Google Chrome.

Google has devised its own mechanism for tracking users and targeting ads — known as Google Ad Topics. To collect data, this technology makes active use of the Google Chrome browser and the Android operating system. Not so long ago, we explained how to opt out of this Google tracking.

Now Facebook has decided to track users through the browser built into its various mobile app versions. That’s how the link-history feature was born. But it offers no additional benefits to regular users — despite Facebook trumpeting the convenience of being able to find any link you ever opened at any moment. But if you don’t like the idea of Facebook tracking your every move, it’s best to turn off the feature; thankfully, it’s easy to do.

How to turn off Facebook link history

First, let’s clarify that link history is only available in Facebook mobile apps. The feature is missing when you use the web version of the social network. It’s also neither available in Facebook Lite (if only because this app has no built-in browser), nor (at least for now) in the Messenger app.

The first time a user opens an external link posted on the social network after Facebook introduced link history, they’re asked for their consent to use the feature.

As you’d probably expect, link history is enabled by default. So most users likely give consent without too much thought — just to get Facebook off their backs and to show the page they want.

If you’ve already opted in to link history and now want to turn it off, there are two easy ways to do so.

The first way to turn off link history

In the Facebook app, open Menu by tapping the hamburger icon (the three lines in the upper-right corner on Android), or the Profile icon in the lower-right corner on iOS.
Go to Settings & privacy — the easiest way is by tapping the gear icon.
Scroll down to Browser and tap it.
In the window that opens, toggle Allow link history
Also, while you’re at it, tap the Clear button next to Link history.

The second way to turn off link history

In the app, tap any link posted on Facebook. This will open the app’s built-in browser.
In it, tap the ellipsis icon (upper-right corner on Android, lower-right on iOS).
Select Go to Settings.
In the window that opens, toggle Allow link history off and tap the Clear button next to Link history.

All done. Facebook will no longer collect your link history. While you’re at it, don’t forget to stop Google tracking you by disabling Google Ad Topics. To avoid online tracking in general, use the Private Browsing feature in Kaspersky applications.

Kaspersky official blog – ​Read More