**BE'ER SHEVA, Israel, Feb. 23, 2023 /PRNewswire/ --** Rezilion announced today the release of the company's new research, "Hiding in Plain Sight: Hidden Vulnerabilities in Popular Open Source Containers," uncovering the presence of hundreds of docker container images containing vulnerabilities that are not detected by most standard vulnerability scanners and SCA tools.

The research revealed numerous high severity/critical vulnerabilities hidden in hundreds of popular container images, downloaded billions of times collectively. This includes high-profile vulnerabilities with publicly known exploits. Some of the hidden vulnerabilities are known to be actively exploited in the wild and are part of the CISA known exploited vulnerabilities catalog, including CVE-2021\-42013, CVE-2021\-41773, CVE-2019\-17558.

This finding follows Part I of the research, released in October, which was the first quality assessment for leading open-source and commercial vulnerability scanners and SCA tools. The vulnerability scanner benchmark survey discovered the most common causes for scanner misidentifications, including false positive and negative results.

The new research dives deeper into one of the root causes identified in the assessment - inability to detect software components not managed by package managers. The study explains how the inherent method of operation of standard vulnerability scanners and SCA tools relies on acquiring data from package managers to know what packages exist in the scanned environment, making them susceptible to missing vulnerable software packages in multiple common scenarios in which software is deployed in ways that circumvent these package managers. This research shows precisely how wide this gap is and its impact on organizations using third-party software. The report provides numerous real-world examples of some of the most popular docker container images that contain dozens of such hidden vulnerabilities. The report also offers recommendations on minimizing the risk presented in the research.

According to the report, package managers circumventing deployment methods are extremely common in Docker containers. The research team has identified over 100,000 container images that deploy code in a way that bypasses the package managers, including most of DockerHub's official container images. These containers either already contain hidden vulnerabilities or are prone to have hidden vulnerabilities if a vulnerability in one of these components is identified.

The report identifies four different scenarios in which software is deployed without interaction with package managers, such as the application itself, runtimes required for the operation of the application, dependencies as are necessary for the application to work, and dependencies required for the deployment/build process of the application that are not deleted at the end of the container image build process and shows how hidden vulnerabilities can find their way to the container images.

"We hope this research will educate developers and security practitioners of the existence of this gap so that they will be able to take appropriate actions to minimize the risk as well as push vendors and open-source projects to add support for these types of scenarios," said Yotam Perkal, Director, Vulnerability Research at Rezilion. "It's important to note that as long as vulnerability scanners and SCA tools fail to accommodate for these situations, any container image that installs packages or executables in this manner may eventually contain 'hidden' vulnerabilities if any of these components become vulnerable."

To download the full report, please visit: https://info.rezilion.com/scanner-research-part-ii

**About Rezilion:**

Rezilion's software supply chain security platform automatically assures that the software you use and deliver is free of risk. Rezilion detects third-party software components on any layer of the software stack and understands the actual risk they carry, filtering out up to 95% of identified vulnerabilities. Rezilion then automatically mitigates exploitable risk across the SDLC, reducing vulnerability backlogs and remediation timelines from months to hours, while giving DevOps teams time back to build.

Learn more about Rezilion's platform at www.rezilion.com and get a 30-day free trial.

Rezilion Research Discovers Hidden Vulnerabilities in Hundreds of Docker Container Images

CloudNativeSecurityCon North America 2023 was a vendor-neutral cloud-native security conference. Here's why it was important.

Cloud-native technology is growing in importance, and the Cloud Native Computing Foundation (CNCF), part of the Linux Foundation, is a key organization driving collaboration on cloud security throughout the industry.

That collaboration includes events such as KubeCon Americas and Europe, which often feature cloud-native security as a key topic, but seeing the importance of cloud native security, CNCF took the next step and created a separate event.

CloudNativeSecurityCon North America 2023 (CNSC) recently took place in Seattle, and served as the first vendor-neutral, practitioner-driven conference focused exclusively on cloud-native security. The event featured over 800 attendees and 50 sponsors. It had 70-plus sessions for all security levels of technologists.

**Security Is People-Powered; Industry Collaboration Is a Solution**

Security remains a pressing issue for the cloud-native and open source community, said Priyanka Sharma, Executive Director, CNCF. During her keynote, she said there are 7.1 million-plus cloud-native developers according to Slash Data.

She emphasized that the industry needs "a paradigm shift to level up our performance," as cloud usage will continue to grow, and so will the threats related to it.

Though the organizations are doing their part to secure their cloud environments, Sharma indicated that top-down approach may not be the best way, instead having a more bottom-up approach from the community, pointing to software security vendor Snyk's "2022 State of Cloud Security Report," which showed 77% of organizations saw poor training and collaboration as a major cloud security challenge.

    

Source: CNSC

Having siloed teams working in different countries, using different tools, and counting on unmonitored policies are common security challenges in many enterprise security scenarios, but when they involve the cloud, it multiplies difficulties to the security environment further. Hence, Sharma stated, "Security is people-powered," and having industry-level collaboration from all the stakeholders along with a shared asset directory will improve cloud security across the industry. Even after all the talks about innovation and right approach done in the cloud-native space, a skill shortage is something the industry is still facing. CNCF announced Kubernetes and Cloud Associate (KCSA) certification, to address the biggest challenge of lack of technical expertise in cloud-native environment.

CNCF organizes itself with Technical Advisory Groups (TAGs) for different focus areas, and it is looking to a Security TAG to help organizations with facilitating the security for projects across the cloud-native ecosystem. It's a 165-member team that supports CNCF projects through education, partnership, and project engagement. This group will help with security features for any CNCF projects; any incubating project within the organization must now go through a security audit by the Security TAG. The Sigstore project that was adopted by Kubernetes was an example of such open, multivendor collaboration.

**Key Conference Topics**

Themes that popped up during the event — including SBOM, runtime security, infrastructure as-a-code security, code to secure policies and authentication, and ChatGPT — indicated that the adoption of cloud-native applications will continue to grow, and the industry must prioritize security for these applications. The thought of having an open source security tool for securing open source code makes sense. Today, CNCF has 21 security-related open-source projects: Open Policy Agent (OPA) and Update Framework TUF have graduated with five other incubating projects, and the rest are in the sandbox stage.

**Software Supply Chain Security**

    

Source: CNSC

Many sessions at the conference were focused on understanding what the software supply chain means and why securing it remains important.

A talk by a Yahoo representative highlighted how 85% to 97% of enterprise code uses open source components, and any vulnerabilities in these may pose security threats. That issue underscores the importance of having security ingrained at every stage of the software development life cycle (SDLC), from application development to CI/CD pipeline down to production.

Code dependencies have become one of the most common reasons leading to supply chain attacks. According to a recent report on software supply chain security, supply chain attacks have grown 742% year-over-year in the past three years. Therefore, a DevSecOps approach is important to ensure the DevOps workflow is maintained by making security seamless. It means having security as an intrinsic part of application development, integration, and operation in DevOps-centric environments.

**"Shift Right" Is as Important as "Shift Left"**

Deployment of applications in the cloud has been a fast-track initiative for many enterprises, often in support of digital transformation initiatives, but many of the same security challenges, such as software vulnerabilities, managing configuration and permission, compliance, and detecting and responding to threats, plaguing traditional applications also hamper cloud application security.

From the cloud-native point of view, two trends are most visible. The first is the way in which "shift left" corresponds to the usage of CI/CD security, having centralized responsibilities and dependencies that can be monitored. It points to moving security toward an earlier stage in the software development life cycle, namely that security is built in from the time the source code is created.

But the second trend is "shift right," which is gaining equal importance in understanding what is going on in the runtime environment as the workload deployed on microservices and orchestrated by Kubernetes. The Falco project with CNCF (originally started by Sysdig), which is based on eBPF technology, seeks to help organizations understand what every process is doing in its containers and hosts. It is like a security camera for the cloud environment.

**Software Bill of Materials**

Log4j was a top of mind during the show, highlighting how it disrupted the operations of many organizations in so many different ways.

Similar high-profile attacks on the supply chain were the reason for the US federal government to issue an executive order to create guidelines for securing software solutions used for the government. The change of approach to building software using third-party dependencies makes having full transparency in the application important.

So, the approach of maintaining a software bill of materials (SBOM) that will offer a listing all components, modules, and libraries used in the application and also drawing the relationship between supply chain components is becoming increasingly important.

One interesting exchange during the conference tackled how to handle metadata that will be collected over time by each software element. In a panel, a Google representative mentioned its new product, Graph for Understanding Artifact Composition (GUAC), which functions like an aggregator for this metadata in a high-fidelity graph database.

**Sponsor Landscape**

    

Source: Omdia

CNSC was a relatively small-scale conference, but its sponsors represented vendors distributed across the industry. Approximately 55% were security vendors, 18% technology vendors offering some security, 12% were technology vendors that use in-house security product but do not sell the security product as a stand-alone offering, and 15% non-security vendors.

**A Strong Start**

The first-ever CNSC was a strong start for the cloud-native community to create a place to gather each year for a focused look at security challenges and opportunities in cloud-native environments.

CNCF is doing a great job getting different types of vendors together and supporting cloud-native security projects. This is exposing developers to security concerns. On the contrary, traditional security teams also must learn to work better with developers and ensure security approaches align with development priorities and business objectives.

This is just a first step toward solving the problems related to cloud-native security. There is more collaboration with people and process to be done in future.

Top Takeaways From CloudNativeSecurityCon 2023

Categories: News
The LockBit gang has released a chat history showing its negotiations with Royal Mail.



(Read more...)




The post Royal Mail schools LockBit in leaked negotiation appeared first on Malwarebytes Labs.

The LockBit group has finally given up any prospect of extracting a ransom from Royal Mail and published the files it stole from the company in a recent ransomware attack. The leak brings weeks of negotiations to a close, leaving Royal Mail without a decryptor, and LockBit without a payday.

Malwarebytes regards LockBit as one of the five most serious cyberthreats facing businesses in 2023. It was the most widely used ransomware-as-a-service (RaaS) in 2022, by far. It accounted for almost a third of all known RaaS attacks last year, and the largest ransom demand it made was a staggering $50 million. In February 2023 it asked Royal Mail for $80 million.

Alongside the leaked files, the LockBit gang have released a chat history that shows the negotiations between the two parties. Perhaps the group is trying to justify its decision to call off the negotiation and leak the stolen files, or perhaps it's a warning to other victims.

You could read this as a failed negotiation or a missed opportunity for Royal Mail, but I don’t. I think the chat between Royal Mail and LockBit shows something quite different.

I suspect that Royal Mail never intended to pay a ransom. It certainly showed no willingness to engage with the ludicrous $80 million that was demanded of it, and it seems to have had the LockBit negotiator dancing to its tune throughout.

The negotiation began on January 12, 2023, and like any Internet chat, the conversation takes place between two avatars who may or may not be who they say they are. When the LockBit negotiator asks who they're talking to, the Royal Mail’s representative says “I work in our IT.”

Maybe they did work in IT, but having spent years working in IT myself, and after seeing how the Royal Mail’s representative conducted themselves, I will simply say they aren’t like anyone I ever met. Perhaps they’re just naturally good negotiators, or perhaps they listened to our recent podcast about ransomware negotiations, but there is every chance they were actually a professional ransomware negotiator.

In the podcast, ransomware negotiator Kurtis Minder reveals that the first job in a situation like this is to play for time, without annoying the representative of the ransomware gang. A good way to lower the temperature is to adopt the ransomware gang’s self-serving vernacular, he says, and the Royal Mail’s “IT guy” does this in subtle ways, such as referring to LockBit’s criminal activity as “penetration testing.” Ransomware gangs like that sort of nonsense for some reason—maybe it helps them sleep at night.

Playing for time is important because it allows the victim to gather as much information as possible, understand their options, and decide their best response. They need to understand which systems are affected, how the organization can function without them temporarily, and what it will take to restore or rebuild them. They will also have numerous stakeholders to involve and duties to fulfill: Legal obligations must be met, law enforcement involved, cyberinsurance rules followed, customers and suppliers informed, and so on.

Royal Mail consistently succeeds in playing for time with LockBit. Although the first 24 hours of the chat are peppered with urgent and vaguely menacing language designed to rush the victim—“don't delay,” “hurry up,” “our patience is not infinite”—LockBit is quickly dragged into the weeds. The first two weeks of negotiation were almost entirely devoted to a tedious conversation about decrypting large files.

According to Royal Mail’s negotiator “my management have heard that your decryptor might not work on large files.” (This tactic of invoking a demanding or difficult to please manager will be familiar to anyone who’s ever haggled with a salesperson over a car.) Whether Royal Mail's curiosity about large file decryption was genuine or a ruse, it created a role reversal in the conversation, with Royal Mail asking the questions and LockBit providing the answers, to prove that it can meet Royal Mail's needs.

The Royal Mail negotiator also tried to earn trust by positioning themselves as a reasonable go between who’s trying to do the best for both parties. They consistently used language like “I am trying to help our Senior Team understand this,” “I am still trying to work with you here,” “I am doing what I can to drive things forward.”

When the conversation finally turned to money, it quickly found more weeds. This time the thorny undergrowth was formed by a disagreement about who LockBit had actually attacked. LockBit thought it was talking to Royal Mail. The victim told them they’re Royal Mail International, a loss-making subsidiary of Royal Mail with a vastly smaller turnover.

LockBit asked for a ransom of $80 million, 0.5 percent of Royal Mail’s annual global turnover. Royal Mail retorted that using LockBit's calculation, a good “starting figure” would be $4 million, based on Royal Mail International's finances.

At this point in the negotiation LockBit actually acknowledged what it was dealing with. “You are a very clever negotiator,” they wrote, “I appreciate your experience in stalling and bamboozling.”

They might have appreciated it, but they didn't seem able to do anything about it. By this point in the negotiation, Royal Mail was dictating the timeline: “We will not have anything new to speak about until Monday,” “Please confirm you will wait for their \[the board’s\] decision on Monday”.

LockBit did as it was told and waited. Finally, the last message from Royal Mail arrived on February 6, 2023. It suggested that the company probably never had any intention of paying. "To be honest with you I have heard that they \[the board\] might not want to pay you for this," it said. "In our perspective the files got leaked when you took them from our system, and paying you won’t undo that in any way."

Ransomware attacks can be devastating, and it's hard to say that being on the end of one is ever a "win" for the target. However, most experts agree that all you can ever do is reduce the chances an attack will occur and reduce the impact if it does. You can only ever play the hand you're dealt, and we think given the hand they were playing, Royal Mail's negotiation came as close to a win as a loss like this ever does.

**How to avoid ransomware**

*   **Block common forms of entry**. Create a plan for patching vulnerabilities in internet-facing systems quickly; disable or harden remote access like RDP and VPNs; use endpoint security software that can detect exploits and malware used to deliver ransomware.
*   **Detect intrusions**. Make it harder for intruders to operate inside your organization by segmenting networks and assigning access rights prudently. Use EDR or MDR to detect unusual activity before an attack occurs.
*   **Stop malicious encryption**. Deploy Endpoint Detection and Response software like Malwarebytes EDR that uses multiple different detection techniques to identify ransomware.
*   **Create offsite, offline backups**. Keep backups offsite and offline, beyond the reach of attackers. Test them regularly to make sure you can restore essential business functions swiftly.
*   **Write an incident response plan**. The period after a ransomware attack can be chaotic. Make a plan that outlines how you'll isolate an outbreak, communicate with stakeholders, and restore your systems.

**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.

Royal Mail schools LockBit in leaked negotiation

ThingsBoard 3.4.1 could allow a remote attacker to gain elevated privileges because hard-coded service credentials (usable for privilege escalation) are stored in an insecure format. (To read this stored data, the attacker needs access to the application server or its source code.)

CVE-2023-26462: ThingsBoard Release Notes

An issue was discovered in the Linux kernel through 6.2.0-rc2. drivers/tty/vcc.c has a race condition and resultant use-after-free if a physically proximate attacker removes a VCC device while calling open(), aka a race condition between vcc_open() and vcc_remove().

This bug assumes that the hacker can physically access the  
target computer.

A race condition may occur if the user physically removes the  
vcc device while calling open().

This is a race condition between vcc\_open() function and  
the vcc\_remove() function, which may lead to Use-After-Free.

Therefore, add a refcount check to vcc\_remove() function  
to free the "vcc\_port" structure after the device is close()d.

\---------------CPU 0--------------------CPU 1-----------------  
vcc\_open() | vcc\_remove()  
\--------------------------------------------------------------  
port = vcc\_get\_ne(tty-> |  
index); — (1) |  
| struct vcc\_port \*port =  
| dev\_get\_drvdata(&vdev->dev);  
| ...  
| kfree(port); — (2)  
vccdbgl(port->vio.lp); — (3) |

This type of race condition is similar with CVE-2022-44032,  
CVE-2022-44033, and CVE-2022-44034.  
\---  
drivers/tty/vcc.c | 18 ++++++++++++++++++  
1 file changed, 18 insertions(+)

diff --git a/drivers/tty/vcc.c b/drivers/tty/vcc.c  
index 34ba6e54789a..31f274c4aa25 100644  
\--- a/drivers/tty/vcc.c  
+++ b/drivers/tty/vcc.c  
@@ -41,6 +41,8 @@ struct vcc\_port {

struct timer\_list rx\_timer;  
struct timer\_list tx\_timer;  
\+ struct vio\_dev \*vdev;  
\+ struct kref refcnt;  
};

/\* Microseconds that thread will delay waiting for a vcc port ref \*/  
@@ -104,6 +106,7 @@ static const struct ktermios vcc\_tty\_termios = {  
.c\_ospeed = 38400  
};

+static void vcc\_delete(struct kref \*kref);  
/\*\*  
\* vcc\_table\_add() - Add VCC port to the VCC table  
\* @port: pointer to the VCC port  
@@ -586,6 +589,8 @@ static int vcc\_probe(struct vio\_dev \*vdev, const struct vio\_device\_id \*id)  
goto free\_port;

port->vio.debug = vcc\_dbg\_vio;  
\+ port->vdev = vdev;  
\+ kref\_init(&port->refcnt);  
vcc\_ldc\_cfg.debug = vcc\_dbg\_ldc;

rv = vio\_ldc\_alloc(&port->vio, &vcc\_ldc\_cfg, port);  
@@ -673,6 +678,14 @@ static void vcc\_remove(struct vio\_dev \*vdev)  
{  
struct vcc\_port \*port = dev\_get\_drvdata(&vdev->dev);

\+ kref\_put(&port->refcnt, vcc\_delete);  
+}  
+  
+static void vcc\_delete(struct kref \*kref)  
+{  
\+ struct vcc\_port \*port = container\_of(kref, struct vcc\_port, refcnt);  
\+ struct viod\_dev \*vdev = port->vdev;  
+  
del\_timer\_sync(&port->rx\_timer);  
del\_timer\_sync(&port->tx\_timer);

@@ -752,12 +765,15 @@ static int vcc\_open(struct tty\_struct \*tty, struct file \*vcc\_file)  
pr\_err("VCC: open: TTY ops not defined\\n");  
return -ENXIO;  
}  
\+ kref\_get(&port->refcnt);

return tty\_port\_open(tty->port, tty, vcc\_file);  
}

static void vcc\_close(struct tty\_struct \*tty, struct file \*vcc\_file)  
{  
\+ struct vcc\_port \*port = vcc\_get\_ne(tty->index);  
+  
if (unlikely(tty->count > 1))  
return;

@@ -767,6 +783,8 @@ static void vcc\_close(struct tty\_struct \*tty, struct file \*vcc\_file)  
}

tty\_port\_close(tty->port, tty, vcc\_file);  
+  
\+ kref\_put(&port->refcnt, vcc\_delete);  
}

static void vcc\_ldc\_hup(struct vcc\_port \*port)  
\--  
2.39.0

CVE-2023-23039: LKML: Yoochan Lee: [PATCH] drivers: tty: vcc: Fix use-after-free in vcc_open()

Organizations are urged to update to the latest versions of FortiNAC to patch a flaw that allows unauthenticated attackers to write arbitrary files on the system.

Researchers have released details for how to exploit a critical remote code execution (RCE) bug in Fortinet's FortiNAC product, which allows an unauthenticated attacker to write arbitrary files on the system and achieve RCE as a root user.

Organizations use FortiNAC as a network access control solution to oversee and secure all digital assets connected to the enterprise network. The product can be used to manage a range of devices, including: corporate endpoints, Internet of Things (IoT), operational technology and industrial control systems (OT/ICS), and connected medical devices (IoMT), among others. The idea is to provide visibility, control, and automated response for everything that connects to the network, and as such, the device offers a golden opportunity for attackers to pivot and move deep into networks, enumerate environments, steal sensitive information, and more.

Researchers at Horizon3.ai released a blog post with a technical analysis of and proof of concept (POC) exploit for the vulnerability, tracked as CVE-2022-39952, and revealed and patched by Fortinet last week. They subsequently released the exploit code on GitHub.

Fortinet's Gwendal Guégniaud discovered the vulnerability, which earned a critical rating of 9.8 on the CVSS vulnerability-severity scale. The bug allows attackers to take external control of a file name or path vulnerability in the FortiNAC Web server, Fortinet said in its advisory, thus allowing unauthenticated arbitrary writes on the system.

Fortinet has patched in its affected product versions, with customers urged to update to FortiNAC version 9.4.1 or above, FortiNAC version 9.2.6 or above, FortiNAC version 9.1.8, or FortiNAC version 7.2.0 or above.

**How to Exploit the Fortinet FortiNAC Flaw**

While there are several ways for attackers to obtain RCE by exploiting arbitrary file write flaws, the researchers wrote what's called a "cron job to /etc/cron.d/" to take advantage of the vulnerability, they said.

The researchers extracted filesystems from both the vulnerable and patched versions of the product to examine the flaw, finding that Fortinet removed an offending file called /bsc/campusMgr/ui/ROOT/configWizard/keyUpload.jsp in the update that patches the bug. It turns out that file allowed an unauthenticated endpoint to parse requests that supply a file in the key parameter and then write it to /bsc/campusMgr/config.applianceKey, the researchers said.

To exploit this flaw, researchers successfully wrote the file and made a call that executes a bash script, which in turn can unzip the file that was just written. The unzip process "will allow placing files in any paths as long as they do not traverse above the current working directory," Horizon3.ai's chief attack engineer Zach Hanley wrote in the blog post. "Because the working directory is /, the call unzip inside the bash script allows any arbitrary file to be written."

"Immediately, seeing this call on the attacker-controlled file gave us flashbacks to a few recent vulnerabilities we’ve looked at that have abused archive unpacking," he added.

Researchers used the aforementioned cron job — which entails using the code /etc/cron.d/payload — to weaponize the flaw. The job gets triggered every minute and initiates a reverse shell to the attacker. To do this, researchers created a zip archive that contains a file and specifies the path for extraction, and then sent the malicious zip file to the vulnerable endpoint in the key field, they said.

"Within a minute, we get a reverse shell as the root user," which then can allow for remote code to be executed, Hanley wrote.

**History of Attacker Interest**

Historically, attackers have had a tendency to pounce on Fortinet flaws — sometimes even before the company knows they exist. Since they offer a prime opportunity to gain a foothold on enterprise networks, it would be prudent for any organizations running affected versions of FortiNAC to update to the patched products ASAP. So far, neither Fortinet nor Horizon3.ai are aware of any instances of attackers taking advantage of the flaw, but now that the latter's proof of concept is released, with step-by-step details on how it can be exploited, this is likely to change. 

As recently as January, the researchers tied a sophisticated new backdoor dubbed BoldMove to a zero-day vulnerability that Fortinet discovered in multiple versions of its FortiOS and FortiProxy technologies in December. The flaw allowed an unauthenticated attacker to execute arbitrary code on affected systems. In the zero-day attack, a China-based threat actor engaged in cyber-espionage operations apparently had written the malware to run specifically on Fortinet's FortiGate firewalls even before the vulnerability was made public and patched, the researchers discovered.

In October, attackers also showed significant interest in a critical authentication bypass vulnerability in multiple versions of Fortinet's FortiOS, FortiProxy, and FortiSwitchManager technologies, particularly after exploit code for the flaw was released.

Exploit Code Released for Critical Fortinet RCE Bug

By Habiba Rashid
The voice chat app under discussion is OyeTalk, which is available for Android and iOS devices and is operated from Pakistan.
This is a post from HackRead.com Read the original post: Android voice chat app with 5m installs leaked user chats

OyeTalk was leaking unencrypted data through unprotected access to Firebase, Google’s mobile application development platform that provides cloud-hosted database services.

A popular Android voice chat app, OyeTalk, has leaked private user data, including their unencrypted chats, usernames, and cellphone International Mobile Equipment Identity (IMEI) numbers.

With over five million downloads on **Google Play**, the app has compromised the privacy of all its users while simultaneously exposing them to malicious threats.

OyeTalk on Android

OyeTalk was leaking data through unprotected access to **Firebase**, Google’s mobile application development platform that provides cloud-hosted database services.

The researchers warned that malicious actors could have deleted the dataset, resulting in a permanent loss of users’ private messages, if the leaked data had not been backed up. 

According to the Cyber News **blog post**, Despite being informed of the data spill, the app developers failed to close off public access to the database. Google’s security measures had to step in, since the spill got too big, to close off the database.

This isn’t all. The developers also carelessly left sensitive information hardcoded in the application’s client-side, including a Google API (application programming interface) key and links to Google storage buckets. The exploitation of this security practice in the past has resulted in data loss or a complete takeover of user data stored on open Firebase or other storage systems.

It turns out, this was not the first occurrence of a data leak affecting OyeTalk. The researchers found that the database had been discovered and marked as vulnerable by unknown actors, likely with no malicious intent. The database contained specific fingerprints used to mark open Firebases, known as “**Proof of Compromise**” (PoC) and Evidence of Compromise (EoC) or Indicator of Compromise (IOC).

**Repercussions**

The repercussions of a data leak like the one that occurred with the OyeTalk voice chat app can be severe and far-reaching. First and foremost, the personal information of users can be compromised, leaving them vulnerable to scams.

Furthermore, the leak of personal data can also have a negative impact on the reputation of the app and the company behind it. Users may lose trust in the app and its ability to protect their data, leading to a decline in its user base and revenue. This can also result in legal consequences for the company, as they may face lawsuits and fines for violating data privacy laws.

Overall, the OyeTalk data leak can have significant and lasting consequences for users, the app and its company, and society at large. It underscores the importance of robust data protection measures and responsible handling of personal information and highlights the need for ongoing vigilance in the face of ever-evolving **cybersecurity threats**.

1.  **23 Android apps leaked sensitive data of 100m users**
2.  **GoKeyboard App Spying on Millions of Android Users**
3.  **Dune! game app leaked personal data of Android users**
4.  **Login Details of Tech Giants Leaked in Data Center Hacks**
5.  **Iranian hackers drop RatMilad Android spyware in VPN app**

I’m a student and cybersecurity writer. On a random Sunday, I am likely to be figuring out life and reading Kafka.

Android voice chat app with 5m installs leaked user chats

Apple has revised the security advisories it released last month to include three new vulnerabilities impacting iOS, iPadOS, and macOS.
The first flaw is a race condition in the Crash Reporter component (CVE-2023-23520) that could enable a malicious actor to read arbitrary files as root. The iPhone maker said it addressed the issue with additional validation.
The two other vulnerabilities,

Endpoint Security / Software Update

Apple has revised the security advisories it released last month to include three new vulnerabilities impacting iOS, iPadOS, and macOS.

The first flaw is a race condition in the Crash Reporter component (CVE-2023-23520) that could enable a malicious actor to read arbitrary files as root. The iPhone maker said it addressed the issue with additional validation.

The two other vulnerabilities, credited to Trellix researcher Austin Emmitt, reside in the Foundation framework (CVE-2023-23530 and CVE-2023-23531) and could be weaponized to achieve code execution.

"An app may be able to execute arbitrary code out of its sandbox or with certain elevated privileges," Apple said, adding it patched the issues with "improved memory handling."

The medium to high-severity vulnerabilities have been patched in iOS 16.3, iPadOS 16.3, and macOS Ventura 13.2 that were shipped on January 23, 2023.

Trellix, in its own report on Tuesday, classified the two flaws as a "new class of bugs that allow bypassing code signing to execute arbitrary code in the context of several platform applications, leading to escalation of privileges and sandbox escape on both macOS and iOS."

The bugs also bypass mitigations Apple put in place to address zero-click exploits like FORCEDENTRY that was leveraged by Israeli mercenary spyware vendor NSO Group to deploy Pegasus on targets' devices.

As a result, a threat actor could exploit these vulnerabilities to break out of the sandbox and execute malicious code with elevated permissions, potentially granting access to calendar, address book, messages, location data, call history, camera, microphone, and photos.

Even more troublingly, the security defects could be abused to install arbitrary applications or even wipe the device. That said, exploitation of the flaws requires an attacker to have already obtained an initial foothold into it.

"The vulnerabilities above represent a significant breach of the security model of macOS and iOS which relies on individual applications having fine-grained access to the subset of resources they need and querying higher privileged services to get anything else," Emmitt said.

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

Apple Warns of 3 New Vulnerabilities Affecting iPhone, iPad, and Mac Devices

By Deeba Ahmed
The bugs allowed cybercriminals to bypass the iOS system's security protections and execute unauthorized code. 
This is a post from HackRead.com Read the original post: Apple Bug Could Allow Attackers Access to Photos and Messages

The findings are based on previous research from Google and Citizen Lab conducted in 2021 which discovered a zero-click, zero-day iOS exploit dubbed “ForcedEntry,” linked to the Israeli NSO Group.

Apple devices and products are known for their advanced security mechanisms, particularly the iPhone and Macbook. However, the latest research reveals that even Apple products aren’t safe from the prying eyes of threat actors.

Researchers at the cybersecurity firm Trellix Advanced Research Center have disclosed details of a newly discovered privilege escalation bug class that, if exploited, could allow an attacker to sweep up call history, messages, and photos from the device.

According to researchers, the bugs allowed cybercriminals to bypass the iOS system’s security protections and execute unauthorized code. The security flaws were ranked as medium to high in terms of security.

Trellix’s vulnerability research director, Doug McKee, stated that although Apple has addressed the issue, the concern is that these vulnerabilities allow bypassing of Apple’s security model at a “fundamental level.”

Apple said the bugs weren’t exploited in the wild before being fixed.

**How Was the Bug Discovered?**

The findings are based on previous research from Google and Citizen Lab conducted in 2021. The organizations discovered a zero-click, zero-day iOS exploit dubbed “ForcedEntry,” linked to NSO Group.

This was a highly sophisticated exploit found on a Saudi activist’s iPhone and was used for installing Pegasus malware developed by the NSO Group. The same spyware was also found on the iPhones of nine State Department officials in the United States.

This exploit had two key features: first, it tricked the iPhone into opening a malicious PDF disguised as a GIF file. Secondly, it enabled attackers to evade the sandbox that Apple introduced to prevent apps from accessing data from other apps or other parts of the device.

This second feature of ForcedEntry was the basis of Trellix’s research from senior vulnerability researcher Austin Emmitt. A proof-of-concept was released to demonstrate how the bugs could be exploited.

**Vulnerabilities**

Emmitt discovered a new class of vulnerabilities revolving around the NSPredicate tool that filters code within Apple’s systems. This tool was first exploited in ForcedEntry, as the 2021 research revealed, and Apple introduced new measures to prevent this abuse.

However, the mitigation methods were insufficient, as Trellix researchers found that these methods could also be bypassed since bugs in the NSPredicate class were found in multiple places in macOS and iOS systems.

This includes the Springboard app, which manages the home screen on an iPhone and can access photos, location data, and the camera. After exploiting the bugs, the attacker could access places they could not otherwise invade. Attackers trying to exploit it need to gain an initial foothold into the device.

Vulnerabilities in NSPredicate were discovered in macOS 13.2 and iOS 16.3, and Apple patched them with software updates in January. The company also issued CVEs for these flaws—CVE-2023-23530 and CVE-2023-23531—and released new versions of macOS and iOS.

1.  Apple AirTags used as trojan for credential hacking
2.  iOS Devices Receive Vital Security Updates from Apple
3.  Charging cable remotely steals data from Apple devices
4.  55 Apple bugs risked iCloud account takeover, data theft
5.  Study: Android sends more data to Google than iOS to Apple

Apple Bug Could Allow Attackers Access to Photos and Messages

A lack of rate limiting on the password reset endpoint of Chamberlain myQ v5.222.0.32277 (on iOS) allows attackers to compromise user accounts via a bruteforce attack.

The Chamberlain Group LLC, the corporate parent company to LiftMaster, Chamberlain, Merlin and Grifco, is a global leader in access solutions and products. We design and engineer residential garage door openers, commercial door operators and gate entry systems. Read our story.

Tag

#ios