The funds from Germany's Sovereign Tech Fund will be used to integrate zero-trust capabilities, tools for software bill of materials, and other security features.

Source: Les Polders via Alamy Stock Photo

The health of the global Internet and digital infrastructure relies heavily on volunteer-maintained open source projects. Various organizations and initiatives now provide funding to make security fixes or improve features for some of these projects.

Last week, the FreeBSD Foundation announced a €686,400 (approximately $762,540) investment from Germany's Sovereign Tech Fund. The foundation drives development and maintenance of the FreeBSD operating system, a Unix-based operating system similar to Linux. The funding from STF is intended to cover work for the rest of 2024 and extend into 2025 and will focus on security features and improvements.

STF is supported by the German Federal Ministry for Economic Affairs and Climate Action (BMWK) and is hosted by the German Federal Agency for Disruptive Innovation (SPRIND). The fund has actively supported open source projects that are important components of the global digital infrastructure, such as €1 million ($1.1 million) for GNOME (a widely used desktop application for Linux operating systems) development at the end of last year and €203,000 ($225,487) to GStreamer (a multimedia framework used widely in streaming apps, embedded devices, and browsers) earlier this year. Several of STF's recent investments are tied to security improvements, such as making the encrypted home directory a GNOME feature and rewriting GStreamer's various Web and networking protocols (RTP/RTCP, RTSP, and WebRTC) from C to Rust to eliminate recurring memory-based vulnerabilities.

The FreeBSD investment will also focus on several security initiatives, such as zero-trust builds, continuous integration/continuous delivery (CI/CD) automation, reducing technical debt, enhancing security controls, and improving tools related to the software bill of materials. Reducing technical debt is important since many vulnerabilities linger on in years-old components that are no longer being maintained or even looked at.

Zero-trust builds refer to the ability to prove where all the source code and tooling used in FreeBSD came from and are trusted. This is necessary to ensure that the tools used (such as compilers) are not introducing backdoors or malware into the code.

The focus on CI/CD automation is necessary to streamlining software delivery and operations. It will allow for constantly running security tests to ensure that changes have not introduced vulnerabilities and fixing them as they are found.

"This investment in critical digital infrastructure will accelerate modernization of FreeBSD, enhance security hygiene, and improve developer experiences," said Fiona Krakenbürger, co-founder of STF, in a statement.

STF has supported a slew of other open source projects, including curl, FFmpeg, Rustls (a TLS library written in Rust), and Coreutils uutils (the coreutils library with basic file, shell, and text functions rewritten in Rust).

FreeBSD Gets €686,400 to Boost Security Features

At Black Hat USA, security researcher Michael Bargury released a "LOLCopilot" ethical hacking module to demonstrate how attackers can exploit Microsoft Copilot — and offered advice for defensive tooling.

Source: Marcos Alvarado via Alamy Stock Photo

BLACK HAT USA – Las Vegas – Thursday, Aug. 8 – Enterprises are implementing Microsoft's Copilot AI-based chatbots at a rapid pace, hoping to transform how employees gather data and organize their time and work. But at the same time, Copilot is also an ideal tool for threat actors.

Security researcher Michael Bargury, a former senior security architect in Microsoft's Azure Security CTO office and now co-founder and chief technology officer of Zenity, says attackers can use Copilot to search for data, exfiltrate it without producing logs, and socially engineer victims to phishing sites even if they don't open emails or click on links.

Today at Black Hat USA in Las Vegas, Bargury demonstrated how Copilot, like other chatbots, is susceptible to prompt injections that enable hackers to evade its security controls.

The briefing, Living off Microsoft Copilot, is the second Black Hat presentation in as many days for Bargury. In his first presentation on Wednesday, Bargury demonstrated how developers could unwittingly build Copilot chatbots capable of exfiltrating data or bypassing policies and data loss prevention controls with Microsoft's bot creation and management tool, Copilot Studio.

**A Red-Team Hacking Tool for Copilot**

Thursday's follow-up session focused on various risks associated with the actual chatbots, and Bargury released an offensive security toolset for Microsoft 365 on GitHub. The new LOLCopilot module, part of powerpwn, is designed for Microsoft Copilot, Copilot Studio, and Power Platform.

Bargury describes it as a red-team hacking tool to show how to change the behavior of a bot, or "copilot" in Microsoft parlance, through prompt injection. There are two types: A direct prompt injection, or jailbreak, is where the attacker manipulates the LLM prompt to alter its output. With indirect prompt injections, attackers modify the data sources accessed by the model.

Using the tool, Bargury can add a direct prompt injection to a copilot, jailbreaking it and modifying a parameter or instruction within the model. For instance, he could embed an HTML tag into an email to replace a correct bank account number with that of the attacker, without changing any of the reference information or altering the model with, say, white text or a very small font.

"I'm able to manipulate everything that Copilot does on your behalf, including the responses it provides for you, every action that it can perform on your behalf, and how I can personally take full control of the conversation," Bargury tells Dark Reading.

Further, the tool can do all of this undetected. "There is no indication here that this comes from a different source," Bargury says. "This is still pointing to valid information that this victim actually created, and so this thread looks trustworthy. You don't see any indication of a prompt injection."

**RCE = Remote "Copilot" Execution Attacks**

Bargury describes Copilot prompt injections as tantamount to remote code-execution (RCE) attacks. While copilots don't run code, they do follow instructions, perform operations, and create compositions from those actions.

"I can enter your conversation from the outside and take full control of all of the actions that the copilot does on your behalf and its input," he says. "Therefore, I'm saying this is the equivalent of remote code execution in the world of LLM apps."

During the session, Bargury demoed what he describes as remote Copilot executions (RCEs) where the attacker:

*   Exfiltrates data in advance of an earnings report to trade on that information
    
*   Makes Copilot a malicious insider that directs users to a phishing site to harvest credentials
    

Bargury isn't the only researcher who has studied how threat actors could attack Copilot and other chatbots with prompt injection. In June, Anthropic detailed its approach to red team testing of its AI offerings. And for its part, Microsoft has touted its red team efforts on AI security for some time.

**Microsoft's AI Red Team Strategy**

In recent months, Microsoft has addressed newly surfaced research about prompt injections, which come in direct and indirect forms.

Mark Russinovich, Microsoft Azure’s CTO and technical fellow, recently discussed various AI and Copilot threats at the annual Microsoft Build conference in May. He emphasized the release of Microsoft's new Prompt Shields, an API designed to detect direct and indirect prompt injection attacks.  

"The idea here is that we're looking for signs that there are instructions embedded in the context, either the direct user context or the context that is being fed in through the RAG \[retrieval-augmented generation\], that could cause the model to misbehave," Russinovich said.

Prompt Shields is among a collection of Azure tools Microsoft recently launched that are designed for developers to build secure AI applications. Other new tools include Groundedness Detection to detect hallucinations in LLM outputs, and Safety Evaluation to detect an application's susceptibility to jailbreak attacks and creating inappropriate content.

Russinovich also noted two other new tools for security red teams: PyRIT (Python Risk Identification Toolkit for generative AI), an open source framework that discovers risks in generative AI systems. The other, Crescendomation, automates Crescendo attacks, which produce malicious content. Further, he announced Microsoft’s new partnership with HiddenLayer, whose Model Scanner is now available to Azure AI to scan commercial and open source models for vulnerabilities, malware or tampering.

**The Need for Anti-"Promptware" Tooling**

While Microsoft says it has addressed those attacks with safety filters, AI models are still susceptible to them, according to Bargury.

He says in specific, there's a need for more tools that scan for what he and other researchers call "promptware," i.e., hidden instructions and untrusted data. "I'm not aware of anything you can use out of the box today \[for detection\]," Bargury says.

"Microsoft Defender and Purview don't have those capabilities today," he adds. "They have some user behavior analytics, which is helpful. If they find the copilot endpoint having multiple conversations, that could be an indication that they're trying to do prompt injection. But actually, something like this is very surgical, where somebody has a payload, they send you the payload, and \[the defenses\] aren't going to spot it."

Bargury says he regularly communicates with Microsoft's red team and notes they are aware of his presentations at Black Hat. Further, he believes Microsoft has moved aggressively to address the risks associated with AI in general and its own Copilot specifically.

"They are working really hard," he says. "I can tell you that in this research, we have found 10 different security mechanisms that Microsoft's put in place inside of Microsoft Copilot. These are mechanisms that scan everything that goes into Copilot, everything that goes out of Copilot, and a lot of steps in the middle."

**About the Author**

Jeffrey Schwartz is a journalist who has covered information security and all forms of business and enterprise IT, including client computing, data center and cloud infrastructure, and application development for more than 30 years. Jeff is a regular contributor to Channel Futures. Previously, he was editor-in-chief of Redmond magazine and contributed to its sister titles Redmond Channel Partner, Application Development Trends, and Virtualization Review. Earlier, he held editorial roles with CommunicationsWeek, InternetWeek, and VARBusiness. Jeff is based in the New York City suburb of Long Island.

How to Weaponize Microsoft Copilot for Cyberattackers

Microsoft execs detailed the company's reaction to the CrowdStrike incident and emphasized the value of a collective identity.

Ann Johnson, Corporate Vice President and Deputy CISO at Microsoft, and Sherrod DeGrippo, Director of Threat Intelligence Strategy at Microsoft, on the main stage at Black Hat USA.Source: Kristina Beek

BLACK HAT USA – Las Vegas – Wednesday, Aug. 7 – This week at Black Hat, Ann Johnson, corporate vice president and deputy chief information security officer (CISO) at Microsoft, and Sherrod DeGrippo, Microsoft's director of threat intelligence strategy, took to the main stage for their talk, "From the Office of the CISO: Smarter, Faster, Stronger, Security in the Age of AI." While attendees may have expected a discussion focused on ways that AI can help the effectiveness of cybersecurity tools, one could say that Johnson and DeGrippo decided to go off script.

"Does anyone remember a couple of weeks ago, there was like a little glitch?" DeGrippo asked the crowd, referring to the recent global CrowdStrike outage and earning a laugh in response.

The fault sensory configuration update to CrowdStrike's Falcon platform on July 19 triggered Microsoft outages for millions, and "blue screens of death" as far as the eye could see. As the days passed, the fallout continued to grow, with the estimated monetary loss amounting to roughly $5.4 billion, excluding Microsoft's own losses.

Johnson went on to give the audience the lowdown from someone who was there and witnessed the effects of the outage firsthand. The evening before the incident, Microsoft found itself dealing with a limited scope package in Azure in one of its US regions. 

"At 11:30 that night, it was remediated, was resolved, and I went to bed," Johnson said. "I was like 'OK, we're good.' At 1 in the morning, maybe 1:15, my phone rang with a customer \[who\] said 'Hey, I’m getting this blue screen of death.'"

Other calls started coming in, and she realized this wasn't connected to the Azure outage. Johnson explained that Microsoft then "rallied the troops" to face the problem.

"The pride I had, not just in Microsoft but those people that were literally working in shifts … these folks were working around the clock," she says. "The industry was working around the clock. And even though it was the operations folks that were most impacted, not the cyber folks, the resilience, the community, the things I saw in the industry were so powerful that yet again, it renews my faith that we all can win together."

Johnson’s take on the event is that the response to it from professionals was "incredible" to witness. However, what is the lesson to be learned?

**Community Is No. 1**

As DeGrippo detailed, the Microsoft Threat Intelligence Center (MSTIC) is focused on working closely with customers regarding intelligence briefings, and is "embedded" in its community of independent researchers, fellow vendors, and even colleagues at healthcare organizations and in other verticals.

For instance, Scattered Spider, a group responsible for a significant number of ransomware events in the past 18 months, is a persistent group that Microsoft has paid close attention to. Microsoft's community, from MSTIC to its Digital Crimes Unit (DCU), DeGrippo says, is eager to combat the group, helping law enforcement efforts. And it's not just Microsoft that does this, Johnson insists — its peers in the industry are also working with the public sector to defend people from the threat actor, sharing tactics and defense strategies. 

"For everything you see in the news, there are thousands of \[malicious\] things that haven’t happened because all the people in this room stopped it from happening," Johnson told Black Hat attendees. "Take a victory lap and a round of applause. Yeah, there’s bad things that are going to continue to happen. But all you stop the thousands of other things from happening, and that’s what community does."

**AI in the Hands of Threat Actors & Defenders**

Part of improving the community going forward is embracing technologies that make defenders' lives easier. For instance, as GenAI continues to grow in popularity, threat actors will use it to their advantage. According to Johnson, they'll use it to become more effective and efficient at what they do, making them more difficult to combat. What should defenders do in response? The exact same thing. 

"We want to use technology like AI or whatever the latest technology is to make you more effective, so you can take that time off," she said, referencing how new strategies and tools are needed to ensure that cyber defenders have less burnout. Events like the CrowdStrike Falcon update snafu and the resulting Microsoft outage should not require people to sacrifice their health or time with family while "working hours on end to combat the issues we’re collectively facing," Johnson said.

She added, "AI does have a very meaningful role in the world of the CISO and in the world of cyber defenders, but … we want to talk about the human beings, the community, the defenders."

Microsoft on CISOs: Thriving Community Means Stronger Security

Attackers can use a seemingly innocuous IP address to exploit localhost APIs to conduct a range of malicious activity, including unauthorized access to user data and the delivery of malware.

Source: Tada Images via Shutterstock

Attackers can use a flaw that exploits the 0.0.0.0 IP address to remotely execute code on various Web browsers — Chrome, Safari, Firefox, and others — putting users at risk for data theft, malware, and other malicious activity.

Researchers at open source security firm Oligo Security have discovered a way to bypass browser security and interact with services running on an organization's local network from outside the network, that they are calling "0.0.0.0 Day," because of the Web address it exploits.

The vulnerability exists due to "the inconsistent implementation of security mechanisms across different browsers, along with a lack of standardization in the browser industry," Avi Lumesky, an Oligo AI security researcher, revealed in a blog post published this week.

Attackers can use the flaw to exploit localhost application programming interfaces (APIs) from the browser, thus performing a range of malicious activities.

"As a result, the seemingly innocuous IP address, 0.0.0.0, can become a powerful tool for attackers to exploit local services, including those used for development, operating systems, and even internal networks," Lumesky wrote.

**Breaking Down the Flaw**

The flaw lies in the ability by design of browsers for services to send a request to almost any HTTP server using JavaScript; a browser's key job is to focus on delivering the correct response, either by serving up a valid response to a request or an error.

While browsers are generally supposed to prevent errant or malicious requests from getting through via their responses, there has been a lack of streamlined security in handling requests across browsers since their inception.

"For a long time, it was not clear how browsers should behave when they make requests to local or internal networks from less-private contexts," Lumesky explained in the post.

While most browsers have relied on CORS, or Cross-Origin Resource Sharing — a standard defining a way for client Web applications that are loaded in one domain to interact with resources in a different domain — "its performance depends on the response content, so requests are still made and can still be sent," Lumesky noted.

"This is simply not good enough," he wrote. "History proved that a single HTTP request can attack a home router — and if that's all it takes, every user needs to be able to prevent this request from happening at all."

**PNA Bypass**

Chrome's introduction of Private Network Access (PNA) — which goes beyond CORS — should, in theory, protect websites from the 0.0.0.0 day bug. PNA proposes distinguishing between public, private, and local networks, ensuring that "pages loaded under a less-secure context will not be able to communicate with more-secure contexts," Lumesky wrote.

However, Oligo researchers discovered that website requests sent to 0.0.0.0, which should be blocked under PNA, were actually received and processed by local servers. "This means public websites can access any open port on your host without the ability to see the response," Lumesky wrote.

To prove their point, the attackers investigated how ShadowRay, a recent attack campaign its researchers discovered targeting AI workloads, could execute its attack from the browser using 0.0.0.0 as its attack vector.

ShadowRay enabled arbitrary code execution when a private server was unintentionally exposed to the Internet, and went undiscovered for nearly a year. To prove their concept, Oligo researchers ran a local Ray cluster on localhost, then started a socket that is listening to new connections to open a reverse shell.

"Then, the victim clicks on the link in the email, which runs the exploit," Lumesky explained. "The exploit opens a reverse shell for the attacker on the visitor’s machine."

The researchers proved the concept within Chromium, Safari, and Firefox to execute ShadowRay from the browser in "one of an undoubtedly huge number of remote code execution attacks enabled by this approach," Lumesky noted. They also proved the attack via Selenium Grid public servers and PyTorch TorchServe via respective previously identified attack campaigns SeleniumGreed and ShellTorch.

Ultimately, the researchers demonstrated how by using 0.0.0.0 together with mode "no-cors," attackers "can use public domains to attack services running on localhost and even gain arbitrary code execution, all using a single HTTP request," Lumeksy explained.

**How Defenders Can Mitigate Attacks**

Oligo disclosed the findings to the relevant browser owners — including Google, Apple, and Mozilla — which responded by making fixes in their browsers to block 0.0.0.0 as a target IP, according to Oligo.

Meanwhile, as the companies in charge work to streamline security standards across browser offerings, there are other technical mitigations that network administrators can use to thwart attacks using the vector, Lumesky said.

They include implementing PNA headers, verifying the HOST header of the network request to protect against DNS rebinding attacks to localhost or 127.0.0.1, and generally mistrusting localhost networks just because they are "local." "Add a minimal layer of authorization, even when running on localhost," he advised.

Network administrators should also use HTTPS over HTTP whenever possible and implement CSRF tokens in your applications, even if they are local.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

'0.0.0.0 Day' Flaw Puts Chrome, Firefox, Mozilla Browsers at RCE Risk

The Dark Reading team once again welcomes the world's top cybersecurity experts to the Dark Reading News Desk live from Black Hat USA 2024. Tune into the livestream.

The Dark Reading News Desk will live stream for a second day today, Thursday, Aug. 8, from 10 a.m. PDT/1 p.m. ET to 4 p.m. PT/7 p.m. ET. The video will also be available on YouTube following the live stream.

You don't have to trek to Las Vegas to experience the best of Black Hat USA 2024.

The Dark Reading team is back again with the News Desk, steaming live from the heart of the Black Hat action at Mandalay Bay.

During two full days of live Black Hat coverage, Dark Reading has invited the world's top cybersecurity researchers, leaders, and experts to sit down at the News Desk and take on today's most pressing issues, including the rise of artificial intelligence and the evaluation of national cybersecurity strategies, as well as analyst forecasts into the year ahead and beyond.

Today, the Dark Reading News Desk lineup continues with Akamai researcher David Ori, who will offer highlights from his Black Hat Briefing on VPN post-exploitation techniques. In addition, Narayana Pappu, CEO of Zendata, will talk about the privacy risks inherent with post-cookie advertising tech solutions, and Michael Bargury, chief technology officer of Zenity, will reveal what he found in his research on the much-talked-about Microsoft Copilot.

Yesterday, Dark Reading spoke with Omdia director Maxine Holt to break down the highlights from the Omdia Analyst Summit at Black Hat, as well as MITRE engineers Marissa Dotter and Alexander Byrne, who discussed their research on large language models for offensive use. Columbia University scholar Jason Healy also stopped by to share insights into his Black Hat USA 2024 Briefing, "Is Defense Winning?"

Join the Dark Reading News Desk for ongoing, up-to-the-minute coverage of the very best of Black Hat USA 2024 from wherever you are. Check out conversations you won't hear anywhere else.

Dark Reading News Desk Live From Black Hat USA 2024

As AI technologies continue to advance at a rapid pace, privacy, security and governance teams can't expect to achieve strong AI governance while working in isolation.

Source: marcos alvarado via Alamy Stock Photo

COMMENTARY

AI technology is proliferating at a rapid pace, becoming an essential component of many businesses' operations. While organizations are achieving genuine benefits with them, the rise of AI-based systems does create new obstacles regarding data privacy, reputational risk, and new attack vectors for companies. 

AI systems rely on massive amounts of data, often including sensitive personal information. Improper handling of this data can lead to cyber vulnerabilities, privacy violations, and legal and regulatory issues. When tampered with, AI tools also have the potential to cause reputational damage — such as when Microsoft's AI chatbot Tay was exploited by users who fed it offensive and racist content, or when Amazon's AI recruiting tool exhibited bias against female candidates after being trained on historical hiring data that favored men. These incidents illustrate how important it is for organizations to implement safeguards to ensure AI systems aren't learning — and then generating outputs with — biased or malicious data.

Developing these safeguards requires a collaborative approach from privacy, security, and governance teams. While these teams, of course, have their areas of expertise, approaching AI governance from siloes won't work. Here are some ways that privacy, security, and governance teams can each flex their strengths to collaborate on strong AI governance:

**Security Team**

*   Infrastructure hardening: Strengthen your organization’s AI/ML infrastructure so that it can handle extensive training data — securely. You can achieve this by building strong access controls over who can access training data, setting multifactor authentication protocols for any access to the infrastructure, patching the infrastructure, and so on. Test the strength of your AI/ML infrastructure with red teaming or penetration testing. 
    
*   Alerting and monitoring: Develop robust monitoring capabilities to detect and prevent theft of your proprietary AI models.
    
*   Data leakage prevention: Adequate governance over the data being input into third-party AI systems is crucial; after all, this is what these AI systems will be trained on. Implement data leakage prevention solutions and strategies to monitor the sensitive data flowing into your and third-party AI systems, and ensure all AI solutions are vetted before uploading any sensitive information.
    
*   Employee training: Educate employees on AI-related risks, such as deepfakes and voice-based vishing attacks. Regularly test employees on their abilities to identify and thwart potential attacks.
    

**Governance Team**

*   Evaluate, evaluate, evaluate: Continuously evaluate the ethical implications of using AI technologies within your organization, and cross-check your AI and data practices with new regulation to ensure you remain compliant.
    
*   And educate, educate, educate: With the rapidly changing landscape, it’s crucial to continuously educate and enable your employees on risks and organizational policies for AI usage.
    

**Privacy Team**

*   AI risk assessments: Own the process of conducting risk assessments for AI projects to identify and mitigate privacy and compliance risks. 
    
*   Privacy by design: Implement privacy-by-design principles in AI development to build privacy-focused AI systems. These include ensuring consumer consent gathering strategies are understood, putting privacy safeguards in place to protect personal data, and implementing data anonymization strategies when training models.
    
*   Maintaining transparency and user preferences: Build workflows to ensure transparency and manage user consent, preferences, and data rights effectively.
    

**Working Together**

Collaboration between these teams is crucial for effective AI governance. Here's where they'll intertwine most:

*   AI task force: Develop a cross-functional AI task force within the organization with representation from key stakeholders across privacy, security, and governance. This task force will be responsible for developing AI guidelines and policies for the organization, approving the procurement of new AI technologies to carefully evaluate and mitigate AI risks, and ensuring that AI safety is prioritized when new systems are developed. Schedule regular meetings (monthly, for example) for the AI task force to discuss industry trends, emerging threats, and new use cases for AI technologies.
    
*   Dedicated communication channels: Establish channels where employees can easily ask questions and receive timely information about approved AI tools and their use. Utilize cross-functional forums like company all-hands or department-specific all-hands meetings to communicate organization-wide updates pertaining to AI use and considerations.
    
*   Leveraging technology and automation: The rise of AI systems has led to innovative technologies designed to identify and catalog AI systems within your organization and supply chain. It is essential to evaluate and implement these tools to enhance your AI governance framework. Integrating these advanced technologies, as well as solutions like SecurityPal for navigating security reviews, can help you maintain oversight, ensure compliance, and effectively manage the growing complexity of AI applications.
    

As AI technologies continue to advance at a rapid pace, privacy, security, and governance teams can't expect to achieve strong AI governance while working in isolation. The creation of an AI task force, fostering open communication around timely challenges and risks, will provide immediate benefits. Working together, rather than in siloes, these teams can ensure your AI systems are developed and deployed responsibly, ethically, and securely, ultimately safeguarding your organization's reputation and integrity.

**About the Authors**

Sanket Kavishwar, Director of Product Management, Relyance AI

Sanket Kavishwar is director of product management at Relyance AI. With more than a decade of experience in SaaS, Sanket has a diverse background encompassing roles as a software engineer developing security solutions, a consultant implementing ERP solutions for enterprise clients, a customer success leader managing enterprise accounts, and a go-to-market leader scaling advanced privacy programs for enterprises. Currently, as a product leader, he focuses on delivering products at the intersection of privacy and security.

Security & GRC Lead, Plaid

Kenneth Moras, security and GRC lead for Plaid, is a cybersecurity leader with extensive experience in building strategic risk management programs at Plaid and scaling cybersecurity programs at notable organizations such as Meta and Adobe. His expertise also extends to cybersecurity consulting for Fortune 500 companies during his tenure at KPMG.

Building an Effective Strategy to Manage AI Risks

Black Hat presentation reveals adversaries don't need to complete all seven stages of a traditional kill chain to achieve their objectives.

Source: Funtap via Shutterstock

BLACK HAT USA – Las Vegas – Thursday, Aug. 8 – Organizations that are expanding their use of SaaS applications may want to revise their notions of — and approaches to — the cyber kill chain.

SaaS applications have transformed the modern organization's attack surface and eliminated — or made easier — several of the steps that adversaries have traditionally needed to execute a successful attack, researchers at AppOmni said in a talk at Black Hat USA 2024.  Security teams need to revise and readjust their defenses to keep ahead of the new reality.

**The SaaS Kill Chain**

"The SaaS-enabled kill chain, when considered from the lens of MITRE ATT&CK tactics, is abbreviated," the researchers said. "Several steps are often skipped or entirely unnecessary for an attack to accomplish their goals and the majority of defenses are focused on the initial access stage."

The software-as-a-service model has become nearly ubiquitous. Research Productiv conducted last year revealed organizations, on average, used a staggering 342 SaaS applications at the end of 2023, with operations teams being the biggest users, followed by IT, sales, and product teams. Among the most popular SaaS products were Confluence, Salesforce, Tableau, Atlassian Cloud, and Jira.

AppOmni found the growing use of such applications give adversaries new — and often quicker — ways to target enterprise application and data than before. Researchers at the company analyzed some 230 billion normalized SaaS audit log events from across 24 different SaaS services and 1.9 million alerts over a six-month period to get an idea of attacker tactics, techniques, and procedures (TTPs) in SaaS environments.

The analysis showed that attackers often don't need to execute all seven steps of the traditional chain to launch a successful SaaS attack. Lockheed Martin's cyber kill chain — which has long been used as a basis for defending against attacks — identifies reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives as actions an adversary must complete to pull off a successful attack.

With attacks on SaaS environments, "the kill chain from an attacker's perspective is really centralized down to a couple of points: initial access and credential access, and collection and exfiltration," Brandon Levene, principal product manager, threat detection, at AppOmni tells Dark Reading.

**Walking in Through the Front Door**

In many of the attacks that AppOmni analyzed, adversaries gained access to an organization's SaaS applications through an externally facing identity provider. "Usually, they just walk in through the front door with valid accounts," Levene says. Attackers often use infostealers to grab user credentials to cloud accounts or tactics like credential stuffing, brute force, and password spraying to acquire credentials to cloud accounts — or they simply purchase them in Dark Web markets, according to Levene.

"Once you are past the IdP \[identity provider\] like an Okta, or a Ping or an Entra, all applications behind that are freely available to you as the attacker," he says. That means attackers don't have to necessarily conduct reconnaissance to gather information on a target environment because they already have access to it.

Similarly, an attacker needs little time and resources to establish persistence on a compromised environment or enable lateral movement because a valid credential gives them persistent and wide access to whatever they need. "Once you compromise an externally facing identity provider like Okta, you don't need persistence or lateral movement," Levene says.

He points to two large attacks that AppOmni analyzed as examples of how adversaries target SaaS environments. In one of them, the threat actor logged into the IdP using a valid token and then modified the IP ranges that were allowed to authenticate to various applications. In just 10 minutes, the threat actor downloaded more than 100 files from cloud storage and information repositories. They also modified authentication policies for some applications and changed direct deposit payment choices in a likely attempt to redirect funds. "They didn't have to go through a VPN. They didn’t even bother to obfuscate their real location. What they did was basically smash and grab," Levene says.

He adds that many of the brute force, password spraying, and credential stuffing attacks that AppOmni observed targeted Microsoft O365 and came from two large Chinese networks: ChinaNet and China Unicon.

Enabling better visibility across SaaS environments is a key first step to protecting against such attacks, he notes. Organizations need to understand their attack surface, look at how their SaaS apps are configured and monitor them. They must also fully leverage their IdP's capabilities and features like MFA and hardware tokens. Levene adds that the goal should be to enforce a zero-trust access model to SaaS applications.

**About the Author**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

SaaS Apps Present an Abbreviated Kill Chain for Attackers

Researchers at Aqua Security discovered the "Shadow Resource" attack vector and the "Bucket Monopoly" problem, where threat actors can guess the name of S3 buckets based on their public account IDs.

Source: Holger Burmeister via Alamy Stock Photo

BLACK HAT USA – Las Vegas – Thursday, Aug. 8 – Six critical vulnerabilities in Amazon Web Services (AWS) could have allowed threat actors to target organizations with remote code execution (RCE), exfiltration, denial-of-service attacks, or even account takeovers.

"Most of the vulnerabilities were considered critical because they gave access to other accounts with minimal effort from the attacker perspective," Aqua's lead security researcher Yakir Kadkoda tells Dark Reading.

During a briefing on Wednesday at Black Hat USA in Las Vegas, researchers at Aqua Security revealed that they discovered new attack vectors using bugs "Bucket Monopoly" and "Shadow Resources." The impacted AWS services include Cloud Formation, CodeStar, EMR, Glue, SageMaker, and Service Catalog.

Upon discovering the vulnerabilities in February, the Aqua researchers reported them to AWS, which confirmed the issues and rolled out mitigations to the respective services piecemeal between March and June. However, open source iterations could still be vulnerable.

**'Bucket Monopoly': Attacking Public AWS Account IDs**

The researchers first uncovered Bucket Monopoly, an attack method that can significantly boost the success rate of attacks that exploit AWS S3 buckets — i.e., online storage containers for managing objects, such as files or images, and resources required for storing operational data.

The issue is that S3 storage buckets were designed to use predictable, easy-to-guess AWS account IDs instead of a unique identifier for each bucket name using a hash or qualifier.

"Sometimes the only thing that an attacker needs to know about an organization is their public account ID for AWS, which is not considered sensitive data right now, but we recommend it is something that an organization should keep as a secret," Kadkoda says.

To mitigate the issue, AWS changed the default configurations.

"All of the services have been fixed by AWS in that they no longer create the bucket name automatically," he explains. "AWS now adds a random identifier or sequence number if the desired bucket name already exists."

Security researchers and AWS customers have long debated whether AWS account IDs should be public or private. AWS cautions customers against sharing credentials and advises them to use and share account IDs carefully. However, according to AWS documentation on account identities, account IDs "are not considered secret, sensitive, or confidential information."

Aqua's researchers disagree.

"Based on our research, we strongly believe that account IDs should be considered secrets since there may be other kinds of similar exploits that could be carried out based on knowing an account ID," Kadkoda notes in a detailed technical report on the vulnerabilities set to be published on Friday. "Although the common assumption is that knowing an account ID alone is not sufficient to hack an account, attackers might still use it to gather information about your AWS account and more."

An AWS spokesperson declined to comment on that specifically, but did say that AWS was aware of this research.

"We can confirm that we have fixed this issue, all services are operating as expected, and no customer action is required,” the spokesperson says.

**Shadow Resources: Hidden Assets Offer Cover for Attackers**

Kadkoda says his team also discovered the Shadow Resources attack vector, which can create AWS S3 service components unknown to the account owner.

The researchers initially discovered the problem in the AWS CloudFormation service, where an attacker could engage in resource squatting by creating accounts in unused AWS geographic regions with the same name as legitimate, existing stacks. Once the victim stored their workloads in a new region, they could connect to it and then unknowingly use attacker-controlled S3 buckets.

That's because when using the service with the AWS Management Console to create a new stack, AWS automatically creates an S3 bucket to store CloudFormation templates. The name of the S3 bucket is the same across all AWS regions, which is how an attacker can guess the account name and gain access to it.

"I can take over your S3 bucket and just poison the configuration and replace it," Aqua security researcher Assaf Morag says. "It's a huge thing because in between the lines, with a remote code execution, you can grab the accounts of any company in the world."

All services require configuration files, and AWS uses S3 buckets as its file system to store configurations.

"In most cases, these configurations are really significant because these are the instructions to the services," Morag says. "It could be a YAML file or other things that the service needs to use behind the scenes."

Given that customers can have hundreds or thousands of distinct AWS accounts spread across regions worldwide, exploits of shadow services could have been significant, Morag emphasizes. Where there were any victims of the vulnerability is not known.

"The potential of being attacked or being a victim could have been massive," he says.

**Open Source Projects in S3 Buckets Could Still Be Vulnerable**

While AWS has mitigated the vulnerabilities impacting its services, Kadkoda warns that the attack vectors could still impact open source projects deployed in their AWS environments. Many open source projects automatically create S3 buckets or direct users to deploy them, he notes.

"We found a lot of open source projects vulnerable to this vector because they're using them behind the scenes with predictable bucket names," Kadkoda says.

Users should check to see whether each existing bucket's name has been claimed elsewhere, and, if so, they should rename it.

In all cases, Kadkoda and Morag say users should avoid creating S3 buckets with predictable or static identifiers in the first place. Instead, they should create an S3 bucket name with a unique hash or a random identifier for each region and account to prevent attackers from claiming them first.

**About the Author**

Jeffrey Schwartz is a journalist who has covered information security and all forms of business and enterprise IT, including client computing, data center and cloud infrastructure, and application development for more than 30 years. Jeff is a regular contributor to Channel Futures. Previously, he was editor-in-chief of Redmond magazine and contributed to its sister titles Redmond Channel Partner, Application Development Trends, and Virtualization Review. Earlier, he held editorial roles with CommunicationsWeek, InternetWeek, and VARBusiness. Jeff is based in the New York City suburb of Long Island.

Critical AWS Vulnerabilities Allow S3 Attack Bonanza

Invisible authentication mechanisms in Microsoft allow any attacker to escalate from privileged to super-duper privileged in cloud environments, paving the way for complete takeover.

Source: Sergey Nivens via Alamy Stock Photo

BLACK HAT USA – Las Vegas – Wednesday, Aug. 7 – An obscure issue with Microsoft's Entra ID identity and access management service could allow a hacker to access every corner of an organization's cloud environment.

Crucially, the attack requires that a hacker already have access to an admin-level account. With that in hand, though, the possibilities are limitless. At 4:20 p.m. local time today at Black Hat, Eric Woodruff, senior cloud security architect at Semperis, will describe how an attacker in such a position could take advantage of layered authentication mechanisms in Entra ID to gain all-powerful global administrator privileges.

An attacker with global administrator privileges can do anything in an organization's cloud environment to any of its connected services, including but not limited to accessing sensitive data and planting malware. As Woodruff explains, "It's like being a domain administrator in the cloud. As a global administrator, you can literally do anything: You could get into people's emails in Microsoft 365, you could move into any application that's tied to Azure, etc."

Entra ID is central to any organization using Microsoft 365 and Azure, managing and securing access and permissions across cloud applications and services.

Within each tenant (organization), Entra ID represents users, groups, and applications as "service principals," which can be assigned roles and permissions of one kind or another.

The problem identified by Woodruff begins with the fact that users with privileged Application Administrator or Cloud Application Administrator roles can assign credentials directly to a service principal. An attacker with such privileges can use this system quirk to effectively act as their targeted application when interfacing with Entra ID.

Next, the attacker can follow the OAuth 2.0 client credential grant flow, exchanging credentials for tokens that grant access to resources. This is where the second major issue comes into play. During his research, Woodruff identified three application service principals capable of performing actions they didn't appear to have permission to enact:

*   In the enterprise social networking service Viva Engage (formerly Yammer), the ability to permanently delete users, including Global Administrators.
    
*   In the Microsoft Rights Management Service, the ability to add users.
    
*   For the Device Registration Service, the ability to elevate privileges to the Global Administrator level
    

The Microsoft Security Response Center (MSRC) assigned these vulnerabilities medium, low, and high severity ratings, respectively.

Woodruff emphasizes that the issue with the Device Registration Service is far more significant than the others. "Generally, you would delegate Admin roles to people doing more day-to-day, mundane things \[in your organization\]. They don't have the power to do whatever. But if they happen to know of this path we found, they could go give themselves that role," he explains.

**Dealing With Cloud Permissions**

When Woodruff went to Microsoft with his findings, the company explained that, in fact, he was allowed to do what he did thanks to hidden authentication mechanisms "behind the scenes."

Dark Reading reached out to Microsoft for more information about how these layered, unseen authentication mechanisms work, and why they exist in the first place. A Microsoft spokesperson replied with no further details.

For now, Microsoft has been patching over the issue with new controls that limit the use of credentials on service principals. Now, when one attempts privilege escalation using the Device Registration Service, Microsoft Graph returns an error.

It's unclear whether this issue has ever been exploited in the wild. To determine that, Woodruff says, organizations can review Entra ID audit logs, or look out for leftover attacker credentials. Neither method is foolproof, however, as logs tend to expire after a certain period of time, and attackers can always retroactively hide their paper trails.

"Having worked in the whole Microsoft ecosystem awhile, I've run a lot of security assessments and would find that a lot of organizations have relatively lax security around application administrators. You see it in the news these days: Someone targets the help desk, and the next thing you know, they're a domain admin, because of some privilege chain," he says.

This latest discovery, though part of the same pattern, was nonetheless a bit of a shock. "It was sort of like: Oh, these app admins at a lot of orgs aren't really guarded the way they should be," he says.

**About the Author**

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

Hazy Issue in Entra ID Allows Privileged Users to Become Global Admins

The number of additions to the Known Exploited Vulnerabilities catalog is growing quickly, but even silent changes to already-documented flaws can help security teams prioritize.

CVE age distribution of KEV by groupSource: GreyNoise Intelligence

B-SIDES LAS VEGAS – Las Vegas – Wednesday, Aug. 7 – Organizations that use the Known Exploited Vulnerabilities (KEV) catalog to prioritize patching are likely missing silent changes to the list that could indicate that an issue's severity has changed, according to an analysis presented at the BSides Las Vegas conference on Aug. 7.

The KEV catalog — which currently consists of more than 1,140 vulnerabilities that are known to have been exploited in the wild — tracks software flaws by their Common Vulnerabilities and Exposures (CVE) identifier, records the date when the vulnerability was confirmed in the wild and has a flag that indicates whether ransomware groups are using the security issues.

Yet, specific changes to the data — such as uncommonly short times to remediate vulnerabilities and changes to the ransomware status — can give security teams valuable information, the analysis stated.

Unfortunately, the Cybersecurity and Infrastructure Security Agency (CISA), which manages the list, does not often call out these changes and outliers, says Glenn Thorpe, senior director of security research and detection engineering at GreyNoise Intelligence.

"We who are not bound by its directives forget that this is actually a to-do list," he says, adding: "So, if folks are actually using this to prioritize remediation or some kind of process, they need to know \[when\] it is updated silently."

The KEV catalog, introduced in November 2021 with 290 exploited vulnerabilities, is maintained by CISA and gives organizations the information necessary to prioritize patching flaws that are currently under attack. The list, however, does not rank the severity of issues, and vulnerabilities are often not added until well after the initial evidence of exploitation comes to light.

**Surge From a Cyber Conflict**

While less than 3 years old, the KEV catalog has already passed through three periods, Thorpe says. The original catalog had 287 vulnerabilities, which had an average age — the time between the release of the CVE and the vulnerability's addition to the KEV list — of 591 days. Then, during a 109-day period in early 2022 and the initial months of Russia's invasion of Ukraine, a massive stockpile of vulnerabilities was exploited, encompassing 396 issues with an average age of 1,898 days.

Starting in mid- to late 2023, CISA started changing its policies on the KEV catalog, providing additional signals as to the severity of a vulnerability. Source: GreyNoise Intelligence

Since mid-2022, 453 newly exploited vulnerabilities have been discovered, with an average age of 567 days.

"There is this thought that maybe the numbers have gone down, because the Russia-Ukraine conflict has dragged on so long," he says. "But I \[feel that\] when it ends, each side will looking for vulnerabilities and stockpiling once again."

Five organizations — Microsoft, Apple, Cisco, Adobe, and Google — account for about half of all vulnerabilities on the list, demonstrating cyberattackers' penchant for major software platforms.

**Pay Attention to Friday Updates**

While any vulnerability in the KEV catalog should likely be patched as soon as possible, companies may want to prioritize those being used in ransomware campaigns. The list has a flag designating whether CISA has confirmed use of a particular flaw by ransomware gangs. However, at least 41 times, that flag has been changed to "known" — indicating ransomware use — after the vulnerability's addition to the list without explicit notification.

Perhaps more critical for prioritization is the "due date" for fixing a vulnerability, which informs federal agencies of the date by which the issue must be remediated. While the vast majority of vulnerabilities have a 21-day requirement, since late 2023, CISA has set shorter remediation deadlines for specific vulnerabilities. The shorter patching deadlines are typically for more critical appliances that are connected to a networks, such as the severe Ivanti vulnerabilities, as well as issues in Juniper routers and Cisco devices and Atlassian's Confluence server, GreyNoise's Thorpe says.

In fact, another data point suggests that CISA made other changes to how it handles KEV-catalog announcements in late 2023. Around the same time that CISA had assigned shorter deadlines, the agency also began foregoing the release of any list updates on Fridays, except in two specific cases, the analysis found.

"Either there was a decision made to prioritize these a little differently, or they ... were kind of figuring out how to prioritize these differently, because the list is getting big," Thorpe says.

Organizations can use the policy changes inferred from the way CISA updates the KEV catalog to understand which issues the agency considers most critical. A KEV update released on a Friday should be considered significant, as should a vulnerability with a due date less than 21 days away. Finally, Thorpe says, updates to the known ransomware usage field are another signal that security teams should pay attention to.

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

Source

DARKReading