In ApplicationsDetailsActivity of AndroidManifest.xml, there is a possible DoS due to a tapjacking/overlay attack. This could lead to local denial of service with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12Android ID: A-183410508

_Published January 3, 2022_

The Android Automotive OS (AAOS) Update Bulletin contains details of security vulnerabilities affecting the Android Automotive OS platform. The full AAOS update comprises the security patch level of 2023-01-05 or later from the January 2023 Android Security Bulletin in addition to all issues in this bulletin.

We encourage all customers to accept these updates to their devices.

The most severe of these issues is a high security vulnerability in the Platform Apps component that could lead to local escalation of privilege with no additional execution privileges needed. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

**Announcements**

*   In addition to the security vulnerabilities described in the January 2023 Android Security Bulletin, the January 2023 Android Automotive OS Update Bulletin also contains patches specifically for AAOS vulnerabilities as described below.

**2023-01-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2023-01-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as Google Play system updates.

**Media Framework**

The vulnerability in this section could lead to local information disclosure with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20353

A-221041256

ID

High

10, 11

**Platform Apps**

The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2021-39738

A-216190509

EoP

High

10, 11, 12, 12L

CVE-2022-20425

A-255830464

DoS

High

10, 11

**Additional vulnerability details**

The section below provides details for security vulnerabilities that are being provided for disclosure purposes. **These issues are not required for SPL compliance.**

**Platform Apps**

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20213

A-183410508

DoS

Moderate

10, 11, 12

CVE-2022-20215

A-183794206

DoS

Moderate

10, 11, 12

CVE-2022-20214

A-183411210

EoP

Low

10, 11, 12

**System UI**

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20458

A-205567776

EoP

Moderate

12L

**Kernel Components**

    

CVE

References

Type

Severity

Subcomponent

CVE-2022-28389

A-228694270  
Upstream kernel

EoP

Moderate

USB CAN bus driver

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

To learn how to check a device's security patch level, read the instructions on the Google device update schedule.

*   Security patch levels of 2023-01-01 or later address all issues associated with the 2023-01-01 security patch level.

Device manufacturers that include these updates should set the patch string level to:

*   \[ro.build.version.security\_patch\]:\[2023-01-01\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2023-01-01 security patch level. Please see this article for more details on how to install security updates.

**2\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**3\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

U-

UNISOC reference number

**4\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**5\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**

Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

**6\. Why does this bulletin have two security patch levels?**

This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.

*   Devices that use the 2023-01-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins.

Partners are encouraged to bundle the fixes for all issues they are addressing in a single update.

**Versions**

  

Version

Date

Notes

1.0

January 3, 2022

Bulletin Published

CVE-2022-20213: Android Automotive OS Update Bulletin—January 2023  |  Android Open Source Project

Your smartphone or wearable could help you out in a truly dangerous situation. Here are some options to consider.

The Best Personal Safety Devices, Apps, and Alarms (2023)

Manufacturer complacency ‘translates into an unacceptable risk for consumers’, warns security expert

Manufacturer complacency ‘translates into an unacceptable risk for consumers’, warns security expert

IoT vendors are making slow progress in making it easy for security researchers to report security bugs, with only 27.1% of suppliers offering a vulnerability disclosure policy.

The figure, based on the latest annual report from the IoT Security Foundation (IoTSF), compares to the 9.7% of IoT (Internet of Things) vendors that were reported to have a disclosure policy in the 2018 edition of the same study.

BACKGROUND IoT Security Foundation launches vulnerability disclosure platform for smart device vendors

Vulnerability management ought to be a cornerstone of connected product security, widely recommended in 30 cybersecurity guidance initiatives including the IoTSF’s IoT Security Assurance Framework.

Straightforward reporting of security issues is essential for security lifecycle maintenance, and vendors risk falling foul of newly enacted UK regulations if they ignore best practice mandates.

The UK’s Product Security and Telecoms Infrastructure – which became law in early December 2022 – requires that IoT manufacturers, importers, and distributors offer a vulnerability disclosure policy, with suppliers who breach this risking potential sanctions including penalties of up to £20,000 per day in the most severe cases.

Catch up on the latest vulnerability disclosure policy news

The IoTSF’s latest study was based on a review of practice of 332 companies who sell consumer-focused IoT products. The review, carried out by mobile and IoT security consultancy Copper Horse, covered security practices tied to a range of products ranging from tablets and routers to smart home lighting controls and smart speakers.

Vendors from Asia tended to be better at establishing vulnerability disclosure programs, with European suppliers trailing significantly behind (34.7% versus 14.5%, respectively).

Laurie Mercer, senior manager of security engineering at HackerOne, said: “Knowing about security vulnerabilities within products and services through a Vulnerability Disclosure Policy (VDP) is an important way to identify and rectify them as part of the product security lifecycle.

“It’s a best practice that customers are increasingly looking for their supplier to adopt, but this research suggests it is not yet common practice.”

**Increased regulation**

Lawmakers across the world are looking to introduce regulations in order to push IoT vendors into making their products more secure. For example in the US lawmakers have established the IoT Cybersecurity Improvement Act (2020).

The draft European Cyber Resilience Act covers similar ground.

David Rogers, CEO of Copper Horse, told The Daily Swig: “The trend is towards mandating it – which makes you wonder again, why aren’t companies realising this? The writing is on the wall!”

Rogers added: “Even with the threat of incoming legislation, there is complacency in manufacturers that translates into an unacceptable risk for consumers when it comes to the security of IoT devices.”

During the study, researchers identified increases in the use of the ‘/security’ contact page, the use of machine-readable ‘secuity.txt’ files and a small decline in PGP key usage for secure submissions.

Other trends uncovered were an increase in the number of vendors that updated their policies and a rise in the number of companies using a third-party ‘proxy service’ to host and maintain their policies.

**Best practice**

It’s not all doom and gloom, however, as the report did highlight examples of good practice by some vendors.

Rogers explained: “Some companies and industries are starting to act in a much better way – there are some examples in the car industry such as Volkswagen Group where they have completely transformed their approach, in a positive way.

“I think these companies can set a good example to their peers in showing that you can work with the security research community without all the brinksmanship.”

Vendors would do well to have a safe harbor policy, a legal framework that allows ethical hackers to look for flaws in systems with risking legal threats or potential prosecution. LG, for example, operates a safe harbor policy for its IoT products.

Looking more broadly, the IoTSF report commends 34 vendors that “meet or exceed what will be required by legislation” based on a review of their policies by security researchers from Copper Horse. Firms listed include Bosch, BT, Canon, Huawei, LG, Logitech, Microsoft, Peloton, Samsung, and Wink.

YOU MAY ALSO LIKE WAGO fixes config export flaw threatening data leak from industrial devices

IoT vendors faulted for slow progress in setting up vulnerability disclosure programs

Devices running Android 12 and below are at risk of attackers downloading apps that direct users to a malicious domain.

The Galaxy App Store, the official mobile app store available on Samsung devices, has two vulnerabilities, which, if exploited, could allow threat actors to install a malicious application without the user ever knowing it's taken place.

The issue only affects devices with Android 12 and lower, according to an analysis from NCC Group.

The first vulnerability, tracked as CVE-2023-21433, lets attackers install applications from the Galaxy App Store. The second, tracked as CVE-2023-21434, could let attackers launch a Web domain they control and execute JavaScript, the NCC Group report on the bugs explained.

"Samsung has released an updated version of the Galaxy App Store (version 4.5.49.8)," NCC Group's Ken Gannon said. "Users should open the Galaxy App Store on their phone, and, if prompted, download and install the latest version."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Pair of Galaxy App Store Bugs Offer Cyberattackers Mobile Device Access

Two security flaws have been disclosed in Samsung's Galaxy Store app for Android that could be exploited by a local attacker to stealthily install arbitrary apps or direct prospective victims to fraudulent landing pages on the web.
The issues, tracked as CVE-2023-21433 and CVE-2023-21434, were discovered by NCC Group and notified to the South Korean chaebol in November and December 2022. Samsung

Mobile Hacking / App Security

Two security flaws have been disclosed in Samsung's Galaxy Store app for Android that could be exploited by a local attacker to stealthily install arbitrary apps or direct prospective victims to fraudulent landing pages on the web.

The issues, tracked as **CVE-2023-21433 and CVE-2023-21434**, were discovered by NCC Group and notified to the South Korean chaebol in November and December 2022. Samsung classified the bugs as moderate risk and released fixes in version 4.5.49.8 shipped earlier this month.

Samsung Galaxy Store, previously known as Samsung Apps and Galaxy Apps, is a dedicated app store used for Android devices manufactured by Samsung. It was launched in September 2009.

The first of the two vulnerabilities is CVE-2023-21433, which could enable an already installed rogue Android app on a Samsung device to install any application available on the Galaxy Store.

Samsung described it as a case of improper access control that it said has been patched with proper permissions to prevent unauthorized access.

It's worth noting here that the shortcoming only impacts Samsung devices that are running Android 12 and before, and does not affect those that are on the latest version (Android 13).

The second vulnerability, CVE-2023-21434, relates to an instance of improper input validation occurring when limiting the list of domains that could be launched as a WebView from within the app, effectively enabling a threat actor to bypass the filter and browse to a domain under their control.

"Either tapping a malicious hyperlink in Google Chrome or a pre-installed rogue application on a Samsung device can bypass Samsung's URL filter and launch a webview to an attacker controlled domain," NCC Group researcher Ken Gannon said.

The update comes as Samsung rolled out security updates for the month of January 2023 to remediate several flaws, some of which could be exploited to modify carrier network parameters, control BLE advertising without permission, and achieve arbitrary code execution.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Samsung Galaxy Store App Found Vulnerable to Sneaky App Installs and Fraud

In 2022, privacy was upended for millions of people. Here are the biggest stories from last year. 



(Read more...)




The post What happened in privacy in 2022 appeared first on Malwarebytes Labs.

Annual reviews of any year’s developments in privacy rarely lend themselves to pithy wrap-ups, but 2022 was different, providing the clearest example yet for so many people—American women in particular—that their privacy was not theirs to determine, and that the often-repeated refrain that privacy doesn’t matter for those who have “nothing to hide” only holds sway until the world around those words decides: “Now you do_._”

The US Supreme Court’s decision to overturn _Roe v. Wade_ and the associated Constitutional right to choose to have an abortion redefined personal privacy, as individual states can now treat previously benign health data as possible evidence in a criminal investigation. Where perhaps millions of women previously had “nothing to hide,” now, they do.

The Supreme Court’s decision was also an event that has few modern equivalents, changing the behaviors of three, core parts of society—government, corporate, and public.

In the wake of a leaked draft of the decision, Federal legislators introduced a new, targeted data privacy bill to protect reproductive health data. Immediately following the decision, countless individuals dropped their current period-tracking apps in search for another app that would promise to better protect their data. And months after the decision, companies are still announcing changes to what types of data they will no longer store.

In looking back at 2022, it isn’t that nothing else happened in data privacy—it’s that nothing else like this has happened for a long time.

Here’s a look at what happened in privacy in 2022.

****Roe v. Wade overturned****

The privacy fallout from the US Supreme Court’s decision in _Dobbs v. Jackson Women’s Health Organization_ is both succinct and enormous: It changed what people want to keep private. 

By allowing a state-by-state approach to the legality of obtaining and providing abortion services, the US Supreme Court’s decision introduced a new uncertainty about what types of online activity—be it Google searches, Facebook posts, TikTok videos, or location histories revealing trips to an abortion clinic—could now be considered as potential evidence of a crime.

Would law enforcement, for example, be able to pull Google search requests on someone they suspected of seeking an abortion? Would text messages between friends be brought before an investigator? What about Instagram stories that included offers to pay for the travel and lodging of complete strangers seeking abortion from other states? And what about period-tracking app data? What if cops could see in a person’s data that, for a week or two, they were pregnant, and then soon after, they were not? 

In the absence of immediate best practices, individuals made their own choices. Period-tracking app users scrambled to find the most secure app online, and one period-tracking app maker promised to encrypt user data so that, even if law enforcement made a request for their data, the data would be unintelligible. (Those promises, one investigation found, were shaky.)

But it wasn’t just period-tracking apps that reconsidered data collection and storage policies.

In July, Google announced that it would automatically delete location histories that revealed physical trips to any sensitive locations, which Google defined as “medical facilities like counseling centers, domestic violence shelters, abortion clinics, fertility centers, addiction treatment facilities, weight loss clinics, \[and\] cosmetic surgery clinics.” Samsung, too, recently announced that it would delete “Women’s health data” collected through Samsung Health.

To address this corporate, piecemeal approach to user privacy, Congressmembers introduced the My Body, My Data Act, which would place new, national restrictions on how companies handle reproductive health data.

****Web wins (and one wayward rollout)****

When the developers of the privacy-forward browser Brave released their own search engine last year, they touted that, unlike other search engines, “Brave Search” would pull from an entirely separate index of the Internet, only relying on Google’s index when it could not fill in the gaps for user searches. Upon Brave Search’s launch, this “independence score,” as the company put it, was 87 percent.

One year later, that score has reportedly increased to 92 percent for all Brave Search users, and Brave Search itself has exited out of beta. But perhaps the biggest privacy draw of all for the tool is simple: It doesn’t track users or their searches.

Privacy-minded users has another choice in web browsers last year, as well, as Mozilla claimed that a new feature in Firefox made it the “most private and secure major browser available across Windows, Mac, and Linux.”

The feature, called Total Cookie Protection, promises to create “cookie jars” for every website that users visit. This will reportedly put browsing activity into separate silos so that user activity cannot be stitched together across websites, which is often done to help build in-depth profiles of who to target with ads.

But why spend so much time on cookie restrictions when, according to Google’s own words several years ago, it, too, would retire third-party tracking in its browser, Chrome?

Probably because that major rollout was delayed yet again—this time to 2024.

****A question of corporate commitment to privacy****

If you can believe it, there was a time last year when the biggest thing happening to Twitter had nothing to do with its new owner, Elon Musk.

In August, the company confirmed a data breach that affected 5.4 million users, their email addresses and phone numbers now linked to their accounts in a data dump that could be found for sale on the dark web.

In May, Twitter was also hit with a $150 million fine from the US Federal Trade Commission for violating an earlier consent order that prohibited the company from “misleading consumers about the extent to which it protects the security, privacy, and confidentiality of nonpublic consumer information, including the measures it takes to prevent unauthorized access to nonpublic information and honor the privacy choices made by consumers.”

But with so broad a description, what, exactly, did Twitter do?

It used phone numbers that were specifically requested for two-factor authentication—a security measure—for targeted advertising.

(At least the company did put its services on Tor last year, a great step for familiarizing users with a more private online experience.)

_To learn more about privacy and Tor’s security benefits to the Internet, listen to our Lock and Code podcast interview with Alec Muffet here._

But privacy blunders—and intentional evasions—have become a guarantee in Silicon Valley, and so Twitter shouldn’t receive all the spotlight.

Facebook, possibly angered by one browser’s decision to remove tracking parameters that Facebook inserted into URLs to help track users across pages, decided to encrypt their URLs so that the browser in question could no longer determine which part of the URL would need to be removed. The company is also facing a lawsuit alleging that it has built a “secret workaround” to safeguards built into the iPhone to prevent the social media giant from tracking users.         

Finally, Google settled multi-state charges that the company had allegedly misled users as to how their locations were tracked across various services, agreeing to pay a whopping $391.5 million. A separate but similar lawsuit is still active against the company.

****Legislation and legal violation****

Compared to earlier years, the legislative battle for data privacy cooled off in 2022, but that doesn’t mean it was necessarily less spirited.

In June, a draft of the US Supreme Court’s opinion in _Dobbs v. Jackson Women’s Health Organization_ was leaked, suggesting that the Court was positioned to soon overturn both _Roe v. Wade_ and _Planned Parenthood v. Casey_, previous decisions that had guaranteed a Constitutional right to choose to have an abortion. 

Before the Supreme Court could issue its final decision, legislators in Washington DC moved fast, introducing the My Body, My Data Act in both the House of Representatives and the Senate. The bill sought to place new restrictions on how companies use “personal reproductive or sexual health information,” allowing for the collection, use, retainment, and disclosure of such data only if a company was delivering a service requested by a user, or if the user gave express consent. The definition of “personal reproductive or sexual health information” in the bill is broad, including any info that could reveal someone’s attempts to “research or obtain” reproductive health service, along with any reproductive or sexual health “conditions,” including pregnancy or menstruation.

The bill has not significantly moved forward since its introduction.

Separately, last year saw the introduction of the American Data and Privacy Protection Act—the latest attempt from Congressmembers to pass a Federal, comprehensive data privacy law for the United States. Like many attempts before, the American Data and Privacy Protection Act would extend the rights to access, correct, and request deletion of the personal data that companies have already collected on them—similar to the rights granted to those living in the European Union through the General Data Protection Regulation (GDPR).

With a new Congress elected, it is unclear whether the bill will progress.

Aside from legislation that has only been introduced, one full-blown law scored its first-ever enforcement action. In California, the state’s attorney general announced a settlement with the makeup company Sephora over allegations that it violated the California Consumer Privacy Act, the state’s privacy law that was first passed in 2018.

According to the Office of the Attorney General, Sephora allegedly “failed to disclose to consumers that it was selling their personal information, … failed to process user requests to opt out of sale via user-enabled global privacy controls in violation of the CCPA, and … it did not cure these violations within the 30-day period currently allowed by the CCPA.”

Per the settlement, Sephora agreed to pay $1.2 million.

****Pushing back against stalkerware****

Rounding out a turbulent year, there was some good news in the continued fight against stalkerware.

Through a months-long investigation, the technology publication TechCrunch revealed that a network of stalkerware-type apps all shared the same security vulnerability that could allow “near-unfettered remote access” to the data of hundreds of thousands of devices that are already infected with said apps. TechCrunch worked with the Carnegie Mellon University Software Engineering Institute to both report the vulnerability and contact any party that could responsibly address the vulnerability. The investigation provided likely the strongest, global “map” of who is providing cover for these types of apps, and how they seem to skirt any consequences.

But there’s more.

Following questions that TechCrunch sent to a company called 1Byte, which operates the server infrastructure behind several of the apps under investigation, two of the apps “appeared to cease working or shut down.” 

Today, TechCrunch offers a tool that allows people to see if their devices are infected with the apps that the publication previously investigated.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

What happened in privacy in 2022

By Vitor Ventura

This post is the result of research presented at Recon Montreal 2022. Two slide decks are provided along with this research . One is the presentation showing the whole process and how to do it on Google Play Protect services. The other one is a workshop on how

_By_ _Vitor Ventura_  

This post is the result of research presented at Recon Montreal 2022. Two slide decks are provided along with this research . One is the presentation showing the whole process and how to do it on Google Play Protect services. The other one is a workshop on how to do it on an emulator targeting MtpService.

**Motivation**

Performing reverse engineering on Android applications and/or malware is often about doing static analysis that is complemented by dynamic analysis. This is an approach that works perfectly with applications that run at the user level and have a user interface. However, the Android security model allows for the existence of system applications, which can be operating system applications, operator applications or vendor applications. This does not mean that the applications require special permissions. They may be regular applications or service provider applications that are pre-installed either by a vendor or by the telecom service provider.

One of the features associated with these applications is that they are uninstalable by the user - The best the user can do is uninstall the latest updates and suspend or deactivate the applications, but never uninstall them.

There are also system applications that are part of the Android framework which, are closed source, thus require reverse engineering to be analyzed.

A popular tool to perform dynamic analysis is the Frida Framework. To use it a researcher needs to inject the Frida library into the target application’s address space. This can be done either by running the Frida daemon with root level access on the device or by patching the target application and making it load the shared library version of Frida. If the target application is headless, i.e. without a user interface, the instrumentation can only be done by forcing the load of the shared library and patching the target application code.  

Doing such analysis should be easy by using an OEM version of the Android operating system; however, these images may not contain the target of our research which created the need to  enable the instrumentation of system applications on Android stock images.

This, however, presented a bigger challenge than originally expected due to the protection mechanisms in place in the Android Operating system. Maddie Stone’s presentation at BlackHat 2019 describes both the limitations and vulnerabilities found on some system applications.

**Obstacles**

There are several limitations imposed by the Android security architecture, but also limitations imposed by the very nature of the availability of the target applications. This section will enumerate the limitations and solutions to those limitations.

**Operating system limitations**

It would be easy to obtain root level access on the operating system if one was to reflash the device with an open operating system like GrapheneOS however this presents two challenges:

1) Applications that are installed by vendors would not be present. Even though it is possible to install them, they may have checks regarding the operating system version they are running on. Eventually a static analysis along with patching could bypass such checks. But at this point the analysis environment would be tainted which could lead to biased results. Additionally there is also the risk of missing some checks.

2) Some vendors add protections to the kernel which won’t be present on this different operating system which tend to be more generic. As an example, Samsung ships most of their kernels with the SELinux permissions set to restricted without the possibility of change from user level.

**Headless applications**

System applications are often headless, meaning that they don’t have a launch activity or a user interface. Without it, tools like Frida or the debugger provided by the Android studio, are not able to start the application and debug it. Effectively the researcher doesn’t have the means to start the application or even to know, in a deterministic way, when the application will be executed.

One option could be the patching of the manifest and adding the launch activity. This poses its own problems, like deciding which existent activity would handle the request, and even checking if the code would be able to handle it. This leads to increased tampering with the application’s way of working, eventually creating unpredictable problems.

**Enabling dynamic analysis on the application**

On Android when doing dynamic analysis on a regular application the analyst can either activate the debug option on the application manifest or use an instrumentation toolkit like Frida.  To activate the debugging the researcher needs to change the debuggable attribute (android:debuggable="true") in the Application section of the application manifest to true, and repackage the application.

To use Frida, assuming there is no root level or the target application is headless, the analyst would need to patch the application, make it load the Frida Gadget and give it the Internet permission. These changes, like the previous, also need a  repackaging of the application.

Android requires that all application packages are digitally signed. In regular applications and in an open environment, the certificate that signs the application has little importance and a researcher can simply use a freshly generated self-signed certificate . However this is not the case if the target application is a system application. The sections ahead explain why.

**Android security architecture**

This section will describe the obstacles that a researcher must overcome to reach the point where it is possible to perform the dynamic analysis.

**Digital certificate collision**

As described above, in order to install an application its package needs to be digitally signed, which shouldn’t be a problem. However, there are a few situations where the certificate that signs the package actually matters. One of these cases, and for good security reasons, is when a user tries to upgrade an application. Imagine the following scenario;

An attacker is able to trick the victim into downloading and installing a fake Instagram application, posing it (to the system) as an upgrade to the original application. If there weren’t checks on the package signatures the malicious application would get access to all the data and configuration from the legitimate application. To avoid this, Android checks if the two applications are signed by the same certificate. If they are not, it won’t allow the installation of the fake upgrade. There are other ways to perform such an attack, but that is beyond the scope of this research.

This means that when the changes needed for dynamic analysis are made and the application is repacked, the patched application will not be able to be installed because the signatures will not match.

**Replace the original application**

Since the patched application cannot be installed on top of the original application, the obvious solution would be to simply uninstall the original one and replace it with the patched one. However this presents another barrier in this specific use case. As it was explained in the first section, these applications cannot be uninstalled. At best they can be deactivated but not uninstalled, making this a huge limitation to overcome in order to dynamically analyze these applications.

**Shared UIDs**

The fact that it's not possible to upgrade applications with different digital signatures is not the only limitation imposed. On the Android operating system, applications may share user IDs (UIDs). This is particularly useful if a developer wants to share information between applications using simple mechanisms provided by Linux without having to use mechanisms provided by the framework. However the security architecture imposes, and rightfully so, that applications that share the user ID must all be signed by the same certificate. Unfortunately, there are several system applications that share the same user ID, so it is likely that a researcher will bump into this limitation throughout their research.

**Solution**

The method to be able to dynamically analyze system applications on Android requires several actions.

**Step-by-step  
**

As it was shown in the previous sections there are several obstacles that need to be overcome in order to dynamically analyze system applications on the Android platform.  

Not necessarily in this order, but first the original target application needs to be uninstalled and removed, then identify if there are shared user ID applications. If these applications exist they need to be either uninstalled or re-signed with the same certificate used to sign the patched version of the target application. The image below illustrates the necessary steps.

Since system applications are often headless for the sake of this document, instrumenting target system application is the best way to perform non-interactive dynamic analysis.

This means that the application needs to be patched, and the instructions for it to load Frida library (gadget) into its address space must be added.

Before jumping into the details of the method it's important to explain the target and the environment. This research was conducted on the standard Android emulator using the Pixel 4 XL skin, an x86 image with API 30. For demonstration purposes the selected target application was the MtpService which is responsible for handling the MediaTransferProtocol setup when a new USB device is connected to the device. This is an open sourced application which was perfect for testing as the reversed code and behavior could always be compared  with the original code.

**Patching and re-signing target application  
**

The first step to patch the target is to unpack it using apktool which can be found here along with the instructions to pack and unpack applications.

The place to actually perform the patching will be highly dependent on the target application, there is not “_one spot fits all_”. As a rule of thumb the library should be  loaded as early as possible in the target application. A good way to do that is to load the library inside the method that handles the “BOOT\_COMPLETED” action as this will be the first one to be executed upon device reboot.  

The manifest will have the class that handles that action named on the receiver section. In the target application the class is called “com.android.mtp.MtpReceiver”. In this class look for the “onReceive()” method as that will be the method that will be executed once the action is broadcasted.

Using the apktool one can decompile the classes.dex and edit the smali code to load the library. The smali code should look like the image below.

Line 151 declares a variable string object referred to as v0 and stores the word “gadget” inside of it. Line 153 invokes the static method “loadLibrary()” which resides inside the System package. With a single String object as argument, the v0 object was previously declared. These two instructions are enough to load a static library into the application address space. The image below illustrates how the code looks like in Java.

Now before repacking the whole application the Frida library needs to be added into the package. In the root of the package (created by apktool after extraction) create a directory called “lib/” inside it and create a directory with the architecture of the library, in this case it's “x86” since this is the emulator. Inside this directory place the library file.

Now, because of the Android installer there are a few tweaks that need to be done. First the library file must start with the prefix “lib” and end with the extension “.so”. So even though the instructions make the system load a library called “gadget”, the file name must be “libgadget.so”. Frida gadget needs a configuration file, whose details will be addressed in the next section. This file also needs to be inside the package so that it is made available upon the loading of the library. Frida gadget will look for a configuration file with the same name as the library itself but with an extension “.config”. So as per Android requirements this file must be called “libgadget.config.so”.

Conforming to these  naming criteria will ensure that upon installation the patched version of the target application will load the Frida gadget once the device is rebooted. Once all the files are in place, the application needs to be repacked into an APK file using apktool.

**Signing the target application  
**

Now the package needs to be re-signed. The certificate can be generated with a simple command such as :

keytool -genkey -v -keystore release-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias my-alias

Keep in mind that this same certificate may be needed to sign applications that share the user ID (UID) with your target application. Before the package can be signed the zip file needs to be aligned which is done with the command below.

zipalign -v -p 4 <package\_file> <output>

Afterwards the package should be signed using the apksigner with the command line below:

apksigner sign --ks <path to java keystore> --out <package name> <output  from zipalign>

**Searching for shared ID applications**

As It happens, the MtpService application installation still fails with the error below.

This means that there are applications that share the same userid but are signed with a different certificate. This can be confirmed by checking the manifest snippet below.

There is a property called “android:sharedUserId” which is defined and set to “android.media”, meaning that there are other applications that use the same userid. Any application using this shared userid must be a system application. A not very elegant but effective method to find all the applications is to download all the system applications, extract and convert the manifest into a text format and search for the shared id property.

Once all of these are known, they can either be removed, using the same technique described in the previous section; OR they can be replaced with a version signed with the same certificate. The latter is the preferred action because there may be unforeseen dependencies between the applications.

**Uninstall/replace the original target application package  
**

_This is a crucial step in this method_, without which Android security architecture will never allow the installation of the patched version of the target application. So in order to do this a tool called Magisk, will have to be installed. Magisk is a “rooting” tool that will allow users to obtain root level access on their devices without changing the whole operating system image. The tool provides a method for users to patch the kernel which can then be re-flashed into the device.

This method is the least intrusive possible, while allowing root access. Because these are system applications analysis, the root access is not that relevant (keep in mind that the application must be patched to have the Frida library in its own code) since there is no need to run Frida server as a daemon with high privileges.

Magisk has another crucial feature: It allows a user to define a virtual filesystem which will be laid on top of the actual file system at boot time. This allows any folder or file to be remapped to the version replacing the original ones flashed into the partitions upon system creation.

The first step is to install Magisk on the system that will be used for the analysis. The installation itself is beyond the scope of this article, but once installed you should be able to see the home screen of the Magisk Application, and should look something like the image below.

The application being  targeted here is stored at “/system/priv-app/MtpService/” and the image below shows that's where the application package is located at.

If one tries to delete the package manually, one can see that “/system” directory is mounted on a read-only filesystem which, as seen below, doesn’t allow the file to be deleted, even though the files are owned as root.

So the way to address this is to use what Magisk calls “modules”, where in reality a user can define a filesystem path to be overlaid by Magisk on top of the real path. Thus changing the contents of the real path. The overlay can simply delete a full path or replace it with one’s own contents.

The Magisk modules configuration is stored in “/data/adb/modules”, the full module documentation can be found here, and in this case one just needs to create a directory with the name desired for the module to have and recreate the path to overlay. By adding the file “.replace” on the last directory, one simply replaces that directory by an empty one.

The image above shows the empty directory after the module has been created.

Now that all the obstacles have been overcome, the patched application can simply be installed and the device rebooted. This should start the patched application with the instrumentation toolkit embedded in it and ready to use.

How to instrument system applications on Android stock images

By Deeba Ahmed
In total 22 proprietary software vulnerabilities were identified in the firmware, which Qualcomm addressed in its January 2023…
This is a post from HackRead.com Read the original post: Chip Vulnerabilities Impacting Microsoft, Lenovo, and Samsung Devices

In total 22 proprietary software vulnerabilities were identified in the firmware, which Qualcomm addressed in its January 2023 security bulletin.

Firmware attacks are increasingly common nowadays as cybercriminals are focusing more on the lower-level embedded code, which supports hardware. **Qualcomm**’s hardware is the latest target in this regard.

Reportedly, the company was notified about the presence of nearly 2 dozen security vulnerabilities in its flagship chipset suite, Snapdragon.

**Vulnerabilities Details**

These vulnerabilities were discovered by Binarly AI-powered firmware protection company. In total 22 proprietary software issues were identified in the firmware, which Qualcomm addressed in its January 2023 security bulletin.

These include 2 bugs in automotive tracked as CVE-2022-33218 and CVE-2022-33219 and one bug in powerline communication firmware tracked as CVE-2022-33265. These bugs were rated critical or high severity and their patching was quite complex.

Additionally, five major vulnerabilities in UEFI firmware on ARM were identified and tracked as CVE-2022-40516 to CVE-2022-40520. These vulnerabilities impacted the whole infrastructure of ARM-based devices and laptops.

Binarly discovered two types of vulnerabilities, including out-of-bounds read issued and stack-based buffer overflows. Both were connected to the DXE driver and could be exploited by whoever gained elevated privileges.

The company has released patches for the vulnerabilities in its latest security advisory, including patches for five connectivity and boot issues.

**Which Devices are at Risk?**

Devices made by Lenovo, Microsoft, and Samsung are at risk due to using Snapdragon chipsets. However, the scope of impact is highly diverse as the vulnerabilities may affect vehicles to powerline communications. For your information, the Snapdragon CPU uses the ARM architecture.

Therefore, apart from Lenovo and other manufacturers, ARM-based Microsoft Surface and Windows Dev Kit 2023/Project Volterra computers were also affected by the vulnerabilities. Some vulnerabilities could lead to arbitrary code execution and be exploited for a Secure Boot bypass, allowing an attacker to gain persistence on a device by gaining privileges to write to the file system.

**How the Flaws Were Discovered?**

Binarly founder and CEO, Alex Matrosov revealed that they discovered around nine security vulnerabilities while examining the Lenovo Thinkpad X13s firmware powered by the Snapdragon system-on-a-chip.

Further probe revealed that some vulnerabilities were specific to Lenovo devices and five impacted Qualcomm reference codes. This means the vulnerabilities were impacting laptops and all other devices having Snapdragon chips installed.

Matrosov clarified that this was the first time UEFI firmware vulnerabilities connected to the ARM device architecture were disclosed at such a scale. The CEO also noted that the number of affected chipsets is “massive.”

The good news is that Lenovo has addressed the issue and its advisory is available here.

1.  Alert: New Bluetooth flaw lets attackers monitor traffic
2.  Source code of over 50 top organizations leaked online
3.  Hackers Exploiting MSI Afterburner to Deliver Coin Miner
4.  400 chip flaws turn 3 billion Android phones into spying tool
5.  Microsoft hopes Windows PCs protection with Pluton security chip

Chip Vulnerabilities Impacting Microsoft, Lenovo, and Samsung Devices

By Waqas
Apparently, the server belongs to a company based in the US with offices around the globe including India.
This is a post from HackRead.com Read the original post: Top ERP Firm Exposing Half a Million Indian Job Seekers Data

At the time of writing, a misconfigured server belonging to an Enterprise Resource Planning (ERP) Software provider based in California, United States was still exposing data to public without any security authentication or password.

An **Elasticsearch server** belonging to a major international IT recruitment and software solution provider is currently exposing the personal data of more than half a million Indian candidates looking for jobs.

However, the data is not limited to jobseeker as the server is also exposing the company’s employees’ data. Another important aspect of this data exposure is the fact that it also contains the company’s client records from different companies, including Apple and Samsung.

This was confirmed to Hackread.com by **Anurag Sen**, a prominent independent security researcher. What is worse, the server is still exposed and publicly accessible without any security authentication or password. Originally, the server was being exposed since late December 2022.

It all started when Anurag scanned for **misconfigured databases on Shodan** and noted a server exposing more than 6GB worth of data to public access. Anurag said that the server belongs to a company originally based in the United States with offices around the globe  
including India. Whilst the database contains details of job seekers in **India**.

Hackread.com would not share the name of the company in this article because the server is still exposed.

**Exposed Data**

Anurag’s analysis of the server revealed that the exposed records contain personal data of over 575,000 individuals, while the size of the data is over 6.3GB and increasing with new data with each day passing. This data includes the following:

*   Full Name
*   Date of birth
*   Email address
*   Phone number
*   Resume details
*   Employer details

The screenshot below shows the candidate details and client data that are currently being exposed:

Image credit: Anurag Sen – Hackread.com

The screenshot below was taken from the live server that shows the company’s client details. Some of these are top companies Apple, Samsung, Sandisk, Unilog, Moody, Intuit, NEC Corporation, Falabella and many more.

The company’s client list also indicates that its a high-profile business with a presence all over the globe.

Screenshot credit: Anurag Sen – Hackread.com

**Indian CERT Alerted**

Since the server is still live at the time of writing; Anurag alerted the Indian Computer Emergency Response Team over the weekend. However, there has been no response from the authorities yet.

**India and server misconfiguration**

India is home to almost 1.4 billion people. This makes the country a lucrative target for businesses as well as cybercriminals. The more the investment, the more widespread and vulnerable the IT infrastructure becomes.

Last year, several top data exposure-related incidents involving tens of millions of victims were reported from India. These included **Indian Federal Police and banking records**, **Covid antigen test results**, **MyEasyDocs**, online packaging marketplace **Bizongo**, etc.

**Impact**

It is yet unclear whether a third party accessed the database **with malicious intent**, such as ransomware gangs or threat actors. However, if it did, it would be devastating for the victim and the healthcare firm responsible for the server.

Furthermore, considering the extent and nature of the exposed data, the incident can have far-reaching implications, such as bad actors downloading the data, carrying out phishing scams, or identity theft-related fraud.

Hackers can hold the company’s server or **data for ransom** and leak it on cybercrime forums if their demands are not met. Nevertheless, the victims in this situation are the job hunters who trusted authorities with their personal information.

**Misconfigured Databases – Threat to Privacy**

Misconfigured or unsecured databases, as we know it, have become a major privacy threat to companies and unsuspected users. **In 2020**, researchers identified over 10,000 unsecured databases that exposed more than ten billion (10,463,315,645) records to public access without any security authentication. 

**In 2021**, the number increased to 399,200 exposed databases. The top 10 countries with top database leaks due to misconfiguration in 2021 included the following:

*   USA – 93,685 databases
*   China – 54,764 databases
*   Germany – 11,177 databases
*   France – 9,723 databases
*   India – 6,545 databases
*   Singapore – 5,882 databases
*   Hong Kong – 5,563 databases
*   Russia – 5,493 databases
*   Japan – 4,427 databases
*   Italy – 4,242 databases

1.  **Hackers claim to be selling 13TB of Domino’s India data**
2.  **Hackers leak data of 29 million Indian job seekers for download**
3.  **India’s COVID-19 surveillance tool exposed millions of user data**
4.  **Hackers leak millions of Airtel India user data with Aadhaar numbers**
5.  **9,517 unsecured databases identified with 10 billion records globally**

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Top ERP Firm Exposing Half a Million Indian Job Seekers Data

Plus: Patches for Apple iOS 16, Google Chrome, Windows 10, and more.

The holiday season is almost over, but security patches are still continuing to arrive thick and fast in December. The month has seen updates released by Apple, Google, and Microsoft, as well as enterprise software companies including the likes of SAP, Citrix, and VMWare. 

Many of the patches fix zero-day vulnerabilities already being exploited in attacks, making it important that they are applied as soon as possible. Here’s the lowdown on all the patches released in December.

Apple iOS and iPadOS 16.2, iOS 15.7.2, iOS 16.1.2

Apple released a major point upgrade to its iOS 16 operating system in December: iOS 16.2. The update comes with features including end-to-end encryption in iCloud, but it also fixes 35 security vulnerabilities.

None of the issues patched in iOS 16.2 are known to have been used in attacks; however, many are pretty serious. The flaws include six in the Kernel and nine in the engine that powers Apple’s Safari browser, WebKit, which could allow an attacker to execute code. 

Apple also released iOS 15.7.2 for users of older iPhones that can’t run iOS 16, fixing a flaw already being used in attacks. Tracked as CVE-2022-42856, the WebKit vulnerability could allow an attacker to execute code, according to Apple’s support page. At the end of November, Apple fixed the same WebKit flaw in iOS 16.1.2.

Since the launch of iOS 16 in September, Apple has been offering security updates to those who don’t want to upgrade to the new operating system. But iOS 15.7.2 is only for older iPhones, so if you’ve got an iPhone 8 or above, you now need to upgrade to iOS 16 to stay secure. 

The iPhone maker also released macOS Ventura 13.1, watchOS 9.2, tvOS 16.2, macOS Big Sur 11.7.2, macOS Monterey 12.6.2, and Safari 16.2.

Google Android 

December was a hefty patch month for Google’s Android operating system, with fixes for dozens of security vulnerabilities issued during the month. Tracked as CVE-2022-20411, the most severe is a critical vulnerability in the System component that could lead to remote code execution over Bluetooth with no additional execution privileges needed, Google said in a security bulletin. 

Google also fixed two critical flaws in the Android Framework component, CVE-2022-20472 and CVE-2022-20473. Meanwhile, 151 Pixel-specific bugs were patched by Google in December. 

The December patch is available for Google’s own Pixel devices as well as Samsung smartphones, including the hardware maker’s flagship Galaxy range. 

Google Chrome 108

Google has issued an emergency update for its Chrome browser to fix the ninth zero-day vulnerability of the year. Tracked as CVE-2022-4262, the high-severity type confusion issue in Chrome’s V8 JavaScript engine could allow a remote attacker to exploit heap corruption via a crafted HTML page. “Google is aware that an exploit for CVE-2022-4262 exists in the wild,” the browser maker said in a blog.

The emergency update arrived just days after Google released Chrome 108, patching 28 security flaws. Among the fixes are CVE-2022-4174—a type confusion flaw in V8—and several use-after-free bugs. None of these vulnerabilities have been exploited in attacks, according to Google. But given that the latest bug is already in the hands of attackers, it’s a good idea to update Chrome as soon as possible.

Microsoft Patch Tuesday 

Microsoft’s December Patch Tuesday was another big one, fixing 49 security vulnerabilities, including a flaw being used in attacks. Tracked as CVE-2022-44698, the issue is a Windows SmartScreen security feature bypass vulnerability that could lead to loss of integrity and availability.

“An attacker can craft a malicious file that would evade Mark of the Web (MOTW) defenses, resulting in a limited loss of integrity and availability of security features such as Protected View in Microsoft Office, which rely on MOTW tagging,” Microsoft said.

Tag

#samsung