**DENVER****,** **April 20, 2023** **/PRNewswire/ --** Red Canary, a leader in managed detection and response, launched Red Canary Readiness, a new portfolio of offerings that gives teams a whole new way to train and prepare for incidents. Now any company can improve their incident response preparedness by empowering their security teams to practice and validate the skills, processes, and playbooks required to quickly respond to cyber and business continuity threats.

The initial Readiness product is Readiness Exercises, a first-of-its-kind continuous learning platform that combines training, tabletops, and atomic tests in one experience. With Readiness Exercises available today, cybersecurity professionals get on-demand content and expert training at their fingertips, making it easy for companies to skill up employees, no matter where they are.

**Enterprises must maintain a skilled and ready workforce to face today's top cybersecurity threats**

Adversaries are becoming faster and more efficient at distributing and scaling cyberattacks. Rather than infrequent and one-size-fits-all training, continuous learning is critical to keep pace with the evolving threat landscape.

Readiness scenarios are ripped from the headlines and informed by Red Canary's leading threat intelligence and adversary research from its Managed Detection and Response (MDR) solution, which conducts millions of investigations per year. This expertise is mapped to industry-standard frameworks, such as NIST and MITRE ATT&CK®, to ensure teams are practicing the most critical scenarios. Training can be self-guided or facilitated, ranging from 20 minutes to 2 hours, and prepares teams to face incidents involving business email compromise, ransomware, and other threats including Qbot and Raspberry Robin.

"We have previously invested in cybersecurity training but have had mixed results. The exercises don't always relate to the threats that matter most to us, and the lessons are infrequent and don't always stick," said Michael Strong, Chief Security Officer, GCI. "This is why we are so excited about Readiness Exercises. Now our team can continuously train and benchmark our progress, learning from the Red Canary team who respond to real-world threats daily. It gives me confidence knowing that we're better prepared for the next threat that comes our way."

"Just having an incident response plan and a set of playbooks is no longer enough. That plan and those playbooks must be put to the test regularly and refined to keep up with evolving threats," wrote Jess Burn, Sr. Analyst, Forrester in an April 2022 blog post.

Readiness Exercises foster continuous learning, which drives both employee and business success through:

*   **Continuously improving your readiness:** Benchmark current skill levels against industry standards through frequent feedback and scoring. Onboard new team members and establish a culture of consistent skill improvement.
*   **Training for real-world threats:** Continuously practice and validate team preparedness against realistic scenarios based on trending adversary groups, tools, and MITRE ATT&CK® techniques.
*   **Get training, tabletops, and atomic tests in one experience:** Bring together disparate learning tools and run them in your environment to maximize their relevance and impact.

"We're excited to announce the launch of Readiness Exercises, a comprehensive solution that combines tabletop exercises, cybersecurity training, and atomic testing into a seamless, continuous learning experience," said Brian Beyer, CEO of Red Canary. "With this innovative product, we're reinventing the way organizations approach cybersecurity training and prepare for real-world threats."

**Learn more**

*   Learn more about Readiness
*   Watch the Readiness Exercises video
*   Register for the Readiness webinar

**Availability** 

Red Canary Readiness launched today, with Red Canary Readiness Exercises generally available now.

**About Red Canary**

Red Canary is a leader in managed detection and response (MDR). We serve companies of every size and industry, focusing on finding and stopping threats before they can have a negative impact. As the security ally for nearly 1,000 organizations, we provide MDR across our customers' cloud workloads, identities, SaaS applications, networks, and endpoints. For more information about Red Canary, visit: https://www.redcanary.com.

SOURCE Red Canary

Red Canary Announces Readiness

Heading to San Francisco next week? Here are all the Talos and Cisco Secure talks and events you won't want to miss.

Thursday, April 20, 2023 14:04

Welcome to this week’s edition of the Threat Source newsletter.

We’re firing up the conference circuit again for 2023, kicking things off next week with the RSA Conference in San Francisco. Cisco has a ton of exciting announcements, keynotes and talks lined up for the week, but there are also plenty of Talos-focused events to take in.

We’ll be at our own booth giving “flash talks” throughout the conference and will generally be around to answer questions about Talos, provide service demos and talk about the latest security offerings from Cisco. In case you’re having a hard time finding the Cisco booth, use RSA’s map here. The main Talos team will be at North Expo N-5845 and Cisco Talos Incident Response will be at South Expo S-1027.

Here are some of the other major events at RSA that we’re taking part in.

*   Brad Garnett, the head of Cisco Talos Incident Response, is joining the Cisco Secure Security Stories podcast for a live recording on Tuesday the 25th at 11 a.m. PT inside the Customer Lounge at the Marriott Marquis. Head up to the fifth floor and look for the Sierra K room! Brad will be discussing the latest trends and attacker TTPs his team is seeing in the field.
*   Cisco has a special sponsored talk on Wednesday the 26th from 9:40 – 10:30 a.m. PT with Nick Biasini, the head of Talos Outreach, and AJ Shipley, Cisco Secure’s vice president of product management for threat, detection and response. This session will analyze why industry partnerships are a must for security to win. Come meet A.J. and Nick in the Moscone South building, or if you can’t make it, a recording will be available for RSA attendees.
*   There will be two live Beers with Talos episodes on the 26th at 2 p.m. PT and the 27th at 9 a.m. PT. Join the BWT gang for gameshows, security hot takes and general debauchery. Both recording sessions will be in the Customer Lounge.
*   If you want a chance to meet the BWT hosts and some other special Talos guest, join us in the Customer Lounge on Wednesday at 4 p.m. PT for a meet-and-greet and networking session. This is an open session with Talos experts, Beers with Talos and members of the Cisco CISO Advisory panel.
*   The latest episode of ThreatWise TV from (now Talos’ own!) Hazel Burton also has a rundown of everything you can expect from Cisco and Talos at RSA. You can also read Cisco’s preview blog post here.

**The one big thing**

The UK’s National Cyber Security Center (NCSC) released a report this week on a sustained campaign by a Russian intelligence agency targeting a vulnerability in routers that Cisco published a patch for in 2017. This campaign, dubbed "Jaguar Tooth," is an example of a much broader trend of sophisticated adversaries targeting networking infrastructure to advance espionage objectives or pre-position for future destructive activity. While infrastructure of all types has been observed under attack, attackers have been particularly successful in compromising infrastructure with out-of-date software.

**Why do I care?**

In short, there are extremely sophisticated actors who are increasingly targeting network infrastructure devices from a variety of manufacturers. Talos and Cisco are concerned that insufficient awareness and patching, the reliance on end-of-life equipment and the necessity for always-on connectivity makes too many infrastructure devices easy prey. The results of these issues range from being an unwitting participant in criminal activity to events of true national security impact.

**So now what?**

Relying on out-of-date gear or utilizing out-of-date protocols and technologies will eventually cost your organization. Work with your vendor to give yourself the best chance of defending your environment. Talos’ blog also has a series of recommendations for defending and updating aging network infrastructure. For the specific Jaguar Tooth campaign, users who haven’t already should patch affected devices immediately.

**Top security headlines of the week**

**A 21-year-old was arrested for allegedly leaking sensitive Pentagon and Department of Defense documents and images on a Discord server.** The images eventually made their way onto other popular social media platforms in the public eye. The U.S. military is increasingly relying on Discord and other emerging social platforms for recruitment but has become a popular place for leakers to share secrets and other sensitive information. One of the other users on the Discord server where the most recent slate of images was leaked said the alleged leaker wanted to make sure “we know what’s going on with our tax dollars,” though the user who spoke to CNN was only 17 years old.  A 2021 report from the U.S. House of Representatives found that user moderation on platforms like Discord is not enough to prevent leaks, saying “the risks of relying too much on user moderation when the userbase may not have an interest in reporting problematic content.” (Washington Post, Slate, CNN)

The U.S. Cybersecurity and Infrastructure Security Agency **released new guidance for software manufacturers to adopt secure-by-design principles** and make the software more secure from the start of its lifecycle rather than being tacked on as later patches. Some of the major recommendations include having companies take ownership of the security implications of their products, embracing “radical transparency” toward security issues and ensuring there is support from company leadership to prioritize product security.  Other federal agencies from Australia, Canada, the United Kingdom, Germany, Netherlands and New Zealand published similar guidelines. (FedScoop, CISA)

**Montana is set to be the first U.S. state to ban downloads of the popular social media app TikTok,** citing security and data privacy concerns related to the app’s Chinese owners. The bill, which is set to be signed into law soon, is likely to spark a Constitutional debate around First Amendment freedom of speech protections and national digital privacy law. The state is likely to also face technical challenges around restricting downloads, and access to, the app. Company representatives from TikTok called the bill an "attempt to censor American voices” and “egregious government overreach.” A similar ban is being considered in U.S. Congress but faces a more uphill battle than in Montana’s Republican-controlled legislature. (Wired, Buzzfeed)

**Can’t get enough Talos?**

*   Talos Takes Ep. #134: How to best prepare for, and respond to, supply chain attacks
*   Cisco urges users to keep its network hardware up-to-date
*   Threat Roundup for April 7 – 14
*   Vulnerability Spotlight: Hard-coded password vulnerability could allow attacker to completely take over Lenovo Smart Clock

**Upcoming events where you can find Talos**

**RSA** **(April 24 - 27)**

San Francisco, CA

**Cisco Talos Incident Response: On Air** **(April 27)**

Virtual

**Cisco Live U.S.** **(June 4 - 8)**

Las Vegas, NV

**Most prevalent malware files from Talos telemetry over the past week**

  
**SHA 256:** 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
**MD5:** 2915b3f8b703eb744fc54c81f4a9c67f  
**Typical Filename:** VID001.exe  
**Claimed Product:** N/A  
**Detection Name:** Win.Worm.Coinminer::1201

**SHA 256:** e248b01e3ccde76b4d8e8077d4fcb4d0b70e5200bf4e738b45a0bd28fbc2cae6  
**MD5:** 1e2a99ae43d6365148d412b5dfee0e1c  
**Typical Filename:** PDFpower.exe  
**Claimed Product:** PdfPower  
**Detection Name:** Win32.Adware.Generic.SSO.TALOS

**SHA 256:** e4973db44081591e9bff5117946defbef6041397e56164f485cf8ec57b1d8934  
**MD5:** 93fefc3e88ffb78abb36365fa5cf857c  
**Typical Filename:** Wextract  
**Claimed Product:** Internet Explorer  
**Detection Name:** PUA.Win.Trojan.Generic::85.lp.ret.sbx.tg

**SHA 256:** 00ab15b194cc1fc8e48e849ca9717c0700ef7ce2265511276f7015d7037d8725  
**MD5:** d47fa115154927113b05bd3c8a308201  
**Typical Filename:** mssqlsrv.exe  
**Claimed Product:** N/A  
**Detection Name:** Trojan.GenericKD.65065311

**SHA 256:** 4ad8893f8c7cab6396e187a5d5156f04d80220dd386b0b6941251188104b2e53  
**MD5:** cdd331078279960a1073b03e0bb6fce4  
**Typical Filename:** mediaget.exe  
**Claimed Product:** MediaGet  
**Detection Name:** W32.DFC.MalParent

Threat Source newsletter (April 20, 2023) — Preview of Cisco and Talos at RSA

Today's LLMs pose too many trust and security risks.

_The Berryville Institute of Machine Learning (BIML) recently attended_ _Calypso AI’s Accelerate AI 2023_ _conference in Washington, DC. The meeting included practitioners from both government and industry, regulators, and academics. I participated in a very timely panel entitled "Emerging Risks and Opportunities of LLMs in the NATSEC and Beyond." That panel spurred this article._

_None of the content in this column was created by an LLM._

Large language models (LLMs) are a kind of machine learning system that has taken the world by storm. ChaptGPT (aka GPT-3.5), an LLM produced and fielded by OpenAI, is one of the most pervasive and popular of the many generative AI models for text. Other generative models include the image generators Dall-E, Midjourney, and Stable Diffusion, and the code generator Copilot.

LLMs and other generative tools present incredible opportunities for applications, and the rush to field such systems is in full gallop. LLMs have the potential to be lots of fun, solve hard problems in science, help with the thorny problems of knowledge management, create interesting content, and most importantly in my view, move the world a little closer to artificial general intelligence (AGI) and a theory of representation that produces massive cognitive science breakthroughs.

But using today's nascent LLMs — and any generative AI tools — comes with real risks.

**Of Parrots and Pollution**

LLMs are trained on massive corpuses of information (300 billion words, mostly scraped from the Internet) and use auto-association to predict the next word in a sentence. As such, most scientists agree that LLMs do not really "understand" anything or do any real thinking. Rather, they are "stochastic parrots," as some researchers call them. LLMs still do generate impressive streams of text, in context, and in an often useful and deeply surprising manner.

Feedback loops are an important class of problem in all kinds of ML models (and one that BIML introduced several years ago as “\[raw:8:looping\]”). Here is what we said at the time:

_Model confounded by subtle feedback loops. If data output from the model are later used as input back into the same model, what happens? Note that this is rumored to have happened to Google translate in the early days when translations of pages made by the machine were used to train the machine itself. Hilarity ensued. To this day, Google restricts some translated search results through its own policies_.

Imagine what will happen when a majority of what can be easily scraped from the Internet is generated by AI models of dubious quality, and then these LLMs start to eat their own tails. Talk about information pollution.

Some AI researchers and information security professionals are already deeply worried about information pollution today, but an infinite spewing information pollution pipeline sounds bad.

**Mansplaining-as-a-Service**

LLMs are very good B.S. artists. These models regularly express incorrect opinions and alternative facts with great confidence, and often make up information to justify their answers in a conversation (including pretend scientific references). Imagine what happens when average knowledge as scraped from the Internet — which includes lots of wrong things — is used to create new content.

The ultimate "reply guy" is not who we need writing news stories for us in the future. Facts actually do matter.

**Mirroring Broken Security**

LLMs are often trained on data that is biased in many ways. Sexist, racist, xenophobic, and misogynistic systems can and will be modeled from data sets originally collected when society was less progressive. Bias is a serious issue in LLMs, and one that operational Band-Aids are unlikely to fix.

**Trusting Deepfakes**

Deepfakes are a side effect of generative AI that has been discussed for some time. Fakes or spoofing are always a risk in security, but the capacity to make higher-quality fakes that are easy to believe is here. There are some obvious worst-case scenarios: moving markets, causing wars, inflaming cultural divides, and so on. Careful where that video came from.

**Automating Everything**

Generative models like LLMs have the capacity to replace lots of jobs, including low-level white collar jobs. Millions of people get plenty of satisfaction out of their jobs, but what if all of those jobs are willy-nilly replaced by ML systems that are cheaper to operate? We already see this with some writing content-creation jobs in local sports stories and marketing copy, for example. Should LLMs be writing our articles? Should they be practicing law? How about doing medical diagnosis?

**Using a Tool for Evil**

Generative AI can create some fun stuff. If you haven’t played with ChapGPT, you should give it a shot. I haven’t had this much fun with new technology since I got my first Apple \]\[+ in 1981, or since Java applets came out in 1995.

But the power of generative AI can be used for evil as well. For example, what if we put ML to the task of designing a novel virus with the propagation capability of COVID and the delayed onset parameters of rabies? Or how about the task of creating a plant with pollen that is also a neurotoxin. If I can think up these dastardly things in my kitchen, what happens when a real evil person starts brainstorming with ML?

Tools have no intrinsic morality or ethics. And for the record, the idea of "protecting prompts" is a pretend solution akin to protecting supercomputer access with command-line filtering.

**Holding Information in a Broken Cup**

Data moats are a thing now. That’s because if an ML model (with the help of humans) can get to your data and learn how to profitably parrot what you do by training on your data, it will. This leads to multiple risks best solved by carefully protecting your data sets instead of cramming them unto an ML model and fielding the model to the general public. In the gold rush world of ML, the gold is data.

Protecting data is harder than it sounds. Think how the government's current information classification system can't always protect classified information. Clearly, protecting sensitive and confidential information is already a huge challenge, so imagine what happens when we intentionally train up our ML systems on confidential information and set them out into the world.

Extraction and transfer attacks exist today, so be careful what you pour in your ML cup.

**What Should We Do About LLM Risk?**

So should we put some kind of magic moratorium on ML research for a few months as some technologists have self-servingly suggested? No, that's just silly. What we need to do is recognize these risks and face them directly.

The good news is that an entire industry is being built around securing ML systems, which I call machine learning security or MLsec. Check out what these new hot startups are building to control ML risk — but do so with a skeptical and well-informed eye.

Expert Insight: Dangers of Using Large Language Models Before They Are Baked

A heap-based buffer overflow vulnerability exists in the TriangleMesh clone functionality of Slic3r libslic3r 1.3.0 and Master Commit b1a5500. A specially-crafted STL file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**SUMMARY**

A heap-based buffer overflow vulnerability exists in the TriangleMesh clone functionality of Slic3r libslic3r 1.3.0 and Master Commit b1a5500. A specially-crafted STL file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Slic3r libslic3r 1.3.0  
Slic3r libslic3r Master Commit b1a5500

**PRODUCT URLS**

libslic3r - http://slic3r.org

**CVSSv3 SCORE**

8.1 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-130 - Improper Handling of Length Parameter Inconsistency

**DETAILS**

Slic3r is an open-source 3D printing toolbox, mainly utilized for translating 3D printing model file types into machine code for any printer. Slic3r uses libslic3er to do most of the non-GUI-based heavy lifting: reading various file formats, converting formats, and outputting appropriate gcode for the 3D printer’s given settings.

The libslic3r library, for parsing an STL file, will eventually execute the following function:

    bool
    STL::read(std::string input_file, TriangleMesh* mesh)
    {
        try {
            mesh->ReadSTLFile(input_file);
            mesh->check_topology();
        } catch (...) {
            throw std::runtime_error("Error while reading STL file");
        }
        return true;
    }
    

libslic3r heavily relies on ADMesh for several things, including STL manipulation. Indeed the ReadSTLFile function will eventually call ADMesh’s stl_open for parsing the STL file:

    stl_open(stl_file *stl, const ADMESH_CHAR *file) {
      stl_initialize(stl);
      stl_count_facets(stl, file);
      stl_allocate(stl);
      stl_read(stl, 0, 1);
      if (!stl->error) fclose(stl->fp);
    }
    

The function stl_count_facets will count how many triangles are present in the STL object provided. Then the stl_allocate will use that number to allocate the required number of facets:

    void
    stl_allocate(stl_file *stl) {
      [...]
      stl->facet_start = (stl_facet*)calloc(stl->stats.number_of_facets,
                                            sizeof(stl_facet));
      if(stl->facet_start == NULL) perror("stl_initialize");
      stl->stats.facets_malloced = stl->stats.number_of_facets;                                             [1]
    [...]
    }
    

The stl->stats.number_of_facets will be used to represent how many valid facets are in the stl->facet_start array. At [1], the number_of_facets is used to initialize the stl->stats.facets_malloced parameter. This parameter represents the actual number of elements allocated for the stl->facet_start array. At this point stl->stats.facets_malloced and stl->stats.number_of_facets coincide. Allegedly stl->stats.facets_malloced will always coincide with the actual allocated space for stl->facet_start.

The check_topology function eventually will remove the degenerate facets, the ones that do not form a valid triangle (for example, if two of the three vertices of any provided triangles are the same, they are removed).

libslic3r, during the read STL phase, will eventually reach the copy constructor for TriangleMesh:

    TriangleMesh::TriangleMesh(const TriangleMesh &other)
        : stl(other.stl), repaired(other.repaired)
    {
        this->clone(other);
    }
    

This copy constructor will essentially copy 1-to-1 many parameters, including the stl->stats.facets_malloced parameter, and then call the clone function:

    void TriangleMesh::clone(const TriangleMesh& other) {
        [..]
        if (other.stl.facet_start != NULL) {
            this->stl.facet_start = 
                      (stl_facet*)calloc(other.stl.stats.number_of_facets, sizeof(stl_facet));              [2]
            std::copy(
                      other.stl.facet_start, 
                      other.stl.facet_start + other.stl.stats.number_of_facets,
                      this->stl.facet_start);                                                               [3]
        }
        [..]
    }
    

This function will manage the pointers of the new objects, creating new arrays and copying the contents from the other argument. For instance, at [2], the this->stl.facet_start, array that contains the actual facets, is allocated, and then, at [3] is populated with the original object contents.

After the whole copy constructor procedure stl->stats.facets_malloced could not coincide anymore with the actual allocated space for stl->facet_start . Indeed, stats.facets_malloced is copied as it is, but the stats.number_of_facets can be less than the allocated spaces (for instance, for the removed degenerate facets). After the copy constructor, the object could have a stl.facet_start that is allocated with a smaller number than stats.facets_malloced. Because these variable are used in the ADMesh’s functions to understand if it is required to allocate more space for the stl.facet_start array, this problem can lead to a heap buffer overflow.

For example, the function used to add a facet is ADMesh’s stl_add_facet:

    void
    stl_add_facet(stl_file *stl, stl_facet *new_facet) {
      if (stl->error) return;
    
      stl->stats.facets_added += 1;
      if(stl->stats.facets_malloced < stl->stats.number_of_facets + 1) {                                    [4]
        [... Allocate more space ...]
      }
      stl->facet_start[stl->stats.number_of_facets] = *new_facet;                                           [5]
    
      [...]
    }
    

We can analyze at [4] the stl object, loading a specific STL, to realize that a buffer overflow could occur:

    (gdb) p *stl
    $5 = {
      [..]
      facet_start = 0x9b5c70,
      [...]
      stats = {
    
        number_of_facets = 0x3,
        [..]
        facets_malloced = 0x4,
        [...]
      },
    [...]
    }
    

Above it is shown that the stl object has stats.number_of_facets=3 and stats.facets_malloced=4.

    (gdb) heap chunk stl->facet_start
    Chunk(addr=0x9b5c70, size=0xb0, flags=PREV_INUSE)
    Chunk size: 176 (0xb0)
    Usable size: 168 (0xa8)
    [...]
    

The facet_start has size 0xa8. So, the number of elements in the array is:

    (gdb) p 0xa8/sizeof(stl_facet)
    $15 = 0x3
    

With the example provided, at [4], the branch will not be taken and so no reallocation will take place. This will cause a heap buffer overflow at [5].

**Crash Information**

    ==8==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e00000133c at pc 0x556e0e8d47c6 bp 0x7ffc72e7a6a0 sp 0x7ffc72e7a698
    WRITE of size 52 at 0x60e00000133c thread T0
        #0 0x556e0e8d47c5 in stl_add_facet /app/Slic3r/xs/src/admesh/connect.c:977
        #1 0x556e0e8d3fd3 in stl_fill_holes /app/Slic3r/xs/src/admesh/connect.c:935
        #2 0x556e0e8eb2a9 in stl_repair /app/Slic3r/xs/src/admesh/util.c:589
        #3 0x556e0e621c63 in Slic3r::TriangleMesh::repair() /app/Slic3r/xs/src/libslic3r/TriangleMesh.cpp:186
        #4 0x556e0e59229e in Slic3r::ModelObject::repair() /app/Slic3r/xs/src/libslic3r/Model.cpp:602
        #5 0x556e0e58b522 in Slic3r::Model::repair() /app/Slic3r/xs/src/libslic3r/Model.cpp:211
        #6 0x556e0e505745 in main /app/Slic3r/src/slic3r.cpp:20
        #7 0x7f6f0cbee81c in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2381c)
        #8 0x556e0e5054f9 in _start (/app/Slic3r/build/slic3r+0x6f4f9)
    
    0x60e00000133c is located 0 bytes to the right of 156-byte region [0x60e0000012a0,0x60e00000133c)
    allocated by thread T0 here:
        #0 0x7f6f0d1f0987 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
        #1 0x556e0e621339 in Slic3r::TriangleMesh::clone(Slic3r::TriangleMesh const&) /app/Slic3r/xs/src/libslic3r/TriangleMesh.cpp:103
        #2 0x556e0e621035 in Slic3r::TriangleMesh::TriangleMesh(Slic3r::TriangleMesh const&) /app/Slic3r/xs/src/libslic3r/TriangleMesh.cpp:85
        #3 0x556e0e59ae10 in Slic3r::ModelVolume::ModelVolume(Slic3r::ModelObject*, Slic3r::TriangleMesh const&) /app/Slic3r/xs/src/libslic3r/Model.cpp:1054
        #4 0x556e0e590ce5 in Slic3r::ModelObject::add_volume(Slic3r::TriangleMesh const&) /app/Slic3r/xs/src/libslic3r/Model.cpp:499
        #5 0x556e0e524c80 in Slic3r::IO::STL::read(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, Slic3r::Model*) /app/Slic3r/xs/src/libslic3r/IO.cpp:59
        #6 0x556e0e5056ef in main /app/Slic3r/src/slic3r.cpp:19
        #7 0x7f6f0cbee81c in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2381c)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /app/Slic3r/xs/src/admesh/connect.c:977 in stl_add_facet
    Shadow bytes around the buggy address:
      0x0c1c7fff8210: fd fd fd fd fa fa fa fa fa fa fa fa 00 00 00 00
      0x0c1c7fff8220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1c7fff8230: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      0x0c1c7fff8240: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
      0x0c1c7fff8250: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c1c7fff8260: 00 00 00 00 00 00 00[04]fa fa fa fa fa fa fa fa
      0x0c1c7fff8270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff8280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff8290: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff82a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1c7fff82b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==8==ABORTING
    

**TIMELINE**

2022-09-01 - Vendor Disclosure  
2023-04-03 - Last Contact Date  
2023-04-20 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2022-36788: TALOS-2022-1593 || Cisco Talos Intelligence Group

Ubuntu Security Notice 6033-1 - It was discovered that the Traffic-Control Index implementation in the Linux kernel did not properly perform filter deactivation in some situations. A local attacker could possibly use this to gain elevated privileges. Please note that with the fix for thisCVE, kernel support for the TCINDEX classifier has been removed. William Zhao discovered that the Traffic Control subsystem in the Linux kernel did not properly handle network packet retransmission in certain situations. A local attacker could use this to cause a denial of service.

==========================================================================  
Ubuntu Security Notice USN-6033-1  
April 19, 2023

linux-oem-6.1 vulnerabilities  
==========================================================================

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 22.04 LTS

Summary:

Several security issues were fixed in the Linux kernel.

Software Description:  
- linux-oem-6.1: Linux kernel for OEM systems

Details:

It was discovered that the Traffic-Control Index (TCINDEX) implementation  
in the Linux kernel did not properly perform filter deactivation in some  
situations. A local attacker could possibly use this to gain elevated  
privileges. Please note that with the fix for this CVE, kernel support for  
the TCINDEX classifier has been removed. (CVE-2023-1829)

William Zhao discovered that the Traffic Control (TC) subsystem in the  
Linux kernel did not properly handle network packet retransmission in  
certain situations. A local attacker could use this to cause a denial of  
service (kernel deadlock). (CVE-2022-4269)

Thadeu Cascardo discovered that the io_uring subsystem contained a double-  
free vulnerability in certain memory allocation error conditions. A local  
attacker could possibly use this to cause a denial of service (system  
crash). (CVE-2023-1032)

It was discovered that the TUN/TAP driver in the Linux kernel did not  
properly initialize socket data. A local attacker could use this to cause a  
denial of service (system crash). (CVE-2023-1076)

It was discovered that the Real-Time Scheduling Class implementation in the  
Linux kernel contained a type confusion vulnerability in some situations. A  
local attacker could use this to cause a denial of service (system crash).  
(CVE-2023-1077)

It was discovered that the ASUS HID driver in the Linux kernel did not  
properly handle device removal, leading to a use-after-free vulnerability.  
A local attacker with physical access could plug in a specially crafted USB  
device to cause a denial of service (system crash). (CVE-2023-1079)

It was discovered that the io_uring subsystem in the Linux kernel did not  
properly perform file table updates in some situations, leading to a null  
pointer dereference vulnerability. A local attacker could use this to cause  
a denial of service (system crash). (CVE-2023-1583)

It was discovered that the Xircom PCMCIA network device driver in the Linux  
kernel did not properly handle device removal events. A physically  
proximate attacker could use this to cause a denial of service (system  
crash). (CVE-2023-1670)

It was discovered that the APM X-Gene SoC hardware monitoring driver in the  
Linux kernel contained a race condition, leading to a use-after-free  
vulnerability. A local attacker could use this to cause a denial of service  
(system crash) or expose sensitive information (kernel memory).  
(CVE-2023-1855)

It was discovered that a race condition existed in the Bluetooth HCI SDIO  
driver, leading to a use-after-free vulnerability. A local attacker could  
use this to cause a denial of service (system crash). (CVE-2023-1989)

It was discovered that the ST NCI NFC driver did not properly handle device  
removal events. A physically proximate attacker could use this to cause a  
denial of service (system crash). (CVE-2023-1990)

José Oliveira and Rodrigo Branco discovered that the Spectre Variant 2  
mitigations with prctl syscall were insufficient in some situations. A  
local attacker could possibly use this to expose sensitive information.  
(CVE-2023-1998)

It was discovered that the BigBen Interactive Kids' gamepad driver in the  
Linux kernel did not properly handle device removal, leading to a use-  
after-free vulnerability. A local attacker with physical access could plug  
in a specially crafted USB device to cause a denial of service (system  
crash). (CVE-2023-25012)

It was discovered that a race condition existed in the TLS subsystem in the  
Linux kernel, leading to a use-after-free or a null pointer dereference  
vulnerability. A local attacker could use this to cause a denial of service  
(system crash) or possibly execute arbitrary code. (CVE-2023-28466)

It was discovered that the Bluetooth subsystem in the Linux kernel did not  
properly initialize some data structures, leading to an out-of-bounds  
access vulnerability in certain situations. An attacker could use this to  
expose sensitive information (kernel memory). (CVE-2023-28866)

Reima Ishii discovered that the nested KVM implementation for Intel x86  
processors in the Linux kernel did not properly validate control registers  
in certain situations. An attacker in a guest VM could use this to cause a  
denial of service (guest crash). (CVE-2023-30456)

Duoming Zhou discovered that a race condition existed in the infrared  
receiver/transceiver driver in the Linux kernel, leading to a use-after-  
free vulnerability. A privileged attacker could use this to cause a denial  
of service (system crash) or possibly execute arbitrary code.  
(CVE-2023-1118)

Update instructions:

The problem can be corrected by updating your system to the following  
package versions:

Ubuntu 22.04 LTS:  
   linux-image-6.1.0-1009-oem      6.1.0-1009.9  
   linux-image-oem-22.04c          6.1.0.1009.9

After a standard system update you need to reboot your computer to make  
all the necessary changes.

ATTENTION: Due to an unavoidable ABI change the kernel updates have  
been given a new version number, which requires you to recompile and  
reinstall all third party kernel modules you might have installed.  
Unless you manually uninstalled the standard kernel metapackages  
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,  
linux-powerpc), a standard system upgrade will automatically perform  
this as well.

References:  
   https://ubuntu.com/security/notices/USN-6033-1  
   CVE-2022-4269, CVE-2023-1032, CVE-2023-1076, CVE-2023-1077,  
   CVE-2023-1079, CVE-2023-1118, CVE-2023-1583, CVE-2023-1670,  
   CVE-2023-1829, CVE-2023-1855, CVE-2023-1989, CVE-2023-1990,  
   CVE-2023-1998, CVE-2023-25012, CVE-2023-28466, CVE-2023-28866,  
   CVE-2023-30456

Package Information:  
   https://launchpad.net/ubuntu/+source/linux-oem-6.1/6.1.0-1009.9

Ubuntu Security Notice USN-6033-1

WordPress PowerPress plugin versions 10.0 and below suffer from a persistent cross site scripting vulnerability.

    On April 5, 2023, our Wordfence Threat Intelligence team identified and began the responsible disclosure process for a stored Cross-Site Scripting (XSS) vulnerability in Blubrry’s PowerPress plugin, which is actively installed on more than 50,000 WordPress websites. The vulnerability enables threat actors with contributor-level permissions or higher to inject malicious web scripts into pages using the plugin’s shortcode.All Wordfence Premium, Wordfence Care, and Wordfence Response customers, as well as those still using the free version of our plugin, are protected against any exploits targeting this vulnerability by the Wordfence firewall’s built-in Cross-Site Scripting protection.We contacted Blubrry on April 6, 2023, and promptly received a response. After providing full disclosure details, the developer released a patch on April 10, 2023. We commend the PowerPress development team for their swift response and timely patch release.We urge users to update their sites with the latest patched version of PowerPress, version 10.0.4 at the time of this writing, as soon as possible.This email content has also been published on our blog and you're welcome to post a comment there if you'd like to join the conversation. Or you can read the full post in this email.Vulnerability Summary From Wordfence IntelligenceTitle: PowerPress <= 10.0 - Authenticated (Contributor+) Stored Cross-Site Scripting via Shortcode Plugin: PowerPress Plugin Slug: powerpressAffected Versions: <= 10.0CVE ID: CVE-2023-1917 CVSS Severity Score: 5.4 (Medium)CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N Researcher: Alex Thomas Fully Patched Version: 10.0.2Technical AnalysisPowerPress is a plugin that allows WordPress users to publish and manage podcasts. It provides a shortcode ([powerpress]) that allows users to display the PowerPress player on a WordPress page. However, insecure implementation of the plugin’s shortcode functionality allows for the injection of arbitrary web scripts into these pages. A closer examination of the code reveals that the ‘powerpress_shortcode_handler’ function did not adequately sanitize user-supplied input and a number of functions (for various podcast player options) that utilize the shortcode attributes did not adequately escape output.The powerpress_shortcode_handler function The powerpress_shortcode_handler functionThe powerpress_generate_embed function creates an iframe using unescaped shortcode attributes. The powerpress_generate_embed function creates an iframe using unescaped shortcode attributes.This makes it possible for threat actors to carry out stored XSS attacks. Once a script is injected, it will execute each time a user accesses the affected page. Threat actors could potentially steal sensitive information, manipulate site content, or redirect users to malicious websites.Disclosure TimelineApril 5, 2023 – Wordfence Threat Intelligence team discovers the stored XSS vulnerability in PowerPress and initiates responsible disclosure.April 6, 2023 – We get in touch with the development team at Blubrry and send full disclosure details.April 7, 2023 – The vendor acknowledges the report and begins working on a fix.April 10, 2023 – The fully patched version, 10.0.1, is released.April 11, 2023 – Wordfence confirms the fix addresses the vulnerability.April 14, 2023 – Blubrry releases an additional patch (version 10.0.2) to address a workaroundConclusionIn this blog post, we have detailed a stored XSS vulnerability within the PowerPress plugin affecting versions 10.0 and earlier. This vulnerability allows authenticated threat actors with contributor-level permissions or higher to inject malicious web scripts into pages that execute when a user accesses an affected page. The vulnerability has been fully addressed in version 10.0.2 of the plugin.We encourage WordPress users to verify that their sites are updated to the latest patched version of PowerPress.All Wordfence users, including those running Wordfence Premium, Wordfence Care, and Wordfence Response, as well as sites still running the free version of Wordfence, are fully protected against this vulnerability.If you know someone who uses this plugin on their site, we recommend sharing this advisory with them to ensure their site remains secure, as this vulnerability poses a significant risk.For security researchers looking to disclose vulnerabilities responsibly and obtain a CVE ID, you can submit your findings to Wordfence Intelligence and potentially earn a spot on our leaderboard.

WordPress PowerPress 10.0 Cross Site Scripting

As is typical with emerging technologies, both innovators and regulators struggle with developments in generative AI, much less the rules that should govern its use.

It has been a busy time in the world of large language models. In late March, OpenAI disclosed a breach of users' personal data. ChatGPT does not appear to have issued an independent apology. As a mere algorithm, how could it? "Right" and "wrong" are only known to it by the artifice of its content filters.

OpenAI has reasserted its commitment to protecting users' privacy and keeping their data safe; however, it has since been reported that Samsung employees exposed confidential meeting minutes and source code via prompts sent to ChatGPT. OpenAI warns against the use of sensitive information in conversations, but there are clearly significant risks that the AI industry needs to address in the development of models and services. Garante, the Italian data protection authority, issued a ruling to prevent use of ChatGPT at the end of March, and the Office of the Privacy Commissioner of Canada has launched its own investigation into ChatGPT's privacy implications. The eventual consequences for OpenAI and the AI community remain to be seen.

Soon after reporting of the initial OpenAI breach came the Future of Life Institute's open letter, calling for a six-month halt to what they termed "giant AI experiments." The letter was signed by many of the signatories to a 2015 Future of Life Institute open letter, warning of the dangers of autonomous weapons equipped with AI to cause harm. The sentiments expressed in the letter are not universally held, with two doyens of the AI industry, Andrew Ng and Yann LeCun, jointly communicating their disagreement with calls for a pause in research.

With the Future Life Institute's open letter establishing a development threshold of AI systems "more powerful than GPT-4," there must have be some degree of anxiety among those working on Google's Bard and Microsoft's Copilot systems, which were overlooked. While it is fortunate that the generative pretrained transformer (GPT) class of models are, as yet, without ego, given the coverage they are receiving within the technical community and the popular press; it is appropriate to reflect on the ChatGPT data breaches, alongside the new capabilities announced in GPT-4.

**Wider Concerns**

The data breach reported by OpenAI occurred against a background of wider concern about the societal implications, regulatory oversight, governance, and practical application of powerful AI systems. Analysis from Goldman Sachs suggested that generative AI systems could deliver a 7% increase in global GDP over a 10-year period, while simultaneously affecting the jobs of 300 million people. The UK government's recent white paper (PDF) has also been contrasted to the interventionist approach reflected in the proposed EU Artificial Intelligence Act.

In OpenAI's disclosure of the ChatGPT data breach, it is important to note their observation that the bug "allowed some users to see titles from another active user's chat history," and, possibly, "the first message of a newly-created conversation was visible in someone else's chat history if both users were active around the same time."

While the bug is resolved, the risks to privacy and confidentiality in centralized AI systems have been exposed along with users' data. GPT-4's reported performance data is impressive, and the prospect of multi-modal prompts, comprising images and text, extends the scope of potential applications. But what happens to all that prompt data? What does it say about the user? What might that prompt data disclose? And, what are the implications of all that generated probabilistic output for the veracity of tomorrow's information domain?

**Questions Raised**

Important questions are also raised about the source of the massive volumes of training data required for initial development. Has informed consent been obtained for the use of this data? Are copyrights and other intellectual property protections respected? How is the veracity of training data established and the accuracy of predictions evaluated? None of these questions are easily answered by the current state of the art for predictive text sequencing, where their ethical foundation is at best opaque and the risk of future self-reference looms large as all the probabilistic and erroneous responses churned out by ChatGPT and GPT-4 enter the corpus of training data.

OpenAI openly states on the ChatGPT FAQs page that user conversations are retained for training and users should avoid including sensitive data in prompts, to avoid the problems experienced by Samsung. But what constitutes sensitive data, beyond the obvious information that is subject to regulatory control or that explicitly identifies the user? Well, every prompt discloses some information about the user sand their unique interests. The language, phraseology, and tone of prompts point to the personal characteristics and preferences of the user. Such characterizations can be used to finetune responses to either individual users or derived subsets of the overall user population.

Eventually, imperceptibly unique characteristics contained in the spelling and punctuation tics, image geometry, or source documentation of inputs to GPT services could discern sensitive information, or, worse, enable simulation of a human response that cannot be discriminated by either machine or human judgement.

In parallel, Ilya Sutskever, co-founder and chief scientist of OpenAI, caused another recent stir when he stated that the closed-source stance taken with respect to the architecture of GPT-4 was necessary in response to competitive threats and potential safety implications associated with disclosure of the technology. As is typically the case with processes of innovation, the regulatory environment today is disjointed and in a losing race to catch up with developments in the field. The new capabilities of GPT-4 and services based on the prior generation of GPT technology are imbued with significant risks, many of which remain unforeseen and unimagined. Reduced transparency in model development will not help.

**Risky Business**

While the risk to data privacy and confidentiality is evident at the implementation level, those risks are an intrinsic component of ChatGPT, GPT-4, and other centralized AI systems. How we address these risks as a society, to exploit the welcome benefits of AI without the sacrifice of cherished human rights, is one of the many questions posed by accelerating advancements in machine intelligence. If we are not sufficiently concerned about the information our human-machine conversations disclose about us today, we might worry more when, as a team of AI researchers have already demonstrated, one day soon, machines will possess the capability to actually read our minds. There is much for humanity and GPT-4 to ponder.

GPT-4 Provides Improved Answers While Posing New Questions

An issue was discovered in ONOS 2.5.1. In IntentManager, the install-requested intent (which causes an exception) remains in pendingMap (in memory) forever. Deletion is possible neither by a user nor by the intermittent Intent Cleanup process.

Open Network Operating System (ONOS®) is the leading open source SDN controller for building next-generation SDN/NFV solutions.

ONOS was designed to meet the needs of operators wishing to build carrier-grade solutions that leverage the economics of white box merchant silicon hardware while offering the flexibility to create and deploy new dynamic network services with simplified programmatic interfaces. ONOS supports both configuration and real-time control of the network, eliminating the need to run routing and switching control protocols inside the network fabric. By moving intelligence into the ONOS cloud controller, innovation is enabled and end-users can easily create new network applications without the need to alter the dataplane systems.

The ONOS platform includes:

*   A platform and a set of applications that act as an extensible, modular, distributed SDN controller.
*   Simplified management, configuration and deployment of new software, hardware & services.
*   A scale-out architecture to provide the resiliency and scalability required to meet the rigors of production carrier environments.

With an expanding community of developers and users, ONOS is an open-source project distributed under the Apache 2.0 license.

**ONOS is the only open source controller providing:**

**Scalability**

Offers virtually unlimited replication for scaling control plane capacity as needed

**High Performance**

Performs to the exacting specifications of large network operators

**Resiliency**

Provides the availability required for mission critical operator networks.

**Legacy device support**

Makes it easy to add or configure traditional devices and services with model based dynamic configuration

**Next-Generation device support**

Gives real-time control for native SDN dataplane devices with OpenFlow® and now with P4 support

**Enabling next-generation solutions in service provider networks**

ONOS has enabled the SDN revolution. Combining ONOS with white box switches and ONOS applications enables new forms of innovation never before possible with closed legacy networks.

**Edge Networks**

CORD® (Central Office Re-architected as a Datacenter) is delivering edge cloud for operators, reinventing the edge of operator networks in cloud-native ways for efficiency and agility. By blending the best of Cloud, SDN and NFV, CORD provides complete integrated solutions for fixed access (PON), mobile and wireless 5G access, mobile core (EPC) and enterprise service delivery.

**Transport Networks**

ODTN (Open Disaggregated Transport Network) is disaggregating carrier core networks, and reassembling a solution using SDN principles and white box efficiencies to build high performance backbones with disruptive economics.

**Datacenter**

Trellis is a complete spine leaf datacenter fabric solution with multi-tenant overlay support, built completely with bare metal white box switches.

**And More**

Various SDN solutions for switches, PON (OLTs), Wireless (RANs & eNBs), and ROADMs

**ONOS in Action**

**Virtualization of Cable Networks**

**Air Traffic Control Network**

Technical Steering Team (TST)

The TST oversees the ONOS project and is responsible for all technical decisions.

**ONOS Resources**

**ONOS Community**

CVE-2021-38363: Open Network Operating System (ONOS) SDN Controller for SDN/NFV Solutions

The mass compromise of the VoIP firm's customers is the first confirmed incident where one software supply chain attack enabled another, researchers say.

The cybersecurity industry has scrambled in recent weeks to understand the origins and fallout of the breach of 3CX, a VoIP provider whose software was corrupted by North Korea-linked hackers in a supply chain attack that seeded out malware to potentially hundreds of thousands of its customers. Cybersecurity firm Mandiant now has an answer to the mystery of how 3CX was itself penetrated by those state-sponsored hackers: The company was one of an untold number of victims infected with the corrupted software of _another_ company—a rare, or perhaps even unprecedented, example of how a single group of hackers used one software supply chain attack to carry out a second one. Call it a supply-chain chain reaction.

Today, Mandiant revealed that in the midst of its investigation of the 3CX supply chain attack, it's now found the patient zero for that widespread hacking operation, which hit a significant fraction of 3CX's 600,000 customers. According to Mandiant, a 3CX employee’s PC was hacked through an earlier software supply chain attack that hijacked an application of Trading Technologies, a financial software firm that was targeted by the same hackers who compromised 3CX. That hacker group, known as Kimsuky, Emerald Sleet, or Velvet Chollima, is widely believed to be working on behalf of the North Korean regime.

Mandiant says the hackers somehow managed to slip backdoor code into an application available on Trading Technology's website known as X\_Trader. That infected app, when it was later installed on the computer of a 3CX employee, then allowed the hackers to spread their access through 3CX's network, reach a server 3CX used for software development, corrupt a 3CX installer application and infect a broad swathe of its customers, according to Mandiant.

“This is the first time we've ever found concrete evidence of a software supply chain attack leading to another software supply chain attack,” says Mandiant chief technology officer Charles Carmakal. “So this is very big, and very significant to us.”

Mandiant says it hasn't been hired by Trading Technologies to investigate the original attack that exploited its X\_Trader software, so it doesn't know how the hackers altered Trading Technologies' application or how many victims—other than 3CX—there may have been from the compromise of that trading app. The company notes that Trading Technologies had stopped supporting X\_Trader in 2020, though the application was still available for download through 2022. Mandiant believes, based on a digital signature on the corrupted X\_Trader malware, that Trading Technologies' supply chain compromise occurred before November 2021, but that the 3CX follow-on supply chain attack didn't occur until early this year.

A spokesperson for Trading Technologies told WIRED that the company had warned users for 18 months that X\_Trader would no longer be supported in 2020, and that, given that X\_Trader is a tool for trading professionals, there's no reason it should have been installed on a 3CX machine. The spokesperson added that 3CX was not a customer of Trading Technologies, and that any compromise of the X\_Trader application doesn't affect its current software. 3CX didn't respond to WIRED's request for comment.

Exactly what the North Korean hackers sought to accomplish with their interlinked software supply chain attacks still isn't entirely clear, but it appears to have been motivated in part by simple theft. Two weeks ago, cybersecurity firm Kaspersky revealed that at least a handful of the victims targeted with the corrupted 3CX application were cryptocurrency-related companies based in "Western Asia," though it declined to name them. Kaspersky found that, as is often the case with massive software supply chain attacks, the hackers had sifted through their potential victims and delivered a piece of second-stage malware to only a tiny fraction of those hundreds of thousands of compromised networks, targeting them with “surgical precision.”

Mandiant agrees that at least one goal of the North Korea-linked hackers is no doubt cryptocurrency theft: It points to earlier findings from Google's Threat Analysis Group that AppleJeus, a piece of malware tied to the same hackers, was used to target cryptocurrency services via a vulnerability in Google's Chrome browser. Mandiant also found that the same backdoor in 3CX's software was inserted into another cryptocurrency application, CoinGoTrade, and that it shared infrastructure with yet another backdoored trading app, JMT Trading.

All of that, in combination with the group's targeting of Trading Technologies, points to a focus on stealing cryptocurrency, says Ben Read, Mandiant's head of cyberespionage threat intelligence. A broad supply chain attack like the one that exploited 3CX's software would “get you in places where people are handling money,” Read says. “This is a group heavily focused on monetization.”

But Mandiant's Carmakal notes that given the scale of these supply chain attacks, crypto-focused victims may still be just the tip of the iceberg. “I think we'll learn about many more victims over time as it relates to one of these two software supply chain attacks,” he says.

While Mandiant describes the Trading Technologies and 3CX compromises as the first known instance of one supply chain attack leading to another, researchers have speculated for years about whether other such incidents were similarly interlinked. The Chinese group known as Winnti or Brass Typhoon, for instance, carried out no fewer than six software supply chain attacks from 2016 to 2019. And in some of those cases, the method of the hackers' initial breach wasn't ever discovered—and may well have been from an earlier supply chain attack.

Mandiant's Carmakal notes that there were signs, too, that the Russian hackers responsible for the notorious SolarWinds supply chain attack were also doing reconnaissance on software development servers inside some of their victims, and were perhaps planning a follow-on supply chain attack when they were disrupted.

After all, a hacker group capable of carrying out a supply chain attack usually manages to cast a vast net that pulls in all sorts of victims—some of whom are often software developers that themselves offer a powerful vantage point from which to carry out a follow-on supply chain attack, casting out the net yet again. If 3CX is, in fact, the first company hit with this sort of supply-chain chain reaction, it's unlikely to be the last.

The Huge 3CX Breach Was Actually 2 Linked Supply Chain Attacks

In the short time since their inception, ChatGPT and other generative AI platforms have rightfully gained the reputation of ultimate productivity boosters. However, the very same technology that enables rapid production of high-quality text on demand, can at the same time expose sensitive corporate data. A recent incident, in which Samsung software engineers pasted proprietary code into ChatGPT,

Artificial Intelligence / Data Safety

In the short time since their inception, ChatGPT and other generative AI platforms have rightfully gained the reputation of ultimate productivity boosters. However, the very same technology that enables rapid production of high-quality text on demand, can at the same time expose sensitive corporate data. A recent incident, in which Samsung software engineers pasted proprietary code into ChatGPT, clearly demonstrates that this tool can easily become a potential data leakage channel. This vulnerability introduces a demanding challenge for security stakeholders, since none of the existing data protection tools can ensure no sensitive data is exposed to ChatGPT. In this article we'll explore this security challenge in detail and show how browser security solutions can provide a solution. All while enabling organizations to fully realize ChatGPT's productivity potential and without having to compromise on data security.

**The ChatGPT data protection blind spot: How can you govern text insertion in the browser?**

Whenever an employee pastes or types text into ChatGPT, the text is no longer controlled by the corporate's data protection tools and policies. It doesn't matter if the text was copied from a traditional data file, an online doc, or another source. That, in fact, is the problem. Data Leak Prevention (DLP) solutions – from on-prem agents to CASB – are all **file-oriented**. They apply policies on files based on their content, while preventing actions such as modifying, downloading, sharing, and more. However, this capability is of little use for ChatGPT data protection. There are no files involved in ChatGPT. Rather, usage involves pasting copied text snippets or typing directly into a web page, which is beyond the governance and control of any existing DLP product.

**How browser security solutions prevent insecure data usage in ChatGPT**

LayerX launched its browser security platform for continuous monitoring, risk analysis, and real-time protection of browser sessions. Delivered as a browser extension, LayerX has granular visibility into every event that takes place within the session. This enables LayerX to detect risky behavior and configure policies to prevent pre-defined actions from taking place.

In the context of protecting sensitive data from being uploaded to ChatGPT, LayerX leverages this visibility to single out attempted text insertion events, such as 'paste' and 'type', within the ChatGPT tab. If the text's content in the 'paste' event violates the corporate data protection policies, LayerX will prevent the action altogether.

To enable this capability, security teams using LayerX should define the phrases or regular expressions they want to protect from exposure. Then, they need to create a LayerX policy that is triggered whenever there's a match with these strings.

See what it looks like in action:

Setting the policy in the LayerX Dashboard

A user that tries to copy sensitive information into ChatGPT gets blocked by LayerX

In addition, organizations that wish to prevent their employees from using ChatGPT altogether, can use LayerX to block access to the ChatGPT website or to any other online AI-based text generators, including ChatGPT-like browser extensions.

**Learn more about LayerX ChatGPT data protection here.**

**Using LayerX's browser security platform to gain comprehensive SaaS protection**

The difference that makes LayerX the only solution that can effectively address the ChatGPT data protection gap **is its placement in the browser itself,** with real-time visibility and policy enforcement on the actual browser session. This approach also makes it an ideal solution for protecting from any cyber threat that targets data or user activity in the browser, as is the case with SaaS applications.

Users interact with SaaS apps through their browsers. This makes it easy for LayerX to protect both the data within these apps as well as the apps themselves. This is achieved by enforcing the following types of policies on users' activities throughout the web sessions:

**Data protection policies:** On top of standard file-oriented protection (prevention of copy/share/download/etc.), LayerX provides the same granular protection it does for ChatGPT. In fact, once the organization has defined which inputs it bans pasting, the same policies can be expanded to prevent exposing this data to any web or SaaS location.

**Account compromise mitigation**: LayerX monitors each user's activities on the organization's SaaS apps. The platform will detect any anomalous behavior or data interaction that indicates that the user's account is compromised. LayerX policies will then trigger either the termination of the session or disable any data interaction abilities for the user in the app.

**Learn more about LayerX ChatGPT data protection here**.

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

Tag

#intel