Plus: The worst telecom hack in US history rolls on, iPhones are harder to break into, and more of the week’s top security news.

A joint investigation by WIRED, Bayerischer Rundfunk (BR), and Netzpolitik.org uncovered that US companies legally collecting digital ad data are enabling adversaries to cheaply track American military and intelligence personnel. A collaborative analysis of billions of location coordinates from a US-based data broker revealed detailed tracking of thousands of devices from sensitive US sites in Germany, including NSA facilities and bases reportedly housing US nuclear weapons.

Elsewhere, social media giant Meta has disclosed for the first time its efforts to combat the forced-labor compounds driving the surge in pig butchering scams on its platforms. The company revealed that it has been quietly collaborating with global law enforcement, tech industry partners, and external experts for over two years to dismantle the crime syndicates behind these operations in Southeast Asia and the UAE. This year alone, Meta reports it has taken down more than 2 million accounts linked to scam compounds in Myanmar, Laos, Cambodia, the Philippines, and the UAE.

At the Cyberwarcon security conference on Friday, the cybersecurity firm SpyCloud shared findings about publicly accessible black market services offering low-cost access to sensitive information on Chinese citizens, including phone numbers, banking details, hotel and flight records, and even real-time location data. According to the firm’s researchers, these services seem to obtain their data through insiders within Chinese surveillance agencies and government contractors, who sell their access. Also at the conference, cybersecurity firm Volexity uncovered that a Russian hacking group has reportedly developed a novel Wi-Fi-hacking technique that involves taking control of a nearby laptop and using it as a bridge to infiltrate a targeted Wi-Fi network. Dubbed a “nearest neighbor attack,” the method was uncovered during a 2022 investigation by the firm into a network breach of an unnamed Washington, DC. client. And finally, researchers explored how the US is calling out foreign influence campaigns faster than they ever have—but there’s plenty of room for improvement.

That’s not all. Each week, we round up the security and privacy news we didn’t cover in depth ourselves. Click on the headlines to read the full stories. And stay safe out there.

**“King of Toxic Masculinity” Gets Hacked**

Hacktivists have breached an online “educational platform” founded by the misogynistic right-wing influencer Andrew Tate reportedly revealing the email addresses of hundreds of thousands of users as well as the contents of the platforms’ private chat servers. Data from the hack, first reported by the Daily Dot, has now been published by the transparency nonprofit Distributed Denial of Secrets.

Andrew Tate, the so-called “king of toxic masculinity,” is currently under house arrest in Romania and faces two separate criminal charges, including allegations of forming an organized criminal group and trafficking women across Romania, the UK, and the US.

The compromised platform, a subscription-based service known as The Real World (formerly called Hustler's University), describes itself as a “global community” focused on “personal growth.” According to its website, members receive expert training, mentorship, and access to a wide range of educational courses for around $50 per month.

According to the Daily Dot, hacktivists announced their breach of the platform on Thursday by disrupting the course's main chatroom with a barrage of uploaded emojis while Tate was livestreaming an episode of his show _Emergency Meeting_ on Rumble. The emojis included a transgender pride flag, a feminist fist, an AI-generated image of Tate wrapped in a rainbow flag.

Data from the breach, verified by WIRED, includes more than 700,000 usernames and reportedly includes messages from 221 public and 395 private chat servers. An analysis by the Daily Dot reveals a mix of content within the chat logs, ranging from motivational quotes and personal progress updates to grievances about the “LGBTQ agenda.” WIRED is continuing to analyze the leaked material.

**The “Worst Telecom Hack in US History” Is Still Ongoing**

Chinese government hackers have infiltrated over a dozen US telecommunications companies in what a senior senator is calling the worst telecom breach in American history—and they’re still inside the networks. The hacking group, Salt Typhoon, has been able to eavesdrop on audio calls in real time and obtain millions of records of call and text metadata from targeted individuals, according to a Washington Post interview with Senator Mark Warner of Virginia, chairman of the Senate Intelligence Committee.

Fewer than 150 victims have been identified and notified by the FBI so far—most of them in the DC region—including president-elect Donald Trump, his vice president-elect, JD Vance, as well as people working for Vice President Kamala Harris and state department officials.

Warner said, however, that the effort was not directly election-related, as the hackers got into some telecom systems more than a year ago.

**Leaked Documents Show GrayKey Struggles to Access Modern iPhones**

Leaked documents obtained by 404 Media reveal that GrayKey, a phone-hacking tool used by law enforcement to extract data from devices in their possession, can at the moment only partially access information from modern iPhones running iOS 18.0 and 18.0.1.

While the precise details of exactly how Graykey operates are unknown, the tool reportedly brute-forces iPhone or Android passcodes to unlock them—essentially hacking the phone—allowing law enforcement to then access and extract encrypted device data. While the specific types of data accessible during a “partial” extraction are unclear, it likely includes unencrypted files and metadata, such as file sizes and folder structures.

The document provides context to an ongoing cat-and-mouse dynamic between forensic technology companies and mobile device manufacturers. With each new software update, tools like GrayKey are temporarily thwarted, prompting developers to quickly adapt their technology to catch up. At the moment it appears that they have not. This leak follows another report from 404 Media about a feature in iOS 18 called “inactivity reboot,” which forces devices to restart after four days of inactivity, adding another layer of difficulty for law enforcement attempting to access data on seized devices.

**Europe Probes Undersea Cable Sabotage**

European authorities are investigating suspected sabotage to two undersea fiber-optic cables: one linking Finland and Germany, and the other connecting Sweden and Lithuania. Russia—widely suspected as the likely perpetrator—denies involvement, dismissing the allegations as “ridiculous.”

The incident began on Sunday when two telecommunications companies detected traffic disruptions likely caused by physical damage to undersea cables. One of the affected cables, known as C-Lion—a vital 730-mile link between Finland and Central Europe—runs alongside other critical infrastructure, including gas pipelines and power lines.

By Wednesday, the Danish navy had reportedly intercepted a Chinese cargo ship in connection with the disruptions. The vessel, which had most recently docked in Russia before the incident, was near the damaged area at the time. It is now under investigation, with its crew being questioned about their possible involvement.

Andrew Tate’s ‘Educational Platform’ Was Hacked

A security-relevant race between mremap() and THP code has been discovered. Reaching the buggy code typically requires the ability to create unprivileged namespaces. The bug leads to installing physical address 0 as a page table, which is likely exploitable in several ways: For example, triggering the bug in multiple processes can probably lead to unintended page table sharing, which probably can lead to stale TLB entries pointing to freed pages.

    SummaryI found a security-relevant race between mremap() and THP code. Reaching the buggy code typically requires the ability to create unprivileged namespaces. The bug leads to installing physical address 0 as a page table, which is likely exploitable in several ways: For example, triggering the bug in multiple processes can probably lead to unintended page table sharing, which probably can lead to stale TLB entries pointing to freed pages.I also found two other (untested) theoretical races, but those arguably might not even count as bugs, and I'm pretty sure they're not security bugs. I am including my analysis of the closely related non-issues 2 and 3 as context in case you're curious, but I think they're stuff we can deal with on the public list later (or maybe even just leave as-is). Feel free to ignore that part of this report.I will send a suggested patch for the security bug, but I think it's unclear if my patch is actually the right way to fix it.This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2024-12-31.For more details, see the Project Zero vulnerability disclosure policy: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.htmlSecurity bug: move_normal_pmd vs MADVISE_COLLAPSEDescriptionIn mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd().move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination:        /* Clear the pmd */        pmd = *old_pmd;        pmd_clear(old_pmd);        VM_BUG_ON(!pmd_none(*new_pmd));        pmd_populate(mm, new_pmd, pmd_pgtable(pmd));        flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE);The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after we have inspected the PMD entry to decide how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise):process A                      process B=========                      =========mremap  mremap_to    move_vma      move_page_tables        get_old_pmd        alloc_new_pmd                      *** PREEMPT ***                               madvise(MADV_COLLAPSE)                                 do_madvise                                   madvise_walk_vmas                                     madvise_vma_behavior                                       madvise_collapse                                         hpage_collapse_scan_file                                           collapse_file                                             retract_page_tables                                               i_mmap_lock_read(mapping)                                               pmdp_collapse_flush                                               i_mmap_unlock_read(mapping)        move_pgt_entry(NORMAL_PMD, ...)          take_rmap_locks          move_normal_pmd          drop_rmap_locksIn this case, while move_normal_pmd() expects to see a PMD entry pointing to a page table, the PMD entry has actually been cleared. So this line:pmd_populate(mm, new_pmd, pmd_pgtable(pmd));runs pmd_pgtable() on a cleared PMD entry. On typical implementations (including the X86 one), this simply masks off some bits of pmd and assumes that the remainder is a physical address - so pmd_pgtable(0) returns a pointer to the page for physical address 0. Then, pmd_populate() constructs a PMD entry that points to this physical address as a page table.So this ends up installing physical address 0 as a page table.Fixing itI guess there are two ways we could fix this:    Hold the rmap locks much more broadly in move_page_tables(). In particular, take them before inspecting the source pmd, and if we do a PMD-level move, keep them held throughout the entire move.    Add a bunch of extra recheck/retry logic.I think the first option is nicer in terms of code complexity. Moving the lock up requires a small bit of refactoring though, and the broader locking could conceivably degrade the performance of concurrent rmap access.I will send a suggested patch for the first option in a minute (and I have tested that with that patch, my reproducer no longer triggers); but we might want to do some more bikeshedding of whether this is the right way to patch it, and if yes, whether the patch is doing too little lock-dropping for performance or adds too much complexity with the lock-dropping...ReproducerI made a testcase that triggers this issue after a while and causes a splat when the kernel later tries to unmap this page table at physical address 0:#define _GNU_SOURCE#include <err.h>#include <sched.h>#include <stdio.h>#include <string.h>#include <fcntl.h>#include <signal.h>#include <stdlib.h>#include <unistd.h>#include <sys/syscall.h>#include <sys/stat.h>#include <sys/prctl.h>#include <sys/mount.h>#include <sys/mman.h>#include <sys/wait.h>#include <sys/ioctl.h>static void pin_to(int cpu) {  cpu_set_t cset;  CPU_ZERO(&cset);  CPU_SET(cpu, &cset);  if (sched_setaffinity(0, sizeof(cpu_set_t), &cset))    err(1, "set affinity");}#ifndef MADV_COLLAPSE#define MADV_COLLAPSE 25#endif#define SYSCHK(x) ({          \  typeof(x) __res = (x);      \  if (__res == (typeof(x))-1) \    err(1, "SYSCHK(" #x ")"); \  __res;                      \})static void write_file(char *name, char *buf) {  int fd = SYSCHK(open(name, O_WRONLY));  if (write(fd, buf, strlen(buf)) != strlen(buf))    err(1, "write %s", name);  close(fd);}static void write_map(char *name, int outer_id) {  char buf[100];  sprintf(buf, "0 %d 1", outer_id);  write_file(name, buf);}int main(void) {  // set up new mount ns for tmpfs with THP  int outer_uid = getuid();  int outer_gid = getgid();  SYSCHK(unshare(CLONE_NEWNS|CLONE_NEWUSER));  SYSCHK(mount(NULL, "/", NULL, MS_PRIVATE|MS_REC, NULL));  write_file("/proc/self/setgroups", "deny");  write_map("/proc/self/uid_map", outer_uid);  write_map("/proc/self/gid_map", outer_gid);  // make tmpfs with THP  SYSCHK(mount("none", "/tmp", "tmpfs", MS_NOSUID|MS_NODEV, "huge=advise"));  pin_to(0);  while (1) {    int fd = SYSCHK(open("/tmp/a", O_RDWR|O_CREAT, 0600));    void *ptr = SYSCHK(mmap((void*)0x200000UL, 0x200000, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED_NOREPLACE, fd, 0));    SYSCHK(ftruncate(fd, 0x1000));    *((volatile char *)ptr) = 'a';    SYSCHK(ftruncate(fd, 0x200000));    SYSCHK(madvise(ptr, 0x200000, MADV_HUGEPAGE));    close(fd);    SYSCHK(unlink("/tmp/a"));    int child = SYSCHK(fork());    if (child == 0) {      for (int i=0; i<512; i++)        ((volatile char *)ptr)[0x1000*i] = 'a';      struct sched_param param = { .sched_priority = 0 };      SYSCHK(sched_setscheduler(0, SCHED_IDLE, &param));      /* race (outer side, will be preempted) */      SYSCHK(mremap((void*)0x200000, 0x200000, 0x200000, MREMAP_MAYMOVE|MREMAP_FIXED, (void*)0x40000000));      return 0;    }    for (int i=0; i<512; i++)      ((volatile char *)ptr)[0x1000*i] = 'a';    usleep(10);    /* race (inner side, will preempt after timer and voluntary resched) */    int madv_res = madvise(ptr, 0x200000, MADV_COLLAPSE);    if (madv_res == -1)      fprintf(stderr, "_");    int wstatus;    SYSCHK(waitpid(child, &wstatus, 0));    SYSCHK(munmap(ptr, 0x200000));    fprintf(stderr, ".");  }}Usage:user@vm:~/collapse-vs-mremap$ gcc -o collapse-vs-mremap-2-noassist collapse-vs-mremap-2-noassist.cuser@vm:~/collapse-vs-mremap$ ./collapse-vs-mremap-2-noassist.................................................................................................................................Result on Linux 6.11 in a QEMU VM, where a bunch of non-zero data is left over in the first 0x1000 bytes of physical memory (note the pmd:00000067):[  120.427189] BUG: Bad page map in process collapse-vs-mre  pte:f000ff53f000ff53 pmd:00000067[  120.428763] addr:0000000040000000 vm_flags:200000fb anon_vma:0000000000000000 mapping:ffff888007dd70f8 index:0[  120.430526] file:a fault:shmem_fault mmap:shmem_mmap read_folio:0x0[  120.431706] CPU: 0 UID: 1000 PID: 1219 Comm: collapse-vs-mre Tainted: G        W          6.11.0 #493[  120.433591] Tainted: [W]=WARN[  120.434201] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[  120.435849] Call Trace:[  120.436375]  <TASK>[  120.436843]  dump_stack_lvl+0x53/0x70[  120.437570]  print_bad_pte+0x4e6/0x8e0[...][  120.447625]  vm_normal_page+0x1c8/0x260[...][  120.450162]  unmap_page_range+0x914/0x3d10[...][  120.456954]  unmap_vmas+0x1cc/0x390[...][  120.461123]  exit_mmap+0x160/0x6c0[...][  120.465181]  mmput+0xa0/0x3a0[  120.465793]  do_exit+0x7cd/0x27f0[...][  120.472198]  do_group_exit+0xac/0x230[  120.472916]  __x64_sys_exit_group+0x3e/0x50[  120.473722]  x64_sys_call+0x17f3/0x1800[  120.474469]  do_syscall_64+0x4b/0x110[  120.475189]  entry_SYSCALL_64_after_hwframe+0x76/0x7e[...][  120.489560]  </TASK>On other machines where physical page 0 contains only zeroes, the error is different and the kernel complains about the mm's pagetable bytes counter being -4096 on process exit.ImpactReaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. (Some Android kernels set CONFIG_READ_ONLY_THP_FOR_FS=y, but those kernels are older than 6.6, so they're not affected.)As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, so on normal Linux systems you usually need the ability to create your own user+mount namespace (like my reproducer does).If you trigger this bug in two different processes, or in two different locations in the same process, you should get physical page 0 mapped in two different places. Assuming you know that a certain part of the page contains zeroes, you should be able to get page table entries installed through one of the mappings, and then access those page table entries through the other mapping of the same page table.At that point, I think several bad things can happen that could lead to privilege escalation, though I haven't tested that:    When a PTE is zapped through the page table's first mapping, TLB flushes will only be done for the first mapping, but there can be TLB entries created through the second mapping. So you could probably end up with stale TLB entries pointing to freed pages.    If VMA 1 and VMA 2 share a page table, and you install an anonymous page through VMA 1, and then use mremap() on VMA 2 to move that PTE to another location, and then munmap() VMA 1, you'll end up with an anonymous page that's only mapped into a VMA that is not associated with the page's anon_vma, which leads to kernel UAF. (See https://project-zero.issues.chromium.org/issues/42451486 and https://git.kernel.org/linus/2555283eb40d .)I think the exploitability of this bug depends on whether a struct page has been allocated for physical address 0 - but that seems to be the case at least on the two X86 systems I tested this on.Non-issue 2 (no impact): move_ptes vs MADVISE_COLLAPSEmove_ptes() locks the source and destination page tables as follows:        old_pte = pte_offset_map_lock(mm, old_pmd, old_addr, &old_ptl);        if (!old_pte)                return -EAGAIN;        new_pte = pte_offset_map_nolock(mm, new_pmd, new_addr, &new_ptl);        if (!new_pte) {                pte_unmap_unlock(old_pte, old_ptl);                return -EAGAIN;        }        if (new_ptl != old_ptl)                spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);pte_offset_map_nolock() followed by manually taking the page table lock does not (unlike pte_offset_map_lock()) protect against concurrent removal of the page table via retract_page_tables(); and that can happen when need_rmap_locks is false. So I think that after this block, we can end up with new_pte pointing to a page table that has already been scheduled for RCU-delayed freeing. The good news is that (as far as I understand) this can only happen when all the PTEs in the source page table are pte_none(), so no PTEs will actually be written to the detached destination page table, so nothing bad happens.Non-issue 3 (probably no impact, untested): move_huge_pmd vs split_huge_page_to_list_to_orderThe classic way mremap() used to work is:    We make a new VMA.    We move page table entries into the new VMA with move_page_tables(), creating page tables if necessary. Only page table entries are moved; the old page tables stay where they are.    If a page table allocation fails due to OOM, or if the ->mremap handler returns an error, we use move_page_tables() to move the page table entries back to the old VMA; this is expected to always succeed, since the old page tables still exist, so page table allocation should not happen.As a comment in move_page_tables() explains:/* * On error, move entries back from new area to old, * which will succeed since page tables still there, * and then proceed to unmap new area instead of old. */However, that does not hold in the following scenario, assuming that the architecture does not define HAVE_MOVE_PMD (which permits mremap() to move entire page tables):    move_vma() calls move_page_tables()    move_page_tables() moves an anonymous huge PMD entry.    move_page_tables() tries to move more page table entries, but page table allocation fails, and the function returns early.    Another racing process causes the huge PMD entry to be split via split_huge_page_to_list_to_order() (turning the huge PMD entry into a PMD entry pointing to a page table whose PTEs point to all the subpages).    move_vma() calls move_page_tables() in the reverse direction to move PTEs back.    move_page_tables() unexpectedly needs to allocate a new page table to move the PTEs generated by the huge PMD split, which again fails. PTEs are left behind in the destination area.    do_vmi_munmap() removes the temporary destination VMA and removes the left-behind PTEs in the destination area.So in the end, an anonymous page has erroneously disappeared from the VMA, but I think that doesn't lead to any major consequences.FWIW, the architectures that define HAVE_ARCH_TRANSPARENT_HUGEPAGE without also defining HAVE_MOVE_PMD are: mips, loongarch, s390, sparc64, arc, arm.I think similar things can probably also happen on x86/arm64 if, when moving PTEs back with move_pgt_entry(HPAGE_PMD, ...), we race with a concurrent split_huge_page_to_list_to_order() such that move_huge_pmd() fails at the __pmd_trans_huge_lock() and we fall back to the move_ptes() path.CommentsAll commentsja...@google.com <ja...@google.com> #2Oct 15, 2024 11:05AMThe fix for the security bug is currently in the MM tree at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?id=9118e3ff1212add463770537519dce4aed51cf94 , on the mm-hotfixes-unstable branch.ja...@google.com <ja...@google.com> #3Oct 22, 2024 09:28AMMarked as fixed, reassigned to ja...@google.com.Fix landed as https://git.kernel.org/linus/6fa1066fc5d00cb9f1b0e83b7ff6ef98d26ba2aa ("mm/mremap: fix move_normal_pmd/retract_page_tables race").In stable releases:    6.6.58 (2024-10-22)    6.11.5 (2024-10-22)Related CVE Number: CVE-2024-50066.Credit: Jann Horn

Linux 6.6 Race Condition

Nosebeard Labs has identified a critical vulnerability in the Apple system wide web content filter that allows a full bypass of content restrictions. This vulnerability, which occurs specifically when Screen Time content filtering settings are enabled, permits users or attackers to access restricted websites in Safari without detection. The timeline in this advisory is probably the most interesting thing to note. It shows a Fortune 10 ignoring a concern for years until a news article gets written, and that is truly disappointing. Do better Tim.

    Dear colleagues,Nosebeard Labs is pleased to share its latest advisory, detailing a bypass of Apple's system wide web content filter. The HTML version of this advisory is also available at:https://nosebeard.co/advisories/nbl-001.htmlWarmest regards,Nosebeard Labs## SummaryNosebeard Labs Security Advisory NBL-001Title: Apple web content filter bypass allows unrestricted access to blocked content (macOS/iOS/iPadOS/visionOS/watchOS)Advisory ID: NBL-001Date: 2024-11-15Severity: Critical (CVSS 9.1)Affected Product: Safari on any Apple device with Screen Time enabledCVE ID: CVE-2024-44206## OverviewNosebeard Labs has identified a critical vulnerability in Apple’s system wide web content filter that allows a full bypass of content restrictions. This vulnerability, which occurs specifically when Screen Time’s content filtering settings are enabled, permits users or attackers to access restricted websites in Safari without detection. By exploiting a misalignment between Screen Time’s Access Control List (ACL) and WebKit’s URI validation, a specially crafted URI can circumvent both layers of protection.Apple has assigned CVE-2024-44206 to this issue and issued a fix for macOS Sonoma 14.x, iOS/iPadOS 17.x, watchOS 10.x, visionOS 1.x, Safari 17.x and up.However, a fix is still pending for the backport channels.## DescriptionThis vulnerability arises when the WebKit Cocoa layer in Safari ingests a URI without performing comprehensive validation, combined with a failure by the Screen Time ACL filter to recognize and block the malformed URI. The flaw allows a crafted URI to bypass all Screen Time content filtering settings, including deny/allow lists and parental content filters, providing unrestricted access to blocked content.## Affected SystemsThis vulnerability affects all devices on macOS, iOS, iPadOS, watchOS and visionOS platforms with Safari and Screen Time enabled, impacting an estimated 250 million devices globally.## Attack ScenariosThe vulnerability can be exploited both locally and remotely:1. Local Exploitation: Users can manipulate the address bar to manually enter a crafted URI, bypassing Screen Time restrictions.2. Network-Based Exploitation: Attackers can load restricted content remotely by embedding a crafted URI within an iframe, bypassing restrictions without requiring user interaction.## Impact1. Confidentiality: Unrestricted access to restricted websites compromises the confidentiality of content filtering controls, potentially exposing sensitive or inappropriate material.2. Scope and Integrity: This vulnerability spans across two separate security mechanisms (Screen Time and WebKit), representing a critical architecture-level issue. Additionally, accessing unsecured or unlogged resources poses potential integrity risks.## CVSS ScoreVector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:NScore: 9.1 (Critical)## MitigationsUpgrade to the latest iOS/iPadOS 17.x or 18.x / macOS Sonoma 14.x  / visionOS 1.x / watchOS 10.x / Safari 17.6 respectively. Users who are unable to apply a fix can contact us for more info.## Vendor ResponseApple has issued CVE-2024-44206 and supplied a fix within WebKit; however, a fix remains pending for iOS/iPadOS version 16.x. We recommend that Apple undertake further review to address the issue comprehensively.## Timeline–Milestone:2020-11-24 Vulnerability discovered internally at NBL–Milestone:2021-03-08 Initial disclosure to Apple Product Security–2021-03-09 Apple Product Security recommends to open a bug report on Feedback Assistant2021-03-10 We opened a bug report on Feedback Assistant as advised by Apple Product Security2021-03-15 We follow-up by adding additional info to the open bug report on F.A.2021-08-16 We follow-up again referring Apple Product Security to open ticket, stressing that the issue can be also demonstrated in their EU Apple Stores2021-08-24 We follow-up again to Apple Product Security, referring to the previous follow-up2021-08-25 Rejected by Apple Security - “We do not see any actual security implications. We recommended reporting this issue via Feedback Assistant”2024-03-18 NBL submits a second report 3 years later to appeal via Apple Security Bounty Program, urging to re-evaluate, also providing PoC code2024-03-19 Apple Security Research closes report - “We’re unable to identify a security issue in your report” - “Screen Time is not intended to protect a device against manipulation” - “We recommend reporting this via Feedback Assistant”2024-04-02 Status of Bug Report on F.A. from 2021-03-10 “Open, Similar Reports None”2024-04-03 We follow-up again asking Apple Security for a final reassessment, providing a temporary workaround2024-04-03 Apple Security recommends opening a bug report - “ST is not intended to protect a device against manipulation” - “MDM profiles provide configuration management but do not establish additional security boundaries beyond what iOS and iPadOS have to offer.”2024-05-05 Initial contact with Joanna Stern of WSJ2024-05-06 Referring PSIRT ticket # directly to an Apple PSIRT contact via undisclosed SOC - no response2024-05-28 Joanna Stern/WSJ runs Apple through this2024-05-29 Apple commits patches to Safari branch–Milestone:2024-06-05 Wall Street Journal addresses our finding in their article “A Bug Allowed Kids to Visit X-Rated Sites. Apple Took Three Years to Fix It.” by Joanna Stern–2024-06-18 We follow-up again with Urgent request for re-evaluation to Apple Product Security (“Addendum”)2024-06-27 We follow-up on our follow-up Update Request Screen Time Security Vulnerability Report (“Follow-Up”)2024-07-23 Apple releases fix in iOS 17.6RC et al.2024-07-26 Letter to Apple welcoming first fix, reiterating our dedication to Responsible Disclosure, intended to coordinate further disclosure process and close the affair asking them to give credit and align to their SBP–Milestone:2024-07-29 Apple releases fixes for macOS Sonoma 14.6, iOS/iPadOS 17.6, watchOS 10.6, visionOS 1.3 and Safari 17.6, leaving iOS/iPadOS 16.x still affected.–2024-07-31 Apple responds “ST is not intended to protect a device from malicious manipulation, and bug reports on features like this are therefore typically ineligible for credit or Apple Security Bounty award. However, we’d like to make an exception and award you USD (...)* as a thank you for your report. Also, we’d like to credit you on our security advisory under the ‘Additional recognition’ section of the page.” *We were offered the minimum possible amount.2024-08-01 We inquire about the bounty amount asking Apple to “comment on our proposed evaluation under the CVSS metrics, sharing with us their transparent assessment of the vulnerability under the terms and broad criteria of the bounty program.”2024-08-01 Apple “appreciates our suggestions, but CVSS scores are not something that they publish to their security advisory.”2024-08-03 Patches merged with public WebKit branch2024-08-19 We are reaching out to Apple again “Ringing the escalation bell for the SBP team”2024-08-23 Apple Product Security advises a call2024-09-10 Apple Security rejects adjustment of the bounty as “out of scope/edge case policy” in the call, offering a $20,000 charity donation instead We request Apple to assign a CVE.–Milestone:2024-10-17 Apple follows-up with CVE-2024-44206 and an update to the advisorieshttps://support.apple.com/en-us/120909https://support.apple.com/en-us/120911https://support.apple.com/en-us/120913https://support.apple.com/en-us/120915https://support.apple.com/en-us/120916–2024-10-23 We follow-up one more time to request a further review of the severity and reward2024-11-02 NBL-001 advisory draft shared with Apple2024-11-14 Apple requests naming their charity offer among bounty payout details, leaving out further comments on the contents of the advisory itself.2024-11-15 NBL-001 published## ContactFor more information, please contact Andreas Jaegersberger or Ro Achterberg from Nosebeard Labs at labs@nosebeard.co.## Special ThanksMuch love goes out to Joanna Stern for her incredible support in making this happen.We also want to thank Aaron Kaplan for the tailwind throughout the journey and Arnoud Engelfriet for the rapid legal advice.Buongiorno to the cap’n <3

Apple Web Content Filter Bypass

Apple Security Advisory 11-19-2024-4 - iOS 17.7.2 and iPadOS 17.7.2 addresses code execution vulnerabilities.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256APPLE-SA-11-19-2024-4 iOS 17.7.2 and iPadOS 17.7.2iOS 17.7.2 and iPadOS 17.7.2 addresses the following issues.Information about the security content is also available athttps://support.apple.com/121754.Apple maintains a Security Releases page athttps://support.apple.com/100100 which lists recentsoftware updates with security advisories.JavaScriptCoreAvailable for: iPhone XS and later, iPad Pro 13-inch, iPad Pro 12.9-inch2nd generation and later, iPad Pro 10.5-inch, iPad Pro 11-inch 1stgeneration and later, iPad Air 3rd generation and later, iPad 6thgeneration and later, and iPad mini 5th generation and laterImpact: Processing maliciously crafted web content may lead to arbitrarycode execution. Apple is aware of a report that this issue may have beenactively exploited on Intel-based Mac systems.Description: The issue was addressed with improved checks.WebKit Bugzilla: 283063CVE-2024-44308: Clément Lecigne and Benoît Sevens of Google's ThreatAnalysis GroupWebKitAvailable for: iPhone XS and later, iPad Pro 13-inch, iPad Pro 12.9-inch2nd generation and later, iPad Pro 10.5-inch, iPad Pro 11-inch 1stgeneration and later, iPad Air 3rd generation and later, iPad 6thgeneration and later, and iPad mini 5th generation and laterImpact: Processing maliciously crafted web content may lead to a crosssite scripting attack. Apple is aware of a report that this issue mayhave been actively exploited on Intel-based Mac systems.Description: A cookie management issue was addressed with improved statemanagement.WebKit Bugzilla: 283095CVE-2024-44309: Clément Lecigne and Benoît Sevens of Google's ThreatAnalysis GroupThis update is available through iTunes and Software Update on youriOS device, and will not appear in your computer's Software Updateapplication, or in the Apple Downloads site. Make sure you have anInternet connection and have installed the latest version of iTunesfrom https://www.apple.com/itunes/iTunes and Software Update on the device will automatically checkApple's update server on its weekly schedule. When an update isdetected, it is downloaded and the option to be installed ispresented to the user when the iOS device is docked. We recommendapplying the update immediately if possible. SelectingDon't Install will present the option the next time you connectyour iOS device.The automatic update process may take up to a week depending onthe day that iTunes or the device checks for updates. You maymanually obtain the update via the Check for Updates buttonwithin iTunes, or the Software Update on your device.To check that the iPhone, iPod touch, or iPad has been updated:* Navigate to Settings* Select General* Select About. The version after applying this update will be"iOS 17.7.2 and iPadOS 17.7.2".All information is also posted on the Apple Security Releasesweb site: https://support.apple.com/100100.This message is signed with Apple's Product Security PGP key,and details are available at:https://www.apple.com/support/security/pgp/-----BEGIN PGP SIGNATURE-----iQIzBAEBCAAdFiEEsz9altA7uTI+rE/qX+5d1TXaIvoFAmc9JGcACgkQX+5d1TXaIvqaMhAArOKmA61hgLNGofjznuKQo6Jc42iPl7a/ZiB2Tq5ynZKPIGmGiM3HdJQ8bbifOgpkmNcA3h1OUlXnnkbdehq6d8MzI9WSn6uHdgWZ5LqLMXOWgsEF5Hwwmm7zaqTaqMv4fV2J6w2wTcoL5XptxGXiEi37/GzcureD3hvL+nRAAzR6c/gRXmcEjGL7pVTNJA0C8VyY9kG+Uc7ia2m5Riux2jsYzWYppPfCwUFeo3bQDexG7WsiHa00OZN+HkNS5/1t/7hftJZ+w/PbVnEK23Dm962NQgCrcFKGnbjNGJQlIjl+xfbi6BuQ6lJJZAI+3WqPHXLAMCcae/DfERqXWnJu8fTMfCwCbQVx185Cih+mtH0oc4MtPtiZdhi8TxZpVGZHYjLJa9VANTrNzkAmFflnhAC4tAG2FXx3ld3t/8u9Fhv0oyTa5HlzVYJ/WJgK32eT7I1h7Oqrp49KZcMIM8H6ZwNXYOI+Rf7GXdEN2y9Qhb+IOvdilTrCTpzRl6Gu6fBwH0G0UGHRktnBPlryJdOg26J1iVBZg6/K/CSjQizWdDXN/Nq4YwI17Eq4HtFdtOtrs5n0bDz+fsfGbsieTyUz1BUet2xLzPECfD4nYEKmckD1d/dRylc3vK9YGOCp1nWDoPSKnmkU9Il2SFAIuEM9o60lCN7PMWBrC9zYXMAxFmY==+VKC-----END PGP SIGNATURE-----

Apple Security Advisory 11-19-2024-4

Apple Security Advisory 11-19-2024-3 - iOS 18.1.1 and iPadOS 18.1.1 addresses code execution vulnerabilities.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256APPLE-SA-11-19-2024-3 iOS 18.1.1 and iPadOS 18.1.1iOS 18.1.1 and iPadOS 18.1.1 addresses the following issues.Information about the security content is also available athttps://support.apple.com/121752.Apple maintains a Security Releases page athttps://support.apple.com/100100 which lists recentsoftware updates with security advisories.JavaScriptCoreAvailable for: iPhone XS and later, iPad Pro 13-inch, iPad Pro 12.9-inch3rd generation and later, iPad Pro 11-inch 1st generation and later,iPad Air 3rd generation and later, iPad 7th generation and later, andiPad mini 5th generation and laterImpact: Processing maliciously crafted web content may lead to arbitrarycode execution. Apple is aware of a report that this issue may have beenactively exploited on Intel-based Mac systems.Description: The issue was addressed with improved checks.WebKit Bugzilla: 283063CVE-2024-44308: Clément Lecigne and Benoît Sevens of Google's ThreatAnalysis GroupWebKitAvailable for: iPhone XS and later, iPad Pro 13-inch, iPad Pro 12.9-inch3rd generation and later, iPad Pro 11-inch 1st generation and later,iPad Air 3rd generation and later, iPad 7th generation and later, andiPad mini 5th generation and laterImpact: Processing maliciously crafted web content may lead to a crosssite scripting attack. Apple is aware of a report that this issue mayhave been actively exploited on Intel-based Mac systems.Description: A cookie management issue was addressed with improved statemanagement.WebKit Bugzilla: 283095CVE-2024-44309: Clément Lecigne and Benoît Sevens of Google's ThreatAnalysis GroupThis update is available through iTunes and Software Update on youriOS device, and will not appear in your computer's Software Updateapplication, or in the Apple Downloads site. Make sure you have anInternet connection and have installed the latest version of iTunesfrom https://www.apple.com/itunes/iTunes and Software Update on the device will automatically checkApple's update server on its weekly schedule. When an update isdetected, it is downloaded and the option to be installed ispresented to the user when the iOS device is docked. We recommendapplying the update immediately if possible. SelectingDon't Install will present the option the next time you connectyour iOS device.The automatic update process may take up to a week depending onthe day that iTunes or the device checks for updates. You maymanually obtain the update via the Check for Updates buttonwithin iTunes, or the Software Update on your device.To check that the iPhone, iPod touch, or iPad has been updated:* Navigate to Settings* Select General* Select About. The version after applying this update will be"iOS 18.1.1 and iPadOS 18.1.1".All information is also posted on the Apple Security Releasesweb site: https://support.apple.com/100100.This message is signed with Apple's Product Security PGP key,and details are available at:https://www.apple.com/support/security/pgp/-----BEGIN PGP SIGNATURE-----iQIzBAEBCAAdFiEEsz9altA7uTI+rE/qX+5d1TXaIvoFAmc9JA8ACgkQX+5d1TXaIvrGzw/+PXf2fGgzCN5of6OYK0sWiJRRLZoL0uSZ9dOaD7I0/CyAx91Mv4OyH9Vveo9k84ZABNk4IO401WWLM8XSRSVILTcskT+SdXZrtOMYvmtUHUPKI35OWf1GBFdkgfnnFSRYf/B+WWb4PV0iO01lyFQVU5qDLcrUCAUQLwighfAX2yEn+Zml3NX6i2E5o2Rhc93Nac5a2cIcOGOSKrwsor0sh8NkAl9DcyPW6i6K3t59lUjiUY9XZQtEi6AyrChA84mo6Hb8wLwVIY17b8LVuruOSn3xg+Cc5eO5bOXp1O5lnR3dhuiZ2bl5BKawrp8+MDRsBZuTPS0k2Di3rmzuZ/GnvaQdtQKhcbOQ7tWW6evk/8TnFwlULaCr26OVbuLj0NWJ7GJYWpPuRWO0lFy9z9Fjdk4n+ptA7qmSWrhbdl+/uwUxJA5X58pVRWeWBExGP3S/ST/5YgAfZXBjHuDLiHKMOtQ3PktaMuEWhLFgGXNllXGQDihL4lS/XUQ1/E+mpWyY+kAbjtmCYlpez5MgeLkVv66yEWhOhsBMNIM+jkkRjktJo2SfhJMSryNLQlY37zn/VWf8Av+L60YoZhoMmx7DJLIr+HI257zbIE35CVZ+badn18d3eA+fq3RPtsDD8nlUePyZeNhEvc30Y5hXsIyK+Z0Ny+JgJfP1E6BeAJjjci0==ifwz-----END PGP SIGNATURE-----

Apple Security Advisory 11-19-2024-3

PRESS RELEASE

TEMPE, Ariz. and PRAGUE, Nov. 21, 2024 /PRNewswire/ -- Norton, a leading Cyber Safety brand of Gen™ (NASDAQ: GEN), has launched the new Norton Small Business Premium, an all-in-one, easy-to-use cybersecurity plan specifically designed for entrepreneurs and small businesses. In addition to powerful device security, Norton Small Business Premium features 24/7 Business Tech Support, Financial Monitoring, Social Media Monitoring and more.

"More than half (56%)\* of small business owners report that cybersecurity threats impact their business. Unfortunately, not enough of these entrepreneurs and small businesses have cybersecurity in place, often due to their cost and complexity," said Leena Elias, Chief Product Officer at Gen. "Norton Small Business Premium not only takes the work out of securing your business, we also help when other IT issues crop up."

Cybersecurity is crucial for businesses to protect their sensitive data, networks, and digital assets from cyberthreats that can lead to unauthorized access to company networks, data breaches, financial losses, and reputation damage. To help protect businesses where they need it most, Norton Small Business Premium includes features such as:

*   24/7 Business Tech Support: Subscriptions include access to Norton experts five time as year. These experts are available 24/7 for remote IT support on your devices, network, and software.
    
*   Financial Monitoring: Get alerts so you can act quickly if we detect suspicious transactions on your company's bank accounts.   
    
*   Social Media Monitoring: Prevent your business social media profiles from being taken over by regularly monitoring for suspicious activities on your accounts. 
    
*   Device Security: Real-time antivirus helps protect your devices, and our firewall\* helps block cybercriminals from accessing your network.
    
*   Secure VPN: Work online and access websites more safely at home or on the go with bank-grade VPN encryption.
    
*   Additional features include Password Manager, Cloud Backup, performance enhancements and more.
    

Norton Small Business Premium doesn't require an IT specialist or cybersecurity knowledge to use. It's easy to install and runs seamlessly in the background on Windows, Mac, Android, and iOS, allowing you to focus on your business without slowing down operations. 

Norton recommends 10 tips for small business Cyber Safety: 

1.  Learn to spot signs of phishing and teach your employees
    
2.  Only click links or download attachments from known sources
    
3.  Avoid sharing personal information or private company data over email
    
4.  Always keep your operating system, applications, and drivers up-to-date
    
5.  Make sure your WiFi network is protected with a strong password
    
6.  Regularly back up your data
    
7.  Require employees to use a VPN when doing company work on a public WiFi network (think airports and coffee shops)
    
8.  Always use multi-factor-authentication for an extra layer of protection
    
9.  Don't neglect mobile devices – make sure they are password protected and use security software
    
10.  Invest in a cybersecurity solution such as Norton Small Business Premium
    

Norton Small Business Premium is available now with prices starting at $299.99/year with options for 6, 10 or 20-device plans. For more information, please visit norton.com/products/small-business.

About Norton   
Norton is a leading Cyber Safety brand of Gen™ (NASDAQ: GEN), a global company dedicated to powering Digital Freedom through its family of trusted consumer brands including Norton, Avast, LifeLock, Avira, AVG, ReputationDefender and CCleaner. Gen empowers people to live their digital lives safely, privately, and confidently today and for generations to come. Gen brings award-winning products and services in cybersecurity, online privacy and identity protection to more than 500 million users in more than 150 countries. Learn more at Norton.com and GenDigital.com.

You May Also Like

Norton Introduces Small Business Premium for Business-Grade Security

The future of cybersecurity isn't about preventing every breach — it's about learning and growing stronger with each attack.

Akhil Mittal, Senior Manager, Black Duck Software

November 21, 2024

6 Min Read

Source: Brain light via Alamy Stock Photo

COMMENTARY

Despite massive investments in cybersecurity, breaches are still on the rise, and attackers seem to evolve faster than defenses can keep up. The IBM "Cost of a Data Breach Report 2024" estimates the average global breach cost has reached a staggering $4.88 million. But the true damage goes beyond the financial — it's about how quickly your organization can recover and grow stronger. Focusing only on prevention is outdated. It's time to shift the mindset: Every breach is an opportunity to innovate. 

**Turning Breaches Into Opportunities**

Breaches are no longer theoretical. They're happening right now — AI-powered hacks, supply chain vulnerabilities, and social engineering make them inevitable. IBM's report shows that 83% of organizations faced multiple breaches last year. One retail client I worked with had the same mindset: focusing on prevention and detection alone. But after facing multiple breaches, the company flipped its approach — each breach became a learning opportunity. Instead of panic, the company built resilience.

**Strengthening Defenses After Each Breach**

Organizations need to shift from asking, "How do we stop breaches?" to "How do we get stronger from breaches?" Here are five strategies that I've seen make a significant impact: 

**1\. From Breach to Micro-Incident **

Not every breach needs to be a disaster. By treating breaches as micro-incidents, you can contain the damage and quickly move forward. With network segmentation and behavioral analytics, threats can be isolated and stopped from spreading. One financial client cut its recovery time by 50% by adopting self-isolating networks. When suspicious activity was detected, the network kicked into action, isolating the threat and stopping its spread. 

**2\. Stress Test Daily **

Running breach simulations once or twice a year is no longer enough. Leading organizations are stress-testing their defenses daily. This goes beyond testing — it's about actively rehearsing for real-world scenarios, ensuring your teams are battle-ready. Think of it like chaos engineering: You aren't just hoping for the best. You're deliberately looking for weaknesses so you can fix them before attackers find them. This approach helped another client find multiple weak points that were missed in its regular annual penetration tests. 

**3\. Minimize Human Intervention **

When a breach hits, speed is everything. Self-healing systems powered by AI automatically isolate compromised systems and begin repairs without the need for human intervention. One of my e-commerce clients cut its recovery time in half with self-healing technology. Its teams could stop putting out fires and focus on strategic long-term improvements. 

**4\. Adaptive Defense **

Every breach is an opportunity to learn and improve. One of the financial clients created a feedback loop that used AI-powered systems to analyze each breach. Machine learning models adapted defenses, spotting patterns in the attacks, adjusting firewall rules, and fine-tuning detection algorithms. Gartner predicts that by 2026, 30% of enterprises will automate more than half of their network activities, using AI to detect and respond to threats in minutes. 

**5\. Collective Defense **

No one fights cyber threats alone. A healthcare consortium I know began sharing real-time threat intelligence with other organizations. This collective defense approach helped it detect and stop attacks faster. Participating in networks like Information Sharing and Analysis Centers (ISACs) or using platforms like MITRE ATT&CK can boost defenses across industries by pooling insights and data. 

**Cybersecurity as a Competitive Advantage**

Resilience is the new competitive advantage. You can't prevent every breach, but how quickly you respond is what sets you apart. Accenture found that 87% of consumers trust companies that handle breaches with transparency and resilience. It's not the breach itself that builds trust, of course — it's how you respond. 

In industries like finance, healthcare, and technology, resilience not only helps you recover but also fosters customer loyalty. As cyber threats become more global, regulations like GDPR in Europe demand fast, transparent responses. In the Asia-Pacific region, rapid digital transformation is creating new attack surfaces. Wherever your business operates, resilience is key to success.

**Actionable Steps for CISOs**

Here's how chief information security officers (CISOs) can turn breaches into growth opportunities: 

*   Run continuous breach simulations: Make breach simulations part of your daily routine. Simulate phishing, ransomware, and supply chain attacks to identify vulnerabilities before real attackers exploit them. Leading companies, inspired by chaos engineering, run controlled breach tests every day, treating each one as an opportunity to fine-tune their incident response plans. 
    
*   Adopt self-healing systems: AI-powered self-healing systems minimize downtime by automatically detecting and isolating compromised systems, ensuring your business keeps running. With 24/7 monitoring tools, you can spot unusual behavior fast, allowing your teams to focus on strategic initiatives instead of reactive firefighting. 
    
*   Leverage AI-driven threat intelligence sharing: Join intelligence-sharing networks like ISACs to collaborate with peers. Real-time threat data allows organizations to stay ahead of emerging threats. Platforms like MITRE ATT&CK help teams analyze adversary behaviors, enabling them to fine-tune defense strategies. 
    
*   Prepare for quantum computing: While quantum computing is still emerging, it could eventually break today's encryption standards. Start preparing now by researching quantum-resistant encryption and staying informed on the latest industry developments. 
    
*   Create a resilience-first culture: Resilience shouldn't just be a buzzword — it must become part of your company's DNA. Encourage your teams to learn from every incident, find gaps in your defenses, and use them as opportunities to build stronger systems. Regularly debrief after breaches to reflect on what went right, not just what went wrong. This helps create a culture of continuous improvement, ensuring that your organization gets stronger after every incident. 
    

Resilience isn't just the CISO's job. CEOs and compliance officers also play crucial roles in aligning the entire organization with resilience strategies. Regulatory frameworks like Europe's General Data Protection Regulation (GDPR) and the US Portability and Accountability Act (HIPAA) demand transparent recovery protocols, and how leadership handles breaches impacts brand trust, shareholder confidence, and customer loyalty.

**Leading With Resilience**

The future of cybersecurity isn't about preventing every breach — it's about learning and growing stronger with each attack. Companies that turn breaches into opportunities for innovation won't just survive — they'll lead. By adopting resilience-first strategies, continuous improvement, and adaptive defenses, your organization can turn security challenges into competitive advantages. 

**About the Author**

Senior Manager, Black Duck Software

Akhil Mittal is a recognized cybersecurity leader with more than two decades of experience in application security, cloud security, and DevSecOps. As a Gartner Cybersecurity ambassador and senior manager at Black Duck Software, he leads key security initiatives, helping global organizations strengthen their defenses against advanced cyber threats. Akhil has worked closely with chief information security officers (CISOs) and executive leadership to align security strategies with business goals, ensuring robust protection across industries. He also contributes his expertise through leading cybersecurity publications and serves as a judge for top industry awards and hackathons. Certified in CISSP and CCSP, his work continues to shape the future of cybersecurity, driving innovation and resilience worldwide.

Cybersecurity Is Critical, but Breaches Don't Have to Be Disasters

Forces Penpals, a social network for US and UK military personnel, exposed the sensitive data of 1.1M users,…

Forces Penpals, a social network for US and UK military personnel, exposed the sensitive data of 1.1M users, including SSNs, personal details, and proof of service. Learn about the incident and its possible impact.

Forces Penpals, a dating service and social network for members of the US and UK armed forces and their supporters since 2002, was found leaking personal details of over 1.1 million registered users.

This issue was identified by Jeremiah Fowler, a prominent cybersecurity researcher recognized for uncovering and advising on securing **misconfigured cloud servers** and databases.

According to Fowler’s **report** for VPNmentor, shared with Hackread.com ahead of its publication on November 20, 2024, the data belonged to Conduitor Limited, which publicly trades as Forces Penpals.

****The Exposed Data****

The analysis revealed that the leaked information included both Personally Identifiable Information (PII) and sensitive images. Additionally, the exposed data contained Social Security Numbers (SSNs) of unsuspecting users. This echoes the August 6, 2024, breach at National Public Data, where a hacker leaked 3.6 billion records from users in the USA, Canada, and the UK, which also included billions of SSNs.

In the case of Forces Penpals, the server exposed the following data:

*   **Images**
*   **Locations**
*   **Full names**
*   **Mailing addresses**
*   **Social Security Numbers**
*   **National Insurance Numbers (Similar to SSN in the UK).**

Fowler noted that the server also contained additional data that should not have been exposed. This included documents such as proof of service, military ranks, the branch of service the individual belongs to, and other sensitive details.

> _“The publicly exposed database was not password-protected or encrypted. It contained a total of 1,187,296 documents. In a limited sampling, a majority of the documents I saw were user images, while others were photos of potentially sensitive proof of service documents.”_  
> 
> Jeremiah Fowler

Screenshot from the exposed data (Screenshot via VPNmentor)

****Current Status****

Forces Penpals has acknowledged the breach, attributing it to a coding error that misdirected documents and left a directory listing publicly accessible. The company has since taken steps to secure the database.

However, it is still unclear whether any malicious actors accessed the exposed information. Forces Penpals has yet to disclose the duration of the exposure or report any signs of suspicious activity.

It is also unclear whether the data was leaked through the website or the company’s iOS and Android apps. Nevertheless, this incident is a reminder for similar services to focus on data security and safeguard their users’ privacy from growing cyber threats.

1.  **Data Leak Exposes Indian Police, Military Biometric Data**
2.  **US military personnel defrauded into losing $822m in scams**
3.  **British Military’s Twitter and YouTube Hacked in Crypto Scam**
4.  **US Military Targeted by Smartwatches Linked to Data Breaches**
5.  **Misconfigured AWS Buckets Expose US Military Spying Campaign**

US and UK Military Social Network “Forces Penpals” Exposes SSN, PII Data

Though the information regarding the exploits is limited, the company did report that Intel-based Mac systems have been targeted by cybercriminals looking to exploit CVE-2024-44308 and CVE-2024-44309.

Source: Shahid Jamil via Alamy Stock Photo

Apple has released security updates to address two zero-day vulnerabilities that are under active exploitation in the wild.

The bugs, tracked as CVE-2024-44308 (CVSS 6.8) and CVE-2024-44309 (CVSS 4.3), are, respectively, a vulnerability in JavaScriptCore that could lead to arbitrary code execution; and a cookie management vulnerability in WebKit that could lead to a cross-site scripting (XSS) attack while processing malicious Web content.

The bugs affect Apple's iOS, iPadOS, macOS, visionOS, and the Safari Web browser; the company reports that it has addressed them with better checks and improved state management.

Clément Lecigne and Benoît Sevens at Google's Threat Analysis Group (TAG) first discovered and reported the vulnerabilities and, as is customary for the company, Apple did not provide any additional details of reported attacks nor did it offer indicators of compromise (IoCs).

"Apple is aware of a report that this issue may have been actively exploited on Intel-based Mac systems," Apple stated its advisory for both zero-days, the lone piece of information regarding in-the-wild exploitation attempts.

Those using affected Apple ecosystem products should update to iOS 18.1.1, macOS Sequoia 15.1.1, and  iOS 17.7.2 as soon as possible to avoid compromise.

**About the Author**

Apple Urgently Patches Actively Exploited Zero-Days

People are receiving disturbing emails that appear to imply something has happened to their friend or family member.

Tech support scammers are again stooping low with their email campaigns. This particular one hints that one of your contacts may have met an untimely end.

It all starts with an email titled “Sad announcement” followed by a full name of someone you know. The email may appear to come from the person themselves.

A co-worker who received such an email pointed it out to our team. Looking around, I found the first report about such an email in a tweet dating back to February 5, 2024.

With some more information about what I was looking for, I managed to find several more.

There is a great deal of variation between the emails, but we do have enough samples to show you a pattern which looks like this:

Subject: Sad announcement: <First name><Last name>

Sometimes the colon is replaced by the word “from”.

Then a short sentence to pique the reader’s curiosity, which often references photos. Here are some examples:

> “When you open them you will see why I actually wanted to share them with you today”
> 
> “Never thought I would want to share these images with you, anyways here they are”
> 
> “I’m presuming you should remember these two ladies, in that photo”
> 
> “When I was looking through some old folders I found these 3 pics”
> 
> “it wasn’t initially my plan, but I had to change my mind about it”
> 
> “Two pictures that I wanted to share with you. They’re likely to bring a flood of memories to you, as they did to me…”
> 
> “Probably should have contacted you a little bit earlier. Anyways just wanted to keep you updated”

This is then immediately followed by a link. These also follow a certain pattern:

gjsqr.hytsiysx.com

tmdlod.vdicedohf.com

gtfhq.rmldxkff.com

pdbh.ramahteen.com

owwiu.dexfyerd.com

roix.unrgagceso.com

yrlbi.vohdsniuz.com

uqjk.mbafwnds.com

vjdbd.hhesdeh.com

mbjzo.enexoo.com

These domains are all registered with NameCheap and are only active for a few days.

To close the emails off, the scammers end with a quote in the format:

> “You do not find the happy life. You make it.” –  Camilla Eyring Kimball

The sender addresses are spoofed to look like they were coming from family or friends of the target. The actual sender addresses are compromised accounts from all over the world.

The campaign looks to have targeted mainly the US, but I also found some located in Ireland and the UK and some odd ones in India and Italy.

So, the question is, what are they after? The short-lived domains really made it hard for me to figure that out. It took me quite a bit to find a domain that was still active, but then I knew soon enough what the end-goal of the spammers was.

A short chain of redirects sent me to https://niceandsafetystore0990.blob.core.windows[.]net/niceandsafetystore0990/index.html which is now blocked by Malwarebytes Browser Guard.

The blob.core.windows.net subdomains are unique identifiers for Azure Blob Storage accounts. They follow this format:

<storageaccountname>.blob.core.windows.net

Where <storageaccountname> is the name of the specific Azure Storage account. Spammers like using them because the windows.net part of the domain makes them look trustworthy.

The website itself probably looks familiar to a lot of readers: A fake online Windows Defender scan.

The fake Windows Defender site shows that your system is infected with loads of threats.

Funny enough the site claims to be Windows Defender, but uses Malwarebytes’ detection names. For example: Microsoft does not detect the Potentially Unwanted Program which Malwarebytes detects as PUP.Optional.RelevantKnowledge.

Anyway, the website quickly takes up the entire screen, so you have to click or hold (depending on your browser) the ESC button to get back the controls that allow you to close the website.

Now that you have seen the patterns in the email, we hope that you will refrain from clicking the links. The redirect chain can be changed and may be different for your location and type of system. So, there may be more serious consequences than an annoying website.

**How to avoid the “sad announcement” scam**

*   Always compare the actual sender address with the email address this person would normally use to send you an email.
*   Never click on link in an unsolicited email before checking with the sender.
*   Don’t call the phone numbers displayed on the website, because they will try to defraud you.
*   If in doubt, contact your friend via another, trusted method

If your browser or mobile device “locks up”, meaning you’re no longer able to navigate away from a virus warning, you’re likely looking at a tech support scam. If something claims to show the files and folders from inside of your browser, this is another signal that you’re on a fake page. Close the browser if possible or restart your device if this doesn’t work.

Despite the occasional arrests and FTC fines for tech support scammers and their henchmen, there are still plenty of cybercriminals active in this field. Scams range from unsolicited calls offering help with your “infected” computer to fully-fledged websites where you can purchase heavily over-priced versions of legitimate security software.

Unfortunately for some people these warnings may have come too late. So what should you do if you have fallen victim to a tech support scam? Here are a few pointers:

*   Have you already paid? Contact your credit card company or bank and let them know what’s happened. You may also need to file a complaint with the FTC or contact your local law enforcement agency, depending on your region.
*   If you’ve shared your password with a scammer, change it on every account that uses this password. Consider using a password manager and enable 2FA for important accounts.
*   Scan your device. If scammers have had access to your system, they may have planted a backdoor so they can revisit whenever they feel like it. Malwarebytes can remove backdoors and other software left behind by scammers.
*   Keep an eye out for unexpected payments. Be on the lookout for suspicious charges/payments on your credit cards and bank accounts so you can revert and stop them.

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

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

Tag

#ios